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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,1a52c822fc0dbb23 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Rational for not making cursor tagged in Containers Date: Sat, 21 Apr 2007 00:33:12 -0500 Organization: Jacob's private Usenet server Message-ID: References: <1176998738.656903.141250@q75g2000hsh.googlegroups.com> <1177010938.200523.325290@p77g2000hsh.googlegroups.com> <1a8y2vakorfhx.225uqh4hifpd$.dlg@40tude.net> <1xmzi7newnilp.23m3zze8h9yi.dlg@40tude.net> <1177066583.5876.30.camel@localhost.localdomain> <1177080147.5876.87.camel@localhost.localdomain> <1q1kx2jlcvnuj.ck0711mj4few$.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1177133477 11990 69.95.181.76 (21 Apr 2007 05:31:17 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sat, 21 Apr 2007 05:31:17 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Path: g2news1.google.com!news4.google.com!proxad.net!feed.ac-versailles.fr!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail Xref: g2news1.google.com comp.lang.ada:15185 Date: 2007-04-21T00:33:12-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:desawg9du795$.1nlp3h75ktl4a.dlg@40tude.net... > On Fri, 20 Apr 2007 15:11:53 -0500, Randy Brukardt wrote: > > > "Dmitry A. Kazakov" wrote in message > > news:1q1kx2jlcvnuj.ck0711mj4few$.dlg@40tude.net... > > ... > >> Also I fail to understand why polymorphic objects has to be records > >> and not arrays or access types. Why array or number cannot have > >> discriminants, but records can? > > > > This ones easy. There is a fundamental difference between elementary types > > (which can represent only one value) and composite types (which can contain > > multiple values). Adding discriminants to an elementary type would turn it > > into a composite type -- and that way lies madness. > > That's because you consider discriminant as a component. But why? > Discriminant is a constraint / parameter of a value. It is associated with > the value but is not necessarily a part of it. That way lies madness. You could have the same value yet they wouldn't pass the checks because this stuff that isn't part of the value doesn't match. That's very different than a range constraint, for instance, which is outside the value, but it doesn't change the checking of the value. That is, values don't have constraints. > Examples of discriminated scalar types: > > 1. type Ring_Buffer_Index (Size : Positive) is mod Size; > > 2. type Bounded_Integer (Min : Integer; Max : Integer) is range Min..Max; These would be possible in Ada (as records) if there wasn't a rule specifically forbidding it. And the reason for the rule is simply that there isn't any real value to these sorts of constructs. even if there was, though, mapping them as records, assuming a decent way to handle literals. No reason to treat them as elementary. > 3. type Dimensioned (Dimension : Unit) is digits 8 range -100.0..100.0; Same here. > 4. type C_String (Length : Positive) is > access all Interfaces.C.chars_array (1..Length); > > Note the target is a flat array! > > 5. type Checked_Access (Not_Null : Boolean) is > access not null (Not_Null) of Something; All constrained access types are madness. It isn't possible to make any useful meaning out of them, and they cause an infinite number of definitional problems. Ada shouldn't have ever had them (we've essentially made them illegal for general access types, but we can't do anything about the Ada 83 ones). In any case, *my* language would de-emphisize access types as much as possible. No anonymous ones; probably structural matching (so the named ones would work a lot like the anonymous ones of Ada); in out parameters serve the purpose better anyway. They'd be second-class citizens to discourage their use by anyone other than people implementing containers... ... > Counter examples: > > 1. polymorphic access types (for smart pointers, interators, cursors) No anything for access types; they should be made so hard to use that it's almost unthinkable to do so. All of the things you mention are ADTs, implemented by controlled records. (Dereference would also be a possible redefinable record operation, of course.) Yes, you'll occassionally need access types to implement ADTs, but never, ever visibly in a spec. > 2, extensible enumeration types We tried to work this out, and it simply doesn't work. Operations like ordering simply aren't extensible in a useful way. > 3. polymorphic numeric types (mixed arithmetic implementations, > computations with mixed numeric representations) Maybe, but I'm dubious. Again, I think it would be better to have better ADTs that could replace a numeric type. ... > > So, I guess the ideal language would be one in which everything was a > > controlled record type. (For Janus/Ada, that's already true in many cases: a > > protected type is just a special controlled record type; task objects are > > essentially controlled, unconstrained arrays are really records that contain > > bounds and a data pointer, etc.) But such a language would be pretty > > space-inefficient (you could optimize individual calls to avoid dispatching, > > but there is no way to eliminate the space overhead, because you can never > > tell what might be done in some separately compiled unit.) > > This is a consequence of IMO a wrong view on what discriminant (or tag) is. > If you consider them as components, you indeed land in the pitfall you > described above. But if discriminant is just an attribute of a value > forcibly removed when known static, then there is no any space loss. These are almost never known to be static (consider parameter passing). What you're suggesting *might* be possible to describe, but it wouldn't be possible to implement. If the parameter passing code in Janus/Ada got any more complex, it could never be made to work (it might already be at that point - there's over 2500 lines of code for that alone). > The values of statically constrained / specific types will have no > discriminants / tags. Dynamically constrained / polymorphic values will > have it, just as dynamically constrained strings have a dope. Only the > [by-reference] types with the reserved words tagged or limited will have > discriminants and the tag among them stored the value. I think it is a > doable program. Maybe, but only if you're successful in getting rid of generics and most of the other special cases (like "view conversions"). Otherwise, it is just too complex to implement. And if you do get rid of generics, I think you'll find that nothing significant is ever known to be static. Randy.