[MLton] Showing types of variables

[Vesa Karvonen]

On Nov 1, 2007 10:27 PM, Matthew Fluet <fluet at tti-c.org> wrote:
> On Sat, 13 Oct 2007, Vesa Karvonen wrote:
[...]
> > - I couldn't figure out a way to just find the types of variables, so
> > I modified the code to actually save the type in the newUses function
> > as a part of the defUses field. [...]
>
> I can't see an easy way of finding it either.  It looks like the type
> scheme of variables should be in the current field of the NameSpace.t
> type (and possibly accessible via the lookup field of the NameSpace.t
> type), but there are various imperative manipulations of the current
> environment that may mean that that information isn't all there at the
> time we want to emit def-use information.

Yes, I initially wrote code to lookup the types, but it didn't find
them --- except for some top-level symbols.  Browsing the code a bit
more I noticed that the current scope was being mutated, which
probably made the types inaccessible.

> Your method seems fine.

Ok.  I guess we'll go with it and possibly refine it later.

> > - Saving the types (and formatting them (layout)) seems to take
> > considerable space (and time). [...]
>
> I didn't notice the space/time overhead.  (But, then, I'm fairly
> forgiving.)

Well, I have a laptop with (only) 1GB of RAM (of which 128MB is
currently taken by the graphics driver) and while working to get MLton
to save the types it happened several times (I tried a few variations)
that a build of MLton started to swap (taking forever to build).  So,
the current code only saves the types of variables, which means that
MLton builds without swapping on my laptop.  However, elaboration
(when compiling MLton) now takes significantly longer and it seems
that most of the time is spent in GC.  I've been planning to get a new
machine in a few months, so the problem (for me) probably goes away.

> > - The type names aren't perhaps the best possible names one could get.
> > They have an extra ?. prefix and sometimes a _N suffix. [...]

I also noticed (later) that in some case a variables may get a wrong
type (I guess) due to the merging of def-uses performed in
elaborate-env.  For example, sometimes the type of an int[32] variable
might be shown as int16.  This seems to happen when the definition is
in a functor that is instantiated with multiple types.  One option
might be to avoid merging two def-uses when they have different types.
 This might lead to some other problems (what to do at a def site?).
Another option might be to save (and show) all the types (a list of
types instead of an option).

> Ideally, the type displayed at the definition of a variable would be the
> string representation of the type that would have been used were a type
> error reported at the point of the definition.  [...]
> On the other hand, the displayed types seem no worse than what we get from
> the -show-basis <file> mechanism. [...]

Yes, I agree.

> Actually, now that I think about it, we could get the nicer names if we
> did the "Scheme.layoutPretty" at the point where we invoke "newUses",
> rather than doing it after the end of elaboration.  But, this will almost
> certainly eat up a lot of space, because the layout form of a type is much
> larger than its internal representation. [...]
> Alternatively, if one were to completely rework the elaborator, we could
> use a persistent data structure for the environment.  [...]

Hmm... Is it really possible to call Scheme.layoutPretty at newUses?
I mean, have the types been completely inferred at that point?
Looking through the code, it would seem to me that it wouldn't be the
case.  Perhaps the layout could be performed at some "safe" points
like just before leaving certain kinds of scopes when the newly
introduced types are known to be (in most cases) fully inferred.

At any rate, these are worth considering.  Perhaps with a clever
coding of the layout result, it might be possible to share much of
their representations and save space.  Perhaps there could be an
option to get higher quality type names.  One could use the option
when compiling smaller programs or when there is plenty of memory.  I
could look at this if/when I get a machine with more memory.

> Anyways, if I'm going to dream, it would be really cool to have the type
> displayed at the use of a variable to correspond to the (instantiated)
> type at that use site. [...]

Yes, I agree.  This would probably also take a lot more space, but it
is certainly worth considering at some point.

> In any case, given that the def-type and the use-type of variables can
> differ (not only that the use-type is an instantiation, but also that the
> types in scope at the two points don't always agree), I wonder if it
> wouldn't be better to only show the type of a variable at its def-site.
> I still think that would be useful, since one often is interested in the
> type of some unannoted local variable, and the def point probably isn't
> far from the use point.

I see what you mean, but I think that it would probably just be an
unnecessary hurdle for the user to have to jump to the definition (or
explicitly invoke a command) to see the type.  I'll introduce a
customization variable for this.  It also wouldn't be difficult to
change the def-use mode to support having messages (types) attached to
both definitions and uses and have it show one or both of them when
looking at a use point.

> One final, very minor, comment about the def-use.el mode.  I note that
> when hovering over a variable, with the type displayed, the displayed type
> will overwrite any other Emacs messages being sent to the mini-buffer. [...]

Yes, I also noticed this (and a another bug) and fixed it in my local
copy shortly after sending the patch.  Currently the message is
displayed just once while the cursor is on the same symbol and there
is a command (bound by default to C-c C-t) to show the message.

I'll commit my changes to the def-use mode shortly (the support to
show types).  I'll defer committing the changes to MLton for a few
days as I plan to try a couple of alternatives.  In the meanwhile,
attached is a patch to MLton that works with the changes I'll commit
to def-use mode.  It differs from the old patch in that the type is
saved as the last entry on a def line, which, I believe, is slightly
more backwards compatible (e.g. an awk script parsing def-use files
would likely still work) and probably makes sense otherwise (optional
field(s) last).

-Vesa Karvonen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: du-with-types.patch
Type: text/x-diff
Size: 5891 bytes
Desc: not available
Url : http://mlton.org/pipermail/mlton/attachments/20071102/8de83cd9/du-with-types.bin