[Haskell-cafe] Type Directed Name Resolution

[Richard O'Keefe]

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.
    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).

As SML proves, having record-sensitive field names is a *different*
question from Type Directed Name Resolution applied to plain function names.
> 
> 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.

(By the way, if the field names of a record type are visible outside its
module, I start wondering why.)


> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>