Re: Ada is almost useless in embedded systems

Re: Ada is almost useless in embedded systems

[Tore Joergensen]

Robert Dewar (dewar@cs.nyu.edu) wrote:
: Nasser, of course he did not post his reasons. This was a troll, one of the
: more transparent trolls one sees these days. [...snip...] There
: typically are two kinds of trolls, ones that make people mad enough to
: respond (the case here), or ones that entice people to respond ("I have
: XXX pictures free, but don't send me email, post here instead"). 
: Newsgroups are nicer places to be if people simply ignore trolls of both
: kinds :-)

Off topic: I'm just a little curious about this use of 'troll'...
Oxford Advanced Learner's Dictionary of Current English (1984) lists
two interpretations; "(in Scandinavian myth) supernatural being, a giant,
or, in later tales, a mischievous but friendly dwarf" and "fish with rod
and line by pulling bait through the water behind a boat". Even a 'Current
English'-dictionary from 1984 isn't current anymore :-), so I'm wondering:
Is this a common use of 'troll', and if it is, is it a noun made from the
'fishing' verb?
--
+-------------------------+-------------------------------------------+
| Tore B. Joergensen      | e-mail : tore@lis.pitt.edu                |
| Centre Court Villa      | web    : http://www.pitt.edu/~tojst1      |
| 5535 Centre Avenue # 6  |                                           |
| Pgh, PA 15232, USA      | Norwegian MSIS-student at Univ. of Pgh.   |
+-------------------------+-------------------------------------------+

Re: Ada is almost useless in embedded systems

[Robert Dewar]

Tore asks

"Off topic: I'm just a little curious about this use of 'troll'...
Oxford Advanced Learner's Dictionary of Current English (1984) lists
two interpretations; "(in Scandinavian myth) supernatural being, a giant,
or, in later tales, a mischievous but friendly dwarf" and "fish with rod
and line by pulling bait through the water behind a boat". Even a 'Current
English'-dictionary from 1984 isn't current anymore :-), so I'm wondering:
Is this a common use of 'troll', and if it is, is it a noun made from the
'fishing' verb?"

The trouble with English is that it is a very large language, so you need
a big dictionary :-)

I just went downstairs to haul up volume XVIII of OED 2nd edition, to see
what it says.

Troll as a noun is an old usage. There are two entries, one for the 
meaning we are interested in, and a second one for the Scandinavian
creature.

Under the first meaning, we have

"The act of trolling, a going or moving round; routine or repetition"

This is probably not the origin of the Internet use, but seemed
entertainingly relevant. A 1790 quote is

"The troll of their categorical table might have informed them that
there was something else ... besides substance and quantity" 

:-)

The relevant use is probably

"The method of trolling in fishing" 

or

"A lure used in trolling"

The first reference to the method is 1681, and first reference to the lure
that is quoted is 1869.

Anyway the internet usage is an adaptation of an old word that seems
well adapted for the internet use (i.e. a post whose primary intention
is to have other people respond with a post). John McCabe's original
post was a classical troll, the kind that works by aggravating people
into replying, even before there is anything of substance to reply to.

The other kind of troll lures people with an irresistable promise (e.g. 
"I have XXX pictures free, but don't email me, post to this newsgroup
if you want me to send a copy to you"), but it's hard to figure out
a positive troll of this kind that would work on CLA. I suppose if
early on we had posted something like

"Free copy of Ada 95 compiler, post to this group if you want one",
we would have got a fair number of poeple taking the bite (but I
still don't think that we could match the appeal of XXX pictures :-)

Re: Ada is almost useless in embedded systems

[Keith Thompson]

In <4g54r5$57j@toads.pgh.pa.us> tore@lis.pitt.edu (Tore Joergensen) writes:
> Off topic: I'm just a little curious about this use of 'troll'...
> Oxford Advanced Learner's Dictionary of Current English (1984) lists
> two interpretations; "(in Scandinavian myth) supernatural being, a giant,
> or, in later tales, a mischievous but friendly dwarf" and "fish with rod
> and line by pulling bait through the water behind a boat". Even a 'Current
> English'-dictionary from 1984 isn't current anymore :-), so I'm wondering:
> Is this a common use of 'troll', and if it is, is it a noun made from the
> 'fishing' verb?

Still off topic:

Quoting The Jargon File, version 3.3.0:

> :troll: v.,n.  To utter a posting on {Usenet} designed to
>    attract stupid responses or {flame}s.  May derive from the
>    phrase "trolling for {newbie}s" or some similar construction.
>    The well-constructed troll is a post that induces lots of newbies
>    and flamers to make themselves look even more like idiots than they
>    already do, while subtly conveying to the more savvy and
>    experienced that it is in fact a deliberate troll.  If you don't
>    fall for the joke, you get to be in on it.
>  
>    Some people claim that the troll is properly a narrower category
>    than {flame bait}, that a troll is categorized by containing
>    some assertion that is wrong but not overtly controversial.

(I'm not commenting on whether the article that started this thread was
a deliberate troll.)

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
"As God is my witness, I thought turkeys could fly." -- Arthur Carlson, WKRP

Re: Ada is almost useless in embedded systems

[John McCabe]

>Still off topic:

>Quoting The Jargon File, version 3.3.0:

>> :troll: v.,n.  To utter a posting on {Usenet} designed to
>>    attract stupid responses or {flame}s.  May derive from the
>>    phrase "trolling for {newbie}s" or some similar construction.
>>    The well-constructed troll is a post that induces lots of newbies
>>    and flamers to make themselves look even more like idiots than they
>>    already do, while subtly conveying to the more savvy and
>>    experienced that it is in fact a deliberate troll.  If you don't
>>    fall for the joke, you get to be in on it.

That's interesting. As the originator of this thread, I can only say
that the original posting was _not_ designed to attract _stupid_
responses. 

Hopefully some of the discussion that has gone on under this thread
has shown that to be the case.

I honestly believed that I would receive intelligent responses
explaining all the good features of Ada for embedded systems but I was
obviously a bit naive.

As you should have seen by now I had what I felt to be a number of
valid points on the unsuitability of Ada (83 remember) in embedded
systems. 

During the discussions that have taken place as a result of this, I
have learned a great deal about Ada, especially that the new version
(Ada 95) is well worth looking into, although it is unlikely that I
will be able to use Ada 95 for some time.

In particular, w.r.t the original points I mentioned (and in that
order):

1) Strong Typing is also very good if you have a large system with a
large number of programmers. Obviously it is advisable to catch errors
as early as possible as the later you find them, the more expensive
they tend to be to find. Also I have seen an article on 'lint' and its
usage and there are some very good points in it related to the fact
that it gives a lot of detail about trivial errors which can lead to
the user unintentionally ignoring the serious errors!

2) Bitwise logical functions - can be used on one dimensional packed
arrays of booleans.  I have also learned a more general lesson which
is to be a lot more sceptical about my customer's requirements and to
design defensively. Finally, I have learned about Ada 95's modular
types which from what I have heard, will be a very valuable addition
to the language.

3) Enumeration representation clauses - I knew that I could get round
the problem I described and I now also know the reasons why the
restrictions exist although I have not really changed my opinion on
that point. Richard O'Keefe pointed out the Ada 95 definition of these
clause, but I have not managed to obtain the Ada 95 LRM yet to get the
exact context so I cannot really comment for the moment.

4) Variant Records. Now here is one place where I believe I really
screwed up! As soon as I was given an example (well, a 2nd example) by
Bob Gilbert on this point, the stuff I'd learned on my 1989 Ada
Training course came flooding back. In my defense all I can say is it
was about 2 years between that course and actually getting into the
position where I could use Ada in earnest and I had forgotten it.
Still no excuse really! I appreciate all the information I've been
given on this one.

5) Chapter 13. Mmmm well. Yes, Ada makes it obvious that there are
implementation dependant language features whereas other languages do
not. I'm still not convinced about the flexible this allows on the
implementations but the impression I get from what I've heard on Ada
95 is that far more definition has gone into this area.
Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Ada is almost useless in embedded systems

[Richard A. O'Keefe]

john@assen.demon.co.uk (John McCabe) writes:
>I honestly believed that I would receive intelligent responses
>explaining all the good features of Ada for embedded systems but I was
>obviously a bit naive.

With all due respect, it is a mystery to me how anyone could have expected
a posting whose title is
	"Ada is almost useless..."
to be perceived as anything other than flame bait.  When the first thing you
say is, in effect, "I know you have nothing worthwhile to tell me", you have
no right to be surprised if you fail to receive the response you expected.

>1) Strong Typing is also very good if you have a large system with a
>large number of programmers. Obviously it is advisable to catch errors
>as early as possible as the later you find them, the more expensive
>they tend to be to find. Also I have seen an article on 'lint' and its
>usage and there are some very good points in it related to the fact
>that it gives a lot of detail about trivial errors which can lead to
>the user unintentionally ignoring the serious errors!

In defence of Lint, I have to say that all of the things it reports are
likely symptoms of serious errors, and that it is next door to impossible
to UNINTENTIONALLY ignore the serious errors.  The only way you can ignore
the serious errors is by not tracking down all the lint reports to see how
serious they are.  A typical experience with someone else's code might be
	- 16 000 lines of source code
	-  1 000 lines of lint warnings
	-     10 hours checking the lint warnings
	-     10 days fixing the serious bugs.
Many categories of warnings can easily be switched off.

There are two real problems with lint.
(1) The declarations of C do not provide enough information for really
    effective checking.  (E.g. all integer types are compatible.)
(2) There are legions of C programmers who apply lint, if at all, far too
    late in the life cycle, after they have already populated their code
    with tons of lint.


>2) Bitwise logical functions - can be used on one dimensional packed
>arrays of booleans.  

But you didn't need the net for this.  It's in the manual!
Think "logical", find "logical operators" in the Ada83 LRM, go to
section 4.5.1 "Logical Operators and Short-Circuit Control Forms",,
and there staring you in the fact is a table that says 'and', 'or',
'xor' apply to "array of boolean components".

>3) Enumeration representation clauses - I knew that I could get round
>the problem I described and I now also know the reasons why the
>restrictions exist although I have not really changed my opinion on
>that point. Richard O'Keefe pointed out the Ada 95 definition of these
>clause, but I have not managed to obtain the Ada 95 LRM yet to get the
>exact context so I cannot really comment for the moment.

For the sake of completeness, I should point out the possibility of generating
the Ada source text.  I can well imagine that if your primary source for the
names and values of the enumeration literals puts them in some funny order,
then you might want the manually edited document to have them in the same
order so that they can be the more easily checked.

Let your codes document have the form

	<number in decimal>	<identifier>	<optional comment>
	...
	<number in decimal>	<identifier>	<optional comment>

with the entries in the order of your primary source.  Call this file
	typename.org

You want to generate
	type <type name> is (
	 <identifier>	-- <optional comment>
	...
	,<identifier>	-- <optional comment>
	);
	for <type name> use (
	 <identifier> => <number>
	...
	,<identifier> => <number>
	);
in a file called
	typename.ada

Put the following shell script in a file called mk-ada-enum:
#!/bin/sh
typename=$1
echo "type $typename is ("
echo "for $typename use (" >$$.use
separator=" "
sort -n | while read number identifier comment ; do
    echo "$separator$identifier	-- $comment"
    echo "$separator$identifier => $number" >>$$.use
    separator=","
done
echo ");"
echo ");" >>$$.use
cat $$.use
rm $$.use

Use it like this:
	mk-ada-enum "Ada_Type_Name" <typename.org >typename.ada

For example, I put these lines in "funny.org":
	4	foo	"d" is not supported
	1	bar	not a wet one
	3	ick	the shut down signal
	2	ugh	response to the shut down signal
Running "mk-ada-enum Funny <funny.org >funny.ada" produced this output:
type Funny is (
 bar	-- not a wet one
,ugh	-- response to the shut down signal
,ick	-- the shut down signal
,foo	-- "d" is not supported
);
for Funny use (
 bar => 1
,ugh => 2
,ick => 3
,foo => 4
);

It isn't pretty, but that doesn't matter, because you maintain the table,
not the generated Ada code.  (The scripting language isn't important; if
it were in TCL I could run it on a Macintosh.)

-- 
Election time; but how to get Labour _out_ without letting Liberal _in_?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: Ada is almost useless in embedded systems

[Norman H. Cohen]

In article <4gechc$g26@goanna.cs.rmit.EDU.AU>, ok@goanna.cs.rmit.EDU.AU
(Richard A. O'Keefe) writes: 

|> In defence of Lint, I have to say that all of the things it reports are
|> likely symptoms of serious errors, and that it is next door to impossible
|> to UNINTENTIONALLY ignore the serious errors.  The only way you can ignore
|> the serious errors is by not tracking down all the lint reports to see how
|> serious they are.  A typical experience with someone else's code might be
|>      - 16 000 lines of source code
|>      -  1 000 lines of lint warnings
|>      -     10 hours checking the lint warnings
|>      -     10 days fixing the serious bugs.
|> Many categories of warnings can easily be switched off.
|>
|> There are two real problems with lint.

You mean you don't consider the ten hours checking the lint warnings (let
alone ten days fixing only the "serious" bugs) to be a "real problem"?
Or did I miss your smiley?

|> (1) The declarations of C do not provide enough information for really
|>     effective checking.  (E.g. all integer types are compatible.)

Indeed.

|> (2) There are legions of C programmers who apply lint, if at all, far too
|>     late in the life cycle, after they have already populated their code
|>     with tons of lint.

Not an option with Ada.  You can't get a successful compilation until
your code has been delinted.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Ada is great for embedded systems (was Ada is almost useless in embedded systems)

[Ken & Virginia Garlington]

Ted Dennison wrote:
> 
> John McCabe wrote:
> 
> > 1) Strong typing is very good if your coders are learners or possibly
> > not very good, and can be useful to guide you in the direction of bugs
> > at the compilation stage but the enforcement of strong typing can lead
> > to code that is difficult to understand because you end up having
> > numerous type casts and unchecked conversions in order to implement
> > something quite simple. C does not enforce strong typing so you can
> > get away with some very strange code, but if you really want to check
> > where you may find problems, you can use 'lint'.
> 
> For Godlike programmers (such as yourself?), perhaps type checking
> is an inconvienence.... [snip]

I always see a discussion of Ada vs. C typing end up here. Let me suggest
an alternative explanation of Ada vs. C typing, which is hinted at in Mr.
McCabe's comment.

If you don't want to use strong typing in Ada, _don't_. You can write Ada
code that has basically the same level of type checking as in C, and it
will run. There's very little in Ada that forces type casts and unchecked
conversions, particularly for simple programs.

Here's the distinction. If I _do_ want to use strong typing in Ada,
and I think it's important for the users of my code to pay attention to that
typing since it's necessary to understanding how my code works, I can do it.
In "C", I can't force users of my code to run lint, purify, and all these
neat C add-ons I see advertised in the magazines for several hundred
dollars a pop. I can put in comments, and cross my fingers, and that's about it.
I know that my code may be used by new hires, or super-programmers coming off
vacation in the Bahamas, so I may want to be precise in how I define my solution.
(See "defensive programming" in the software engineering literature.)

Ada is written in terms of the writer of code defining what should be done
with it, rather than the user. This has its good and bad points, but the Ada
approach is pretty common to manufactured items in general (e.g., the warranty gets
voided if you use the product in a way not defined by the manufacturer). If we want to 
think of software more as a set of manufactured components, and less as an art form, 
then the Ada way seems to be a good way to start. Of course, lots of people like art 
better than manufacturing, so it's not going to please everyone.

> > 2) In the system I am currently developing I have discovered a need
> > use bitwise logical functions on a register which contains 16 bits,
> > all of which are accessed at one time, and all of which have identical

I do this all the time in my Ada 83 embedded systems, so I don't know what the
problem is here. Early Ada 83 implementations were somewhat inefficient with bit
ops, but current products do a reasonable job here.

> > 3) When I'm designing/implementing a system, I like to follow the
> > order of command lists provided in requirement specification when
> > defining enumerated types of these command. I tend to have very little

> 
> So what? As long as they are all there, who cares what order they are
> listed in? I don't see how this cripples Ada to the point where it is
> useless. C doesn't even HAVE enumerated types! You'd have do use
> a series of constants, which you can do in Ada as well!!

I think the issue is: If in the spec, a discrete is listed as Open/Closed, then
it would be nice for the type to read (Open, Closed). However, if Open=1 and
Closed=0, then you have to reverse the order in the type. I've never noticed
this in our embedded systems, since our engineers list these in ascending order.

It is a good point that Ada enumerated values are really useful in embedded systems,
particularly those with a lot of inverted discretes (e.g. On=0, Off=1). It is
much less error-prone than using constants, where the old cut-and-paste error

  On: constant := 0;
  Off: constant := 0;

always seemed to be hanging around.

