Parenthesis Postfix Function Syntax Allowing (x,y)f

[jessebett]

This issue is to discuss the possible advantages and disadvantages for allowing a postfix function call syntax where the function name appears after the closing parenthesis.
i.e. (x)f or (x,y)f

I think this notation has merit because it maintains the relationship between parenthesis() and function calling.

Recall that, by definition, Tuples are an abstraction containing the arguments of a yet unspecified function: (x,y).
f(x,y) gives the syntax to call the function f on the tuple of arguments.

I propose we extend that intuition to also allow (x,y)f to be valid syntax for function calling.

Right now it is not valid syntax. Further, (x)f is parsed as juxtaposition, so *. This causes f(x) to behave completely differently from (x)f. I don't think that is ideal either.

We would have to resolve some ambiguities e.g. f(x)g and (f)(g).

Are there obvious problems with allowing this beyond aesthetic discomfort?

[StefanKarpinski]

It should be noted that this is so unsettling to @ararslan that he hasn't even thrown his customary 👎🏻 on it, but merely put a 😕 on it instead.

[jessebett]

"aesthetic discomfort" was a pointed comment aimed at @ararslan

[ararslan]

I thought it deserved a 😕 given that the issue doesn't actually articulate why one would ever want to do this and what the perceived benefit would be.

[oxinabox]

I will point out we have AFAIK exactly 1 post fix operator.
' which defaults to adjoint.

I would maybe like some more postfix operators.
But I don't know that I would want postfix functions that require (,)

[jessebett]

The issue is missing some context from discussions on Slack around issues that result from juxtaposition.

One potential benefit is that it feels wrong that (x)f should lower to *. This would prevent that.

[jessebett]

A less provocative strategy for this issue could have been this:

Regardless of whether (x)f should be postfix notation, why should this syntax involve a method error on * at all? To me this is much more unsettling than the existence of postfix notation (which will never not upset @ararslan ) and as @oxinabox already pointed out, we have a postfix in Julia already.

f = sin
x = 2

(x)f 
# MethodError(*,(2,sin))

[KristofferC]

why should this syntax involve a method error on * at all?

Because that's how the syntax is documented (https://docs.julialang.org/en/v1/manual/integers-and-floating-point-numbers/#man-numeric-literal-coefficients).

If you want to get rid of this syntax, then open an issue about that instead perhaps?

[jessebett]

@KristofferC my syntax issue has nothing to do with integers or floating point numbers.

x = sin
y = cos

x(y) #MethodError(sin, (cos,))
(x)y #MethodError(*, (sin, cos))

First method error makes sense. Second method error involves * because juxtaposition is lowered to multiplication.

[KristofferC]

I didn't say it did. Read further in the section of the docs I linked:

Additionally, parenthesized expressions can be used as coefficients to variables, implying multiplication of the expression by the variable:

julia> (x-1)x

[mbauman]

One potential benefit is that it feels wrong that (x)f should lower to *. This would prevent that.

One potential downfall is that (x)y already means *. This would be breaking.

[jessebett]

I did read it and understand that it is where this syntax is documented. I am saying that the behaviour of (x)y should not involve multiplication at all. Let alone being documented in the section on Integers and Floating Point Numbers.

If you want to get rid of this syntax, then open an issue about that instead perhaps?

I don't want to get rid of the syntax. I want the syntax to mean something intuitive, which is why I opened this issue.

[Seelengrab]

What would foo(bar)baz even mean with this? Julia doesn't support arbitrary precedence of functions, so what should happen? Parser error? First call baz with argument bar, then foo with argument bar or the other way around? You could make a case for either one of them, so to fix this in place would need REALLY good convincing arguments.

To me this seems like a syntax change that just wants to extend tuple semantics for the sake of expanding them..

[ararslan]

I want the syntax to mean something intuitive

(1)sin meaning sin(1) feels more "wat" than intuitive, IMO.

[jessebett]

@ararslan It's not surprising that familiar prefix functions like sin feel like "wat" when written postfix.

But is the current situation actually intuitive? That (foo)bar == foo * bar in all cases. But foo(bar) == foo*bar only when foo is a numeric literal? To me it does not.

Also. I didn't open this issue to unnecessarily propose breaking changes just for fun. The existing syntax surrounding juxtaposition and multiplication is a regular gotcha. It started a discussion on gripes channel about surprising, unintuitive results. e.g.

julia> xf = 10
10
julia> 2xf
20
julia> 0xf
0x0f

Trying to resolve these annoying juxtaposition issues naturally arises at the question of the correct behaviour for this syntax.