<pre style="white-space:pre-wrap;background-color:rgb(255,255,255)"><div dir="auto">>> On 6/5/20 7:05 AM, Anthony Clayden wrote:
>><i style="font-family:-apple-system,HelveticaNeue"> Hi Michael, I apologise if I'm being dumb, but that ewd.pdf is not a</i></div><div dir="auto">>><i style="font-family:-apple-system,HelveticaNeue"> 'publication' and is not by Dijkstra, right?</i></div><div dir="auto">
> Sure.


>> <i style="font-family:-apple-system,HelveticaNeue">It's taking some of the ideas from Dijkstra's EWD1300, but misapplying</i></div><div dir="auto">>><i style="font-family:-apple-system,HelveticaNeue"> them to Haskell in a rather badly-informed way.</i></div><div dir="auto">
> I wouldn't say so, for reasons explained below.

<br></div><div dir="auto">An undated pdf without even the authors names, </div><div dir="auto">but using a respected author's name seems dodgy to me.</div><div dir="auto">It's not "with E.W.Dijkstra" at all, indeed I'd say it's "against" him.</div><div dir="auto">I think what they impute to EWD is wrong in fact and wrong in attitude,</div><div dir="auto">for reasons explained below.</div><div dir="auto"><br></div><div dir="auto">
>><i style="font-family:-apple-system,HelveticaNeue"> After all, Haskell already has a 'Application Operator' spelled ($),</i></div><div dir="auto">>><i style="font-family:-apple-system,HelveticaNeue"> which is perfectly first-class and with which you can do the equational</i></div><div dir="auto">>><i style="font-family:-apple-system,HelveticaNeue"> reasoning (with lambdas) that the doco is talking about.</i></div><div dir="auto">
> The thread that I was recalling (Language complexity & beginners) can be
found here,
>
> <a href="https://mail.haskell.org/pipermail/haskell-cafe/2016-February.txt" style="font-family:-apple-system,HelveticaNeue">https://mail.haskell.org/pipermail/haskell-cafe/2016-February.txt</a></div><div dir="auto">
> and it started as a discussion about the use of ($) for function
> application. Namely, what should its type be?</div><div dir="auto"><br></div><div dir="auto">Its type is :: (a -> b) -> a -> b; that's in the Haskell Report</div><div dir="auto">and what you get at the GHCi prompt :t ($) -- at GHC 6.5 with no extensions on.</div><div dir="auto"><br></div><div dir="auto">Also while we're at it Data.Function.& :: a -> (a -> b) -> b  </div><div dir="auto">-- reverse application, which'll do for the paper Ben suggested.</div><div dir="auto"><br></div><div dir="auto">> Whatever you answer is going to be wrong.</div><div dir="auto"><br></div><div dir="auto">That's a fine type for the purposes of the 'thought-dialogue'</div><div dir="auto">-- which is not a language specification.</div><div dir="auto">If GHC's type under the hood is polykinded/higher-ordered/typeRep'd/etc</div><div dir="auto">yes that'll confuse beginners, but won't upset the 'thought'.</div><div dir="auto"><br></div><div dir="auto">> 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.</div><div dir="auto"><br></div><div dir="auto">So that's what the authors of EWD.pdf do at the end of the piece,</div><div dir="auto">so that they derive (.) by eta-reduction. It's bogus.</div><div dir="auto"><br></div><div dir="auto">Also bogus their is putting '.' between the lambda and the bound variable.</div><div dir="auto">WTF is that? You don't 'apply' lambda to a variable; </div><div dir="auto">it's not a function; <span style="font-family:-apple-system,HelveticaNeue">it's a binding mechanism. </span></div><div dir="auto">Some syntaxes for lambda calculus put a dot _after_ the bound variable, <span style="font-family:-apple-system,HelveticaNeue">where Haskell uses ->.</span></div><div dir="auto"><br></div><div dir="auto">To put it bluntly: the authors are blundering.</div><div dir="auto">

> But whitespace as function application syntax has its own problems.</div><div dir="auto"><br></div><div dir="auto">EWD1300 has only a short section on 'Invisible operators'. Dijkstra doesn't like them.</div><div dir="auto"><br></div><div dir="auto">To expand his examples, in:</div><div dir="auto"><br></div><div dir="auto">>    π + x sin(y)</div><div dir="auto"><br></div><div dir="auto">The invisible space (juxtaposition) between x and sin means multiplication; </div><div dir="auto">the invisible non-spaces within "sin" are not juxtaposition, they're merely a multi-letter name; </div><div dir="auto">the invisible non-space between "sin" and parens is function application.</div><div dir="auto">(To be precise in C-family languages, it's the pair of parens: rand() is niladic function rand applied to no arguments.)</div><div dir="auto"><br></div><div dir="auto">Practical programming languages are limited to ASCII, so can't have UTF-8 chars in names, so we'd have to spell π as "pi" -- which includes another invisible non-space.</div><div dir="auto"><br></div><div dir="auto">Then EWD1300 wants to put alternating operators with names, thusly:</div><div dir="auto"><br></div><div dir="auto">>    pi + x * sin.y</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">> So we want something like ($), but we want it to be *syntax*,</div><div dir="auto"><br></div><div dir="auto">Yes. EWD1300's syntax is that (presumably) what's lexed as a (sequence-of) symbol</div><div dir="auto">alternates with what's lexed as a name/sequence-of letter.</div><div dir="auto">And there's precedence/associativity; and parens' only purpose is to override.</div><div dir="auto"><br></div><div dir="auto">EWD1300 does not claim that what's between "pi" and + or between + and x</div><div dir="auto">is function application. EWD1300 does not consider operator sections</div><div dir="auto">or partial application of operators; only partial application of functions.</div><div dir="auto">There's brief mention of 'lambda-abstraction' (partial application), </div><div dir="auto">but no working of actual lambda expressions.</div><div dir="auto"><br></div><div dir="auto">EWD1300 is not talking about Haskell's peculiar syntax at all.</div><div dir="auto">Including not talking about lambda syntax.</div><div dir="auto">And I'm sure he'd complain about the iffy use of parens in operator sections</div><div dir="auto">-- they're not there merely to override precedence;</div><div dir="auto">(5) === 5;  (pi) === pi;  (+) =/= +</div><div dir="auto"><br></div><div dir="auto">> and it should take the place of " " rather than supplement it.</div><div dir="auto">> That's the argument those guys (and the paper Ben suggested) are trying to make.</div><div dir="auto"><br></div><div dir="auto">EWD1300 does not suggest there's function application between an operator and its operands</div><div dir="auto">-- although one could argue that's just as much juxtaposition.</div><div dir="auto">Suggesting that for any other operator than ($) would be OK</div><div dir="auto">and thereby deals with Haskell's operator sections.</div><div dir="auto">But suggesting it for ($) leads to infinite regress.</div><div dir="auto">Dijkstra (the real one) was smart enough to see that.</div><div dir="auto"><br></div><div dir="auto">The pdf poses a bogus problem; direct consequence of the authors not understanding EWD1300.


AntC</div><br></pre>