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 Path: g2news1.google.com!news3.google.com!feeder3.cambrium.nl!feeder5.cambrium.nl!feeder2.cambrium.nl!feed.tweaknews.nl!193.201.147.79.MISMATCH!transit4.hitnews.eu!news.taunusstein.net!open-news-network.org!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Rational for not making cursor tagged in Containers Date: Sat, 21 Apr 2007 23:28:34 -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> <15dj4pbkifj9c$.1g4y21vyx4j4d$.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1177216000 21682 69.95.181.76 (22 Apr 2007 04:26:40 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sun, 22 Apr 2007 04:26:40 +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 Xref: g2news1.google.com comp.lang.ada:15210 Date: 2007-04-21T23:28:34-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:15dj4pbkifj9c$.1g4y21vyx4j4d$.dlg@40tude.net... > On Sat, 21 Apr 2007 00:33:12 -0500, Randy Brukardt wrote: > > > "Dmitry A. Kazakov" wrote in message ... > >> 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. > > Sure, example: access discriminants of task types. Huh? Two tasks never have the same value. > It is not madness, it is the same difference like between class-wide and > specific. These are different though mutually compatible [sub]types. A > dynamically constrained value has discriminants, a statically constrained > value does not have the discriminants whose values are statically known. > Even if these are still kept in the value bit pattern. Known discriminants > are undeterminable from constrained values [for sanity reasons]. Huh again? You have to know the discriminants, or you couldn't pass them to an unconstrained (or, if you prefer, 'Class) parameter. > > 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. > > The values are not same, String is not String (1..80). String is a type, not a value. String(1..80) is a subtype, not value. "ABC" is a value and that value includes its bounds. ... > Hmm, what is the difference between elementary and non-elementary? In which > way mod 256 is more elementary than array (Positive range 1..8) of Boolean? One is a single value, the other is a set of values. You can do math on the former to extract bits, but you can't get at them directly. Surely, you could design a language with only kind of type (a super-record). But it would be highly inefficient; there'd be a few special cases that could be fast, but they wouldn't happen that much. > To me the only difference is built-in vs. user-defined, which vanishes in > absence of visibility on the private declarations. ... > > ... > >>> 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). > > Because presently discriminants are not allowed, so, I presume, they are > all static. I.e. it definitely works! (:-)) Discriminants are not allowed where? I was talking about where they are allowed; if you extend them to be allowed everywhere. Of course, a compiler could special case no possible discriminants (I think it would have to, adding a complexity). But if you allow adding them to extensions (and it seems you should), then not 'Class ever is known to not have discriminants. So they're almost always dynamic, and they have to almost always be part of the value. (And there are a lot more uses of 'Class in your universe without generics!) > > 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). > > Just 2500? (:-)) Parameter passing is one of the easiest (conceptually) things that a compiler has to do. It's just evaluate and push. For that to get that complex is outrageous. (Yes, our shared generics are a major culprit.) > >> 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 > > If no new formal generic types will be introduced, then I don't see it as a > big deal. Possibly generics will never be get right, but that is not > because of discriminants. (:-)) If you do shared generics as we do, generics essentially double the work for everything. You idea would multiply it by 4 again. I think that's beyond my ability to imagine... ... > > 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. > > Generics is a sufficiently different thing. The constraint is put on the > compilation unit like package and then it propagates to the declarations of > the unit. The closest approximation is derivation, which puts tag > constraint on a class-wide. It would be interesting to analyse some > large-scale Ada code. I guess that less than 10% of all calls with tagged > arguments would be dispatching. I.e. 90% is static. It might even be less than that. But I was referring to your previous comments on how lousy generics are in a general way. I was presuming that your ideal language would not have them. But then you'd have to have a lot of operations on 'Class (to get a polymorphic Put, for one example). In which case there would be far more dispatching calls than in Ada (we tend to use generics rather than inheritance, I think). Randy.