Direct Quote from the RM

Direct Quote from the RM

[anon]

Intro or section 0 between 150 .. 200 lines in the RM for Ada 95! 

Quote

    Design Goals

    6   Ada was originally designed with three overriding concerns:  
        program reliability and maintenance, programming as a human 
        activity, and efficiency. This revision to the language was 
        designed to provide greater flexibility and extensibility, 
        additional control over storage management and synchronization, 
        and standardized packages oriented toward supporting important
        application areas, while at the same time retaining the original 
        emphasis on reliability, maintainability, and efficiency.

    7   The need for languages that promote reliability and simplify 
        maintenance is well established.  Hence emphasis was placed 
        on program readability over ease of writing.  For example, the 
        rules of the language require that program variables be explicitly 
        declared and that their type be specified.  Since the type of a 
        variable is invariant, compilers can ensure that operations on
        variables are compatible with the properties intended for objects 
        of the type.  Furthermore, error-prone notations have been avoided, 
        and the syntax of the language avoids the use of encoded forms in 
        favor of more English-like constructs.  Finally, the language offers 
        support for separate compilation of program units in a way that 
        facilitates program development and maintenance, and which 
        provides the same degree of checking between units as within a
        unit.

    8   Concern for the human programmer was also stressed during the 
        design. Above all, an attempt was made to keep to a relatively 
        small number of underlying concepts integrated in a consistent 
        and systematic way while continuing to avoid the pitfalls of 
        excessive involution.  The design especially aims to provide 
        language constructs that correspond intuitively to the normal 
        expectations of users.

    9   Like many other human activities, the development of programs 
        is becoming ever more decentralized and distributed.  Consequently, 
        the ability to assemble a program from independently produced 
        software components continues to be a central idea in the design.  
        The concepts of packages, of private types, and of generic units 
        are directly related to this idea, which has ramifications in many 
        other aspects of the language.  An allied concern is the maintenance 
        of programs to match changing requirements; type extension and the 
        hierarchical library enable a program to be modified while minimizing
        disturbance to existing tested and trusted components.

  10   No language can avoid the problem of efficiency.  Languages that 
        require over-elaborate compilers, or that lead to the inefficient use 
        of storage or execution time, force these inefficiencies on all 
        machines and on all programs.  Every construct of the language was 
        examined in the light of present implementation techniques.  Any 
        proposed construct whose implementation was unclear or that 
        required excessive machine resources was rejected.

Unquote!

Which any programmer should take to mean that they should write High 
Integrity and Efficient code to maintain the Ada Design Goals. And that 
just one of many parts of the manual that address these type of concerns.

Randy Brukardt may have writing one or more sections but as the list 
of authors states he was not alone. So, unless he wrote the intro he 
could of skipped that section. Just like most people who read the RM,
they skip parts that does not deal with writing code. I personally have 
no problems that Randy Brukardt writing part(s) of the RM unless he 
wrote that intro. In that case, telling me to re-read it is just wrong.

Re: Direct Quote from the RM

[Simon Wright]

anon@anon.org (anon) writes:

>   10   No language can avoid the problem of efficiency.  Languages
>         that require over-elaborate compilers, or that lead to the
>         inefficient use of storage or execution time, force these
>         inefficiencies on all machines and on all programs.

This is the only part of the text you quote that addresses the
compilation environment. And what it says is, the design of the Ada
language is such that it does not require over-elaborate compilers,
and that (once compiled) a program doesn't have to be inefficient.

But there's nothing there that says the compiler itself has to be
efficient! of course inefficient compilers will be unpopular, but
that's quite a different matter.

Re: Direct Quote from the RM

[anon]

Paragraph of 10 from Design Goal.

  10   No language can avoid the problem of efficiency.  Languages that 
        require over-elaborate compilers, or that lead to the inefficient use 
        of storage or execution time, force these inefficiencies on all 
        machines and on all programs.  Every construct of the language was 
        examined in the light of present implementation techniques.  Any 
        proposed construct whose implementation was unclear or that 
        required excessive machine resources was rejected.

"Any proposed construct whose implementation was unclear or that required 
excessive machine resources was rejected." That statement suggest that 
"gnatmake" in using requires 5 complete programs to be loaded at one time 
just to compile a single routine or package when 3 to 3 will do should be 
rejected!

gnatmake => use in core 5 program.
gnat compile => uses 4 program 3 in core.
gcc -c => uses 3 in core program (gcc which calls gnat1 then calls as).

So using "gcc -c" is the best and is worst "gnatmake".  Of course, this 
can become excessive in execution time if the GNAT system is compiled 
with "-fstack-check".

Defaulting the "-fstack-check" which can not at the movement be remove 
by the "pragma Suppress (Storage_Check);". Leads "to the inefficient use 
of storage or execution time, force these inefficiencies on all machines 
and on all programs." So it too must be rejected!

And there are more places in the RM then just this part. But most people 
I think had skip reading the Intro section.

And as for parallel. The way I write code allows me to compile in parallel 
even though that development design is not support in the RM. But I have 
learned a few trick alone the way that allows this. 

Note: Parallel => I mean the number of complete compilers loaded and 
running in core (no swapper file usage) at the same time. That is on the 
old single-cpu system it was called Concurrency, but with two/four/+ 
cpus that is called Parallel. For example on a system with 4G with 1G 
given to the OS/(user interface), that leave 3G or about 3_000 in core 
compilers if the gcc, gnat1, as, and file/package take less than 1MB in 
size or 1_500 in core compilers if they require 2MB.

And "gnatmake" does not use the Ada Task and to insure "Safety and 
Security" of the code will only allow the compiling of one package at a 
time because of the design of Ada structure. (As someone pointed out).
This is defined also in the RM if you look. 

Note: The "make -jN" or "gnatmake -jN" does not allow multiple 
compilers to be loaded in core at the same time.



