Re: Generic default parameters

Re: Generic default parameters

[Grein, Christoph]

> > 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.

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. 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.]

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.

Re: Generic default parameters

[Dmitry A. Kazakov]

On Tue, 14 May 2002 06:57:52 +0200 (MET DST), "Grein, Christoph"
<christoph.grein@eurocopter.com> 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

Re: Generic default parameters

[Grein, Christoph]

> >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.
> ...
> True. It would make some old code ambiguous. However the ambiguity can
> be relatively easily resolved.

Easy or not, only if absolutely necessary would the ARG be willing to change the 
language in a way that is upwardly incompatible. This proposal does not seem 
worth it.

> >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));

This is invalid syntax (I can imagine what you mean - it's a mess). But the 
rules would not be so simple. Defaulted parameters need not come last (in this 
way you force named association when omitting parameters).

So would either subprogram

  procedure (X: S; Y: T := Def);
  procedure (X: T := Def; Y: S);

match

  procedure (W: S);

What about

  procedure (X: S; Y: S := Def);
  procedure (X: S := Def; Y: S);

Would they both match?

Re: Generic default parameters

[Dmitry A. Kazakov]

On Tue, 14 May 2002 13:03:46 +0200 (MET DST), "Grein, Christoph"
<christoph.grein@eurocopter.com> wrote:

>> >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.
>> ...
>> True. It would make some old code ambiguous. However the ambiguity can
>> be relatively easily resolved.
>
>Easy or not, only if absolutely necessary would the ARG be willing to change the 
>language in a way that is upwardly incompatible. This proposal does not seem 
>worth it.

I have no illusions. (:-))

Well, it is not so hard to write wrappers, however it is nasty,
especially when an instantiation happens at library level. Then one
needs a special package to pack dirty clothes there.

>> >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));
>
>This is invalid syntax

Yep, I just added function composition, which differs not very much
from providing a value to a parameter, for both go in the direction of
specializing subprograms without wrappers.

