Generics not overloadable

Generics not overloadable

[Mark Lundquist]

Generic units cannot be overloaded.

That is a bother.

Apparently this is to allow for a name denoting a generic_declaration,
occurring within the generic_formal_part of the same generic_declaration, to
denote the generic unit itself [AARM 8.6(18b)].

Questions:

1) Do I understand this correctly (that this is the reason generics are not
overloadable)?

2) Of what use is a name denoting a generic unit within its own formal part?
You certainly can't instantiate the generic there.  What else can you bloody
well do with a generic unit (in general) besides instantiate it?

3) In any case, why could overloading rules not just as well apply to
generic unit names both outside the generic and within the formal parts?

4) Is there anything else that could be done to fix this (make generics
overloadable)?

And now some questions for the language lawyers (these are "help me get to
know my RM better" questions):

5) I could not actually find the rule covering resolution of a generic unit
name denoting a generic_declaration within the unit's own formal part.
There are a couple of rules that refer to such a rule, but where's the
actual rule?  I was looking for a Name Resolution Rule somewhere, like in
12.1...

6) The aforementioned paragraph in the AARM says that the rule in question
"implies" that generics are not overloadable.  It certainly stands to reason
that generics cannot be overloaded in light of such a rule, but I took
"implies" in the technical sense: that is, that this rule in combination
with some other rules entails the result.  What would those other rules be?

Thanks,
Mark Lundquist
http://members.home.com/mlundquist2/consulting

Generics not overloadable

[Mark Lundquist]

I posted this earlier today, but I never saw the post show up, so maybe it
went into the bit-bucket for some reason.  Here it is again just in case...

----
Generic units cannot be overloaded.

That is a bother.

Apparently this is to allow for a name denoting a generic_declaration,
occurring within the generic_formal_part of the same generic_declaration, to
denote the generic unit itself [AARM 8.6(18b)].

Questions:

1) Do I understand this correctly (that this is the reason generics are not
overloadable)?

2) Of what use is a name denoting a generic unit within its own formal part?
You certainly can't instantiate the generic there.  What else can you bloody
well do with a generic unit (in general) besides instantiate it?

3) In any case, why could overloading rules not just as well apply to
generic unit names both outside the generic and within the formal parts?

4) Is there anything else that could be done to fix this (make generics
overloadable)?

And now some questions for the language lawyers (these are "help me get to
know my RM better" questions):

5) I could not actually find the rule covering resolution of a generic unit
name denoting a generic_declaration within the unit's own formal part.
There are a couple of rules that refer to such a rule, but where's the
actual rule?  I was looking for a Name Resolution Rule somewhere, like in
12.1...

6) The aforementioned paragraph in the AARM says that the rule in question
"implies" that generics are not overloadable.  It certainly stands to reason
that generics cannot be overloaded in light of such a rule, but I took
"implies" in the technical sense: that is, that this rule in combination
with some other rules entails the result.  What would those other rules be?

Thanks,
Mark Lundquist
http://members.home.com/mlundquist2/consulting

Re: Generics not overloadable

[Ted Dennison]

In article <ypcN7.89512$XJ4.49083085@news1.sttln1.wa.home.com>, Mark Lundquist
says...
>
>I posted this earlier today, but I never saw the post show up, so maybe it
>went into the bit-bucket for some reason.  Here it is again just in case...

I for one did see it. I just don't have good answers for you. Our language
lawyers seem to be on vacation today. :-)

>Generic units cannot be overloaded.
>
>That is a bother.

All I can say is that this is a nit that's been with Ada since the '83 days. It
annoyed me too when I discovered it, but that was back in '89. By now its just
something I intuitively code around.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Generics not overloadable

[Robert Dewar]

Ted Dennison<dennison@telepath.com> wrote in message news:<VGcN7.41331$xS6.69936@www.newsranger.com>...

> It annoyed me too when I discovered it

I find it hard to believe that it would be easy to come
up with an example where it would help the reader to
name two visible generic units with the same name.

Indeed, far too often overloading in Ada is misused to
save the bother of thinking of different names. You should
only overload by deliberate decision where it makes reading
clearer, otherwise overloading can confuse a reader.

Re: Generics not overloadable

[R. Tim Coslet]

Also overloading prevents separating the unit.

-- 
        R. Tim Coslet
        r_tim_coslet@pacbell.net

Technology, n. Domesticated natural phenomena.


> From: dewar@gnat.com (Robert Dewar)
> Organization: http://groups.google.com/
> Newsgroups: comp.lang.ada
> Date: 28 Nov 2001 19:41:52 -0800
> Subject: Re: Generics not overloadable
> 
> Ted Dennison<dennison@telepath.com> wrote in message
> news:<VGcN7.41331$xS6.69936@www.newsranger.com>...
> 
>> It annoyed me too when I discovered it
> 
> I find it hard to believe that it would be easy to come
> up with an example where it would help the reader to
> name two visible generic units with the same name.
> 
> Indeed, far too often overloading in Ada is misused to
> save the bother of thinking of different names. You should
> only overload by deliberate decision where it makes reading
> clearer, otherwise overloading can confuse a reader.

Re: Generics not overloadable

[Ian Wild]

Mark Lundquist wrote:
> 
... 
> 2) Of what use is a name denoting a generic unit within its own formal part?
> You certainly can't instantiate the generic there.  What else can you bloody
> well do with a generic unit (in general) besides instantiate it?

It can call itself recursively.

Re: Generics not overloadable

[Mark Lundquist]

