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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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!news4.google.com!out03a.usenetserver.com!news.usenetserver.com!in01.usenetserver.com!news.usenetserver.com!news.tele.dk!news.tele.dk!small.news.tele.dk!newsgate.cistron.nl!xs4all!news2.euro.net!newsfeed.freenet.de!news.teledata-fn.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Rational for not making cursor tagged in Containers Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH 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> Date: Sat, 21 Apr 2007 11:39:17 +0200 Message-ID: <15dj4pbkifj9c$.1g4y21vyx4j4d$.dlg@40tude.net> NNTP-Posting-Date: 21 Apr 2007 11:38:05 CEST NNTP-Posting-Host: a4a82991.newsspool2.arcor-online.net X-Trace: DXC=D0ZOE^cAZOL@Y=h<_c3PkHA9EHlD;3YcB4Fo<]lROoRA8kF On Sat, 21 Apr 2007 00:33:12 -0500, Randy Brukardt wrote: > "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. Sure, example: access discriminants of task types. 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]. > 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). >> 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. If Ring_Buffer_Index (being privately a record) can be used as an array index then it is just fine to me. > No reason to treat them as elementary. 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? To me the only difference is built-in vs. user-defined, which vanishes in absence of visibility on the private declarations. >> 3. type Dimensioned (Dimension : Unit) is digits 8 range -100.0..100.0; > > Same here. But it is the only way to have dimensioned values in a usable way. >> 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. [...] > ... >> 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. Then we are in full agreement. All access types above are just abbreviations for the [record, whatever] types implementing access interface. This implementation does not bother me, as long as I can ensure its efficiency. What I want is a uniform way to hang a constraint on anything regardless on where that thing will be used. No special treatment to any interface. >> 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. You mean 'Succ? That should depend on covariance/contravariance of the arguments and the result. If you consider constrained and unconstrained values as same, then I bet there is no solution. The compiler shall know the difference when an enumeration value appears in a case-statement. >> 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. Full agreement as above. > ... >>> 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! (:-)) > 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? (:-)) >> 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. (:-)) > and most of > the other special cases (like "view conversions"). No view conversions for non-by-reference types, a new object will be created instead. > 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de