Add var syntax for convenient access to the state effect

[axch]

As suggested by @apaszke,

var x = stuff
...

would desugar into

with_state stuff \x.
  ...

[axch]

Generalization, from discussion with @dougalm: How about adding general syntactic sugar for de-denting continuation lambdas? To wit, introduce a <- lexeme that's syntactic sugar where

<pat> <- <expr>
<block>

becomes

<expr> \<pat>.
  <block>

Then for the var use-case, one can write

x <- with_state <init>
...

(and if we want more syntactic sugar to make that medicine go down even easier, we can add it).

[dougalm]

I think this would go a long way towards mitigating indentation hell. It's similar in spirit to Haskell's do notation, which turns <e1> >>= \x -> <e2> into do {x <- <e1> ; <e2>}. (It might even be the same thing as do-notation for the special case of the continuation monad...)

We might also want syntax to create a local scoped block, so that the scope of the reference doesn't have to be the entire rest of the function. Perhaps:

x = ...
ans = do
  y <- with_state init_val
  z = f x y
  g z

which would desugar to

x = ...
ans = with_state init_val \y.
  z = f x y
  g z

[EDIT] never mind! I just realized that the former (apart from <-) is already valid Dex syntax without the do. We don't need to add anything extra. (Although we might want to tweak the parser so that you can have a scoped block without having to bind the result to a name.)

[apaszke]

Yeah, I agree that would be nice. I think Koka reserves the with keyword for that.

[axch]

Another case we don't handle yet:

AsList _ $ with_state 0 \listIdx.
  ...

can't be spelled as

AsList _ $
  listIdx <- with_state 0
  ...

because the expression doesn't recognize that it's opening a block. It might be fixable, but it's also not completely clear how important it is, because there is no indentation difference between these two forms anyway.

[axch]

Also, I noticed that

i <- iter
...

is legal Dex now. I hereby suggest that it be bad style to use <- syntax for any continuation lambda that is transparently meant to be called a different number of times than once.[*]

[*] I say "transparently" because one is of course free to implement the list monad using this syntax; I think it's not bad style to write x <- select <options>, because in that monad the notion is that the continuation is "logically" called just once, with the correct value. The fact that the monad is really doing search is sort of an implementation detail. Ditto for various proposed probabilistic programming monads. But I'd rather not see a lot if i <- iter in Dex code.