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.