That’s a standard array syntax like MATLAB and is very useful visually and when copying from a textbook for example. Functions like vcat and hcat do the same thing. The worst whitespace issue in Julia in my opinion still is something like rand (2, 3) is not allowed.
I don’t have any statistics to assess how ubiquitous this is, but being able to write f ( x ) in any language (at least those I know of) but not in Julia seems weird enough. I saw many code bases that use that without restrictions. It also resembles plain English. Functions in Julia are first class citizens and to my limited knowledge this restriction came from allowing macros to act on tuples. I guess putting restrictions on macros would have been better than putting restrictions on function. Any way, I’m sure that all decisions made by the respectable Julia developers and awesome community are only taken after extensive discussions, so if the community chooses that, it is very welcome.
no, but I can point to the fact that all libraries you look, you will find people doing f(x) and PEP8 uses f(x) (if you’re thinking about python, since clearly this is not allowed in Julia)
Many things in Julia are space-sensitive. For example ab is not the same as a b. What I suspect you’re asking about is when horizontal space is used to separate “arguments” and there are two contexts where this happens:
In array concatenation, horizontal whitespace separates horizontally concatenated blocks;
In parens-less macro calls, arguments are separated by horizontal whitespace (cf. macro calls that use parens, which are like function calls and use commas to separate arguments)
The rules for both of these contexts are the same and have the same caveats: 1+2 is the same as 1 + 2 is the same as 1+ 2 but different from 1 +2. You can test it like this:
Opinions about whether this is ugly or improves clarity are besides the point really. Calling a function as f ( x ) was originally allowed in Julia syntax, but it caused a syntax ambiguity in macro calls, so it was disallowed. The ambiguity, if I recall correctly, was that we allow macros to be called either as @m a b or as @m(a, b), both of which are useful in different cases. But then what does @m (a, b) mean? Is it a call with two arguments or a call with a single tuple argument? If you disallow the whitespace between the function and its arguments in function call syntax, then this ambiguity is resolved (it has to be a macro with a single argument that is a tuple).
That’s certainly a way to indicate that you want to pass a tuple, but it’s a different syntax which does matter for macros, and it doesn’t help disambiguate the other syntax.
Ouch. Would anyone miss it if this were disallowed (note, doesn’t strictly have to disallow for Vectors, only for 1×N matrices, but probably best to do for all cases for consistency)? It doesn’t seem super useful, and only allowing:
julia> [1.0 2.0 (3.0 - 4.0)]
seems would be ok. In practice (for arrays) how often would you actually do something like this, on purpose, or at least where a - b are variables (or if either is not a literal)?
At least accident-waiting-to-happen (a bug?) is something a linter, could and should (do they) catch. If not considered a bug, will have to wait for Julia 2.0… until then, I’ve been thinking Julia needs a debug/warning mode, and if running in the REPL, it seems it could be on by default.
There is no problem with arrays as they have their special syntax anyways as I said above and as mentioned also by @StefanKarpinski . The problem dates back to 2014 when they wanted to allow @m (a, b) to mean calling the macro @m on a tuple. In my opinion, they chose the easiest solution not the best solution in that case. Functions are used more than anything else in Julia, but macros should only be second to them. So, I imagine the better solution was to choose (and I can’t assess how difficult this is TBH):
@m a, b # call @m on two variables a, b
@m a b # call @m on two variables a, b
@m (a, b) # call @m on single variable (a, b)
and leave functions alone. That’s, force a space after macro names because macros are equivalent to functions without the parentheses; f(x, y) should be equivalent to @f x, y.
Allowing spaces after function names, however, can significantly improve readability in many cases. 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”). A similar case in Julia is when they forced a space before ? and after : in 1 > 2 ? 1 : 0. In this case, 1 > 2? 1 : 0 is like normal English and is not bad at all. Many people also, including myself, have the habit of adding that space before function names for clarity (I use it a lot in my introductory C course). In general, languages that give freedom and trust to the programmer seem to be more enjoyable (Nim was criticized at some point for relying heavily on spaces). Some emerging languages even went farther and removed macros altogether, but I think macros are pretty useful though.
If you’re writing Lisp, sure. I mean in that case, (f (2, 3))means f((2, 3)) right? Postfix, I would add space in Lisp too because otherwise I would think I’m calling the function with two arguments
At least for sin.