bugGNU Octave - Bugs: bug #57103, Support Unicode mathematical...


bug #57103: Support Unicode mathematical symbols as function and variable names

Submitted by:  Anton Kochkov <xvilka>
Submitted on:  Wed 23 Oct 2019 07:56:55 AM UTC  
Category:  Interpreter Severity:  1 - Wish
Priority:  1 - Later Item Group:  Feature Request
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Thu 24 Oct 2019 03:05:17 AM UTC, comment #7: 

I don't see a technical reason that we couldn't expand the range of what it means to be a symbol name in the language beyond /[_a-zA-Z][_a-zA-Z0-9]*/ (to exactly what character set, I don't know), but I'm not sure it's a good idea.

For me, one of the biggest reasons to not make a change like this is compatibility with Matlab.  We don't really get to choose much about how the language works.  When we have innovated in the past, it has pretty much always come back to bite us later.

John W. Eaton <jwe>
Project Administrator
Thu 24 Oct 2019 12:50:41 AM UTC, comment #6: 

This is a really interesting idea. As a software engineer and maintainer, I hate it. But as a data analyst who sometimes names variables stuff like "delta_vee" and "sigma_prime", it's really intriguing.

It opens up a bunch of issues with:
a) different Unicode characters that look like each other
b) font support for non-basic-English characters
c) input methods for non-basic-English characters
d) support for source code file encoding detection/configuration in the first place
e) ugh, that "prime" character looks just like the "transpose" operator or a single-quote but would be a normal identifier component, and double-prime looks just like double-quotes
f) same with "mathematical times" and its siblings: unless we introduce syntax for new operator classes, "A×B" is a single token that's treated as an identifier, not equivalent to "A × B".
g) Unicode normalization issues
h) accessibility issues
i) weird injection-attack security issues?

Given that Octave tends to support older OS versions (esp. Linux) for a long time (relevant for b and c), and I don't think we have anyone with enough Unicode expertise to properly define the character classes that would be appropriate to use for identifiers etc., I suspect that doing this right now would just open a big bag of hurt. But it's sure interesting to think about for the future.

Andrew Janke <apjanke>
Wed 23 Oct 2019 12:42:35 PM UTC, comment #5: 

Thanks for clearing this up. The thing about LaTeX notation being supported but not Unicode threw me off the track...

Markus Mützel <mmuetzel>
Project Member
Wed 23 Oct 2019 12:08:30 PM UTC, comment #4: 

Gentoo, Octave 5.1.0. It is not a version specific, it's how Octave currently written.

Note, I am not speaking about strings, I know they allow this, obviously. I meant the variables and function names. I know that's currently impossible, thus this feature request. It's 2019 year and more software allows to deal with the Unicode mathematical symbols.

Anton Kochkov <xvilka>
Wed 23 Oct 2019 11:43:56 AM UTC, comment #3: 

Which OS and Octave version?

Function and variable names must contain only ASCII letters, digits and underscores and follow the rules as described in section "7 Variables" in the manual.

Using non-ASCII characters in strings should be possible:

x = "α";

Markus Mützel <mmuetzel>
Project Member
Wed 23 Oct 2019 11:13:33 AM UTC, comment #2: 

See example for the function name

octave:1> function[result] = σ(x)
parse error:

  syntax error

>>> function[result] = σ(x)



Or a variable name:

octave:1> ℤ = 1;
parse error:

  invalid character '�' (ASCII 226)

>>> ℤ = 1;



Something like α character can't even be pasted to the REPL (while it works for pasting directly in the bash in the same terminal window):

octave:1> �
parse error:

  invalid character '�' (ASCII 177)

>>> �



Anton Kochkov <xvilka>
Wed 23 Oct 2019 10:52:15 AM UTC, comment #1: 

I don't think we should extent the language to support non-ASCII characters in function and variable names.

But from the description in comment #0, I am not sure what this bug report is exactly about. Is it that the you want to use Unicode characters in strings (single-quoted or double-quoted)? That should be working in many places with Octave 5 already. And the situation will have improved some more for Octave 6.

Can you give a specific example that isn't working as expected?
Please, also report your operating system and Octave version.

Markus Mützel <mmuetzel>
Project Member
Wed 23 Oct 2019 07:56:55 AM UTC, original submission:  

Many mathematical systems nowadays support use of the Unicode characters in the program texts and REPL/console.

Currently, Octave supports the LaTeX notation for the output/plotting, but not the Unicode characters themselves in the functions code.

For example, systems like Coq, Agda, Lean support Unicode characters as parts of their programs:

- https://github.com/coq/coq/wiki/CoqIde-configuration-to-input-special-characters
- https://github.com/soonhokong/travis_test/blob/master/doc/lean/tutorial.md#propositional-logic
- https://people.inf.elte.hu/divip/AgdaTutorial/Symbols.html

Or Maxima:
- https://feb.kuleuven.be/public/u0003131/wxMaxima/wxM_intro/58_5Greekcharacters.htm

Or Mathematica:
- https://www.wolfram.com/language/12/networking-and-system-operations/use-the-full-range-of-unicode-characters.html?product=language

https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode for commonly used characters.

Anton Kochkov <xvilka>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by apjanke (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by siko1056 (Updated the item)
  • -email is unavailable- added by xvilka (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-10-23 siko1056 CategoryNone => Interpreter
        Severity3 - Normal => 1 - Wish
        Priority5 - Normal => 1 - Later
        Item GroupNone => Feature Request
        StatusNone => Confirmed

    Back to the top

    Powered by Savane 3.5