In <m2k5ogvxo4.fsf@mac.com>, Simon Wright <simon.j.wright@mac.com> writes:
>anon@anon.org (anon) writes:
>
>>   10   No language can avoid the problem of efficiency.  Languages
>>         that require over-elaborate compilers, or that lead to the
>>         inefficient use of storage or execution time, force these
>>         inefficiencies on all machines and on all programs.
>
>This is the only part of the text you quote that addresses the
>compilation environment. And what it says is, the design of the Ada
>language is such that it does not require over-elaborate compilers,
>and that (once compiled) a program doesn't have to be inefficient.
>
>But there's nothing there that says the compiler itself has to be
>efficient! of course inefficient compilers will be unpopular, but
>that's quite a different matter.

Re: Direct Quote from the RM

[Markus E L]

'anon AT anon DOT org (anon)' wrote:

> Paragraph of 10 from Design Goal.
>
>   10   No language can avoid the problem of efficiency.  Languages that 
>         require over-elaborate compilers, or that lead to the inefficient use 
>         of storage or execution time, force these inefficiencies on all 
>         machines and on all programs.  Every construct of the language was 
>         examined in the light of present implementation techniques.  Any 
>         proposed construct whose implementation was unclear or that 
>         required excessive machine resources was rejected.
>
> "Any proposed construct whose implementation was unclear or that required 
> excessive machine resources was rejected." That statement suggest that 
> "gnatmake" in using requires 5 complete programs to be loaded at one time 
> just to compile a single routine or package when 3 to 3 will do should be 
> rejected!

Since when is gnatmake a "construct of the language"? Furthermore the
text describes the (past) design process of Ada language and does (as
I understand it) not impose requirements on the compiler/tool
implementation. That would be the difference between "was rejected"
and "shall rejected" AFAI understand.

- M

Re: Direct Quote from the RM

[Georg Bauhaus]

anon wrote:

> "Any proposed construct whose implementation was unclear or that required 
> excessive machine resources was rejected." That statement suggest that 
> "gnatmake" in using requires 5 complete programs to be loaded at one time 
> just to compile a single routine or package when 3 to 3 will do should be 
> rejected!

I had been under the impression that Ada was designed for software
systems of more than one compilation unit...


> Note: Parallel => I mean the number of complete compilers loaded and 
> running in core (no swapper file usage) at the same time.

I'm curious about the elaboration rules when a compilation system
of 3_000 complete compilers is working on the same source at the
same time (not using gnatmake).
How many compilation units would be under the control of the
3_000 compilers in this example? How do they get organized?

 > Note: The "make -jN" or "gnatmake -jN" does not allow multiple
 > compilers to be loaded in core at the same time.

Ehr, why is that?
"`-jn'
   Use n processes to carry out the (re)compilations. On a
   multiprocessor machine compilations will occur in parallel."

Re: Direct Quote from the RM

[anon]

For Georg Bauhaus

As for parallel, I was talking about compiling up to 3_000 packages or 
files used in a partition for a computer system with 4GB. Not all parallel 
operations are about threads or a thread hopping onto different 
processor's job schedulers. In this parallel design the system can contain 
up to 3_000 copies of "gcc", "gnat1" and "as" in memory and excuting 
in parallel design with each other to utilize the cpu and memory to the 
fullest! In other words,

