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: a07f3367d7,73cb216d191f0fef X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.24.132 with SMTP id u4mr3473624wif.6.1364938762736; Tue, 02 Apr 2013 14:39:22 -0700 (PDT) MIME-Version: 1.0 Path: ex12ni19333wid.1!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!194.109.133.83.MISMATCH!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!news.bbs-scene.org!weretis.net!feeder4.news.weretis.net!news.on-luebeck.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: Thu, 28 Mar 2013 16:55:34 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <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 1364507747 9822 69.95.181.76 (28 Mar 2013 21:55:47 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 28 Mar 2013 21:55:47 +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 Date: 2013-03-28T16:55:34-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:cqf0yy6q930$.1sdzw45bc0c1w.dlg@40tude.net... > On Wed, 27 Mar 2013 14:42:47 -0500, Randy Brukardt wrote: > >> 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). > > What is "regular" object here? String? A non-slice string object. >> I don't see any way for a single data type to have two >> different behaviors > > These are two data types, string and slice. Are you treating slice as an > Ada-subtype of string? I consider slice a member of same class as string, > yet a distinct type (in Ada sense). This is like 4.1.5, but in the same > type hierarchy. I thought you might do that, but then you're going to have problems of compatibility (Ada currently considers them the same type). An operation like "&" cannot not allow mixed string operands (if you do allow that, you make string literals ambiguous). ... >> Nobody wants "type cloning". > > It is a very useful building block to me. Anyway it is Ada 83 legacy. Ada 83 derived types are virtually useless, and no one understood how they worked. I objected to building tagged types on that foundation during Ada 9x, but they didn't pay any attention to me on that. :-) Ada 83 derived types would be one of the first things to get rid of in a new Ada-like language -- everything should be related. Indeed, all integer types belong to Root_Integer'Class (you just can't name that type in Ada as it stands); it would be weird to *break* that. ... >> I don't think a version of untagged'Class that did not work on existing >> derived types would fly. > > Astonishing that you even considered that possibility. In my view they are > completely independent things. You really have a strange mind. The whole idea of 'Class is to allow different but related types to share implementations. You're only allowed to convert between related types, which includes derived types. >> In any case, I didn't realize that you were making an entire new kind of >> type derivation > > To me it is exactly same as tagged extension when you add nothing to the > existing representation. Sure, this I totally agree with. But those are highly related to each other: Parent'Class includes the parent and the derivation. > We also need "extension" that drops parent's representation altogether. > E.g. something like: > > type Character is new Unsigned_8 -- or enumeration, whatever > and Wide_Wide_Character'Interface; > > Character is member of Wide_Wide_Character'Class with a representation > different from Wide_Wide_Character. I don't think that would work semantically, at least in the 'Class case. Unless you expect every operation down to assigning individual components to be dispatching, even in primitive routines defined for a specific type. That's because you can't copy all tagged types (we have to have limited types), and thus calling a parent operation would have to assume that extensions have a different representation. That would both have problems of re-dispatch and simply would be awfully expensive (you'd have to do full program compilation to have any hope of decent code). The only alternative would be to totally ban implementation inheritance on such types, but as implementation inheritance is 10 times more useful than interface inheritance, it would make the construct 95% useless. >>> 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! > > Making it regular is a simplification. This isn't regular. All numeric types are currently members of a single hierarchy, and in practice, the vast majority of tagged types are members of two hierarchies (controlled and limited controlled). If I was going to simplify this further, I would make all of these into a single hierarchy. More hierarchies don't buy anything (you can always move your 'Classes around in the hierarchy to get subsets). >>>> 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. > > Only when Der is derived using Ada 83 construct. Int'Class will be built > using "extension." No way; derived types currently form a hierarchy (that's why you can interconvert them); changing that would require fundamentally changing the Ada model of hierarchies. The issue today is that you can't name those hierarchies, that's what untagged 'Class would allow. >>>> 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). > > This is one of possible interpretations of Ada semantics. You consider > literals primitive operations, e.g. > > function "1" return Int; > > In Ada 95 such function has to be overridden, when Der extends Int. > However, if the representation is inherited and not changed, the rule > could > be that the compiler silently overrides all literals: > > overriding function "1" return Der; > > In this case you will have 1 overloaded. Op will become ambiguous. Yes, this is how Ada literals work today. This isn't how its described (it's an implicit conversion rather than overloading) but the effect is the same. > The alternative with different types can be discarded using some > preference > rules, e.g. domination, and thus ambiguity resolved. Preference rules cause Beaujolias effects, and almost never can be tolerated. Ada used to have some for literals and they caused all manner of problems. The preference rules for universal causes problems as well (as you are pointing out here); these are extremely fragile and only work because universal types can't have any user-defined operations or visibility changes. As soon as user-defined things are involved, preference rules simply don't work. Maybe they would work in a language without nesting and private parts and use clauses, but they don't work in Ada. (The problem being that adding or removing a single declaration can silently change the meaning of an expression without causing an error. This is considered intolerable.) >>>> 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. > > I don't want to expose File at all. Public views should have no access to > it, otherwise than indirectly through the handle. E.g. they should not be > able to get an access the file object, store it somewhere, deallocate it, > use stream attributes on it, and perform any other fancy stuff. > Furthermore, later on, a decision may fall to replace file descriptor with > something completely different keeping code that uses handles intact. It > is > good old information hiding principle. Fine. But then you don't need any user-visible dereferencing, and you surely wouldn't use it. My contention remains: if you are going to allow user "Handle.all", then you need to expose the type of Handle.all. If you don't need to allow that, then you are not going to use 4.1.5 at all. So I fail to see your concern. >>> 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. > > There is nothing new that people die, yet nobody actually likes it. > >> 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. > > Some C compilers give warning when you write: > > if (x = 1) ... > >> 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. > > Error checks do not belong to coding standards. Coding standard, and > testing, and code review etc are there when compiler checks were > impossible. Compiler checks are impossible for these things. Unless you want to drive yourself nuts with OOP baloney - and it's never going to be possible to do these sorts of checks with type checking. (This is not a type problem, it's a subtype (in the Ada sense) problem.) Feel free to pick your poison, as it will, but expecting types to do all of the work is just as silly as expecting that you can make a correct program with defining any types at all. Randy.