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 03:22:34 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-139-192.tnt8.hh2.uunet.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: Generic default parameters Date: Tue, 14 May 2002 12:23:52 +0200 Message-ID: References: NNTP-Posting-Host: pec-139-192.tnt8.hh2.uunet.de (149.225.139.192) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: fu-berlin.de 1021371753 21563104 149.225.139.192 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:24007 Date: 2002-05-14T12:23:52+02:00 List-Id: On Tue, 14 May 2002 06:57:52 +0200 (MET DST), "Grein, Christoph" wrote: >> > 6. A more liberal matching of actual subprograms against formal ones. >> > If some parameters of the actual subrogram have defaults, then they >> > can be absent in the formal one. >> > >> > generic >> > with procedure Put (Item : in Object) is <>; >> > package Foo ... >> > >> > Then an instantiation with Integer_IO.Put: <-------- #2 >> > >> > procedure Put >> > ( Item : in Num; >> > Width : in Field := Default_Width; >> > Base : in Number_Base := Default_Base >> > ); >> > >> > should be legal. >> >> I like this. I don't see how it could be a problem. > >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. > >Imagine Ada95 code that defines > > procedure Put (Item: in Num) is -- #1 > begin > Put (Item, Default_Width, Default_Base); -- the Int_IO one, #2 > end Put; > > package Foo_Inst is new Foo; > >Currently this is OK since only #1 matches. With this proposal, #1 and #2 would >be candidates (assuming the latter is directly visible), so the compiler would >not know which to take. This breakes old code. True. It would make some old code ambiguous. However the ambiguity can be relatively easily resolved. >OK, you could complicate the rules by stating that if there is a match without >defaults, this one is preferred, then it would not break old code. No, that would be a mess. >But then you >would introduce another case where adding or removing a declaration silently >changes the code. We surely do not want another such rule. > >[Beaujolais effect, where adding and removing a use clause changes the legal >behaviour, has been removed from Ada with the 95 standard. >Sadly enough, a new effect has been introduced, where adding and removing a with >clause can now change the legal behaviour (think of child packages) - isn't this >called the Ripple effect? >We really do not want another such effect. If you think more closely about it, >such a preference rule would reintroduce the Beaujolais effect.] That's for sure. >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)); (:-)) But I was reluctant in asking too much. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de