library level required or not?

library level required or not?

[Marius Amado Alves]

Language lawers, please help me.

I have in my notes that an object, of a type declared in package Ada or 
descendants, is not required to be defined at library level, even if the type 
is controlled. (I know I can declare unbounded strings, which are clearly 
controlled, in a 'main' procedure.)

I vaguely recall deriving this rule from the RM, but now I cannot find the 
clause. Is the rule true? By what clause?

Thanks a lot.

Re: library level required or not?

[Preben Randhol]

On 2004-03-01, Marius Amado Alves <maa@liacc.up.pt> wrote:
>
> Ok, I found Ada Issue 115, which clarifies that "a language-defined generic 
> package may be instantiated at any nesting depth."
>
> I'm still in the dark regarding unbounded strings though, as 
> Ada.Strings.Unbounded is not generic.

What do you mean?

-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: library level required or not?

[Marius Amado Alves]

Myself:
> I have in my notes that an object, of a type declared in package Ada or
> descendants, is not required to be defined at library level, even if the
> type is controlled. (I know I can declare unbounded strings, which are
> clearly controlled, in a 'main' procedure.)
>
> I vaguely recall deriving this rule from the RM, but now I cannot find the
> clause. Is the rule true? By what clause?

Ok, I found Ada Issue 115, which clarifies that "a language-defined generic 
package may be instantiated at any nesting depth."

I'm still in the dark regarding unbounded strings though, as 
Ada.Strings.Unbounded is not generic.

Re: library level required or not?

[Marius Amado Alves]

On Monday 01 March 2004 18:41, Preben Randhol wrote:
> On 2004-03-01, Marius Amado Alves <maa@liacc.up.pt> wrote:
> > Ok, I found Ada Issue 115, which clarifies that "a language-defined
> > generic package may be instantiated at any nesting depth."
> >
> > I'm still in the dark regarding unbounded strings though, as
> > Ada.Strings.Unbounded is not generic.
>
> What do you mean?

If you look at the GNAT sources for example, you'll find that Unbounded_String 
is controlled. And yet you can declare an unbounded string inside a 'main' 
program. Try pulling that out with your own controlled type.

Re: library level required or not?

[Simon Wright]

Marius Amado Alves <maa@liacc.up.pt> writes:

> On Monday 01 March 2004 18:41, Preben Randhol wrote:
> > On 2004-03-01, Marius Amado Alves <maa@liacc.up.pt> wrote:
> > > Ok, I found Ada Issue 115, which clarifies that "a language-defined
> > > generic package may be instantiated at any nesting depth."
> > >
> > > I'm still in the dark regarding unbounded strings though, as
> > > Ada.Strings.Unbounded is not generic.
> >
> > What do you mean?
> 
> If you look at the GNAT sources for example, you'll find that
> Unbounded_String is controlled. And yet you can declare an unbounded
> string inside a 'main' program. Try pulling that out with your own
> controlled type.

?

There is a difference between instantiating the generic, which amounts
to defining a new type derived from Controlled, and declaring an
instance of a type .. is this 3.9.1(3)?

(I also see (4), "A type extension shall not be declared in a generic
body if the parent type is declared outside that body." I think ISNBAL
-- I shall never be a lawyer)

-- 
Simon Wright                               100% Ada, no bugs.

Re: library level required or not?

[Marius Amado Alves]

> > If you look at the GNAT sources for example, you'll find that
> > Unbounded_String is controlled. And yet you can declare an unbounded
> > string inside a 'main' program. Try pulling that out with your own
> > controlled type.
>
> ?
>
> There is a difference between instantiating the generic, which amounts
> to defining a new type derived from Controlled, and declaring an
> instance of a type

You're right, I mixed things up... a bit.

> .. is this 3.9.1(3)?

I think so, that it is that clause that ultimately obliges controlled objects 
to be defined at library level. So what's the deal with Unbounded_String? 
(ISNBAL too, obvioulsy.)

Re: library level required or not?

[Randy Brukardt]

"Marius Amado Alves" <maa@liacc.up.pt> wrote in message
news:mailman.48.1078160769.327.comp.lang.ada@ada-france.org...
> Language lawers, please help me.
>
> I have in my notes that an object, of a type declared in package Ada or
> descendants, is not required to be defined at library level, even if the
type
> is controlled. (I know I can declare unbounded strings, which are clearly
> controlled, in a 'main' procedure.)
>
> I vaguely recall deriving this rule from the RM, but now I cannot find the
> clause. Is the rule true? By what clause?

*Types* derived from Controlled have to be at library-level. *Objects* have
no such restrictions. I can't point at a rule that says that, for the simple
reason that there isn't any. In the absense of a specific rule, of course,
there is no restriction, and that's the case here.

                         Randy.

Re: library level required or not?

[Marius Amado Alves]

> *Types* derived from Controlled have to be at library-level. *Objects* have
> no such restrictions.

Yes. My mind is much clearer now. Thanks.

Main subprogram at library level (was: library level required or not?)

[Jeffrey Carter]

Randy Brukardt wrote:

> *Types* derived from Controlled have to be at library-level.

I have just had an idea. Suppose we had a standard pragma that declared 
that a library-level subprogram was a main subprogram. The subprogram 
could then only be a main subprogram and could not be called by itself 
or another subprogram, only by the environment task.

The declarative region of such a subprogram would then be considered to 
be at the library level, allowing controlled types to be declared there.

This would make Ada a little easier for newcomers without impacting 
existing code, which would not have the pragma and hence would not allow 
controlled types there.

Has anything like this been proposed before? Any thoughts as to whether 
it is likely to fly if submitted as an AI?

-- 
Jeff Carter
"Your mother was a hamster and your father smelt of elderberries."
Monty Python & the Holy Grail
06