Task 1 in memmory -> (copy #1 of gnat compiler system) + (package 1) 
Task 2 in memmory -> (copy #2 of gnat compiler system) + (package 2) 
Task 3 in memmory -> (copy #3 of gnat compiler system) + (package 3) 
  ...
Task N in memmory -> (copy #4 of gnat compiler system) + (package N) 

Note: "gnat compiler system" is "gcc" and "gnat1" and as", which is 
done by the "gnat compile" command or "gcc -c".  

In this design it does not matter the number of processors or the number 
of threads. This can be done by creating a script file like (linux version):

#script
#
gnat compile <name1>.adb &
gnat compile <name2>.adb &
gnat compile <name3>.adb &
..
gnat compile <nameN>.adb &
#
#end script


Usage of the Swapper file must be turn off. Swapping defeat the purpose. 
And you may have to up the priority of the background tasks but that not 
a problem either. Also I could of used "gcc -c" but that too much like C 
programming. so I choose not too use it. 

Note: "gnatmake" or "make" can not be setup in this way to preform is 
type of parallel processing. 


Now as for "gnatmake" try this "gnatmake *".  It does not work in 
Linux/FreeBSD.  So, to compile packages before you create the main 
program you must use "gnat compile" or better yet "gcc -c". Also, If you 
have more than a couple of packages you normally build a script file to 
compile the code, which can easily be turn into loading multiple copies of 
the compiler and fully use the system resources aka parallel compiling. 
Then when you build the main procedure out of habit you will again use 
the "gcc -c" or "gnat compile" instead of "gnatmake" and then 
"gnatbind" and then "gnatlink".

So, teaching or using "gnatmake" is a waste of the newbee time! 
Because most project require more than one or two extra packages!


For "Elaboration rule"! Well try this:

1. create a temporary dir
2. cd to that temporary dir
3. copy system.ads to this temporary dir.
4. copy s-stoele.ad* to this temporary dir    
   -- System.Storage_Elements package for example.
5. edit system.ads and remove the comment at the top of the file.
 Note: Any child package should, by the "Elaboration rules" force the 
       operator to recompile system.ads first.

6. gnat compile s-stoele.adb -gnatpg -nostdinc
   This file is a child of system.  But where is the error?
7. gnat compile system.ads -gnatpg -nostdinc

Note: Only if you "bind" a program that uses the 
      System.Storage_Elements will you see the Error based 
      on the "Elaboration rule" in this example.

Plus, not all project require Elaboration to be used.


In <4740d5f0$0$27131$9b4e6d93@newsspool1.arcor-online.net>, Georg Bauhaus <rm.tsoh+bauhaus@maps.futureapps.de> writes:
>anon wrote:
>
>> "Any proposed construct whose implementation was unclear or that required 
>> excessive machine resources was rejected." That statement suggest that 
>> "gnatmake" in using requires 5 complete programs to be loaded at one time 
>> just to compile a single routine or package when 3 to 3 will do should be 
>> rejected!
>
>I had been under the impression that Ada was designed for software
>systems of more than one compilation unit...
>
>
>> Note: Parallel => I mean the number of complete compilers loaded and 
>> running in core (no swapper file usage) at the same time.
>
>I'm curious about the elaboration rules when a compilation system
>of 3_000 complete compilers is working on the same source at the
>same time (not using gnatmake).
>How many compilation units would be under the control of the
>3_000 compilers in this example? How do they get organized?
>
> > Note: The "make -jN" or "gnatmake -jN" does not allow multiple
> > compilers to be loaded in core at the same time.
>
>Ehr, why is that?
>"`-jn'
>   Use n processes to carry out the (re)compilations. On a
>   multiprocessor machine compilations will occur in parallel."

Re: parallel translation (was: Direct Quote from the RM)

[Georg Bauhaus]

On Tue, 2007-11-20 at 13:43 +0000, anon wrote:
> For Georg Bauhaus
> 
> As for parallel, I was talking about compiling up to 3_000 packages or 
> files used in a partition for a computer system with 4GB.

OK. This was my understanding, too.

> Task 1 in memmory -> (copy #1 of gnat compiler system) + (package 1) 
> Task 2 in memmory -> (copy #2 of gnat compiler system) + (package 2) 
> Task 3 in memmory -> (copy #3 of gnat compiler system) + (package 3) 
>   ...
> Task N in memmory -> (copy #4 of gnat compiler system) + (package N) 

Right. Now,

with P2;
package P1 is
   ...
end P1;

P1 (in file "p1.ads", say) depends on P2 (in file "p2.ads", say).
I am assuming that Task 1 is supposed to compile P1, and task 2
is supposed to compile P2. An elaboration order will have to be
established in order to translate almost anything. Here, for
example, task 1 (compiling P1) must know what is in P2 (compiled
in task 2) because P1 depends on P2. How do the compilers etc.
communicate?

> For "Elaboration rule"! Well try this:

Why should a programmer new to Ada mess with compiler files?
And how will the GNAT specifics of System.Storage_Elements and
special processing of System affect the package dependences in an
Ada project?

Re: parallel translation

[Jeffrey R. Carter]

Georg Bauhaus wrote:
> 
> P1 (in file "p1.ads", say) depends on P2 (in file "p2.ads", say).
> I am assuming that Task 1 is supposed to compile P1, and task 2
> is supposed to compile P2. An elaboration order will have to be
> established in order to translate almost anything. Here, for
> example, task 1 (compiling P1) must know what is in P2 (compiled
> in task 2) because P1 depends on P2. How do the compilers etc.
> communicate?

No, GNAT is source based. The compilation of P1 will read p2.ads; the 
compilation of P2 will read p2.ads and p2.adb (if needed). The compilation of P1 
need not wait for P2 to be compiled.

If P1 depends on the body of P2 (perhaps by calling an inlined subprogram with 
-gnatn), then you have a problem similar to what you described. I'm not sure how 
GNAT handles this, but perhaps the task compiling P1 can wait until appropriate 
versions of p2.ali and p2.o are created.

-- 
Jeff Carter
"Go and boil your bottoms."
Monty Python & the Holy Grail
01

Re: parallel translation

[Samuel Tardieu]

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

Jeffrey> If P1 depends on the body of P2 (perhaps by calling an
Jeffrey> inlined subprogram with -gnatn), then you have a problem
Jeffrey> similar to what you described. I'm not sure how GNAT handles
Jeffrey> this, but perhaps the task compiling P1 can wait until
Jeffrey> appropriate versions of p2.ali and p2.o are created.

As you wrote, GNAT is source based. If P1 depends on the body of P2,
it will use its source file (p2.adb in this case), and this is totally
independant of the compilation of P2 which may well happen in
parallel or after the compilation of P1.

Any unit can be compiled without depending on any other unit
compilation. Moreover, the compiler never reads any ali file. gnatmake
does (to determine what needs to be compiled), and gnatbind does as
well (to determine the elaboration order).

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/

Re: parallel translation

[Jeffrey R. Carter]

Samuel Tardieu wrote:
>>>>>> "Jeffrey" == Jeffrey R Carter <spam.jrcarter.not@acm.nospam.org> writes:
> 
> Jeffrey> If P1 depends on the body of P2 (perhaps by calling an
> Jeffrey> inlined subprogram with -gnatn), then you have a problem
> Jeffrey> similar to what you described. I'm not sure how GNAT handles
> Jeffrey> this, but perhaps the task compiling P1 can wait until
> Jeffrey> appropriate versions of p2.ali and p2.o are created.
> 
> As you wrote, GNAT is source based. If P1 depends on the body of P2,
> it will use its source file (p2.adb in this case), and this is totally
> independant of the compilation of P2 which may well happen in
> parallel or after the compilation of P1.
> 
> Any unit can be compiled without depending on any other unit
> compilation. Moreover, the compiler never reads any ali file. gnatmake
> does (to determine what needs to be compiled), and gnatbind does as
> well (to determine the elaboration order).

Thanks for the clarification.

-- 
Jeff Carter
"Go and boil your bottoms."
Monty Python & the Holy Grail
01

Re: parallel translation

[Georg Bauhaus]

On Tue, 2007-11-20 at 18:47 +0000, Jeffrey R. Carter wrote:
> Georg Bauhaus wrote:
> > 
> > P1 (in file "p1.ads", say) depends on P2 (in file "p2.ads", say).
> > I am assuming that Task 1 is supposed to compile P1, and task 2
> > is supposed to compile P2. An elaboration order will have to be
> > established in order to translate almost anything. Here, for
> > example, task 1 (compiling P1) must know what is in P2 (compiled
> > in task 2) because P1 depends on P2. How do the compilers etc.
> > communicate?
> 
> No, GNAT is source based. The compilation of P1 will read p2.ads; the 
> compilation of P2 will read p2.ads and p2.adb (if needed). The compilation of P1 
> need not wait for P2 to be compiled.

Yes, I had felt uneasy after posting as the comment confused translation
and elaboration. Yet, I had understood that something like a shell
script was to control starts of gccs for each file, basically. What is
the win over "gnatmake -jnnn" when none of the independent compilers
knows which file has already been processed? There will not normally
be a "p2.ali" after "gcc -c" has read and analyzed "p2.ads" (with'ed
by P1).

Time to look at the sources of gnatmake.

Re: Direct Quote from the RM

[Vadim Godunko]

On Nov 20, 4:43 pm, a...@anon.org (anon) wrote:
>
> So, teaching or using "gnatmake" is a waste of the newbee time!
> Because most project require more than one or two extra packages!
>
1) gnatmake has special -jX command line switch, where X is a number
of parallel gcc commands.

1a) you may use classic make program and its parallel modifications.

2) two dual core processors and 4Gb of RAM doesn't really many
resources even for medium size projects. Real projects may utilize up
to 3Gb of RAM per one compiler process.

> 6. gnat compile s-stoele.adb -gnatpg -nostdinc
>    This file is a child of system.  But where is the error?
What are you expecting? You are _exactly_ ask _compiler_ rebuild
specific file. Note, _compiler_! Compiler must prepare relevant
elaboration code, but it doesn't responsible for partition elaboration
at hole, ...

> Note: Only if you "bind" a program that uses the
>       System.Storage_Elements will you see the Error based
>       on the "Elaboration rule" in this example.
>
... bind program is responsible for generation of partition
elaboration code.

> Plus, not all project require Elaboration to be used.
>
Can you please provide an real example?

Re: Direct Quote from the RM

[anon]

>> Plus, not all project require Elaboration to be used.
>>
>Can you please provide an real example?

1. Since a persion was asking about "Ada OS" the other day!
   An Ada version of a Multi-Boot program simular to XP or LILO.

2. Another type can be partitions that use other language I/O and library 
   functions with or without the "pragma No_Run_Time;" statement. In 
   the GNAT examples there is a program called "use_of_import.adb" 
   which requires "impoerted_function.c".


In <a954e769-3822-4079-a77d-957d56be4a9e@d61g2000hsa.googlegroups.com>, Vadim Godunko <vgodunko@gmail.com> writes:
>On Nov 20, 4:43 pm, a...@anon.org (anon) wrote:
>>
>> So, teaching or using "gnatmake" is a waste of the newbee time!
>> Because most project require more than one or two extra packages!
>>
>1) gnatmake has special -jX command line switch, where X is a number
>of parallel gcc commands.
>
>1a) you may use classic make program and its parallel modifications.
>
>2) two dual core processors and 4Gb of RAM doesn't really many
>resources even for medium size projects. Real projects may utilize up
>to 3Gb of RAM per one compiler process.
>
>> 6. gnat compile s-stoele.adb -gnatpg -nostdinc
>>    This file is a child of system.  But where is the error?
>What are you expecting? You are _exactly_ ask _compiler_ rebuild
>specific file. Note, _compiler_! Compiler must prepare relevant
>elaboration code, but it doesn't responsible for partition elaboration
>at hole, ...
>
>> Note: Only if you "bind" a program that uses the
>>       System.Storage_Elements will you see the Error based
>>       on the "Elaboration rule" in this example.
>>
>.... bind program is responsible for generation of partition
>elaboration code.
>
>> Plus, not all project require Elaboration to be used.
>>
>Can you please provide an real example?

Re: Direct Quote from the RM

[Randy Brukardt]

"anon" <anon@anon.org> wrote in message
news:mYI%i.27882$if6.6495@bgtnsc05-news.ops.worldnet.att.net...
> Intro or section 0 between 150 .. 200 lines in the RM for Ada 95!
>
> (long quote omitted).

Ah, yes, the motherhood section. I was asking you to provide a *normative*
reference (one that is actually binding on users/implementers), which the
introduction is surely not such a section. (See the definition of
"normative" in 1.1.2.)

The introduction is just a list of "good" properties which really doesn't
mean that much and has no bearing on the requirements for implementations
and users. Pretty much every programming language has a version of these
same goals. After all, can you imagine a programming language saying that it
was designed to make unreliable programs with no regard to efficiency? Who'd
use that?

Others have explained the difference between properties of the language and
properties of the toolset, so I won't spend more time on that.

                                  Randy.






> Quote
>
>     Design Goals
>
>     6   Ada was originally designed with three overriding concerns:
>         program reliability and maintenance, programming as a human
>         activity, and efficiency. This revision to the language was
>         designed to provide greater flexibility and extensibility,
>         additional control over storage management and synchronization,
>         and standardized packages oriented toward supporting important
>         application areas, while at the same time retaining the original
>         emphasis on reliability, maintainability, and efficiency.
>
>     7   The need for languages that promote reliability and simplify
>         maintenance is well established.  Hence emphasis was placed
>         on program readability over ease of writing.  For example, the
>         rules of the language require that program variables be explicitly
>         declared and that their type be specified.  Since the type of a
>         variable is invariant, compilers can ensure that operations on
>         variables are compatible with the properties intended for objects
>         of the type.  Furthermore, error-prone notations have been
avoided,
>         and the syntax of the language avoids the use of encoded forms in
>         favor of more English-like constructs.  Finally, the language
offers
>         support for separate compilation of program units in a way that
>         facilitates program development and maintenance, and which
>         provides the same degree of checking between units as within a
>         unit.
>
>     8   Concern for the human programmer was also stressed during the
>         design. Above all, an attempt was made to keep to a relatively
>         small number of underlying concepts integrated in a consistent
>         and systematic way while continuing to avoid the pitfalls of
>         excessive involution.  The design especially aims to provide
>         language constructs that correspond intuitively to the normal
>         expectations of users.
>
>     9   Like many other human activities, the development of programs
>         is becoming ever more decentralized and distributed.
Consequently,
>         the ability to assemble a program from independently produced
>         software components continues to be a central idea in the design.
>         The concepts of packages, of private types, and of generic units
>         are directly related to this idea, which has ramifications in many
>         other aspects of the language.  An allied concern is the
maintenance
>         of programs to match changing requirements; type extension and the
>         hierarchical library enable a program to be modified while
minimizing
>         disturbance to existing tested and trusted components.
>
>   10   No language can avoid the problem of efficiency.  Languages that
>         require over-elaborate compilers, or that lead to the inefficient
use
>         of storage or execution time, force these inefficiencies on all
>         machines and on all programs.  Every construct of the language was
>         examined in the light of present implementation techniques.  Any
>         proposed construct whose implementation was unclear or that
>         required excessive machine resources was rejected.
>
> Unquote!
>
> Which any programmer should take to mean that they should write High
> Integrity and Efficient code to maintain the Ada Design Goals. And that
> just one of many parts of the manual that address these type of concerns.
>
> Randy Brukardt may have writing one or more sections but as the list
> of authors states he was not alone. So, unless he wrote the intro he
> could of skipped that section. Just like most people who read the RM,
> they skip parts that does not deal with writing code. I personally have
> no problems that Randy Brukardt writing part(s) of the RM unless he
> wrote that intro. In that case, telling me to re-read it is just wrong.
>

Re: Direct Quote from the RM

[Randy Brukardt]

"anon" <anon@anon.org> wrote in message
news:mYI%i.27882$if6.6495@bgtnsc05-news.ops.worldnet.att.net...
> Intro or section 0 between 150 .. 200 lines in the RM for Ada 95!
>
> (long quote omitted).

Ah, yes, the motherhood section. I was asking you to provide a *normative*
reference (one that is actually binding on users/implementers), which the
introduction is surely not such a section. (See the definition of
"normative" in 1.1.2.)

The introduction is just a list of "good" properties which really doesn't
mean that much and has no bearing on the requirements for implementations
and users. Pretty much every programming language has a version of these
same goals. After all, can you imagine a programming language saying that it
was designed to make unreliable programs with no regard to efficiency? Who'd
use that?

Others have explained the difference between properties of the language and
properties of the toolset, so I won't spend more time on that.

                                  Randy.






> Quote
>
>     Design Goals
>
>     6   Ada was originally designed with three overriding concerns:
>         program reliability and maintenance, programming as a human
>         activity, and efficiency. This revision to the language was
>         designed to provide greater flexibility and extensibility,
>         additional control over storage management and synchronization,
>         and standardized packages oriented toward supporting important
>         application areas, while at the same time retaining the original
>         emphasis on reliability, maintainability, and efficiency.
>
>     7   The need for languages that promote reliability and simplify
>         maintenance is well established.  Hence emphasis was placed
>         on program readability over ease of writing.  For example, the
>         rules of the language require that program variables be explicitly
>         declared and that their type be specified.  Since the type of a
>         variable is invariant, compilers can ensure that operations on
>         variables are compatible with the properties intended for objects
>         of the type.  Furthermore, error-prone notations have been
avoided,
>         and the syntax of the language avoids the use of encoded forms in
>         favor of more English-like constructs.  Finally, the language
offers
>         support for separate compilation of program units in a way that
>         facilitates program development and maintenance, and which
>         provides the same degree of checking between units as within a
>         unit.
>
>     8   Concern for the human programmer was also stressed during the
>         design. Above all, an attempt was made to keep to a relatively
>         small number of underlying concepts integrated in a consistent
>         and systematic way while continuing to avoid the pitfalls of
>         excessive involution.  The design especially aims to provide
>         language constructs that correspond intuitively to the normal
>         expectations of users.
>
>     9   Like many other human activities, the development of programs
>         is becoming ever more decentralized and distributed.
Consequently,
>         the ability to assemble a program from independently produced
>         software components continues to be a central idea in the design.
>         The concepts of packages, of private types, and of generic units
>         are directly related to this idea, which has ramifications in many
>         other aspects of the language.  An allied concern is the
maintenance
>         of programs to match changing requirements; type extension and the
>         hierarchical library enable a program to be modified while
minimizing
>         disturbance to existing tested and trusted components.
>
>   10   No language can avoid the problem of efficiency.  Languages that
>         require over-elaborate compilers, or that lead to the inefficient
use
>         of storage or execution time, force these inefficiencies on all
>         machines and on all programs.  Every construct of the language was
>         examined in the light of present implementation techniques.  Any
>         proposed construct whose implementation was unclear or that
>         required excessive machine resources was rejected.
>
> Unquote!
>
> Which any programmer should take to mean that they should write High
> Integrity and Efficient code to maintain the Ada Design Goals. And that
> just one of many parts of the manual that address these type of concerns.
>
> Randy Brukardt may have writing one or more sections but as the list
> of authors states he was not alone. So, unless he wrote the intro he
> could of skipped that section. Just like most people who read the RM,
> they skip parts that does not deal with writing code. I personally have
> no problems that Randy Brukardt writing part(s) of the RM unless he
> wrote that intro. In that case, telling me to re-read it is just wrong.
>

Re: Direct Quote from the RM

[Ludovic Brenta]

Randy Brukardt writes
> The introduction is just a list of "good" properties which really doesn't
> mean that much and has no bearing on the requirements for implementations
> and users. Pretty much every programming language has a version of these
> same goals. After all, can you imagine a programming language saying that it
> was designed to make unreliable programs with no regard to efficiency? Who'd
> use that?

Malbolge and INTERCAL come to mind :)

And yes, there are people "using" these languages, for some weird
definition of "use" :)

