add ⟂ to infix operator precedence #24404

chakravala · 2017-10-30T15:55:11Z

Hi, since I am using ↗, ↖ as binary mathematical infix operators for a package, it would help if these were able to be used as infix. I'm not entirely sure if I added it into the right place.

The goal is to be able to do something like

julia> [1,2,3] ↗ [3,2,1]
ERROR: syntax: extra token "↗" after end of expression
Stacktrace:
 [1] macro expansion at ./REPL.jl:97 [inlined]
 [2] (::Base.REPL.##1#2{Base.REPL.REPLBackend})() at ./event.jl:73

Please let me know if there is something additional that needs to be done to allow this.

JeffBezanson · 2017-10-30T16:01:46Z

Out of curiosity, what do you use them for?

chakravala · 2017-10-30T16:05:57Z

Out of curiosity, what do you use them for?

It's called the "over" and "under" operation for binary trees. Essentially, it combines 2 trees into 1, the over operation α ↗ β identifies the root of α with the leftmost leaf of β, while the under operation α ↖ β identifies the rightmost leaf of α with the root of β.

It's a fairly standard operation, sometimes / or \ are used, but that conflicts with matrices in Julia.

You can find more information in the references of my package Dendriform.jl

fredrikekre · 2017-10-30T16:28:11Z

xref: https://discourse.julialang.org/t/why-are-not-useable-as-binary-infix-operators/6777

JeffBezanson · 2017-10-30T18:10:30Z

Note that arrows use the precedence of "implies" so e.g. x↗y==z would parse as x↗(y==z) with this change.

chakravala · 2017-10-30T20:26:19Z

Note that arrows use the precedence of "implies" so e.g. x↗y==z would parse as x↗(y==z) with this change.

Thanks for clarifying, what needs to be done to avoid that? which of these lists should it be added to?

JeffBezanson · 2017-10-30T21:11:57Z

I'm really not sure what precedence it should have (#23224 (comment)). I see the Arithmetree paper doesn't use exactly these operators, so that doesn't offer much guidance. Do these arrows have any other mathematical uses that might hint at their precedence (e.g. are they multiply-like or power-like)? Otherwise I'd probably just keep them in the "arrow" precedence level, and recommend parentheses.

By the way, the READMEs for your julia packages are really nice!!

chakravala · 2017-10-30T22:54:35Z

I'm really not sure what precedence it should have (#23224 (comment)). I see the Arithmetree paper doesn't use exactly these operators, so that doesn't offer much guidance.

In that paper the symbol for over and under is / and \. However, in the new paper I am writing I have replaced it with the arrow notation, since it's actually slightly more indicative of what the meaning of it is. Also, since I would like this operation to work on vectors, I can't use \ and / in julia for it, since that would conflict with matrix operations. So I decided to use the arrow notation for that operation, which I saw in another paper on arxiv.

The way it's used in my package and in the math, it should be treated more like something of a multiplication or addition symbol. probably it should not be in the arrow category, I would prefer it to take precedence over order relations like < and ==, but I'm not sure what category would be right

By the way, the READMEs for your julia packages are really nice!!

Thank you very much, it is still a work in progress and not completed (missing some clear documentations), but I'm gradually trying to make it exciting for visitors to explore and discover

pabloferz · 2017-10-31T01:15:03Z

Maybe you can use ⍁ and ⍂, but those would need to be added as infix operators as well.

EDIT:
'⍁': Unicode U+2341 (category So: Symbol, other) (APL FUNCTIONAL SYMBOL QUAD SLASH)
'⍂': Unicode U+2342 (category So: Symbol, other) (APL FUNCTIONAL SYMBOL QUAD BACKSLASH)

EDIT 2:
That would require to add autocompletions for the symbols to be practical though, something like \APLslash and \APLbackslash.

chakravala · 2017-10-31T02:12:25Z

@pabloferz Thanks for the suggestion, but I've already settled for these symbols in writing the paper months ago. Having them as infix operators in Julia is an after thought at this point.

After thinking it over and taking a look at the other precedence lists, I figured it might actually fit into the prec-power list the best, due to its upward motion, and that would probably also give it the right kind of precedence that it needs mathematically. It seems that the prec-arrow list is all horizontal arrows anyway, so it probably makes more sense to put it into the power category from that perspective as well, plus the prec-arrow list already has so many in it, lets give prec-power some more symbol options

chakravala · 2017-10-31T02:55:57Z

Also, I'd like to ask what is the reasoning behind placing ⊣, ⊢ under the comparison group? Is there a specific need for that? In dendriform algebra for example, these operations would be analogous to addition, in fact the addition is the union of those two operations. Not that it needs to be changed, but if there is no particular reason for it being in the comparison group, could we consider moving it to plus?

JeffBezanson · 2017-10-31T04:00:35Z

In computer science ⊢ is usually a relation, which is probably why we parse it as a comparison. See https://en.wikipedia.org/wiki/Turnstile_(symbol). I think this is pretty standard, so I'd rather keep it there.

chakravala · 2017-10-31T04:47:54Z

Alright, I see. That explains why those need parenthesis.

One final thing is in the future I intend to use ⊥, but it has not been added to any list yet, so I went with the plus list for now. If that is alright, and the slanted arrows are alright, then this is finished.

Extra Idea: instead of hard-coding these operators, what if Julia allowed users to define their own operators and their precedence using multiple dispatch? then one particular definition of an operator might have some kind of precedence or associativity, while a different defintion of it for another purpose would have a completely different precedence and associativity, but it's the same symbol. This would allow a great deal of flexibility, if it were possible, but would need type inference.

JeffBezanson · 2017-10-31T04:54:32Z

⊥ to me represents a bottom element. I don't think it's an operator.

define their own operators and their precedence using multiple dispatch

That would require knowing types before code is even parsed, which is not really possible. There could be a separate mechanism for customizing parsing of operators within a certain file, but some people find that confusing, plus it makes it harder to print expressions or copy and paste code.

chakravala · 2017-10-31T04:59:49Z

⊥ to me represents a bottom element. I don't think it's an operator.

You mean like minimum of a set? Where is that notation used? In my case, it is used to represent the middle sum operation in the tri-algebra (which generalizes the di-algebra from binary trees to any tree) You can find it's usage in the Arithmetree paper and other papers talking about tri-algebras.

JeffBezanson · 2017-10-31T05:14:41Z

It's very commonly used in lattice theory and type theory (https://en.wikipedia.org/wiki/Up_tack).

chakravala · 2017-10-31T05:26:43Z

Then there's probably not a good argument for making it an op, so I removed the commit for that. Are the slanted arrows okay then?

If mathematics is ever formalized into something like a programming language, I wonder if somebody will find a clever way of handling these symbols with so many different meanings.

Now I'm beginning to gain a greater appreciation for natural language math and how flexible it is, that flexibility is not easily reproduced in a formal language.

chakravala · 2017-10-31T13:28:31Z

@JeffBezanson might this be possible: could we make the list of operator precedences mutable, so that packages could define their own operator precedences at run time? e.g.

set_op_prec(:⊥, :plus)

then Julia would throw an error or warning if two packages try to add the same operator to conflicting precedence levels. This would solve many of the issues associated with the static operator precedence

Then the Base Julia precedence lists would only include the essential operators used by Base. If this was implemented, then it would also be much more clear to users how the precedence system actually works, because they helped define it as they are implementing their packages

Please let me know if that is feasible, and if the changes in this PR ar okay as-is.

Liso77 · 2017-10-31T21:07:35Z

As wiki says: "perpendicular symbol (⟂, \perp in LaTeX, U+27C2 in Unicode) is a binary relation symbol"

julia> "⟂"=="⊥"  # \perp  \bot 
false

I am not sure if it brings nice solution to the problem. :-)

