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
good stuff.
-KQ
Quoting AntC
Kevin Quick
writes: On Tue, 31 Jan 2012 23:10:34 -0700, Anthony Clayden
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).
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
------------------------------------------------- This mail sent through IMP: http://horde.org/imp/