🚀 go-pugleaf

In article <1ccaamINNgbt@uwm.edu> markh@csd4.csd.uwm.edu (Mark) writes:
> (1) Assignment-Let correspondence.
>                 assignment statement <-> let statement.

In article <1992Oct27.184717.15170@cs.yale.edu> odersky@pigeon.CS.YALE.EDU (Martin Odersky) writes:
>I like the idea of integrating functional and imperative programming, but  
>don't think this particular correspondence holds up under close  
>inspection. For instance, what do you do about procedures? E.g.
>
>  let a = 0
>  let inc cont = let a = a + 1 in cont
>  in inc (inc (inc done))

I don't agree with the premise (using "let inc cont = let a = a + 1 in cont")
for pretty much the same reason I wouldn't agree with the idea of using

let *A = 4 in ...

In that case you had a different notation:

let *A <- 4 in E

which was equivalent to:

                let * = lamnda x.(if (x == A) 4 else *x) in E

which gives the desired results, along with the ability to now fully capture the
distinction between copying and aliasing in the pure lambda calculus, and along
with a theorem (the alpha_1 transformation rule) which states the equivalence
of lambda expressions such as:

                   let *A <- 4 in let *B <- 5 in *A + *B

and

                   let X = 4 in let Y = 5 in X + Y

thus capturing the sense in which "*A is being assigned to".

As you say...

>In any case, something quite un-let-like goes on.

and the culprit is the let statement you sneaked in there.

Apart from that, I don't understand your notation, particularily:

>  in inc (inc (inc done))
                    ^^^^

well enough to answer your question.