body stub not allowed in inner scope

body stub not allowed in inner scope

[Mehdi Saada]

I find that rule very limitating !
I need the procedures to know the context (access local variable).
Same with nested packages:
I need them to access local variable too, and be able to exit an enclosing loop. Though I'm not sure it's allowed either.
Without stuff like this, my working memory is already overflowed with a hundred lines.

Re: body stub not allowed in inner scope

[AdaMagica]

procedure P is
  procedure R is
    procedure I is separate;  -- illegal since in inner scope
  begin ... end R;
begin ... end P;
--------------------------
procedure P is
  procedure R is separate;  -- make enclosing a stub
begin ... end P;

separate (P)
procedure R is
  procedure I is separate;  -- now legal
begin ... end R;

separate (P.R)
procedure I is
begin ... end I;

Re: body stub not allowed in inner scope

[Mehdi Saada]

Thanks.
But that's ugly... How about fixing this for the next norm ?

Re: body stub not allowed in inner scope

[AdaMagica]

Am Mittwoch, 28. Februar 2018 15:30:28 UTC+1 schrieb Mehdi Saada:
> Thanks.
> But that's ugly... How about fixing this for the next norm ?

May be, but ... mere ugliness is not a sufficient reason for change. There are more important additions to come.

And any syntax and semantic change, small as it may be, has implications in the RM and in the compiler code. Think of the hierarchical unit name. There might be anonymous levels in between:

procedure P is
begin
  declare
    package Q is ... end Q;
    package body Q is separate;
  begin ... end;
end P;

So some more rules in the RM to formulate.

Re: body stub not allowed in inner scope

[Mehdi Saada]

I am aware of this. Sad but true. Eventhough those change in semantics might seem logical for a human being, it can become a nightmare to formulate and integrate with the preexisting rules.
I refactorized (is it the good term ?) my code, to put as much subprograms in a standalone package, and reduce the nested subprograms in the two cases where I really needed the context.
All is fine, EXCEPT I had to introduce an access to STRING where I wanted an inner block. It broke my heart.
Which gave me a main program like this:

with LEDIT; use LEDIT;
procedure MAIN is
   LINE: access constant String; -- EVIL!!
   CURSOR: NATURAL;
   procedure SEPARATE_NUMBER_AND_CONTENT is separate;
   procedure ANALYSE_LIST_COMMAND is separate;
begin
   while not END_OF_FILE(Standard_Input) loop
      LINE :=  new STRING'(TRIM(LET_ONLY_GRAPHIC_CHARACTERS(GET_LINE), LEFT));
...
   end loop;
   ...
end MAIN;

Whereas I wanted this, because SEPARTE... and ANALYSE... NEED to know about LINE, but can't be declared in a block.

while_loop
  declare
    LINE : STRING := PROCESSING(GET_LINE);
    BLABLA is separate;
  begin
    BLABLA;
  end;
end loop;

Re: body stub not allowed in inner scope

[Mehdi Saada]

More over, it's not merely about ugliness, but readibility, which is a main goal of Ada.

Re: body stub not allowed in inner scope

[Jeffrey R. Carter]

On 02/28/2018 02:01 PM, Mehdi Saada wrote:
> I find that rule very limitating !
> I need the procedures to know the context (access local variable).
> Same with nested packages:
> I need them to access local variable too, and be able to exit an enclosing loop. Though I'm not sure it's allowed either.
> Without stuff like this, my working memory is already overflowed with a hundred lines.

How do you write the separate body? Remember, you have to be able to handle

package body P is
    procedure Q is
       procedure R is separate;
    begin -- Q
       R;
    end Q;

    procedure Q (I : Integer) is
       procedure R is separate;
    begin -- Q
       R;
    end q;
end P;

-- 
Jeff Carter
"From this day on, the official language of San Marcos will be Swedish."
Bananas
28

Re: body stub not allowed in inner scope

[Simon Wright]

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

> On 02/28/2018 02:01 PM, Mehdi Saada wrote:
>> I find that rule very limitating !
>> I need the procedures to know the context (access local variable).
>> Same with nested packages:
>> I need them to access local variable too, and be able to exit an
>> enclosing loop. Though I'm not sure it's allowed either.
>> Without stuff like this, my working memory is already overflowed
>> with a hundred lines.
>
> How do you write the separate body? Remember, you have to be able to handle
>
> package body P is
>    procedure Q is
>       procedure R is separate;
>    begin -- Q
>       R;
>    end Q;
>
>    procedure Q (I : Integer) is
>       procedure R is separate;
>    begin -- Q
>       R;
>    end q;
> end P;