>(I can imagine what you mean - it's a mess). But the 
>rules would not be so simple. Defaulted parameters need not come last (in this 
>way you force named association when omitting parameters).
>
>So would either subprogram
>
>  procedure (X: S; Y: T := Def);
>  procedure (X: T := Def; Y: S);
>
>match
>
>  procedure (W: S);

Only the first matches. The rules should be same as in case of
overloading:

   procedure A (X: S; Y: T := Def);
   procedure A (X: T := Def; Y: S);
   W : S;
...
   A (W); -- It is unambiguous, so should be
...
   procedure B (W: S) renames A;  -- OK, the first one
--
-- To rename the second:
--
   procedure C (W: S) renames A (Y=>W); -- Named association
   procedure D (W: S) renames A (T'First); -- Another value for X

>What about
>
>  procedure (X: S; Y: S := Def);
>  procedure (X: S := Def; Y: S);
>
>Would they both match?

Yes, because one is a homograph of another.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Generic default parameters

[Stephen Leake]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:

> On Tue, 14 May 2002 13:03:46 +0200 (MET DST), "Grein, Christoph"
> <christoph.grein@eurocopter.com> wrote:
> 
> >What about
> >
> >  procedure (X: S; Y: S := Def);
> >  procedure (X: S := Def; Y: S);
> >
> >Would they both match?
> 
> Yes, because one is a homograph of another.

This is truly horrible! Hmm, maybe you meant to say "they both match,
so the instantiation fails".

Let's let this die; it turns out to be a bad idea. Next time, I'll try
harder to find something wrong with an idea before I endorse it :).

-- 
-- Stephe

Re: Generic default parameters

[Dmitry A. Kazakov]

On 14 May 2002 10:05:44 -0400, Stephen Leake
<stephen.a.leake.1@gsfc.nasa.gov> wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
>
>> On Tue, 14 May 2002 13:03:46 +0200 (MET DST), "Grein, Christoph"
>> <christoph.grein@eurocopter.com> wrote:
>> 
>> >What about
>> >
>> >  procedure (X: S; Y: S := Def);
>> >  procedure (X: S := Def; Y: S);
>> >
>> >Would they both match?
>> 
>> Yes, because one is a homograph of another.
>
>This is truly horrible!

Why something horrible for instantiations is not horrible for calls?
Ambiguities are unavoidable when a language has overloading. Backward
compatibility, that's the problem.

>Hmm, maybe you meant to say "they both match,
>so the instantiation fails".

Yes.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Generic default parameters

[Thomas Wolf]

It seems I'm not alone with these ideas... so let's summarize
and see if we can get a halfway decent proposal for the ARG
out of the discussions:

Ada 95 lacks features for:

1. specifying a default type for generic formal type parameters

   The idea would be to allow something like

   generic
      type Something is range <> := Natural;

   and if an instantiation does *not* supply an actual for
   'Something', 'Natural' will be taken.

2. specifying a default for generic formal package parameters:

   generic
      with package X is new Y (<>) := Z;

   where Z of course would have to be an instantiation of Y.

   Or maybe even

   generic
      with package X is new Y (<>) := Y (Param1 => Default1,
                                         Param2 => Default2,
                                         ...);

   i.e., allow the default to be an anonymous instance?
   (I guess, the first variant is sufficient, and the second
   would only unnecessarily complicate matters.)

3. specify a default for a generic formal "in out" object:

   with System.Storage_Pools;
   generic
      type Something is private;
      Pool : in out System.Storage_Pools.Root_Storage_Pool'Class :=
         Some_Default_Pool_Instance;
   package X is
      type Some_Access is access all Something;
      for Some_Access'Storage_Pool use Pool;
      ...

4. providing defaults in a generic renaming:

   generic
     type Something is private;
   package A is ...

   generic package B renames A (Something => Integer);

   or even

   generic
     type Something is range <> := Natural;
   package C is ...

   generic package D renames C (Something => Integer);

5. Linked to (3) above: some way to specify a storage pool that
   is equal to whatever pool the compiler would use if no
   "for Some_Access'Storage_Pool use ..." clause was present, i.e.
   a generic way to refer to the standard storage pool of a type
   without referring to the type. Something like

   generic
      type Something is private;
      Pool : in out System.Storage_Pools.Root_Storage_Pool'Class := <>;
   package X is
      type Some_Access is access all Something;
      for Some_Access'Storage_Pool use Pool;
      ...

   and if an instantiation provides an actual for 'Pool', that will
   be taken as the storage pool of type 'Some_Access', but if an
   instantiation doesn't provide an actual, 'Some_Access' will use
   a standard storage pool.

   Not sure if point (5) makes sense, especially since it would be
   useful only for storage pools, but make no sense at all for other
   types...

Personally, I have encountered several occasions where I would have
liked to have some (or all) of these features. They'd help a lot in
writing general generics (:-) that still are simple to instantiate.
 
Comments, anyone? Would these things be worth to consider for inclusion
in the next Ada revision? 

-- 
-----------------------------------------------------------------
Thomas Wolf                          e-mail: t_wolf@angelfire.com

Re: Generic default parameters

[Preben Randhol]

On Fri, 10 May 2002 16:22:50 +0200, Thomas Wolf wrote:
> 
> It seems I'm not alone with these ideas... so let's summarize
> and see if we can get a halfway decent proposal for the ARG
> out of the discussions:
> 
> Ada 95 lacks features for:
> 
> 1. specifying a default type for generic formal type parameters
> 
>    The idea would be to allow something like
> 
>    generic
>       type Something is range <> := Natural;
> 
>    and if an instantiation does *not* supply an actual for
>    'Something', 'Natural' will be taken.

I actually like that Ada95 doesn't allow a default value, and I don't
understand what the gain is in a default value. Expecially not for
generic pacakges. If one want a default value why don't just do:

package Some_Package is 
   new Some_Generic_Pacakge (Data_Type => Some_Default_Type);

in a package and use this?

Preben

Re: Generic default parameters

[Marin David Condic]

For the same reason that (in effect) you can have a "default value" for
functions. You say you want a "<" function and with the "is <>" part you are
saying, "But if one is already defined and you don't need to override it for
any reason, then you can save yourself the effort."

In your example, this is fine for a generic where you want only one
parameter to default (or all parameters to default). What if you have 5
parameters and only two of them can sensibly have a default? You can't
pre-instantiate with just the two parameters. (Although this might pose a
solution that requires no new syntax..... Hmmm......) In the case of Lists,
the type of element you're storing should never default because it doesn't
make sense. However the data type of a returned element count might sanely
default to Natural unless the user has something else in mind. How would you
pre-instantiate that with a default value when you have no default element
type?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnadnts9.42d.randhol+abuse@kiuk0156.chembio.ntnu.no...
>
> I actually like that Ada95 doesn't allow a default value, and I don't
> understand what the gain is in a default value. Expecially not for
> generic pacakges. If one want a default value why don't just do:
>
> package Some_Package is
>    new Some_Generic_Pacakge (Data_Type => Some_Default_Type);
>
> in a package and use this?
>
> Preben

Re: Generic default parameters

[Simon Wright]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> In your example, this is fine for a generic where you want only one
> parameter to default (or all parameters to default). What if you have 5
> parameters and only two of them can sensibly have a default? You can't
> pre-instantiate with just the two parameters. (Although this might pose a
> solution that requires no new syntax..... Hmmm......) In the case of Lists,
> the type of element you're storing should never default because it doesn't
> make sense. However the data type of a returned element count might sanely
> default to Natural unless the user has something else in mind. How would you
> pre-instantiate that with a default value when you have no default element
> type?

I think what you're discussing here is related to "traits" in the C++
world??? (something that's a black mystery to me). Or perhaps it's
"partial specialization".

Anyway, this would be very useful, I think, in simplifying a complex
generic arrangement like the BCs'.

Re: Generic default parameters

[Hyman Rosen]

Simon Wright wrote:
> I think what you're discussing here is related to "traits" in the C++
> world??? (something that's a black mystery to me). Or perhaps it's
> "partial specialization".

Let me try to explain what these are.
In C++, the equivalent of an Ada generic package is a class template.
In Ada, once you have a generic package, it is a fixed thing. You can
instantiate man packages from the generic, but they all share the same
specification and implementation code. In C++, you can write a partial
specialization, which causes an entirely different declaration and
implementation code to be used when the template is instantiated for
certain values of the generic parameters. (A refinement of this is the
explicit specialization, which is a specialization written for a single
set of generic parameter values.)

Here's a silly example of a compile-time factorial calculator:

// generic template
template<int N> struct factorial { enum { val = N * factorial<N-1>::val }; };
// specialization for N == 0
template<> struct factorial<0> { enum { val = 1 }; };
int f6 = factorial<6>::val;	// evaluates to 720 at compile-time

The compiler uses the generic template unless the template parameter
is zero, whereupon it uses the special case provided.

Then you can think of traits as the equivalent of Ada having user-defined
attributes. You write a class template that contains type definitions or
constants pertaining to a type, that you can't get from the compiler itself,
and then you write specializations for the types you need.

> Anyway, this would be very useful, I think, in simplifying a complex
> generic arrangement like the BCs'.

Yes, that's exactly the idea.

Re: Generic default parameters

[Preben Randhol]

On Fri, 10 May 2002 12:50:52 -0400, Marin David Condic wrote:

> For the same reason that (in effect) you can have a "default value"
> for functions. You say you want a "<" function and with the "is <>"
> part you are saying, "But if one is already defined and you don't need
> to override it for any reason, then you can save yourself the
> effort."
> 
> In your example, this is fine for a generic where you want only one
> parameter to default (or all parameters to default). What if you have
> 5 parameters and only two of them can sensibly have a default? You
> can't pre-instantiate with just the two parameters. (Although this
> might pose a solution that requires no new syntax..... Hmmm......) In
> the case of Lists, the type of element you're storing should never
> default because it doesn't make sense. However the data type of a
> returned element count might sanely default to Natural unless the user
> has something else in mind. How would you pre-instantiate that with a
> default value when you have no default element type?

I'm not sure I understand. If you have 5 parameters and only two can
have a default then I don't see why giving the generic defaults would
help. To me it sounds like making generics less strongly typed/more
dynamic, but probably I misunderstand you :-)

Preben
-- 

Re: Generic default parameters

[Marin David Condic]

The original issue was one of bringing in a "Count Of List Elements" type as
a generic parameter. You have to bring in the element type because you can't
know what that should be in advance. However, you *might* want to say
"Unless Otherwise Directed Make The Count Of List Elements Be 'Natural'" -
the reason being that for a large number of simple cases, you may never want
anything more specialized than Natural - so you don't want the extra work of
specifying it in the instantiation. Yet you want the ability to override the
default from time to time if for some reason you *do* want a more
specialized type. Example:

generic
    type Element_Type is private ;
    type Element_Count is range <> => Natural ; -- or whatever syntax
package Lists is.....

and then....

package My_Simple_Lists is new Lists (Element_Type => Some_Type);

(Here I got a list that will be counted up with Natural)

package
    My_Really_Strongly_Typed_Lists
is new
    Lists (
        Element_Type => Apple_Type,
        Element_Count =>
Apple_Counter_Not_To_Be_Confused_With_Apple_Cart_Pushers_Counters);

The idea is to let the obsessive-compulsives get what they want without
bumming out the laid-back, chilling dudes for whom Natural is good enough.
:-)