-- 
Ludovic Brenta.

Re: Direct Quote from the RM

[Randy Brukardt]

"anon" <anon@anon.org> wrote in message
news:mYI%i.27882$if6.6495@bgtnsc05-news.ops.worldnet.att.net...
> Intro or section 0 between 150 .. 200 lines in the RM for Ada 95!
>
> (long quote omitted).

Ah, yes, the motherhood section. I was asking you to provide a *normative*
reference (one that is actually binding on users/implementers), which the
introduction is surely not such a section. (See the definition of
"normative" in 1.1.2.)

The introduction is just a list of "good" properties which really doesn't
mean that much and has no bearing on the requirements for implementations
and users. Pretty much every programming language has a version of these
same goals. After all, can you imagine a programming language saying that it
was designed to make unreliable programs with no regard to efficiency? Who'd
use that?

Others have explained the difference between properties of the language and
properties of the toolset, so I won't spend more time on that.

                                  Randy.






> Quote
>
>     Design Goals
>
>     6   Ada was originally designed with three overriding concerns:
>         program reliability and maintenance, programming as a human
>         activity, and efficiency. This revision to the language was
>         designed to provide greater flexibility and extensibility,
>         additional control over storage management and synchronization,
>         and standardized packages oriented toward supporting important
>         application areas, while at the same time retaining the original
>         emphasis on reliability, maintainability, and efficiency.
>
>     7   The need for languages that promote reliability and simplify
>         maintenance is well established.  Hence emphasis was placed
>         on program readability over ease of writing.  For example, the
>         rules of the language require that program variables be explicitly
>         declared and that their type be specified.  Since the type of a
>         variable is invariant, compilers can ensure that operations on
>         variables are compatible with the properties intended for objects
>         of the type.  Furthermore, error-prone notations have been
avoided,
>         and the syntax of the language avoids the use of encoded forms in
>         favor of more English-like constructs.  Finally, the language
offers
>         support for separate compilation of program units in a way that
>         facilitates program development and maintenance, and which
>         provides the same degree of checking between units as within a
>         unit.
>
>     8   Concern for the human programmer was also stressed during the
>         design. Above all, an attempt was made to keep to a relatively
>         small number of underlying concepts integrated in a consistent
>         and systematic way while continuing to avoid the pitfalls of
>         excessive involution.  The design especially aims to provide
>         language constructs that correspond intuitively to the normal
>         expectations of users.
>
>     9   Like many other human activities, the development of programs
>         is becoming ever more decentralized and distributed.
Consequently,
>         the ability to assemble a program from independently produced
>         software components continues to be a central idea in the design.
>         The concepts of packages, of private types, and of generic units
>         are directly related to this idea, which has ramifications in many
>         other aspects of the language.  An allied concern is the
maintenance
>         of programs to match changing requirements; type extension and the
>         hierarchical library enable a program to be modified while
minimizing
>         disturbance to existing tested and trusted components.
>
>   10   No language can avoid the problem of efficiency.  Languages that
>         require over-elaborate compilers, or that lead to the inefficient
use
>         of storage or execution time, force these inefficiencies on all
>         machines and on all programs.  Every construct of the language was
>         examined in the light of present implementation techniques.  Any
>         proposed construct whose implementation was unclear or that
>         required excessive machine resources was rejected.
>
> Unquote!
>
> Which any programmer should take to mean that they should write High
> Integrity and Efficient code to maintain the Ada Design Goals. And that
> just one of many parts of the manual that address these type of concerns.
>
> Randy Brukardt may have writing one or more sections but as the list
> of authors states he was not alone. So, unless he wrote the intro he
> could of skipped that section. Just like most people who read the RM,
> they skip parts that does not deal with writing code. I personally have
> no problems that Randy Brukardt writing part(s) of the RM unless he
> wrote that intro. In that case, telling me to re-read it is just wrong.
>

