[Haskell-cafe] Some thoughts on Type-Directed Name Resolution
anthony_clayden at clear.net.nz
Wed Feb 1 11:49:45 CET 2012
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.
> 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
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.
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
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
> 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).
More information about the Haskell-Cafe