From here, I might imagine a case where for a more complex generic parameter
list, I might have half of the parameters have defaults the other half are
"must supply" parameters. Think of when you might have a function or
procedure in which you have default values for parameters. Same thing.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnadq3j5.1cf.randhol+abuse@kiuk0156.chembio.ntnu.no...
>
> I'm not sure I understand. If you have 5 parameters and only two can
> have a default then I don't see why giving the generic defaults would
> help. To me it sounds like making generics less strongly typed/more
> dynamic, but probably I misunderstand you :-)
>

Re: Generic default parameters

[Hyman Rosen]

Preben Randhol wrote:
> I'm not sure I understand. If you have 5 parameters and only two can
> have a default then I don't see why giving the generic defaults would
> help.

If the default case is common, then users instantiating the generic
would usually specify only the three parameters which have no default.
Really, I don't see why you are having so much difficulty with this
concept. Defaults are never necessary; they are a device to simplify
user code when you want to offer seldom-used versatility. That Ada
has them at all is a sign that the designers though them useful.
Therefore they may be useful in further contexts as well, especially
as experience is gained from such uses in other languages.

Re: Generic default parameters

[Hyman Rosen]

Preben Randhol wrote:
> I actually like that Ada95 doesn't allow a default value, and I don't
> understand what the gain is in a default value.

