[Haskell] Per-type function namespaces (was: Data.Set whishes)

Simon Peyton-Jones simonpj at microsoft.com
Fri Mar 5 09:17:47 EST 2004

| From: Ross Paterson [mailto:ross at soi.city.ac.uk]
| On Thu, Mar 04, 2004 at 09:21:23AM -0000, Simon Peyton-Jones wrote:
| > My personal view is this: we should have adopted the ML view of
| > It solves the immediate problem, and no more elaborate scheme seems
| > sufficiently "right" to be declared the winner.    Alas, like all
| > proposals, it's not backward compatible, and hence not likely to
| About a year ago, you were toying with a simple polymorphic system
| just "has" predicates.  If these were automatically derived, it seems
| you'd get something quite close to backward compatible, except for the
| pesky extra lifting in record types, and not being able to omit fields
| when constructing the record.  (And update might not statically check
| that all fields belong to the same constructor, for the simple version
| of the type system.)  Is that just too clunky?

It's possible, but I don't know.  Speaking for myself, I've rather lost
motivation on the records front, because the design space does not seem
to have a clear optimum point.  Adding has predicates in full glory
seems overkill to get re-use of labels.  Ah, but they also give you
polymorphic record operations!  Yes, but so do other versions, with
different and rather subtle technical tradeoffs.  That's why I've backed
up to something extremely simple: either (a) disambiguate record labels
by qualifying with the type constructor or (b) go the ML route. 

None of this is to discourage people from experimenting with variants --
quite the reverse.  That's how we may find out what a good system is. 


More information about the Haskell mailing list