I love how this is done in Software Transactional Memory (STM) in Haskell. There, the transaction code happens in its own type (monad), and there is an explicit conversion function called `atomically :: STM a -> IO a`, which carries out the transaction.
This means that the transaction becomes its own block, clearly separated, but which can reference pure values in the surrounding context.
do
…
some IO stuff
…
res <- atomically $ do
…
transaction code
which can reference
results from the IO above
…
…
More IO code using res, which is the result of the transaction
…
This problem was solved by Plan 9 (roughly 1990) where there was a compose key to turn sequences into Unicode characters. Say compose-f-a to get ∀. This was all configurable in /lib/keyboard.
On so-called modern X11 or Wayland based systems (Linux or *BSD), there is a similar feature called XCompose. Worse syntax, but still functional.
Being able to configure your system to type the characters really doesn't solve the problem. In particular, if you get data (including metadata such as filenames) from someone else, you need to recognize the characters, both to do the configuration and then actually type them. And characters are not glyphs. There are all kinds of cases where simply looking at something doesn't and can't tell you what characters are in it.
There is a portable unicode¹ tool available, and it is packaged in a bunch of distributions. I'll spare us the full output, but "unicode a→z" produces something like:
U+0061 LATIN SMALL LETTER A
UTF-8: 61 UTF-16BE: 0061 Decimal: a Octal: \0141
a (A)
Uppercase: 0041
Category: Ll (Letter, Lowercase); East Asian width: Na (narrow)
Unicode block: 0000..007F; Basic Latin
Bidi: L (Left-to-Right)
Age: Assigned as of Unicode 1.1.0 (June, 1993)
…
U+2192 RIGHTWARDS ARROW
…
U+007A LATIN SMALL LETTER Z
Emacs has a built-in M-x describe-char that prints out similar information and also this useful tip:
to input: type "C-x 8 RET 2192" or "C-x 8 RET RIGHTWARDS ARROW"
However in the case of trying to type the name of a file in a shell, that has some weird unicode character in it, just copying the character is faster than to first identify it and then use some clever trick to type it. It can be useful to know for some small number of weird symbols how to insert them, or to use C-x 8 RET (followed by TAB-completion) to find symbols, but I almost always stick to what is available on my keyboard, and often only a small ASCII subset of that, to keep things simple.
And just to point out that there is WinCompose, for Windows, and a somewhat janky but usable solution using Karabiner Elements and macos-compose for Mac.
Well, I would venture that they consider women more as property than people. Which is of course a disgusting way to relate to fellow humans, but dehumanization is all the rage with these people.
I think we could get a lot further if we implement proper capability based security. Meaning that the authority to perform actions follows the objects around. I think that is how we get powerful tools and freedom, but still address the security issues and actually achieve the principle of least privilege.
For FreeBSD there is capsicum, but it seems a bit inflexible to me. Would love to see more experiments on Linux and the BSDs for this.
FreeBSD used to have an ELF target called "CloudABI" which used Capsicum by default.
Parameters to a CloudABI program were passed in a YAML file to a launcher that acquired what was in practice the program's "entitlements"/"app permissions" as capabilities that it passed to the program when it started.
I had been thinking of a way to avoid the CloudABI launcher.
The entitlements would instead be in the binary object file, and only reference command-line parameters and system paths.
I have also thought of an elaborate scheme with local code signing to verify that only user/admin-approved entitlements get lifted to capabilities.
However, CloudABI got discontinued in favour of WebAssembly (and I got side-tracked...)
A capability model wouldn't have prevented the compromised binary from being installed, but it would totally prevent that compromised binary from being able to read or write to any specific file (or any other system resource) that Notepad++ wouldn't have ordinarily had access to.
The original model of computer security is "anything running on the machine can do and touch anything it wants to".
A slightly more advanced model, which is the default for OSes today, is to have a notion of a "user", and then you grant certain permissions to a user. For example, for something like Unix, you have the read/write/execute permissions on files that differ for each user. The security mentioned above just involves defining more such permissions than were historically provided by Unix.
But the holy grail of security models is called "capability-based security", which is above and beyond what any current popular OS provides. Rather than the current model which just involves talking about what a process can do (the verbs of the system), a capability involves taking about what a process can do an operation on (the nouns of the system). A "capability" is an unforgeable cryptographic token, managed by the OS itself (sort of like how a typical OS tracks file handles), which grants access to a certain object.
Crucially, this then allows processes to delegate tasks to other processes in a secure way. Because tokens are cryptographically unforgeable, the only way that a process could have possibly gotten the permission to operate on a resource is if it were delegated that permission by some other process. And when delegating, processes can further lock down a capability, e.g. by turning it from read/write to read-only, or they can e.g. completely give up a capability and pass ownership to the other process, etc.
This means that the transaction becomes its own block, clearly separated, but which can reference pure values in the surrounding context.