Generic package parameters not externally visible : what's the rational ?

Generic package parameters not externally visible : what's the rational ?

[Hibou57 (Yannick Duchêne)]

Hello ghosts out there,

24h without even a single post on comp.lang.ada... I hope every body
is Ok.

Still the time for my two cents of the day : parameters of generic
packages are not externally visible. I use to read in a few places on
the web, this is so to preserve type privacy, but without any examples
which could illustrate this view.

What's the rational behind this ?

I like to do something like this to work around this :

generic

   Parameter_Type is (<>);

   -- Other generic parameters ...

package Generic_Package is

   -- Give external access to generic parameters which are not visible
otherwise.

   subtype Formal_Parameter_Type is Parameter_Type

   -- The same for other generic parameters ...

   -- Remaining of the package ...

end Generic_Package;

I feel it is oftenly useful to have external access to generic
parameters : it is more clear and more consistent than making
reference to stuffs from different source (finally, the package
instance is a place where all these references are available, so why
not use these). I feel this is especially useful when other generic
packages are instantiated using the same parameters used to
instantiate another generic packages.

That's why I was wondering about the rational which is underlying to
this restriction (the one which disallows a generic parameter to be
externally visible).

Have a nice time (if every one is Ok).

Re: Generic package parameters not externally visible : what's the rational ?

[Ludovic Brenta]

Yannick Duchêne wrote on comp.lang.ada:
> Hello ghosts out there,
>
> 24h without even a single post on comp.lang.ada... I hope every body
> is Ok.
>
> Still the time for my two cents of the day : parameters of generic
> packages are not externally visible. I use to read in a few places on
> the web, this is so to preserve type privacy, but without any examples
> which could illustrate this view.
>
> What's the rational behind this ?
>
> I like to do something like this to work around this :
>
> generic
>
>    Parameter_Type is (<>);
>
>    -- Other generic parameters ...
>
> package Generic_Package is
>
>    -- Give external access to generic parameters which are not visible
> otherwise.
>
>    subtype Formal_Parameter_Type is Parameter_Type
>
>    -- The same for other generic parameters ...
>
>    -- Remaining of the package ...
>
> end Generic_Package;
>
> I feel it is oftenly useful to have external access to generic
> parameters : it is more clear and more consistent than making
> reference to stuffs from different source (finally, the package
> instance is a place where all these references are available, so why
> not use these). I feel this is especially useful when other generic
> packages are instantiated using the same parameters used to
> instantiate another generic packages.
>
> That's why I was wondering about the rational which is underlying to
> this restriction (the one which disallows a generic parameter to be
> externally visible).
>
> Have a nice time (if every one is Ok).

(I'm OK, thank you, and qute busy with the Debian Policy for Ada and
gnat-4.4....)

I think this is at least consistent: the values of subprogram
parameters are also invisible outside the subprogram. Making "in out"
generic formal variables visible outside the generic would be
dangerous IMHO. As for generic formal types, subprograms, packages and
constants... why not.

--
Ludovic Brenta.

Re: Generic package parameters not externally visible : what's the rational ?

[Robert A Duff]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> I think this is at least consistent: the values of subprogram
> parameters are also invisible outside the subprogram. Making "in out"
> generic formal variables visible outside the generic would be
> dangerous IMHO. As for generic formal types, subprograms, packages and
> constants... why not.

I don't buy the analogy with subprograms.  When you "instantiate"
(i.e. call) a subprogram, you don't create a nameable entity
that can be referred to from outside.  A better analogy would
be discriminants, which are really parameters passed in to
a type when you "instantiate" it (i.e. create an object of the type).
And the discriminants are visible from outside the object,
as they should be.

I don't see any particular danger for the "in out" case.
It would mean you can reach in and change it from the outside,
but that's true of regular variables declared in the generic
package spec.  So don't do that.  (It's also true for "in out"s
in the formal package case, if I remember correctly -- I'm
too lazy to look it up right now.)

Anyway, generic formal "in out" parameters are used approximately
never, so I don't care that much if they're slightly dangerous.

- Bob

Re: Generic package parameters not externally visible : what's the rational ?

[Hibou57 (Yannick Duchêne)]