Ada allows default values in other contexts.
What is the gain there? Why do you think the
same doesn't apply here?

Re: Generic default parameters

[Preben Randhol]

On Fri, 10 May 2002 15:04:41 -0400, Hyman Rosen wrote:
> Preben Randhol wrote:
>> I actually like that Ada95 doesn't allow a default value, and I don't
>> understand what the gain is in a default value.
> 
> Ada allows default values in other contexts.

Default values yes, but arn't you talking about default types? 

Preben

Re: Generic default parameters

[Larry Kilgallen]

In article <slrnadq3ae.1cf.randhol+abuse@kiuk0156.chembio.ntnu.no>, Preben Randhol <randhol+abuse@pvv.org> writes:
> On Fri, 10 May 2002 15:04:41 -0400, Hyman Rosen wrote:
>> Preben Randhol wrote:
>>> I actually like that Ada95 doesn't allow a default value, and I don't
>>> understand what the gain is in a default value.
>> 
>> Ada allows default values in other contexts.
> 
> Default values yes, but arn't you talking about default types? 

Ada allows passing in types only in the case of generic parameters.
It is not identical to passing in values, but is a parallel concept.
Likewise, defaulting types that are generic parameters would be
a parallel concept.

Re: Generic default parameters

[Marin David Condic]

Yes, but why wouldn't it be useful to do the same with types? Used to be we
had procedures with parameters where you supplied values. Then we advanced
to generic procedures where you supply types. So if its useful to specify
default values for regular parameters, why wouldn't it be useful to specify
default values for generic parameters?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnadq3ae.1cf.randhol+abuse@kiuk0156.chembio.ntnu.no...
> On Fri, 10 May 2002 15:04:41 -0400, Hyman Rosen wrote:
> > Preben Randhol wrote:
> >> I actually like that Ada95 doesn't allow a default value, and I don't
> >> understand what the gain is in a default value.
> >
> > Ada allows default values in other contexts.
>
> Default values yes, but arn't you talking about default types?
>
> Preben

Re: Generic default parameters

[Randy Brukardt]

Preben Randhol wrote in message ...
>On Fri, 10 May 2002 16:22:50 +0200, Thomas Wolf wrote:
>>
>> It seems I'm not alone with these ideas... so let's summarize
>> and see if we can get a halfway decent proposal for the ARG
>> out of the discussions:
>>
>> Ada 95 lacks features for:
>>
>> 1. specifying a default type for generic formal type parameters
>>
>>    The idea would be to allow something like
>>
>>    generic
>>       type Something is range <> := Natural;
>>
>>    and if an instantiation does *not* supply an actual for
>>    'Something', 'Natural' will be taken.
>
>I actually like that Ada95 doesn't allow a default value, and I don't
>understand what the gain is in a default value. Expecially not for
>generic pacakges. If one want a default value why don't just do:
>
>package Some_Package is
>   new Some_Generic_Pacakge (Data_Type => Some_Default_Type);
>
>in a package and use this?

