But the way let is used at the top level does not make sense. Consider let x = 3 in x let y = 4 in y
What is the value if this program? It is invalid as the expression 3 4 Is an error. The following would make sense: let x = 3 in x + let y = 4 in y and it would evaluate to 7. An expression is something that evaluates to a value, and due to referential transparency, that value should always be the same for the same inputs (ML ignores this bit). So a valid program could be a single let at the top level (if a program is an expression that evaluates to an expression). Otherwise the top level is a set of declarations, not an expression, and should not be evaluated. Keean. On Sun, May 3, 2015 at 12:29 AM, Keean Schupke <[email protected]> wrote: > 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} indeed, fwiw there there is a copy of ML's BNF here: http://www.cse.buffalo.edu/~regan/cse305/MLBNF.pdf F# seems to consider it a keyword. i'm rather rusty on parsing in general, so this is more likely to be completely broken, not to mention incomplete, hopefully it explains what I was thinking... ... decls = DECL | DECL';' DECL block = let DECLS blocks = BLOCK | BLOCK '&' BLOCK expr = BLOCKS in EXPR end | ... so let is still only usable in an expression _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
