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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,e19a809544945098 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!m44g2000hsc.googlegroups.com!not-for-mail From: echancrure@gmail.com Newsgroups: comp.lang.ada Subject: Re: worrying behaviour Date: Fri, 2 May 2008 10:41:01 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: NNTP-Posting-Host: 78.16.189.21 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1209750062 8427 127.0.0.1 (2 May 2008 17:41:02 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 2 May 2008 17:41:02 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: m44g2000hsc.googlegroups.com; posting-host=78.16.189.21; posting-account=j4uaqAoAAAA5AhxfF2TUYlfYDKlx8cY_ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:21175 Date: 2008-05-02T10:41:01-07:00 List-Id: On May 2, 4:54 pm, Adam Beneschan wrote: > On May 2, 8:26 am, echancr...@gmail.com wrote: > > > > > After the discussion on static expressions etc. > > > I came up against this problem which I thought was initially related > > to it but probably not. > > > let's say I have: > > > with Ada.Text_IO; use Ada.Text_IO; > > with ints; > > procedure static is > > function "-"(L, R : ints.My_Int) return ints.My_int renames > > ints."-"; > > function "-"(L : ints.My_Int) return ints.My_int renames ints."-"; > > Y : constant ints.My_int := -1; > > Z : constant ints.My_int := 1-1; > > begin > > Put_Line (ints.My_Int'Image (Y) & ints.My_Int'Image (Z)); > > end static; > > > and > > > package ints > > is > > type My_Int is range -100..100; > > function "-" (L, R : My_Int) return My_int; > > end ints; > > > package body ints > > is > > function "-" (L, R : My_Int) return My_Int > > is > > begin > > return 42; > > end "-"; > > end ints; > > > So basically, I have forgotten to define unary "-" in the the ints > > package. > > It's automatically defined for all integer types (such as My_Int), as > are unary "+" and binary "+", "-", "*", "/", etc. In the Ints > package, you've overridden the binary "-", but the other predefined > operations are not affected and are still visible. So unary "-" does > exist. > > I'm not sure that there's a good solution in Ada. If you really > wanted to make sure that the only operators available for My_Int are > the ones that you remembered to override, you could declare My_Int > private, but then you'd lose the ability to have numeric literals for > that type (in other packages). I suppose that having some sort of > language construct that says "kill all predefined operators for a > type" would be useful in your case. > > On the other hand, your example is obviously not a real-world case, > and I'm having trouble envisioning a case where this would be an > issue. In a real-life situation, either it would be OK to make the > type a private type, or (if the type really were an integer type) > there wouldn't be any problem with allowing the predefined operators > to exist. (Especially unary "-". I know that "*" and "/" can cause > headaches for types that represent measurements, but addition and > comparison operations don't have this issue.) Perhaps someone could > give an example of a situation where a feature that prevents > predefined integer operations from being defined would be useful, but > I can't think of one offhand. > > Are you working on a real-life project where this is a real danger, or > are you simply trying to test your understanding of the language? > > > gnat does not complain and the .exe returns '-1 42' as would be > > expected without the unary - rename. > > > Here however I have renamed the unary - to something that does not > > exist. > > It does exist, as I've explained. > > > Surely an error should be generated here. Otherwise this is very > > dangerous behaviour. > > There are cases where compilers sometimes generate warnings, because > while they are legal Ada there is a very high probability that the > programmer did something wrong. An example would be defining a "+" > function that renames a "*" defined in another package. > > However, defining a unary "-" that renames another unary "-" is a > common idiom (and was even moreso before USE TYPE was added to Ada > 95). I don't see anything in this code that a compiler could > reasonably warn about, although perhaps others may have different > opinions about that. > > -- Adam Thanks Adam for your comprehensive answer. I know there is no error here, I just thought that if you explicitly bother to provide a renaming operator declaration it would be reasonable for the compiler to expect an explicit definition for it... Of course declaring the type private would highlight the problem but ... are you really sure that in the real world those mistakes are not made? (would be pretty hard to detect and would probably only be revealed on boundary cases) After all what is the point of renaming an operator and not provide an actual body for it but the default one? Does it not deserve a warning? Is this allowed in Spark (I think it is but I have no Spark checker)? regards, chris