Re: Direct Quote from the RM

[anon]

For Randy Brukardt.

You did not need to post three copies of you post! I read the first one.

Since, you want to sub-divide the RM that's fine. From 1.1.2 using (2 
and 3) states the core starts in Section 1 .. 13. So using 
"Section 1 General" paragraph 1.

Quote!

    1   Ada is a programming language designed to support the 
        construction of long-lived, highly reliable software systems.  
        The language includes facilities to define packages of related 
        types, objects, and operations.  The packages may be 
        parameterized and the types may be extended to support the
        construction of libraries of reusable, adaptable software 
        components.  The operations may be implemented as subprograms 
        using conventional sequential control structures, or as entries 
        that include synchronization of concurrent threads of control as 
        part of their invocation.  The language treats modularity in the 
        physical sense as well, with a facility to support separate
        compilation.

Unquote!

Which echoes the "Design Goals" with less detail. You step in that one. 
But to extend this concept (answer) every paragraph under the Headings
"Implementation Requirements", "Implementation Permissions", 
"Implementation Advice" and "NOTES" strengthen the concept of creating 
"HIGH INTEGRITY and HIGH RELIABLE" software.

Note: The one and only and I do mean ONLY language that states in its 
design and goal sections it was construct for high reliable and high 
integrity software is Ada.  Every language has a specific purpose, and Ada 
purpose is for creating efficiency and integrity software. Just like COBOL 
was created as a "COmmon Business-Oriented Language" and FORTRAN 
was created as a "FORmula TRANslation" language.  