The point of course is to provide defaults for some (not all)
parameters, so the "package" you're talking about would have to be
generic.

The case that brought this up is something like:

    generic
        type Element_Type is private;
        type Count_Type is (<>) use Natural;
    package Lists is ...

Generally, the default Count type is sufficient. But there may be
occassions where some user-defined type would be valuable. A typical
instantiation would look like:

    package My_List is new Element (Some_Record);

To get that with a package, you'd have to have a generic package
wrapper:

    generic
        type Element_Type is private;
    package List_with_Natural_Count is
        package List is new Lists (Element_Type, Natural);
    end List_with_Natural_Count;

and then you would have complications in naming the items in the
instantiation (especially if you do not want to use a "use clause" on
the package). The net effect (either way) is to make it harder to create
a general component that is also relatively easy to use.

                       Randy.

Re: Generic default parameters

[Preben Randhol]

On Fri, 10 May 2002 14:27:39 -0500, Randy Brukardt wrote:
> 
> The point of course is to provide defaults for some (not all)
> parameters, so the "package" you're talking about would have to be
> generic.
> 
> The case that brought this up is something like:
> 
>     generic
>         type Element_Type is private;
>         type Count_Type is (<>) use Natural;
>     package Lists is ...
> 
> Generally, the default Count type is sufficient. But there may be
> occassions where some user-defined type would be valuable. A typical
> instantiation would look like:
> 
>     package My_List is new Element (Some_Record);
                             ^^^^^^^
                             Lists ?

> To get that with a package, you'd have to have a generic package
> wrapper:
> 
>     generic
>         type Element_Type is private;
>     package List_with_Natural_Count is
>         package List is new Lists (Element_Type, Natural);
>     end List_with_Natural_Count;
> 
> and then you would have complications in naming the items in the
> instantiation (especially if you do not want to use a "use clause" on
> the package). The net effect (either way) is to make it harder to
> create a general component that is also relatively easy to use.


OK I see.

-- 
"Jeg tror nordmenn har glemt hvordan de tilbreder fisk. De er mest
 opptatt av firkantet fisk."
  --  Kristian Kristiansen, yrkesfisker, aftenposten.no 19/04/02

Re: Generic default parameters

[Stephen Leake]

Thomas Wolf <t_wolf@angelfire.com> writes:

> 5. Linked to (3) above: some way to specify a storage pool that
>    is equal to whatever pool the compiler would use if no
>    "for Some_Access'Storage_Pool use ..." clause was present, i.e.
>    a generic way to refer to the standard storage pool of a type
>    without referring to the type. Something like
> 
>    generic
>       type Something is private;
>       Pool : in out System.Storage_Pools.Root_Storage_Pool'Class := <>;
>    package X is
>       type Some_Access is access all Something;
>       for Some_Access'Storage_Pool use Pool;
>       ...
> 
>    and if an instantiation provides an actual for 'Pool', that will
>    be taken as the storage pool of type 'Some_Access', but if an
>    instantiation doesn't provide an actual, 'Some_Access' will use
>    a standard storage pool.
> 
>    Not sure if point (5) makes sense, especially since it would be
>    useful only for storage pools, but make no sense at all for other
>    types...

I think a cleaner solution to 5 is a standard name for the standard
storage pool, combined with 3 (default object for "in out"). So we'd
have:

  generic
     type Something is private;
     Pool : in out System.Storage_Pools.Root_Storage_Pool'Class := 
         System.Storage_Pools.Default_Storage_Pool;
  package X is
     type Some_Access is access all Something;
     for Some_Access'Storage_Pool use Pool;

There may have to be more than one default storage pool; that may be
why there is no standard name now.
  
> Comments, anyone? Would these things be worth to consider for inclusion
> in the next Ada revision? 

I agree they would all be useful, but I have personally only seen the
need for 5 and 3.

-- 
-- Stephe

Re: Generic default parameters

[Thomas Wolf]

stephen.a.leake.1@gsfc.nasa.gov wrote:
> Thomas Wolf <t_wolf@angelfire.com> writes:
> 
> > 5. Linked to (3) above: some way to specify a storage pool that
> >    is equal to whatever pool the compiler would use if no
> >    "for Some_Access'Storage_Pool use ..." clause was present, i.e.
> >    a generic way to refer to the standard storage pool of a type
> >    without referring to the type.

