Unclear error message - please help

Unclear error message - please help

[Alfred Hilscher]

Hello,

I have a problem with some code I've written. The compiler (GNAT 3.15p
on Windows) reports an error whereas I think it should not.


Package spec:

package Pkg is
  procedure Proc (Host : STRING; RC : out Integer; Identifier : in
Integer := 0);

  procedure Proc (Host : STRING;
                 Time_Response : out Integer; RC : out Integer;
                 Time_Wait : Integer := 1000;
                 Identifier : Integer := 0);
end Pkg;


Main program:

with Text_IO;
with Ada.Command_Line;  use Ada.Command_Line;

with Pkg; use Pkg;

procedure PkgTest is
  RC : Integer;
begin
  if Argument_Count /= 1
  then
    Text_IO.Put_Line ("call: PkgTest <ip>");
    return;
  end if;
  
  Proc (Argument (1), RC, 2507);
  Text_IO.Put_Line ("RC=" & Integer'Image (RC));
end PkgTest;


The compiler says, that the procedure call is ambigous, but I think, it
is clear, that "Proc" from line 2 should be used, as it has parameters
(in, out, in) while "Proc" from line 4 has (in, out, out). And the value
(2507) in the call of "Proc" can not be used as an "out" parameter. It
this a know error, or do I have strong misunderstandings there?

pkgtest.adb:15:03: ambiguous expression (cannot resolve "Proc")
pkgtest.adb:15:03: possible interpretation at pkg.ads:4
pkgtest.adb:15:03: possible interpretation at pkg.ads:2

-- 
-----------------------------------------------------
To send me mail, please replace "Spam" by "Jedermann"
-----------------------------------------------------

Re: Unclear error message - please help

[Gene]

Parameter mode is not used in overload resolution.

Re: Unclear error message - please help

[Ludovic Brenta]

Alfred Hilscher <SPAM@alfred-hilscher.de> writes:
> The compiler says, that the procedure call is ambigous, but I think, it
> is clear, that "Proc" from line 2 should be used, as it has parameters
> (in, out, in) while "Proc" from line 4 has (in, out, out). And the value
> (2507) in the call of "Proc" can not be used as an "out" parameter. It
> this a know error, or do I have strong misunderstandings there?
>
> pkgtest.adb:15:03: ambiguous expression (cannot resolve "Proc")
> pkgtest.adb:15:03: possible interpretation at pkg.ads:4
> pkgtest.adb:15:03: possible interpretation at pkg.ads:2

The compiler is correct, because the mode (in, out or in out) is not
considered when resolving overloading.  See the Annotated (not plain)
Ada Reference Manual, 6.4.1(5).

You can resolve the overloading by using named parameter association:

  Proc (Host => Argument (1), RC => RC, Identifier => 2507);


-- 
Ludovic Brenta.

Re: Unclear error message - please help

[Robert A Duff]

Alfred Hilscher <SPAM@alfred-hilscher.de> writes:

> Hello,
> 
> I have a problem with some code I've written. The compiler (GNAT 3.15p
> on Windows) reports an error whereas I think it should not.
> 
> 
> Package spec:
> 
> package Pkg is
>   procedure Proc (Host : STRING; RC : out Integer; Identifier : in
> Integer := 0);
> 
>   procedure Proc (Host : STRING;
>                  Time_Response : out Integer; RC : out Integer;
>                  Time_Wait : Integer := 1000;
>                  Identifier : Integer := 0);
> end Pkg;
> 
> 
> Main program:
> 
> with Text_IO;
> with Ada.Command_Line;  use Ada.Command_Line;
> 
> with Pkg; use Pkg;
> 
> procedure PkgTest is
>   RC : Integer;
> begin
>   if Argument_Count /= 1
>   then
>     Text_IO.Put_Line ("call: PkgTest <ip>");
>     return;
>   end if;
>   
>   Proc (Argument (1), RC, 2507);
>   Text_IO.Put_Line ("RC=" & Integer'Image (RC));
> end PkgTest;
> 
> 
> The compiler says, that the procedure call is ambigous, but I think, it
> is clear, that "Proc" from line 2 should be used, as it has parameters
> (in, out, in) while "Proc" from line 4 has (in, out, out). And the value
> (2507) in the call of "Proc" can not be used as an "out" parameter. It
> this a know error, or do I have strong misunderstandings there?
> 
> pkgtest.adb:15:03: ambiguous expression (cannot resolve "Proc")
> pkgtest.adb:15:03: possible interpretation at pkg.ads:4
> pkgtest.adb:15:03: possible interpretation at pkg.ads:2

As others have said, the compiler is correct.

I think that's a good thing.  The overload resolution rules should not
be "too smart" -- they should allow things to be ambiguous (and
therefore illegal) if there's a likelihood that the reader of the code
will be confused.

I think the call "Proc (Argument (1), RC, 2507);" is confusing, because
it's hard to know which Proc is called.  So it's good that it's illegal.
(It's illegal because parameter modes are not taken into account for
overload resolution.)  It's especially confusing because of all the
defaulted parameters.

When you have two or more parameters of the same type, named notation is
usually a good idea, as somebody suggested.  Otherwise, you might make a
mistake, and pass RC as the actual parameter for the Time_Response
parameter.

Other ideas:

Don't use Integer all over the place, but instead use
different types, to avoid confusion.

Or use two different names, instead of calling both "Proc".

- Bob

Re: Unclear error message - please help

[Alfred Hilscher]

Robert A Duff schrieb:
> 
> Other ideas:
> 
> Don't use Integer all over the place, but instead use
> different types, to avoid confusion.

Ok, I tried it, but it seems that a "subtype" is also not the solution:

package spec:
package Pkg is

  subtype 
    Sixteen_Bits is Integer range 0..65535;
    
  procedure Proc (Host : STRING; RC : out Integer; Identifier : in
Sixteen_Bits := 0);

  procedure Proc (Host : STRING;
                 Time_Response : out Integer; RC : out Integer;
                 Time_Wait : Integer := 10;
                 Identifier : in Sixteen_Bits := 0);
end Pkg;

program:
with Text_IO;
with Ada.Command_Line;  use Ada.Command_Line;

with Pkg; use Pkg;

procedure PkgTest is
  RC : Integer;
begin
  if Argument_Count /= 1
  then
    Text_IO.Put_Line ("call: PkgTest <ip>");
    return;
  end if;
  
  Proc (Argument (1), RC, Sixteen_Bits (2507));
  Text_IO.Put_Line ("RC=" & Integer'Image (RC));
end PkgTest;

 
> Or use two different names, instead of calling both "Proc".

No, that's not what I want. The advantage of Ada against other languages
is the overloading: that same things can have the same name(e.g. Put for
all types, unlike WriteInt, WriteCard ... in Modula).
 
> - Bob

Alfred

-- 
-----------------------------------------------------
To send me mail, please replace "Spam" by "Jedermann"
-----------------------------------------------------

Re: Unclear error message - please help

[Björn Persson]

Alfred Hilscher wrote:
> Ok, I tried it, but it seems that a "subtype" is also not the solution:

It compiles if you make Sixteen_Bits a type instead of a subtype:

type Sixteen_Bits is new Integer range 0..65535;

-- 
Bj�rn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: Unclear error message - please help

[Martin Krischik]

Bjï¿œrn Persson wrote:

> Alfred Hilscher wrote:
>> Ok, I tried it, but it seems that a "subtype" is also not the solution:
> 
> It compiles if you make Sixteen_Bits a type instead of a subtype:
> 
> type Sixteen_Bits is new Integer range 0..65535;

But that would be 17 bit type. 

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Unclear error message - please help

[Dmitry A. Kazakov]

On Sat, 08 Oct 2005 21:39:35 +0200, Alfred Hilscher wrote:

> Robert A Duff schrieb:
>> 
>> Don't use Integer all over the place, but instead use
>> different types, to avoid confusion.
> 
> Ok, I tried it, but it seems that a "subtype" is also not the solution:

That cannot have any effect. Subtypes do not resolve ambiguity.
 
> package spec:
> package Pkg is
> 
>   subtype 
>     Sixteen_Bits is Integer range 0..65535;
>     
>   procedure Proc (Host : STRING; RC : out Integer; Identifier : in
> Sixteen_Bits := 0);
> 
>   procedure Proc (Host : STRING;
>                  Time_Response : out Integer; RC : out Integer;
>                  Time_Wait : Integer := 10;
>                  Identifier : in Sixteen_Bits := 0);
> end Pkg;

Why Time_Wait, Time_Response are Integers? Consider making them Time
(absolute time is always more reliable), or maybe Duration (time span) or
at least

   type Milliseconds is new Natural; -- This is not Integer!

Similarly Identifier should be a different type, probably a modular one,
better private.

   type Sixteen_Bits is mod 2**16; 

It could look like:

type ID is private;
No_ID : constant ID;

procedure Proc
          (  Host : String;
             Count : out Natural;
             Identifier : ID := No_ID
          );

procedure Proc
          (  Host : String;
             Count : out Natural;
             Time_Stamp : out Time;
             Time_Out : Duration := 0.01;
             Identifier : ID := No_ID
          );

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Unclear error message - please help

[Robert A Duff]

Alfred Hilscher <SPAM@alfred-hilscher.de> writes:

> Robert A Duff schrieb:
> > 
> > Other ideas:
> > 
> > Don't use Integer all over the place, but instead use
> > different types, to avoid confusion.
> 
> Ok, I tried it, but it seems that a "subtype" is also not the solution:

When I said "different types" I didn't mean "subtypes".

> package spec:
> package Pkg is
> 
>   subtype 
>     Sixteen_Bits is Integer range 0..65535;

This is just a subtype of Integer, not a different type.  To declare
different _types_, you say something like:

    type Apple_Count is range 1..100;
    type Orange_Count is range 1..100;

These are two different types, and different from Integer, too.
Overloading is based on _types_, not subtypes.

It depends on what you're doing, but I suspect Sixteen_Bits is not a
good name for a type.  Name your types after what you're measuring our
counting or indexing or whatever -- not how big they are.

>   procedure Proc (Host : STRING; RC : out Integer; Identifier : in
> Sixteen_Bits := 0);
> 
>   procedure Proc (Host : STRING;
>                  Time_Response : out Integer; RC : out Integer;
>                  Time_Wait : Integer := 10;
>                  Identifier : in Sixteen_Bits := 0);

Think about this: Why are return codes and amounts of time the "same
type"?  And "identifiers"?

> end Pkg;
> 
> program:
> with Text_IO;
> with Ada.Command_Line;  use Ada.Command_Line;
> 
> with Pkg; use Pkg;
> 
> procedure PkgTest is
>   RC : Integer;
> begin
>   if Argument_Count /= 1
>   then
>     Text_IO.Put_Line ("call: PkgTest <ip>");
>     return;
>   end if;
>   
>   Proc (Argument (1), RC, Sixteen_Bits (2507));
                            ^^^^^^^^^^^^^^^^^^^

I think you meant "Sixteen_Bits'(2507)".

That is, a qualified expression, not a type conversion.

>   Text_IO.Put_Line ("RC=" & Integer'Image (RC));
> end PkgTest;
> 
>  
> > Or use two different names, instead of calling both "Proc".
> 
> No, that's not what I want. The advantage of Ada against other languages
> is the overloading: that same things can have the same name(e.g. Put for
> all types, unlike WriteInt, WriteCard ... in Modula).
>  
> > - Bob
> 
> Alfred
> 
> -- 
> -----------------------------------------------------
> To send me mail, please replace "Spam" by "Jedermann"
> -----------------------------------------------------

Re: Unclear error message - please help

[Martin Krischik]

Alfred Hilscher wrote:

>   subtype
>     Sixteen_Bits is Integer range 0..65535;

The name "Sixteen_Bits" suggest a different implementation:

type Sixteen_Bits is mod 2 ** 16;
for Sixteen_Bits'Size use 16;

A "range 0..65535" needs 17 bits and an "is Integer" is usually 32 bit.

See

http://en.wikibooks.org/wiki/Ada_Programming/Types/range
http://en.wikibooks.org/wiki/Ada_Programming/Types/mod

for more info.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Unclear error message - please help

[Robert A Duff]

Martin Krischik <krischik@users.sourceforge.net> writes:

> Alfred Hilscher wrote:
> 
> >   subtype
> >     Sixteen_Bits is Integer range 0..65535;
> 
> The name "Sixteen_Bits" suggest a different implementation:
> 
> type Sixteen_Bits is mod 2 ** 16;
> for Sixteen_Bits'Size use 16;
> 
> A "range 0..65535" needs 17 bits and an "is Integer" is usually 32 bit.

I don't really agree with that advice.  Modular types should be used
only in certain rare circumstances.  (They are, perhaps, my least
favorite feature of Ada.)

Anyway, Sixteen_Bits is 16 bits.  I mean, Sixteen_Bits'Size = 16.
There's no implementation choice here -- that's required of all
implementations.  And you can use rep clauses or pragmas Pack
to ensure that objects of this subtype are actually allocated
16 bits.  Without such clauses or Pack, the compiler is free
to do whatever it likes -- probably allocate 32 bits for each object.
17 bits is pretty unlikely!  ;-)

Arithmetic will be done in the base range, however -- you'll get
overflows past Integer'First..Integer'Last, not 0..2**16-1.

> See
> 
> http://en.wikibooks.org/wiki/Ada_Programming/Types/range
> http://en.wikibooks.org/wiki/Ada_Programming/Types/mod
> 
> for more info.

- Bob

Re: Unclear error message - please help

[Brian May]

>>>>> "Martin" == Martin Krischik <krischik@users.sourceforge.net> writes:

    Martin> A "range 0..65535" needs 17 bits and an "is Integer" is
    Martin> usually 32 bit.

    Martin> See

    Martin> http://en.wikibooks.org/wiki/Ada_Programming/Types/range
    Martin> http://en.wikibooks.org/wiki/Ada_Programming/Types/mod

    Martin> for more info.

I read the above links but didn't see why a range 0..65535 requires 17
bits.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Unclear error message - please help

[Martin Krischik]

Brian May wrote:

>>>>>> "Martin" == Martin Krischik <krischik@users.sourceforge.net> writes:
> 
>     Martin> A "range 0..65535" needs 17 bits and an "is Integer" is
>     Martin> usually 32 bit.
> 
>     Martin> See
> 
>     Martin> http://en.wikibooks.org/wiki/Ada_Programming/Types/range
>     Martin> http://en.wikibooks.org/wiki/Ada_Programming/Types/mod
> 
>     Martin> for more info.
> 
> I read the above links but didn't see why a range 0..65535 requires 17
> bits.

All range types alow for positive and negative values - even when the
subtype is restricted to a positive range - so they need a sign bit.

That means the compiler needs to support:

 X : Sixteen_Bits'Base := - 65535;

Most likely Sixteen_Bits'Base'Size will be 32 bit.

Others pointed out that you can request the data to be packed - which
slipped my mind when I was writing the post - sorry about that. In fact you
can pack a range 1000 .. 1255 into 8 bit if you want to.

So I stand corrected in that you need only need 16 after all.

However data which has been packed need to be unpacked to do anything
usefull with them. Performance depends on how well the compiler will handle
the packing/unpacking.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Unclear error message - please help

[Brian May]

>>>>> "Martin" == Martin Krischik <krischik@users.sourceforge.net> writes:

    Martin> All range types alow for positive and negative values -
    Martin> even when the subtype is restricted to a positive range -
    Martin> so they need a sign bit.

In another thread I asked if it was possible to have a unsigned 64 bit
number on a 32 bit platform - the answer was yes.

People showed me the specification of a built-in Ada package to prove
it. Sorry I can't remember the exact name of the Package
(os.interfaces???), and I don't have time to check now either.

Nobody mentioned anything about packing (that I noticed) either.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Unclear error message - please help

[Martin Dowie]

Brian May wrote:
>>>>>>"Martin" == Martin Krischik <krischik@users.sourceforge.net> writes:
> 
> 
>     Martin> All range types alow for positive and negative values -
>     Martin> even when the subtype is restricted to a positive range -
>     Martin> so they need a sign bit.
> 
> In another thread I asked if it was possible to have a unsigned 64 bit
> number on a 32 bit platform - the answer was yes.
> 
> People showed me the specification of a built-in Ada package to prove
> it. Sorry I can't remember the exact name of the Package
> (os.interfaces???), and I don't have time to check now either.

Interfaces

> Nobody mentioned anything about packing (that I noticed) either.

No need for modular types.

Cheers

-- Martin

Re: Unclear error message - please help

[Martin Krischik]

Brian May wrote:

>>>>>> "Martin" == Martin Krischik <krischik@users.sourceforge.net> writes:
> 
>     Martin> All range types alow for positive and negative values -
>     Martin> even when the subtype is restricted to a positive range -
>     Martin> so they need a sign bit.
> 
> In another thread I asked if it was possible to have a unsigned 64 bit
> number on a 32 bit platform - the answer was yes.
> 
> People showed me the specification of a built-in Ada package to prove
> it. Sorry I can't remember the exact name of the Package
> (os.interfaces???), and I don't have time to check now either.
 
> Nobody mentioned anything about packing (that I noticed) either.

Unsigned type are created with the keyword "mod" while the keyword "range"
creates signed integer. Ok, I confess that needs a bit of getting used to.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Unclear error message - please help

[Robert A Duff]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

> On Mon, 10 Oct 2005 08:02:07 +1000, Brian May <bam@snoopy.apana.org.au>
> declaimed the following in comp.lang.ada:
> 
> > 
> > I read the above links but didn't see why a range 0..65535 requires 17
> > bits.
> 
> 	I haven't dug up the reference books, but I seem to recall that, for
> a non-MOD type, the /base/ storage is assumed to be signed. So...
> 0..65535 implies a base of -65535..65535; with a run-time check that no
> negatives are allowed.
> 
> 	Ah... Page 39 of my old reference manual
> 
> """
> A signed_integer_type_definition defines an integer type whose base
> range includes at least the values of the simple_expressions and is
> symmetric about zero, excepting possibly an extra negative value. A
> signed_integer_type_definition also defines a constrained first subtype
> of the type, with a range whose bounds are given by the values of the
> simple_expressions, converted to the type being defined.
> """
> 
> Keywords: base range; symmetric about zero.

Right.  But don't confuse the base range with the memory size of
values/objects of that subtype.

The base range determines how arithmetic works: overflow will not
happen, so long as you stay within that base range.  So, for example,
(X+Y)/2 will not overflow, so long as the value of X+Y is within the
base range.

But the object X might be stored in a smaller number of bits than the
base range requires.  Normally, the compiler will store X in a register
or memory location that matches the base range, for efficiency, but you
can request smaller memory size with all kinds of rep clauses/pragmas.

Anyway, I think the original post showed a [sub]type derived from
Integer, so it will have the same base range as Integer (perhaps 32
bits).

- Bob