Re: Certified C compilers for safety-critical embedded systems

Re: Certified C compilers for safety-critical embedded systems

[Mike Silva]

Alan Balmer <albalmer@att.net> wrote in message news:<b5feuv06s2nmpakq0o1b7v0kpd450v3eli@4ax.com>...
> On 22 Dec 2003 10:20:04 -0800, snarflemike@yahoo.com (Mike Silva)
> wrote:
> 
> >"tanya" <tanya.anne@bigpond.com> wrote in message news:<bs62ph$giu$1@newshost.mot.com>...
> >
> >> As for using C, it is a simple language that can be and is used safely by
> >> many people.
> >
> >I think a more interesting question is: given a particular quality of
> >programming talent and fixed amounts of time and money, how will
> >software written in C fare against software written in "better" (as
> >determined by safety-critical industry concensus) languages?  I think
> >the evidence is overwhelming that it will fare quite badly, meaning it
> >will cost more and/or take more time and/or and have more residual
> >errors.
> >
> Sounds interesting. Can you provide references to such evidence,
> obtained under the stated conditions?

I think the Ada and SPARK communities can, which is why I've added
comp.lang.ada to this thread.  For example, here's reference to a
100:1 residual error reduction between C and SPARK, and a 10:1
reduction between C and Ada, with all code having been previously
certified to DO178B level A:

http://www.sparkada.com/downloads/Mar2002Amey.pdf

Some more interesting reading (note that MISRA acknowledges that there
are better languages than C for safety-critical work):

http://www.sparkada.com/downloads/misracatsil4reader.pdf

This document has a table of language recommendations (search for
"Language Recommendations (IEC 1508)" ).  C is only recommended for
SIL1, while it is not recommended for SIL3 and SIL4:

https://www.cis.strath.ac.uk/teaching/ug/classes/52.422/programming.languages.doc

Mike

Re: Certified C compilers for safety-critical embedded systems

[Alan Balmer]

On 22 Dec 2003 21:06:08 -0800, snarflemike@yahoo.com (Mike Silva)
wrote:

>Alan Balmer <albalmer@att.net> wrote in message news:<b5feuv06s2nmpakq0o1b7v0kpd450v3eli@4ax.com>...
>> On 22 Dec 2003 10:20:04 -0800, snarflemike@yahoo.com (Mike Silva)
>> wrote:
>> 
>> >"tanya" <tanya.anne@bigpond.com> wrote in message news:<bs62ph$giu$1@newshost.mot.com>...
>> >
>> >> As for using C, it is a simple language that can be and is used safely by
>> >> many people.
>> >
>> >I think a more interesting question is: given a particular quality of
>> >programming talent and fixed amounts of time and money, how will
>> >software written in C fare against software written in "better" (as
>> >determined by safety-critical industry concensus) languages?  I think
>> >the evidence is overwhelming that it will fare quite badly, meaning it
>> >will cost more and/or take more time and/or and have more residual
>> >errors.
>> >
>> Sounds interesting. Can you provide references to such evidence,
>> obtained under the stated conditions?
>
>I think the Ada and SPARK communities can, which is why I've added
>comp.lang.ada to this thread.  For example, here's reference to a
>100:1 residual error reduction between C and SPARK, and a 10:1
>reduction between C and Ada, with all code having been previously
>certified to DO178B level A:
>
>http://www.sparkada.com/downloads/Mar2002Amey.pdf

An interesting article, though not for the residual error reduction
references, which are simply quotes of claims made by Lockheed, with
no background. However, the author makes some excellent points,
including one I don't see made often enough - that higher level
languages tend to increase abstraction but decrease predictability.
This is countered to a significant extent by using a well-chosen
language subset, like SPARK. In particular, this leads to the
possibility of static analyzers which are, in a sense, the logic
equivalent of lint's syntax checking.

In reference to "those who maintain that choice of programming
language does not matter, and that critical code can be written
correctly in any language", he says "The claim may be true in
principle but clearly is not commonly achieved in practice." Let me
interject that my position is that "critical code can be written
correctly in any language" (actually stronger than I would contend),
but not that "choice of programming language does not matter." I'd
also point out that there is probably more critical code written in
assembler and C than in Ada or SPARK :-)
>
>Some more interesting reading (note that MISRA acknowledges that there
>are better languages than C for safety-critical work):
>
>http://www.sparkada.com/downloads/misracatsil4reader.pdf
>
Sorry, but the MISRA recommendations and guidelines are so poorly done
that I can't accept them as even relevant. This is not just my
opinion, but that of some very well-respected authorities, and has
been discussed here on occasion.

>This document has a table of language recommendations (search for
>"Language Recommendations (IEC 1508)" ).  C is only recommended for
>SIL1, while it is not recommended for SIL3 and SIL4:
>
>https://www.cis.strath.ac.uk/teaching/ug/classes/52.422/programming.languages.doc

This is one in a series of lectures. I would have some fun arguing
with the lecturer on some of his points, but he does include the
referenced tables from the IEC publication (which I'm too cheap to buy
:-)

I think I have to concede that, on the average, code quality can be
better with a well-chosen subset of a higher-level language other than
C. However, it's still my opinion that "average" programmers, as
described in these studies, shouldn't be writing safety-critical code.

Unfortunately, the material presented doesn't give me any idea of the
whole development process - I don't know if the code in question was
reviewed, linted, or even designed before coding ;-) It may have more
to do with other parts of the process than with the language. I won't
argue that C and poor process are often found in the same
neighborhood.

Since a large part of my work is maintenance of legacy systems, I'll
readily agree that the error rate I encounter is horrible. I'll also
claim that error rates of programs I've completely reworked are very
low. Further, most of the errors I find would have been prevented by
good practices, sticking to standard C where possible, and paying
attention to compiler warnings. In fairness to my predecessors, some
of this code was written before the standard, which excuses about 3%
of the problems I find.

Anyway, some very interesting reading. Thank you.

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

Re: Certified C compilers for safety-critical embedded systems

[Mike Silva]

Alan Balmer <albalmer@att.net> wrote in message news:<eslguvk1fm9bbjs2hak84p2i2in77gv62d@4ax.com>...
> On 22 Dec 2003 21:06:08 -0800, snarflemike@yahoo.com (Mike Silva)
> wrote:

> >...For example, here's reference to a
> >100:1 residual error reduction between C and SPARK, and a 10:1
> >reduction between C and Ada, with all code having been previously
> >certified to DO178B level A:
> >
> >http://www.sparkada.com/downloads/Mar2002Amey.pdf
> 
> An interesting article, though not for the residual error reduction
> references, which are simply quotes of claims made by Lockheed, with
> no background. 

Just to clarify, the error reduction claims I was referring to were
those cited from a UK MoD study done by Aerosystems International. 
I'd like to be able to find that study, or a fuller summary, on line.

Mike

Re: Certified C compilers for safety-critical embedded systems

[Larry Kilgallen]

In article <eslguvk1fm9bbjs2hak84p2i2in77gv62d@4ax.com>, Alan Balmer <albalmer@att.net> writes:

> I think I have to concede that, on the average, code quality can be
> better with a well-chosen subset of a higher-level language other than
> C. However, it's still my opinion that "average" programmers, as
> described in these studies, shouldn't be writing safety-critical code.

Ah, but do you have a way of preventing that ?

(Not just on systems you build, but on those to which you entrust your
own safety.)

> Since a large part of my work is maintenance of legacy systems, I'll
> readily agree that the error rate I encounter is horrible. I'll also
> claim that error rates of programs I've completely reworked are very
> low.

One of the big flaws in replacing a software system outright is to
ignore the fact that requirement capture has been inadequate.

Re: Certified C compilers for safety-critical embedded systems

[Alan Balmer]

On 23 Dec 2003 14:33:11 -0600, Kilgallen@SpamCop.net (Larry Kilgallen)
wrote:

>> Since a large part of my work is maintenance of legacy systems, I'll
>> readily agree that the error rate I encounter is horrible. I'll also
>> claim that error rates of programs I've completely reworked are very
>> low.
>
>One of the big flaws in replacing a software system outright is to
>ignore the fact that requirement capture has been inadequate.

I'm not quite sure what you mean. In maintenance work, the only reason
to modify a program is because it doesn't, in some respect, meet
requirements, either the original requirements or new requirements
which have evolved. Requirements are rarely static during initial
development, let alone a few years down the road :-)

When I say "completely reworked", I don't mean to imply that I rewrite
programs from scratch. I make them ANSI compliant and warning free,
eliminate unused elements, eliminate globals as far as possible,
eliminate unsafe (often erroneous) practices and code,  restructure
and recode to make the code more maintainable, and  where possible
replace internal functions with standard C functions or functions from
our proven in-house libraries. At that point I can stand to read it,
and the real work begins <g>. After this, usually there is
considerable refactoring and often some replacement of algorithms.
Some testing is done during the process. A code review follows,
corrections are made if needed, and more formal unit testing is done
before turning the product over to QA.

Typically, during this process, I'll identify a dozen or more bugs in
an average thousand-line program. Some of them will be recognized by
our support people - "Gee, it's been doing that every couple of
months, but we couldn't reproduce it" , or more often "It's always
done this, but we have a workaround."

That last, incidentally, is a real problem for us. Our support people
are good, and often come up with workarounds to problems they never
tell us about. They enjoy being heroes to the customer, and can't be
persuaded that they'll never run out of work ;-)

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

Re: Certified C compilers for safety-critical embedded systems

[Larry Kilgallen]

In article <ujchuvkp5bmio83vf6t8c0hblkjvrasr60@4ax.com>, Alan Balmer <albalmer@att.net> writes:
> On 23 Dec 2003 14:33:11 -0600, Kilgallen@SpamCop.net (Larry Kilgallen)
> wrote:
> 
>>> Since a large part of my work is maintenance of legacy systems, I'll
>>> readily agree that the error rate I encounter is horrible. I'll also
>>> claim that error rates of programs I've completely reworked are very
>>> low.
>>
>>One of the big flaws in replacing a software system outright is to
>>ignore the fact that requirement capture has been inadequate.
> 
> I'm not quite sure what you mean. In maintenance work, the only reason
> to modify a program is because it doesn't, in some respect, meet
> requirements, either the original requirements or new requirements
> which have evolved. Requirements are rarely static during initial
> development, let alone a few years down the road :-)

For years the program has met some requirements that are "hidden".
Users depended upon certain features but they were never called out
as features in the documentation - they were useful interactions
between different documented features.

A good example is the VMS Mail program, which someone decided to
rewrite from Bliss into C, most likely because they favored C.
Now, ten years later, they are just getting rid of the MAIL/OLD
command that invoked the previous Bliss implementation.  They
had to carry it that long because of all the undocumented features
missing from the Bliss version.

> When I say "completely reworked", I don't mean to imply that I rewrite
> programs from scratch. I make them ANSI compliant and warning free,
> eliminate unused elements, eliminate globals as far as possible,
> eliminate unsafe (often erroneous) practices and code,  restructure
> and recode to make the code more maintainable, and  where possible
> replace internal functions with standard C functions or functions from
> our proven in-house libraries.

Ok, that is different.

Larry Kilgallen
Who subsequently rewrote a Bliss program into Ada, knowing
the lesson of VMS Mail, because the original Bliss design
was incompatible with new requirements.  That rewrite is
just now starting to hit the streets.  Wish it luck :-)

Re: Certified C compilers for safety-critical embedded systems

[Chris Hills]

In article <20619edc.0312222106.3b369547@posting.google.com>, Mike Silva
<snarflemike@yahoo.com> writes
>
>Some more interesting reading (note that MISRA acknowledges that there
>are better languages than C for safety-critical work):

That will change. 

>http://www.sparkada.com/downloads/misracatsil4reader.pdf

Praxis has a vested interest in not letting C be used for SIL 4

BTW 
slide 3 is erroneous.
slide 5 is also erroneous.

AFAIK Praxis are not "involved" with MISRA-C they may have been some
years ago in the original version but much work has been done since
then. AFAIK they have not taken much, if any part, in this.

AFAIK they did not make their SPADE C results available to the MISRA-C
working group who for the last 3 years have been working on MISRA-C2.

Praxis don't have a unique view of MISRA-C.  They are one of many who
were involved in MISRA-C1. They are not one of the main companies who
were promoting and working with it in the last 5 years.

Slide 6 is interesting. The quotes are out of context and misleading.
The Praxis presentation is clearly written with a (commercial) axe to
grind. I was at the MISRA-C 2002 forum. In fact I did one of the
presentations that has been misquoted.... 

As it goes on they rubbish C and surprise surprise come up with a
solution that is their tools.... :-) 

The Ada (tools) community must be rattled if it needs to spend time
trying to rubbish MISRA-C. Perhaps it is just sour grapes as they no
longer push a MISRA-C tool? 

Since the 2002 meeting MISRA-C2 has been reviewed by the SAE and JSAE
several major automotive companies, aerospace companies, also  members
of WG14 the ISO-C panel and met with approval. MISRA-C2 will be
available at the end of Q1 2004


>This document has a table of language recommendations (search for
>"Language Recommendations (IEC 1508)" ).  C is only recommended for
>SIL1, while it is not recommended for SIL3 and SIL4:
>
>https://www.cis.strath.ac.uk/teaching/ug/classes/52.422/programming.languages.do

Yet  C is used in some of the highest integrity systems around. Other
languages that are recommended hardly exist and certainly not on many
platforms.

Empirical evidence and a glance at 61508 may require a change in the
table D2.... BTW table D2 in the lecturers notes is NOT in 61598.

In CEI/IEC 61508:1998 Part 7 Table C1 (page 79), yes I do have my own
copy of 61508, all 7 parts. We find a similar table to "D2" above:

            Sil1   Sil2   Sil3 Sil4
Ada          HR    HR      R    R
ADA (subset) HR    HR      HR   HR
C            R     -      NR    NR

as expected  BUT

C (subset, codinng standard and static analysis) 
             HR   HR      HR     HR


So whilst straight ADA *is* better than vanilla C. No one would debate
that!  Spark ADA is no better than C with a subset, coding standard and
using static analysis....  IE much the same constraints as SPARK ADA has
over ADA...

I know of projects using C in Railway, space, aero and medical projects.

PASCAL and Mod2 are mentioned but you will be hard pressed to find tool
for these for many targets. BTW is there ADA for the PIC, AVR and 8015?

I come back to my comment previously that the ADA tools vendors must be
worried if they are spending this much effort trying to rubbish MISRA-C
which is an automotive guide.  Though it has gained widespread use
outside the automotive industry due to those involved with it.


Regards
        Chris


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Certified C compilers for safety-critical embedded systems

[Alan Balmer]

On Wed, 24 Dec 2003 16:46:19 +0000, Chris Hills <chris@phaedsys.org>
wrote:

>Since the 2002 meeting MISRA-C2 has been reviewed by the SAE and JSAE
>several major automotive companies, aerospace companies, also  members
>of WG14 the ISO-C panel and met with approval. MISRA-C2 will be
>available at the end of Q1 2004

Thanks for the good analysis. I'd like to keep up with news about
MISRA-C2. What's a good source?

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

Re: Certified C compilers for safety-critical embedded systems

[Dave Hansen]

On Wed, 24 Dec 2003 16:46:19 +0000, Chris Hills <chris@phaedsys.org>
wrote:

[...]
>
>PASCAL and Mod2 are mentioned but you will be hard pressed to find tool
>for these for many targets. BTW is there ADA for the PIC, AVR and 8015?

Nit: it's "Pascal," "Modula-2," and "Ada."

The PIC I doubt. I'm hard-pressed to consider some of the "C"
compilers for PIC to be C.  As an alternative HLL, JAL (Just Another
Language) is kind of interesting.  http://www.voti.nl/jal/

The AVR is supported by GCC, so GNAT might work, though the runtime
support probably isn't there.  I haven't tried it in any case.

The 8015 I've never heard of.  I assume you mean 8051, to which I'd
have to say I haven't heard of one, though there is a Modula-2
compiler.

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

Re: Certified C compilers for safety-critical embedded systems

[Chris Hills]

In article <k8mjuvshdirlqkl5its6jbqr7hlthfk990@4ax.com>, Alan Balmer
<albalmer@att.net> writes
>On Wed, 24 Dec 2003 16:46:19 +0000, Chris Hills <chris@phaedsys.org>
>wrote:
>
>>Since the 2002 meeting MISRA-C2 has been reviewed by the SAE and JSAE
>>several major automotive companies, aerospace companies, also  members
>>of WG14 the ISO-C panel and met with approval. MISRA-C2 will be
>>available at the end of Q1 2004
>
>Thanks for the good analysis. I'd like to keep up with news about
>MISRA-C2. What's a good source?
>

Well come the new year comp.lang.c.misra  assuming I can get the
paperwork sorted.

Otherwise just ask me.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Certified C compilers for safety-critical embedded systems

[Chris Hills]

In article <3fe9f0d7.104475725@News.CIS.DFN.DE>, Dave Hansen
<iddw@hotmail.com> writes
>On Wed, 24 Dec 2003 16:46:19 +0000, Chris Hills <chris@phaedsys.org>
>wrote:
>
>[...]
>>
>>PASCAL and Mod2 are mentioned but you will be hard pressed to find tool
>>for these for many targets. BTW is there ADA for the PIC, AVR and 8015?
>
>Nit: it's "Pascal," "Modula-2," and "Ada."
>
>The PIC I doubt. I'm hard-pressed to consider some of the "C"
>compilers for PIC to be C.
:-) 
I know what you mean.

>The AVR is supported by GCC,
GCC is not usually suitable for 8 and 16 bit embedded systems. IT is a
generic compiler system that is not usually a patch onthe commercial
ones.. 

> so GNAT might work, though the runtime
>support probably isn't there.  I haven't tried it in any case.


>
>The 8015 I've never heard of.  I assume you mean 8051, to which I'd
>have to say I haven't heard of one, 

yes.... though some one will now tell us about the 8015 from 197* that
was around for 2.3 years :-)

>though there is a Modula-2
>compiler.

But is it any good? 

I once had to work on an embedded system using Mod2 a none of the
compilers supported the basic language in the same way.  Let alone
extensions.  It turned out that the most stable compiler was the least
standard :-( 

A theoretically good language is no use at all if the compiler
implementations are no good. 

At least with C there will usually be several commercial compilers and a
multitude of testing and checking tools.  

It's one thing having a compiler but what about the rest. How many ICE
support ADA? 

Regards
        Chris

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Certified C compilers for safety-critical embedded systems

[Alan Balmer]

On Wed, 24 Dec 2003 20:35:03 +0000, Chris Hills <chris@phaedsys.org>
wrote:

>
>Well come the new year comp.lang.c.misra  assuming I can get the
>paperwork sorted.
>
Great. I'll keep a lookout.

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

Re: Certified C compilers for safety-critical embedded systems

[Dave Hansen]

On Wed, 24 Dec 2003 20:41:41 +0000, Chris Hills <chris@phaedsys.org>
wrote:

>In article <3fe9f0d7.104475725@News.CIS.DFN.DE>, Dave Hansen
><iddw@hotmail.com> writes
[...]
>>The AVR is supported by GCC,
>GCC is not usually suitable for 8 and 16 bit embedded systems. IT is a
>generic compiler system that is not usually a patch onthe commercial
>ones.. 

Avr-gcc actually generates _very_ nice code for the AVR, better than
one commercial compiler I use, and comparable with another.  Of
course, unlike the 8051, the AVR was developed with HLL (esp. C) in
mind.  For example, it has 32 general-purpose registers.

[...re: 8051...]
>>though there is a Modula-2
>>compiler.
>
>But is it any good? 

You'd have to ask Mr. Granville.  Though I think I know what he'd say.
;-)

But as a datapoint, it was able to come within one instruction of my
handwritten assembly on a pathological checksum routine I posted back
in January of 1999 (seven instructions vs. six).  The Keil C compiler
I was usingat the time (v5.5 IIRC) was unable to do better than 13,
even when using the intrinsics for byte rotation and testing the carry
bit.

So from what little I've seen, I'd say it looks quite good.

>
>I once had to work on an embedded system using Mod2 a none of the
>compilers supported the basic language in the same way.  Let alone
>extensions.  It turned out that the most stable compiler was the least
>standard :-( 
>
>A theoretically good language is no use at all if the compiler
>implementations are no good. 

Fewer implementations implies fewer good implementations, true.  At
least the odds are reduced.  Fewer targetted platforms means your code
is less portable as well.

>
>At least with C there will usually be several commercial compilers and a
>multitude of testing and checking tools.  

I think I said it earlier in this thread: The only processors I'm
aware of that don't have a C or NQC (Not Quite C) compiler are
four-bitters.  It's ubiquitous.

But C can be, umm, subtle, and static checking tools (particularly
Lint) are IMHO _required_.  Sadly, they're not often used.

>
>It's one thing having a compiler but what about the rest. How many ICE
>support ADA? 

Nit: ICE is hardware.  And the various debuggers I've seen shipped
with most ICE systems don't support C particularly well either.

And I haven't used an ICE in years.  

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

Re: Certified C compilers for safety-critical embedded systems

[Mike Silva]

Chris Hills <chris@phaedsys.org> wrote in message news:<45cs9hAbLc6$EAAx@phaedsys.demon.co.uk>...
> In article <20619edc.0312222106.3b369547@posting.google.com>, Mike Silva
> <snarflemike@yahoo.com> writes
> >
> >Some more interesting reading (note that MISRA acknowledges that there
> >are better languages than C for safety-critical work):
> 
> That will change. 

I'd like to hear your thoughts on the noted 100:1 residual error
improvement between SPARK code and C code, all DO-178B level A.  Do
you think the C code examined did not use "a subset, coding standards
and static analysis"?  If they didn't, who does?  Is your claim that,
properly used, C can yield equivalent residual error rates as SPARK? 
If so, why do you think the code examined in the study was a 100 times
worse?

Mike

Re: Certified C compilers for safety-critical embedded systems

[Mike Silva]

Chris Hills <chris@phaedsys.org> wrote in message news:<45cs9hAbLc6$EAAx@phaedsys.demon.co.uk>...
>             Sil1   Sil2   Sil3 Sil4
> Ada          HR    HR      R    R
> ADA (subset) HR    HR      HR   HR
> C            R     -      NR    NR
> 
> as expected  BUT
> 
> C (subset, codinng standard and static analysis) 
>              HR   HR      HR     HR

I had a thought about this also.  In the Ada case we see a change from
R (recommended) to HR (highly recommended) at SIL3 and SIL4.  In the C
case we see a change from NR (not recommended), past - (no
recommendation) and R to HR.  To go from Ada to SPARK is one step
(i.e. good to best) while to go from C to SIL4-C is three steps (i.e.
worst to best).  How will that (3 step improvement vs. 1 step
improvement) manifest itself in the complexity, cost and lack of
errors in the tools, the expressiveness and ease of use of the
resulting language subset, etc, etc.

Mike

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Dave Hansen wrote:

> The AVR is supported by GCC, so GNAT might work, though the runtime
> support probably isn't there.  I haven't tried it in any case.

Please, there is a version of GNAT that requires zero run-time support. 
   In fact in the safety critical market it is favored as a base for 
SPARK, since then there is no need to validate the run-time.

But remember that you really have to think in terms of development host, 
target, and the ICE or other system used to download and run tests.  So 
the triplet you want may or may not be supported.

> The 8015 I've never heard of.  I assume you mean 8051, to which I'd
> have to say I haven't heard of one, though there is a Modula-2
> compiler.

There have been several Ada compilers that targetted 8-bit 
microprocessors.  However, I don't think anyone ever validated an 8051 
target due to capacity limitations.  There is an interesting discussion 
here, at length, about that topic (in 1995): 
http://www.adahome.com/News/Trip-Reports/TA95-email.html

There is evan a comment there (by me):

"AFAIK the smallest computers that Ada has been targeted to
include the 128-kbyte Western Digital P-machines, the Russian PDP-11
clones, and the RRSoft compiler which ran on 512K 8088 based
PC-clones.

However, in all these cases the compiler was self-hosted!

So certainly an 8051 target is very reasonable, it just remains
to be seen if anyone wants to do it."

I think the situation is still the same, although there are other 8-bit 
and even 4-bit microcontrollers with Ada targets.  So it may just be 
that programmers who choose Ada choose Motorola microprocessors, and 
vice-versa.  (In point of fact, I've never used an Intel microprocessor 
in an embedded system, but I have used many Motorola chips, and Z-80s.)

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Chris Hills]

In article <3fea086c.110513550@News.CIS.DFN.DE>, Dave Hansen
<iddw@hotmail.com> writes
>On Wed, 24 Dec 2003 20:41:41 +0000, Chris Hills <chris@phaedsys.org>
>>
>>At least with C there will usually be several commercial compilers and a
>>multitude of testing and checking tools.  
>
>I think I said it earlier in this thread: The only processors I'm
>aware of that don't have a C or NQC (Not Quite C) compiler are
>four-bitters.  It's ubiquitous.

I like "NQC"....  it is a useful TLA as the standards people get in to a
tizz when you talk about the C that is on most 8/16 bit embedded
compilers. 

>But C can be, umm, subtle, and static checking tools (particularly
>Lint) are IMHO _required_.  Sadly, they're not often used.

There is NO EXCUSE for not using a static analyser on C. There are free
Lints,  Commercial ones i.e.   PC-Lint is only a couple 100 USD

I can't see ANY justification for not using some form of Lint with C.

>>It's one thing having a compiler but what about the rest. How many ICE
>>support ADA? 
>
>Nit: ICE is hardware.

Yes.... of course it is. It is an embedded debugging tool. Somewhat
relevant in a discussion on language support in an embedded NG

>  And the various debuggers I've seen shipped
>with most ICE systems don't support C particularly well either.
>And I haven't used an ICE in years.  
I have... several. 

ICE support C VERY well.  As well as (actually better) than simulators.

There is little of no similar support for most other languages.  There
is some for ADA... Years ago I saw some for Pascal and Modula2 but I
don't know any supporting them now.

If you don't use an ICE how do you debug and test?

Regards
  Chris

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Certified C compilers for safety-critical embedded systems

[Chris Hills]

In article <SLednTOvKejD0XeiRVn-gg@comcast.com>, Robert I. Eachus
<rieachus@comcast.net> writes
>Dave Hansen wrote:
>
>But remember that you really have to think in terms of development host, 
>target, and the ICE or other system used to download and run tests.  So 
>the triplet you want may or may not be supported.

Exactly my point. A theoretically good language is useless without the
support tools.... And those support tools haveto be of high quality as
well. 

>> The 8015 I've never heard of.  I assume you mean 8051, to which I'd
>> have to say I haven't heard of one, though there is a Modula-2
>> compiler.
>
>There have been several Ada compilers that targetted 8-bit 
>microprocessors.

I am surprised.

>  However, I don't think anyone ever validated an 8051 
>target due to capacity limitations. 
That is the problem. A non-validated Ada compiler would be no more value
than a good C compiler. Actually  a good C compiler eg the Keil C51 that
has been extensively used in safety related projects by a large number
of people would be better simply because of the empirical field usage
compared to a non-validated Ada compiler with a small user base..


> There is an interesting discussion 
>here, at length, about that topic (in 1995): 
>http://www.adahome.com/News/Trip-Reports/TA95-email.html

>There is evan a comment there (by me):
>"AFAIK the smallest computers that Ada has been targeted to
>include the 128-kbyte Western Digital P-machines, the Russian PDP-11
>clones, and the RRSoft compiler which ran on 512K 8088 based
>PC-clones.
>
>However, in all these cases the compiler was self-hosted!

That takes some doing!!!


>So certainly an 8051 target is very reasonable, it just remains
>to be seen if anyone wants to do it."

I doubt it. At least not in large enough numbers to justify it
especially as 61508 permits C  (subset, with coding standard and static
checking) to SIL-4

In effect a SPARK-C


>I think the situation is still the same, although there are other 8-bit 
>and even 4-bit microcontrollers with Ada targets.  So it may just be 
>that programmers who choose Ada choose Motorola microprocessors, and 
>vice-versa.  (In point of fact, I've never used an Intel microprocessor 
>in an embedded system, but I have used many Motorola chips, and Z-80s.)

Yes there are a LOT!!  They are mainly the 186 and 386. There are of
course the PC 104 systems but... Strangely due to the sort of projects
they 186 and 386 were used in there has been a lot of activity in that
field over the last 9 months.... However I doubt this interest will
continue (unless somewhere else gets invaded)



/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Certified C compilers for safety-critical embedded systems

[Chris Hills]

In article <20619edc.0312241511.3a934503@posting.google.com>, Mike Silva
<snarflemike@yahoo.com> writes
>Chris Hills <chris@phaedsys.org> wrote in message news:<45cs9hAbLc6$EAAx@phaedsy
>s.demon.co.uk>...
>>             Sil1   Sil2   Sil3 Sil4
>> Ada          HR    HR      R    R
>> ADA (subset) HR    HR      HR   HR
>> C            R     -      NR    NR
>> 
>> as expected  BUT
>> 
>> C (subset, codinng standard and static analysis) 
>>              HR   HR      HR     HR
>
>I had a thought about this also.  In the Ada case we see a change from
>R (recommended) to HR (highly recommended) at SIL3 and SIL4.  In the C
>case we see a change from NR (not recommended), past - (no
>recommendation) and R to HR.  To go from Ada to SPARK is one step
>(i.e. good to best) while to go from C to SIL4-C is three steps (i.e.
>worst to best).  

btw not "worst to best"  

I agree to a point. I think this reflects the engineering profession is
maturing and the support tools are coming of age.

>How will that (3 step improvement vs. 1 step
>improvement) manifest itself in the complexity, cost and lack of
>errors in the tools, the expressiveness and ease of use of the
>resulting language subset, etc, etc.

I think that there are now tools and methods in place that there were
not previously.  The sheer weight of the commercial pressure has
improved quality in the compilers and support tools. It has generated a
lot of safety related support for a language that was not originally
designed to be a safety critical language. 

This does not mean it can't be used for safety related projects just
that initially the users were not working in that sort of a field so the
mind set was not there. You could write appalling code in Ada but the
average practitioner has been taught Ada with a view to safety related
systems. The majority of C programmers were not.



/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Certified C compilers for safety-critical embedded systems

[Alan Balmer]

On 24 Dec 2003 14:59:57 -0800, snarflemike@yahoo.com (Mike Silva)
wrote:

>Chris Hills <chris@phaedsys.org> wrote in message news:<45cs9hAbLc6$EAAx@phaedsys.demon.co.uk>...
>> In article <20619edc.0312222106.3b369547@posting.google.com>, Mike Silva
>> <snarflemike@yahoo.com> writes
>> >
>> >Some more interesting reading (note that MISRA acknowledges that there
>> >are better languages than C for safety-critical work):
>> 
>> That will change. 
>
>I'd like to hear your thoughts on the noted 100:1 residual error
>improvement between SPARK code and C code, all DO-178B level A.  Do
>you think the C code examined did not use "a subset, coding standards
>and static analysis"?  If they didn't, who does?  Is your claim that,
>properly used, C can yield equivalent residual error rates as SPARK? 

That seems obvious. It's possible to write a C program with *no*
residual errors. It may be easier to write a SPARK program with no
residual errors, but there's no law that says C programs have to have
more errors.

>If so, why do you think the code examined in the study was a 100 times
>worse?
>
Hard to tell, from the given data. Direct access to the study would be
needed. I would be surprised if the authors of the study didn't do
some analysis of causes.

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

Re: Certified C compilers for safety-critical embedded systems

[Chad R. Meiners]

"Chris Hills" <chris@phaedsys.org> wrote in message
news:fUk12TA8gB7$EA$E@phaedsys.demon.co.uk...
> I doubt it. At least not in large enough numbers to justify it
> especially as 61508 permits C  (subset, with coding standard and static
> checking) to SIL-4
>
> In effect a SPARK-C

When you says static checking, do you include static checkers that can prove
that assertions are never volilated (within a set of assumptions)?  If so
then your C subset with static checking might be in effect a SPARK-C.  SPARK
supports some very nice formal verification techniques which you might be
overlooking.

-CRM

Re: Certified C compilers for safety-critical embedded systems

[Martin Krischik]

Chris Hills wrote:

I wonder how you can speak about a programing languages if you can't even
spell there names properly.

> I once had to work on an embedded system using Mod2 a none of the

It's Modula-2. If you are to lazy to type additional four characters you
should not be writing savety critical software.

> It's one thing having a compiler but what about the rest. How many ICE
> support ADA?

Ada is the name if a woman and not the American Denitist Association and as
such spelled capital "A", lower "d", lower "a" - "Ada".

With Regards

Martin.

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Certified C compilers for safety-critical embedded systems

[Hyman Rosen]

Martin Krischik wrote:
> It's Modula-2. If you are to lazy to type additional four characters you
> should not be writing savety critical software.

It's "too" and "an" and "safety". If you are too lazy to use a spelling and
grammar checker, you should not be writing comments criticizing other peoples'
writing.

Re: Certified C compilers for safety-critical embedded systems

[Larry Kilgallen]

In article <$km9afA3DB7$EAYO@phaedsys.demon.co.uk>, Chris Hills <chris@phaedsys.org> writes:
> In article <3fea086c.110513550@News.CIS.DFN.DE>, Dave Hansen
> <iddw@hotmail.com> writes

>>But C can be, umm, subtle, and static checking tools (particularly
>>Lint) are IMHO _required_.  Sadly, they're not often used.
> 
> There is NO EXCUSE for not using a static analyser on C.

Certainly there is an excuse -- it is not enforced by the compiler.

That is quite different from the situation with Ada.

Re: Certified C compilers for safety-critical embedded systems

[Chris Hills]

In article <bcEFNEK9esyI@eisner.encompasserve.org>, Larry Kilgallen
<Kilgallen@SpamCop.net> writes
>In article <$km9afA3DB7$EAYO@phaedsys.demon.co.uk>, Chris Hills 
><chris@phaedsys.org> writes:
>> In article <3fea086c.110513550@News.CIS.DFN.DE>, Dave Hansen
>> <iddw@hotmail.com> writes
>
>>>But C can be, umm, subtle, and static checking tools (particularly
>>>Lint) are IMHO _required_.  Sadly, they're not often used.
>> 
>> There is NO EXCUSE for not using a static analyser on C.
>
>Certainly there is an excuse -- it is not enforced by the compiler.
>
>That is quite different from the situation with Ada.

So it all has to be enforced by the compiler?

The main difference between C and ADa is that the average ADA programmer
is in a safety critical environment. The average C programmer is not. 

If C program development was *normally* taught as though it was going to
be used in a safety critical environment I think things would change. 



/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Certified C compilers for safety-critical embedded systems

[Robert A Duff]

Hyman Rosen <hyrosen@mail.com> writes:

> Martin Krischik wrote:
> > It's Modula-2. If you are to lazy to type additional four characters you
> > should not be writing savety critical software.
> 
> It's "too" and "an" and "safety". If you are too lazy to use a
> spelling and grammar checker, you should not be writing comments
> criticizing other peoples' writing.

:-)

Well said, Hyman.

It's true that Ada is correctly spelt "Ada", not "ADA" or "ADa", but
come on.  Why do we need to make a big deal about it?  Ada has some
advantages over C, but beating people up over the spelling isn't going
to convince anybody of anything.

- Bob

P.S. for those interested in Ada trivia: In the December 22 issue of
Newsweek, there's a photo of Tony Blair standing in front of a portrait
of Ada.  That's the Ada for whom the language was named.  Page 32.

Re: Certified C compilers for safety-critical embedded systems

[Robert A Duff]

Chris Hills <chris@phaedsys.org> writes:

> In article <bcEFNEK9esyI@eisner.encompasserve.org>, Larry Kilgallen
> <Kilgallen@SpamCop.net> writes
> >In article <$km9afA3DB7$EAYO@phaedsys.demon.co.uk>, Chris Hills 
> ><chris@phaedsys.org> writes:
> >> In article <3fea086c.110513550@News.CIS.DFN.DE>, Dave Hansen
> >> <iddw@hotmail.com> writes
> >
> >>>But C can be, umm, subtle, and static checking tools (particularly
> >>>Lint) are IMHO _required_.  Sadly, they're not often used.
> >> 
> >> There is NO EXCUSE for not using a static analyser on C.
> >
> >Certainly there is an excuse -- it is not enforced by the compiler.
> >
> >That is quite different from the situation with Ada.
> 
> So it all has to be enforced by the compiler?

No, it doesn't.  I agree with you that (in principle) there's nothing
wrong with running 'lint' or whatever in addition to the compiler.
However, 'lint' (in the case of C) doesn't have enough information
to perform the checks that are routinely done by Ada compilers.

The issue is not (primarily) which tool does the analysis (the compiler
versus lint).  The issue is how much information about the intent of the
programmer is contained in the source code.

> The main difference between C and ADa is that the average ADA programmer
> is in a safety critical environment. The average C programmer is not. 

I think it's a mistake to assume that that "average" Ada programmer is
doing safety critical work.  Ada (and/or SPARK) are good in that
environment, but Ada is also quite good for writing run-of-the-mill
non-safety-critical programs, too.  I don't know the statistics, so I
can't say about "average", but the program I'm working on right now
is not safety critical, or even real-time or embedded, but I get some
productivity benefit from Ada's ability to allow me to express various
(compile-time-checkable) constraints.

So I don't agree that the "main" difference between C and Ada is their
environment.

(Boy, I guess the spelling police will really get after you for spelling
"Ada" wrong twice in the same sentence -- "ADa" and "ADA".  Sheesh.  ;-))

> If C program development was *normally* taught as though it was going to
> be used in a safety critical environment I think things would change. 

Probably.  But to learn Ada, you have to first learn to write "Hello,
world", and then learn some more simple stuff, and so on.  Same with C.
Nobody learns to write real-time/embedded/high-integrity/safety-critical
stuff on the first try.

- Bob

Re: Certified C compilers for safety-critical embedded systems

[Larry Kilgallen]

In article <p$OIcVFWHL7$EA6t@phaedsys.demon.co.uk>, Chris Hills <chris@phaedsys.org> writes:
> In article <bcEFNEK9esyI@eisner.encompasserve.org>, Larry Kilgallen
> <Kilgallen@SpamCop.net> writes
>>In article <$km9afA3DB7$EAYO@phaedsys.demon.co.uk>, Chris Hills 
>><chris@phaedsys.org> writes:
>>> In article <3fea086c.110513550@News.CIS.DFN.DE>, Dave Hansen
>>> <iddw@hotmail.com> writes
>>
>>>>But C can be, umm, subtle, and static checking tools (particularly
>>>>Lint) are IMHO _required_.  Sadly, they're not often used.
>>> 
>>> There is NO EXCUSE for not using a static analyser on C.
>>
>>Certainly there is an excuse -- it is not enforced by the compiler.
>>
>>That is quite different from the situation with Ada.
> 
> So it all has to be enforced by the compiler?
> 
> The main difference between C and ADa is that the average ADA programmer
> is in a safety critical environment. The average C programmer is not. 
> 
> If C program development was *normally* taught as though it was going to
> be used in a safety critical environment I think things would change. 

Whereas I think that so long as the infrastructure leaves certain things
to be done "by hand" there will be skimping.

Consider all the regulation and oversight required for drug safety tests.

Re: Certified C compilers for safety-critical embedded systems

[David Emery]

Several people have asserted the argument that the large
number of users of a given tool implies quality in that tool.

I don't buy it.  By this logic, MS Windows should be
absolutely flawproof, and the infamous Pentium Divide bug
should never have happened.

No amount of usage can make up for design flaws.  Popularity
is much less about technical qualities than it is about
marketing.  C, Windows, x86 chips have substantial market
share, which is not the same as saying that they have
substantial quality by design.

			dave

Re: Certified C compilers for safety-critical embedded systems

[Stephen Leake]

Chris Hills <chris@phaedsys.org> writes:

> That is the problem. A non-validated Ada compiler would be no more value
> than a good C compiler. 

That's a pretty strong statement, and I would argue demonstrably
false. The public GNAT compiler 3.15p is non-validated (in the
strictest technical sense; that specific version does not come with a
validation certificate).

The version of Ada most likely to run on 8 bit machines would have no
tasking, no exceptions, and possibly no floating or fixed point, or
dynamic dispatching. That would still be a far better language than C!
Packages, generics, strong typing in general, aggregates,
representation clauses; none of these make demands on the run-time
environment, but all are very powerful programming language features.

> Actually a good C compiler eg the Keil C51 that has been extensively
> used in safety related projects by a large number of people would be
> better simply because of the empirical field usage compared to a
> non-validated Ada compiler with a small user base..

Well, if by "better" you solely mean "more trusted", or possibly "more
thoroughly tested", I would agree. But I'd still use the Ada compiler,
and write thorough unit tests. I don't trust _any_ compiler to not
have bugs when running _my_ code.

-- 
-- Stephe

Re: Certified C compilers for safety-critical embedded systems

[Richard Henry]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:5802069.JsgInS3tXa@linux1.krischik.com...
> Chris Hills wrote:
>
>
> > I once had to work on an embedded system using Mod2 a none of the
>
> It's Modula-2. If you are to lazy to type additional four characters you
> should not be writing

->savety<-

> critical software.

Re: Certified C compilers for safety-critical embedded systems

[James Rogers]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in 
news:wccekur4151.fsf@shell01.TheWorld.com:

> Chris Hills <chris@phaedsys.org> writes:
>> So it all has to be enforced by the compiler?
> 
> No, it doesn't.  I agree with you that (in principle) there's nothing
> wrong with running 'lint' or whatever in addition to the compiler.
> However, 'lint' (in the case of C) doesn't have enough information
> to perform the checks that are routinely done by Ada compilers.

Two simple examples are array bounds checking and scalar range checking.

The C standard explicitly permits accessing one element beyond the end
of an array. Neither the C compiler nor lint can determine if an array
index is outside the bounds of the array. Ada compilers detect static
references beyond the end of an array every time.

Examples:

int foo[10];

int i;

for(i = 0; i < 100; ++i)
{
   foo[i] = i;
}

Although human inspection clearly identifies the for loop indices
to be beyond the bounds of the array, neither the C compiler nor lint
will detect the problem. Since the problem can be clearly identified
using human inspection one might assume this is a problem one would
never see. Unfortunately, the definition of the array may occur many
dozens or even hundreds of lines of code away from the "for" loop.
The definition and the "for" loop may even be located in different 
source files, making the likelihood of human identification very low.

type my_index is range 0..9;
type My_Array_Type is array(my_index) of integer;

foo : My_Array_Type;

for num in 0..99 loop
   foo(num) := num;
end loop;

All Ada compilers will correctly identify the error in the for loop.
The type of "num" is not the same as the type of the index, because
the range of values defined for "num" are not all within the range of
values in my_index. This detection will happen properly no matter how
far the definition is separated from the "for" loop.

Another problem, at least in my uses of lint in the past, was the
settings for lint. You can set lint sensitivity from very low to
very high. The lowest settings for lint miss a number of errors, while
the highest settings for lint often produce a number of false error
indications. It is not always obvious which lint setting to use for
the best level of error identification with a minimum of false error 
messages.

Jim Rogers

Re: Certified C compilers for safety-critical embedded systems

[Jeff C,]

"James Rogers" <jimmaureenrogers@att.net> wrote in message
news:Xns945DE49836882jimmaureenrogers@204.127.36.1...
> Robert A Duff <bobduff@shell01.TheWorld.com> wrote in
> news:wccekur4151.fsf@shell01.TheWorld.com:
>
> > Chris Hills <chris@phaedsys.org> writes:
> >> So it all has to be enforced by the compiler?
> >
> > No, it doesn't.  I agree with you that (in principle) there's nothing
> > wrong with running 'lint' or whatever in addition to the compiler.
> > However, 'lint' (in the case of C) doesn't have enough information
> > to perform the checks that are routinely done by Ada compilers.
>
> Two simple examples are array bounds checking and scalar range checking.
>
> The C standard explicitly permits accessing one element beyond the end
> of an array. Neither the C compiler nor lint can determine if an array
> index is outside the bounds of the array. Ada compilers detect static
> references beyond the end of an array every time.
>
> Examples:
>
> int foo[10];
>
> int i;
>
> for(i = 0; i < 100; ++i)
> {
>    foo[i] = i;
> }
>
> Although human inspection clearly identifies the for loop indices
> to be beyond the bounds of the array, neither the C compiler nor lint
> will detect the problem. Since the problem can be clearly identified



While most C compilers and lint won't find this, there are static analysis
tools that can. Granted the
tools may be able to do a better job on Ada code because there is more
information to work with but
simple cases like you presented here (even if the loop was "far away:" from
foo) can be detected
by tools like Programming Research QA C (No Ada Available) and Polyspace
(Ada available)..

Perhaps even by the LDRA static analysis tools (Ada available) though I have
less to go on for this tool.

Re: Certified C compilers for safety-critical embedded systems

[James Rogers]

"Jeff C," <nolongersafeto@userealemailsniff.com> wrote in
news:yA9Hb.488862$275.1387889@attbi_s53: 

> While most C compilers and lint won't find this, there are static
> analysis tools that can. Granted the
> tools may be able to do a better job on Ada code because there is more
> information to work with but
> simple cases like you presented here (even if the loop was "far away:"
> from foo) can be detected
> by tools like Programming Research QA C (No Ada Available) and
> Polyspace (Ada available)..

Of course, static analysis for any language has its limitations.
For example, what tool exists for C that will reliably identify
the following problem:

int foo[10];

int total(int *a)
{
   int i;
   int sum = 0;
   for(i = 0; i < 100; ++i)
   {
      sum += a[i];
   }
   return sum;
}

Of course, the common C idiom is to pass a limit value along
with the array reference.

int total(int *a, int limit)
{
   int i;
   int sum = 0;
   for(i = 0; i < limit; +=i)
   {
      sum += a[i];
   }
   return sum;
}

The problem is that there is no explicit relationship between
the value passed to the formal parameter "limit" and the number
of elements in the array. It is up to the programmer to ensure
correctness in this detail.

Ada, on the other hand, provides a completely safe syntax to
deal with such problems.

type my_index is range 0..9;

type my_array is array(my_index range <>) of integer;

function total(a : my_array) return integer is
   sum : integer := 0;
begin
   for i in a'range loop
      sum := sum + a(i);
   end loop;
   return sum;
end total;

The Ada run-time will produce a correct iteration through
the array passed to total every time. The compiler will detect
any attempt to pass an parameter that is not of the type my_array.

This is clearly not a case that can be fully handled using static
analysis. Nevertheless, it must be handled correctly for all valid
cases. In Ada it can be proven that the iterations will always be
correct. In C there is no such proof possible. You must rely upon
the skills and attention of the programmer.

When reliability engineers encounter a system relying upon human
actions the commonly accepted error rate, assuming properly trained
humans, is 1 in 1000. Such an error rate is unacceptably low for
most safety critical systems. An error rate of 1 in 1000 is a
reliability rate of 0.999. Safety critical systems commonly
require reliability rates on the order of 0.999999. This is
three orders of magnitude higher than can be achieved through
reliance on human correctness.

Jim Rogers

Re: Certified C compilers for safety-critical embedded systems

[Martin Krischik]

Hyman Rosen wrote:

> Martin Krischik wrote:
>> It's Modula-2. If you are to lazy to type additional four characters you
>> should not be writing savety critical software.
> 
> It's "too" and "an" and "safety". If you are too lazy to use a spelling
> and grammar checker,

I am not lo lazy for that. It's just that sending an english post thue a
german spell checker won't help.

> you should not be writing comments criticizing other
> peoples' writing.

I would never comment on sombodies general spelling. Mine is bad enough.
Only in this case it was the spelling of what we here call an "Eigenname".
A name which starts in englich with a capital letter.

Also, if you never read enough about Ada to know how it is spelled, how do
you know enough about its features.

Did you know about:

type Month is new Integer range 1 .. 12;
for Month'Size is 8;

and how will you do it in C?

Use an unsigned short int. Well an short int is usualy 16 bit not 8.

Use an unsigned char? Well it is 8 bit - but is is a character not a number.

If you are lucky you have real C99 compiler with byte. But byte is still
0 .. 255 wich is more the 20 times range needed. That means - in savety
critical software - you have to "assert" the value before using it.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Certified C compilers for safety-critical embedded systems

[Ian Bell]

James Rogers wrote:

snip
> 
> type my_index is range 0..9;
> type My_Array_Type is array(my_index) of integer;
> 
> foo : My_Array_Type;
> 
> for num in 0..99 loop
>    foo(num) := num;
> end loop;
> 
> All Ada compilers will correctly identify the error in the for loop.
> The type of "num" is not the same as the type of the index, because
> the range of values defined for "num" are not all within the range of
> values in my_index. This detection will happen properly no matter how
> far the definition is separated from the "for" loop.
> 

I know nothing about ada so this is a genuine query rather than a ctiticism. 
The above example is fine as long as literals are used - even a C compiler
could be devised to make this check - but what happens when the array index
is computed?

Ian

Re: Certified C compilers for safety-critical embedded systems

[Frank J. Lhota]

"James Rogers" <jimmaureenrogers@att.net> wrote in message
news:Xns945DE49836882jimmaureenrogers@204.127.36.1...
> The C standard explicitly permits accessing one element beyond the end
> of an array.

Careful! All that the standard guarantees is that the address of the one
element beyond the should compare in the expected fashion with the addresses
of the other array elements. For example, if we have

    int foo[10];
    int* bar = foo + 10;

then the C standard will guarantee that

    bar > foo + i

for any i in the range 0 .. 9 inclusive. Although the standard guarantees
the behavior of a pointer one past the end of an array, it explicitly does
NOT guarantee anything about accessing an element past the end of an array.
An attempt to read or write *bar leads to unpredictable results.

> Neither the C compiler nor lint can determine if an array
> index is outside the bounds of the array.

It depends. I would imagine that some C compilers and lint might catch
something like this:

    int foo[10];
    ...
    j = foo[10];

The real problem is that once an array is passed to a function, length
information is lost. This is one area where the C++ vector template made a
real advance. Of course, Ada had the approach to arrays all along, in that
it never divorced the length from the array data.

Re: Certified C compilers for safety-critical embedded systems

[Chris Hills]

In article <aA4Hb.15723$Fg.396@lakeread01>, David Emery <demery@cox.net>
writes
>Several people have asserted the argument that the large
>number of users of a given tool implies quality in that tool.
>
>I don't buy it.  By this logic, MS Windows should be
>absolutely flawproof, and the infamous Pentium Divide bug
>should never have happened.

We are in comp.arch.embedded...... Ms Desktop tools are not relevant.
Besides AFAIK their license excludes any safety critical use.

>No amount of usage can make up for design flaws.  Popularity
>is much less about technical qualities than it is about
>marketing.  C, Windows, x86 chips have substantial market
>share, which is not the same as saying that they have
>substantial quality by design.

Correct for the desktop tools but among *Embedded* tools it does
especially where the aim is to go for the high reliability market. 

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Certified C compilers for safety-critical embedded systems

[Simon Wright]

Ian Bell <ian@ruffrecordsDOTworldonline.co.uk> writes:

> James Rogers wrote:
> 
> snip
> > 
> > type my_index is range 0..9;
> > type My_Array_Type is array(my_index) of integer;
> > 
> > foo : My_Array_Type;
> > 
> > for num in 0..99 loop
> >    foo(num) := num;
> > end loop;
> > 
> > All Ada compilers will correctly identify the error in the for
> > loop.  The type of "num" is not the same as the type of the index,
> > because the range of values defined for "num" are not all within
> > the range of values in my_index. This detection will happen
> > properly no matter how far the definition is separated from the
> > "for" loop.
> 
> I know nothing about ada so this is a genuine query rather than a
> ctiticism.  The above example is fine as long as literals are used -
> even a C compiler could be devised to make this check - but what
> happens when the array index is computed?

You mean as in

  type my_index is range 0 .. some_variable;

-- yes, Ada compilers will perform the check.

Actually the code wasn't actually compiled by whoever posted it, a
crime on c.l.a: you either have to say

  for Num in 0 .. 99 loop
     Foo (My_Index (Num)) := Num;
  end loop;

(which GNAT doesn't see as a problem until execution time) or 

   for Num in My_Index range 0 .. 99 loop
      Foo (Num) := Integer (Num);
   end loop;

to which GNAT says

constraints.adb:10:35: warning: static value out of range of type "My_Index" defined at line 3
constraints.adb:10:35: warning: "Constraint_Error" will be raised at run time

(this is the "99").

Re: Certified C compilers for safety-critical embedded systems

[Georg Bauhaus]

In comp.lang.ada Ian Bell <ian@ruffrecordsdotworldonline.co.uk> wrote:
:James Rogers> foo : My_Array_Type;
:> 
:> for num in 0..99 loop
:>    foo(num) := num;
:> end loop;
:> 
:> All Ada compilers will correctly identify the error in the for loop.
:> [...]
: 
: I know nothing about ada so this is a genuine query rather than a ctiticism. 
: The above example is fine as long as literals are used - even a C compiler
: could be devised to make this check - but what happens when the array index
: is computed?

Wouldn't that become a famous compiler that finds out, at compile
time, which value a certain variable is going to have? :-)

If you want a hole in your foot, you can make one, though it might
not be easy:

with Interfaces;
with Ada.Integer_Text_IO; use Ada;

procedure t is
   --  read a positive value from standard input and create an
   -- array of that size, which is filled (hopping excessively)

   procedure rubber_buffer(limit: Positive) is

      subtype Index is Positive range 1 .. limit;
      -- a range constraint on Positive, determined at call time

      buffer: array(Index) of Interfaces.Unsigned_8;
      -- storage for 1 .. limit 8bit quantities

   begin
      --  demonstration of constraint_error

      off_buffer:  -- k grows too large for a buffer index

          for k in Index'first .. 2 * Index'last loop
             buffer(k) := 42;  -- index check failed, at run time
          end loop off_buffer;

      off_index_range:  -- k gets too large for Index subtype's range

          for
            k in Index'first .. Index(2 * Index'last)
                                --  range check failed, at run time
          loop
             buffer(k) := 42;
          end loop off_index_range;

   end rubber_buffer;

   n: Positive;
   --  upper limit of 1-based buffer, read at run time

begin
   Integer_Text_IO.get(n);
   rubber_buffer(n);
end t;


That's why language-defined array constructs such as
the 'range attribute are useful. You can write

  for k in buffer'range loop
     buffer(k) := 42;
  end loop;

(or in this case more simply, using language defined `others'

  buffer := (others => 42);)

no matter what the buffer's index range currently is.


-- Georg

Re: Certified C compilers for safety-critical embedded systems

[Ian Bell]

Simon Wright wrote:

> Ian Bell <ian@ruffrecordsDOTworldonline.co.uk> writes:
> 
>> James Rogers wrote:
>> 
>> snip
>> > 
>> > type my_index is range 0..9;
>> > type My_Array_Type is array(my_index) of integer;
>> > 
>> > foo : My_Array_Type;
>> > 
>> > for num in 0..99 loop
>> >    foo(num) := num;
>> > end loop;
>> > 
>> > All Ada compilers will correctly identify the error in the for
>> > loop.  The type of "num" is not the same as the type of the index,
>> > because the range of values defined for "num" are not all within
>> > the range of values in my_index. This detection will happen
>> > properly no matter how far the definition is separated from the
>> > "for" loop.
>> 
>> I know nothing about ada so this is a genuine query rather than a
>> ctiticism.  The above example is fine as long as literals are used -
>> even a C compiler could be devised to make this check - but what
>> happens when the array index is computed?
> 
> You mean as in
> 
>   type my_index is range 0 .. some_variable;
> 
> -- yes, Ada compilers will perform the check.
> 

That was not what I had in mind and seems to me to be rather dodgy code.  i
was thinking more of the return value of some function being used as an
index to the array.

Ian

Re: Certified C compilers for safety-critical embedded systems

[Ian Bell]

Georg Bauhaus wrote:

> In comp.lang.ada Ian Bell <ian@ruffrecordsdotworldonline.co.uk> wrote:
> :James Rogers> foo : My_Array_Type;
> :> 
> :> for num in 0..99 loop
> :>    foo(num) := num;
> :> end loop;
> :> 
> :> All Ada compilers will correctly identify the error in the for loop.
> :> [...]
> : 
> : I know nothing about ada so this is a genuine query rather than a
> : ctiticism. The above example is fine as long as literals are used - even
> : a C compiler could be devised to make this check - but what happens when
> : the array index is computed?
> 
> Wouldn't that become a famous compiler that finds out, at compile
> time, which value a certain variable is going to have? :-)
> 

Ah, so Ada is no better than C in that respect?

Ian

Re: Certified C compilers for safety-critical embedded systems

[Jeff C,]

"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:bskd67$6me$1@a1-hrz.uni-duisburg.de...
> In comp.lang.ada Ian Bell <ian@ruffrecordsdotworldonline.co.uk> wrote:
> :James Rogers> foo : My_Array_Type;
> :>
> :> for num in 0..99 loop
> :>    foo(num) := num;
> :> end loop;
> :>
> :> All Ada compilers will correctly identify the error in the for loop.
> :> [...]
> :
> : I know nothing about ada so this is a genuine query rather than a
ctiticism.
> : The above example is fine as long as literals are used - even a C
compiler
> : could be devised to make this check - but what happens when the array
index
> : is computed?
>
> Wouldn't that become a famous compiler that finds out, at compile
> time, which value a certain variable is going to have? :-)
>
> If you want a hole in your foot, you can make one, though it might
> not be easy:


Again, tools like this do exist. One can argue over how well they work but
they do exist.
Tools like Polyspace Verifier can at times tell you statically that you have
a problem in your code.

For example the following psuedo code fragment would likely be flagged as a
potential error by polyspace

A, b : float;
C : integer;
D : array(1 .. 10) of float;

begin
 A := random_float;
 B := cos(a);
 C := integer(C * 9.0) + 1;
  D(C) := 0;
end;


while code like


A, b : float;
C : integer;
D : array(1 .. 10) of float;

begin
 A := random_float;
 B := cos(a);
 C := integer(C * 9.0) + 1;
  if C >= D'first and C <= D'last then
    D(C) := 0;
  end if;
end;


Would not generate an error during static analysis. (at least not for the
obvious error I intended to introduce in the first case ... :)

These tools exist now and have existed for some years.

Re: Certified C compilers for safety-critical embedded systems

[Larry Kilgallen]

In article <z+se8hAfAb7$EAYZ@phaedsys.demon.co.uk>, Chris Hills <chris@phaedsys.org> writes:

> We are in comp.arch.embedded...... Ms Desktop tools are not relevant.

Some of us are in comp.lang.ada.

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Ian Bell wrote:

> Ah, so Ada is no better than C in that respect?

No, Ada is much better than C in that respect.  The concept that Ada 
supports but C doesn't is best expressed described by example:

function Identity(N: Positive) return Matrix is
   Result: Matrix(1..N, 1..N) := (others => (others => 0.0));
begin
   for I in Matrix(1)'Range loop
     Result(I,I) := 1.0;
   end loop;
   return Result;
end Identity;

The size of the matrix returned will often be determined at run-time, 
but both the compiler and any static checking tools can verify that 
there are no potential out-of-range assignments here. This sort of 
"statically matching" constraints, where the constraints are dynamic but 
can be statically determined to be identical is formalized in RM 4.9.1. 
  There are certain cases in Ada where statically matching subtypes are 
required, but in general Ada programmers tend to use statically matching 
subtypes even where they are not required.  It not only makes for more 
efficient code, since the compiler can remove constraint checks, but it 
means that if the code is changed elsewhere, the change does not need to 
be propagated.  This makes code maintenance much easier.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Stephen Leake wrote:

> The version of Ada most likely to run on 8 bit machines would have no
> tasking, no exceptions, and possibly no floating or fixed point, or
> dynamic dispatching. That would still be a far better language than C!
> Packages, generics, strong typing in general, aggregates,
> representation clauses; none of these make demands on the run-time
> environment, but all are very powerful programming language features.

Actually, there is no reason not to support fixed-point, although I 
probably wouldn't support decimal types.  There is no reason to omit 
exceptions, but I might not support exception occurances (RM 11.4.1). 
And again there is no reason not to support dynamic dispatching, but I 
would certainly limit the number of tasks and the size of task stacks.

But the key question is, "Does the compiler pass all the validation 
tests that I care about?"  This is what the VSR really addresses.  Right 
now it is normal for a validation to list hundreds of tests as 
"non-applicable."  Of course, most of these are for floating-point with 
digits > 14.

Having said all that, I can't really get excited about validating Ada 
compilers for the i8051 or for that matter the Z-80.  Every time I have 
used a chip that "small" on a project, complete test coverage of the 
machine code was not that hard to do.  Typically the chip implements a 
finite-state machine with at most a couple of dozen states, and it is 
easier to tie the generated code to the state diagram in the 
specification than to prove both the source code and the compiler.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Georg Bauhaus]

In comp.lang.ada Ian Bell <ian@ruffrecordsdotworldonline.co.uk> wrote:
:> Wouldn't that become a famous compiler that finds out, at compile
:> time, which value a certain variable is going to have? :-)
:> 
: 
: Ah, so Ada is no better than C in that respect?

In the dynamic Matrix example by R. Eachus a number of dynamic things
can indeed be statically studied, it seems. This implies there is a
measure for how much can be "found out" at compile time, given the
features of language X.  (In the above sentence I was only trying to
say that there is _no_ real world compiler that can possibly solve
the general problem of finding variables' values at runtime, for some
program in any programming language, given some input :-) But that is
not relevant here I think.)

Splint is an indicator too.  Considering maxSet/maxRead (array bounds, at
least some), require/ensure (Eiffel contracts), modifies (in, out, in out
parameter modes), etc., I suddenly feel very much at home in the language
that tries to look like C, though not quite.
Splint programs can only be translated by a compiler using the trick
of hiding the new language in C comments. I guess that the additional
information in the comments is then not available to the C compiler,
so the C compiler can only profit from users who try to redesign
their software, but it cannot itself profit from the comments...

Will there be profit if a true Splint compiler will evaluate
the additional information in the comments? Would the language
look like, well, not C, semantically? :-)


-- Georg

Re: Certified C compilers for safety-critical embedded systems

[Chris Hills]

In article <wp6gcQns6pRu@eisner.encompasserve.org>, Larry Kilgallen
<Kilgallen@SpamCop.net> writes
>In article <z+se8hAfAb7$EAYZ@phaedsys.demon.co.uk>, Chris Hills 
><chris@phaedsys.org> writes:
>
>> We are in comp.arch.embedded...... Ms Desktop tools are not relevant.
>
>Some of us are in comp.lang.ada.

Repent!
:-)
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Certified C compilers for safety-critical embedded systems

[Georg Bauhaus]

In comp.lang.ada Ian Bell <ian@ruffrecordsdotworldonline.co.uk> wrote:
:> You mean as in
:> 
:>   type my_index is range 0 .. some_variable;
:> 
:> -- yes, Ada compilers will perform the check.
:> 
: 
: That was not what I had in mind and seems to me to be rather dodgy code.  i
: was thinking more of the return value of some function being used as an
: index to the array.

That should depend on what the compiler can find out about the
function.  For example, if there is "type Index is range 0..359;",
then if a function is specified to return values of a constrained
subtype of Index ranging from 0..179, and a buffer has been allocated for
some Index subtype's values ranging from 180..359, the compiler will
warn if you use the function's values as indices to the array,
_although_ in C terms the array index values and the function return
values are indistinguishable (both unsigned shorts for example).
I.e.
   type Index is range 0..359;
   subtype First_Half is Index range 0..179;
   subtype Second_Half is Index range 180..359;

   buffer: array(First_Half) of Some_Decimal_Type;

   function some_val return Second_Half;
   --  Second_Half values at random

...

    27.    if buffer(some_val) > 10.0 then
                     |
        >>> warning: value not in range of type "First_Half" defined at line 6
        >>> warning: "Constraint_Error" will be raised at run time

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Alan Balmer wrote:

> That seems obvious. It's possible to write a C program with *no*
> residual errors. It may be easier to write a SPARK program with no
> residual errors, but there's no law that says C programs have to have
> more errors.

But is it possible to write a C program and an Ada program which 
implement the same algorithm with no residual errors?

My experience indicates that it is not.  This is not saying that you 
can't build an Ada to C translator, or a C to Ada translator, although 
the first has been done several times, and the second would be much 
harder.  The problem is that if I have a C program "in hand" and go to 
translate it into Ada, there are usually hundreds of questions that I 
end up asking.  Some of them may be answered in the specificiation for 
the C program--assuming that such a specification exists.

The net result is that even if I start out to write identical programs 
in C and Ada, the Ada program ends up much more tightly specified. 
Whether these additional specifications are meaningful in terms of the 
intent of the program, or are just "accidental" overspecification due to 
the fact that Ada asks the question and it is easier to answer it than 
dodge it, the Ada and C programs implement two different specifications. 
  (Or to be formal, the set of specifications that the C program 
satisfies will normally be a superset of those satisfied by the 
"equivalent" Ada program.)

Does this make the C program better?  I don't think so.  I am much more 
concerned that set of specifications satisfied includes the "real" 
specification, which often includes requirements omitted from the 
original written specification.  Ada does a much better job of 
identifying these implicit requirements and getting them formalized.

The best example of this problem doesn't involve Ada at all.  The French 
developed a programming language used for the Airbus A320, and it took 5 
crashes for omissions in the specification to be identified and fixed.

One problem was that the autopilot would maintain a specified hight 
above ground between waypoints until the last waypoint before landing. 
Then it would put the plane into the glidepath for the destination 
runway.  The problem occurred when the last waypoint set was not in the 
glide path, the 'correction' that occurred when the waypoint was passed 
could result in a stall, or in the case of a landing in mountainous 
territory diving to the glide path which was underground at the last way 
point.

Airbus originally diagnosed the cause of the crashes as the pilots 
selecting the 'wrong' descent mode.  But as I said, it was not pilot 
error, but a missing specification.  The glide path for the runway was 
assumed to be everywhere above ground.  More correctly it was assumed 
that the last waypoint would be the outer beacon for the intended 
runway.  But there are cases where that is not possible, and in those 
cases, the A320 could be deadly. And in the crash which resulted in the 
problem being detected, the outer marker beacon was situated on a 
mountain which extended into the glide path.

As far as I am concerned Airbus's contribution to the analysis of a 
crash near Strasbourg, France January 20, 1992 was criminal.  If you 
look at all the "weasel words" in retrospect, they knew that it couldn't 
have been the pilot error they suggested.  (Autopilot in wrong mode.) 
The "rapid" descent that left one second between the altitude warning 
and the crash was at over a 50% angle over descending terrain.  Somehow 
I don't think the flight crew "overlooked" the rapid descent--other than 
looking through the cockpit window below their feet.

As it was, it took two more crashes before an investigation concluded 
that at least two previous crashes, and probably all four were due to 
missing requirements in the specifications for the provably correct 
code.  For example, in the first crash at a French airshow, a lot of 
attention was focused on whether the engines spooled up "quick enough" 
when the crew selected abort/go around.  A later crash in Japan in a 
similar situation, but a "real" landing attempt showed that engine speed 
  wasn't the problem.  The Japanese plane didn't strike trees with its 
tail: "Finally, the engine stalled after the angle of ascent increased 
to 53 degrees, and the plane fell towards the ground, crashing 
tail-first."  As any pilot can tell you trying to increase altitude in 
any flight mode, but certainly when close to the ground, pulling the 
nose much above level is a deadly error. Beyond a certain AoA (angle of 
attack) the plane will slow down requiring more AoA (or throttle) to 
stay level. Go back and look at the first A320 crash, and it is clear 
that a human pilot would have not have increased the AoA to go around, 
and in (more) level flight the tail would not have hit the trees.

Sorry to spend so many electrons and photons on this, but it is an issue 
that should not be overlooked.  Formal proofs of correctness are 
worthless if the requirements are not complete.  I like a language that 
asks the questions that the specification forgot.
-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[CBFalconer]

James Rogers wrote:
> 
... snip ...
> 
> When reliability engineers encounter a system relying upon human
> actions the commonly accepted error rate, assuming properly trained
> humans, is 1 in 1000. Such an error rate is unacceptably low for
> most safety critical systems. An error rate of 1 in 1000 is a
> reliability rate of 0.999. Safety critical systems commonly
> require reliability rates on the order of 0.999999. This is
> three orders of magnitude higher than can be achieved through
> reliance on human correctness.

And even then, 1000 such 6 nines reliable systems together can be
expected to have a combined reliability of 0.999.  Now consider
the count of individual transistors in a moderately complex
processor.

There are two basic methods of improving the end product
reliability:  Improve the component reliability, and reduce the
number of components.  This argues heavily against using a Pentium
when a PIC will do.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

Re: Certified C compilers for safety-critical embedded systems

[Alexandre E. Kopilovitch]

I think that the following posting (of Robert I. Eachus) should be placed in
appropriate section of Ada-promoting websites, at least unofficial ones, such
as AdaPower and AdaWorld - because it is the best explanation of the Ada
adavantages at essentially popular level I ever seen. Yes, it may be enhanced
by correcting typos (I noticed at least one) and by making the explanations
of the crash cases slightly more detailed (perhaps providing simple pictures)
- not all readers have pilot experience or at least are regular readers of
Flying magazine; but even without those enhancements it is a very rare writing,
which can explain the matter for some people inlvolved into decision processes
about software - so it should be made easily accessible and referenced.


> Date: Sat, 27 Dec 2003 16:33:47 -0500
> From: "Robert I. Eachus" <rieachus@comcast.net>
> Subject: Re: Certified C compilers for safety-critical embedded systems
> To: comp.lang.ada@ada-france.org
> Message-ID: <0ridnTmiEKohZ3Ci4p2dnA@comcast.com>
>
> Alan Balmer wrote:
> 
> > That seems obvious. It's possible to write a C program with *no*
> > residual errors. It may be easier to write a SPARK program with no
> > residual errors, but there's no law that says C programs have to have
> > more errors.
> 
> But is it possible to write a C program and an Ada program which 
> implement the same algorithm with no residual errors?
> 
> My experience indicates that it is not.  This is not saying that you 
> can't build an Ada to C translator, or a C to Ada translator, although 
> the first has been done several times, and the second would be much 
> harder.  The problem is that if I have a C program "in hand" and go to 
> translate it into Ada, there are usually hundreds of questions that I 
> end up asking.  Some of them may be answered in the specificiation for 
> the C program--assuming that such a specification exists.
> 
> The net result is that even if I start out to write identical programs 
> in C and Ada, the Ada program ends up much more tightly specified. 
> Whether these additional specifications are meaningful in terms of the 
> intent of the program, or are just "accidental" overspecification due to 
> the fact that Ada asks the question and it is easier to answer it than 
> dodge it, the Ada and C programs implement two different specifications. 
>   (Or to be formal, the set of specifications that the C program 
> satisfies will normally be a superset of those satisfied by the 
> "equivalent" Ada program.)
> 
> Does this make the C program better?  I don't think so.  I am much more 
> concerned that set of specifications satisfied includes the "real" 
> specification, which often includes requirements omitted from the 
> original written specification.  Ada does a much better job of 
> identifying these implicit requirements and getting them formalized.
> 
> The best example of this problem doesn't involve Ada at all.  The French 
> developed a programming language used for the Airbus A320, and it took 5 
> crashes for omissions in the specification to be identified and fixed.
> 
> One problem was that the autopilot would maintain a specified hight 
> above ground between waypoints until the last waypoint before landing. 
> Then it would put the plane into the glidepath for the destination 
> runway.  The problem occurred when the last waypoint set was not in the 
> glide path, the 'correction' that occurred when the waypoint was passed 
> could result in a stall, or in the case of a landing in mountainous 
> territory diving to the glide path which was underground at the last way 
> point.
> 
> Airbus originally diagnosed the cause of the crashes as the pilots 
> selecting the 'wrong' descent mode.  But as I said, it was not pilot 
> error, but a missing specification.  The glide path for the runway was 
> assumed to be everywhere above ground.  More correctly it was assumed 
> that the last waypoint would be the outer beacon for the intended 
> runway.  But there are cases where that is not possible, and in those 
> cases, the A320 could be deadly. And in the crash which resulted in the 
> problem being detected, the outer marker beacon was situated on a 
> mountain which extended into the glide path.
> 
> As far as I am concerned Airbus's contribution to the analysis of a 
> crash near Strasbourg, France January 20, 1992 was criminal.  If you 
> look at all the "weasel words" in retrospect, they knew that it couldn't 
> have been the pilot error they suggested.  (Autopilot in wrong mode.) 
> The "rapid" descent that left one second between the altitude warning 
> and the crash was at over a 50% angle over descending terrain.  Somehow 
> I don't think the flight crew "overlooked" the rapid descent--other than 
> looking through the cockpit window below their feet.
> 
> As it was, it took two more crashes before an investigation concluded 
> that at least two previous crashes, and probably all four were due to 
> missing requirements in the specifications for the provably correct 
> code.  For example, in the first crash at a French airshow, a lot of 
> attention was focused on whether the engines spooled up "quick enough" 
> when the crew selected abort/go around.  A later crash in Japan in a 
> similar situation, but a "real" landing attempt showed that engine speed 
>   wasn't the problem.  The Japanese plane didn't strike trees with its 
> tail: "Finally, the engine stalled after the angle of ascent increased 
> to 53 degrees, and the plane fell towards the ground, crashing 
> tail-first."  As any pilot can tell you trying to increase altitude in 
> any flight mode, but certainly when close to the ground, pulling the 
> nose much above level is a deadly error. Beyond a certain AoA (angle of 
> attack) the plane will slow down requiring more AoA (or throttle) to 
> stay level. Go back and look at the first A320 crash, and it is clear 
> that a human pilot would have not have increased the AoA to go around, 
> and in (more) level flight the tail would not have hit the trees.
> 
> Sorry to spend so many electrons and photons on this, but it is an issue 
> that should not be overlooked.  Formal proofs of correctness are 
> worthless if the requirements are not complete.  I like a language that 
> asks the questions that the specification forgot.
> -- 
>                                            Robert I. Eachus
> 
> "The war on terror is a different kind of war, waged capture by capture, 
> cell by cell, and victory by victory. Our security is assured by our 
> perseverance and by our sure belief in the success of liberty." -- 
> George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Stephen Leake]

"Robert I. Eachus" <rieachus@comcast.net> writes:

> Stephen Leake wrote:
> 
> > The version of Ada most likely to run on 8 bit machines would have no
> > tasking, no exceptions, and possibly no floating or fixed point, or
> > dynamic dispatching. That would still be a far better language than C!
> > Packages, generics, strong typing in general, aggregates,
> > representation clauses; none of these make demands on the run-time
> > environment, but all are very powerful programming language features.
> 
> Actually, there is no reason not to support fixed-point, although I
> probably wouldn't support decimal types.  There is no reason to omit
> exceptions, but I might not support exception occurances (RM 11.4.1).

I was quoting the restrictions imposed by GNAT's undocumented 'pragma
No_Runtime', which is admittedly serving a somewhat different purpose.

The runtime support for fixed point is simple, but it is not zero.
Same for exceptions. Runtime support for "zero cost" exceptions is
more complex.

> And again there is no reason not to support dynamic dispatching, 

I don't know if pragma No_Runtime eliminates this; I never tried it
(since it's undocumented, the only way to discover if a feature is
prevented is to try it. Well, one could read the source.).

> <snip>
> Having said all that, I can't really get excited about validating Ada
> compilers for the i8051 or for that matter the Z-80.  Every time I
> have used a chip that "small" on a project, complete test coverage of
> the machine code was not that hard to do.  Typically the chip
> implements a finite-state machine with at most a couple of dozen
> states, and it is easier to tie the generated code to the state
> diagram in the specification than to prove both the source code and
> the compiler.

Right. That's the approach I would take; test the application code
thoroughly, so you find any compiler bugs.

-- 
-- Stephe

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Alexandre E. Kopilovitch wrote:
> I think that the following posting (of Robert I. Eachus) should be placed in
> appropriate section of Ada-promoting websites, at least unofficial ones, such
> as AdaPower and AdaWorld - because it is the best explanation of the Ada
> adavantages at essentially popular level I ever seen. Yes, it may be enhanced
> by correcting typos (I noticed at least one) and by making the explanations
> of the crash cases slightly more detailed (perhaps providing simple pictures)
> - not all readers have pilot experience or at least are regular readers of
> Flying magazine; but even without those enhancements it is a very rare writing,
> which can explain the matter for some people inlvolved into decision processes
> about software - so it should be made easily accessible and referenced.

I'm glad you like it, but as you said, it needs some work.  What I 
realized I left out after I posted it was an explanation of the "Cobra 
Dance" crashes of F-104s.  This involved the same thing that happened in 
the two go-around crashes.  With the F-104 you could get "under the 
power curve" and more power to the engines increased the AoA in spite of 
any control inputs from the pilot.  The state usually occurred on a 
landing approach, but no one survived to explain what happened.  Finally 
one pilot realized he was going into a cobra dance and decided to kill 
all electrical power (including fuel pumps) so that he would have a 
chance to avoid the fatal fire (no zero altitude ejection seats back 
then--and regained control of the aircraft.

The effect was nowhere near as bad in the A320.  But setting the control 
mode to take-off/go-around spooled up the engines without checking the AoA.

Incidently I have no real clue as to whether programming the A320 in Ada 
would have caught this problem.  It would have been much more likely to 
catch the glide path problem that occurred in the Strasbourg crash.  But 
in a way they were the same problem--cases where maximum limits should 
have been specified (on rate of descent and AoA).  In Ada, of course, 
you would tend to ask what the limit on the commanded rate of descent by 
the autopilot should be when the aircraft was above the glide path on 
landing--and that would lead to lots of meetings to figure out the 
answer.  In fact, the original "probable cause" for the Strasbourg crash 
was pilot error.  Airbus figured that the aircrew must have set the 
autopilot descent rate incorrectly.  It turned out later that, once the 
last waypoint was cleared, that setting was ignored.

Hmm.  The code was not as bad as that seems to suggest.  If the aircraft 
was in the glide path, but too high, the setting was obeyed.  If the 
aircraft was outside the glide path the limits were ignored.  That is 
probably not a wrong choice--if the aircraft is already in the glide 
path when you enter the mode. (For example, if flying through a 
microburst, do you want to limit the potential actions if the plane is 
being taken entirely out of the glide path?  Definitely not on the low 
side.  On the high side, say a sudden headwind?  I might prefer abort/go 
around to precipitous action.) In the Strasbourg crash the pilot was on 
approach to one runway, then was directed to land on another.  His last 
set waypoint was fine for the first runway, deadly for the second, and 
the plane was probably unrecoverable before the crew had a clue that 
there was a problem.

If you need to visualize it, the plane was instructed to approach the 
runway from the side, then turn into the glide path inside the outer 
marker.  Not a landing pilots like, but better than take-offs where you 
have to turn immediately.  However when the flight control system 
started "flying the glide path," it thought it was way too high, off to 
the side, and on the wrong heading.  It tried to fix all three 
"problems" immediately.

The AoA case is more difficult because the actual AoA is not something 
where you want the software to crash (or cause an exception) if the AoA 
is out of reasonable bounds.  However, it is hard to imagine someone 
familar with the domain--flight control systems--letting through go 
around code that ignored the AoA. The reason it apparently got through 
shows in the name of the mode: take off/go around.  It would not seem 
strange to ignore the AoA when spooling the engines up to take-off.

Is that what happened?  I don't know for sure, and I don't think anyone 
does.  All we have are recollections years afterwards that the formal 
specifications were very opaque to anyone not familiar with formal logic 
and programming, and that there were some problems validating the 
specifications for that reason.

This, incidently, is one of the reasons why I always say that in Ada, 
the right approach is not to model the solution space, but to model the 
problem space.  That way the requirements are easy to trace, implement, 
verify, and if necessary modify, in terms meaningful to domain experts.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Mike Silva]

Chris Hills <chris@phaedsys.org> wrote in message news:<W4TqREA2bf7$EA9g@phaedsys.demon.co.uk>...
> In article <wp6gcQns6pRu@eisner.encompasserve.org>, Larry Kilgallen
> <Kilgallen@SpamCop.net> writes
> >In article <z+se8hAfAb7$EAYZ@phaedsys.demon.co.uk>, Chris Hills 
> ><chris@phaedsys.org> writes:
> >
> >> We are in comp.arch.embedded...... Ms Desktop tools are not relevant.
> >
> >Some of us are in comp.lang.ada.
> 
> Repent!

How do you think I got *into* comp.lang.ada?!

> :-)

Me too!

Re: Certified C compilers for safety-critical embedded systems

[Peter Amey]

Mike Silva wrote:
[snip]
>>>
>>>http://www.sparkada.com/downloads/Mar2002Amey.pdf
>>
>>An interesting article, though not for the residual error reduction
>>references, which are simply quotes of claims made by Lockheed, with
>>no background. 
> 
> 
> Just to clarify, the error reduction claims I was referring to were
> those cited from a UK MoD study done by Aerosystems International. 
> I'd like to be able to find that study, or a fuller summary, on line.
> 
> Mike

The study was only fully reported at a private MoD briefing.  The 
nearest thing to a public version is in a recent article by Andy German 
(of Qinetiq) in a recent issue of Crosstalk.  The Andy German paper 
covers experiencess of static analysis of a large number of air systems 
and shows similar (but not quite so extreme) trends to the C130J figures.

Peter

Re: Certified C compilers for safety-critical embedded systems

[Peter Amey]

I would much rather concentrate on technical issues here (for example, 
why deep static analysis of _any_ general-purpose langauge is 
impossible; or, why systems of integrities in the better-than 10e-6 
failures per hour class _require_ deep static analysis); however, I 
can't let Chris Hill's petulent little rant below pass unchallenged!

Chris Hills wrote:
> In article <20619edc.0312222106.3b369547@posting.google.com>, Mike Silva
> <snarflemike@yahoo.com> writes
> 
>>Some more interesting reading (note that MISRA acknowledges that there
>>are better languages than C for safety-critical work):
> 
> 
> That will change. 
> 
> 
>>http://www.sparkada.com/downloads/misracatsil4reader.pdf
> 
> 
> Praxis has a vested interest in not letting C be used for SIL 4

Praxis has a long-held commitment to using the best technology available 
and to advancing the state of the software industry as a whole.  Our 
objection to using C for SIL 4 is that it is unsuited to that task.  The 
majority of the proponents of the use of C in this role are C tool 
vendors; are they too governed only by vested interest?

> 
> BTW 
> slide 3 is erroneous.
> slide 5 is also erroneous.
> 

> AFAIK Praxis are not "involved" with MISRA-C they may have been some
> years ago in the original version but much work has been done since
> then. AFAIK they have not taken much, if any part, in this.
> 

Neither slide is erroneous. They are clearly dated 2002 and are factually
correct for that date.  We had two members on the original MISRA-C 
committee
and attended every workshop and committee meeting until the beginning of
this year.  We still monitor the mailing list and will contribute again 
when
we have something to say.

> AFAIK they did not make their SPADE C results available to the MISRA-C
> working group who for the last 3 years have been working on MISRA-C2.

Wrong.  We did.  Unfortunately the rather stern view we took of what was 
needed to make C fully-analyseable (basically, a Pascal subset in C 
syntax) was not seen as being compatible with the apparent aim of the 
comittee: as much C as possible with the minimal restrictions needed to 
plug the biggest holes.

> 
> Praxis don't have a unique view of MISRA-C.  They are one of many who
> were involved in MISRA-C1. They are not one of the main companies who
> were promoting and working with it in the last 5 years.

The slide clearly states that this is Rod's personal view and he (with 
appalling semantics) qualifies the "unique" with "almost".  I think is 
is at least defensible to say that Praxis's experience as: implementors 
of world class critical systems, language designers; and tool vendors 
_does_ give us a different (even unique) perspective from most other 
contributors none of which (AFAIK) has done _all_ of these things.

> 
> Slide 6 is interesting. The quotes are out of context and misleading.
> The Praxis presentation is clearly written with a (commercial) axe to
> grind. I was at the MISRA-C 2002 forum. In fact I did one of the
> presentations that has been misquoted.... 

Perhaps you can recall the context in which Less Hatton's shack/swamp 
comment can be interpreted in a positive way?

> 
> As it goes on they rubbish C and surprise surprise come up with a
> solution that is their tools.... :-) 

We don't rubbish C.  We rubbish magic where logic is to be preferred. 
We have well-articulated reasons for saying that C is not well suited 
for constructing high-integrity systems.  The proponents of C for this 
purpose never seem to present their reasons.  All we ever hear are: 
"there are lots of C programmers around"; "we only ever employ the best 
people and they don't make those kinds of mistakes"; and, the falsehood, 
"C, with suitable support tools, is as good as anything else".

We don't take this view because we have alternative tools, we have 
alternative tools because we take this view!

> 
> The Ada (tools) community must be rattled if it needs to spend time
> trying to rubbish MISRA-C. Perhaps it is just sour grapes as they no
> longer push a MISRA-C tool? 

Again we are not trying to rubbish MISRA-C.  We continue to believe that 
  it is useful enterprise.  If people want to use C for smaller, 
safety-related systems then having a widely-supported coding standard is 
a "good thing".  We will continue to rubbish the promotion of that 
coding standard to application domains for which it unsuitable.

We no longer promote a MISRA-C tool because the widely-differing 
behaviour of our and competing tools and the high level of ambiguity in 
the MISRA-C rules showed that the market was too immature for tools 
claiming to enforce MISRA-C compliance.  We preferred, in that 
situation, to say nothing rather than make claims that could not be 
defended by logic and by reasoned argument.  I hope that MISRA-C2 will 
be  better; however, my long experience of designing unambiguous and 
analyseable programming languages leads me to believe that it won't.

> 
> Since the 2002 meeting MISRA-C2 has been reviewed by the SAE and JSAE
> several major automotive companies, aerospace companies, also  members
> of WG14 the ISO-C panel and met with approval. MISRA-C2 will be
> available at the end of Q1 2004
> 
> 
> 
>>This document has a table of language recommendations (search for
>>"Language Recommendations (IEC 1508)" ).  C is only recommended for
>>SIL1, while it is not recommended for SIL3 and SIL4:
>>
>>https://www.cis.strath.ac.uk/teaching/ug/classes/52.422/programming.languages.do
> 
> 
> Yet  C is used in some of the highest integrity systems around. Other
> languages that are recommended hardly exist and certainly not on many
> platforms.
> 
> Empirical evidence and a glance at 61508 may require a change in the
> table D2.... BTW table D2 in the lecturers notes is NOT in 61598.
> 
> In CEI/IEC 61508:1998 Part 7 Table C1 (page 79), yes I do have my own
> copy of 61508, all 7 parts. We find a similar table to "D2" above:
> 
>             Sil1   Sil2   Sil3 Sil4
> Ada          HR    HR      R    R
> ADA (subset) HR    HR      HR   HR
> C            R     -      NR    NR
> 
> as expected  BUT
> 
> C (subset, codinng standard and static analysis) 
>              HR   HR      HR     HR
> 
> 
> So whilst straight ADA *is* better than vanilla C. No one would debate
> that!  Spark ADA is no better than C with a subset, coding standard and
> using static analysis....  IE much the same constraints as SPARK ADA has
> over ADA...

Fundamental misconception.  SPARK is wholly unambiguous and therefore 
analyseable in a formal and mathematical sense.  An un-annotated subset 
of C _cannot_ have this property.  Analysis of such a language can, 
therefore, ony result in the _detection_ of certain kinds of error, it 
cannot _prove_ that they have been eliminated.

> 
> I know of projects using C in Railway, space, aero and medical projects.

Use, even widespread use, does not imply suitability.

> 
> PASCAL and Mod2 are mentioned but you will be hard pressed to find tool
> for these for many targets. BTW is there ADA for the PIC, AVR and 8015?
> 

Agreed.  Modula-2, in particular, was a nice language from which a 
secure, SPARK-like sublanguage could have been constructed.  Pity it, 
unlike Ada, never achieved critical mass.

> I come back to my comment previously that the ADA tools vendors must be
> worried if they are spending this much effort trying to rubbish MISRA-C
> which is an automotive guide.  Though it has gained widespread use
> outside the automotive industry due to those involved with it.
> 

I have pooh-poohed this pooh-poohing enough already!

> 
> Regards
>         Chris
> 

have a Happy New Year


Peter

Re: Certified C compilers for safety-critical embedded systems

[Chris Hills]

In article <bsm4hq$ea20f$1@ID-69815.news.uni-berlin.de>, Peter Amey
<peter.amey@praxis-cs.co.uk> writes
>
>
>Mike Silva wrote:
>[snip]
>>>>
>>>>http://www.sparkada.com/downloads/Mar2002Amey.pdf
>>>
>>>An interesting article, though not for the residual error reduction
>>>references, which are simply quotes of claims made by Lockheed, with
>>>no background. 
>> 
>> 
>> Just to clarify, the error reduction claims I was referring to were
>> those cited from a UK MoD study done by Aerosystems International. 
>> I'd like to be able to find that study, or a fuller summary, on line.
>> 
>> Mike
>
>The study was only fully reported at a private MoD briefing.  The 
>nearest thing to a public version is in a recent article by Andy German 
>(of Qinetiq) in a recent issue of Crosstalk.  The Andy German paper 
>covers experiencess of static analysis of a large number of air systems 
>and shows similar (but not quite so extreme) trends to the C130J figures.
>
>Peter
>
Hi Peter,

I have just downloaded your paper. Interesting and well worth reading. 

Regards
        Chris


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Certified C compilers for safety-critical embedded systems

[Chris Hills]

In article <bsmagl$e5ajv$1@ID-69815.news.uni-berlin.de>, Peter Amey
<peter.amey@praxis-cs.co.uk> writes
>
>I would much rather concentrate on technical issues here 
OK

>(for example, 
>why deep static analysis of _any_ general-purpose langauge is 
>impossible; 

Interesting.... can you explain? Perhaps as a separate thread? 

>or, why systems of integrities in the better-than 10e-6 
>failures per hour class _require_ deep static analysis); 

Is that a contradiction or do you mean that you need static analysis but
it can never be 100%? 

>> Praxis has a vested interest in not letting C be used for SIL 4
>
>Praxis has a long-held commitment to using the best technology available 
>and to advancing the state of the software industry as a whole. 
That's got to be from the marketing dept :-)


> Our 
>objection to using C for SIL 4 is that it is unsuited to that task.
On its own I would agree. 

>  The 
>majority of the proponents of the use of C in this role are C tool 
>vendors; are they too governed only by vested interest?

Good point. However you could argue the same for Ada hence the
development of Spark Ada. I think that all that is happening is that
there is (thank god) a realisation that unfettered C *IS* dangerous and
it should be used with various tools not least a static analyser. Who
would buy a word processor these days that does not have a spell
chequer?

>> AFAIK Praxis are not "involved" with MISRA-C they may have been some
>> years ago in the original version but much work has been done since
>> then. AFAIK they have not taken much, if any part, in this.
>Neither slide is erroneous. They are clearly dated 2002 and are factually
>correct for that date.  We had two members on the original MISRA-C 
>committee
The original committee stopped along while ago. 

>and attended every workshop and committee meeting until the beginning of
>this year.  
>We still monitor the mailing list and will contribute again 
>when
>we have something to say.

That explains why I have not seen any one from Praxis in the last year
or two. 


>> AFAIK they did not make their SPADE C results available to the MISRA-C
>> working group who for the last 3 years have been working on MISRA-C2.
>
>Wrong.  We did. 

Can you send it to me? It would be useful to go over it (again?) before
we lock down C2

> Unfortunately the rather stern view we took of what was 
>needed to make C fully-analyseable (basically, a Pascal subset in C 
>syntax) was not seen as being compatible with the apparent aim of the 
>comittee: as much C as possible with the minimal restrictions needed to 
>plug the biggest holes.

Yes. We have to work with the language we have.  Also the view was taken
(generally) that if we went from C to (almost) Pascal in one go we would
loose the audience.  MISRA-C1 was so successful because it was user
friendly. A LOT of companies are using it. Their C has improved....
MISRA-C2 is a step further. Hopefully all the current MISRA users will
move to it.  MISRA-C3 will be another step forward.

You don't run a marathon by running 26 miles on day one of training.

>> Praxis don't have a unique view of MISRA-C.  They are one of many who
>> were involved in MISRA-C1. They are not one of the main companies who
>> were promoting and working with it in the last 5 years.
>
>The slide clearly states that this is Rod's personal view and he (with 
>appalling semantics)

Whereas mine English is perrfek :-) 

> qualifies the "unique" with "almost".  I think is 
>is at least defensible to say that Praxis's experience as: implementors 
>of world class critical systems, language designers; and tool vendors 
>_does_ give us a different (even unique) perspective from most other 
>contributors none of which (AFAIK) has done _all_ of these things.

OK. Though there are others involved who would argue their corner...  IT
would make a fun discussion over a bottle of scotch one night but
probably not for public consumption.


>> Slide 6 is interesting. The quotes are out of context and misleading.
>> The Praxis presentation is clearly written with a (commercial) axe to
>> grind. I was at the MISRA-C 2002 forum. In fact I did one of the
>> presentations that has been misquoted.... 
>
>Perhaps you can recall the context in which Less Hatton's shack/swamp 
>comment can be interpreted in a positive way?

:-) 
I think he referring to C99  he has used that analogy at several ISO C
meetings. This is why  we are still working with C90 at the moment. 

>> As it goes on they rubbish C and surprise surprise come up with a
>> solution that is their tools.... :-) 
>
>We don't rubbish C.  We rubbish magic where logic is to be preferred. 
>We have well-articulated reasons for saying that C is not well suited 
>for constructing high-integrity systems.  The proponents of C for this 
>purpose never seem to present their reasons.  All we ever hear are: 
>"there are lots of C programmers around"; "we only ever employ the best 
>people and they don't make those kinds of mistakes"; and, the falsehood, 
>"C, with suitable support tools, is as good as anything else".
>
>We don't take this view because we have alternative tools, we have 
>alternative tools because we take this view!

Logical. I think part of the problem is that Ada is usually (always?)
taught in a high integrity context.  C is usually taught is an appalling
way.

I have had one lecturer tell me he taught C but used cin and cout in
strad of print and scanf as they were too difficult and anyway C was
simply a sub-set of C++....  (another candidate for a thread of it's own
:-)

>> The Ada (tools) community must be rattled if it needs to spend time
>> trying to rubbish MISRA-C. Perhaps it is just sour grapes as they no
>> longer push a MISRA-C tool? 
>
>Again we are not trying to rubbish MISRA-C.  We continue to believe that 
> it is useful enterprise.

Yes if they must use C at least we can improve the usage.

>  If people want to use C for smaller, 
>safety-related systems then having a widely-supported coding standard is 
>a "good thing".  We will continue to rubbish the promotion of that 
>coding standard to application domains for which it unsuitable.

Fair enough. 

>We no longer promote a MISRA-C tool because the widely-differing 
>behaviour of our and competing tools and the high level of ambiguity in 
>the MISRA-C rules showed that the market was too immature for tools 
>claiming to enforce MISRA-C compliance.  

That I can't disagree with. In fact part of my presentation at the 2002
MISRA forum was the problem that there is no MISRA-C certification of
tools anyone could interpret as they saw fit and claim what they like.
SOme claimed things there were not (in my view) supportable

>We preferred, in that 
>situation, to say nothing rather than make claims that could not be 
>defended by logic and by reasoned argument.  
Yes.. things have been made a little difficult by some of the claims...
"we test 100% of MISRA"*

*That is we test 100% of the rules we thing our tool can test.... :-(

>I hope that MISRA-C2 will 
>be  better; 

Hopefully. There are a few things in the pipeline that will be announced
in Feb/March

>however, my long experience of designing unambiguous and 
>analyseable programming languages leads me to believe that it won't.

It will be better. How much better we will have to see but anything that
improves the general level of embedded C programming has to be a Good
Thing (tm) 


>> Yet  C is used in some of the highest integrity systems around. Other
>> languages that are recommended hardly exist and certainly not on many
>> platforms.
>> 
>> Empirical evidence and a glance at 61508 may require a change in the
>> table D2.... BTW table D2 in the lecturers notes is NOT in 61598.
>> 
>> In CEI/IEC 61508:1998 Part 7 Table C1 (page 79), yes I do have my own
>> copy of 61508, all 7 parts. We find a similar table to "D2" above:
>> 
>>             Sil1   Sil2   Sil3 Sil4
>> Ada          HR    HR      R    R
>> ADA (subset) HR    HR      HR   HR
>> C            R     -      NR    NR
>> 
>> as expected  BUT
>> 
>> C (subset, codinng standard and static analysis) 
>>              HR   HR      HR     HR
>> 
>> 
>> So whilst straight ADA *is* better than vanilla C. No one would debate
>> that!  Spark ADA is no better than C with a subset, coding standard and
>> using static analysis....  IE much the same constraints as SPARK ADA has
>> over ADA...
>
>Fundamental misconception.  SPARK is wholly unambiguous and therefore 
>analyseable in a formal and mathematical sense.  An un-annotated subset 
>of C _cannot_ have this property.  Analysis of such a language can, 
>therefore, ony result in the _detection_ of certain kinds of error, it 
>cannot _prove_ that they have been eliminated.

Good point. 

>> I know of projects using C in Railway, space, aero and medical projects.
>Use, even widespread use, does not imply suitability.

The point was that C has been used successfully in these areas. At one
time it was said no HLL could be used in these areas. 


>> PASCAL and Mod2 are mentioned but you will be hard pressed to find tool
>> for these for many targets. BTW is there ADA for the PIC, AVR and 8015?
>Agreed.  Modula-2, in particular, was a nice language from which a 
>secure, SPARK-like sublanguage could have been constructed.  Pity it, 
>unlike Ada, never achieved critical mass.

I was once asked to set up a Modula2 system... in theory the language
was good but I discovered that the compiler had been written in x86
assembler, there was a most of a user manual but when I contacted the
company that wrote the compiler the programmer had left and they had no
design documentation, notes or bug fixes. No evidence of any testing
etc. 

In theory the language was good but the tools we had were not safe.

>I have pooh-poohed this pooh-poohing enough already!

Cue the Black Adder Goes Forth* sketch in what happens when you don't
pooh-pooh the pooh-pooh... (this will require a new NG not just a new
thread)

(Forth? even he had an opinion on languages)   


>have a Happy New Year
>Peter

Happy New Year? with you waiting to analyse every line of MISRA-C2... I
shall need tranquillisers :-)

BTW Re your Correctness by Construction: Better can also be cheaper...
Interesting reading. I also use the line "better is also cheaper" when
discussing C programming 

Regards & Happy New Year

Chris


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Certified C compilers for safety-critical embedded systems

[CBFalconer]

Peter Amey wrote:
> Chris Hills wrote:
> > <snarflemike@yahoo.com> writes
> >
> >> Some more interesting reading (note that MISRA acknowledges that
> >> there are better languages than C for safety-critical work):
> >
... snip ...
> 
> Wrong.  We did.  Unfortunately the rather stern view we took of
> what was needed to make C fully-analyseable (basically, a Pascal
> subset in C syntax) was not seen as being compatible with the
> apparent aim of the comittee: as much C as possible with the
> minimal restrictions needed to plug the biggest holes.

This may be just as well, since IMO part of the C problem is the
extreme reuse and terseness of tokens and the perverse precedence
rules.  

No language can be proof against errors, it can only supply extra
redundancy and increase the likelihood of detection at compile
time or detection at run time via appropriate checks. 
Unfortunately the latter will always require a means of
disablement, and the psychology of programmers is such that that
will be used unnecessarily.

> 
... snip ...
> 
> We don't rubbish C.  We rubbish magic where logic is to be
> preferred. We have well-articulated reasons for saying that C is
> not well suited for constructing high-integrity systems.  The
> proponents of C for this purpose never seem to present their
> reasons.  All we ever hear are: "there are lots of C programmers
> around"; "we only ever employ the best people and they don't
> make those kinds of mistakes"; and, the falsehood, "C, with
> suitable support tools, is as good as anything else".

Again, I consider splint annotatated C to be another language,
with an even more unnatural syntax.  Also, the best people DO make
those kinds of mistakes, and I present myself as evidence. 
Unfortunately many of the best programmers are somewhat sot in
their ways, and will reach for the C system as opposed to learning
an Ada or Pascal system, just as not too long ago they reached for
the assembler rather than learn Fortran, PL/I, Pascal, or C. 
Availability also has a hand in here.

I consider the ideal mixture for embedded systems to be a
combination of assembly, C, and Pascal.  The result can be trimmed
down to the abilities of highly incapable hardware, and yet can be
made mutually compatible.  I think (and I am willing to be
corrected) that Ada cannot be trimmed substantially and still be
Ada, and even if it can the extra verbiage will deter users.  

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

Re: Certified C compilers for safety-critical embedded systems

[Ed Falis]

On Sun, 28 Dec 2003 15:51:57 GMT, CBFalconer <cbfalconer@yahoo.com> wrote:


> I consider the ideal mixture for embedded systems to be a
> combination of assembly, C, and Pascal.  The result can be trimmed
> down to the abilities of highly incapable hardware, and yet can be
> made mutually compatible.  I think (and I am willing to be
> corrected) that Ada cannot be trimmed substantially and still be
> Ada, and even if it can the extra verbiage will deter users.
>

I think the subset of Ada used by SPARK is a good counter-example.  It's 
not the only one in use, since Ada provides pragmas that restrict 
functionality to achieve a higher level of determinism, or to 
reduce/remove the need for runtime library support.

- Ed

Re: Certified C compilers for safety-critical embedded systems

[Chris Hills]

In article <1563361.SfB03k3vvC@linux1.krischik.com>, Martin Krischik
<krischik@users.sourceforge.net> writes
>Hyman Rosen wrote:
>and how will you do it in C?
>
>Use an unsigned short int. Well an short int is usualy 16 bit not 8.
>
>Use an unsigned char? Well it is 8 bit - but is is a character not a number.

[plain] char is a character
singed and unsigned char are integer types.

>If you are lucky you have real C99 compiler with byte. 

there are no C99 compilers bar the (apparently) the Tasking Tricore
compiler.




/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Certified C compilers for safety-critical embedded systems

[Chad R. Meiners]

"Chris Hills" <chris@phaedsys.org> wrote in message
news:GawT1aBurv7$EA8G@phaedsys.demon.co.uk...
> In article <bsmagl$e5ajv$1@ID-69815.news.uni-berlin.de>, Peter Amey
> <peter.amey@praxis-cs.co.uk> writes
> >(for example,
> >why deep static analysis of _any_ general-purpose langauge is
> >impossible;
>
> Interesting.... can you explain? Perhaps as a separate thread?

Rice's theorem states this.  It is a result of the undecidablility of the
Halting problem, and it is also related to Godel's incompleteness theorem.
I would suggest taking a class on computation theory, but it might suffice
to read a book on computation theory and work through the problems.

> >or, why systems of integrities in the better-than 10e-6
> >failures per hour class _require_ deep static analysis);
>
> Is that a contradiction or do you mean that you need static analysis but
> it can never be 100%?

No it isn't a contradiction.  SPARK is not a general purpose language; it is
a special purpose language (SPARK is not Turing-Complete hence Rice's
theorem doesn't apply to it), which is designed to facilitate deep static
analysis.

Re: Certified C compilers for safety-critical embedded systems

[Ian Bell]

Georg Bauhaus wrote:

> In comp.lang.ada Ian Bell <ian@ruffrecordsdotworldonline.co.uk> wrote:
> :> You mean as in
> :> 
> :>   type my_index is range 0 .. some_variable;
> :> 
> :> -- yes, Ada compilers will perform the check.
> :> 
> : 
> : That was not what I had in mind and seems to me to be rather dodgy code.
> :  i was thinking more of the return value of some function being used as
> : an index to the array.
> 
> That should depend on what the compiler can find out about the
> function.  For example, if there is "type Index is range 0..359;",
> then if a function is specified to return values of a constrained
> subtype of Index ranging from 0..179, and a buffer has been allocated for
> some Index subtype's values ranging from 180..359, the compiler will
> warn if you use the function's values as indices to the array,
> _although_ in C terms the array index values and the function return
> values are indistinguishable (both unsigned shorts for example).

So are you basically saying that Ada requires the function return type to be
bounded and can simply check this against the array bound?

Ian

Re: Certified C compilers for safety-critical embedded systems

[Ian Bell]

CBFalconer wrote:

> James Rogers wrote:
>> 
> ... snip ...
>> 
>> When reliability engineers encounter a system relying upon human
>> actions the commonly accepted error rate, assuming properly trained
>> humans, is 1 in 1000. Such an error rate is unacceptably low for
>> most safety critical systems. An error rate of 1 in 1000 is a
>> reliability rate of 0.999. Safety critical systems commonly
>> require reliability rates on the order of 0.999999. This is
>> three orders of magnitude higher than can be achieved through
>> reliance on human correctness.
> 
> And even then, 1000 such 6 nines reliable systems together can be
> expected to have a combined reliability of 0.999.  Now consider
> the count of individual transistors in a moderately complex
> processor.
> 
> There are two basic methods of improving the end product
> reliability:  Improve the component reliability, and reduce the
> number of components.  This argues heavily against using a Pentium
> when a PIC will do.
> 

Interesting argument but a potentialy flawed example.  First one pentium and
one pic are each one component so no reduction in components. More
importantly, though a Pentium may have more transistors in it than a PIC
and hence might be seen as more complex, it is not necessarily less
reliable.  Indeed given the relatives quantities manufactured the pentium
might well be much more reliable than the PIC.

Ian

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Chad R. Meiners wrote:

> Rice's theorem states this.  It is a result of the undecidablility of the
> Halting problem, and it is also related to Godel's incompleteness theorem.
> I would suggest taking a class on computation theory, but it might suffice
> to read a book on computation theory and work through the problems.
...
> No it isn't a contradiction.  SPARK is not a general purpose language; it is
> a special purpose language (SPARK is not Turing-Complete hence Rice's
> theorem doesn't apply to it), which is designed to facilitate deep static
> analysis.

True in practice, and also in theory due to limits on memory sizes.  But 
if you were to write a SPARK program that was an interpreter for a 
general purpose language, verification would only result in proving that 
the interpreter worked correct and say nothing about programs in the 
interpreted language.

Not how you would use SPARK in any case, but it is worth remembering. 
Just as I can write Ada programs that are not SPARK programs but can 
statically proven to halt, or I can write an Ada program for which no 
such proof is possible.  SPARK just provides a convenient way to write 
programs that can be proven correct, and to automate much of the proof.

In C it is much, much harder to write programs that can be proven 
correct, but it can be done.  One way is with an Ada to C translator. If 
I had to produce a large safety-critical system for a chip which did not 
have an Ada compiler, using an Ada to C translator (several exist) and 
the SPARK tools might be a decent alternative to an Ada port.

In practice for the small programs that are common on 8-bit chips, I 
find it easier to validate the generated code to the original requirements.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Ian Bell wrote:

> So are you basically saying that Ada requires the function return type to be
> bounded and can simply check this against the array bound?

No. He is saying that Ada types and subtypes typically contain 
information about expected values that will be checked at compile time 
or run time as appropriate.

If the subtypes "statically match", which does not mean that the bounds 
are static, it can be determined at compile time that no run-time check 
will be necessary.  And of course, that means you don't have to worry 
about what happens if the check fails.  In fact, years ago in Ada 83, I 
had a nice tool that detected every place that a run-time bound was 
tested by the compiler.  About one-third of the cases were cases where 
rearranging the code would allow the compiler to eliminate the check, 
one-third were really needed, and the rest were bugs.  Today I use the 
SPARK analyzer or other (ASIS) tools to do essentially the same checking.

You are not required to use subtypes which are correctly bounded in Ada. 
But it is a big help to (static) debugging and program correctness if 
you do.  And in another thread on comp.lang.ada we are discussing that 
it is a VERY useful property of Ada, not just because it makes it more 
likely that the program will correctly implement the requirements.  It 
also often results in missed requirements being detected.

I have lost track of the number of times when a "simple question" about 
the right way to declare a subtype or assign a default value in Ada, has 
gone back to the design team to write a new requirement, as soon as they 
figured out what it should be.

My favorite example of this came from a project which was doing a flight 
control system for a fighter aircraft.  They wanted to know if it was 
possible to implement the system as a round-robin scheduler in Ada.  I 
sent back a template of what the final code would look like, and a set 
of questions that needed to be answered before the code could be 
written--or the question answered.  A month or so later I called back 
and asked whether that had solved their problem.  The answer was that 
they had resolved fifteen of the seventeen questions I had asked and 
they only had two left!

Eventually, they used hard-deadline scheduling because that way they 
could resolve the remaining questions.  Notice that the questions in one 
sense had nothing to do with Ada.  Ada had made the need for answers 
obvious, but the questions could be stated in terms that were actually 
independent of programming language and hardware.

"If the tracking of incoming missles exceeds its time slot should it be 
aborted or allowed to delay the navigation function?"

"If the aircraft state update takes longer than expected--read time-outs 
on status inquiries due to damage--should it restart where it left off 
in the next time-slot, continue execution at low-priority, or reset to 
the beginning for the next time slot but skip the failed check?"

These are not easy questions, and there may be no "right" answer in the 
sense of one that will always save the aircraft.  But choosing the best 
answer may save some aircraft that would otherwise be lost.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Alexandre E. Kopilovitch]

Robert I. Eachus wrote:

> Alexandre E. Kopilovitch wrote:
> > I think that the following posting (of Robert I. Eachus) should be placed in
> > appropriate section of Ada-promoting websites, at least unofficial ones, such
> > as AdaPower and AdaWorld - because it is the best explanation of the Ada
> > adavantages at essentially popular level I ever seen.
> >...
>
>I'm glad you like it, but as you said, it needs some work.
I guess that these your words probably mean that it will never happen.
It is a pity.

> What I 
> realized I left out after I posted it was an explanation of the "Cobra 
> Dance" crashes of F-104s.
This additional example may be good here in c.l.a. but it is certainly
excessive for a manager/executive kind - it makes the thing heavier and it
demands bigger intellectual effort for understanding, which is certainly a
drawback... and the conclusions there are somehow vague or seems vague.

By the way, I remember that F-104 Starfighter was very deadly airplane in
Germany. Germany bought many F-104 and plenty of them crashed (you know,
Soviet newspapers were greatly delighted with that, and picked every case
eagerly) - much more (at least in proportion) than in USA. I always thought
that there should be some cultural difference (between US pilots and German
pilots), which caused that effect.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Certified C compilers for safety-critical embedded systems

[Chad R. Meiners]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:ItOdncXDf7nrHnKiRVn-gw@comcast.com...
>
> True in practice, and also in theory due to limits on memory sizes.

I believe SPARK is a finite language.  That is you can only declare finite
data structures.  In general purpose languages you can declare infinite data
structures, which are needed to be Turing-Complete.  Most compilers (and
computers) only support subsets of general purpose programming language ;-)

> But
> if you were to write a SPARK program that was an interpreter for a
> general purpose language, verification would only result in proving that
> the interpreter worked correct and say nothing about programs in the
> interpreted language.

Well if you had some nice properties about the interpreted language then the
verification of the interpreter would imply that those program apply to the
program while they are being interpreted. I know---I am nitpicking, but I
have been trained to.

> Not how you would use SPARK in any case, but it is worth remembering.

I believe the SPARK examiner is written in SPARK. ;-)

> Just as I can write Ada programs that are not SPARK programs but can
> statically proven to halt, or I can write an Ada program for which no
> such proof is possible.  SPARK just provides a convenient way to write
> programs that can be proven correct, and to automate much of the proof.

I completely agree.  I just get excited about SPARK because it is one of the
few formal tools situated toward the end of the verify/validation chain.
For instances for a formal methods class, I used Promela and LOTOS to prove
a theorem for a safety property about a set of traffic lights for a one lane
bridge.  With SPARK I was able to able to prove that the premise of that
theorem was satisfied by the traffic controller program that I wrote.

> In C it is much, much harder to write programs that can be proven
> correct, but it can be done.

I agree.  However, directly working with proofs about programs written in C
would probably not be a process that you could pick up in a week to finish a
class project ;-)

> One way is with an Ada to C translator. If
> I had to produce a large safety-critical system for a chip which did not
> have an Ada compiler, using an Ada to C translator (several exist) and
> the SPARK tools might be a decent alternative to an Ada port.

This really isn't writing C programs to be proven correct.  It is generating
them as an intermediate representation.  Once the C code is compiled, you
can still use the practice that you suggested below.

> In practice for the small programs that are common on 8-bit chips, I
> find it easier to validate the generated code to the original
requirements.

A wise practice considering that compilers have bugs.  However, the point of
verifying that SPARK code meets validated requirements is to detect errors
sooner to simplify the later stages of development.  Hopefully once you VV
the SPARK program, your task to VV the generated code is simplified.

-CRM
To reply by email, change the "hotmail" to "yahoo".

Re: Certified C compilers for safety-critical embedded systems

[Georg Bauhaus]

In comp.lang.ada Robert I. Eachus <rieachus@comcast.net> wrote:
: Ian Bell wrote:
: 
:> So are you basically saying that Ada requires the function return type to be
:> bounded and can simply check this against the array bound?
: 
: No. He is saying that Ada types and subtypes typically contain 
: information about expected values that will be checked at compile time 
: or run time as appropriate.

I'll try one of Robert's ideas.
Say I do not ignore the compiler's warning that the function used
for array indexing will return values out of range for the array. I
might see that the choice of two subtypes has been inappropriate
and should be replaced with two different types. They will have
overlapping ranges but will allow the same representation in
bits. However, the program cannot be compiled any longer, using
the same buffer:

procedure p is

   type Red_Index is range 90 .. 105;
   type Light_Red_Index is range 100 .. 120;

   buffer: array(Red_Index) of Boolean;

   function some_val return Light_Red_Index is separate;

begin
   if buffer(some_val) then
      null;  -- do something here, in a more real program
   end if;
end p;

    11.    if buffer(some_val) then
                     |
        >>> expected type "Red_Index" defined at line 3
        >>> found type "Light_Red_Index" defined at line 4

That is, I might presume that color Red is not too different from
Light_Red. I might know that the number of bits used for values
in the two types will be the same (char in C terms, say).  Still the
compiler will not let me use Light_Red_Index's value 101 and
Red_Index's value 101 interchangeably.

The range check goes away when both the function and the array
use the same index type (the function is implemented to return
random values from the index type's range (because the generator
has been instantiated with that type.))  The assembly listing shows
8bit register use on i686 when the index range permits, even with
numbers ranging beyond 255 (or > 65535 for that matter).

   type Light_Red_Index is range 92_000 .. 92_200;
   for Light_Red_Index'Size use 8;

In short, convenient, checked at compile time, and efficient :-)

-- Georg

Re: Certified C compilers for safety-critical embedded systems

[Peter Hermann]

In comp.lang.ada Robert A Duff <bobduff@shell01.theworld.com> wrote:
> However, 'lint' (in the case of C) doesn't have enough information

> (Boy, I guess the spelling police will really get after you for spelling
> "Ada" wrong twice in the same sentence -- "ADa" and "ADA".  Sheesh.  ;-))

He is a LINT-user    :-|

Re: Certified C compilers for safety-critical embedded systems

[Peter Amey]

Robert I. Eachus wrote:

[snip]
> 
> Not how you would use SPARK in any case, but it is worth remembering. 
> Just as I can write Ada programs that are not SPARK programs but can 
> statically proven to halt, or I can write an Ada program for which no 
> such proof is possible.  SPARK just provides a convenient way to write 
> programs that can be proven correct, and to automate much of the proof.
> 
> In C it is much, much harder to write programs that can be proven 
> correct, but it can be done.  One way is with an Ada to C translator. If 
> I had to produce a large safety-critical system for a chip which did not 
> have an Ada compiler, using an Ada to C translator (several exist) and 
> the SPARK tools might be a decent alternative to an Ada port.
> 

Funny you should mention that.  We are currently doing exactly this for 
an aviation project.  Tool chain is UML to SPARK to C.  Most of the 
verification activity will be done on the SPARK intermediate "design 
model".  We have found that SPARK to C translation is much easier than 
Ada to C translation.  For example, verification activities at the SPARK 
level eliminate the requirement to add run-time checks to the C (which 
is therefore very easy to compare against the SPARK source); 
furthermore, the use of SPARK laregly eliminates the need for a run-time 
library so all the C is directly traceable to user-written SPARK statements.

I have submitted a paper on this to Ada Europe.  We are also in the 
process of productising the process (probably in the form of a "generate 
C" switch for the SPARK Examiner.

regards

Peter

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Georg Bauhaus wrote:

> That is, I might presume that color Red is not too different from
> Light_Red. I might know that the number of bits used for values
> in the two types will be the same (char in C terms, say).  Still the
> compiler will not let me use Light_Red_Index's value 101 and
> Red_Index's value 101 interchangeably.

Well, it would be better to say that the compiler won't let you mix 
Light_Red_Index and Red_Index implicitly.  You can always say:

if buffer(Red_Index(some_val)) then...

If the two types are represented the same, then there will be no real 
run-time cost for the conversion.  (If both Red_Index and 
Light_Red_Index were SUBtypes of Integer, then you could write:

if buffer(some_val) then... and there would be a range check associated 
with the indexing operation.  With Red_Index and Light_Red_Index as 
separate types, there will be a range check now associated with the 
conversion instead of the subscripting.  But assuming that the 
representations of the types are identical, the code should be identical.

>                                        The assembly listing shows
> 8bit register use on i686 when the index range permits, even with
> numbers ranging beyond 255 (or > 65535 for that matter).
> 
>    type Light_Red_Index is range 92_000 .. 92_200;
>    for Light_Red_Index'Size use 8;
> 
> In short, convenient, checked at compile time, and efficient :-)

Yep, and if you do a type conversion as above, the compiler will add the 
bias back in (or add the net difference if there are two different 
biases).  This means you can write your code in meaningful units and 
allow the compiler to remember and generate any conversions.  This is 
real handy when you have a sensor that for example, returns a 12-bit 
encoding of an angle.  You can write the code using units of degrees (or 
radians or grads if you want) and the compiler will convert your 
constants at compile time.  Get a new sensor with a 16-bit ADC, and all 
you have to change is the type declaration (and of course, recompile and 
test).

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Alexandre E. Kopilovitch wrote:

> By the way, I remember that F-104 Starfighter was very deadly airplane in
> Germany. Germany bought many F-104 and plenty of them crashed (you know,
> Soviet newspapers were greatly delighted with that, and picked every case
> eagerly) - much more (at least in proportion) than in USA. I always thought
> that there should be some cultural difference (between US pilots and German
> pilots), which caused that effect.

Yep, but the cultural difference was not in the pilots but in the 
training regimes.  The F-104 was an unforgiving aircraft.  In the USAF, 
F-104 pilots, I talked to said that "only" two crashes in a simulator 
session was a good day.  The Germans apparently concentrated more on 
training pilots for "normal" missions and flight regimes.  Since normal 
reflexes could be deadly, and the Cobra Dance was only one instance, the 
USAF training concentrated on getting rid of those reflexes.

I knew several USAF pilots that flew both the F-104 and then the F-4 
Phantom II.  They said one of the hardest things to UNlearn from their 
F-104 training was that in the F-104 you always advanced the throttle in 
steps.  Going from low power to full military power (or to afterburner) 
too quickly was likely to be lethal.  So if you were expecting combat, 
you sat at a throttle setting that would allow you to go "all the way" 
in one step.  In the F-4 the biggest concern was fuel state.  In full 
afterburner you could exhaust all internal fuel in less than two 
minutes.  But the F-4 could spool up rapidly, and adding afterburner was 
icing on the cake.  So the pilots learned to conserve fuel when 
possible. When combat threatened, of course, the first thing they did 
was to go to full military power, with or without afterburner depending 
on the situation and fuel state.

Incidently in Vietnam a lot of pilots won fighter to fighter duels then 
didn't have enough fuel to get back to base, or even to areas over 
friendly forces.  Early on, they had to bail out.  Later, both the Navy 
and Air Force tended to send a couple of F-4s with "buddy packs" -- 
external fuel stores and probe and drouge air-to-air refueling kits -- 
along on any CAP (combat air patrol) missions, and even some CAS (close 
air support) and bombing missions.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Chad R. Meiners wrote:

> "Robert I. Eachus" <rieachus@comcast.net> wrote in message
> news:ItOdncXDf7nrHnKiRVn-gw@comcast.com...
> 
>>True in practice, and also in theory due to limits on memory sizes.
>  
> I believe SPARK is a finite language.  That is you can only declare finite
> data structures.  In general purpose languages you can declare infinite data
> structures, which are needed to be Turing-Complete.  Most compilers (and
> computers) only support subsets of general purpose programming language ;-)

I think we are agreeing violently. ;-)  My point is that you can use 
external (from a SPARK viewpoint) storage to make SPARK Turing-Complete. 
  For an example, consider an embedded system that includes a tape drive 
for data logging. The system as a whole is Turing Complete, given an 
operator to change tapes, but it wouldn't normally be used in that way.

So you would be able to prove that a package that used the tape drive to 
implement a stack was correct, but you couldn't validate programs that 
used the tape as an unbounded store.

Once you get into this situation, which I have run into on several 
projects you have to decide where to make the cut.  I remember one 
particular (pre-SPARK) Ada project where we validated that the program 
would not fail if it ran out of logging space, and that the amount of 
logging space available met the system spec.  We just had to live with 
the fact that the logging requirement was somewhat arbitrary.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Dave Hansen]

Perhaps I should read further in the thread before replying, but I
just can't help it:

On Sat, 27 Dec 2003 05:29:44 GMT, James Rogers
<jimmaureenrogers@att.net> wrote:

[...]
>The C standard explicitly permits accessing one element beyond the end
>of an array. Neither the C compiler nor lint can determine if an array
>index is outside the bounds of the array. Ada compilers detect static
>references beyond the end of an array every time.
>
>Examples:
>
>int foo[10];
>
>int i;
>
>for(i = 0; i < 100; ++i)
>{
>   foo[i] = i;
>}
>
>Although human inspection clearly identifies the for loop indices
>to be beyond the bounds of the array, neither the C compiler nor lint
>will detect the problem. Since the problem can be clearly identified

This one's pretty easy for PC-lint.  Consider:

---begin included file---
C:\Dave>type lloop.c

void f(void)
{
    int foo[10];

    int i;

    for(i = 0; i < 100; ++i)
    {
       foo[i] = i;
    }
}

C:\Dave>lint-nt -u lloop.c
PC-lint for C/C++ (NT) Ver. 8.00n, Copyright Gimpel Software 1985-2003

--- Module:   lloop.c
                 _
       foo[i] = i;
lloop.c  10  Warning 662: Possible creation of out-of-bounds pointer
(90 beyond
    end of data) by operator '[' [Reference: file lloop.c: lines 8,
10]
lloop.c  8  Info 831: Reference cited in prior message
lloop.c  10  Info 831: Reference cited in prior message
                 _
       foo[i] = i;
lloop.c  10  Warning 661: Possible access of out-of-bounds pointer (90
beyond
    end of data) by operator '[' [Reference: file lloop.c: lines 8,
10]
lloop.c  8  Info 831: Reference cited in prior message
lloop.c  10  Info 831: Reference cited in prior message
_
}
lloop.c  12  Warning 550: Symbol 'foo' (line 4) not accessed
lloop.c  4  Info 830: Location cited in prior message

C:\Dave>
---end included file---

The "-u" option tells PC-lint to do a "unit" check, i.e., that the
referenced file is not a complete program, so it should suppress
errors like "Function f defined but not called."

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

Re: Certified C compilers for safety-critical embedded systems

[Dave Hansen]

On Sun, 28 Dec 2003 16:33:05 +0000, Chris Hills <chris@phaedsys.org>
wrote:

[...]
>
>[plain] char is a character
>singed and unsigned char are integer types.

Plain character is an abomination.  It is particularly unsuited for
character data.  You can get singed.  ;-)

All three are integer types.  All three are 1 byte wide ("byte" does
not mean "8 bits").

>
>>If you are lucky you have real C99 compiler with byte. 

I'm not sure what you mean.  There's no such thing as "byte."
uint8_t?  Not guaranteed to exist.  unint_least8_t?  That would work,
but I fear relatively few even know it exists, let alone how to use
it...

>
>there are no C99 compilers bar the (apparently) the Tasking Tricore
>compiler.

Comeau?

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

Re: Certified C compilers for safety-critical embedded systems

[Martin Krischik]

Chris Hills wrote:

> In article <1563361.SfB03k3vvC@linux1.krischik.com>, Martin Krischik
> <krischik@users.sourceforge.net> writes
>>Hyman Rosen wrote:
>>and how will you do it in C?
>>
>>Use an unsigned short int. Well an short int is usualy 16 bit not 8.
>>
>>Use an unsigned char? Well it is 8 bit - but is is a character not a
>>number.
> 
> [plain] char is a character
> singed and unsigned char are integer types.

Your are kidding. And you realy want to use a language which can not
distinquish between a number and a character for safety-critical systems?

>>If you are lucky you have real C99 compiler with byte.

> there are no C99 compilers bar the (apparently) the Tasking Tricore
> compiler.

I does not realy speak in favour of C if in 2003 there is still no major
compiler to meet the 1999 standarts.

But then amost nobody knows the standart anyway. Even if you are prepared to
pay the $18 to actulay see it, you are hard pressed to find the place where
you can actually order it. 

The Ada standart, however, is available for all:

http://adaic.org/standards/95lrm/html/RM-TTL.html

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Certified C compilers for safety-critical embedded systems

[Frank J. Lhota]

"Chris Hills" <chris@phaedsys.org> wrote in message
news:11LvOkBBXw7$EAJw@phaedsys.demon.co.uk...
> [plain] char is a character
> singed and unsigned char are integer types.

"singed" char? Perhaps there is a distinction between sung and unsung chars.

Re: Certified C compilers for safety-critical embedded systems

[Chad R. Meiners]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:H_mdnevqls8nwW2iRVn-iQ@comcast.com...
> I think we are agreeing violently. ;-)  My point is that you can use
> external (from a SPARK viewpoint) storage to make SPARK Turing-Complete.
>   For an example, consider an embedded system that includes a tape drive
> for data logging. The system as a whole is Turing Complete, given an
> operator to change tapes, but it wouldn't normally be used in that way.

Yep. We are agreeing.  I was going to use the tape drive example but you
beat me to it.

> So you would be able to prove that a package that used the tape drive to
> implement a stack was correct, but you couldn't validate programs that
> used the tape as an unbounded store.
>
> Once you get into this situation, which I have run into on several
> projects you have to decide where to make the cut.  I remember one
> particular (pre-SPARK) Ada project where we validated that the program
> would not fail if it ran out of logging space, and that the amount of
> logging space available met the system spec.  We just had to live with
> the fact that the logging requirement was somewhat arbitrary.

Interesting...I had always suspected that this had to happen in practice,
but I didn't actually know how professionals (at least a set of
professionals;) reacted to these sorts of impasses.  Thank you, I bet this
bit of information will turn up useful to me sometime in the future.

-CRM

Re: Certified C compilers for safety-critical embedded systems

[Alex Colvin]

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

>[...]
>>The C standard explicitly permits accessing one element beyond the end

not exactly. it permits addressing one beyond the end, but not accessing
so 
	int a[10], *after = &a[10];
is OK, but
	a[10]++
isn't

The rule lets you do bounds checks on pointers, even with empty ranges.


-- 
	mac the na�f

Re: Certified C compilers for safety-critical embedded systems

[Hyman Rosen]

Alex Colvin wrote:
>>>The C standard explicitly permits accessing one element beyond the end
> not exactly. it permits addressing one beyond the end, but not accessing
> so 
> 	int a[10], *after = &a[10];
> is OK, but
> 	a[10]++
> isn't
> The rule lets you do bounds checks on pointers, even with empty ranges.

And in C++, you must write
     int a[10], *after = a + 10
as &a[10] is illegal. C99 gave special dispensation to remove &*
(a[10] is rewritten as *(a+10) so &a[10] is &*(a+10) becoming (a+10))
but C++ did not, even on built-in types.

Re: Certified C compilers for safety-critical embedded systems

[Morris Dovey]

Martin Krischik wrote:

> But then amost nobody knows the standart anyway. Even if you
> are prepared to pay the $18 to actulay see it, you are hard
> pressed to find the place where you can actually order it.

Martin...

The link in my sig leads to another that'll take you directly to 
the ANSI on-line store where (for US$18) you can download it in 
PDF format. I keep mine on a business card sized CD-ROM with 
copies of Acrobat Reader and xpdf.
-- 
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall far from the tree.

Re: Certified C compilers for safety-critical embedded systems

[James Rogers]

iddw@hotmail.com (Dave Hansen) wrote in 
news:3ff0686d.528369824@News.CIS.DFN.DE:

> Perhaps I should read further in the thread before replying, but I
> just can't help it:
> 
> On Sat, 27 Dec 2003 05:29:44 GMT, James Rogers
> <jimmaureenrogers@att.net> wrote:
> 
> [...]
>>The C standard explicitly permits accessing one element beyond the end
>>of an array. Neither the C compiler nor lint can determine if an array
>>index is outside the bounds of the array. Ada compilers detect static
>>references beyond the end of an array every time.
>>
>>Examples:
>>
>>int foo[10];
>>
>>int i;
>>
>>for(i = 0; i < 100; ++i)
>>{
>>   foo[i] = i;
>>}
>>
>>Although human inspection clearly identifies the for loop indices
>>to be beyond the bounds of the array, neither the C compiler nor lint
>>will detect the problem. Since the problem can be clearly identified
> 
> This one's pretty easy for PC-lint.  Consider:
> 
> ---begin included file---
> C:\Dave>type lloop.c
> 
> void f(void)
> {
>     int foo[10];
> 
>     int i;
> 
>     for(i = 0; i < 100; ++i)
>     {
>        foo[i] = i;
>     }
> }
> 

How well does PC-lint catch the following variation:

void f(int *foo)
{
   int i;
   for(i = 0; i < 100; ++i)
   {
      foo[i] = i;
   }
}

int main(int argc, char *argv[])
{
   int bar[10];
   f(bar);
}

The abstract error is the same, yet function f has no
visibility to the size of the actual array being passed
to it. In fact, function f does not have any assurance
that its actual parameter will even point to an array.
C syntax simply does not provide the information needed
within the called function.

Compare that with the Ada syntax for dealing with arrays.

procedure main is
   type small_index is range 1..10;
   type small_array is array(small_index) of integer;
   bar : small_array;
   procedure f(foo : in out small_array) is
   begin
      for i in foo'range loop
         foo(i) := i;
      end loop;
   end f;
begin
   f(bar);
end main;

Ada arrays do not loose their bounds and indexing information
when passed to functions or procedures. Furthermore, you can
define your own array types and use those types in function and
procedure parameters. 

The Ada syntax foo'range evaluates to the ordered range of index
values for array foo. The for loop simply iterates through that
ordered range of values. The range of values is taken from the
array itself. If I were to make a small change in the for loop 
as follows:

      for i in 0..foo'last loop
         foo(i) := i;
      end loop;

The compiler would identify this as an error. The type small_array
was defined with a lowest index value of 1, not 0. 0 is not even
a valid value for the small_index type. Many compilers will identify both
errors.

Jim Rogers

Re: Certified C compilers for safety-critical embedded systems

[Martin Krischik]

Morris Dovey wrote:

> Martin Krischik wrote:
> 
>> But then amost nobody knows the standart anyway. Even if you
>> are prepared to pay the $18 to actulay see it, you are hard
>> pressed to find the place where you can actually order it.
> 
> Martin...
> 
> The link in my sig leads to another that'll take you directly to
> the ANSI on-line store where (for US$18) you can download it in
> PDF format. I keep mine on a business card sized CD-ROM with
> copies of Acrobat Reader and xpdf.

Thanks.

> --
> Morris Dovey
> West Des Moines, Iowa USA
> C links at http://www.iedu.com/c
> Read my lips: The apple doesn't fall far from the tree.

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Certified C compilers for safety-critical embedded systems

[Martin Krischik]

Frank J. Lhota wrote:

> "Chris Hills" <chris@phaedsys.org> wrote in message
> news:11LvOkBBXw7$EAJw@phaedsys.demon.co.uk...
>> [plain] char is a character
>> singed and unsigned char are integer types.
> 
> "singed" char? Perhaps there is a distinction between sung and unsung
> chars.

Grin.

Well in C you can have signed char where char'Pos is range -128 .. +127 and
unsigned char where char'Pos ist 0 .. 255. One of the top 10 mistakes K&R
did. It leads to a lot of misunderstandings and signed char is only used
when Short_Short_Integer is needed.

Which is yet another example where in C you have to say "A" when realy you
want "B". How a static analysis tool will deal with this I never know. 

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Certified C compilers for safety-critical embedded systems

[Martin Krischik]

Dave Hansen wrote:

> On Sun, 28 Dec 2003 16:33:05 +0000, Chris Hills <chris@phaedsys.org>
> wrote:
> 
> [...]
>>
>>[plain] char is a character
>>singed and unsigned char are integer types.
> 
> Plain character is an abomination.  It is particularly unsuited for
> character data.  You can get singed.  ;-)

Grin. But most C programmers are to lazy for to type unsigned.

> All three are integer types.  All three are 1 byte wide ("byte" does
> not mean "8 bits").

That is why Ada 'Size gives you the size in bits. No misunderstanding here. 

>>>If you are lucky you have real C99 compiler with byte.
> 
> I'm not sure what you mean.  There's no such thing as "byte."
> uint8_t?  Not guaranteed to exist.  unint_least8_t?  That would work,
> but I fear relatively few even know it exists, let alone how to use
> it...

You allwas learn something new. But unint_least8_t is not helpfull for
safety-critical embedded systems. You might need exaclty 8 bit.

Which brings me back to the original Question. How will you do this in C:

type Month is new Integer range 1 .. 12;
for Month'Size is 8;

Or even better:

type Display_Element is Interger range 0 .. 9;
for Display_Element'Size use 4;

type Display_Array is array (Integer range 1 .. 6) of Display_Element;
pragma Pack (Display_Array);

Display : Display_Array;
for Display'Address use 16#12_3456#;

We are talking "safety-critical embedded systems". The Plane might crash if
11 is ever stored in a Display_Element.

With Regards

Martin.
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Certified C compilers for safety-critical embedded systems

[Dave Hansen]

On Tue, 30 Dec 2003 11:18:55 +0100, Martin Krischik
<krischik@users.sourceforge.net> wrote:

>Dave Hansen wrote:
[...re: plain, signed, and unsigned char...]
>> All three are integer types.  All three are 1 byte wide ("byte" does
>> not mean "8 bits").
>
>That is why Ada 'Size gives you the size in bits. No misunderstanding here. 

In C, CHAR_BIT gives you the number of bits in [[un]signed] char.  It
must be >= 8.

>
>>>>If you are lucky you have real C99 compiler with byte.
>> 
>> I'm not sure what you mean.  There's no such thing as "byte."
>> uint8_t?  Not guaranteed to exist.  unint_least8_t?  That would work,
>> but I fear relatively few even know it exists, let alone how to use
>> it...
>
>You allwas learn something new. But unint_least8_t is not helpfull for
>safety-critical embedded systems. You might need exaclty 8 bit.

If a platform supports uint8_t (unsigned integer exactly 8 bits wide)
the compiler must provide the type.  If the platform does not support
the type, you have to choose another platform.

>
>Which brings me back to the original Question. How will you do this in C:
>
>type Month is new Integer range 1 .. 12;
>for Month'Size is 8;

You could do something like

   typedef struct month{
      value:8;
   } Month;

>
>Or even better:
>
>type Display_Element is Interger range 0 .. 9;
>for Display_Element'Size use 4;

   typedef struct display_element{
      value:4;
   } Display_Element;

>
>type Display_Array is array (Integer range 1 .. 6) of Display_Element;
>pragma Pack (Display_Array);

   typedef struct display_array{
      elt0: 4;
      elt1: 4;
      elt2: 4;
      elt3: 4;
      elt4: 4;
      elt5: 4;
   } Display_Array;

>
>Display : Display_Array;
>for Display'Address use 16#12_3456#;

   Display_Array *Display = (Display_Array *) 0x123456;

Though in no case would the ranges be enforced.  Heck, enumerations
aren't enforced in any way either:

   enum { Red, Green, Blue } color;
   int number;

   color = 42;
   number = Red;

Is perfectly fine as far as the compiler is concerned.

>We are talking "safety-critical embedded systems". The Plane might crash if
>11 is ever stored in a Display_Element.

Then don't do that.  ;-)

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

Re: Certified C compilers for safety-critical embedded systems

[Martin Krischik]

Alex Colvin wrote:

>>[...]
>>>The C standard explicitly permits accessing one element beyond the end
> 
> not exactly. it permits addressing one beyond the end, but not accessing
> so
> int a[10], *after = &a[10];
> is OK, but
> a[10]++
> isn't

But the compiler won't isue an exception when you actualy do. First C does
not have exception handling (Ada has) and then it just not allowed but
almost no compiler will stop you doing it Especialy when a function call is
in between declaration and use.

> 
> The rule lets you do bounds checks on pointers, even with empty ranges.


With Regards


Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Certified C compilers for safety-critical embedded systems

[Martin Krischik]

Dave Hansen wrote:

> On Tue, 30 Dec 2003 11:18:55 +0100, Martin Krischik
> <krischik@users.sourceforge.net> wrote:
> 
>>Dave Hansen wrote:
> [...re: plain, signed, and unsigned char...]
>>> All three are integer types.  All three are 1 byte wide ("byte" does
>>> not mean "8 bits").
>>
>>That is why Ada 'Size gives you the size in bits. No misunderstanding
>>here.
> 
> In C, CHAR_BIT gives you the number of bits in [[un]signed] char.  It
> must be >= 8.
> 
>>
>>>>>If you are lucky you have real C99 compiler with byte.
>>> 
>>> I'm not sure what you mean.  There's no such thing as "byte."
>>> uint8_t?  Not guaranteed to exist.  unint_least8_t?  That would work,
>>> but I fear relatively few even know it exists, let alone how to use
>>> it...
>>
>>You allwas learn something new. But unint_least8_t is not helpfull for
>>safety-critical embedded systems. You might need exaclty 8 bit.
> 
> If a platform supports uint8_t (unsigned integer exactly 8 bits wide)
> the compiler must provide the type.  If the platform does not support
> the type, you have to choose another platform.
> 
>>
>>Which brings me back to the original Question. How will you do this in C:
>>
>>type Month is new Integer range 1 .. 12;
>>for Month'Size is 8;
> 
> You could do something like
> 
>    typedef struct month{
>       value:8;
>    } Month;
> 
>>
>>Or even better:
>>
>>type Display_Element is Interger range 0 .. 9;
>>for Display_Element'Size use 4;
> 
>    typedef struct display_element{
>       value:4;
>    } Display_Element;

>>type Display_Array is array (Integer range 1 .. 6) of Display_Element;
>>pragma Pack (Display_Array);
> 
>    typedef struct display_array{
>       elt0: 4;
>       elt1: 4;
>       elt2: 4;
>       elt3: 4;
>       elt4: 4;
>       elt5: 4;
>    } Display_Array;

I had my array start at 1 not 0. In C all numbers start with 0 but in the
real world they usualy start with 1.

>>Display : Display_Array;
>>for Display'Address use 16#12_3456#;
> 
>    Display_Array *Display = (Display_Array *) 0x123456;

Display_Array *const Display = (Display_Array *) 0x123456;
 
> Though in no case would the ranges be enforced.  Heck, enumerations
> aren't enforced in any way either:
> 
>    enum { Red, Green, Blue } color;
>    int number;
> 
>    color = 42;
>    number = Red;
> 
> Is perfectly fine as far as the compiler is concerned.
> 
>>We are talking "safety-critical embedded systems". The Plane might crash
>>if 11 is ever stored in a Display_Element.
> 
> Then don't do that.  ;-)

But is it not much better if the compiler stoped you from doing that
mistake?

Anyway, all above is is just plain C and it is not at all as save as the Ada
code. Nor is it as easy to read (safety-critical software in my book should
be code reviewed). And this is just 

The claim here in the group is that by use of a static analysis tool the C
code can be made as secure as the Ada code. So let me expand my question:
How with the static analysis tool find out the the follwing might lead to
the plane crashing.

Ada:

Display (1) = 11;                --  Compiler will warn you compile time
Display (2) = Value + 2;   --  exeption if Value is greater 7

C:

Display->elt0 = 11;
Display->elt1 = Value + 2;   

This example might be over primitive but humans somtimes make this little
mistakes.


With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Certified C compilers for safety-critical embedded systems

[Hyman Rosen]

Martin Krischik wrote:
> I had my array start at 1 not 0. In C all numbers start with 0 but in the
> real world they usualy start with 1.

The "real world" doesn't have arrays. Only computer programs do.

Re: Certified C compilers for safety-critical embedded systems

[Chris Hills]

In article <1731094.1f7Irsyk1h@linux1.krischik.com>, Martin Krischik
<krischik@users.sourceforge.net> writes
>
>I had my array start at 1 not 0. In C all numbers start with 0 but in the
>real world they usualy start with 1.

Interesting point. Apparently 0 is the first positive integer.
Everything starts at 0. Otherwise things would start with 1 or -1  there
would be nothing (not 0) between them :-)

Zero is a valid number.

runs for cover and turns off email system :-)
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Certified C compilers for safety-critical embedded systems

[Chris Hills]

In article <bshl7d$1gab$1@msunews.cl.msu.edu>, Chad R. Meiners
<crmeiners@hotmail.com> writes
>
>"Chris Hills" <chris@phaedsys.org> wrote in message
>news:fUk12TA8gB7$EA$E@phaedsys.demon.co.uk...
>> I doubt it. At least not in large enough numbers to justify it
>> especially as 61508 permits C  (subset, with coding standard and static
>> checking) to SIL-4
>>
>> In effect a SPARK-C
>
>When you says static checking, do you include static checkers that can prove
>that assertions are never volilated (within a set of assumptions)?  If so
>then your C subset with static checking might be in effect a SPARK-C.  SPARK
>supports some very nice formal verification techniques which you might be
>overlooking.

No. I was thinking about Lint initially but I am sure that some of the
better (more expensive :-) tools will test to various criteria etc and
AFAIK do what you are suggesting but I am not certain on this.  any one
using QAC or LDRA's tool like to comment?

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: Certified C compilers for safety-critical embedded systems

[Dmitry A. Kazakov]

Chris Hills wrote:

> In article <1731094.1f7Irsyk1h@linux1.krischik.com>, Martin Krischik
> <krischik@users.sourceforge.net> writes
>>
>>I had my array start at 1 not 0. In C all numbers start with 0 but in the
>>real world they usualy start with 1.
> 
> Interesting point. Apparently 0 is the first positive integer.

Zero is the first natural number, positive numbers do not include zero.

> Everything starts at 0. Otherwise things would start with 1 or -1  there
> would be nothing (not 0) between them :-)

> Zero is a valid number.

All numbers are valid. What could be an "invalid" number?

> runs for cover and turns off email system :-)

Just start receiving the answer number zero! (:-))

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Certified C compilers for safety-critical embedded systems

[Dmitry A. Kazakov]

Hyman Rosen wrote:

> Martin Krischik wrote:
>> I had my array start at 1 not 0. In C all numbers start with 0 but in the
>> real world they usualy start with 1.
> 
> The "real world" doesn't have arrays. Only computer programs do.

The "real world" does not have numbers as well.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Certified C compilers for safety-critical embedded systems

[CBFalconer]

Martin Krischik wrote:
> 
... snip ...
> 
> The claim here in the group is that by use of a static analysis
> tool the C code can be made as secure as the Ada code.

I don't think anyone knowledgeable is seriously making such a
claim.  However, nobody knowledgeable would make the claim that
assembly language is unnecessary either, and similarly C is
extremely useful as a lingua franca extending over many systems.

As has been pointed out elsethread, it is possible to translate
Ada to C, which immediately takes advantage of the de facto
portability, but gives up some compile time efficiency and
convenience.  After all, the usual function of a C compiler is to
translate a C program to assembly language, except that that
destination is not standardized.

Implementation of run-time checks may require that the C code make
extensive use of system subroutines.  It may not be possible to
use "a = b + c;" statements.  At the same time the full C library
is probably not needed, and can be heavily pruned for Ada use.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

Re: Certified C compilers for safety-critical embedded systems

[Dave Hansen]

On Tue, 30 Dec 2003 18:08:23 +0100, Martin Krischik
<krischik@users.sourceforge.net> wrote:

>Dave Hansen wrote:
[...]
>> Then don't do that.  ;-)
>
>But is it not much better if the compiler stoped you from doing that
>mistake?

Of course.  Thus the smiley.  I freely admit that Ada does checking
that no C compiler does.  I even admit it may (may!) be a better
langauge than C (for appropriate values of "better").

But with the possible exception of the Atmel AVR (GNAT?), there is
_no_ Ada compiler for _any_ of the microprocessors I'm using today.
For me, that makes C a better language.

>
>Anyway, all above is is just plain C and it is not at all as save as the Ada
>code. Nor is it as easy to read (safety-critical software in my book should
>be code reviewed). And this is just 

No, it's not the same, it's just as close as I could get.  But
"easy-to-read" is in the eye of the reader.  I learned Pascal and
Modula-2 years ago, so Ada doesn't look too bad.  But other than the
variable declaration syntax and some of the strange precedence rules,
I find C very easy to read.

Many consider the terseness of C to be a problem or even a
disadvantage.  But sometimes it helps in comprehension.  Consider:

   int key;
   extern int get_key(void);
   extern void process(int);
   #define EXIT_KEY  'X'

   while ( (key = get_key()) != EXIT_KEY )
      process(key);

How do you do that in Ada?  

Even the canonical strcpy function is obvious and has a certain
beauty.  Perhaps you think it looks more like line noise:

   char *strcpy(char *dest, char *src)
   {
      char *retval = dest;

      while (*dest++ = *src++)
         continue;

      return retval;
   }

But it's "safe" only when used properly.

>
>The claim here in the group is that by use of a static analysis tool the C
>code can be made as secure as the Ada code. So let me expand my question:

I wouldn't make that claim.  Mine would be that the proper use of a
static analysis tool will make C code much better than if you didn't
use a static analysis tool at all.  Substituting "Ada" for "C" in the
previous statement would probably leave it true.

>How with the static analysis tool find out the the follwing might lead to
>the plane crashing.
>
>Ada:
>
>Display (1) = 11;                --  Compiler will warn you compile time
>Display (2) = Value + 2;   --  exeption if Value is greater 7

Exceptions are valuable only if handled (think Ariane 5).  How would
you handle this one?

>
>C:
>
>Display->elt0 = 11;
>Display->elt1 = Value + 2;   
>
>This example might be over primitive but humans somtimes make this little
>mistakes.

True.  But I don't think even Ada will catch them all.  And it
certainly does no better than C for e.g. sensor failures.  

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

Re: Certified C compilers for safety-critical embedded systems

[Martin Krischik]

Chris Hills wrote:

> In article <1731094.1f7Irsyk1h@linux1.krischik.com>, Martin Krischik
> <krischik@users.sourceforge.net> writes

>>I had my array start at 1 not 0. In C all numbers start with 0 but in the
>>real world they usualy start with 1.
 
> Interesting point. Apparently 0 is the first positive integer.

In my Math lessons there had been the Natural Numbers "N" and the Natural
Number with 0 "N0" (0 should be subsripted). 

> Everything starts at 0.

No. Look at the next calender for examples: The day of month start with 1.
The month of year as well. Some might debate Day of Week but at least in
the bible they have been counted from 1 to 7.

Three expamples of integer ranges which do not start with 0.

> Otherwise things would start with 1 or -1  there
> would be nothing (not 0) between them :-)

Just to tease you:

type Some_Array is new array (Integer range -1 .. 1) of Some_Element;

is valid Ada code.

> Zero is a valid number.

Shure it is. But not in all cases.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Certified C compilers for safety-critical embedded systems

[CBFalconer]

Hyman Rosen wrote:
> Martin Krischik wrote:
> 
> > I had my array start at 1 not 0. In C all numbers start with 0
> > but in the real world they usualy start with 1.
> 
> The "real world" doesn't have arrays. Only computer programs do.

You live in a highly peculiar world. :-)

Martin means array indices, not numbers, IMO.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

Re: Certified C compilers for safety-critical embedded systems

[CBFalconer]

Dave Hansen wrote:
> 
... snip ...
> 
> Many consider the terseness of C to be a problem or even a
> disadvantage.  But sometimes it helps in comprehension.  Consider:
> 
>    int key;
>    extern int get_key(void);
>    extern void process(int);
>    #define EXIT_KEY  'X'
> 
>    while ( (key = get_key()) != EXIT_KEY )
>       process(key);
> 
> How do you do that in Ada?

I won't answer that, but here is how I would do it in Pascal:

   FUNCTION nextkey(VAR keyval : char) : boolean;

      BEGIN
      keyval = get_key;
      nextkey = keyval <> EXIT_KEY;
      END;

   BEGIN
   ....
   WHILE nextkey(key) DO process(key);
   ....

I have no qualms about factoring out baby subroutines.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

Re: Certified C compilers for safety-critical embedded systems

[Hyman Rosen]

CBFalconer wrote:
> You live in a highly peculiar world. :-)
> Martin means array indices, not numbers, IMO.

Counting in the real world is done in many peculiar ways.
For example, at least in the US, house numbers tend to be
even on one side of the street and odd on the other.

Counting in computer programs should be done in a way most
convenient for the programs to do their work.

Re: Certified C compilers for safety-critical embedded systems

[Ed Falis]

On Tue, 30 Dec 2003 19:20:50 GMT, Dave Hansen <iddw@hotmail.com> wrote:

>    int key;
>    extern int get_key(void);
>    extern void process(int);
>    #define EXIT_KEY  'X'
>
>    while ( (key = get_key()) != EXIT_KEY )
>       process(key);
>
> How do you do that in Ada?
>


with Get_Key, Process;
--  Assuming appropriate declarations elsewhere

procedure Do_it is
     Key: Character;
     Exit_Key : constant Character := 'X';
begin
    loop
        Key := Get_Key;
    exit when Key = Exit_Key;
       Process (Key);
    end loop;
end Do_It;

An extra few lines.

- Ed

Re: Certified C compilers for safety-critical embedded systems

[Larry Kilgallen]

In article <1072806253.772580@master.nyc.kbcfp.com>, Hyman Rosen <hyrosen@mail.com> writes:
> Martin Krischik wrote:
>> I had my array start at 1 not 0. In C all numbers start with 0 but in the
>> real world they usualy start with 1.
> 
> The "real world" doesn't have arrays. Only computer programs do.

Cleanup in Aisle 7.

Re: Certified C compilers for safety-critical embedded systems

[Larry Kilgallen]

In article <1072819860.150168@master.nyc.kbcfp.com>, Hyman Rosen <hyrosen@mail.com> writes:
> CBFalconer wrote:
>> You live in a highly peculiar world. :-)
>> Martin means array indices, not numbers, IMO.
> 
> Counting in the real world is done in many peculiar ways.
> For example, at least in the US, house numbers tend to be
> even on one side of the street and odd on the other.
> 
> Counting in computer programs should be done in a way most
> convenient for the programs to do their work.

And it is, generally using binary...

Counting in the _source_ of computer programs should be done in the
way to maximize correctness of the computer-human interface.  For
the number of people who attended a Modern Western Square Dance,
that means starting at 8 (any fewer and there was no dance).

Re: Certified C compilers for safety-critical embedded systems

[Hyman Rosen]

Larry Kilgallen wrote:
> Cleanup in Aisle 7.

And in many buildings, the next higher floor after 12 is 14.
In my building, the next higher floor after 14 is PH.

If anything, counting in the real world is a lot like Ada
enumeration types.

Re: Certified C compilers for safety-critical embedded systems

[Alexandre E. Kopilovitch]

Dmitry A. Kazakov wrote:

> Hyman Rosen wrote:
>
> > Martin Krischik wrote:
> >> I had my array start at 1 not 0. In C all numbers start with 0 but in the
> >> real world they usualy start with 1.
> > 
> > The "real world" doesn't have arrays. Only computer programs do.
>
> The "real world" does not have numbers as well.

As well as words and notions. So no argument is possible in that too very
real world... or about it.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Certified C compilers for safety-critical embedded systems

[Dave Hansen]

On Tue, 30 Dec 2003 21:15:46 GMT, CBFalconer <cbfalconer@yahoo.com>
wrote:

>Dave Hansen wrote:
>> 
[...]
>>    while ( (key = get_key()) != EXIT_KEY )
>>       process(key);
>> 
>> How do you do that in Ada?
>
>I won't answer that, but here is how I would do it in Pascal:
>
>   FUNCTION nextkey(VAR keyval : char) : boolean;
>
>      BEGIN
>      keyval = get_key;
>      nextkey = keyval <> EXIT_KEY;
>      END;
>
>   BEGIN
>   ....
>   WHILE nextkey(key) DO process(key);
>   ....

I'd thought about that, but I remembered my instructors discouraging
functions with side effects.  I'm not sure why now, other than they'd
been teaching us FORTRAN the previous quarter.  Certainly after 20
years of programming in C, it seems almost second nature today.

Though one thing bugs me.  In C, nextkey would be written something
like

   int nextkey(int *key_ptr)
   {
      *key_ptr = get_key();
      return *key_ptr != EXIT_KEY;
   }

and would be called like

   while ( nextkey(&key) ) process(key);

Note the address operator at the call.  It makes it obvious (at the
point the function is used) that nextkey modifies its parameter (or at
least it _could_).  In Pascal, the only way to know that is to look at
the function definition.  In C++, the parameter is likely to be a
reference, and have the same problem (IMHO) as Pascal.

Oh, and I never did like Pascal's cutesy way of returning a value from
a function...  But that's just syntax.  Until you try to use the
function name as a temporary -- then all recursive heck breaks out.

>
>I have no qualms about factoring out baby subroutines.

Nor I.  One recent small (PIC) project has 26 function definitions
(including main).  Since most of these are called from one place
(each), the compiler is smart enough to "inline" them so that worst
case return stack usage (including interrupt) is 3.

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

Re: Certified C compilers for safety-critical embedded systems

[Dave Hansen]

On Tue, 30 Dec 2003 21:35:10 GMT, Ed Falis <falis@verizon.net> wrote:

>On Tue, 30 Dec 2003 19:20:50 GMT, Dave Hansen <iddw@hotmail.com> wrote:
[...]
>>    while ( (key = get_key()) != EXIT_KEY )
>>       process(key);
>>
>> How do you do that in Ada?
>>
>
>
>with Get_Key, Process;
>--  Assuming appropriate declarations elsewhere
>
>procedure Do_it is
>     Key: Character;
>     Exit_Key : constant Character := 'X';
>begin
>    loop
>        Key := Get_Key;
>    exit when Key = Exit_Key;
>       Process (Key);
>    end loop;
>end Do_It;

Thanks.  It was a serious question.  I did want to know.

Though structurally, this reminds me of

   while (1)  /* or for (;;) if you like obscure syntax */
   {
      key = get_key();
      if (key == EXIT_KEY) break;
      process(key);
   }

which tends to be discouraged.

Another question:  Note that in C, even though get_key takes no
parameters, it is called with empty parentheses, while Get_Key in Ada
looks (syntactically) like any other variable.  ISTR that in Modula-2,
a function that takes no paramters could be called either way (with or
without empty parentheses).  Is this true in Ada?  FWIW, I like the
empty parens because they signal to the reader that something special
is going on.

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

Re: Certified C compilers for safety-critical embedded systems

[Martin Krischik]

Hyman Rosen wrote:

> CBFalconer wrote:
>> You live in a highly peculiar world. :-)
>> Martin means array indices, not numbers, IMO.
> 
> Counting in the real world is done in many peculiar ways.
> For example, at least in the US, house numbers tend to be
> even on one side of the street and odd on the other.
> 
> Counting in computer programs should be done in a way most
> convenient for the programs to do their work.

Here you hit the main difference between the Pascal/Modula-2/Ada fraction
and the C/C++ fraction.

Those Pascal/Modula-2/Ada fraction belive that computer programs should
reseble the real word as much as possible and translating beween real world
and computer world should be done by the compiler and the optimizer.

Because once the compiler and optimizer have learned to do that will do it 
right every time. Unlike humans.

I have a lot more experience in C++ then in Ada jet I make a lot more little
mistakes in C++ then in Ada. Most of which are type convertions where there
is no type is to be converted.

And of course I use warning level 4 to tell me about unsuitable type
convertions but it does not help. Mostly because the 3rd party libraries
(incl. the STL) are not compatible with warning level 4.

From my experience 10 to 1 (10 times as many silly little mistakes in C++)
is realistic.

And, unlike the normal C/C++ developer, who take these bugs K&R given, I
know that an Ada compiler would have told me that I am doing something
silly.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Certified C compilers for safety-critical embedded systems

[Martin Krischik]

Dave Hansen wrote:

> On Tue, 30 Dec 2003 21:35:10 GMT, Ed Falis <falis@verizon.net> wrote:
> 
>>On Tue, 30 Dec 2003 19:20:50 GMT, Dave Hansen <iddw@hotmail.com> wrote:
> [...]
>>>    while ( (key = get_key()) != EXIT_KEY )
>>>       process(key);
>>>
>>> How do you do that in Ada?
>>>
>>
>>
>>with Get_Key, Process;
>>--  Assuming appropriate declarations elsewhere
>>
>>procedure Do_it is
>>     Key: Character;
>>     Exit_Key : constant Character := 'X';
>>begin
>>    loop
>>        Key := Get_Key;
>>    exit when Key = Exit_Key;
>>       Process (Key);
>>    end loop;
>>end Do_It;
> 
> Thanks.  It was a serious question.  I did want to know.
> 
> Though structurally, this reminds me of
> 
>    while (1)  /* or for (;;) if you like obscure syntax */
>    {
>       key = get_key();
>       if (key == EXIT_KEY) break;
>       process(key);
>    }
> 
> which tends to be discouraged.

In Ada the exit is at the front of the statement and therefore easier to
spot.

> Another question:  Note that in C, even though get_key takes no
> parameters, it is called with empty parentheses, while Get_Key in Ada
> looks (syntactically) like any other variable.  ISTR that in Modula-2,
> a function that takes no paramters could be called either way (with or
> without empty parentheses).  Is this true in Ada?  FWIW, I like the
> empty parens because they signal to the reader that something special
> is going on.

Well, no. This is partly because of the way rename works:

http://www.adaic.org/standards/95lrm/html/RM-8-5-4.html
http://www.adaic.org/standards/95lrm/html/RM-3-5-1.html

(you don't need to pay $18 to read it ;-))

Look aut for the renamings of "red" ;-). Not every function is actualy a
function.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Certified C compilers for safety-critical embedded systems

[Ed Falis]

On Wed, 31 Dec 2003 00:11:37 GMT, Dave Hansen <iddw@hotmail.com> wrote:

> Though structurally, this reminds me of
>
>    while (1)  /* or for (;;) if you like obscure syntax */
>    {
>       key = get_key();
>       if (key == EXIT_KEY) break;
>       process(key);
>    }
>
> which tends to be discouraged.

This is a matter of language-specific idioms, I'd say.   The exit from the 
statement list of a loop is the most flexible Ada iteration form, but it 
isn't used all that often - the other forms are more common since they 
cover most cases.

>
> Another question:  Note that in C, even though get_key takes no
> parameters, it is called with empty parentheses, while Get_Key in Ada
> looks (syntactically) like any other variable.  ISTR that in Modula-2,
> a function that takes no paramters could be called either way (with or
> without empty parentheses).  Is this true in Ada?  FWIW, I like the
> empty parens because they signal to the reader that something special
> is going on.

The empty parens are not allowed in Ada.  Bob Eachus or someone else might 
be able to give some of the rationale.  It's a case similar to the choice 
of () for array indexing rather than [].  In Ada, a function result is 
considered conceptually similar to a constant, as are enumeration 
literals, and many of the same rules apply to them and their use.  I 
suspect the syntax is intended to reinforce this.

- Ed

Re: Certified C compilers for safety-critical embedded systems

[Georg Bauhaus]

In comp.lang.ada Dave Hansen <iddw@hotmail.com> wrote:
:   while ( nextkey(&key) ) process(key);
: 
: Note the address operator at the call.  It makes it obvious (at the
: point the function is used) that nextkey modifies its parameter (or at
: least it _could_).  In Pascal, the only way to know that is to look at
: the function definition.  In C++, the parameter is likely to be a
: reference, and have the same problem (IMHO) as Pascal.

Ada solution that addresses both & and the while(1) issue:

procedure p is

   function next_key (key_filled: access Character) return Boolean is separate;

   procedure process (the_key: in out Character) is separate;


   key: aliased Character;

begin

   while next_key (key'access) loop
      process(key);

   end loop;

end p;


-- Georg

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Ed Falis wrote:

> This is a matter of language-specific idioms, I'd say.   The exit from 
> the statement list of a loop is the most flexible Ada iteration form, 
> but it isn't used all that often - the other forms are more common since 
> they cover most cases.

Depends on your programming style (and the type of programs you write) 
how often it occurs.  I always use it for "n and a half" type loops, and 
for tasks where the main body is a loop that is only exited in special 
circumstances.  Certainly in Ada, such loop are not discouraged, 
although some people get bent out of shape if you have two exits in a 
loop.  I certainly am not going to get upset, or even be mildly 
concerned about:

loop
   Input := Next_Char;
   exit when Input = 'X';
   exit when Input = 'x';
   Process_Input;
end loop;

vs.

loop
   Input := Next_Char;
   exit when Input = 'X' or else Input = 'x';
   Process_Input;
end loop;

In fact I slightly prefer the first form.

> The empty parens are not allowed in Ada.  Bob Eachus or someone else 
> might be able to give some of the rationale.  It's a case similar to the 
> choice of () for array indexing rather than [].  In Ada, a function 
> result is considered conceptually similar to a constant, as are 
> enumeration literals, and many of the same rules apply to them and their 
> use.  I suspect the syntax is intended to reinforce this.

There was a time when the parenthesis were required.  I think it made it 
from Preliminary Ada into Ada 80, but definitely was gone before Ada 82. 
  The argument against the empty parentheses was mostly stylistic, but 
the equivalence of enumeration and other literals to function calls was 
the real killer.  A rule that determine when the empty parentheses were 
required was considered to be a burden on users, but it also would have 
been a burden on implementors and the ARG. ;-)

Incidently there are a few cases in Ada where a function result is 
equivalent to a variable not a constant.  Read about return by reference 
for more details.  And of course you can have cases where a function 
returns an access value, and can appear in a name on the left hand side 
of an assignment statement:

function Predecessor(Node: Item_Access) return Item_Access;
...
Temp, New_Node: Item_Access;
...
New_Node.Next := Temp;
Predecessor(Temp).Next := New_Node;

Of course, this is a much more common use of functions in variable names 
  than return by reference functions.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Alex Colvin]

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


>The empty parens are not allowed in Ada.  Bob Eachus or someone else might 
>be able to give some of the rationale.  It's a case similar to the choice 
>of () for array indexing rather than [].  In Ada, a function result is 
>considered conceptually similar to a constant, as are enumeration 
>literals, and many of the same rules apply to them and their use.  I 
>suspect the syntax is intended to reinforce this.


I suspect that the use of () instead of [] has more to do with 7-bit
character sets for European languages. See
	http://archive.adaic.com/standards/83rat/html/ratl-02-01.html
and ISO 646. Same problem that gave us C trigraphs


-- 
	mac the na�f

Re: Certified C compilers for safety-critical embedded systems

[Robert A Duff]

(I've deleted comp.arch.embedded, since this is about some weird Ada
obscurity.)

"Robert I. Eachus" <rieachus@comcast.net> writes:

> There was a time when the parenthesis were required.  I think it made it
> from Preliminary Ada into Ada 80, but definitely was gone before Ada
> 82.

I believe that's correct.

>... The argument against the empty parentheses was mostly stylistic, but
> the equivalence of enumeration and other literals to function calls was
> the real killer.

Agreed.

>...A rule that determine when the empty parentheses were
> required was considered to be a burden on users, but it also would have
> been a burden on implementors and the ARG. ;-)

But I think requiring empty parens on parameterless calls would actually
*simplify* the compiler.  I can think of two cases:

    function F(X: Integer := 1) return String;

Only context can tell whether F(37) means "call F with actual parameter
37" versus "call F with actual parameter defaulted to 1, and then select
component number 37 of the resulting String."  That is, it requires
overload resolution to figure out the syntax of "F(37)" -- is it a
function call or is it an indexed component?

The other example is entry families.  Task_Name.Entry_Name(X)
could mean to call a parameterless entry whose index in the family
is X, or it could mean to call a single entry passing actual parameter
X.  The compiler can't tell which it is based purely on (context free)
syntax.

- Bob

Re: Certified C compilers for safety-critical embedded systems

[Hyman Rosen]

Robert A Duff wrote:
> But I think requiring empty parens on parameterless calls would actually
> *simplify* the compiler.

Don't forget the useful fiction that enumeration literals
are parameterless functions. That would be impacted by
requiring empty parentheses. Now, if it hadn't been decided
that array access and function calls should both use ()...

Re: Certified C compilers for safety-critical embedded systems

[Robert A Duff]

Hyman Rosen <hyrosen@mail.com> writes:

> Robert A Duff wrote:
> > But I think requiring empty parens on parameterless calls would actually
> > *simplify* the compiler.
> 
> Don't forget the useful fiction that enumeration literals
> are parameterless functions.

I don't much like that "useful fiction".  Seems more like a "strange
confusion", to me.

We don't pretend that "1" is the name of a function, after all.

>... That would be impacted by
> requiring empty parentheses.

Indeed.

>... Now, if it hadn't been decided
> that array access and function calls should both use ()...

Yeah, ... ;-)

- Bob

Re: Certified C compilers for safety-critical embedded systems

[Hyman Rosen]

Robert A Duff wrote:
> I don't much like that "useful fiction".  Seems more like a "strange
> confusion", to me.

That fiction combines with the ability to overload on return type such
that you can have the same name (or literal) used as an enumerator for
multiple types, and the compiler figures out which one is meant from
context in most cases. It means that the ARM doesn't have to create a
separate rule allowing and explaining this.

But you already know that, right?

Re: Certified C compilers for safety-critical embedded systems

[Dmitry A. Kazakov]

Robert A Duff wrote:

> Hyman Rosen <hyrosen@mail.com> writes:
> 
>> Robert A Duff wrote:
>> > But I think requiring empty parens on parameterless calls would
>> > actually *simplify* the compiler.
>> 
>> Don't forget the useful fiction that enumeration literals
>> are parameterless functions.
> 
> I don't much like that "useful fiction".  Seems more like a "strange
> confusion", to me.
> 
> We don't pretend that "1" is the name of a function, after all.

Why not to?

There is a famous way to build positive numbers from sets. Let null be an
empty set, then {null} is 1, {{null}} is 2 etc. Putting this in Ada
notation, could be:

1 renames (others=>null);
2 renames (others=>(others=>null));
... -- (:-))

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Certified C compilers for safety-critical embedded systems

[Randy Brukardt]

"Hyman Rosen" <hyrosen@mail.com> wrote:
> Robert A Duff wrote:
> > I don't much like that "useful fiction".  Seems more like a "strange
> > confusion", to me.
>
> That fiction combines with the ability to overload on return type such
> that you can have the same name (or literal) used as an enumerator for
> multiple types, and the compiler figures out which one is meant from
> context in most cases. It means that the ARM doesn't have to create a
> separate rule allowing and explaining this.
>
> But you already know that, right?

Bob better know that, or we'll have to revoke his language-lawyer license!
:-)

                   Randy.

Re: Certified C compilers for safety-critical embedded systems

[Robert A Duff]

Hyman Rosen <hyrosen@mail.com> writes:

> Robert A Duff wrote:
> > I don't much like that "useful fiction".  Seems more like a "strange
> > confusion", to me.
> 
> That fiction combines with the ability to overload on return type such
> that you can have the same name (or literal) used as an enumerator for
> multiple types, and the compiler figures out which one is meant from
> context in most cases. It means that the ARM doesn't have to create a
> separate rule allowing and explaining this.

I very much like the ability to overload on return type (as in the enum
lits we're talking about).  This is superior to the overloading in C++,
and many other languages, IMHO, which is always bottom up.

But the reasoning seems to be:
1. Overloading is for subprogram names.
2. But we want to overload enum lits, too.
3. So we better pretend that enum lits are functions.

A better line of thinking is:
1. Overloading is for subprogram names.
2. But we want to overload enum lits, too.
3. OOPS.  Number 1 is wrong.  We can let enum lits be overloaded,
but there's no reason to pretend they're functions.  They're just plain
old literals.
4. Might as well let constants be overloaded, too, with rules similar
to enum lits.

By the way, there's no need for a "separate rule" to allow overloading.
If the concept exists in the language, and you don't want to allow
overloading of everything, then you need rules in the other direction --
for example, the rules in Ada about no two homographs in the same
declarative region.

I would prefer to allow *everything* to be overloaded, but put the
restrictions in the resolution rules.

> But you already know that, right?

I know it only too well.  ;-)

- Bob

Re: Certified C compilers for safety-critical embedded systems

[Dave Hansen]

On Wed, 31 Dec 2003 14:27:08 +0000 (UTC), Georg Bauhaus
<sb463ba@l1-hrz.uni-duisburg.de> wrote:

>In comp.lang.ada Dave Hansen <iddw@hotmail.com> wrote:

Note: I'm reading from comp.arch.embedded.  Just so you know where I'm
coming from...

>:   while ( nextkey(&key) ) process(key);
>: 
[... "&" operator signals "nextkey" might modify the value of the
parameter ...]
>
>Ada solution that addresses both & and the while(1) issue:
>
>procedure p is
>
>   function next_key (key_filled: access Character) return Boolean is separate;
>
>   procedure process (the_key: in out Character) is separate;
>
>
>   key: aliased Character;
>
>begin
>
>   while next_key (key'access) loop
>      process(key);
>
>   end loop;
>
>end p;

Thanks.  I like it, if I understand it.  ;-)

Is the "'access" tag (or whatever you call it) _required_ on the call
if a function is going to modify the parameter?  I like it even better
if that's true.

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

Re: Certified C compilers for safety-critical embedded systems

[Stephen Leake]

iddw@hotmail.com (Dave Hansen) writes:

> On Wed, 31 Dec 2003 14:27:08 +0000 (UTC), Georg Bauhaus
> <sb463ba@l1-hrz.uni-duisburg.de> wrote:
> 
> Is the "'access" tag (or whatever you call it) _required_ on the call
> if a function is going to modify the parameter?  

Yes. Ada allows "in out" for procedure parameters, but not for
function parameters.

> I like it even better if that's true.

I don't. Why introduce pointers when "in out" would do the job!

Apparently there were some people on the design team for Ada 83 who
thought "function" meant "no side effects", and want to "enforce"
that. Of course, functions can have side effects; now they just have
to lie about it!

But it's not going to change :).

-- 
-- Stephe

Re: Certified C compilers for safety-critical embedded systems

[Martin Krischik]

Dave Hansen wrote:

> On Wed, 31 Dec 2003 14:27:08 +0000 (UTC), Georg Bauhaus
> <sb463ba@l1-hrz.uni-duisburg.de> wrote:
> 
>>In comp.lang.ada Dave Hansen <iddw@hotmail.com> wrote:
> 
> Note: I'm reading from comp.arch.embedded.  Just so you know where I'm
> coming from...
> 
>>:   while ( nextkey(&key) ) process(key);
>>: 
> [... "&" operator signals "nextkey" might modify the value of the
> parameter ...]
>>
>>Ada solution that addresses both & and the while(1) issue:
>>
>>procedure p is
>>
>>   function next_key (key_filled: access Character) return Boolean is
>>   separate;
>>
>>   procedure process (the_key: in out Character) is separate;
>>
>>
>>   key: aliased Character;
>>
>>begin
>>
>>   while next_key (key'access) loop
>>      process(key);
>>
>>   end loop;
>>
>>end p;
> 
> Thanks.  I like it, if I understand it.  ;-)
> 
> Is the "'access" tag (or whatever you call it) _required_ on the call

Its called an attribute. All sort of things can have attributes. i.E. the
Integer'Image () (function) attribute creates a String repesenting and
Integer.

> if a function is going to modify the parameter?  I like it even better
> if that's true.

For functions yes, procedures however have in, out, in out and access. The
difference between out and in out is interesting one. out means that the
data comes back but no data is passed in.

BZW: in, out and in out may or may not be implemented by the use of pointer.
The compiler will do what is best. i.E. for a char it might be better to
copy the char in and out instead passing a pointer. Especialy when a
register is available for parameter passing.

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Certified C compilers for safety-critical embedded systems

[Georg Bauhaus]

In comp.arch.embedded Dave Hansen <iddw@hotmail.com> wrote:
: On Wed, 31 Dec 2003 14:27:08 +0000 (UTC), Georg Bauhaus
: <sb463ba@l1-hrz.uni-duisburg.de> wrote:
: 
:>In comp.lang.ada Dave Hansen <iddw@hotmail.com> wrote:
: 
: Note: I'm reading from comp.arch.embedded.  Just so you know where I'm
: coming from...

Sorry. I need to adjust my reader software.

: Is the "'access" tag (or whatever you call it)

It's an attribute, like 'address, 'size, 'range, etc.

: Is the "'access" tag (or whatever you call it) _required_ on the call
: if a function is going to modify the parameter?  I like it even better
: if that's true.

Yes, as Stephen has explained. Let me add that if you want a variable
to be modifiably through some pointer you will have to say so.
You declare the variable aliased (using the "aliased" keyword
in the declaration), and point to it using 'access values.

There is also an 'unchecked_access attribute which allows pointers to
aliased local objects to be passed around. The intention is to remind
the programmer/maintainer of the pointer validity check that cannot
in general be done by the compiler as in the following example:

   type Reg16_Ptr is access all Interfaces.Unsigned_16;
   --  pointer to a 16 bit register


   function trig_reg return Reg16_Ptr is
      
      v: aliased Interfaces.Unsigned_16;
      --  16 bits from the toaster's eject trigger, v is local to function
      
      pragma Import(Ada, v);
      --  do not initialise v
      
      for v'address use System.Storage_Elements.To_Address(16#A022#);
      --  hardware address
   begin
      return v'unchecked_access;
      --  points to local v which is really a register, not a value on the
      -- stack
   end trig_reg;


-- Georg

Re: Certified C compilers for safety-critical embedded systems

[Frank J. Lhota]

"Stephen Leake" <Stephe.Leake@nasa.gov> wrote in message
news:mailman.212.1073342204.31149.comp.lang.ada@ada-france.org...
> Apparently there were some people on the design team for Ada 83 who
> thought "function" meant "no side effects", and want to "enforce"
> that. Of course, functions can have side effects; now they just have
> to lie about it!

AFAIK the following is completely valid Ada 83. Note how similar this is to
the examples presented to show why allowing "in out" parameters in functions
is a bad idea.

    type Integer_Acc is access Integer;

    X_Acc : Integer_Acc := new Integer'( 2 );
    Y : Integer;

    function Incr( Acc : in Integer_Acc ) return Integer is
    begin
       Acc.all := Acc.all + 1;
       return Acc.all;
    end Incr;

    ...

    Y := Incr( X_Acc ) - X_Acc.all;     -- Y is ???

Re: Certified C compilers for safety-critical embedded systems

[Jean-Pierre Rosen]

> "Stephen Leake" <Stephe.Leake@nasa.gov> wrote in message
> news:mailman.212.1073342204.31149.comp.lang.ada@ada-france.org...
> Apparently there were some people on the design team for Ada 83 who
> thought "function" meant "no side effects", and want to "enforce"
> that. Of course, functions can have side effects; now they just have
> to lie about it!
I've seen this argument quite often (especially by RBKD), but it is totally bogus.
Nobody claimed that functions should not have side effects, but only that functions compute a result given some parameters and the
global state of the program. It was felt that it was OK for a function to modify the global state, but modifying the parameters
would be surprising and error-prone.

BTW, Ada79 had functions that were required to not have side effects, and value returning procedures that did not have this
constraint. This was felt to be too extreme (or maybe difficult to enforce) and the current solution to be an acceptable trade-off.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Certified C compilers for safety-critical embedded systems

[Hyman Rosen]

Martin Krischik wrote:
> Its called an attribute. All sort of things can have attributes. i.E. the
> Integer'Image () (function) attribute creates a String repesenting and
> Integer.

This is the main feature which confounds attempts to use the C
preprocessor on Ada programs. It also confounds "ordinary" program
editors that believe single quotes should come in matched pairs.

Yet another obstacle for potential new users of Ada, who might want
to load up some Ada code in a non-Ada IDE to have a look at it.

Re: Certified C compilers for safety-critical embedded systems

[Kelly Hall]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1073409810.463948@master.nyc.kbcfp.com...
> This is the main feature which confounds attempts to use the C
> preprocessor on Ada programs. It also confounds "ordinary" program
> editors that believe single quotes should come in matched pairs.

As for the C preprocessor, why not use m4 instead?  Why would anyone want to
use the C preprocessor on Ada programs when there are other, better,
just-as-free, macro processors available?

As for smart editors that aren't smart enough, I'd suggest upgrading to
something smarter or downgrading to something dumber.  Emacs and vi should
both work fine.

> Yet another obstacle for potential new users of Ada, who might want
> to load up some Ada code in a non-Ada IDE to have a look at it.

Is it common for developers to have their programming language selection
determined by the limitations of their text editor?

If you want to argue against Ada, you should find a better argument than "my
editor is broken".

Kelly

Re: Certified C compilers for safety-critical embedded systems

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

> It also confounds "ordinary" program
>editors that believe single quotes should come in matched pairs.

Don't you think the single quote 's occurin' relatively common in the
English language, 'though it has another meaning there? So it
shouldn't be too hard to understand that they don't always come in
match'd pairs. Oh yes, I'm knowin'. Now I'm stretchin' it way too far,
don't I? :->


Vinzent.

Re: Certified C compilers for safety-critical embedded systems

[Martin Dowie]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1072806253.772580@master.nyc.kbcfp.com...
> Martin Krischik wrote:
> > I had my array start at 1 not 0. In C all numbers start with 0 but in
the
> > real world they usualy start with 1.
>
> The "real world" doesn't have arrays. Only computer programs do.

I must remember to tell my radar building biddies, who have (various types
of) antenna arrays... ;-)

Re: Certified C compilers for safety-critical embedded systems

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> Don't you think the single quote 's occurin' relatively common in the
> English language, 'though it has another meaning there?

And in visual basic, ' begins a comment which extends to end of line.
Your example of single quotes in English demonstrates that its use is
to indicate elided characters, which is not going to carry over to
someone trying to understand Ada.

Re: Certified C compilers for safety-critical embedded systems

[Georg Bauhaus]

In comp.lang.ada, ... Hyman Rosen <hyrosen@mail.com> wrote:

: It also confounds "ordinary" program
: editors that believe single quotes should come in matched pairs.

Like a VB editor?
How do "ordinary" program editors handle std::string s = "'"; ?
Or any string literal that has a single quote in it?
How about a < b?
Is it difficult to write Algol 60 programs in "ordinary" program
editors, then?

I think programming languages should not be designed solely
around the "beliefs" of "ordinary" program editors?


-- Georg

Re: Certified C compilers for safety-critical embedded systems

[Hyman Rosen]

Kelly Hall wrote:
> As for the C preprocessor, why not use m4 instead?  Why would anyone want to
> use the C preprocessor on Ada programs when there are other, better,
> just-as-free, macro processors available?

Because they already use the C preprocessor for C, and for IDL, and for
X Window resource files, and perhaps for other things, while they have
never even heard of m4. Because the configuration information with which
they hope to filter their Ada source code already exists in the form of
system header files in C preprocessor format.

> As for smart editors that aren't smart enough, I'd suggest upgrading to
> something smarter or downgrading to something dumber.  Emacs and vi should
> both work fine.

As I said, it's an obstacle. Obstacles aren't insurmountable, just annoying.

> Is it common for developers to have their programming language selection
> determined by the limitations of their text editor?

It's common for people to load up files in whatever editor they happen to
be using at the moment. The scattered single quotes are going to look funny,
and people are going to think it's an odd choice, once they realize that
quoted strings aren't being delimited.

> If you want to argue against Ada, you should find a better argument than "my
> editor is broken".

Why would I want to argue against Ada?

Re: Certified C compilers for safety-critical embedded systems

[tmoran]

>And in visual basic, ' begins a comment which extends to end of line.
>Your example of single quotes in English demonstrates that its use is
>to indicate elided characters, which is not going to carry over to
>someone trying to understand Ada.
the attribute mark "'" can be interpreted as standing for "'s "
  Integer'image() Integer's image()
  X'address       X's address
  A'range         A's [index] range    (why not A'domain?)

----

"War is in fact the true nurse of executive aggrandizement.  In war a
physical force is created, and it is the executive will to direct it.  In
war the public treasuries are to be unlocked, and it is the executive hand
which is to dispense them, In war the honors and emoluments of office are
to be multiplied and it is the executive patronage under which they are to
be employed.  It is in war finally that laurels are to be gathered, and it
is the executive brow they are to encircle.  The strongest passions and
the most dangerous weakness of the human breast - ambition, avarice,
vanity, the honorable or venial love of fame - are all in conspiracy
against the desire and duty of peace."  James Madison

Re: Certified C compilers for safety-critical embedded systems

[Alexandre E. Kopilovitch]

Jean-Pierre Rosen wrote:

> > Of course, functions can have side effects; now they just have
> > to lie about it!
> I've seen this argument quite often (especially by RBKD), but it is totally
> bogus. Nobody claimed that functions should not have side effects, but only
> that functions compute a result given some parameters and the global state
> of the program. It was felt that it was OK for a function to modify the
> global state, but modifying the parameters would be surprising and error-prone.

But the problematic cases are exactly those where a variable belonging to the
global state is passed by/represented as a parameter - and here the contradiction
appears: from one side it may be computed (changed) by the function as it is
a part of the global state, but from another side it shoudn't be changed by
the function as it is a parameter.

So I don't think that that argument is bogus, it has a real controversy as its
ground.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Alexandre E. Kopilovitch wrote:

> So I don't think that that argument is bogus, it has a real controversy as its
> ground.

Exactly.  Way back, going from Preliminary Ada to Ada 80, the decision 
was made to allow side-effects in functions, but not to allow parameters 
to be modified, using that name/view.  The Rosen trick is just a 
different way to get a non-constant view of a global passed as a 
parameter.  Notice that when the value passed is not a global variable 
(or a variable in an outer scope) the Rosen trick can be used, but it 
won't affect the caller's environment at all.  If what is passed is 
really a constant (and stored in the code section) the Rosen trick will 
cause a protection violation. (Of course, assuming that your OS marks 
code as readable and executable but not writable.)

If you really want to insure that a function doesn't modify its 
parameters, just pass expressions instead of names.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Stephen Leake]

"Jean-Pierre Rosen" <rosen@adalog.fr> writes:

> > "Stephen Leake" <Stephe.Leake@nasa.gov> wrote in message
> > news:mailman.212.1073342204.31149.comp.lang.ada@ada-france.org...
> > Apparently there were some people on the design team for Ada 83 who
> > thought "function" meant "no side effects", and want to "enforce"
> > that. Of course, functions can have side effects; now they just have
> > to lie about it!

> I've seen this argument quite often (especially by RBKD), but it is
> totally bogus. 

Hmm. You must be using some different meanings for the words "totally
bogus" than I do.

> Nobody claimed that functions should not have side effects, but only
> that functions compute a result given some parameters and the global
> state of the program. 

That's what procedures do as well; what's the difference? Oh, one of
the "out" parameters to a function is called the "result". Why should
that matter?

> It was felt that it was OK for a function to modify the global
> state, but modifying the parameters would be surprising and
> error-prone.

Surprising to you, perhaps. Not to me! It is surprising to me that I
_can't_ have "in out" in functions.

So the argument is _not_ _totally_ bogus. A little bogus, perhaps? I'd
prefer to say the argument is not universally accepted, or more
accuratly, not accepted by a majority of the Ada 83 and 95 teams.

> BTW, Ada79 had functions that were required to not have side
> effects, and value returning procedures that did not have this
> constraint. This was felt to be too extreme (or maybe difficult to
> enforce) and the current solution to be an acceptable trade-off.

I understand that was the decision reached. Obviously, I'd prefer the
Ada79 approach. Or provide a pragma (like Pure) that says "this
function has no side effects". I'm having a hard time understanding
what the downside of permitting me to use "in out" in functions is,
for those who don't want them. It doesn't cost them anything! We could
give them a compiler switch that forbids them if they want it.

-- 
-- Stephe

Re: Certified C compilers for safety-critical embedded systems

[Frank J. Lhota]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1073421950.964139@master.nyc.kbcfp.com...
> Kelly Hall wrote:
> > As for the C preprocessor, why not use m4 instead?  Why would anyone
want to
> > use the C preprocessor on Ada programs when there are other, better,
> > just-as-free, macro processors available?
>
> Because they already use the C preprocessor for C, and for IDL, and for
> X Window resource files, and perhaps for other things, while they have
> never even heard of m4.

But learning about m4 is a valuable exercise! It is a flexible and powerful
preprocessor with far more capabilities that the C preprocessor.

Re: Certified C compilers for safety-critical embedded systems

[Martin Krischik]

Stephen Leake wrote:

> I understand that was the decision reached. Obviously, I'd prefer the
> Ada79 approach. Or provide a pragma (like Pure) that says "this

Funny, but just today I read that GNAT does indeed have pragma
Pure_Function.

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Certified C compilers for safety-critical embedded systems

[Marin David Condic]

What exactly would be the meaning of:

A := Func_X (A) + Func_Y (A) ;

if functions had in-out parameters and A could be modified while 
evaluating the RHS? I suppose one might be able to come up with some 
evaluation rules that at least meant determinism for the end result, but 
staring at it would not make it intuitively obvious to even the most 
casual observer. Sure, the functions *could* modify A if they had 
visibility to the right scope, but how often does someone do that in 
real-world use? The current style - while not guaranteeing a lack of 
side effects - tends to discourage it and leads to more easily 
comprehended code.

I don't understand what the headache is here anyway. If one wants to 
modify parameters, use a procedure. If one wants some kind of 
math-oriented thingie to return a result, use a function. Only 
interfacing to squirly languages like C seems to be an issue - and I 
think that ought to be a difficult and painful thing to discourage it 
from happening. :-)

MDC

Jean-Pierre Rosen wrote:
> 
> I've seen this argument quite often (especially by RBKD), but it is totally bogus.
> Nobody claimed that functions should not have side effects, but only that functions compute a result given some parameters and the
> global state of the program. It was felt that it was OK for a function to modify the global state, but modifying the parameters
> would be surprising and error-prone.
> 
> BTW, Ada79 had functions that were required to not have side effects, and value returning procedures that did not have this
> constraint. This was felt to be too extreme (or maybe difficult to enforce) and the current solution to be an acceptable trade-off.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Certified C compilers for safety-critical embedded systems

[Dmitry A. Kazakov]

On Wed, 07 Jan 2004 12:56:36 GMT, Marin David Condic
<nobody@noplace.com> wrote:

>What exactly would be the meaning of:
>
>A := Func_X (A) + Func_Y (A) ;
>
>if functions had in-out parameters and A could be modified while 
>evaluating the RHS? I suppose one might be able to come up with some 
>evaluation rules that at least meant determinism for the end result, but 
>staring at it would not make it intuitively obvious to even the most 
>casual observer. Sure, the functions *could* modify A if they had 
>visibility to the right scope, but how often does someone do that in 
>real-world use? The current style - while not guaranteeing a lack of 
>side effects - tends to discourage it and leads to more easily 
>comprehended code.
>
>I don't understand what the headache is here anyway. If one wants to 
>modify parameters, use a procedure. If one wants some kind of 
>math-oriented thingie to return a result, use a function.

The headache is:

declare
   X : Y'Class := <no procedure allowed here!>;
   Z : String := <no procedure allowed here!>;

One wants:

A. to have an ability to return objects of unconstrained types
B. in design, to avoid side-effects not manifested by the parameters
C. in design, to avoid unnecessary use of pointers

A+B+C is that too much?

[ In any of the possible evaluation orders? I have an impression that
some people would agree with A, B, C, but not with A+B+C (:-)) ]

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Certified C compilers for safety-critical embedded systems

[Stephen Leake]

Marin David Condic <nobody@noplace.com> writes:

> What exactly would be the meaning of:
> 
> A := Func_X (A) + Func_Y (A) ;

> if functions had in-out parameters and A could be modified while
> evaluating the RHS? 

Obviously, this is erroneous code, since the result depends on the
order of evaluation. Note that it is legal Ada now, if A is an
access parameter. It is similarly erroneous if either Func_X or Func_Y
have other mutually-dependent side effects.

Ada usually tries to eliminate the possibility of such erroneous code.
But given all the ways this statement can be erroneous, I see very
little gain from forbidding "in out".

I guess that's the point of disagreement; how much gain or cost there
is in forbidding "in out".

> Sure, the functions *could* modify A if they
> had visibility to the right scope, but how often does someone do
> that in real-world use? 

All the time in my code, because I need to write reentrant code that
has state.

The canonical example is a random number generator:

function Random (Gen : in out Generator) return Float;

"Obviously", this should be a function (the C and Ada standards say so
:). Also "obviously", it needs to modify the state of the generator.
Not so obviously, that state needs to be stored in the parameter, so I
can call Random from several different threads.

Currently, in non-tricky, legal Ada 95, we cannot simultaneously
satisfy all of the above statements. The only one I'm free to change
is the first one; subprograms that modify state and are reentrant must
be procedures, not functions. (I include using "access" instead of "in
out" as "tricky" code).

All of the Ada 95 implementations must resort to "tricks" to implement
the standard Random. That seems "totally bogus" to me :).

> The current style - while not guaranteeing a lack of side effects -
> tends to discourage it and leads to more easily comprehended code.

Marginally more comprehendable, in some cases. Marginally less
comprehendable, in other cases. This is really a moot point, since we
have access parameters.

Why is making A "access" better than making A "in out"? The parameter
mode is supposed to indicate whether the parameter is modified or not.
It is _not_ supposed to indicate the parameter passing mechanism!

Using "access" instead of "in out" is a form of lying to the user; it
reduces comprehension.

> I don't understand what the headache is here anyway. If one wants to
> modify parameters, use a procedure. 

That is always possible. But why should I not have the choice of using
a function, if it fits the application better?

Why is Random a function?

> If one wants some kind of
> math-oriented thingie to return a result, use a function. 

But I want a function that modifies state in a reentrant way, like
Random does.

> Only interfacing to squirly languages like C seems to be an issue -
> and I think that ought to be a difficult and painful thing to
> discourage it from happening. :-)

Interfacing with C always requires a pragma, so 'pragma
Valued_Procedure' is perfectly reasonable here. I agree that is _not_
an argument for "in out" in functions.

-- 
-- Stephe

Re: Certified C compilers for safety-critical embedded systems

[Hyman Rosen]

Frank J. Lhota wrote:
> But learning about m4 is a valuable exercise! It is a flexible and powerful
> preprocessor with far more capabilities that the C preprocessor.

One of the things you can learn about m4 is that it has no way of
dealing specially with character strings, so if you're using it on
Ada programs and innocently want to do
     Text_IO.Put_Line("This is a UNIX system!");
you could very easily wind up with
     Text_IO.Put_Line("This is a 1 system!");

Re: Certified C compilers for safety-critical embedded systems

[Martin Dowie]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1073409810.463948@master.nyc.kbcfp.com...
> Martin Krischik wrote:
> > Its called an attribute. All sort of things can have attributes. i.E.
the
> > Integer'Image () (function) attribute creates a String repesenting and
> > Integer.
>
> This is the main feature which confounds attempts to use the C
> preprocessor on Ada programs. It also confounds "ordinary" program
> editors that believe single quotes should come in matched pairs.
>
> Yet another obstacle for potential new users of Ada, who might want
> to load up some Ada code in a non-Ada IDE to have a look at it.

I've never used it but what about the GNAT pre-processor (gnatprep?). Given
that it is a pre-processor for Ada (well GNAT Ada :-) it should be able to
handle everything.

Otherwise, you are surely using a knife when you need a spoon...

Re: Certified C compilers for safety-critical embedded systems

[Robert A Duff]

Stephen Leake <stephen_leake@acm.org> writes:

> The canonical example is a random number generator:
> 
> function Random (Gen : in out Generator) return Float;
> 
> "Obviously", this should be a function (the C and Ada standards say so
> :).

During the Ada 9X project, some folks suggested making it a procedure.
This was considered a non-starter, primarily because Fortran uses a
function, and that's what people expect.  It is rather strange that
(some of) the same language designers who choked at the idea of making
Random a procedure were adamant about forbidding 'in out' params.

There are all kinds of advantages to using functions over procedures.
One is that you can use a function to initialize an object, right at
the point of declaration.  Using a procedure is error prone, because
the initialization is far-separated from the declaration, and because
it requires making constants into variables.  Furthermore, some
kinds of subtypes *cannot* be initialized by procedures -- String,
for example.

Limiting the applicability of functions by forbidding 'in out'
is poor language design.  The programmer should be the one
to decide when side effects are appropriate.

The mistake is in thinking that Ada "functions" are the same thing as
maths "functions" -- they are not.  Ada functions are simply a procedure
with a different calling syntax.  IMHO, both kinds of subprograms should
have been called "procedures".

>... Also "obviously", it needs to modify the state of the generator.
> Not so obviously, that state needs to be stored in the parameter, so I
> can call Random from several different threads.

It is also possible to implement the generator as a private type that
has a pointer into the heap.  But then you need to horse around with
finalization in order to manage the memory.  And note that the generator
type cannot simply *be* a limited controlled type, because of the
accessibility rules -- more horsing around.

- Bob

Re: Certified C compilers for safety-critical embedded systems

[Alexandre E. Kopilovitch]

Robert A Duff wrote:

> Ada functions are simply a procedure with a different calling syntax.

>From a compiler writer's viewpoint - perhaps yes. But certainly not from
programmer's viewpoint - if that programmer has and uses a brain (that is,
not just eyes and fingers). There is a well-known fact that human brain tends
to differentiate between result-oriented and "good next step" approaches, and
this has nothing specifically mathematical. Anyway, returning to programming,
I suppose you will not claim that there is absolutely no difference (except
syntax) between functional and procedural programming languages.

>  IMHO, both kinds of subprograms should have been called "procedures".

I think that these both kinds of subprograms are already called "subprograms",
so there is no need for another common name for them.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Certified C compilers for safety-critical embedded systems

[Dmitry A. Kazakov]

On Thu,  8 Jan 2004 06:32:05 +0300 (MSK), "Alexandre E. Kopilovitch"
<aek@VB1162.spb.edu> wrote:

>Robert A Duff wrote:
>
>> Ada functions are simply a procedure with a different calling syntax.
>
>>From a compiler writer's viewpoint - perhaps yes. But certainly not from
>programmer's viewpoint - if that programmer has and uses a brain (that is,
>not just eyes and fingers). There is a well-known fact that human brain tends
>to differentiate between result-oriented and "good next step" approaches, and
>this has nothing specifically mathematical. Anyway, returning to programming,
>I suppose you will not claim that there is absolutely no difference (except
>syntax) between functional and procedural programming languages.

That would be a point only if you were arguing for pure functions. Do
you? But that was not the design goal, as many have pointed, alas.

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Certified C compilers for safety-critical embedded systems

[Scott Moore]

"safety critical C" is an oxymoron if I ever heard one.

Re: Certified C compilers for safety-critical embedded systems

[Scott Moore]

"> > As for smart editors that aren't smart enough, I'd suggest upgrading to
> > something smarter or downgrading to something dumber.  Emacs and vi should
> > both work fine.
>
> As I said, it's an obstacle. Obstacles aren't insurmountable, just annoying.
>
> > Is it common for developers to have their programming language selection
> > determined by the limitations of their text editor?
>
> It's common for people to load up files in whatever editor they happen to
> be using at the moment. The scattered single quotes are going to look funny,
> and people are going to think it's an odd choice, once they realize that
> quoted strings aren't being delimited.
>

I  put a single quote line into codewright just now. It turns the rest of the line red.
Big deal. Get a new editor.

Re: Certified C compilers for safety-critical embedded systems

[Frank J. Lhota]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcc65fn9vtb.fsf@shell01.TheWorld.com...
> During the Ada 9X project, some folks suggested making it a procedure.
> This was considered a non-starter, primarily because Fortran uses a
> function, and that's what people expect.  It is rather strange that
> (some of) the same language designers who choked at the idea of making
> Random a procedure were adamant about forbidding 'in out' params.

Was there any discussion of using access types, i.e.

    function Random (Gen : access Generator) return Result_Subtype;

This would require that each generator is aliased, and that 'Access
attributes be used, but at least this would give some recognition to the
fact that the generator is changed by the call.

> There are all kinds of advantages to using functions over procedures.
> One is that you can use a function to initialize an object, right at
> the point of declaration.  Using a procedure is error prone, because
> the initialization is far-separated from the declaration, and because
> it requires making constants into variables.  Furthermore, some
> kinds of subtypes *cannot* be initialized by procedures -- String,
> for example.
>
> Limiting the applicability of functions by forbidding 'in out'
> is poor language design.  The programmer should be the one
> to decide when side effects are appropriate.
>
> The mistake is in thinking that Ada "functions" are the same thing as
> maths "functions" -- they are not.  Ada functions are simply a procedure
> with a different calling syntax.  IMHO, both kinds of subprograms should
> have been called "procedures".
>
> >... Also "obviously", it needs to modify the state of the generator.
> > Not so obviously, that state needs to be stored in the parameter, so I
> > can call Random from several different threads.
>
> It is also possible to implement the generator as a private type that
> has a pointer into the heap.  But then you need to horse around with
> finalization in order to manage the memory.  And note that the generator
> type cannot simply *be* a limited controlled type, because of the
> accessibility rules -- more horsing around.
>
> - Bob

Re: Certified C compilers for safety-critical embedded systems

[Hyman Rosen]

Scott Moore wrote:
> Big deal. Get a new editor.

And that's certainly something they would do if they decided
to use Ada.  But I was talking about casual first impressions.
There was a thread here a while ago claiming that Ada was easy
to read and that no odd surprises lurk in the syntax, unlike C
and its ilk. This is a counterexample.

Re: Certified C compilers for safety-critical embedded systems

[Hyman Rosen]

Scott Moore wrote:
> "safety critical C" is an oxymoron if I ever heard one.

Ariane 5! Ariane 5! Nyah nyah! Nyah nyah!

Re: Certified C compilers for safety-critical embedded systems

[Martin Krischik]

Hyman Rosen wrote:

> Scott Moore wrote:
>> "safety critical C" is an oxymoron if I ever heard one.
> 
> Ariane 5! Ariane 5! Nyah nyah! Nyah nyah!

That wasn't a programing bug - that was a management bug!

The managent decided to use the Ariane 4 software on the Ariane 5. They
wanted to save the money on developing *and* testing a new software
release.

No programer had been asked if the Ariane 4 software was suitable for the
Ariane 5. The software was not run thrue a test suit - not even once.

Fatal since it was no sporatic problem. It was a 100% allways problem:
Ariane 4 is a vertical lift off, the software was designed for vertical
lift off. Ariane 5 is a tilted lift off.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Certified C compilers for safety-critical embedded systems

[Robert A Duff]

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> writes:

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
> news:wcc65fn9vtb.fsf@shell01.TheWorld.com...
> > During the Ada 9X project, some folks suggested making it a procedure.
> > This was considered a non-starter, primarily because Fortran uses a
> > function, and that's what people expect.  It is rather strange that
> > (some of) the same language designers who choked at the idea of making
> > Random a procedure were adamant about forbidding 'in out' params.
> 
> Was there any discussion of using access types, i.e.
> 
>     function Random (Gen : access Generator) return Result_Subtype;
> 
> This would require that each generator is aliased, and that 'Access
> attributes be used, but at least this would give some recognition to the
> fact that the generator is changed by the call.

As far as I can remember, this idea was considered, and was generally
thought to be ugly.  I mean, suppose you're trying to convince a Fortran
programmer to use Ada for numerics stuff.  If you start babbling about
aliased and 'Access when there is no inherent need for pointers,
they're going to laugh, and rightly so.

It would boil down to this rule: "All variables of type Generator must
be declared aliased, for reasons only some crazy language lawyer types
can explain."

The random number package was designed to be easy to use.  Introducing
pointers, or making Random a procedure, were thought to be annoyances.

- Bob

Re: Certified C compilers for safety-critical embedded systems

[Robert A Duff]

"Alexandre E. Kopilovitch" <aek@VB1162.spb.edu> writes:

> Robert A Duff wrote:
> 
> > Ada functions are simply a procedure with a different calling syntax.
> 
> >From a compiler writer's viewpoint - perhaps yes.

I'm not talking about the compiler writer.

>... But certainly not from
> programmer's viewpoint - if that programmer has and uses a brain (that is,
> not just eyes and fingers). There is a well-known fact that human brain tends
> to differentiate between result-oriented and "good next step" approaches, and
> this has nothing specifically mathematical. Anyway, returning to programming,
> I suppose you will not claim that there is absolutely no difference (except
> syntax) between functional and procedural programming languages.

No, I don't claim that, although at some level they are equivalent;
you can convert a procedural program into a functional one by adding
a lot of parameter passing.

My point was just that Ada's functions are *not* functions in the
functional programming sense.  Calling them "function" is therefore
misleading.

I *do* claim that both of the following compute the same mathematical
function:

    function F(X: Integer) return Integer is
    begin
        return X**2;
    end F;

    function P(X: Integer; Result: out Integer) is
    begin
        Result := X**2;
    end P;

but use different notations at the call site.

The Oz language makes these issues a bit clearer, I think.
It has a pure-functional subset that allows either notation!
Interesting.

Now, if Ada had a way to declare pure functions, enforced by the
compiler, then I wouldn't mind calling them functions.  But that's not
what Ada's functions are.

> >  IMHO, both kinds of subprograms should have been called "procedures".
> 
> I think that these both kinds of subprograms are already called "subprograms",
> so there is no need for another common name for them.

I'm not suggesting "another" name.  I'm suggesting that a *single* name
would suffice, where Ada has three names: function, procedure,
subprogram.

- Bob

Re: Certified C compilers for safety-critical embedded systems

[Georg Bauhaus]

Robert A Duff <bobduff@shell01.theworld.com> wrote:
: I'm not suggesting "another" name.  I'm suggesting that a *single* name
: would suffice, where Ada has three names: function, procedure,
: subprogram.

I seem to remember "funtion procedures" from old SNOBOL4 books :-)


-- Georg

Re: Certified C compilers for safety-critical embedded systems

[Dave Hansen]

On Thu, 08 Jan 2004 10:18:12 GMT, "Scott Moore" <samiam@moorecad.com>
wrote:

[...]
>I  put a single quote line into codewright just now. It turns the rest of the line red.
>Big deal. Get a new editor.

Umm, CodeWright has an Ada lexer.  Not very sophisticated, but it
solves this problem.  When I put the function using "key'access" in a
junk.ada buffer, the "access" is highlighted as a keyword, and the
apostrophe (single-quote) is black.  

The biggest problem is that it doesn't differentiate well between
functions, simple variables, and arrays: An identifier followed by a
paren is highlighted as a function, otherwise it's black (default).
More sophisticated behavior would require a symbol table -- I think
CodeWright's language lexers are not much (if any) more sophisticated
than regular expressions.

If that's all too confusing, you can turn coloring off if you so
desire.  In any case, I don't think you need a whole new editor -- At
least, not if you start with the right one.

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

Re: Certified C compilers for safety-critical embedded systems

[Alexandre E. Kopilovitch]

Dmitry A. Kazakov wrote:

> > There is a well-known fact that human brain tends
> >to differentiate between result-oriented and "good next step" approaches, and
> >this has nothing specifically mathematical. Anyway, returning to programming,
> >I suppose you will not claim that there is absolutely no difference (except
> >syntax) between functional and procedural programming languages.
>
>That would be a point only if you were arguing for pure functions. Do
>you?

No. I'm against over-emphasising of "purity" for functions on the basis of
analogy with functions in mathematics.

A mathematical function is an abstraction, and it is very safe and thoroughly
guarded abstraction, while in programming nothing can be so abstract, and
therefore nothing can be (or should be) so "pure". For example (perhaps
somehow exotic, but nevertheless quite real), you can't entirely avoid
side-effects even if you use pure (in the programming sense) function: your
function does not change by itself anything in global space, but it just takes
some processor time for computation, and because of this some another task
reaches a particular point slightly later - and your whole program/system
loses significant data or even crashes or stalls.

So, my point is that the general notion of function in general-purpose
programming language should be a reasonable approximation of its mathematical
model, but not an attempt of exact translation of that mathematical notion
into programming. In general-purpose (and procedural) programming language
this notion should be placed somehow between that "pure" mathematical model
and the vague, but no less valuable notion of result-oriented subprogram.
It is for language designers to determine the exact position of the notion
within this range.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Certified C compilers for safety-critical embedded systems

[Kenneth Almquist]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
> During the Ada 9X project, some folks suggested making [the random
> number generator subprogram be] a procedure.
> This was considered a non-starter, primarily because Fortran uses a
> function, and that's what people expect.  It is rather strange that
> (some of) the same language designers who choked at the idea of making
> Random a procedure were adamant about forbidding 'in out' params.

A quote about eating your own dog food comes to mind here...

It's not just expectations created by other languages which are a
problem here.  A few years ago I wrote a package which looked in
part like:

    package Buffered_IO is

       type Buffered_Input is tagged abstract limited private;

       -- A buffered input object reads data in large blocks for
       -- efficiency, similar to the C standard I/O library or the
       -- C++ "istream" type.  To read an input source, you first
       -- declare and initialize a type derived from Buffered_Input;
       -- The details of how you do this depend on where the data
       -- is coming from; see the child packages of Buffered_IO for
       -- details.  However, once an input source is opened, you can
       -- read it like you would expect:

       procedure Get(File : in out Buffered_Input'class;
                     Item : out Character);
       pragma inline(Get);
       procedure Get(File : in out Buffered_Input'class;
                     Item : out String);
       function End_Of_File(File : in out Buffered_Input'class)
                           return Boolean;

Oops, that last declaration is illegal.  But am I seriously going to
ask Ada programmers to write code like:

       loop
          End_Of_File(Input, EOF);
       exit when EOF;
          ...
       end loop;

I don't think so.  So I changed the paramter mode of End_Of_File to "in",
and used by GNAT to implement Ada.Numerics.Discrete_Random to allow the
parameter to be used like an "in out" parameter.
				Kenneth Almquist

Re: Certified C compilers for safety-critical embedded systems

[Hyman Rosen]

Alexandre E. Kopilovitch wrote:
> No. I'm against over-emphasising of "purity" for functions on the basis of
> analogy with functions in mathematics.

This is the worst mistake in computing that is made by people who are really
smart. They get so caught up on their analogies and metaphors that they forget
that programming is not the analogous object. It is its own very unique form
of expression, and treating it as if it were exactly something else leads to
error and inconvenience. You see the same sort of thing in object-oriented
programming debates, not just in Ada with respect to functions with in/out
parameters. The way Eiffel was ruined by covariance is another example.

Re: Certified C compilers for safety-critical embedded systems

[Alexandre E. Kopilovitch]

Robert A Duff wrote:

> > I suppose you will not claim that there is absolutely no difference (except
> > syntax) between functional and procedural programming languages.
>
> No, I don't claim that, although at some level they are equivalent;

Certainly - at some level they are, but from another angle they aren't.

> you can convert a procedural program into a functional one by adding
> a lot of parameter passing.

Yes... but I'd put it in other words: by wasting a lot of time and effort -;)

> My point was just that Ada's functions are *not* functions in the
> functional programming sense.

Certainly yes, they aren't.

>  Calling them "function" is therefore misleading.

No. It may be misleading for little schoolgirls and for computer science
students, pity for them. but for nobody else. The main association for notion
of function is presence of explicit single result. All other is secondary and
may vary according to local conventions. Note that the word "function" was
used (before programming emerged) outside of mathematics (or physics) quite
heavily, and those functions certainly weren't "pure". And that is what I'd
like to say: the notion of function in programming inherits from both
mathematical and non-mathematical meanings, and is used for reflecting them
both.
 
> I'm not suggesting "another" name.  I'm suggesting that a *single* name
> would suffice, where Ada has three names: function, procedure,
> subprogram.

So try "subprogram" as that single name, and perhaps you'll see the result
better then if you imagine "procedure" there. 




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Certified C compilers for safety-critical embedded systems

[Mark Lorenzen]

Marin David Condic <nobody@noplace.com> writes:

> It would seem intuitively obvious to even the most casual observer
> that if you're not sure what a thing is *supposed* to do, you can't
> possibly be sure that it does it.  Unfortunately, this lesson is often
> learned at great financial (and sometimes human) expense.
>
> MDC

Indeed. I am a big proponent of formal methods and mathematical
proofs. But using these tools makes it even more important to get the
requirements correct, sound and complete.

- Mark Lorenzen

>
> Robert I. Eachus wrote:
>> The Airbus 320 should bury the idea that theorem provers can result
>> in safe software.  In the case of the Airbus 320 what happened was
>> that the formal logic used for stating the requirements/theorems was
>> relatively opaque to experts in the field (read pilots).  So the
>> flaws in the requirements, and later about 500 people, were buried
>> by that opacity.
>>
>
>
> -- 
> ======================================================================
> Marin David Condic
> I work for: http://www.belcan.com/
> My project is: http://www.jsf.mil/NSFrames.htm
>
> Send Replies To: m   o   d   c @ a   m   o   g
>                     c   n   i       c   .   r
>
>      "Face it ladies, its not the dress that makes you look fat.
>      Its the FAT that makes you look fat."
>
>          --  Al Bundy
>
> ======================================================================

Re: Certified C compilers for safety-critical embedded systems

[Vinzent 'Gadget' Hoefler]

Dave Hansen wrote:

>The biggest problem is that it doesn't differentiate well between
>functions, simple variables, and arrays: An identifier followed by a
>paren is highlighted as a function, otherwise it's black (default).

What's wrong with that? Arrays are just (constant) functions. ;-)
There's no difference between a function that actually calculates
something and its precomputed equivalent called array or - to be more
precise - lookup-table.


Vinzent.

Re: Certified C compilers for safety-critical embedded systems

[Mark Lorenzen]

Leif Roar Moldskred <rmoldskr+usenet@online.no> writes:

> tmoran@acm.org writes:
>
>>   Specification: the program will print, on January 30, 2004, the name
>> of the President of the United States on January 30, 2005.
>>   That wasn't a hard spec to write - I await your implementation. ;)
>
> In pseudo-code:
>
> PRINT ( "There will be no President of the United States on January 30th, 2005" )
> FOR EACH name in set_of_candidates_for_president DO
>   PRINT( "The President of the United States on January 30th, 2005 will be " )
>   PRINT( name )
> DONE
>
> Now, if your specification had explicitly stated that the program should print 
> out _only_ the name of the person who will be president of the United States
> on January 30th, 2005, it would have been harder.
>
> -- 
> Leif Roar Moldskred
> Got Sfik?

Beautiful example showing that the "Print_President_Name" function was
underspecified. In this case the original specification made implicit
use of some knowledge in the domain. This is often (allways?) the case
with texual descriptions and specifications and is probably one of the
causes that it is so difficult to write formal specifications. The
math itselt is not difficult (at least not on the "user level"), but
remembering all the necessary statements about the domain and the
problem is.

- Mark Lorenzen

In-Out Parameters for functions (was: Re: Certified C compilers for safety-critical embedded systems

[Marin David Condic]

Yeah, but as far as I can tell C always had "in only" parameters and 
everything was a function returning a result. The only way you could get 
"in out" mode was passing addresses (indistinguishable to the garden 
variety programmer from a 'Access) and of course dealing with all the 
errors that resulted from no checking that a parameter actually was an 
address. Such a setup didn't seem to hurt C with respect to popularity 
or getting Fortran programmers to understand it.

I'm ambivalent about "in out" for functions. I've never found it 
difficult to use functions just the way they are and can't think of a 
case where in-out would have helped me with a real world problem. The 
only example anyone ever seems to cite is the Random Number Generator 
leading me to think that maybe this *is* the only instance in which it 
is genuinely useful. OTOH, I could see how they might be included and 
not impact my life one iota. If you don't need it, you don't use it. 
Except that possibly it casts into doubt what happens in an expression 
loaded with function calls where one used to be able to assume that the 
parameters were not being modified. With in-out you'd have to know the 
parameter modes before you could interpret what the expression was doing.

MDC



Robert A Duff wrote:
> 
> As far as I can remember, this idea was considered, and was generally
> thought to be ugly.  I mean, suppose you're trying to convince a Fortran
> programmer to use Ada for numerics stuff.  If you start babbling about
> aliased and 'Access when there is no inherent need for pointers,
> they're going to laugh, and rightly so.
> 



-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Certified C compilers for safety-critical embedded systems

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> What's wrong with that? Arrays are just (constant) functions. ;-)
> There's no difference between a function that actually calculates
> something and its precomputed equivalent called array or - to be more
> precise - lookup-table.

Except that arrays are not constant. What is the advantage of concealing
from the reader of the code that an array reference is occurring? This is
just another one of those places where dumb theory was used in the place
of practical language design.

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Frank J. Lhota wrote:

> Was there any discussion of using access types, i.e.
> 
>     function Random (Gen : access Generator) return Result_Subtype;
> 
> This would require that each generator is aliased, and that 'Access
> attributes be used, but at least this would give some recognition to the
> fact that the generator is changed by the call.

Actually, and I think more interesting, was that we discussed making the 
generator parameter implicit, and having a per task generator value.

That idea was dropped because some people thought it would make calls to 
Random slower, and others were worried that it would force all compilers 
to support per task variables.  Per task variables did make it into Ada 
9X, but there is no standard way to use them with random number 
generators. I keep promising myself that someday I will have to write a
generic that does that, but it seems like using a sledgehammer to swat a 
fly.  Every time the issue comes up, it is easier to create a new 
generator object inside each task.

But notice that having a "default" generator would be either error prone 
in the presense of tasking, or slow because references would have to be 
via a protected object whether or not a program used random numbers in 
more than one task.  We avoided that mistake, and not by accident.  But 
it does create this anomaly that the "normal" random number generator 
interface does have this weird side effect on its parameter.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Hyman Rosen wrote:

> Scott Moore wrote:
> 
>> "safety critical C" is an oxymoron if I ever heard one.
> 
> 
> Ariane 5! Ariane 5! Nyah nyah! Nyah nyah!

In every group that I participated in that ever discussed issues of code 
reuse from a systems perspective, the fact that an M1A1 tank was not an 
M1 tank was discussed.  (Substitute F-15 and F-15E for Air Force 
sponsored groups and so on.) The result, of course is that you may be 
able to reuse much of the code, but you CANNOT reuse the requirements 
analysis.  And if the requirements change, then the testing has to 
change. So even if you can reuse 100% of the code, that only saves 15% 
of the overall software costs.  Library reuse works on the other hand, 
but you have to invest in building the library independent of an 
particular development project.  If a reuse library contains software 
that matches your requirements, then you have a component that solves 
part of your problem and does not require a new test plan, test suite, 
and testing.  (You still need to perform system test however.)

Arianne 501 crashed because the bean counters tried to do software reuse 
without repeating the requirements analysis, and later cut out all 
system testing.  Oops!  Incidently the subsequent Arianne 5 failures 
followed almost identical fault trees, but they did not involve Ada code.


-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Hyman Rosen]

Robert I. Eachus wrote:
> Arianne 501 crashed because...

Yes, I know. But I'm also pretty sure that there's lots of
safety-critical code that's written in C. If someone is
going to mouth off with ignorant comments about C, I want
to make sure that I mouth off with ignorant comments about
Ada.

Re: Certified C compilers for safety-critical embedded systems

[CBFalconer]

Hyman Rosen wrote:
> Robert I. Eachus wrote:
> 
> > Arianne 501 crashed because...
> 
> Yes, I know. But I'm also pretty sure that there's lots of
> safety-critical code that's written in C. If someone is going to
> mouth off with ignorant comments about C, I want to make sure
> that I mouth off with ignorant comments about Ada.

Neither of which is very helpful.  You might do well to recognize
that Ada has been designed to detect Stupid Human Tricks as far as
practicable, while C is designed to allow SHTs anywhere that they
are not demonstrably and immediately fatal.  At the same time I
expect Scott Moore has more experience with strongly typed and
relatively safe languages than you do.  I may be wrong.

Given a choice of two airline pilots, would you choose the one
whose sole experience has been stunt-flying and racing, or the one
who has been captaining an airliner without incident for a similar
length of time?  Would you alter your choice if 

 a) You want to get there in one piece or 
 b) You have to get there yesterday to prevent disaster or 
 c) Only one is available.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

Re: Certified C compilers for safety-critical embedded systems

[Hyman Rosen]

CBFalconer wrote:
 > Ada has been designed...

That does not make safety-critical C an "oxymoron".

Re: Certified C compilers for safety-critical embedded systems

[Robert A Duff]

Hyman Rosen <hyrosen@mail.com> writes:

> Alexandre E. Kopilovitch wrote:
> > No. I'm against over-emphasising of "purity" for functions on the basis of
> > analogy with functions in mathematics.
> 
> This is the worst mistake in computing that is made by people who are really
> smart. They get so caught up on their analogies and metaphors that they forget
> that programming is not the analogous object. It is its own very unique form
> of expression, and treating it as if it were exactly something else leads to
> error and inconvenience. You see the same sort of thing in object-oriented
> programming debates, not just in Ada with respect to functions with in/out
> parameters. The way Eiffel was ruined by covariance is another example.

I think I see what you're saying, but I don't understand the point about
Eiffel.  Please explain.

- Bob

Re: Certified C compilers for safety-critical embedded systems

[Robert A Duff]

"Alexandre E. Kopilovitch" <aek@VB1162.spb.edu> writes:

> Robert A Duff wrote:
> >  Calling them "function" is therefore misleading.
> 
> No. It may be misleading for little schoolgirls and for computer science
> students, pity for them. but for nobody else.

Well, it seems to mislead a lot of people into thinking that functions
should not have 'in out' parameters.  ;-)

>... The main association for notion
> of function is presence of explicit single result.

True, although there are a few languages that allow functions to return
multiple results.

>... All other is secondary and
> may vary according to local conventions. Note that the word "function" was
> used (before programming emerged) outside of mathematics (or physics) quite
> heavily, and those functions certainly weren't "pure".

That's a good point.  As in, "the function of a car is to provide
transportation."

> So try "subprogram" as that single name, and perhaps you'll see the result
> better then if you imagine "procedure" there. 

I don't much like the term "subprogram".  I'm not sure I can explain
why.

- Bob

Re: In-Out Parameters for functions (was: Re: Certified C compilers for safety-critical embedded systems

[Robert A Duff]

Marin David Condic <nobody@noplace.com> writes:

> Yeah, but as far as I can tell C always had "in only" parameters and
> everything was a function returning a result. The only way you could get
> "in out" mode was passing addresses (indistinguishable to the garden
> variety programmer from a 'Access) and of course dealing with all the
> errors that resulted from no checking that a parameter actually was an
> address. Such a setup didn't seem to hurt C with respect to popularity
> or getting Fortran programmers to understand it.

I've heard a lot of Fortran programmers complaining about C!

> I'm ambivalent about "in out" for functions. I've never found it
> difficult to use functions just the way they are and can't think of a
> case where in-out would have helped me with a real world problem. The
> only example anyone ever seems to cite is the Random Number Generator
> leading me to think that maybe this *is* the only instance in which it
> is genuinely useful.

It's a good example because it's familiar -- it's in the RM.

I can think of several other examples.  How about this one:

    function Get_Line(F: in out File) return String;

You can't make that a procedure, because Get_Line itself needs to
determine the length of the result, and 'out' parameters don't work that
way.  And even if they did, it's kind of nice to be able to say:

    X: constant String := Get_Line(F);

>... OTOH, I could see how they might be included and
> not impact my life one iota. If you don't need it, you don't use
> it.

I agree with that philosophy.  It is not the job of the language
designer to prevent people from doing evil things.  It is the job of the
language designer to prevent people from doing evil things *by
accident*.  You're not likely to declare 'in out' parameters by
accident, so it's fine to let the programmer decide when to use it.
(Probably not very often -- *most* functions should be free of side
effects.)

Except, as you say:

>... Except that possibly it casts into doubt what happens in an
> expression loaded with function calls where one used to be able to
> assume that the parameters were not being modified. With in-out you'd
> have to know the parameter modes before you could interpret what the
> expression was doing.

That's a good point, too.  You can't get any advantage out of having
side-effect-free functions unless you (the reader of the program) can
somehow *know* that they are side-effect-free.

I would be in favor of marking 'in out' and 'out' with some syntax at
the call site.  I would also be in favor of marking calls syntactically
if they have side effects on global variables.  But none of that has
anything to do with Ada (although there was an *optional* way to mark
'[in] out' in Green).

> MDC
> 
> Robert A Duff wrote:
> > As far as I can remember, this idea was considered, and was generally
> > thought to be ugly.  I mean, suppose you're trying to convince a Fortran
> > programmer to use Ada for numerics stuff.  If you start babbling about
> > aliased and 'Access when there is no inherent need for pointers,
> > they're going to laugh, and rightly so.

A: So I know what you're talking about without looking ahead.
Q: Why is top-posting a bad idea?
;-)

- Bob

Re: Certified C compilers for safety-critical embedded systems

[Robert A Duff]

Hyman Rosen <hyrosen@mail.com> writes:

> Robert I. Eachus wrote:
> > Arianne 501 crashed because...
> 
> Yes, I know. But I'm also pretty sure that there's lots of
> safety-critical code that's written in C.

Yes, of course.  There's plenty of hyperbole on usenet -- folks say
"X is impossible and Y is perfect" when the truth is,
"Y is better than X for certain purposes".

It's interesting that there are actually *very* few disasters caused by
the malfunction of safety-critical software (in *any* language).  At
least, compared to the number of malfunctions in software I use every
day on my desk.  Language is important, but it is far from the *only*
issue in ensuring safety.  And airplanes are not dropping out of the
sky all the time.

>... If someone is
> going to mouth off with ignorant comments about C, I want
> to make sure that I mouth off with ignorant comments about
> Ada.

;-)

This vaguely reminds me of the usenet game of "trolling", where one
tries to trick one's opponents into thinking oneself is a blithering
idiot.  I don't get it -- how can anybody get satisfaction out of that?

At least you said "nyah nyah" to let us know you were being sarcastic.

Sorry, this is getting off topic.  I'll shut up now.

- Bob

Re: Certified C compilers for safety-critical embedded systems

[Robert A Duff]

"Robert I. Eachus" <rieachus@comcast.net> writes:

[stuff about random number generator]

Note that Robert Eachus is truly an expert on random number issues.
I wouldn't know a good random-number generation algorithm if it bit
me on the behind.  ;-)  And I don't use them in my work.  I (and others)
were just using the "random" function as an example of a function that
returns a sequence, one at a time, where we believe it's OK to have
side effects (i.e. it's OK that the function returns a different value
each time it's called).

- Bob

Re: In-Out Parameters for functions (was: Re: Certified C compilers for safety-critical embedded systems

[Alexandre E. Kopilovitch]

Robert A Duff wrote:

> >... Except that possibly it casts into doubt what happens in an
> > expression loaded with function calls where one used to be able to
> > assume that the parameters were not being modified. With in-out you'd
> > have to know the parameter modes before you could interpret what the
> > expression was doing.
>
> That's a good point, too.  You can't get any advantage out of having
> side-effect-free functions unless you (the reader of the program) can
> somehow *know* that they are side-effect-free.
>
> I would be in favor of marking 'in out' and 'out' with some syntax at
> the call site.
>...

Let me put here two my messages to Ada-Comment, which were sent there more
than a year ago (November 2002, I think) - they were exactly about this topic,
and the second of them even contains concrete proposal for syntax mark at the
call site.

----- 1 ------------------------------------------------------------------

>I do not believe it can possibly get consensus support.

Lacking a list of arguments against IN OUT in functions, I only guess that
perhaps following restrictions will satisfy the opponents:

1) function with IN OUT parameter cannot be operator (and cannot be renamed
   to operator)
2) actual argument for IN OUT formal parameter cannot be used in any place
   within the whole statement.

>functions aren't really functions in Ada, no matter how much
>some people :-) would like to think that.

Well, even in pure mathematics functions sometimes have effectively OUT
parameters - when used in equations (with a suitable form of equation it is
possible to simulate IN OUT parameter also).

----- 2 ------------------------------------------------------------------

>> perhaps following restrictions will satisfy the opponents:
>> 
>> 1) function with IN OUT parameter cannot be operator (and cannot be renamed
>>    to operator)
>> 2) actual argument for IN OUT formal parameter cannot be used in any place
>>    within the whole statement.
>
>You guess completely wrong,

Not so completely - it appears that the above restrictions actually address
some of those old objections.

> you should really make an effort to dig up
>the old threads on this subject.

I just did that. I found 5 files in old Ada-Comment archive:

   http://archive.adaic.com/standards/95com/mrtcomments/

namely: 94.0817, 94.0818, 94.0819, 94.0821, 94.0907, relevant to the OUT
parameters for functions. I assume that those files cover that old discussion
(if I missed something important and there are other relevant files then I
hope somebody will point me at them).

  It appears that most often stated objection against lifting the restriction
(OUT/IN OUT parameters for functions) was simply "too late" (meaning some
schedule of the Ada9X project) - I found 3 persons saying that. Obviously,
today that kind of objection is "void and null".

  Among the essential objections some are fully covered by the proposed
restrictions (above). Another is about totally unspecified fantom danger
(it is about overloading). And only one seems still valid: it is about
complex expressions where a function call may be used as an actual argument
for another function. I believe that that objection will be covered by the
following 3rd rule for IN OUT parameters for functions:

3) in a function call, an actual argument that corresponds to IN OUT formal
   parameter must be a variable, and must be preceeded by the keyword VAR.

For example:

  X := Random(var Y);

With this rule any confusion becomes improbable, and readability flourishes.

>The objection is that IN OUT parameters are fundamentally inappropriate
>for functions.

Apparently that "fundamentally inappropriate" disintegrates into several
objections, and they are covered by the proposed 3 rules - I repeat them here
together:

1) function with IN OUT parameter cannot be operator (and cannot be renamed
   to operator)
2) actual argument for IN OUT formal parameter cannot be used in any place
   within the whole statement.
3) in a function call, actual argument that corresponds to IN OUT formal
   parameter must be a variable, and must be preceeded by the keyword VAR.

--------------------------------------------------------------------------




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Certified C compilers for safety-critical embedded systems

[Larry Kilgallen]

In article <hYudnRZ2b6gYQGOi4p2dnA@comcast.com>, "Robert I. Eachus" <rieachus@comcast.net> writes:

> Arianne 501 crashed because the bean counters tried to do software reuse 
> without repeating the requirements analysis, and later cut out all 
> system testing.

From another point of view, they just opened the system testing process
up to the public view :-)

Re: Certified C compilers for safety-critical embedded systems

[Georg Bauhaus]

Hyman Rosen <hyrosen@mail.com> wrote:
: 
: What is the advantage of concealing
: from the reader of the code that an array reference is occurring?

Ease of change?  What do C++ programmers say about operator[]?

Re: Certified C compilers for safety-critical embedded systems

[Alexander Kopilovitch]

Robert A Duff wrote:

> >... The main association for notion
> > of function is presence of explicit single result.
> 
> True, although there are a few languages that allow functions to return
> multiple results.

Yes, but those "functions" from one side somehow mimic mathematical
"vector-functions" (note that there may be not true vectors, consisting
of homogeneous components, but a tuple of, say, spherical coordinates instead)
and from other side the multi-component result of such a "function" is usually
considered as single entity in some "virtual" or short-lived sense.

> > So try "subprogram" as that single name, and perhaps you'll see the result
> > better then if you imagine "procedure" there. 
> 
> I don't much like the term "subprogram".  I'm not sure I can explain
> why.

Perhaps because the term "subprogram" is not inherently associated with
ordered execution (just like a "program")... at least that association is
much weaker for it, comparing with "procedure".
 


Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Larry Kilgallen wrote:

> From another point of view, they just opened the system testing process
> up to the public view :-)

Sorry, no.  If the course of Ariane 501 would have been slightly 
different, the launch would have succeeded.  But it would have said 
nothing about the likelihood that then next Airiane 5 launch would have 
succeeded.  In fact there have been three major failures in less than a 
dozen launches, with lots of originally needed testing done after each 
failure, and they still don't have a working system.  In the meantime, 
Ariane 4 (Remember, the one the software requirements were originally 
for?) has had about 100 launches with a very good record.

So the Ariane 5 is almost the poster child for doing reuse without 
redoing the systems requirements analysis from the top.   I would hope 
that no one would ever make that mistake again.  But the lesson that 
keeps being taught about the first Ariane 5 launch is about software 
validation.

Similarly the lessons learned in five Airbus 320 crashes are getting 
papered over.  It is by now clear to those who study such accidents, 
that all five accidents were probably caused by invalid requirements. 
For years Airbus has claimed that the software had been proven correct 
and couldn't have caused the crashes.  But finally enough has come out 
that the accident investigators are pretty sure they know exactly which 
requirements error caused which crash.

The Airbus 320 should bury the idea that theorem provers can result in 
safe software.  In the case of the Airbus 320 what happened was that the 
formal logic used for stating the requirements/theorems was relatively 
opaque to experts in the field (read pilots).  So the flaws in the 
requirements, and later about 500 people, were buried by that opacity.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Dmitry A. Kazakov]

Hyman Rosen wrote:

> Vinzent 'Gadget' Hoefler wrote:
>> What's wrong with that? Arrays are just (constant) functions. ;-)
>> There's no difference between a function that actually calculates
>> something and its precomputed equivalent called array or - to be more
>> precise - lookup-table.
> 
> Except that arrays are not constant.

No that is the type of the result. It can be constant or not. Both arrays
and functions are mappings. The syntax used for the arguments is
irrelevant. So, consequently, Ada has () brackets for indexing.

> What is the advantage of concealing
> from the reader of the code that an array reference is occurring?

Because "being an array" or whatsoever is an implementation detail. Acting
as something, that is interesting for the reader.

> This is
> just another one of those places where dumb theory was used in the place
> of practical language design.

Strange, I would expect you telling us [rightfully] that in this particular
case C++ is better than Ada. C++ has abstract arrays (operator[]), Ada does
not.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Certified C compilers for safety-critical embedded systems

[Frank J. Lhota]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:btoqj7$9qtre$1@ID-77047.news.uni-berlin.de...

> Strange, I would expect you telling us [rightfully] that in this
particular
> case C++ is better than Ada. C++ has abstract arrays (operator[]), Ada
does
> not.

That is why I think that Ada 0y should include a "()" operator, so that we
would have an abstract array capability, as well as an abstract function
capability.

Re: Certified C compilers for safety-critical embedded systems

[Marin David Condic]

It would seem intuitively obvious to even the most casual observer that 
if you're not sure what a thing is *supposed* to do, you can't possibly 
be sure that it does it.  Unfortunately, this lesson is often learned at 
great financial (and sometimes human) expense.

MDC

Robert I. Eachus wrote:
> 
> The Airbus 320 should bury the idea that theorem provers can result in 
> safe software.  In the case of the Airbus 320 what happened was that the 
> formal logic used for stating the requirements/theorems was relatively 
> opaque to experts in the field (read pilots).  So the flaws in the 
> requirements, and later about 500 people, were buried by that opacity.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Certified C compilers for safety-critical embedded systems

[Martin Krischik]

Frank J. Lhota wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:btoqj7$9qtre$1@ID-77047.news.uni-berlin.de...
> 
>> Strange, I would expect you telling us [rightfully] that in this
> particular
>> case C++ is better than Ada. C++ has abstract arrays (operator[]), Ada
> does
>> not.

> That is why I think that Ada 0y should include a "()" operator, so that we
> would have an abstract array capability, as well as an abstract function
> capability.

Of course it would only be usefull in combination with some form ".."
operator. Otherwise one could not transparently create abstract array.

However I imagine that a ".." operator might my very difficult to define.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Certified C compilers for safety-critical embedded systems

[Frank J. Lhota]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:2255889.jXjmIm6Msp@linux1.krischik.com...
> Frank J. Lhota wrote:
> > That is why I think that Ada 0y should include a "()" operator, so that
we
> > would have an abstract array capability, as well as an abstract function
> > capability.
>
> Of course it would only be usefull in combination with some form ".."
> operator. Otherwise one could not transparently create abstract array.
>
> However I imagine that a ".." operator might my very difficult to define.

A further discussion of the "()" operator would be more than welcome, but
let us first review an earlier thread on this topic in this NG, archived
here:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&threadm=1ec946d1.0306090615.a9870ff%40posting.google.com&rnum=38&prev=/groups%3Fq%3DLhota%2B%2522():%253D%2522%2Bgroup:comp.lang.ada%26hl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.lang.ada%26safe%3Doff%26start%3D30%26sa%3DN

In this thread, I also proposed an "():=" operator for updating a component
of an abstract array.

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Mark Lorenzen wrote:

> Indeed. I am a big proponent of formal methods and mathematical
> proofs. But using these tools makes it even more important to get the
> requirements correct, sound and complete.

And that was exactly the problem in the Airbus 320 case.  The grumblings 
of the software designers about the opacity of the formal language used 
were ignored as "the difficulty of learning a new methodology."  The 
real problem was the lack of a formal method for converting the formal 
version of the requirements back into something that could be understood 
by the domain experts.

In government contracting we run into this problem all the time.  The 
contractor wants the "B"-specs, the mapping of the original 
specifications to the intended implementation, to be considered to 
replace the "A"-spec once the B-specs are accepted by the government. 
The government wants the testing done to the A-spec, not the B-spec.

The usual resolution is to delay government acceptance of the B-spec 
until the test plan is available to bounce off the original A-spec. 
Once that requirements tracability is complete, then the government 
allows the B-spec to be signed off as the specification to be 
implemented by the contractor.  But the government does not accept the 
B-spec requirements until they are sure that the test plan will result 
in coverage of the A-spec requirements.  I can't count the number of 
times that the MITRE project team I was on was tasked by the government 
to check that changes to the test plan still covered all the original 
(A-spec) requirements.  Often this was less than a day's work since the 
requirements mapping was still valid.  In other cases, approval dragged 
on for months since requirements changes had to be mapped back to the 
A-spec level.

What happened in the Ariane 501 case can be easily explained by 
referring to this model.  The original test plan covered the "real" 
A-spec.  But the full-up navigation system test called for in the test 
plan was later eliminated due to cost and schedule problems involving 
the test rig.  But no one "looked back" to see which A-spec requirements 
were to be tested by the eliminated test.  Of course, doing such an 
evaluation of the test plan change should have discovered the mismatch 
between the Ariane 4 derived requirements and the Ariane 5 system 
requirements.  (The change to the test plan substituted system testing 
for the upgraded INS for the Ariane 4 for the planned Ariane 5 guidance 
system test.)

This is what I like about the FFRDC (federally funded research and 
development corporation) model the US government uses.  Technically, the 
FFRDC does not work for the particular government agency that contracts 
for the development of whatever new system.  (Often the DoD, but also 
NASA, intelligence organizations, the DOE, and the FAA among others.) 
The FFRDC is charged by Congress with oversight of the project for 
technical and financial feasibility.  But in real day-to-day operations, 
this usually means keeping their eyes focused on the original goal.
If a project like the SSC (super-conducting supercollider) or the A-12 
(Navy stealth attack aircraft) goes out of control and is canceled by 
Congress there is egg on the face of the FFRDC involved.  (Fortunately 
not MITRE in those two cases.)

On the other hand, the FFRDC can go "around" the contracting agency 
directly to Congress when it first becomes clear that the risk 
associated with a project is too great. I've been involved in several of 
those calls.  Or the FFRDC can recommend spending and "extra" hundred 
million dollars or three now to ensure that the project doesn't flop 
later.  Again I have been involved in a few of those calls.  And once I 
even told the government (in this case the Air Force) that the risk was 
not that the contractor couldn't meet the current requirements, but that 
they would, and the government would be left buying an unusable system 
because the governments actual requirements had changed.

That is the other side of the "cost overrun" story.  Had the governments 
real requirements changed?  Yes.  Could the government have held the 
contractors feet to the fire and force them to meet the original 
requirements for the original price?  Yes.  But the government was 
better off negotiating a change order, knowing that the contractor would 
"recover" their previous cost overruns when pricing the change, than 
spending hundreds of millions for a now-useless system, and then putting 
the changes needed to fix it out for bid.

In case you are wondering what changes caused the problem, it was 
Goldwater-Nichols.  This bill changed the way the military responded to 
crises by decentralizing the responsibility to several commands. 
Currently the most well known is the Central Command, which was 
responsible for running the Gulf War, and invasions of Afghanistan and 
Iraq.  What was the problem?  The data presented to various commands and 
to the Pentagon in the original system could be different, since data 
would arrive at different locations via different routes.  But you 
didn't want say Central Command seeing a major threat, and the Pentagon 
(and the President) seeing different data.  We also didn't want to force 
all data to go through the national command authority so it was consistent.

The changes meant that the individual commands needed to know whether 
they were seeing the "full" picture, or damage to the network resulted 
in different commands having access to different data (or the same data 
at significantly different times).  In other words all the theater 
commands needed to see the network status, not just the one location 
responsible for maintaining the network.  It sounds like a minor change, 
but it wasn't.  The network of course was fault-tolerant, and 
maintenance, of course, needed to know which if any links had failed. 
The problem had two parts.  First the commands needed to be able to 
compute the network connectivity, including for links which did not 
directly affect them. This affected network topology and message routing 
for status messages.  Second, the commands needed to be able to do data 
fusion, and get the SAME results as everyone else, independent of 
network timing delays.  This required new data fusion algorithms, where 
the results were independent of the order the data was received.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Hyman Rosen]

Robert A Duff wrote:
> I think I see what you're saying, but I don't understand the point about
> Eiffel.  Please explain.

I think covariance lets you express generics and other functionality
in a way that seems very natural and easy. The designers so fell in
love with the idea that even in the face of hideous difficulties,
including such untenable requirements as whole-program analaysis, they
clung to the notion that this is something they must have. The result
ruined the language - no available Eiffel system implements the checks
to permit covariance to be used safely.

Re: Certified C compilers for safety-critical embedded systems

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Because "being an array" or whatsoever is an implementation detail.

And computer programs are all about implementation.

Anyway, you Ada folks are always so hot to know to what a name refers that
half of you despise "use". So you're all going to see the declaration of the
thing in front of the parentheses anyway, and you're going to know whether
it's an array or a function.

Re: Certified C compilers for safety-critical embedded systems

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Strange, I would expect you telling us [rightfully] that in this particular
> case C++ is better than Ada. C++ has abstract arrays (operator[]), Ada does
> not.

Ada's handling of native arrays is so superior to C++'s that I wouldn't presume
to brag about C++'s operator[]. Anyway, given that C++ can overload function call,
and that can take an arbitrary number of parameters, having operator[] isn't all
that exciting. Furthermore, C++ has no real way of inferring from context to what
use a dereference will be put, and that complicates matters very much.

For example, C++'s std::string has an operator[] which can be used for reading or
for modification
     std::string s("Help!");
     char p = s[3]; // p
     s[3] = "l"; // Hell!
The s[3] construct is not supplied with an information as to whether it is needed
for reading or for writing. As a result, string implementations must assume that
every call to operator[] will result in potentially changing the string, so if they
share duplicate strings behind the scenes, merely calling operator[] forces the
sharing to be broken. You can play tricks with proxy classes and such, but it all
just bogs down.

Re: Certified C compilers for safety-critical embedded systems

[Hyman Rosen]

Robert I. Eachus wrote:
> The Airbus 320 should bury the idea that theorem provers can result in 
> safe software.

It's always been my contention that writing the specifications which you
will then prove that a program obeys is exactly as hard as writing the
program itself.

Re: Certified C compilers for safety-critical embedded systems

[Hyman Rosen]

Georg Bauhaus wrote:
> Ease of change?  What do C++ programmers say about operator[]?

Somehow I don't think Ada programmers' days are filled with flipping
between arrays and functions, but that's just me.

In C++, one is expected to use operator[] for things that are "like"
arrays - containers which can be indexed by something. Note that C++
allows Ada-like syntax as well:
     a(i) = b(j);
because you can overload operator() (the function-call operator).

Re: Certified C compilers for safety-critical embedded systems

[tmoran]

> It's always been my contention that writing the specifications which you
> will then prove that a program obeys is exactly as hard as writing the
> program itself.
  Specification: the program will print, on January 30, 2004, the name
of the President of the United States on January 30, 2005.
  That wasn't a hard spec to write - I await your implementation. ;)

Re: Certified C compilers for safety-critical embedded systems

[Hans-Bernhard Broeker]

In comp.arch.embedded Hyman Rosen <hyrosen@mail.com> wrote:
> Robert I. Eachus wrote:
> > The Airbus 320 should bury the idea that theorem provers can result in 
> > safe software.

Well, saying they can't result in safe software would be even wronger,
of course.  So I guess the real idea that has to be buried is that
they _will_ do so, just like that.

Or, in other words: no matter how good your tools, the GIGO principle
(garbage in, garbage out) still holds.

> It's always been my contention that writing the specifications which you
> will then prove that a program obeys is exactly as hard as writing the
> program itself.

Which would appear to be one of many special cases of what we used to
call the "lemma on conservation of difficulty" among students here.
In the essence it says: "No truly difficult problems ever go away just
by waving some magical tool at them."

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: Certified C compilers for safety-critical embedded systems

[John R. Strohm]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:VK2Mb.2414$Qq.1124@nwrdny01.gnilink.net...
> Robert I. Eachus wrote:
> > The Airbus 320 should bury the idea that theorem provers can result in
> > safe software.
>
> It's always been my contention that writing the specifications which you
> will then prove that a program obeys is exactly as hard as writing the
> program itself.

Yes and no.

Yes, in that writing rigorous formal specifications is HARD WORK.

No, in that the effort you put into writing those rigorous formal specifications
almost always translates into significantly-reduced effort when writing the code
that implements those specifications, because now you have a SOLID
understanding, where you used to have only a sketchy understanding.

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Hyman Rosen wrote:

> Robert I. Eachus wrote:
> 
>> The Airbus 320 should bury the idea that theorem provers can result in 
>> safe software.
> 
> 
> It's always been my contention that writing the specifications which you
> will then prove that a program obeys is exactly as hard as writing the
> program itself.

Depends on where you draw the line. I have been on Ada projects where 
more that 85% of the effort and budget went into requirements and design 
(through to detailed specifcations, which included writing the Ada 
package specs).  All of them finished on time and under budget.

If you do the design right, writing, debugging and testing the package 
bodies is easy.  But I don't recommend that you contract the coding to 
Primate Programmers, Inc. (PPI): 
http://www.newtechusa.com/ppi/pressroom.asp#higher ;-)

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

tmoran@acm.org wrote:

>>It's always been my contention that writing the specifications which you
>>will then prove that a program obeys is exactly as hard as writing the
>>program itself.
> 
>   Specification: the program will print, on January 30, 2004, the name
> of the President of the United States on January 30, 2005.
>   That wasn't a hard spec to write - I await your implementation. ;)

In a sense, very off topic but...

with Ada.Text_IO;
procedure Print_President is
begin Ada.Text_IO.Put_Line(" George W. Bush"); end Print_President;

Projecting the Democratic nominee is tougher, and I live in New 
Hampshire.  It will probably be Dean the way the Democratic party 
primaries are scheduled this year.  His strength is in the Northeast and 
the Rust Belt, which is what it will take to get nominated.  The problem 
is that he has probably killed any chance of carrying states in the 
South and West.  And after the recent census all the states that gained 
Electoral College votes are in those areas.

Could another Democratic candidate do better?  I don't think so.  If 
Dean is nominated he may help the party hold on to Senate and House 
seats in the swing areas.  The problem is that there are no longer 
enough swing areas for the Democrats to carry.  (Another way to say this 
is that if Bush carries the states that Gerald Ford won against Jimmy 
Carter, he wins.)

If there was a Democratic candidate like Jesse Ventura (who was elected 
Governor as an Independent) he might draw enough new voters into the 
voting booths.  But none of the announced candidates can do that, and 
the primary system this year is set up so that one of the current 
candidates will be selected.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Leif Roar Moldskred]

tmoran@acm.org writes:

>   Specification: the program will print, on January 30, 2004, the name
> of the President of the United States on January 30, 2005.
>   That wasn't a hard spec to write - I await your implementation. ;)

In pseudo-code:

PRINT ( "There will be no President of the United States on January 30th, 2005" )
FOR EACH name in set_of_candidates_for_president DO
  PRINT( "The President of the United States on January 30th, 2005 will be " )
  PRINT( name )
DONE

Now, if your specification had explicitly stated that the program should print 
out _only_ the name of the person who will be president of the United States
on January 30th, 2005, it would have been harder.

-- 
Leif Roar Moldskred
Got Sfik?

Re: Certified C compilers for safety-critical embedded systems

[Frank J. Lhota]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:Ux2Mb.2349$Qq.709@nwrdny01.gnilink.net...
> Dmitry A. Kazakov wrote:
> Anyway, you Ada folks are always so hot to know to what a name refers that
> half of you despise "use". So you're all going to see the declaration of
the
> thing in front of the parentheses anyway, and you're going to know whether
> it's an array or a function.

Actually, I have seen a fair amount of hostility to the "using" declaration
in the C++ community. In both cases, the furor is unjustified IMHO.

Re: Certified C compilers for safety-critical embedded systems

[Dmitry A. Kazakov]

Hyman Rosen wrote:

> Robert I. Eachus wrote:
>> The Airbus 320 should bury the idea that theorem provers can result in
>> safe software.
> 
> It's always been my contention that writing the specifications which you
> will then prove that a program obeys is exactly as hard as writing the
> program itself.

Maybe, but nobody showed any better way. Or do you think that XP (eXtreme
Programming) did?

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Certified C compilers for safety-critical embedded systems

[Marin David Condic]

if (Date = Jan_30_2004) then
     for (X in All_Elligible_Citizens'Range) loop
         Put_Line (All_Elligible_Citizens (X).Name) ;
     end loop ;
end if ;

That ought to print the name of the next President well in advance of 
the actual election. ;-)

MDC

tmoran@acm.org wrote:
>>It's always been my contention that writing the specifications which you
>>will then prove that a program obeys is exactly as hard as writing the
>>program itself.
> 
>   Specification: the program will print, on January 30, 2004, the name
> of the President of the United States on January 30, 2005.
>   That wasn't a hard spec to write - I await your implementation. ;)


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Certified C compilers for safety-critical embedded systems

[Dmitry A. Kazakov]

Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> Because "being an array" or whatsoever is an implementation detail.
> 
> And computer programs are all about implementation.

Aha, is that why you hate specifications and formal methods? (:-))

No, to manage complexity we should have different layered views on software
components. Implementation on one level involves specifications of another.
And any implementation is useless if nodody knows what it implements. After
all any arbitrary sequence of bits implements something...

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Certified C compilers for safety-critical embedded systems

[Larry Kilgallen]

In article <40016052.60703@noplace.com>, Marin David Condic <nobody@noplace.com> writes:
> if (Date = Jan_30_2004) then
>      for (X in All_Elligible_Citizens'Range) loop
>          Put_Line (All_Elligible_Citizens (X).Name) ;
>      end loop ;
> end if ;
> 
> That ought to print the name of the next President well in advance of 
> the actual election. ;-)

It depends on the specification of "All_Elligible_Citizens".

I would prefer "All_Citizens_Who_Will_Be_Eligible_At_The_Future_Date"
so as not to exclude some 34 year olds who have a pending birthday.

Re: Certified C compilers for safety-critical embedded systems

[Chad R. Meiners]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:VK2Mb.2414$Qq.1124@nwrdny01.gnilink.net...
> Robert I. Eachus wrote:
> > The Airbus 320 should bury the idea that theorem provers can result in
> > safe software.
>
> It's always been my contention that writing the specifications which you
> will then prove that a program obeys is exactly as hard as writing the
> program itself.

Not always true---we can specify the Halting problem (for a Turing
Equavilent machine), but we cannot implement it without an oracle.

-CRM

Re: Certified C compilers for safety-critical embedded systems

[Everett M. Greene]

"John R. Strohm" <strohm@airmail.net> writes:
> "Hyman Rosen" <hyrosen@mail.com> wrote in message
> > Robert I. Eachus wrote:
> > > The Airbus 320 should bury the idea that theorem provers can result in
> > > safe software.
> >
> > It's always been my contention that writing the specifications which you
> > will then prove that a program obeys is exactly as hard as writing the
> > program itself.
> 
> Yes and no.
> 
> Yes, in that writing rigorous formal specifications is HARD WORK.
> 
> No, in that the effort you put into writing those rigorous formal specifications
> almost always translates into significantly-reduced effort when writing the code
> that implements those specifications, because now you have a SOLID
> understanding, where you used to have only a sketchy understanding.

It has been my observation that there's an inverse relation
between the difficulty in describing what's needed and the
difficulty in implementing it.  Perhaps this is just another
aspect of the specification difficulty -- once you've clearly
specified what's needed, it's not that difficult to implement
it.

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Chad R. Meiners wrote:

> Not always true---we can specify the Halting problem (for a Turing
> Equavilent machine), but we cannot implement it without an oracle.

Actually not quite true.  It is not hard to write a program that 
implements the Halting problem, and for any finite machine, it will 
always return the correct answer.  If you allow the number of 
intermediate states for programs submitted to be unbounded, then you 
cannot bound the execution time for the (combination of) program and 
machine that implements the Halting problem.

The Halting problem and a real time constraint is an impossible 
combination.  For that matter, anyone who works with hard real-time 
knows that you have to allow for the possibility that all of the 
constraints on the system cannot be met.  Then you have to do the 
engineering part of the job and select the right tradeoff.  (Which may 
include a higher power budget or extra weight, or even more money so you 
can build a custom chip.)

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Chad R. Meiners]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:tP2dndMsaLDKEpzd4p2dnA@comcast.com...
> Chad R. Meiners wrote:
>
> > Not always true---we can specify the Halting problem (for a Turing
> > Equavilent machine), but we cannot implement it without an oracle.
>
> Actually not quite true.  It is not hard to write a program that
> implements the Halting problem, and for any finite machine, it will
> always return the correct answer.

This would be a specification for the Halting problem for a bounded Turing
Machine.

> If you allow the number of
> intermediate states for programs submitted to be unbounded, then you
> cannot bound the execution time for the (combination of) program and
> machine that implements the Halting problem.

This would be the specification of the Halting problem for a Turing
Equivalent machine.

> The Halting problem and a real time constraint is an impossible
> combination.

Yes, that was the point.  Writing the specification for the Halting problem
is much easier than writing the implementation since the implementation
doesn't exist.

> For that matter, anyone who works with hard real-time
> knows that you have to allow for the possibility that all of the
> constraints on the system cannot be met.  Then you have to do the
> engineering part of the job and select the right tradeoff.  (Which may
> include a higher power budget or extra weight, or even more money so you
> can build a custom chip.)

I completely agree.

> -- 
>                                            Robert I. Eachus

-CRM

Re: Certified C compilers for safety-critical embedded systems

[CBFalconer]

"Everett M. Greene" wrote:
> "John R. Strohm" <strohm@airmail.net> writes:
> >
... snip ...
> >
> > Yes, in that writing rigorous formal specifications is HARD WORK.
> >
> > No, in that the effort you put into writing those rigorous formal
> > specifications almost always translates into significantly-reduced
> > effort when writing the code that implements those specifications,
> > because now you have a SOLID understanding, where you used to have
> > only a sketchy understanding.
> 
> It has been my observation that there's an inverse relation
> between the difficulty in describing what's needed and the
> difficulty in implementing it.  Perhaps this is just another
> aspect of the specification difficulty -- once you've clearly
> specified what's needed, it's not that difficult to implement it.

And at other times writing the specification becomes easy after
you have implemented the widget.  Maybe the key is to remember
that both the specification and implementation are always subject
to revision in the light of experience, deeper analysis, etc.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

Re: Certified C compilers for safety-critical embedded systems

[Georg Bauhaus]

Larry Kilgallen <Kilgallen@spamcop.net> wrote:
: In article <40016052.60703@noplace.com>, Marin David Condic <nobody@noplace.com> writes:
:> if (Date = Jan_30_2004) then
:>      for (X in All_Elligible_Citizens'Range) loop
:>          Put_Line (All_Elligible_Citizens (X).Name) ;
:>      end loop ;
:> end if ;
:> 
:> That ought to print the name of the next President well in advance of 
:> the actual election. ;-)
: 
: It depends on the specification of "All_Elligible_Citizens".
: 
: I would prefer "All_Citizens_Who_Will_Be_Eligible_At_The_Future_Date"
: so as not to exclude some 34 year olds who have a pending birthday.

Not knowing what the USA will be if they will be etc etc etc...
Is the world math?

Is this an example of what makes a mathematician different from
ordinary people? (Like in: All eligible corn flakes of the united
states of Canada will be president of Mexico. Probably true by
emptiness, nonsense by common sense. ;)


-- Georg

Re: Certified C compilers for safety-critical embedded systems

[Georg Bauhaus]

In comp.lang.ada Chad R. Meiners <crmeiners@hotmail.com> wrote:
: 
: "Robert I. Eachus" <rieachus@comcast.net> wrote in message
: news:tP2dndMsaLDKEpzd4p2dnA@comcast.com...
:> Chad R. Meiners wrote:
:>
:> > Not always true---we can specify the Halting problem (for a Turing
:> > Equavilent machine), but we cannot implement it without an oracle.
:>
:> Actually not quite true.  It is not hard to write a program that
:> implements the Halting problem, and for any finite machine, it will
:> always return the correct answer.
: 
: This would be a specification for the Halting problem for a bounded Turing
: Machine.

Are you sure you can say that a program that implements the Halting
problem for a bounded Turing machine does not implement the same
problem for a Turing machine?


Georg

Re: Certified C compilers for safety-critical embedded systems

[Chad R. Meiners]

"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:btsrnj$gld$2@a1-hrz.uni-duisburg.de...
> In comp.lang.ada Chad R. Meiners <crmeiners@hotmail.com> wrote:
> :
> : "Robert I. Eachus" <rieachus@comcast.net> wrote in message
> : news:tP2dndMsaLDKEpzd4p2dnA@comcast.com...
> :> Chad R. Meiners wrote:
> :>
> :> > Not always true---we can specify the Halting problem (for a Turing
> :> > Equavilent machine), but we cannot implement it without an oracle.
> :>
> :> Actually not quite true.  It is not hard to write a program that
> :> implements the Halting problem, and for any finite machine, it will
> :> always return the correct answer.
> :
> : This would be a specification for the Halting problem for a bounded
Turing
> : Machine.
>
> Are you sure you can say that a program that implements the Halting
> problem for a bounded Turing machine does not implement the same
> problem for a Turing machine?

<humor>
Of course you can SAY it! I just did ;-)
</humor>

It depends what you mean by implement.  I tend to think of implementations
as algorithms (which must halt).  Therefore, since there is no algorithm
that satisfies the Halting problem's specification (it is undecidable),
there is not an implementation.  If you want to define implementation as
something else (reasonable or unreasonable), all bets are off of course.

-CRM

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Chad R. Meiners wrote:

> "Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message

>>Are you sure you can say that a program that implements the Halting
>>problem for a bounded Turing machine does not implement the same
>>problem for a Turing machine?
>
> It depends what you mean by implement.  I tend to think of implementations
> as algorithms (which must halt).  Therefore, since there is no algorithm
> that satisfies the Halting problem's specification (it is undecidable),
> there is not an implementation.  If you want to define implementation as
> something else (reasonable or unreasonable), all bets are off of course.

Excatly, or anyother way of making my point.  All physical machines have 
limits even if someone builds a self-replicating von Neuman system that 
keeps growing itself, it would be limited by the available matter in the 
universe.  But in reality, for realistic time frames even the PC on your 
desk is a sufficiently close approximation to an infinite Turing 
machine.  Does it really matter if I give you an implementation of the 
Halting problem for your PC that will always halt within a trillion 
years, instead of one that does not halt for some inputs? (And are you 
sure, if you had both in hand, you could tell which was which?)

Anyone who works on compiler front end and language definitions has to 
be ready to dance with G�del, decidability issues and the whole nine 
yards.  ANY compiler for a reasonable programming language, and even for 
some unreasonable ones runs right straight into G�del's proof.  It 
either does not accept some legal programs, accepts some illegal 
programs, or never halts for some inputs.  (And as many of you know, 
early releases of compilers tend to do all three.) G�del says that any 
Ada, C, C++, Fortran, or whatever compiler must have at least one of 
those three bugs in it. (In the Ada community, we aim for the first 
choice--that there will be some legal Ada programs that will be rejected 
due to implementation limitations.)

I thought it was wonderful about a decade ago when we made a decision to 
require Ada compilers to solve NP-complete problems--and were honest 
about it. Record representation specifications can be only partially 
specified, and we require the compiler to find a legal layout if one 
exists.  This is of course a bin packing problem, and with not much work 
ANY bin packing or knapsack problem can be mapped to an Ada record 
representation clause.

However, for decades there have been requirements in the Reference 
Manual to solve the Halting problem, but we still dance around saying 
that. In Ada you can write expressions which will be evaluated at 
compile time, and the compiler must decide whether to accept or reject a 
program based on the results of those computations. (Did someone say 
G�del numbers?) I once wrote a joke compiler "benchmark" that used a 
series expansion to compute Pi to 50 places. (Our compiler compiled it 
correctly, but took about 20 minutes.)

Actually Dave Emery and Rich Hilliard a few years later came up with an 
even more torturous compiler test.  I think Dave wrote:

type Positive_Integer is range 0..2**Integer'Last-1;

by accident, and the Verdix compiler just kept churning away.  (Of 
course the last expression was intended to be 2**Integer'Size-1 not 
2**4_294_967_296-1.) I think a number of compilers now check for that 
error by bounding the terms if one gets too large.  In this case once 
you get past 2**32 subtracting one can't bring the final result back in 
range, so you can declare an error and give up.

But there are actually programs in the Ada test suite that depend on the 
fact that A*X-B*Y is a small number for some integers A, B, X, and Y > 
1.  With a computer you can hunt up some pretty nasty expressions that 
require several thousand digits in your arbitrary arithmetic package but 
the final result is say, 13.  Why does Ada require this?  Because it 
allows programs to be written using expressions meaningful in the 
problem domain.  This goes back to the issue of making it easier for 
domain experts to validate designs and implementations.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Peter Amey]

tmoran@acm.org wrote:
>>It's always been my contention that writing the specifications which you
>>will then prove that a program obeys is exactly as hard as writing the
>>program itself.
> 
>   Specification: the program will print, on January 30, 2004, the name
> of the President of the United States on January 30, 2005.
>   That wasn't a hard spec to write - I await your implementation. ;)

A Diebold-like voting machine perhaps :-)

Re: Certified C compilers for safety-critical embedded systems

[Mel Wilson]

In article <XJWdnYzddPrfuZ_dRVn-uw@comcast.com>,
"Robert I. Eachus" <rieachus@comcast.net> wrote:
>
>
>Chad R. Meiners wrote:
>
>> "Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
>
>>>Are you sure you can say that a program that implements the Halting
>>>problem for a bounded Turing machine does not implement the same
>>>problem for a Turing machine?
>>
>> It depends what you mean by implement.  I tend to think of implementations
>> as algorithms (which must halt).  Therefore, since there is no algorithm
>> that satisfies the Halting problem's specification (it is undecidable),
>> there is not an implementation.  If you want to define implementation as
>> something else (reasonable or unreasonable), all bets are off of course.
>
>Excatly, or anyother way of making my point.  All physical machines have
>limits even if someone builds a self-replicating von Neuman system that
>keeps growing itself, it would be limited by the available matter in the
>universe.  But in reality, for realistic time frames even the PC on your
>desk is a sufficiently close approximation to an infinite Turing
>machine.  Does it really matter if I give you an implementation of the
>Halting problem for your PC that will always halt within a trillion
>years, instead of one that does not halt for some inputs? (And are you
>sure, if you had both in hand, you could tell which was which?)

   A lemma, or consequence (if I'm not mistaken) is that you
can calculate the fate, Halting or Not-Halting, of every
program in a finite set of programs S, but the program that
does this can't be in S. Even if the program took a trillion
years, it would take them on a bigger machine than yours.
Douglas Adams' _The Hitchhiker's Guide to the Galaxy_ does
nice work with this in the nest of computer-designing
hyper-super computers that would calculate the question to
the great answer of Life, the Universe and Everything.

        Regards.        Mel.

Re: Certified C compilers for safety-critical embedded systems

[Martin Krischik]

Robert I. Eachus wrote:

> error by bounding the terms if one gets too large.ￜￜInￜthisￜcaseￜonce
> you get past 2**32 subtracting one can't bring the final result back in
> range, so you can declare an error and give up.

$ gnat standard
package Standard is
pragma Pure(Standard);

   type Boolean is (False, True);

   type Integer is range -(2 ** 31) .. +(2 ** 31 - 1);

   subtype Natural  is Integer range 0 .. +(2 ** 31 - 1);
   subtype Positive is Integer range 1 .. +(2 ** 31 - 1);

   type Short_Short_Integer is range -(2 ** 7) .. +(2 ** 7 - 1);
   type Short_Integer       is range -(2 ** 15) .. +(2 ** 15 - 1);
   type Long_Integer        is range -(2 ** 31) .. +(2 ** 31 - 1);
   type Long_Long_Integer   is range -(2 ** 63) .. +(2 ** 63 - 1);

I don't think GNAT will give up at 2**32.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Certified C compilers for safety-critical embedded systems

[Aatu Koskensilta]

Robert I. Eachus wrote:

> Anyone who works on compiler front end and language definitions has to 
> be ready to dance with G�del, decidability issues and the whole nine 
> yards.  ANY compiler for a reasonable programming language, and even for 
> some unreasonable ones runs right straight into G�del's proof.  It 
> either does not accept some legal programs, accepts some illegal 
> programs, or never halts for some inputs.  

Where do you get this curious idea about G�del's proof?

-- 
Aatu Koskensilta (aatu.koskensilta@xortec.fi)

"Wovon man nicht sprechen kann, daruber muss man schweigen"
  - Ludwig Wittgenstein, Tractatus Logico-Philosophicus

Re: Certified C compilers for safety-critical embedded systems

[Alexandre E. Kopilovitch]

Aatu Koskensilta wrote:

> > Anyone who works on compiler front end and language definitions has to 
> > be ready to dance with GО©╫del, decidability issues and the whole nine 
> > yards.  ANY compiler for a reasonable programming language, and even for 
> > some unreasonable ones runs right straight into GО©╫del's proof.  It 
> > either does not accept some legal programs, accepts some illegal 
> > programs, or never halts for some inputs.  
>
> Where do you get this curious idea about GО©╫del's proof?

Why do you call that reference to GО©╫del's proof "curious"? I think that it is
quite natural (although certainly imprecise and to some degree metaphorical,
but it can't be otherwise here) mapping of the sense of that GО©╫del's theorem
to the reality of general-purpose programming languages.

Or you imply that theorems of (mathematical) logic can't have a sense and
therefore shouldn't be mapped to reality at all? -:)



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Certified C compilers for safety-critical embedded systems

[David Starner]

On Wed, 14 Jan 2004 01:18:48 +0300, Alexandre E. Kopilovitch wrote:

> Aatu Koskensilta wrote:
> 
>> > Anyone who works on compiler front end and language definitions has to 
>> > be ready to dance with G�del, decidability issues and the whole
>> > nine yards.  ANY compiler for a reasonable programming language, and
>> > even for some unreasonable ones runs right straight into G�del's
>> > proof.  It either does not accept some legal programs, accepts some
>> > illegal programs, or never halts for some inputs.
>>
>> Where do you get this curious idea about G�del's proof?
> 
> Why do you call that reference to G�del's proof "curious"? 

Because it's wrong. An assembler is a simple compiler; where does a
simple assembler which merely looks up mnemonics in a table run into
G�del's proof? There is a Turing complete language with one instruction:
subtract and jump if negative. So you have a bunch of lines like SJN %0 %1
%2, where you subtract %1 from %0 and jump to %2 if negative. I see no
point where a compiler from this language into Ada or x86 assembly would
not accept some legal programs, accept any illegal programs, or not halt.

So obviously reasonable doesn't mean Turing-complete. But if it doesn't,
where does G�del come in? It seems implausible that every "reasonable"
language is uncompilable. A Basic subset with integer variables A-Z and
POKE, PEEK, assignment, +, -, *, /, =, <, > and an if/then/goto construct
is about equal to some real life Basics, so in some sense is reasonable.
Maybe my imagination is failing me, but I fail to see why G�del's proof
is involved in compiling this to any other reasonable language. I doubt
the compiler language would have to even be Turing complete.

No completely optimizing compiler can exist for any reasonable programming
language, but that's not what he said. Perhaps most languages in existence
run into G�del problems on simple compilation, but I would hesitate to
say that all "reasonable" languages fall into that category.

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Martin Krischik wrote:

> I don't think GNAT will give up at 2**32.

Oops!

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

David Starner wrote:

> Because it's wrong. An assembler is a simple compiler; where does a
> simple assembler which merely looks up mnemonics in a table run into
> G�del's proof? There is a Turing complete language with one instruction:
> subtract and jump if negative. So you have a bunch of lines like SJN %0 %1
> %2, where you subtract %1 from %0 and jump to %2 if negative. I see no
> point where a compiler from this language into Ada or x86 assembly would
> not accept some legal programs, accept any illegal programs, or not halt.

No, an assembler is NOT a simple compiler, at least in the generally 
accepted sense of the term.  A compiler parses context free languages. 
The assembler you hypothesized is capable of being recognized by a 
finite state machine instead of a push-down automata.

> So obviously reasonable doesn't mean Turing-complete. But if it doesn't,
> where does G�del come in? It seems implausible that every "reasonable"
> language is uncompilable. A Basic subset with integer variables A-Z and
> POKE, PEEK, assignment, +, -, *, /, =, <, > and an if/then/goto construct
> is about equal to some real life Basics, so in some sense is reasonable.
> Maybe my imagination is failing me, but I fail to see why G�del's proof
> is involved in compiling this to any other reasonable language. I doubt
> the compiler language would have to even be Turing complete.

Okay, let's try again.  All major programming languages cannot be 
recognized by a finite state machine.  If a language can be recognized 
by a FSM, it is not subject to G�del's Proof.  Assuming away the 
features of a context free grammar that cause the problem, and then 
saying it doesn't exist is silly.  Do you know of any regularly used 
programming languages that don't require PDAs to recognize them?  I 
don't, and I spent decades creating and maintaining compilers and 
programming languages.  (A lot of compilers use LL1 grammers and 
"recursive descent" parsers.  In that case the call stack serves as an 
implicit push-down structure for the parser.  Parsers which use LALR or 
even LR(k) grammars usually use an explicit push-down automata.)

> No completely optimizing compiler can exist for any reasonable programming
> language, but that's not what he said. Perhaps most languages in existence
> run into G�del problems on simple compilation, but I would hesitate to
> say that all "reasonable" languages fall into that category.

I didn't hesitate, and I said it.  Incidently there are some languages 
which are normally interpreted that can be recognized by FSMs.  But they 
are not normally considered to be programming languages, general purpose 
or otherwise.

All this should be standard material in any graduate level course on 
computability.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Aatu Koskensilta]

Alexandre E. Kopilovitch wrote:

> Aatu Koskensilta wrote:
>>
>>Where do you get this curious idea about G�del's proof?
> 
> Why do you call that reference to G�del's proof "curious"? 

Because it seems flat out wrong. That

  [any compiler for a resonable language] either does not accept some
  legal programs, accepts some illegal  programs, or never halts for some
  inputs

does not in any sense follow from G�del's proof. The only way for it to 
be true is if "reasonable language" is defined as a language that is 
compile-time Turing-complete. Most languages currently in use are not. 
Also, from the compile-time Turing-completeness it follows only that the 
compiler will fail to halt for some illegal program, provided the 
language is not unreasonable enough to declare valid programs with 
non-halting compile-time constructions.

> Or you imply that theorems of (mathematical) logic can't have a sense and
> therefore shouldn't be mapped to reality at all? -:)

No, mathematical logic is very relevant to computer science.

-- 
Aatu Koskensilta (aatu.koskensilta@xortec.fi)

"Wovon man nicht sprechen kann, daruber muss man schweigen"
  - Ludwig Wittgenstein, Tractatus Logico-Philosophicus

Re: Certified C compilers for safety-critical embedded systems

[David Starner]

On Wed, 14 Jan 2004 02:07:27 -0500, Robert I. Eachus wrote:

> David Starner wrote:
>
>> So obviously reasonable doesn't mean Turing-complete. But if it doesn't,
>> where does G�del come in? It seems implausible that every "reasonable"
>> language is uncompilable. A Basic subset with integer variables A-Z and
>> POKE, PEEK, assignment, +, -, *, /, =, <, > and an if/then/goto construct
>> is about equal to some real life Basics, so in some sense is reasonable.
>
> 
> Okay, let's try again.  All major programming languages cannot be 
> recognized by a finite state machine.  If a language can be recognized 
> by a FSM, it is not subject to G�del's Proof. 

Okay, I oversimplified the problem. But add a pair of parentheses to
the above language, and it's not recognizable by a FSM. I don't see why a
compiler implementing that language can't be correct. I do understand the
basics of G�del's theorem. As a reasonable language, it's not that much
different from the Basic's that shipped on every bitty box in the 80's. 

>> No completely optimizing compiler can exist for any reasonable programming
>> language, but that's not what he said. Perhaps most languages in existence
>> run into G�del problems on simple compilation, but I would hesitate to
>> say that all "reasonable" languages fall into that category.
> 
> I didn't hesitate, and I said it. 

You said it, but at least two of us don't agree. Would you care to back it
up? Perhaps Ada is in that category, and template programming in C++ is
compile-time Turing-complete. But what about simple languages like ISO
non-extended Pascal, or Fortran 77?

> All this should be standard material in any graduate level course on 
> computability.

Not all programmers have a Masters in computer science, but I did just
fine in my undergraduate class in computability. 

Re: Certified C compilers for safety-critical embedded systems

[Aatu Koskensilta]

David Starner wrote:
> On Wed, 14 Jan 2004 02:07:27 -0500, Robert I. Eachus wrote:
> 
> Perhaps Ada is in that category, and template programming in C++ is
> compile-time Turing-complete. 

Strictly speaking C++ is not compile-time Turing-complete, since there 
is a limit (17) on depth of template recursion. On some compilers (at 
least gcc), this limit can be increased, but I don't know if any of them 
support unbounded template recursion.

-- 
Aatu Koskensilta (aatu.koskensilta@xortec.fi)

"Wovon man nicht sprechen kann, daruber muss man schweigen"
  - Ludwig Wittgenstein, Tractatus Logico-Philosophicus

Re: Certified C compilers for safety-critical embedded systems

[Georg Bauhaus]

Aatu Koskensilta <aatu.koskensilta@xortec.fi> wrote:
: Because it seems flat out wrong. That
: 
:  [any compiler for a resonable language] either does not accept some
:  legal programs, accepts some illegal  programs, or never halts for some
:  inputs
: 
: does not in any sense follow from G?del's proof. The only way for it to 
: be true is if "reasonable language" is defined as a language that is 
: compile-time Turing-complete. Most languages currently in use are not. 

Can a self-hosting compiler then in theory decide whether it is
correct? For the former or the latter languages?


-- Georg

Re: Certified C compilers for safety-critical embedded systems

[Aatu Koskensilta]

Georg Bauhaus wrote:
> Aatu Koskensilta <aatu.koskensilta@xortec.fi> wrote:
> : Because it seems flat out wrong. That
> : 
> :  [any compiler for a resonable language] either does not accept some
> :  legal programs, accepts some illegal  programs, or never halts for some
> :  inputs
> : 
> : does not in any sense follow from G?del's proof. The only way for it to 
> : be true is if "reasonable language" is defined as a language that is 
> : compile-time Turing-complete. Most languages currently in use are not. 
> 
> Can a self-hosting compiler then in theory decide whether it is
> correct? For the former or the latter languages?

I don't think I understand your question. Are you asking about a 
situation in which a compiler is used to compile itself? If so, 
certainly it can for both classes of languages accept itself as a legal 
program. Whether or not it's also correct in the sense of conforming to 
the relevant standard(s) is another matter, and I don't think you would 
expect a compiler to provide proofs of that sort.

-- 
Aatu Koskensilta (aatu.koskensilta@xortec.fi)

"Wovon man nicht sprechen kann, daruber muss man schweigen"
  - Ludwig Wittgenstein, Tractatus Logico-Philosophicus

Re: Certified C compilers for safety-critical embedded systems

[Alexandre E. Kopilovitch]

Aatu Koskensilta wrote:

> > Why do you call that reference to GО©╫del's proof "curious"? 
>
> Because it seems flat out wrong. That
>
>  [any compiler for a resonable language] either does not accept some
>  legal programs, accepts some illegal  programs, or never halts for some
>  inputs
>
> does not in any sense

Hm, _any_? How can you know about _any_ sense? There may be a sense of which
you just aren't aware (for example, a sense of _real_ general-purpose
programming languages and _real_ requirements for _really_used_ compilers
for those languages -;).

> follow from GО©╫del's proof.

It can't formally follow - just because the quoted statement is not formal -
it couples the formal part with informal part, and the latter refers to a hard
reality. So, the statement isn't a logical conclusion, it is an opinion about
relationship between a particular logical construct and a piece of reality. 

> > Or you imply that theorems of (mathematical) logic can't have a sense and
> > therefore shouldn't be mapped to reality at all? -:)
>
> No, mathematical logic is very relevant to computer science.

I didn't mention computer science at all, I asked about a sense relevant to
reality and about a mapping to reality.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Certified C compilers for safety-critical embedded systems

[Aatu Koskensilta]

Alexandre E. Kopilovitch wrote:
> Aatu Koskensilta wrote:
> 
> 
>>>Why do you call that reference to G�del's proof "curious"? 
>>
>>Because it seems flat out wrong. That
>>
>> [any compiler for a resonable language] either does not accept some
>> legal programs, accepts some illegal  programs, or never halts for some
>> inputs
>>
>>does not in any sense
> 
> 
> Hm, _any_? How can you know about _any_ sense? There may be a sense of which
> you just aren't aware (for example, a sense of _real_ general-purpose
> programming languages and _real_ requirements for _really_used_ compilers
> for those languages -;).

Then the impossibility follows from some constraints imposed by these 
"reality" requirements, whatever they are, and not from G�del's theorem 
(or the undecidability of the Halting Problem, which seems more 
appropriate here). The only way to get from undecidability of the 
Halting Problem to the conclusion is to insist that "reasonable" 
languages must be compile-time Turing-complete. I know of no language in 
wide use today that would meet this requirement.

>>follow from G�del's proof.
> 
> 
> It can't formally follow - just because the quoted statement is not formal -
> it couples the formal part with informal part, and the latter refers to a hard
> reality. So, the statement isn't a logical conclusion, it is an opinion about
> relationship between a particular logical construct and a piece of reality. 

It isn't. There's a very clear sense in which the above claim can be 
taken to be about recursive functions - in which case all sorts of 
considerations about hard relaity are obviously irrelevant -, in this 
case about recursive functions that perform transformations on strings. 
To re-iterate what I've said above: such a transformation is 
non-recursive just in case it is (or can be made in a suitable manner) a 
(recursive) encoding of a non-recursive function.

In hard reality there are very few correct compilers if any, but this 
has nothing to do with G�del's theorem or its proof.

-- 
Aatu Koskensilta (aatu.koskensilta@xortec.fi)

"Wovon man nicht sprechen kann, daruber muss man schweigen"
  - Ludwig Wittgenstein, Tractatus Logico-Philosophicus

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Georg Bauhaus wrote:

> Can a self-hosting compiler then in theory decide whether it is
> correct? For the former or the latter languages?

I don't understand the question.  Since this is posted in comp.lang.ada, 
it seems right to relate it to Ada compilers.

There are two questions which seem similar, but are not. 1) Does this 
compiler correctly implement the Ada standard?  We have validation 
tests, and any decent compiler development project extends those tests 
with a large library of regression tests, and runs them constantly as 
part of the ongoing support effort.  In that sense Ada compilers are 
constantly testing to see whether they fail to implement the standard. 
Of course, not failing any existing test does not make the compiler 
perfect, it just means that there are no known bugs.


2) Can this compiler correctly compile all Ada programs?  Of course not. 
  Let me first quote from the Ada RM 1.1.3:

     "A conforming implementation shall:

     * Translate and correctly execute legal programs written in Ada, 
provided that they are not so large as to exceed the capacity of the 
implementation;

     * Identify all programs or program units that are so large as to 
exceed the capacity of the implementation (or raise an appropriate 
exception at run time);

     * Identify all programs or program units that contain errors whose 
detection is required by this International Standard;

     * Supply all language-defined library units required by this 
International Standard;

     * Contain no variations except those explicitly permitted by this 
International Standard, or those that are impossible or impractical to 
avoid given the implementation's execution environment;

     * Specify all such variations in the manner prescribed by this 
International Standard..."

EVERY Ada compiler that currently exists has programs that are part of 
the validation suite that they fail to compile due to capacity 
limitations.  Part of the validation process is to determine whether 
those limitations are in some sense "reasonable".

So as far as G�del's proof is concerned, we know that all Ada compilers 
are incomplete implementations of Ada.  We have accepted that 
incompleteness of Ada implementations as much to be preferred to 
compilers that accept illegal Ada programs, or worse, incorrectly 
recognize the meaning of a given Ada program.

You may consider this a "dirty little secret" about programming 
languages and compilers if you want.  I just consider it a fact of life.

Also, keep in mind that most Ada compilers will accept very large G�del 
numbers, written in factored form or as constants with hundreds of 
digits.  You can design a program so that it only accepts a program as 
legal Ada if a particular G�del number specifies a true theorem in 
G�del's formalization, and will reject it otherwise.  As a practical 
matter, there will be large numbers of such programs where the compiler 
will eventually halt. In practice you won't want to wait that long.  Of 
course, there are other theorems where either the compiler will reject 
the program due to implementation restrictions or the compiler will 
never halt, assuming a perfect machine to run the compiler on.

It may be of great theoretical interest to know that a compilation that 
has already run for a day may not halt in a decade, or a century.  But 
in practice the hardware (and probably the compiler) is just not that good.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[David Starner]

On Wed, 14 Jan 2004 11:44:47 -0500, Robert I. Eachus wrote:
> EVERY Ada compiler that currently exists has programs that are part of
> the validation suite that they fail to compile due to capacity
> limitations.  Part of the validation process is to determine whether
> those limitations are in some sense "reasonable".
> 
> So as far as G�del's proof is concerned, we know that all Ada compilers
> are incomplete implementations of Ada.

In this sense, Ada compilers don't implement a Turing-complete language,
nor are they written in a Turing-complete language. Modern computers, like
any computer in the real world, are merely finite state machines, as a
true Turing machine requires infinite storage, so G�del's proof doesn't
apply.

Re: Certified C compilers for safety-critical embedded systems

[Aatu Koskensilta]

Robert I. Eachus wrote:
> Also, keep in mind that most Ada compilers will accept very large G�del 
> numbers, written in factored form or as constants with hundreds of 
> digits.  You can design a program so that it only accepts a program as 
> legal Ada if a particular G�del number specifies a true theorem in 
> G�del's formalization, and will reject it otherwise.  

I'm not sure if I understand you correctly here - the part where you say 
"You can design a program so that it only accepts a program as
legal Ada if a particular G�del number specifies a true theorem" 
confuses me. Are you saying that for any Pi_1 (#) formula \phi there is 
a standard Ada program \phi*, s.t. \phi* is legal Ada if and only if 
\phi is true (the transformation * being recursive)? Do you have a 
reference for this result? And why do you think this is true for all 
reasonable programming languages?

(#) Surely this is not the case for arbitrary formulae? If it is, Ada 
seems rather an odd language; I've never encountered an actually used 
computer language with correctness of a program not arithmetic.

-- 
Aatu Koskensilta (aatu.koskensilta@xortec.fi)

"Wovon man nicht sprechen kann, daruber muss man schweigen"
  - Ludwig Wittgenstein, Tractatus Logico-Philosophicus

Re: Certified C compilers for safety-critical embedded systems

[Georg Bauhaus]

Aatu Koskensilta <aatu.koskensilta@xortec.fi> wrote:
:> Can a self-hosting compiler then in theory decide whether it is
:> correct? For the former or the latter languages?
: 
: I don't think I understand your question. Are you asking about a 
: situation in which a compiler is used to compile itself?

The choice of the word "correct" was a bit thoughtless. Sorry.
I was indeed thinking about a compiler and its input when it
happens to be the compiler itself, or a patched version.
If it HALTs, I know nothing about correctness from this fact
(there wouldn't be any compiler bugs, after all).
And after reading yours and Robert Eachus' explanations, I trust
there is no way to mechanically decide whether a "real world" compiler
works correctly as described in a consistent standard, even for
the finite amount of input programs that capacity limits
will allow. Is this halfway correct?


thanks,
-- Georg

Re: Certified C compilers for safety-critical embedded systems

[Alexandre E. Kopilovitch]

Aatu Koskensilta wrote:

> >> [any compiler for a resonable language] either does not accept some
> >> legal programs, accepts some illegal  programs, or never halts for some
> >> inputs
> >>
> >>does not in any sense
> > 
> > Hm, _any_? How can you know about _any_ sense? There may be a sense of which
> > you just aren't aware (for example, a sense of _real_ general-purpose
> > programming languages and _real_ requirements for _really_used_ compilers
> > for those languages -;).
>
> Then the impossibility follows from some constraints imposed by these 
> "reality" requirements, whatever they are, and not from GО©╫del's theorem 

GО©╫del's theorem here is not a foundation or cause, but an explanation of
a fact from reality, which was observed many times. This theorem (like any
other logical or mathematical theorem) does not exist in reality, so no one
actually observable fact can _follow_ from that theorem in logical or
mathematical sense. But the theorem is an idealized construct, a clean model,
which may or may not be sufficiently adequate to some real situation. And
that is what I'd like to say: if you don't know enough about _both_ sides
of a correspondence, you can't reasonably judge about its adequacy. It does
not matter how deep is your knowledge about one side of the correspondence,
if you know too little about another side of it - in this case, have too
little experience with internals of production-line compilers, and its real
usage in sufficient scale.

> >>follow from GО©╫del's proof.
> > 
> > 
> > It can't formally follow - just because the quoted statement is not formal -
> > it couples the formal part with informal part, and the latter refers to a hard
> > reality. So, the statement isn't a logical conclusion, it is an opinion about
> > relationship between a particular logical construct and a piece of reality. 
>
> It isn't. There's a very clear sense in which the above claim can be 
> taken to be about recursive functions - in which case all sorts of 
> considerations about hard relaity are obviously irrelevant -, in this 
> case about recursive functions that perform transformations on strings. 

Well, people are different, and some things that happen to be very clear for
you, sound like absolute nonsense for me - I simply can't get (and don't want
to) why those recursive functions appeared here - they seem (for me, of course)
much more irrelevant here than my references to reality.

> In hard reality there are very few correct compilers if any, but this 
> has nothing to do with GО©╫del's theorem or its proof.

Perhaps you consider GО©╫del's theorem as a property of logicians, which is
licensed (with some strict conditions) to computer scientists... If so, I must
disappoint you - not all people agree with that position -:)



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Certified C compilers for safety-critical embedded systems

[Jeff C,]

I can't believe that no one has realized that the halting problem was SOLVED
several years
ago by Microsoft. If you are running on Windows you can be sure that before
too long the
machine will lock up and your program will halt.

(Ok..its not THAT bad anymore...but I could not resist)

Re: Certified C compilers for safety-critical embedded systems

[Pat Rogers]

As this topic no longer corresponds much to the subject line, I feel
free to give in to temptation and contribute thusly:

> "Wovon man nicht sprechen kann, daruber muss man schweigen"
>   - Ludwig Wittgenstein, Tractatus Logico-Philosophicus


"Wittgenstein was a beery swine who was just as sloshed as Schlegel."

Pat Rogers

Re: Certified C compilers for safety-critical embedded systems

[Aatu Koskensilta]

Alexandre E. Kopilovitch wrote:
> Aatu Koskensilta wrote:
> 
>>Then the impossibility follows from some constraints imposed by these 
>>"reality" requirements, whatever they are, and not from G�del's theorem 
> 
> G�del's theorem here is not a foundation or cause, but an explanation of
> a fact from reality, which was observed many times. 

G�del's theorem is an explanation of what fact? That compilers tend not 
to be correct? How would G�del's theorem explain that fact?

 > And
> that is what I'd like to say: if you don't know enough about _both_ sides
> of a correspondence, you can't reasonably judge about its adequacy. It does
> not matter how deep is your knowledge about one side of the correspondence,
> if you know too little about another side of it - in this case, have too
> little experience with internals of production-line compilers, and its real
> usage in sufficient scale.

My knowledge of production-line compilers is not relevant here. G�del's 
theorem - again, the Halting Problem seems much more appropriate here - 
can only be relevant to compilers, if the compilers are thought of as 
recursive transformations of programs into programs (in, say, assembly 
language) or somehow map into formal theories. Otherwise, since G�del's 
theorem says nothing about the intricacies of compiler technology, it's 
simply irrelevant.

Is there a reason to speak about G�del's theorem instead of the 
undecidability of Halting Problem here?

>>It isn't. There's a very clear sense in which the above claim can be 
>>taken to be about recursive functions - in which case all sorts of 
>>considerations about hard relaity are obviously irrelevant -, in this 
>>case about recursive functions that perform transformations on strings. 
> 
> 
> Well, people are different, and some things that happen to be very clear for
> you, sound like absolute nonsense for me - I simply can't get (and don't want
> to) why those recursive functions appeared here - they seem (for me, of course)
> much more irrelevant here than my references to reality.

The Halting Problems speaks about recursive functions. In order to make 
applications of it to a real world situation, you have to be able to see 
some things in the situation as being recursive functions. Otherwise 
Halting Problem tells you nothing about the situation.

>>In hard reality there are very few correct compilers if any, but this 
>>has nothing to do with G�del's theorem or its proof.
> 
> Perhaps you consider G�del's theorem as a property of logicians, which is
> licensed (with some strict conditions) to computer scientists... If so, I must
> disappoint you - not all people agree with that position -:)

I have no such opinions.

-- 
Aatu Koskensilta (aatu.koskensilta@xortec.fi)

"Wovon man nicht sprechen kann, daruber muss man schweigen"
  - Ludwig Wittgenstein, Tractatus Logico-Philosophicus

Re: Certified C compilers for safety-critical embedded systems

[Albert van der Horst]

In article <1073487133.232393@master.nyc.kbcfp.com>,
Hyman Rosen  <hyrosen@mail.com> wrote:
>Frank J. Lhota wrote:
>> But learning about m4 is a valuable exercise! It is a flexible and powerful
>> preprocessor with far more capabilities that the C preprocessor.
>
>One of the things you can learn about m4 is that it has no way of
>dealing specially with character strings, so if you're using it on
>Ada programs and innocently want to do
>     Text_IO.Put_Line("This is a UNIX system!");
>you could very easily wind up with
>     Text_IO.Put_Line("This is a 1 system!");

Of course it does.
You should have quoted it.
Text_IO.Put_Line(`"This is a UNIX system!"');

There is a good reason that m4 has its own quotes.
With it comes utmost flexibility, and a lot of headaches.
Sometimes you want expansion:
void signon()
{
   printf("NAME");
   printf("SUPPLIER");
   printf("VERSION");
   printf("DATE");
}


And if you dislike ` bracketing for m4 use changequote()
Unfortunately this breaks down when the string contains a
single quote.

I use m4 extensively, but I can appreciate that c-folks prefer
a c-aware pre-processor in behalf of the above pit falls.

Nowadays I would say the way to go is xml.
You then can never hide that something is to be expanded,
but maybe that is just as well.

--
Groetjes Albert.
-- 
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
        One man-hour to invent,
                One man-week to implement,
                        One lawyer-year to patent.

Re: Certified C compilers for safety-critical embedded systems

[Albert van der Horst]

In article <2GsAAls/KX7Z089yn@the-wire.com>,
Mel Wilson <mwilson@the-wire.com> wrote:
<SNIP>
>
>   A lemma, or consequence (if I'm not mistaken) is that you
>can calculate the fate, Halting or Not-Halting, of every
>program in a finite set of programs S, but the program that
>does this can't be in S. Even if the program took a trillion
>years, it would take them on a bigger machine than yours.
>Douglas Adams' _The Hitchhiker's Guide to the Galaxy_ does
>nice work with this in the nest of computer-designing
>hyper-super computers that would calculate the question to
>the great answer of Life, the Universe and Everything.

This may be a lemma, but it not a consequence of the Turing
halting problem. The latter is really fairly trivial.

Suppose you have a machine that analyses any machine whether it
stops. It prints yes or no. Now modify such that
instead of printing yes you go in an infinite loop.
Feed this modified machine to the original machine.
If it says yes it halts, than it says no, so the original
machines would have to say no too. Likewise the other
possibility leads to contradiction.

Your lemma requires a much harder proof (if it is true).

>        Regards.        Mel.
--
Groetjes Albert.
-- 
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
        One man-hour to invent,
                One man-week to implement,
                        One lawyer-year to patent.

Re: Certified C compilers for safety-critical embedded systems

[Alexandre E. Kopilovitch]

Aatu Koskensilta wrote:

> > GО©╫del's theorem here is not a foundation or cause, but an explanation of
> > a fact from reality, which was observed many times. 
>
> GО©╫del's theorem is an explanation of what fact? That compilers tend not 
> to be correct? How would GО©╫del's theorem explain that fact?

In short words, real compilers are under high stress, imposed on them by rich
and complex languages, which strive to provide a comprehensive set of features
for a programmer (that is, expressive power) and at the same time to satisfy
various requirements like portability, convenience of maintenance, etc. (that
is, one or another kind of generalization/propagation).

Is this stress inevitable? GО©╫del's theorem says: yes, it is inevitable - while
you are stuck to these goals.

> > And
> > that is what I'd like to say: if you don't know enough about _both_ sides
> > of a correspondence, you can't reasonably judge about its adequacy. It does
> > not matter how deep is your knowledge about one side of the correspondence,
> > if you know too little about another side of it - in this case, have too
> > little experience with internals of production-line compilers, and its real
> > usage in sufficient scale.
>
> My knowledge of production-line compilers is not relevant here.

Interesting. So, you believe that your knowledge of one thing is irrelevant to
your ability to make judgements about its relationship to another thing.

> GО©╫del's 
> theorem - again, the Halting Problem seems much more appropriate here - 

Seems to you - ok, but note that here you are on foreign territory, it is
comp.lang.ada newsgroup, not comp.logic; therefore you if want to be understood,
you should provide arguments familiar to native inhabitants. It may be more
convenient for you (for any reason) to think in terms of some particular
model, but this does not mean that others will share your preferences.

> can only be relevant to compilers, if the compilers are thought of as 
> recursive transformations of programs into programs (in, say, assembly 
> language) or somehow map into formal theories.

Dropping the sacred word "recursive" as inappropriate here, I'd like to inform
you that real production-line compilers aren't just transformations of programs
into programs, that is, from one formal text to another formal text.

First, such a compiler gets at least two input streams, and only one of them
is a formal text. Another always present input stream is the stream of
programmer's intentions. Any real compiler, even of moderate quality, tries
to guess those intentions in many cases/points, and takes them into account.

Second, a real compiler produces at least 3 output streams, and again, only
one of them is (more or less) formal text. Two other always present streams
are diagnostic-errors and diagnostic-warnings, and they aren't formal... even
diagnostic-errors isn't.

(And "getting there is just a beginning" -;)

> Is there a reason to speak about GО©╫del's theorem instead of the 
> undecidability of Halting Problem here?

Certainly yes, because the main problems are not in compilers (algorithms),
but in design of languages.

> > Well, people are different, and some things that happen to be very clear for
> > you, sound like absolute nonsense for me - I simply can't get (and don't want
> > to) why those recursive functions appeared here - they seem (for me, of course)
> > much more irrelevant here than my references to reality.
>
> The Halting Problems speaks about recursive functions. In order to make 
> applications of it to a real world situation, you have to be able to see 
> some things in the situation as being recursive functions.

Recursion means stack, and stack is very human thing, it rarely happens in
non human-made reality. Personally, I like priority queues much better -:) .



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Georg Bauhaus wrote:

> And after reading yours and Robert Eachus' explanations, I trust
> there is no way to mechanically decide whether a "real world" compiler
> works correctly as described in a consistent standard, even for
> the finite amount of input programs that capacity limits
> will allow. Is this halfway correct?

About that.  Even if an Ada compiler completely conforms to the standard 
it will reject some legal Ada programs.  That is what the section of RM 
1.1.3 I quoted was talking about.  There is no real way to determine for 
some programs if, absent the capacity limitations, the program would be 
accepted--other than to try and compile it using a compiler with more 
capacity.  If it succeeds, then you can say that you ran into capacity 
limitations earlier. (Absent compiler bugs of course.)  But if the 
second and subsequent trials fail, you still haven't found out from the 
tools whether or not you have a valid Ada program.

Having said that, there are tests in the ACATS suite, that AFAIK, have 
never been successfully compiled by any compiler.  But they are still 
believed to be legal Ada programs.  (Mostly floating point programs that 
require types with digits from 15 to 30.  Again, AFIAK some of these 
correctly compile on VAXes and on IBM mainframes, but no one has yet 
supported digits 30.)

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

David Starner wrote:

> In this sense, Ada compilers don't implement a Turing-complete language,
> nor are they written in a Turing-complete language. Modern computers, like
> any computer in the real world, are merely finite state machines, as a
> true Turing machine requires infinite storage, so G�del's proof doesn't
> apply.

Yes, all Ada implementations implement a finite subset of Ada.  But, to 
some extent the limitations are a function of the hardware, not of the 
compiler.  The usual way of talking about it is that the triplet of 
(hardware, operating system, compiler) defines a subset of Ada that can 
be compiled.  (Although in reality, you need to consider both the host 
and target hardware and OSes.)

In theory, you could write an Ada compiler that attempted to implement 
(full) Ada, and would only be limited by the actual hardware.  If you 
did that then you could talk about what G�del's Proof has to say about 
the compiler as a device for recognizing Ada.  In practice we ignore the 
fact that addresses are of a static size, since that size is often 
larger than any realistic implementation can support.  (In other words 
many compilers today support 64-bit addresses. I doubt that there is 
2**64 bytes of memory connected to the Internet.  Of course, we will 
probably get there in a few years.  But compiling programs that need 
2**64 bytes of memory when being compiled will still take longer than 
most people are willing to wait.)

The point is though, that G�del's proof does apply.  We know that no 
matter how much memory we make available to a compiler, there are some 
legal programs the compiler can't compile.  The compiler could accept 
illegal programs instead, but we try very hard to avoid that.  It is 
G�del that tells us we have to accept one or the other condition.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Aatu Koskensilta wrote:

> (#) Surely this is not the case for arbitrary formulae? If it is, Ada 
> seems rather an odd language; I've never encountered an actually used 
> computer language with correctness of a program not arithmetic.

As far as this particular case is concerned.  Yes, that is what I am 
saying.  Actually, back when MIL-STD 1815 was Ada and the ANSI standard 
effort was in progress, I wrote an example program that was legal Ada 80 
iff Fermat's Last Theorem was true.  And it was less than two pages of 
code!  The result was that in Ada 83 a compiler was not required to find 
an elaboration order that did not raise Program_Error, assuming one existed.

In Ada 83 days, I gave a presentation at a SIGAda meeting in Dallas, I 
think.  I had a very short package where the legality depended on 
whether or not the compiler generated code would raise Numeric_Error at 
run-time.  In fact, the Verdix compiler compiled the program without 
error (and ran it without an exeception).  The DEC Ada compiler declared 
the program illegal.  And of course, both were right.

We fixed that particular problem in Ada 95 with respect to 
Constraint_Error in 4.9(33-34).  There are still many cases where an Ada 
compiler is allowed to reject a program as illegal if it will always 
raise Program_Error at run-time.  It doesn't take much work to transform 
this rule into an oracle that solves the halting problem.  Of course, 
that means that some programs will fail to compile in a reasonable 
amount of time--for any definition of reasonable.

Why does this bother you?  Remember I started this by saying that with 
Ada 95, we had deliberately accepted requiring all Ada compilers to 
solve NP-complete problems.  We know that if someone wants to he can 
write a program that transforms any NP-complete problem into a bin 
packing problem, and then writes the bin packing problem as an Ada type 
with a representation specification.  If that type declaration compiles, 
the actual layout of the type is a solution to the bin packing problem. 
  The program containing  the declaration just needs to print out the 
values of some static attributes.  Now does that mean that any Ada 
compiler can solve any NP-complete problem in linear time?  Not if you 
include the compile time. ;-)

I don't recommend that as a way to solve most bin-packing problems.  So 
why do we require Ada compilers to do it?  Most bin packing problems 
have easy solutions, and if you have a record declaration it seems silly 
to say that we won't require compilers to solve the easy cases because 
there are some that are hard.  Instead we warn the compiler writers 
about the tough cases, recommend an algorithm, and moved on.  If the 
user overspecifies the record layout, it might take the compiler a while 
to find an acceptable solution.

But we can't require that compilers violate G�del's Proof and we don't. 
  We can't require them to solve the halting problem either, we just ask 
them to take their best shot.

RM 1.1.5(5-6): "Errors that are required to be detected at run time by 
the execution of an Ada program;

The corresponding error situations are associated with the names of the 
predefined exceptions. Every Ada compiler is required to generate code 
that raises the corresponding exception if such an error situation 
arises during program execution. If such an error situation is certain 
to arise in every execution of a construct, then an implementation is 
allowed (although not required) to report this fact at compilation time."

Translation:  There are some potential Ada programs that correspond to 
the halting problem.  If such a program will always raise Program_Error, 
  the implementation is ALLOWED to reject it at compile time.  If the 
compiler can't decide, it may generate code which MAY raise 
Program_Error at run time for some inputs.

So a compiler can reject programs that will raise Program_Error.  But if 
the compiler can't decide whether or not the program will, it can drop 
back and punt.  However, for any case where a compiler will ALWAYS 
reject program if it will raise Program_Error, you can do like the code 
above.  Write a partial recursive function and put the code that will 
raise Program_Error after it.  If the compiler says at compile time that 
the code will ALWAYS raise Program_Error, you know that your partial 
recursive function always halts. ;-)

The program can be messy, but take a look at 4.9.  That is the section 
that requires that static functions with static arguments be evaluated 
at compile time.  If you find an instance that is as elegant as the four 
line instance I found in Ada 83, we will probably "fix" it in Ada 1Z. 
(And for the same reason, to improve portability between compilers.) 
But if it takes a 500 line program, we will probably leave it alone.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Aatu Koskensilta wrote:

> The Halting Problems speaks about recursive functions. In order to make 
> applications of it to a real world situation, you have to be able to see 
> some things in the situation as being recursive functions. Otherwise 
> Halting Problem tells you nothing about the situation.

The Halting problem and G�del's proof are two sides of the same coin, at 
least in computer science.  The Halting problem is a constructive proof 
of G�del's proof.  In any language without partial recursive functions, 
the halting problem is trivial.  (All programs in that language always 
halt.)

If a language allows partial recursive functions, then it is Turing 
complete, and there is no general solution of the halting problem.  You 
can write a program that solves the halting problem correctly for some 
inputs.  But there are either inputs for which the program produces 
incorrect outputs, or there are inputs for which it never halts.  (And 
it is not difficult to prove that for some inputs, you won't be able to 
determine if the halting problem program will eventually halt.)

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Aatu Koskensilta]

Robert I. Eachus wrote:
> Aatu Koskensilta wrote:
> 
>> (#) Surely this is not the case for arbitrary formulae? If it is, Ada 
>> seems rather an odd language; I've never encountered an actually used 
>> computer language with correctness of a program not arithmetic.
> 
> 
> As far as this particular case is concerned.  Yes, that is what I am 
> saying.  Actually, back when MIL-STD 1815 was Ada and the ANSI standard 
> effort was in progress, I wrote an example program that was legal Ada 80 
> iff Fermat's Last Theorem was true. 

But Fermat's Last Theorem is Pi_1. What I was saying was that I find it 
very unlikely that this holds for non-Pi_1 statements, even if it holds 
for Pi_1 ones.

[Snipped an explanation on how the Halting Problem can be reduced to 
legality of Ada program]

So your original statement

  [any compiler for a resonable language] either does not accept some
  legal programs, accepts some illegal  programs, or never halts for some
  inputs

is correct if the reasonable language we're speaking about is Ada. I 
think that, say, Haskell is a reasonable language, and the above does 
not hold for it - the type system is decidable -, but perhaps you find 
Haskell unreasonable.

-- 
Aatu Koskensilta (aatu.koskensilta@xortec.fi)

"Wovon man nicht sprechen kann, daruber muss man schweigen"
  - Ludwig Wittgenstein, Tractatus Logico-Philosophicus

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Aatu Koskensilta wrote:

> So your original statement
> 
>  [any compiler for a resonable language] either does not accept some
>  legal programs, accepts some illegal  programs, or never halts for some
>  inputs
> 
> is correct if the reasonable language we're speaking about is Ada. I 
> think that, say, Haskell is a reasonable language, and the above does 
> not hold for it - the type system is decidable -, but perhaps you find 
> Haskell unreasonable.

No, I used Ada as an example because everyone here should be familiar 
with it, and I am VERY familiar with where the bodies are buried, since 
I helped bury some of them.

The proper way to describe my contention is probably:

All realizable implementations of any programming language are finite. 
(This is because the hardware is a good, but finite, imitation of a 
Turing complete system.)

If a language definition imposes limitations more restrictive than those 
imposed by the hardware, the programming language is finite.  This is 
harder to do than it seems.  For example, Java goes to extremes to 
insist that everything is a 32-bit quantity, including pointers.  But it 
doesn't prevent say a 64-bit implementation from mapping larger physical 
addresses into 32-bit pointers.  As a simple example, an implementation 
could insist that all addressable constructs begin on a 64-bit boundary 
and use 64-bit word addresses rather than 8-bit byte addresses.  (Some 
Java implementations do use word addresses in pointers.)

If the language is Turing complete, but the compiler runs on real 
hardware, then you can't use the compiler to tell the difference between 
physical limitations and cases where it is undecideable whether a 
program is illegal.  You have to rely on analysis to recognize the later 
case.

In particular, for Ada 83 I demonstrated a real case where the legality 
of a program was undecideable, and two compilers gave different (but 
correct) answers.  Given time I can probably find similar cases for all 
Turing complete programming languages, including the usual suspects of 
Fortran, Cobol, C, and Ada 95.  (C++ is so easy it seems like cheating.)

But my real point is that compiler developers can't just wish away 
G�del's proof, and they don't.  Good compilers are always careful to 
distinguish between cases where the compiler can decide that a program 
is illegal and cases where a submission exceeds the capabilities of the 
implementation, but may or may not be illegal.  The example I gave was a 
rare case where a compiler could reach a conclusion about an 
undecideable case based on the run-time behavior of the code that 
compiler would generate.  (And where two compilers were known to make 
different choices for the same hardware.)

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Robert A Duff]

"Robert I. Eachus" <rieachus@comcast.net> writes:

> Having said that, there are tests in the ACATS suite, that AFAIK, have
> never been successfully compiled by any compiler.  But they are still
> believed to be legal Ada programs.  (Mostly floating point programs that
> require types with digits from 15 to 30.  Again, AFIAK some of these
> correctly compile on VAXes and on IBM mainframes, but no one has yet
> supported digits 30.)

I think a better way to look at it is: "legality" is somewhat defined by
the compiler.  Ada compilers are not required to support "digits 30" --
so if you write such a program, it is simply illegal (for most
compilers).  And Ada compilers can detect that just fine.  Nothing to do
with Godel or Halting Problems.

Ada compilers can also detect when they are given programs that exceed
the compiler's capacity (memory to store the parse tree, for example).
Such programs are simply illegal (for that compiler).

- Bob

Re: Certified C compilers for safety-critical embedded systems

[Robert A Duff]

"Robert I. Eachus" <rieachus@comcast.net> writes:

> Aatu Koskensilta wrote:
> 
> > (#) Surely this is not the case for arbitrary formulae? If it is, Ada
> > seems rather an odd language; I've never encountered an actually used
> > computer language with correctness of a program not arithmetic.
> 
> As far as this particular case is concerned.  Yes, that is what I am
> saying.  Actually, back when MIL-STD 1815 was Ada and the ANSI standard
> effort was in progress, I wrote an example program that was legal Ada 80
> iff Fermat's Last Theorem was true.

That was simply a mistake in the wording of the Ada 80 manual.
Not a property of "all useful programming languages".

>...  There are still many cases where an Ada
> compiler is allowed to reject a program as illegal if it will always
> raise Program_Error at run-time.

No.  The Ada RM carefully distinguishes between compile-time and
run-time errors, and compilers are certainly *not* allowed to "reject as
illegal" programs that will (or might) raise exceptions.  "Reject as
illegal" means "refuse to run it".

>...  It doesn't take much work to transform
> this rule into an oracle that solves the halting problem.  Of course,
> that means that some programs will fail to compile in a reasonable
> amount of time--for any definition of reasonable.
> 
> Why does this bother you?  Remember I started this by saying that with
> Ada 95, we had deliberately accepted requiring all Ada compilers to
> solve NP-complete problems.  We know that if someone wants to he can
> write a program that transforms any NP-complete problem into a bin
> packing problem, and then writes the bin packing problem as an Ada type
> with a representation specification.  If that type declaration compiles,
> the actual layout of the type is a solution to the bin packing
> problem.

No.  There is no requirement that Ada compilers pack records optimally.
A rep-clause specifies the layout of components specified.  The compiler
must check that these do not overlap.  That can be done in linear time.
The rest of the fields can be placed anywhere the compiler likes, and
that also can be done in linear time.  There is no requirement to
(optimally) solve the bin-packing problem.

>... The program containing  the declaration just needs to print out
> the values of some static attributes.  Now does that mean that any Ada
> compiler can solve any NP-complete problem in linear time?  Not if you
> include the compile time. ;-)
> 
> I don't recommend that as a way to solve most bin-packing problems.  So
> why do we require Ada compilers to do it?  Most bin packing problems
> have easy solutions, and if you have a record declaration it seems silly
> to say that we won't require compilers to solve the easy cases because
> there are some that are hard.  Instead we warn the compiler writers
> about the tough cases, recommend an algorithm, and moved on.  If the
> user overspecifies the record layout, it might take the compiler a while
> to find an acceptable solution.
> 
> But we can't require that compilers violate G�del's Proof and we
> don't. We can't require them to solve the halting problem either, we
> just ask them to take their best shot.
> 
> RM 1.1.5(5-6): "Errors that are required to be detected at run time by
> the execution of an Ada program;
> 
> The corresponding error situations are associated with the names of the
> predefined exceptions. Every Ada compiler is required to generate code
> that raises the corresponding exception if such an error situation
> arises during program execution. If such an error situation is certain
> to arise in every execution of a construct, then an implementation is
> allowed (although not required) to report this fact at compilation time."
> 
> Translation:  There are some potential Ada programs that correspond to
> the halting problem.  If such a program will always raise Program_Error,
> the implementation is ALLOWED to reject it at compile time.  If the
> compiler can't decide, it may generate code which MAY raise
> Program_Error at run time for some inputs.

This translation is wrong.  What the RM says is that compilers can print
out a message.  It cannot "reject" such a program; it must run it.
Note "of a construct" in the RM wording.  For example:

    X := 0;
    if Some_Condition then
        X := X / X; -- divide by zero
    end if;

Every execution of the construct "X / X" will surely raise C_E, because
it divides by zero.  The compiler is allowed (but not required) to tell
you that.  It has no obligation to prove that Some_Condition will
sometimes be True.

> So a compiler can reject programs that will raise Program_Error.

No.  Compilers must *not* reject the above divide-by-zero program --
they must allow it to be run.  Even if it said "if True then" or "if
False then", it's still a legal Ada program, and we can tell that
without invoking Halting Problems.

>...  But if
> the compiler can't decide whether or not the program will, it can drop
> back and punt.  However, for any case where a compiler will ALWAYS
> reject program if it will raise Program_Error, you can do like the code
> above.  Write a partial recursive function and put the code that will
> raise Program_Error after it.  If the compiler says at compile time that
> the code will ALWAYS raise Program_Error, you know that your partial
> recursive function always halts. ;-)
> 
> The program can be messy, but take a look at 4.9.  That is the section
> that requires that static functions with static arguments be evaluated
> at compile time.

Static expressions cannot contain recursion (or even loops), so I don't
see what this has to do with Godel or the Halting Problem.

It's certainly true that some static expressions can require a huge
amount of memory to evaluate.  E.g., "2**(2**(2**(2**32)))".  I expect
any compiler to complain about that.  It's a capacity limitation, but I
don't see how it has anything to do with Godel's theorem.

>...  If you find an instance that is as elegant as the four
> line instance I found in Ada 83, we will probably "fix" it in Ada
> 1Z. (And for the same reason, to improve portability between compilers.)
> But if it takes a 500 line program, we will probably leave it alone.

- Bob

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Robert A Duff wrote:

> That was simply a mistake in the wording of the Ada 80 manual.
> Not a property of "all useful programming languages".

Ah, but the mistake required all valid Ada 80 compilers to solve the 
halting problem.  The solution was to remove that requirement.

And that is my point, when specifying programming languages such issues 
are a (maybe not common but occasional) occurance.

>...  There are still many cases where an Ada
>>compiler is allowed to reject a program as illegal if it will always
>>raise Program_Error at run-time.

> No.  The Ada RM carefully distinguishes between compile-time and
> run-time errors, and compilers are certainly *not* allowed to "reject as
> illegal" programs that will (or might) raise exceptions.  "Reject as
> illegal" means "refuse to run it".

I chose my words carefully. RM 10.2 (27) "The implementation shall 
ensure that all compilation units included in a partition are consistent 
with one another, and are legal according to the rules of the language." 
  Often failure of the compiler to determine that there is a consistent 
elaboration order means that there is no valid elaboration order.  But 
we allow the compiler to reject a program if it didn't find a valid 
order.  Why?  See above.  Requiring the compiler to find a valid order 
requires solving the halting problem.  (Note that an implementation MAY 
choose an order that cannot be shown to be inconsistant, and provide 
code that causes Program_Error if access before elaboration occurs.) 
But if there is no valid elaboration order, and the compiler detects 
that, the program is illegal.

> No.  There is no requirement that Ada compilers pack records optimally.
> A rep-clause specifies the layout of components specified.  The compiler
> must check that these do not overlap.  That can be done in linear time.
> The rest of the fields can be placed anywhere the compiler likes, and
> that also can be done in linear time.  There is no requirement to
> (optimally) solve the bin-packing problem.

There is no requirement to OPTIMALLY solve the bin-packing problem, 
true.  But if there is a size clause applied to the record, then we do 
require the compiler to find a consistant solution if one exists.

>>The corresponding error situations are associated with the names of the
>>predefined exceptions. Every Ada compiler is required to generate code
>>that raises the corresponding exception if such an error situation
>>arises during program execution. If such an error situation is certain
>>to arise in every execution of a construct, then an implementation is
>>allowed (although not required) to report this fact at compilation time."
>>
>>Translation:  There are some potential Ada programs that correspond to
>>the halting problem.  If such a program will always raise Program_Error,
>>the implementation is ALLOWED to reject it at compile time.  If the
>>compiler can't decide, it may generate code which MAY raise
>>Program_Error at run time for some inputs.
> 
> This translation is wrong.  What the RM says is that compilers can print
> out a message.  It cannot "reject" such a program; it must run it.
> Note "of a construct" in the RM wording.  For example:
> 
>     X := 0;
>     if Some_Condition then
>         X := X / X; -- divide by zero
>     end if;
> 
> Every execution of the construct "X / X" will surely raise C_E, because
> it divides by zero.  The compiler is allowed (but not required) to tell
> you that.  It has no obligation to prove that Some_Condition will
> sometimes be True.

I agree with you on this case.  I was thinking about the case where the 
implementation detects that there is no LEGAL elaboration order.  Such a 
program is illegal and may be rejected.  If it cannot be detected 
whether a valid elaboration order exists, then the compiler MUST 
generate code to raise Program_Error if an illegal elaboration order 
occurs.  The "classic" case is a program that has a library unit that 
reads in input from the user, (in the sequence of statements in the 
program body) and either makes or doesn't make a call to the main 
program before it is elaborated.

> No.  Compilers must *not* reject the above divide-by-zero program --
> they must allow it to be run.  Even if it said "if True then" or "if
> False then", it's still a legal Ada program, and we can tell that
> without invoking Halting Problems.

Agreed.

> Static expressions cannot contain recursion (or even loops), so I don't
> see what this has to do with Godel or the Halting Problem.
> 
> It's certainly true that some static expressions can require a huge
> amount of memory to evaluate.  E.g., "2**(2**(2**(2**32)))".  I expect
> any compiler to complain about that.  It's a capacity limitation, but I
> don't see how it has anything to do with Godel's theorem.

Go back and read G�del.  He uses a clever encoding of a logical calculus 
in the factors of (large) numbers (G�del numbering) to show that 
arbitrary statements can be encoded in an arithmetic formula with a 
limited number of terms.  That showed that recursion is not necessary to 
cause a language to accept contradictory statements.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Certified C compilers for safety-critical embedded systems

[Hyman Rosen]

Albert van der Horst wrote:
> Of course it does.
> You should have quoted it.
> Text_IO.Put_Line(`"This is a UNIX system!"');

I didn't say that you couldn't quote things, I said that it had
no facility for dealing specially with character strings.

Re: Certified C compilers for safety-critical embedded systems

[Robert A Duff]

"Jean-Pierre Rosen" <rosen@adalog.fr> writes:

> > "Stephen Leake" <Stephe.Leake@nasa.gov> wrote in message
> > news:mailman.212.1073342204.31149.comp.lang.ada@ada-france.org...
> > Apparently there were some people on the design team for Ada 83 who
> > thought "function" meant "no side effects", and want to "enforce"
> > that. Of course, functions can have side effects; now they just have
> > to lie about it!
> I've seen this argument quite often (especially by RBKD), but it is totally bogus.
> Nobody claimed that functions should not have side effects, but only that functions compute a result given some parameters and the
> global state of the program. It was felt that it was OK for a function to modify the global state, but modifying the parameters
> would be surprising and error-prone.

Why would modifying parameters be more surprising than modifying
globals?

- Bob

Re: Certified C compilers for safety-critical embedded systems

[Robert A Duff]

"Robert I. Eachus" <rieachus@comcast.net> writes:

> Robert A Duff wrote:
> 
> > That was simply a mistake in the wording of the Ada 80 manual.
> > Not a property of "all useful programming languages".
> 
> Ah, but the mistake required all valid Ada 80 compilers to solve the
> halting problem.  The solution was to remove that requirement.
> 
> And that is my point, when specifying programming languages such issues
> are a (maybe not common but occasional) occurance.

Well said.

- Bob

Re: Certified C compilers for safety-critical embedded systems

[Aatu Koskensilta]

Robert I. Eachus wrote:

> Aatu Koskensilta wrote:
> 
>> The Halting Problems speaks about recursive functions. In order to 
>> make applications of it to a real world situation, you have to be able 
>> to see some things in the situation as being recursive functions. 
>> Otherwise Halting Problem tells you nothing about the situation.
> 
> 
> The Halting problem and G�del's proof are two sides of the same coin, at 
> least in computer science.  The Halting problem is a constructive proof 
> of G�del's proof. 

How is that? In what sense was G�del's original proof non-constructive?

> If a language allows partial recursive functions, then it is Turing 
> complete, and there is no general solution of the halting problem.  You 
> can write a program that solves the halting problem correctly for some 
> inputs.  But there are either inputs for which the program produces 
> incorrect outputs, or there are inputs for which it never halts.  (And 
> it is not difficult to prove that for some inputs, you won't be able to 
> determine if the halting problem program will eventually halt.)

Why is this relevant to the question of whether a compiler can correctly 
recognise all legal programs and reject all illegal ones? Most languages 
do not define "legal" by means of undecidable run-time behaviour. 
Perhaps Ada is different here. You mentioned earlier that producing a 
C++ program which would defeat a given compiler was "trivial". Could you 
provide some details?

-- 
Aatu Koskensilta (aatu.koskensilta@xortec.fi)

"Wovon man nicht sprechen kann, daruber muss man schweigen"
  - Ludwig Wittgenstein, Tractatus Logico-Philosophicus

Re: Certified C compilers for safety-critical embedded systems

[Robert I. Eachus]

Aatu Koskensilta wrote:
>> The Halting problem and G�del's proof are two sides of the same coin, 
>> at least in computer science.  The Halting problem is a constructive 
>> proof of G�del's proof. 
> 
> 
> How is that? In what sense was G�del's original proof non-constructive?

I didn't say that.  What I meant (and think I said) was that in Computer 
Science showing that a computer language allows you to write the proof 
by contradiction in the Halting problem is the easiest way to prove by 
example that, for a given language, undecidability applies at a 
fundamental level.

> Why is this relevant to the question of whether a compiler can correctly 
> recognise all legal programs and reject all illegal ones? Most languages 
> do not define "legal" by means of undecidable run-time behaviour.

But most languages do define what programs are legal in an 
implementation independent manner.

As I said here before, there are languages which can be recognized by a 
finite state machine.  For such languages, it is clear that recognition 
is a decidable problem.  The next step up is to languages which can 
require an arbitrary/indefinite (your choice of word) amount of retained 
state do determine whether or not a program is legal.  Once you show 
that for any amount state, there is a program that requires more 
retained state to determine whether it is legal, you are done.

> Perhaps Ada is different here. You mentioned earlier that producing a 
> C++ program which would defeat a given compiler was "trivial". Could you 
> provide some details?

The easiest for most C++ programs is to create two program identifiers 
that hash/mangle to the same value.  The "Birthday Paradox" usually 
makes a computer search for such a pair not too hard, even if the 
mangled names are large enough--and the mangling algorithm is complex 
enough--to make it hard to find a name that mangles to match a single 
existing name.  A good C++ implementation could prefent the resulting 
program from compiling and linking, but it can't produce a working 
executable.  And of course, a program that has one of the two names as a 
linkname is perfectly fine.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: In-Out Parameters for functions (was: Re: Certified C compilers for safety-critical embedded systems

[Dave Thompson]

On Fri, 09 Jan 2004 13:35:17 GMT, Marin David Condic
<nobody@noplace.com> wrote:

> Yeah, but as far as I can tell C always had "in only" parameters and 
> everything was a function returning a result. The only way you could get 
> "in out" mode was passing addresses (indistinguishable to the garden 

C has always had only pass-by-value (explicitly) which means that a
(formal) parameter is locally initialized/copied from the caller's
(actual) argument. Unless you declare it const (from C89 onward) you
can within the function assign to the *local copy* of the parameter,
with no effect on the argument; this is only sort of like "in".

With the important caveat that there are no array values as such at
all in C; with minor exceptions not relevant here any use of an array
actually uses a pointer (to its first element); subscripting *such a
pointer* accesses the array; and declaring a parameter as an array
actually makes it a pointer (unlike a local or global variable, where
declaring an array produces an array). So arrays (only) are
effectively by-reference, and from C89 can be distinguished as "in" or
"in out" (but visibly shared in both cases) by use of const.

For any other (non-array) type yes you must explicitly pass and use a
pointer to get "in out" and/or visible sharing.

Yes everything is a function, but from C89 a function can be declared
as returning nothing using the special (pseudo?)type "void".

> variety programmer from a 'Access) and of course dealing with all the 
> errors that resulted from no checking that a parameter actually was an 
> address. Such a setup didn't seem to hurt C with respect to popularity 
> or getting Fortran programmers to understand it.
> 
From C89 you can (and should!) declare functions using "prototype"
form which gives the parameter types -- and optionally names, which
contribute nothing to the declaration except allow it to be textually
identical to the header in the definition/body, which in turn allows
cut&paste, manipulation by simple tools like awk, preprocessor tricks,
and such. Arguments to a *prototyped* function (from C) are (required
to be) checked that they agree (well enough) in type. This doesn't
particularly help for interfacing from Fortran, but see below.

> Robert A Duff wrote:
> > 
> > As far as I can remember, this idea was considered, and was generally
> > thought to be ugly.  I mean, suppose you're trying to convince a Fortran
> > programmer to use Ada for numerics stuff.  If you start babbling about
> > aliased and 'Access when there is no inherent need for pointers,
> > they're going to laugh, and rightly so.
> > 

C's quirks have certainly confused quite a lot of people and the
array/pointer relationship constitutes I would estimate at least an
eighth of comp.lang.c all by itself. Certainly they have not *blocked*
C's wide use, but whether it would have spread more/quicker without is
a question no one can answer. And issues about correct pointers or
addresses for C interfacing are quite common in comp.lang.fortran,
although the now-pending revision (still called F2003 but not official
yet last I checked) adds C-interop features that should (if and when
implemented and used) make this more robust.

- David.Thompson1 at worldnet.att.net

Re: In-Out Parameters for functions

[Wojtek Narczynski]

Hello,

I don't follow, and I would like to, because I find [IN] OUT params
for functions very useful. Could you please elaborate on that a bit
more?

> And only one seems still valid: it is about
> complex expressions where a function call may be used as an actual argument
> for another function. I believe that that objection will be covered by the
> following 3rd rule for IN OUT parameters for functions:
> 
> 3) in a function call, an actual argument that corresponds to IN OUT formal
>    parameter must be a variable, and must be preceeded by the keyword VAR.
> 
> For example:
> 
>   X := Random(var Y);
> 
> With this rule any confusion becomes improbable, and readability flourishes.
> 

Looks like you are proposing a new keyword, which is likely to have
been used as variable name. This rarely goes in.

Regards,
Wojtek


PS. When I last raised this issue, Randy Buckhard was kind enough to
explain it to me in this post:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&frame=right&rnum=31&thl=1052791649,1052608147,1051351022,1051243512,1051879196,1051837965,1051735064,1051655015,1051488994,1051348161,1051239613,1051695835&seekm=5ad0dd8a.0307120438.6aac89b5%40posting.google.com#link34

And asked wether we "havd to discuss this AGAIN?" 

:-)

RE: In-Out Parameters for functions

[amado.alves]

"I don't follow, and I would like to, because I find [IN] OUT params
for functions very useful. Could you please elaborate on that a bit
more?"
Maybe the most common example is the idiom (illegal in Ada):
  while Next (Item) loop
    Do_Something (Item);
  end loop;
where the Next function returns false in no more items are available,
and Item is an (illegal) in out parameter which holds the result of
a 'successful' call (and holds garbage on unsuccessful calls--this is 
the ugly bit). The above idiom is perhaps the most clean solution for
the associated problem. I know I invariably use it when I write in C.
(Sorry for the possibly illformatted text. 
I'm stuck with a crapy webmail system.)

Re: In-Out Parameters for functions

[Jean-Pierre Rosen]

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


"amado.alves" <amado.alves@netcabo.pt> a �crit dans le message de news:mailman.7.1074873660.2270.comp.lang.ada@ada-france.org...
>"I don't follow, and I would like to, because I find [IN] OUT params
>for functions very useful. Could you please elaborate on that a bit
>more?"
>Maybe the most common example is the idiom (illegal in Ada):
>  while Next (Item) loop
>    Do_Something (Item);
>  end loop;

I understand pros and cons of  in out for functions, but this one is really not convincing.
I always write:

while More_To_Come loop
   Get (Item);
   Do_Something (Item);
end loop;

Of course, Get raises an exception if there are no more items available, so it is a lot more secure.
Well, of course, security and exceptions are not an issue when you program in C...

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Wojtek Narczynski wrote:

> I don't follow, and I would like to, because I find [IN] OUT params
> for functions very useful. Could you please elaborate on that a bit
> more?
>
> > And only one seems still valid: it is about
> > complex expressions where a function call may be used as an actual argument
> > for another function. I believe that that objection will be covered by the
> > following 3rd rule for IN OUT parameters for functions:
> > 
> > 3) in a function call, an actual argument that corresponds to IN OUT formal
> >    parameter must be a variable, and must be preceeded by the keyword VAR.
> > 
> > For example:
> > 
> >   X := Random(var Y);
> > 
> > With this rule any confusion becomes improbable, and readability flourishes.
> > 

I don't get clear - which point should be elaborated? (for me all that looks
pretty straightforward, complete and unambiguous -:)

> Looks like you are proposing a new keyword,

Actually no - it was more a part of live discussion, then a polished proposal,
so "var" there was just an example of what may be used there. Although I am
not so frightened by new keywords, in this particular case there is no strong
need of one: for example, ACCEPT reserved word may be used here:

   X := Random(accept Y);

or simply IN OUT:

   X := Random(in out Y);

so just choose what you like better -:)

> PS. When I last raised this issue, Randy Buckhard was kind enough to
> explain it to me in this post:
> ...
> And asked wether we "havd to discuss this AGAIN?" 

I don't think that here is any problem. Certainly, Ada language designers
have a good reason to sigh when this issue pops up again. But nevertheless,
we programmers not only have a right to discuss the language issues that
disturb us, but even must do that.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Wojtek Narczynski]

Hello,

> I don't get clear - which point should be elaborated? 
> (for me all that looks pretty straightforward, 
> complete and unambiguous -:)

This worry is unclear to me:

>> And only one seems still valid: it is about complex 
>> expressions where a function call may be used as 
>> an actual argument for another function. 

I don't see how adding IN OUT arguments could make things worse in
this matter. A function can have side effects on global state, it can
have side effects on its IN paramerters (by using the Rosen trick). I
just don't see how documenting those side effects in the function
specification could make things worse.


> (...) But nevertheless, we programmers not only have 
> a right to discuss the language issues that disturb us,
> but even must do that.

I guess :-)


Regards,
Wojtek

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Wojtek Narczynski wrote:

> This worry is unclear to me:
>
> >> And only one seems still valid: it is about complex 
> >> expressions where a function call may be used as 
> >> an actual argument for another function. 
>
> I don't see how adding IN OUT arguments could make things worse in
> this matter.

Look at this formulae:

  F(A) + G(A);

If F is permitted to change value of A then the result of the formulae may
depend on order of computation. And this is obviously dangerous, because the
formulae looks as typical mathematical expression, where this effect usually
is not anticipated. Then notice that the expressions often may be more 
complicated... something like this:

  F(A, B) * G(C, F(A, D)) + G(A, B) * F(C, G(A, D))

Add to that possible optimization issues, and probably you will see some
reason to worry.

Expressions with functions are too important part of a language like Ada,
where various scientific formulas are used very often in typical applications.
Therefore this part must be made safe enough and must respect mathematical
viewpoint, which is naturally and commonly associated with formulas.

> A function can have side effects on global state, it can
> have side effects on its IN paramerters (by using the Rosen trick).

Yes, but if a programmer produces/uses side effects on global state in a
function and especially if he changes IN parameters by any trick, he at least
knows that he is doing irregular things - and takes responsibilty for that.
Providing IN OUT parameters for functions we remove this mental warning/deterrent.

> I just don't see how documenting those side effects in the function
> specification could make things worse.

The problem is that it may be not enough to document those possible side
effects in the function's specification - and the above point is exactly
about that. By requiring it to be documented in call site also, we ensure
that the caller is aware of possible side effect there and agreed with it.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Robert A Duff]

"Alexandre E. Kopilovitch" <aek@VB1162.spb.edu> writes:

> Wojtek Narczynski wrote:
> 
> > This worry is unclear to me:
> >
> > >> And only one seems still valid: it is about complex 
> > >> expressions where a function call may be used as 
> > >> an actual argument for another function. 
> >
> > I don't see how adding IN OUT arguments could make things worse in
> > this matter.
> 
> Look at this formulae:
> 
>   F(A) + G(A);
> 
> If F is permitted to change value of A then the result of the formulae may
> depend on order of computation. And this is obviously dangerous, because the
> formulae looks as typical mathematical expression, where this effect usually
> is not anticipated.

That might be a good argument against side effects in functions, but
Wojtek Narczynski is asking why, given that side effects in functions
are allowed in Ada, is it damaging to allow side effects on 'in out'
parameters.  The F and G functions above might both write upon global
variable X.  How could writing upon parameter A be any worse?

> > A function can have side effects on global state, it can
> > have side effects on its IN paramerters (by using the Rosen trick).
> 
> Yes, but if a programmer produces/uses side effects on global state in a
> function and especially if he changes IN parameters by any trick, he at least
> knows that he is doing irregular things - and takes responsibilty for that.
> Providing IN OUT parameters for functions we remove this mental
> warning/deterrent.

The person reading the body of F or G can of course know what's going
on.  But the person reading the expression "F(A) + G(A)" has no idea.
Allowing 'in out' parameters would not change that fact.

> > I just don't see how documenting those side effects in the function
> > specification could make things worse.
> 
> The problem is that it may be not enough to document those possible side
> effects in the function's specification - and the above point is exactly
> about that. By requiring it to be documented in call site also, we ensure
> that the caller is aware of possible side effect there and agreed with it.

I agree that requiring syntax at the call site to indicate side effects
would be a good idea.  But that's not an argument against 'in out'
parameters of functions.

- Bob

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Robert A Duff wrote:

> > Look at this formulae:
> > 
> >   F(A) + G(A);
> > 
> > If F is permitted to change value of A then the result of the formulae may
> > depend on order of computation. And this is obviously dangerous, because the
> > formulae looks as typical mathematical expression, where this effect usually
> > is not anticipated.
>
> That might be a good argument against side effects in functions, but
> Wojtek Narczynski is asking why, given that side effects in functions
> are allowed in Ada, is it damaging to allow side effects on 'in out'
> parameters.  The F and G functions above might both write upon global
> variable X.  How could writing upon parameter A be any worse?

The F and G functions may both update global variable X, but neither of them
uses that X for computing the result, and this is what makes difference.

Commonly, if several functions may be used in the same expression then they
either update some global variable or use it for computing result, but not both.
That is, if one of them updates a global variable then others should not use
this variable for computation of their results.

So, writing upon global variables in functions may be safe enough - while we
honor the above rule.

But parameters of a function are expected to participate in the computation
of the result, and this is common case. So, even a particular parameter in
a function is not used for computation of the result of *this* function, it
easily may be passed to another function within the same expression and
influence its result.

Therefore, IN OUT parameters in functions will not be worse than the ability
of functions to change global variables if we forbid use of such functions in
expressions, that is:

  If at least one parameter of a function is in IN OUT mode then the function
  cannot be used in a compound expression. This function's call must always
  constitute the whole RHS of an assignment.

or less restrictive rule:

  If at least one parameter of a function is in IN OUT mode then in any
  expression in which this function is called all other calls may be for
  parameterless functions only.





Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On Mon, 26 Jan 2004 00:02:45 +0300 (MSK), "Alexandre E. Kopilovitch"
<aek@VB1162.spb.edu> wrote:

>Therefore, IN OUT parameters in functions will not be worse than the ability
>of functions to change global variables if we forbid use of such functions in
>expressions, that is:
>
>  If at least one parameter of a function is in IN OUT mode then the function
>  cannot be used in a compound expression. This function's call must always
>  constitute the whole RHS of an assignment.
>
>or less restrictive rule:
>
>  If at least one parameter of a function is in IN OUT mode then in any
>  expression in which this function is called all other calls may be for
>  parameterless functions only.

What about:

F(X) and then F(X)

The rule, if any, should prevent using an object in IN OUT mode in an
expression where the evaluation order is not specfied by the language.

Looks much like the aliasing problem:

procedure Foo (X, Y : in out Object) is
begin
   X := F(X) + F(Y); -- Is this legal?
   Foo (X, X); -- And this?
end Foo;

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: In-Out Parameters for functions

[Wojtek Narczynski]

Hello,

> The F and G functions may both update global variable X, but neither of them
> uses that X for computing the result, and this is what makes difference.

Oh, I can easily imagine functions H and J that both do read
_and_write_ a global variable Y.

Perhaps just expressions with value (and side effect) dependent on the
order of computation, should not be allowed. It would be a good rule,
but it is too late for it, I guess.

Or the order of computation should be explicitly defined as left to
right. Or maybe it already is, and I don't know about it :-)

Regards,
Wojtek

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Wojtek Narczynski wrote:

> > The F and G functions may both update global variable X, but neither of them
> > uses that X for computing the result, and this is what makes difference.
>
> Oh, I can easily imagine functions H and J that both do read
> _and_write_ a global variable Y.

And use this global variable Y for computing their results? If you really can
easily imagine all that mess for professional Ada programmers then perhaps you
must be sent back to undergraduate courses -;) .

Note that there are fully legitimate and safe cases where functions actually
read and write global variables, but *not use those variables for computing
thier results*. (I think that in majority of reasonable cases where several
functions use the same global variable both for reading and writing, that
global variable is an array).

> Perhaps just expressions with value (and side effect) dependent on the
> order of computation, should not be allowed. It would be a good rule,
> but it is too late for it, I guess.

You are in hurry? You expect end of the world? -:)  Well, I think that you'll
be able to formulate some good *exact and complete* rule of this kind not
earlier than the ARG will call for proposals for Ada1Z -;) .




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Dmitry A. Kazakov wrote:

> >Therefore, IN OUT parameters in functions will not be worse than the ability
> >of functions to change global variables if we forbid use of such functions in
> >expressions, that is:
> >
> >  If at least one parameter of a function is in IN OUT mode then the function
> >  cannot be used in a compound expression. This function's call must always
> >  constitute the whole RHS of an assignment.
> >
> >or less restrictive rule:
> >
> >  If at least one parameter of a function is in IN OUT mode then in any
> >  expression in which this function is called all other calls may be for
> >  parameterless functions only.
>
> What about:
>
> F(X) and then F(X)

Naturally, forbidden. Perhaps the wording of my (above) "less restrictive rule"
was not good enough, but I meant that "all other calls" includes other calls
of the mentioned function (which has an IN OUT parameter), and that the meaning
is entirely static, not dynamic. So, probably at least one correction should
be made in this rule - replacing "calls" by "references":

  If at least one parameter of a function is in IN OUT mode then in any
  expression in which this function is called all other references may be
  for parameterless functions only.

Well, I leave the exact wording of the rule to native English speakers -;) .

> The rule, if any, should prevent using an object in IN OUT mode in an
> expression where the evaluation order is not specfied by the language.

Yes, certainly. And I'd forbid that even if that order IS specified but may be
non-obvious... actually I'd forbid that in all cases where that order can
matter at all - for anything.

> Looks much like the aliasing problem:
>
> procedure Foo (X, Y : in out Object) is
> begin
>   X := F(X) + F(Y); -- Is this legal?
>   Foo (X, X); -- And this?
> end Foo;

Perhaps legal, but awfully wrong -;)




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Robert A Duff]

wojtek@power.com.pl (Wojtek Narczynski) writes:

> Hello,
> 
> > The F and G functions may both update global variable X, but neither of them
> > uses that X for computing the result, and this is what makes difference.
> 
> Oh, I can easily imagine functions H and J that both do read
> _and_write_ a global variable Y.
> 
> Perhaps just expressions with value (and side effect) dependent on the
> order of computation, should not be allowed. It would be a good rule,
> but it is too late for it, I guess.

The issue is not so simple.  Consider, for example:

    P(F(...), G(...));

and F does "new T", and G also does "new T".  Thus both F and G are both
reading and writing the same variable (namely, the Storage_Pool of T).
But this example is (probably) harmless, even though the 'Address of the
allocated objects will be different depending on the evaluation order.

The same would occur if you have a Unique_Id function that increments a
global integer, and returns a unique number (private type) -- clients
aren't supposed to care about the order of numbers -- just that they're
unique.  If F and G both call Unique_Id, there's no harm.

> Or the order of computation should be explicitly defined as left to
> right. Or maybe it already is, and I don't know about it :-)

No, order of parameter eval is not required to be left-to-right in Ada.

- Bob

Re: In-Out Parameters for functions

[Robert A Duff]

"Alexandre E. Kopilovitch" <aek@VB1162.spb.edu> writes:

>   If at least one parameter of a function is in IN OUT mode then the function
>   cannot be used in a compound expression. This function's call must always
>   constitute the whole RHS of an assignment.

But this allows:

    A(I) := F(I);

where A is an array, and F modifies its parameter I.

- Bob

Re: In-Out Parameters for functions

[Hyman Rosen]

Robert A Duff wrote:
> But this allows:
>     A(I) := F(I);
> where A is an array, and F modifies its parameter I.

You know, Java hasn't lost any business by specifying
order of evaluation. There's a lot to be said for strict
left-to-rightness, operands before operation. Under that
paradigm, the compiler would evaluate I and use it to fix
the identity of the object referred to by A(I). Then it
calls F with I as the parameter. If you said
     A(I) := F(I) + I
and F changed I, the sum would use the changed I. If you
said
     A(I) := I + F(I)
the sum would use the original I.

Of what use is lack of specificty? I think the days where
this could significant speed difference in the generated
code are long gone.

Re: In-Out Parameters for functions

[Robert A Duff]

Hyman Rosen <hyrosen@mail.com> writes:

> Robert A Duff wrote:
> > But this allows:
> >     A(I) := F(I);
> > where A is an array, and F modifies its parameter I.
> 
> You know, Java hasn't lost any business by specifying
> order of evaluation. There's a lot to be said for strict
> left-to-rightness, operands before operation.

True.  At least that way, you don't get different answers on different
implementations.

But it's still hard to understand statements/expressions that have
mutually-depndent side-effecting operations in the middle.
It does seem of some value to attempt to make sure "order doesn't
matter".

- Bob

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Robert A Duff wrote:

>   If at least one parameter of a function is in IN OUT mode then the function
>   cannot be used in a compound expression. This function's call must always
>   constitute the whole RHS of an assignment.
>
> But this allows:
>
>    A(I) := F(I);
>
> where A is an array, and F modifies its parameter I.

Yes, you are certainly right, and I overlooked this standard trap (well-known
from Algol-60 times). But nevertheless I think that in this particular context
- when we are talking about the difference between changing global variables
and IN OUT parameters, this counter-example is not valid - I think that there
is no significant difference between using global variable as index and that
in the example.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Hyman Rosen]

Robert A Duff wrote:
> It does seem of some value to attempt to make sure "order doesn't matter".

But since this will never be the case in Ada, the next best thing is to
define the order.

Re: In-Out Parameters for functions

[Stephen Leake]

"Alexandre E. Kopilovitch" <aek@VB1162.spb.edu> writes:

> Look at this formulae:
> 
>   F(A) + G(A);
> 
> If F is permitted to change value of A then the result of the formulae may
> depend on order of computation. And this is obviously dangerous, because the
> formulae looks as typical mathematical expression, where this effect usually
> is not anticipated. 

Hmm. Let F be Sqrt (Ada.Numerics.Float_Random.Random), and G be
Ada.Numerics.Float_Random.Random. Then we see that Ada _requires_ the
behavior you are describing. So it's clearly a Good Thing :).

Which is pretty ironic, since one reason
Ada.Numerics.Float_Random.Random is defined as a function is to
satisfy some notion of "mathematical purity". The closest the AARM
comes to saying that is in AARM A.5.2:

32.b
          Reason: The requirement for a level of indirection in
          accessing the internal state of a generator arises from the
          desire to make Random a function, rather than a procedure.

Given that Ada _requires_ that users be allowed to write expressions
with the order dependency you describe, what would be wrong with defining
Ada.Numerics.Float_Random.Random with parameter mode "in out"? 

Or, to be fully consistent, Ada.Numerics.Float_Random.Random should be
a procedure.

I'll have to remember to never add two functions of a random number
together in one expression, if I want truly portable results. I don't
think I actually do that, anyway; there are usually intermediate
values when a final result depends on more than one random number. 

But I suspect casual users of random numbers will not be worried about
precisely repeatable results from different compilers for this kind of
expression.

Users will always be able to shoot themselves in the foot. The
language should help them avoid that, but it cannot prevent it. The
language needs to find a reasonable balance between prevention of bad
effects and expressive power. In this particular case I think Ada
strayed too far to the "prevention" side. 

C++, on the other hand, is too far on the "expressive" side in
general.

-- 
-- Stephe

Re: In-Out Parameters for functions

[Stephen Leake]

Hyman Rosen <hyrosen@mail.com> writes:

> Robert A Duff wrote:
> > It does seem of some value to attempt to make sure "order doesn't matter".
> 
> But since this will never be the case in Ada, the next best thing is to
> define the order.

Hmm. It's very unlikely that Ada will change to define the order of
execution in expressions. There are good reasons to leave it undefined
(different optimizations for different targets or speed/space goals,
for example), and changing it would be work for existing compilers.

On the other hand, I can enforce a style rule that says "don't write
expressions whose result depends on order of execution". I could even
write an ASIS tool to help enforce that.

I think this style rule is what Robert is suggesting here.

So I'm not clear what you are saying, Hymen.

-- 
-- Stephe

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On Mon, 26 Jan 2004 23:19:49 +0300 (MSK), "Alexandre E. Kopilovitch"
<aek@VB1162.spb.edu> wrote:

>Dmitry A. Kazakov wrote:
>
>> >Therefore, IN OUT parameters in functions will not be worse than the ability
>> >of functions to change global variables if we forbid use of such functions in
>> >expressions, that is:
>> >
>> >  If at least one parameter of a function is in IN OUT mode then the function
>> >  cannot be used in a compound expression. This function's call must always
>> >  constitute the whole RHS of an assignment.
>> >
>> >or less restrictive rule:
>> >
>> >  If at least one parameter of a function is in IN OUT mode then in any
>> >  expression in which this function is called all other calls may be for
>> >  parameterless functions only.
>>
>> What about:
>>
>> F(X) and then F(X)
>
>Naturally, forbidden. Perhaps the wording of my (above) "less restrictive rule"
>was not good enough, but I meant that "all other calls" includes other calls
>of the mentioned function (which has an IN OUT parameter), and that the meaning
>is entirely static, not dynamic. So, probably at least one correction should
>be made in this rule - replacing "calls" by "references":
>
>  If at least one parameter of a function is in IN OUT mode then in any
>  expression in which this function is called all other references may be
>  for parameterless functions only.

This limitation has no sense for short-circuit operations.

>Well, I leave the exact wording of the rule to native English speakers -;) .
>
>> The rule, if any, should prevent using an object in IN OUT mode in an
>> expression where the evaluation order is not specfied by the language.
>
>Yes, certainly. And I'd forbid that even if that order IS specified but may be
>non-obvious... actually I'd forbid that in all cases where that order can
>matter at all - for anything.

The problem is that this cannot be checked in a reasonable way because
of aliasing. And I am afraid that for Ada newcomers the effect would
be even more frustrating than in the case accessibility checks. If we
had pure functions there could be a more attractive (?) aternative: to
fix the evaluation order if a non-pure function gets involved.

>> Looks much like the aliasing problem:
>>
>> procedure Foo (X, Y : in out Object) is
>> begin
>>   X := F(X) + F(Y); -- Is this legal?
>>   Foo (X, X); -- And this?
>> end Foo;
>
>Perhaps legal, but awfully wrong -;)

A bound error? (:-))

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: In-Out Parameters for functions

[Peter Amey]

Interesting sub thread.  It has raised all the nastiness of function 
side effects, evaluation order dependency and aliasing.  FWIW, avoiding 
these kinds of issue were a major motivator in the design of SPARK. 
SPARK functions never have side effects, the language is free from 
evaluation order dependencies and aliasing is efficiently detected in 
all cases.  These steps, in our opinion, are a necessary precondition 
for rigorous static analysis.

regards

Peter

Alexandre E. Kopilovitch wrote:
> Wojtek Narczynski wrote:
> 
> 
>>This worry is unclear to me:
>>
>>
>>>>And only one seems still valid: it is about complex 
>>>>expressions where a function call may be used as 
>>>>an actual argument for another function. 
>>
>>I don't see how adding IN OUT arguments could make things worse in
>>this matter.
> 
> 
> Look at this formulae:
> 
>   F(A) + G(A);
> 
> [snip]

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On Tue, 27 Jan 2004 02:26:17 GMT, Hyman Rosen <hyrosen@mail.com>
wrote:

>Robert A Duff wrote:
>> It does seem of some value to attempt to make sure "order doesn't matter".
>
>But since this will never be the case in Ada, the next best thing is to
>define the order.

There could be also an opposite point of view. Fixing the evaluation
order you strengthen the "precondition" of the code. I believe that D.
Gries in his The Science of Programming argued to do exactly the
opposite. For example, that the case statement should run all
alternatives in parallel when more than one guard is open etc. His
point, if I correctly remember, was lesser precondition, more general
and better code. Actually this is the old "and" vs. "and then" debate.

Just as an independent observer. (:-))

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: In-Out Parameters for functions

[Wojtek Narczynski]

> And use this global variable Y for computing their results? 
> If you really can easily imagine all that mess for professional Ada 
> programmers then perhaps you must be sent back to undergraduate courses -;) .

Yes, I can imagine that. If the professional programmer only looks at
the specification of those functions, he or she will not know. This is
why I think F + G is worse than F(Y) + G(Y), even if the result of
this expression depends on the order of evaluation of F and G.
 
> Note that there are fully legitimate and safe cases where functions actually
> read and write global variables, but *not use those variables for computing
> thier results*. (I think that in majority of reasonable cases where several
> functions use the same global variable both for reading and writing, that
> global variable is an array).

For function with side effects to remain a function, you need to
consider all its inputs and outputs. It doesn't matter wether you
'return' a result or store it in a global variable.

> You are in hurry? You expect end of the world? -:)  Well, I think that you'll
> be able to formulate some good *exact and complete* rule of this kind not
> earlier than the ARG will call for proposals for Ada1Z -;) .

No rule that would break a lot of code will ever go in.

Regards,
Wojtek

Re: In-Out Parameters for functions

[Wojtek Narczynski]

Hello,

> The issue is not so simple.  Consider, for example:
> 
>     P(F(...), G(...));
> 
> and F does "new T", and G also does "new T".  Thus both F and G are both
> reading and writing the same variable (namely, the Storage_Pool of T).

Point taken, not simple.

> No, order of parameter eval is not required to be left-to-right in Ada.

So it looks to me like there is indeed an issue with in out parameters
(and global state)  for functions that the same program can behave
differently compiled with different compilers.

But as you pointed out, vast majority of side effects are commutative
(allocation, counters).

I also suspect that in real implementations the order is left to
right. Unless some optimizations are in effect. And unless
you-know-who has hidden his secret compiler of mass compilation
you-know-where.

Regards,
Wojtek

Re: In-Out Parameters for functions

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: On Tue, 27 Jan 2004 02:26:17 GMT, Hyman Rosen <hyrosen@mail.com>
: wrote:
: 
:>Robert A Duff wrote:
:>> It does seem of some value to attempt to make sure "order doesn't matter".
:>
:>But since this will never be the case in Ada, the next best thing is to
:>define the order.
: 
: There could be also an opposite point of view. Fixing the evaluation
: order you strengthen the "precondition" of the code.

And how does it help, anyway? If functions have side effects,
you have to consider all values affected and affecting the function,
recursively. Is that practial (or, the next best thing)? Example:

#include <iostream>

class Weird {
  int const modulus;
public:
  Weird(int step) : modulus(step) {}
  int state() const;
};

int Weird::state() const {
  extern int global_state;
  return ++global_state % modulus;
}

int global_state = 2;

bool operator==(const Weird& a, const Weird& b) {
  return a.state() == b.state();
}

int main(void)
{
  Weird x(3), y(4);

  const Weird& w1 = x, w2 = y;

  while (w1 == w2) {
    std::cout << "we have reached the predecessors of " << w1.state()
	      << " and " << w2.state() << std::endl;
  }
  return 0;
}

Re: In-Out Parameters for functions

[Robert A Duff]

Peter Amey <peter.amey@praxis-cs.co.uk> writes:

>... SPARK functions never have side effects, ...

SPARK is consistent.  No side effects involving globals, no side effects
involving parameters.  No side effects.  Simple.

Ada is inconsistent -- as Robert Dewar says, side effects are allowed,
so long as you don't document them on the function spec.

- Bob

Re: In-Out Parameters for functions

[Hyman Rosen]

Stephen Leake wrote:
> Hmm. It's very unlikely that Ada will change to define the order of
> execution in expressions. There are good reasons to leave it undefined
> (different optimizations for different targets or speed/space goals,
> for example), and changing it would be work for existing compilers.

Those are not good reasons, those are "We've Always Done It This Way"
reasons. It would be some work for compiler vendors, but it would be
only a benefit for Ada programmers. For the typical case where order
doesn't matter, adopting the new rule doesn't hurt optimization since
the compiler is always free to use its as-if license to do things in
any order it wants to. And Ada compilers already know how to do things
in defined order since they must compile 'and-then' and 'or-else'.

You are arguing that for the convenience of compiler vendors, programmers
should be subjected to a gratuitous source of non-portability, which they
must avoid by being careful when they code, rather than having the language
protect them. Oddly enough, this is the attitude that Ada proponents are
always denigrating about C++.

Re: In-Out Parameters for functions

[David Starner]

On Tue, 27 Jan 2004 12:37:21 -0500, Hyman Rosen wrote:
> For the typical case where order
> doesn't matter, adopting the new rule doesn't hurt optimization since
> the compiler is always free to use its as-if license to do things in any
> order it wants to.

It would quite a bit of work to prove that two functions don't have side
effects, especially in the face of exceptions. It could easily call for
intra-unit optimizations, and many cases just won't be possible.

> You are arguing that for the convenience of compiler vendors,
> programmers should be subjected to a gratuitous source of
> non-portability, which they must avoid by being careful when they code,
> rather than having the language protect them. Oddly enough, this is the
> attitude that Ada proponents are always denigrating about C++.

Ada usually protects programmers by making things illegal, in the sake of
clarity, rather then adding rigid rules. In a practical sense, the only
times when the order of execution of f(x) + g(x) matters is when there's
tight hidden coupling. Ada usually discourages tight hidden coupling; why
make a rule whose only goal is to make it easier to do? (Yes, I know about
the random case, but by definition, programmers can't depend on the
results of a random function, and I think that includes the same program
compiled with different optimization settings.)

Re: In-Out Parameters for functions

[Hyman Rosen]

David Starner wrote:
> It would quite a bit of work to prove that two functions don't have side
> effects, especially in the face of exceptions. It could easily call for
> intra-unit optimizations, and many cases just won't be possible.

That's fine. In those cases the compiler is obviously not going to
choose evaluation order based on efficiency, so specifying the order
will not pessimize the code.

> Ada usually discourages tight hidden coupling

How does it do that, aside from forbidding functions to have
*out parameters?

Re: In-Out Parameters for functions

[Robert A Duff]

Hyman Rosen <hyrosen@mail.com> writes:

> Stephen Leake wrote:
> > Hmm. It's very unlikely that Ada will change to define the order of
> > execution in expressions. There are good reasons to leave it undefined
> > (different optimizations for different targets or speed/space goals,
> > for example), and changing it would be work for existing compilers.
> 
> Those are not good reasons, those are "We've Always Done It This Way"
> reasons. It would be some work for compiler vendors, but it would be
> only a benefit for Ada programmers.

Probably true.

>...For the typical case where order
> doesn't matter, adopting the new rule doesn't hurt optimization since
> the compiler is always free to use its as-if license to do things in
> any order it wants to.

No, that is not correct.  Compilers cannot tell, at compile time,
whether the order matters (in many cases).  Therefore, they cannot
optimize many of the cases where order does not matter, if the rule were
changed to "left-to-right".

On the other hand, I suspect that order-changing optimizations are not
really all that important for speed.

>... And Ada compilers already know how to do things
> in defined order since they must compile 'and-then' and 'or-else'.

Yes, and they also know that statements in a sequence must be executed
in order.  But that certainly does *not* mean that it would be easy to
change existing compilers to obey left-to-right order for subprogram
parameters.

There is *no way* that Ada will change to require left-to-right.  It's
simply too hard for existing compilers, even if you can convince us
compiler writers that the potential optimizations don't matter much.
And there is *no way* the rules will change to require side effects to
be evident to the compiler (and user!) at the call site.  Too much
incompatibility.  So we're stuck, like C and C++, with an order that's
up to the whim of the compiler writer.

> You are arguing that for the convenience of compiler vendors, programmers
> should be subjected to a gratuitous source of non-portability, which they
> must avoid by being careful when they code, rather than having the language
> protect them. Oddly enough, this is the attitude that Ada proponents are
> always denigrating about C++.

Right.

- Bob

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Stephen Leake wrote:

> > Look at this formulae:
> > 
> >   F(A) + G(A);
> > 
> > If F is permitted to change value of A then the result of the formulae may
> > depend on order of computation. And this is obviously dangerous, because the
> > formulae looks as typical mathematical expression, where this effect usually
> > is not anticipated. 
>
> Hmm. Let F be Sqrt (Ada.Numerics.Float_Random.Random), and G be
> Ada.Numerics.Float_Random.Random. Then we see that Ada _requires_ the
> behavior you are describing. So it's clearly a Good Thing :).

"Random" is very special case, in which an intention is quite opposite to what
is common in normal "regular" circumstances. In "regular" circumstances we want
the same result for the same input data and we are in trouble when this does
not happen for any reason (for example, after moving to another compiler). But
when we use Random we want and expect some diversity of the results (perhaps
intermediate results), and the changes produced by the effect mentioned above
not necessary will defeat our purpose. Anyway, if you use Random for some stable
results you should always be very careful with all computations as well as with
mathematical background for them; so in such a case this effect is just a minor
(and easy) detail among various issues.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Hyman Rosen]

Alexandre E. Kopilovitch wrote:
> "Random" is very special case

So is any function which reads data from an external source,
so it's not quite as special as you would have us believe.

It would be nice to be able to say (in my pidgin Ada)
	Point p := (x => get(), y => get(), z => get());
and know that the members would be read in the order given,
not in some arbitray order.

Re: In-Out Parameters for functions

[Stephen Leake]

"Alexandre E. Kopilovitch" <aek@VB1162.spb.edu> writes:

> Stephen Leake wrote:
> 
> > > Look at this formulae:
> > > 
> > >   F(A) + G(A);
> > > 
> > > If F is permitted to change value of A then the result of the
> > > formulae may depend on order of computation. And this is
> > > obviously dangerous, because the formulae looks as typical
> > > mathematical expression, where this effect usually is not
> > > anticipated.
> >
> > Hmm. Let F be Sqrt (Ada.Numerics.Float_Random.Random), and G be
> > Ada.Numerics.Float_Random.Random. Then we see that Ada _requires_ the
> > behavior you are describing. So it's clearly a Good Thing :).
> 
> "Random" is very special case, in which an intention is quite
> opposite to what is common in normal "regular" circumstances. 

Ok, fine. What is wrong with using mode "in out" for functions in
special cases?

-- 
-- Stephe

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Stephen Leake wrote:

> What is wrong with using mode "in out" for functions in special cases?

Nothing wrong, I think (especially if mutable parameters are marked as such
at the call site). But this thread was about the difference between IN OUT
and change of a global variable, and I just tried to show that this difference
really exists. It does not mean that I'm against IN OUT mode parameters for
functions. On the contrary, I think that it should be permitted (with suitable
restrictions and rules). But at the same time I think that arguments against
that must be stated explicitly.





Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Hyman Rosen wrote:

> > "Random" is very special case
>
> So is any function which reads data from an external source,
> so it's not quite as special as you would have us believe.
No, I was answering for the case where Ada's standard function assumes (or
requires) that behaviour. But Ada's standard Get (in Ada.Text_IO) is not
a function, it is a procedure.

> It would be nice to be able to say (in my pidgin Ada)
>	Point p := (x => get(), y => get(), z => get());
> and know that the members would be read in the order given,
> not in some arbitray order.
If you want really nice programming environment of this kind, you probably
should try APL.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Hyman Rosen]

Alexandre E. Kopilovitch wrote:
> If you want really nice programming environment of this kind, you probably
> should try APL.

Huh? I'm pretty sure I got the syntax wrong, but I was just using
an aggregate. I don't need APL just to use aggregates!

Re: In-Out Parameters for functions

[Stephen Leake]

"Alexandre E. Kopilovitch" <aek@VB1162.spb.edu> writes:

> Stephen Leake wrote:
> 
> > What is wrong with using mode "in out" for functions in special cases?
> 
> Nothing wrong, I think (especially if mutable parameters are marked
> as such at the call site). But this thread was about the difference
> between IN OUT and change of a global variable, 

Hmm. Please see the "subject" line up above. If you beleive the
subject has changed, please post with a different subject.

> and I just tried to show that this difference really exists. 

Hmm. I guess there might be some subtle differences, but I don't see
them as important.

> It does not mean that I'm against IN OUT mode parameters for
> functions. On the contrary, I think that it should be permitted
> (with suitable restrictions and rules). But at the same time I think
> that arguments against that must be stated explicitly.

Ok, sounds like we are in agreement. Except I don't see any need for
any restrictions; that's what style guides and code reviews are for.

-- 
-- Stephe

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On 27 Jan 2004 15:06:57 -0500, Robert A Duff
<bobduff@shell01.TheWorld.com> wrote:

>On the other hand, I suspect that order-changing optimizations are not
>really all that important for speed.

For example:

for I in A'Range loop
   Sum := Sum + A (I) + B (I - A'First + B'First);
end loop;

without order changing one cannot factor out the loop constant
(B'First - A'First). Should the programmer take care of that?

As a programmer I like to hand that stuff over to you, a compiler
designer. In case, I will always have an abilitity to blame that
"stupid compiler"! (:-))

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On Tue, 27 Jan 2004 23:48:58 +0300 (MSK), "Alexandre E. Kopilovitch"
<aek@VB1162.spb.edu> wrote:

>Stephen Leake wrote:
>
>> > Look at this formulae:
>> > 
>> >   F(A) + G(A);
>> > 
>> > If F is permitted to change value of A then the result of the formulae may
>> > depend on order of computation. And this is obviously dangerous, because the
>> > formulae looks as typical mathematical expression, where this effect usually
>> > is not anticipated. 
>>
>> Hmm. Let F be Sqrt (Ada.Numerics.Float_Random.Random), and G be
>> Ada.Numerics.Float_Random.Random. Then we see that Ada _requires_ the
>> behavior you are describing. So it's clearly a Good Thing :).
>
>"Random" is very special case, in which an intention is quite opposite to what
>is common in normal "regular" circumstances. In "regular" circumstances we want
>the same result

And we have the *same* result, a realization of a *random* number. It
indeed does not depend on the input parameters (ideally). A program
using random numbers in turn becomes random in the sense that its code
and results are random. So we could treat Random as a constant, in a
random program. Of course Random is pseudo random, so it needs a
parameter, which is an implementation detail.

BTW, amusing A.5.2:

   procedure Reset (Gen : in Generator);  -- Reset an *IN* parameter!

but consistent with the design choice. Interestingly, that a true
Random, taking numbers from a hardware, should indeed have "in
Generator", provided, that it does not destroy the hardware just by
reading the values. (:-))

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: In-Out Parameters for functions

[Wojtek Narczynski]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccfze1z4mm.fsf@shell01.TheWorld.com>...
> Peter Amey <peter.amey@praxis-cs.co.uk> writes:
> 
> >... SPARK functions never have side effects, ...
> 
> SPARK is consistent.  No side effects involving globals, no side effects
> involving parameters.  No side effects.  Simple.

But would you embark on writing, for example, a high performance email
server in SPARK?

> Ada is inconsistent -- as Robert Dewar says, side effects are allowed,
> so long as you don't document them on the function spec.

Looks to me like the ARG is far from agreement on this subject :-)

Regards,
Wojtek

Re: In-Out Parameters for functions

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> for I in A'Range loop
>    Sum := Sum + A (I) + B (I - A'First + B'First);
> end loop;

For code like this, I would expect the compiler to be
generating all sorts of induction variables. There's
never going to be a loop constant to hoist. The
generated code should look something like this (in C):

n = A_Last - A_First + 1;
if (B_Last - B_First + 1 < n) raise Program_Error;
pa = &A[A_First];
pb = &B[B_First];
while (n-- > 0) sum += *pa++ + *pb++;

In any case, the compiler would be free to rearrange its
calculations any way it likes as long as the results are
the same as doing them in the proper order. If the compiler
cannot determine that this is the case, then the code is
probably tricky enough such that doing it in the defined
order is helpful.

Re: In-Out Parameters for functions

[Robert A Duff]

wojtek@power.com.pl (Wojtek Narczynski) writes:

> > Ada is inconsistent -- as Robert Dewar says, side effects are allowed,
> > so long as you don't document them on the function spec.
> 
> Looks to me like the ARG is far from agreement on this subject :-)

That's true.  Tucker and I, for example, have had this argument several
times.  I'm in favor of allowing 'in out' parameters on functions in Ada
(but not SPARK!), and Tucker is against.

- Bob

Re: In-Out Parameters for functions

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccptd3olj2.fsf@shell01.TheWorld.com...
> wojtek@power.com.pl (Wojtek Narczynski) writes:
>
> > > Ada is inconsistent -- as Robert Dewar says, side effects are allowed,
> > > so long as you don't document them on the function spec.
> >
> > Looks to me like the ARG is far from agreement on this subject :-)
>
> That's true.  Tucker and I, for example, have had this argument several
> times.  I'm in favor of allowing 'in out' parameters on functions in Ada
> (but not SPARK!), and Tucker is against.

Which goes to show that even bright people can be wrong from time-to-time.
:-)

This topic is almost a religious war. I'm one of the few who's changed sides
(even though allowing 'in out' on functions would be such a disruptive
change to Janus/Ada that it probably would lead to the abandonment of the
technology), because it is impossible to do good (pointer-less) O-O
programming without it.

                           Randy.

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On Wed, 28 Jan 2004 10:20:37 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> for I in A'Range loop
>>    Sum := Sum + A (I) + B (I - A'First + B'First);
>> end loop;
>
>For code like this, I would expect the compiler to be
>generating all sorts of induction variables. There's
>never going to be a loop constant to hoist. The
>generated code should look something like this (in C):
>
>n = A_Last - A_First + 1;
>if (B_Last - B_First + 1 < n) raise Program_Error;
>pa = &A[A_First];
>pb = &B[B_First];
>while (n-- > 0) sum += *pa++ + *pb++;

This violates the evaluation order. It should be:

sum += *pa++;
sum += *pb++;

risking to overflow (*) and less stable numerically.

>In any case, the compiler would be free to rearrange its
>calculations any way it likes as long as the results are
>the same as doing them in the proper order.

You managed to factor (I - A'First) out, this can be done without
changing the evaluation order, fine. But what will you do for:

for I in A'Range loop
   Sum := Sum + A (I) + B (I + B'First - A'First);
end loop;

>If the compiler
>cannot determine that this is the case, then the code is
>probably tricky enough such that doing it in the defined
>order is helpful.

My point is, I would leave that stuff to the compiler developers. I
trust them more than me and my programmers! (:-))

----
* and reviving the discussion about introducing ":+="

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On Wed, 28 Jan 2004 17:13:10 -0600, "Randy Brukardt"
<randy@rrsoftware.com> wrote:

>"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
>news:wccptd3olj2.fsf@shell01.TheWorld.com...
>> wojtek@power.com.pl (Wojtek Narczynski) writes:
>>
>> > > Ada is inconsistent -- as Robert Dewar says, side effects are allowed,
>> > > so long as you don't document them on the function spec.
>> >
>> > Looks to me like the ARG is far from agreement on this subject :-)
>>
>> That's true.  Tucker and I, for example, have had this argument several
>> times.  I'm in favor of allowing 'in out' parameters on functions in Ada
>> (but not SPARK!), and Tucker is against.
>
>Which goes to show that even bright people can be wrong from time-to-time.
>:-)
>
>This topic is almost a religious war. I'm one of the few who's changed sides
>(even though allowing 'in out' on functions would be such a disruptive
>change to Janus/Ada that it probably would lead to the abandonment of the
>technology), because it is impossible to do good (pointer-less) O-O
>programming without it.

Would not procedures with return be a minor, non-obtrusive change?

I am afraid that allowing IN OUT parameters would be inconsistent with
the functions of the protected objects. Provided that the prefix
notation creeps Ada, it will be difficult to explain when X.Foo may
change X and when not.

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: In-Out Parameters for functions

[Peter Amey]

Wojtek Narczynski wrote:
> Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccfze1z4mm.fsf@shell01.TheWorld.com>...
> 
>>Peter Amey <peter.amey@praxis-cs.co.uk> writes:
>>
>>
>>>... SPARK functions never have side effects, ...
>>
>>SPARK is consistent.  No side effects involving globals, no side effects
>>involving parameters.  No side effects.  Simple.
> 
> 
> But would you embark on writing, for example, a high performance email
> server in SPARK?
> 

Possibly (or possibly not); however, the absence of function side 
effects would not be a factor in that decision.  Probably the biggest 
obstacle might be the desire to use dynamic data structures constructed 
with access types (which SPARK does not support).

Peter

Re: In-Out Parameters for functions

[Wojtek Narczynski]

Hello,

> Which goes to show that even bright people can be wrong from time-to-time.
> :-)

It is not a problem, as long as they are able to admit it.

> This topic is almost a religious war.

Too bad...

> I'm one of the few who's changed sides (even though allowing 'in out' on
> functions would be such a disruptive change to Janus/Ada that it probably
> would lead to the abandonment of the technology), (...)

Sounds hard to believe, but as I look at your email, I believe you.
How about you add 'return' and 'access' to procedures instead?
(Probably a silly question)

Regards,
Wojtek

Re: In-Out Parameters for functions

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> My point is, I would leave that stuff to the compiler developers. I
> trust them more than me and my programmers! (:-))

It's precisely because people make mistakes that you want a
line of code to always mean the same thing. Otherwise, you
can wind up with something that has unspecified behavior but
happens to do what you want on a given platform, and then it
is liable to break with changes in compiler, or system, or
level of optimization, or being looked at funny.

Re: In-Out Parameters for functions

[David Starner]

On Thu, 29 Jan 2004 10:37:27 -0500, Hyman Rosen wrote:
> It's precisely because people make mistakes that you want a
> line of code to always mean the same thing. Otherwise, you
> can wind up with something that has unspecified behavior but
> happens to do what you want on a given platform, and then it
> is liable to break with changes in compiler, or system, or
> level of optimization, or being looked at funny.

Why should buggy code work? If I wanted buggy code to work, I could use a
programming language that has silent overflow and no array bounds
checking. You can actually get away with that often. But Ada is there to
help me produce correct, maintainable code. Mandating the order of
evaluation doesn't make the code more maintainable, or most likely more
correct. If a programmer realizes what they're doing, at the very least
they can put f(x) and g(x) on separate lines to show that the order
dependency. If they don't realize what they're doing, half the time 
g(x) + f(x) would have been the right code to use.

Re: In-Out Parameters for functions

[Hyman Rosen]

David Starner wrote:
> Why should buggy code work?

I don't think you understand. As Ada stands now, it is perfectly
legal to write code which has unspecified results due to order of
execution. In general, the compiler cannot know whether particular
code has such order dependencies or not, and so cannot reliably
warn of such uses. Therefore, it's possible for such code to slip
undetected into production, and to survive testing because the
order chosen by the compiler is the "correct" one. Then some change
occurs in the environment, such as changing optimization level,
or changing platform, and now the compiler makes a different choice
and the code stops working.

You cannot make the argument that raesonable care would prevent this.
That is the same argument that C programmers make for the compiler not
checking array bounds or pointer access, and Ada proponents roundly
reject such arguments.

Therefore, the best thing to do is to eliminate the lack of specificity,
so that a line of code will be executed in the same order always. Once
this is in place, then depending on the order of evaluation within an
expression will be no more problematic than depending on the order of
execution of a pair of statements, and will not be "buggy". As for its
utility, I submit that code like this:
     Point p := (x => ReadCoord, y => ReadCoord, z => ReadCoord);
is perfectly sensible once you forget that order of evaluation was ever
an issue and accept left-to-right as the natural way of things. Why is
this statement any worse than
     cx, cy, cz : Coord := ReadCoord;
     Point p := (x => cx, y => cy, z=> cz);

Re: In-Out Parameters for functions

[Georg Bauhaus]

Hyman Rosen <hyrosen@mail.com> wrote:
: In general, the compiler cannot know whether particular
: code has such order dependencies or not, and so cannot reliably
: warn of such uses.

True, however in general, i.e. in the presence of global state,
a _programmer_ cannot know what the results of evaluating
expressions in order will be. A reason is complexity of the
required reasoning, in particular in the presense of tasking.


-- Georg

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Wojtek Narczynski wrote:

>How about you add 'return' and 'access' to procedures instead?
At this point I can't resist the temptation to quote my own posting to
Ada-Comment (November 2002) along with the brief discussion, which followed
(I removed the poster's name from all replies). Here it is:

=============================================================================
I'm not going to restate the arguments, but just want to know what is bad or
wrong in the following solution for a problem:

----------
Let us introduce new mode for formal parameter: RETURN mode. This RETURN mode
is the same as OUT mode except the following rules:

  in the procedure specification:

    1) only the first parameter of the procedure may be in RETURN mode;
    2) IN mode is incompatible with RETURN mode, that is, there is no IN RETURN
       mode.

  in the procedure body:

    if the formal parameter in RETURN mode is of indefinite type then the
    attributes, which depend on undefined properties (for example, 'First,
    'Length, etc.) cannot be used for that parameter.

  in a procedure call:

    1) a procedure with the first parameter in RETURN mode may be invoked as
       function (without argument for the first parameter);
    2) normal (that is, procedural) call for that procedure is also available;
       in that call RETURN mode is treated as OUT mode.

----------

--------------------------------------------------------------------------

This is a warmed over version of the DEC Valued_Procedure pragmas ...

--------------------------------------------------------------------------

>This is a warmed over version of the DEC Valued_Procedure pragmas ...

Well, of course, and GNAT implements those pragmas also. But this similarity
is a good thing, as it certifies for a proven mechamism. The difference is that
it is not an implementation-defined pragma(s), but a straight language form.

--------------------------------------------------------------------------

> Well, of course, and GNAT implements those pragmas also. But this similarity
> is a good thing, as it certifies for a proven mechamism. The difference is that
> it is not an implementation-defined pragma(s), but a straight language form.


Well I regard both the pragmas and the AK proposed substitute as too junky
to consider. If you want IN OUT parameters for functions, just allow them.
The DEC pragmas are merely a kludgy device to get around the absence of
a needed feature. I don't see the AK proposal here as any improvement over
the pragmas.

--------------------------------------------------------------------------

> Let us introduce new mode for formal parameter: RETURN mode.
> This RETURN mode is the same as OUT mode except the following rules:
>...

This basic idea might serve as a solution to the "constructor function"
problem that Bob Duff is working in AI-318. The problem with the existing
proposals for that were that the methods of getting a name for the return
result were just plain weird - objects with boatloads of restrictions. It
may be easier to define the needed restrictions in terms of a parameter
mode.

...
--------------------------------------------------------------------------
=============================================================================

Hope this helps -;) .



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Hyman Rosen]

Georg Bauhaus wrote:
> True, however in general, i.e. in the presence of global state,
> a _programmer_ cannot know what the results of evaluating
> expressions in order will be. A reason is complexity of the
> required reasoning, in particular in the presense of tasking.

What a puzzling statement! If a programmer cannt reason about
     c := f1 + f2;
even knowing that f1 and f2 will be called left-to-right, how
can he reason about
     a := f1;
     b := f2;
     c := a + b;

Re: In-Out Parameters for functions

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:6fjh109qllmjek7ud2me7k1t40so3ervmk@4ax.com...
> On Wed, 28 Jan 2004 17:13:10 -0600, "Randy Brukardt"
> <randy@rrsoftware.com> wrote:
>
...
> >This topic is almost a religious war. I'm one of the few who's changed
sides
> >(even though allowing 'in out' on functions would be such a disruptive
> >change to Janus/Ada that it probably would lead to the abandonment of the
> >technology), because it is impossible to do good (pointer-less) O-O
> >programming without it.
>
> Would not procedures with return be a minor, non-obtrusive change?

No. The problem with Janus/Ada's intermediate code is that it assumes that
all calls that return results (and thus can occur in expressions) do not
require parameter checking after the call, and thus does not allow access to
those parameters. In particular, there is nowhere to hang those checks
(called "moss" in the terminology Dan Stock invented to explain our
optimizer; "moss" because it hangs on a tree but isn't part of it.) In
addition, it doesn't allow parameters to be left on the stack after a
value-returning call (which also causes trouble with C varargs functions,
but that is a very limited and very rare problem). We could get around some
of the problems by using a different calling convention for function calls
(passing all in-outs by reference, for instance, making a local copy at the
call site), but that would complicate all kinds of code -- currently,
parameter passing doesn't depend on the entity to which it is passed.

There would be no difference between a procedure returning a value and a
function returning a value to the intermediate (and eventually machine)
code. As such, I don't see much value in that.

                      Randy.

Re: In-Out Parameters for functions

[David Starner]

On Thu, 29 Jan 2004 14:46:22 -0500, Hyman Rosen wrote:

> I don't think you understand. As Ada stands now, it is perfectly
> legal to write code which has unspecified results due to order of
> execution. 

Actually, I do understand that.

> Then some change
> occurs in the environment, such as changing optimization level,
> or changing platform, and now the compiler makes a different choice
> and the code stops working.

That's true, and not unique to this case. Not taking care of the size of
Integer or integers can cause the same problem. So can threading code. 

> You cannot make the argument that raesonable care would prevent this.
> That is the same argument that C programmers make for the compiler not
> checking array bounds or pointer access, and Ada proponents roundly
> reject such arguments.

The difference is that with array bounds or pointer access, the compiler
stops and says you're doing something wrong. This is more analogues to
making array accesses silently wrap to prevent out of bound access; it may
be what the programmer wanted, but a lot of times it won't be, and it will
confuse maintainers who come afterwards.

> Once
> this is in place, then depending on the order of evaluation within an
> expression will be no more problematic than depending on the order of
> execution of a pair of statements, and will not be "buggy". 

I don't think 

a := f(x);
b := g(x);
c := a + b;

is much better than

c := f(x) + g(x);

if f(x) and g(x) make silent changes to significant global state. But
the first at least makes some indication that the order of operations is
important. This is not proper coupling; I hardly see why Ada should go out
of its way to support bad, unmaintainable code.

>As for its
> utility, I submit that code like this:
>      Point p := (x => ReadCoord, y => ReadCoord, z => ReadCoord);
> is perfectly sensible once you forget that order of evaluation was ever
> an issue and accept left-to-right as the natural way of things. Why is
> this statement any worse than
>      cx, cy, cz : Coord := ReadCoord;
>      Point p := (x => cx, y => cy, z=> cz);

I don't think it is. I don't really approve of the second statement,
either. In any case,
  for I := 0.0 .. 2.0 step 0.25 loop
could also be considered perfectly sensible, but most of the statements
that extension would let in wouldn't be considered sensible.

Re: In-Out Parameters for functions + object notation

[Alexandre E. Kopilovitch]

Dmitry A. Kazakov wrote:

> I am afraid that allowing IN OUT parameters would be inconsistent with
> the functions of the protected objects. Provided that the prefix
> notation creeps Ada, it will be difficult to explain when X.Foo may
> change X and when not.

I think that with the following alternative proposal for prefix notation
(which I have sent to Ada-Comment in June 2003) all that would be clearer:

-------------------------------------------------------------------------

!summary

An alternative syntax is proposed here for AI-252. This alternative uses
new attribute instead of extension for meaning of dot-qualification, which is 
currently proposed in AI-252. This text assumes the context of current AI-252.

!proposal

Let us introduce new attribute Method, which always must be followed by dot
and operation, i.e.

  Object'Method.Operation

for example:

  type T is ... ;
  function F(A1 : T; A2 : Integer) return Integer;
  procedure P(A1: T);
  ...

  X : T;
  Actual_A2 : Integer;
  F_Result : Integer;
  ...

  F_Result := X'Method.F(Actual_A2);
  ...
  X'Method.P;

Conceptually, the attribute Method returns a record -- the table of all
relevant methods; some analogy with C++ code is present here, although the
major difference is obvious: contents of this table depends not only on the
object's type, but on surround and visibility rules also.

Basic visibility rules for Operation may stay as they are stated currently
in AI-252, but with additional option: a programmer can explicitly list all
visible packages for a particular subtype using appropriate "for...use"
statement:

  for Subtype'Method use Package1 [, Package2, ..., PackageN];

Such explicit statement overrides basic visibility rules for all
Object'Method.Operation expressions where Object belongs to Subtype.

Further, with this approach we may easily provide a denotation for the
component-on-demand abstraction, that is, unified notation for an externally
immutable view of a data component and a function; all we need for this is
another attribute Property, which should be used the same way:

  Object'Property.Function_Or_DataField

for example, for both

  type T is ... ;
  function F(P : T) return Integer;

and

  type T is record
     F : Integer;
     ...
  end record;

we can write:

  X : T;
  R : Integer;
  ...

  R := X'Property.F;

Arguments for a function prefixed by the Property attribute naturally
correspond indices for array data component.

Further, arrays (that are indexed by controlling object type) likewise may be
used in conjunction with the Property attribute  (in accordance with analogy
between arrays and functions, supported in Ada). For example:

  type String_Index is new Integer;
  S : String(1..10);
  I : String_Index;
  ...
  ... I'Property.S ...

Even multi-dimensional arrays are permitted here. For example:

  type Cities is (Edinburgh, Glasgow, London, Paris, New_York);
  type Distances is array (Cities, Cities) of Float;
  Km_To : Distances := ...;
  ...
  ... Edinburgh'Property.Km_To(Paris) ...

As for arrays of arrays, only outer array may be used, that is, the subscripts
for inner arrays cannot appear. For example:

  type Table_Index is new Integer;
  type Table_Line is String(1..50);  
  Table : array (Table_Index range 1..10) of Table_Line;
  I : Table_Index;
  ...
  ... I'Property.Table ...     -- legal
  ...
  ... I'Property.Table(1) ...  -- illegal


!discussion

Object.Operation syntax seems as acceptable compromise in a case when
there is a controlling object. Although even then the Operation does not
belong to the Object (as it belongs to a package), it is reasonable to claim
that conceptually, the status of being controlling temporary gives the Object
some additional rights over all its operations, and in particular, extends
visibility rules for the Object.

But in many cases there are no controlling objects, and in those cases this
Object.Operation syntax will act against proper expression and understanding
of program design and logic. Moverover, as this Object.Operation style
potentially conflicts with package-orientation, which is fundamental feature
of Ada 95, and as this Object.Operation notation is compulsory in most of
today's mainstream languages, there is real possibility of massive and
disordered mixture of those design styles if this Object.Operation notation
appear in Ada.

There is also anxiety about possible confusion with component notation.
As Robert I. Eachus recently wrote in comp.lang.ada newsgroup
(message-id <3ED056CB.8000200@attbi.com> ):
"I really don't like the idea of allowing the Object.Operation format to 
Ada.  Yeah, the compilers can usually figure it out understand it. But 
the potential confusion with component notation is going to confuse 
experienced Ada users.  (And eventually other O-O language users when 
the actually run into component references."

An alternative proposed here attains main purpose of AI-252, and it does not
contest AI's propositions concerning all things except Object.Operation
syntax. At the same time it establishes a deterrent for unjustified use of
the feature (by extra wording), makes the expression of programmer's intent
more explicit, and additionally, provides finer control over visibility and
over interchangeability between operation and data field.

The level of uniformity achieved with the notation proposed here is even
higher than with dot-notation proposed in current AI-252 (because the arrays
are included) without sacrificing traditional features and natural ways for
expressing specific intentions.

________________________________________________________



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> David Starner wrote:
> 
>> Why should buggy code work? 
> 
> I don't think you understand. As Ada stands now, it is perfectly
> legal to write code which has unspecified results due to order of
> execution. In general, the compiler cannot know whether particular
> code has such order dependencies or not, and so cannot reliably
> warn of such uses. Therefore, it's possible for such code to slip
> undetected into production, and to survive testing because the
> order chosen by the compiler is the "correct" one. Then some change
> occurs in the environment, such as changing optimization level,
> or changing platform, and now the compiler makes a different choice
> and the code stops working.
> 
> You cannot make the argument that raesonable care would prevent this.
> That is the same argument that C programmers make for the compiler not
> checking array bounds or pointer access, and Ada proponents roundly
> reject such arguments.
> 
> Therefore, the best thing to do is to eliminate the lack of specificity,
> so that a line of code will be executed in the same order always. Once
> this is in place, then depending on the order of evaluation within an
> expression will be no more problematic than depending on the order of
> execution of a pair of statements, and will not be "buggy". As for its
> utility, I submit that code like this:
>     Point p := (x => ReadCoord, y => ReadCoord, z => ReadCoord);
> is perfectly sensible once you forget that order of evaluation was ever
> an issue and accept left-to-right as the natural way of things. Why is
> this statement any worse than
>     cx, cy, cz : Coord := ReadCoord;
>     Point p := (x => cx, y => cy, z=> cz);

What determines whether something is a bug?  On many projects it is in 
the mind of the programmer, and nowhere else.  I prefer to work on 
projects with defined and written testable requirements, and to allow 
these to define what is a bug.  If the SDP says to use SPARK, then any 
dependence on evaluation order is a bug, and it will be caught by the 
SPARK toolset.  If the SDP says something else, that will either 
establish guidelines that define functions with side-effects to be bugs, 
or which make calling two functions with mutual side-effects a bug.

Any of the the later approaches are fine with me, and are consistent 
with programming in Ada.  But you have to expect that I will regard any 
language revisions which attempt to change those bug definitions as a 
non-starter.  Notice that you are welcome to use SPARK if you want, and 
in fact I have worked with it on occasion.  But on other projects I have 
worked on, other definitions of bugs have been used.  To change the 
rules now would make lots of code obsolete.

Going through and reevaluating the programs according to the new rules 
is possible.  But without an automated toolset it is very expensive.  If 
there are significant upward incompatibilities in Ada 0Y, expect most 
compiler vendors to plan to provide such migration tools.  Now think 
about the effort required to develop the tools for your proposed change, 
and go away.  Note that SPARK is a subset of Ada, and such a toolset 
does exist for SPARK, so I am not saying it is impossible.  Just that 
you are in effect defining a new language, and the market for that 
language is currently served by SPARK and the SPARK toolset.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On Thu, 29 Jan 2004 14:46:22 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>David Starner wrote:
>> Why should buggy code work?
>
>I don't think you understand. As Ada stands now, it is perfectly
>legal to write code which has unspecified results due to order of
>execution.

Wrong. Here is ARM 4.5:

"...For a sequence of predefined operators of the same precedence
level (and in the absence of parentheses imposing a specific
association), an implementation may impose any association of the
operators with operands so long as the result produced is an allowed
result for the left-to-right association, but ignoring the potential
for failure of language-defined checks in either the left-to-right or
chosen order of association."

allowed result /= unspecified result

The results are specified, they are all possibile ones produced by all
possible combinations exectution sequences. There is nothing wrong
with that, after all some people are still writing multitasking
programs...

>In general, the compiler cannot know whether particular
>code has such order dependencies or not, and so cannot reliably
>warn of such uses. Therefore, it's possible for such code to slip
>undetected into production, and to survive testing because the
>order chosen by the compiler is the "correct" one. Then some change
>occurs in the environment, such as changing optimization level,
>or changing platform, and now the compiler makes a different choice
>and the code stops working.

Writting programs depending on evaluation order in a way that the
"correct" order is not specified, that is not a language problem.
Programmers should know what they are doing. Do you really believe
that tests will detect an "incorrect" order when specified by RM more
probably than when selected by the compiler? In my experience errors
like this are extremely difficult to detect, no matter whether an
order is specified by RM or not. This is why, [and for numerous other
reasons] I would like to see pure functions in Ada + procedures with
return giving all sorts of warnings when order is not *explicitly*
specified.

>You cannot make the argument that raesonable care would prevent this.
>That is the same argument that C programmers make for the compiler not
>checking array bounds or pointer access, and Ada proponents roundly
>reject such arguments.

True, this argument would be invalid. But the argument, derived from
Gries position, is that the order shall be specified explicitly if
relevant to the program semantics. In all cases where the program
semantics does not depend on the order, it shall never be specified.
Both under- and overspecification are wrong.

>Therefore, the best thing to do is to eliminate the lack of specificity,
>so that a line of code will be executed in the same order always. Once
>this is in place, then depending on the order of evaluation within an
>expression will be no more problematic than depending on the order of
>execution of a pair of statements, and will not be "buggy". As for its
>utility, I submit that code like this:
>     Point p := (x => ReadCoord, y => ReadCoord, z => ReadCoord);
>is perfectly sensible once you forget that order of evaluation was ever
>an issue and accept left-to-right as the natural way of things. Why is
>this statement any worse than
>     cx, cy, cz : Coord := ReadCoord;

I presume here the order is also arbitrary.

>     Point p := (x => cx, y => cy, z=> cz);

Anyway there are many orders contradicting each other:

type Point is record
   Z : Coordinate;
   Y : Coordinate;
   X : Coordinate;
end record;
[ + optionally, a nasty represenation clause stating some other, third
order ]

Is this order[s] irrelevant? Provided that programs are written by
idiots, I assure you that 50% of them would believe that keyed
associations will not override the native order of record fields. Or
do you think that the guessing the results of:

   Point P1 := (X => ReadCoord, Y => ReadCoord, Z => ReadCoord);
   Point P1 := (ReadCoord, ReadCoord, ReadCoord);
   Point P1 := (Y => ReadCoord, others => ReadCoord);

should be blessed as a symphony of safety and maintainability?

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: In-Out Parameters for functions + object notation

[Dmitry A. Kazakov]

On Fri, 30 Jan 2004 03:23:28 +0300 (MSK), "Alexandre E. Kopilovitch"
<aek@VB1162.spb.edu> wrote:

>Dmitry A. Kazakov wrote:
>
>> I am afraid that allowing IN OUT parameters would be inconsistent with
>> the functions of the protected objects. Provided that the prefix
>> notation creeps Ada, it will be difficult to explain when X.Foo may
>> change X and when not.
>
>I think that with the following alternative proposal for prefix notation
>(which I have sent to Ada-Comment in June 2003) all that would be clearer:
>
>-------------------------------------------------------------------------
>
>!summary
>
>An alternative syntax is proposed here for AI-252. This alternative uses
>new attribute instead of extension for meaning of dot-qualification, which is 
>currently proposed in AI-252. This text assumes the context of current AI-252.
>
>!proposal
>
>Let us introduce new attribute Method, which always must be followed by dot
>and operation, i.e.
>
>  Object'Method.Operation
[...]

People want Object.Operation, this is the only reason why one should
have it.

IMO any proposal for prefix notation should mend the disorder, caused
by tasks and protected object using the prefix notation, while all
other calls have the functional one. It is desirable to have an
ability to choose a notation for all sorts of things having
parameters.

IMO the simplest way is to have an ability to declare subroutines,
entry points, protected subroutines in any desired notation, plus to
provide a renaming clause to introduce alternative notation[s].

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: In-Out Parameters for functions

[Hyman Rosen]

Robert I. Eachus wrote:
> will be caught by the SPARK toolset...
 > establish guidelines...

To be caught by a toolset requires whole-program analysis.
At the very least, this dooms people who are writing libraries
or generics. Establishing guidelines is no substitute for having
the language avoid problems. C has a guideline that you should
not index beyond the end of an array.

> To change the rules now would make lots of code obsolete.

How can defining something which was previously unspecified
make code obsolete? I'm not saying that Ada should change
any specified behavior it currently has, I'm just saying
that currently unspecified behavior should become specified.

> Now think about the effort required to develop the tools
 > for your proposed change, and go away.

There's certainly work involved in the compiler to make it
evaluate things in a specific order. I personally would not
classify it at the "go away" level. I know that GCC includes
a Java compiler, so it at least has infrastructure for doing
this at some level.

Re: In-Out Parameters for functions

[Peter Amey]

Hyman Rosen wrote:
> Robert I. Eachus wrote:
> 
>> will be caught by the SPARK toolset...
> 
>  > establish guidelines...
> 
> To be caught by a toolset requires whole-program analysis.
> [snip]

Not so in the case of SPARK.  The language design and the use of 
annotations means we can find things like function side effects and 
aliasing at the program unit level using computationally efficient 
techniques.  We can frequently find errors in programs that are not yet 
complete enough to compile.  That is why SPARK users typically run the 
Examiner about 10 times as often as they run the compiler (and about a 
million times as often as they run the debugger!).

See http://www.sparkada.com/downloads/sigada2001.pdf for an overview of 
how this all works.

Peter

Re: In-Out Parameters for functions

[Hyman Rosen]

Dmitry A. Kazakov wrote:
 >>it is perfectly legal to write code which has unspecified results
 >>due to order of execution.
> 
> Wrong. Here is ARM 4.5: 
> allowed result /= unspecified result

That very same section says that
     The two operands of an expression of the form X op Y,
     where op is a binary operator, are evaluated in an
     arbitrary order, as for any function_call

arbitrary order = unspecified result

If I have (pidgin Ada again!)
     x : 0..1 := 0;
     function f : integer is begin x := 1 - x; return x; end f;
     r : integer := f - f;
Then Ada legally permits r to be 1 or -1. That's what I call
unspecified, i.e., no single result is required. In a particular
fixed environment, it is likely that the above code will always
return the same value. If this is done in production code rather
than in a contrived example, and the order dependency isn't so
apparent, it will seem that everything is fine. Then a change in
environment can make the opposite result appear, and things may
be broken.

Everyone here is saying "so don't do that", which is what we
C/C++ programmers always say, and which you Ada guys sneer at.

> Do you really believe that tests will detect an "incorrect" order
 > when specified by RM more probably than when selected by the compiler?

I believe that once code is written, tested, and found to work, then
having the evaluation order chosen by the language means that it will
continue to work even when the environment changes. If the order is
selected by the compiler, then you have no such assurance. Surely
this is obvious?

> In my experience errors like this are extremely difficult to detect

With a defined rather than arbitrary order, this might no longer be
an error. Removing sources of uncertainty in the language is good.

> Both under- and overspecification are wrong.

Nevertheless, in conventional programming languages overspecification
is the rule, and it is what programmers are used to. It is left to the
compiler to rearrange things if it can prove that the result remains
correct by the rules of the language, just as in the section you quoted.

>>    cx, cy, cz : Coord := ReadCoord;
> I presume here the order is also arbitrary.

No, it is not. See 3.3.1/7. The order is strictly left-to-right.

> 50% of them would believe that keyed associations will not override the
 > native order of record fields.

I don't believe that for a second. Making up dumb statistics in order
to bolster an untenable position is silly.

> Or do you think that the guessing the results of:
>    Point P1 := (X => ReadCoord, Y => ReadCoord, Z => ReadCoord);
>    Point P1 := (ReadCoord, ReadCoord, ReadCoord);
>    Point P1 := (Y => ReadCoord, others => ReadCoord);
> should be blessed as a symphony of safety and maintainability?

Yes, actually I very much think so, and there should be no guessing involved.

Re: In-Out Parameters for functions

[Georg Bauhaus]

Hyman Rosen <hyrosen@mail.com> wrote:
: Georg Bauhaus wrote:
:> True, however in general, i.e. in the presence of global state,
:> a _programmer_ cannot know what the results of evaluating
:> expressions in order will be. A reason is complexity of the
:> required reasoning, in particular in the presense of tasking.
: 
: What a puzzling statement! If a programmer cannt reason about
:     c := f1 + f2;
: even knowing that f1 and f2 will be called left-to-right, how
: can he reason about
:     a := f1;
:     b := f2;
:     c := a + b;

He can't. Order won't help unless you assume that order
eases predicting the current global state and how it interacts
with f1 and f2 (or f2 and f1).

Thus order might help in some circumstances, however I don't see
the really big help it offers.

Re: In-Out Parameters for functions

[David Starner]

On Fri, 30 Jan 2004 12:06:26 -0500, Hyman Rosen wrote:
> If I have (pidgin Ada again!)
>      x : 0..1 := 0;
>      function f : integer is begin x := 1 - x; return x; end f;
>      r : integer := f - f;
> Then Ada legally permits r to be 1 or -1. That's what I call
> unspecified, i.e., no single result is required. In a particular
> fixed environment, it is likely that the above code will always
> return the same value. If this is done in production code rather
> than in a contrived example, and the order dependency isn't so
> apparent, it will seem that everything is fine. Then a change in
> environment can make the opposite result appear, and things may
> be broken.
> 
> Everyone here is saying "so don't do that", which is what we
> C/C++ programmers always say, and which you Ada guys sneer at.

Everyone uses arrays and pointers. They are a part of good code. So
Ada people sneer about people who ignore problems even good
programmers have. They don't sneer about unmaintainable code (because "the
order dependency isn't [...] apparent") that they could make deterministic
at the cost of good code. What happens when someone uses f-f later
assuming it will be 1? Or if someone changes the code not to call f-f and
fails to make the side effects that something else is depending on? This
is bad code, and needs to be fixed at the program level, not the language
level.

Re: In-Out Parameters for functions

[Hyman Rosen]

Georg Bauhaus wrote:
> Thus order might help in some circumstances, however I don't see
> the really big help it offers.

As I have said, it makes some "obvious" uses work unsurprisingly, eg.,
     Point p := (x => ReadCoord, y=> ReadCoord, z => ReadCoord);
just as
     cx, cy, cz : Coord := ReadCoord;
works. But the really big help is that the meaning of such code won't
silently change when changing some aspect of the environment. Of what
benefit is it to the programmer when the ARM allows things to happen
in arbitrary order?

Re: In-Out Parameters for functions

[Hyman Rosen]

Peter Amey wrote:
>> To be caught by a toolset requires whole-program analysis.
> 
> Not so in the case of SPARK.

As far as I know, SPARK has no way of calling procedures
except by explicitly mentioning their names. That is, there
are no procedure access variables, no generics, and no
dispatching. So it's no surprise that when you annotate a
declaration in enough detail to tell you what the body will
be doing, you can perform the analysis without seeing the
body. That's close to whole-program analysis in my book.

Also, SPARK doesn't allow side-effects in functions, so this
discussion is pretty moot from SPARK's point of view.

But Ada is not SPARK. Ada does have procedure access variables,
generics, dispatching, and side-effects, and the issues of
evaluation order are germane.

By the way, I read the paper to which you referred. What happens
in SPARK if I have
     package Sensor
     --# own in State;
     is
         function Value return Integer;
         --# global State;
     end Sensor;
and I try to write
     delta : Integer := Sensor.Value - Sensor.Value;

Can I write a function, not a procedure, which will return
different sensor values each time? Can I use them multiple
times in an expression?

Re: In-Out Parameters for functions

[Georg Bauhaus]

Hyman Rosen <hyrosen@mail.com> wrote:
: Georg Bauhaus wrote:
:> Thus order might help in some circumstances, however I don't see
:> the really big help it offers.
: 
: As I have said, it makes some "obvious" uses work unsurprisingly, eg.,
:     Point p := (x => ReadCoord, y=> ReadCoord, z => ReadCoord);
: just as
:     cx, cy, cz : Coord := ReadCoord;
: works. But the really big help is that the meaning of such code won't
: silently change when changing some aspect of the environment. Of what
: benefit is it to the programmer when the ARM allows things to happen
: in arbitrary order?

(add  p: Point := (x | y | z => ReadCoord); to the list of surprises.)

People coming from the substitution model of programming might
"feel like they know what's going on" (L. Wall, perlmod),
however this might be the opposite of helpful in writing
programs that use assignment not substitution, or that use "world",
with or without order.

It matches the tasking dizziness well.

But I won't insist, I'm only trying to see how this could make sense.

Re: In-Out Parameters for functions

[Hyman Rosen]

David Starner wrote:
 > They don't sneer about unmaintainable code that they
 > could make deterministic at the cost of good code.

The example I have previously posted,
     p : Point := (x => ReadCoord, y => ReadCoord, z => ReadCoord);
is not "unmaintainable", except that it is non-deterministic in
current Ada. On the other hand, the following code
     cx, cy, cz : Coord := ReadCoord;
     p : Point := (x => cx, y => cy, z => cz);
is perfectly deterministic. Is it unmaintainable? Perhaps. But the
point is that someone might innocently code the first case, most
likely in a less obvious way, and it might survive all checking
and testing, because such things do, just like buffer overflows
stay in C/C++ code. The "cost" to good code is a phantom, trotted
out as an excuse for maintaining the status quo.


> What happens when someone uses f-f later assuming it will be 1?

With a defined order of execution, if it wasn't 1 before it wouldn't
be 1 now, and the tests would fail, demonstrating the error to the
programmer. With an arbitrary order of execution, it will turn out
to be 1 in the debug build and -1 in the production build, returning
the wrong answer at the worst possible time.

> Or if someone changes the code not to call f-f and fails to make
 > the side effects that something else is depending on?

Then the code will fail, and testing will show that it has failed.

> This is bad  code, and needs to be fixed at the program level,
 > not the language level.

Whether or not the code is bad, I believe that it can readily slip
through checks into production because it works by coincidence. It
cannot be fixed at the program level any more than array overflows
can be fixed at the program level.

Re: In-Out Parameters for functions

[Hyman Rosen]

Georg Bauhaus wrote:
> People coming from the substitution model of programming...
> I'm only trying to see how this could make sense.

I'm trying to see how someone could believe that fixing an order of
evaluation doesn't make sense. Of what use is arbitrariness to the
semantics of the language?

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Hyman Rosen wrote:

> I believe that once code is written, tested, and found to work, then
> having the evaluation order chosen by the language means that it will
> continue to work even when the environment changes. If the order is
> selected by the compiler, then you have no such assurance. Surely
> this is obvious?

You must be surprised, but the right answer is "generally, NO". The situation
depends on kind of applications for which the language is aimed.

When you rely upon fixed (in the language) evaluation order you are risking
to make things non-commutative. And if those things are commutative in the
underlying theory then you are subjected to unexpected failure when some part
of your "environment" changes. And if evaluation order is fixed in the
language then you lose an opportunity to caught that potentially dangerous
non-commutativity by testing with various compilers and various optimization
levels. Moreover, those failures that happen because of this difference -
between a theory, which is based on commutativity, and a non-commutative
implementation, may be extremely hard to investigate, just because the reason
is located neither in theory nor in software implemention, but somehow between
them. So, by fixing order of evaluation you enhance the overall situation
for theoretically trivial applications, but worsen it for applications that
are substantially based on non-trivial mathethical/physical theories.

So, both decisions - to fix evaluation order in Java and not to do that in Ada
- are right, these languageas are extreme cases: Java is used primarily for
theoreticaly trivial applications, while Ada is often used for applications,
based on mathematically non-trivial theories.

> Nevertheless, in conventional programming languages overspecification
> is the rule, and it is what programmers are used to.

That's true about commodity, but Ada language too often is used for programming
things that aren't commodities in any reasonable sense, and this is Ada's
native land. Ada isn't a popular language, can't be, and don't strive to be
too popular; what is desired is to get as much as possible of proper audience,
but not much more.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Georg Bauhaus]

Hyman Rosen <hyrosen@mail.com> wrote:
: Georg Bauhaus wrote:
:> People coming from the substitution model of programming...
:> I'm only trying to see how this could make sense.
: 
: I'm trying to see how someone could believe that fixing an order of
: evaluation doesn't make sense. Of what use is arbitrariness to the
: semantics of the language?

I had people in mind, not just programming languages.
You might say it makes sense to adapt one's reasoning to the
requirements of a programmaing language/style etc.
For predicting properties of object code this might be necessary
in addition to checking. However, do you define or design high
level languages to just produce object code in a systematic
manner or is there more to it? Like expressiveness, dealing well
with what people (not: Scheme fans, Ada fans, APL fans)
usually do when writing programs? Languages that suggest
ways of commanding a computer to "execute an idea"?

In the substitution model you don't have to worry about
the order of evaluation, that is, you reduce complexity.
However, the world has state, and no rollback, so the 
substitution model may not work.

Consequence: In the presence of time dependence, learn to
"think from left to right" in addition to down the sequence
of instructions.
Alternative consequence: In the presence of time dependence, if you
want a specific order of elaboration, say so in the direction
of declarations and statements, but not when it comes to
"inputs" to "value creating items". (I admit that this is somewhat
artificial.)

If you say that the idea of substitution should not be a guideline
when variables can have changing values, you might want order of
evaluation to imply consistency with western wrinting direction in all
respects. I.e. I am weighting other aspects of source code constructs
less, like "a collection of inputs to a function where each
input is named" --conceptually the order of association is an addon
necessitated by that nasty time dependent statefulness of the world
in case there are globals or inputs or side effects.

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Dmitry A. Kazakov wrote:

> I am afraid that allowing IN OUT parameters would be inconsistent with
> the functions of the protected objects. Provided that the prefix
> notation creeps Ada, it will be difficult to explain when X.Foo may
> change X and when not.

If we require a mark for IN OUT parameter at call cite, that is,

  F(keyword X)

then X.F will be illegal (given that

   keyword F.X

is illegal).




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> I'm trying to see how someone could believe that fixing an order of
> evaluation doesn't make sense. Of what use is arbitrariness to the
> semantics of the language?

This has been explained once in this thread, but here goes again.  The 
order of evaluation that Ada allows to be arbitrary is so that some 
'common' optimizations such as common subexpression elimination and code 
hoisting can be done.  This trade-off was explicitly accepted because 
without it, much of the constraint checking that Ada requires would be 
too expensive, and everyone would turn it off.  (In fact, in the 
embedded world we often had to convince project management not to 
mandate turning constraint checking off.  It does no good for the 
programmers to know that Ada constraint checking is essentially cost 
free if you don't explain that to management as well.)

Let me give a simple example to explain this:

for I in A'Range loop
   A(I) := B(I);
end loop;

Now 'obviously' you don't have to do the range check on A every time 
through the loop, but what about B?  You can check that the lower bound 
is okay once, but it seems that you have to check against the upper 
limit each time.  Actually in Ada 95, you don't.  I won't go into the 
ramifications needed to explain this hear, because the real explanation 
is that the programmer didn't ask for it, and we don't want to prevent 
the compiler from handling this move the same way as:

  A := B(A'First..A'Last);

If you really NEED the check to be repeated, write:

for I in A'Range loop
   begin
     A(I) := B(I);
   exception
     when Constraint_Error => Do_Something(I);
   end;
end loop;

If A and B are Strings, you should now get a byte copy and the value of 
I in the exception handler will reflect the first subscript to fail the 
check.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

(Others have done a good job of answering most of Hyman's points, but...)

>> To change the rules now would make lots of code obsolete.

> How can defining something which was previously unspecified
> make code obsolete? I'm not saying that Ada should change
> any specified behavior it currently has, I'm just saying
> that currently unspecified behavior should become specified.

Your assumption is that you could create a new rule which makes the new 
language a subset of the old one.  In one sense, that is easy.  Keep all 
the old legality rules and just add new ones.  Some existing programs 
will no longer compile, but if they do compile, they will have the same 
semantics as before.  I don't think you can come up with a set of rules 
like that without a lot of effort, but you are welcome to try.  The 
SPARK people certainly took that path and did it successfully.

But what if you keep the legality rules the same, and "just" change the 
semantics?  Then the problem is proving that existing code will have the 
same semantics under the new rules as under the old ones.

The current situation is that order of evaluation in Ada is partially 
specified.  I know of lots of code which was validated in part "by hand" 
and in part by tools which recognize the current Ada rules.  If the 
semantics change, recompiling this code makes all that analysis junk. 
(For example, red/black analysis in crypto code.)

If you want to reuse the existing code with new code, it is impractical 
to redo that analysis. (The code is often written so as to make the 
analysis easier.  But it won't necessarily be that easy for the new 
semantics.) So you either use a "project validated" compiler, or throw 
the code away.

I know what I would do, and changes in Ada that would make using "new" 
Ada compilers an issue are just what I said, a non-starter.

Notice that I and many other programmers know the existing Ada rules 
very well, and so does the SPARK Examiner.  That is one measure of how 
much would be thrown away by a major change to 11.6.

Incidently Ada 95 did change 11.6.  But it is worth noting that the 
changes were to resolve AI-315--remember that is an Ada 83 AI 
number--which we never found a fix for that wouldn't do too much damage 
to the language and to compilers.  Since Ada 95 was a much bigger change 
than Ada 0Y will be, we accepted that change then.  But not without a 
lot of soul searching.  It may have been that more soul-searching would 
have been worthwhile.  (The change is to define canonical semantics in 
terms of external effects.)  See 11.6(3) and 1.1.3(8-15).  In fact, I 
think that one change did more to slow the adoption of Ada 95 than any 
other change from Ada 83.

> There's certainly work involved in the compiler to make it
> evaluate things in a specific order. I personally would not
> classify it at the "go away" level. I know that GCC includes
> a Java compiler, so it at least has infrastructure for doing
> this at some level.

Once again, the problem is not with the compiler.  The whole idea of the 
entire HOLWG effort, even before GREEN became Ada, was to reduce the 
number of programming languages and compilers used by the DoD so that an 
infrastructure of support tools could be built around one or more core 
languages.  The HOLWG then decided that no existing language was 
sufficient as a base language for embedded system programming and tools. 
  That started a process that ended up creating Ada.

SPARK is one of the few non-compiler Ada tools that has reached the 
necessary critical mass to be able to say that it won't go away.  Other 
tools are part of the support infrastructure for each compiler, and 
should last at least as long as the compiler does.  An example in this 
category is gnatchop.  There are lots of other tools, such as GtkAda 
that have not reached the plateau, but if Ada usage keeps growing they 
will get there.  Or you can consider Rational's tools.  Rational made a 
business decision to develop those tools for several languages, 
primarily C++ and Ada. It might be interesting to find out what the 
relative sizes of the Ada and C++ markets are for Rational's tools, but 
from the original HOLWG viewpoint, it is irrelevant.  The tools are 
commercial, and the tools are available.  Anything else is gravy.


So in my opinion, any change to Ada which had the effect of invalidating 
  existing toolsets is a non-starter--and a bad idea.

Incidently there is nothing preventing anyone reading this from getting 
the GNAT compiler source and modifying it to support, say, in out 
parameters for functions.  But if you want to try a major change like 
the one Hyman is suggesting, I know I wouldn't have the energy or 
patience to try it.  A change like in out parameters for functions is 
localized, and even thought the localization may only be to a dozen 
places in the code, it shouldn't require modifying more than 5 KSLOC. 
Changing the order of evaluation rules would affect a substantial 
fraction of the entire compiler.  Call it reviewing 500 KSLOC and 
modifying 100 KSLOC.  Put out an RFP and I'll "No bid."  ACT might 
respond. ;-)


-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: In-Out Parameters for functions

[Randy Brukardt]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1075482385.142744@master.nyc.kbcfp.com...
...
> That very same section says that
>      The two operands of an expression of the form X op Y,
>      where op is a binary operator, are evaluated in an
>      arbitrary order, as for any function_call
>
> arbitrary order = unspecified result

Sorry, Hyman, but Ada has a very specific meaning for "unspecified result",
and that's what people here (usually) mean. "Unspecified" means not only is
*any* result allowed, but also that the implementer doesn't even need to
tell you what the result will be. "Implementation-Defined" is that any
result is allowed, but the implementer has to tell you which it is.

This case is "only" about a (usually small, often a singleton) set of
allowed results. In your example, returning "-2" isn't allowed (obviously).

I realize you are using the term informally, but I think you're confusing a
lot of people by using it.

                  Randy.

Re: In-Out Parameters for functions

[cl1motorsports]

i just started on this message, and i don't know ada very well, BUT
wouldn't the best solution be to have the compiler throw an error if a
parameterless function that returns a different value is used as a
parameter to a procedure or function call? It is
bad form to write code like that in the first place.

Re: In-Out Parameters for functions

[Hyman Rosen]

Randy Brukardt wrote:
> Sorry, Hyman, but Ada has a very specific meaning for "unspecified result",
> and that's what people here (usually) mean. "Unspecified" means not only is
> *any* result allowed, but also that the implementer doesn't even need to
> tell you what the result will be.

That doesn't seem to be correct. Here's a quote from 1.1.3 of the ARM:
     Certain aspects of the semantics are defined to be either
     implementation defined or unspecified. In such cases, the
     set of possible effects is specified, and the implementation
     may choose any effect in the set. Implementations shall document
     their behavior in implementation-defined situations, but
     documentation is not required for unspecified situations.

So I would have to say you're wrong. Unspecifed behavior allows the
implementation to choose from a limited set of possible effects, not
from an unlimited one, and the implementation doesn't have to tell
you what it chooses.

 > I realize you are using the term informally, but I think you're confusing a
 > lot of people by using it.

Apparently, I was using it formally, and the confused people are confused :-)

Re: In-Out Parameters for functions

[Hyman Rosen]

Alexandre E. Kopilovitch wrote:
 > And if evaluation order is fixed in the language then you lose an opportunity
 > to caught that potentially dangerous non-commutativity by testing with various
 > compilers and various optimization levels.

I'm sorry, but this is abject nonsense. When you use a language that does not
specify evaluation order and does not require the implementation to document
evaluation order, you will gain absolutely zero knowledge about "dangerous
non-commutativity" whatever the heck that might even mean, no matter how much
testing you do on how many systems, becaus eyou have no way of knowing if any
of those systems did their evaluations in an order different from another.

> So, both decisions - to fix evaluation order in Java and not to do that in Ada
> - are right, these languageas are extreme cases: Java is used primarily for
> theoreticaly trivial applications, while Ada is often used for applications,
> based on mathematically non-trivial theories.

This is so nonsensical, it approaches the level of the Chewbacca defense.
You may choose to believe this if you like, and I won't even attempt to
argue with this line of reasoning. It would be like debating the mad.

Re: In-Out Parameters for functions

[David Starner]

On Sun, 01 Feb 2004 04:10:37 +0000, Hyman Rosen wrote:

> When you use a language that does not
> specify evaluation order and does not require the implementation to document
> evaluation order, you will gain absolutely zero knowledge about "dangerous
> non-commutativity" whatever the heck that might even mean

You won't gain knowledge by brute force, but it does permit certain
reasoning, formal and informal, about code that you can't do if the
language forces evaluation order.

Re: In-Out Parameters for functions

[Hyman Rosen]

David Starner wrote:
> You won't gain knowledge by brute force, but it does permit certain
> reasoning, formal and informal, about code that you can't do if the
> language forces evaluation order.

Sure. The compiler can say "I can pick an arbitrary order, so obviously
the programmer doesn't care what the order is." It's just like in C++,
where the compiler says, "He's using this as the index, so he must know
wht he's doing." If the programmer did thsi by intention, then an
opportunity for optimization is exposed. If the programmer is in error,
then an opportunity for a bug is exposed. The question is whether the
potential gain in optimization outweighs the potential for error. I don't
believe the potential for optimization afforded by leaving order of
execution unspecified is significant at all.

Re: In-Out Parameters for functions

[David Starner]

On Sun, 01 Feb 2004 21:55:54 +0000, Hyman Rosen wrote:

> David Starner wrote:
>> You won't gain knowledge by brute force, but it does permit certain
>> reasoning, formal and informal, about code that you can't do if the
>> language forces evaluation order.
> 
> Sure. The compiler can say "I can pick an arbitrary order, so obviously
> the programmer doesn't care what the order is." 

But the human can also say that. He doesn't have to worry that the
programmer before him, knowing the evaluation rules, make a+b /= b+a.

> It's just like in C++,
> where the compiler says, "He's using this as the index, so he must know
> wht he's doing." 

But Ada can do something about that. For this to be equivalent, you'd have
to be asking for Ada to always return 0 or A(A'First) if you used an index
out of range. 

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On Fri, 30 Jan 2004 12:06:26 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
> >>it is perfectly legal to write code which has unspecified results
> >>due to order of execution.
>> 
>> Wrong. Here is ARM 4.5: 
>> allowed result /= unspecified result
>
>That very same section says that
>     The two operands of an expression of the form X op Y,
>     where op is a binary operator, are evaluated in an
>     arbitrary order, as for any function_call
>
>arbitrary order = unspecified result
>
>If I have (pidgin Ada again!)
>     x : 0..1 := 0;
>     function f : integer is begin x := 1 - x; return x; end f;
>     r : integer := f - f;
>Then Ada legally permits r to be 1 or -1. That's what I call
>unspecified, i.e., no single result is required.

Does the specification of f require single result? It does not,
because f could as well call to Random or ask operator for a value.
Moreover, there could be a concurrent task modifying x! So it is not
Ada, but you who didn't specify it. Should you have written down the
full contract of f, a user of f would know whether it is legal to use
f as above, or concurrently from different tasks etc. The real [Ada]
problem is not order, but that a malignantly impure f can be used as
if it were pure.

>In a particular
>fixed environment, it is likely that the above code will always
>return the same value. If this is done in production code rather
>than in a contrived example, and the order dependency isn't so
>apparent, it will seem that everything is fine. Then a change in
>environment can make the opposite result appear, and things may
>be broken.

Which means that the code is wrong.

>Everyone here is saying "so don't do that", which is what we
>C/C++ programmers always say, and which you Ada guys sneer at.

OK, according to your theory C++ is right requiring to specify
parameter passing mode: by-copy vs. by-reference. But it is just one
of many evil features of C++! Once per month reviewing code I detect
programmers passing constant containers by copy! They do it over and
over again. Imagine a test which would catch that? With some
exemptions Ada leaves that to the compiler. And yes, it is well
possible to write a program which will work if the compiler chooses
one mode and crash otherwise.

>> Do you really believe that tests will detect an "incorrect" order
> > when specified by RM more probably than when selected by the compiler?
>
>I believe that once code is written, tested, and found to work, then
>having the evaluation order chosen by the language means that it will
>continue to work even when the environment changes. If the order is
>selected by the compiler, then you have no such assurance. Surely
>this is obvious?

It is not. Because "found to work" /= "found correct". There is a hope
that a code dependent on execution order will continue to work so far
the order is not changed. But isn't it better to know that the code
remains valid for any order?

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On Sat, 31 Jan 2004 02:39:43 +0300 (MSK), "Alexandre E. Kopilovitch"
<aek@VB1162.spb.edu> wrote:

>Dmitry A. Kazakov wrote:
>
>> I am afraid that allowing IN OUT parameters would be inconsistent with
>> the functions of the protected objects. Provided that the prefix
>> notation creeps Ada, it will be difficult to explain when X.Foo may
>> change X and when not.
>
>If we require a mark for IN OUT parameter at call cite, that is,
>
>  F(keyword X)
>
>then X.F will be illegal (given that
>
>   keyword F.X
>
>is illegal).

Why should we do it at call site?

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: In-Out Parameters for functions

[Peter Amey]

[snip]
> 
> By the way, I read the paper to which you referred. What happens
> in SPARK if I have
>     package Sensor
>     --# own in State;
>     is
>         function Value return Integer;
>         --# global State;
>     end Sensor;
> and I try to write
>     delta : Integer := Sensor.Value - Sensor.Value;

You get a static semantic error: SPARK only allows variables and 
constants to be initialized by constant (i.e. fixed at compile time) 
expressions.  Functions cannot be used.  (There are other reasosn for 
this as well including avoidance of elaboration order dependencies).

> 
> Can I write a function, not a procedure, which will return
> different sensor values each time? Can I use them multiple
> times in an expression?
> 

No.  There are special rules for volatile functions.  They can only be 
used directly in simple assignment or return statements, not in general 
expressions.

Peter

Re: In-Out Parameters for functions

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Which means that the code is wrong.
 > ...
 > Because "found to work" /= "found correct".
 > ...
> But isn't it better to know that the code remains valid for any order?

There's no question that the code is wrong. There's no question that
as the language stands, it would be better to know that it is valid
for any order. The problem is that wrong code which has been found
to work can slip out into production. We know this is the case in C
for array bounds and pointer access, exacerbated by the compiler not
checking for these kinds of errors, and I don't see why it should not
be the case for Ada errors not detected by the compiler.

Once this code has slipped out into production, what gain is there by
having it potentially break by a change in environment?

Re: In-Out Parameters for functions

[Hyman Rosen]

David Starner wrote:
> But Ada can do something about that. For this to be equivalent, you'd have
> to be asking for Ada to always return 0 or A(A'First) if you used an index
> out of range. 

No, because in this case there is always a valid result to return,
since the results are merely unspecified (i.e., chosen from a legal
set of possible outcomes). Why do we want the compiler to pick an
arbitrary value instead of specifying which one it picks?

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On Mon, 02 Feb 2004 09:33:21 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> Which means that the code is wrong.
> > ...
> > Because "found to work" /= "found correct".
> > ...
>> But isn't it better to know that the code remains valid for any order?
>
>There's no question that the code is wrong. There's no question that
>as the language stands, it would be better to know that it is valid
>for any order. The problem is that wrong code which has been found
>to work can slip out into production. We know this is the case in C
>for array bounds and pointer access, exacerbated by the compiler not
>checking for these kinds of errors, and I don't see why it should not
>be the case for Ada errors not detected by the compiler.

It should be the case, but it does not imply fixing the order.
Semantically wrong code cannot be made correct by doing that. To
continue your analogy with bounds checks, it is like to allow wrong
array index, but to define the result of A [-99999999999] as 0. It is
not much better. Better is to check, which means checking for
order-dependent side effects.

Fixing and specifying does not solve the problem of knowing what and
how things are fixed. In C++ A & B | C is legal and specified, but I
do appreciate Ada for making A and B or C illegal.

>Once this code has slipped out into production, what gain is there by
>having it potentially break by a change in environment?

Wrong code should not go so far.

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: In-Out Parameters for functions

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Semantically wrong code cannot be made correct by doing that.

That's not true. If it happens that a defined evaluation order
would do what the programmer wanted, then the code would indeed
become correct.

> it is like to define the result of A [-99999999999] as 0

No, it's not nearly as bad, because in the case of evaluation order,
we are specifying one of a set of legal results, whereas for indexing
there is no legal result.

> Wrong code should not go so far.

But there is (nearly) nothing to be gained by forcing the code to be
considered wrong.

Re: In-Out Parameters for functions

[Randy Brukardt]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:pT_Sb.6670$bn1.3505@nwrdny02.gnilink.net...
> Randy Brukardt wrote:
> > Sorry, Hyman, but Ada has a very specific meaning for "unspecified
result",
> > and that's what people here (usually) mean. "Unspecified" means not only
is
> > *any* result allowed, but also that the implementer doesn't even need to
> > tell you what the result will be.
>
> That doesn't seem to be correct. Here's a quote from 1.1.3 of the ARM:
>      Certain aspects of the semantics are defined to be either
>      implementation defined or unspecified. In such cases, the
>      set of possible effects is specified, and the implementation
>      may choose any effect in the set. Implementations shall document
>      their behavior in implementation-defined situations, but
>      documentation is not required for unspecified situations.
>
> So I would have to say you're wrong. Unspecifed behavior allows the
> implementation to choose from a limited set of possible effects, not
> from an unlimited one, and the implementation doesn't have to tell
> you what it chooses.

I think you're misinterpreting the meaning of this paragraph. Only bounded
errors always give a set of possible results. There is an implied
requirement for sensible choices, but certainly the RM rarely if ever gives
a set of results for either I-D or unspecifed.

Try 13.9(11), for instance (Unchecked_Conversion). It says that the result
is I-D, but never says anything about the possible results (other than that
it may be abnormal!). I know of compilers that reject such conversions;
others do various masking operations; and still others raise exceptions.
That's pretty close to the entire set of possible results!

I note that the AARM notes say "Note that the ``set of possible effects''
can be ``all imaginable effects''; which seems to be the default case. So I
think that the only purpose of that phrase is to allow the RM to give a set
of possible results -- something it rarely if ever does.

                   Randy.

Re: In-Out Parameters for functions

[Hyman Rosen]

Randy Brukardt wrote:
> So I think that the only purpose of that phrase is to allow the RM to give a set
> of possible results -- something it rarely if ever does.

When it speaks about order of evaluation, it says that the operands are
evaluated in "arbitrary order". That clearly results in a limited set of
possible results.

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On Mon, 02 Feb 2004 12:01:19 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> Semantically wrong code cannot be made correct by doing that.
>
>That's not true. If it happens that a defined evaluation order
>would do what the programmer wanted, then the code would indeed
>become correct.

I do not think so. + is commutative, if a programmer uses it so that
a+b /= b+a, he makes a semantical error. Later on, he may forget about
his mistake, a code viewer will be even not aware about it. So I treat
it as a *wrong* code. A wrong code may under some circumstances
function properly, false => true. You want to fix the circumstances, I
prefer to fix the code.

>> it is like to define the result of A [-99999999999] as 0
>
>No, it's not nearly as bad, because in the case of evaluation order,
>we are specifying one of a set of legal results, whereas for indexing
>there is no legal result.

The results are illegal, if different [*]. When a programmer writes:
x:=a+b, the postcondition of that is:

{ x=a+b & x=b+a }

so there is no legal way to make it dependent on the evaluation order.

>> Wrong code should not go so far.
>
>But there is (nearly) nothing to be gained by forcing the code to be
>considered wrong.

Yes, if that cannot be checked. As I always said, I wished to have
pure functions in Ada.

------
* Floating point numbers are intervals and equations become inclusions
and the postcondition will hold.

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: In-Out Parameters for functions

[Hyman Rosen]

Dmitry A. Kazakov wrote:
 > + is commutative

Mathematics went beyond dogmatic statements like that many years ago.
Notice you didn't say that * is commutative. Very disingenuous.

> You want to fix the circumstances, I prefer to fix the code.

Once the circumstances are fixed, the code is no more broken
than if the operands were evaluated in sequential statements.

> The results are illegal, if different [*].

Can you point to where the ARM says so? I believe you are wrong.

> When a programmer writes: x:=a+b, the postcondition of that is:
> { x=a+b & x=b+a }

If I replace + with *, you would find no one agreeing with you if the
operands were matrices, for example.

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On Tue, 03 Feb 2004 09:06:52 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
> > + is commutative
>
>Mathematics went beyond dogmatic statements like that many years ago.
>Notice you didn't say that * is commutative. Very disingenuous.

Well, on numbers with overflow + is as non-commutative as * for
matrices. Commutativity is not a property of the sign "+". And
compilers do not try to optimize user-defined types just because they
have "+" defined, I hope.

>> You want to fix the circumstances, I prefer to fix the code.
>
>Once the circumstances are fixed, the code is no more broken
>than if the operands were evaluated in sequential statements.

Nope, false => true, but this does not make false premise true.

>> The results are illegal, if different [*].
>
>Can you point to where the ARM says so? I believe you are wrong.

I didn't talk about ARM. However, it mentions mathematically correct
result. If a+b differs from b+a more than accuracy requirements allow,
it is no more mathematically correct.

>> When a programmer writes: x:=a+b, the postcondition of that is:
>> { x=a+b & x=b+a }
>
>If I replace + with *, you would find no one agreeing with you if the
>operands were matrices, for example.

For matrices * is not commutative. We are discussing commutative
operators.

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: In-Out Parameters for functions

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> For matrices * is not commutative. We are discussing commutative
> operators.

Ada allows + to be a user-written function. When this is done,
the function receives the operands in the order written in the
code. The operation is commutative only if this function wants
it to be. And "we" are not discussing commutative operators.
You are, in raising all of these crypto-mathematical objections
to fixing an order of evaluation. I have yet to find any of these
objections at all compelling - your theories seem to have nothing
to do with the actual process of writing code in Ada, either as
it now stands or as I think it should.

Re: In-Out Parameters for functions

[David Starner]

On Tue, 03 Feb 2004 11:11:23 -0500, Hyman Rosen wrote:

> I have yet to find any of these
> objections at all compelling 

The person who raised the argument and persists in arguing one side
doesn't find the counter-arguments compelling. Shocking.

> your theories seem to have nothing
> to do with the actual process of writing code in Ada, either as
> it now stands or as I think it should.

It violates the expectations of a maintaining programmer.

To run into this problem, you'd usually be writing clumsy, hard to follow
code that needs to be fixed, not patched at the language level. 

Your solution papers over the problem instead exposing it and getting it
fixed in the code, like it should be and which is done with the array and
pointer examples you keep bringing up.

You have to test the production version of your software already. You
never know what different switches will do to your code whether so
authorized by the standard or not.

All those arguments have to do with the writing of code in Ada.

Re: In-Out Parameters for functions

[Hyman Rosen]

David Starner wrote:
> The person who raised the argument and persists in arguing one side
> doesn't find the counter-arguments compelling. Shocking.

There are plenty of times where I am convinced that a position I hold
has compelling counter-arguments. This is not one of them. I have yet
to hear why a deliberate ambiguity is better than a definite order.

> It violates the expectations of a maintaining programmer.

So your point is that the language should increase the possibility of
error instead? This just makes no sense. I really get the sense that
people are clinging desperately to "we've always done it this way".

> To run into this problem, you'd usually be writing clumsy, hard to follow
> code that needs to be fixed, not patched at the language level. 

To belabor the point once more,
     p : Point := (x => ReadCoord, y => ReadCoord, z => ReadCoord);
is not clumsy or hard to follow, merely wrong in the status quo.

> Your solution papers over the problem

My solution makes it no longer be a problem.

> the array and pointer examples you keep bringing up.

I haven't brought them up in the context of Ada, only C/C++.

> You have to test the production version of your software already. You
> never know what different switches will do to your code whether so
> authorized by the standard or not.

True. But that doesn't mean that errors couldn't slip in anyway.
Errors that could be prevented at no cost to the programmer.

> All those arguments have to do with the writing of code in Ada.

I don't find that compelling :-)

Re: In-Out Parameters for functions

[David Starner]

On Tue, 03 Feb 2004 18:38:26 -0500, Hyman Rosen wrote:

> David Starner wrote:
>> The person who raised the argument and persists in arguing one side
>> doesn't find the counter-arguments compelling. Shocking.
> 
> There are plenty of times where I am convinced that a position I hold
> has compelling counter-arguments. This is not one of them. I have yet
> to hear why a deliberate ambiguity is better than a definite order.

You're still far from an impartial judge.

>> It violates the expectations of a maintaining programmer.
> 
> So your point is that the language should increase the possibility of
> error instead? This just makes no sense. 

It shouldn't make things right just because it can. It should make
things right because they are logically right.

>> To run into this problem, you'd usually be writing clumsy, hard to follow
>> code that needs to be fixed, not patched at the language level. 
> 
> To belabor the point once more,
>      p : Point := (x => ReadCoord, y => ReadCoord, z => ReadCoord);
> is not clumsy or hard to follow, merely wrong in the status quo.

I have some pieces of code in response:

for I in 0.0 .. 1.0 step 0.25
is not clumsy or hard to follow, merely wrong in the status quo. But
making it right would bring in a lot of other stuff that won't work right.

x : 0..1 := 0;
function f : integer is begin x := 1 - x; return x; end f;
r : integer := f - f;

This isn't the clearest bit of code in the first place; on first glance, I
want to say that r is 0. I have to read the implementation details of f to
figure out what's going on. If it were

x: 0..1 = 0;
function f (z : integer) : integer is begin 
	x := x - z; 
	return x - z; 
end f;

r: integer = f (x);

then we would have stepped into another of Ada's constructive ambiguities,
the fact that x may have been passed by copy or by reference. In a
real-life program, the same code that produces the first will quite
possibly run into the second problem. And if you don't, that doesn't mean
that the maintainer, who doesn't understand the program as well, won't.

>> Your solution papers over the problem
> 
> My solution makes it no longer be a problem.

In any real program, diddling with a bunch of global variables is likely
to be hard to maintain and hard to reason about. Any thing that assumes
that the interpretation order of a line is left to right is going to be
adding sequence points where most languages don't have them and most code
doesn't have them and is going to be surprising to a maintainer, and
probably missed without comments.
 
>> the array and pointer examples you keep bringing up.
> 
> I haven't brought them up in the context of Ada, only C/C++.

You've mentioned how they differ between Ada and C. But it's different to
make something an loud error and make it legal.

> True. But that doesn't mean that errors couldn't slip in anyway. Errors
> that could be prevented at no cost to the programmer.

And this could cause errors, by making things legal that are hard to
reason about and actually program with. And there's a cost to the
programmer, because it's a loss of an optimization opportunity and hence a
slower program at the end.

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Hyman Rosen wrote:

> > + is commutative
>
> Mathematics went beyond dogmatic statements like that many years ago.
Very interesting information. May I ask you for a couple of references? I mean
authoritative mathematical books where plus sign (+, without any modifications)
denotes some non-commutative operation.

And also, if the value of "pi" or "e" constant is somehow changed recently
(or if they are no longer constants) - in modern mathematics - then please
tell us that.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Ludovic Brenta]

"Alexandre E. Kopilovitch" <aek@VB1162.spb.edu> writes:

> And also, if the value of "pi" or "e" constant is somehow changed recently
> (or if they are no longer constants) - in modern mathematics - then please
> tell us that.

Don't you know? 2+2=5, but only for large values of 2.

:)

-- 
Ludovic Brenta.

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Hyman Rosen wrote:

> There are plenty of times where I am convinced that a position I hold
> has compelling counter-arguments. This is not one of them. I have yet
> to hear why a deliberate ambiguity is better than a definite order.
Ah, you just wanted a compelling argument! Sorry, I didn't get you properly
earlier - I thought that you wanted to understand. So, here is a compelling
argument: consider a deliberate ambiguity in choosing of the next leader of
a country in democratic societies, and compare it with quite definite order 
of that in absolute monarchies and totalitarian (Communists and others) regimes.
Which mode you like better?

But if you want purely scientific/technical and at the same time compelling
and condensed argument then I must disappoint you - you have very little
chance for getting it for free, simply asking for it - in this case. For free
you can get a hint only, and you already refused it. Well, you have an option: turn to 
ARA or to some Ada-related vendor and ask them whether they can and will
supply you a compelling argument on this matter for $$$. Perhaps they will agree.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

> I have yet
>to hear why a deliberate ambiguity is better than a definite order.

Because it is better to remove the ambiguity instead of making it look
like something else when in fact it isn't.


Vinzent.

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On 04 Feb 2004 04:26:34 +0100, Ludovic Brenta
<ludovic.brenta@insalien.org> wrote:

>"Alexandre E. Kopilovitch" <aek@VB1162.spb.edu> writes:
>
>> And also, if the value of "pi" or "e" constant is somehow changed recently
>> (or if they are no longer constants) - in modern mathematics - then please
>> tell us that.
>
>Don't you know? 2+2=5, but only for large values of 2.
>
>:)

if 2 + 2 = 5 then
   5 := 4;
end if;

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: In-Out Parameters for functions

[Stuart Palin]

Hyman Rosen wrote:

> There are plenty of times where I am convinced that a position I hold
> has compelling counter-arguments. This is not one of them. I have yet
> to hear why a deliberate ambiguity is better than a definite order.

I am no expert in these matters, but I thought that at some
time in the [distant] past the argument was made that the
ambiguity allows optimization: in particular optimization in
systems employing highly parallel computing architectures.

In such systems, different parts of an expression could be
'farmed out' and computed in parallel because there was no
assumption of any sequential order.

This argument should also have merit in cases where
processors have multiple execution units and support for
out-of-order execution.  Just how far must a compiler go in
preserving the sequential order written in the source code?

I would agree with you that in most run-of-the-mill software
cases the lack of definite execution order does create a
pitfall for the unwary.  But, it also creates an opportunity
for 'smart compilers' to optimize.  In the end, surely, the
language must strike a balance in judging the true intent of
an author (when they are writing vanilla programs).  Is the
serialization of an expression a specific requirement or an
unwanted by-product of the format of the source code!

On balance [however much I might find it a pain in my line
of programming], I think that the language has chosen the
most pragmatic approach.  Those of us who are really
concerned about the matter will add it to our list of
concerns [and then probably turn to SPARK to save us from
ourselves :-) ]

--
Stuart Palin

Re: In-Out Parameters for functions

[Hyman Rosen]

David Starner wrote:
>>     p : Point := (x => ReadCoord, y => ReadCoord, z => ReadCoord);
> 
> I have some pieces of code in response:
> for I in 0.0 .. 1.0 step 0.25

Is this currently legal in Ada? Remember that my example is.

> the fact that x may have been passed by copy or by reference.

OK, I accept that there are more ambiguity issues than I have
been cnsidering. I suppose you object to getting rid of those too?

> In any real program, diddling with a bunch of global variables is likely
> to be hard to maintain and hard to reason about.

But using functions that read input is not hard to reason about.
     BunchOfReadings : array(1..100) of Integer := (others => ReadSensor);
Someone might reasonably think that the above line of code should fill
the array with sensor readings in order. You can tell him that it won't
work that way, but you can hardly say that he had no right to expect that
it would.

> sequence points where most languages don't have them

Java does, and many people are now exposed to that.
The Java language refernce manual also recommends not writing code
which exploits this, though, so that's one for your side. I think
it's just atavistic dread from the reptillian hindbrain.

 > it's a loss of an optimization opportunity

But it's not, except for programs which are now exhibiting unspecified
behavior. If an expression has only one value regardless of execution
order, then the compiler will be free to evaluate it in any order.

Re: In-Out Parameters for functions

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> Because it is better to remove the ambiguity instead of making it look
> like something else when in fact it isn't.

But Ada doesn't necessarily warn you that such an ambiguity exists,
so it might wind up not getting removed.

Re: In-Out Parameters for functions

[Hyman Rosen]

Stuart Palin wrote:
 > But, it also creates an opportunity for 'smart compilers' to optimize.

Notice that if an expression has only one possible value regardless of
evaluation order then the compiler can evaluate it in any order it wants,
and with the current evaluation rules, it is unwise to write expressions
that have more than one possible value based on evaluation order. So no
correct existing programs necessarily need to be pessimized by fixing
evaluation order.

Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>Vinzent 'Gadget' Hoefler wrote:
>> Because it is better to remove the ambiguity instead of making it look
>> like something else when in fact it isn't.
>
>But Ada doesn't necessarily warn you that such an ambiguity exists,
>so it might wind up not getting removed.

Well, IMO it doesn't get removed just by fixing the evaluation order,
either. It still is wrong code and as such it is the *code* that has
to be fixed.


Vinzent.

Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>it is unwise to write expressions that have more than one possible
>value based on evaluation order.

It is not only unwise, it is plain stupid.

>So no correct existing programs necessarily need to be pessimized by
>fixing evaluation order.

Precisely. You don't need to fix the evaluation order. It wouldn't
help anyway because the code remains to be stupid.


Vinzent.

Re: In-Out Parameters for functions

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> Well, IMO it doesn't get removed just by fixing the evaluation order,
> either. It still is wrong code and as such it is the *code* that has
> to be fixed.

What is it about definite order of evaluation that you and so
many others find intrinsically evil?

Re: In-Out Parameters for functions

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> It is not only unwise, it is plain stupid.

Under current rules.

> Precisely. You don't need to fix the evaluation order. It wouldn't
> help anyway because the code remains to be stupid.

It would help by making the "stupid" code work the same way
everywhere, cutting down an opportunity for error. And then
it would lead to non-stupid uses, such as the initialization
code I've been posting.

Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>Vinzent 'Gadget' Hoefler wrote:
>> Well, IMO it doesn't get removed just by fixing the evaluation order,
>> either. It still is wrong code and as such it is the *code* that has
>> to be fixed.
>
>What is it about definite order of evaluation that you and so
>many others find intrinsically evil?

Because it forces the programmer to think about optimization instead
of thinking about readability.


Vinzent.

Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>It would help by making the "stupid" code work the same way
>everywhere, cutting down an opportunity for error. And then
>it would lead to non-stupid uses, such as the initialization
>code I've been posting.

Maybe. But it will also lead to more stupid code because we now know
about the evaluation order and thus can (or even: must) do
optimizations ourselves. That sort of optimizations that we would
normally leave to the compiler.


Vinzent.

Re: In-Out Parameters for functions

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> Because it forces the programmer to think about optimization instead
> of thinking about readability.

How does it do that? Is the programmer forced to think about optimization
instead of readability when he writes a sequence of statements?

Re: In-Out Parameters for functions

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> Maybe. But it will also lead to more stupid code because we now know
> about the evaluation order and thus can (or even: must) do
> optimizations ourselves. That sort of optimizations that we would
> normally leave to the compiler.

Do you have an example? What sort of optimization is implied by
order of evaluation that would lead a programmer to choose one
way over another?

Re: In-Out Parameters for functions

[David Starner]

On Wed, 04 Feb 2004 10:52:14 -0500, Hyman Rosen wrote:

> What is it about definite order of evaluation that you and so
> many others find intrinsically evil?

Have you ever studied functional programming? I think part of the
objection is the concept that pure functional programming is the ideal and
that we differ from that for efficiency and a closer mapping to the
hardware.

Also, half the examples have been horrible code that should never be
written. So much of the code enabled by this feature can't be fixed
to use it without a program-wide analysis of the problems, wherein it
would be just as easy to fix the code not to depend on evaluation order.

> OK, I accept that there are more ambiguity issues than I have
> been cnsidering. I suppose you object to getting rid of those too?

That would require major surgery to the language that would leave it
backwardly-incompatible or require the compiler to do stupid slow things.
If you want Java, you know where to find it.

In any case, you have a huge group of ambiguity issues around threads.
It's inherent in the system. If you're worried about your compiler
changing evaluation order at compile time, wait until your program starts
behaving erratically at run time because you made the same mistakes.

> But using functions that read input is not hard to reason about.
>      BunchOfReadings : array(1..100) of Integer := (others => ReadSensor);

Which it is easy to warn about and simple to fix.

> But it's not, except for programs which are now exhibiting unspecified
> behavior. If an expression has only one value regardless of execution
> order, then the compiler will be free to evaluate it in any order.

If the compiler can prove that, which is easier said then done. At best,
it will slow down compilers at compile-time, proving what they could
assume before, and slow down programs at run-time when they couldn't prove
it.

Re: In-Out Parameters for functions

[Stuart Palin]

Hyman Rosen wrote:
> 
> Stuart Palin wrote:
>  > But, it also creates an opportunity for 'smart compilers' to optimize.
> 
> Notice that if an expression has only one possible value regardless of
> evaluation order then the compiler can evaluate it in any order it wants,
> and with the current evaluation rules, it is unwise to write expressions
> that have more than one possible value based on evaluation order. So no
> correct existing programs necessarily need to be pessimized by fixing
> evaluation order.

But the premise in many of your other postings in this
thread seems to be concerned with resolving the case where
the expression [currently] has an 'ambiguous' value.

As has already been pointed out in this thread, an Ada
compiler can not determine - simply from its specification -
whether a function will have a side-effect or not.  (SPARK
resolves the issue by extending specifications with
annotations; but then it is striking a different balance
between  flexibility in the design and verifiability of
behaviour).

I agree with you that it is unwise to write expressions that
[unintentionally] have more than one possible value; but I
think the point I made still stands.  Ada seems to have (as
a matter of pragmatism) chosen not to prohibit certain
aspects of ambiguity because the potential benefits [in a
wide range of cases] out-weigh the pitfalls.

[Again, re-affirming my lack of expertise in these matters
of the Ada language, the 'pragmatic view' seems to be that:
a) people would mostly write functions without side-effects,
b) if they are writing functions with side-effects they
would/should be especially careful how they use them anyhow,
and c) Good performance in embedded real-time systems (on a
variety of targets) is desirable [essential if you consider
Ada to be targeted at the real-time embedded application
market]: consequently, in general the order of evaluation is
not fixed; allowing compilers to find an optimal
implementation order - including concurrent computation.

This may seem even more reasonable if one acknowledges there
are other cases where ambiguous behaviour can arise - for
instance data aliasing through parameter passing (another
thing prevented by SPARK) - so the die is cast!]

If your proposal to define the execution order were to be
adopted, how might a programmer write the Ada code to
express their intent that they don't care what order the
expression is executed in (provided it respected the
precedence rules) - they just want the most efficient
implementation?

How much do you think this [manual optimization] would add
to/detract from the clarity of the code?

How do you think someone who is writing applications for a
target that offers high levels of parallel computation would
feel about it?

--
Stuart Palin

Re: In-Out Parameters for functions

[Hyman Rosen]

Stuart Palin wrote:
> But the premise in many of your other postings in this
> thread seems to be concerned with resolving the case where
> the expression [currently] has an 'ambiguous' value.

Yes.

> As has already been pointed out in this thread, an Ada
> compiler can not determine - simply from its specification -
> whether a function will have a side-effect or not.

Yes.

> Ada seems to have (as
> a matter of pragmatism) chosen not to prohibit certain
> aspects of ambiguity because the potential benefits [in a
> wide range of cases] out-weigh the pitfalls.

Those benefits being?

> allowing compilers to find an optimal implementation order

But you are now talking about finding an optimal implementation
order for an expression involving more than one function call
where the compiler has no access to the body of the functions.
Do you really think that allowing the compiler to pick the order
of the calls will significantly affect the efficiency?

> - including concurrent computation.

I don't see how this can possibly be allowed, unless the compiler
can see the bodies to inline them. The standard allows operands
and arguments to be evaluated in arbitrary order, but concurrent
execution would completely break any functions that accessed common
data structures.

> This may seem even more reasonable if one acknowledges there
> are other cases where ambiguous behaviour can arise - for
> instance data aliasing through parameter passing

Eliminating sources of ambiguity is a good thing even if not all
of them can be removed.

> If your proposal to define the execution order were to be
> adopted, how might a programmer write the Ada code to
> express their intent that they don't care what order the
> expression is executed in

They could not, just as they cannot specify this for sequences
of statements. If you write
     x := a + b;
     y := c + d;
you may not care which statement is executed first, but you have no
way of telling this to the compiler. Either the compiler can figure
this out for itself, or it can't.

> How much do you think this [manual optimization] would add
> to/detract from the clarity of the code?

I think this is non-existent now, and will continue to be so.

> How do you think someone who is writing applications for a
> target that offers high levels of parallel computation would
> feel about it?

They would feel that order of evaluation is completely orthogonal
to their concerns.

Re: In-Out Parameters for functions

[Hyman Rosen]

Alexandre E. Kopilovitch wrote:
> Ah, you just wanted a compelling argument! Sorry, I didn't get you properly
> earlier - I thought that you wanted to understand. So, here is a compelling
> argument: consider a deliberate ambiguity in choosing of the next leader of
> a country in democratic societies, and compare it with quite definite order 
> of that in absolute monarchies and totalitarian (Communists and others) regimes.
> Which mode you like better?
> 
> But if you want purely scientific/technical and at the same time compelling
> and condensed argument then I must disappoint you - you have very little
> chance for getting it for free, simply asking for it - in this case. For free
> you can get a hint only, and you already refused it. Well, you have an option: turn to 
> ARA or to some Ada-related vendor and ask them whether they can and will
> supply you a compelling argument on this matter for $$$. Perhaps they will agree.

"Ladies and gentlemen of the supposed jury, I have one final thing I want you
to consider: this is Chewbacca. Chewbacca is a Wookiee from the planet Kashyyyk,
but Chewbacca lives on the planet Endor. Now, think about that. That does not
make sense!

"Why would a Wookiee -- an eight foot tall Wookiee -- want to live on Endor with
a bunch of two foot tall Ewoks? That does not make sense!

"But more importantly, you have to ask yourself: what does that have to do with
this case? Nothing. Ladies and gentlemen, it has nothing to do with this case!
It does not make sense!

"Look at me, I'm a lawyer defending a major record company, and I'm talkin' about
Chewbacca. Does that make sense? Ladies and gentlemen, I am not making any sense.
None of this makes sense.

"And so you have to remember, when you're in that jury room deliberating and
conjugating the Emancipation Proclamation... does it make sense? No! Ladies and
gentlemen of this supposed jury, it does not make sense.

"If Chewbacca lives on Endor, you must acquit! The defense rests."

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> But you are now talking about finding an optimal implementation
> order for an expression involving more than one function call
> where the compiler has no access to the body of the functions.
> Do you really think that allowing the compiler to pick the order
> of the calls will significantly affect the efficiency?

Of course it will.  Consider for one example a Pure subprogram, say a 
call to Sin or Log from a math package inside a loop.  The pragma Pure 
rules allow the compiler to hoist the call outside the loop, if the 
parameter(s) are unchanged in successive calls.

YOU may think that is a contrived example, but it is not.  That sort of 
thing happens all the time in embedded flight dynamics systems where a 
set of expressions is iterated a couple of times for convergence.  And 
even if the expressions are not iterated, they often include common 
subexpressions that can be pulled out of line by the compiler.  Any call 
to a Pure function can be treated as a common subexpression, even if the 
subprogram itself is not inlined.

This is one of the nice features of Ada for safety-critical systems. 
The formulas for things like flight dynamics can be almost copied 
verbatum from the specification, and the compiler (and Verifier!) can do 
the grody work of finding an efficient implementation and showing that 
it is equivalent.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: In-Out Parameters for functions

[Hyman Rosen]

Robert I. Eachus wrote:
> Hyman Rosen wrote:
>> But you are now talking about finding an optimal implementation
>> order for an expression involving more than one function call
>> where the compiler has no access to the body of the functions.
>> Do you really think that allowing the compiler to pick the order
>> of the calls will significantly affect the efficiency?
> 
> Of course it will.  Consider for one example a Pure subprogram, say a 
> call to Sin or Log from a math package inside a loop.  The pragma Pure 
> rules allow the compiler to hoist the call outside the loop, if the 
> parameter(s) are unchanged in successive calls.

Sigh. When I said "access to the body" I meant that the compiler has
no more information about what the function does than its declaration.
Obviously if a function is declared Pure then its return value is not
affected by order of execution, and the compiler can hoist away.

Think about it - if you write
     s := Sin(x) + Cos(y)
Ada requires that both arguments are evaluated, but doesn't specify the
order. Yet, with a pragma Pure in place, Ada need not evaluate the operands
each time in a loop, but can hoist the calculations out, as you say. Why
would specifying the order change this?

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> Think about it - if you write
>     s := Sin(x) + Cos(y)
> Ada requires that both arguments are evaluated, but doesn't specify the
> order. Yet, with a pragma Pure in place, Ada need not evaluate the operands
> each time in a loop, but can hoist the calculations out, as you say. Why
> would specifying the order change this?

That may be why you keep butting your head against a brick wall.  If Ada 
said that in an equation like: s := Sin(1-x) + Cos(y); that the terms 
had to be evaluated left to right, that would say you couldn't evaluate 
Cos(y) before Sin(1-x) whether or not they were declared Pure.

Ada does allow compilers to combine calls to Pure functions, and if that 
is not okay, don't declare them Pure.  But that doesn't say that Pure 
functions can't have side effects.  It just changes what a compiler is 
allowed to do with Pure functions.  In fact, right now on the ARG list 
we are discussing a fix to 10.2.1 Elaboration Control which defines 
pragma Pure and pragma Preelaborate.  There are some new features in Ada 
0Y that require some wording changes, and we want them to be as 
restrictive as necessary, but no stricter.  In that discussion we have 
discussed exactly this issue.  (A Pure subprogram call can be 
eliminated, and if the subprogam has side-effects, well the programmer 
was warned.  No different from some other effects of optimizing compilers.

But note that what users have been warned about is that marking a unit 
as Pure may allow the optimizer to eliminate some calls.  The compilers 
are not allowed to call the function somewhere that it wouldn't be 
called otherwise.  The compiler must insure that a Pure function that 
would never be called in the canonical order is never called in the 
order the compiler selects.  And if two Pure functions have side 
effects, and both are called, the side effects must happen in the right 
order.

So the new rule that you are proposing would severly limit some very 
useful optimizations, unless you had exceptions for Pure functions, and 
predefined operators, and static expressions, and... Well you get the 
picture.  Soon you have more exceptions than case that are constrained 
by the rule, and all to insure that functions with side-effects are 
called in a single canonical order.

We prefer to have one easily understood set of rules.  Unfortunately in 
some useful cases these rules work out to "if you really want to be 
sure, install a block with an exception handler."  But this is based on 
twenty years of experience.  Users at all levels don't want strict 
execution orders in most cases, but they all seem to want very good 
optimization.

Also note incidently that what some users really do care about, and 
which has raised entirely too much discussion for something that will 
never be changed, is short-circut expression evaluation.  I don't know 
how many requests I have seen in various forms for redefining 'or' to 
mean 'or else' and 'and' to mean 'and then'.  (The proposals for the 
current meanings of 'and' and 'or' have lots of different syntax 
suggestions associated with them.)  But the real unalterable answer is 
NO! (Or maybe something more forceful.)  There is too much existing code 
that depends on the current rules and the cost of revising that code is 
totally out of proportion to the potential savings--which I don't even 
think exist.  The compiler can use short circut forms if the expression 
after 'and' or 'if' is marked Pure or a static expression, or only 
involves predefined expressions, etc.  (See the similar list above, 
which is what brought it to mind. ;-)

So the only cases where the proposed rule change would make a difference 
are exactly those cases that would have to be revised in existing code. 
And when you check on why the request was made, it often resulted from 
an error message at compile time.  The message can always be eliminated 
by changing the 'and' to 'and then' or the 'or' to 'or else'.  But in 
practice the programmer really has to think to be sure that is the right 
change.

It is the required thinking that seems to generate the revision 
requests. If 'and then' and 'or else' were the defaults then they 
wouldn't need to think during compilation, and they could wait for an 
exception at run-time. ;-)

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: In-Out Parameters for functions

[Stuart Palin]

Hyman Rosen wrote:

> > Ada seems to have (as
> > a matter of pragmatism) chosen not to prohibit certain
> > aspects of ambiguity because the potential benefits [in a
> > wide range of cases] out-weigh the pitfalls.
> 
> Those benefits being?
> 
> > allowing compilers to find an optimal implementation order

... allowing compilers to find an optimal implementation
order!???

> But you are now talking about finding an optimal implementation
> order for an expression involving more than one function call
> where the compiler has no access to the body of the functions.
> Do you really think that allowing the compiler to pick the order
> of the calls will significantly affect the efficiency?
> 
> > - including concurrent computation.

Yes - as Robert Eachus has illustrated much better than I
could.

> Eliminating sources of ambiguity is a good thing even if not all
> of them can be removed.

Agreed, but to emphasize the point made by Robert Eachus -
if the rules you introduce are too complex the cure is worse
than the disease.  There is some merit in having a set of
rules that are perhaps imperfect, but are simpler to
understand: at least you are sure of where you stand.

> > If your proposal to define the execution order were to be
> > adopted, how might a programmer write the Ada code to
> > express their intent that they don't care what order the
> > expression is executed in
> 
> They could not, just as they cannot specify this for sequences
> of statements. If you write
>      x := a + b;
>      y := c + d;
> you may not care which statement is executed first, but you have no
> way of telling this to the compiler. Either the compiler can figure
> this out for itself, or it can't.

or you could possibly identify that x and y are part of a
common object and so might be processed jointly:

   type doublet is record
     x : ... ;
     y : ... ;
   end record;
   ...
   XY : doublet;
   ...

   XY := doublet'(x => a+b, y => c+d);

If they are truly unconnected objects then perhaps they
should be processed in separate tasks.

However, I think that in practice the language has taken a
pragmatic view of where to draw the line in balancing
'ambiguity' of order with optimization: within a single
expression the order of evaluation may be ambiguous, between
separate statements it may not.
--
Stuart Palin

Re: In-Out Parameters for functions

[Hyman Rosen]

Robert I. Eachus wrote:
> That may be why you keep butting your head against a brick wall.  If Ada 
> said that in an equation like: s := Sin(1-x) + Cos(y); that the terms 
> had to be evaluated left to right, that would say you couldn't evaluate 
> Cos(y) before Sin(1-x) whether or not they were declared Pure.
> 
> Ada does allow compilers to combine calls to Pure functions, and if that 
> is not okay, don't declare them Pure.  But that doesn't say that Pure 
> functions can't have side effects.  It just changes what a compiler is 
> allowed to do with Pure functions.

I am not butting my head against a brick wall, I am butting into brick heads.
(Who was it who defined teaching as the art of pounding abstract facts into
concrete heads? :-)

Right now, the ARM says that the operands in an expression are evaluated in
arbitrary order, and I would propose that it say that operands are evaluated
left-to-right. Neither of those statements gives any permission to not call
a subprogram present in an expression.

The section that specifies pragma Pure says that under certain circumstances,
a call to a pure function may be omitted and replaced with the results of a
previous call. That would remain as true in the left-to-right version as in
the arbitrary order version. The concepts are entirely orthogonal.

Re: In-Out Parameters for functions

[Hyman Rosen]

Stuart Palin wrote:
> ... allowing compilers to find an optimal implementation order!???

But as you go on to quote me, the cases where the compiler would not
be permitted to do this are relatively rare, and involve the presence
of multiple function calls within an expression. In such a case, how
much optimization will operand reordering buy?

>>>- including concurrent computation.

Where does Ada permit the concurrent execution of multiple function
calls of an expression?

> if the rules you introduce are too complex the cure is worse
> than the disease.

Fortunately, the rules I introduce are not.

> There is some merit in having a set of rules that are perhaps
 > imperfect, but are simpler to understand: at least you are sure
 > of where you stand.

Yes, that's what my rules would accomplish. There are many people
who are astonished to realize that in
     a := f(a(0)) + g(b(1));
the only constraints are that a is called before f and b before g,
but nothing else is required, so that six orders are possible:
     abfg abgf afbg bafg bagf bgaf

>    XY := doublet'(x => a+b, y => c+d);
> 
> If they are truly unconnected objects then perhaps they
> should be processed in separate tasks.

I will leave it to the people who describe Ada code as readeable to
tell me whether turning a sequence of assignments into an aggregate
or a pair of tasks is a good idea.

Re: In-Out Parameters for functions

[David Starner]

On Tue, 24 Feb 2004 01:55:41 +0000, Hyman Rosen wrote:
> Yes, that's what my rules would accomplish. There are many people
> who are astonished to realize that in
>      a := f(a(0)) + g(b(1));
> the only constraints are that a is called before f and b before g,
> but nothing else is required, so that six orders are possible:
>      abfg abgf afbg bafg bagf bgaf

And there are many people who would be astonished if it matters
and feel compelled to go find the author and beat them over the
head with the ARM.

In any case, there are a lot of things many people would be
astonished to realize. Many people were astonished to realize
that C ints weren't 16 bits long; that didn't mean that the
standard should have changed the definition. Many people
are also astonished to find out that the size of an integer
isn't necessarily the same size as a pointer. 

Re: In-Out Parameters for functions

[Jacob Sparre Andersen]

Hyman Rosen wrote:

> Where does Ada permit the concurrent execution of multiple function
> calls of an expression?

Nowhere (I can remember) - except that "arbitrary order" in my eyes
includes "at the same time".

> Yes, that's what my rules would accomplish. There are many people
> who are astonished to realize that in
>      a := f(a(0)) + g(b(1));
> the only constraints are that a is called before f and b before g,
> but nothing else is required, so that six orders are possible:
>      abfg abgf afbg bafg bagf bgaf

Since Ada specifically is targeted to concurrent processing I find
that astonishment a bit strange.  But maybe those people you're
thinking of aren't used to concurrent processing?

> >    XY := doublet'(x => a+b, y => c+d);
> > If they are truly unconnected objects then perhaps they
> > should be processed in separate tasks.
> 
> I will leave it to the people who describe Ada code as readeable to
> tell me whether turning a sequence of assignments into an aggregate
> or a pair of tasks is a good idea.

If the objects are _logically_ unconnected, the above notation implies
a connection between the objects that only exists for the sake of this
specific implementation.  That may confuse later maintainers of the
code.

Jacob
-- 
"Banning open source would have immediate, broad, and
 strongly negative impacts on the ability of many sensitive
 and security-focused DOD groups to protect themselves
 against cyberattacks"                        -- Mitre Corp.

Re: In-Out Parameters for functions

[Jean-Pierre Rosen]

From: "Jacob Sparre Andersen" <sparre@nbi.dk>
> Hyman Rosen wrote:
>
> > Where does Ada permit the concurrent execution of multiple function
> > calls of an expression?
>
> Nowhere (I can remember) - except that "arbitrary order" in my eyes
> includes "at the same time".
Definitely not. 1.1.4 (18):
   Whenever the run-time semantics defines certain actions to happen in an arbitrary order, this means that
   the implementation shall arrange for these actions to occur in a way that is equivalent to some sequential order,
   following the rules that result from that sequential order.

Otherwise it would mean that all functions should protect themselves against concurrent evaluation, even if there are not tasks in
the program!
Of course, if a compiler determines that a function has no side effect, it can do concurrent evaluation under the "as if" rule. Note
that the rule really says that "it shall be equivalent to some sequential order", not that it is evaluated sequentially.
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: In-Out Parameters for functions

[Hyman Rosen]

David Starner wrote:
> And there are many people who would be astonished if it matters
> and feel compelled to go find the author and beat them over the
> head with the ARM.

As I have said over and over again, the problematic case is when
it matters, and no one notices, and the compiler happens to do
what you want. Then a change in environment could result in the
order changing, and all of a sudden, code mysteriously breaks.

Re: In-Out Parameters for functions

[David Starner]

On Tue, 24 Feb 2004 09:51:44 -0500, Hyman Rosen wrote:
> As I have said over and over again, the problematic case is when
> it matters, and no one notices, and the compiler happens to do
> what you want. Then a change in environment could result in the
> order changing, and all of a sudden, code mysteriously breaks.

And the life and death case is when it matters and the compiler does
what you want, and then maintainers change something, and after they
discover there were uncommented, incredibly subtle order issues, they
go out to kill the original smart-ass programmer. 

Re: In-Out Parameters for functions

[Stephen Leake]

David Starner <dvdeug@email.ro> writes:

> On Tue, 24 Feb 2004 09:51:44 -0500, Hyman Rosen wrote:
> > As I have said over and over again, the problematic case is when
> > it matters, and no one notices, and the compiler happens to do
> > what you want. Then a change in environment could result in the
> > order changing, and all of a sudden, code mysteriously breaks.
> 
> And the life and death case is when it matters and the compiler does
> what you want, and then maintainers change something, and after they
> discover there were uncommented, incredibly subtle order issues, they
> go out to kill the original smart-ass programmer. 

I think Hyman has two valid points:

1) if the language specified left-to-right order, there would never be
   a need to "kill the original smart-ass programmer"

2) Does anyone have a real example of a compiler taking advantage of
   the evaluation order freedom to speed up a program?

Ada is supposed to be about clear, unsurprising code. Subtle order
issues are just that - "subtle". If the language _could_ make them a
non-issue, at very little cost, I think it _should_.

I have not heard anyone respond to 2), which is supposedly the reason
the freedom is there. If no compiler actually takes advantage of it,
it's not worth having.

I don't think there's much chance Ada will change in this area; it
would cost more to change the documentation than it is worth.

But we can at least be honest about it!

-- 
-- Stephe

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On 24 Feb 2004 19:44:12 -0500, Stephen Leake <stephen_leake@acm.org>
wrote:

>David Starner <dvdeug@email.ro> writes:
>
>> On Tue, 24 Feb 2004 09:51:44 -0500, Hyman Rosen wrote:
>> > As I have said over and over again, the problematic case is when
>> > it matters, and no one notices, and the compiler happens to do
>> > what you want. Then a change in environment could result in the
>> > order changing, and all of a sudden, code mysteriously breaks.
>> 
>> And the life and death case is when it matters and the compiler does
>> what you want, and then maintainers change something, and after they
>> discover there were uncommented, incredibly subtle order issues, they
>> go out to kill the original smart-ass programmer. 
>
>I think Hyman has two valid points:
>
>1) if the language specified left-to-right order, there would never be
>   a need to "kill the original smart-ass programmer"

But also, if the language disallowed side-effects when there could be
more than one order. I prefer the second, provided that the term
"side-effect" should be formally defined by the language and visible
from the specifications.

>2) Does anyone have a real example of a compiler taking advantage of
>   the evaluation order freedom to speed up a program?

The question is what gets lost if an evaluation order is fixed. I gave
an example earlier:

for I in A'Range loop
   Sum := Sum + A (I) + B (B'First + I - A'First);
   ...

Here with left-to-right order the compiler cannot optimize neither the
array index of B, nor can it increment Sum by adding A()+B(). Well,
these optimizations could be made possible if the compiler might prove
that the result does not depend on the order. That could be quite
difficult to formally define, especially regarding numeric exceptions
and floating-point accuracy stuff. Even more difficult it would be
check.

But finally, if all that could be achived, then the compiler will be
capable to simply detect that different orders give different results,
and threat it as an error. Much better than fixing an arbitrary order!

So the bottom line, IMO, 1 makes no sense.

>Ada is supposed to be about clear, unsurprising code. Subtle order
>issues are just that - "subtle". If the language _could_ make them a
>non-issue, at very little cost, I think it _should_.

Right, the present situation is not good. But IMO the solution lies in
introducing formally pure functions and imposing limitations on use of
impure functions (and procedures with results) in expressions.

>I have not heard anyone respond to 2), which is supposedly the reason
>the freedom is there. If no compiler actually takes advantage of it,
>it's not worth having.
>
>I don't think there's much chance Ada will change in this area; it
>would cost more to change the documentation than it is worth.
>
>But we can at least be honest about it!

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: In-Out Parameters for functions

[David Starner]

On Tue, 24 Feb 2004 19:44:12 -0500, Stephen Leake wrote:
> 1) if the language specified left-to-right order, there would never be
>    a need to "kill the original smart-ass programmer"

If it got changed in maintenance, and introduced a bug because no one
saw the hidden dependency, then there would be. 
 
> Ada is supposed to be about clear, unsurprising code. Subtle order
> issues are just that - "subtle". If the language _could_ make them a
> non-issue, at very little cost, I think it _should_.

But it doesn't change the meaning of much clear, unsurprising code. Most
of the examples depend on hidden state. The rest depend on I/O. Neither
occur much in clear, unsurprising code.

(Okay, so I/O is necessary in programs. But the examples using I/O
can be rewritten not to use this, and are usually pretty obvious.)
 
> I don't think there's much chance Ada will change in this area; it
> would cost more to change the documentation than it is worth.
> 
> But we can at least be honest about it!

I think part of it is language philosophy. Ada is not C, but it's not
Java, either. Ada's goal is not to make every program run exactly the same
everywhere. Perhaps the supposed efficiency goals aren't achieved by this
choice, but reversing the choice, and helping some marginal code become
legal, isn't a huge win in the terms of Ada's choices. 

Re: In-Out Parameters for functions

[Marin David Condic]

That is an issue I think we Ada fans often get caught up in. "Well, in 
*theory* an Ada compiler could do blah blah blah...." But if, in 
*practice*, none of them do and none of them have any plans to do so, 
then effectively "The Language" doesn't do it. A good example is when 
people post here asking "Does Ada have garbage collection?" We tell them 
the standard allows it, but nobody does it. Do they care that the 
standard allows it if they can't get a compiler that does it? The same 
goes for other issues like efficiency. A feature might theoretically be 
implementable in an efficient manner, but if nobody does it well in 
practice, you get the accusation "Ada is slow..." and its hard to argue 
against.

There is a real distinction between what the standard says and what 
might exist by way of implementations, but for most practical purposes, 
average developers don't make that distinction. Hence, there is a de 
facto "standard" which cannot be ignored.

MDC


Stephen Leake wrote:
> 
> 2) Does anyone have a real example of a compiler taking advantage of
>    the evaluation order freedom to speed up a program?

> 
> I have not heard anyone respond to 2), which is supposedly the reason
> the freedom is there. If no compiler actually takes advantage of it,
> it's not worth having.
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: In-Out Parameters for functions

[Hyman Rosen]

David Starner wrote:
> I think part of it is language philosophy.

What philosophy requires the retention of a feature
that offers no benefits and can be removed without
affecting legal programs?

Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>David Starner wrote:
>> I think part of it is language philosophy.
>
>What philosophy requires the retention of a feature
>that offers no benefits and can be removed without
>affecting legal programs?

The philosophy that the semantics of a program should be the same, no
matter if you choose to write "f := a + b;" or "f = b + a;" instead.
With that in mind, it is easier to make someone aware of better
writing functions *without* side-effects, which is supposed to be a
good thing. :-)

BTW, AFAICS and JFTR: C and C++ don't specify evaluation either (I
don't know if Java does fix it), except when sequence points are
involved. The only difference is that unfortunately all Boolean
operations happen to be sequence points here.


Vinzent.

Re: In-Out Parameters for functions

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> The philosophy that the semantics of a program should be the same, no
> matter if you choose to write "f := a + b;" or "f = b + a;" instead.

But Ada does not have that philosophy, so that cannot be the reason
to maintain the feature. When "+" is a user-defined subprogram, its
operands are always passed in the order written; a + b is always
invoked as "+"(a, b) and never as "+"(b, a).

> BTW, AFAICS and JFTR: C and C++ don't specify evaluation either

Correct. I've made the same arguments in the C++ newsgroups :-)

> (I don't know if Java does fix it)

It does.

>  The only difference is that unfortunately all Boolean
> operations happen to be sequence points here.

"Unfortunately"? Built-in && is the equivalent of Ada "and then"
and || is the equivalent of "or else". What exactly makes that
unfortunate?

Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>Vinzent 'Gadget' Hoefler wrote:
>> The philosophy that the semantics of a program should be the same, no
>> matter if you choose to write "f := a + b;" or "f = b + a;" instead.
>
>But Ada does not have that philosophy, so that cannot be the reason
>to maintain the feature.

It has it for built-in functions where the compiler knows that it
doesn't make any difference.

>When "+" is a user-defined subprogram, its
>operands are always passed in the order written; a + b is always
>invoked as "+"(a, b) and never as "+"(b, a).

Well, yes.

Think of the case where "+" might not be commutative. I guess it would
be too much burden to specify in the standard that the compiler should
be able to figure out if this is the case or not in each particular
case. The simplest example would be a "+" where a and b have different
types. ;-)

>>  The only difference is that unfortunately all Boolean
>> operations happen to be sequence points here.
>
>"Unfortunately"? Built-in && is the equivalent of Ada "and then"
>and || is the equivalent of "or else". What exactly makes that
>unfortunate?

There's no equivalent of an Ada's "and" and "or" where the compiler
can evaluate if the comparison with the result of a costly square-root
function should be delayed until we can figure out if the simple
boolean flag already gives us the result:

|if (Sqrt (x) > 5.0) and b then ...

So you should always write this in the most efficient order then, even
if it might not be the most intuitive way.

BTW, the above is another reason why you shouldn't write functions
with side effects, because if you do the compiler *has* to evaluate
Sqrt, too. :-)


Vinzent.

Re: In-Out Parameters for functions

[Hyman Rosen]

Hyman Rosen wrote:
> But Ada does not have that philosophy, so that cannot be the reason
> to maintain the feature. When "+" is a user-defined subprogram, its
> operands are always passed in the order written; a + b is always
> invoked as "+"(a, b) and never as "+"(b, a).

And I should add that the same holds true for associativity. If you
write a + b + c and "+" is user-defined, the call is "+"("+"(a, b), c)
and never "+"(a, "+"(b, c)). The freedom to use other associations is
only for predefined operators.

Re: In-Out Parameters for functions

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> Think of the case where "+" might not be commutative.

Exactly. So as I said, Ada has no philosophy that a + b
means the same thing as b + a. Thus it is not a relevant
argument against specifying order of evaluation.

> There's no equivalent of an Ada's "and" and "or" where the compiler
> can evaluate if the comparison with the result of a costly square-root
> function should be delayed until we can figure out if the simple
> boolean flag already gives us the result:
> 
> |if (Sqrt (x) > 5.0) and b then ...

How would knowing that b is false help the compiler not call the
costly operation? The rules of Ada require that for "and", both
operands are evaluated! If you are really intent on writing such
code in C or C++, you may say !!a & !!b, where the hideousness
will give a clue to the reader that something weird is going on.

> BTW, the above is another reason why you shouldn't write functions
> with side effects, because if you do the compiler *has* to evaluate
> Sqrt, too. :-)

If the compiler knows enough about Sqrt to know that it has no side
effects, then it will have no problem checking b first even if you
write (sqrt(x) > 5.0 and then b).

Really, all these arguments sound so desperate.

Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>The rules of Ada require that for "and", both
>operands are evaluated!

No, it doesn't.

>> BTW, the above is another reason why you shouldn't write functions
>> with side effects, because if you do the compiler *has* to evaluate
>> Sqrt, too. :-)
>
>If the compiler knows enough about Sqrt to know that it has no side
>effects, then it will have no problem checking b first even if you
>write (sqrt(x) > 5.0 and then b).

Well, in *this* case you *want* it to be evaluated first, I guess. :)

>Really, all these arguments sound so desperate.

Well, I don't build compilers. But - AFAICS - the only reason for not
fixing the evaluation order usually *is* code optimization.


Vinzent.

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> But Ada does not have that philosophy, so that cannot be the reason
> to maintain the feature. When "+" is a user-defined subprogram, its
> operands are always passed in the order written; a + b is always
> invoked as "+"(a, b) and never as "+"(b, a).

Absolutely wrong.  If I or any other Ada programmer defines an abstract 
type Foo, and it makes sense to add Integers to Foo, and the semantics 
of addition are commutative, I will declare:

function "+"(L: Foo; R: Integer) return Foo is...

function "+"(L: Integer; R: Foo) return Foo
is begin return R+L; end "+";

This is standard programming practice because it reflects the underlying 
semantics.  In fact I will probably provide "-" operations as well, 
defined as return L+(-R) and R+(-L) respectively.  (And yes, sometimes I 
will even provide an exception handler to deal with subrtracting 
Integer'First..)

-- 
                                           Robert I. Eachus

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

Re: In-Out Parameters for functions

[Preben Randhol]

On 2004-02-25, Hyman Rosen <hyrosen@mail.com> wrote:
>> 
>> |if (Sqrt (x) > 5.0) and b then ...
>
> How would knowing that b is false help the compiler not call the
> costly operation?

isn't 
   
   if (undecided) and false then 

the same as 

   if false then

?

Only in the case that b is true is the evaluation of needed Sqrt (x) > 5.0 

Or have I missed som point here?


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

Re: In-Out Parameters for functions

[Preben Randhol]

On 2004-02-25, Hyman Rosen <hyrosen@mail.com> wrote:
>
> If the compiler knows enough about Sqrt to know that it has no side
> effects, then it will have no problem checking b first even if you
> write (sqrt(x) > 5.0 and then b).

Well

if sqrt(x) > 5.0 and then b then

is the same as

if sqrt(x) > 5.0 then
   if b then


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

Re: In-Out Parameters for functions

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> Hyman Rosen wrote:
>>The rules of Ada require that for "and", both
>>operands are evaluated!
> No, it doesn't.

ARM 4.5/11 says
     "The two operands of an expression of the form X op Y,
      where op is a binary operator, are evaluated in an
      arbitrary order, as for any function_call (see 6.4)."

Where do you find permission for Ada to not evaluate one
operand of an "and" or "or" expression?

Re: In-Out Parameters for functions

[Hyman Rosen]

Preben Randhol wrote:
> Only in the case that b is true is the evaluation of needed Sqrt (x) > 5.0 
> Or have I missed som point here?

Sqrt(x) may have side effects.

Re: In-Out Parameters for functions

[Hyman Rosen]

Robert I. Eachus wrote:
> Absolutely wrong. ... I will declare...

You are describing your programming practices.
Your practices do not necessarily represent the
philosophy of the language. In any case, when I
said that a + b becomes "+"(a, b) and not "+"(b, a)
I was not "absolutely wrong" but "absolutely right".

Re: In-Out Parameters for functions

[Hyman Rosen]

Preben Randhol wrote:
> if sqrt(x) > 5.0 and then b then
> 
> is the same as
> 
> if sqrt(x) > 5.0 then
>    if b then

Yes, so? As I said, if the compiler knows that sqrt(x)
is free of side effects, it can go ahead and evaluate
b first and never call sqrt(x) if b is false.
That's true in both forms above. It doesn't matter how
you write it. If sqrt(x) is free of side effects, you
cannot know whether it has been called, as far as the
language definition is concerned.

Re: In-Out Parameters for functions

[Preben Randhol]

On 2004-02-25, Hyman Rosen <hyrosen@mail.com> wrote:
> Yes, so? As I said, if the compiler knows that sqrt(x)
> is free of side effects, it can go ahead and evaluate
> b first and never call sqrt(x) if b is false.
> That's true in both forms above. It doesn't matter how
> you write it. If sqrt(x) is free of side effects, you
> cannot know whether it has been called, as far as the
> language definition is concerned.

My point was that when you use the and then you tell the compiler to
evaluate left-side before right. Whereas if you use only and it is not
given which side will be evaluated first. At least I thought so.

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

Re: In-Out Parameters for functions

[Hyman Rosen]

Preben Randhol wrote:
> My point was that when you use the and then you tell the compiler to
> evaluate left-side before right. Whereas if you use only and it is not
> given which side will be evaluated first. At least I thought so.

Yes, that's correct. However, program behavior is always subject to
the "as if" convention. That is, the program must have observable
behavior as if the compiler did things in the order that the language
specified, but that observable behavior is limited by the language
definition to things like I/O, calling imported subprograms, and some
other stuff that can be loosely categorized as side-effects.

In the proposed case of (sqrt(x) > 0.5 and b), if sqrt(x) has side
effects it must be evaluated regardless of the value of b, and if
it has no side effects you cannot know if it has been evaluated, and
so the compiler may evaluate b first and never evaluate sqrt(x) at
all. The latter holds even if you write (sqrt(x) > 0.5 and then b).

Re: In-Out Parameters for functions

[Frank J. Lhota]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1077727544.813834@master.nyc.kbcfp.com...
> Preben Randhol wrote:
> > Only in the case that b is true is the evaluation of needed Sqrt (x) >
5.0
> > Or have I missed som point here?
>
> Sqrt(x) may have side effects.

For example, if x < 0.0, then Sqrt(x) raises an exception!

Re: In-Out Parameters for functions

[Randy Brukardt]

"Stephen Leake" <stephen_leake@acm.org> wrote in message
news:mailman.20.1077669870.327.comp.lang.ada@ada-france.org...
> 2) Does anyone have a real example of a compiler taking advantage of
>    the evaluation order freedom to speed up a program?

Janus/Ada will take advantage of this to reduce pending floating point
results on the Intel CPUs. These are quite expensive because the floating
point stack is very short, so it has to be clear before any subprogram call.
Thus the pending results have to be spilled to memory (and later reloaded),
rather than just using registers.

So, if you have an expression like:

    B := V + F(...);

Janus/Ada may make the call first, in order to avoid the pending floating
point operation.

Of course, if F changes the value of V, then you'll get a different answer.
Of course, the compiler does not know what's in the body of F. Indeed, even
if it could see the body of F, it couldn't assume that it doesn't modify V,
as it could be changed and recompiled without the call code being changed.

Thus, requiring a particular order of evaluation would make this
optimization impossible. (Even if V is a local variable, it could be changed
by overlays or other nasty code.)

                   Randy.

Re: In-Out Parameters for functions

[Randy Brukardt]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1077727496.631820@master.nyc.kbcfp.com...
> ARM 4.5/11 says
>      "The two operands of an expression of the form X op Y,
>       where op is a binary operator, are evaluated in an
>       arbitrary order, as for any function_call (see 6.4)."
>
> Where do you find permission for Ada to not evaluate one
> operand of an "and" or "or" expression?

11.6(5), of course. Since there is no requirement to evaluate a function
solely to see if it raises an exception (since the result is not needed in
this case), the entire call can be removed.

                         Randy.

Re: In-Out Parameters for functions

[Hyman Rosen]

Randy Brukardt wrote:
> "Hyman Rosen" <hyrosen@mail.com> wrote
>>Where do you find permission for Ada to not evaluate one
>>operand of an "and" or "or" expression?
> 
> 11.6(5), of course.

For the particular case of sqrt(x), where we're talking
about Ada's built-in sqrt, and the only possible side-effect
is for it to raise an exception. But if instead we have
(gnurble(x) > 0.5 and b), and the compiler knows that b is
false but has no information about what gnurble does, it
must call gnurble(x) even though the result is irrelevant.

Re: In-Out Parameters for functions

[Jim Rogers]

Stephen Leake <stephen_leake@acm.org> wrote in message news:<mailman.20.1077669870.327.comp.lang.ada@ada-france.org>...
> I think Hyman has two valid points:
> 
> 1) if the language specified left-to-right order, there would never be
>    a need to "kill the original smart-ass programmer"
> 
> 2) Does anyone have a real example of a compiler taking advantage of
>    the evaluation order freedom to speed up a program?

But how does his order of evaluation work with named notation?
Is the order determined by the order of the formal parameters, or by
the order of the actual parameters?

In Ada it is not as easy to determine parameter order because of
named notation.

Jim Rogers

Re: In-Out Parameters for functions

[Hyman Rosen]

Jim Rogers wrote:
> But how does his order of evaluation work with named notation?

I would go with the order of the actual parameters,
not the order of the formal parameters. One goal of
specifying evaluation order is to have unsurprising
behavior, so saying
     Battery(Catcher => GetName, Pitcher => GetName);
should assign the first name read to Catcher and the
second to Pitcher, regardless of the order of the formal
parameters of Battery.

I can't at the moment think of a good reason for doing it
the other way from the programmer's point of view, rather
than for the convenience of the compiler.

Re: In-Out Parameters for functions

[Preben Randhol]

On 2004-02-25, Hyman Rosen <hyrosen@mail.com> wrote:
> Randy Brukardt wrote:
>> "Hyman Rosen" <hyrosen@mail.com> wrote
>>>Where do you find permission for Ada to not evaluate one
>>>operand of an "and" or "or" expression?
>> 
>> 11.6(5), of course.
>
> For the particular case of sqrt(x), where we're talking
> about Ada's built-in sqrt, and the only possible side-effect
> is for it to raise an exception. But if instead we have
> (gnurble(x) > 0.5 and b), and the compiler knows that b is
> false but has no information about what gnurble does, it
> must call gnurble(x) even though the result is irrelevant.

Or you have to do:

   value := gnuble(x);

   if value > 0.5 and b then 

to be sure that any side effects are performed.


   with Ada.Text_IO;  use Ada.Text_IO; 

   procedure eval is
      flag : Boolean := false;

      function gnurble(value : Float) return Float is
      begin
         Put_Line ("I was called");
         return value + 99.0;
      end gnurble;

   begin
      if flag and gnurble (1.0) > 2.0 then
   --   if gnurble (1.0) > 2.0 and flag then   -- or this case
   --   if false and gnurble (1.0) > 2.0 then  -- or this
   --   if gnurble (1.0) > 2.0 and false then  -- or this
         Put_Line ("True");
      else
         Put_Line ("False");
      end if;

   end eval;


For all these cases I get that the gnurble function was called and the
if statment is of course false. Even with optimisation.

However if you do this:


   with Ada.Text_IO;  use Ada.Text_IO; 

   procedure eval is
      flag : Boolean := false;

      function gnurble(value : Float) return Float is
      begin
         flag := true;                        -- Added a side effect
         Put_Line ("I was called");
         return value + 99.0;
      end gnurble;

   begin
      if flag and gnurble (1.0) > 2.0 then    -- Case 1 
    --  if gnurble (1.0) > 2.0 and flag then  -- Case 2
         Put_Line ("True");
      else
         Put_Line ("False");
      end if;

   end eval;

The result is:

Case 1:

% ./eval 
I was called
True

Case 2:

% ./eval 
I was called
True

Wheras if you do:

   if flag and then gnurble (1.0) > 2.0 then

then gnurble is never called of course.

Compiler GNAT 3.15p
-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: In-Out Parameters for functions

[Preben Randhol]

On 2004-02-26, Preben Randhol <randhol+valid_for_reply_from_news@pvv.org> wrote:
> For all these cases I get that the gnurble function was called and the
> if statment is of course false. Even with optimisation.

Note when I say optimisation I only did: gnatmake -O3 
I didn't have time to check the UG for other optimisation flags...


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

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On Wed, 25 Feb 2004 17:19:50 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Jim Rogers wrote:
>> But how does his order of evaluation work with named notation?
>
>I would go with the order of the actual parameters,
>not the order of the formal parameters. One goal of
>specifying evaluation order is to have unsurprising
>behavior, so saying
>     Battery(Catcher => GetName, Pitcher => GetName);
>should assign the first name read to Catcher and the
>second to Pitcher, regardless of the order of the formal
>parameters of Battery.
>
>I can't at the moment think of a good reason for doing it
>the other way from the programmer's point of view, rather
>than for the convenience of the compiler.

Discriminants are exposed as members and can be used in named
associations. From any point of view they are better to be evaluated
first:

type Buffer (Size : Integer) is record
   Data : String (1..Size);
end record;

Note that the aggregate:

Buffer'(Data => ..., Size => ...)

is quite legal. So by fixing the evaluation order here the compiler
will be forced to make a temporal copy of the Data field, because it
will be unable to create Buffer not knowing Size.

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>Vinzent 'Gadget' Hoefler wrote:
>> Hyman Rosen wrote:
>>>The rules of Ada require that for "and", both
>>>operands are evaluated!
>> No, it doesn't.
>
>ARM 4.5/11 says
>     "The two operands of an expression of the form X op Y,
>      where op is a binary operator, are evaluated in an
>      arbitrary order, as for any function_call (see 6.4)."
>
>Where do you find permission for Ada to not evaluate one
>operand of an "and" or "or" expression?

In "arbitrary"? ;-)


Vinzent.

Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>For the particular case of sqrt(x), where we're talking
>about Ada's built-in sqrt, and the only possible side-effect
>is for it to raise an exception. But if instead we have
>(gnurble(x) > 0.5 and b), and the compiler knows that b is
>false but has no information about what gnurble does, it
>must call gnurble(x) even though the result is irrelevant.

Yes, it should (I'm not sure, if it actually *has to*) call the
function if it is possible that the function has side-effects.

What's your problem here?


Vinzent.

Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>Jim Rogers wrote:
>> But how does his order of evaluation work with named notation?
>
>I would go with the order of the actual parameters,
>not the order of the formal parameters. One goal of
>specifying evaluation order is to have unsurprising
>behavior, so saying
>     Battery(Catcher => GetName, Pitcher => GetName);
>should assign the first name read to Catcher and the
>second to Pitcher, regardless of the order of the formal
>parameters of Battery.

Yes, and that is a very good example on how to write bad code. First:
GetName is obviously a function with side-effect, second it relies on
a specific calling order.

If you want a specific order, do it explicitely:

|Tmp_Name_1 := GetName;
|Tmp_Name_2 := GetName;
|
|Battery(Catcher => Tmp_Name_1, Pitcher => Tmp_Name_2);

>I can't at the moment think of a good reason for doing it
>the other way from the programmer's point of view,

Well, my point of view to the original code would be that it doesn't
matter which name gets assigned to which parameter.

>rather than for the convenience of the compiler.

Yes, true. But Ada is - like a lot of others - a programming language
that is supposed to get compiled some day. And sometimes language
designers should keep an eye on this if they want a language to be
used outside of purely theoretical and/or educational areas.

So it might be possible that in the parsing/compiling process the
order specified in the named notation simply gets reordered to the
order of how the parameters are declared. Well, even this still
doesn't mean, that this would be the order in which the functions are
called in the end.

I think, all this discussion about execution order is a little bit
senseless when today we have processors that do explicit instruction
reordering and even have parallel execution support. Even if the
compiler issues code where the execution order is fixed that doesn't
mean that the processor will execute it this way. And you don't want
the compiler to emit one serializing instruction after another just to
make sure that the execution order does not change, do you?

IMO, it is easier to just not rely on side-effects. No side-effects,
no problems.


Vinzent.

Re: In-Out Parameters for functions

[Wojtek Narczynski]

Hello,

> I would go with the order of the actual parameters,
> not the order of the formal parameters. One goal of
> specifying evaluation order is to have unsurprising
> behavior, so saying
>      Battery(Catcher => GetName, Pitcher => GetName);
> should assign the first name read to Catcher and the
> second to Pitcher, regardless of the order of the formal
> parameters of Battery.

How about:

Battery(Catcher => GetName then Pitcher => GetName, Doorman => GetName
);

This way the change would not affect current code, and you could
specify partial order.

Regards,
Wojtek

Re: In-Out Parameters for functions

[Lutz Donnerhacke]

* Wojtek Narczynski wrote:
> How about:
> Battery(Catcher => GetName then Pitcher => GetName, Doorman => GetName);

Very bad. Hard to read. Hard to maintain. Bad Ada-Style.

   declare
      catcher : constant Name := GetName;
      pitcher : constant Name := GetName;
      doorman : constant Name := GetName;
   begin
      Battery(catcher, pitcher, doorman);
   end;

Moderate to write, moderate to read and easy to understand/maintain.

Re: In-Out Parameters for functions

[Robert I. Eachus]

Vinzent 'Gadget' Hoefler wrote:

> Hyman Rosen wrote:
> 
>> For the particular case of sqrt(x), where we're talking about Ada's
>> built-in sqrt, and the only possible side-effect is for it to raise
>> an exception. But if instead we have (gnurble(x) > 0.5 and b), and
>> the compiler knows that b is false but has no information about
>> what gnurble does, it must call gnurble(x) even though the result
>> is irrelevant.
> 
> 
> Yes, it should (I'm not sure, if it actually *has to*) call the 
> function if it is possible that the function has side-effects.
> 
> What's your problem here?
> 

That he has never read 10.2.1(18)? "If a library unit is declared pure,
then the implementation is permitted to omit a call on a library-level 
subprogram of the library unit if the results are not needed after the 
call. Similarly, it may omit such a call and simply reuse the results 
produced by an earlier call on the same subprogram, provided that none 
of the parameters are of a limited type, and the addresses and values of 
all by-reference actual parameters, and the values of all by-copy-in 
actual parameters, are the same as they were at the earlier call. This 
permission applies even if the subprogram produces other side effects 
when called."

Can't we just all agree that Hymen is not an Ada language expert and 
doesn't want to be?  In this case, the rules of Ada are well thought out 
to allow any user, not the compiler to determine whether an 
"unnecessary" function call can be eliminated.  Similarly, the language 
allows users to force syncronization points and orders of evaluation, 
when they are a necessary part of the algorithm being implemented.

We have jokingly called for shooting a programmer who knowingly writes 
code that depends on order of evaluation and then--yes that is an Ada 
and then--doesn't document it or force the compiler to use the necessary 
order.   Actually the correction applied would probably be education, 
warnings, bad reviews, and eventually firing the employee if nececssary.

For anyone who deliberately persists in such bad habits, if necessary 
could be within weeks. Emphasis on deliberately, but I have had to make 
that decision for programmers who persisted in other bad habits like 
bypassing the required check-in procedures for software. In that case, 
firing the programmer probably saved him from a lynch mob, as other 
programmmers kept finding their submissions being rejected due to his 
changes not passing the regression tests.

What do we do with Mr. Hymen Rosen?  For now, I'm going to just post 
chapter and verse, and that Mr. Rosen's opinion on any Ada language 
issue should be ignored.

-- 
                                           Robert I. Eachus

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

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> Preben Randhol wrote:
> 
>> Only in the case that b is true is the evaluation of needed Sqrt (x) > 
>> 5.0 Or have I missed som point here?
> 
> 
> Sqrt(x) may have side effects.

Totally irrelevant.  As I just posted what matters is whether or not 
Sqrt(x) is declared in a pure library unit.  In the case of the standard 
Sqrt, the standard also says:

    pragma Pure(Generic_Elementary_Functions);

So the compiler is free to eliminate calls to Sqrt if possible.

-- 
                                           Robert I. Eachus

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

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> Robert I. Eachus wrote:
> 
>> Absolutely wrong. ... I will declare...
> 
> 
> You are describing your programming practices.
> Your practices do not necessarily represent the
> philosophy of the language. In any case, when I
> said that a + b becomes "+"(a, b) and not "+"(b, a)
> I was not "absolutely wrong" but "absolutely right".

No, you were absolutely wrong as usual.  The order of evaluation of the 
parameters to "+" is undefined whether the "+" is user defined or 
language defined.  To quote 6.4(10): "These evaluations are done in an 
arbitrary order."  There is even an explicit footnote at 4.5(14) that 
explains that this applies to predefined operators as well as user 
defined operators.

I should stop wrestling with pigs.  But I would like to preserve this 
newsgroup as a place where users can get reliable advice on language 
issues.  So I have to keep putting up these placards that say ignore 
anything Hyman Rosen says about Ada language issues.

-- 

                                           Robert I. Eachus

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

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> Jim Rogers wrote:
> 
>> But how does his order of evaluation work with named notation?
> 
> 
> I would go with the order of the actual parameters,
> not the order of the formal parameters. One goal of
> specifying evaluation order is to have unsurprising
> behavior, so saying
>     Battery(Catcher => GetName, Pitcher => GetName);
> should assign the first name read to Catcher and the
> second to Pitcher, regardless of the order of the formal
> parameters of Battery.
> 
> I can't at the moment think of a good reason for doing it
> the other way from the programmer's point of view, rather
> than for the convenience of the compiler.

You can't but Randy posted a very good explanation of why his compiler 
does it in a different order.  And even at the risk of sounding like a 
broken record, the Ada standard say this will be done in "an arbitrary 
order."  If a user wants to, he can use other language rules (and code 
that makes it obvious that it is intentional) to force a particular 
evaluation order.  But it is much harder to do that than to make the 
code agnostic about evaluation order, and that is intentional.

-- 

                                           Robert I. Eachus


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

Re: In-Out Parameters for functions

[Jean-Pierre Rosen]

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


"Robert I. Eachus" <rieachus@comcast.net> a �crit dans le message de news:-tednUSWDcMxbqDdRVn-sw@comcast.com...
> What do we do with Mr. Hymen Rosen?  For now, I'm going to just post
> chapter and verse, and that Mr. Rosen's opinion on any Ada language
> issue should be ignored.
>
Please always use qualified notation (with the first-name). Otherwise, a partial quotation of the above would overload several
people :-)

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: In-Out Parameters for functions

[Hyman Rosen]

Preben Randhol wrote:
> For all these cases I get that the gnurble function was called and the
> if statment is of course false. Even with optimisation.

We're in violent agreement here. Everything you report is
exactly how I exepcted it to be. (Except for the case of
the gnurble which modifies the flag, where I don't have any
expectations.)

Re: In-Out Parameters for functions

[Hyman Rosen]

Robert I. Eachus wrote:
> Vinzent 'Gadget' Hoefler wrote:
>> What's your problem here?
> That he has never read 10.2.1(18)?
> Can't we just all agree that Hyman is not an Ada language expert and 
> doesn't want to be? ... What do we do with Mr. Hyman Rosen?  For now,
 > I'm going to just post chapter and verse, and that Mr. Rosen's opinion
 > on any Ada language issue should be ignored.

This particular subthread started when V'G'H stated that in C/C++
     "The only difference is that unfortunately all Boolean
      operations happen to be sequence points here."
When I asked him why this was unfortunate, he replied that the Ada
     if (Sqrt (x) > 5.0) and b then
permitted Ada to test b first, and not call Sqrt(x) if b was false.
I pointed out that unless sqrt(x) (later amended to gnurble(x)) was
known to the compiler to be free of side-effects, the compiler must
call it regardless of the value of b. I also pointed out that under
similar circumstances
     if (Sqrt (x) > 5.0) and then b then
would allow exactly the same optimization to be performed, i.e., b
could be tested first and sqrt(x) need not be called if b is false.
I assume 10.2.1(18)'s "results are not needed" allows the compiler
to be as brilliant as it wants to be in determining this?

In these discussions I tend to use the phrase "free of side-effects"
as shorthand. I know that prgama pure subprograms are permitted to
have side-effects, but that's not germane to the discussion, and I
don't feel like adding "or pure" all over the place.

Re: In-Out Parameters for functions

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> Hyman Rosen wrote:
>>Where do you find permission for Ada to not evaluate one
>>operand of an "and" or "or" expression?
> 
> In "arbitrary"? ;-)

Being permitted to do some things in arbitrary order certainly
does not give permission to omit doing some of them. The ARM
does not say that an arbitrary number of operands are evaluated,
it says that the operands are evaluated in arbitrary order.

This is not Wonderland, where words mean exactly what you want
them to.

Re: In-Out Parameters for functions

[Hyman Rosen]

Robert I. Eachus wrote:
> Hyman Rosen wrote:
>> In any case, when I
>> said that a + b becomes "+"(a, b) and not "+"(b, a)
>> I was not "absolutely wrong" but "absolutely right".
> 
> No, you were absolutely wrong as usual.  The order of evaluation of the 
> parameters to "+" is undefined whether the "+" is user defined or 
> language defined.

Where did I say that the order of evaluation of the operands was
defined? V'G'H argued that the philosophy of Ada was that a + b
and b + a are the same. I pointed out that for user-defined "+",
when you write a + b, the function is called with a as the Left
operand and b as the Right, never the reverse.

 > I should stop wrestling with pigs.

You are so eager to believe I am wrong about everything I say that
you are not reading what I say. Stop it. You're just going to annoy
the pig :-)

Re: In-Out Parameters for functions

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> Yes, and that is a very good example on how to write bad code. First:
> GetName is obviously a function with side-effect, second it relies on
> a specific calling order.

Well, duh. The discussion is about what behavior we want in this case
should we actually define a specific calling order.

> I think, all this discussion about execution order is a little bit
> senseless when today we have processors that do explicit instruction
> reordering and even have parallel execution support.

Not at all. We are discussing the semantics of Ada. How they are
implemented on a processor by the compiler is not relevant.

Re: In-Out Parameters for functions

[Hyman Rosen]

Lutz Donnerhacke wrote:
> Very bad. Hard to read. Hard to maintain. Bad Ada-Style.
>    declare
>       catcher : constant Name := GetName;
>       pitcher : constant Name := GetName;
>       doorman : constant Name := GetName;
>    begin
>       Battery(catcher, pitcher, doorman);
>    end;
> Moderate to write, moderate to read and easy to understand/maintain.

Or, in well-defined Ada,
     declare
         catcher, pitcher, doorman : constant Name := GetName;
     begin
        Battery(catcher, pitcher, doorman);
     end;

Re: In-Out Parameters for functions

[Hyman Rosen]

Robert I. Eachus wrote:
 > Randy posted a very good explanation of why his compiler
> does it in a different order.

Yes. That was finally a legitimate example of the compiler
using this permission to generate better code.

> But it is much harder to do that than to make the 
> code agnostic about evaluation order, and that is intentional.

But unlike such things as array index violations, Ada isn't
required to tell you that your code is not agnostic about
evaluation order, and therefore such violations can lurk
undetected.

Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>Vinzent 'Gadget' Hoefler wrote:
>> Hyman Rosen wrote:
>>>Where do you find permission for Ada to not evaluate one
>>>operand of an "and" or "or" expression?
>> 
>> In "arbitrary"? ;-)
>
[Disagreement]

>This is not Wonderland, where words mean exactly what you want
>them to.

Should I have marked the Smiley Red and with an additional
"blink"-Attribute? Perhaps some alarming sound, too?


Vinzent.

Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>Vinzent 'Gadget' Hoefler wrote:
>> Yes, and that is a very good example on how to write bad code. First:
>> GetName is obviously a function with side-effect, second it relies on
>> a specific calling order.
>
>Well, duh. The discussion is about what behavior we want in this case
>should we actually define a specific calling order.

Yes. But I don't like the idea of inviting programmers to a party "We
have defined the evaluation order - now you can write functions with
side-effects and they behave equally strange on all systems".

>> I think, all this discussion about execution order is a little bit
>> senseless when today we have processors that do explicit instruction
>> reordering and even have parallel execution support.
>
>Not at all. We are discussing the semantics of Ada. How they are
>implemented on a processor by the compiler is not relevant.

It just doesn't make sense to argue about a specific order if the
processor itself changes it when the code gets executed, does it?


Vinzent.

Re: In-Out Parameters for functions

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> Yes. But I don't like the idea of inviting programmers to a party "We
> have defined the evaluation order - now you can write functions with
> side-effects and they behave equally strange on all systems".

The idea is to make it not strange, so that you read the code and
immediately understand what it does.

> It just doesn't make sense to argue about a specific order if the
> processor itself changes it when the code gets executed, does it?

Of course it does, in the same way that we can talk about Ada's
support for decimal arithmetic on processors which are unrelentingly
binary. Programming langiage semantics don't have anything to do
with processor semantics.

Re: In-Out Parameters for functions

[David Starner]

On Thu, 26 Feb 2004 13:12:32 -0500, Hyman Rosen wrote:
> The idea is to make it not strange, so that you read the code and
> immediately understand what it does.

Part of the point of the argument is that I don't believe your solution
can change; it's still going to be virtually impossible to follow, it's
just going to be sanctioned as acceptable.

Re: left-to-right (was In-Out Parameters for functions)

[Stephen Leake]

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

> On 24 Feb 2004 19:44:12 -0500, Stephen Leake <stephen_leake@acm.org>
> wrote:
> 
> >I think Hyman has two valid points:
> >
> >1) if the language specified left-to-right order, there would never be
> >   a need to "kill the original smart-ass programmer"
> 
> But also, if the language disallowed side-effects when there could be
> more than one order. I prefer the second, provided that the term
> "side-effect" should be formally defined by the language and visible
> from the specifications.

That's never going to happen!

> >2) Does anyone have a real example of a compiler taking advantage
> >of the evaluation order freedom to speed up a program?
> 
> The question is what gets lost if an evaluation order is fixed. I gave
> an example earlier:
> 
> for I in A'Range loop
>    Sum := Sum + A (I) + B (B'First + I - A'First);
>    ...
> 
> Here with left-to-right order the compiler cannot optimize neither the
> array index of B, 

What do you mean by "optimize" in this sentence? the array index of B
is B'First + I - A'First. It must be computed before B(). In what way
would this be done differently by a "real Ada" compiler vs a
"left-to-right" Ada compiler?

> nor can it increment Sum by adding A()+B(). 

True; it must compute temp := Sum + A(), then Sum := temp + B(). What
difference does that make, in actual practice? How many compilers do
anything else?

Hmm. For scalars, if A and B happen to be in registers, and Sum in
ram, I can see compilers messing with the order. Can anyone confirm
that actually happens in real compilers? It's been a while since I
messed with gcc code generation.

> Well, these optimizations could be made possible if the compiler
> might prove that the result does not depend on the order. That could
> be quite difficult to formally define, especially regarding numeric
> exceptions and floating-point accuracy stuff. Even more difficult it
> would be check.

That is _precisely_ the point. Since it is difficult to formally
define and check the meaning of "does not depend on order", why do we
expect people to be able to do it? 

On the other hand, that's also why it's not likely such restrictions
will be added to the definition of "pure" functions in Ada.

> But finally, if all that could be achived, then the compiler will be
> capable to simply detect that different orders give different
> results, and threat it as an error. Much better than fixing an
> arbitrary order!

Why is that better? The goal is to have code that works (meaning
produces correct results :), on all compilers/platforms. If I only
have to prove that one evaluation order is correct, that is easier
than if I have to think about many evaluation orders.

> So the bottom line, IMO, 1 makes no sense.

But you haven't answered my question. Is there, in actual fact, any
compiler that actually does these optimizations?

> >Ada is supposed to be about clear, unsurprising code. Subtle order
> >issues are just that - "subtle". If the language _could_ make them a
> >non-issue, at very little cost, I think it _should_.
> 
> Right, the present situation is not good. But IMO the solution lies in
> introducing formally pure functions and imposing limitations on use of
> impure functions (and procedures with results) in expressions.

That's way more work than simply requiring left-to-right, and
therefore far less likely to happen.

-- 
-- Stephe

Re: In-Out Parameters for functions

[Stephen Leake]

"Robert I. Eachus" <rieachus@comcast.net> writes:

> <snip 10.2.1 (18)> 
> 
> Can't we just all agree that Hymen is not an Ada language expert and
> doesn't want to be?  

I don't think that is a fair characterization of Hymen's discussions.

> In this case, the rules of Ada are well thought out to allow any
> user, not the compiler to determine whether an "unnecessary"
> function call can be eliminated. Similarly, the language allows
> users to force syncronization points and orders of evaluation, when
> they are a necessary part of the algorithm being implemented.

Hymen is asking about the value of these rules _in practice_, and
attempting to discuss whether a slightly different set of rules might
be better for Ada.

In particular, are there any _actual compilers_ that take advantage of
the freedom given by 10.2.1 (18)?

> We have jokingly called for shooting a programmer who knowingly
> writes code that depends on order of evaluation and then--yes that
> is an Ada and then--doesn't document it or force the compiler to use
> the necessary order. Actually the correction applied would probably
> be education, warnings, bad reviews, and eventually firing the
> employee if nececssary.
> 
> For anyone who deliberately persists in such bad habits, if necessary
> could be within weeks. Emphasis on deliberately, but I have had to
> make that decision for programmers who persisted in other bad habits
> like bypassing the required check-in procedures for software. In that
> case, firing the programmer probably saved him from a lynch mob, as
> other programmmers kept finding their submissions being rejected due
> to his changes not passing the regression tests.

True. And appropriate for any bad habit.

But not relevant here. The question is "would a slightly different
rule be better for Ada". Not "what are the current rules of Ada".
Although it is true that some people in this discussion need
refreshers on that ...

> What do we do with Mr. Hymen Rosen? For now, I'm going to just post
> chapter and verse, and that Mr. Rosen's opinion on any Ada language
> issue should be ignored.

ok. 

-- 
-- Stephe

left-to-right (was In-Out Parameters for functions)

[Stephen Leake]

"Robert I. Eachus" <rieachus@comcast.net> writes:

> Hyman Rosen wrote:
> 
> > Preben Randhol wrote:
> >
> >> Only in the case that b is true is the evaluation of needed Sqrt
> >> (x) > 5.0 Or have I missed som point here?
> > Sqrt(x) may have side effects.
> 
> Totally irrelevant.  As I just posted what matters is whether or not
> Sqrt(x) is declared in a pure library unit.  In the case of the
> standard Sqrt, the standard also says:
> 
>     pragma Pure(Generic_Elementary_Functions);
> 
> So the compiler is free to eliminate calls to Sqrt if possible.

And that freedom would remain if Ada were changed to require
strict left-to-right order (just to bring this thread back to one of
it's main points :).

-- 
-- Stephe

Re: In-Out Parameters for functions

[Stephen Leake]

"Robert I. Eachus" <rieachus@comcast.net> writes:

> Hyman Rosen wrote:
> 
> > But Ada does not have that philosophy, so that cannot be the reason
> > to maintain the feature. When "+" is a user-defined subprogram, its
> > operands are always passed in the order written; a + b is always
> > invoked as "+"(a, b) and never as "+"(b, a).
> 
> Absolutely wrong.  

That's an odd thing to say! 

> If I or any other Ada programmer defines an abstract type Foo, and
> it makes sense to add Integers to Foo, and the semantics of addition
> are commutative, I will declare:
> 
> function "+"(L: Foo; R: Integer) return Foo is...

Let's call this function 1.

> function "+"(L: Integer; R: Foo) return Foo is begin return R+L; end
> "+";

and function 2.

Yes. and the reason you need to do this is that the Ada _language_
requires that 'a + b' _always_ be equivalent to "+" (a, b), not "+"
(b, a), as Hymen said!

To be more concrete:
declare
   a : Foo;
   b : Integer;
   c : integer;
   d : integer;
begin
   c := a + b; -- calls function 1
   d := b + a; -- calls function 2
end;

If Ada were allowed to use "+" (b, a) for 'a + b', you would not need
function 2 to compute d.

-- 
-- Stephe

left-to-right (was In-Out Parameters for functions)

[Stephen Leake]

"Robert I. Eachus" <rieachus@comcast.net> writes:

> Hyman Rosen wrote:
> 
> > Robert I. Eachus wrote:
> >
> >> Absolutely wrong. ... I will declare...
> > You are describing your programming practices.
> > Your practices do not necessarily represent the
> > philosophy of the language. In any case, when I
> > said that a + b becomes "+"(a, b) and not "+"(b, a)
> > I was not "absolutely wrong" but "absolutely right".
> 
> No, you were absolutely wrong as usual.  The order of evaluation of
> the parameters to "+" is undefined whether the "+" is user defined or
> language defined.  To quote 6.4(10): "These evaluations are done in an
> arbitrary order."  There is even an explicit footnote at 4.5(14) that
> explains that this applies to predefined operators as well as user
> defined operators.

"+" (a, b) vs "+ (b, a) is not about order of evaluation; it is about
association of parameters.

To be more clear, we should be saying:

'a + b' is equivalent to "+" (left => a, right => b);

it is never equivalent to "+" (left => b, right => a);

whether b or a gets evaluated first is an orthogonal question.

> I should stop wrestling with pigs. But I would like to preserve this
> newsgroup as a place where users can get reliable advice on language
> issues. So I have to keep putting up these placards that say ignore
> anything Hyman Rosen says about Ada language issues.

Hm. What I'm getting from your postings is that you are having a hard
time actually hearing what Hymen is saying. You keep responding to
different points, and now you are resorting to ad hominem attacks.

Misunderstandings are to be expected in newsgroups!

-- 
-- Stephe

Re: In-Out Parameters for functions

[Stephen Leake]

"Robert I. Eachus" <rieachus@comcast.net> writes:

> You can't but Randy posted a very good explanation of why his compiler
> does it in a different order.  And even at the risk of sounding like a
> broken record, the Ada standard say this will be done in "an arbitrary
> order."  

Hymen is trying to discuss a change to that Ada rule. Repeating what
the current Ada rules say is not helpful.

> If a user wants to, he can use other language rules (and code that
> makes it obvious that it is intentional) to force a particular
> evaluation order. But it is much harder to do that than to make the
> code agnostic about evaluation order, and that is intentional.

Ok. Some of us don't understand why it is harder; that would be a
useful thing to talk about.

-- 
-- Stephe

Re: In-Out Parameters for functions

[David Starner]

On Fri, 27 Feb 2004 00:21:25 -0500, Stephen Leake wrote:
> In particular, are there any _actual compilers_ that take advantage of
> the freedom given by 10.2.1 (18)?

Yes. In <103q25acc6knm97@corp.supernews.com>, in a reply to this same
comment of yours, Randy Brukardt pointed out that Janus/Ada will take
advantage of this, and why.

Re: left-to-right (was In-Out Parameters for functions)

[Dmitry A. Kazakov]

On 26 Feb 2004 23:58:22 -0500, Stephen Leake <Stephe.Leake@nasa.gov>
wrote:

>Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> writes:
>
>> On 24 Feb 2004 19:44:12 -0500, Stephen Leake <stephen_leake@acm.org>
>> wrote:
>> 
>> >I think Hyman has two valid points:
>> >
>> >1) if the language specified left-to-right order, there would never be
>> >   a need to "kill the original smart-ass programmer"
>> 
>> But also, if the language disallowed side-effects when there could be
>> more than one order. I prefer the second, provided that the term
>> "side-effect" should be formally defined by the language and visible
>> from the specifications.
>
>That's never going to happen!

Alas.

>> >2) Does anyone have a real example of a compiler taking advantage
>> >of the evaluation order freedom to speed up a program?
>> 
>> The question is what gets lost if an evaluation order is fixed. I gave
>> an example earlier:
>> 
>> for I in A'Range loop
>>    Sum := Sum + A (I) + B (B'First + I - A'First);
>>    ...
>> 
>> Here with left-to-right order the compiler cannot optimize neither the
>> array index of B, 
>
>What do you mean by "optimize" in this sentence? the array index of B
>is B'First + I - A'First. It must be computed before B(). In what way
>would this be done differently by a "real Ada" compiler vs a
>"left-to-right" Ada compiler?

A left-to-right compiler shall first evaluate B'First + I, then
decrement it by A'First.

What I would expect from a good compiler is factoring out the cycle
constant B'First - A'First and omitting all index checks for B when
A'Length = B'Length. I am not sure if that will be possible for a
strict left-to-right compiler without dealing with program semantics.

>> nor can it increment Sum by adding A()+B(). 
>
>True; it must compute temp := Sum + A(), then Sum := temp + B(). What
>difference does that make, in actual practice? How many compilers do
>anything else?
>
>Hmm. For scalars, if A and B happen to be in registers, and Sum in
>ram, I can see compilers messing with the order. Can anyone confirm
>that actually happens in real compilers? It's been a while since I
>messed with gcc code generation.

It is a pity that Robert Dewar isn't here.

>> Well, these optimizations could be made possible if the compiler
>> might prove that the result does not depend on the order. That could
>> be quite difficult to formally define, especially regarding numeric
>> exceptions and floating-point accuracy stuff. Even more difficult it
>> would be check.
>
>That is _precisely_ the point. Since it is difficult to formally
>define and check the meaning of "does not depend on order", why do we
>expect people to be able to do it? 

Exactly, they should not! People have to write programs so that they
would be valid for any allowed order. If they don't the code is
broken. In my view it is broken *even* if the language defined
implicit order is the one assumed by the programmer.

My point is: either 1) the order is specified explicitly by the
programmer, or 2) the code is valid for any order.

>On the other hand, that's also why it's not likely such restrictions
>will be added to the definition of "pure" functions in Ada.

There is no need to check program semantics very precisely. The
language may simply outlaw "pure" functions like:

X : Integer;
function Pure return Integer is
-- pragma Pure (Pure);
begin
   return X - X; -- Does not depend on X
end Pure;

>> But finally, if all that could be achived, then the compiler will be
>> capable to simply detect that different orders give different
>> results, and threat it as an error. Much better than fixing an
>> arbitrary order!
>
>Why is that better? The goal is to have code that works (meaning
>produces correct results :), on all compilers/platforms.

But the code has some semantics it implements, at least I hope it is
so (:-)). This semantics is either order-dependent or not. That does
not depend on platform. The goal is to implement that semantics. The
rest does Ada.

> If I only
>have to prove that one evaluation order is correct, that is easier
>than if I have to think about many evaluation orders.

True. Weaker the precondition, harder to write the code. It is quite
easy to write sqrt provided that the only valid value of the argument
is 0. Alas, that would be not what people understand under sqrt. From
software design point of view it is always worth to try to write
order-independent code, like one with a weakest precondition. The
opposite should be treated rather as an exception.

>> So the bottom line, IMO, 1 makes no sense.
>
>But you haven't answered my question. Is there, in actual fact, any
>compiler that actually does these optimizations?

Randy Brukardt gave one example. However I would like to stress that
optimization and implementation freedom is only one, though important
argument. Software design practice is no less important. Fixing order
not imposed by the semantics, and thus an arbitrary order, is that
sort of premature optimization Knuth wrote about. My concern is that
fixing an arbitrary order would bless bad software design in favor of
getting results now.

>> >Ada is supposed to be about clear, unsurprising code. Subtle order
>> >issues are just that - "subtle". If the language _could_ make them a
>> >non-issue, at very little cost, I think it _should_.
>> 
>> Right, the present situation is not good. But IMO the solution lies in
>> introducing formally pure functions and imposing limitations on use of
>> impure functions (and procedures with results) in expressions.
>
>That's way more work than simply requiring left-to-right, and
>therefore far less likely to happen.

AFAIK Ravescar profile would be a part of the standard. A time may
come when some SPARK ideas will be evaluated too.

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: left-to-right (was In-Out Parameters for functions)

[Stephen Leake]

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

> On 26 Feb 2004 23:58:22 -0500, Stephen Leake <Stephe.Leake@nasa.gov>
> wrote:
> 
> >Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> writes:
> >
> >> The question is what gets lost if an evaluation order is fixed. I gave
> >> an example earlier:
> >> 
> >> for I in A'Range loop
> >>    Sum := Sum + A (I) + B (B'First + I - A'First);
> >>    ...
> >> 
> >> Here with left-to-right order the compiler cannot optimize neither the
> >> array index of B, 
> >
> >What do you mean by "optimize" in this sentence? the array index of B
> >is B'First + I - A'First. It must be computed before B(). In what way
> >would this be done differently by a "real Ada" compiler vs a
> >"left-to-right" Ada compiler?
> 
> A left-to-right compiler shall first evaluate B'First + I, then
> decrement it by A'First.
> 
> What I would expect from a good compiler is factoring out the cycle
> constant B'First - A'First and omitting all index checks for B when
> A'Length = B'Length. I am not sure if that will be possible for a
> strict left-to-right compiler without dealing with program
> semantics.

Ok. That is a good example.

So, Hymen; we now have (at least) two good examples of optimizations
that are useful, but would not be possible if the language required
right-to-left parameter evaluation.

Do you agree the cost of changing is to right-to-left is not worth the
gain?

> <snip>
> It is a pity that Robert Dewar isn't here.

Yes!

> >> Well, these optimizations could be made possible if the compiler
> >> might prove that the result does not depend on the order. That
> >> could be quite difficult to formally define, especially regarding
> >> numeric exceptions and floating-point accuracy stuff. Even more
> >> difficult it would be check.
> >
> >That is _precisely_ the point. Since it is difficult to formally
> >define and check the meaning of "does not depend on order", why do we
> >expect people to be able to do it? 
> 
> Exactly, they should not! People have to write programs so that they
> would be valid for any allowed order. If they don't the code is
> broken. In my view it is broken *even* if the language defined
> implicit order is the one assumed by the programmer.
> 
> My point is: either 1) the order is specified explicitly by the
> programmer, or 2) the code is valid for any order.

Hmm. You missed my point. Let me try again.

You have made two statements:

1) "the programmer must ensure the code is valid for any order of
   evaluation".

2) "it is difficult to check if things do depend on order of
   evaluation"

The second is paraphrased, but I believe it captures what you said
above.

These statements seem at odds, to me. You are requiring the programmer
to do something that is difficult. 

> >> But finally, if all that could be achived, then the compiler will be
> >> capable to simply detect that different orders give different
> >> results, and threat it as an error. Much better than fixing an
> >> arbitrary order!
> >
> >Why is that better? The goal is to have code that works (meaning
> >produces correct results :), on all compilers/platforms.
> 
> But the code has some semantics it implements, at least I hope it is
> so (:-)). This semantics is either order-dependent or not. That does
> not depend on platform. The goal is to implement that semantics. The
> rest does Ada.

Right. And _if_ the semantics happens to be order-dependent, then to
be portable, the same order must be used on every compiler/platform.
That is not possible in Ada 95; it would be possible in "left-to-right
Ada 95".

> > If I only
> >have to prove that one evaluation order is correct, that is easier
> >than if I have to think about many evaluation orders.
> 
> True. Weaker the precondition, harder to write the code. It is quite
> easy to write sqrt provided that the only valid value of the argument
> is 0. Alas, that would be not what people understand under sqrt. From
> software design point of view it is always worth to try to write
> order-independent code, like one with a weakest precondition. The
> opposite should be treated rather as an exception.

You are assuming the consequence of this argument :).

The point is that (perhaps) it is _not_ always worth writing
order-independent code.

So we need to talk about why you believe this to be the case - we
cannot simply say "yes, you are right".

> >But you haven't answered my question. Is there, in actual fact, any
> >compiler that actually does these optimizations?
> 
> Randy Brukardt gave one example. However I would like to stress that
> optimization and implementation freedom is only one, though important
> argument. Software design practice is no less important. Fixing order
> not imposed by the semantics, and thus an arbitrary order, is that
> sort of premature optimization Knuth wrote about. My concern is that
> fixing an arbitrary order would bless bad software design in favor of
> getting results now.

But it is only bad _because_ it prevents optimization. At least, that
is the only argument I have heard so far. You do _not_ give a
different argument in this paragraph; you just repeat the optimization
one.

What _other_ reason is there?

Software design practices such as "write order-independent code" are
useful simplifications of complex arguments; they allow programmers to
get on with day-to-day work without spending lots of time thinking
about arcane compiler implementation issues :). 

However, in _this_ discussion, we are trying to elucidate the complex
argument behind this particular software design practice, in order to
decide if it is still valid.

> >> >Ada is supposed to be about clear, unsurprising code. Subtle order
> >> >issues are just that - "subtle". If the language _could_ make them a
> >> >non-issue, at very little cost, I think it _should_.
> >> 
> >> Right, the present situation is not good. But IMO the solution lies in
> >> introducing formally pure functions and imposing limitations on use of
> >> impure functions (and procedures with results) in expressions.
> >
> >That's way more work than simply requiring left-to-right, and
> >therefore far less likely to happen.
> 
> AFAIK Ravescar profile would be a part of the standard. 

Yes, the Ravenscar profile will (probably :) be standardized in Ada
0Y. But that will be as an restriction pragma, allowing users to
choose a subset of Ada.

> A time may come when some SPARK ideas will be evaluated too.

If you mean that the SPARK language will be added as another optional
Ada standard, I doubt it. SPARK may become a standard on its own.

-- 
-- Stephe

Re: left-to-right (was In-Out Parameters for functions)

[Preben Randhol]

On 2004-02-27, Stephen Leake <Stephe.Leake@nasa.gov> wrote:
> These statements seem at odds, to me. You are requiring the programmer
> to do something that is difficult. 

Isn't that the C-way?

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

Re: left-to-right (was In-Out Parameters for functions)

[Hyman Rosen]

Stephen Leake wrote:
> Ok. That is a good example.
> 
> So, Hymen; we now have (at least) two good examples of optimizations
> that are useful, but would not be possible if the language required
> right-to-left parameter evaluation.
> 
> Do you agree the cost of changing is to right-to-left is not worth the
> gain?

That's "Hyman". I don't think the array index case is a good
counterexample; compilers are now very good at dealing with
loop induction variables, and I doubt that generated code for
this would be affected by l-to-r. RB's case was better.

Whether such cases are sufficient is a matter of judgement,
but the existence of a good optimization example means that
l-to-r will never be adopted (not that there was a chance
anyway).

Re: left-to-right (was In-Out Parameters for functions)

[Dmitry A. Kazakov]

On 27 Feb 2004 09:07:12 -0500, Stephen Leake <Stephe.Leake@nasa.gov>
wrote:

>Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> writes:
>
>> Exactly, they should not! People have to write programs so that they
>> would be valid for any allowed order. If they don't the code is
>> broken. In my view it is broken *even* if the language defined
>> implicit order is the one assumed by the programmer.
>> 
>> My point is: either 1) the order is specified explicitly by the
>> programmer, or 2) the code is valid for any order.
>
>Hmm. You missed my point. Let me try again.
>
>You have made two statements:
>
>1) "the programmer must ensure the code is valid for any order of
>   evaluation".
>
>2) "it is difficult to check if things do depend on order of
>   evaluation"
>
>The second is paraphrased, but I believe it captures what you said
>above.
>
>These statements seem at odds, to me. You are requiring the programmer
>to do something that is difficult. 

It is like constructive vs. existence proof. (:-)) The programmer need
not to check things, because he a priory knows what they are. This
knowledge comes from the application domain. If he does not have it,
he should better search for other occupation. But the compiler knows
nothing, so it should check, not assume as Hyman Rosen proposes.

>> >> But finally, if all that could be achived, then the compiler will be
>> >> capable to simply detect that different orders give different
>> >> results, and threat it as an error. Much better than fixing an
>> >> arbitrary order!
>> >
>> >Why is that better? The goal is to have code that works (meaning
>> >produces correct results :), on all compilers/platforms.
>> 
>> But the code has some semantics it implements, at least I hope it is
>> so (:-)). This semantics is either order-dependent or not. That does
>> not depend on platform. The goal is to implement that semantics. The
>> rest does Ada.
>
>Right. And _if_ the semantics happens to be order-dependent, then to
>be portable, the same order must be used on every compiler/platform.

Then the semantics has to be *explicitly* expressed in the code, as an
important part of implementation. The code reader should clearly see
it, and say, aha!

>That is not possible in Ada 95; it would be possible in "left-to-right
>Ada 95".
>
>> > If I only
>> >have to prove that one evaluation order is correct, that is easier
>> >than if I have to think about many evaluation orders.
>> 
>> True. Weaker the precondition, harder to write the code. It is quite
>> easy to write sqrt provided that the only valid value of the argument
>> is 0. Alas, that would be not what people understand under sqrt. From
>> software design point of view it is always worth to try to write
>> order-independent code, like one with a weakest precondition. The
>> opposite should be treated rather as an exception.
>
>You are assuming the consequence of this argument :).
>
>The point is that (perhaps) it is _not_ always worth writing
>order-independent code.

Of course, in all cases when the semantics is order-dependent. 

>So we need to talk about why you believe this to be the case - we
>cannot simply say "yes, you are right".

We cannot, because it would mean that there are no cases where the
semantics is order-independent.

>> >But you haven't answered my question. Is there, in actual fact, any
>> >compiler that actually does these optimizations?
>> 
>> Randy Brukardt gave one example. However I would like to stress that
>> optimization and implementation freedom is only one, though important
>> argument. Software design practice is no less important. Fixing order
>> not imposed by the semantics, and thus an arbitrary order, is that
>> sort of premature optimization Knuth wrote about. My concern is that
>> fixing an arbitrary order would bless bad software design in favor of
>> getting results now.
>
>But it is only bad _because_ it prevents optimization. At least, that
>is the only argument I have heard so far. You do _not_ give a
>different argument in this paragraph; you just repeat the optimization
>one.
>
>What _other_ reason is there?

Occam's razor priciple - to have code valid under possibly least
strong assumtions. Weaker they are, higher is the code quality.

>Software design practices such as "write order-independent code" are
>useful simplifications of complex arguments; they allow programmers to
>get on with day-to-day work without spending lots of time thinking
>about arcane compiler implementation issues :). 

Yep, that is what I am afraid of! (:-))

>However, in _this_ discussion, we are trying to elucidate the complex
>argument behind this particular software design practice, in order to
>decide if it is still valid.
>
>> >> >Ada is supposed to be about clear, unsurprising code. Subtle order
>> >> >issues are just that - "subtle". If the language _could_ make them a
>> >> >non-issue, at very little cost, I think it _should_.
>> >> 
>> >> Right, the present situation is not good. But IMO the solution lies in
>> >> introducing formally pure functions and imposing limitations on use of
>> >> impure functions (and procedures with results) in expressions.
>> >
>> >That's way more work than simply requiring left-to-right, and
>> >therefore far less likely to happen.
>> 
>> AFAIK Ravescar profile would be a part of the standard. 
>
>Yes, the Ravenscar profile will (probably :) be standardized in Ada
>0Y. But that will be as an restriction pragma, allowing users to
>choose a subset of Ada.

Like one with pure functions...

>> A time may come when some SPARK ideas will be evaluated too.
>
>If you mean that the SPARK language will be added as another optional
>Ada standard, I doubt it. SPARK may become a standard on its own.

I meant measures to make more things statically checkable. SPARK is
one possible of many ways. In many cases it is too restrictive. So
probably one should have many levels of restrictions.

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: left-to-right (was In-Out Parameters for functions)

[Hyman Rosen]

Stephen Leake wrote:
 > and now you are resorting to ad hominem attacks.

Let me defend him - he's misquoting Heinlein that trying
to teach a pig to sing wastes your time and annoys the pig.
I don't think he was attacking me personally, he just thinks
I'm never going to "get it" about Ada.

Re: left-to-right (was In-Out Parameters for functions)

[Alexandre E. Kopilovitch]

Dmitry A. Kazakov wrote:

> Randy Brukardt gave one example. However I would like to stress that
> optimization and implementation freedom is only one, though important
> argument. Software design practice is no less important. Fixing order
> not imposed by the semantics, and thus an arbitrary order, is that
> sort of premature optimization Knuth wrote about. My concern is that
> fixing an arbitrary order would bless bad software design in favor of
> getting results now.

As this concern of yours is somehow imprecise and vague, it will probably
be hated by those software sergeants (and I think we have at least one here),
who need definite rules for thinking and conclusive (or compelling) arguments
always and everywhere.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Randy Brukardt]

"Vinzent 'Gadget' Hoefler" <nntp-2004-02@t-domaingrabbing.de> wrote in
message news:t9fr30tnl8rh0ain01qeqq17ottovqdso3@jellix.jlfencey.com...
...
> So it might be possible that in the parsing/compiling process the
> order specified in the named notation simply gets reordered to the
> order of how the parameters are declared.

Right. That's exactly what Janus/Ada does internally for named notation, and
the arguments are evaluated in the order that they get passed; no matter
what order they were passed in.

> IMO, it is easier to just not rely on side-effects. No side-effects, no
problems.

Which was the basic idea behind Pure - a way to declare that functions have
no meaningful side effects. (Caching values and records calls in a
scratchpad aren't meaningful). It's unfortunate that applying the "Pure"
categorization is so difficult. GNAT provides a solution here - pragma
Pure_Function - which essentially declares to the compiler that the function
has no meaningful side effects without any checks. (This pragma is being
considered for Ada 200Y.) One could imagine a coding standard which required
all functions used in non-trivial expressions (that is, not used alone) to
be marked either Pure or Pure_Function.

                    Randy.

Re: left-to-right (was In-Out Parameters for functions)

[Randy Brukardt]

"Stephen Leake" <Stephe.Leake@nasa.gov> wrote in message
news:mailman.25.1077857933.327.comp.lang.ada@ada-france.org...
> Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> writes:
> > Right, the present situation is not good. But IMO the solution lies in
> > introducing formally pure functions and imposing limitations on use of
> > impure functions (and procedures with results) in expressions.
>
> That's way more work than simply requiring left-to-right, and
> therefore far less likely to happen.

I don't think we could allow the incompatibilities that would occur from
banning side-effects in expressions. But a compiler could give a warning if
it found such an expression or potentially such an expression (function
calls to functions that aren't Pure or Pure_Function). That wouldn't be
incompatible, and it would have the effect of detecting the problem when it
happens.

That seems like the most appropriate solution at this point. It's very
similar to the way compilers warn about uses of uninitialized variables
(another place where Ada chose the "unsafe" option for pragmatic reasons).
One could imagine a compiler switch that turned these warnings into errors,
so that at least disiplined developers could avoid problems. (GNAT can do
this for some warnings, I know.)

                      Randy.

Re: left-to-right (was In-Out Parameters for functions)

[Stephen Leake]

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

> On 27 Feb 2004 09:07:12 -0500, Stephen Leake <Stephe.Leake@nasa.gov>
> wrote:
> 
> >You have made two statements:
> >
> >1) "the programmer must ensure the code is valid for any order of
> >   evaluation".
> >
> >2) "it is difficult to check if things do depend on order of
> >   evaluation"
> >
> >The second is paraphrased, but I believe it captures what you said
> >above.
> >
> >These statements seem at odds, to me. You are requiring the programmer
> >to do something that is difficult. 
> 
> It is like constructive vs. existence proof. (:-)) The programmer need
> not to check things, because he a priory knows what they are. This
> knowledge comes from the application domain. If he does not have it,
> he should better search for other occupation. But the compiler knows
> nothing, so it should check, not assume as Hyman Rosen proposes.

Ok, that makes sense. But _this_ programmer would appreciate some help
from the language. But I guess that's really the domain of SPARK, not
Ada. 

> >> >Why is that better? The goal is to have code that works (meaning
> >> >produces correct results :), on all compilers/platforms.
> >> 
> >> But the code has some semantics it implements, at least I hope it is
> >> so (:-)). This semantics is either order-dependent or not. That does
> >> not depend on platform. The goal is to implement that semantics. The
> >> rest does Ada.
> >
> >Right. And _if_ the semantics happens to be order-dependent, then to
> >be portable, the same order must be used on every compiler/platform.
> 
> Then the semantics has to be *explicitly* expressed in the code, as an
> important part of implementation. The code reader should clearly see
> it, and say, aha!

Yes! the code should certainly express the desired semantics!

I'm not clear what your point here is.

> >So we need to talk about why you believe this to be the case - we
> >cannot simply say "yes, you are right".
> 
> We cannot, because it would mean that there are no cases where the
> semantics is order-independent.

Why is that a problem?

Matrix multiply semantics is order-dependent (not evaluation order,
but multiply order). Again, I'm not getting your point.

> >> >But you haven't answered my question. Is there, in actual fact, any
> >> >compiler that actually does these optimizations?
> >> 
> >> Randy Brukardt gave one example. However I would like to stress that
> >> optimization and implementation freedom is only one, though important
> >> argument. Software design practice is no less important. Fixing order
> >> not imposed by the semantics, and thus an arbitrary order, is that
> >> sort of premature optimization Knuth wrote about. My concern is that
> >> fixing an arbitrary order would bless bad software design in favor of
> >> getting results now.
> >
> >But it is only bad _because_ it prevents optimization. At least, that
> >is the only argument I have heard so far. You do _not_ give a
> >different argument in this paragraph; you just repeat the optimization
> >one.
> >
> >What _other_ reason is there?
> 
> Occam's razor priciple - to have code valid under possibly least
> strong assumtions. Weaker they are, higher is the code quality.

Then we should all be using SPARK. There is a trade off to be made;
readability vs portability vs efficiency. Ada 95 made one choice for
the trade off; we are discussing other possible choices.

-- 
-- Stephe

Re: left-to-right (was In-Out Parameters for functions)

[Robert I. Eachus]

Stephen Leake wrote:

> But you haven't answered my question. Is there, in actual fact, any
> compiler that actually does these optimizations?

Sure, lots of them, but that is not really the interesting question. 
The interesting experiment is to find a way to turn off just the 
optimizations that take advantage of the reordering freedoms, then see 
what effect it has on the performance of the compiled code on some set 
of benchmarks.

It might take hacking source to be sure of doing exactly that in GNAT, 
but you can probably bound the benefit using current optimization switches.

Of course, the real interesting part of the project would be to run the 
suite on different hardware architectures and see how much of an effect 
it has on modern CPU architectures compared to say a Pentium or 80486 
without superscalar and OoO support in the CPU.

It would probably make a good senior project for some undergraduate, and 
if the results showed that the effect of such optimizations on 
superscalar out-of-order CPUs it might make a Master's or PhD thesis. 
In any case it should result in a couple of papers.

Why do I suggest this as an academic project?  Well years go the same 
sort of thing was done by hardware and language architects both in 
academia and in industry.  The conclusion AT THAT TIME, was that the 
freedom to reorder, and the compiler code to take advantage of it, was 
very worthwhile.  With OoO superscaler machines, it is not clear that 
there would be any advantage to requiring "more predictable" semantics 
in programming languages given what happens during execution.  But it 
could be that the "optimization freedoms" don't buy much in the way of 
performance anymore.

-- 
                                           Robert I. Eachus


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

Re: In-Out Parameters for functions

[Robert I. Eachus]

Jean-Pierre Rosen wrote:

> "Robert I. Eachus" <rieachus@comcast.net> a �crit dans le message de news:-tednUSWDcMxbqDdRVn-sw@comcast.com...
> 
>>What do we do with Mr. Hymen Rosen?  For now, I'm going to just post
>>chapter and verse, and that Mr. Rosen's opinion on any Ada language
>>issue should be ignored.

> Please always use qualified notation (with the first-name). Otherwise, a partial quotation of the above would overload several
> people :-)

Good point, I explicitly qualified the first reference for just that 
reason--that the paragraph might be quoted out of context.  I probably 
should have either used "his" or a full name for the second reference as 
well.

As you well know, of course, it is very hard to write something that 
doesn't sound stilted, and still stands up to hostile (mis-)interpretation.

-- 
                                           Robert I. Eachus

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

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> Robert I. Eachus wrote:
> 
>> Hyman Rosen wrote:
>>
>>> In any case, when I
>>> said that a + b becomes "+"(a, b) and not "+"(b, a)
>>> I was not "absolutely wrong" but "absolutely right".
>>
>>
>> No, you were absolutely wrong as usual.  The order of evaluation of 
>> the parameters to "+" is undefined whether the "+" is user defined or 
>> language defined.
> 
> 
> Where did I say that the order of evaluation of the operands was
> defined? V'G'H argued that the philosophy of Ada was that a + b
> and b + a are the same. I pointed out that for user-defined "+",
> when you write a + b, the function is called with a as the Left
> operand and b as the Right, never the reverse.
> 
>  > I should stop wrestling with pigs.
> 
> You are so eager to believe I am wrong about everything I say that
> you are not reading what I say. Stop it. You're just going to annoy
> the pig :-)

No, it is trying to teach a pig to sing that annoys the pig.  When you 
wrestle with pigs, you just get dirty, and the pig enjoys it.  (Of 
course, if the pig is a pet and kept clean, the person doing the 
wrestling may stay clean and actually want the pig to enjoy it.)  But 
this is not a discussion of ENGLISH semantics ;-)

MY point, which apparently you missed, was not that Ada compilers are 
allowed to ignore the order of parameters (except of course with named 
notation). It is that you will find lots of places in the standard where 
order independent SEMANTICS occurs, for example in 13.7.1(7).  In those 
cases the usual implementation (in this case of package 
System.Storage_Elements) will simplify things by using parameter 
flipping and pragma Inline.  If we were to change the semantics of Ada 
to require left-to-right evaluation, what should be done with these 
functions, especially when they are in-lined?  A workable rule probably 
could be written, but it is the sort of thing you have to look at with a 
proposal like yours.

-- 
                                           Robert I. Eachus

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

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> But unlike such things as array index violations, Ada isn't
> required to tell you that your code is not agnostic about
> evaluation order, and therefore such violations can lurk
> undetected.

No matter how hard we try, it is not always possible for a compiler to 
read the programmer's mind.  So there will always be bugs that exist 
only in the author's mind.  If I write:

X := X + 10;

But I actually intended to decrement X, the compiler can't catch that. 
In fact on some other day, I might write identical code and expect X to 
be incremented.  (In fact what probably happened was that I did a sloppy 
cut-and-paste, but ignore that for now.)

Compilers can notice suspicious code, and warn the author.  For example, 
if I had written:

X := X + 0;

A good compiler might warn me that the assignment statement resulted in 
no code being generated, and that might lead me to find MY bug.  But 
bugs are always a matter of definition.  That is why I like the style of 
programming where I start with a list of requirements, and the code is 
expected to implement those requirements exactly.  That way the judgment 
of whether or not something is a bug is objective, not personal. 
(Doesn't stop me from considering "poorly formatted output" to be a 
valid bug report.)

-- 
                                           Robert I. Eachus

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

Re: In-Out Parameters for functions

[Robert I. Eachus]

I said:
>>If a user wants to, he can use other language rules (and code that
>>makes it obvious that it is intentional) to force a particular
>>evaluation order. But it is much harder to do that than to make the
>>code agnostic about evaluation order, and that is intentional.

Stephen Leake wrote:

> Ok. Some of us don't understand why it is harder; that would be a
> useful thing to talk about.

I am probably not the best one to ask about it, since believe it or not, 
  one of my personal fights during the Ada 9X development process was 
that it should be POSSIBLE to force an evaluation order.

But I'll give it a try.  In modern CPUs synchronization calls that allow 
"precise" interrupts are very expensive, in an execution time sense of 
course. In Ada, this means that requiring variables to have specific 
values when Constraint_Error is raised.  Or for that matter when any 
predefined exception is raised.  But in practice the interesting cases 
are for Constraint_Error.

If there is a specified order, then someone can write a test that raises 
  Constraint_Error in "interesting" places, and looks at the values of 
variables in the handler.  In Ada 83, there was a huge, nasty AI, 
AI-315, that looked at this issue and RM 11.6 in general.  (Notice that 
section 11.6 Exceptions and Optimization in the Ada 83 manual 
corresponds to 11.6 in Ada 95. This was very intentional.)

The debate over what to do about this "problem" in Ada 83 was never 
resolved.  In theory, the freedoms granted in (Ada 83) 11.6 could be 
used to make  almost any program do anything.  But in practice there 
were some very strict rules that made it almost impossible for compilers 
to "take advantage" of these freedoms.

The tension was that the compiler vendors wanted to get rid of some of 
the more onerous requirements.  But those who wrote programs which 
needed to raise (and handle) Constraint_Error were of course concerned 
that Constraint_Error not turn into something where any attempt to 
handle Constraint_Error could cause the hard drive to be overwritten.

The current solution as far as I am concerned goes a little too far in 
the direction of allowing optimizations at the expense of making 
exception handlers more difficult to write.  In fact, you sometimes have 
to insert a call to an independent subprogram just to guarantee the 
necessary semantics. "An independent subprogram is one that is defined 
outside the library unit containing the construct whose check failed, 
and has no Inline pragma applied to it. Any assignment that occurred 
outside of such abort-deferred operations or independent subprograms can 
be disrupted by the raising of the exception, causing the object or its 
parts to become abnormal, and certain subsequent uses of the object to 
be erroneous, as explained in 13.9.1." (RM 11.6(6) where else?)

As far as programs that don't have to deal with Constraint_Error 
handlers are concerned though, the situation is much better.  If you 
split a complex expression into a series of assignment statements, the 
order of evaluation is not guaranteed, but you do get "as if" semantics. 
  (Again, absent Constraint_Error being raised.)

-- 
                                           Robert I. Eachus

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

Re: In-Out Parameters for functions

[Hyman Rosen]

Robert I. Eachus wrote:
>  It is that you will find lots of places in the standard where
> order independent SEMANTICS occurs, for example in 13.7.1(7).  In those 
> cases the usual implementation (in this case of package 
> System.Storage_Elements) will simplify things by using parameter 
> flipping and pragma Inline.  If we were to change the semantics of Ada 
> to require left-to-right evaluation, what should be done with these 
> functions, especially when they are in-lined?  A workable rule probably 
> could be written, but it is the sort of thing you have to look at with a 
> proposal like yours.

The section to which you refer defines a pair of "+" operations.
I don't see how they cause any issues for l-to-r. And pragma Inline
does not affect the semantics of a program, so again I don't see what
the relevance is. I do agree that there seem to be unholy complexities
lurking in the trade-offs between checking requirements and allowing
optimization which could be exacerbated by requiring l-to-r.

Re: left-to-right (was In-Out Parameters for functions)

[Stephen Leake]

"Robert I. Eachus" <rieachus@comcast.net> writes:

> Stephen Leake wrote:
> 
> > But you haven't answered my question. Is there, in actual fact, any
> > compiler that actually does these optimizations?
> 
> Sure, lots of them, but that is not really the interesting question.

Well, it was interesting to _me_, because I didn't know the answer. I
suspect any question to which you know the answer is "uninteresting"
:). 

> The interesting experiment is to find a way to turn off just the
> optimizations that take advantage of the reordering freedoms, then
> see what effect it has on the performance of the compiled code on
> some set of benchmarks.

Yes. Maybe one of your students will take up the challenge?

> <snip> Well years go the same
> sort of thing was done by hardware and language architects both in
> academia and in industry.  The conclusion AT THAT TIME, was that the
> freedom to reorder, and the compiler code to take advantage of it, was
> very worthwhile.  

Ok. That explains Ada's choice.

> With OoO superscaler machines, it is not clear that there would be
> any advantage to requiring "more predictable" semantics in
> programming languages given what happens during execution. But it
> could be that the "optimization freedoms" don't buy much in the way
> of performance anymore.

Right. Until someone does that, we cannot fairly evaluate the issue of
whether changing to requiring left-to-right parameter evaluation would
gain more than it loses.

But I'm satisfied for now that it is not worth it. 

-- 
-- Stephe

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> The section to which you refer defines a pair of "+" operations.
> I don't see how they cause any issues for l-to-r. And pragma Inline
> does not affect the semantics of a program, so again I don't see what
> the relevance is. I do agree that there seem to be unholy complexities
> lurking in the trade-offs between checking requirements and allowing
> optimization which could be exacerbated by requiring l-to-r.

You are getting there.  Bob Mathis once told me a Lisp joke:

(defun twiddle-thumbs thumb1 thumb2 (twiddle-thumbs thumb2 thumb1))

That really sums up the issue I was bringing up. The second function in 
that particular pair of functions is probably defined by:

  function "+"(Left : Storage_Offset; Right : Address) return Address is
  begin return Right + Left; end "+";
  -- with pragma Inline in the spec.

Now, when do you apply your left-to-right requirement, before or after 
the pragma Inline has been applied?  Since the pragma Inline probably 
applies to both calls, I guess the answer has to be before the inlining.

Thinking some more about your proposal, now that I have looked at it 
from all sides, a much more modest version  seems reasonable: If an 
expression contains two non-pure, non-predefined functions they must be 
evaluated in canonical order instead of "some order."  This would allow 
compilers to do all their code motion in most cases, and only 
expressions with two or more impure function calls would need to switch 
off some of those optimizations.  You could probably modify GNAT to 
check the effects of that rule change out if you wanted to.  (Or ask 
your compiler vendor to put in a switch--the result of turning on the 
switch would still be a legal implementation of Ada.  Not that there is 
a requirement that compiler switches work that way.)

Personally, as I said, I have written code that has to handle 
Constraint_Error in some cases, and reraise it in others.  In those 
cases, for Ada 95, I not only have to break some expressions into two 
parts, but insure that the parts are covered by different exception 
handlers--in different packages.  It is a pain to get that code right 
according to the (current) Ada 95/2000 rules, but I don't think your 
change would help.  It is the permission in the last sentence of 11.6(6) 
that is the real issue.

-- 
                                           Robert I. Eachus

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

Re: In-Out Parameters for functions

[Jon S. Anthony]

"Robert I. Eachus" <rieachus@comcast.net> writes:

> Hyman Rosen wrote:
> 
> > The section to which you refer defines a pair of "+" operations.
> > I don't see how they cause any issues for l-to-r. And pragma Inline
> > does not affect the semantics of a program, so again I don't see what
> > the relevance is. I do agree that there seem to be unholy complexities
> > lurking in the trade-offs between checking requirements and allowing
> > optimization which could be exacerbated by requiring l-to-r.
> 
> You are getting there.  Bob Mathis once told me a Lisp joke:
> 
> (defun twiddle-thumbs thumb1 thumb2 (twiddle-thumbs thumb2 thumb1))

???  This is ill formed Common Lisp.  Presumably you mean:

(defun twiddle-thumbs (thumb1 thumb2)
  (twiddle-thumbs thumb2 thumb1))

Which if called, say by:

...
  (twiddle-thumbs l-thumb r-thumb)
...

will produce an infinite loop (and thus the "joke" part).

BTW, Lisp _does_ require l-to-r argument evaluation in calls.


> That really sums up the issue I was bringing up. The second function
> in that particular pair of functions is probably defined by:

I'm fairly sure you are referring to the pair of functions mentioned
in HR's comment, but just so no one else gets confused: There is only
one function in the Lisp given, not two.


>   function "+"(Left : Storage_Offset; Right : Address) return Address is
>   begin return Right + Left; end "+";
>   -- with pragma Inline in the spec.
> 
> Now, when do you apply your left-to-right requirement, before or after
> the pragma Inline has been applied?  Since the pragma Inline probably
> applies to both calls, I guess the answer has to be before the
> inlining.

It's irrelevant as you (the compiler writer) simply arrange to have
the arguments evaluated in the correct order and then passed.  Here is
an implementation of such a pair (in Lisp, since you can do this sort
of stuff at the user/programmer level):

(defmacro +one (l r)
  `(+ ,l ,r))

(defmacro +two (l r)
  (with-gensyms (ul ur)
    `(let ((,ul ,l) ; evaluate l
	   (,ur ,r)); evaluate r
       (+one ,ur ,ul))))


This is semantically (at compilation level semantics) the same as:

(defun +one (l r)
  (+ l r))

(defun +two (l r)
  (+one r l))

(declaim (inline +one +two))


What gets generated at a call in some code:

(macroexpand-1 '(+one (sqrt 8) (expt 2 32)))
   ==> (+ (sqrt 8) (expt 2 32))

(macroexpand-1 '(+two (sqrt 8) (expt 2 32)))
   ==>
(LET ((#:G87115 (SQRT 8)) (#:G87116 (EXPT 2 32)))
  (+ONE #:G87116 #:G87115))

(macroexpand '(+two (sqrt 8) (expt 2 32))) ; Fully expand
   ==>
(LET ((#:G87135 (SQRT 8)) (#:G87136 (EXPT 2 32)))
  (+ #:G87136 #:G87135))


(+two (sqrt 8) (expt 2 32))
   ==> 4.2949673e+9


So, arguments to both are always evaluated in the correct order, even
though one compiles directly inline to a call of the other which is
also compiled inline.  No big deal.



/Jon

Re: left-to-right (was In-Out Parameters for functions)

[Dmitry A. Kazakov]

On 28 Feb 2004 08:22:20 -0500, Stephen Leake <Stephe.Leake@nasa.gov>
wrote:

>Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> writes:
>
>> On 27 Feb 2004 09:07:12 -0500, Stephen Leake <Stephe.Leake@nasa.gov>
>> wrote:
>> 
>> >> >Why is that better? The goal is to have code that works (meaning
>> >> >produces correct results :), on all compilers/platforms.
>> >> 
>> >> But the code has some semantics it implements, at least I hope it is
>> >> so (:-)). This semantics is either order-dependent or not. That does
>> >> not depend on platform. The goal is to implement that semantics. The
>> >> rest does Ada.
>> >
>> >Right. And _if_ the semantics happens to be order-dependent, then to
>> >be portable, the same order must be used on every compiler/platform.
>> 
>> Then the semantics has to be *explicitly* expressed in the code, as an
>> important part of implementation. The code reader should clearly see
>> it, and say, aha!
>
>Yes! the code should certainly express the desired semantics!
>
>I'm not clear what your point here is.

Expression notation was designed to resemble the mathematical one,
which has no evaluation order. A sequential order in a formula is a
rare exception. The left-to-right sequential order is an exception of
exception. If we want to define an order, then we should use a
notation that clearly indicates the order. An infix notation does not.
To pretend that it does would be misleading.

>> >So we need to talk about why you believe this to be the case - we
>> >cannot simply say "yes, you are right".
>> 
>> We cannot, because it would mean that there are no cases where the
>> semantics is order-independent.
>
>Why is that a problem?
>
>Matrix multiply semantics is order-dependent (not evaluation order,
>but multiply order).

You mean that matrix multiplication is not commutative (A*B /= B*A)?,
because it is associative: A*(B*C) = (A*B)*C.

> Again, I'm not getting your point.

When I see A*B*C in a program I do expect that "*" is a multiplicative
operation. Further I expect that operands evaluation order is
irrelevant, because the notation tells nothing about it, and I really
do not want ARM to specify it. It would break the abstraction. Should
I really know whether A is a function, reference or a register? Isn't
dereferencing A an evaluation? Should that also be made left-to-right?
Are cache effects relevant? Should ARM define them?

>> Occam's razor priciple - to have code valid under possibly least
>> strong assumtions. Weaker they are, higher is the code quality.
>
>Then we should all be using SPARK.

I do not think so. SPARK limits many things to gain checkability. This
actually also violates the principle of least strong assumtion, as
left-to-right order would do. The difference is that SPARK gives a
valuable gain - checkability. I feel that left-to-right order rather
makes error detection harder, by making broken code working. Maybe it
would appropriate to remember PL/1 lessons here. They also tried to
specify a conversion in all possible cases. Made it PL/1 more
portable, readable?

>There is a trade off to be made;
>readability vs portability vs efficiency. Ada 95 made one choice for
>the trade off; we are discussing other possible choices.

I hope that it can be reconciled by wider using DbC. If a user-defined
operation has an interesting side-effect, that should be specified in
the contract and later checked in all cases where the side-effect is
used.

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: left-to-right (was In-Out Parameters for functions)

[Dmitry A. Kazakov]

On Fri, 27 Feb 2004 21:29:54 +0300 (MSK), "Alexandre E. Kopilovitch"
<aek@VB1162.spb.edu> wrote:

>Dmitry A. Kazakov wrote:
>
>> Randy Brukardt gave one example. However I would like to stress that
>> optimization and implementation freedom is only one, though important
>> argument. Software design practice is no less important. Fixing order
>> not imposed by the semantics, and thus an arbitrary order, is that
>> sort of premature optimization Knuth wrote about. My concern is that
>> fixing an arbitrary order would bless bad software design in favor of
>> getting results now.
>
>As this concern of yours is somehow imprecise and vague, it will probably
>be hated by those software sergeants (and I think we have at least one here),
>who need definite rules for thinking and conclusive (or compelling) arguments
>always and everywhere.

If somebody does not like vagueness of philosophy, we could try to
turn to rigour of mathematics. However, you know what will be said
then! (:-))

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: In-Out Parameters for functions

[Hyman Rosen]

Robert I. Eachus wrote:
> Now, when do you apply your left-to-right requirement, before or after 
> the pragma Inline has been applied?

Pragma Inline is not exactly "applied". It is a hint to the compiler
that it would be advantageous for certain code to be expanded inline
as opposed to being called through the "normal" subprogram mechanism.
It does not have any effect on the meaning of Ada code which uses such
a subprogram, and therefore would not have any meaning when considering
l-to-r behavior.

> If an expression contains two non-pure, non-predefined functions they
 > must be evaluated in canonical order instead of "some order."

This gets you most of the way there. It would still leave pathological
cases like (I + Inc(I)) unspecified, but I can't imagine that there's
any real code out there which cares.

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> Pragma Inline is not exactly "applied". It is a hint to the compiler
> that it would be advantageous for certain code to be expanded inline
> as opposed to being called through the "normal" subprogram mechanism.
> It does not have any effect on the meaning of Ada code which uses such
> a subprogram, and therefore would not have any meaning when considering
> l-to-r behavior.

There you go again.  What you say seems to make sense, but it is not 
correct.  To quote from 11.6(6):  "An independent subprogram is one that 
is defined outside the library unit containing the construct whose check 
failed, and has no Inline pragma applied to it."

So although whether the compiler does follow the advice of a pragma 
Inline, it has semantic effects.  Those effects happen to be important 
in this particular case.  The appearance of an independent subprogram 
prevents the compiler from doing some reorderings.  Put in the pragma 
Inline, and the code might not be inlined by the compiler, but the 
compiler could move other code from before to after it or vice-versa.


-- 
                                           Robert I. Eachus

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

Re: In-Out Parameters for functions

[Hyman Rosen]

Robert I. Eachus wrote:
> So although whether the compiler does follow the advice of a pragma 
> Inline, it has semantic effects.

The same section says
     "The permissions granted by this clause can have an effect on the
      semantics of a program only if the program fails a language-defined
      check."

So unless you're coding in a way where you expect to cause and catch
l-d checks, it won't matter.

Also, if I read that section correctly, in a sequence of code like this
     a := 0;
     b := c + d;
     e := f + g;
     h := i + j;
     a := 1 / a;
it is possible that only the assignment to a will have occurred when the
exception handler from the division by zero is executed, is that correct?
Doesn't that make catching failures of language-defined checks useless?
You will know that something bad happened, but you won't know which objects
in your program are abnormal.

Re: In-Out Parameters for functions

[Jacob Sparre Andersen]

Hyman Rosen wrote:

> So unless you're coding in a way where you expect to cause and catch
> l-d checks, it won't matter.

Yes (assuming your functions haven't got side effects).

> Also, if I read that section correctly, in a sequence of code like
> this
>      a := 0;
>      b := c + d;
>      e := f + g;
>      h := i + j;
>      a := 1 / a;
> it is possible that only the assignment to a will have occurred when
> the exception handler from the division by zero is executed, is that
> correct?

I _think_ (haven't got the ARM around right now) that in case the
object b, e and h aren't accessible/used after the exception has been
raised, you are correct that the only thing that actually happens in
the following statements is that an exception is raised by the
division by zero.  This view is based on the principle of �same
external effect�.

If b, e or h on the other hand is accessible/used after the exception
has been raised, then the (or some of the) three intermediate
statements have to be executed as well to give the same external
effect.

> Doesn't that make catching failures of language-defined checks
> useless?  You will know that something bad happened, but you won't
> know which objects in your program are abnormal.

No.  You should know from the sequence the statements are written in,
which statements have been executed if it has an effect on which of
the _accessible_ objects are in which state.

Jacob (who isn't a LL and didn't look it up in the ARM)
-- 
�What fun is it being "cool" if you can't wear a sombrero?�

Re: In-Out Parameters for functions

[Hyman Rosen]

Jacob Sparre Andersen wrote:
> No.  You should know from the sequence the statements are written in,
> which statements have been executed if it has an effect on which of
> the _accessible_ objects are in which state.

I don't think so, given 11.6(6).

Re: In-Out Parameters for functions

[Jacob Sparre Andersen]

Hyman Rosen wrote:
> Jacob Sparre Andersen wrote:

> > No.  You should know from the sequence the statements are written
> > in, which statements have been executed if it has an effect on
> > which of the _accessible_ objects are in which state.
> 
> I don't think so, given 11.6(6).

Right!

But if this really is a serious problem for you, you can handle it by
putting each of the five assignments in your sequence of statements
within its own begin-exception-end block.  Assuming that I have
understood 11.6(6) correctly by now.

Jacob
-- 
"Those who profess to favor freedom and yet depreciate
 agitation, are people who want crops without ploughing the
 ground; they want rain without thunder and lightning; they
 want the ocean without the roar of its waters."
                                        -- Frederick Douglas

Re: In-Out Parameters for functions

[Hyman Rosen]

Jacob Sparre Andersen wrote:
> But if this really is a serious problem for you, you can handle it by
> putting each of the five assignments in your sequence of statements
> within its own begin-exception-end block.

That's not really the point. If I know in micro-detail where a check
is failing, I could just as easily make it not fail. What I expected
(which will probably earn me another blast from RE for not getting
the Ada mindset) was that the reason for l-d checks is to prevent the
kind of errors you find in C, namely undetected erroneous changes that
trigger problems at some remove from the place where they occurred.
It seems to me that the Ada rules allow the same sort of thing to
happen - if I have a handler at a high level for a language-defined
error, it's possible that any number of objects may have been left in
an abnormal state when the exception triggered, and I will encounter
erroneous (and possibly undetected) behavior at some later point.

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> The same section says
>     "The permissions granted by this clause can have an effect on the
>      semantics of a program only if the program fails a language-defined
>      check."
> 
> So unless you're coding in a way where you expect to cause and catch
> l-d checks, it won't matter.

Exactly correct.  But I do write code that deals with Constraint_Error, 
and has to do so correctly--whatever that means in that particular library.

> Also, if I read that section correctly, in a sequence of code like this
>     a := 0;
>     b := c + d;
>     e := f + g;
>     h := i + j;
>     a := 1 / a;
> it is possible that only the assignment to a will have occurred when the
> exception handler from the division by zero is executed, is that correct?
> Doesn't that make catching failures of language-defined checks useless?
> You will know that something bad happened, but you won't know which objects
> in your program are abnormal.

In fact for this sequence the compiler can generate code that does no 
assignments and always raises Constraint_Error.  I wrote a little program:

with Ada.Text_IO; use Ada.Text_IO;
procedure Hyman_Example is
   A,B,C,D,E,F,G,H,I,J: Integer := 1;
begin
   begin
     a := 0;
     b := c + d;
     e := f + g;
     h := i + j;
     a := 1 / a;
   exception when Constraint_Error =>
     Put_Line("Constraint_Error Raised. a = " & Integer'Image(A)
         & " b = " & Integer'Image(B)
         & " e = " & Integer'Image(E)
         & " h = " & Integer'Image(H));
   end;
end Hyman_Example;

And was actually surprised that GNAT didn't give me a warning and do 
just that.  I suspect that GNAT was being 'nice' because it saw a 
declare block there to handle Constraint_Error.  I could try making the 
declare block a library unit procedure and see what happens.

-- 
                                           Robert I. Eachus

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

Re: In-Out Parameters for functions

[Georg Bauhaus]

Robert I. Eachus <rieachus@comcast.net> wrote:
: 
: And was actually surprised that GNAT didn't give me a warning and do 
: just that.

Maybe I just haven't understood, however:
Compiling: hyman_example.adb (source file time stamp: 2004-03-02 16:28:14)

    11.      a := 1 / a;
                    |
        >>> warning: division by zero
        >>> warning: "Constraint_Error" will be raised at run time

 18 lines: No errors, 2 warnings

(further warnings about C, D, F, G, I, J not being modified
but not declared constant, if requested.)

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> That's not really the point. If I know in micro-detail where a check
> is failing, I could just as easily make it not fail. What I expected
> (which will probably earn me another blast from RE for not getting
> the Ada mindset) was that the reason for l-d checks is to prevent the
> kind of errors you find in C, namely undetected erroneous changes that
> trigger problems at some remove from the place where they occurred.
> It seems to me that the Ada rules allow the same sort of thing to
> happen - if I have a handler at a high level for a language-defined
> error, it's possible that any number of objects may have been left in
> an abnormal state when the exception triggered, and I will encounter
> erroneous (and possibly undetected) behavior at some later point.

First of all, on this point I agree with you that the Ada 95 rules go 
too far.  Fortunately, if you look at the example I posted, most Ada 
compilers are very careful about taking advantage of the 11.6(6) 
freedoms when exceptions can happen.

The real problem is that it is very hard to write a rule that makes 
sense given the way today's CPUs are built.  The CPU will reorder 
instructions at run-time, and only some CPUs will pretend, if an 
instruction causes an interrupt, that the ordering was precise.  I could 
probably reference half a dozen architecture manuals for you, that 
detail exactly how precise and non-precise interrupts are serviced.  But 
it is lots of really boring trivia to sort through to figure out what 
happens in a case that you might care about.  But I do read those 
manuals, thoroughly at least for most SPARC family processors, x86 
processors and now AMD64/IA-32e CPUs.

You have to remember is that the implementations vary, even within a 
processor family, and worse some processors have multiple modes, with 
different interrupt behavior.  So the current (Ada 95) RM rules really 
amount to do what makes sense on the real hardware--because the compiler 
compiles to an ISA, and for many ISAs, the rules change from 
implementation to implementation.

Fortunately, as the program I just posted shows, most compilers still 
obey the old Ada 83 meta-rule:  "Thou shalt not reason from 
erroneousness."  The program as written is (intentionally) erroneous. 
Not causes a bounded error, which is a much more tightly limited case, 
but erroneous.

Would I write code like that 'for real'?  Of course not.  But it doesn't 
prevent me from grumbling about how difficult it can be for a programmer 
to avoid erroneousness in some contexts.

(Technically what you have to do is write subprograms that handle 
exceptions internally as follows:

procedure Foo(...) is
   -- object declarations here should never raise an exception.
   -- put things that can in a nested block.
begin
   declare
      -- potentially problematical variables
   begin
      -- do any additional checking here, but don't assign to any
      -- out or in out parameters.

      -- firewall This is usually a call to some external procedure or
      -- function that is not inlined.  This can be, and often is in
      -- code that I write, a call that is needed anyway.

      -- do any assignments to globals or parameters here.
   exception
      when Constraint_Error =>
      -- fix the problem either by using a different
      -- algorithm, or by a nested call to Foo with modified parameters.
      when others => raise;
      -- or whatever, it is usually Constraint_Error that takes all the
      -- work, and any other exceptions are passed back to the caller.
   end; -- nested block.
end Foo;

All that looks like a lot of work, but it isn't usually.  It is just 
that most programmers Ada or otherwise have no idea of what it takes to 
write a subprogram that actually deals with Constraint_Error instead of 
just renaming it or letting it propagate to the caller.

To give just one example, think about an Inverse function for matrices. 
  There are matrices for which the inverse is well defined, there are 
cases where the matix is singular, and there is a third group of cases 
where the matrix is ill conditioned or stiff.  Often it takes a lot more 
CPU cycles to run the cases which can deal with ill-conditioned or stiff 
matrices, so you really do want to try say, simple LU decomposition first.

If you do go to that effort, putting the firewall call in is no big 
deal.  Writing the code so that you can begin over when needed is often 
more work, but in this case you are not inverting the matrix in place 
(unless you pass the matrix with an access parameter).

Now if anyone wants to submit a suggestion to Ada-Comment suggesting 
that there actually be a language defined procedure Firewall that does 
nothing but what its name implies, fine.  Personally I find it easy 
enough to have my own version around and call it.

-- 
                                           Robert I. Eachus

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

Re: In-Out Parameters for functions

[Robert I. Eachus]

Georg Bauhaus wrote:

> Robert I. Eachus <rieachus@comcast.net> wrote:
> : 
> : And was actually surprised that GNAT didn't give me a warning and do 
> : just that.
> 
> Maybe I just haven't understood, however:
> Compiling: hyman_example.adb (source file time stamp: 2004-03-02 16:28:14)
> 
>     11.      a := 1 / a;
>                     |
>         >>> warning: division by zero
>         >>> warning: "Constraint_Error" will be raised at run time
> 
>  18 lines: No errors, 2 warnings
> 
> (further warnings about C, D, F, G, I, J not being modified
> but not declared constant, if requested.)

Hmmm.  What version, and with which command line parameters? I actually 
used: gnatmake -gnato -f -O3 hyman_example.adb  With GNAT 3.15p for 
Windows/x86.

-- 
                                           Robert I. Eachus

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

Re: In-Out Parameters for functions

[Randy Brukardt]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1078245216.689285@master.nyc.kbcfp.com...
> Jacob Sparre Andersen wrote:
> > But if this really is a serious problem for you, you can handle it by
> > putting each of the five assignments in your sequence of statements
> > within its own begin-exception-end block.
>
> That's not really the point. If I know in micro-detail where a check
> is failing, I could just as easily make it not fail.

Not really. Try writing a multiply routine that detects overflow without
handling the exception.

>  What I expected
> (which will probably earn me another blast from RE for not getting
> the Ada mindset) was that the reason for l-d checks is to prevent the
> kind of errors you find in C, namely undetected erroneous changes that
> trigger problems at some remove from the place where they occurred.
> It seems to me that the Ada rules allow the same sort of thing to
> happen - if I have a handler at a high level for a language-defined
> error, it's possible that any number of objects may have been left in
> an abnormal state when the exception triggered, and I will encounter
> erroneous (and possibly undetected) behavior at some later point.

Handling l-d checks requires great care. It's generally only safe to do so
in a very narrow section of code (like the overflow check mentioned above),
or in a very broad chunk of code (the whole subsystem). Usually, you just
want to log them and either exit or reinitialize everything and start over.
Ada doesn't really support continuation from constraint_error or
storage_error.

                 Randy.

Re: In-Out Parameters for functions

[Georg Bauhaus]

Robert I. Eachus <rieachus@comcast.net> wrote:
: 
: Hmmm.  What version, and with which command line parameters? I actually 
: used: gnatmake -gnato -f -O3 hyman_example.adb  With GNAT 3.15p for 
: Windows/x86.

GCC 3.4 from last year, on GNU/Linux, the div by 0 warning is issued with
no options present (except -gnatv), the could-be-declared-constant warnings
follow after adding -gnatwa.


-- Georg