If you’re using Unicode symbols and their built-in precedence is not appropriate, you could open an issue about changing their precedence. There tends to be one “correct” precedence level for a given operator based on whether it is addition-like, multiplication-like, etc.
This is not a bug, it’s a feature that you wish Julia had that it doesn’t have.
We already had an issue and it was decided that the changes for the symbols in questions cant be accepted, and that’s okay, I’m not going to open another issue about it again. It’s certainly not a dealbreaker for me. The only thing is, it seems to me that it might be technically feasible to make the precedence customization a feature, especially with the alternarive parser written in Julia. Maybe I will fork it and experiment with this idea, I just simply like to think about how to generalize things. Apparently, I am very interested in parsers, two of my packages are essentially parsers, so I guess this is just something I want to explore. Maybe if I can demonstrate a working example with the Julia parser written in Julia (with non-breaking changes), maybe then the community will be more open to it.
If you write a package that parses strings using your modified Julia syntax, then anybody who wants this feature can simply import CusomizedPrecedence. (It is not necessary to convince the core developers that your idea is a good one in order to register a package. There are some basic requirements on naming and testing, but that’s about it.)
(I think @chakravala is referring to this discussion: add ⟂ to infix operator precedence by chakravala · Pull Request #24404 · JuliaLang/julia · GitHub)
It actually doesn’t matter what language the parser is written in — it’s a staging issue. Consider this source file:
f()
a + b * c
How do you write a parser that can parse this file? Well, calling f() might call the change-operator-precedence function, so you can’t parse the next line until you have executed the first line. To do that, you need a full julia runtime available, in the right state (with all needed packages etc. loaded). Of course that is technically possible, but many people consider it highly undesirable since it makes things so tightly coupled. So if a feature like this is implemented, it needs some kind of special parser syntax that doesn’t involve a turing-complete language, e.g. $#$ precedence + 12 or something.
Something that I think would make a really cool project would be a “Paper Notation” package. Something that lets you define the syntax that you use in your paper, and then write strings in that syntax that are parsed and translated into Julia code by a string macro.
Custom operators and precedence would be one aspect of this, but there are other aspects as well. The user could:
ab parses as a * b.Combine this with a way to convert the Unicode to LaTeX and an editor with good support for subscripts and superscripts, and you have a WYSIWYG system. The code that you run will look exactly like the code in your paper.
Just an idea…
Thanks for pointing this out, this is the most valid criticism of this idea so far. Yet, some other languages do seem to have the feature.
Python could avoid (solve) this problem with encoding declarations or import hooks …
I don’t say Julia needs to go in this direction but it could be inspiration.
hy-lang and macropy and emptyset (this one is simplest one and trying to explain import hook technique in Readme.md) are examples which use import hooks.