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