# New idea: importable operators

**URL:** <https://discourse.julialang.org/t/new-idea-importable-operators/7457>\
**Category:** General Usage\
**Created:** [December 2, 2017, 6:07pm UTC](https://discourse.julialang.org/t/new-idea-importable-operators/7457 "2017-12-02T18:07:35Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [December 2, 2017, 6:07pm UTC](https://discourse.julialang.org/t/new-idea-importable-operators/7457/1 "2017-12-02T18:07:35Z")

</div>

Since the feature freeze is coming up… (a trivial restricted/easy to implement pre-support should be possible).

I have two possible uses for importable operators.

a)

Instead of A’ to transpose a matrix, Aᵀ was proposed (in Github issue) as an alternative.

The proposal failed since there are some other uses for that ᵀ (as part of variable names?), and there’s already an ASCII operator.

Would it be possible to implement it in the parser FemptoLisp/Scheme code, and minimally and have it dormant? I mean the ᵀ would parse as any other ASCII letter (or whatever is done now; as a parse error).

But for those who want the accepted math syntax they could somehow import the operator [for a module or a file], and get the transpose. Or maybe could get to define the purpose?

b)

`and` and `or` where proposed as synonyms or replacement for && and or. These are strictly for [short-circuiting] control flow, not just operators.

The proposal failed, and I had a counterproposal where they are defined as non-short-cicuiting. Long store, not going to argue pros and cons here…

But can they at least be defined in the parser, just to get an syntax error? Yes, that’s strictly a breaking change, but would/is already(?) be using those as variable names…

If we want to define them post-1.0 then it will of course be a breaking change that we want to wait with for at least one year for 2.0, because of no-break promise in 1.0?

Even if we only define the operators as “illegal keywords” is it a valuable idea? We can then later define them in 1.0.x as something specific, or implement the importable idea.

There’s already in NEWS something similar:

Custom infix operators can now be defined by appending Unicode combining marks, primes, and sub/superscripts to other operators. For example, +̂ₐ″ is parsed as an infix operator with the same precedence as + (#22089).

And I see this thread:

> [@Why are arrow\_upper\_right, arrow\_upper\_left not useable as Binary infix operators?](https://discourse.julialang.org/t/why-are-not-useable-as-binary-infix-operators/6777/3):
>
> See: [https://github.com/JuliaLang/julia/issues/23224](https://github.com/JuliaLang/julia/issues/23224) We’d eventually like to allow this, but the basic problem is that we haven’t decided what precedence to use for things like arrow_upper_right. (The precedence of an operator is set in the parser and needs to be decided more or less permanently. It is difficult to decide what to do with Unicode symbols that don’t have a standard mathematical meaning.)

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [December 2, 2017, 7:06pm UTC](https://discourse.julialang.org/t/new-idea-importable-operators/7457/2 "2017-12-02T19:06:42Z")

</div>

Try this:

[https://github.com/Ismael-VC/InfixFunctions.jl](https://github.com/Ismael-VC/InfixFunctions.jl)

That along with #22089 probably covers enough ground.