> > 4) Pascal provides variant records, C provides unions and Ada provides
> > variant records. What differences are there between these? Obviously I
> > am aware that none of these languages guarantee that the variants are
> > front of the record type. How can you map this onto e.g. a 1553 bus
> > command buffer where the command structure is NOT defined to fit into
> > the Ada variant record type structure? This has been implemented in my

Actually, we've not had any problems using Ada with our 1553 interfaces. It
may be that our mappings are just a little less perverse...

> > 5) Finally chapter 13. What is the point of having a program to come
> > up with a portable, general purpose, 'standard for use in DoD
> ...
> > reasoning of this and I think it is stupid. At work we have 3 Ada
> > compilers for MIL-STD-1750A targets and we have been surprised at the
> > amount of work that is involved in getting a single piece of code to
> > compile under all three. Previously I used Motorola's implementation
> > of GCC for a DSP56001 target, and the HP UNIX ANSI standard compiler
> > on a single piece of code, without modification, and they both
> > compiled the code perfectly. This proves to me that C is a far more
> > portable language than Ada.

Have you tried to port C code between three different 1750 compilers? For some
reason (probably the small user base), comparisons of 1750 target compiler
capabilities vs. host compilers (e.g. HP) always come off bad. This
is true for Ada, and I suspect it's true for C as well. (Did you have any trouble
getting the HP to fix in the same space as the 1750? :)

However, we have ported large chunks of code between DEC Ada, Telesoft Ada/1750,
and Tartan Ada/1750 with no trouble. So, it may be a consequence of the way you
had to write your Ada code, or you just picked some bad compilers, or you need the
extra power of Ada 95 to make your code portable. I don't know.

Re: Ada is almost useless in embedded systems

[AdaWorks]

Joe Gamache (jgamache@mailgw.sanders.lockheed.com) wrote:
: In article <824056183.18993@assen.demon.co.uk>, 
: john@assen.demon.co.uk says...
: >

: >1) Strong typing is very good if your coders are learners or 
: possibly


  The fact that several contibutors to this thread are focusing their
  comments on "strong typing" indicates that there are still a large 
  number of software practitioners who do not understand the underlying
  rationale for Ada.  

  Ada is not about strong typing.  

  The type model is a feature of the language, albeit an important one. Of
  equal importance (maybe of greater importance) is the set of rules related
  to scope and visibility.  These rules are often misunderstood, and 
  sometimes ignored.  There are other characteristics of the language that
  must be considered in evaluating its role as a software engineering tool.

  So what is the criteria you use for selecting a programming environment?
  The overriding issue is whether one wants a language in which the compiler
  catches most of the errors.  If the answer is, "Yes," the correct choice
  is Ada.  If it is, "No," use something else.  Decide on your criteria and
  the select the language.  As for me, I am not very smart, so I like to
  use a language that helps me avoid stupid misteaks. [sic]  :-)

  Richard Riehle
  adaworks@netcom.com

-- 

richard@adaworks.com
AdaWorks Software Engineering
Suite 27
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815
FAX  328-1112

Re: Ada is almost useless in embedded systems

[Ken Garlington]

AdaWorks wrote:
> 
>   So what is the criteria you use for selecting a programming environment?
>   The overriding issue is whether one wants a language in which the compiler
>   catches most of the errors.  If the answer is, "Yes," the correct choice
>   is Ada.  If it is, "No," use something else.

Actually, I think you short-change Ada here. Another question to ask is: Who will
need to read the software?

I have been very impressed with the readability of (well-written) Ada, particularly
by non-software engineers. If a hardware engineer wants to read our software to
understand how it manipulates the hardware, he can read it with only infrequent
access to any manuals, etc. If a system test engineer wants to read our software
to understand a data structure or algorithm, no problem. Even a (shudder) customer
with little software expertise can review our code and understand with very little
assistance.

I have also seen these same engineers presented with a C++ program. First, out come the
manuals...

Re: Ada is almost useless in embedded systems

[Hugh Dunne]

AdaWorks wrote:
> 
> Joe Gamache (jgamache@mailgw.sanders.lockheed.com) wrote:
> : In article <824056183.18993@assen.demon.co.uk>,
> : john@assen.demon.co.uk says...
> : >
> 
> : >1) Strong typing is very good if your coders are learners or
> : possibly
> 
>   The fact that several contibutors to this thread are focusing their
>   comments on "strong typing" indicates that there are still a large
>   number of software practitioners who do not understand the underlying
>   rationale for Ada.
> 
>   Ada is not about strong typing.[snip]
>   So what is the criteria you use for selecting a programming environment?
>   The overriding issue is whether one wants a language in which the compiler
>   catches most of the errors.  If the answer is, "Yes," the correct choice
>   is Ada.  If it is, "No," use something else.  Decide on your criteria and
>   the select the language.  As for me, I am not very smart, so I like to
>   use a language that helps me avoid stupid misteaks. [sic]  :-)

Good point. Strong typing is part of a larger issue: having the compiler
catch as many mistakes as possible. I can't think of a situation where it's 
preferable to have the application crash at run time, or worse still, silently 
give wrong answers.

Another meta-issue is having code that is readable and self-documenting. This
is _not_ just for the benefit of novice coders. No matter how expert your
fellow team members are, give them a break and things will go more smoothly
for the whole team. Even if you're a one-person team, remember that the code
you write today may have to be set aside for a while and then looked at again.
A little foresight will pay dividends.

Of course Ada by itself doesn't guarantee readable code, but it does make it
easier for a conscientious programmer to produce readable code. Very often
you can produce a code fragment which looks almost exactly the same as the
text of the requirement. You don't have to mess around with the ampersands,
asterisks and various dingbats that are unavoidable in C and C++.

-- 
-----------------------------------------------------------------------------
Hugh Dunne/Logica UK Ltd/Medina House/Randalls Way/Leatherhead KT22 7TW/UK
dunneh@lhd.logica.com +44 171 637-9111 x5973           http://www.logica.com/
DISCLAIMER: Any opinions expressed are those of the author and not of Logica.

Re: Ada is almost useless in embedded systems

[Alan Brain]

>In article <824056183.18993@assen.demon.co.uk>, john@assen.demon.co.uk (John McCabe) writes:
>> 
>> 
>> 1) Strong typing is very good if your coders are learners or possibly
>> not very good,

Agree. Mice ditto. Keyboards as well. Real Programmers use the Front 
Panel switches, and have their teeth filed to bite holes in the punched 
cards. Anyone who uses Keyboards is a Wimp, Loser and Weenie who does not 
understand Machine Code, and who makes mistakes when coding in binary. 
001000110110 obviously shows which registers you're using, which ALUs and 
even which communications pipeline you have. It is terser (only 2 
different possibilities in each position) and more powerful than 
favourites of the aforementioned Wimps, Losers and Weenies such as 'for 
i++:'.

Sorry, Flame off. But this supercilious balderdash has been repeated too 
long for me to let it go unchallenged.

Look at the recent Byte article "Why Software Projects Fail". One of the 
Cardinal rules set forth for success is to use Assertions. A lot. Any 
Strongly typed language automatically provides sanity-checks every time 
you do an operation, without you having to code it handraullically.

I've programmed for over 20 years in various assemblers, Fortran II, 
Fortran IV, Cobol, Forth, Trac, PLZ/Sys, Ada95, and coded large projects 
in Assemblers, APL, Fortran 77, CMS-2M, CMS-2Y, Meta, C, SMR-2, Pascal, 
Basic (for my sins..), and Ada 83.

I've written complete accounting systems (Client-Server using a GOSH-WOW 
5 Mb!!! Hard Disk costing many thousands of $) in APL. It was Terse. And 
Powerful. But write-only.

I've written hard real-time systems in C, from being involved in the 
second port of Unix into C in 1976 at Sydney University.

Since 1983, I've been working 90% in Ada, 10% in C ( and some C++ 
recently).

I'm sure the next time a significant advance in the art comes along, 
people will complain that Real Programmers use Ada 95, and only Wimps, 
Losers and Weenies use a Virtual Reality Programming System, which is 
only "good if your coders are learners or possibly not very good.".


In the meantime, I'd say that C is great for ameteurs in small projects, 
( hey, even I'd prefer it in many circumstances ), but Ada X, Modula Y or 
Eifel are the languages of choice for professionals who aren't slaves to 
COBOL.

  

Re: Ada is almost useless in embedded systems

[R.A.L Williams]

In article <4g3ljv$mmc@news.pacifier.com> steved@199.2.117.161  (Steve Doiel) writes:

> From: steved@199.2.117.161  (Steve Doiel)
> In ... (Daniel Grambihler) writes:
> 
> [snip]
> 
> >
> >I don't recall a claim the it was *impossible* to interface to hardware. Just
> >that it is badly designed for that job. I agree. Interfacing to hardware with
> >Ada is a pain.
> >
Yes that has been my experience too. At least compared with doing the same
job in C. I have to admit, however, that I haven't tried it for quite a
few years and perhaps compiler quality has improved.

[snip]

> 
> Well Daniel if portability is an issue, I think you need to scrap using
> 'C' bit fields to map to hardware registers or test your particular compiler
> for what it generates and settle for non-portable.
>
 
[snip]

I think one of the problems we are all having with this discussion is the 
context in which various statements are being made:

- programming in the large vs. programming in the small
- portability vs. fixed target environment

to mention but two sources of contention. Let's take an example I was 
peripherally involved in recently. We had to produce a small interface unit
that did a certain amount of data processing (all done in dedicated hardware
because of the desired rates) and, in addition, logged time-stamped
information onto a 'legacy' tape unit. Unfortunately the time-stamped
information also came from 'legacy' equipment, but a different legacy. I 
won't go into details but hardware designers can come up with thouroughly
unpleasant specifications when they want to! Portability didn't come into
the matter because this was a one-off system for a particular research
application. We knew the platform, in fact we designed it (the CPU board
at least), we knew the host and the job was so small that we couldn't
justify the expense of any compiler we didn't already have. Programming 
'in the large' was not an issue because, again, the whole job was so
small. To be honest, the engineer in charge of the development didn't
even consider using Ada but, if he had, I would have advised strongly
against it because, leaving aside the issues of large projects and
portability of representation, Ada (83 at least) is IMO far harder to
use than C.

Large system developments certainly get all the headlines and certainly 
represent a larger 'concentrated' risk if they go wrong, but at what
level, I wonder, is the bulk of man-power in the industry expended? In the
UK more people are employed in 'small businesses' than in multi-nationals.
I wonder if, by analogy, the same is also true of software development. If
this is the case, then maybe us 'little people' should have a voice too :-)

Bill Williams


-- 
Bill Williams                     |GEC-Marconi does not necessarily
GEC-Marconi Research Centre       |endorse my opinions!

bill.williams@gecm.com
Tel: +44 1245 242016
Fax: +44 1245 478639

Re: Ada is almost useless in embedded systems

[Richard A. O'Keefe]

ralw@valiant.gmrc.gecm.com (R.A.L Williams) writes:
>To be honest, the engineer in charge of the development didn't
>even consider using Ada but, if he had, I would have advised strongly
>against it because, leaving aside the issues of large projects and
>portability of representation, Ada (83 at least) is IMO far harder to
>use than C.

This statement, coming from someone with such a background, deserves
a fuller exposition.  I hope R. A. L. Williams will provide one.

My personal experience, having used C since 1979, and Ada only for the last
couple of years, is precisely the opposite.  I consider myself expert in C;
perhaps that's why I thought it was hard to use.  I may say that it seems
to be easier to _teach_ Ada than to teach C; you can get a heck of a long
way without worrying about pointers, and it is so refreshing to be able to
answer questions of the form "how do I do X" with "well, it's really a topic
for later, but here's how you do it in Ada" instead of "well, there's no
language support for that in C in order to keep the compiler simple back in
the 70's."

(I hope this crashes before the written-in-C operating system crashes again...)

-- 
Election time; but how to get Labour _out_ without letting Liberal _in_?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: Ada is almost useless in embedded systems

[AdaWorks]

John McCabe (john@assen.demon.co.uk) wrote:
: I believe that Ada is badly designed with respect to interfacing to
: hardware and because of this should not be recommended for use in
: embedded systems.

  There have been truly abominable embedded systems project deployed
  written in Ada.  One could say the same of C, assembler and Forth.

  There are truly excellent embedded systems deployed written in Ada.
  This is also true of C, assembler, and Forth.

  The question, "Can Ada be used for the construction of well-performing
  embedded systems," is no longer a valid question. There are enough 
  operational systems in place to answer, "Yes."  

  We have no need to prove, through argument, whether Ada is appropriate
  for embedded systems software.  The Ada track-record speaks for itself.
  You have the burden of proof.  Since so many embedded systems are doing
  so well programmed in Ada, how do you prove it is not suited to such
  systems?

  The fact that some Ada software applications are horrible is not a function
  of the language, but a function of poor design, poor software practice,
  and often, in my experience, poor configuration management.

  Whatever reasons you may have are not relevant given Ada's record of 
  success.

  Do you recall the scientific proof that the Bumblebee could not fly because
  of its aerodymanic properties and wing-span?  

                      "Sweeny shifts from ham to ham,
                        Stirring the water in his bath."

  I do not recal the next two lines of Mr. Eliot's poem, but they 
  have to do with the folly of such proofs.                           

  Richard Riehle
-- 

richard@adaworks.com
AdaWorks Software Engineering
Suite 27
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815
FAX  328-1112

Re: Ada is almost useless in embedded systems

[Ken Garlington]

AdaWorks wrote:
> 
>   Whatever reasons you may have are not relevant given Ada's record of
>   success.

I think that's a little harsh. Certainly with Ada 83 (which was the original
context of the topic), there were problems with using it for certain classes
of embedded systems - some technical, some not. None of them were insurmountable,
but they existed.

The point is: Ada is no longer Ada 83. Some of the Ada 95 revision requests were 
written by people with the same gripes as Mr. McCabe, and those RRs were 
incorporated into Ada 95 where possible. As a result, I think Ada 95 is a better 
language for embedded systems programming than Ada 83, and so the Ada 83 
experience is becoming obsolete from the technical side. From the non-technical 
side (compiler maturity, cost, etc.) the Ada 95 world is also much improved from 
the early days of Ada 83.

Re: Ada is almost useless in embedded systems

[AdaWorks]

Ken Garlington (GarlingtonKE@lfwc.lockheed.com) wrote:
: AdaWorks wrote:
: > 
: >   Whatever reasons you may have are not relevant given Ada's record of
: >   success.

: I think that's a little harsh. Certainly with Ada 83 (which was the original
: context of the topic), there were problems with using it for certain classes
: of embedded systems - some technical, some not. None of them were insurmountable,
: but they existed.

  Well, OK, all right, Ken.  I do somemtimes tend to hyperbole.  
  However, the main point is that Ada (even Ada 83) has been used
  successfully for a large variety of projects, both embedded and
  non-embedded.  While it is true that Ada 83 had its difficult 
  issues (or Ada 95 might have been superfluous), it was possible 
  to overcome these difficulties when they manifested themselves.

  I wonder if anyone can cite a high-level language that has no
  difficulties.  

  Regarding your point in an earlier posting about my understating the
  value of Ada, I plead guilty. My purpose was to summarize what
  I see as two important contributions of Ada, but with no intention
  of nullifying any of the other important benefits of the language.
  Certainly, we each have our favorite features about the tools
  in our toolset.  

  Richard Riehle
  adaworks@netcom.com
-- 

richard@adaworks.com
AdaWorks Software Engineering
Suite 27
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815
FAX  328-1112

Re: Ada is almost useless in embedded systems

[Jon S Anthony]

In article <824495640.102@assen.demon.co.uk> john@assen.demon.co.uk (John McCabe) writes:

> >In passing, it may be of interest to note that the original VAX Ada
> >did not implement shared, and opted instead to implement a pragma
> >volatile.  Volatile basically did the "optimization" bit that you are
> >concerned about, but explicitly did _not_ provide for indivisible
> >operations.
> 
> That's interesting and sound like what Ada95 does (according to Robert
> Dewar's comment elsewhere).

Not quite.  Ada95 _splits_ these two things between pragma volatile and
pragma atomic.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Ada is almost useless in embedded systems

[R.A.L Williams]

In article <4gea0h$ckd@goanna.cs.rmit.EDU.AU> ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) writes:

> ralw@valiant.gmrc.gecm.com (R.A.L Williams) writes:
> >To be honest, the engineer in charge of the development didn't
> >even consider using Ada but, if he had, I would have advised strongly
> >against it because, leaving aside the issues of large projects and
> >portability of representation, Ada (83 at least) is IMO far harder to
> >use than C.
> 
> This statement, coming from someone with such a background, deserves
> a fuller exposition.  I hope R. A. L. Williams will provide one.

The specification for some of the data formats had things like:
- values split across several bit fields, ie.
   a bit of A
   a bit of B
   some more of A
   the rest of B
- bit reversed values
- fixed point numbers with 'weird' resolutions.

