Discussion issue for #848: balloting of optional whitespace at complex message start

[aphillips]

Use this issue to discuss technical issues related to #848.

Note that there is already extensive discussion in:

• Recent telecons
• Discussion Thread for Delimiting Pattern Boundaries #507
• PEWS design document

[eemeli]

One aspect of our current syntax that I've not seen noted in the previous discussions on this is that right now, .foo is not a valid message but .foo is, because of the leading space. I find this difference rather surprising, as the leading space is effectively escaping the .. I don't think that this is a practice we should encourage, even though it is much "lighter" than the officially recommended {{.foo}}.

Separately, as @stasm noted in one of our discussions on this, supporting leading spaces for complex messages is in line with our syntax design goals, as it makes the syntax easier to write for developers and makes messages easier to embed as string literals in programming languages.

[echeran]

As I said before, I'm split on this, but I voted A (status quo). I can see the argument for making the proposed change -- it doesn't complicate things too much, and can maybe some developers, so why not? On the other hand, we have discussed this at much greater length with more people in the past to arrive at our current status -- I think saying that it adds complexity taking us further away from the principle that simple messages are "WYSIWYG", it is a concern at the level of developer tooling so not in scope for MF itself, and it's not a common real-world scenario.

I have a hard time with this discussion not because of this particular topic itself, nor the likely outcome to overturn the decision we made before. Rather, the relative ease with which we're revisiting and overturning the decision unsettles me because I feel less certain on what basis we decide things. These issues are complicated, yes, and we talked about syntax a lot, ex: the times we talked about keeping the lookahead count of our LL parser to be 2 or less -- at least in meetings 2023-{2/13, 2/27, 6/19, 10/2). We're ignoring that now. Proposal B is designed to eliminate the surprising behavior of a complex message becoming a simple one if there is whitespace before it, but the complexity we're dealing with is due to the surprising contrast of simple messages starting in text mode and complex messages needing to get into code mode, whitespace, sigils, and avoiding i18n inequities while doing so.

The problems of complexity we have been dealing with since late 2023 after flipping from starting in code mode to text mode would be non-issues if we didn't go down this path. @gibson042 didn't want to say that he told us so, but that simple messages should be degenerate versions of complex messages as he said back then, and I totally agree (as I did back then). I have a much clearer sense of the principles behind that.