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!out03b.usenetserver.com!news.usenetserver.com!in01.usenetserver.com!news.usenetserver.com!news.tele.dk!news.tele.dk!small.news.tele.dk!news-fra1.dfn.de!newsfeed.ision.net!newsfeed2.easynews.net!ision!newsfeed.arcor.de!newsspool4.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> <15dj4pbkifj9c$.1g4y21vyx4j4d$.dlg@40tude.net> Date: Sun, 22 Apr 2007 10:38:35 +0200 Message-ID: <1q5s2gqbzhatf$.2xu8gdz4hxm8$.dlg@40tude.net> NNTP-Posting-Date: 22 Apr 2007 10:38:35 CEST NNTP-Posting-Host: d14fa79a.newsspool3.arcor-online.net X-Trace: DXC=NIWa=BcUa`n016@cHD@m;jMcF=Q^Z^V3h4Fo<]lROoRaFl8W>\BH3Yb7Ec9Imkc`hoDNcfSJ;bb[eIRnRBaCd On Sat, 21 Apr 2007 23:28:34 -0500, Randy Brukardt wrote: > "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. So how are you going to check the discriminant once, provided that the value shall determine the validity? My point is that there are two values of different types we are talking about, one with and another without the discriminant. >> 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. Where is any problem? If the discriminant is statically determinable I can reconstruct it at the call point, create a dynamically constrained object [which is not necessarily contiguous in the memory] and pass it. If the discriminant is indeterminable, then I must already have a dynamically constrained object to pass. >>> 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. No, that depends on the type of "ABC". What is "ABC"'First? There is no logical way to derive it from the value otherwise than voluntarily set it at some arbitrary value, like 1. > ... >> 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. Neither I can do it with the latter. There is an operation which extracts bits from the value. This operation has the parameter of some other type and the result of third. I could define such operation on the former or disallow it on the latter making the type private. Would that change its elementariness? Just per view? Wouldn't F'Exponent make F non-elementary? What about Boolean xor? May I claim that xor extracts a component of its first Boolean argument in some Platonic universe? It just makes no sense to me. >> 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. Yes, I meant that nothing would change for the types which presently have no discriminants, if we allowed but not used them. > 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. 'Class is a difficult case. And a general question regarding it is, should it be possible to have it "hyper-dispatching"? [sorry, for inventing new terms on the fly]? I mean T'Class'Class. If yes, then we will have different levels of tags. Another question is whether "multiple-polymorphic" things were allowed. Here I mean multiple of tags at the same level: T'Class(1), T'Class(2) etc. I think these questions have to be answered in order to build a sane OO types system. What I do believe is that this system could be uniformly expressed in terms discriminants and impose no *any* penalty on computing with specific types. > 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!) Yes, T'Class always has the tag (which is not necessarily dynamic). >>>> 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... It is not obvious to me. I guess that "type X is new Y with private" is where it should stop. Certainly, I don't want to try to express the types constraints in formal generic parameters. It would be a Sisyphean task worth of nothing. > 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). Certainly, but I guess that shared generic bodies have to "dispatch" to the actual "with procedure" as well. In the end it should turn equivalent, because, there is no implicit re-dispatch in Ada. If the class-wide bodies are inlined, then in comparable cases the tags will be known and all dispatching calls within them will be resolved statically. The rest would be space overhead for storing tags. Now, if the callee are inlined as well and type involved is not by-reference, then the compiler can remove call T -> T'Class -> T conversions, it would otherwise generate. That would mean no any overhead. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de