chakravala · 2017-11-01T16:19:12Z

Yes, so the \perp symbol should probably work as an operator in Julia, leaving the \bot available as a function name.

Wouldn't it make sense for Julia to have a mutable operator precedence system though? This would make it much more useful as a formal specficiation language for pure mathematics, since any symbol could have so many different contexts and meanings.

And if you disagree, then why not explain?

StefanKarpinski · 2017-11-01T16:53:16Z

What I disagree with is user-controlled operator precedence. That's definitely not going to happen.

JeffBezanson · 2017-11-01T17:06:39Z

Custom operator precedence is definitely controversial, but it should not be thought of as mutable operator precedence. In other words, you do not want an imperative command that says "change the precedence of operator x to y", but rather a scoped construct that says "in this file or block, operator x has precedence y". That would allow different packages to use different precedence rules simultaneously without interference.

However, that still has problems like that it's not possible to parse expressions without extra context info.

JeffBezanson · 2017-11-01T17:07:59Z

\perp is a relation, so if we add it, it should go in the comparison precedence level.

chakravala · 2017-11-01T17:10:48Z

In other words, you do not want an imperative command that says "change the precedence of operator x to y", but rather a scoped construct that says "in this file or block, operator x has precedence y". That would allow different packages to use different precedence rules simultaneously without interference.

This is actually what I meant as a feature. I didn't mean that the precedence should be fully mutable. What I meant is that it should be possible to add an operator precedence after Julia has started. After you set it, it should not be changed obviously, so it should not be mutable aftewards. What I meant in this case is that it should be possible to add to the list, but not necessarily undo it after the package has loaded already.

