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=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,73cb216d191f0fef X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.224.110.68 with SMTP id m4mr7227666qap.2.1363470718539; Sat, 16 Mar 2013 14:51:58 -0700 (PDT) X-Received: by 10.50.236.40 with SMTP id ur8mr773949igc.6.1363470718481; Sat, 16 Mar 2013 14:51:58 -0700 (PDT) Path: k8ni188qas.0!nntp.google.com!dd2no1987591qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 16 Mar 2013 14:51:58 -0700 (PDT) In-Reply-To: <1jtvzi1v65aqm.1k5ejsveno59f.dlg@40tude.net> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=69.20.190.126; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 69.20.190.126 References: <8klywqh2pf$.1f949flc1xeia.dlg@40tude.net> <513f6e2f$0$6572$9b4e6d93@newsspool3.arcor-online.net> <513faaf7$0$6626$9b4e6d93@newsspool2.arcor-online.net> <51408e81$0$6577$9b4e6d93@newsspool3.arcor-online.net> <11rcs3gg4taww$.bylek8fsshyz$.dlg@40tude.net> <99929f93-b80f-47c3-8a37-c81002733754@googlegroups.com> <87ec4b1d-f7cd-49a4-8cff-d44aeb76a1ad@googlegroups.com> <78103a2f-5d19-4378-b211-1917175d5694@googlegroups.com> <3p6p8k0yfly7.ctazdw7fc5so$.dlg@40tude.net> <1jtvzi1v65aqm.1k5ejsveno59f.dlg@40tude.net> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Is this expected behavior or not From: Shark8 Cc: mailbox@dmitry-kazakov.de Injection-Date: Sat, 16 Mar 2013 21:51:58 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2013-03-16T14:51:58-07:00 List-Id: On Saturday, March 16, 2013 11:36:57 AM UTC-6, Dmitry A. Kazakov wrote: > On Sat, 16 Mar 2013 09:55:53 -0700 (PDT), Shark8 wrote: >=20 > > On Saturday, March 16, 2013 1:41:27 AM UTC-6, Dmitry A. Kazakov wrote: > >>=20 > >> Thus either subtypes will have same representation or you > >> won't have a class. > >=20 >=20 > > I'm thinking of it more in the terms of generic operations: independent= of > > representation. >=20 > Generics are useless for strings [and almost anything else].=20 I would disagree with that -- generics are quite useful; in the year that I= was professionally programming PHP I found myself *constantly* wishing for= generics (and packages, and [to a lesser extent] real records). I think it's rather a shame that the compile-time computation aspect of gen= erics is not emphasized a bit more -- I've got an idea for exploiting this = property for planetary-orbit simulation. -- but then there are a *LOT* of t= hings in Ada that don't get enough emphasis. (A language-level time type [&= duration] is such that it obliterates an entire 'section' of Jon Skeet's t= alk http://vimeo.com/7403673 on common programming errors/difficulties.) > Without class-wide objects you need a set of instances for each combinati= on of > encoding/character/index. No better than present mess. I think it's not impossible to unify at least some of that -- Index, for ex= ample, is always Positive. -- I don't disagree that stings are a difficult = subject, but that doesn't mean that there aren't some elegant solutions tha= t might be applied to the problem. {Encoding might not be that difficult, w= e already have the character-map construct, we might be able to have an "en= coding-map" which would allow us to translate freely between different enco= dings.} > >> Another problem is that string types must have more=20 > >> than one interface to deal with UTF-8 etc. An UTF-8 string is *both* a= n > >> array of Wide_Wide_Character (=3D Unicode code points) and an array or > >> sequence of Character (octets). That might be less of a problem than you might think; the 'Read and 'Write = should handle the Octet-view while the type as-defined handles the Array-of= -[[Wide_]Wide_]Character view. > > Ah, things get tricky here; Unicode is kind of a bear when you consider > > 'characters' because its codepoints aren't necessarily characters. >=20 > Yes, code points are glyphs. Not all -- Unicode, bing backward-compatible w/ ASCII must have control-cha= racters, which contradict that statement. But even disregarding those, ther= e are characters such as the "zero-width non-joiner". (see http://msmvps.c= om/blogs/jon_skeet/archive/2009/11/02/omg-ponies-aka-humanity-epic-fail.asp= x ) > > An > > example would be the so-called "combining characters" which you can use > > for things like accents or ZALGO-text. (See these, respectively: >=20 > > http://en.wikipedia.org/wiki/Combining_character and, http://eeemo.net/= ) >=20 > It is important for rendering only, if anybody uses it. Nope, see above for the zero-width non-joiner. > > It would be a big mistake to assume character =3D code-point when deali= ng > > with Unicode. > [...] >=20 > Rules according to which two texts are considered equivalent can be > infinitely complex. You cannot do that on the basis of per character > comparison. Character =3D glyph =3D code point is good enough for most > applications. > > I guess what I'm trying to say is that if we did it right, we could > > modify/expand the type-system so that something like UNIVERSAL_INTEGER > > could be made/explicitly-specified. >=20 > Arrays must have interfaces. Array interface should vary along the index > and element "axes" forming a class. Any type should have a class. It shou= ld > be possible to drop implementation upon inheritance composing operations > with type conversion. That is basically all. It would be fully backward > compatible. Actual problems lie elsewhere [MD, parallel type hierarchies]= . Parallel type hierarchies are probably the way address GUI -- you could hav= e one for the graphical side and one for the data-side -- but I'm fairly im= pressed with the way Delphi handled it with the VCL. {Yes there are some wa= rts, but that system works very well in-practice; indeed the C#/.NET compon= ents/events is a near-direct plagiarism [though w/ worse event-names, IMO]}= . > > In any case; I think it worth considering not just outward/downward > > expansion of the language, but inward/upward [unification] as well. >=20 > Welcome in the club. But in order to be able to weight proposals you need= a > more or less formal framework to describe language type system. Already > this little faces a fierce opposition. So don't expect much. This is likely to be true -- but I think the reward for doing so would outw= eigh the costs. {Especially if we could unify strings s.t. the [[Wide_]Wide= _]Character packages are merely 'instantiations' of an "abstract string."}