|
<td>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; my premises in this round have been that (1) we should try to implement as many useful record operations, predicates, and invariants as we can, (2) we should try to unify the sets of operations into a coherent whole, (3) we should identify to what extent and in what form we need to have language and implementation support, and (4) users, not library providers, will decide which subsets of operations they use most; assuming that one particular view of records is "the usual one", or "what most programmers expect" has not helped in the past, and will not help now; just making yet-another-record-proposal is no more likely to succeed than any of the previous attempts, whereas a library providing for as many common usage patterns as possible might have a chance of breaking the deadlock, and laying the groundwork for a future design that might actually have some users and experience behind it; to be successful, such a design would evolve in use, rather than be proclaimed and ignored)*</td></tr></table>
|
|
<td>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; my premises in this round have been that (1) we should try to implement as many useful record operations, predicates, and invariants as we can, (2) we should try to unify the sets of operations into a coherent whole, (3) we should identify to what extent and in what form we need to have language and implementation support, and (4) users, not library providers, will decide which subsets of operations they use most; assuming that one particular view of records is "the usual one", or "what most programmers expect" has not helped in the past, and will not help now; just making yet-another-record-proposal is no more likely to succeed than any of the previous attempts, whereas a library providing for as many common usage patterns as possible might have a chance of breaking the deadlock, and laying the groundwork for a future design that might actually have some users and experience behind it; to be successful, such a design would evolve in use, rather than be proclaimed and ignored)*</td></tr></table>
|
|
I 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.
|
|
<table><tr><th>.</th>
|