On 12/11/2010, at 2:16 PM, John Lask wrote:
On 12/11/2010 9:22 AM, Richard O'Keefe wrote:
I'm afraid it's not a *convincing* use case. It's not convincing because here "owner" *means different things*.
consider "length" ...
I have records with the attribute length, length can be given as an Int, Double, Float or maybe as a constructed type "Length", length's use as a record selector would also clash with List.length. All these have the same denotation.
"All these have the same denotation"? I am extremely confused here. AH! You mean you call them all by the same name. Well yes, that's the problem, right there.
I remind readers once again that in SML record selectors *don't* clash with names of functions. I am not concerned here to argue either for or against SML-style records and their selectors, only to point out that wanting *record fields* whose significance depends on the record they select from is *NOT* the same thing as TDNR in principle, so that arguments for that don't even come close to being arguments for TDNR as such.
should I then seporate into int_length, float_length, or use rec1_length, rec2_length etc etc...
No, the differing result types are an epiphenomenon of their differing semantics.
The length of a piece of string is a physical length.
length of string measured in CM's, in MM, in Inches, as an Int, float ... they all denote the same thing modulo some theory. You could argue that a length in CM's measured as a float is semantically different to that of CM's as an Int, which it is, but somewhere along the line those semantic differences become irrelevant to the abstract domain of application, your model, and it is that model that you wish to represent as a program, although you need to deal with the concrete differences as an implementation detail.
The length of a lecture is a time. The length of a queue is a natural number (counting people). The length of a book is a positive integer (counting say pages, or words) The length of a vowel is a relative time.
These quantities are measured differently, combined differently, and assessed differently. Calling them all "length" is a METAPHOR. (There are at least three metaphors in the list above: time-is-space, codex-is-scroll, and a form of metonomy.)
for proper name space management why should I have to define each record that defines a length field with different representation in distinct modules, or with different names for the field label when they denote the same thing?
But you just explained that while they may have the same denotation (the identifier), what it DENOTES is NOT the same (otherwise they could not be different types).
you are right
As SML proves, having record-sensitive field names is a *different* question from Type Directed Name Resolution applied to plain function names.
agreed
This is easily handled in C, Pascal, PL/1, Cobol why not in Haskell ?
But it *isn't* handled *AT ALL* in any of those languages, let alone handled easily.
In C, Pascal, PL/I, and COBOL field names are *not* values. C, Pascal, and PL/I let you pass functions as parameters to functions. But you cannot pass field names that way. The only thing you can do with a field name is apply it *immediately* to a record. And those languages don't have type variables, so when you apply a selector to a record, you know then and there what the type is.
If what you want is some sort of record facility at least as good as SML's, fine. What I am arguing against is anything resembling Type Directed Name Resolution (alias ad hoc overloading) being applied to plain ordinary functions.
that's something like what I want. I am not argiung in favor of TDNR, only that haskell record system needs improvement, particularly the scoping of field labels.
(By the way, if the field names of a record type are visible outside its module, I start wondering why.)
depends on what your using them for ..
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe