[Haskell-cafe] Some thoughts on Type-Directed Name Resolution

[AntC]

Donn Cave <donn <at> avvanta.com> writes:

> 
> Quoth AntC <anthony_clayden <at> clear.net.nz>,
> ...
> > We're on the slippery slope! Where will it end?
> >
> > And now that I've found it, I so love:
> >
> >     customer.lastName.tail.head.toUpper    -- Yay!
> 
> ... compared to present practice, with where dot is function
> composition only -
> 
>     (toUpper.head.tail.lastName) customer
> 
> So two competing meanings of ".", where one is literally the reverse
> of the other.  Of course we won't be able to spell composition
> without spaces any more, so technically the backwards and forward
> sense of . are distinct, but it seems kind of unfortunate anyway.

Thanks Donn. I can see we aren't going to agree on this, so I'll be brief. 
(I'll use my limited time to gather the proposal properly on to a wiki.)

It was a surprise to me that dot without spaces around is still legal syntax 
for function composition. So yes, we're going to break code (and hearts, by 
the sound of it).

I'm proposing my record fields so that selectors are just functions. Then it's 
independent of dot notation. (It's the semantics I'm far more concerned with.)

You (Donn) can then avoid 'switching on' dot as tight-binding reverse func 
apply, and nothing's got broken. (On the other hand, the change in semantics 
is so dramatic switching it on would get compile failures in typing 
expressions, so I don't see any danger of running broken code.)

We could use something other than dot for the purpose (# has been suggested), 
but the trouble is that the user-defined operator space has got used up. I see 
that as part of introducing tight-binding reverse func apply, I also need a 
loose-binding version (counterpart to ($) in the Prelude). (.$) seems most 
natural, but probably that's already extant in user-defined code.

So the advantage of dot (aside from it being familiar from other programming 
paradigms) is that we know the design space isn't used up.

> ...
> 
> If you'll consider an idea from the peanut gallery ...  for me, the
> dot notation for fields may as well be "spelling" as an operator -
> that is, customer.lastName deploys a field named ".lastName".

No, I no longer think it's just spelling. (I can see my Yay example is pushing 
the innovation too far too fast.) Examples which might be easier to swallow:

     customer.fullName
     shape.area
     date.dayOfWeek
     name.middleInitial
     list.length

Are all pseudo- or virtual or calculated 'fields'. (Or if not fields, then 
attributes or properties.)

I presume you're not suggesting we have both a function `area' and a pseudo-
field `.area'?

Perhaps we could allow some graphic char as a prefix to field names? (perhaps 
# because it's already allowed as part of magic-hash names?

But it would be part of the name, _not_ an operator.

     customer.#firstName   <===> (#firstName customer)


AntC