Re: library level required or not?

[Robert I. Eachus]

Simon Wright wrote:

> (I also see (4), "A type extension shall not be declared in a generic
> body if the parent type is declared outside that body." I think ISNBAL
> -- I shall never be a lawyer)

This rule seems very mysterious, but it is actually a simple rule! 
Well, simple compared to the alternative.  There are many weird things 
that you could do if this rule wasn't there.  Rather than have a dozen 
exceptions to other rules, this one rule takes care of all of them.

If you really need a type extension in a generic body, you can put the 
extension declaration in the private part of the package specification. 
  This way (necessary) checks can be made at the point of any 
instantiation.  If they succeed, fine.  If not the instantiation is 
illegal.  But the Ada model doesn't allow rejecting an instantiation 
because of declarations in the body of the generic.

Extending a type declared in the generic body itself can never cause a 
problem because the legality of those declarations can't depend on the 
characteristics of a generic formal parameter.

-- 
                                           Robert I. Eachus

"The only thing necessary for the triumph of evil is for good men to do 
nothing." --Edmund Burke

Re: Main subprogram at library level (was: library level required or not?)

[Randy Brukardt]

"Jeffrey Carter" <spam@spam.com> wrote in message
news:FlS0c.14848$yZ1.11477@newsread2.news.pas.earthlink.net...
> Randy Brukardt wrote:
>
> > *Types* derived from Controlled have to be at library-level.
>
> I have just had an idea. Suppose we had a standard pragma that declared
> that a library-level subprogram was a main subprogram. The subprogram
> could then only be a main subprogram and could not be called by itself
> or another subprogram, only by the environment task.
>
> The declarative region of such a subprogram would then be considered to
> be at the library level, allowing controlled types to be declared there.
>
> This would make Ada a little easier for newcomers without impacting
> existing code, which would not have the pragma and hence would not allow
> controlled types there.
>
> Has anything like this been proposed before? Any thoughts as to whether
> it is likely to fly if submitted as an AI?

AI-344 proposes to remove the restriction altogether. Certainly a better
idea than eliminating it in one weird place...

(But I don't know what will happen with that AI - it has not been discussed
much to date.)

                 Randy.

Re: Main subprogram at library level

[Jeffrey Carter]

Randy Brukardt wrote:

> AI-344 proposes to remove the restriction altogether. Certainly a better
> idea than eliminating it in one weird place...

Eliminating it altogether, if possible, would be nice. I was coming from 
the position that the restriction is necessary. If it's not necessary, 
why do we have it?

However, I'm not sure that that the main subprogram's declarative region 
is really such a weird place. Lots of people, including some with Ada 
experience and knowledge of the restriction, assume that the main 
subprogram is at library level (until their compiler tells them 
otherwise and they post a message here asking why).

> (But I don't know what will happen with that AI - it has not been discussed
> much to date.)

I hope that changes.

-- 
Jeff Carter
"I spun around, and there I was, face to face with a
six-year-old kid. Well, I just threw my guns down and
walked away. Little bastard shot me in the ass."
Blazing Saddles
40

Re: Main subprogram at library level

[Dale Stanbrough]

In article <7qa1c.16379$yZ1.8619@newsread2.news.pas.earthlink.net>,
 Jeffrey Carter <spam@spam.com> wrote:

> Randy Brukardt wrote:
> 
> > AI-344 proposes to remove the restriction altogether. Certainly a better
> > idea than eliminating it in one weird place...
> 
> Eliminating it altogether, if possible, would be nice. I was coming from 
> the position that the restriction is necessary. If it's not necessary, 
> why do we have it?
> 
> However, I'm not sure that that the main subprogram's declarative region 
> is really such a weird place. Lots of people, including some with Ada 
> experience and knowledge of the restriction, assume that the main 
> subprogram is at library level (until their compiler tells them 
> otherwise and they post a message here asking why).

I hope I've got this right...!

It may not be at the "library level" (meaning you can place values in
heap/static storage) as the values will still have to be on the stack.
The main procedure can be called recursively, as well as being 
called as a simple procedure by others later on.

The validity of the compilation shouldn't be determined by who decides
to call it at some later date.

Dale

-- 
dstanbro@spam.o.matic.bigpond.net.au

Re: Main subprogram at library level

[Randy Brukardt]

"Jeffrey Carter" <spam@spam.com> wrote in message
news:7qa1c.16379$yZ1.8619@newsread2.news.pas.earthlink.net...
> Randy Brukardt wrote:
>
> > AI-344 proposes to remove the restriction altogether. Certainly a better
> > idea than eliminating it in one weird place...
>
> Eliminating it altogether, if possible, would be nice. I was coming from
> the position that the restriction is necessary. If it's not necessary,
> why do we have it?

Well, the AI proposed replacing this restriction by a bunch of others,
intended to prevent objects of a nested type from "leaking" out into an
outer scope (which is the real problem that has to be solved). The question
that hasn't been really answered is whether the proposed restrictions are
sufficient to solve the problem, and whether nested dispatching is really
implementable.

                Randy.

Re: Main subprogram at library level

[Jeffrey Carter]

Randy Brukardt wrote:

> Well, the AI proposed replacing this restriction by a bunch of others,
> intended to prevent objects of a nested type from "leaking" out into an
> outer scope (which is the real problem that has to be solved). The question
> that hasn't been really answered is whether the proposed restrictions are
> sufficient to solve the problem, and whether nested dispatching is really
> implementable.

I understand the problem. The AI sounds complicated, especially if no 
one is sure it's sufficient or even possible. My proposal is at least 
simple. That doesn't mean it would garner any support.

-- 
Jeff Carter
"You've got the brain of a four-year-old boy,
and I bet he was glad to get rid of it."
Horse Feathers
47