"Ian Wild" <ian@cfmu.eurocontrol.int> wrote in message
news:3C0611EB.F7E0E1A9@cfmu.eurocontrol.int...
> Mark Lundquist wrote:
> >
> ...
> > 2) Of what use is a name denoting a generic unit within its own formal
part?
> > You certainly can't instantiate the generic there.  What else can you
bloody
> > well do with a generic unit (in general) besides instantiate it?
>
> It can call itself recursively.

Huh?

Yes - a name occuring within the body of the generic unit denoted by that
name refers to the "current instance" of the generic.

I believe that's what you're talking about -- but that's not what my post
was about :-)

-- mark

Re: Generics not overloadable

[Nick Roberts]

I think what Ian meant was that a generic unit can be a function, and some
functions are recursive. E.g.:

   generic
      type Number is range <>;
   function Factorial (N: in Number) return Number;

   function Factorial (N: in Number) return Number is
   begin
      if N < 0 then raise Constraint_Error; end if;
      if N < 2 then return 1; end if;
      return N * Factorial(N-1);
   end;

Here the last occurance of 'Factorial' is the use of the generic unit's name
as its current instance in order to make a recursive call upon itself.

--
Best wishes,
Nick Roberts

Re: Generics not overloadable

[Mark Lundquist]

"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0111281941.2620b70a@posting.google.com...
> Ted Dennison<dennison@telepath.com> wrote in message
news:<VGcN7.41331$xS6.69936@www.newsranger.com>...
>
> > It annoyed me too when I discovered it
>
> I find it hard to believe that it would be easy to come
> up with an example where it would help the reader to
> name two visible generic units with the same name.

Why should it make a difference whether they are generic?  The principle is
the same.  As for examples, just about anything will do, but here's one
(self-explanatory, I trust)...

    generic
        with procedure Action (On : Item);
    procedure Apply (Over : Collection);

    generic
        with procedure Action (On : Item; Continue : out Boolean);
    procedure Apply (Over : Collection);

    generic
        with procedure Action (On : Item);
    procedure Apply (Start, Finish : in Iterator);

    generic
        with procedure Action (On : Item; Continue : out Boolean);
    procedure Apply (Start, Finish : in Iterator);

The user should not have to remember a different fiddly specialized name for
each variant.   It's much more natural, and easier on the user,  if each can
be called simply "Apply".

>
> Indeed, far too often overloading in Ada is misused to
> save the bother of thinking of different names.

Maybe so, but not by me :-).  I take naming too seriously, if anything :-).
Incidentally, I realized the reason for the language rule that makes it
impossible to overload generics.  The wonderful benefit :-) is that I can
write

    generic
        type Foo is private;
        with procedure Something (Foo : X.Foo);
    package X is
        .
        .

Talk about "saving the bother of thinking of different names"!

I'd gladly trade away this liberty in the generic formal part for the
ability to overload generics.

-- mark

Re: Generics not overloadable

[Stephen Leake]

"Mark Lundquist" <mlundquist2@attbi.com> writes:

> "Robert Dewar" <dewar@gnat.com> wrote in message
> news:5ee5b646.0111281941.2620b70a@posting.google.com...
> > Ted Dennison<dennison@telepath.com> wrote in message
> news:<VGcN7.41331$xS6.69936@www.newsranger.com>...
> >
> > > It annoyed me too when I discovered it
> >
> > I find it hard to believe that it would be easy to come
> > up with an example where it would help the reader to
> > name two visible generic units with the same name.
> 
> Why should it make a difference whether they are generic?  The principle is
> the same.  As for examples, just about anything will do, but here's one
> (self-explanatory, I trust)...

I'll weigh in with Robert here; I find this abhorrent :).

>     generic with procedure Action (On : Item); procedure Apply (Over
>     : Collection);
> 
>     generic
>         with procedure Action (On : Item; Continue : out Boolean);
>     procedure Apply (Over : Collection);
> 
>     generic
>         with procedure Action (On : Item);
>     procedure Apply (Start, Finish : in Iterator);
> 
>     generic
>         with procedure Action (On : Item; Continue : out Boolean);
>     procedure Apply (Start, Finish : in Iterator);
> 
> The user should not have to remember a different fiddly specialized name for
> each variant.   It's much more natural, and easier on the user,  if each can
> be called simply "Apply".

This seems true, until you get to the instantiations. Taking your
approach, all three would be identical, assuming appropriately
overloaded procedures 'My_Action':

procedure My_Apply is new Apply (Action => My_Action);
procedure My_Apply is new Apply (Action => My_Action);
procedure My_Apply is new Apply (Action => My_Action);

Obviously, the compiler has no chance to sort this out. But the
argument is that it is bad for the reader. Suppose we forgot one of
these (assuming there were some way to make it legal). Later, when we
try to call the missing My_Apply, the compiler says "no procedure
matching My_Apply is visible". So we come back to here and say "Yes it
is!". 

Too confusing. This is better:

procedure My_Apply is new Apply_Over_Boolean (My_Action);
procedure My_Apply is new Apply_Start_Finish (My_Action);
procedure My_Apply is new Apply_Start_Finish_Boolean (My_Action);

Now both the compiler and the reader can sort things out.
> 
> 
> >
> > Indeed, far too often overloading in Ada is misused to save the
> > bother of thinking of different names.
> 
> Maybe so, but not by me :-).  I take naming too seriously, if anything :-).
> Incidentally, I realized the reason for the language rule that makes it
> impossible to overload generics.  

I'm not sure you have; did you consider trying to instantiate your example?

-- 
-- Stephe