In <fhta34$fv9$1@jacob-sparre.dk>, "Randy Brukardt" <randy@rrsoftware.com> writes:
>"anon" <anon@anon.org> wrote in message
>news:mYI%i.27882$if6.6495@bgtnsc05-news.ops.worldnet.att.net...
>> Intro or section 0 between 150 .. 200 lines in the RM for Ada 95!
>>
>> (long quote omitted).
>
>Ah, yes, the motherhood section. I was asking you to provide a *normative*
>reference (one that is actually binding on users/implementers), which the
>introduction is surely not such a section. (See the definition of
>"normative" in 1.1.2.)
>
>The introduction is just a list of "good" properties which really doesn't
>mean that much and has no bearing on the requirements for implementations
>and users. Pretty much every programming language has a version of these
>same goals. After all, can you imagine a programming language saying that it
>was designed to make unreliable programs with no regard to efficiency? Who'd
>use that?
>
>Others have explained the difference between properties of the language and
>properties of the toolset, so I won't spend more time on that.
>
>                                  Randy.
>
>
>
>
>
>
>> Quote
>>
>>     Design Goals
>>
>>     6   Ada was originally designed with three overriding concerns:
>>         program reliability and maintenance, programming as a human
>>         activity, and efficiency. This revision to the language was
>>         designed to provide greater flexibility and extensibility,
>>         additional control over storage management and synchronization,
>>         and standardized packages oriented toward supporting important
>>         application areas, while at the same time retaining the original
>>         emphasis on reliability, maintainability, and efficiency.
>>
>>     7   The need for languages that promote reliability and simplify
>>         maintenance is well established.  Hence emphasis was placed
>>         on program readability over ease of writing.  For example, the
>>         rules of the language require that program variables be explicitly
>>         declared and that their type be specified.  Since the type of a
>>         variable is invariant, compilers can ensure that operations on
>>         variables are compatible with the properties intended for objects
>>         of the type.  Furthermore, error-prone notations have been
>avoided,
>>         and the syntax of the language avoids the use of encoded forms in
>>         favor of more English-like constructs.  Finally, the language
>offers
>>         support for separate compilation of program units in a way that
>>         facilitates program development and maintenance, and which
>>         provides the same degree of checking between units as within a
>>         unit.
>>
>>     8   Concern for the human programmer was also stressed during the
>>         design. Above all, an attempt was made to keep to a relatively
>>         small number of underlying concepts integrated in a consistent
>>         and systematic way while continuing to avoid the pitfalls of
>>         excessive involution.  The design especially aims to provide
>>         language constructs that correspond intuitively to the normal
>>         expectations of users.
>>
>>     9   Like many other human activities, the development of programs
>>         is becoming ever more decentralized and distributed.
>Consequently,
>>         the ability to assemble a program from independently produced
>>         software components continues to be a central idea in the design.
>>         The concepts of packages, of private types, and of generic units
>>         are directly related to this idea, which has ramifications in many
>>         other aspects of the language.  An allied concern is the
>maintenance
>>         of programs to match changing requirements; type extension and the
>>         hierarchical library enable a program to be modified while
>minimizing
>>         disturbance to existing tested and trusted components.
>>
>>   10   No language can avoid the problem of efficiency.  Languages that
>>         require over-elaborate compilers, or that lead to the inefficient
>use
>>         of storage or execution time, force these inefficiencies on all
>>         machines and on all programs.  Every construct of the language was
>>         examined in the light of present implementation techniques.  Any
>>         proposed construct whose implementation was unclear or that
>>         required excessive machine resources was rejected.
>>
>> Unquote!
>>
>> Which any programmer should take to mean that they should write High
>> Integrity and Efficient code to maintain the Ada Design Goals. And that
>> just one of many parts of the manual that address these type of concerns.
>>
>> Randy Brukardt may have writing one or more sections but as the list
>> of authors states he was not alone. So, unless he wrote the intro he
>> could of skipped that section. Just like most people who read the RM,
>> they skip parts that does not deal with writing code. I personally have
>> no problems that Randy Brukardt writing part(s) of the RM unless he
>> wrote that intro. In that case, telling me to re-read it is just wrong.
>>
>
>

