Say, x^2 can be written as x², tanspose(M) can be written as Mᵀ, and so on?
I like it
no, because Julia allows unicode variable names:
julia> x² = 3
3
- - -
julia> Meta.@lower x²
:x²
it’s just one token
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>
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.
well yeah if you use it like that:
julia> x²(x) = sqrt(x)
x² (generic function with 1 method)
julia> x²(3)
1.7320508075688772
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
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
Very interesting! Is this mentioned in the documentation?
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
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.)
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 δ
).
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.)