Ugh, Commas

[trans]

Really like how Kitten is shaping up. Just went through your slides. (Is there a video of the actually presentation anywhere, btw?). So kudos!

One thing that bothered me though was the use of commas (in type signatures, lists and tuples). For a concatenative language that just totally seers my sensibilities. Are they really necessary?

[evincarofautumn]

Thanks! Unfortunately the presentation wasn’t recorded.

Commas are a deliberate bit of redundancy, which basically just make it easier to provide good error messages (for both syntax & types) by preventing syntax from “running away”. They used to be absent from Kitten entirely—and the master compiler still uses fewer commas than the new compiler.

For example, when introducing multiple local variables, the syntax was:

-> x y z;
more code (blah)

If you forgot the semicolon, it would continue to happily eat words, treating them as variable names, until it got to the left parenthesis and reported a missing semicolon.

-> x y z
more code (blah)

Adding commas improved this:

-> x, y, z;
more code (blah)

Now, if you forget the semicolon, it will fail exactly where the error is, not at some possibly-distant later point.

[trans]

Unfortunately the presentation wasn’t recorded.

:disappointed:

Commas are a deliberate bit of redundancy, which basically just make it easier to provide good error messages (for both syntax & types) by preventing syntax from “running away”.

I see. But couldn't the same be done with bracketing of some sort?

-> ( x y z )

[evincarofautumn]

But couldn't the same be done with bracketing of some sort?

Sure, in fact it used to be -> { x y z }. People didn’t like the look of it. Same goes for [a (b + c) (d * e)] instead of [a, b + c, d * e].

[trans]

Hmm... them ain't Forthers :wink:

Well, maybe there's room for both?

In any case thanks for the discuss.

[sullyj3]

What about delimiting local assignment with newlines? So, if you actually wanted to put values into more code, you'd have to do

-> x y z
-> more code

and the

-> x y z
more code (blah)

would be valid, with more code (blah) evaluated as normal words instead of assignment.

IMO it makes sense and looks nice to have locals delimited by space, since they're dealing directly with the stack, in a kind of mirror to usual juxtaposition. Whereas lists have nothing to do with the stack, so it makes sense to have different syntax. I mean, a priori, I would've expected [a (b + c) (d * e)] to be a list containing a mini stack or something. Hmm, makes me wonder what would happen if lists were mini stacks, and you could do things like shove functions inside that context...

[evincarofautumn]

That’s not a bad idea—and presumably a semicolon would be allowed where a newline is expected, so you could still write one-liners with locals. However, I’m loath to make whitespace more significant than it already is, and every other list-like thing is already delimited with commas. I’d also like to leave the syntax open to possible future extensions that use juxtaposition for something more impactful, such as inline pattern matching. I’ll keep this discussion in mind when I revisit this area of the language; it’s just currently low on my to-do list.

[suhr]

I mean, a priori, I would've expected [a (b + c) (d * e)] to be a list containing a mini stack or something.

In fact, [ func ] could work like {func} array where array: a.. (a.. -> b..b) -> [b] — a function that calls func and wraps the result into array.

So instead of [a, b + c, d * e] you could write just [a b+c d*e]. Everything is an expression, brackets just alter the evaluation or the result.

But I believe it's consistency vs familiarity and convenience. For example, fully concatenative style for Board, Player -> Board, Optional<Player> +IO +Exit is Board Player -> Board (Player Optional) +IO + Exit. But it is definitely unfamiliar, also probably somewhat inconvenient.