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: Mon, 23 Apr 2007 18:26:39 -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> <1q5s2gqbzhatf$.2xu8gdz4hxm8$.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1177370685 5185 69.95.181.76 (23 Apr 2007 23:24:45 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 23 Apr 2007 23:24:45 +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!news3.google.com!proxad.net!exabot.com!feed.ac-versailles.fr!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail Xref: g2news1.google.com comp.lang.ada:15245 Date: 2007-04-23T18:26:39-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:1q5s2gqbzhatf$.2xu8gdz4hxm8$.dlg@40tude.net... > 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. I'm sorry, but I have no idea of what you are talking about at this point. I think our discussion has gotten two abstract, and precisely what is being proposed is no longer obvious... > >> 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. You said "Known discriminants are undeterminable from constrained values [for sanity reasons]." So where else do they come from? The type of the value contains no information (they're always unconstrained); the subtype can be changed trivially (so you can't depend on it). > >>> 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. No, I meant that a value is a set of components and bounds, "ABC" is (almost) the closest thing that you can write. A literal is not a value, either. There is no notation for a value! Every value has bounds/discriminants; where they come from is part of the language definition. Assuming them is just fine, or specifying them, or consulting an oracle... > > ... > >> 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? No, of course not. But we're not talking about user-defined operations, we're talking about what is available by default. > Just per view? Wouldn't F'Exponent make F non-elementary? You're probably right; but of course Float types follow no sane model so I don't care much about them. You can't design anything sensible if you worry about them. Just bolt 'em on to whatever model you're using and continue. ;-) > 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. You could argue anything, but doing so doesn't make it sensible. > >> 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. OK. But your premise is not really true; the compiler complexity would jump dramatically, and thus the number of bugs in the compiler would jump as well. Similarly, the language definition would almost certainly be written for types with discriminants; the rules for the no discriminant case would no longer exist separately, and thus they would be subtly different. > > 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. Maybe. I'm not so sure. But in the absense of a real attempt to do so, who can tell? > > 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 original object's tag might not be dynamic, and might be possible to be omitted (even if it is logically present). But once you pass it to T'Class, you have to include the tag dynamically, because it can be anything. (Well, unless you are engaging in full-program optimization. But that's not practical in real systems today; anything added on the fly destroys full-program optimization.) > >>>> 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. Your scheme boils down to having a very general type system for which the compiler recognizes and special cases any combination of things where it can be done better (that is, discriminants can be omitted, tags can be omitted, by-reference parameter passing should be turned to by-value, etc.) There would be no syntaxtic "clues" as to when such optimizations could be done; there could be nothing consistent about the representation of types. Very little about how to build compilers as I know it could be used. Perhaps, if you are starting with a completely blank page with really brilliant people, it could be done more cheaply than I could. But then the problems inherient in starting from scratch would occur: lots of bugs, especially coming from places where the rules don't fit the design. > > 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. That's my point; it is farily equivalent. And there is essentially nothing static in our generic bodies. I don't see how you could avoid that in a "unified" language. > 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. Very little can be practically inlined: either very short routines or routines that are only called once (and the latter requires full-program optimization, which is problematic as noted earlier). Anything else will cause an explosion in code size. Thus, talking about what could happen when something is inlined is irrelevant -- of course inlined code will be better than non-inlined code, but the bulk of a program will not be inlined. Similar, any *as if* optimizations are always fair game for a compiler, but they're irrelevant when evaluating the semantics of the usual case. You can't assume that optimizations are going happen - often they're only applicable in trivial cases that rarely occur. Randy.