OK, so Ada (83 and 95) can handle all these things. 95 far easier than
83 I suspect (modulo types are a tremendous improvement for example).
My attitude to this sort of thing is that you find the right tool for 
the job. I strongly suspect, based on my experience with Ada 83 at
least and having seen the solution in C, that any solution is bound to
be pretty much unreadable because of the nature of the problem. That
said C seems to be the better tool for this particular type of low
level manipulation because it is, basically, a high level assembler
and, as such, has syntax and semantics which maps very directly to the
architecture of the 'typical' CPU. Ada implements a higher level
abstraction which, although useful for writing 'high level'
applications, makes it comparatively clumsy for this sort of low level
code. Essentially what I am saying is that, where this sort of low
level manipulation is required using Ada will tend to obscure the
solution because of its high level abstraction where C, which is
inherently low level, expresses it succinctly.

Of course, the decision must look at the whole problem. In the system
discussed above there was very little else. We do a lot of this sort
of thing - interfaces between existing pieces of kit which are too
complex to implement entirely in hardware - and, franly, C is still
the ideal language. If there had been significant other processing or
control to do we might have looked at Ada or C++ or a mixed language
solution. As it was, these other choices were sub-optimal.
> 
> My personal experience, having used C since 1979, and Ada only for the last
> couple of years, is precisely the opposite.  I consider myself expert in C;
> perhaps that's why I thought it was hard to use.  I may say that it seems
> to be easier to _teach_ Ada than to teach C; you can get a heck of a long
> way without worrying about pointers, and it is so refreshing to be able to
> answer questions of the form "how do I do X" with "well, it's really a topic
> for later, but here's how you do it in Ada" instead of "well, there's no
> language support for that in C in order to keep the compiler simple back in
> the 70's."
> 
That's an interesting point. Ada certainly makes it easy to avoid the 
normal C beginners mistakes. Also, of course, we don't normally let
beginners loose on implementing devious embedded systems so the places
where the issue we're discussing is relevant don't arise.

> (I hope this crashes before the written-in-C operating system crashes again...)
> 
On our network it's the P(ersonal) C(atastrophes) that cause all the
problems. What do Microsoft use?
> -- 
> Election time; but how to get Labour _out_ without letting Liberal _in_?
> Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Bill Williams
-- 
Bill Williams                     |GEC-Marconi does not necessarily
GEC-Marconi Research Centre       |endorse my opinions!

bill.williams@gecm.com
Tel: +44 1245 242016
Fax: +44 1245 478639

Re: Ada is almost useless in embedded systems

[John McCabe]

dewar@cs.nyu.edu (Robert Dewar) wrote:

>John McCabe says

<snip>

>It might be easy to use, but it obviously has nothing to do with
>package Machine_Code, which uses aggregates rather than procedure
>calls. What you describe is more closely related to the approach
>described in th Ada 95 RM as "intrinsic subprograms"

Yes, I've read about them.

>If the compiler you cite calls their package Machine_Code, then it clearly
>is not an accurate Ada 83 implementation, rather it is an impermissible
>extension.

If you remember some of my previous postings etc about my current Ada
compiler, I think you could probably reach the conclusion that _I_
don't think it is an accurate Ada 83 implementation (motive - be wary
of TLD!). It makes me wonder why there is such a fuss about
validation! I know the validation suite is limited in what is actually
checked but this seems a bit outrageous.

>However, in Ada 95, either approach is allowed (package Machine_Code or
<snip>

That does sound better to me (as far as the language is concerned),
but obviously TLD appear to be being a bit strange in their
interpretation here!

>For another example of this, look at the support for machine intrinsics
>in the Alsys x86 technology (that's my design, so I know it well :-)
<snip>

I don't think I'll bother looking for the moment thank you (at least
not until I need to use an x86 compiler) but that approach sounds
similar to the MSPs (Machine Specific Procedures) package that comes
with PSS's compiler. Do you know of it?

>By the way, the plan for GNAT in this area is to define some additional
>attributes which hook into the existing GCC mechanism for assembly
>language inserts (see description in GNU C manual).

Presumably this is related to the C compilers asm("string") call?


Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[John G. Volan]

In article <EACHUS.96Mar21184540@spectre.mitre.org> 
Robert I. Eachus, eachus@spectre.mitre.org writes:
>In article <4iq2ia$lk7@dayuc.dayton.saic.com> 
>John G. Volan ><John_Volan@ccmail.dayton.saic.com> writes:
...
>  (My conclusion was that you really only need one package:)
...
>    --add
>
>    procedure Increment (This : in out Item; By: in Positive);
>    procedure Decrement (This : in out Item; By: in Positive);
...
>    procedure Increment (This : in out Item; By: in Positive) is
                                                     ^^^^^^^^^
>    begin
>      This := Item'Val(Item'Pos(This) + By);
>    end Increment;
>
>    procedure Decrement (This : in out Item; By: in Positive) is
                                                     ^^^^^^^^^
>    begin
>      This := Item'Val(Item'Pos(This) - By);
>    end Decrement;
...

Horrors! This assumes that Standard.Integer subsumes all possible ranges
of 'Pos values for all discrete types (enumeration, integer, modular).
A very dubious assumption!  What about Long_Long_Integer?  The long-term
reusability of this package is problematic.

Also, why limit Increment/Decrement to Positive?  Why not allow any
arbitrary integer?  The C analogs for these procedures, += and -=,
carry no such limitation.

Finally, you're looking too narrowly at the problem:  You seem to be
focussed exclusively on analogs for ++ -- += -= , and are neglecting 
similarly contentious operations such as *= /= %= .  Also, you're
only looking at discrete types.  What about real types?  My inanely
trivial packages covered all the bases.

However, your Cycle operation is a nice touch.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature
( Name => "John G. Volan", E_Mail => "John_Volan@dayton.saic.com",
  Favorite_Slogan => "Ada95: The *FIRST* International-Standard OOPL",
  Humorous_Disclaimer => "These opinions are undefined by SAIC, so" &
    "any use would be erroneous ... or is that a bounded error now?" );
------------------------------------------------------------------------

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Robert Dewar]

John said

"Horrors! This assumes that Standard.Integer subsumes all possible ranges
of 'Pos values for all discrete types (enumeration, integer, modular).
A very dubious assumption!  What about Long_Long_Integer?  The long-term
reusability of this package is problematic."

Nope, not horrors at all. Increment should mean increment, not add, if
you want to add, please use the + operator which is just fine for
this purpose.

I think it actively HELPS maintainability that increment accepts only
small positive values.

I also think that the extnsion of these operators, dubious in the first
place, to weird cases like mod is a disservice. I can put up with += in
C but I find the use of things like %= and ^= to be tortured syntax,
which I prefer NOT to import in any case.

I still think the whole business is a tempest in a teapot, and do not think
that the use of any of these packages helps in reading, maintaining, or
even writing code.

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Tucker Taft]

Robert Dewar (dewar@cs.nyu.edu) wrote:

: I also think that the extnsion of these operators, dubious in the first
: place, to weird cases like mod is a disservice. I can put up with += in
: C but I find the use of things like %= and ^= to be tortured syntax,
: which I prefer NOT to import in any case.

As a small anecdote here relating to the "op=" operations of C, 
my most recent "favorite" bug in C code I was writing was in the following:

  if (a /= b) {
    ...
  }

The GCC compiler nicely warns you if you write "if (a = b) {" and
suggests an extra level of parentheses to emphasize that you really
want an assignment, not an equality, operator.  Unfortunately, it
isn't so helpful with the "op=" operators, and presumes that if
you use one of those, you know what you are doing.  Alas, after
writing a lot of Ada, I didn't in this case.  Of course what I meant
was "if (a != b) {".  Instead, I divided A by B, and tested the result
for non-zero-ness.  Groink!

At this point Dave Emery comes on and asks me why in the world
I am writing any code in C... ;-}

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Norman H. Cohen]

In article <Dot06M.Asu.0.-s@inmet.camb.inmet.com>,
stt@henning.camb.inmet.com (Tucker Taft) writes: 

|> As a small anecdote here relating to the "op=" operations of C,
|> my most recent "favorite" bug in C code I was writing was in the following: 
|>
|>   if (a /= b) {
|>     ...
|>   }
|>
|> The GCC compiler nicely warns you if you write "if (a = b) {" and
|> suggests an extra level of parentheses to emphasize that you really
|> want an assignment, not an equality, operator.  Unfortunately, it
|> isn't so helpful with the "op=" operators, and presumes that if
|> you use one of those, you know what you are doing.  Alas, after
|> writing a lot of Ada, I didn't in this case.  Of course what I meant
|> was "if (a != b) {".  Instead, I divided A by B, and tested the result
|> for non-zero-ness.  Groink!

Yes, I've done the same thing.  It's one of a group of C pitfalls to
which Ada programmers are especially susceptible.  Another is to leave
the empty parentheses off a parameterless function call in a context
in which C is willing to accept a pointer-valued expression.  There are
far too many such contexts.  When I wrote

   if ( some_predicate ) {
      ...
   }

instead of

   if ( some_predicate() ) {
      ...
   }

C obediently coerced some_predicate to a pointer to the function and
tested whether that pointer was null.  As Tuck so eloquently put it,
Groink!

|> At this point Dave Emery comes on and asks me why in the world
|> I am writing any code in C... ;-}

So we don't start to take Ada for granted, of course. ;-)

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Robert A Duff]

In article <Dot06M.Asu.0.-s@inmet.camb.inmet.com>,
Tucker Taft <stt@henning.camb.inmet.com> wrote:
>As a small anecdote here relating to the "op=" operations of C, 
>my most recent "favorite" bug in C code I was writing was in the following:
>
>  if (a /= b) {
>    ...
>  }

Ouch.

But I don't blame this on the existence of the shorthand notation.
I blame it on (1) the fact that the assignment operators like /=
return a value, and (2) the fact that there is no separation between
boolean and integer types.  If (1) were fixed, the problem would
go away, and if (2) were fixed, the problem would be extremely
rare.

>At this point Dave Emery comes on and asks me why in the world
>I am writing any code in C... ;-}

Indeed.  ;-)

- Bob

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[John G. Volan]

Rober Dewar said:

>John said
>
>"Horrors! This assumes that Standard.Integer subsumes all possible ranges
>of 'Pos values for all discrete types (enumeration, integer, modular).
>A very dubious assumption!  What about Long_Long_Integer?  The long-term
>reusability of this package is problematic."
>
>Nope, not horrors at all. Increment should mean increment, not add, if
>you want to add, please use the + operator which is just fine for
>this purpose.

Oh, for goodness sake, Robert, are you quibbling over terminology?
Forget the identifiers I happened to choose, what do you think the C
operators += and -= mean?  Maybe I should have reserved the names
"Increment" and "Decrement" as analogs for "++" and "--" only, and not
overloaded them as analogs for "+=" and "-=" too.  Perhaps I should
have used "Increase" and "Decrease" for the latter instead, since
clearly "Increment" and "Decrement" carry the connotation of
adding/subtracting an "incremental" (i.e., "small") amount.

>I think it actively HELPS maintainability that increment accepts only
>small positive values.

Hardly.  The trouble with Robert Eachus's version, e.g.:

>    type Item is (<>);
...
>    procedure Increment (This : in out Item; By: in Positive) is
>    begin
>      This := Item'Val(Item'Pos(This) + By);
>    end Increment;

is that it doesn't just limit the "By" parameter to Standard.Positive,
it also limits the "This" parameter to possibly a relatively small
range of the Item type.  But this is not explicit -- the user will
discover it only by accident, when the "This" parameter happens to have
a position number beyond the range of Standard.Integer, so that the
call to Item'Pos blows up with Constraint_Error.  Perhaps if Robert
Eachus wanted to make this limitation more explicit, he should have
done:

  generic
    type Item is (<>);
  package Discrete_Arithmetic is

    subtype Addable is Item range
        Item'Val (Integer'Max (Integer'First, Item'Pos(Item'First))) ..
        Item'Val (Integer'Min (Integer'Last,  Item'Pos(Item'Last)));
        
    procedure Increase (This : in out Addable; By : in Positive);
    procedure Decrease (This : in out Addable; By : in Positive);
    ...
  end Discrete_Arithmetic;

Now _that_ would have been "truth in advertising."  But this is silly.
IMHO, Robert Eachus goes too far in trying to use a _single_ generic to
define analogs for += and -= universally for all _discrete_ types,
including enumerated types.  Being able to "increment" or "decrement"
an enumerated value beyond its immediate successor or predecessor might
be an interesting capability, but does it justify cluttering things up
for the integer and modular cases?  Considering the latter, why would
anyone want to take a variable of their own particular integer or
modular type and add/subtract a value of a _different_ integer type
(namely Standard.Integer)?  In Robert Dewar's terms, I think Robert
Eachus' generalization is a _confusion_, rather than a _unification_,
of the concept of numeric addition/subtraction. When designing
generics, it is all too easy to fall into the trap of being _overly_
general.

I believe it would be much, much simpler to just define the "Increase"
and "Decrease" procedures in terms of an Item type for which "+" and
"-" are already defined, and simply have done with it:

    procedure Increase (This : in out Item; By : in Item) is
    begin
        This := This + By;
    end Increase;
    
    procedure Decrease (This : in out Item; By : in Item) is
    begin
        This := This - By;
    end Decrease;
    
That's not a problem if Item is a generic formal _numeric_ type -- i.e.,
one of the following that I had before:

    generic
        type Item is range <>; -- generic formal integer type
    package Integer_Arithmetic is ...
    
    generic
        type Item is mod <>; -- generic formal modular type
    package Modular_Arithmetic is ...
    
    generic
        type Item is digits <>; -- generic formal floating-point type
    package Floating_Arithmetic is ...
    
    generic
        type Item is delta <>; -- generic formal fixed-point type
    package Fixed_Arithmetic is ...
    
With these in place, we could then do something like, oh, I dunno, say:

    type Simulation_Coordinate is range -10_000 .. +10_000;
    package Simulation_Coordinate_Arithmetic is
        new Integer_Arithmetic (Simulation_Coordinate);
    use Simulation_Coordinate_Arithmetic;
    ...

    for The_Simulation_Step in Simulation_Step loop
        ...
        for Target_Index in Target_Table'Range loop
            ...

            Increase (Target_Table(Target_Index).Current_X,
                By => Target_Table(Target_Index).Delta_X_Per_Step);
             
            Increase (Target_Table(Target_Index).Current_Y,
                By => Target_Table(Target_Index).Delta_Y_Per_Step);
             
            -- Note: deltas are _not_ necessarily positive for every
            -- target.  Targets might be moving in any direction.
            
            ...
         end loop;
        ...
    end loop;
    
IMHO, this is more readable, and less error-prone than, say:

            Target_Table(Target_Index).Current_Y :=
                Target_Table(Target_Index).Current_X +
                Target_Table(Target_Index).Delta_Y_Per_Step;
                
Whoops!  Gosh, what I _really_ meant to say was:

            Target_Table(Target_Index).Current_Y :=
                Target_Table(Target_Index).Current_Y +
                Target_Table(Target_Index).Delta_Y_Per_Step;

;-)

>I also think that the extnsion of these operators, dubious in the first
>place, to weird cases like mod is a disservice. I can put up with += in
>C but I find the use of things like %= and ^= to be tortured syntax,
>which I prefer NOT to import in any case.

Nobody is advocating C's tortured syntax.  All we're doing here is
coming up with a (partial) analogy, in Ada, for the _semantics_ of
these operations.  There is absolutely no reason to suppose that the
analogous Ada procedures would be "tortured" at all.  (Note that I'm
calling these a _partial_ analogy for C's op= functions.  The Ada
analogs I'm suggesting are _procedures_ with side effects, not
_functions_ with side effects -- now _that_ would be a truly tortured
concept).

A procedure called "Modulo" that reduces a variable to its modulo after
division, and a procedure called "Remainder" that reduces a variable to
its remainder after division, seem to me to be just as understandable,
and just as well justified (as far as that goes) as, say, "Increase",
"Decrease", "Multiply", and "Divide".

I could just as easily argue that it was "tortured syntax" to invent
special infix operator functions for "mod" and "rem" in the first
place.  Why didn't the original designers of Ada simply do these as
ordinary functions, or perhaps attribute functions?  Well, whatever the
reasons, the fact remains that they _do_ exist, and have become well
accepted, and are considered analogous to + - * / .  So, _if_, I say,
_if_ we're going to supply side-effect-procedure versions for + - * /,
then why not, by analogy, do the same for mod and rem?

>I still think the whole business is a tempest in a teapot, and do not think
>that the use of any of these packages helps in reading, maintaining, or
>even writing code.

Well, you know, Robert, I'm half inclined to agree with you (I've done a
lot of declare-blocks-with-renaming-declarations in my time), but I'm
not prepared to stand on my pulpit and preach to the vast unwashed mass
of C and C++ programmers (and maybe COBOL programmers too) that their
precious side-effect arithmetic operations are not fit for mortal ken.
I'm not going to tell them that they can either accept "the One True
Ada Way" or they can just march their little fannies right out of our
congregation, thank you very much! I'd much rather tell them that, yes,
they can get what they want out of Ada, if they really need it, and
here's a safe and easy way to do it.  I think it's much more prudent to
take people like that and turn them _on_ to Ada _first_ -- and _then_
try to gently persuade them that one of their cherished idioms might
not be so essential as they thought.

Unless (heaven forfend!) that idiom might have some merit after all ...

In an earlier post, Robert Dewar writes:

>Only a true lover of verbosity could like increment(item) which is longer
      ^^^^^^^^^^^^^^^^^^^^^^^^^
      (And to whom might you be referring, hmmm?  :-)  Would the 
      immortal Professor Dewar engage in cheap shots?  Nooooo...)
>than either
>
>(a) the standard Ada form:  item := item + 1;
>
>(b) the COBOL form (!)  add 1 to item

It's pointless to compare this with the COBOL form, since we're talking
about what's possible within the syntax of Ada.  But as for Ada syntax,
hmmm, let's see.  It looks like

    Increment (Reasonably_Readable_Variable);
    
has a cost of 1*N+13 keystrokes (where N is the length of the variable
name), whereas

    Reasonably_Readable_Variable := Reasonably_Readable_Variable + 1;
    
has a cost of 2*N+9 keystrokes.  First of all, we _all_ know that the
whole point of programming is _keystroke conservation_, yes indeedee! 
I know _I_ for one am _not_ gonna risk carpal tunnel typing in 13
keystrokes when I can get by with just 9, by gum!  And of course,
_everyone_ would agree that the constant term (13 vs 9) is _by far_ 
more important than the linear term (1*N vs 2*N).  So _of course_ the
first version is _always_ going to be longer than the second version.
Mm-hmm.  Yup.  So it's _self evident_ that only a true lover of
verbosity would prefer the first version over the second.  Mm-hmm. Yup.

(For the sarcasm impaired:  :-/   There is a difference between
gratuitous verbosity and necessary thoroughness.  There is also such a
thing as gratuitous brevity.  I object to abbreviations such as "Inc"
and "Dec" on the grounds that you would never use them in conversation,
nor would you write them in English prose.  They are too easily
confused with "Ink" and "Inc." and "Deck" and "Deque".  To me, the
extra 6 characters needed to type in "Increment" and "Decrement" are a
triviality, compared with the guarantee this gives me that my code will
be understood by anyone with a working knowledge of the English
language.  By the way, it's always bothered me that there is really no
polite way to pronounce 'Succ. :-)

{ But, u no, f u cn rd ths, u myt s wel uz C styl 4 ur prsnl ltrs! :-) }

>Of course a discussion like this always generates lots of discussion.
>Unlike abstract types, type extnsions, overriding, dispatching etc,
>everyone at least fully understands the idea of incrementing a variable :-)

