Readit NewsThere's a lot of discussion about this; practically changing the execution character set isn't trivial, and it's not necessarily even a desirable feature. Even with full -fexec-charset support, it still makes sense to provide compile-time translation from Unicode to target strings. For example, Commodore PETSCII makes vastly more sense as an execution character set than a source character set.
Stop adding random emoji. Don't add fictional languages, no matter how cool. Don't do.. this.
By continuing to extend Unicode like this, they risk diluting their core purpose and creating unnecessary complexity. Unicode should remain focused on its original goal and not cater to niche or novel additions.
EDIT: I'm certain there's a proposal submitter out there that contorted the argument beyond the reasonable point that these existed in an old Usborne programming book text as inline images and need to be represented. I'm going to try to hunt it down.
EDIT 2: The original proposal? https://www.unicode.org/L2/L2019/19025-terminals-prop.pdf Some of the proposed characters might have come from an older submission as well https://unicode.org/L2/L2021/21234-terminals-smalltalk.pdf
Deleted Comment
- Soundness of their semantics at a conceptual level
- Correct implementation of the semantics in rustc (in Rust)
- Correct translation of those semantics to LLVM IR targeting OS syscalls in rustc (in Rust)
- Correct translation of LLVM IR to native code in LLVM (written in C++)
- Correct implementation of OS syscalls (typically in C)
Python's safety guarantees typically depend on:
- Soundness of their semantics at a conceptual level
- Correct implementation of the semantics in CPython (in C)
- Correct translation of C to LLVM IR targeting OS syscalls in Clang (in C++)
- Correct translation of LLVM IR to native code in LLVM (written in C++)
- Correct implementation of OS syscalls (typically in C)
Both are typically contingent on correct implementation of a huge swath of C/C++ and Rust code. Even if the entire stack were written in Rust, it still wouldn't be sufficient to guarantee memory safety, since bugs anywhere in the stack could introduce memory unsafety into compiled Rust code.
Rust's guarantees come entirely at the first two layers of the stack: If the semantics are sound, and the semantics are implemented correctly in rustc, then the generated LLVM IR (treated abstractly) has memory safety. Python has similar guarantees: if its semantics are sound, and the semantics are implemented correctly in CPython compiler/interpreter, then the resulting execution of the interpreter has memory safety.
The overall complaint is one of structure; prose flows from one point to another without my being able to build a model of where the argument is going, where it came from, what's an essential detail, what's an interesting aside, etc.
It's a common fault in technical writing, maybe the most common in my experience. IMO, well-organized writing is a "parasocial" endeavor: there's a bit of mind-reading involved. One needs to get inside the head of their audience and try to predict their mental states. Why did they click on this? What questions do they have? What preconceptions would cause them to immediately close out? How can you answer those concerns as quickly as possible, and lead gradually into a more nuanced discussion (if they so desire). If they're not likely to desire it, can you convince them to?
The answers to these kinds of questions about a brand new reader should suggest a thesis. Similar reasoning about a reader who has read the thesis should suggest the content of an abstract. And so forth, for an introduction, a guide to contents, etc. After that, presuming some skimming helps too.
If anything, the 1980s is when the idea of fully reusable, separately-developed software components first became practical, with Objective-C and the like. In fact it's a significant success story of Rust that this sort of pervasive software componentry has now been widely adopted as part of a systems programming language.