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

[Matthew Fluet]

> > 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.
>
> I feel the same.  About the only other prefix that looks reasonable to
> me is "_.", or maybe even "_".  But I think "?." is better.

I don't care for either "_." or "_".  I'm happy enough with "?."; I
wouldn't mind "#." or "$.", but it's not a strong preference.

> > 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.
>
> Are you referring to the isChar in PRIM_TYCONS
>
>       val layoutApp:
> 	 tycon * (Layout.t * {isChar: bool, needsParen: bool}) vector
> 	 -> Layout.t * {isChar: bool, needsParen: bool}
>
> If so, I don't see how we can get rid of it.  It is used to layout
> "char vector" as "string".  When laying out the vector type, there
> isn't enough information in the Layout.t argument to know whether we
> have a char vector or some other vector.

I understand that, but what I was wondering was whether or not this
layoutApp was really responsible for printing types that the user would
see.  For example, if I have:

structure S :> sig type t
                   val x : t
                   val f : t * int -> bool
               end =
struct
   type t = int
   val x = 0
   fun f (x, y) = x < y
end

val b = S.f (1, 2)

Then the error I get is:
Error: z.sml 12.9: function applied to incorrect argument
   expects: [S.t] * _
   but got: [int] * _
   in: S.f (1, 2)

So, with the program:

val b = String.<(1,1)

I'm guessing that the error
Error: z.sml 2.9: function applied to incorrect argument
   expects: [string] * [string]
   but got: [int] * [int]
   in: String.< (1, 2)

is picking up the "string" from the STRING and BASIS signatures, where it
appears as an explicit type name.


Anyways, it's not a big deal.  I just figured that by the time we reached
the user's program, all the primitive types had been hidden away behind
signatures, so maybe the primitive tycon layout functions weren't being
used to print type errors.  Now, there is still the problem of dealing
with constants, so maybe it is being invoked.