Oh, sure they do, sure, sure.  And, it seems, everyone fully understands
this idea ... _differently_. :-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature
( Name => "John G. Volan", E_Mail => "John_Volan@dayton.saic.com",
  Favorite_Slogan => "Ada95: The *FIRST* International-Standard OOPL",
  Humorous_Disclaimer => "These opinions are undefined by SAIC, so" &
    "any use would be erroneous ... or is that a bounded error now?" );
------------------------------------------------------------------------

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Robert Dewar]

John Volan said

">    procedure Increment (This : in out Item; By: in Positive) is
>    begin
>      This := Item'Val(Item'Pos(This) + By);
>    end Increment;

is that it doesn't just limit the "By" parameter to Standard.Positive,
it also limits the "This" parameter to possibly a relatively small
range of the Item type."

Well I can't get particularly upset by that , but if you are, just
change this to Item'Val (Item'Pos(This) + Positive'Pos (By)).

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Robert I. Eachus]

   Bob Duff (bobduff@world.std.com) said:

  > Using Increment instead of "++" isn't going to make the program horribly
  > verbose.  My complaint is that people are suggesting a generic
  > instantiation, which is a bunch of useless verbosity, to replace
  > something that's very simple in C...

  > If you try to convince a C programmer to change "foo[i]++;" to
  > "Increment(Foo(I));", that's fine.  But to require a generic
  > instantiation in addition would make the C programmer laugh, and rightly
  > so.  I think we'd be better off just admitting that there's no direct
  > replacement for ++ in Ada, and tell the programmer, "Sorry, but you have
  > to write "Foo(I) := Foo(I) + 1;".

    No, I think we are converging to the "right" solution...  You
object, and I think rightly, to asking programmers to instantiate a
generic to get Increment for integer types.  Would you settle for a
use clause?  I beginning to conclude that the right solution for
Integer is a non-generic package.  For enumeration types, you need a
generic, but then again, any enumeration type you want the operations
for will already require a declaration.  Adding another line seems
acceptable.

    The only question that now remains is does it make sense to have
an "extended" Integer type with additional operations that can be
derived from?  Possibly, but I don't think the major need for such a
type is to provide increment and decrement.  It is needed for mixed
mode operations found in some C programs that combine logical bitwise
operations, shifts, SIGNED arithmetic, and ignoring of overflow.  A
very special type, and in Ada 95, quite easy to build.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Robert A Duff]

In article <4j7dcl$dfu@dayuc.dayton.saic.com>,
John G. Volan  <John_Volan@ccmail.dayton.saic.com> wrote:
>...To me, the
>extra 6 characters needed to type in "Increment" and "Decrement" are a
>triviality, compared with the guarantee this gives me that my code will
>be understood by anyone with a working knowledge of the English
>language....

Pardon my saying so, but that's complete nonsense.  You can't understand
Ada programs without understanding the semantics of Ada, whether or not
your identifiers are verbose or terse.  Furthermore, it is completely
irrelevant whether random folks off street can understand your Ada code.
What matters is whether a professional programmer, who knows the
language, can understand the code well enough to modify it without
breaking it.

By the way, a C programmer would laugh at this whole conversation.  The
C programmer wants to say foo++, and we Ada folks start rambling on
about generic instantatiations and other complicated gobbledegook.
Sheesh.

- Bob

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Tore Joergensen]

Robert A Duff (bobduff@world.std.com) wrote:
: Pardon my saying so, but that's complete nonsense.  You can't understand
: Ada programs without understanding the semantics of Ada, whether or not
: your identifiers are verbose or terse.  Furthermore, it is completely
: irrelevant whether random folks off street can understand your Ada code.

Partly true. You can't start changing the code without knowing the language,
but it isn't allways true that you can't get a fairly good idea about how
the program works without knowing the language, if the language/identifiers
are close to English (or another human language). This may or may not be
important, depending on the project. 

: What matters is whether a professional programmer, who knows the
: language, can understand the code well enough to modify it without
: breaking it.

This is of course important, but in some cases it will also be important
that people that cooperate with you (which may not be a programmer, or
at least not an Ada-programmer) can get a fairly good understanding
of what the program does. Of course the documentation will do most of that
job, but readable code doesn't hurt :-).
-- 
+-------------------------+-------------------------------------------+
| Tore B. Joergensen      | e-mail : tore@lis.pitt.edu                |
| Centre Court Villa      | web    : http://www.pitt.edu/~tojst1      |
| 5535 Centre Avenue # 6  |                                           |
| Pgh, PA 15232, USA      | Norwegian MSIS-student at Univ. of Pgh.   |
+-------------------------+-------------------------------------------+

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[John G. Volan]

In article <dewar.827845699@schonberg> Robert Dewar, dewar@cs.nyu.edu writes:
>John Volan said
>
>>    procedure Increment (This : in out Item; By: in Positive) is
>>    begin
>>      This := Item'Val(Item'Pos(This) + By);
>>    end Increment;
>
>is that it doesn't just limit the "By" parameter to Standard.Positive,
>it also limits the "This" parameter to possibly a relatively small
>range of the Item type."
>
>Well I can't get particularly upset by that , but if you are, just
>change this to Item'Val (Item'Pos(This) + Positive'Pos (By)).

Okay, that leaves the exact type returned by the 'Pos functions
ambiguous, but what does Ada95 do in that case?  Does it just default
to Standard.Integer anyway?  (In that case, your answer doesn't really
solve the problem.) Or can the compiler pick an integer type that's big
enough?  Or does this simply cause a compilation error?

Anyway, I don't have much objection to this operation if it's limited
to enumerated types, since the supported range of Standard.Integer on a
given implementation is likely to correspond to the supported range of
positions for an enumerated type on the same implementation. (Is the word
"likely" correct, or does Ada95 provide a stronger guarantee of this?)

But this operation is really of marginal utility for enumerated types
anyway. And when applied to an integer or modular type, it's downright
silly. Why would anyone want the second parameter to be
Standard.Integer, when it could just be their own Item type, which is
so much more simple and straightforward?  In light of that, why do we
need to keep propping up this 'Pos/'Val technique with ever more
complicated encrustations?

------------------------------------------------------------------------
Internet.Usenet.Put_Signature
( Name => "John G. Volan", E_Mail => "John_Volan@dayton.saic.com",
  Favorite_Slogan => "Ada95: The *FIRST* International-Standard OOPL",
  Humorous_Disclaimer => "These opinions are undefined by SAIC, so" &
    "any use would be erroneous ... or is that a bounded error now?" );
------------------------------------------------------------------------

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Tucker Taft]

John G. Volan (John_Volan@ccmail.dayton.saic.com) wrote:
: In article <dewar.827845699@schonberg> Robert Dewar, dewar@cs.nyu.edu writes:
: >John Volan said
: >
: >>    procedure Increment (This : in out Item; By: in Positive) is
: >>    begin
: >>      This := Item'Val(Item'Pos(This) + By);
: >>    end Increment;
: >
: >is that it doesn't just limit the "By" parameter to Standard.Positive,
: >it also limits the "This" parameter to possibly a relatively small
: >range of the Item type."
: >
: >Well I can't get particularly upset by that , but if you are, just
: >change this to Item'Val (Item'Pos(This) + Positive'Pos (By)).

: Okay, that leaves the exact type returned by the 'Pos functions
: ambiguous, but what does Ada95 do in that case?  Does it just default
: to Standard.Integer anyway?  (In that case, your answer doesn't really
: solve the problem.) Or can the compiler pick an integer type that's big
: enough?  Or does this simply cause a compilation error?

The 'Pos attribute returns a value of type universal_integer,
which is implicitly convertible to any integer type.  Given that
you are adding it to a value of subtype Positive, it will be
converted to Integer (since Positive is a subtype of Integer).
See RM95 3.5.5(4), 8.6(24), 6.4.1(11).

: ( Name => "John G. Volan", E_Mail => "John_Volan@dayton.saic.com",

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Robert Dewar]

Robert/John/Tuck said

": >Well I can't get particularly upset by that , but if you are, just
: >change this to Item'Val (Item'Pos(This) + Positive'Pos (By)).

: Okay, that leaves the exact type returned by the 'Pos functions
: ambiguous, but what does Ada95 do in that case?  Does it just default
: to Standard.Integer anyway?  (In that case, your answer doesn't really
: solve the problem.) Or can the compiler pick an integer type that's big
: enough?  Or does this simply cause a compilation error?

The 'Pos attribute returns a value of type universal_integer,
which is implicitly convertible to any integer type.  Given that
you are adding it to a value of subtype Positive, it will be
converted to Integer (since Positive is a subtype of Integer).
See RM95 3.5.5(4), 8.6(24), 6.4.1(11)."

Sorry Tuck, I don't see this, I am adding two universal integer types here
seems clear to me that this addition is done in universal integer, i.e.
the longest possible integer type at runtime, and then converted to
Item type. Please enlighten me as to why you feel otherwise, I don't
see any "value of subtype Postive" in my expression!

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Tucker Taft]

Robert Dewar (dewar@cs.nyu.edu) wrote:
: Robert/John/Tuck said

: ": >Well I can't get particularly upset by that , but if you are, just
: : >change this to Item'Val (Item'Pos(This) + Positive'Pos (By)).

: : Okay, that leaves the exact type returned by the 'Pos functions
: : ambiguous, but what does Ada95 do in that case?  Does it just default
: : to Standard.Integer anyway?  (In that case, your answer doesn't really
: : solve the problem.) Or can the compiler pick an integer type that's big
: : enough?  Or does this simply cause a compilation error?

:   The 'Pos attribute returns a value of type universal_integer,
:   which is implicitly convertible to any integer type.  Given that
:   you are adding it to a value of subtype Positive, it will be
:   converted to Integer (since Positive is a subtype of Integer).
:   See RM95 3.5.5(4), 8.6(24), 6.4.1(11)."

: Sorry Tuck, I don't see this, I am adding two universal integer types here
: seems clear to me that this addition is done in universal integer, i.e.
: the longest possible integer type at runtime, and then converted to
: Item type. Please enlighten me as to why you feel otherwise, I don't
: see any "value of subtype Postive" in my expression!

Oops!  I was reading the original line of "Item'Pos(This) + By" instead
of the suggested replacement.  In the suggested replacement,
where both operands are the result of 'Pos, the "preference"
rule for root numeric types (8.6(14)) will mean that they will both
be converted to root_integer, whose run-time base range is
defined to be System.Min_Int .. System.Max_Int.
See RM95 8.6(29) and 3.5.4(14).

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Tucker Taft]

Tucker Taft (stt@henning.camb.inmet.com) wrote:

: Oops!  I was reading the original line of "Item'Pos(This) + By" instead
: of the suggested replacement.  In the suggested replacement,
: where both operands are the result of 'Pos, the "preference"
: rule for root numeric types (8.6(14)) will mean that they will both

Oops oops -------------------------^^ should be (29)

: be converted to root_integer, whose run-time base range is
: defined to be System.Min_Int .. System.Max_Int.
: See RM95 8.6(29) and 3.5.4(14).

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[John G. Volan]

In article <DovoDs.3ML@world.std.com> Robert A Duff, bobduff@world.std.com
writes:
>Pardon my saying so, but that's complete nonsense.  You can't understand
>Ada programs without understanding the semantics of Ada, whether or not
>your identifiers are verbose or terse.  Furthermore, it is completely
>irrelevant whether random folks off street can understand your Ada code.
>What matters is whether a professional programmer, who knows the
>language, can understand the code well enough to modify it without
>breaking it.

Then why did we ever bother with any of the identifiers on the left
below, when the more terse identifiers on the right would have done
"just as well" ... as long as you happened to be a member of that
select coterie known as "professional programmers":

    Ada Identifier          Gratuitous Abbreviation
    --------------          -----------------------
    Standard                Std
    Integer                 Int
    Interfaces              Int [sic]
    Natural                 Nat
    Positive                Pos
    Pos [sic]               Pos [sic]
    Value                   Val
    Val [sic]               Val [sic]
    Image                   Img
    Boolean                 Bool
    Character               Char
    String                  Str
    Constraint_Error        CErr
    Program_Error           PErr
    System                  Sys
    Address                 Addr
    Text_IO                 TIO
    File_Type               Ftyp
    File                    F
    Item                    I
    Width                   W
    Base                    B
    Create                  Creat [truly, truly, gratuitous]
    End_Of_File             EOF
    package                 pkg
    procedure               proc
    function                func
    generic                 gnrc
    range                   rng
    access                  ptr
    abstract                abs
    abs [sic]               abs [sic]
    is                      =
    begin                   {
    end                     }
    ... etc., etc., ad nauseum
    
Or is this whole discussion just a case of "_our_ cherished
abbreviations (Inc, Dec) are things of ineffable beauty, but _those_
abbreviations are utter abominations"?

(BTW, 'SUCC 'SUCCs :-) )

>By the way, a C programmer would laugh at this whole conversation.

Let 'em laugh.  Let them use their cryptic terse language, and let them
adopt the cryptic terse style their cowboy culture favors.  It makes no
never mind to me.

But for better or for worse, Ada is (for the most part) a less terse
language.  More importantly, the culture behind Ada tends to favor
saying what you mean as plainly as possible, so that _intelligent_
people (not necessarily language experts) have a better chance of
reading it straight. Ada culture does not tend to promote the invention
of ad hoc "codes" that only the initiated can decipher. If that
philosophy means you have to type in a few more keystrokes, well,
keystrokes are cheap.  Misunderstanding can be expensive.

It's amazing to me that the same people who whine about a few measly
keystrokes in a piece of code do not seem to have such a problem
spelling the same words out completely when they're writing something
for a human being to read (especially if it happens to be their boss :-).

What's wrong with my last sentence?  Yeah, software's ment to be read
by human beings, too.

>The C programmer wants to say foo++ ...

Ada programmer [Socratically]: "You want to do a "++"?  Hmm, that's
cryptic to me..."  [Winks knowingly at the other Ada programmers.]
"What exactly do you _mean_ by this, um, "++" thing?  What are you
actually trying to _do_?"

