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.75.82 with SMTP id a18mr5616225wiw.0.1366380868836; Fri, 19 Apr 2013 07:14:28 -0700 (PDT) MIME-Version: 1.0 Path: hg5ni22265wib.1!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!85.12.40.130.MISMATCH!xlned.com!feeder1.xlned.com!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!usenetcore.com!border1.nntp.ams.giganews.com!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!nrc-news.nrc.ca!News.Dal.Ca!news.litech.org!news.stack.nl!news.ecp.fr!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, 11 Apr 2013 18:02:49 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <1gnmajx2fdjju.1bo28xwmzt1nr.dlg@40tude.net> <3gv2jwc95otm.pl2aahsh9ox8.dlg@40tude.net> <1gkxiwepaxvtt$.u3ly33rbwthf.dlg@40tude.net> <1fmcdkj58brky.bjedt0pr39cd$.dlg@40tude.net> <1bj564vat3q1j$.1s4d00rlzx4ux$.dlg@40tude.net> <8bj2k30k7i19.w7ehsldwbf7x.dlg@40tude.net> <1o34nhpfuy6yl$.2orlukd1elr7.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1365721372 12394 69.95.181.76 (11 Apr 2013 23:02:52 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 11 Apr 2013 23:02:52 +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-04-11T18:02:49-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:1o34nhpfuy6yl$.2orlukd1elr7.dlg@40tude.net... > On Wed, 10 Apr 2013 17:07:57 -0500, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" wrote in message >> news:8bj2k30k7i19.w7ehsldwbf7x.dlg@40tude.net... >>> On Tue, 9 Apr 2013 18:24:29 -0500, Randy Brukardt wrote: >> ... >>>>> Why there should be many? >>>> >>>> If you've got operations like "+" or "*", you'll have a lot of >>>> functions >>>> returning objects of the type. That's a bad idea for the reasons I >>>> mentioned. >>> >>> You have + and * of GUI objects? That is weird. Anyway if you have >>> arithmetic upon a hierarchy how the compiler is supposed to deduce >>> implementations for derived types? >> >> Tagged types and extension is used for more than just GUIs. > > Tagged types are useless when arithmetic operations get involved. It does > not work with present design, because type hierarchies are not handled for > such operations. > >> The compiler shouldn't have trouble with inheriting implementations > > type Real is tagged record > Value : Float; > end record; > function "+" (L, R : Real) return Real; > > type Complex is new Real with record > Img : Float; > end record; > > How is the compiler supposed to inherit "+"? Easy, it uses the defined constructor. I explained that in the part of the message that you deleted. That's a feature Ada is missing but could easily have, especially as we already have something like it for null extensions. Of course, I don't think Float and Complex have enough in common for this sort of derivation to make sense. (The only commonality between float "*" and complex "*" is the name.) ... >>> You don't make language design dependent and promoting bad practices. >> >> If you are starting with a blank page, you're right. If you are building >> on >> 30+ years of practice, even "bad practice" has to be taken into account. > > Nonsense. Bad practice is bad. Longer it lasts bigger is the damage. Not nonsense. You can't break existing programs if you expect people to upgrade. I've got a million or so lines of Ada code; I can't use a new upgraded language on those if they are going to be broken, and I can't support a different compiler for every version of code ever written. If you can detect the "bad practice" at compile-time *and* its rare enough, then, and only then, can we consider an incompatibility. Differences at run-time are intolerable unless the likelihood of it occurring in practice are very small. We've made exceptions to that, but only after many attempts to adopt other solutions and a lot of research of existing databases of code. (And they're always controversial.) >> This is one of the reasons that the language you're suggesting really has >> to >> be different than Ada. > > We already discussed that. I want to preserve Ada semantics. It is you who > wants completely change the way string types are used in Ada. But you're not going to come close to preserving Ada semantics. The model of the language is a very important part of that semantics, as it is encoded in countless books and articles and tutorials. The gain from abandoning it (and we'd have to abandon it to adopt a model like yours) would have to be immense. ... >>>> That isn't very likely to >>>> happen. The only way to define these conversions would be through a >>>> Wide_Wide_String intermediate - the net effect is that the conversions >>>> will be quite expensive and you would never, ever want to use such >>>> implementations. >>> >>> This is exactly the overhead of doing this using the infamous unary plus >>> operation. I don't understand the point you are trying to make. You >>> don't >>> want to override for custom types, you don't want automatic conversion >>> as >>> too expensive. There is no third way. You want to apply explicit >>> conversions at all call points? This is exactly the solution you >>> declared >>> inefficient. It not only inefficient, it is extremely error prone and a >>> major overhead for those unfortunate who have to use the package defined >>> in such manner. The compiler rejects a program. What you do? Erratically >>> place unary pluses before all arguments? But that is invisible. Actually >>> some >>> hundred of them are already visible. For each of them the compiler spits >>> some garbage error messages on you. But the right one you need is not >>> visible. Were was it declared? Was it declared anywhere? Have fun! >> >> You're confusing expensive *implicit* operations with expensive explicit >> ones. I don't care that an explicit type conversion is expensive -- you >> wrote it, you meant it, and you can see the consequences -- it's right >> there >> in the source code. > > Right, I don't care about performance I care about usability of the > packages. Only when performance becomes a problem I address that. But I > never let performance issues to cripple my design. Fair enough, as I agree in general. But it is important, especially for embedded systems, that there is a correlation between the "expense" of the construct and how "expensive" it looks. I don't think expensive operations should occur automatically, especially if they're a dubious idea to begin with. > But if performance is your concern, you must be the first to go for > multi-methods, because this is the only way to define type-specific > operations and to have different representations for different members of > the hierarchy. Your proposal was to render all strings as > Wide_Wide_String. > And you tell me about efficiency? It is never a good idea to mix types in a program: String shouldn't be mixed with Wide_String, Float with Complex, or Integer with Float. In the rare case when you need to do so, you should write an explicit conversion. There's nothing wrong with storing all strings in unbounded UTF-8, for instance, but storing them in a variety of formats will just cause you a huge amount of translation overhead. It's not worth it. The Wide_Wide_Strings are only used for conversions between types and literals. (And for slice emulation, although I'm dubious that we need that; the operations in Ada.Strings.Fixed are easier to understand and use for most things.) >> For instance, I tend to write out the entire name of the conversion >> between >> string and unbounded string: >> >> Ada.Text_IO.Put_Line (Ada.Strings.Unbounded.To_String (My_Object)); > > Hideous. What kind of information this mess should convey to the reader? > 2/3 of it is noise. My_Object is a string, why Put_Line does not handle > it? It's a "string", not a String. Of course it shouldn't handle it. I'd like a shorter name for this conversion (preferably a user-defined type conversion), but I definitely do not want to get rid of it here. Ada.Text_IO.Put_Line (String (My_Object)); seems perfect. Of course, "General_Text_IO" would take Root_String'Class, so you could write what you want with it. Ada.General_Text_IO.Put_Line (My_Object); The internals of the Put_Line operation would be a lot more expensive in that case, whether that matters or not depends on the problem (probably not for Put_Line). Anyway, our programming styles are probably 180 degrees apart -- it's not surprising that we don't agree on any of this. Randy.