If we place Julia in the (broad) Lisp family, this looks like a reasonable request. Eg for Common Lisp and Racket, the surface syntax is almost arbitrarily extensible.
However, even though it took me some time to appreciate it, I think Julia is much more careful about syntactic extensions. Eg macros require a @, so instead of blending seamlessly into the syntax like they do for other Lisps, the reader is warned that code transformations with non-standard evaluation etc can happen there.
Because of this, I would be cautious about packages customizing the syntax along other directions, too. The way things work at the moment, I can just read a piece of code and have a pretty good idea of the evaluation structure (or, if I see a @, be warned about having to look it up).
Julia already has this for infix operators, as long as you are willing to spell the operators in a certain way. There are an infinite number of user-defined operators available — dozens of Unicode operators, plus, in Julia 0.7, a large set of suffixes that you can append arbitrarily.
Unfortunately, the problem with this is that the order of operations is hard coded into the parser.
What is truly needed is the ability to specify an arbitrary order of operations, and to make meta-packages that provide certain standard sets of order of operation, so that mathematicians can create alternate symbologies for very different kinds of abstract algebras.
It has always bothered me that the Julia core devs are against the idea of making the order of operations user defined, so that it can be arbitrary.
This is a major limitation where other languages are going to overtake Julia.
Haskell, but only for user-defined `op` infix operators. On the other hand, Haskell doesn’t allow Unicode math operators or even identifiers like x̂.
But I think it’s a stretch to call this a “major limitation” of Julia. Julia allows notation that is much closer to standard mathematics than any language I’m aware of because of the richness of the Unicode operator and identifier support.
But what’s the point of being mainstream? Hey, I get that most users probably dont want to deal with that, and it doesnt need to be turned on by default. But what’s wrong with having a switch that enables this feature if someone wants to get really wild and creative or obscure? Then you have to be forced to switch away from Julia to a proof-based language for that project.
In fact, I would love to change the precedence of operations because I still think that the result:
6/2(2+1) = 1
is wrong However, IMHO, this is a very, very dangerous step. Everything can go wild if someone decides to do this and the debugging can be very difficult.
Being able to read and review someone else’s code without having to know all of the possible global effects is much more important than being able to skip parenthesis in a language that is made for distributed package development and collaboration.
Interesting! I’m going to prognosticate a bit and predict that actually using this for anything other than defining the operators that ship with the language is going to come to be considered an anti pattern and not something one ought to do when following best practices. It will be interesting to see if I’m right! In any case, it’s a stretch to say that user-defined operator precedence is a feature that a modern programming language clearly can’t succeed without.
I think the main use is/is going to be defining operators that are “kind of like” existing operators and should have similar precedence. That is, if • is defined for matrix multiply, it can be given the precedence of * (which is always elementwise).
Putting aside the fact that * is already matrix multiplication, there are lots of allowed user-defined operators that are “kind of like *” and have the same precedence (in fact, infinitely many):
Just take * (or one of the above) and add one or more of any of the allowed operator suffixes in Julia 0.7, e.g. *̂₁ᵃ′ is an operator with the same precedence as *.
Similarly for + etcetera.
(It seems a lot clearer to me to write a *ₘ b than a `mytimes` b for an operator that is kind of like *.)
If you are someone who doesn’t want to customize the operator precedence, it is very unlikely that you will ever encounter a scenario where you actually need it. However, there are real scenarios for some people where they want to be able to customize this. In those cases, you would be expected to have the necessary mathematical background before you would be able to contribute anything anyway, so I don’t see any issue with it, from a contributing point of view. If you want to work on code with abstract mathematics, background knowledge is needed regardless… so I don’t really see the extra steps as having a negative side effect.
By the way, my comment above about this being a major issue seems to be misinterpreted here. It is not major in the sense that it affects the “mainstream” status of the language. It is major in the sense that if you were to require this feature for a specific research, then another language has to be used. I’d rather stay within the Julia environment than to switch to another language only because operator precedence cannot be set.
I think you are using “require” in some sense that I’m not familiar with. I can’t imagine a research project “requiring” a programming language to use a particular spelling for a function call.
And if you do have a research project that “requires” particular spellings, it is quite likely that no existing programming language will satisfy you, because every language has certain keywords that cannot be renamed.
Operators can also be suffixed with modifying marks, primes, and sub/superscripts, e.g. +̂ₐ″ is parsed as an infix operator with the same precedence as + .
However, IMHO, this is a very, very dangerous step. Everything can go wild if someone decides to do this and the debugging can be very difficult.