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