Is it possible to use x² to mean taking square x^2

Say, x^2 can be written as x², tanspose(M) can be written as Mᵀ, and so on?

1 Like

I like it

1 Like

no, because Julia allows unicode variable names:

julia> x² = 3
3
- - -

julia> Meta.@lower x²
:x²

it’s just one token

5 Likes

Well, certain unicode characters are actually treated as operators in Julia:

julia> ~(f,x)=f(x)
~ (generic function with 1 method)

julia> sin~1
0.8414709848078965

julia> ↦ = |>
|> (generic function with 1 method)

julia> 1↦sin
0.8414709848078965

julia>
1 Like

You can find those operators here: julia/julia-parser.scm at master · JuliaLang/julia · GitHub

Because superscripts are already allowed for variable names, making them act as exponents (or ᵀ for transpose) would be a breaking change and would violate semantic versioning if done prior to v2.0. At its current stage of development, Julia is unlikely to add new syntax sugar except in cases where it does not cause a breaking change. As demonstrated by Python 2 → Python 3 migration hell, language developers need to be very conservative with breaking changes to limit the cost they impose on users.

4 Likes

well yeah if you use it like that:

julia> x²(x) = sqrt(x)
x² (generic function with 1 method)

julia> x²(3)
1.7320508075688772
2 Likes

It is possible to use unicode superscripts as postfix operators if they are prefixed by the ' symbol.

For example:

julia> x'² = x^2
'² (generic function with 1 method)

julia> 3'²
9
15 Likes

A somewhat common pattern is to use superscripts for intermediate results of the corresponding operation, such as

x² = x^2
y = (5 + x²)^3 + 4x² + 1
20 Likes

Very interesting! Is this mentioned in the documentation?

1 Like

I would like to appeal to all Julia developers: please avoid using Unicode
characters in your code. They are a pain to write, often are confusing
and lead to reduced legibility (is that an apostrophe or a prime?), and
in some settings are simply not displayed correctly.

Reference: Commonly Confused Characters

5 Likes

my 2c is the further the code is from a “end-users script”, the less Unicode characters it should contain. Imagine Julia’s Base looks like this and see who wants to make a PR now:

mutable struct Dict{𝒦,𝒱} <: AbstractDict{𝒦,𝒱}
    slots::Array{UInt8,1}
    keys::Array{𝒦,1}
    vals::Array{𝒱,1}
    𝒩::Int
    count::Int
    age::UInt
    ℓ::Int  # an index <= the indices of all used slots
    maxprobe::Int
end

I wish I was dreaming but I know one package who’s code looks like this through the entire repository.

Btw, I think Keno is kind enough that he won’t mind if I use his amazing Diffractor as example, but:
https://github.com/JuliaDiff/Diffractor.jl/blob/bc22ad68a59b2f013d9f934de00bb7a2c1edf605/src/interface.jl#L22-L35

I’m torn apart on this, on one hand math symbol is extremely useful abstraction for this domain, on the other hand…do you expect users to type ∇() instead of gradient() when using this package? what if they don’t have editor support (i.e. learning, following a tutorial, etc.)

7 Likes

I think there is an important distinction to make between using unicode in source code vs. forcing users to use unicode in an external interface. I find using unicode in source code makes it easier for me to read and develop, since it helps me avoid using unnecessarily long variable names. However I don’t make interfaces that force users to use unicode (for example we have a function called delta but those who want to can use the syntax δ).

6 Likes

I totally agree.

Here’s a link to the documentation on allowed names. (It does not mention ' specifically, but in general it is possible to add sub/superscripts to operators.)

3 Likes