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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a24:c105:: with SMTP id e5-v6mr3178300itg.13.1530818046063; Thu, 05 Jul 2018 12:14:06 -0700 (PDT) X-Received: by 2002:a54:4e94:: with SMTP id c20-v6mr1584599oiy.5.1530818045936; Thu, 05 Jul 2018 12:14:05 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!border1.nntp.ams1.giganews.com!nntp.giganews.com!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!85.12.16.70.MISMATCH!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.am4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!d7-v6no2910804itj.0!news-out.google.com!z3-v6ni2927iti.0!nntp.google.com!u78-v6no2880539itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 5 Jul 2018 12:14:05 -0700 (PDT) In-Reply-To: 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: <5de5f768-40bf-4518-a647-22788658de74@googlegroups.com> <64454862-b293-4ed7-9c3e-c8a1252344db@googlegroups.com> <0ebf920a-61fa-47e8-a34f-54da2e143bb6@googlegroups.com> <6af9d974-b2b4-4ab9-82e6-690ffaee2901@googlegroups.com> <795161eb-b58c-4146-9721-9b553039868a@googlegroups.com> <176034645.552448963.078419.laguest-archeia.com@nntp.aioe.org> <1064fcce-1b1c-4672-bd4e-9eb93c3a0240@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <16b51832-a06d-4274-aaed-72db36c1d50a@googlegroups.com> Subject: Re: Strange crash on custom iterator From: Shark8 Injection-Date: Thu, 05 Jul 2018 19:14:06 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 4735 X-Received-Body-CRC: 1943791473 Xref: reader02.eternal-september.org comp.lang.ada:53667 Date: 2018-07-05T12:14:05-07:00 List-Id: On Thursday, July 5, 2018 at 11:20:00 AM UTC-6, Dan'l Miller wrote: >=20 > But, Shark8, you seem to criticizing something a little different than th= at. In some alternate universe where Unicode or ISO10646 transpired entire= ly 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-stra= nd string or something like that (not merely allocating the billion nonBMP = codepoints better so that we would have a one-letter-one-codepoint axiom).= =20 Well, Ada does like 'disassembling' things [concepts, etc] into usable comp= onent pieces, traditionally-speaking. So, I'd expect the multilingual probl= em-space would likely be decomposed into some usable/useful sets of types/s= ubprograms. To borrow from other ISO stuff, perhaps something like: -- ISO 639-1 PACKAGE LANGUAGES IS Type Code is ( ab, aa, [...], za, zu ); -- other stuff. END LANGUAGES; PACKAGE LANGUAGES.CONSTRUCTS IS -- A Text is a full sequence of linguistically meaningful data, a sequen= ce of contexts. Type Text is private; -- subprograms... =20 -- Essentailly a "string" w/ a language context. Type Context( Language : Code; Length : Natural ) is private; -- subprograms PRIVATE --... END LANGUAGES.CONSTRUCTS; Or something; the point is the preservation of the structure/context of the= sequence-of-symbols\words\graphemes\whatever to provide a solid multilingu= al foundation rather than throwing away all context, shoving everything in = the Unicode-blender and having to deal with string-of-hexadecimal-sludge (c= odepoints) which, in-turn, forces reconstruction of the lost structures and= contexts... maybe involving the [ab]use of RegEx, that always seems to be = an answer when dealing with textually-represented data, hence why so many o= f our peers seem to think that RegEx is suitable for parsing/processing HTM= L.... Yes, it bucks the "everything is a string" mentality of C/unix influenced O= S-APIs; where the analog of a path would be an actual vector of names [eg (= "root", "projects", "source", "file.adb")] rather than a plain text-string = [eg "root\projects\source\file.adb"] if applied to the OS as well. The whole purpose is, as stated up-thread, "to aid the creative craftsman, = not enforce mediocrity".