Looking for a paper

Everyone knows that parentheses suck for function application. But I'm looking for a CS paper that argues that function application should have its own explicit syntax in a functional programming language. I believe, in the paper, that a dot "." was used, but this would be analogous to Haskell's "$" function, except that it would be made part of the language definition. I think it came up on this mailing list (where else would I have seen it?), and if anyone remembers the name or author I'd be grateful.

I remember this from one of Dijkstra's notes, but I don't remember which one. On dinsdag 9 april 2019 16:00:11 CEST Michael Orlitzky wrote:
Everyone knows that parentheses suck for function application.
But I'm looking for a CS paper that argues that function application should have its own explicit syntax in a functional programming language. I believe, in the paper, that a dot "." was used, but this would be analogous to Haskell's "$" function, except that it would be made part of the language definition.
I think it came up on this mailing list (where else would I have seen it?), and if anyone remembers the name or author I'd be grateful.
_______________________________________________ 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.

I found it: https://www.cs.utexas.edu/~EWD/transcriptions/EWD13xx/EWD1300.html On dinsdag 9 april 2019 16:00:11 CEST Michael Orlitzky wrote:
Everyone knows that parentheses suck for function application.
But I'm looking for a CS paper that argues that function application should have its own explicit syntax in a functional programming language. I believe, in the paper, that a dot "." was used, but this would be analogous to Haskell's "$" function, except that it would be made part of the language definition.
I think it came up on this mailing list (where else would I have seen it?), and if anyone remembers the name or author I'd be grateful.
_______________________________________________ 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.

On 4/9/19 10:41 AM, jaro.reinders@gmail.com wrote:
I found it: https://www.cs.utexas.edu/~EWD/transcriptions/EWD13xx/EWD1300.html
Thank you, this is obviously also relevant, but it's not the one I'm remembering. The notation is the same, though, so this explains what I'm looking for (and is also an interesting read).

On 4/9/19 11:09 AM, Michael Orlitzky wrote:
On 4/9/19 10:41 AM, jaro.reinders@gmail.com wrote:
I found it: https://www.cs.utexas.edu/~EWD/transcriptions/EWD13xx/EWD1300.html
Thank you, this is obviously also relevant, but it's not the one I'm remembering. The notation is the same, though, so this explains what I'm looking for (and is also an interesting read).
After the Dijkstra hint, I was able to track it down: http://www.the-magus.in/Publications/ewd.pdf Thanks!

On 10 Apr 2019, at 12:00 am, Michael Orlitzky
wrote: Everyone knows that parentheses suck for function application.
But I'm looking for a CS paper that argues that function application should have its own explicit syntax in a functional programming language. I believe, in the paper, that a dot "." was used, but this would be analogous to Haskell's "$" function, except that it would be made part of the language definition.
I think it came up on this mailing list (where else would I have seen it?), and if anyone remembers the name or author I'd be grateful.
Hi Michael, long time.. Check out: A useful lambda-notation. Fairouz Kamareddine, Rob Nederpelt. Theoretical Computer Science 115 (1996) 85-109 They use “item notation”, and argue that maybe function application isn’t what we should be writing to begin with. Ben.

On 5/1/19 9:45 AM, Ben Lippmeier wrote:
Hi Michael, long time..
Check out:
A useful lambda-notation. Fairouz Kamareddine, Rob Nederpelt. Theoretical Computer Science 115 (1996) 85-109
They use “item notation”, and argue that maybe function application isn’t what we should be writing to begin with.
Thanks! This one's still a bit over my head, but I kept some category theory papers for 10+ years until I was able to read them, so I'm not afraid of this =)

On 5/1/19 9:45 AM, Ben Lippmeier wrote:
Check out:
A useful lambda-notation. Fairouz Kamareddine, Rob Nederpelt. Theoretical Computer Science 115 (1996) 85-109
They use “item notation”, and argue that maybe function application isn’t what we should be writing to begin with.
500+ pages of TaPL later, I can read this =) Their item notation goes a bit further than function application because it encompasses the typed lambda calculi: * Item notation has to handle inline function definitions like (lambda x. 2*x) y (apply the doubling function to "y") * Item notation needs to account for the type annotations in lambda abstractions, such as lambda x:T. f x (declare the argument "x" is of type "T") But, the main idea of item notation is simple: 1. Values, types, and kinds are left alone. 2. Type annotations are handled in a way that is irrelevant for my next few paragraphs. 3. The function application "f x" is translated to "(x delta)f" (These translations are actually performed recursively on terms, but the idea should be clear). The interesting one is #3, because in Dijkstra-dot notation we would write "f x" as "f.x", to mean "apply f to the argument x". The item notation, on the other hand, uses (x delta)f to mean, essentially, "feed x to the function f as an argument." They've used a delta instead of a dot (the dot is taken in the lambda calculus), but the idea is similar. If we were to reverse the Dijkstra-dot notation and write "x.f" to indicate the application of "f" to "x", then we recover the same idea. Doing so has some other benefits -- it makes diagrams easier to read, especially if you write (f;g) for the composition of g and f: x.(f;g) <===> feed x to f, then feed its result to g Older algebra books often adopt this convention modulo the dot, writing for example "xA" for the application of "A" to "x". (When these are vectors/matrices, you can explain away the heresy by defining R^n to consist of row vectors.) And in the presence of anonymous functions -- namely, lambda abstractions -- the item notation paper makes good arguments for this preference. In any case, parentheses are the worst possible choice, and I do find it interesting that the same ideas keep reappearing. Thanks for the reference.

Could it possibly be Dijkstra's mid-2000 essay on notation?
https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1300.html
Dijkstra used f.x and a programming language I used in the 80s that was
designed in the 60s used x.f and that worked very nicely with thinking
of record fields as functions.
F# of course has both f x and x |> f, where |> has caught on as $ did not.
On Thu, 2 May 2019 at 01:45, Ben Lippmeier
On 10 Apr 2019, at 12:00 am, Michael Orlitzky
wrote: Everyone knows that parentheses suck for function application.
But I'm looking for a CS paper that argues that function application should have its own explicit syntax in a functional programming language. I believe, in the paper, that a dot "." was used, but this would be analogous to Haskell's "$" function, except that it would be made part of the language definition.
I think it came up on this mailing list (where else would I have seen it?), and if anyone remembers the name or author I'd be grateful.
Hi Michael, long time..
Check out:
A useful lambda-notation. Fairouz Kamareddine, Rob Nederpelt. Theoretical Computer Science 115 (1996) 85-109
They use “item notation”, and argue that maybe function application isn’t what we should be writing to begin with.
Ben.
_______________________________________________ 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.

Richard,
Op wo 5 jun. 2019 om 04:22 schreef Richard O'Keefe
participants (5)
-
Ben Lippmeier
-
Dominique DEVRIESE
-
jaro.reinders@gmail.com
-
Michael Orlitzky
-
Richard O'Keefe