[...]

> I think a cleaner solution to 5 is a standard name for the standard
> storage pool, combined with 3 (default object for "in out"). So we'd
> have:
> 
>   generic
>      type Something is private;
>      Pool : in out System.Storage_Pools.Root_Storage_Pool'Class := 
>          System.Storage_Pools.Default_Storage_Pool;
>   package X is
>      type Some_Access is access all Something;
>      for Some_Access'Storage_Pool use Pool;
> 
> There may have to be more than one default storage pool; that may be
> why there is no standard name now.

Exactly. Every access type may have its own "standard" pool as far as I
can tell from the RM. Hence maybe something like your
System.Storage_Pools.Default_Storage_Pool, but it would need to be
treated specially: it'd have to denote not *one* particular pool,
but would have to denote depending on context *the* pool from the
set of all possible standard pools that would apply to a given access
type. Hmm... what about other uses of storage pools? It appears that
besides passing it around to finally assign it to some access type
with a representation clause one cannot do very much with a storage
pool, see RM 13.11(20).

While I still think something like that would be useful, I'm not sure
I like such a context dependent semantics...

-- 
-----------------------------------------------------------------
Thomas Wolf                          e-mail: t_wolf@angelfire.com

Re: Generic default parameters

[Dmitry A. Kazakov]

On Fri, 10 May 2002 16:22:50 +0200, Thomas Wolf <t_wolf@angelfire.com>
wrote:

>It seems I'm not alone with these ideas... so let's summarize
>and see if we can get a halfway decent proposal for the ARG
>out of the discussions:
>
>Ada 95 lacks features for:
>
>1 .. 5

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:

procedure Put
(  Item  : in Num;
   Width : in Field := Default_Width;
   Base  : in Number_Base := Default_Base
);

should be legal.

7. Incomplete instantiations:

   package X is new Y (<>);
   --
   -- No actual parameters given.
   -- All declarations of the visible part of X
   -- are incomplete here in usual sense.
   -- I.e. if X declares a a type XX then
   --    type XX_Ptr is access X.XX;
   -- would be OK.
. . .
private
   package X is new Y (<parameter-list>);

The formal parameters which actuals are not visible in the public
part, shall be only used in the private part or the body of the
generic. The idea is to instantiate a generic with some private things
and yet to have the instance visible.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Generic default parameters

[Stephen Leake]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:

> 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:
> 
> 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.

> 7. Incomplete instantiations:
> 
>    package X is new Y (<>);
>    --
>    -- No actual parameters given.
>    -- All declarations of the visible part of X
>    -- are incomplete here in usual sense.
>    -- I.e. if X declares a a type XX then
>    --    type XX_Ptr is access X.XX;
>    -- would be OK.
> . . .
> private
>    package X is new Y (<parameter-list>);
> 
> The formal parameters which actuals are not visible in the public
> part, shall be only used in the private part or the body of the
> generic. The idea is to instantiate a generic with some private things
> and yet to have the instance visible.

This I'm less happy with. I think you can get the same effect with
library instantiations and/or child packages.

-- 
-- Stephe

Re: Generic default parameters

[Dmitry A. Kazakov]

On 13 May 2002 10:00:26 -0400, Stephen Leake
<stephen.a.leake.1@gsfc.nasa.gov> wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
>
>> 7. Incomplete instantiations:
>> 
>>    package X is new Y (<>);
>>    --
>>    -- No actual parameters given.
>>    -- All declarations of the visible part of X
>>    -- are incomplete here in usual sense.
>>    -- I.e. if X declares a a type XX then
>>    --    type XX_Ptr is access X.XX;
>>    -- would be OK.
>> . . .
>> private
>>    package X is new Y (<parameter-list>);
>> 
>> The formal parameters which actuals are not visible in the public
>> part, shall be only used in the private part or the body of the
>> generic. The idea is to instantiate a generic with some private things
>> and yet to have the instance visible.
>
>This I'm less happy with. I think you can get the same effect with
>library instantiations and/or child packages.

I do not know how. Moreover I suppose that there should be no way,
otherwise, "private" would be leaky, which we definitely do not want
to have.

A concrete example. Let we want to implement smart pointers / handles.
It could go as follows:

package Object is
   type Entity is new
      Ada.Finalization.Limited_Controlled with
   record
      Use_Count : Natural := 0; -- Reference count
   end record;
...
end Object;

