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

[Simon Peyton-Jones]

| 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
records.
| > It solves the immediate problem, and no more elaborate scheme seems
| > sufficiently "right" to be declared the winner.    Alas, like all
other
| > proposals, it's not backward compatible, and hence not likely to
fly.
| 
| About a year ago, you were toying with a simple polymorphic system
with
| 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. 

Simon