[MLton] cvs commit: major improvements to -show-basis

[Matthew Fluet]

> > Abstract types in signatures are displayed as type equalities:
> >
> >   signature ARRAY2 =
> >      sig
> >         type 'a array = 'a array
> >         ...
> >      end
> >
> > I'm confused by the "= 'a array"; it seems to suggest a type equality with
> > the top-level array, but that is clearly incorrect.
>
> Yeah.  It is supposed to indicate that type name array denotes the
> flexible tycon (local to this signature) called array.  The problem
> that I had was how to uniquely identify tycons when displaying
> signatures.

I understand the problem now.  One reason this specifically jumped out at
me was that under a previous incarnation of -show-basis, we could get
stuff like:

structure Int : sig
                   type int = Int.int
                   ...
                end

which I thought may have been leaking some information about the fact that
we rebind Int when exporting the final basis.  (i.e., that the "inner"
Int.int was referring to the previous (now shadowed) Int structure.)

> I decided it was too hard to try to generate valid sigexps.

Absolutely.

> The best fix that I can think of is to choose some prefix that
> distinguishes all the flexible tycons in the signature.  Offhand, the
> best prefix I can think of is "?." (intuitively, we don't know what
> structure binds the tycon).  That would make the above signature
> display as
>
> signature S =
>    sig
>       type t = ?.t
>       structure U:
>          sig
>             type t = ?.U.t
>             val x: ?.t
>             val y: ?.U.t
>          end
>    end
>
> This at least makes it clear when a tycon in a signature is flexible
> or not, and I think makes things completely unambiguous.

That's better.  At least then I can think of "?" as "this".  I was going
to suggest replacing "?" with "<this>", but that's a little notationally
heavy.  One argument for it is that the SML/NJ pretty-printer has got me
hooked on thinking that "?" means a shadowed/out-of-scope structure.


BTW, I was wondering if the new front-end can keep tycons straight enough
that we don't need the {isChar: bool} flag for pretty-printing primitive
tycons.  That is, if we opaquely match Char early enough, will everything
for a user's program necessarily talk about char and not word8.