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=unavailable autolearn_force=no version=3.4.4 Path: border1.nntp.ams3.giganews.com!border2.nntp.ams3.giganews.com!border2.nntp.ams2.giganews.com!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!nntp.giganews.com!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.fsmpi.rwth-aachen.de!reality.xs3.de!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Is this expected behavior or not Date: Wed, 27 Mar 2013 14:42:47 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <78103a2f-5d19-4378-b211-1917175d5694@googlegroups.com> <3p6p8k0yfly7.ctazdw7fc5so$.dlg@40tude.net> <1jtvzi1v65aqm.1k5ejsveno59f.dlg@40tude.net> <1hvv2kd9smnfx.6spgz9thd1mh$.dlg@40tude.net> <1raubw1sk48ca$.69rdgczvnnf.dlg@40tude.net> <2qwq2cdeuvhu$.qtnb8zyhuob9$.dlg@40tude.net> <1u72u7h5j4jg3$.wlxmaltyzqik.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1364413379 18142 69.95.181.76 (27 Mar 2013 19:42:59 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 27 Mar 2013 19:42:59 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Original-Bytes: 12108 Xref: number.nntp.dca.giganews.com comp.lang.ada:180815 Date: 2013-03-27T14:42:47-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:wdlyfbnwcnp7.10c9btwjmpm7j.dlg@40tude.net... > On Tue, 26 Mar 2013 16:31:35 -0500, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" wrote in message >> news:1u72u7h5j4jg3$.wlxmaltyzqik.dlg@40tude.net... >>> On Mon, 25 Mar 2013 17:58:26 -0500, Randy Brukardt wrote: >>> >>>> "Dmitry A. Kazakov" wrote in message >>>> news:a96esjwiniqy$.op3wh7x9wrsl.dlg@40tude.net... >>>>> On Fri, 22 Mar 2013 21:33:02 -0500, Randy Brukardt wrote: >>>> ... >>>>>> That doesn't necessarily mean copying of the data. If the designer >>>>>> of the abstraction, have put in enough smarts to share >>>>>> representations -- >>>>>> after all, >>>>> >>>>> You should break your mental block. No shared representation, I want >>>>> different representations for different string types. >>>> >>>> I was talking about sharing representations of *different* objects of >>>> the >>>> same string type (for instance, a string variable and a slice of that >>>> variable - that case, sharing the data might be preferred to copying >>>> it). >>> >>> OK, the representation would be for type-specific string objects: >>> >>> bounds + pointer >>> >>> and for class-wide string objects: >>> >>> tag + bounds + pointer >> >> Sure, but irrelevant. The question is whether slicing copies the data or >> not. If it is a new object, the data must be copied logically, > > No, logically it is a referential object. > >> but my point >> was that it would be possible for an abstraction to defer actually making >> a >> copy until an assignment is actually done. It's still a copy. > > Exactly the reverse, an implementation could be allowed to use a copy if > that is consistent with the semantics of the slice being a reference. > > But regardless of the semantics, why this representation should not work? The problem is that a slice ought to be a referential object as you put it, and a "regular" object is definitely *not* a referential object (a copy copies the data). I don't see any way for a single data type to have two different behaviors - as you've argued elsewhere, you can't have a single operation doing two different things. I suppose you could make a slice be a different type than a regular string object, but then you have problems with type matching (you want a slice to be compatible with the equivalent normal object). ... >>>> And dispatching is incompatible with untagged types, simply because Ada >>>> 83 got inheritance horribly wrong, and we're stuck with that. >>> >>> I disagree. It seems fully compatible with Ada 83 because T'Class would >>> be >>> a distinct type with objects of that type. It is orthogonal to >>> Ada-subtypes. You will not dispatch on Positive vs. Integer, these will >>> reman specific [sub]types. In order to dispatch you will need a >>> class-wide >>> object of the type Integer'Class (which will be strictly same as >>> Positive'Class, except, possibly, the constraint). That object will have >>> the representation tag + value. For Integer and Positive objects nothing >>> changes. We might consider redefining some existing operations to become >>> class-wide in some arguments, but that is another story. >> >> You missed the point altogether. You can't dispatch in general on >> untagged >> types because overriding operations may have different modes and subtypes >> for the parameters. So what *is* the profile of the operation for >> T'Class, >> and how can it work? >> >> Consider: >> >> Type Int is range 1 .. 10; >> procedure Op (A, B : in Int); >> >> Type Der is new Int; > > This is not derivation within the class, it is a "type-cloning." Type > cloning creates a new class and new a type (all types up the hierarchy). > We > need some syntax to indicate the difference. > > type Der is new Int ; > > It is unfortunate that tagged types reused "is new" for a purpose > completely different from type cloning. Nobody wants "type cloning". We waste a lot of mental energy getting rid of it in generics, for example. I have no idea why anyone that wants 'Class would want to avoid maximizing the interoperability of types. The original motivating example for Integer'Class was: Put (Obj : Integer'Class; Width : Count := 0); so that one didn't need to understand generic instantiations just to do simple I/O of strongly typed entities. I don't think a version of untagged'Class that did not work on existing derived types would fly. For no other reason than the fact that it would make tagged and untagged types more different, rather than less different. In any case, I didn't realize that you were making an entire new kind of type derivation - I wouldn't have guessed that someone that has been talking repeatedly about simplifying the language would add an entirely new kind of type to the language. > Moreover, it is highly desired to that cloning were available for tagged > types as well: > > package Original is new Ada.Containers.Vectors ...; > type Clone is new Original.Vector; -- Cloning, not extending! > > Now, I have to hierarchies of Vector, not very useful in this particular > case, because of missing helper types, but anyway. Pointless complication. I thought you were trying to simplify the language! >> overriding >> procedure Op (A : in out Der; B : in Der); > > This is not an overriding since the mode is different. It *is* an overriding in Ada 83, and it still is in Ada 2012. I agree that it should not have been, but that is irrelevant because we're stuck with it. >> Obj : Int'Class := Der'(1); >> Op (A => 1, B => Obj); -- Legal?? > > MD is not fully implemented in Ada, but anyway, presuming that Op is a > multi-method, that the mode is "in" and that 1 is Universal_Integer (is > it?), the above is illegal because Op is not a method of > Universal_Integer'Class. You would have to write it as: > > Op (A => Der'(1), B => Obj); -- Same tags > Op (A => Int'(1), B => Obj); -- Different tags, Constraint_Error This seems wrong; an integer literal usually gets its type from context. It's only a value of type Universal_Integer if there is no type given from context (as in a type conversion or number declaration). I was presuming that integer literals act as tag-indeterminate functions (the most sensible model; if you have constants for a tagged type you usually would model them as tag-indeterminate functions - for instance, the constants Zero and One in a universal arithmetic package), you don't need multiple dispatch: the Ada dispatching rules simply calls the correct version of the function for the tag of the object. And that's what we would want to happen for integer literals (that's the closest analogy to what happens for existing expressions). > Multi-methods (a special case of MD) is another and long story. They > should > be properly supported in the end. > >> And if you say that Der cannot override Op this way, you're now >> incompatible >> with Ada 83- Ada 2012. > > I want to preserve and extend type-cloning. And you claim that the ARG keeps building gazebos. You're building a lakeside floating pavillion. ;-) ... >> An interface can't have "..." as the parameter type for Write; there has >> to >> be something there. > > procedure Write (File : in out File_Access; Data : Stream_Element_Array) > is abstract; > >> And that's the target type! Say again how it is that you >> are not exposing this type?? > > The target is File. I would gladly have MD and a hierarchy for the second > parameter, but that is another story for now. OK, if the target is File, then you know that - that's public information. When you dereference a File_Handle, you get a File. You don't have to make the contents of File public, just it's name. So I still don't see why you think this is a problem. >>>>>> That's my point about static analysis. Such a tool should be able to >>>>>> prove >>>>>> that the majority of run-time checks can't happen, and give you a >>>>>> list of >>>>>> those remaining. >>>>> >>>>> I don't need any list. Should I send it to my customers? I need the >>>>> program fail to compile when writing analogue input. >>>> >>>> Treat the list as failures if you must, and insist that it be empty >>>> before shipping. >>> >>> So, I need an AI system to parse compiler messages (of various vendors) >>> on >>> top? >> >> Huh? Why would you "parse" them? > > Because whether a message is relevant to the choice if the program were OK > to deploy depends now on the message content. The language does not help > me > anymore to indicate it as a bug. But there is absolutely nothing new about this. GNAT has a variety of warnings (calling everything it displays a "warning" in order to avoid arguments about its particular classifications of message), but most people choose to treat some subset of them as errors that have to be removed before deployment. You would do that same; choose a *class* of warnings that have to be removed; there is no parsing of messages needed. If a warning in the prohibited class exists, the program is not ready for deployment. Yes, this means you need to develop a coding standard and a development standard to ensure that these these things are followed. But not having those in some form is just lousy programming management. And one thing we decided on the ARG long ago is that there is no way that a programming language can prevent lousy programming management -- any language can be misused without much effort. That cannot be prevented by a programming language; it's futile to try, and when you do try, you tend to make the language harder to use on real problems. So we assume competent management is used with Ada; we're not trying to make the language idiot-proof. Randy.