Viewing inferred types

[Bernard James POPE]

I think that the ability to view types of subexpressions in programs would
be very useful. Some work has been done in this direction. One example
I know of is Typeview (www-users.cs.york.ac.uk/~olaf/PUBLICATIONS/typeview.html)
The last time I checked it only worked for a small functional language.

> Focusing on part 1, I see two possible approaches:
>
>  A. Ask an existing Haskell interpreter/compiler to output the
>     information.  I looked briefly at the implementations listed at
>     http://www.haskell.org; none of them seems to produce anything
>     (i.e., any debugging output) from which the necessary information
>     can be extracted.  Therefore, to take this approach, we would need
>     to modify an implementation.  I would be very happy to be
>     corrected on this observation.

I have looked at pulling types out of various compilers. This can be
tricky for a number of reasons.

ghc provides the -ddump-types flag which
will dump type signatures for all top-level bindings in a module. With some
help from the devlopers I was able to get types for local bindings as well
(lets and wheres). Still, with this information you would need to do some
reconstruction of subexpression types within your typeviewer.

nhc98 provides the option -tbound, which shows the symbol table after type
checking. If I remember correctly I had trouble with the renamer of nhc98.
It seemed hard to reconcile source ids with their renamed counterparts.

>  B. Connect a Haskell parser (e.g., hsparser) to a Haskell type
>     checker (e.g., _Typing Haskell in Haskell_).  This is the
>     preferred approach because the solution would not depend on the
>     internals of any Haskell implementation.  However, the output of
>     hsparser is neither typed nor desugared for piping into _Typing
>     hsparser is neither typed nor desugared for piping into _Typing
>     Haskell in Haskell_, so some conversion/desugaring work is
>     required.                                   

I am nearly finished doing precisely this task. Basically I have stuck
hsparser onto the front of thih (with a lot of glue). It only works for
single module programs at the moment, and it runs slowly. The reason I
did this is that I need detailed type information for some other work that
I am doing, and I couldn't easily get what I wanted from the compilers.

It is not currently available for public release, partly because it needs
some polishing, and partly because not all of the code is mine to release
(some of it is Mark Jones'). The intention is to make an alpha release
available soon (next few weeks) with the appropriate permissions granted of 
course.
 
A colleague of mine will be speeding up the code and adding better error
diagnostics, and time permitting, extending the code to multi-modules
(possibly with a hmake style front-end).

If you want more information, or you wish to collaborate on this project
please let me know.

Bernie