On 26 oct, 12:05, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> (I'm OK, thank you, and qute busy with the Debian Policy for Ada and
> gnat-4.4....)
Yes, I know (I've read your previous announcement about it)

On 26 oct, 12:05, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> I think this is at least consistent: the values of subprogram
> parameters are also invisible outside the subprogram. Making "in out"
> generic formal variables visible outside the generic would be
> dangerous IMHO. As for generic formal types, subprograms, packages and
> constants... why not.
>
> --
> Ludovic Brenta.
I did not though about this "in out" formal parameter, because I never
use it.
This may be a good reason, why not, I will think about it if I ever
use it.

Re: Generic package parameters not externally visible : what's the rational ?

[Robert A Duff]

"Hibou57 (Yannick Duch�ne)" <yannick_duchene@yahoo.fr> writes:

> Still the time for my two cents of the day : parameters of generic
> packages are not externally visible. I use to read in a few places on
> the web, this is so to preserve type privacy, but without any examples
> which could illustrate this view.
>
> What's the rational behind this ?

I don't think there is any rationale.  It makes perfect sense
for them to be visible, but they're not.  I guess it was just
a minor mistake in Ada 83, and it's never been thought important
enough to fix in later versions.  I don't see any way in
which this rule "preserves type privacy".

Note that the rule is different for generic formal packages.

Your workaround is OK.  I've done that.  But it presents an
annoying problem -- you have to think of two different names for the
same thing.

- Bob

Re: Generic package parameters not externally visible : what's the rational ?

[Hibou57 (Yannick Duchêne)]

On 26 oct, 15:56, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
> Your workaround is OK.  I've done that.  But it presents an
> annoying problem -- you have to think of two different names for the
> same thing.
>
> - Bob

If the prefix is always the same and consistent across all packages,
it can be quite easy (I've choose “ Formal_ ”, the same as in the
example). This is then just a matter of convention.

Re: Generic package parameters not externally visible : what's the rational ?

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcciqe26w5q.fsf@shell01.TheWorld.com...
> "Hibou57 (Yannick Duch�ne)" <yannick_duchene@yahoo.fr> writes:
>
>> Still the time for my two cents of the day : parameters of generic
>> packages are not externally visible. I use to read in a few places on
>> the web, this is so to preserve type privacy, but without any examples
>> which could illustrate this view.
>>
>> What's the rational behind this ?
>
> I don't think there is any rationale.  It makes perfect sense
> for them to be visible, but they're not.  I guess it was just
> a minor mistake in Ada 83, and it's never been thought important
> enough to fix in later versions.  I don't see any way in
> which this rule "preserves type privacy".

I'm not sure that it "makes perfect sense" for them to be visible: it would 
surely increase the chance of name collisions outside of the package. 
Indeed, I find that it makes "perfect sense" for them not the visible: they 
are not part of the package that gets instantiated. That's clear from the 
syntax (they're outside the package). You're going to say that discriminants 
are outside of the type, too, but they're also visible. I can't argue with 
that beyond saying that that placement of discriminants is just awful; I 
place them in the wrong place and continually forget to include them in 
aggregates because they're well away from the other components.

The main point is, it isn't clear either way: both choices aren't ideal. So 
one was chosen. And changing it surely would be incompatible, at the very 
least with use-visibility (if you start adding names, those names could 
become invisible if there are collisions) -- and it is insufficiently broken 
to take on that incompatibility.

                                              Randy.

Re: Generic package parameters not externally visible : what's the rational ?

[Jeffrey R. Carter]

Randy Brukardt wrote:
> 
> The main point is, it isn't clear either way: both choices aren't ideal. So 
> one was chosen. And changing it surely would be incompatible, at the very 
> least with use-visibility (if you start adding names, those names could 
> become invisible if there are collisions) -- and it is insufficiently broken 
> to take on that incompatibility.

One possible rationale is:

In order to reference the generic parameters from the instance, you have to have 
visibility of the instantiation. If you have visibility of the instantiation, 
then you have visibility of the generic actual parameters used in the 
instantiation. Therefore, you do not need visibility of the generic parameters 
from the instance, so why complicate the language by providing it?

-- 
Jeff Carter
"We'll make Rock Ridge think it's a chicken
that got caught in a tractor's nuts!"
Blazing Saddles
87

Re: Generic package parameters not externally visible : what's the rational ?

[Hibou57 (Yannick Duchêne)]

On 27 oct, 22:36, "Jeffrey R. Carter" <spam.jrcarter....@spam.acm.org>
wrote:
> One possible rationale is:
>
> In order to reference the generic parameters from the instance, you have to have
> visibility of the instantiation. If you have visibility of the instantiation,
> then you have visibility of the generic actual parameters used in the
> instantiation. Therefore, you do not need visibility of the generic parameters
> from the instance, so why complicate the language by providing it?

After that, I will then try to give a view of the other hand :

One good reason to miss it, is when a package A has another package B
in its formal parameters and this formal package parameter (B) is it
self generic, and A needs to use some type which were given to
instantiate the package B. This is an example case where the parameter
which were used to instantiate a package, are not accessible from a
point they are needed (if P instantiated B, of course P has access to
parameters used to instantiate B, but this does not help A, it if ever
itself also need these).

More about this latter point : it may be possible, to just give to A,
the same type, but if A has let say, two of three package in its
formal parameters, then, the number of generic parameter may increase
a bit too much, at the cost of readability or at the cost of easy of
use. Using such redundancies sometime, in the opposite, help
readability or is useful when it recall something explicitly, but
sometime, when it is too much, it breaks readability and comes with a
feeling of confusion.

To come back to the first point : one other good reason apart of a
generic package having another generic in its parameters, is when a
generic package B may also be instantiated in a package A, which will
then be use in another package C, which does not have direct access to
the parameters used to instantiate the package (let say it was in a
third package which A deeply rely on one, but not C). Then, one of the
more natural way to access these, if ever needed for other stuff in C,
is the generic package instance B itself.


Randy Brukardt Wrote :

> And changing it surely would be incompatible, at the very
> least with use-visibility

That's an interesting point indeed. I did not though about it at first
sight, because I never Use.

Re: Generic package parameters not externally visible : what's the rational ?

[Jeffrey R. Carter]

Hibou57 (Yannick Duch�ne) wrote:
> 
> One good reason to miss it, is when a package A has another package B
> in its formal parameters and this formal package parameter (B) is it
> self generic, and A needs to use some type which were given to
> instantiate the package B. This is an example case where the parameter
> which were used to instantiate a package, are not accessible from a
> point they are needed (if P instantiated B, of course P has access to
> parameters used to instantiate B, but this does not help A, it if ever
> itself also need these).

But Ada allows a generic to reference the unknown generic parameters of its 
formal package parameters. See ARM 12.7.

> To come back to the first point : one other good reason apart of a
> generic package having another generic in its parameters, is when a
> generic package B may also be instantiated in a package A, which will
> then be use in another package C, which does not have direct access to
> the parameters used to instantiate the package (let say it was in a
> third package which A deeply rely on one, but not C). Then, one of the
> more natural way to access these, if ever needed for other stuff in C,
> is the generic package instance B itself.

Then C clearly has a dependency on this 4th pkg (shall we call it D?), and that 
dependency should be made explicit, by including "with D;" on C.

-- 
Jeff Carter
"We'll make Rock Ridge think it's a chicken
that got caught in a tractor's nuts!"
Blazing Saddles
87

Re: Generic package parameters not externally visible : what's the rational ?

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

"Hibou57 (Yannick Duch�ne)" <yannick_duchene@yahoo.fr> wrote in message 
news:3084820f-4799-4555-b309-92c8ff7e2436@m16g2000yqc.googlegroups.com...
...
> Using such redundancies sometime, in the opposite, help
> readability or is useful when it recall something explicitly, but
> sometime, when it is too much, it breaks readability and comes with a
> feeling of confusion.

Surely I have a feeling of confusion :-) at the idea of having a generic 
package with a large number of interelated formal packages. That sounds a 
new way to create unmaintainable spagetti code (gotos aren't the only way to 
make things impossible to understand). That's irrespective of how the 
formals on the outer package are named.

                                   Randy.

Re: Generic package parameters not externally visible : what's the rational ?

[Hibou57 (Yannick Duchêne)]

On 28 oct, 20:07, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> Surely I have a feeling of confusion :-) at the idea of having a generic
> package with a large number of interelated formal packages. That sounds a
> new way to create unmaintainable spagetti code (gotos aren't the only way to
> make things impossible to understand). That's irrespective of how the
> formals on the outer package are named.
>
>                                    Randy.

In return, you've just frightened me (not less) with that “ Surely I
have a feeling of confusion :-) at the idea of having a generic
package with a large number of interelated formal packages ”. Sounds
to me like if you attempted to make me understand I'm making a *big*
design mistake.

May I say gotos are sometime considered not so much evil, but it is
not the spot here

The same coupling between formal packages do exist, even if it's less
visible, with other packages because they are not generic. I attempt
an example : let say we want a package whose intent is to search
matches of some kind of patterns in strings. We feel its something
which is finally somewhat universal, and we decide to make it a
generic package, working on arrays of discrete type items. So instead
of a package working on strings, we create a generic package, with a
formal type parameter, which will be instantiated with
Standard.Character or Standard.Wide_Wide_Character for the initial
purpose. Then, we later wish some helpers to log statistics on
patterns and sequences which matched each others (an example, do not
expect it to be clearly useful at first sight, just imagine it is
useful to someone). This helper package must work with the same type
of data the pattern-matching package use. It will have a pattern-
matching package as one of its formal parameters, and for clarity, we
may add the discrete type to its parameters as well, to clearly show
they have this type in common. Imagine now (my own imagination has
exhausted at this point, so imagine what you want), we have a second
helpers, which is related to the first package the same the other
helper package is, and again another package, which has this time,
dependencies to the two helpers package.

This may seems “ complex ”, but this is not more than any other stuff
of the same area, like data flow, code flow or the like. If relations
and dependencies are clear and coherent, what is like spaghettis
here ?

Another advocating based on a comment after the previous example :
with non-generic, you would just see multiple packages each holdings a
reference to Standard.Wide_Wide_Character, thus you will not feel
there are coupled, but just related to Standard.Wide_Wide_Character.
There, as they are all generics, you see them all depending each
others, to be sure they all use some one type in common. This seems
complex, because a dependency is clearly reported and stated, while
this is not clearly stated with non-generic (this would just be fact
someone may notice after analysis), but relations are finally still as
much complex, and they are the same in both case (generic, and non-
generic case).

I do not mean you comment is wrong, I just attempt to reply and
advocate an view on the situation.

If I'm surely wrong on the long time, I want to know before I discover
it myself after a (too much) long time

Re: Generic package parameters not externally visible : what's the rational ?

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1782 bytes --]

"Hibou57 (Yannick Duch�ne)" <yannick_duchene@yahoo.fr> wrote in message 
news:7e99bb5a-26a8-4ccb-b8d0-3b6882c40ebe@k17g2000yqb.googlegroups.com...
...
>I do not mean you comment is wrong, I just attempt to reply and
>advocate an view on the situation.
>
>If I'm surely wrong on the long time, I want to know before I discover
>it myself after a (too much) long time

I don't have time to give you a detailed reply, sorry. (Well, not unless you 
want to hire me for consulting. :-)

