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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!mx05.eternal-september.org!feeder.eternal-september.org!nuzba.szn.dk!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Gnat 2013 is out! Date: Wed, 19 Jun 2013 16:57:45 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <32d94173-533a-471e-95a0-abb73a6cdcc2@googlegroups.com> <51a9e025$0$9521$9b4e6d93@newsspool1.arcor-online.net> <33025e6c-b893-4c66-98f6-0fb469016583@googlegroups.com> <51b6c424$0$6633$9b4e6d93@newsspool2.arcor-online.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1371679066 32185 69.95.181.76 (19 Jun 2013 21:57:46 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 19 Jun 2013 21:57:46 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:15849 Date: 2013-06-19T16:57:45-05:00 List-Id: "Georg Bauhaus" wrote in message news:51b6c424$0$6633$9b4e6d93@newsspool2.arcor-online.net... ... > Second, concerning the constraints that need to be supplied, > is there *any* way in Ada that allows them to be stated > "really simply"? If you need constraints, that is not an appropriate use of this feature. It's really for discarding error codes from non-Ada APIs, and those should be some discrete type (either integer or enumeration). The base type is good enough for those cases. It would be usable for some composites, but not all. But that's OK, the entire point is to have a simple shorthand for a discarded parameter. If it gets at all complex, it no longer has much benefit in readability (I'd much rather see an explicit declaration rather than some strange magic syntax). And discarding of composite parameters is slightly suspicious. > If the dummy syntax is for expressions of substitutes of a regular > declaration, how can a dummy expression be so much more simple > than a dummy declaration? The syntax I proposed was "<>". That's it, there is no declaration, constraint, range, or any of that. It's readable, can easily be read to mean "discard" in this case, and it doesn't look much like a legal parameter expression. If it gets much more complex than that, then it simply isn't worth it. Compare what I write today: declare Dummy : Code_Type; -- Not used in the following begin Some_Call (Param_A, Param_B, Dummy); end; That's 5 lines, 8 extra tokens for the Dummy declaration. That's a very small amount of writing to save, so whatever replaces it had better be very small or there is no point: Some_Call (Param_A, Param_B, <>); qualifies. The more complex suggestions I have seen simply don't simplify enough to justify the complexity. > About the only thing I can imagine towards simplified syntax > is inference of type *and* range constraints, with the help > of context (the subprograms' declarations). Is that double > inference part of Ada right now? There is (or should be) no need to constraints on dummy temporaries that are going to be discarded anyway. Why would anyone want something discarded to be range checked (thus introducing a point of failure)? If you need that, that's *not* a discarded dummy. Since you don't *want* constraints on dummies, there is no need to infer them. Just use the base type of the parameter, and be done with it. If there is any ambiguity, or you can't have an object of the base type, then you'll have to write those 8 extra tokens. How awful. :-) But I think you've convinced me this feature isn't worth the work. It just doesn't save enough, and the slippery slope of people trying to expand it (so it saves nothing in either dimension) completely kills any value. And that's before anyone does a detailed semantic analysis on it, which often kills apparently good ideas anyway. Randy.