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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
