Re: Nitpicky definition compatibility bug, SML/NJ deviation

On Fri, Aug 26, 2011 at 2:33 AM, Robert J. Simmons <[email protected]> wrote:
> MLton accepts the following program:
>
> structure @#$ = struct val foo = 4 end
> val y = @#$.foo
> val () = print "Goodbye.\n"
>
> However, according to Page 5 of the revised definition, "The
> identifier class StrId is represented by alphanumeric identifiers not
> starting with a prime," which would seem to exclude symbolic
> identifiers from being the names of structures and signatures.

Agreed.

> I swear I don't go around looking for these things, I was using the
> definition to try to write a syntax highlighter for Standard ML on
> GitHub.

You might be interested in the Pygments lexer I wrote for SML:
  http://mlton.org/Pygments
And the "lexical curiosities" that I discovered while writing it:
  http://mlton.org/pipermail/mlton/2011-May/030931.html

My Pygments lexer flags a lexical error in the above fragment, but
only at the "val y = @#$.foo", since it disallows a symbolic id as a
leading part of a long identifier.

> In the process of generating
> https://bitbucket.org/robsimmons/pygments-main/src/351f8bf6f859/tests/examplefiles/example.sml,
> I came up with another SML/NJ vs. MLton deviation. SML/NJ does not
> treat the single prime -'- as a type variable, nor -'0- and -'_-.
> Similarly, SML/NJ does not treat -'''- or -'''''''- as eqtype
> variables.

Yeah, I discovered those as well.  They are, admittedly, fairly awful
as actual tyvar identifiers in real code.

-Matthew