Use of UTF8 Identifiers


#1

I recently coded with Julia and this language support UTF8 identifiers as \pi or \sqrt. It’s possible to add some kind of UTF-8 identifiers that will be translated into textual ASCII for Java compatibility.
For example, we will have this code :

val π = 3.14... // in Kotlin (accessible by \pi)

should be compiled into

double pi = 3.14...

and

val π  = 3.14
val pi = 3.14 // Redefinition of val pi

should fail because π == pi as an identifier.

Those identifiers allow to have a clearer syntax for mathematical purposes like:

fun f(x: Number) = √(x + 3x.²)
fun g(x: Number) = 4 * x + 5
typealias MFunction = (Number) -> Number
infix MFunction.○(f: MFunction) = { x: Number -> this(f(x)) }
val h = g ○ f

#2

I think it is generally a bad idea since it creates a hell of the problem for tooling and works differently for different IDEs to say nothing about breaking compatibility with everything. I have some experience with UTF-8 identifiers in BlackBox (Oberon-2) environment. It could be nice read, but terrible to write and maintain.
Kotlin allows to use any natural names for identifiers if they are in backticks and I think it is a reasonable compromise.


#3

Thank’s for your response. So maybe instead of adding this feature directly in the language maybe it will be better to create some kind of plugin for an IDE that will transform the appearance of some identifiers like `pi` or `sqrt`.


#4

With the latex completion for Atom I’m able to write this code (it’s executable).

typealias MFunction = (Double) -> Double

infix fun MFunction.`∘`(f: MFunction): MFunction = { x -> this(f(x))}
fun `√`(x: Double) = Math.sqrt(x)

val Double.`²` get() = Math.pow(this, 2.0)

val f: MFunction = { x -> `√`(x + (3 * x).`²`) } 
val g: MFunction = { x -> 4 * x + 5 }

fun main(args: Array<String>) {

  val h = g `∘` f
    
  val π = 3.14
  println(h(π))

}

I think with some improvements for readability it should be usable.


#5

I don’t think that it really improves readability, but you can contribute such a plugin, it should not be that hard to implement.


#6

I’ll see some documentation about plugin creation for IntelliJ thank’s


#7

How about something like @RenderAs("√") annotation, where IDE (I’m thinking about IntelliJ specifically) could replace the name of the identifier on call sites with specified text, similarly like it does for Android string resources (where the localized string is shown in grey instead of the R.string.something, but only until cursor is placed nearby)? Or something similar is done in Java with anonymous classes, where it renders them as lambdas (where applicable).

It would be transparent, need no modifications of Kotlin itself, should be pretty easy to implement as a plugin to IntelliJ (not sure about other IDEs) and create almost no maintenance burden on anyone, as the code would be perfectly readable without any support for it.


#8

Do you really think that has better readability when applied to the expression in brackets than sqrt?

Personally, I think that kotlin is good for mathematics and scientific applications, it could even in some cases replace both python and julia, but mathematic symbols in code do not improve everything. If one has a expression engine like the one I recently written, one can create a rendering mechanism to represent it as, for example, HTML. But why would someone want it in the code?


#9

I am not saying that I would use it, as I am pretty happy with plain old ascii identifiers (perhaps with some conservative operator overloading). But if someone really likes symbols in their code, I see that as a valid preference.
And if someone really wants to use symbols, I’d prefer the annotation based approach to

  • backticked unicode (which is hard to write and I find backticks in code really ugly),
  • special \backslash identifiers (which is another gotcha that will complicate the language (especially for begginers) and there will always be someone, who wants another symbol added) and to
  • allowing any unicode to all identifiers (the crazy amount of weird operators in Scala is one of the reasons why I left that language).

Another good benefit of annotation-based approach, is that it can be more self documenting. You could have Vector.crossProduct and Vector.scalarProduct both render to some arbitrary mathematical symbol, but still see what the real operation is just by hovering over the function call. And nobody would be forced to use it, as it would be only a setting in the IDE, without any style or preference controversy.