search

SMLFamily / Successor-ML

A version of the 1997 SML definition with corrections and some proposed Successor ML features added.
190 stars 10 forks source link

constructors #5

Open RobertHarper opened 8 years ago

RobertHarper commented 8 years ago

Another thing that I am sure has been proposed and maybe implemented is a better treatment of constructors vs variables. I'm all in favor of symbolic-or-capitalized constructors, and lower-case variables. As it stands prefixing almost any program by "datatype x = x" will wreak havoc.

A related point is that it's kind of silly to lexically distinguish type variables, which need no lexical distinction, and not lexically distinguish constructors, which do. I'd love it if we could just use a, b, c etc as type variables, and not always have to write the stupid tick mark.

DemiMarie commented 7 years ago

If Unicode characters become allowed in identifiers, then this raises a problem: Not every Unicode character has upper- and lower-case forms.

JohnReppy commented 7 years ago

The ticks on type variables don't bother me, but I agree about constructor identifiers.

The issue of what is a upper-case letter is already an issue with symbolic identifiers, but we can presumably follow the convention of defining ":" as being "upper case".

Allowing Unicode identifiers introduces a lot of other design challenges (e.g., should identifiers be normalized when considering if two Unicode identifiers are the same?)