GNAT couldn't handle that even if it was the Qs that were separate.

Re: body stub not allowed in inner scope

[Jeffrey R. Carter]

On 02/28/2018 07:05 PM, Simon Wright wrote:
>>
>> package body P is
>>     procedure Q is
>>        procedure R is separate;
>>     begin -- Q
>>        R;
>>     end Q;
>>
>>     procedure Q (I : Integer) is
>>        procedure R is separate;
>>     begin -- Q
>>        R;
>>     end q;
>> end P;
> 
> GNAT couldn't handle that even if it was the Qs that were separate.

Sorry. That 2nd R should be S.

-- 
Jeff Carter
"From this day on, the official language of San Marcos will be Swedish."
Bananas
28

Re: body stub not allowed in inner scope

[Randy Brukardt]

"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:15c49c4e-726a-4fd7-bf35-c7d27ff9a491@googlegroups.com...
> Thanks.
> But that's ugly... How about fixing this for the next norm ?

Does anyone other than ACATS tests actually use stubs these days? Why? (We 
used to use them extensively, but only because Janus/Ada on 16-bit MS-DOS 
limited a single unit to 64K of generated code -- and our editors couldn't 
handle more than 256K of source code at a time. None of that makes sense 
today.)

                                        Randy.

Re: body stub not allowed in inner scope

[Randy Brukardt]

"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:ace36299-15fa-478f-9a9f-5484b9bfc92f@googlegroups.com...
...
> Whereas I wanted this, because SEPARTE... and ANALYSE... NEED to know 
> about LINE, but can't be declared in a block.
>
> while_loop
>  declare
>    LINE : STRING := PROCESSING(GET_LINE);
>    BLABLA is separate;
>  begin
>    BLABLA;
>  end;
> end loop;

This case would *never* be allowed, because there is no name for the blocks 
here. You'd have to give the block and loop a name for this to be 
meaningful. But it simply isn't worth the hassle -- don't modern IDEs allow 
collapsing the code in cases like this? (I don't know, I've never used a 
modern IDE beyond a few accidental openings of GPS. If they don't, why even 
bother with an IDE?)

                                 Randy.

Re: body stub not allowed in inner scope

[Mehdi Saada]

You got a point. At least GPS do, I saw that but IDE feel very bloated for my humble use, and I am not used to CLI editors either... Yeah, you can pity me.
I could name the block of course. Would it really be hard or not to implement this in this case ?

Re: body stub not allowed in inner scope

[J-P. Rosen]

Le 01/03/2018 à 00:23, Randy Brukardt a écrit :
> "Mehdi Saada" <00120260a@gmail.com> wrote in message 
> news:15c49c4e-726a-4fd7-bf35-c7d27ff9a491@googlegroups.com...
>> Thanks.
>> But that's ugly... How about fixing this for the next norm ?
> 
> Does anyone other than ACATS tests actually use stubs these days? Why? (We 
> used to use them extensively, but only because Janus/Ada on 16-bit MS-DOS 
> limited a single unit to 64K of generated code -- and our editors couldn't 
> handle more than 256K of source code at a time. None of that makes sense 
> today.)
At least for task and protected bodies, which can't be child units.

Also, stubs have visibility to elements in the parent's body, although I
agree that direct visibility of global elements should be limited.


-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: body stub not allowed in inner scope

[Dmitry A. Kazakov]

On 01/03/2018 00:23, Randy Brukardt wrote:
> "Mehdi Saada" <00120260a@gmail.com> wrote in message
> news:15c49c4e-726a-4fd7-bf35-c7d27ff9a491@googlegroups.com...
>> Thanks.
>> But that's ugly... How about fixing this for the next norm ?
> 
> Does anyone other than ACATS tests actually use stubs these days?

I do.

> Why?

To move large subprograms out of the way. Usually they are called from 
some big case:

procedure This is separate;
procedure That is separate;

    case X is
      when This =>
         Do_This;
      when That =>
         Do_That;
      ...

This also helps to cut the lists of with/use clauses, because most of 
them needed for the separate body only.

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

Re: body stub not allowed in inner scope

[Simon Wright]

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

> Does anyone other than ACATS tests actually use stubs these days? Why?

