Changes between Version 24 and Version 25 of ExtensibleRecords


Ignore:
Timestamp:
Nov 25, 2007 3:15:53 PM (6 years ago)
Author:
barney
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ExtensibleRecords

    v24 v25  
    4141 .:: The problem with unpermuted records is illustrated in the example at the bottom of this page: it forces you to make functions polymorphic when they "ought" to be monomorphic. This means that no-one can use records in a straightforward way without understanding the details of all the predicates. ''(predicates are parts of types, in particular, they restrict polymorphism. as the example shows, you can still be monomorphic if you absolutely want to, but understanding types, including predicates, is essential for understanding how to use haskell operations)'' 
    4242 .:: In both cases, the usual approach (permutation, no repeats) is what most programmers expect. We have to remember that this proposal is supposed to be ''the'' records system for Haskell. It must be the right system for simple problems as well as complex ones. ''(if you are really still stuck at the "one system fits everyone" stage, i would find it difficult to continue any discussion)'' 
     43 
     44I think both points of view are quite clear. I also think it is not up to us alone to decide what goes into Haskell. I must say, I find your last comment extraordinary! If we are going to have lots of systems, why bother to argue about which is best? The reason Haskell has no decent records system at the moment is because there are too many good proposals, not that there are none. When writing this page, I was trying to make clear the various design decisions that must be made in choosing a system. Obviously, different people would make different decisions, but at some point, the Haskell committee must make a decision about what to include in the standard. 
     45 
    4346 
    4447= Label Namespace =