ml.lex/ml.grm
Matthew Fluet
fluet@CS.Cornell.EDU
Mon, 20 Nov 2000 15:39:22 -0500 (EST)
>
> > I also have the problem that when I do a fresh make nj-mlton in src/mlton,
> > I get errors in the ml.lex and ml.grm produced files (I need to add in
> > some type int = Int.t declaration and change some strings to Char
> > vectors). Do I need to use the mlton version of ml-lex/yacc to produce
> > the right files?
>
> Yes. The MLton version of lex/yacc produces slightly different output than the
> SML/NJ output. The output should work with SML/NJ and MLton. The output
> produced by SML/NJ lex/yacc will not work with MLton because we use 32 bit
> integers everywhere and there are references to toplevel functions (like
> String.size) which use 31 bit ints.
>
> Any ideas for how to report a better error message or avoid this
> confusion would be appreciated.
We could add dependencies in the Makefile that force ml.lex.sml and
ml.grm.sig/ml.grm.sml to be compiled with the MLton versions of mllex and
mlyacc before doing the call to smlnj. Alternatively, I suspect there is
a way in CM to rebind the auxilary programs to process .grm and .lex
files.
Of course, this still leaves a chicken-and-the-egg problem (from the point
of view of a "fresh" compile): you need a MLton to produce mllex and
mlyacc and you need mllex and mlyacc to produce a MLton.
This hadn't been as much of an issue for me previously, because the
/src/mlton/Makefile had the commented out command:
# don't remove the lex and yacc stuff because then MLton tries to remake
#
# rm -f front-end/ml.lex.sml front-end/ml.grm.*
But that's been restored in the latest Makefile.