Changes between Version 25 and Version 26 of ExtensibleRecords
- Nov 25, 2007 5:07:48 PM (7 years ago)
v25 v26 40 40 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)'' 41 41 .:: 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)'' 43 43 44 44 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.