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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f7a9613bbc2bd8c9 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-05-14 05:00:30 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!fu-berlin.de!uni-berlin.de!pec-70-22.tnt4.hh2.uunet.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: Generic default parameters Date: Tue, 14 May 2002 14:01:47 +0200 Message-ID: <4dt1eucrs8l97qnj0nq5hmgihuu6kbprdk@4ax.com> References: NNTP-Posting-Host: pec-70-22.tnt4.hh2.uunet.de (149.225.70.22) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: fu-berlin.de 1021377627 21234686 149.225.70.22 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:24010 Date: 2002-05-14T14:01:47+02:00 List-Id: On Tue, 14 May 2002 13:03:46 +0200 (MET DST), "Grein, Christoph" wrote: >> >I do see problems with this proposal. First of all it would be a major >upwardly >> >incompatible change and break old code - a NONO for the ARG. >> ... >> True. It would make some old code ambiguous. However the ambiguity can >> be relatively easily resolved. > >Easy or not, only if absolutely necessary would the ARG be willing to change the >language in a way that is upwardly incompatible. This proposal does not seem >worth it. I have no illusions. (:-)) Well, it is not so hard to write wrappers, however it is nasty, especially when an instantiation happens at library level. Then one needs a special package to pack dirty clothes there. >> >This being the case, it seems useless to discuss how matching rules for >> >subprograms with defaulted parameters should be defined - they are not so >> >obvious for me. >> >> In fact I thought that the matching rules for subprogram renaming >> should be relaxed with regard of default values. Presently, generics >> just use that rules. I wished these rules were same as ones for >> subprogram calls. Maybe, as close as: >> >> function Int_Sqrt (X : Integer) renames Sqrt (Float (X)); >> procedure Debug (X : Integer) >> renames Put_Line >> (File=>My_File; Item=>Integer'Image (X)); > >This is invalid syntax Yep, I just added function composition, which differs not very much from providing a value to a parameter, for both go in the direction of specializing subprograms without wrappers. >(I can imagine what you mean - it's a mess). But the >rules would not be so simple. Defaulted parameters need not come last (in this >way you force named association when omitting parameters). > >So would either subprogram > > procedure (X: S; Y: T := Def); > procedure (X: T := Def; Y: S); > >match > > procedure (W: S); Only the first matches. The rules should be same as in case of overloading: procedure A (X: S; Y: T := Def); procedure A (X: T := Def; Y: S); W : S; ... A (W); -- It is unambiguous, so should be ... procedure B (W: S) renames A; -- OK, the first one -- -- To rename the second: -- procedure C (W: S) renames A (Y=>W); -- Named association procedure D (W: S) renames A (T'First); -- Another value for X >What about > > procedure (X: S; Y: S := Def); > procedure (X: S := Def; Y: S); > >Would they both match? Yes, because one is a homograph of another. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de