From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Received: by 2002:a6b:3dd:: with SMTP id e90-v6mr1158692ioi.85.1530727264054; Wed, 04 Jul 2018 11:01:04 -0700 (PDT) X-Received: by 2002:aca:4787:: with SMTP id u129-v6mr587360oia.4.1530727263857; Wed, 04 Jul 2018 11:01:03 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.linkpendium.com!news.linkpendium.com!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!u78-v6no1892290itb.0!news-out.google.com!l67-v6ni1826itl.0!nntp.google.com!d7-v6no1903291itj.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 4 Jul 2018 11:01:03 -0700 (PDT) In-Reply-To: <64454862-b293-4ed7-9c3e-c8a1252344db@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=76.113.16.86; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 76.113.16.86 References: <70c11a71-3832-4f57-8127-f3f1c48a052f@googlegroups.com> <62e38ee4-f72f-4ed8-bef1-952040fb7f8d@googlegroups.com> <64d8b4a1-a92c-4b90-b95c-e821749de969@googlegroups.com> <887212304.552080112.848502.laguest-archeia.com@nntp.aioe.org> <87muvan83x.fsf@adaheads.home> <1449870001.552246132.581310.laguest-archeia.com@nntp.aioe.org> <5de5f768-40bf-4518-a647-22788658de74@googlegroups.com> <64454862-b293-4ed7-9c3e-c8a1252344db@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <0ebf920a-61fa-47e8-a34f-54da2e143bb6@googlegroups.com> Subject: Re: Strange crash on custom iterator From: Shark8 Injection-Date: Wed, 04 Jul 2018 18:01:04 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:53605 Date: 2018-07-04T11:01:03-07:00 List-Id: On Wednesday, July 4, 2018 at 10:55:08 AM UTC-6, Dan'l Miller wrote: >=20 > 1) As a fellow ISO standard (ISO8652), Ada is compelled by ISO rules to c= omply with ISO standards (instead of other standards bodies) when an ISO st= andard exists for that topic. Except that, if you'll allow me to be blunt and politically incorrect, Unic= ode is a terrible [non-]solution to the problem. Mark my words: Building/st= andardizing on Unicode will only bring pain and suffering. "The purpose of standardization is to aid the creative craftsman, *not* to = enforce the common mediocrity." =E2=80=94 Author unknown; found on a blackboard at Eglin Air Force Base Unicode is fatally flawed because it does enforce the common mediocrity. Mu= ch like, eg, strings for representing paths is the common way to do things,= so too is Unicode overly tied to the wrongheaded manner of doing things: d= iscarding actual structure in favor of ad hoc calculation, eliminating sema= ntically useful [and needed information] and hoping to be able to recover i= t with later processing. As an example, the sentence "The Hebrew word for 'man' is '=D7=90=D7=93=D7= =9D' (Adam)." is *NOT* merely a sequence of graphemes, codepoints, and/or = bytes. It is a semantically meaningful text consisting of multiple language= s... and *this* is what Unicode discards. A much better way to handle something like this would be a sort of multi-li= ngual 'string'/'sequence' type, where the above would be in a Lisp-ish stru= cture: ((English-string "The Hebrew word for " (quotation "man") "is "), (q= uotation (Hebrew-string "=D7=90=D7=93=D7=9D")), English-string (parenthetic= al "Adam")). But Unicode discards all that information, instead opting for ('T', 'h', 'e= ', ' ', 'H', 'e' 'b' ...) and offloading the structure-recovery to whatever= text-processing / display-method API there is. But this is all par-for-course within computer-science and "the industry" -= - Welcome to the wonderful world of unix/C "small tools" and "pipes" where = text processing is mandatory and at every step of the problem you discard a= ll type-information, forcing everything downstream to re-parse the text -- = all over again; "enforce the common mediocrity" thy name is Unix/C.