Re: Direct Quote from the RM

[Adam Beneschan]

On Nov 20, 4:32 am, a...@anon.org (anon) wrote:
> For Randy Brukardt.
>
> You did not need to post three copies of you post! I read the first one.
>
> Since, you want to sub-divide the RM that's fine. From 1.1.2 using (2
> and 3) states the core starts in Section 1 .. 13. So using
> "Section 1 General" paragraph 1.

Randy, I think he's got you there.  Perhaps I should make a formal
request in Ada-Comment that 1.1.2(3) be changed from "Sections 1
through 13" to "Sections 1.1.3 through 13".  And maybe I'm the right
person to submit this, since I seem someone who worries way too much
about the implications of taking the RM's language hyper-literally.
Maybe this should be brought up at an ARG meeting, for comic relief to
release some stress before delving into the next Baird issue.  (I
notice you finally changed the !recommendation section of AI05-0051,
by the way...)  :) :)

                            -- Adam

Re: Direct Quote from the RM

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message
news:d5495389-9ee7-44f5-8a3e-864afdc7edee@s36g2000prg.googlegroups.com...
> On Nov 20, 4:32 am, a...@anon.org (anon) wrote:
> > For Randy Brukardt.
> >
> > You did not need to post three copies of you post! I read the first one.
> >
> > Since, you want to sub-divide the RM that's fine. From 1.1.2 using (2
> > and 3) states the core starts in Section 1 .. 13. So using
> > "Section 1 General" paragraph 1.
>
> Randy, I think he's got you there.

Not sure why you think so, none of the language talking about compilation
environments is echoed there. And the original discussion was about
compilation environments, not about the language itself.

> Perhaps I should make a formal
> request in Ada-Comment that 1.1.2(3) be changed from "Sections 1
> through 13" to "Sections 1.1.3 through 13".  And maybe I'm the right
> person to submit this, since I seem someone who worries way too much
> about the implications of taking the RM's language hyper-literally.

<grin> I don't think there is anything wrong with 1.1 or 1.1.1. It *is*
unusual that Section 1 isn't marked as Redundant in the AARM, because it is
just the normal non-normative introductory text. (Most clauses in the RM
start with introductory text that doesn't include anything normative - it
just makes the purpose of the clause easier to understand for the reader. A
big difference between the Ada standard and many others is the attempt to
make it readable to ordinary programmers.) The real problem is that 1.12
doesn't clearly note that introductory text is non-normative - but that's
probably because there are some counter-examples.

> Maybe this should be brought up at an ARG meeting, for comic relief to
> release some stress before delving into the next Baird issue.  (I
> notice you finally changed the !recommendation section of AI05-0051,
> by the way...)  :) :)

