Re: worrying behaviour

[echancrure@gmail.com]

On May 2, 4:54 pm, Adam Beneschan <a...@irvine.com> 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