* Problem with instantiating generic procedure @ 1999-07-17 0:00 Markus Kuhn 1999-07-17 0:00 ` Florian Weimer ` (4 more replies) 0 siblings, 5 replies; 13+ messages in thread From: Markus Kuhn @ 1999-07-17 0:00 UTC (permalink / raw) Sorry, but after searching through the RM for almost an hour, I still haven't figured out what I do wrong here and how I should fix this. I declare in a package spec a procedure A and I want to implement the procedure body of A by instantiating a generic procedure G. The following is the shortest possible program that reproduces my problem: -- bug.ads -- package Bug is procedure A; end Bug; -- bug.adb -- package body Bug is generic procedure G; procedure G is begin null; end G; procedure A is new G; end Bug; ------------- GNAT 3.11p on Linux insists on the following error message: bug.adb:1:14: missing body for "A" declared at bug.ads:3 bug.adb:11:14: "A" conflicts with declaration at bug.ads:3 What is wrong with simply implementing a procedure declared in the spec file in the body file by instantiating it from a generic procedure of the exact same signature? Both A and G have no parameters, so how can there be a conflict? It would be nice if GNAT wrote out explicitely the two conflicting sides, each time it uses the word "conflict" in an error message. Any idea what is wrong here? Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/> ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with instantiating generic procedure 1999-07-17 0:00 Problem with instantiating generic procedure Markus Kuhn @ 1999-07-17 0:00 ` Florian Weimer 1999-07-18 0:00 ` Markus Kuhn 1999-07-17 0:00 ` Vladimir Olensky ` (3 subsequent siblings) 4 siblings, 1 reply; 13+ messages in thread From: Florian Weimer @ 1999-07-17 0:00 UTC (permalink / raw) mgk25@cl.cam.ac.uk (Markus Kuhn) writes: > Sorry, but after searching through the RM for almost an hour, I still > haven't figured out what I do wrong here and how I should fix this. ARM 6.1(20): | A subprogram_declaration or a generic_subprogram_declaration requires | a completion: a body, a renaming_declaration (see 8.5), or a pragma | Import (see B.1). A completion is not allowed for an | abstract_subprogram_declaration. I guess this means that an instance of a generic subprogram isn't allowed as a completion for a subprogram declaration. The obvious workaround is using a renaming declaration. Of course, the GNAT error message could be a bit more helpful. BTW: I stumbled across this problem and the solution while a solving the very first Ada exercise of my computer science course. ;) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with instantiating generic procedure 1999-07-17 0:00 ` Florian Weimer @ 1999-07-18 0:00 ` Markus Kuhn 1999-07-18 0:00 ` Chad R. Meiners 1999-07-18 0:00 ` Florian Weimer 0 siblings, 2 replies; 13+ messages in thread From: Markus Kuhn @ 1999-07-18 0:00 UTC (permalink / raw) Florian Weimer <fw@s.netic.de>: |> ARM 6.1(20): |> |> | A subprogram_declaration or a generic_subprogram_declaration requires |> | a completion: a body, a renaming_declaration (see 8.5), or a pragma |> | Import (see B.1). A completion is not allowed for an |> | abstract_subprogram_declaration. Thanks! But the RM also says in section 12.3: A generic_instantiation declares an instance; it is equivalent to the instance declaration (a package_declaration or subprogram_declaration) immediately followed by the instance body, both at the place of the instantiation. So if 6.1 says that a subprogram_declaration requires a body and 12.3 says that a generic instantiation does provide the equivalent of a body, then I still do not understand where the RM says that my program is illegal. In addition, I see absolutely no good reason, why the language should forbid this. It just requires an ugly workaround via renaming, which forces me to pollute the object namespace and makes the code less readable by introducing yet another temporary name for something. In my case, I make over 30 instantiations (I am writing a type-safe binding for the linux ioctl() system calls), so I also have to add now over 30 renames, which looks really ugly. I guess I'll submit it as a bug report to ACT and let them decide whether it is just an unclear error message or a non-conformity to the RM. In any case, if someone keeps an Ada 0X wish list, please put adding generic instantiations to 6.1(20) onto it. |> I guess this means that an instance of a generic subprogram isn't allowed |> as a completion for a subprogram declaration. The obvious workaround |> is using a renaming declaration. Of course, the GNAT error message |> could be a bit more helpful. Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/> ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with instantiating generic procedure 1999-07-18 0:00 ` Markus Kuhn @ 1999-07-18 0:00 ` Chad R. Meiners 1999-07-18 0:00 ` Florian Weimer 1 sibling, 0 replies; 13+ messages in thread From: Chad R. Meiners @ 1999-07-18 0:00 UTC (permalink / raw) Perhaps the follow solution is an acceptable alterative to renaming generic instantiations: Package Generics is generic Type Parameter is private; procedure G(Item : Parameter); end Generics; Package body Generics is Procedure G(Item : Parameter) is begin null; end G; end Generics; with Generics; Package Instantiations is Procedure A is new Generics.G(Integer); --Procedure A(Item : Integer); end Instantiations; The only problem with this solution is that Generics is not a private package, but I don't think that would be a problem in your case. -Chad R. Meiners Markus Kuhn <mgk25@cl.cam.ac.uk> wrote in message news:7ms4en$kl8$1@pegasus.csx.cam.ac.uk... > Florian Weimer <fw@s.netic.de>: > |> ARM 6.1(20): > |> > |> | A subprogram_declaration or a generic_subprogram_declaration requires > |> | a completion: a body, a renaming_declaration (see 8.5), or a pragma > |> | Import (see B.1). A completion is not allowed for an > |> | abstract_subprogram_declaration. > > Thanks! But the RM also says in section 12.3: > > A generic_instantiation declares an instance; it is equivalent to the > instance declaration (a package_declaration or subprogram_declaration) > immediately followed by the instance body, both at the place of the > instantiation. > > So if 6.1 says that a subprogram_declaration requires a body and 12.3 says that > a generic instantiation does provide the equivalent of a body, then I still > do not understand where the RM says that my program is illegal. In addition, > I see absolutely no good reason, why the language should forbid this. It just > requires an ugly workaround via renaming, which forces me to pollute the object > namespace and makes the code less readable by introducing yet another temporary > name for something. In my case, I make over 30 instantiations (I am writing a type-safe > binding for the linux ioctl() system calls), so I also have to add now over 30 > renames, which looks really ugly. > > I guess I'll submit it as a bug report to ACT and let them decide whether it is > just an unclear error message or a non-conformity to the RM. In any case, if someone > keeps an Ada 0X wish list, please put adding generic instantiations to 6.1(20) onto > it. > > |> I guess this means that an instance of a generic subprogram isn't allowed > |> as a completion for a subprogram declaration. The obvious workaround > |> is using a renaming declaration. Of course, the GNAT error message > |> could be a bit more helpful. > > Markus > > -- > Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK > Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/> ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with instantiating generic procedure 1999-07-18 0:00 ` Markus Kuhn 1999-07-18 0:00 ` Chad R. Meiners @ 1999-07-18 0:00 ` Florian Weimer 1999-07-19 0:00 ` Robert Dewar 1 sibling, 1 reply; 13+ messages in thread From: Florian Weimer @ 1999-07-18 0:00 UTC (permalink / raw) mgk25@cl.cam.ac.uk (Markus Kuhn) writes: > Florian Weimer <fw@s.netic.de>: > |> ARM 6.1(20): > |> > |> | A subprogram_declaration or a generic_subprogram_declaration requires > |> | a completion: a body, a renaming_declaration (see 8.5), or a pragma > |> | Import (see B.1). A completion is not allowed for an > |> | abstract_subprogram_declaration. > > Thanks! But the RM also says in section 12.3: > > A generic_instantiation declares an instance; it is equivalent to the > instance declaration (a package_declaration or subprogram_declaration) > immediately followed by the instance body, both at the place of the > instantiation. > > So if 6.1 says that a subprogram_declaration requires a body and > 12.3 says that a generic instantiation does provide the equivalent > of a body, then I still do not understand where the RM says that my > program is illegal. You have two subprogram declarations, one in the package specification and one implicitly created by the instantiation in the package body. I suppose this isn't allowed (ARM 6.1(1)): | [...] The definition of a subprogram can be given in two parts: a | subprogram declaration defining its interface, and a subprogram_body | defining its execution. [...] > In addition, I see absolutely no good reason, why the language > should forbid this. From my limited point of view, I don't see it either. There's a related thing I'd like to see improved in a future Ada revision: pragma Import requires the use of renaming declarations as well if the Ada functions in question are overloaded. The effects are quite similar here (namespace pollution). ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with instantiating generic procedure 1999-07-18 0:00 ` Florian Weimer @ 1999-07-19 0:00 ` Robert Dewar 1999-07-19 0:00 ` Florian Weimer 0 siblings, 1 reply; 13+ messages in thread From: Robert Dewar @ 1999-07-19 0:00 UTC (permalink / raw) In article <m3so6mdw05.fsf@deneb.cygnus.stuttgart.netsurf.de>, Florian Weimer <fw@s.netic.de> wrote: > From my limited point of view, I don't see it either. > > There's a related thing I'd like to see improved in a future Ada > revision: pragma Import requires the use of renaming declarations as > well if the Ada functions in question are overloaded. The effects are > quite similar here (namespace pollution). But the name space pollution is a minimal problem, because it occurs only in private parts or in package bodies, not in package specs. We did discuss the possibility of completing subprogram declarations with generic instantiations, but it was considered too much machinery for too little gain. Remember this is just syntactic sugar for defining a body which does the instantiation internally and then calls the procedure. In practice, this is the way it would be implemented in any case. I would guess this is in practice of minimal importance. In all the use of GNAT so far, this issue has never come up, so it is certainly not something that many people expect to be there! As for pragma Import, the renaminings can all be done in the private part, so this is not really a burden: package p is procedure q; procedure q (x : integer); private procedure q_no_args renames q; procedure q_int_arg (x : integer) renames q; pragma Import (C, q_no_args); pragma Import (C, q_int_arg); end p; Indeed, since you need separate names for the routines that implement these two cases, forcing names to be used in this way can actually make things clearer! > Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with instantiating generic procedure 1999-07-19 0:00 ` Robert Dewar @ 1999-07-19 0:00 ` Florian Weimer 0 siblings, 0 replies; 13+ messages in thread From: Florian Weimer @ 1999-07-19 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > But the name space pollution is a minimal problem, because it > occurs only in private parts or in package bodies, not in > package specs. Thanks, I wasn't aware of this. > I would guess this is in practice of minimal importance. In all > the use of GNAT so far, this issue has never come up, so it is > certainly not something that many people expect to be there! This seems to be case for this specific use of pragma Import as well, because GNAT 3.11p generates bad code for your example. ;) (A call to procedure q (with or without an integer argument) results in a `call q' instruction in both cases, which is certainly wrong.) > package p is > procedure q; > procedure q (x : integer); > private > procedure q_no_args renames q; > procedure q_int_arg (x : integer) renames q; > > pragma Import (C, q_no_args); > pragma Import (C, q_int_arg); > > end p; The renaming declaration are `in the wrong direction', I guess. Something like this is required instead: package p is procedure q; procedure q (x : integer); private procedure q_no_args; procedure q_int_arg (x : integer); pragma Import (C, q_no_args); pragma Import (C, q_int_arg); procedure q renames q_no_args; procedure q (x : integer) renames q_int_arg; end p; ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with instantiating generic procedure 1999-07-17 0:00 Problem with instantiating generic procedure Markus Kuhn 1999-07-17 0:00 ` Florian Weimer @ 1999-07-17 0:00 ` Vladimir Olensky 1999-07-18 0:00 ` David C. Hoos, Sr. ` (2 subsequent siblings) 4 siblings, 0 replies; 13+ messages in thread From: Vladimir Olensky @ 1999-07-17 0:00 UTC (permalink / raw) Here are two working examples that solves your problem. Gnat 3.11p, WinNT. Hope this will help. As I understand it one should first have instantiation of generic procedure and only then bind it with the procedure name declared at spec. --=============================== Example 1: ---------------------------------- package Bug is procedure A; end Bug; --------------------------------- with ada.text_io; use ada.text_io; package body Bug is generic procedure G; procedure G is begin put_line("Body of A implemented as generic"); end G; procedure AA is new G; procedure A renames AA; end Bug; --=============================== Example 2: ---------------------------------- generic package G is procedure GP; end G; ---------------------------------- with ada.text_IO; use ada.text_io; package body G is procedure GP is begin put_line("Body of A implemented as generic"); end GP; end G; ----------------------- package Bug is procedure A; end Bug; ---------------- with G; package body Bug is package AA is new G; procedure A renames AA.GP; end Bug; ---------------------------- --================================== -- test procedure for both examples with Bug; procedure Tst_Bug is begin Bug.A; end Tst_Bug; ---------------------------------------------- Regards, Vladimir Olensky Markus Kuhn wrote in message <7mqfcq$9og$1@pegasus.csx.cam.ac.uk>... >Sorry, but after searching through the RM for almost an hour, I still >haven't figured out what I do wrong here and how I should fix this. >I declare in a package spec a procedure A and I want to implement the >procedure body of A by instantiating a generic procedure G. The following >is the shortest possible program that reproduces my problem: > >-- bug.ads -- >package Bug is > > procedure A; > >end Bug; >-- bug.adb -- >package body Bug is > > generic > procedure G; > > procedure G is > begin > null; > end G; > > procedure A is new G; > >end Bug; >------------- > >GNAT 3.11p on Linux insists on the following error message: > >bug.adb:1:14: missing body for "A" declared at bug.ads:3 >bug.adb:11:14: "A" conflicts with declaration at bug.ads:3 > >What is wrong with simply implementing a procedure declared >in the spec file in the body file by instantiating it from >a generic procedure of the exact same signature? Both A and G >have no parameters, so how can there be a conflict? > >It would be nice if GNAT wrote out explicitely the two conflicting >sides, each time it uses the word "conflict" in an error message. > >Any idea what is wrong here? > >Markus > >-- >Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK >Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/> ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with instantiating generic procedure 1999-07-17 0:00 Problem with instantiating generic procedure Markus Kuhn 1999-07-17 0:00 ` Florian Weimer 1999-07-17 0:00 ` Vladimir Olensky @ 1999-07-18 0:00 ` David C. Hoos, Sr. 1999-07-19 0:00 ` Tucker Taft 1999-07-19 0:00 ` Robert A Duff 4 siblings, 0 replies; 13+ messages in thread From: David C. Hoos, Sr. @ 1999-07-18 0:00 UTC (permalink / raw) Markus Kuhn <mgk25@cl.cam.ac.uk> wrote in message news:7mqfcq$9og$1@pegasus.csx.cam.ac.uk... > Sorry, but after searching through the RM for almost an hour, I still > haven't figured out what I do wrong here and how I should fix this. > I declare in a package spec a procedure A and I want to implement the > procedure body of A by instantiating a generic procedure G. The following > is the shortest possible program that reproduces my problem: > > -- bug.ads -- > package Bug is > > procedure A; > > end Bug; > -- bug.adb -- > package body Bug is > > generic > procedure G; > > procedure G is > begin > null; > end G; > > procedure A is new G; > > end Bug; > ------------- > > GNAT 3.11p on Linux insists on the following error message: > > bug.adb:1:14: missing body for "A" declared at bug.ads:3 > bug.adb:11:14: "A" conflicts with declaration at bug.ads:3 > > What is wrong with simply implementing a procedure declared > in the spec file in the body file by instantiating it from > a generic procedure of the exact same signature? Both A and G > have no parameters, so how can there be a conflict? > > It would be nice if GNAT wrote out explicitely the two conflicting > sides, each time it uses the word "conflict" in an error message. > > Any idea what is wrong here? What you have in the instantiation is the declaration of a spec for procedure A which is a homograph of the declaration in bug.ads -- and, therefore, illegal, conflicting. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with instantiating generic procedure 1999-07-17 0:00 Problem with instantiating generic procedure Markus Kuhn ` (2 preceding siblings ...) 1999-07-18 0:00 ` David C. Hoos, Sr. @ 1999-07-19 0:00 ` Tucker Taft 1999-07-19 0:00 ` Markus Kuhn 1999-07-19 0:00 ` Robert A Duff 4 siblings, 1 reply; 13+ messages in thread From: Tucker Taft @ 1999-07-19 0:00 UTC (permalink / raw) Markus Kuhn wrote: > ... > > What is wrong with simply implementing a procedure declared > in the spec file in the body file by instantiating it from > a generic procedure of the exact same signature? Both A and G > have no parameters, so how can there be a conflict? We considered allowing a subprogram spec to be completed by a generic instantiation during the 9X design process. Ultimately we chose to only allow renaming-as-body. So if you want to do this, you must first do the instantiation using a different name, and then define the body by renaming this generic. The rationale behind disallowing a generic instance to be used directly was as follows: A generic instantiation does not include any parameter profile for the subprogram being defined. Hence, matching it up with a spec in the presence of overloading could be difficult for the reader. On the other hand, a renaming includes a parameter profile. Hence, matching a spec with a renaming-as-body did not impose any extra burden on the reader. Therefore, given the general preference for readability over writability, renaming-as-body was proposed as the general solution to problems like this, and instantiation-as-body was not allowed. That's the rationale. I will admit we had a fair amount of discussion before we came to consensus. It is always tricky to negotiate these readability versus writability issues. In the long run the emphasis on readability always seems wise, but in the short term, the emphasis sometimes comes across as just being arbitrarily picky. > ... > > Any idea what is wrong here? You need to use renaming-as-body instead. > > Markus > > -- > Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK > Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/> -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with instantiating generic procedure 1999-07-19 0:00 ` Tucker Taft @ 1999-07-19 0:00 ` Markus Kuhn 1999-07-23 0:00 ` Tucker Taft 0 siblings, 1 reply; 13+ messages in thread From: Markus Kuhn @ 1999-07-19 0:00 UTC (permalink / raw) Tucker Taft <stt@averstar.com> writes: |> The rationale behind disallowing a generic instance to be used |> directly was as follows: |> |> A generic instantiation does not include any parameter profile |> for the subprogram being defined. Hence, matching it up with |> a spec in the presence of overloading could be difficult for the |> reader. On the other hand, a renaming includes a parameter profile. |> Hence, matching a spec with a renaming-as-body did not impose any |> extra burden on the reader. Therefore, given the general preference |> for readability over writability, renaming-as-body was proposed as |> the general solution to problems like this, and instantiation-as-body |> was not allowed. |> |> That's the rationale. I will admit we had a fair amount of discussion |> before we came to consensus. It is always tricky to negotiate these |> readability versus writability issues. In the long run the emphasis |> on readability always seems wise, but in the short term, the emphasis |> sometimes comes across as just being arbitrarily picky. Thanks for your reply. In my particular case, I have around 3 generic procedures, from which I create over 30 instances, which are then made publically visible. None of thes procedures is overloaded, they do already have different names. The over 30 "renames" that I have to add now really decrease the readability of the code. They add unneeded notational complexity and destroy much of the codes originally intended notational elegance. Sure, I can live with it, it is just an example where the intension of restricting the flexibility of the language to support the reader fired in the wrong direction. The concern about supporting the reader versus the writer is a noble one, but it can be wrong to enforce a bit too much here. Really readable programs can only be achieved with the active cooperation of the writer. I think it is not wrong to leave many aspects of what is more readable or not at the discretion of the writer. It is difficult to forsee all possible situations at language design time. Indirections and the introduction of new names can also make code significantly less readable. Our brains have fixed neurophyisiological limits as to how many objects we can simultaneously handle in our short-term memory (in the range of 6-8 for healthy adults), and a blowup in notation will consume some of this very limited capacity. Sometimes a compact (even if semantically more complex) notation can help readers to process and perceive the overall situation hierarchically, while a more lengthy but semantically simpler form does not support this. Ada unfortunatelly choses sometimes a bit too much of the latter alternative and I think we have seen an example here. One of the more important things I learned the hard way over the time was, that some things are difficult to reason about in a theoretical manner. They have to be tried and measured instead to get meaningful results. The performance and efficiency of machine code on modern branch-predicting superscalar CPUs is one good example. The readability of some language syntax and semantic for experienced readers is another one. Both can very easily be misestimated if they are just discussed at an abstract level without good experimental verification. Where there ever any controlled readability experiments done during the Ada design process? I frequently hear that the Pascal syntax style was considered to be more readable than the C syntax, but is this just folklore or is there a scientifically quotable foundation for this? Is for example a[i*4+j-32*k+56] += f(4); really more difficult to read than a(i*4+j-32*k+56) := a(i*4-j+32*k+56) + f(4); and are these two statements equivalent? Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/> ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with instantiating generic procedure 1999-07-19 0:00 ` Markus Kuhn @ 1999-07-23 0:00 ` Tucker Taft 0 siblings, 0 replies; 13+ messages in thread From: Tucker Taft @ 1999-07-23 0:00 UTC (permalink / raw) Markus Kuhn wrote: > The concern about supporting the reader versus the writer is a noble one, > but it can be wrong to enforce a bit too much here. I agree. It is a tradeoff. You could argue we erred on this one. On the other hand, a systematic naming convention could make it relatively easy to deal with. E.g.: procedure X_Inst is new G(...); procedure X(A, B : Integer) renames X_Inst; > ...Really readable > programs can only be achieved with the active cooperation of the writer. That's certainly true. On the other hand, I strongly believe that the design of a language does have a significant effect on the average readability of code, even when looking at the exact same pool of programmers. Languages with a lot of short-hands to some degree encourage the use of short-hands, which (on the average) make code harder to read, in my experience. The goal of Ada is that once the writer succeeded in producing a compilable program, the meaning is (on the average) quite obvious to the reader. It does take longer to produce a compilable program, but the clarity to the subsequent readers makes up for that quickly, in my experience. > ... > Where there ever any controlled readability experiments done during the > Ada design process? I frequently hear that the Pascal syntax style was > considered to be more readable than the C syntax, but is this just > folklore or is there a scientifically quotable foundation for this? The experiments in general involved coding up examples using the competing proposals, and/or creating "gedanken" experiments relating to maintenance activities, etc. Robustness during maintenance activities was also considered an important criteria. By forcing the renaming, you get somewhat better protection if the profile of a generic subprogram changes (e.g. by the addition of a defaulted parameter), or at least you get better error messages. If a generic instantiation were allowed to complete a subprogram spec, then if the profile of the generic changed, the generic instantiation would "morph" into a legal stand-alone instantiation, and you would get a potentially mysterious message that there was no body found for the subprogram spec. > Is for example > > a[i*4+j-32*k+56] += f(4); > > really more difficult to read than > > a(i*4+j-32*k+56) := a(i*4-j+32*k+56) + f(4); > > and are these two statements equivalent? I would agree that "+=" is a nice operation, and I often miss it when coding in Ada. However, when you start having things like "X *= A + B" or "Y /= Z-3" the readability of these shortcuts begins to drop in my view (due to confusions about precedence, etc.). In the presence of user-defined operators, it is also unclear whether things like "+=" should be automatically defined by the compiler in terms of user-defined assignment and user-defined "+", or require its own explicit user definition. From my perspective, the most important thing is to have at least a *goal* of creating a readable, maintainable, safe language. Of course you will miss sometimes, but if you don't even try, you will probably miss most of the time. > Markus > > -- > Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK > Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/> -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem with instantiating generic procedure 1999-07-17 0:00 Problem with instantiating generic procedure Markus Kuhn ` (3 preceding siblings ...) 1999-07-19 0:00 ` Tucker Taft @ 1999-07-19 0:00 ` Robert A Duff 4 siblings, 0 replies; 13+ messages in thread From: Robert A Duff @ 1999-07-19 0:00 UTC (permalink / raw) mgk25@cl.cam.ac.uk (Markus Kuhn) writes: > What is wrong with simply implementing a procedure declared > in the spec file in the body file by instantiating it from > a generic procedure of the exact same signature? ... Nothing, except that it's illegal. ;-) The Ada 9X design team proposed to allow this, but it was not considered important enough -- any language change has some cost, and the benefit of allowing this is not huge. Note that in Ada 83, the renaming-as-body didn't exist, so you had to write a whole wrapper body. - Bob -- Change robert to bob to get my real email address. Sorry. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~1999-07-23 0:00 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-07-17 0:00 Problem with instantiating generic procedure Markus Kuhn 1999-07-17 0:00 ` Florian Weimer 1999-07-18 0:00 ` Markus Kuhn 1999-07-18 0:00 ` Chad R. Meiners 1999-07-18 0:00 ` Florian Weimer 1999-07-19 0:00 ` Robert Dewar 1999-07-19 0:00 ` Florian Weimer 1999-07-17 0:00 ` Vladimir Olensky 1999-07-18 0:00 ` David C. Hoos, Sr. 1999-07-19 0:00 ` Tucker Taft 1999-07-19 0:00 ` Markus Kuhn 1999-07-23 0:00 ` Tucker Taft 1999-07-19 0:00 ` Robert A Duff
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox