This sort of disagreement means that nothing gets done. After my
experience with the wiki page, I don't believe anything will get done
until one of the core ghc developers makes some arbitrary decisions
and implements whatever they want to, which will then eventually
become part of the standard by default.


This is the sort of situation where a "benign dictator" is needed. I have no 
strong feelings about which of all of these (all very good) proposals get 
implemented, but I do have a strong opinion that the lack of "proper" records 
is hurting Haskell quite a bit.

Any of them will do, just get it in there! I'm assuming that Simon {PJ,M} et 
al. won't make an obviously terrible choice, and GHC seems to be the de facto 
standard anyway, so if they just implemented something in GHC that would be 
good enough for me, and a shoe-in for a future standard.

Since you are taking my name in vain, I had better respond!  I wish I felt as 
confident of my good taste as you do. My last attempt to implement records 
(with Umut Acar, more or less the design in the "proposal for records" paper) 
involved rather significant changes to the type checker, and I was reluctant to 
commit to them without stronger evidence that it was a good design.

I'm not so despondent about the Wiki page. It's already a good start.  Don't 
give up too soon!

You say that "lack of proper records is hurting Haskell".   I think it'd help 
to give much more structure to that statement.  "proper records" means 
different things to different people.   After all Haskell already has somethng 
you can call "records" but they obviously aren't "proper" for you.

So it might be interesting to do several things.

1.  List the interested parties.  The Wiki page doesn't say who's interested in 
this so it's hard to judge whether the "hurting" is a widely held opinion or 
not.

2. List the possible features that "records" might mean.  For example:

*         Anonymous records as a type.  So {x::Int, y::Bool} is a type.  (In 
Haskell as it stands, records are always associated with a named data type.

*         Polymorphic field access.  r.x accesses a field in any record with 
field x, not just one record type.

*         Polymorphic extension

*         Record concatenation

*         Are labels first-class?

*         etc
Give examples of why each is useful.   Simply writing down these features in a 
clear way would be a useful exercise.  Probably some are "must have" for some 
people, but others might be optional.

3.  Cross-tabulate, for each of the current proposals, say which features they 
have.

4. Reflect on how invasive each proposal would be, given the existence of type 
functions.


Simon
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Reply via email to