Let me just give my general thinking on this subject. I think formal 
packages should be used sparingly, in part because they complicate the use 
of a generic package (the more instances and parameters that you have write 
before anything useful can be done, the harder it is to understand and the 
more likely that you will just forget using the generic and "roll your 
own").

Typically, when I've had to compose generics, I will nest an instantiation 
of one inside the other. (That's pretty much all you could do in Ada 83, 
after all.) Most of the time, that works fine, and the operations in the 
instance can be used directly or re-exported with renames as needed.

I also would have to agree with Dmitry (at least to a point) that generics 
can really interfere with your designs, so you need to use them sparingly. 
You can't avoid them completely when designing something like containers 
(for instance), but note that we made a strong effort to preserve the 
"single instance" model in almost all of the language-defined generics. We 
did that even at the cost of being able to have container interfaces (which 
would be really nice for abstraction purposes, but would require a second 
level of generic instances in order to be useful).

                                     Randy.

Re: Generic package parameters not externally visible : what's the rational ?

[Hibou57 (Yannick Duchêne)]

On 29 oct, 23:56, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> I don't have time to give you a detailed reply, sorry. (Well, not unless you
> want to hire me for consulting. :-)
Don't mind about time, I can understand
If could ask you for consulting, I enjoy to do, but unluckily, I'm
jobless, ... so ...
any I feel honored you've take some time to answer ;)

> Typically, when I've had to compose generics, I will nest an instantiation
> of one inside the other. (That's pretty much all you could do in Ada 83,
> after all.) Most of the time, that works fine, and the operations in the
> instance can be used directly or re-exported with renames as needed.
I was thinking about such a thing, it was planned, but I still not
tried it, because I was busy at thinking about what the best naming
conventions are (another topic).

> That's pretty cynical. Most of time, once you get your generic working,
> you hardly every touch it again. Besides, you could make the above
> statement for  almost any Ada (or other programming language) code
> when it is reused.
I also feel better after that, the assertion you replied to with these
words, was also a bit frightening to me (I was thinking it was a bit
too much, but was not sure after all, as I know there are probably a
lot of things I do not know).

Re: Generic package parameters not externally visible : what's the rational ?

[Hibou57 (Yannick Duchêne)]

continuation (forgotten in the latter)

On 27 oct, 22:36, "Jeffrey R. Carter" <spam.jrcarter....@spam.acm.org>
wrote:
> from the instance, so why complicate the language by providing it?

while after all, it can be done with a work around, which does not
break anything (well, only some personal cases perhaps, that's true as
well).

Re: Generic package parameters not externally visible : what's the rational ?

[Robert A Duff]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> writes:

> One possible rationale is:
>
> In order to reference the generic parameters from the instance, you have
> to have visibility of the instantiation. If you have visibility of the
> instantiation, then you have visibility of the generic actual parameters
> used in the instantiation. Therefore, you do not need visibility of the
> generic parameters from the instance,

I agree you don't need it (at least, in the Ada 83 cases).

>...so why complicate the language by
> providing it?

But I don't see why it complicates the language.  Seems like a wash in
Ada 83.  And in Ada 95/2005, I think the existing rule is slightly more
complicated (because it special-cases generic formal packages).

- BOb

Re: Generic package parameters not externally visible : what's the rational ?

[Jeffrey R. Carter]

Robert A Duff wrote:
> 
> But I don't see why it complicates the language.  Seems like a wash in
> Ada 83.  And in Ada 95/2005, I think the existing rule is slightly more
> complicated (because it special-cases generic formal packages).

Well, sure, but they added lots of stuff that makes the language more 
complicated that I don't even think should be in there.

-- 
Jeff Carter
"We'll make Rock Ridge think it's a chicken
that got caught in a tractor's nuts!"
Blazing Saddles
87

Re: Generic package parameters not externally visible : what's the rational ?

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> I'm not sure that it "makes perfect sense" for them to be visible: it would 
> surely increase the chance of name collisions outside of the package. 

Shrug.  So you would end up saying "Instance.Element_Type" once in a while.

