I was pleasantly surprised when I saw that SML/NJ recently made some major changes in version 110.79 which is part of a move towards something called Successor ML. This seems to be a cooperative venture between SML/NJ and MLton and bodes well for the future of SML.
However, I seem to encounter a weird bug (on 64-bit Windows 7) when I try to use some of the new features. To try it out, I wrote the following in a file called sml_successor_test.sml
:
Control.succML := true;
val n = 123_456;
print (Int.toString n);
when I try to load it into the REPL using use "C:\Programs\sml_successor_test.sml";
the compiler balks at the second line in the file (which uses a new type of number literal which should be enabled). But -- when I immediately run the exact same use
command as before -- it works.
If first use Control.succML := true;
in the REPL and then use use
to load the file (after removing that line from the file) it does work. On the other hand, if I just fire up SML, enable succML
, and then have the assignment val n = 123_456;
directly in the REPL, it fails the first time but then works.
To sum up -- there seems to be a weird lag between when Control.succML := true
is evaluated and when it takes effect, a lag which happens in some contexts but not others. Any idea what is behind this and any workaround?
This happens to me on Mac OS X as well. What I did, though, was to use the -Cparser.succ-ml=true
flag in my sml
alias, which behaves as expected:
alias sml="rlwrap /usr/local/bin/sml -Cparser.succ-ml=true"
I forget now what's the Windows equivalent. You may have to create your own sml wrapper script and place it before the SML/NJ one in PATH
.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With