[Haskell-cafe] Looking for a paper [Dijkstra-Dot]

[Richard O'Keefe]

This is one of the notational issues where I venture to disagree
with the Master.  It's on a par with arguing that a number like
1234 would be easier to read as 1`2`3`4 where the semantics of
x`y is x*10+y.  More seriously, in "f x", there is an explicit
operator already.  It's "f".  The space is needed for lexical
reasons only.  If you say no, functions are not operators --
though in Haskell infix operators are functions -- but
application is the operator, so you should write "f at x" (usual
FP notation) or "f.x" (Dijkstra), then although it isn't
technically true, I've always felt that there is an infinite
regress lurking in the background:
 if x + y means (+) x y
 which really stands for (+)@x at y
 then shouldn't that in turn stand for (@)((@)(+)x)y
 and what should _that_ stand for?


On Fri, 5 Jun 2020 at 23:45, Michael Orlitzky <michael at orlitzky.com> wrote:

> On 6/5/20 7:05 AM, Anthony Clayden wrote:
> > Hi Michael, I apologise if I'm being dumb, but that ewd.pdf is not a
> > 'publication' and is not by Dijkstra, right?
>
> Sure.
>
>
> > It's taking some of the ideas from Dijkstra's EWD1300, but misapplying
> > them to Haskell in a rather badly-informed way.
>
> I wouldn't say so, for reasons explained below.
>
>
> > After all, Haskell already has a 'Application Operator' spelled ($),
> > which is perfectly first-class and with which you can do the equational
> > reasoning (with lambdas) that the doco is talking about.
>
> The thread that I was recalling (Language complexity & beginners) can be
> found here,
>
>   https://mail.haskell.org/pipermail/haskell-cafe/2016-February.txt
>
> and it started as a discussion about the use of ($) for function
> application. Namely, what should its type be? Whatever you answer is
> going to be wrong. The root of that problem is that ($) is itself a
> function, and you can't insist on using a function to apply function
> application without risk of severe injury. So the only way to even use
> ($) is via the true function application syntax, namely whitespace.
>
> But whitespace as function application syntax has its own problems. So
> we want something like ($), but we want it to be *syntax*, and it should
> take the place of " " rather than supplement it. That's the argument
> those guys (and the paper Ben suggested) are trying to make.
>
>
> > Also it doesn't seem to know Haskellers very well; nor Dijkstra's
> > well-known support for Haskell in education.
> >
> > There's other bits and pieces of 'Publications' on that the-magus site;
> > including spoofs of Dijkstra which can't even spell his first name
> > right. I rather suspect the ewd.pdf is a spoof that didn't turn out very
> > funny. So altogether it's a couple of dudes shooting the breeze.
>
> These all seem pretty irrelevant to the point being made, which I think
> has merit. This is all just a language design curiosity to me, though,
> and I'm not looking to start a new religious war until some of the
> present ones are resolved.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200608/f325080d/attachment.html>