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_clay...@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/ _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe