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: a07f3367d7,73cb216d191f0fef X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.224.157.1 with SMTP id z1mr3487116qaw.8.1365342197324; Sun, 07 Apr 2013 06:43:17 -0700 (PDT) Path: ef9ni11076qab.0!nntp.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!xlned.com!feeder7.xlned.com!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!news.n-ix.net!news.bawue.net!storethat.news.telefonica.de!telefonica.de!weretis.net!feeder4.news.weretis.net!news.mixmin.net!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Is this expected behavior or not Date: Tue, 2 Apr 2013 10:44:07 +0200 Organization: cbb software GmbH Message-ID: <3gv2jwc95otm.pl2aahsh9ox8.dlg@40tude.net> References: <1raubw1sk48ca$.69rdgczvnnf.dlg@40tude.net> <2qwq2cdeuvhu$.qtnb8zyhuob9$.dlg@40tude.net> <1u72u7h5j4jg3$.wlxmaltyzqik.dlg@40tude.net> <1gnmajx2fdjju.1bo28xwmzt1nr.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 X-Received-Bytes: 10211 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 2013-04-02T10:44:07+02:00 List-Id: On Mon, 1 Apr 2013 19:40:42 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:1gnmajx2fdjju.1bo28xwmzt1nr.dlg@40tude.net... > .... >> The point is that whether you create a totally new string hierarchy or >> create one for already existing string types, you will have the issue with >> "&" (and any other operation with more than one argument/result of string >> type). That is *independent* on whatever Ada did or not before. It is in >> the nature of a multi-method, which "&" is. If you want a hierarchy of >> strings you *must* face this problem. > > No you don't. There are no language-defined multi-methods. String & String = > String is not a multi-method. Once String becomes member of a class it is. For the operation "&" there exist only two possibilities, Either it is a primitive operation of the class and so a multi-method, or else it is declared individually on each member of the class in separate packages (somewhere after the freezing point). The later variant is so silly that I don't even consider it. > You, the user, can define such operations, of > course, but then you have the deal with the consequences. Generally, it's > best if you don't do that. What is the use of a string type without operations? >>>> The model of Ada 95 tagged types provides a class with shared >>>> representations. This need to be augmented for the case when >>>> representations has to be different. Note that this was partially done when >>>> Java interfaces were added in Ada 2005. Java interface is a type without >>>> any representation, so there is nothing to inherit from, except for a slot >>>> for the type tag. Drop that slot, and you will have a workable model for >>>> building classes of scalar types and arrays. >>> >>> I don't know how one could implement "interfaces" without a tag. >> >> You have the tag in the representation of untagged'Class. You don't have >> it in the representation of untagged. > > Doesn't work, as I've previously explained. You said that it would not fit into Ada 83 derived types model. I answered that it never considered within that model. The model to augment is Ada 95 tagged types. > You have to be able to inherit > implementation of operations, for all types. It is already not so. See Ada 95 abstract primitive operations and operations dispatching in the result. They are NOT inherited. The programmer is asked to override them, because the compiler has no idea how to implement them. > And there exist plenty of Ada > types for which copying is not allowed. No problem. See above. All primitive operation will be inherited abstract if the representation is not inherited and no [user-defined] conversion defined (e.g. for a by-reference type). > The only way to implement those is > via some sort of dispatching, and the need poisons the possibility of > omitting tags, even for "specific" operations. I don't understand where you get this. The model is exactly the model of tagged types, but without specific objects required to keep the tag. The only thing it influences is view conversions between T and T'Class. Nothing else is changed. > The type conversions are view conversions, and they never make copies. View conversions will be kept for tagged types and not introduced for untagged ones. > That > forces the representation to be compatible. You could change that for > by-copy types (although that would have run-time compatibility issues for > controlled objects), Controlled objects are tagged, hence no change here. > but you can't change that for types that have no copy > operation (like tasks and protected objects). So how to do you implement > them? Array of task is an untagged type, too, and it certainly should be > able to use 'Class. Sure. T'Class will be a referential object when T is untagged by-reference type. It will consist of the type tag and a *pointer* to the specific object (not much different from 4.1.5), and from view conversions ether, though formally a new object. When T is by-copy, T'Class is the type tag + a copy of T. >> I don't ban inheritance of the representation. I want to be able not to do >> it when I don't need it, e.g. for character and string types. > > But it's not that easy. If you have an array of tasks: > > type Foo (1 .. 10) of Some_Task with Component_Size => 32; > > and you derive another array of tasks from it: > > type New_Foo is new Foo with Component_Size => 64; > > This is legal, and you have different representations. Irrelevant. Ada 83 derivation (cloning) is orthogonal to Ada 95 extension model. We are talking about the later. >>> It really kills the entire idea. >> >> No, IF String inherited the representation of Wide_Wide_String, THAT would >> kill the idea. >> >> The whole idea is not to inherit irrelevant representations! > > I don't see the problem here; if Root_String is an abstract tagged type, Java interfaces will not work for characters/strings. No need even to try it. >> The bottom line is, I regard Ada 83 construct "type S is new T;" as very >> useful, and wished it be valid with all specific types without silly >> exceptions Ada 95 made for tagged types. > > Fair enough. I regard "type S is new T;" as a junk piece of syntax that was > inherited from Ada 83, and should never be used. We completely disagree on > this one, and there really is nothing worth talking about. > > You previously asked about: > > type Velocity is new Float; > > That would get you a repremand if you worked for me. You never, ever use the > types in Standard (because they're not necessarily portable to other > compilers). You derive types based on your actual application requirements: > > type Velocity is digits 5 range -1.0E+10 .. 1.0E+10; This is a bad design pattern because it refers to some magic numbers spread all over the source code, a huge maintenance problem, potentially. The proper pattern would be: type Measurement is digits 5 range -1.0E+10 .. 1.0E+10; ... type Velocity is new Measurement; type Acceleration is new Measurement; ... >>> Because you need operations that work on every object, >>> copyable or not. Remember, there are no type conversions between types in >>> different hierarchies. >> >> And, this is what different hierarchies are for. > > For what? To make it impossible to pass integers to Text_IO, or to use them > to instantiation Text_IO? It is in the same generic formal class, thus instantiation is possible. You are confusing generic classes, and classes induced by cloning, and classes induced by interface inheritance. They are not same. There is an infinite number of means by which some types could be lumped into a class. Class is no more than a set of types. E.g. all types which declarations start at the source code line 123 is a class. That does not make them possible or not to be used in Text_IO instantiation. That would be some other class. >>>> But they are still the same >>>> hierarchy. You need some fundamental operation which tells that a type >>>> breaks off the hierarchy. >>> >>> Yes, of course all containers ought to be members of the same hierarchy. >>> How else would you create generic algorithms? >> >> Easily. Cloning borrows all operations. Define algorithm on the original >> type. Then clone it. Done! > > But you have cloned nothing. I did types, literals, operations. > Either you have a conversion to the original > type, in which case they belong to the same hierarchy. This is a possible way to implement cloning. This is not the semantics of. The semantics is that there is a new set of types, values and operations with the properties of the original. Nothing more. > A string class with a mixed & is nonsense. (I think the String & Character > in Ada 83 was nonsense, but it's not a problem here.) It would be interesting to learn how many c.l.a. readers share such an extreme view. To me "&" is one of the most important requirements on string class design. It is also a good test for the language type system maturity. > The only & is String & String = String, and so on for all types. Totally useless, IMO. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de