[TYPES] Typing extensible records without row variables?

[Brian Hulley]

Matthias Blume wrote:
> 
> On Aug 25, 2008, at 8:55 PM, Brian Hulley wrote:
> 
>> 3) While it is obviously useful to have extensible records it is not at
>> all clear to me whether or not extensible variants are similarly useful
>> since there are other ways of achieving extensiblility in functional
>> programming e.g. by adding new combinators to a combinator library and
>> keeping the underlying representation variant completely hidden.
> 
> In our ICFP'06 paper[*] we suggest that extensible variants (actually: 
> extensible cases) might be a useful programming concept that integrates
>  gracefully into an ML- (or Haskell-) like language after all.

Thanks - I found the above useful especially for the way extensible 
variants are given meaning at the term level by splitting the usual case 
construct into match + cases and making the cases part the first class 
dual of extensible records. Also of special interest is the fact that 
the "lacks" predicates of various other papers I'd read are directly 
incorporated into the kind of the row variable so that everything is 
dealt with in the same place instead of being represented by a special 
kind *and* a special predicate, and of course the details of how all 
this is implemented efficiently, and some other points too.

In terms of integration, if these variants are to replace the normal 
non-extensible datatype variants of ML/Haskell, there is still (afaics) 
the issue of syntactic convenience vs theoretical completeness of the 
duality due to the fact that the extensible variant constructors must 
each take exactly one argument yet the programmer would probably prefer 
to avoid having to supply "redundant" units, and on the other hand, if 
one were to also keep the normal datatypes then there would be two sorts 
of variant in the language. (Of course perhaps this is just a minor 
inconvenience compared with the advantages of extensible cases.)

> 
> ou might also be interested in having a look at our upcoming APLAS 
> paper[**], where we point out that the same idea not only 
> straightforwardly extends to the typing of exceptions (a fact that has
> been exploited several times in previous work on exception analysis by
> other authors), but also can be taken as a starting point
> for a language design that (a) rules out any uncaught exceptions, and 
> (b) integrates well with the notion of extensible records and cases.
> 
> Matthias
> 
> [*] Extensible Programming with First-Class Cases.
>     Matthias Blume, Umut A. Acar and Wonseok Chae.
>     In Proceedings of the 11th ACM SIGPLAN International Conference on 
> Functional Programming (ICFP'06).
>     Portland, Oregon. Sep 18-20, 2006.
> 
> [**] Exception Handlers as Extensible Cases.
>      Matthias Blume, Umut A. Acar, and Wonseok Chae.
>      To appear in Proceedings of the Sixth ASIAN Symposium on 
> Programming Languages and Systems (APLAS 2008).
>      Bangalore, India, Dec 9-11, 2008.
>      An expanded version is available as University of Chicago CS 
> Technical Report TR-2008-03.
> 

Thanks also for the second reference,

Brian.