C programmer doing Ada: "Um, well, see, I don't want to have to do a lot
of cutting and pasting of these variable names here just so I can do
"+".  I'm just trying to increment them..."

Ada programmer: "Ah, so you want to _increment_.  So it must mean that
you want" [pregnant pause] "an _Increment_ procedure, right?"

C programmer [feeling a little stupid]:  "Gee, now that you put it that
way, I guess so."

Ada programmer [jovially]: "Well, why didn't you say so in the first
place?  No problem, here's how you can get one..."

[Then again, folks, Socrates was not well-liked... :-) ]

>... and we Ada folks start rambling on
>about generic instantatiations and other complicated gobbledegook.
>Sheesh.

Hey, don't look at me.  My generics were about as inanely
direct as I could make them. It's other folks that keep
advocating gooping them up with complex agglomerations of 'Pos and
'Val and what-not, just to get some marginal extra capabilities.

But you don't like a generic as a workaround at all?  Alright, suggest
something better, maybe even an Ada0X improvement, if you think it's
warranted. Just don't tell me the answer is: "Either thou must accept
the received perfection of Ada95 as it is, or thou mayst as well become
a C programmer". Sheesh indeed.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature
( Name => "John G. Volan", E_Mail => "John_Volan@dayton.saic.com",
  Favorite_Slogan => "Ada95: The *FIRST* International-Standard OOPL",
  Humorous_Disclaimer => "These opinions are undefined by SAIC, so" &
    "any use would be erroneous ... or is that a bounded error now?" );
------------------------------------------------------------------------

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Robert A Duff]

In article <4jchbi$ep0@dayuc.dayton.saic.com>,
John G. Volan  <John_Volan@ccmail.dayton.saic.com> wrote:
>In article <DovoDs.3ML@world.std.com> Robert A Duff, bobduff@world.std.com
>writes:
>>Pardon my saying so, but that's complete nonsense.  You can't understand
>>Ada programs without understanding the semantics of Ada, whether or not
>>your identifiers are verbose or terse.  Furthermore, it is completely
>>irrelevant whether random folks off street can understand your Ada code.
>>What matters is whether a professional programmer, who knows the
>>language, can understand the code well enough to modify it without
>>breaking it.
>
>Then why did we ever bother with any of the identifiers on the left
>below, when the more terse identifiers on the right would have done
>"just as well" ... as long as you happened to be a member of that
>select coterie known as "professional programmers":

Because using zillions of strange abbreviations makes the code harder to
understand, FOR PROFESSIONAL PROGRAMMERS.  My point is just that this
has nothing to do with making the code understandable by random folks
off the street -- that's clearly impossible.  You cannot understand any
substantial Ada program if you don't know Ada -- and using nice
un-abbreviated identifiers won't change that fact.

>    Ada Identifier          Gratuitous Abbreviation
>    --------------          -----------------------
>..[various examples deleted]
>    Create                  Creat [truly, truly, gratuitous]

Yeah, that's a particularly bad one!

>Or is this whole discussion just a case of "_our_ cherished
>abbreviations (Inc, Dec) are things of ineffable beauty, but _those_
>abbreviations are utter abominations"?

Using Increment instead of "++" isn't going to make the program horribly
verbose.  My complaint is that people are suggesting a generic
instantiation, which is a bunch of useless verbosity, to replace
something that's very simple in C.

>But for better or for worse, Ada is (for the most part) a less terse
>language.  More importantly, the culture behind Ada tends to favor
>saying what you mean as plainly as possible, so that _intelligent_
>people (not necessarily language experts) have a better chance of
>reading it straight.

No, I disagree.  I don't care if people who don't know Ada can't read
Ada.  Of course they can't.  I want Ada to be readable so that people
who *do* know it can read it.  (And, of course, it's always a good idea
if the language is simple enough, so that people who *don't* know it can
*learn* it.)

>.. Ada culture does not tend to promote the invention
>of ad hoc "codes" that only the initiated can decipher. If that
>philosophy means you have to type in a few more keystrokes, well,
>keystrokes are cheap.  Misunderstanding can be expensive.

Agreed.

>[Then again, folks, Socrates was not well-liked... :-) ]

For good reason!  ;-)

>>... and we Ada folks start rambling on
>>about generic instantatiations and other complicated gobbledegook.
>>Sheesh.
>
>Hey, don't look at me.  My generics were about as inanely
>direct as I could make them.

My point is that they're not (and cannot be) "inanely direct" *enough*.
If you try to convince a C programmer to change "foo[i]++;" to
"Increment(Foo(I));", that's fine.  But to require a generic
instantiation in addition would make the C programmer laugh, and rightly
so.  I think we'd be better off just admitting that there's no direct
replacement for ++ in Ada, and tell the programmer, "Sorry, but you have
to write "Foo(I) := Foo(I) + 1;".

>... It's other folks that keep
>advocating gooping them up with complex agglomerations of 'Pos and
>'Val and what-not, just to get some marginal extra capabilities.

Yeah, I was complaining about that, too.

>But you don't like a generic as a workaround at all?  Alright, suggest
>something better, maybe even an Ada0X improvement, if you think it's
>warranted.

I did suggest a different workaround, using derived types.  Also, an
earlier version of Ada 9X had an even better solution (IMHO): you could
declare a procedure Increment, which would work on any integer type,
without cluttering up your program with generic instantiations.  The
generic solution just isn't worth it -- all I want to do is add 1 to a
variable.

>...Just don't tell me the answer is: "Either thou must accept
>the received perfection of Ada95 as it is, or thou mayst as well become
>a C programmer". Sheesh indeed.

OK, I won't tell you that -- I don't believe it.

- Bob

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[John G. Volan]

In article <Dp1Gxq.15M@world.std.com>
Robert A Duff, bobduff@world.std.com writes:

>In article <4jchbi$ep0@dayuc.dayton.saic.com>,
>John G. Volan  <John_Volan@ccmail.dayton.saic.com> wrote:
...
>>Then why did we ever bother with any of the identifiers on the left
>>below, when the more terse identifiers on the right would have done
>>"just as well" ... as long as you happened to be a member of that
>>select coterie known as "professional programmers":
>
>Because using zillions of strange abbreviations makes the code harder to
>understand, FOR PROFESSIONAL PROGRAMMERS.  

On this, we seem to be in violent agreement. :-)

>My point is just that this
>has nothing to do with making the code understandable by random folks
>off the street -- that's clearly impossible.  You cannot understand any
>substantial Ada program if you don't know Ada -- and using nice
>un-abbreviated identifiers won't change that fact.

I take your point, and I'm sorry I glossed over it before -- I thought
Tore Joergensen already did a good job of responding to this.  I agree
with Tore that (1) yes, you're right, it does take more than just a
working knowledge of English to fully understand an Ada program, or at
least to understand it enough to do maintenance on it; but (2) not
everyone who is involved in the development of software is necessarily
a professional programmer that's doing the actual coding. IMHO, the
fewer obstacles to understanding we put in the way of these associated
folks, the better things will be all around.  But perhaps that's a
minor point.

Let me turn your argument around another way:  Even a professional
programmer doesn't start out as one.  There is some point in the
education of every professional programmer where a "random person off
the street" gets their first introduction to programming concepts and
computer languages. Usually, this happens at least a decade after that
person first learns to read and write their own natural language.  (At
least, at this stage in human history.) IMHO, anyone with reasonably
good literacy skills should have a decent chance of becoming a
software engineer.

But I'm afraid that, as you so aptly put it, "zillions of _strange_
abbreviations" [my emphasis] do a lot to get in the way of that
happening.  I suspect that many intelligent people who might have made
important contributions to our field were turned off to the whole idea,
simply because of the obscurely cryptic nature of so much of the code
that's written these days. This is a shame, because I strongly believe
that this ad hoc crypticness is totally gratuitous -- there is nothing
fundamentally inherent in software that requires it to be obscure and
obfuscated, and it only tends to be that way for _cultural_, not
_technical_ reasons.

So the playing field is ceded to two groups of individual: (1) Those who
eagerly embrace and perversely thrive on ad-hoc crypticness, in the
extreme case even _promoting_ it as a cynical guarantee of their job
security -- to whit, hackers (spit, spit); and (2) those stalwart few
who can overcome the hurdles set up by the hackers, and through
fortitude and perserverance learn to talk to computers, without
forgetting how to talk to people. Things are getting better, but I'm
afraid that the latter group is still a minority.

...
>I want Ada to be readable so that people
>who *do* know it can read it.  (And, of course, it's always a good idea
>if the language is simple enough, so that people who *don't* know it can
>*learn* it.)
...

Hmm ... I think in retrospect you actually agreed with the point I just
made! :-)

...
>Using Increment instead of "++" isn't going to make the program horribly
>verbose.  My complaint is that people are suggesting a generic
>instantiation, which is a bunch of useless verbosity, to replace
>something that's very simple in C.
...
>>Hey, don't look at me.  My generics were about as inanely
>>direct as I could make them.
>
>My point is that they're not (and cannot be) "inanely direct" *enough*.
>If you try to convince a C programmer to change "foo[i]++;" to
>"Increment(Foo(I));", that's fine.  But to require a generic
>instantiation in addition would make the C programmer laugh, and rightly
>so.  I think we'd be better off just admitting that there's no direct
>replacement for ++ in Ada, and tell the programmer, "Sorry, but you have
>to write "Foo(I) := Foo(I) + 1;".

Oh, I don't think it's as bad as all that.  Instantiating a generic
isn't all _that_ big a deal, and for beginners it can simply be an
incantation that they can come to understand later.  But perhaps you
have a point that something as "simple" as side-effect arithmetic
shouldn't warrant a generic -- but where do you draw the line at
"simple"?  Is I/O too "simple" to warrant having to instantiate
Text_IO's generic subpackages; should we have had something analogous
to printf instead? Is deallocating a heap object too "simple" to
warrant having to instantiate Unchecked_Deallocation, or should we have
had a built-in free or delete operation? Is breaking the strong typing
system when you need to too "simple" to warrant having to instantiate
Unchecked_Conversion, or should Ada have just allowed arbitrary type
conversions?  These are all things an arrogant C-fanatic might
conceivably laugh at, but I think we Ada programmers ought to have
thick enough skins not to let that bother us.

...
>>But you don't like a generic as a workaround at all?  Alright, suggest
>>something better, maybe even an Ada0X improvement, if you think it's
>>warranted.
>
>I did suggest a different workaround, using derived types.

Yes, that's a good technique, one that I've actually used in my own
code, now that I think about it.  More people should realize that any
sort of type, even scalar types, can be endowed with new _primitive_
subprograms which can be _inherited_ by derived types.  This was true
even in Ada83.  For all that Ada83 was branded as an "object based"
language, but not an "object oriented" language, people should give
Ada83 credit for actually having _inheritance_, even though it didn't
have Ada95's mechanisms for type-extension and classwide polymorphism.

...
>>...Just don't tell me the answer is: "Either thou must accept
>>the received perfection of Ada95 as it is, or thou mayst as well become
>>a C programmer". Sheesh indeed.
>
>OK, I won't tell you that -- I don't believe it.

I'm glad of that! :-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature
( Name => "John G. Volan", E_Mail => "John_Volan@dayton.saic.com",
  Favorite_Slogan => "Ada95: The *FIRST* International-Standard OOPL",
  Humorous_Disclaimer => "These opinions are undefined by SAIC, so" &
    "any use would be erroneous ... or is that a bounded error now?" );
------------------------------------------------------------------------

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[AdaWorks]

John G. Volan (John_Volan@ccmail.dayton.saic.com) wrote:
 
 [snip, snip, snip]

: ...  (1) yes, you're right, it does take more than just a
: working knowledge of English to fully understand an Ada program, or at
: least to understand it enough to do maintenance on it; 

  One of the better reasons to use C.  One could imagine coding C in
  Japanese using Kanji. The brevity of C notation makes it representable
  in the language symbols of Arabic, Thai, Greek, Sanskrit, Burmese,
  Hebrew, Russian, and others that do not derive from some variant 
  of the Western European alphabet.  

  I wonder if the same thing can the same be said of Eiffel, Ada, Smalltalk, 
  etc?  It seems to me that most of the high-order programming 
  languages are heavily dependent on a Euro-centric alphabet whereas
  the underlying programing ideas are not. Certainly, Ada has improved 
  with regard to its internationalization.  However, a more symbolic
  language - a universal assembler - such as C comes closer to the 
  culture-independent model that makes complex  mathematical notations
  comphrehensible in academic institutions all over this tiny planet, 
  from Cambodia to Sweden, from Iceland to Osaka.

  My copies of the Japanese and Chinese Ada Reference Manual show quite
  clearly that Ada 83 was somewhat provincial. Although the
  explanatory text for each manual is in the language of the culture, the 
  Ada program examples are in English.  

  Richard Riehle
  adaworks@netcom.com



  

  
-- 

richard@adaworks.com
AdaWorks Software Engineering
Suite 27
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815
FAX  328-1112

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Robert A Duff]

In article <4jkfpj$jl1@dayuc.dayton.saic.com>,
John G. Volan  <John_Volan@ccmail.dayton.saic.com> wrote:
>...but (2) not
>everyone who is involved in the development of software is necessarily
>a professional programmer that's doing the actual coding. IMHO, the
>fewer obstacles to understanding we put in the way of these associated
>folks, the better things will be all around.  But perhaps that's a
>minor point.

OK, fair enough.  Perhaps I shoudn't have been so strident in my earlier
post.  But let's not go from the above, to trying to sell Ada by saying
it's so "self documenting" that anybody can understand it.

>Oh, I don't think it's as bad as all that.  Instantiating a generic
>isn't all _that_ big a deal, and for beginners it can simply be an
>incantation that they can come to understand later.  But perhaps you
>have a point that something as "simple" as side-effect arithmetic
>shouldn't warrant a generic -- but where do you draw the line at
>"simple"?  Is I/O too "simple" to warrant having to instantiate
>Text_IO's generic subpackages; should we have had something analogous
>to printf instead?

Well, I don't know.  It *is* a problem for teaching Ada, to have to
introduce generic instantiations very early.  It's true that you can
just tell the beginner to type some magic incantation, and that's what
everybody does, but it makes the beginner uncomfortable.  The beginner
wants to understand everything in the program.

I wouldn't advocate printf, though -- it is inherently type unsafe.
Other solutions are possible.

Of course, Ada 95 has predefined instantiations for type Integer and so
forth.  And there's always 'Image.

>...Is deallocating a heap object too "simple" to
>warrant having to instantiate Unchecked_Deallocation, or should we have
>had a built-in free or delete operation?

No, I don't think so.

>... Is breaking the strong typing
>system when you need to too "simple" to warrant having to instantiate
>Unchecked_Conversion, or should Ada have just allowed arbitrary type
>conversions?

No, certainly not.

>Yes, that's a good technique, one that I've actually used in my own
>code, now that I think about it.  More people should realize that any
>sort of type, even scalar types, can be endowed with new _primitive_
>subprograms which can be _inherited_ by derived types.  This was true
>even in Ada83.  For all that Ada83 was branded as an "object based"
>language, but not an "object oriented" language, people should give
>Ada83 credit for actually having _inheritance_, even though it didn't
>have Ada95's mechanisms for type-extension and classwide polymorphism.

The "brand" was pretty fair, since polymorphism is pretty important.

- Bob

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[John G. Volan]

In article <Dp1Dx7.LrI.0.-s@inmet.camb.inmet.com>
Tucker Taft, stt@henning.camb.inmet.com writes:

>In the suggested replacement,
>where both operands are the result of 'Pos, the "preference"
>rule for root numeric types (8.6(14)) will mean that they will both
>be converted to root_integer, whose run-time base range is
>defined to be System.Min_Int .. System.Max_Int.
>See RM95 8.6(29) and 3.5.4(14).

Okay, then it seems that this usage of 'Pos/'Val takes a discrete Item
type value and a Standard.Positive value, expands both to the largest
available integer size, adds them together, and then contracts the
result back down to the size of the discrete Item type. If I've got
that right, then this seems an inordinately expensive way of doing a
simple addition/subtraction operation, just to achieve generality
across all discrete types.

(Of course, if Standard.Integer and the position numbers for Item type
both already happen to correspond to the largest available integer type
on your implementation, then no expansion and contraction would be
done.  But these days typically Standard.Integer is 32 bits and
Standard.Long_Long_Integer is 64 bits, at least with most GNAT ports
I've seen.)

If we're going to do this for enumerated types, then I'd just assume
stick with the original formula of:

    Item'Val(Item'Pos(This) + By)
    
which would wind up using the "+" for Standard.Integer.  As I understand
it, whatever range you get for Standard.Integer is guaranteed to be
implemented optimally well on whatever target architecture you're
compiling for, and that range should correspond to what's possible for
enumerated types.

For an integer or modular Item type, I'd favor the more direct approach
of using whatever "+"/"-" operator that type happened to have, and just
let both parameters of the procedure be that type, as I described in
the Integer_Arithmetic and Modular_Arithmetic packages.

