[Haskell-cafe] Some thoughts on Type-Directed Name Resolution
quick at sparq.org
quick at sparq.org
Wed Feb 1 16:22:42 CET 2012
Fair deuce. With all due respect now included, my same concern still seems to
apply although I believe I poorly stated it originally. Allow me to retry:
By declaring partial application an invalid parse, it introduces an exception
to point-free style that is at odds with the normal intuition of the uses of "f x".
SPJ's SOPR raises it as an issue and indicates he's inclined to disallow it; my
concern above would still apply.
As I surely mis-understand it (referencing your proposal as RHCT since I haven't
seen another reference):
SOPR: map (\r -> f r) recs
SOPR: map (get f) recs
SOPR/alt: qfmap (undefined :: "f") id recs
RHCT: map (\r -> f r) recs
RHCT: map (\r -> r.$rev_ f) recs
RHCT: map ((.$)f) recs
If partial application is allowed (against SPJ's inclination and explicitly
disallowed in your scheme), I could have:
map .f recs
in either SOPR or your proposal, which (to me) is an intuitive coordination of
the two concepts (point-free/partial application and f.x desugaring). I don't
think this is currently a valid parse, so I don't think it breaks existing, but
that's not a very well informed opinion either.
My concern is a triviality however; my intent was to attempt to assist in trying
to clarify a what I perceived as a conceptual gap in the discussion. I am most
grateful for the significant time and effort contributed by yourself, SPJ, and
all other parties, and I fear I've mostly wasted people's time on syntactic
trivialities already well discussed and dismissed. Please do carry on, it's all
Quoting AntC <anthony_clayden at clear.net.nz>:
> 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
> 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
> 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
> 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
> 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).
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
This mail sent through IMP: http://horde.org/imp/
More information about the Haskell-Cafe