Changes between Version 25 and Version 26 of ExtensibleRecords


Ignore:
Timestamp:
Nov 25, 2007 5:07:48 PM (6 years ago)
Author:
claus
Comment:

clarify comment

Legend:

Unmodified
Added
Removed
Modified
  • ExtensibleRecords

    v25 v26  
    4040 Ok, opinion (since you asked for it!) :: The problem with scoping is that, in most cases, repeated fields are a programmer error, and the point of types is to catch such errors at compile time. At first sight, the ability to scope fields in this way looks like extra power to the programmer, but is this actually useful? I've seen no convincing examples where scoping allows a more clearly structured program, whereas there are plenty of cases where it will mean an error goes uncaught. If you have a good example of scoping, please add it to the examples section on this page. ''(the way to think about scoped records is not as "repeated fields are required", but as "if repeated fields cause no errors, they are not ruled out"; an example would be `PATH` settings: you can make sure that you have only one version of each tool in `PATH`, but most of the time you just move the version you want right now to the front)'' 
    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)'' 
    42  .:: 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)'' 
     42 .:: 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)'' 
    4343 
    4444I 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.