<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">This is one of the notational issues where I venture to disagree</div><div class="gmail_default" style="font-family:monospace,monospace">with the Master.  It's on a par with arguing that a number like</div><div class="gmail_default" style="font-family:monospace,monospace">1234 would be easier to read as 1`2`3`4 where the semantics of</div><div class="gmail_default" style="font-family:monospace,monospace">x`y is x*10+y.  More seriously, in "f x", there is an explicit</div><div class="gmail_default" style="font-family:monospace,monospace">operator already.  It's "f".  The space is needed for lexical</div><div class="gmail_default" style="font-family:monospace,monospace">reasons only.  If you say no, functions are not operators --</div><div class="gmail_default" style="font-family:monospace,monospace">though in Haskell infix operators are functions -- but</div><div class="gmail_default" style="font-family:monospace,monospace">application is the operator, so you should write "f@x" (usual</div><div class="gmail_default" style="font-family:monospace,monospace">FP notation) or "f.x" (Dijkstra), then although it isn't</div><div class="gmail_default" style="font-family:monospace,monospace">technically true, I've always felt that there is an infinite</div><div class="gmail_default" style="font-family:monospace,monospace">regress lurking in the background:</div><div class="gmail_default" style="font-family:monospace,monospace"> if x + y means (+) x y</div><div class="gmail_default" style="font-family:monospace,monospace"> which really stands for (+)@x@y</div><div class="gmail_default" style="font-family:monospace,monospace"> then shouldn't that in turn stand for (@)((@)(+)x)y</div><div class="gmail_default" style="font-family:monospace,monospace"> and what should _that_ stand for?</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 5 Jun 2020 at 23:45, Michael Orlitzky <<a href="mailto:michael@orlitzky.com">michael@orlitzky.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/5/20 7:05 AM, Anthony Clayden wrote:<br>
> Hi Michael, I apologise if I'm being dumb, but that ewd.pdf is not a<br>
> 'publication' and is not by Dijkstra, right?<br>
<br>
Sure.<br>
<br>
<br>
> It's taking some of the ideas from Dijkstra's EWD1300, but misapplying<br>
> them to Haskell in a rather badly-informed way.<br>
<br>
I wouldn't say so, for reasons explained below.<br>
<br>
<br>
> After all, Haskell already has a 'Application Operator' spelled ($),<br>
> which is perfectly first-class and with which you can do the equational<br>
> reasoning (with lambdas) that the doco is talking about.<br>
<br>
The thread that I was recalling (Language complexity & beginners) can be<br>
found here,<br>
<br>
  <a href="https://mail.haskell.org/pipermail/haskell-cafe/2016-February.txt" rel="noreferrer" target="_blank">https://mail.haskell.org/pipermail/haskell-cafe/2016-February.txt</a><br>
<br>
and it started as a discussion about the use of ($) for function<br>
application. Namely, what should its type be? Whatever you answer is<br>
going to be wrong. The root of that problem is that ($) is itself a<br>
function, and you can't insist on using a function to apply function<br>
application without risk of severe injury. So the only way to even use<br>
($) is via the true function application syntax, namely whitespace.<br>
<br>
But whitespace as function application syntax has its own problems. So<br>
we want something like ($), but we want it to be *syntax*, and it should<br>
take the place of " " rather than supplement it. That's the argument<br>
those guys (and the paper Ben suggested) are trying to make.<br>
<br>
<br>
> Also it doesn't seem to know Haskellers very well; nor Dijkstra's<br>
> well-known support for Haskell in education.<br>
> <br>
> There's other bits and pieces of 'Publications' on that the-magus site;<br>
> including spoofs of Dijkstra which can't even spell his first name<br>
> right. I rather suspect the ewd.pdf is a spoof that didn't turn out very<br>
> funny. So altogether it's a couple of dudes shooting the breeze.<br>
<br>
These all seem pretty irrelevant to the point being made, which I think<br>
has merit. This is all just a language design curiosity to me, though,<br>
and I'm not looking to start a new religious war until some of the<br>
present ones are resolved.<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div>