In this case, for most packages there would probably be a common system for defining the precedences. However, there might be the rare package that does not need to co-operate with other packages and would benefit from having completely different precedences.

Could you explain further what is the technical difficulty with it?

chakravala · 2017-12-15T03:16:30Z

Hi, could we at least merge the ⟂ perp symbol? The new commit only has it added, without the arrows.

stevengj · 2017-12-15T05:07:08Z

@chakravala, you'll also have to remove ⟂ from the list of allowed identifier characters in the parser.

Note that this is a breaking change and should be marked as such in the NEWS.

stevengj · 2017-12-15T05:09:53Z

Parsing ⟂ as a comparison makes sense to me, since we already parse ∥ (U+2225) as a comparison operator too.

(If only ∥ weren't so microscopic in my font.)

chakravala · 2017-12-15T12:33:20Z

Done. However, those are not the same symbol, I added the \perp symbol, which is different than the one in julia_extensions.c is. Hence, I did not remove it.

julia> "⟘"=="⟂"
false

stevengj · 2017-12-15T17:24:27Z

NEWS.md

@@ -31,7 +31,7 @@ New language features
    `@generated` and normal implementations of part of a function. Surrounding code
    will be common to both versions ([#23168]).

-  * Added `⟂` (perp) operator with comparison precedence ([#24404]).
+  * Added `⟂` (\perp) `∥` (\parallel) operator with comparison precedence ([#24404]).


∥ is already in the list of comparison operators.

(Sorry I initially led you astray on this.)

stevengj · 2017-12-15T17:28:17Z

Would be good to add a test, e.g.

@test Base.operator_precedence(:∥) == Base.operator_precedence(:⟂) == Base.operator_precedence(:<)

stevengj · 2017-12-15T17:31:00Z

In julia_extensions.c, ⟂ (U+27c2) is included as an identifier char here, separate from ⟘ U+27d8.

chakravala · 2017-12-15T17:47:30Z

That is taken care of now. Thanks for checking it.

StefanKarpinski · 2017-12-15T17:48:55Z

test/parse.jl

@@ -254,3 +254,6 @@ end
    end
    @test_throws ArgumentError parse(Complex{Int}, "3 + 4.2im")
 end
+
+# added ⟂ to operator precedence (#24404)
+@test Base.operator_precedence(:∥) == Base.operator_precedence(:⟂) == Base.operator_precedence(:<)


Directly testing what the operator_precedence function returns seems kind of pointless since that's what you defined it to be. Testing the result of a few parses would seem to be a better end-to-end test.

Something like

@test Meta.parse("a ⟂ b ⟂ c") == Expr(:comparison, :a, :⟂, :b, :⟂, :c) @test Meta.parse("a ⟂ b ∥ c") == Expr(:comparison, :a, :⟂, :b, :∥, :c)

?

stevengj · 2017-12-15T17:55:59Z

NEWS.md

@@ -31,6 +31,8 @@ New language features
    `@generated` and normal implementations of part of a function. Surrounding code
    will be common to both versions ([#23168]).

+  * Added `⟂` (\perp) operator with comparison precedence ([#24404]).


put backticks around \perp

stevengj · 2017-12-15T17:57:20Z

src/flisp/julia_extensions.c

@@ -84,7 +84,7 @@ static int is_wc_cat_id_start(uint32_t wc, utf8proc_category_t cat)

              (wc >= 0x266f &&
               (wc == 0x266f || wc == 0x27d8 || wc == 0x27d9 || // ♯, ⟘, ⟙
-                (wc >= 0x27c0 && wc <= 0x27c2) ||  // ⟀, ⟁, ⟂
+                (wc >= 0x27c0 && wc <= 0x27c2) ||  // ⟀, ⟁


You only changed the comment, not the code. Need to change the upper limit to 0x27c1.

chakravala · 2017-12-15T18:11:53Z

fixed the test, news, and character range.

based on the following Julia pull-requests JuliaLang/julia#24404 JuliaLang/julia#31604

added ↗, ↖ as infix arrow operators

538d948

ararslan added needs news A NEWS entry is required for this change needs tests Unit tests are required for this change parser Language parsing and surface syntax labels Oct 30, 2017

changed to prec-power

b94ee28

chakravala force-pushed the master branch from 2709bf2 to b94ee28 Compare October 31, 2017 05:19

added \perp

183a1fa

Merge branch 'master' into master

9fa8502

chakravala changed the title ~~add ↗, ↖ as infix arrow operators~~ add ⟂ to infix operator precedence Dec 15, 2017

stevengj added breaking This change will break code triage This should be discussed on a triage call and removed needs news A NEWS entry is required for this change labels Dec 15, 2017

chakravala changed the title ~~add ⟂ to infix operator precedence~~ add ⟂ and ∥ to infix operator precedence Dec 15, 2017

stevengj reviewed Dec 15, 2017

View reviewed changes

chakravala force-pushed the master branch from 1d58bdb to 86ede4b Compare December 15, 2017 17:38

chakravala changed the title ~~add ⟂ and ∥ to infix operator precedence~~ add ⟂ to infix operator precedence Dec 15, 2017

chakravala force-pushed the master branch from 86ede4b to 05a4b21 Compare December 15, 2017 17:43

StefanKarpinski reviewed Dec 15, 2017

View reviewed changes

stevengj reviewed Dec 15, 2017

View reviewed changes

chakravala force-pushed the master branch from 05a4b21 to f03e799 Compare December 15, 2017 18:10

removed ⟂ from julia_extensions.c

7687348

chakravala force-pushed the master branch from f03e799 to 7687348 Compare December 15, 2017 18:52

stevengj approved these changes Dec 15, 2017

View reviewed changes

JeffBezanson merged commit bd04c13 into JuliaLang:master Dec 21, 2017

JeffBezanson removed the triage This should be discussed on a triage call label Dec 21, 2017

holocronweaver mentioned this pull request Jun 8, 2018

Replace && and || with and and or #5238

Closed

chakravala added a commit to chakravala/julia-vim that referenced this pull request Apr 19, 2019

added ⋆ (\star) and ⟂ (\perp) operations

802e739

based on the following Julia pull-requests JuliaLang/julia#24404 JuliaLang/julia#31604

carlobaldassi pushed a commit to JuliaEditorSupport/julia-vim that referenced this pull request Apr 19, 2019

added ⋆ (\star) and ⟂ (\perp) operations

386371f

based on the following Julia pull-requests JuliaLang/julia#24404 JuliaLang/julia#31604

add ⟂ to infix operator precedence #24404

add ⟂ to infix operator precedence #24404

Conversation

chakravala commented Oct 30, 2017 • edited Loading

JeffBezanson commented Oct 30, 2017

chakravala commented Oct 30, 2017 • edited Loading

fredrikekre commented Oct 30, 2017

JeffBezanson commented Oct 30, 2017 • edited Loading

chakravala commented Oct 30, 2017 • edited Loading

JeffBezanson commented Oct 30, 2017 • edited Loading

chakravala commented Oct 30, 2017 • edited Loading

pabloferz commented Oct 31, 2017 • edited Loading

chakravala commented Oct 31, 2017 • edited Loading

chakravala commented Oct 31, 2017

JeffBezanson commented Oct 31, 2017

chakravala commented Oct 31, 2017 • edited Loading

JeffBezanson commented Oct 31, 2017

chakravala commented Oct 31, 2017

JeffBezanson commented Oct 31, 2017

chakravala commented Oct 31, 2017

chakravala commented Oct 31, 2017 • edited Loading

Liso77 commented Oct 31, 2017

chakravala commented Nov 1, 2017 • edited Loading

StefanKarpinski commented Nov 1, 2017

JeffBezanson commented Nov 1, 2017

JeffBezanson commented Nov 1, 2017

chakravala commented Nov 1, 2017

chakravala commented Dec 15, 2017

stevengj commented Dec 15, 2017

stevengj commented Dec 15, 2017 • edited Loading

chakravala commented Dec 15, 2017

stevengj Dec 15, 2017

Choose a reason for hiding this comment

stevengj Dec 15, 2017

Choose a reason for hiding this comment

stevengj commented Dec 15, 2017

stevengj commented Dec 15, 2017

chakravala commented Dec 15, 2017 • edited Loading

StefanKarpinski Dec 15, 2017

Choose a reason for hiding this comment

stevengj Dec 15, 2017

Choose a reason for hiding this comment

stevengj Dec 15, 2017

Choose a reason for hiding this comment

stevengj Dec 15, 2017

Choose a reason for hiding this comment

chakravala commented Dec 15, 2017

chakravala commented Oct 30, 2017 •

edited

Loading

chakravala commented Oct 30, 2017 •

edited

Loading

JeffBezanson commented Oct 30, 2017 •

edited

Loading

chakravala commented Oct 30, 2017 •

edited

Loading

JeffBezanson commented Oct 30, 2017 •

edited

Loading

chakravala commented Oct 30, 2017 •

edited

Loading

pabloferz commented Oct 31, 2017 •

edited

Loading

chakravala commented Oct 31, 2017 •

edited

Loading

chakravala commented Oct 31, 2017 •

edited

Loading

chakravala commented Oct 31, 2017 •

edited

Loading

chakravala commented Nov 1, 2017 •

edited

Loading

stevengj commented Dec 15, 2017 •

edited

Loading

chakravala commented Dec 15, 2017 •

edited

Loading