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@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@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@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.