Wojciech,
> - ambiguity with structure equivalence operator
- replacement of == would not be good as it is reserved for
> physical equality
Pointer equality is not coreML (not in SML, nor F#). Easy to fix anyway.
- ambiguity in the parser, e.g. the toplevel let bindings are separated
> by "let", the local lets by pair "let" and "in"
>
I thought about this one... that's the interesting point of forcing a
single name on the left of the '=' sign
f = fun x y -> x + y
you can deduce this meant LET f = fun x y -> x + y and therefore know where
the previous instruction ends because the two constructions are isomorphic.
Say
let g = fun x -> x + 1 in let f = fun x -> let v = g 0 in x + v
becomes
g = fun x -> x + 1 f = fun x -> v = g 0 in x + v
with a unique semantic
g = fun x -> x + 1
f = fun x ->
v = g 0
in x + v
You only need "in" for the return value of the function, all other elements
being separated by an implicit ";"
Notice that "fun" is also useless, the arrow alone shows it is a
function g = x -> x + 1 but that feels a bit extreme.
- ignoring "rec" - no good too - please see the other thread, it
> contradicts how the aliasing of values is now used e.g. for extending
> modules via. include
>
Easy to fix as well.
Diego Olivier
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