Same deal for Floating_Arithmetic and Fixed_Arithmetic, by the way.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature
( Name => "John G. Volan", E_Mail => "John_Volan@dayton.saic.com",
  Favorite_Slogan => "Ada95: The *FIRST* International-Standard OOPL",
  Humorous_Disclaimer => "These opinions are undefined by SAIC, so" &
    "any use would be erroneous ... or is that a bounded error now?" );
------------------------------------------------------------------------

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[John G. Volan]

In article <EACHUS.96Mar25144123@spectre.mitre.org> 
Robert I. Eachus, eachus@spectre.mitre.org writes:

>    I felt that the range of Integer is large enough for most uses.
>In general I expect this package to be used with 1) enumeration types
>2) character types 3) loop indexes and 4) string indexes.

Two points:

- (2) is just a special case of (1). I could see your procedures going
into something like the Discrete_Arithmetic package I described, but
then I think the package ought to be called Enumeration_Arithmetic, to
emphasize the intent that the actual Item type be an enumeration.
  
- (3) and (4) might be enumerated types, but when they're integer types,
they could be supported more simply and directly by the
Integer_Arithmetic package I described.  No need to mix things up by
tying everything to Standard.Integer.
  
>  > Also, why limit Increment/Decrement to Positive?  Why not allow any
>  > arbitrary integer?  The C analogs for these procedures, += and -=,
>  > carry no such limitation.
>
>   Shrug.  I guess I could be convinced to Integer, but Inc(X, -1)
>seems silly.

If the following is legal in Ada:

    X := X + (-1);
    
then why should we presume to stop a programmer from doing:

    Increase (X, By => -1);
    
no matter how silly (we think) it is? 
    
And why do you assume that the second parameter to this procedure would
always be a (small) integer _literal_?  Given that you clearly are
making that assumption, I can understand how it wouldn't really matter
to you what type the second parameter was, so Standard.Integer is as
good as anything.  But this is what I mean by your focus being too
narrow. Here's a (somewhat) realistic example that overturns your
assumption:

    -- assume these are all the same type:
    Vertical_Acceleration := Gravity; -- happens to be negative (downward)
    Vertical_Velocity := ... ; -- could begin positive but ends up negative
    Altitude := ... ;
    ...
    while Altitude > 0 loop
        ...
        -- using a fast, but admittedly non-Newtonian, approximation, and
        -- assuming 1 unit (whatever that is) elapsed time between updates:
        
        Increase (Vertical_Velocity, By => Vertical_Acceleration);
        Increase (Altitude, By => Vertical_Velocity);
        ...
    end loop;
    Put_Line (">>CRUNCH!<<"); -- :-)
    
the C equivalent being:

        Vertical_Velocity += Vertical_Acceleration;
        Altitude += Vertical_Velocity;
            
Perhaps the words "Increase" and "Decrease" carry too much of a
connotation of directionality.  Perhaps we need better identifiers than
these to convey the sense of what += and -= really do.  Anybody have
any suggestions?

But on second thought, why isn't the second parameter on the "+" and "-"
functions limited to Positive?  Doesn't "addition" carry a sense of
making a value "bigger" and "subtraction" carry a sense of making a
value "smaller"?  Yet, despite these connotations, does anybody have
any trouble with the fact that you can _add_ a negative number and
thereby generate a _smaller_ value, or _subtract_ a negative number and
thereby generate a _bigger_ value?  Or that you can add or subtract
zero and get the same value?  Does this make "+" and "-" harder to
understand and less "readable"?  Or have we all managed to internalize
all these ideas?  Well, if we can do that with "+" and "-", then what's
the problem with transferring that understanding to "Increase" and
"Decrease" (or whatever you want to call them)?  Especially if we
explain to new Ada students that "Increase" is related to "+" and
"Decrease" is related to "-", so keep in mind everything you learned in
junior-high algebra?

(By the same token, why isn't the second parameter on "*" and "/"
restricted to numbers greater than 1.0?  Isn't multiplication
supposed to "expand" a value while division "reduces" it?  But if
you apply a number between 0.0 and 1.0 (exclusive), the effects of
these operations are the exact reverse.  And, of course, multiplying
or dividing exactly by 1.0 has no effect.  But do these properties
reduce the understandability or readability of "*" and "/"?
"You may very well think so, but I could not possibly comment."
-- Daniel Urquhart :-)

[snip]
>I left out the Min and Max also, but I now think the two
>argument versions should go in, but the versions with array parameters
>complicate things too much.

Are we talking Ada83 here?  If you mean Ada95, why reinvent the wheel?
Aren't Item'Min and Item'Max adequate?  Or did you mean:

    function Minimum_Of (This, That : in Item) return Item
        renames Item'Min;
        
    function Maximum_Of (This, That : in Item) return Item
        renames Item'Max;

Or maybe you meant:

    procedure Minimize (This : in out Item; Against : in Item) is
    begin
        This := Item'Min (This, Against);
    end Minimize;
    
    procedure Maximize (This : in out Item; Against : in Item) is
    begin
        This := Item'Max (This, Against);
    end Maximize;
    
As for array versions, well, there's a lot you could put into an
Array_Arithmetic package, but let's not go overboard... :-)

...

Hmm, I just realized that I missed a couple of operators.  Maybe we
should also include:

    procedure Negate (This : in out Item) is
    begin
        This := -This;
    end Negate;
    
    procedure Absolve (This : in out Item) is
    begin
        This := abs This;
    end Absolve; -- :-)  Well, can you think of a better related verb?

Of course, there's no C analog for these, but they do fit the pattern
of avoiding an error-prone repetition of a long target variable name.
  
------------------------------------------------------------------------
Internet.Usenet.Put_Signature
( Name => "John G. Volan", E_Mail => "John_Volan@dayton.saic.com",
  Favorite_Slogan => "Ada95: The *FIRST* International-Standard OOPL",
  Humorous_Disclaimer => "These opinions are undefined by SAIC, so" &
    "any use would be erroneous ... or is that a bounded error now?" );
------------------------------------------------------------------------

Re: Ada is almost useless in embedded systems

[Robert Dewar]

John McCabe said

"If you check the detail of pragma shared, I think you'll find this
does not provide the same facilities as the C 'volatile' attribute. I
have checked this according to my compiler manual, so I do know what
I'm talking about here.

Also, as I've mentioned elsewhere, I know nothing about Ada 95, all my
comments are purely Ada 83."

This is wrong, pragma shared corresponds to pragma Atomic in Ada 95,
not to pragma Volatile (and the volatile keyword in C).

Volatile does not require atomic access and can be applied to anything.
Atomic (Shared) can only be applied to objects for which atomic access
can be guaranteed, which is likely to be very restrictive.

There is no equivalent of pragma Volatile in Ada 83.

Re: Ada is almost useless in embedded systems

[John McCabe]

dewar@cs.nyu.edu (Robert Dewar) wrote:

>John McCabe said

>"If you check the detail of pragma shared, I think you'll find this
>does not provide the same facilities as the C 'volatile' attribute. I
>have checked this according to my compiler manual, so I do know what
>I'm talking about here.

>Also, as I've mentioned elsewhere, I know nothing about Ada 95, all my
>comments are purely Ada 83."

>This is wrong, pragma shared corresponds to pragma Atomic in Ada 95,
>not to pragma Volatile (and the volatile keyword in C).

I'm sorry Robert but I don't see understand why you are saying this is
wrong. I am not suggesting here that there is a correspondence between
shared and anything to do with Ada 95.

>Volatile does not require atomic access and can be applied to anything.
>Atomic (Shared) can only be applied to objects for which atomic access
>can be guaranteed, which is likely to be very restrictive.

>There is no equivalent of pragma Volatile in Ada 83.

I do appreciate the response though as myself and Jon have also been
discussing this using email and I was going to attempt to email you
for an explanation of pragma volatile. I had a look at John Barnes'
book Programming in Ada 95 yesterday and it seems to skimp over it.

Additional detail would be appreciated on this one.


Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Ada is almost useless in embedded systems

[Robert Dewar]

pragma Volatile is identical to the volatile keyword in C. Most people, even
those who think they know C, don't accurately know the semantics of volatile,
it is a little tricky, but the informal view (don't optimize away loads
and stores) is close enough for most purposes.

Re: Ada is almost useless in embedded systems

[John McCabe]

dewar@cs.nyu.edu (Robert Dewar) wrote:

>pragma Volatile is identical to the volatile keyword in C. Most people, even
                    ^^^^^^^^^
I mentioned somewhere else that I believed the volatile qualifier in C
could be ignored by the compiler. Can youo confirm that, and if this
is true, is it the same for Ada 95?

>those who think they know C, don't accurately know the semantics of volatile,
>it is a little tricky, but the informal view (don't optimize away loads
>and stores) is close enough for most purposes.


Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Ada is almost useless in embedded systems

[Robert Dewar]

"I mentioned somewhere else that I believed the volatile qualifier in C
could be ignored by the compiler. Can youo confirm that, and if this
is true, is it the same for Ada 95?"

Volatile can only be ignored by a C compiler if it treats everything
as volatile by default, which is I suppose conceivable for a very
poor compiler, but other than this rather trivial observation I know
nothing that would justify or suggest this "belief". 

Re: Ada is almost useless in embedded systems

[Fergus Henderson]

john@assen.demon.co.uk (John McCabe) writes:

>dewar@cs.nyu.edu (Robert Dewar) wrote:
>
>>pragma Volatile is identical to the volatile keyword in C. Most people, even
>                    ^^^^^^^^^
>I mentioned somewhere else that I believed the volatile qualifier in C
>could be ignored by the compiler. Can youo confirm that, and if this
>is true, is it the same for Ada 95?

No, C and C++ compilers can't ignore the volatile qualifier.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3

Re: Ada is almost useless in embedded systems

[Ken & Virginia Garlington]

John McCabe wrote:
> That's all very well, but if you are _not_ using tasking, and your
> compiler knows this (which it obviously should), then this implies
> that this pragma is redundant - no tasks = no shared objects.

Actually, one of the things that's easy to forget in Ada is that you
are _always_ using tasking. The main program is just another task. 
Another issue is that the compiler may _not_ know you are using tasking 
when it encounters the pragma, since the task referencing the object may 
not have been compiled yet. So, I suspect that many Ada compilers don't 
do the optimization you're assuming.

> What pragma shared is _not_ is a directive to enforce no optimisation
> of an object. On the other hand, this is exactly what the C volatile
> qualifier is.

There is a distinction between shared and volatile, which is why some 
Ada 83 vendors (e.g. DEC Ada) added it as an extra pragma, and why it is 
now part of the Ada standard.

Re: Ada is almost useless in embedded systems

[Robert Dewar]

John McCabe says

"> What pragma shared is _not_ is a directive to enforce no optimisation
> of an object. On the other hand, this is exactly what the C volatile
> qualifier is."

Not quite, in particular the "exactly" here is confusing. THe exact
definition of volatile is a little tricky (but quite precise). The
meaning of "optimization" is also tricky and not at all precise.

Re: Ada is almost useless in embedded systems

[John McCabe]

dewar@cs.nyu.edu (Robert Dewar) wrote:

>John McCabe says

>"> What pragma shared is _not_ is a directive to enforce no optimisation
>> of an object. On the other hand, this is exactly what the C volatile
>> qualifier is."

>Not quite, in particular the "exactly" here is confusing. THe exact
>definition of volatile is a little tricky (but quite precise). The
>meaning of "optimization" is also tricky and not at all precise.

As far as K&RII is concerned, in the section in the back with the
annotations it explains the purpose of the volatile qualifier as being
to ensure that the compiler doesn't optimize e.g. redundant
assignments etc on a particular object.

I'll check the book when I get to work tomorrow and give you the exact
comment if you want.


Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Ada is almost useless in embedded systems

[Robert Dewar]

John says

"As far as K&RII is concerned, in the section in the back with the
annotations it explains the purpose of the volatile qualifier as being
to ensure that the compiler doesn't optimize e.g. redundant
assignments etc on a particular object."

John, get a copy of the ANSI standard if you want to discuss things at
this level. K&RII is not a full accurate description of the standard (nor
does it pretend to be!)

Any serious C programmer should (a) have a copy of the ANSI standard and
(b) know their way around it.

The same of course is true for Ada programmers.

I am not saying that people should learn the languages from the standard,
that's asking too much, but you should learn to use it as a reference,
since it is the only authoritative source for detailed semantic information
in both cases.

Re: Ada is almost useless in embedded systems

[John McCabe]

dewar@cs.nyu.edu (Robert Dewar) wrote:

>John says

>"As far as K&RII is concerned, in the section in the back with the
>annotations it explains the purpose of the volatile qualifier as being
>to ensure that the compiler doesn't optimize e.g. redundant
>assignments etc on a particular object."

>John, get a copy of the ANSI standard if you want to discuss things at
>this level. K&RII is not a full accurate description of the standard (nor
>does it pretend to be!)

I know that and I will try to get hold of the ANSI standard, however
K&RII contains a summary of the standard with annotations explaining
the reasoning behind some of the features and to this end it is very
useful.

>Any serious C programmer should (a) have a copy of the ANSI standard and
>(b) know their way around it.

>The same of course is true for Ada programmers.

>I am not saying that people should learn the languages from the standard,
>that's asking too much, but you should learn to use it as a reference,
>since it is the only authoritative source for detailed semantic information
>in both cases.

Very true.
Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Ada 83 in embedded systems

[Alan Brain]

One example regarding the use of Ada 83 in embedded systems: A firm I 
used to work for had 2 sets of processors on a VME databus. The KAV-30/40 
(DEC) was programmed almost exclusively in Ada, with a few lines of 
assembler here and there ( < .001% by memory). The other was a card 
containing 2 Intel i860s, which were ORIGINALLY programmed in C, with an 
Ada Superstructure, but whose C portions shrank with time.

One reason for this was the greater productivity, in terms of working 
code, shown by novice Ada programmers as opposed to expert C programmers.

Case in Point: The I/O between them was via DMA. To give an idea of how 
novice the programmers were, there was great consternation in the Ada 
team, and joyous delight in the C team, when it was found that the 
internal representation of a 6-level variant record* containing 22K Bytes 
of data differed significantly between the DDCI (i860) compiler and the 
DEC Compiler. So the decision was made against my strong reccomendations 
to 'go for C'. Three months later, no progress. The C compiler just 
didn't specify the representation well enough for portability.

The i860 is an excellent number-cruncher, but particularly awful at 
moving memory around. A decision was therefore made that the interface 
should be as per the DDCI native (unspecified) representation.

It took me a fair while, and quite a bit of experimentation, to find out 
what the DDCI compiler did, especially regarding word boundaries. The 
documentation differed significantly from actuality. Nonetheless, soon I 
was able to have a base type, plus a sub-type on the KAV processor with a 
different representation to the default, which just happened to be the 
same as the i860. This sub-type was used on the i860 throughout, (as it 
was exactly the same one used by the compiler if no representation 
instructions were used), and as an input buffer type for the KAV, 
converted to the base type by assignment statements (which incidentally 
performed boundary checks on each field individually, so that error 
correction was eased).

The only traps for young players were : Conversion from Big-Endian to 
little-endian ( performed by hardware - jumpers on the cards), the fact 
that one compiler started its enumerated types at 0, while the other 
started at one - which made assignment statements neccessary - and that 
one card used the DEC float, while the other used IEEE. This latter was 
cured by a horrible Kludge - before signalling data ready, a program was 
executed that recognised the data type on the i860, transformed the 
relevant Floats to DEC format, before flushing the cache and signalling 
data ready. An inverse process took care of received floats. This was 
done because the i860 is great for bit manipulation too, and efficiency 
was a very high concern.

The IEEE->DEC floating point conversion was originally in C, and was from 
a library. As an exercise, I converted I re-wrote it in Ada - and found a 
Bug in the C! To add insult to injury, the object from the DDCI Ada 83 
compiler worked 15% faster than the buggy C code, and 5% faster than the 
re-written (by a Guru) C.

A trap even for experienced players was that the particular stepping of 
the i860 that we used in the first cards had a design fault. Without 
Ada's excellent error detection capabilities, it is very doubtful we 
would have found the problem. ( When Caching was enabled, Pipelining was 
enabled, and an integer in the program segment was loaded into the 
floating point part of the chip within 16 cycles of an interrupt being 
serviced, the interrupt return register would be corrupted - usually to 
0, ie machine reset, but sometimes randomly in address space - hairy!)

Bottom Line: Measured Data Transfer rate from the first attempt without 
optimisation was 192 MBits/Sec, well over the 176 MBits/Sec required.

Lessons from the above:

This is the type of compromise you gotta live with in the 'real world'.

These are some of the issues - sometimes efficiency is crucial, and 
causes you to do some very iffy things, even in Ada. (Ada 83 anyway)

That Ada 83 even in this case performed radically better than C - even 
though C was on its home ground.

