Are there any samples of what the generated code looks like in various languages?
I would also like to suggest a project name change as soon as possible.
> cito has no own garbage collector. You get what the target language offers. If it's C#, Java, JavaScript, Python, then there is a GC. In C, C++ and Swift, there are stack variables and reference counting for dynamic allocations. In OpenCL there are only stack variables.
So you can (and probably should) do almost any memory management as you would in C++. Except I don't see any alternative for `weak_ptr` at the moment.
Well that's already out the door because I almost never use shared_ptr in C++ code. The C++ core guidelines recommend using unique_ptr whenever possible. If you're going to use shared_ptr literally everywhere you do dynamic allocation, you'd be better off using a tracing GC to avoid the extra pointer indirection (and cache miss) with every dereference.
It seems to me that Cito should have manual memory management because a manual memory language can be trivially mapped onto a GC language (just turn every free or delete to an nop), while the inverse problem is intractable in the general case.
A shared_ptr can be optimized to unique_ptr if it's not copied.
Not sure what you mean by "a GC language". Most cito targets are garbage-collected.
Even though I put HN at 120% font size
At least the github page heading has a large enough font size to see it
Also, you could make jokes about the holy see programming language.
Forgive me if the above is incorrect, but in case it is:
The majority of your world's fellow humans, wishing to be comp developers, already spent months or years (combined) of their individual lives in order to learn English as non-native-speakers to do just that.
Your "whining" (yes, it's intended to be somewhat impolite, but I don't think it's unreasonable given the above) that, in case 膯 becomes the next-gen well-known programming tool, you'll have to spend maybe a couple of hours to update your keyboard mapping or learn some other way of quickly typping '膯' invokes 0 of my (and many others') empathy. Though many were helpful to suggest you how to do that quickly/correctly.
I hope my words will be deemed as 'fair enough given the context' :)
I don't have one anymore to test though, but I used to use the mac layout on Linux for a while exactly for composing using alt.
Or maybe this has changed (back) in a recent OS update? I'm running 12.0beta on this machine.
The dead-keys like Opt-E for acute only work with a small set of letters in the standard US keyboard layout, although it's possible for a different layout to support more -- subject to the combinations existing as precomposed characters in Unicode. (For other combinations, you'd need to enter a combining accent after the letter, and rely on the font to supports placing it properly.)
edit: Looks like it's supposed to work, I don't know what I'm doing wrong: https://help.ubuntu.com/community/GtkComposeTable
If you鈥檙e not in en_US you can find other locales and their Compose sequences in the nls directory.
edit: hold on, that's only in Firefox. Anywhere else, comma+c does 莽 and apostrophe+c does 膰
Yet your sentence, clearly written in English, contains all these characters.
You are supposed to be able to type them if you write in English. Also, if you are in polite company, it's alright to drop the occasional Greek word. So here we are: if you can fully write in English, you can use all these characters.
Ascii-only is the modern equivalent of all-caps. Something archaic, still used by old people with hopelessly limited input devices.
I use such characters every day because my native language has them, so maybe that's why my tooling is naturally chosen/adapted to support it.
And would the onus not be on the screen reader to not produce gibberish for a simple letter?
> creating a lookup table for all the unicode material out there might've been considered impractical or performance-hitting for the developers.
just doesn't ring true to me in any way for current software. I understand that people can be using older software, which is why I strive to restrict myself to ASCII as much as possible for the widest possible support for my users, but my software also supports unicode identifiers, up to and including a whole unicode table to talk about confusables[1]. And not all TTS software "ignores" characters, which is why people advice against using 饾憮饾憥饾憶饾憪饾懄 unicode because it doesn't get read as text but instead each character is described individually. (This is also something that TTS software should support for their users' sake, but I digress.)
To be clear, it is reasonable to be practical and cater to the software as it exists, but that doesn't mean that we shouldn't ask for better software.
[1]: this is thanks to the crate unic-udc containing this information: https://github.com/open-i18n/rust-unic
The simplest example is string interpolation, I've just submitted an issue: https://github.com/pfusik/cito/issues/26
However, I don't think a project may simultaneously have dangling references and claim to follow "Principle of least astonishment". Dangling references are unsurprising if you've been using C++ a lot, but I expect them to be very surprising to people coming from basically any garbage-collected language: Java/C#/Kotlin/JavaScript.
On the other hand, if you only know "safe" languages and target "safe" languages, there will be no dangling references.
By POLA, 膯 doesn't reinvent keywords (compare to Rust) and the translated code is meant to look "obvious" compared to what you wrote in 膯. It's not "knowledge of C# is sufficient to write code correct in eight other languages" (that would be quite astonishing actually).