From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA11572 for caml-red; Thu, 8 Feb 2001 19:54:50 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id GAA17993 for ; Thu, 8 Feb 2001 06:55:51 +0100 (MET) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f185toH23450; Thu, 8 Feb 2001 06:55:50 +0100 (MET) Received: from localhost (patrick@localhost) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f185thI24608; Thu, 8 Feb 2001 00:55:43 -0500 (EST) (envelope-from patrick@watson.org) Date: Thu, 8 Feb 2001 00:55:42 -0500 (EST) From: Patrick M Doane To: Pierre Weis cc: John Max Skaller , caml-list@inria.fr Subject: Re: compilation of lablgl examples. In-Reply-To: <200102072202.XAA05588@pauillac.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: weis@pauillac.inria.fr 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