On Wednesday 24 October 2001 12:32, Simon Peyton-Jones wrote:
The elimination of "stupid" existential wrapper constructors is discussed in a bit more detail in the paper Mark and I wrote recently:
First class modules for Haskell http://research.microsoft.com/~simonpj/papers/first-class-modules/index.htm
I really like the thrust of the argument. I definitely agree with the direction of the paper. Your paper mentioned the binder rule, which requires an explict type for modules that appear as arguments of functions. I understand the need for this rule, and it is itself a reasonable restriction. The problem is that in combination with a lack of subtyping between records, this implies that one must specify every field that can and must appear in a module. I'm trying to decide if this is a reasonable restriction. From my experiences with other systems such as Modula-3, my instincts say no. Say you are implementing modules for Ints and Floats. My old habits would lead to the following signatures: record Int a = (+), (*) :: a -> a -> a div, mod :: a -> a -> a record Float a = (+),(*):: a -> a -> a (/) :: a -> a -> a sin, cos :: a -> a Then, by my understanding, one could not write a function that mentions only (+) and (*) that is polymorphic in these modules. You couldn't pass it both Int a and Float a, because the signatures are different, which seems to be an artificial restriction. I think extending the system with some form of subtyping between records would be important for a usable system. Your paper suggested that you are planning to do this. Any thoughts on current ideas in this direction? On the other hand, one could split each module up into several different pieces, such as "Ring a", and "Trig a". This might be very reasonable, but it strikes me as being a little too fine-grained. best, leon