bug report for MLton
Thu, 29 Mar 2001 16:58:47 -0800 (PST)
> 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
You could always look at the ml.grm file that comes with MLton:
> 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.