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.180.89.133 with SMTP id bo5mr56599wib.6.1364267117280; Mon, 25 Mar 2013 20:05:17 -0700 (PDT) Path: p18ni17985wiv.0!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!85.12.40.130.MISMATCH!xlned.com!feeder1.xlned.com!border5.a.newsrouter.astraweb.com!news.astraweb.com!border6.newsrouter.astraweb.com!newspeer1.nac.net!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!exi-in1.telstra.net!news.telstra.net!newsgate.cuhk.edu.hk!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Is this expected behavior or not Date: Sat, 23 Mar 2013 10:53:37 +0100 Organization: cbb software GmbH Message-ID: References: <99929f93-b80f-47c3-8a37-c81002733754@googlegroups.com> <87ec4b1d-f7cd-49a4-8cff-d44aeb76a1ad@googlegroups.com> <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> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: XRUMb5xlbonTNodERpEXEw.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 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 2013-03-23T10:53:37+01:00 List-Id: On Fri, 22 Mar 2013 21:33:02 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:2qwq2cdeuvhu$.qtnb8zyhuob9$.dlg@40tude.net... >> I still don't understand why is it relevant. Ada already has "loops" you >> are talking about for String and Wide_String. Why cannot you use them for >> their representations after selecting through dispatch? > > You can - but there is no benefit to doing so, so why bother? Egh, we wanted a class of strings, didn't we? >>> There's nothing that you can do with a slice that you can't do with a >>> loop, and usually the loop is easier to write and understand. >> >> Are you suggesting to call Put from a loop instead of Put_Line? I Don't >> want the language forcing me doing that. > > You need a loop somewhere (or a complex abstraction); Yes, the loop shall be within Put_Line. > In your particular example, that means that the slice needs to be a new > object. It certainly is, already. > 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. >>> Slicing is already impossible for the case that we're talking about, >> >> ? >> >> Normal strings have slices and should continue to have them. > > Sure, but Root_String'Class is a separate type hierarchy. I see, yet another outhouse, also. Ada quickly becomes a shantytown... >>> and >>> interface to foreign language already has to be done through special >>> types. >> >> Which should certainly be in the same class! There is no semantic reason >> why char_array should not be considered string. > > It won't work, semantically or implementation-wise. This is a total restart > of String semantics, and the old semantics will still exist (probably in > Annex J). There is no way to make the existing array semantics work like a > tagged type, and that is absolutely necessary for dispatching to work (even > if it isn't a "tagged type" in Ada terms). The way is to allow untagged T to have T'Class. This will preserve all semantics and all existing representations. Not even an explicit root type is needed, e.g. for char_array. The technique makes it possible to have ad-hoc supertypes, which would serve the purpose, e.g. you would define Put_Line on such a supertype and it will work for both String and char_array. Not a line changed in Standard or Interfaces.C. >>> No I mean all objects. It should be none of your business how the >>> compiler implements objects >> >> On the contrary, the compiler is free to choose a representation under the >> constraints specified by the programmer. I don't want Ada to become C#. > > That's the same thing I said, so I don't know why you are claiming that this > is different. It is different becauseto me it should be up to the programmer to set these constraints. The constraint is that char_array is a sequence of aliased char without gaps. If the compiler does not know how to implement a particular string operation on char_array, it should ask me. >>> None of the above makes any sense whatsoever. We need all of those things >>> in the object in order to generate code. >> >> So, you want to describe all possible problem domains in the RM? The RM >> should know that a matrix of 2 rows and 5 columns can be multiplied to a >> 5x8 matrix, but not to a 8x8 matrix? Good luck with that! > > No, but we need the building blocks so that one can specify such things as > part of the language. And the building block necessary is a statically checked constraint. The check shall be user-defined. The constraint shall be not present in constrained objects. This building block would give everything needed to have string class as well. >> This is a totally bogus argument. OO imposes no overhead on specific >> types. > > That's kool-aid invented by the Ada 9x team. It's not remotely true, > especially as all usable OOP types have to be controlled. See above. T'Class for all types! >> Nobody proposes to change tagged types. The idea is to add classes to >> non-tagged types by adding tag to the class-wide object while keeping >> specific objects as-is. > > But there is no point in doing so. Inheritance of operations of discrete > types is a bad idea that Ada already has and is virtually useless. ? > Why go further down a path to nowhere? Not even single step made so far. I see a lot of ad-hocks added recently which directly influence discrete types. All these aspects, attributes ('Read) are defined on discrete types as well. You are dragged down the path, looking backwards... >> How do I put such a reference in an array, for example? 4.1.5 would be >> extremely difficult to use for intended purpose. > > It's just a tagged object, do with it what you want. I don't see why you > think there is a problem. We will see. My prediction is that 4.1.5 will be very rarely used. Those who will try it, will have to fight with language limitations imposed by the design and then will drop it. Libraries based on it, will in turn become difficult to use for average programmers. Too much mental overhead, too many helper types (a bad OO-fest), too much time to find the package where the mess resides, too much efforts to understand why the compiler rejected obvious code... >>> Ahh, but that was a case where the "existing semantics" was good enough >>> so we didn't create a new thing. This is a very special access type, one >>> that almost never can be copied -- for practical purposes it can only be >>> dereferenced. That's what we needed. Note that there is no intent that >>> anyone ever create an object for this access type (and that is where all >>> of the problems lie). It just has the syntax of an access type so we didn't >>> have to invent a new thing to get dereferencing. >> >> You have a very specific use case in mind, namely containers. There is a >> whole world outside that, for which what you said is untrue, e.g. for >> smart pointers. The thing not only exposes access, it also exposes the target >> type. > > You have to expose the target type in order to have strong typing. How could > you hide it and still make type checks? Why should target type be public? > The ONLY reason that we need 4.1.5 is so that we can assign directly > into the target type. Yes, it is a hack designed for single use case. >>>> Even if it were compile-time it would require same representation for all >>>> involved objects. How would I do it for Unsigned_1 and String? >>> >>> I don't see this necessarily. You certainly can use dispatching to >>> support different representations. >> >> No way. Consider operation Send: >> >> procedure Send (To : in out Register; Value : Unsigned_1); >> >> procedure Send (To : in out Register; Value : String); >> >> It cannot dispatch! Firstly, Unsigned_1 and String are not in the same >> class. Secondly, even if they were, it would be MD! So, you need MI and MD >> to make it happen. Without them, poor man's solution is messing with >> generics. > > If you really wanted to go this way, you'd put all of those types in the > same class. (Having every possible advantage without any disadvantages is > impossible.) You are right about multiple dispatch in some cases, although > it's usually possible to layer those: > > procedure Send (To : in out Register; Value : Data'Class); > > which is legal Ada. Sure, this is exactly how I do it. It bursts into dozens of generic packages and hundreds of their instances. Unless you propose to code all hundreds of combinations manually... How should I test THIS? > I admit I don't see any point to a tagged Register type, but I take your > word for it that there is some value to that. Register must be tagged because Send is an operation on the register [and ultimately on the device the register refers to] >>> I think >>> these need a balance, especially as modern static analyzers can remove >>> the >>> vast majority of them (or warn that they might fail, which is a cause for >>> concern). >> >> It is not about removing checks, though performance is a concern too. The >> major problem is that failed checks must be flagged as errors. You are a >> compiler writer, I am designing automation systems. To me run-time check >> is much too late. A fault can break real things, apart from maintenance. >> Imagine Claw running on an oil platform. Do you own a helicopter? > > 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de