Nawww, Tucker just did his homework and provided a new version, which
necessarily included a real recommendation. Of course, if you read his
e-mail that ends the !appendix of the e-mail, you'll note that the effect of
the AI hasn't changed any. :-)

                           Randy.

Re: Direct Quote from the RM

[anon]

If you read below the quote you would have read that I included all 
paragraphs under the heading "Implementation Requirements", 
"Implementation Permissions", "Implementation Advice" and "NOTES".

With that said, Section 1.1.5 paragraph 11, under the  
"Implementation Permissions" heading states that the usages of 
"compile line switch" converts the 'Standard Ada Compiler' to a 
'Non-Standard Compiler' mode of operation that can reject 
compilation_units that do not comply with the "Non-Standard" mode 
or to halt compiling due to too many "errors/warnings".

Note: 'mode of operation' has to do with "compilation environments".

So, adding "-fstack-check" converts the standard GNAT compiler to 
an "Non-standard compiler". 

Also, the "-fstack-check" switch does not reject compilation_units 
or halt process because of to many errors/warnings.  It only halts 
the process if the Storage_Error exception is not trapped and a 
Storage_Error is raised, which could be apart of the algorithm. 
So, it does not meet the definition of a "command line switch" in 
Section 1.1.5 (11).

Also requesting that this switch becomes apart of the default 
suggest that one wants all future GNAT Ada compiler to be 
"Non-Standard" only Ada compile. 

And does a 'Non-Standard' compiler imply "HIGH INTEGRITY and 
HIGH RELIABLE" software, based on the RM? The answer is 'NO!'


In <fi07no$t2$1@jacob-sparre.dk>, "Randy Brukardt" <randy@rrsoftware.com> writes:
>"Adam Beneschan" <adam@irvine.com> wrote in message
>news:d5495389-9ee7-44f5-8a3e-864afdc7edee@s36g2000prg.googlegroups.com...
>> On Nov 20, 4:32 am, a...@anon.org (anon) wrote:
>> > For Randy Brukardt.
>> >
>> > You did not need to post three copies of you post! I read the first one.
>> >
>> > Since, you want to sub-divide the RM that's fine. From 1.1.2 using (2
>> > and 3) states the core starts in Section 1 .. 13. So using
>> > "Section 1 General" paragraph 1.
>>
>> Randy, I think he's got you there.
>
>Not sure why you think so, none of the language talking about compilation
>environments is echoed there. And the original discussion was about
>compilation environments, not about the language itself.
>
>> Perhaps I should make a formal
>> request in Ada-Comment that 1.1.2(3) be changed from "Sections 1
>> through 13" to "Sections 1.1.3 through 13".  And maybe I'm the right
>> person to submit this, since I seem someone who worries way too much
>> about the implications of taking the RM's language hyper-literally.
>
><grin> I don't think there is anything wrong with 1.1 or 1.1.1. It *is*
>unusual that Section 1 isn't marked as Redundant in the AARM, because it is
>just the normal non-normative introductory text. (Most clauses in the RM
>start with introductory text that doesn't include anything normative - it
>just makes the purpose of the clause easier to understand for the reader. A
>big difference between the Ada standard and many others is the attempt to
>make it readable to ordinary programmers.) The real problem is that 1.12
>doesn't clearly note that introductory text is non-normative - but that's
>probably because there are some counter-examples.
>
>> Maybe this should be brought up at an ARG meeting, for comic relief to
>> release some stress before delving into the next Baird issue.  (I
>> notice you finally changed the !recommendation section of AI05-0051,
>> by the way...)  :) :)
>
>Nawww, Tucker just did his homework and provided a new version, which
>necessarily included a real recommendation. Of course, if you read his
>e-mail that ends the !appendix of the e-mail, you'll note that the effect of
>the AI hasn't changed any. :-)
>
>                           Randy.
>
>
>

Re: Direct Quote from the RM

[Randy Brukardt]

"anon" <anon@anon.org> wrote in message
news:ZtA0j.33469$if6.26651@bgtnsc05-news.ops.worldnet.att.net...
...
> You did not need to post three copies of you post! I read the first one.

I didn't intend to post more than one; the first and second attempts failed
during the posting and I didn't realize that they had gotten through despite
the error. Since the newsreader sends before reading, I didn't notice the
multiple postings until later. I suppose it's what I get for feeding the
troll...

                  Randy.

Re: Direct Quote from the RM

[Randy Brukardt]

"anon" <anon@anon.org> wrote in message
news:ZtA0j.33469$if6.26651@bgtnsc05-news.ops.worldnet.att.net...
...
> You did not need to post three copies of you post! I read the first one.

I didn't intend to post more than one; the first and second attempts failed
during the posting and I didn't realize that they had gotten through despite
the error. Since the newsreader sends before reading, I didn't notice the
multiple postings until later. I suppose it's what I get for feeding the
troll...

                  Randy.

Re: Direct Quote from the RM

[Adam Beneschan]

On Nov 20, 7:01 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "anon" <a...@anon.org> wrote in message
>
> news:ZtA0j.33469$if6.26651@bgtnsc05-news.ops.worldnet.att.net...
> ...
>
> > You did not need to post three copies of you post! I read the first one.
>
> I didn't intend to post more than one; the first and second attempts failed
> during the posting and I didn't realize that they had gotten through despite
> the error. Since the newsreader sends before reading, I didn't notice the
> multiple postings until later. I suppose it's what I get for feeding the
> troll...

Well, your explanation for why the post showed up three times only
showed up twice, so I guess that's an improvement.  :)

This is a big problem with Google Groups, which I use to post.  Too
often, I write my post and send it, and Google eventually comes back
with a message like "There was an error in posting, try again later",
only to find out that the post actually did make it out to Usenet and
I didn't really need to retry.  It doesn't appear that you're using
Google to post, but apparently whatever method you're using suffers
from the same glitch.

                        -- Adam