I would not allow top level let's at all. In terms of parsing, let is an
expression (it has a non-monadic type). Top level declarations have a
monadic type (or can't be part of an expression). Something like for a
minimal definition of an expression:
var = alpha, {alnum}
abs = '\', var, '.', expr
let = 'let', var, '=', expr
expr = var | abs | let
decl = var, '=', expr
program = decl, {decl}
Keean.
On 3 May 2015 05:52, "Matt Rice" <ratm...@gmail.com> wrote:
> On Fri, May 1, 2015 at 11:10 AM, Jonathan S. Shapiro <s...@eros-os.org>
> wrote:
> > The habit in functional languages has been to use something like "let" as
> > the top-level binding form. This grants economy of mechanism, but it
> leads
> > to a design inconsistency.
> >
> > On the one hand, the bindings in a LET should go out of scope when the
> let
> > does. If so, it should follow that in the following code:
> >
> > let x = 5
> > in
> > ...
> >
> > let x = 3
> > in
> > ...
> >
> >
> > x is not rebound because it has gone out of scope. Most functional
> languages
> > nonetheless diagnose this as a rebinding.
> >
> > Does anybody else find this distasteful and confusing?
>
> I don't think i gave an opinion in my last email,
> don't really have an F# compiler, but it seems to me that it allows a form
> of
>
> let x = 5
> in ...
> let y = x
> in ...
>
> I find this particularly nefarious, I could imagine that if this was
> usable as some of parallel declarations to a resulting environment
>
> e.g. to avoid the sequential nature of the let forms that allow multiple eq
> as in sml's
>
> let val foo = 0;
> val bar = foo;
> in ... end
>
>
> the example here: http://fsharpforfunandprofit.com/posts/let-use-do/
>
> let alice = {First="Alice"; Last="Doe"}
> let {First=first} = alice
>
> seems to confirm that, and adding the parallel construction it still
> suffers from the rebinding problem... seems to have far more in common
> with set! than let...
> _______________________________________________
> bitc-dev mailing list
> bitc-dev@coyotos.org
> http://www.coyotos.org/mailman/listinfo/bitc-dev
>
_______________________________________________
bitc-dev mailing list
bitc-dev@coyotos.org
http://www.coyotos.org/mailman/listinfo/bitc-dev
