bug report for MLton

[Stephen Weeks]

> Oops!  You can tell I don't know my SML'97 :-(
> Sorry about the false alarm.

No problem.  Since MLton doesn't have a real front end, it's tough to know
what's going on.  I'd recommend trying out the Kit as the closest thing to SML
97 with reasonable error messages.

> I have the revised Definition at the office, but I'm at home this week
> (it's spring break).  If you know of a place to get a grammar of
> SML'97 online, please let me know.

The only thing I know of is Larry Paulson's grammar for SML' 90, available at
	http://www.csci.csusb.edu/dick/samples/ml.syntax.html

You could always look at the ml.grm file that comes with MLton:
	src/mlton/front-end/ml.grm

> I spent an hour today failing to fix
> 
>             structure EncodingInterface : ENCODING_GENERATOR
>                 where Code.Constructor = ULinked.Constructor (* NOT SML'97 *)
> 
> It just doesn't look possible without good tool support.

Maybe this can be done with a structure sharing constraint instead of a where?
I've been pretty successful using an approach like that in MLton.

> I'm trying to port some of my SML/NJ code to compile with MLton
> as a kind of experiment.  I've already found a bug in MLton, but

What bug did you find in MLton?

Matthias Blume writes:

> Perhaps it would be easier (and more useful in the long run) to ask Steve Weeks
> to add "where" for structures to  MLton.  After all, everybody agrees that its
> omission from SML'97 is a mere oversight.  Or you just don't switch (see above).

We don't plan to to add this construct (or any of the other tens of SML/NJ
deviations) to MLton until it becomes part of the standard.

> More seriously, I am not aware of any "rewrite this SML/NJism to true SML"
> feature in the compiler.  There are a bunch of other extensions that would
> have the same problem.  And more are probably to come.

As you can imagine, our view is that the SML/NJ approach of ignoring the
standard is good for SML/NJ (for exactly the reasons Matthias mentions), but bad
for SML.  In particular, it often makes porting code unreasonably difficult.