My stance is that it is possibly better if we do not try to include a
one-size-fits-it-all record system into the language, but if the
language provided support for basic things that almost all record
system *libraries* would need.
Agreed. To the extent that such libraries could be improved
by sugar, a general solution for such library-specific sugar
might be sought. But the record libraries tended to be quite
useful, modulo (of the top of my head, probably incomplete):
- first-class labels
I wonder whether the recent lifting of values into the
type-level (towards typed types) offers sufficient
convenience? Do they address the sharing issue?
Haven't had the time to read yet;
- soundness
All the type-class based libraries work in the grey area
of things that GHC allows for pragmatic reasons and that
Hugs disallowed for soundness reasons; the success of
GHC shows that Hugs was too careful, but I'd prefer if
GHC either acquired safe features that could replace the
current interplay of FDs and Overlapping Instances, or
if someone proved the set of features in use safe;
- optimization
there is no reason why record libraries need to be slow
to run, and the compilation time increases needed to
make it so might be optimized away, too; but someone
needs to do the work, or record field selection will
-naively and in overloaded style- involve linear lookup;
If these were to be addressed, record libraries would be
more widely acceptable than they are today (though I
recommend playing with the ones that exist, and reporting
on their strengths and weaknesses in practice); initially,
everyone would use their favorite, but I am hopeful that
a common API would emerge eventually, from use.
We haven't had any luck agreeing on a common API
before use, and none of the many good proposals have
managed to sway everyone, which is why I agree on not
settling on a single design just yet - just pave the road
for wider adoption of record libraries).
Back to the side-line for me;-)
Claus
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
