Hello, On Mon, 4 Jan 2021 14:09:30 +0200 Alex Hall <alex.mojaki@gmail.com> wrote:
On Mon, Jan 4, 2021 at 1:30 PM Paul Sokolovsky <pmiscml@gmail.com> wrote:
Which leads us back to the question - did anyone of those who did that over decades ever bothered to post some kind of "spec" for this alternative syntax?
Is there a lot that needs to be specified?
Well, I surely don't expect such a "spec" to be split in 3 parts, like the pattern matching proposal. (Wait, isn't pattern matching is also simple? An expression, block scope - all those are obvious ;-)). On the other hand, previously mentioned Scheme proposal does have some size in it: https://srfi.schemers.org/srfi-119/srfi-119.html , and an improvement over 2 previous specs, so there's certainly something to spec out, to explain choices available, and argue specific selections made.
I imagine that the braces would correspond to the special INDENT and DEDENT tokens in the grammar and that's the bulk of the problem solved.
Aye, except the beginning is solved.
The only remaining questions I can think of are whether you would want to keep the colons that initiate indented blocks and how to deal with ambiguity between the new blocks and existing uses of braces like set displays.
Yes, and how do we deal with the ambiguity? As I mentioned, I'd consider an MVP a syntax which allows full rountripping [on lexical level] for initial indent-based code.
Anything else?
I don't know, that's why I ask. I hate NIH and would rather start with prior art before giving my try. Otherwise, there're issues with existing implementations, e.g.: https://github.com/nekitdev/braces.py : ========= There is a known limitation in braces.py. That is, indentation like this does NOT work: def f(x) { return x; } ========= That's not compliant implementation by any reasonable spec, so where's the spec in the first place? -- Best regards, Paul mailto:pmiscml@gmail.com