stz parser ambiguity

Since I'm trying to write example code I have found it annoying that I don't have syntax highlighting. My editor of choice these days is zed which uses tree-sitter as its parser. I suppose I could take everything we know and try to make a parser grammar for it?

So I did that last night and had to leave it broken when I went to bed. Lunch time today I had another look at the problem and it's a collision between closures and methods with no arguments.

// method declaration with no arguments:
[ my-thing | -> int | 17 ]

// closure declaration with one capture:
my-thing2 = 16
my-closure = [ my-thing2 | -> int | my-thing2 + 1 ]

The two block statements are identical to the parser. It doesn't know that 'my-thing' is a variable in the second example. I then thought - okay - I need to figure out how to add contextual information to the parser definition.

However, when discussing the problem with my friend zzap he made the observation that if the parser had to have context then a developer reading the code would have to have context too. They might have to scroll back quite far in the method to find out if my-thing is a variable or not.

Instead of solving the contextual information I should strive to make the code clearer. This particular closure definition was born out of the idea that developers should be very aware that they're referencing things in a stack frame outside the block. That or implement borrow checking.

So instead I'm going to add a new piece of syntax. Instead of declaring your use of captured variables up front you must tag them with a wiggly tail ~.

For those of you who don't know, the kind of keyword syntax i've been using is called "snake-case" where you kebab the words together. Also known as kebab-case I believe. As opposed to things like CamelCase which are okay I guess. I use that endlessly in Smalltalk already. I just wanted a change of scenery and to avoid so much shift-keying.

Anyway back to the cute little tail. We can now re-write the collision:

[ my-thing | -> int | 17 ]
my-thing2 = 16
my-closure = [ -> int | ~my-thing2 + 1 ]

Every access to my-thing2 will be a reminder to the developer of that external scope. I hope. And it gives the variable a nice cute tail when you use it.

This should fix the grammar ambiguity. Hopefully there aren't more.