Proposal: Dot as Postfix Function Apply

[Jules Bean]

On 6 Nov 2015, at 08:31, Dominique Devriese <dominique.devriese at cs.kuleuven.be> wrote:

> 2015-11-05 9:21 GMT+01:00 Jules Bean <jules at jellybean.co.uk>:
>>> The fact that it may conflict
>>> with previous, less natural syntax choices (lens composition with .
>>> comes to mind) should not be counted against an opt-in extension.
>> 
>> Lens composition with (.) is not really a syntax choice - Lens composition with (.) is simply function composition with (.) which is a fairly deeply-set Haskell choice. I can see arguments against using (.) for function composition but I don’t think anyone would seriously consider changing that now: and Lens composition will always have the same syntax as function composition.
>> 
>> It just so happens that Lens composition with (.) gives us the ability to write person^.job.title which is one of those nice coincidences which looks a bit like C-style object dereference.
> 
> This coincidence is nice because it approximates expectations from
> other languages.  Unfortunately, this approximation breaks down
> quickly in only slightly more complex cases like `func
> person^.job.title`, "person^.someFuncProperty someArgument" and
> doesn't extend to writing `person.job.title`, leading (imho) to
> confusion and an unnatural feel.

Yes. It breaks down in the sense that it’s different. So it is, at best a nice coincidence which fosters a little useful intuition and, on closer inspect, also fosters some confusion.

On the other hand, the *reasons* that it is different are good reasons; and they lead to a more powerful abstraction because, for example (job.title) is in isolation a valid term, a lens itself, and it can be used with other functions and other contexts and combined in ways you cannot combine things in the C-style languages we started with; things like easily extracting all the titles of all the jobs in a complex structure, or neatly combining together functions which modify several sub properties of different properties, and so on.

So it’s a trade-off, but the stuff you win is quite substantial.

> Also, I'm not sure why there's a "vote" about this now.  As someone
> already mentioned, no community approval is needed to *first*
> implement it in some way (perhaps using ghc-reskin as suggested by
> someone), experiment with it and see if it makes as much sense as some
> of us expect.


Agreed. No community approval is required to work on experiments, whether they take place as translators or indeed GHC patches for people to try.

On the other hand the purpose of posting to the mailing list was to get discussion and, that’s what we’re getting :-)

Jules