My use case for stubs is that I have a code generator that transforms a
UML model into the framework of an Ada solution; subprograms, task and
protected type bodies are generated as separates, so that there's no
hassle with having the tool work out how not to overwrite the real
bodies. This was triggered by bad experiences with Rational Rose back in
2000.

I have to admit that the only commercial project that I'm aware of that
uses this tool is (if any work is being done at all) in very low-level
long term maintenance, and (on past evidence) supremely unlikely to be
interested in upgrading to a new Ada standard.

[I have one separate package body of 300 lines - to reduce clutter in a
package body that was already 260 lines. Even if emacs ada-mode would
now be able to fold it, it certainly couldn't then!]

Re: body stub not allowed in inner scope

[Niklas Holsti]

On 18-03-01 01:23 , Randy Brukardt wrote:
> "Mehdi Saada" <00120260a@gmail.com> wrote in message
> news:15c49c4e-726a-4fd7-bf35-c7d27ff9a491@googlegroups.com...
>> Thanks.
>> But that's ugly... How about fixing this for the next norm ?
>
> Does anyone other than ACATS tests actually use stubs these days? Why?

I occasionally use a stub when a subprogram has to be implemented 
differently for different compilation targets (say, embedded-SPARC vs 
PC-x86).

Generally I prefer to have different bodies of entire packages for 
different targets, but occasionally the difference is so small and local 
(or is a late addition) that separating just a subprogram is convenient.

Stubs are also used by unit-testing tools, which often add a stub 
procedure to a package under test, in order to access the declarations 
in the package body.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: body stub not allowed in inner scope

[Björn Lundin]

On 2018-03-01 00:23, Randy Brukardt wrote:
> "Mehdi Saada" <00120260a@gmail.com> wrote in message 
> news:15c49c4e-726a-4fd7-bf35-c7d27ff9a491@googlegroups.com...
>> Thanks.
>> But that's ugly... How about fixing this for the next norm ?
> 
> Does anyone other than ACATS tests actually use stubs these days? 

If stub = separate then
we do - a lot.

>Why? 
Auto-generated code.
We pass record structures back and forth to our c#-client over a socket.
The records are defined in xml
The (de)/serialization is  generated by a tool as separate procedures,
and the part of the server that receives a call from client
uses a big if/elsif to find out what just arrived.
It then calls the correct de-serialization procedure which is an
auto-generated separate.

(the tool also generates corresponding (de)/serialization for c#)


-- 
--
Björn

Re: body stub not allowed in inner scope

[marciant]

On Wednesday, February 28, 2018 at 6:23:32 PM UTC-5, Randy Brukardt wrote:
> 
> Does anyone other than ACATS tests actually use stubs these days? Why? (We 
> used to use them extensively, but only because Janus/Ada on 16-bit MS-DOS 
> limited a single unit to 64K of generated code -- and our editors couldn't 
> handle more than 256K of source code at a time. None of that makes sense 
> today.)

Definitely: To teezing out minor differences between big packages due to "the same" program running on updated "hardware": keepping more code "common".

Re: body stub not allowed in inner scope

[Shark8]

On Wednesday, February 28, 2018 at 4:23:32 PM UTC-7, Randy Brukardt wrote:
> "Mehdi Saada" wrote in message 
> news:15c49c4e-726a-4fd7-bf35-c7d27ff9a491...
> > Thanks.
> > But that's ugly... How about fixing this for the next norm ?
> 
> Does anyone other than ACATS tests actually use stubs these days? Why?

I do, sometimes.
Usually to put a particularly knotty or verbose chunk of code. For example, in an interpreter I was writing I put all the operators, which 'explodes' (m*n; m = #types, n = #operators) based on the number of internal types, in their own package and made the body separate.

I've also used it with parsing & stream-I/O functions:
Function Parse( Text : String ) return Program;
Function Parse( Text : String ) return Program is Separate;

Procedure Read(
        Stream : not null access Ada.Streams.Root_Stream_Type'Class;
        Item   : out  T) is Separate;

> (We used to use them extensively, but only because Janus/Ada on 16-bit MS-DOS 
> limited a single unit to 64K of generated code -- and our editors couldn't 
> handle more than 256K of source code at a time. None of that makes sense 
> today.)

This is true; but it does make sense for organizing and isolating portions of the codebase even further w/o having to muck up the library-hierarchy... and might be required at a certain level (eg primitive ops).

Re: body stub not allowed in inner scope

[Jacob Sparre Andersen]

Simon Wright <simon@pushface.org> writes:
> Randy Brukardt <randy@rrsoftware.com> writes:

> My use case for stubs is that I have a code generator that transforms
> a UML model into the framework of an Ada solution; subprograms, task
> and protected type bodies are generated as separates, so that there's
> no hassle with having the tool work out how not to overwrite the real
> bodies. This was triggered by bad experiences with Rational Rose back
> in 2000.

This sounds rather similar to some work I've done for Consafe Logistics
last year.  I wrote a code generator, which compiles Swagger/OAS
specifications of REST interfaces into packages declaring the services
and the types used.  The actual service implementations are made
separate, to have the optimal separation of developer-written and
tool-written Ada code.

Greetings,

Jacob
-- 
recursive, adj.; see recursive

Re: body stub not allowed in inner scope

[Randy Brukardt]

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

"J-P. Rosen" <rosen@adalog.fr> wrote in message 
news:p7898p$1arv$1@gioia.aioe.org...
> Le 01/03/2018 à 00:23, Randy Brukardt a écrit :
>> "Mehdi Saada" <00120260a@gmail.com> wrote in message
>> news:15c49c4e-726a-4fd7-bf35-c7d27ff9a491@googlegroups.com...
>>> Thanks.
>>> But that's ugly... How about fixing this for the next norm ?
>>
>> Does anyone other than ACATS tests actually use stubs these days? Why? 
>> (We
>> used to use them extensively, but only because Janus/Ada on 16-bit MS-DOS
>> limited a single unit to 64K of generated code -- and our editors 
>> couldn't
>> handle more than 256K of source code at a time. None of that makes sense
>> today.)
> At least for task and protected bodies, which can't be child units.
>
> Also, stubs have visibility to elements in the parent's body, although I
> agree that direct visibility of global elements should be limited.

Yes, but why put them in a separate file in the first place? The only reason 
I know not to do that is that editors (and compilers) used to have size 
limits. It's usually easier to have one big file because it makes fewer 
places to look for things. (The subunits in Janus/Ada are annoying because 
one opens the body to find something only to find it isn't there and a 
different file has to be opened. Often, I don't know exactly what I'm 
looking for and have to bounce back and forth several times.)

                                              Randy.

Re: body stub not allowed in inner scope

[Randy Brukardt]

"Jacob Sparre Andersen" <jacob@jacob-sparre.dk> wrote in message 
news:87tvtzv7rg.fsf@jacob-sparre.dk...
> Simon Wright <simon@pushface.org> writes:
>> Randy Brukardt <randy@rrsoftware.com> writes:
>
>> My use case for stubs is that I have a code generator that transforms
>> a UML model into the framework of an Ada solution; subprograms, task
>> and protected type bodies are generated as separates, so that there's
>> no hassle with having the tool work out how not to overwrite the real
>> bodies. This was triggered by bad experiences with Rational Rose back
>> in 2000.
>
> This sounds rather similar to some work I've done for Consafe Logistics
> last year.  I wrote a code generator, which compiles Swagger/OAS
> specifications of REST interfaces into packages declaring the services
> and the types used.  The actual service implementations are made
> separate, to have the optimal separation of developer-written and
> tool-written Ada code.

The CLAW Builder generated code does this, but used user-generated packages 
for this purpose (rather than separates). The user provides the name of the 
package, and the generated code makes the needed calls. We were about to 
allow the user to choose to generate the package specifications for such 
packages (that never got implemented) so that the bodies would be easier to 
write (that would make the profiles of the needed routines obvious, rather 
than just being in the popup help for the builder). We never even considered 
subunits for this purpose (maybe should have? Dunno.) One never wants to mix 
machine-generated code (which the user should look at only in cases where 
there is a bug in the tools) with user-generated code (which the user 
obviously has to manage, and would prefer to use their normal IDE for 
development).

                                            Randy.

Re: body stub not allowed in inner scope

[J-P. Rosen]

Le 01/03/2018 à 23:38, Randy Brukardt a écrit :
> Yes, but why put them in a separate file in the first place? The only reason 
> I know not to do that is that editors (and compilers) used to have size 
> limits. It's usually easier to have one big file because it makes fewer 
> places to look for things. (The subunits in Janus/Ada are annoying because 
> one opens the body to find something only to find it isn't there and a 
> different file has to be opened. Often, I don't know exactly what I'm 
> looking for and have to bounce back and forth several times.)
> 
I think your opinion is closely linked to the fact that you don't use
(AFAIK) modern editors. With GPS or Emacs, you click on an entity and
"goto declaration" to retrieve it. OTOH, long scrolls are annoying, so
there is a clear benefit in having your stuff split on several, not too
big files.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: body stub not allowed in inner scope

[Dmitry A. Kazakov]

On 02/03/2018 08:14, J-P. Rosen wrote:
> Le 01/03/2018 à 23:38, Randy Brukardt a écrit :
>> Yes, but why put them in a separate file in the first place? The only reason
>> I know not to do that is that editors (and compilers) used to have size
>> limits. It's usually easier to have one big file because it makes fewer
>> places to look for things. (The subunits in Janus/Ada are annoying because
>> one opens the body to find something only to find it isn't there and a
>> different file has to be opened. Often, I don't know exactly what I'm
>> looking for and have to bounce back and forth several times.)
>>
> I think your opinion is closely linked to the fact that you don't use
> (AFAIK) modern editors. With GPS or Emacs, you click on an entity and
> "goto declaration" to retrieve it. OTOH, long scrolls are annoying, so
> there is a clear benefit in having your stuff split on several, not too
> big files.

+ modern wide-screen displays capable to show 2-3 tabs/windows with code 
side-by-side. Being able to see both maim body and the separate one is a 
big advantage.

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

Re: body stub not allowed in inner scope

[G. B.]

Randy Brukardt <randy@rrsoftware.com> wrote:
> why put them in a separate file in the first place? 

Yes, separate units can be placed after the bodies,
yet in the same file! Not always my choice but that, too
moves dependences out of the superunit.
Irrespective of what a compiler can make of this.

Re: body stub not allowed in inner scope

[Simon Wright]

G. B. <nonlegitur@nmhp.invalid> writes:

> Randy Brukardt <randy@rrsoftware.com> wrote:
>> why put them in a separate file in the first place? 
>
> Yes, separate units can be placed after the bodies,
> yet in the same file! Not always my choice but that, too
> moves dependences out of the superunit.
> Irrespective of what a compiler can make of this.

This seems a really crazy approach.

Given that Emacs, for example, is quite capable of displaying two
view of different parts of the same buffer.

Re: body stub not allowed in inner scope

[Randy Brukardt]

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:p7b8c6$dq2$1@gioia.aioe.org...
> On 02/03/2018 08:14, J-P. Rosen wrote:
>> Le 01/03/2018 à 23:38, Randy Brukardt a écrit :
>>> Yes, but why put them in a separate file in the first place? The only 
>>> reason
>>> I know not to do that is that editors (and compilers) used to have size
>>> limits. It's usually easier to have one big file because it makes fewer
>>> places to look for things. (The subunits in Janus/Ada are annoying 
>>> because
>>> one opens the body to find something only to find it isn't there and a
>>> different file has to be opened. Often, I don't know exactly what I'm
>>> looking for and have to bounce back and forth several times.)
>>>
>> I think your opinion is closely linked to the fact that you don't use
>> (AFAIK) modern editors. With GPS or Emacs, you click on an entity and
>> "goto declaration" to retrieve it. OTOH, long scrolls are annoying, so
>> there is a clear benefit in having your stuff split on several, not too
>> big files.
>
> + modern wide-screen displays capable to show 2-3 tabs/windows with code 
> side-by-side. Being able to see both maim body and the separate one is a 
> big advantage.

That works with any editor (nothing prevents opening multiple MS-DOS 
windows - I usually have about 20 of those open). The real problem is that 
one needs a massive screen to really have enough room - I once calculated 
that I'd need a 52" screen to show all of the source code that I need to see 
to work on the compiler side-by-side. And I had better vision then; I 
probably couldn't even see the edges of such a screen today (it would have 
to wrap around my head at an even 18-24" distance!!)

One of the reasons I never use GPS is because it comes up in a font that is 
rugged and too hard to read on my computer. Making it bigger fixes that, but 
then I'd need a lot larger screen than the 24" one I have today.

Moral: these things help, but not that significantly.

                               Randy.

Re: body stub not allowed in inner scope

[Randy Brukardt]

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

"J-P. Rosen" <rosen@adalog.fr> wrote in message 
news:p7atjs$1qme$1@gioia.aioe.org...
> Le 01/03/2018 à 23:38, Randy Brukardt a écrit :
>> Yes, but why put them in a separate file in the first place? The only 
>> reason
>> I know not to do that is that editors (and compilers) used to have size
>> limits. It's usually easier to have one big file because it makes fewer
>> places to look for things. (The subunits in Janus/Ada are annoying 
>> because
>> one opens the body to find something only to find it isn't there and a
>> different file has to be opened. Often, I don't know exactly what I'm
>> looking for and have to bounce back and forth several times.)
>>
> I think your opinion is closely linked to the fact that you don't use
> (AFAIK) modern editors. With GPS or Emacs, you click on an entity and
> "goto declaration" to retrieve it. OTOH, long scrolls are annoying, so
> there is a clear benefit in having your stuff split on several, not too
> big files.

Lots of windows are annoying, too; it is hard to get the right one on top. 
Even if you use a "goto declaration", now you have the wrong window on top 
and getting back is a pain. (My old editor tiles windows and thus avoids 
this problem.)

I'm generally not looking for "a declaration", I'm looking for code that 
implements something, typically written 30 years ago, sometimes by someone 
else, whose name I don't know (perhaps I have an idea, but it's often 
wrong), and I don't know how it works. No editor is going to help 
significantly with that.

I don't use "modern editors" not because I'm some sort of Luddite, but 
rather because I want to "eat my own dog food" and thus not depend on 
something that we don't have for them.

Regardless, the majority of "goto declaration" commands are intensely 
frustating, because they don't handle most of the subtle visibility issues 
of Ada (or they require correct compilable code to do so), they don't have a 
sane way to deal with inheritance and instances (where you need to see both 
the original routine and the actuals/type declaration in order to know 
what's going on), and just don't match what the compiler sees. To do this 
right, you need a special Ada compiler that can deal with partial sources 
and the like - which would cost as much to develop as an actual Ada 
compiler. (Indeed, Ada is spending many man-years on exactly such a 
project.) We couldn't afford it, so that's a feature you most likely will 
never see in a Janus/Ada IDE.

Scrolling is annoying, yes, but that's easy to mitigate by not doing it. :-) 
Search for something (I usually use "procedure") in long files. Once you get 
the to right place, you're going to have to scroll in any case (most of the 
subprograms in Janus/Ada are quite long because of all of the different 
cases that have to be dealt with, >500 lines is not uncommon).

                                  Randy.

Re: body stub not allowed in inner scope

[Dennis Lee Bieber]

On Fri, 2 Mar 2018 16:10:24 -0600, "Randy Brukardt" <randy@rrsoftware.com>
declaimed the following:


>one needs a massive screen to really have enough room - I once calculated 
>that I'd need a 52" screen to show all of the source code that I need to see 

	Massive screen won't help unless the resolution remains at, say 96DPI.

	The LCDs made for large TVs tend to scale the resolution... The 24"
monitor is 1920x1200 (16x10 aspect)... My 46" HDTV is... 1920x1080 (16x9
aspect).

	You'd have to go to something like "8K Ultra HD" to really get more
working space (16 times the HD pixels).
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: body stub not allowed in inner scope

[G.B.]

On 02.03.18 20:47, Simon Wright wrote:
> G. B. <nonlegitur@nmhp.invalid> writes:
> 
>> Randy Brukardt <randy@rrsoftware.com> wrote:
>>> why put them in a separate file in the first place?
>>
>> Yes, separate units can be placed after the bodies,
>> yet in the same file! Not always my choice but that, too
>> moves dependences out of the superunit.
>> Irrespective of what a compiler can make of this.
> 
> This seems a really crazy approach.
> 
> Given that Emacs, for example, is quite capable of displaying two
> view of different parts of the same buffer.

Emacs, or any other plain text editor, has no influence
on the semantics of Ada unit dependencies, as that's a matter
of structuring source text. I'd like an Ada compiler to
diagnose that a dependency can be moved to a subunit refactored
from some coherent part of a body, say. GNAT does this for
with-clauses that can be moved to the body.

-- -*- page-delimiter: "^\\(package\\|separate\\)" -*-

package body P is

     procedure P1;
     procedure P2;
     procedure P3;
     procedure P4;

     X : T;

     procedure P1 is null;
     procedure P2 is null;
     procedure P3 is null;
     procedure P4 is separate;

end P;


with Subsystem.Load;
separate (P)
procedure P4 is
     use Subsystem;
begin
     if Whatever (X) then
         X.Op_15;
         Load.Get_Going (X);
     end if;
end P4;