[MLton] Re: [MLton-commit] r6295

[Vesa Karvonen]

On Jan 3, 2008 3:16 AM, Matthew Fluet <fluet at tti-c.org> wrote:
> On Wed, 2 Jan 2008, Vesa Karvonen wrote:
> > Reverted a change made in revision 6046.
> >
> > Tycon.newString and Tycon.fromString have the same effect except that
> > Tycon.newString leaves the printName of the tycon unset while
> > Tycon.fromString sets the given string as the printName for type tycon.
> >
> > In revision 6046, the code was changed to use Tycon.newString.  An effect
> > of that change was that the names of many (more?) tycons in compiler
> > output (e.g. output produced by show-basis) included a generated suffix.
> > Although such names are more precise in some sense, the generated suffices
> > make the tycon names less readable to a programmer.
>
> ... but more readable to (and precise for) a developer trying to debug the
> output of elaboration.

Right.  I assumed that was the case.  Perhaps I was too hasty in
reverting the change...

> I've no objection to reverting the change, but that was the reason for it.

...and there should rather be an expert switch to choose between the
two kinds of names.  Maybe something like

  -print-unique-tycon-names {false|true}

Or it could implied by some other switch.

At any rate, I believe that for a number of features, namely
-show-basis and -show-def-use, the non-suffixed names are better by
default, because they are shorter and what the programmer would expect
(or at least what I would expect as a programmer).

I was also going to make a number of other changes to make the types
in output more readable to a programmer.  I plan to change
setTyconNames (in ElaborateEnv) to not add the "?." prefix in case it
is called at a top-level scope, which is the case for show-basis and
(will be for) show-def-use.  I've already implemented that, but it is
pending my review to determine whether it has undesirable consequences
 (i.e. whether it makes the output (more) ambiguous).  I also plan to
change the pretty printing of functors so that the functor formal
parameter name in the output matches the name in the (where type)
constraints for the formal parameter signature.  This means either
storing the functor formal parameter name in the functor closure
(which is what I've currently implemented) or using some generated
name for the functor argument.  I'm unsure of which would be the
better alternative.  I would also like to avoid the "'?." prefix in
constraints in signatures (in -show-basis output).  I already
experimented with using the signature name instead of "?" (although it
isn't valid SML, of course).  I'm not sure whether that is the best
alternative.  Similarly, I think that it could be a good idea to
prefix/nest type names for functor arguments with the functor name and
have written experimental code to do that.  The point with adding the
functor name as a prefix is to make the type names make global sense.
This would be mainly to make types in def-use output to be
understandable regardless of where (whether inside or outside the
functor) one is looking at the type.

Suggestions are welcome!

-Vesa Karvonen