generic
   type Object_Type (<>) is abstract new Entity with private;
   type Object_Type_Ptr is access all Object_Type'Class;
package Object.Handle is
   type Handle is tagged private;
...
private
   type Handle is new Ada.Finalization.Controlled with record
      Ptr : Object_Type_Ptr := null;
   end record;
end Object.Handle;

Now the problem, how to instantiate Object.Handle having Object_Type
private? Let we have:

package IO is
...
private
   type File_Descriptor is new Entity with ...;
   type File_Descriptor_Ptr is access all File_Descriptor'Class;
end IO;

package IO.Handles is
   package Handles is
       new Object.Handle (File_Descriptor, File_Descriptor_Ptr);
           -- Illegal, File_Descriptor is not visible here
   subtype IO_Handle is Handles.Handle;
   ...
end IO.Handles;

If we move the instantiation into the private part it would work, but
then it would be private. Once private, always private. With 7 it
could be:

package IO.Handles is
   package Handles is new Object.Handle (<>);
   subtype IO_Handle is Handles.Handle;
   ... -- Declaration of proxy operations on handles
private
   package Handles is
       new Object.Handle (File_Descriptor, File_Descriptor_Ptr);
end IO.Handles;

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Generic default parameters

[Stephen Leake]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:

> A concrete example. Let we want to implement smart pointers / handles.
> It could go as follows:
> 
> package Object is
>    type Entity is new
>       Ada.Finalization.Limited_Controlled with
>    record
>       Use_Count : Natural := 0; -- Reference count
>    end record;
> ...
> end Object;
> 
> generic
>    type Object_Type (<>) is abstract new Entity with private;
>    type Object_Type_Ptr is access all Object_Type'Class;
> package Object.Handle is
>    type Handle is tagged private;
> ...
> private
>    type Handle is new Ada.Finalization.Controlled with record
>       Ptr : Object_Type_Ptr := null;
>    end record;
> end Object.Handle;
> 
> Now the problem, how to instantiate Object.Handle having Object_Type
> private? Let we have:
> 
> package IO is
> ...
> private
>    type File_Descriptor is new Entity with ...;
>    type File_Descriptor_Ptr is access all File_Descriptor'Class;
> end IO;
> 
> package IO.Handles is
>    package Handles is
>        new Object.Handle (File_Descriptor, File_Descriptor_Ptr);
>            -- Illegal, File_Descriptor is not visible here
>    subtype IO_Handle is Handles.Handle;
>    ...
> end IO.Handles;

Simple. Make IO.Handles a private package:

private package IO.Handles is

Now the only places IO.Handles.IO_Handles can be seen are the same
places IO.File_Descriptor can be seen.

Hmm, perhaps you _wanted_ IO.Handles.IO_Handle to be public, so
clients could do stuff. Simple :

with Object.Handle;
package IO.Handles is
   type IO_Handle is private;
private
   package Handles is new Object.Handle (File_Descriptor, File_Descriptor_Ptr);
           -- Illegal, File_Descriptor is not visible here
   type IO_Handle is new Handles.Handle with null record;

end IO.Handles;


-- 
-- Stephe

Re: Generic default parameters

[Dmitry A. Kazakov]

On 13 May 2002 12:42:45 -0400, Stephen Leake
<stephen.a.leake.1@gsfc.nasa.gov> wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
>
>> A concrete example. Let we want to implement smart pointers / handles.
>> It could go as follows:
>> 
>> package Object is
>>    type Entity is new
>>       Ada.Finalization.Limited_Controlled with
>>    record
>>       Use_Count : Natural := 0; -- Reference count
>>    end record;
>> ...
>> end Object;
>> 
>> generic
>>    type Object_Type (<>) is abstract new Entity with private;
>>    type Object_Type_Ptr is access all Object_Type'Class;
>> package Object.Handle is
>>    type Handle is tagged private;
>> ...
>> private
>>    type Handle is new Ada.Finalization.Controlled with record
>>       Ptr : Object_Type_Ptr := null;
>>    end record;
>> end Object.Handle;
>> 
>> Now the problem, how to instantiate Object.Handle having Object_Type
>> private? Let we have:
>> 
>> package IO is
>> ...
>> private
>>    type File_Descriptor is new Entity with ...;
>>    type File_Descriptor_Ptr is access all File_Descriptor'Class;
>> end IO;
>> 
>> package IO.Handles is
>>    package Handles is
>>        new Object.Handle (File_Descriptor, File_Descriptor_Ptr);
>>            -- Illegal, File_Descriptor is not visible here
>>    subtype IO_Handle is Handles.Handle;
>>    ...
>> end IO.Handles;
>
>Hmm, perhaps you _wanted_ IO.Handles.IO_Handle to be public, so
>clients could do stuff. Simple :
>
>with Object.Handle;
>package IO.Handles is
>   type IO_Handle is private;
>private
>   package Handles is new Object.Handle (File_Descriptor, File_Descriptor_Ptr);
>   type IO_Handle is new Handles.Handle with null record;
>
>end IO.Handles;

