Ben Franksen wrote: > Barney Hilken wrote: >>> From: Ben Franksen <[EMAIL PROTECTED]> >>> Date: 18 February 2008 21:32:29 GMT >>> To: haskell@haskell.org >>> Could you be more specific? Which proposals exactly do you mean and >>> where >>> can I read more about them? >> >> Hlist is one of the ones | was thinking of. Two more are "poor man's >> records" a.k.a. Data.Record.hs, whose author certainly believes it >> should be the basis for the new system, and my own system, >> downloadable from http://homepage.ntlworld.com/b.hilken/files/Records.hs >> >> There is a discussion of the various possibilities on the wiki >> http://hackage.haskell.org/trac/ghc/wiki/ExtensibleRecords >> which you are encouraged to contribute to! > > Thanks, exactly the kind of pointer I had hoped for! I'll read up on the > existing proposals.
My proposal how to proceed is to /eliminate/ candidates by the following criteria: (a) efficient field access (b) requires no or only minimal /additional/ extensions to compiler or language (c) light-weight syntax and semantics, at least for the simple non-polymorphic cases My rationale for these criteria goes like this: efficient access is necessary if we want to compete with the much simpler record systems in mainstream languages. If records are not as light-weight (syntactically as well as wrt run-time performance) as 'normal' Haskell data types, then people will be reluctant to use them, especially in library APIs. Finally, having to wait for highly experimental additional extensions to be available, tried, and tested, would only help to indefinitely post-pone the introduction of a usable record system. Now, these three criteria together immediately eliminate all the 'mostly library' proposals, including HeterogeneousCollections, Data.Record.hs, and TypeFamilies, since in all of them records are represented as nested pairs (more or less) and efficient field access relies on not yet available compiler optimizations i.e. 'partial evaluation of type class programs'. They also directly depend on advanced type system extensions that are either only partially implemented yet (type families, type sharing), or controversial (fundeps). Criterion (c) also eliminates proposals in which labels must be pre-declared; it is not completely clear to me which of the 'mostly library' proposals require how much compiler support to completely automate this. TREX seems to be generally agreed to be too complicated to implement and explain. What remains are Daan's ScopedLabels approach and SPJ's proposal which I mentioned earlier. Both are simple to explain, support light-weight syntax, and require only minimal or no additional (type system or other) extensions beyond what the proposal itself specifies. These are IMO the only really practical proposals. It is, however, unclear to me whether the ScopedLabels proposal can be implemented effciently (AFAIR, the issue is only briefly mentioned at the end of the paper). Just my 2 cents. Cheers Ben _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
