Re: compilation of lablgl examples.

[Patrick M Doane <patrick@watson.org>]

On Wed, 7 Feb 2001, Pierre Weis wrote:

> [...]
> > I.e., polymorphic variants are more useful for prototyping,
> > since types do not need to be declared before writing
> > algorithms, yet the declarations can still be added later
> > when the design is solider to check just how solid it really is.
> 
> This is an interesting idea, worth a try. I'm still not sure the
> static type checker could handle gracefully the ``partial and
> exhaustive match'' problem, but I may be wrong...
> 
> [...]
> You should try on a small example, not on a huge optimizing compiler
> for a full fledged language!

I tried two experiments that had similar goals to the ones John originally
mentioned.

The first was changing an abstract syntax to use polymorphic variants. For
this particular syntax, different subsets of variant types wanted to be
used through the syntax. This seemed to be a good match for the
polymorphic variants and it really improved the code readability.

I eventually abandoned the approach though as I tried to develop and
prototype with it. Since the abstract syntax was quite large, the
"exhaustive match" errors were also very large. At one point I had to
switch the project back to using regular variants simply to fix a problem
I couldn't track down. Maybe some kind of tree-based difference algorithm
could improve the error messages here? 

The second experiment was with a set of types that were refined over time
in a fashion similar to a compiler. There were particular components that
were similar at every stage, but the associated data evolved throughout
the flow. My first attempt was to introduce polymorphic type variables to
the constructors but this became unwieldy because of cyclic dependencies
among types. I needed about 8 type variables for every type throughout the
module. This really hurt readability and couldn't be reasonably used.

Switching to polymorphic variants worked quite well. Although I quickly
discovered that the expressiveness of this approach is much better for
code that is purely functional. For example, you can't translate a
hashtable containing one variant type to a subset through imperative
update. Since a large body of the transformations I need to express were
imperative, this approach didn't work in practice.

I do think that it is reasonable to try this on a multi-phase compiler and
the approach could provide many benefits. It is probably best to test on a
small toy language first though.

Patrick Doane