Yes, but this would kill the nature of IO_Handle. It would be just a
private or a tagged private type. All operations defined on Handle get
invisible, as well as the fact that IO_Handle is a descendant of an
instance of Object.Handle.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Generic default parameters

[Stephen Leake]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:

> On 13 May 2002 12:42:45 -0400, Stephen Leake
> <stephen.a.leake.1@gsfc.nasa.gov> wrote:
>
> >Hmm, perhaps you _wanted_ IO.Handles.IO_Handle to be public, so
> >clients could do stuff. Simple :
> >
> >with Object.Handle;
> >package IO.Handles is
> >   type IO_Handle is private;
> >private
> >   package Handles is new Object.Handle (File_Descriptor, 
> >                                         File_Descriptor_Ptr);
> >   type IO_Handle is new Handles.Handle with null record;
> >
> >end IO.Handles;
> 
> Yes, but this would kill the nature of IO_Handle. It would be just a
> private or a tagged private type. All operations defined on Handle get
> invisible, as well as the fact that IO_Handle is a descendant of an
> instance of Object.Handle.

Well, I don't know what you want. You started out saying you wanted an
"incomplete" type in the public part, with a full type in the private
part that was from a generic instantiation. This gives you that.

If you want "all operations defined on IO_Handle" to be visible, then why
do you want an "incomplete" type in the public part?

Why should a client know that IO_Handle is a derived type, especially
since the parent type is invisible?

I guess I need to see an example of how you think a client would use
your new kind of type. That would make it clearer why a private type
won't work.

-- 
-- Stephe

Re: Generic default parameters

[Dmitry A. Kazakov]

On 14 May 2002 10:02:20 -0400, Stephen Leake
<stephen.a.leake.1@gsfc.nasa.gov> wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
>
>> On 13 May 2002 12:42:45 -0400, Stephen Leake
>> <stephen.a.leake.1@gsfc.nasa.gov> wrote:
>>
>> >Hmm, perhaps you _wanted_ IO.Handles.IO_Handle to be public, so
>> >clients could do stuff. Simple :
>> >
>> >with Object.Handle;
>> >package IO.Handles is
>> >   type IO_Handle is private;
>> >private
>> >   package Handles is new Object.Handle (File_Descriptor, 
>> >                                         File_Descriptor_Ptr);
>> >   type IO_Handle is new Handles.Handle with null record;
>> >
>> >end IO.Handles;
>> 
>> Yes, but this would kill the nature of IO_Handle. It would be just a
>> private or a tagged private type. All operations defined on Handle get
>> invisible, as well as the fact that IO_Handle is a descendant of an
>> instance of Object.Handle.
>
>Well, I don't know what you want. You started out saying you wanted an
>"incomplete" type in the public part, with a full type in the private
>part that was from a generic instantiation. This gives you that.

No, it does not. I want the following:

   type IO_Handle is new Handles.Handle with null record;

I cannot have that when Handles is an instance depending on some
actual parameters invisible in the public part of the package. I must
either move it to the private part, or make it [tagged] private. Both
is unsatisfactory.

>If you want "all operations defined on IO_Handle" to be visible, then why
>do you want an "incomplete" type in the public part?

Correction, all operations declared on its *parent*.

>Why should a client know that IO_Handle is a derived type, especially
>since the parent type is invisible?

That's the point. The parent type shall be visible.

>I guess I need to see an example of how you think a client would use
>your new kind of type. That would make it clearer why a private type
>won't work.

The problem is to have [with generics] two parallel type sets, one
public, one private:

public:
   generic Handle     File_Handle    Sequential_File_Handle ...
private:
   generic Object <--- File_Object <--- Sequential_File_Object ...

Clients see only handles. Objects are private. Each time a package
privately implements a new object type, some child package can
instantiate a generic package to provide handles to objects.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de