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?

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