> Indeed, I find that it makes "perfect sense" for them not the visible: they 
> are not part of the package that gets instantiated. That's clear from the 
> syntax (they're outside the package).

I've always found that syntax odd, for what it's worth.
Part of the declarative region of the generic package
comes before its name.

>... You're going to say that discriminants 
> are outside of the type, too, but they're also visible. I can't argue with 
> that beyond saying that that placement of discriminants is just awful; I 
> place them in the wrong place and continually forget to include them in 
> aggregates because they're well away from the other components.
>
> The main point is, it isn't clear either way: both choices aren't ideal. So 
> one was chosen. And changing it surely would be incompatible, at the very 
> least with use-visibility (if you start adding names, those names could 
> become invisible if there are collisions) -- and it is insufficiently broken 
> to take on that incompatibility.

Agreed.  I don't think anybody suggesting "fixing" this minor problem
-- they just asked for rationale, and I speculated.

- Bob

Re: Generic package parameters not externally visible : what's the rational ?

[Hibou57 (Yannick Duchêne)]

On 27 oct, 23:19, "Jeffrey R. Carter" <spam.jrcarter....@spam.acm.org>
wrote:
> Then C clearly has a dependency on this 4th pkg (shall we call it D?), and that
> dependency should be made explicit, by including "with D;" on C.
While both origin are equally legitimate, and this is not only the
case with generics.
This make me thing its the same kind of type matching by name (or
declaration) and type matching by structure. Here, we could say than
the origin means something. As a concrete image, let say the type in
its first declaration place, has some comments attached to it. Ok.
Then, a package as a formal parameter, with some comments attached to
this parameters. Then, the parameters is associated to the defined
type. Here, the presence of comments stands for a meaning, and the
fact that some comment may be associated to the type at the place
where it is a formal parameter, shows that using one or the other
origin, may not means the same thing. If I refer to A.C, this may not
mean the same as if I refer to B.C, even if C is the same in both
place. After all, the generic parameter of a package, is one location,
a fixed location, and the type used to instantiate the package, may
not be so much clearly fixed (I apologize if my word does not seems
very clear, I'm trying to express a though). If I refer to A.C, I mean
something, if I refer to B.C, I may mean something else, and the
difference may have multiple cause (clarity, logic, requirement,
style, etc).

I take long to talk about and does not hesitate to say a lot about
details, because I'm currently thinking about what conventions I
should use, what patterns and overall strategies for this and that.
And I would like to work at it the sooner, rather than to have to come
back to it too much late (I'm testing on a little sample application
with about 40 small packages, most of which are generics, and spend a
lot of time to rewrite this and that, re-read all to see if it seems
accessible and readable, easy to use, well glued, etc).

> But Ada allows a generic to reference the unknown generic parameters of its
> formal package parameters. See ARM 12.7.
I did not knew about it, I will look at it tomorrow. Thanks for the
point.

On 28 oct, 00:34, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
> > Indeed, I find that it makes "perfect sense" for them not the visible: they
> > are not part of the package that gets instantiated. That's clear from the
> > syntax (they're outside the package).
>
> I've always found that syntax odd, for what it's worth.
> Part of the declarative region of the generic package
> comes before its name.
The same for me, I have never really feel at ease with this package
name not coming at the first place (probably another thing from the
beginning of the long history of Ada).

About the previous assertion, saying “ they are not part of the
package that gets instantiated ”, I sincerely do not understand this
assertion. Where are they if they are not part of the package ? If
they are given as parameters, they are injected in the package.

But right a few minutes ago, I was thinking that is may be finally
better to be able to hide something there. Perhaps peoples who were
talking about protecting type privacy, were thinking about a formal
parameter used in the private part of the package only. When it is
(this may not always be so much strange as it seems, to give formals
parameters which are only used in private part), it is better to not
make these visible from the outside. Providing this is a good answer,
then the actual is so just the best, because it allow to show or hide
at the discretion of the author (the language does not impose anything
there, except it hides by default, and that's finally a good fact).

Re: Generic package parameters not externally visible : what's the rational ?

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]

"Hibou57 (Yannick Duch�ne)" <yannick_duchene@yahoo.fr> wrote in message 
news:b6d32b60-333f-495d-b17a-7ab589690bbb@d10g2000yqh.googlegroups.com...

...
>But right a few minutes ago, I was thinking that is may be finally
>better to be able to hide something there. Perhaps peoples who were
>talking about protecting type privacy, were thinking about a formal
>parameter used in the private part of the package only. When it is
>(this may not always be so much strange as it seems, to give formals
>parameters which are only used in private part), it is better to not
>make these visible from the outside. Providing this is a good answer,
>then the actual is so just the best, because it allow to show or hide
>at the discretion of the author (the language does not impose anything
>there, except it hides by default, and that's finally a good fact).

By jove, I think he's got it! :-)

The above reasoning makes sense, and it actually seems to reflect the 
supposed rationale. It would be nice if a fuller example of this was 
included somewhere. (I'd put it into the AARM if I had any idea of where it 
should go.)

                                             Randy.

Re: Generic package parameters not externally visible : what's the rational ?

[Stephen Leake]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Hibou57 (Yannick Duch�ne)" <yannick_duchene@yahoo.fr> wrote in message 
> news:b6d32b60-333f-495d-b17a-7ab589690bbb@d10g2000yqh.googlegroups.com...
>
> ...
>>But right a few minutes ago, I was thinking that is may be finally
>>better to be able to hide something there. Perhaps peoples who were
>>talking about protecting type privacy, were thinking about a formal
>>parameter used in the private part of the package only. When it is
>>(this may not always be so much strange as it seems, to give formals
>>parameters which are only used in private part), it is better to not
>>make these visible from the outside. Providing this is a good answer,
>>then the actual is so just the best, because it allow to show or hide
>>at the discretion of the author (the language does not impose anything
>>there, except it hides by default, and that's finally a good fact).
>
> By jove, I think he's got it! :-)
>
> The above reasoning makes sense, and it actually seems to reflect the 
> supposed rationale. It would be nice if a fuller example of this was 
> included somewhere. (I'd put it into the AARM if I had any idea of where it 
> should go.)

And we should add optional "private" keywords on all the formal
parameters, as we now have "private with" for context clauses.

Then non-private formal generic parameters could be visible, and
private ones not.

-- 
-- Stephe

Re: Generic package parameters not externally visible : what's the rational ?

[Hibou57 (Yannick Duchêne)]

On 28 oct, 20:12, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "Hibou57 (Yannick Duchêne)" <yannick_duch...@yahoo.fr> wrote in messagenews:b6d32b60-333f-495d-> By jove, I think he's got it! :-)

What does mean “ By Jove ” ? (I'm not native English, sorry).

> The above reasoning makes sense, and it actually seems to reflect the
> supposed rationale. It would be nice if a fuller example of this was
> included somewhere. (I'd put it into the AARM if I had any idea of where it
> should go.)
>
>                                              Randy.

Do you want to say I should have given an example ? If so, I may try
to get one for a later reply.

Re: Generic package parameters not externally visible : what's the rational ?

[AdaMagica]

On 29 Okt., 13:21, Hibou57 (Yannick Duchêne)
<yannick_duch...@yahoo.fr> wrote:
> On 28 oct, 20:12, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>
> > "Hibou57 (Yannick Duchêne)" <yannick_duch...@yahoo.fr> wrote in messagenews:b6d32b60-333f-495d-> By jove, I think he's got it! :-)
>
> What does mean “ By Jove ” ? (I'm not native English, sorry).

By Jupiter

Latin Jupiter Nom., Jovis Gen., Jovi Dat. ...

Re: Generic package parameters not externally visible : what's the rational ?

[Georg Bauhaus]

AdaMagica schrieb:
> On 29 Okt., 13:21, Hibou57 (Yannick Duch�ne)
> <yannick_duch...@yahoo.fr> wrote:
>> On 28 oct, 20:12, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>>
>>> "Hibou57 (Yannick Duch�ne)" <yannick_duch...@yahoo.fr> wrote in messagenews:b6d32b60-333f-495d-> By jove, I think he's got it! :-)
>> What does mean � By Jove � ? (I'm not native English, sorry).
> 
> By Jupiter
> 
> Latin Jupiter Nom., Jovis Gen., Jovi Dat. ...


Maybe Randy was referring to My Fair Lady?  (The next Ada
Europe conference is taking place in Val�ncia in Spain, so ...)

Song and text here
http://www.emusic.com/samples/m3u/song/11203159/16687952.m3u

or here
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewAlbum?i=286653028&id=286652971&s=143443
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewAlbum?i=325987468&id=325987225&s=143443

Re: Generic package parameters not externally visible : what's the rational ?

[Jeffrey R. Carter]

Georg Bauhaus wrote:
> AdaMagica schrieb:
>> On 29 Okt., 13:21, Hibou57 (Yannick Duch�ne)
>> <yannick_duch...@yahoo.fr> wrote:
>>> On 28 oct, 20:12, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>>>
>>>> "Hibou57 (Yannick Duch�ne)" <yannick_duch...@yahoo.fr> wrote in messagenews:b6d32b60-333f-495d-> By jove, I think he's got it! :-)
>>> What does mean � By Jove � ? (I'm not native English, sorry).
>> By Jupiter
>>
>> Latin Jupiter Nom., Jovis Gen., Jovi Dat. ...
> 
> 
> Maybe Randy was referring to My Fair Lady?  (The next Ada
> Europe conference is taking place in Val�ncia in Spain, so ...)

Wasn't that "By George"?

-- 
Jeff Carter
"C's solution to this [variable-sized array parameters] has real
problems, and people who are complaining about safety definitely
have a point."
Dennis Ritchie
25

Re: Generic package parameters not externally visible : what's the rational ?

[Georg Bauhaus]

Jeffrey R. Carter schrieb:
> Georg Bauhaus wrote:
>> AdaMagica schrieb:
>>> On 29 Okt., 13:21, Hibou57 (Yannick Duch�ne)
>>> <yannick_duch...@yahoo.fr> wrote:
>>>> On 28 oct, 20:12, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>>>>
>>>>> "Hibou57 (Yannick Duch�ne)" <yannick_duch...@yahoo.fr> wrote in
>>>>> messagenews:b6d32b60-333f-495d-> By jove, I think he's got it! :-)
>>>> What does mean � By Jove � ? (I'm not native English, sorry).
>>> By Jupiter
>>>
>>> Latin Jupiter Nom., Jovis Gen., Jovi Dat. ...
>>
>>
>> Maybe Randy was referring to My Fair Lady?  (The next Ada
>> Europe conference is taking place in Val�ncia in Spain, so ...)
> 
> Wasn't that "By George"?
> 

Yes, the second interjection starts with those words.
I found one "By Jove!" in Pygmalion.
(It is Pickering's expression when he sees Liza
dressed like a lady for the first time.
Ada is a lady's name, too...)
"I think she's got it" is the first interjection in the song,
"By George, she's got it" the second.  I'm not familiar
with permissions to refer to deities in theaters
of the time (or in comp.lang.ada), so I was assuming
some such was meant.

Re: Generic package parameters not externally visible : what's the rational ?

[Stephen Leake]

AdaMagica <christoph.grein@eurocopter.com> writes:

> On 29 Okt., 13:21, Hibou57 (Yannick Duchêne)
> <yannick_duch...@yahoo.fr> wrote:
>> On 28 oct, 20:12, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>>
>> > "Hibou57 (Yannick Duchêne)" <yannick_duch...@yahoo.fr> wrote in messagenews:b6d32b60-333f-495d-> By jove, I think he's got it! :-)
>>
>> What does mean “ By Jove ” ? (I'm not native English, sorry).
>
> By Jupiter
>
> Latin Jupiter Nom., Jovis Gen., Jovi Dat. ...

It's just an exclamation, like "wow" or "by God". Some people find "by
God" offensive because their religion says it is a form of swearing,
so they use "Jove" instead; Jove is a Roman god, so for modern
Christians, "By Jove" is a less severe form of swearing than "by God".

Always interesting, the places comp.lang.ada gets to :).

-- 
-- Stephe

Re: Generic package parameters not externally visible : what's the rational ?

[Ludovic Brenta]

Yannick Duchêne wrote on comp.lang.ada:
> What does mean “ By Jove ” ? (I'm not native English, sorry).

You seem never to have read Blake and Mortimer comics :)

Sacrebleu!

--
Ludovic Brenta.

Re: Generic package parameters not externally visible : what's the rational ?

[Hibou57 (Yannick Duchêne)]

On 30 oct, 18:53, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> Yannick Duchêne wrote on comp.lang.ada:
>
> > What does mean “ By Jove ” ? (I'm not native English, sorry).
>
> You seem never to have read Blake and Mortimer comics :)
>
> Sacrebleu!
>
> --
> Ludovic Brenta.

I feel I should, this must be Cool (j'irai voir ça chez un bouquiniste
à l'occasion, je ne connais que de nom)

Re: Generic package parameters not externally visible : what's the rational ?

[Hibou57 (Yannick Duchêne)]

On 28 oct, 20:12, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> By jove, I think he's got it! :-)
>
> The above reasoning makes sense, and it actually seems to reflect the
> supposed rationale. It would be nice if a fuller example of this was
> included somewhere. (I'd put it into the AARM if I had any idea of where it
> should go.)
>
>                                              Randy.

While a remaining point would not look so much nice in a rational :
the name trouble. OK, it's nice the language hides by default and it's
not a trouble because one may show if he/she want. That said, in Ada,
everything must have a name ( ;) ) and I do not see a good rational
which could give any good reason about the fact that “ if you want to
make it visible, you must trick the name ”, moreover that good naming
is an important part of Ada programs.

The point is then not about the possibility to hide or the possibility
to show (that is solved), and rather about the required trick on the
name.

I leave this one point to interested peoples, without me (because I
know it is a language fact and nothing could be able to change this).

Re: Generic package parameters not externally visible : what's the rational ?

[Dmitry A. Kazakov]

On Tue, 27 Oct 2009 16:08:09 -0500, Randy Brukardt wrote:

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
> news:wcciqe26w5q.fsf@shell01.TheWorld.com...
>> "Hibou57 (Yannick Duch�ne)" <yannick_duchene@yahoo.fr> writes:
>>
>>> Still the time for my two cents of the day : parameters of generic
>>> packages are not externally visible. I use to read in a few places on
>>> the web, this is so to preserve type privacy, but without any examples
>>> which could illustrate this view.
>>>
>>> What's the rational behind this ?
>>
>> I don't think there is any rationale.  It makes perfect sense
>> for them to be visible, but they're not.  I guess it was just
>> a minor mistake in Ada 83, and it's never been thought important
>> enough to fix in later versions.  I don't see any way in
>> which this rule "preserves type privacy".
> 
> I'm not sure that it "makes perfect sense" for them to be visible: it would 
> surely increase the chance of name collisions outside of the package.

Sorry, but that is a "generic" property of anything declared in a generic
package. Two instances of the same generic packages always collide when
"use"-ed.

> Indeed, I find that it makes "perfect sense" for them not the visible: they 
> are not part of the package that gets instantiated.

I argue that they are. Each formal parameter can be thought as instantiated
(from the actual) in the package, rather than passed from outside.

> That's clear from the 
> syntax (they're outside the package). You're going to say that discriminants 
> are outside of the type, too, but they're also visible. I can't argue with 
> that beyond saying that that placement of discriminants is just awful; I 
> place them in the wrong place and continually forget to include them in 
> aggregates because they're well away from the other components.

That depends on the mental model of the discriminant. If the discriminant
is a type constraint, then you are right. But in Ada this concept, if ever
existed, has been eroded. Presently discriminant is merely an immutable
component. I am also in favor the "constraint" model, and yes, in this
model it would be reasonable to make discriminants invisible, e.g. when
they are used for construction and then dropped. But that is not the Ada
model now.

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

Re: Generic package parameters not externally visible : what's the rational ?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:10eygvuzeit9g.xwy2wanxoxgf$.dlg@40tude.net...
> On Tue, 27 Oct 2009 16:08:09 -0500, Randy Brukardt wrote:
...
>> I'm not sure that it "makes perfect sense" for them to be visible: it 
>> would
>> surely increase the chance of name collisions outside of the package.
>
> Sorry, but that is a "generic" property of anything declared in a generic
> package. Two instances of the same generic packages always collide when
> "use"-ed.

No, I was thinking of name collisions when the formal and actual have the 
same name (that is very common for subprogram parameters and is not uncommon 
in generic as well). If the formal is also visible, you end up with two 
things with the same name. Something like:

   generic
       type Int is range <>;
   package Gen is
       ...
   end Gen;

   with Gen;
   package Test is
       type Int is range ...;
       package My_Gen is new Gen (Int);
   end Test;

   with Test;
   procedure Check is
      use Test, Test.Gen;
      Obj : Int; -- (1)
   ...

(1) is legal by the current rules, but if the formal was visible, it would 
become illegal because there would be two Int's visible. That would become 
worse if any of the proposals for integrated instantiations are adopted, 
because both Ints would be visible in the same scope, and thus use Test 
would become ineffective: exactly the reverse of what is wanted from an 
integrated instantiation.

...
>> That's clear from the
>> syntax (they're outside the package). You're going to say that 
>> discriminants
>> are outside of the type, too, but they're also visible. I can't argue 
>> with
>> that beyond saying that that placement of discriminants is just awful; I
>> place them in the wrong place and continually forget to include them in
>> aggregates because they're well away from the other components.
>
> That depends on the mental model of the discriminant. If the discriminant
> is a type constraint, then you are right. But in Ada this concept, if ever
> existed, has been eroded. Presently discriminant is merely an immutable
> component. I am also in favor the "constraint" model, and yes, in this
> model it would be reasonable to make discriminants invisible, e.g. when
> they are used for construction and then dropped. But that is not the Ada
> model now.

...other than for Unchecked_Unions, and even there the model is incomplete. 
(You can reference the discriminant in a context where it can be determined, 
such as for a constrained object, even though it is not stored anywhere. But 
you can't reference it if the object is unconstrained.)

                                    Randy.

Re: Generic package parameters not externally visible : what's the rational ?

[Dmitry A. Kazakov]

On Wed, 28 Oct 2009 14:19:58 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:10eygvuzeit9g.xwy2wanxoxgf$.dlg@40tude.net...
>> On Tue, 27 Oct 2009 16:08:09 -0500, Randy Brukardt wrote:
> ...
>>> I'm not sure that it "makes perfect sense" for them to be visible: it would
>>> surely increase the chance of name collisions outside of the package.
>>
>> Sorry, but that is a "generic" property of anything declared in a generic
>> package. Two instances of the same generic packages always collide when
>> "use"-ed.
> 
> No, I was thinking of name collisions when the formal and actual have the 
> same name (that is very common for subprogram parameters and is not uncommon 
> in generic as well). If the formal is also visible, you end up with two 
> things with the same name. Something like:
> 
>    generic
>        type Int is range <>;
>    package Gen is
>        ...
>    end Gen;
> 
>    with Gen;
>    package Test is
>        type Int is range ...;
>        package My_Gen is new Gen (Int);
>    end Test;
> 
>    with Test;
>    procedure Check is
>       use Test, Test.Gen;
>       Obj : Int; -- (1)
>    ...
> 
> (1) is legal by the current rules, but if the formal was visible, it would 
> become illegal because there would be two Int's visible. That would become 
> worse if any of the proposals for integrated instantiations are adopted, 
> because both Ints would be visible in the same scope, and thus use Test 
> would become ineffective: exactly the reverse of what is wanted from an 
> integrated instantiation.

It is clear that some code will become illegal. Here is another example of
a collision upon instantiation in the current version of Ada:

   generic
      type I is (<>);
   package P is
      type T is tagged null record;
      procedure Foo (Obj : T; X : I);
      procedure Foo (Obj : T; X : Integer);
   end P;

   package Bar is new P (Integer); -- Boom!

I don't think we should much care about backward compatibility with regard
to generics.

My take is that any generic code is potentially broken. Anyone who uses
generics beyond very trivial cases should know that, and mentally prepare
himself to fix his code over and over again.

>>> That's clear from the
>>> syntax (they're outside the package). You're going to say that discriminants
>>> are outside of the type, too, but they're also visible. I can't argue with
>>> that beyond saying that that placement of discriminants is just awful; I
>>> place them in the wrong place and continually forget to include them in
>>> aggregates because they're well away from the other components.
>>
>> That depends on the mental model of the discriminant. If the discriminant
>> is a type constraint, then you are right. But in Ada this concept, if ever
>> existed, has been eroded. Presently discriminant is merely an immutable
>> component. I am also in favor the "constraint" model, and yes, in this
>> model it would be reasonable to make discriminants invisible, e.g. when
>> they are used for construction and then dropped. But that is not the Ada
>> model now.
> 
> ...other than for Unchecked_Unions, and even there the model is incomplete. 
> (You can reference the discriminant in a context where it can be determined, 
> such as for a constrained object, even though it is not stored anywhere. But 
> you can't reference it if the object is unconstrained.)

Yes, I also thought about Unchecked_Unions. It would be great to have
checked Unchecked_Unions without "case" (:-))

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

Re: Generic package parameters not externally visible : what's the rational ?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1kf8mo4r9lqxg.1tdhqe6femt9m.dlg@40tude.net...
...
> I don't think we should much care about backward compatibility with regard
> to generics.

Well, I doubt that would be very popular with anyone that has existing Ada 
code that they want to use with the latest version of the language.

As Robert Dewar says, incompatibilities have a very high bar. There has to 
be real and compelling value for an incompatibility. I don't see that in 
this case that that it not clear that the revised situation is really better 
than the current one -- it's mostly a sideways move.

> My take is that any generic code is potentially broken. Anyone who uses
> generics beyond very trivial cases should know that, and mentally prepare
> himself to fix his code over and over again.

That's pretty cynical. Most of time, once you get your generic working, you 
hardly every touch it again. Besides, you could make the above statement for 
almost any Ada (or other programming language) code when it is reused.

                                     Randy.

Re: Generic package parameters not externally visible : what's the rational ?

[Dmitry A. Kazakov]

On Thu, 29 Oct 2009 18:03:02 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1kf8mo4r9lqxg.1tdhqe6femt9m.dlg@40tude.net...
> ...
>> I don't think we should much care about backward compatibility with regard
>> to generics.
> 
> Well, I doubt that would be very popular with anyone that has existing Ada 
> code that they want to use with the latest version of the language.
> 
> As Robert Dewar says, incompatibilities have a very high bar. There has to 
> be real and compelling value for an incompatibility. I don't see that in 
> this case that that it not clear that the revised situation is really better 
> than the current one -- it's mostly a sideways move.

True, but there are two very different cases, depending on whether the
change is in the semantics or else detected by the compiler. The latter is
not a big issue. If we one day decided to use the word "kill" instead of
"abort", that would be rather minor nuisance. But if we decided that
"abort" would spawn a copy of the task, that would be a catastrophe.

>> My take is that any generic code is potentially broken. Anyone who uses
>> generics beyond very trivial cases should know that, and mentally prepare
>> himself to fix his code over and over again.
> 
> That's pretty cynical.

Yes. After years of using generics you have to become cynical. (:-))

> Most of time, once you get your generic working, you 
> hardly every touch it again.

Huh, I have lost my illusions long ago. It stays fixed right until a next
compiler bug or a next fix of a compiler bug. Most of the generics are in
half workarounds for programmer's misunderstanding of how generics actually
work, for some compiler bugs, for some silly language limitations.

> Besides, you could make the above statement for 
> almost any Ada (or other programming language) code when it is reused.

To some extent, but the difference is qualitative. The only other Ada issue
of comparable damaging potential is the lack of exception contracts. My
personal estimation is that about 20% of time is spent on fixing generics
and 20-30% on catching unexpected exceptions.

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

Re: Generic package parameters not externally visible : what's the rational ?

[Stephen Leake]

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

> My take is that any generic code is potentially broken. Anyone who uses
> generics beyond very trivial cases should know that, and mentally prepare
> himself to fix his code over and over again.

That is certainly not my experience. I use generics extensively; it's
one of the best features of the language.

-- 
-- Stephe

Re: Generic package parameters not externally visible : what's the rational ?

[Dmitry A. Kazakov]

On Fri, 30 Oct 2009 06:25:21 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> My take is that any generic code is potentially broken. Anyone who uses
>> generics beyond very trivial cases should know that, and mentally prepare
>> himself to fix his code over and over again.
> 
> That is certainly not my experience. I use generics extensively; it's
> one of the best features of the language.

Do you use generic in other generics?

How does look the hierarchy matrix of?

This requires a bit explanation. A set of generics sharing some common
parameter (like the number type in a generic matrix package) are kind of
class, i.e. they declare sets of types dependant on the parameter (like
vector, matrix etc). I call this almost "trivial".

Non-trivial it becomes when you have several such axes.

Here is an example of a mesh of generic packages with 4 axes:

   http://www.dmitry-kazakov.de/ada/fuzzy.htm#8

Note that semantically the example is quite simple, almost evident. Its
implementation and use is horrific. I would never consider it "fixed".

As for being the "best language feature", I hope that you would easily find
lots of more useful and advanced Ada features. What about unconstrained
types? User-defined numeric types? Packages (vs. types) as encapsulation
modules? If any of these were removed it would not be Ada. On the contrary,
Ada without generics sounds quite plausible to me.

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

Re: Generic package parameters not externally visible : what's the rational ?

[Hibou57 (Yannick Duchêne)]

On 30 oct, 20:32, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> Do you use generic in other generics?

While I do not know if it is the kind of reply you were expected, here
is mine : I use generics in other generics, when a generic has a
formal type parameter which come from another generic package. If want
want to assert the type T is provided (or derived from the one
provided) by a package P, then both P and T must appear in the
parameters. If P is generic (this can be legitimate), then you end up
with a generic using another generic.

Note : and in that case, this may be useful to make this package
visible from the outside (exporting the content via renames and
subtype, is not always done exhaustively)

You may also understand you can have generics dealing with generics,
when you use the Mixin pattern to add features in a well designed way,
to that if you ever modify the Mixin package, then modifications
applies to all the package created with this Minxin. The Mixin may be
generic, and the package it receives as a parameter as well.

Apologizes if this was not the kind of question you were requesting
about.

Re: Generic package parameters not externally visible : what's the rational ?

[Dmitry A. Kazakov]

On Fri, 30 Oct 2009 19:06:56 -0700 (PDT), Hibou57 (Yannick Duch�ne) wrote:

> On 30 oct, 20:32, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> Do you use generic in other generics?
> 
> While I do not know if it is the kind of reply you were expected, here
> is mine : I use generics in other generics, when a generic has a
> formal type parameter which come from another generic package. If want
> want to assert the type T is provided (or derived from the one
> provided) by a package P, then both P and T must appear in the
> parameters. If P is generic (this can be legitimate), then you end up
> with a generic using another generic.
>
> Note : and in that case, this may be useful to make this package
> visible from the outside (exporting the content via renames and
> subtype, is not always done exhaustively)

Yes, I do it as well. This is the case when a formal parameter of a generic
is used in another generic.

Note that a generic child package can use formals of its parent. That is
the case why your proposal about visibility is so important in my eyes. It
is an *obvious* language bug.

The case is represented here:

generic
   type T is private;
package P is
end P;

generic
package P.Q is
   Y : T;
end P.Q;

with P.Q;
generic
   with package PQ is new P.Q (<>);
package R is
   X : PQ.T; -- Wring! You cannot see T, and there is no way to name it
end R;

In R you see Y of a "non-existent type".  This is obviously broken to me.

(Yes, I am extensively using the trick of subtype and renaming formal
parameters you wrote about earlier)

But as I said, generics are broken per their nature. With the time it gets
only worse. (:-()

> You may also understand you can have generics dealing with generics,
> when you use the Mixin pattern to add features in a well designed way,
> to that if you ever modify the Mixin package, then modifications
> applies to all the package created with this Minxin. The Mixin may be
> generic, and the package it receives as a parameter as well.

Yes I do it very often. But to give a word of warning, it is a road to
hell. In our current project the diagram of generic units is several pages
long, because of mixins. There is no other way because "high language
priests" have decided that multiple inheritance were bad for us, so the
language has crippled interface types instead of normal MI. The result is
just horrific. Mixin is a bad design pattern, but I wrote about it and
generics many times before.

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

Re: Generic package parameters not externally visible : what's the rational ?

[Hibou57 (Yannick Duchêne)]

On 31 oct, 10:14, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> Note that a generic child package can use formals of its parent. That is
> the case why your proposal about visibility is so important in my eyes. It
> is an *obvious* language bug.

A step to the side, still related to your comment ...

Although related by derivation, my packages were all along each others
(I'm experimenting, so I try many things before I choose and know
why). I've started to rework all package, to use child package when
possible.

It seems it saves a lot to do so : shared generic parameters, so less
generic parameters needed for instantiation.

I would like to say I feel (from higher to lower importance) child are
nice for :
1) Shared privates subset (formally required)
2) Generics (not formally required, but may save a lot of stuff)
3) Mapping domain organization (nice, but not really required,
although useful)
?) I'm still wondering about child packages and derivations (another
subject opened about it).

Generic package hierarchy is nicer than I previously supposed

Re: Generic package parameters not externally visible : what's the rational ?

[Dmitry A. Kazakov]

On Tue, 3 Nov 2009 00:25:24 -0800 (PST), Hibou57 (Yannick Duch�ne) wrote:

> On 31 oct, 10:14, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> Note that a generic child package can use formals of its parent. That is
>> the case why your proposal about visibility is so important in my eyes. It
>> is an *obvious* language bug.
> 
> A step to the side, still related to your comment ...
> 
> Although related by derivation, my packages were all along each others
> (I'm experimenting, so I try many things before I choose and know
> why). I've started to rework all package, to use child package when
> possible.
> 
> It seems it saves a lot to do so : shared generic parameters, so less
> generic parameters needed for instantiation.

There is also a competitive way of "generic interface package", so to say.
That is when generic parameters are passed with another generic package
rather than directly. E.g.:

generic
   type T is private;
   with function "+" (Left, Right : T) return T;
package Generic_Interface is
   -- No own declarations, the package promotes its formal parameters
   -- to other packages
end Generic_Interface;

with Generic_Interface;
generic
   with package Parameters is new Generic_Interface (<>);
package P is
   -- Here we can define some further operations on Parameters.T and
   -- other types based on Parameters.T
end P;

> Generic package hierarchy is nicer than I previously supposed

Yes, but beware that there are *three* hierarchies:

1. one of the generic packages
2. of the instances of generic packages (you can instantiate a generic
child of generic A as a non-generic child of non-generic B)
3. of nested packages (you can instantiate within a package)

A creative use of 1-3 may create a perfect mess out of your program...

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

Re: Generic package parameters not externally visible : what's the rational ?

[Hibou57 (Yannick Duchêne)]

On 3 nov, 10:59, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> > Generic package hierarchy is nicer than I previously supposed
>
> Yes, but beware that there are *three* hierarchies:
>
> 1. one of the generic packages
> 2. of the instances of generic packages (you can instantiate a generic
> child of generic A as a non-generic child of non-generic B)
> 3. of nested packages (you can instantiate within a package)
>
> A creative use of 1-3 may create a perfect mess out of your program...
I was not really sure about the meaning of “ mess out ” (the term you
used), now I suppose this may mean “ real mess ”, and here is why.

I see at least three productive enough mess seeds with generic child
hierarchy (from the less to the most nasty)
1) The implicit with which comes with all child packages, generic or
not (I had never really enjoyed this implicit With).
2) The miss-match between the generic Withed path and the actual
instance matching path
3) The naming nightmare which comes while creating the instance
hierarchy

With more details :
1) Dependencies are clearly explicit with classic packages, this is no
more the case with child packages. I know this is the same with non-
generic, but this is not really welcome to me (I sometime dream about
child packages hierarchy which would require explicit With).
2) Let A, a generic package, B, a generic child of A, C, an instance
of A, then instantiating C.B requires to With A.B. I understand why it
is this way (although this could have been another way too), but an
A.B whose A actually and implicitly match C, does not help to be
clear.
3) The one I really do not like : with same packages as in #2,
instantiating A.B as a child of C, requires to use a new name which
cannot be B, and if the name B is the most natural one in the context
of A, this mostly mean this would be the same in the context of C,
thus the naming nightmare. For the purpose of the comment which will
follows right after, let call it D.

To reword what you were saying, there is indeed three hierarchies and
not two : the source generic hierarchy (like A.B), the instance
hierarchy (like C.D) and beside this instance hierarchy, another
implicit generic hierarchy (like C.B), and this is hard to deal with.

Yes, now I'm sure you were really talking about mess.

#3 may be solved using a standard prefix for all generics, like
Generic_, but I do not like it, because this easily ends in too much
long paths. Now I'm seeking for a more clever way to easily handle
this three-hierarchies structure. This would not Solve #2 any way.

(Hope I was Ok to post these comments here)

Re: Generic package parameters not externally visible : what's the rational ?

[Dmitry A. Kazakov]

On Thu, 5 Nov 2009 02:38:46 -0800 (PST), Hibou57 (Yannick Duch�ne) wrote:

> #3 may be solved using a standard prefix for all generics, like
> Generic_, but I do not like it, because this easily ends in too much
> long paths. Now I'm seeking for a more clever way to easily handle
> this three-hierarchies structure. This would not Solve #2 any way.

I am using "Generic_" because it is almost impossible to do anything
otherwise if you have really many generics. And I do, because I have to.

If anything has to have a separate name space then generics is the first
candidate. Generic unit is not a unit, it is a macro, a term of the meta
language. There is no reason to have it also a proper name in the object
language. The object language does not operate it. This is comparable to
the names of the "cut" and "paste" buttons in the IDE. Why an integer
variable may not have the same name as the "paste" button? (:-))

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

Re: Generic package parameters not externally visible : what's the rational ?

[Hibou57 (Yannick Duchêne)]

On 5 nov, 12:00, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> I am using "Generic_" because it is almost impossible to do anything
> otherwise if you have really many generics. And I do, because I have to.
Then, may be a point to discuss about : when using a "_Mixin" packages
(or "_Facet", after Rosen, this is the same), as a "_Mixin" package is
generic (this would not make sense otherwise), the "Generic_" prefix
may not be needed when the package is "_Mixin". Or perhaps
"_Mixin" (nor "_Facet") should not be used after-all, and only
"Generic_" should be (showing no difference between "_Mixin" and
others "Generic_").

Re: Generic package parameters not externally visible : what's the rational ?

[Dmitry A. Kazakov]

On Thu, 5 Nov 2009 04:16:11 -0800 (PST), Hibou57 (Yannick Duch�ne) wrote:

> On 5 nov, 12:00, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> I am using "Generic_" because it is almost impossible to do anything
>> otherwise if you have really many generics. And I do, because I have to.

> Then, may be a point to discuss about : when using a "_Mixin" packages
> (or "_Facet", after Rosen, this is the same), as a "_Mixin" package is
> generic (this would not make sense otherwise), the "Generic_" prefix
> may not be needed when the package is "_Mixin". Or perhaps
> "_Mixin" (nor "_Facet") should not be used after-all, and only
> "Generic_" should be (showing no difference between "_Mixin" and
> others "Generic_").

Sounds interesting. Can you give some examples?

BTW, Generic_ becomes quite obtrusive with children packages. When you
have:

   generic
      ...
   package Generic_Grandfather.Geneirc_Father.Generic_Son is

you start to think who is a generic_idiot here? (:-))

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

Re: Generic package parameters not externally visible : what's the rational ?

[Hibou57 (Yannick Duchêne)]

On 5 nov, 15:09, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Thu, 5 Nov 2009 04:16:11 -0800 (PST), Hibou57 (Yannick Duchêne) wrote:
> > On 5 nov, 12:00, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> >> I am using "Generic_" because it is almost impossible to do anything
> >> otherwise if you have really many generics. And I do, because I have to.
> > Then, may be a point to discuss about : when using a "_Mixin" packages
> > (or "_Facet", after Rosen, this is the same), as a "_Mixin" package is
> > generic (this would not make sense otherwise), the "Generic_" prefix
> > may not be needed when the package is "_Mixin". Or perhaps
> > "_Mixin" (nor "_Facet") should not be used after-all, and only
> > "Generic_" should be (showing no difference between "_Mixin" and
> > others "Generic_").
>
> Sounds interesting. Can you give some examples?
You are more experienced than I am, so this may not sounds so much
interesting after-all

I was talking about the "_Mixin" design pattern, which is a suggested
way to do something like MI (Multiple Inheritance) with Ada. I think
you do not use it, as your talked about some personal success stories
you had with the Interface construct, and "_Mixin" is supposed to be
the generic way to do most of what Interface can do. In the previous
context, I was to say that as the "_Mixin" design pattern only makes
sense with generics, if a package as the "_Mixin" suffix, there is no
need to add the "Generic_" prefix, because "_Mixin" implies the
package is generic. Then, as "_Mixin" and "Generic_" both means
"generic", I was simply wondering if "_Mixin" was to be really used or
not (finally, I think it is of real interest, so I did not drop
"_Mixin" in favor or "Generic_").

Providing I've understood your question the proper way.

Re: Generic package parameters not externally visible : what's the rational ?

[Dmitry A. Kazakov]

On Fri, 6 Nov 2009 04:19:10 -0800 (PST), Hibou57 (Yannick Duch�ne) wrote:

> On 5 nov, 15:09, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Thu, 5 Nov 2009 04:16:11 -0800 (PST), Hibou57 (Yannick Duch�ne) wrote:
>>> On 5 nov, 12:00, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>>> wrote:
>>>> I am using "Generic_" because it is almost impossible to do anything
>>>> otherwise if you have really many generics. And I do, because I have to.
>>> Then, may be a point to discuss about : when using a "_Mixin" packages
>>> (or "_Facet", after Rosen, this is the same), as a "_Mixin" package is
>>> generic (this would not make sense otherwise), the "Generic_" prefix
>>> may not be needed when the package is "_Mixin". Or perhaps
>>> "_Mixin" (nor "_Facet") should not be used after-all, and only
>>> "Generic_" should be (showing no difference between "_Mixin" and
>>> others "Generic_").
>>
>> Sounds interesting. Can you give some examples?
> You are more experienced than I am, so this may not sounds so much
> interesting after-all
> 
> I was talking about the "_Mixin" design pattern, which is a suggested
> way to do something like MI (Multiple Inheritance) with Ada. I think
> you do not use it, as your talked about some personal success stories
> you had with the Interface construct, and "_Mixin" is supposed to be
> the generic way to do most of what Interface can do.

In fact I am forced to use both because MI is not supported for concrete
types. I have MI only in the interfaces. There are generics to provide
implementations for the concrete types implementing those interfaces. It is
awfully complex, I hate it, but I know no other way to do this.

The problem of naming is only of a facet of the bigger mess. It is a
consequence of a bad pattern, but that pattern is imposed by the language.

> In the previous
> context, I was to say that as the "_Mixin" design pattern only makes
> sense with generics, if a package as the "_Mixin" suffix, there is no
> need to add the "Generic_" prefix, because "_Mixin" implies the
> package is generic. Then, as "_Mixin" and "Generic_" both means
> "generic", I was simply wondering if "_Mixin" was to be really used or
> not (finally, I think it is of real interest, so I did not drop
> "_Mixin" in favor or "Generic_").

Yes, that was my question too. It looks to me an interesting idea to name
generics after their roles. Mixin is probably too general, there are
several scenarios where generics are used. MI emulation is one case.
Another (also mixin) is that when you had layered protocols and did not
want to specify the transport layer. You could make it a generic parameter,
an abstract base type from which higher levels derive. Yet another is
parallel hierarchies of types, like of objects and of handles to them etc. 

Maybe such common patterns could be classified and given recognizable
suffixes or prefixes instead of rather empty Generic_, which adds no value
beyond merely separating the name space.

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

Re: Generic package parameters not externally visible : what's the rational ?

[Hibou57 (Yannick Duchêne)]

On 30 oct, 20:32, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> Here is an example of a mesh of generic packages with 4 axes:
>
>    http://www.dmitry-kazakov.de/ada/fuzzy.htm#8
>
Seems nice to study, will look at it

Re: Generic package parameters not externally visible : what's the rational ?

[Stephen Leake]

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

> On Fri, 30 Oct 2009 06:25:21 -0400, Stephen Leake wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> My take is that any generic code is potentially broken. Anyone who uses
>>> generics beyond very trivial cases should know that, and mentally prepare
>>> himself to fix his code over and over again.
>> 
>> That is certainly not my experience. I use generics extensively; it's
>> one of the best features of the language.
>
> Do you use generic in other generics?

Yes. See http://www.stephe-leake.org/ada/sal.html, in particular the
sal-gen-alg hierarchy.

You'll have to download and unpack the code; my webserver doesn't have
enough space for the unpacked HTML version (guess it's time to spend
more money on the web server).

> This requires a bit explanation. A set of generics sharing some common
> parameter (like the number type in a generic matrix package) are kind of
> class, i.e. they declare sets of types dependant on the parameter (like
> vector, matrix etc). I call this almost "trivial".

Right; SAL has that in sal-gen_math.

> Non-trivial it becomes when you have several such axes.

Yes. For example, Unbounded_Arrays have Index_Type and Item_Type.

> Here is an example of a mesh of generic packages with 4 axes:
>
>    http://www.dmitry-kazakov.de/ada/fuzzy.htm#8
>
> Note that semantically the example is quite simple, almost evident. Its
> implementation and use is horrific. I would never consider it "fixed".

Sorry, I don't see the complexity; what are the four axes?

There are problems that can't be solved in Ada; that doesn't make Ada
useless!

Problems that can be almost solved, and push the boundaries of the
language, and be very frustrating.

> As for being the "best language feature", I hope that you would easily find
> lots of more useful and advanced Ada features. 

Defining a metric on Ada features is not easy. My vote for best
feature changes month to month; the best one is the one I most recently
used to solve a hard problem. This month, that's generics.

In previous months, it's been tasking, dispatching, interfaces, and
rep clauses on packed record types.

> What about unconstrained types? 

Yes, if the metric is "things that other languages don't have", that's
high on the list.

> User-defined numeric types? 

Not so important; I end up using the compiler types anyway, except for
Unsigned_n in packed records. Ada should have defined _all_ of
Unsigned_n, for n = 1 .. 64, in the first place.

Distinct numeric types (derived from compiler defined types) is important.

> Packages (vs. types) as encapsulation modules? 

That's just obvious; I wouldn't use a language that doesn't have that :).

Even C++ has that now. Not called packages, but close enough.

> If any of these were removed it would not be Ada. On the contrary,
> Ada without generics sounds quite plausible to me.

True. Ada without overloading is "plausible" as well. But that's just
another metric.

-- 
-- Stephe

Re: Generic package parameters not externally visible : what's the rational ?

[Dmitry A. Kazakov]

On Sat, 31 Oct 2009 08:44:18 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> Non-trivial it becomes when you have several such axes.
> 
> Yes. For example, Unbounded_Arrays have Index_Type and Item_Type.

Now consider I/O packages for Item_Type and Index_Type, and a package for
Unbounded_Array I/O that uses all these three. At some point the structure
of dependencies becomes a DAG.

>> Here is an example of a mesh of generic packages with 4 axes:
>>
>>    http://www.dmitry-kazakov.de/ada/fuzzy.htm#8
>>
>> Note that semantically the example is quite simple, almost evident. Its
>> implementation and use is horrific. I would never consider it "fixed".
> 
> Sorry, I don't see the complexity; what are the four axes?

Base number, enumeration of truth values, arrays of, map to the truth
value. These are initial parameters which group themselves in different
combinations to produce new types in generic instances of the second
generation of packages. These are selected in new combinations in the third
generation and so on.

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