finalize static and delay syntax

[dylex]

The "delay" "keyword" only really needs to appear is types (and possibly patterns for lambda) and currently looks like function application, so is unambiguous there. In practice, there is little reason to use it in patterns, so limiting to types seems reasonable.

"static" however, appears in types similarly, but also needs to apply to let, case, and possibly lambdas. (Currently we really do treat it as a keyword in "let static", which is a hack.) One option is to allow it in patterns in general, and infer from them (let static x = ..., case x of static _ ..., static x -> ...). Another is to use special keywords. The fact that case has multiple patterns and looks strange argues for the latter. I would prefer a pre- or post-symbol, something like _let or case# or even #->. This scheme could also allow user functions like if_ to be defined following a similar pattern.

Originally I wanted "delay" and "static" to be handled the same way, general enough even to support other macro-like "transforms", but I no longer think that's a good idea, as they're quite different. As a side note, backtick is the only character not (yet) parsed as anything (infix in haskell).

[girving]

The "delay" "keyword" only really needs to appear is types (and possibly patterns for lambda) and currently looks like function application, so is unambiguous there.  In practice, there is little reason to use it in patterns, so limiting to types seems reasonable.

I'd like to keep the syntax for types and expressions as unified as possible, which means that patterns and the right side of function types involve the same grammar elements. For example, this kind of expression is valid

f (delay Int -> Float)

Hmm. Actually, maybe that's a problem. The function that takes Int and returns Float is basically the same thing as the type that takes Int and returns Float, but I guess that no longer applies once delay is in the picture.

"static" however, appears in types similarly, but also needs to apply to let, case, and possibly lambdas.  (Currently we really do treat it as a keyword in "let static", which is a hack.)  One option is to allow it in patterns in general, and infer from them (let static x = ..., case x of static _ ..., static x -> ...).  Another is to use special keywords.  The fact that case has multiple patterns and looks strange argues for the latter.  I would prefer a pre- or post-symbol, something like _let or case# or even #->.  This scheme could also allow user functions like if_ to be defined following a similar pattern.

I agree that let static is verbose, and am still fond of my "s" prefix suggestion (slet, scase, sif). I don't like the underscores or #. Putting the distinguishing mark on the -> doesn't make much sense, since it should apply uniformly to all branches.

Originally I wanted "delay" and "static" to be handled the same way, general enough even to support other macro-like "transforms", but I no longer think that's a good idea, as they're quite different.  As a side note, backtick is the only character not (yet) parsed as anything (infix in haskell).

[dylex]

While maintaining parallelism is nice, it adds a lot of complexity which seems unnecessary for no added expressiveness. With both delay and static, you often have multiple patterns which must all match, and furthermore must semantically escape out to the type level. In the case of delay, there's a delay function that can make Delays, so there's really no need for delay lambdas or lets. Restricting delay creation to typed function definitions doesn't seem like much of a loss.

Fine, I'll go with the s prefix for now. I don't like it, but it's easy to change so whatever. The one issue (which is what the arrow was about) is whether there is such a thing as a static lambda. I can't really imagine a use for them. (We also make case matching a little more all or nothing but I think that's better anyway, and you can still write multiple cases if you want selective staticness.)

In both cases, I feel like simplicity and uncluttered syntax wins out over a few edge cases. I also think of both of these as pre-processor-like features (which is why I like the #), but that may be limiting my view. But taking these things out of patterns altogether I think will be a win overall, both for adding things in the future and readability/catching typos.