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

[AntC]

Kevin Quick <quick <at> sparq.org> writes:

> 
> 
> On Tue, 31 Jan 2012 23:10:34 -0700, Anthony Clayden  
> <anthony_clayden <at> clear.net.nz> wrote:
> > I'm proposing x.f is _exactly_ f x. That is, the x.f gets
> > desugared at an early phase in compilation.
> 
> Anthony,
> 
> I think part of the concern people are expressing here is that the above  
> would imply the ability to use point-free style.  But this orthogonality  
> is disavowed by your exception:
> 
> > A 'one-sided dot doesn't mean anything.
> 

Kevin, thank you for helping me clarify my descriptions. I admit my 'proposal' 
is probably a bit hard to follow at the moment, because it lives in a series 
of emails, rather than all in a coherent wiki page.

It's also possibly confusing because there are three differing proposals in 
play, and they all use dot notation for field selection, but they use it 
somewhat differently.

But every proposal supports dot-as-function-composition, providing the dot 
appears with space on both sides.

The discussion with Donn Cave has clarified that under my proposal (but not 
TDNR or SORF), the dot notation is not necessary. Donn is concerned that older 
code might be using dot for function composition in contexts that would be 
ambiguous with field-selection-as-reverse-application.
 http://www.haskell.org/pipermail/haskell-cafe/2012-January/099008.html

So we could make the dot notation a compiler option:
- you either keep with H98 syntax,
  so field selection must be by usual function syntax f x
- or use dot notation so that x.f desugars to f x
  (of course you could still use f x: nothing forces you to use the dot)

Let me give some examples to clarify what I mean by 'one-sided' dot:
   M.f    -- no spaces, upper case to left, is qualified name
   x.f    -- no spaces, lower case to left, desugars to f x
   x . f  -- spaces both side of dot, is function composition
   x. f   -- space on one side only, what does that mean?
   x .f   -- space on one side only, what does that mean?

In my view, those last two (which I'm calling 'one-sided' dot) are too 
confusing (for the eye, at least). I would reject them as invalid syntax. H98 
might treat them as function composition. (I'm not sure, I wouldn't code like 
that.)

Donn is saying that he doesn't want to break extant code that uses 'one-sided' 
dot. Fair enough. Under my proposal we could make it a compiler option to 
stick with H98 syntax, an which case x.f is function composition (I believe), 
not field selection.

I know Wadler's rule about the disproportionate time spent on lexical syntax. 
SPJ was trying (inter alia) to introduce dot notation to support more OO-type 
thinking. I'm more familiar with dot-as-field-selector from relational 
databases, so I'm keen to introduce it.

But frankly it's a side-show compared to addressing the namespace issues 
around records.


> I haven't read the underlying proposals, ...

No, clearly you haven't from what follows. Pay me (and the other contributors) 
the respect of doing so before wasting my time. I'm a busy person. I 
appreciate the feedback on this forum when it's informed. I appreciate that 
people give their time voluntarily (which is what I'm doing).