Simon thanks for the questions. I'll try to clarify. [1]
... For example, what does it mean to "remove the need to declare labels, make them identifiable as such in use"?
implicit label declarations, basically. the code for records I posted depends on any two field labels being distinguishable by type. to get readable records, we want something like typed constants, e.g.: data LabelX = LabelX deriving (..) but all these declarations will be the same, apart from the label name, so if we had syntactic means to see that something is a label, and the only inhabitant of its type, there'd be no need for these declarations. for the sake of discussion, let us assume that we reserve a '#' prefix before identifiers and types to single them out as label-related. then we'd know (without explicit declaration) that #labelX :: #LabelX why would that be interesting? that brings us to your second issue: [2]
Then, the code that you enclosed appeared to show that you could do without any extension at all.
the code establishes a context for the proposal, nothing more. the code demonstrates that there are record system variants that we can implement without any new language extensions. but it could not be used in practical, multi-module situations, because of the need to declare those label types. if we have two modules, A and B (think ...OpenGL and some GUI library), that both want to use records with fields named 'pointX', they'd both have to declare the field label as data PointX = PointX deriving (..) now, if we ever want to import A and B into the same module C (think OpenGL windows in a GUI), we are in trouble, because we have two "conflicting" declarations for PointX. at the moment, that means that we have two ways out - either use qualified names in C: A.PointX and B.PointX; this is awkward, to say the least, and still doesn't let us identify what should be two instances of the same field name, forcing upon us superfluous conversions - or modify the imports: introduce a new module PointX that declares PointX, and have both A and B import that; this is impractical: it breaks module composition, and there is no least upper bound in the import hierarchy where we can safely place our label declarations once and for all which brings us to your final suggestion: [3]
Records are a huge swamp with a very large number of possible variants and design choices. Perhaps you might gain more traction if you were ruthlessly specific about what language changes you advocate, and what benefits they would have (versus the existing situation).
I was trying to single out a minimal extension that might help to steer around that swamp (which seems to be the undeclared intention for Haskell'?), while still providing the means for making progress wrt a better record system for Haskell'. I was explicitly _not_ suggesting to build any new record system variant into the language. the code shows by example what is possible without new extensions while also highlighting issues that are not easily addressed without new extensions (and making old extensions official parts of the language). the concrete proposal is to address one of these remaining issues, namely how to identify record field labels as such. for that, I outlined three options, although that outline perhaps wasn't concrete enough: 1. make label declarations unneccessary (eg., #pointX :: #PointX) 2. make type sharing expressible (something like the sharing constraints in Standard ML's module language, to allow you to say when two declarations from different imports refer to the same type) 3. introduce a least upper bound for shared label imports (so A and B could just 'import Data.Label(pointX)', which would magically provide the shared declaration for pointX) does that clear things up a bit? if anyone still has questions, please ask!-) cheers, claus original message: http://www.haskell.org//pipermail/haskell-prime/2006-February/000463.html