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 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Top 10 Worst C# Features Date: Sat, 5 Sep 2015 09:21:31 +0200 Organization: cbb software GmbH Message-ID: <1ua50qw5jsnov.y1h28aoi7447$.dlg@40tude.net> References: Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: VL9PesNteoW7ZJu/aOPHLA.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:27710 Date: 2015-09-05T09:21:31+02:00 List-Id: On Sat, 5 Sep 2015 09:45:43 +0300, Niklas Holsti wrote: > - Outputs of a computation can be made available to a caller, without > the caller having to declare "out" variables, by implementing the > computation in the elaboration block in the body of a generic package, > which has generic formal objects corresponding to the formal "in" and > "in out" parameters of the computation, and declares public variables > corresponding to the "out" parameters of the computation. To "call" this > computation, the "caller" instantiates the generic, and can then access > the public variables of the instance, with the values computed at > elaboration of the instance, without explicitly declaring her own > variables for use as "outs". But I'm sure that most programmers would > consider this to be a weird misuse of the generic facility. Further, the > instantiation must be done as a declaration, not as a statement, and the > "out" variables can seldom be declared constant, because the computation > is often too complex to be done in the declaration of the generic package. It is worth to have a language construct for this. There are cases beyond multiple out parameters when this is necessary, e.g. if X in T'Class then declare Y : T'Class renames T'Class (X); or if Ptr /= null then declare X : T := Ptr.all; > In a more functional-programming approach, a procedure could be made to > "return" its outputs by calling different "continuation" procedures > (given as "in" parameters) for the different outcomes; each such > continuation procedure could have its own set of "in" parameters > corresponding to the "outs" available from the original procedure in > this outcome. This would be rather far from the procedural Ada style, > but perhaps it could be used as the internal implementation of what I > proposed above, even if the source syntax does not look like continuations. This is an independent case to me. It falls into the basket "co-routines". If we had co-routines we could use them to handle multiple outputs. BTW, this is rather data-driven approach than functional. DDA is a mess on a much bigger scale than one could imagine... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de