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 <anthony_clayden@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 '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/