Re: Strange crash on custom iterator

["Dan'l Miller" <optikos@verizon.net>]

On Thursday, July 5, 2018 at 11:47:33 AM UTC-5, Shark8 wrote:
> On Wednesday, July 4, 2018 at 8:07:56 PM UTC-6, Luke A. Guest wrote:
> > Shark8 wrote:
> > 
> > >> Shark8, what would be the better solution for character-encoding itself?
> > >>  (not whole words)
> > > 
> > > Whole-word isn't a terrible idea, per se. But the thrust I was getting at
> > > is the delination between languages: with Unicode it's a sequence of
> > > codepoints, independent of the actual item (word, sentence, etc) other
> > > than [perhaps] graphic-presented. That the example is (Eng,Eng,Eng...Eng,
> > > Heb,Heb,Heb,Heb, Eng,Eng,Eng...) codepoints is not the problem, though
> > > related, because it discards all information in favor of (num, num, num,
> > > num, ...) rather than actually considering alternate languages: IMO,
> > > ("The Hebrew word for man" (quote ADAM) (quote "Adam") ".") is much
> > > better as 'text' because we're preserving structure: [ENGLISH [THIS
> > > SECTION HEBREW] ENGLISH].
> > > 
> > 
> > I don’t understand why you think Unicode should carry linguistic
> > information when all it has ever been designed to do is encode symbols
> > across all languages and their direction.
> 
> I'm not saying that "Unicode should" do *anything* -- I'm saying Unicode solves *the wrong problem*.
> 
> "Encoding symbols" ties everything to a stupidly primitive level, forcing everything to such lowest
> common denominator so as to apply "the unix way" processing to text: discard all structural information,
> all semantic information, and have "some tool" regenerate it later... just like "the unix way" discards
> type-information in favor of forcing ad-hoc parsing on unstructured-text at every step between it's
> "small tools" connected together with 'pipes'.

At some level I could conceivably agree with you in principle that a strictly-linear sequence of unadorned symbols is too low-level is some designs to be useful.  For example, there was a time in the 1970s through early 1980s when Texas Instruments microprocessors excessively modeled a Turing machine's tapes (dual-tape model).  No one nowadays would think that a processor should be strictly & intentionally designed to overtly model a Turing machine directly right down to the linear streams/tapes of symbols.

Unicode/ISO10646 is asinine in its insistence on a sequence of •multiple• codepoints being the ••shortest possible•• representation of some individual letter in some natural language.  Programmers want one-letter-one-codepoint representation in all languages—not some Turing-machine tape to process sequentially statefully, as Unicode demands even in its 32-bit UCS4 or UTF-32 representations.  Programmers don't want any “well, yeah but …” situations at all when they just finished executing the fully-normalize-all-the-codepoints-in-this-string subprogram (but that “well yeah but …” is the world we suffer in with Unicode/ISO10646 as currently defined).

But, Shark8, you seem to criticizing something a little different than that.  In some alternate universe where Unicode or ISO10646 transpired entirely differently, what would Unicode-done-right* look like, especially w.r.t. Ada strings.  It seems that you are alluding to some sort of multiple-strand string or something like that (not merely allocating the billion nonBMP codepoints better so that we would have a one-letter-one-codepoint axiom). 

* Yeah, I know, in Unicode done right, there wouldn't be any Unicode or ISO10646 at all, but what would there be instead and what would the strawman look like at all in Ada?