That the Ada was maintainable - and as time went by, and 
specs/requirements changed, by a process of 'survival of the fittest' a 
greater and greater proportion changed from C to Ada 83, as the 
unmodifiable C code had to be thrown away. (By Unmodifiable, I mean 'Not 
Modifiable for X Dollars, where X dollars = the cost of writing it from 
scratch in Ada 83")

That the type checking, the exception handling and other 
much-maligned-by-C-hackers safety features of Ada 83, when used properly, 
enabled a very obscure chip fault to be found (and worked around by 
massaging the compiler's interrupt processing code generator), and made 
the whole system relatively well protected against code bugs. soft 
failures, and hardware faults in a very large and safety-critical system.

* 6 levels of Variant Record: A Variant record, one of whose fields is a 
variant record, one of whose fields is a variant record.... to 6 levels. 
Yes, some hardware people deserve defenestrating... 

So: The original title of the thread - 'Ada is nearly useless for 
embedded systems' would seem to be bovine scatology. Or at least, if 
true, I'd have to say that all others are not just nearly, but completely 
useless!  

Re: Ada is almost useless in embedded systems

[Robert I. Eachus]

In article <RALW.96Mar13101857@vulcan.gecm.com> bill.williams@gecm.com writes:

  > When you're inspecting someone elses code I like the shortcuts that the
  > rich C operators give you. My favourite example has got to be the
  > assignment operators, += etc. Take this (contrived) case...

  > How much easier to *require* (by means of coding standards etc.) the
  > first to be written

  >   bibble_bobble.wibble_wobble += 3;...

  > And what if the coder had actually meant

  > OK, these names are clearly fatuous. But similar cases *do* arise in
  > complex software where, for perfectly sensible reasons a coding standard
  > requires all variables and structure members to have 'meaningful' names.
  > I don't think Ada is immune to this sort of problem.

   No, but the differnce is cultural, not linguistic.  There have been
programs where I needed to do lots of incrementing and declared:

   procedure Inc(X: in out Integer; Y: in Integer := 1) 
   is begin X := X + Y; end Inc;
   pragma Inline(Inc);

   ...and then went and used it all over.  I even had one program that
provided half a dozen similar operations, and instantiated it for
several integer types.  Note that I COULD have written things in terms
of the 'SUCC attribute, but the Ada cultural convention seems to be to
only use 'SUCC and 'PRED for enumeration types, or generic formal
enumeration types.
  
  > > (6) Strong Typing: In the Ada code, the type casting is and must
  > >     be explicity coded.  This provides secure compile-time
  > >     documentation of how big each integer is at each step. This
  > >     is especially useful when you are doing something tricky,
  > >     like writing over memory in a segment register.

  > I approve of strong type *checking*. As we all know (except those
  > who either never write any 'difficult' apps. or never test what
  > they write) type mismatches are a major cause of errors. What
  > irritates me about Ada (and Eiffel is even worse!) is that when *I
  > know* that what I am doing is desirable and correct the language
  > won't let me produce a concise and easily readable expression of
  > it. And, no, I don't consider having to declare my conversion
  > routines in one part of a program so I can use them elsewhere a
  > particularly neat way of solving the problem. Ada deliberately
  > makes it 'unpleasant' to do an unchecked_conversion. IMO it goes a
  > bit too far.

    Ah, but in Ada CHECKED conversions are easy to write and don't
require declarations.  

    In Ada "X := Float(Y);" does just what you would expect, convert Y
to Float and assign it to X.  It is defined for Y of any numeric type.
In fact, when you declare any numeric type you also implicitly create
such a conversion operation.  You also get well defined conversion
operations with derived type declarations, and with many array
declarations.  It is only where you need to convert between types with
no obvious mapping, or when you specifically want no checking, that
you have to resort to Unchecked_Conversion.


					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada is almost useless in embedded systems

[Alan Brain]

eachus@spectre.mitre.org (Robert I. Eachus) wrote:

>   No, but the differnce is cultural, not linguistic.  There have been
>programs where I needed to do lots of incrementing and declared:
>
>   procedure Inc(X: in out Integer; Y: in Integer := 1) 
>   is begin X := X + Y; end Inc;
>   pragma Inline(Inc);
>
>   ...and then went and used it all over.  I even had one program that
>provided half a dozen similar operations, and instantiated it for
>several integer types.

Ditto here - mainly using generics. This also gives you the opportunity of 
defining exactly what exception you want raised if you accidentally overstray 
the bounds of the input type.

Hands up all those who have never done i++ and had the result go over the 
intended maximum value of i? Ada won't stop you doing this (ie committing a 
bug) - but will tell you about it at run-time, and allow you to write code that 
will work regardless.

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Robert Dewar]

Direction_Type'Increment (Direction);

does not seem very inspiring

Direction := Direction + 1;

seems OK. Yes, I know yu can find complex cases, but in well written
code, complex stuff is minimized anyway, and for example nearly all
incmrenets in the GNAT source are of simple variables.
\x1a

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Jay Martin]

dewar@cs.nyu.edu (Robert Dewar) writes:

>Direction_Type'Increment (Direction);

>does not seem very inspiring

>Direction := Direction + 1;

>seems OK. Yes, I know yu can find complex cases, but in well written
>code, complex stuff is minimized anyway, and for example nearly all
>incmrenets in the GNAT source are of simple variables.
>\x1a


Heh, for the editor confused type the following:

<Start Mark> Expression <Copy Marked> := <Paste> + 1; <Return>

For modification, a similar procedure is used, but you get the idea.

In a few years my 1000 page PHD thesis explaining the complete theory
of this method will be available via FTP.

Jay

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Robert I. Eachus]

In article <4iq2ia$lk7@dayuc.dayton.saic.com> John G. Volan <John_Volan@ccmail.dayton.saic.com> writes:

  > I wasn't throwing down a gauntlet or anything, just throwing out an idea 
  > for consideration ... :-)

   But since you took the gauntlet back, I'll suggest some of the
things I was going to put in:

  > No need to think about it overnight, _both_ can be done fairly
  > trivially:
 
  (My conclusion was that you really only need one package:)

  ------------------------------------------------------------------------
  generic
    type Item is (<>);
  package Discrete_Arithmetic is

    procedure Increment (This : in out Item);

    procedure Decrement (This : in out Item);

    --add

    procedure Increment (This : in out Item; By: in Positive);
    procedure Decrement (This : in out Item; By: in Positive);

    procedure Cycle (This: in out Item);

    --moved for obvious reasons.

    pragma Inline (Increment);
    pragma Inline (Decrement);
    pragma Inline (Cycle);

  end Discrete_Arithmetic;
  ------------------------------------------------------------------------
  package body Discrete_Arithmetic is

    procedure Increment (This : in out Item) is
    begin
      This := Item'Succ (This);
    end Increment;

    procedure Decrement (This : in out Item) is
    begin
      This := Item'Pred (This);
    end Decrement;

    procedure Increment (This : in out Item; By: in Positive) is
    begin
      This := Item'Val(Item'Pos(This) + By);
    end Increment;

    procedure Decrement (This : in out Item; By: in Positive) is
    begin
      This := Item'Val(Item'Pos(This) - By);
    end Decrement;

    procedure Cycle (This: in out Item) is
    begin
      if This = Item'LAST
      then This := Item'First;
      else This := Item'Succ(This);
      end if;
    end Cycle;
    
  end Discrete_Arithmetic;

  ------------------------------------------------------------------
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Norman H. Cohen]

In article <dewar.827181191@schonberg>, dewar@cs.nyu.edu (Robert Dewar)
writes: 

|> Direction := Direction + 1;
|>
|> seems OK. Yes, I know yu can find complex cases, but in well written
|> code, complex stuff is minimized anyway, and for example nearly all
|> incmrenets in the GNAT source are of simple variables.

And for the rare exception, you can write: 

   declare
      X: Integer renames Extraordinary_Long_Array_Name(Complex_Index_Value_Expression).Absurdly_Long_Component_Name;
   begin
      X := X + 1;
   end;

I find x++ convenient, but it's hardly worth bloating Ada with another
feature.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Ada is almost useless in embedded systems

[David Weller]

In article <dirk.827148504@demokrit>,
Dirk Dickmanns <dirk@demokrit.informatik.unibw-muenchen.de> wrote:
>-- The second argument should be named "by" giving
>Increment(foobar, by => 5);
>-- for those formerly hurt by some assembler's sequence of operands/result,
>-- especially when using an assembler command as name for a function :-)
><picky mode off>
>

I like that.  I've also suggested
	Obj'Inc(Amount) and Obj'Dec(Amount)

The problem is that I heard Digital Equipment Corporation copyrighted
the word DEC :-)

( ^^^^^^  How urban myths are started :-)
-- 
		    GNAT = GNAT is Not an Ada Translator
==Ada 95 Booch Components: www.ocsystems.com/booch or www.dfw.net/~dweller==
Reality: Work, Work, Work, Guitar.         | Plugged: Fender Telecaster Deluxe
Fantasy: Guitar, Guitar, Guitar, Work(ha!) | Unplugged: Yamaha CG-150SA

Re: Bug or Limitation? (was: Ada is almost useless in embedded systems)

[Robert Dewar]

T.E.D. said

"Just to clarify, this was a documented limitation of Integer_IO. I'm
not sure if the attribute would have worked, and I don't believe I
checked. It would be odd for that to be different, though (If you
already have the code to do this in the compiler, why not paste it
into Integer_IO?)."

SMART does not include Text_IO. The S in SMART stands for Small!

Re: Bug or Limitation? (was: Ada is almost useless in embedded systems)

[Ted Dennison]

Robert Dewar wrote:
> 
> T.E.D. said
> 
> "Just to clarify, this was a documented limitation of Integer_IO. I'm
> not sure if the attribute would have worked, and I don't believe I
> checked. It would be odd for that to be different, though (If you
> already have the code to do this in the compiler, why not paste it
> into Integer_IO?)."
> 
> SMART does not include Text_IO. The S in SMART stands for Small!

ARRRG! 

You are absolutely right, of course.

Honestly, though. I'm pretty sure this restriction existed. If it 
wasn't Text_IO (which it couldn't have been) then it must have been
the attribute. I'm about 2,000 miles away from the closest documentation
set for that compiler that I know about, so the more I try to 
elaborate on this, the more likely I am to say something completly
wrong.

(I sure hope someone with access to an Alsys 68K SMART manual looks 
this up, before I start saying it was in SMART's tasking or garbage 
collection code).


-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Robert I. Eachus]

In article <dewar.827181191@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:

  > Direction_Type'Increment (Direction);

  > does not seem very inspiring

  > Direction := Direction + 1;

  > seems OK. Yes, I know you can find complex cases, but in well written
  > code, complex stuff is minimized anyway, and for example nearly all
  > increments in the GNAT source are of simple variables.

   Agreed.  Very much agreed.  At one time I thought that Ada 9X
should include user defined attributes, but it just isn't that useful
a feature.  As Robert Dewar points out above the second form is
usually both shorter and reads better.  When you do lots of increments
and decrements what you really want is:

    Inc(Direction);

    And the code for that is fairly trival.  I may accept John Volan's
challenge and post a proposed package tomorrow.  But I don't think it
needs to be standardized.   (The issue I want to think about overnight
is whether the generic formal should be "is range <>" or "is (<>)".

    I already know that I want to rewrite the package to:

    procedure Inc(Object: in out Formal_Type);
    procedure Inc(Object: in out Formal_Type; By: in Integer);
    function Inc(Value: in Formal_Type) return Formal_Type;
    function Inc(Value: in Formal_Type; By: in Integer) return Formal_Type;
    
    Since you want the one parameter forms to inline right.

    (Should the function form be named something other than Inc and
Dec?  Does the Ada domain specific knowledge that the parameters of
a function are not changed dominate here, or should it be named Next?)

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[John G. Volan]

In article <EACHUS.96Mar19195517@spectre.mitre.org> 
Robert I. Eachus, eachus@spectre.mitre.org writes:

>I may accept John Volan's challenge and post a proposed package tomorrow. 

I wasn't throwing down a gauntlet or anything, just throwing out an idea 
for consideration ... :-)

>(The issue I want to think about overnight
>is whether the generic formal should be "is range <>" or "is (<>)".

No need to think about it overnight, _both_ can be done fairly trivially: 

    ------------------------------------------------------------------------
	generic
	    type Item is (<>);
	package Discrete_Arithmetic is
	
	    procedure Increment (This : in out Item);
	    pragma Inline (Increment);
	    
	    procedure Decrement (This : in out Item);
	    pragma Inline (Decrement);
	    
	end Discrete_Arithmetic;
    ------------------------------------------------------------------------
    package body Discrete_Arithmetic is
	
	    procedure Increment (This : in out Item) is
	    begin
	        This := Item'Succ (This);
	    end Increment;
	    
	    procedure Decrement (This : in out Item) is
	    begin
	        This := Item'Pred (This);
	    end Decrement;
	    
	end Discrete_Arithmetic;
    ------------------------------------------------------------------------
	generic
	    type Item is range <>;
	package Integer_Arithmetic is
	
	    procedure Increment (This : in out Item);
	    pragma Inline (Increment);
	    
	    procedure Decrement (This : in out Item);
	    pragma Inline (Decrement);
	    
	    procedure Increment (This : in out Item; By : in Item);
	    pragma Inline (Increment);
	    
	    procedure Decrement (This : in out Item; By : in Item);
	    pragma Inline (Decrement);
	    
	    procedure Multiply (This : in out Item; By : in Item);
	    pragma Inline (Increment);
	    
	    procedure Divide (This : in out Item; By : in Item);
	    pragma Inline (Decrement);
	    
	    procedure Modulo (This : in out Item; By : in Item);
	    pragma Inline (Increment);
	    
	    procedure Remainder (This : in out Item; By : in Item);
	    pragma Inline (Decrement);
	    
	end Integer_Arithmetic;
    ------------------------------------------------------------------------
	package body Integer_Arithmetic is
	
	    procedure Increment (This : in out Item) is
	    begin
	        This := Item'Succ (This);
	    end Increment;
	    
	    procedure Decrement (This : in out Item) is
	    begin
	        This := Item'Pred (This);
	    end Decrement;
	    
	    procedure Increment (This : in out Item; By : in Item) is
	    begin
	        This := This + By;
	    end Increment;
	    
	    procedure Decrement (This : in out Item; By : in Item) is
	    begin
	        This := This - By;
	    end Decrement;
	    
	    procedure Multiply (This : in out Item; By : in Item) is
	    begin
	        This := This * By;
	    end Multiply;
	    
	    procedure Divide (This : in out Item; By : in Item) is
	    begin
	        This := This / By;
	    end Divide;
	    
	    procedure Modulo (This : in out Item; By : in Item) is
	    begin
	        This := This mod By;
	    end Modulo;
	    
	    procedure Remainder (This : in out Item; By : in Item) is
	    begin
	        This := This rem By;
	    end Remainder;
	    
	end Integer_Arithmetic;
    ------------------------------------------------------------------------
	generic
	    type Item is mod <>;
	package Modular_Arithmetic is
	
	    procedure Increment (This : in out Item);
	    pragma Inline (Increment);
	    
	    procedure Decrement (This : in out Item);
	    pragma Inline (Decrement);
	    
	    procedure Increment (This : in out Item; By : in Item);
	    pragma Inline (Increment);
	    
	    procedure Decrement (This : in out Item; By : in Item);
	    pragma Inline (Decrement);
	    
	    procedure Multiply (This : in out Item; By : in Item);
	    pragma Inline (Increment);
	    
	    procedure Divide (This : in out Item; By : in Item);
	    pragma Inline (Decrement);
	    
	    procedure Modulo (This : in out Item; By : in Item);
	    pragma Inline (Increment);
	    
	    procedure Remainder (This : in out Item; By : in Item);
	    pragma Inline (Decrement);
	    
	end Modular_Arithmetic;
    ------------------------------------------------------------------------
	package body Modular_Arithmetic is
	
	    procedure Increment (This : in out Item) is
	    begin
	        This := Item'Succ (This);
	    end Increment;
	    
	    procedure Decrement (This : in out Item) is
	    begin
	        This := Item'Pred (This);
	    end Decrement;
	    
	    procedure Increment (This : in out Item; By : in Item) is
	    begin
	        This := This + By;
	    end Increment;
	    
	    procedure Decrement (This : in out Item; By : in Item) is
	    begin
	        This := This - By;
	    end Decrement;
	    
	    procedure Multiply (This : in out Item; By : in Item) is
	    begin
	        This := This * By;
	    end Multiply;
	    
	    procedure Divide (This : in out Item; By : in Item) is
	    begin
	        This := This / By;
	    end Divide;
	    
	    procedure Modulo (This : in out Item; By : in Item) is
	    begin
	        This := This mod By;
	    end Modulo;
	    
	    procedure Remainder (This : in out Item; By : in Item) is
	    begin
	        This := This rem By;
	    end Remainder;
	    
	end Modular_Arithmetic;
    ------------------------------------------------------------------------
	generic
	    type Item is digits <>;
	package Floating_Arithmetic is
	
	    procedure Increment (This : in out Item);
	    pragma Inline (Increment);
	    
	    procedure Decrement (This : in out Item);
	    pragma Inline (Decrement);
	    
	    procedure Increment (This : in out Item; By : in Item);
	    pragma Inline (Increment);
	    
	    procedure Decrement (This : in out Item; By : in Item);
	    pragma Inline (Decrement);
	    
	    procedure Multiply (This : in out Item; By : in Item);
	    pragma Inline (Increment);
	    
	    procedure Divide (This : in out Item; By : in Item);
	    pragma Inline (Decrement);
	    
	end Floating_Arithmetic;
    ------------------------------------------------------------------------
	package body Floating_Arithmetic is
	
	    procedure Increment (This : in out Item) is
	    begin
	        This := Item'Succ (This);
	    end Increment;
	    
	    procedure Decrement (This : in out Item) is
	    begin
	        This := Item'Pred (This);
	    end Decrement;
	    
	    procedure Increment (This : in out Item; By : in Item) is
	    begin
	        This := This + By;
	    end Increment;
	    
	    procedure Decrement (This : in out Item; By : in Item) is
	    begin
	        This := This - By;
	    end Decrement;
	    
	    procedure Multiply (This : in out Item; By : in Item) is
	    begin
	        This := This * By;
	    end Multiply;
	    
	    procedure Divide (This : in out Item; By : in Item) is
	    begin
	        This := This / By;
	    end Divide;
	    
	end Floating_Arithmetic;
    ------------------------------------------------------------------------
	generic
	    type Item is delta <>;
	package Fixed_Arithmetic is
	
	    procedure Increment (This : in out Item);
	    pragma Inline (Increment);
	    
	    procedure Decrement (This : in out Item);
	    pragma Inline (Decrement);
	    
	    procedure Increment (This : in out Item; By : in Item);
	    pragma Inline (Increment);
	    
	    procedure Decrement (This : in out Item; By : in Item);
	    pragma Inline (Decrement);
	    
	    procedure Multiply (This : in out Item; By : in Item);
	    pragma Inline (Increment);
	    
	    procedure Divide (This : in out Item; By : in Item);
	    pragma Inline (Decrement);
	    
	end Fixed_Arithmetic;
    ------------------------------------------------------------------------
	package body Fixed_Arithmetic is
	
	    procedure Increment (This : in out Item) is
	    begin
	        This := Item'Succ (This);
	    end Increment;
	    
	    procedure Decrement (This : in out Item) is
	    begin
	        This := Item'Pred (This);
	    end Decrement;
	    
	    procedure Increment (This : in out Item; By : in Item) is
	    begin
	        This := This + By;
	    end Increment;
	    
	    procedure Decrement (This : in out Item; By : in Item) is
	    begin
	        This := This - By;
	    end Decrement;
	    
	    procedure Multiply (This : in out Item; By : in Item) is
	    begin
	        This := This * By;
	    end Multiply;
	    
	    procedure Divide (This : in out Item; By : in Item) is
	    begin
	        This := This / By;
	    end Divide;
	    
	end Fixed_Arithmetic;
    ------------------------------------------------------------------------

That only took me about 10 minutes of my lunch break to write.  Brought to
you by the miracle of cut and paste! ;-)

