Julia: make `f (a,b)` an error

[StefanKarpinski]

See https://groups.google.com/forum/#!topic/julia-users/ysc9loSduN0

We would want to make it a warning first, then an error later on.

[goszlanyi]

This would be a future-proof decision.

[stevengj]

It seems odd to me to disallow this. Has there ever been a programming language that disallowed whitespace before parentheses in function calls?

There are certainly people out there who habitually put spaces between the function and arguments; e.g. the GNU Coding Standards recommends this ("We find it easier to read a program when it has spaces before the open-parentheses and after the commas."), although that style always felt weird to me.

[BobPortmann]

It seems to me that the problem in the link above is not that function calls allow an optional space, but that macro calls consider the parens optional. If macro calls forced the parens then there would be no ambiguity between @printf("%f",42.0) and @printf ("%f",42.0). With the present system the 1st is a macro call with two inputs and the 2nd is a macro call with one tuple as input.

Note that I hate the f (a,b) style, but it feels a bit extreme to exclude it.

[stevengj]

Requiring parens in a macro call would be a major change, and would change the flavor of the language somewhat. The optional parens in a macro call allow the macro calls to look more like syntax and less like function calls. e.g. @inbounds and @parallel and so forth would be a lot uglier with parens.

[goszlanyi]

Macros without parentheses
and function calls with parentheses but no space before them
seems to be a good balance to me.

[StefanKarpinski]

Title changed to reflect the bigger issue.

[StefanKarpinski]

We could, deprecate the @f (a,b) syntax for a while and then change it to mean @f(a,b) and require people to write @f((a,b)) if they really want to pass a tuple to a macro, but that feels pretty awkward for macros – sometimes you _want_ to just pass a tuple to a macro. The style of writing f (a,b) is really awful, imo, and if getting rid of that is the cost we pay to avoid confusion but still allow easily passing tuples to macros, I'm ok with that.

[nalimilan]

+1

It will also help enforcing a common coding style.

[JeffBezanson]

I'm ok with disallowing f (x). The macro thing is a bit of a distraction; one more serious issue is the difference between f (x) and [f (x)]. If you're in the habit of writing the extra space, adding square brackets doesn't do what you'd expect.

[porterjamesj]

+1 for disallowing

[vtjnash]

julia is more space-sensitive than many other languages, so I think think is very reasonable

[StefanKarpinski]

There has to be a pretty long deprecation period because a lot of people have code that looks like this.

[vtjnash]

Also, post-0.3

[nalimilan]

Also, post-0.3

Better deprecate as soon as possible, but be tolerant for a long period, so starting with 0.3 might be a good idea.

[ivarne]

We should be really sure that we really want to deprecate something before deprecating it in a release (ref: Scalar + Array), but sooner is better than later. It is just a parser warning, not a complicated feature that we would need multiple iterations to get right.

[mbauman]

+1 for the deprecation. I really like the uniform style that Julia has converged upon, and enforcing it within the parser (within reason) helps with readability.

That said, there are similar syntaxes that should probably be treated similarly:

• typed array literal: Int  [1.0 2 3.0], String  []
• typed comprehensions: Int  [i for i in 1.0:3.0], (String=>Int)  ["$i"=>i for i in 1.:2.]
• type parameters: Array  {Int,0}, Dict  {String,Int}  ()

To my eyes, these all look like foreign constructs.

[ViralBShah]

I personally do not like the f (a,b) form visually. I feel a little queasy about disallowing it altogether though. That said, we do have other whitespace specific behaviour (concatenation is the only one I can recall, but I am not sure if that is the only one).

[jiahao]

[1:end] vs [1 :end] is a notoriously pernicious example of semantically meaningful whitespace

[rfourquet]

Why not having functions and macros behave more similarly: f (a, b) == f((a, b)), i.e. f x y z == f(x, y, z), a syntax similar to that of haskell for function application.

[nalimilan]

@rfourquet It's far too risky. People will mistakenly add a space between the function name and the parenthesis, and get weird no method errors because a tuple got passed as first argument; or even no error but a really confusing result.

[StefanKarpinski]

The problem is with the ambiguity of the macro invocation syntax – that would just add more problems.

[hayd]

+1 I've been bit by this in ruby where f(x, y) != f (x, y), tricky to spot.

[ninjin]

As I was the first one to suggest this back on julia-users, I wholeheartedly support this and think that we should do this sooner rather than later.

[tiffany352]

I would like to point out that in function-like C preprocessor macro definitions, the spec mandates that there be no space in between the name of the macro and the left parenthesis. It doesn't apply to invocations, but there is a major difference between #define foo(x) x and #define foo (x) x (the former is a function-like macro, the latter simply expands to (x) x). It would not be unprecedented to do this.

[timholy]

I'll add my vote for disallowing this. From the comments here there's almost universal agreement we should do this, so I removed the "decision" tag and marked it "up for grabs."

[stevengj]

Yeah, we should go ahead and disallow this; my earlier comment was too hasty, since there are these sorts of whitespace sensitivities all over Julia already.

[ScottPJones]

An earlier comment asked if other languages disallowed spaces between the function name and (, and many of the older languages definitely did...and still do, in fact... I seem to recall even some early C compilers that did not allow them either [things like BDS C for the 8080 processor]. :+1: to disallow this...

[tkelman]

Close due to #11891, or wait until the deprecation is removed?

[ninjin]

@tkelman: I say we keep it open until we turn it into an error on the v0.5 branch.

[ivarne]

Open a new issue to collect a list of 0.5 deprecations that should be removed?

[stevengj]

I thought that all deprecations for version 0.$n are generally turned into errors for 0.$(n+1)?

[tkelman]

Yeah, I don't think we need to remove deprecations that were added during 0.4-dev until we move from 0.5-dev to 0.5-pre.

[swt30]

Maybe related: today I did

julia> using PyPlot. PyCall

What I expected: PyPlot and PyCall to be loaded
What I mistyped: A period instead of a comma
What I got: The same as typing using PyPlot.PyCall
What I thought would happen if I made this mistake: A syntax error.

a .b is already deprecated but this is still permitted. I can imagine it being a little tricky to debug if you don't spot there's a dot instead of a comma there.

[stevengj]

@swt30, this is unrelated; please file a separate issue if needed.

[Keno]

Am I understanding correctly that the deprecation was introduced newly on 0.5? In that case this issue should be moved into the 0.6 milestone.

[tkelman]

https://github.com/JuliaLang/julia/commit/3aed3f5489ab3d12155ba112644b3d86d7b42658 was included in 0.4.0, so no.

[Keno]

I see, so this'll be closed when we remove deprecations.

[tkelman]

The deprecation is entirely in the parser I think, so it depends whether those are as clearly organized as the ones in base/deprecated.jl.