... | @@ -41,26 +41,6 @@ An important difference between the various proposals is what constitutes a vali |
... | @@ -41,26 +41,6 @@ An important difference between the various proposals is what constitutes a vali |
|
- Permutativity:: Are `{X :: Int, Y :: Int}` and `{Y :: Int, X :: Int}` the same type? The **Poor Man's Records** system distinguishes these two, which makes implementation much simpler, but means that any function which accepts permuted records must be polymorphic.
|
|
- Permutativity:: Are `{X :: Int, Y :: Int}` and `{Y :: Int, X :: Int}` the same type? The **Poor Man's Records** system distinguishes these two, which makes implementation much simpler, but means that any function which accepts permuted records must be polymorphic.
|
|
- Repeated Fields:: Is `{X :: Int, X :: Int}` a valid record type? Both **Poor Man's Records** and **Scoped Labels** allow this type, but other systems consider this an error.
|
|
- Repeated Fields:: Is `{X :: Int, X :: Int}` a valid record type? Both **Poor Man's Records** and **Scoped Labels** allow this type, but other systems consider this an error.
|
|
|
|
|
|
<table><tr><th>Ok, opinion (since you asked for it!)</th>
|
|
|
|
<td>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.
|
|
|
|
</td></tr></table>
|
|
|
|
|
|
|
|
<table><tr><th>.</th>
|
|
|
|
<td>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.
|
|
|
|
</td></tr></table>
|
|
|
|
|
|
|
|
<table><tr><th>.</th>
|
|
|
|
<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.
|
|
|
|
</td></tr></table>
|
|
|
|
|
|
|
|
<table><tr><th>.</th>
|
|
|
|
<td>I totally disagree. More operations aren't always better! What the language needs is a records system which allows and encourages you to structure your code in the clearest possible way. In my opinion, choosing a type system which behaves as expected is an important part of that, but I would quickly be convinced otherwise by some examples which show that these extra features help to write better code. Personal comments, on the other hand, don't help.
|
|
|
|
</td></tr></table>
|
|
|
|
|
|
|
|
<table><tr><th>.</th>
|
|
|
|
<td>The way forward (as I see it) is to implement all the various possible designs as libraries (with the necessary compiler support) and then see which library is best in practice.
|
|
|
|
</td></tr></table>
|
|
|
|
|
|
|
|
# Label Namespace
|
|
# Label Namespace
|
|
|
|
|
|
|
|
|
... | | ... | |