4 ms·

Cool to see programming languages using non-english as a base. However, > No son validas las letras acentuadas u otros caracteres como la ñ. ["Accented lette

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/Variables.html 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?

BitwiseFool 6y ago
I know that languages like Swift can support Emoji, so why not support accented latin characters?
- jan_Inkepa 6y ago
  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...
matheusmoreira 6y ago
Lack of Unicode support in the parser? Can't think of any other reason.
mumblemumble 6y ago
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.
- account42 6y ago
  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.
dynamic_sausage 6y ago
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_languages https://en.wikipedia.org/wiki/Non-English-based_programming_...
jgwil2 6y ago
It does seem like support for Spanish-language characters should be a feature of a Spanish-based programming language.
ufo 6y ago
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...
- mumblemumble 6y ago
  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.
  - ufo 6y ago
    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.
JaumeGreen 6y ago
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.
- User23 6y ago
  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 http://users.monash.edu/~damian/papers/HTML/Perligata.html
  - jan_Inkepa 6y ago
    Oh now that I've learned some Latin I can understand this page a lot better. Thanks for the reminder it exists!
OrbitRock 6y ago
We really need an ñ operator
OrbitRock 6y ago
Great, now everybody will laugh when you try to name a variable “year”.
- SamBam 6y ago
  I spent way too long trying to work out if there was an accented Spanish word "yéar" or something that was funny...
  - nperez 6y ago
    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 :)
    - sergiotapia 6y ago
      that's why I type it `anho` when speaking with latino friends i don't have the n on my english keyboard
      - anthk 6y ago
        setxkbmap us -variant intl -option compose:rwin] Press altgr or right win key + [aeiou] or n.
      - SamBam 6y ago
        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".)

BitwiseFool 6y ago

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

jan_Inkepa 6y ago
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...

matheusmoreira 6y ago

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

mumblemumble 6y ago

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.

account42 6y ago
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.

dynamic_sausage 6y ago

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_languages https://en.wikipedia.org/wiki/Non-English-based_programming_...

jgwil2 6y ago

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

ufo 6y ago

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...

mumblemumble 6y ago
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.
- ufo 6y ago
  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.

JaumeGreen 6y ago

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.

User23 6y ago
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 http://users.monash.edu/~damian/papers/HTML/Perligata.html
- jan_Inkepa 6y ago
  Oh now that I've learned some Latin I can understand this page a lot better. Thanks for the reminder it exists!

OrbitRock 6y ago

We really need an ñ operator

OrbitRock 6y ago

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

SamBam 6y ago
I spent way too long trying to work out if there was an accented Spanish word "yéar" or something that was funny...
- nperez 6y ago
  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 :)
  - sergiotapia 6y ago
    that's why I type it `anho` when speaking with latino friends i don't have the n on my english keyboard
    - anthk 6y ago
      setxkbmap us -variant intl -option compose:rwin] Press altgr or right win key + [aeiou] or n.
    - SamBam 6y ago
      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".)