Re: Strange crash on custom iterator

[Shark8 <onewingedshark@gmail.com>]

On Wednesday, July 4, 2018 at 12:57:40 PM UTC-6, Dmitry A. Kazakov wrote:
> On 2018-07-04 20:01, Shark8 wrote:
> > On Wednesday, July 4, 2018 at 10:55:08 AM UTC-6, Dan'l Miller wrote:
> 
> > As an example, the sentence "The Hebrew word for 'man' is 'אדם' (Adam)."  is *NOT* merely a sequence of graphemes, codepoints, and/or bytes. It is a semantically meaningful text consisting of multiple languages... and *this* is what Unicode discards.
> 
> And rightly so. Like 91093835.6 is just a number instead "meaningful": 
> the mass of a stationary electron.
> 
> One fundamental principle of software design is abstraction in the sense 
> of throwing away unnecessary information. A printer may know nothing 
> about Hebrew.

Interesting how you're ready, willing and able to conflate all portions of data-storage/-management into a single operation: printing.

But let's take a step backward; what about displaying the text? One certainly could argue that Unicode is a good solution in this arena, after all havng the ability to encode all of human language is it's stated design-goal, so surely it must be well-suited to that, right?

Not really.
The mere fact of "combining characters" makes unicode no more suited to textual display than a sort of hypothetical Forth/PostScript where each word/token/character is processed by the display driver and rendered appropriately. (The aforementioned Lisp-like structure being executed is the procedure: "painting/displaying the english text, switch-to-hebrew, print/display hebrew text, switch-to-english, print/display english text", which of course can be further decomposed to "print 'T' [horizontal-stroke, vertical stroke] print 'h' [vertical stroke, curved stroke, vertical stroke] print 'e' [horizontal stroke, curved stroke] ....")

This is the essential idea behind PostScript printers; and it works well. (The same/analogous procedure must be executed in SW and transmitted to the printer in non-PostScript printers; usually using some proprietary printer-control-language, which is essentially what printer-drivers *ARE*.)

So, even working backward from your example of printing, where you claim that "knowledge of Hebrew is unneeded" is... well dubious. It's certainly needed  somewhere along the line for this example. My contention that "sequence of codepoints + font" is flatly stupid for a multi-language system.

Arguably it's stupid for a single-language system, too. As an example we could use paths: "root\projects\x\source" is flatly moronic*, and we can see this by how it pops up in multi-platform development: should there be a terminal '\'? do those '\' characters need escaped? do they need to be replaced with '/'? What we have is a sequence (root, projects, x, source) which corresponds to a path down a tree, but the common "industry practice" is to think of this as a string of characters and "parse/reparse/regex/reparse/whatever" textual manipulations to read what the structure is rather than sensibly save the structural information.

* forced upon us by stupid, thin APIs to the OS.