>... But I don't think it needs to be standardized.

The trouble is, anybody and his brother could do the same thing I just
did, but slightly differently one way, or slightly differently another
way ... eventually, the world is going to abound with multiple versions
of this idea (that is, _if_ folks really think this is worth doing, but
that's another issue).  Anybody and his brother could have implemented
dynamic unbounded strings and complex arithmetic and transcendental
functions and so on in Ada83 (and they did!), but there's value in
having a standardized way of doing those things now in Ada95.  So maybe
my packages above could have been Ada.Numerics.Discrete_Arithmetic,
Ada.Numerics.Integer_Arithmetic, and so on ...

>    function Inc(Value: in Formal_Type) return Formal_Type;
>    function Inc(Value: in Formal_Type; By: in Integer) return Formal_Type;
...
>    (Should the function form be named something other than Inc and
>Dec?  

Yes, they should be named 'Succ and 'Pred, and "+" and "-". :-)  Really,
all we're talking about is providing Ada95 procedure equivalents for
C's arithmetic-with-side-effect operators: ++ -- += -= *= /=.  No need
to come up with a substitute for operations Ada95 already has.  But if
you must, why not just do renamings?

    type Item is range <>;
    ...
    function Successor_Of
        (This : in Item) return Item renames Item'Succ;
    function Predecessor_Of
        (This : in Item) return Item renames Item'Pred;
    function Sum_Of
        (This, Plus_That  : in Item) return Item renames "+";
    function Difference_Of
        (This, Minus_That : in Item) return Item renames "-";
    function Product_Of
        (This, Times_That : in Item) return Item renames "*";
    function Quotient_Of
        (This, Over_That  : in Item) return Item renames "/";
    function Remainder_Of
        (This, Over_That  : in Item) return Item renames "rem";
    function Modulo_Of
        (This, Over_That  : in Item) return Item renames "mod";

But that seems a little extreme, don't you think? :-)
   
>Does the Ada domain specific knowledge that the parameters of
>a function are not changed dominate here, or should it be named Next?)

My instinct is to use nouns for function names rather than verbs, as you
can see above.  It emphasizes the fact that the point of a function is
the result it returns, and not some naughty side-effect that it shouldn't
be doing anyway. :-)  (But let's not start up _that_ thread again... :-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature
( Name => "John G. Volan", E_Mail => "John_Volan@dayton.saic.com",
  Favorite_Slogan => "Ada95: The *FIRST* International-Standard OOPL",
  Humorous_Disclaimer => "These opinions are undefined by SAIC, so" &
    "any use would be erroneous ... or is that a bounded error now?" );
------------------------------------------------------------------------

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Alan Brain]

John G. Volan <John_Volan@ccmail.dayton.saic.com> wrote:
------------------------------------------------------------------------
>	generic
>	    type Item is (<>);

------------------->8-----------------------------

May I humbly suggest adding a few exceptions to the spec? There are 
quite a few places where CONSTRAINT_ERROR is possible at run-time, and 
it's usually a pretty good idea to map this into something a bit more 
informative, so the caller can know where the error occurred.

I know it's obvious, but some readers won't be familiar with Ada93, so 
please bear with me if I give an example:

     Supposing you have a type

subtype INTEGER_DEGREES_TYPE is INTEGER range 1..360;

VFR_BEARING : INTEGER_DEGREES_TYPE := 360;


     Then 

INCREMENT(VFR_BEARING);

     would raise a CONSTRAINT_ERROR, always.

In order to make a really reliable, fault-tolerant ( and bug-tolerant ) 
program, it would be really great if instaed of the generalised 
CONSTRAINT_ERROR being handled, a 
DISCRETE_ARITHMETIC_FOR_INTEGER_DEGREES.INCREMENT_OVERFLOW_ERROR was 
raised, differentiated from anything else in the same block that could 
cause CONSTRAINT_ERROR.

So code could be (withs, uses omitted for clarity)


DETERMINE_VFR_BLOCK:

begin
  -- do something here --
  INCREMENT(VFR_BEARING);
  -- do something else here --

exception
  when INCREMENT_OVERFLOW_ERROR => do some sort of recovery;
  when CONSTRAINT_ERROR         => do something else;
  when others                   => do something else again;

end DETERMINE_VFR_BLOCK;

Just my 2c.
   

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Robert A Duff]

In article <EACHUS.96Mar19195517@spectre.mitre.org>,
Robert I. Eachus <eachus@spectre.mitre.org> wrote:
>and decrements what you really want is:
>
>    Inc(Direction);

Yeah, but I don't really want to have write a generic instantiation just
for this silly little thing.  I like the fact that you can do this
concisely in C, but if you make me write an instantiation, I'll say,
forget it, it's not worth the trouble, I'll just spell it out as
"X := X + 1;"

Nobody commented on my derived type idea, which I sometimes use in my
own code.

>    And the code for that is fairly trival.  I may accept John Volan's
>challenge and post a proposed package tomorrow.  But I don't think it
>needs to be standardized.   (The issue I want to think about overnight
>is whether the generic formal should be "is range <>" or "is (<>)".

range <>, IMHO.

>    I already know that I want to rewrite the package to:
>
>    procedure Inc(Object: in out Formal_Type);
>    procedure Inc(Object: in out Formal_Type; By: in Integer);
>    function Inc(Value: in Formal_Type) return Formal_Type;
>    function Inc(Value: in Formal_Type; By: in Integer) return Formal_Type;
>    
>    Since you want the one parameter forms to inline right.

Heh?  Not sure what you mean -- the defaulted-parameter version should
inline just fine, shouldn't it?

Why declare functions?  Ada already *has* a perfectly readable
functional version -- just say "X + 1".  The point of the procedure
versions is to avoid writing X twice (where X is more complex than a
simple variable name), but there's no such rationale for the functions.

Historical note: An early version of Ada 9X made this sort of thing
pretty painless:

    procedure Incr(X: in out Root_Integer'Class);

Declare that *once*, and you can say "Incr(X);" for X of any integer
type.  No instantiations necessary, no need to derive from a "special"
integer type.

In Ada 95, however, Root_Integer is a name that no user may utter
(reminds me of the name of God in some parts of the Bible), and 'Class
is not allowed for untagged types.

- Bob

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Peter Hermann]

Robert A Duff (bobduff@world.std.com) wrote:
: >is whether the generic formal should be "is range <>" or "is (<>)".
: range <>, IMHO.

I always prefer the discrete type over the specialized
numerical thing, with 'succ and 'pred . Just a feeling.

Ada0x will have general procedure calls
	     increment(item);
	     decrement(item);
for all discrete types, of course ;-)  :-)

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Robert Dewar]

"Ada0x will have general procedure calls
             increment(item);
             decrement(item);
for all discrete types, of course ;-)  :-)"

Well of course this is a joke, but I trust everyone undrstands that, the
idea of "general" procedure calls is really horrible.

Only a true lover of verbosity could like increment(item) which is longer
than either

(a) the standard Ada form:  item := item + 1;

(b) the COBOL form (!)  add 1 to item

Of course a discussion like this always generates lots of discussion.
Unlike abstract types, type extnsions, overriding, dispatching etc,
everyone at least fully understands the idea of incrementing a variable :-)

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Robert I. Eachus]

In article <4ivnr9$86o@dayuc.dayton.saic.com> John G. Volan <John_Volan@ccmail.dayton.saic.com> writes:

  > Horrors! This assumes that Standard.Integer subsumes all possible ranges
  > of 'Pos values for all discrete types (enumeration, integer, modular).
  > A very dubious assumption!  What about Long_Long_Integer?  The long-term
  > reusability of this package is problematic.

    I felt that the range of Integer is large enough for most uses.
In general I expect this package to be used with 1) enumeration types
2) character types 3) loop indexes and 4) string indexes.  (The
magic conversions implicit in 'POS and 'VAL in the body mean that
there is no risk of type mismatch.)

  > Also, why limit Increment/Decrement to Positive?  Why not allow any
  > arbitrary integer?  The C analogs for these procedures, += and -=,
  > carry no such limitation.

   Shrug.  I guess I could be convinced to Integer, but Inc(X, -1)
seems silly.

  > Finally, you're looking too narrowly at the problem:  You seem to be
  > focussed exclusively on analogs for ++ -- += -= , and are neglecting 
  > similarly contentious operations such as *= /= %= .  Also, you're
  > only looking at discrete types.  What about real types?  My inanely
  > trivial packages covered all the bases.

   I've never used *= /= or %= except when debugging a C compiler.

   As for real types, yes, if you feel those types are needed you do
need added packages.

  > However, your Cycle operation is a nice touch.

   Thanks.  I left out the Min and Max also, but I now think the two
argument versions should go in, but the versions with array parameters
complicate things too much.

   
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Mats Weber]

>Ada0x will have general procedure calls

We should call it Ada 0y because we already know that x = 5

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[John G. Volan]

In article <DozHr8.88L.0.-s@inmet.camb.inmet.com>
Tucker Taft, stt@henning.camb.inmet.com writes:

>John G. Volan (John_Volan@ccmail.dayton.saic.com) wrote:
>: In article <dewar.827845699@schonberg> Robert Dewar, dewar@cs.nyu.edu writes:
>: >Well I can't get particularly upset by that , but if you are, just
>: >change this to Item'Val (Item'Pos(This) + Positive'Pos (By)).
>
>: Okay, that leaves the exact type returned by the 'Pos functions
>: ambiguous, but what does Ada95 do in that case?
[snip]
>
>The 'Pos attribute returns a value of type universal_integer,
>which is implicitly convertible to any integer type.  Given that
>you are adding it to a value of subtype Positive, it will be
>converted to Integer (since Positive is a subtype of Integer).

Yes, that's clearly the case for:

    Item'Val (Item'Pos(This) + By)
              ^^^^^^^^^^^^^^   ^^
            univeral integer   Standard.Positive
            
but that wasn't what I was asking.  I was referring to Robert Dewar's
suggestion:

    Item'Val (Item'Pos(This) + Positive'Pos(By))
              ^^^^^^^^^^^^^^   ^^^^^^^^^^^^^^^^
            univeral integer   universal integer
            
I assume that both of these must be converted to some actual integer
type before being added together and passed in to Item'Val.  But which
integer type?

------------------------------------------------------------------------
Internet.Usenet.Put_Signature
( Name => "John G. Volan", E_Mail => "John_Volan@dayton.saic.com",
  Favorite_Slogan => "Ada95: The *FIRST* International-Standard OOPL",
  Humorous_Disclaimer => "These opinions are undefined by SAIC, so" &
    "any use would be erroneous ... or is that a bounded error now?" );
------------------------------------------------------------------------

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Geert Bosch]

Robert I. Eachus (eachus@spectre.mitre.org) wrote:
:     (Should the function form be named something other than Inc and
: Dec?  Does the Ada domain specific knowledge that the parameters of
: a function are not changed dominate here, or should it be named Next?)

The terms increment and decrement suggest an update of the parameter, so
I think these terms are good. Something like Next(T) sounds more like a
function. Also when speaking about these operations everybody talks about
incrementing and decrementing variables, so I see no justification for using
other terms.

One point would be whether to use the long or the short name. I'd vote for
the long version. I don't see the huge win in saving those 6 keystrokes. 
I find that I can read the word Decrement as fast as Dec. For people who are 
not guilty of having used assembly-language the long variant will definately 
be easier to understand.  So, I think the best readable variant is to use 
Increment and Decrement.

When I helped people with their initial programming course (using Turbo
Pascal) I found that for most people Inc(x) and Dec(x) were not clear:
they often asked what those functions did or looked them up in the
library. Once they knew the new secret function they used it all over
the place, because Inc(A[I]) would be much faster than A[I] := A[I] + 1;
Most of them were very disappointed when I showed them that both forms
generated identical code. There must be some reason that people want to
write Inc(I); or I++; instead of I := I + 1; or Increment(I); 

BTW: I really, really  miss those mixed assembly/Pascal listings in
which the assembly used the right symbolic names for both globals and
locals.

Greetings,
   Geert

-- 
E-Mail: geert@sun3.iaf.nl      ***   Lbh whfg penpxrq ZvpebFbsg'f   ***
 Phone: +31-53-4303054         **  arj naq vzcebirq frphevgl flfgrz. **

Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[Mats Weber]

In article <EACHUS.96Mar19195517@spectre.mitre.org>,
eachus@spectre.mitre.org (Robert I. Eachus) wrote:

>    (Should the function form be named something other than Inc and
>Dec?  Does the Ada domain specific knowledge that the parameters of
>a function are not changed dominate here, or should it be named Next?)

I would prefer Succ and Pred for the functions, so we use the same
convention as for attributes.

Re: Ada is almost useless in embedded systems

[Kevin Dalley]

>>>>> "Laurent" == Laurent Guerby <Laurent.Guerby@enst-bretagne.fr> writes:

> Scott H. James writes

> : (5) Verbosity: Ada has all of C's unary and binary operators, but Ada
> :     requires C's assignment operators to be spelled out. This is an
> :     aesthetic issue, and possibly a readability issue.

> Readability  for what ???  I always thought that a+=b  was  a hint for
> poor optimizers. But that's a matter of taste ;-)

I once thought that.  Currently, I find that it is more clear for
programmers, and less prone to error then spelling out the same same
variable twice.  This is particularly true if the variable name is
long, for example an element of an array or of a structure:

	fred->array[x+i] += 5;

is much easier for a human to understand than:

	fred->array[x+i] = fred->array[x+i] + 5;

and easier to distinguish from:

	fred->array[x+i] = fred->array[x+i-1] + 5;

kevin

-- 
kevin
kevin@aimnet.com