Hacker News Reader

Hacker News

Comment by jan_Inkepa | Hacker News Reader

Full thread

jan_Inkepa

Cool to see programming languages using non-english as a base.

However,

> No son validas las letras acentuadas u otros caracteres como la ñ.

["Accented letters or other characters such as ñ are not valid." sez deepl]

https://manual.lenguajelatino.org/es/stable/sintaxis/Variabl...

Looks like it doesn't support accented characters in variable names. I wonder what their reason for excluding those is?

View on HN

Non-English-based programming was common in the Soviet Union, but certainly not unique to it:

https://en.wikipedia.org/wiki/Non-English-based_programming_...

It does seem like support for Spanish-language characters should be a feature of a Spanish-based programming language.

Yeah, I wonder the same. After all making a programming language derived from a real language and not using the "features" of said language seems lacking.

In fact it should be "función", that way it would not matter whether you are writing code or documentation.

Here's the Sieve of Eratosthenes as a fun example of what you're asking for[1].

        #! /usr/local/bin/perl -w
        use Lingua::Romana::Perligata;
        maximum inquementum tum biguttam egresso scribe.
        meo maximo vestibulo perlegamentum da.
        da duo tum maximum conscribementa meis listis.
        dum listis decapitamentum damentum nexto
            fac sic
                nextum tum novumversum scribe egresso.
                lista sic hoc recidementum nextum cis vannementa da listis.
            cis.

[1] http://users.monash.edu/~damian/papers/HTML/Perligata.html

Oh now that I've learned some Latin I can understand this page a lot better. Thanks for the reminder it exists!

I'm guessing it's because the language was implemented in C, whose stdlib doesn't really do Unicode strings, and the authors didn't think to use a different string type for identifiers until it was too late.

You don't need "Unicode strings" for this - and C strings can hold UTF-8 just fine. What you need is Unicode-normalization so that different ways to compose the same character refer to the same variable, but that can be done in C with a library just fine.

Great, now everybody will laugh when you try to name a variable “year”.

I spent way too long trying to work out if there was an accented Spanish word "yéar" or something that was funny...

For those who don't speak Spanish, año is "year", and without the accent on the "ñ", it's a body part that you can probably guess :)

that's why I type it `anho` when speaking with latino friends i don't have the n on my english keyboard

        setxkbmap us -variant intl -option compose:rwin]

Press altgr or right win key + [aeiou] or n.

You're using the Portuguese transliteration of the eñe. And if you were doing it with an Italian or French transliteration, you could write "agno."

(That said, it's one that's so common it's worth learning the keyboard shortcut for. On a Mac it's "opt-n, n".)

I don't know what was they reason they chose but a one possible one is that unicode variable names introduce several implementation challenges. You need to worry about normalization (the same character may be represented by different byte sequences) and you might need to have large tables to be able to tell whether an unicode character is a letter or a symbol. There are also problems with encodings; UTF-8 vs Latin-1 and so on...

I imagine it wouldn't have been that hard, if the authors had just used ICU4C for string handling. I've had good luck with just converting all input to normal form C. The bigger challenge there is that, if you're using ICU strings, then you've lost the ability to use any library that is designed to work with C strings. There's no way to avoid 0x00 showing up in the middle of UTF-16 and UTF-32 strings, and, even if you use modified UTF-8 to avoid NUL bytes, you still break the assumption that a string's length is equal to its size is bytes.

Not to mention the inherent problem of adding a dependency to an external library.

I know that in the case of Lua that was one of the main reasons. ICU by itself would be larger than the rest of the interpreter.

Lack of Unicode support in the parser? Can't think of any other reason.

I know that languages like Swift can support Emoji, so why not support accented latin characters?

Full Emoji support is ... horrendous ... I look into it about once a year; I think there are proposals for unicode but as of now it's still super hard to detect if something's a single emoji symbol or not (the most current regex I saw for emoji-matching was, IIRC, several KB in size...). Some day in our cyberpunk future we'll get there...probably some decades after full self-driving vehicles have become standard...

We really need an ñ operator

Reply on news.ycombinator.com