* Re: Ada is almost useless in embedded systems [not found] ` <dewar.823962356@schonberg> @ 1996-02-17 0:00 ` Tore Joergensen 1996-02-17 0:00 ` Robert Dewar 1996-02-19 0:00 ` Keith Thompson 0 siblings, 2 replies; 74+ messages in thread From: Tore Joergensen @ 1996-02-17 0:00 UTC (permalink / raw) 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. | +-------------------------+-------------------------------------------+ ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Ada is almost useless in embedded systems 1996-02-17 0:00 ` Ada is almost useless in embedded systems Tore Joergensen @ 1996-02-17 0:00 ` Robert Dewar 1996-02-19 0:00 ` Keith Thompson 1 sibling, 0 replies; 74+ messages in thread From: Robert Dewar @ 1996-02-17 0:00 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Ada is almost useless in embedded systems 1996-02-17 0:00 ` Ada is almost useless in embedded systems Tore Joergensen 1996-02-17 0:00 ` Robert Dewar @ 1996-02-19 0:00 ` Keith Thompson 1996-02-19 0:00 ` John McCabe 1 sibling, 1 reply; 74+ messages in thread From: Keith Thompson @ 1996-02-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Ada is almost useless in embedded systems 1996-02-19 0:00 ` Keith Thompson @ 1996-02-19 0:00 ` John McCabe 1996-02-21 0:00 ` Richard A. O'Keefe 0 siblings, 1 reply; 74+ messages in thread From: John McCabe @ 1996-02-19 0:00 UTC (permalink / raw) >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> ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Ada is almost useless in embedded systems 1996-02-19 0:00 ` John McCabe @ 1996-02-21 0:00 ` Richard A. O'Keefe 1996-02-21 0:00 ` Norman H. Cohen 0 siblings, 1 reply; 74+ messages in thread From: Richard A. O'Keefe @ 1996-02-21 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Ada is almost useless in embedded systems 1996-02-21 0:00 ` Richard A. O'Keefe @ 1996-02-21 0:00 ` Norman H. Cohen 0 siblings, 0 replies; 74+ messages in thread From: Norman H. Cohen @ 1996-02-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 74+ messages in thread
[parent not found: <824056183.18993@assen.demon.co.uk>]
[parent not found: <311E924E.74CE@escmail.orl.mmc.com>]
* Re: Ada is great for embedded systems (was Ada is almost useless in embedded systems) [not found] ` <311E924E.74CE@escmail.orl.mmc.com> @ 1996-02-17 0:00 ` Ken & Virginia Garlington 0 siblings, 0 replies; 74+ messages in thread From: Ken & Virginia Garlington @ 1996-02-17 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 74+ messages in thread
[parent not found: <4fnqpm$3nh@news.sanders.lockheed.com>]
* Re: Ada is almost useless in embedded systems [not found] ` <4fnqpm$3nh@news.sanders.lockheed.com> @ 1996-02-19 0:00 ` AdaWorks 1996-02-21 0:00 ` Ken Garlington 1996-02-21 0:00 ` Hugh Dunne 0 siblings, 2 replies; 74+ messages in thread From: AdaWorks @ 1996-02-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Ada is almost useless in embedded systems 1996-02-19 0:00 ` Ada is almost useless in embedded systems AdaWorks @ 1996-02-21 0:00 ` Ken Garlington 1996-02-21 0:00 ` Hugh Dunne 1 sibling, 0 replies; 74+ messages in thread From: Ken Garlington @ 1996-02-21 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Ada is almost useless in embedded systems 1996-02-19 0:00 ` Ada is almost useless in embedded systems AdaWorks 1996-02-21 0:00 ` Ken Garlington @ 1996-02-21 0:00 ` Hugh Dunne 1 sibling, 0 replies; 74+ messages in thread From: Hugh Dunne @ 1996-02-21 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 74+ messages in thread
[parent not found: <4fnp37$nj1@theopolis.orl.mmc.com>]
* Re: Ada is almost useless in embedded systems [not found] ` <4fnp37$nj1@theopolis.orl.mmc.com> @ 1996-02-22 0:00 ` Alan Brain 0 siblings, 0 replies; 74+ messages in thread From: Alan Brain @ 1996-02-22 0:00 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Ada is almost useless in embedded systems [not found] <823906039.22113@assen.demon.co.uk> [not found] ` <4fgrq3$mc4@qualcomm.com> [not found] ` <824056183.18993@assen.demon.co.uk> @ 1996-02-19 0:00 ` Jon S Anthony 1996-02-19 0:00 ` AdaWorks ` (5 subsequent siblings) 8 siblings, 0 replies; 74+ messages in thread From: Jon S Anthony @ 1996-02-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Ada is almost useless in embedded systems [not found] <823906039.22113@assen.demon.co.uk> ` (2 preceding siblings ...) 1996-02-19 0:00 ` Jon S Anthony @ 1996-02-19 0:00 ` AdaWorks 1996-02-21 0:00 ` Ken Garlington 1996-02-19 0:00 ` R.A.L Williams ` (4 subsequent siblings) 8 siblings, 1 reply; 74+ messages in thread From: AdaWorks @ 1996-02-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Ada is almost useless in embedded systems 1996-02-19 0:00 ` AdaWorks @ 1996-02-21 0:00 ` Ken Garlington 1996-02-23 0:00 ` AdaWorks 0 siblings, 1 reply; 74+ messages in thread From: Ken Garlington @ 1996-02-21 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Ada is almost useless in embedded systems 1996-02-21 0:00 ` Ken Garlington @ 1996-02-23 0:00 ` AdaWorks 0 siblings, 0 replies; 74+ messages in thread From: AdaWorks @ 1996-02-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Ada is almost useless in embedded systems [not found] <823906039.22113@assen.demon.co.uk> ` (3 preceding siblings ...) 1996-02-19 0:00 ` AdaWorks @ 1996-02-19 0:00 ` R.A.L Williams 1996-02-21 0:00 ` Richard A. O'Keefe 1996-02-26 0:00 ` R.A.L Williams ` (3 subsequent siblings) 8 siblings, 1 reply; 74+ messages in thread From: R.A.L Williams @ 1996-02-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Ada is almost useless in embedded systems 1996-02-19 0:00 ` R.A.L Williams @ 1996-02-21 0:00 ` Richard A. O'Keefe 0 siblings, 0 replies; 74+ messages in thread From: Richard A. O'Keefe @ 1996-02-21 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Ada is almost useless in embedded systems [not found] <823906039.22113@assen.demon.co.uk> ` (4 preceding siblings ...) 1996-02-19 0:00 ` R.A.L Williams @ 1996-02-26 0:00 ` R.A.L Williams [not found] ` <4h3q56$1vk@goanna.cs.rmit.EDU.AU> [not found] ` <emery-0902962215150001@line316.nwm.mindlink.net> ` (2 subsequent siblings) 8 siblings, 1 reply; 74+ messages in thread From: R.A.L Williams @ 1996-02-26 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 74+ messages in thread
[parent not found: <4h3q56$1vk@goanna.cs.rmit.EDU.AU>]
[parent not found: <dewar.825635955@schonberg>]
[parent not found: <826571250.140@assen.demon.co.uk>]
[parent not found: <dewar.826634800@schonberg>]
* Re: Ada is almost useless in embedded systems [not found] ` <dewar.826634800@schonberg> @ 1996-03-21 0:00 ` John McCabe 1996-03-23 0:00 ` Side-effect arithmetic again [was: Ada ... in embedded systems] John G. Volan 0 siblings, 1 reply; 74+ messages in thread From: John McCabe @ 1996-03-21 0:00 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-21 0:00 ` John McCabe @ 1996-03-23 0:00 ` John G. Volan 1996-03-23 0:00 ` Robert Dewar 1996-03-26 0:00 ` John G. Volan 0 siblings, 2 replies; 74+ messages in thread From: John G. Volan @ 1996-03-23 0:00 UTC (permalink / raw) 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?" ); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-23 0:00 ` Side-effect arithmetic again [was: Ada ... in embedded systems] John G. Volan @ 1996-03-23 0:00 ` Robert Dewar 1996-03-25 0:00 ` Tucker Taft 1996-03-26 0:00 ` John G. Volan 1 sibling, 1 reply; 74+ messages in thread From: Robert Dewar @ 1996-03-23 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-23 0:00 ` Robert Dewar @ 1996-03-25 0:00 ` Tucker Taft 1996-03-25 0:00 ` Robert A Duff 1996-03-25 0:00 ` Norman H. Cohen 0 siblings, 2 replies; 74+ messages in thread From: Tucker Taft @ 1996-03-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-25 0:00 ` Tucker Taft @ 1996-03-25 0:00 ` Robert A Duff 1996-03-25 0:00 ` Norman H. Cohen 1 sibling, 0 replies; 74+ messages in thread From: Robert A Duff @ 1996-03-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-25 0:00 ` Tucker Taft 1996-03-25 0:00 ` Robert A Duff @ 1996-03-25 0:00 ` Norman H. Cohen 1 sibling, 0 replies; 74+ messages in thread From: Norman H. Cohen @ 1996-03-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-23 0:00 ` Side-effect arithmetic again [was: Ada ... in embedded systems] John G. Volan 1996-03-23 0:00 ` Robert Dewar @ 1996-03-26 0:00 ` John G. Volan 1996-03-26 0:00 ` Robert Dewar 1996-03-26 0:00 ` Robert A Duff 1 sibling, 2 replies; 74+ messages in thread From: John G. Volan @ 1996-03-26 0:00 UTC (permalink / raw) 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?" ); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-26 0:00 ` John G. Volan @ 1996-03-26 0:00 ` Robert Dewar 1996-03-29 0:00 ` Robert I. Eachus 1996-03-26 0:00 ` Robert A Duff 1 sibling, 1 reply; 74+ messages in thread From: Robert Dewar @ 1996-03-26 0:00 UTC (permalink / raw) 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)). ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-26 0:00 ` Robert Dewar @ 1996-03-29 0:00 ` Robert I. Eachus 0 siblings, 0 replies; 74+ messages in thread From: Robert I. Eachus @ 1996-03-29 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-26 0:00 ` John G. Volan 1996-03-26 0:00 ` Robert Dewar @ 1996-03-26 0:00 ` Robert A Duff 1996-03-26 0:00 ` Tore Joergensen 1 sibling, 1 reply; 74+ messages in thread From: Robert A Duff @ 1996-03-26 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-26 0:00 ` Robert A Duff @ 1996-03-26 0:00 ` Tore Joergensen 1996-03-27 0:00 ` John G. Volan ` (2 more replies) 0 siblings, 3 replies; 74+ messages in thread From: Tore Joergensen @ 1996-03-26 0:00 UTC (permalink / raw) 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. | +-------------------------+-------------------------------------------+ ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-26 0:00 ` Tore Joergensen @ 1996-03-27 0:00 ` John G. Volan 1996-03-27 0:00 ` John G. Volan 1996-03-27 0:00 ` John G. Volan 2 siblings, 0 replies; 74+ messages in thread From: John G. Volan @ 1996-03-27 0:00 UTC (permalink / raw) 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?" ); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-26 0:00 ` Tore Joergensen 1996-03-27 0:00 ` John G. Volan @ 1996-03-27 0:00 ` John G. Volan 1996-03-28 0:00 ` Tucker Taft 1996-03-27 0:00 ` John G. Volan 2 siblings, 1 reply; 74+ messages in thread From: John G. Volan @ 1996-03-27 0:00 UTC (permalink / raw) 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?" ); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-27 0:00 ` John G. Volan @ 1996-03-28 0:00 ` Tucker Taft 1996-03-28 0:00 ` Robert Dewar 0 siblings, 1 reply; 74+ messages in thread From: Tucker Taft @ 1996-03-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-28 0:00 ` Tucker Taft @ 1996-03-28 0:00 ` Robert Dewar 1996-03-29 0:00 ` Tucker Taft 0 siblings, 1 reply; 74+ messages in thread From: Robert Dewar @ 1996-03-28 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-28 0:00 ` Robert Dewar @ 1996-03-29 0:00 ` Tucker Taft 1996-03-29 0:00 ` Tucker Taft 0 siblings, 1 reply; 74+ messages in thread From: Tucker Taft @ 1996-03-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-29 0:00 ` Tucker Taft @ 1996-03-29 0:00 ` Tucker Taft 0 siblings, 0 replies; 74+ messages in thread From: Tucker Taft @ 1996-03-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-26 0:00 ` Tore Joergensen 1996-03-27 0:00 ` John G. Volan 1996-03-27 0:00 ` John G. Volan @ 1996-03-27 0:00 ` John G. Volan 1996-03-29 0:00 ` Robert A Duff 2 siblings, 1 reply; 74+ messages in thread From: John G. Volan @ 1996-03-27 0:00 UTC (permalink / raw) 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?" ); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-27 0:00 ` John G. Volan @ 1996-03-29 0:00 ` Robert A Duff 1996-03-30 0:00 ` John G. Volan 1996-03-30 0:00 ` John G. Volan 0 siblings, 2 replies; 74+ messages in thread From: Robert A Duff @ 1996-03-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-29 0:00 ` Robert A Duff @ 1996-03-30 0:00 ` John G. Volan 1996-03-31 0:00 ` AdaWorks 1996-04-01 0:00 ` Robert A Duff 1996-03-30 0:00 ` John G. Volan 1 sibling, 2 replies; 74+ messages in thread From: John G. Volan @ 1996-03-30 0:00 UTC (permalink / raw) 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?" ); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-30 0:00 ` John G. Volan @ 1996-03-31 0:00 ` AdaWorks 1996-04-01 0:00 ` Robert A Duff 1 sibling, 0 replies; 74+ messages in thread From: AdaWorks @ 1996-03-31 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-30 0:00 ` John G. Volan 1996-03-31 0:00 ` AdaWorks @ 1996-04-01 0:00 ` Robert A Duff 1 sibling, 0 replies; 74+ messages in thread From: Robert A Duff @ 1996-04-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-29 0:00 ` Robert A Duff 1996-03-30 0:00 ` John G. Volan @ 1996-03-30 0:00 ` John G. Volan 1 sibling, 0 replies; 74+ messages in thread From: John G. Volan @ 1996-03-30 0:00 UTC (permalink / raw) 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?" ); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 74+ messages in thread
[parent not found: <emery-0902962215150001@line316.nwm.mindlink.net>]
[parent not found: <DMoA85.52I@eskimo.com>]
[parent not found: <823965654.4500@assen.demon.co.uk>]
[parent not found: <824165619.14894@assen.demon.co.uk>]
[parent not found: <JSA.96Feb13133713@organon.com>]
[parent not found: <824259217.26321@assen.demon.co.uk>]
* Re: Ada is almost useless in embedded systems [not found] ` <824259217.26321@assen.demon.co.uk> @ 1996-02-17 0:00 ` Robert Dewar 1996-02-18 0:00 ` John McCabe 0 siblings, 1 reply; 74+ messages in thread From: Robert Dewar @ 1996-02-17 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Ada is almost useless in embedded systems 1996-02-17 0:00 ` Ada is almost useless in embedded systems Robert Dewar @ 1996-02-18 0:00 ` John McCabe 1996-02-18 0:00 ` Robert Dewar 0 siblings, 1 reply; 74+ messages in thread From: John McCabe @ 1996-02-18 0:00 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Ada is almost useless in embedded systems 1996-02-18 0:00 ` John McCabe @ 1996-02-18 0:00 ` Robert Dewar 1996-02-19 0:00 ` John McCabe 0 siblings, 1 reply; 74+ messages in thread From: Robert Dewar @ 1996-02-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Ada is almost useless in embedded systems 1996-02-18 0:00 ` Robert Dewar @ 1996-02-19 0:00 ` John McCabe 1996-02-20 0:00 ` Robert Dewar 1996-02-21 0:00 ` Fergus Henderson 0 siblings, 2 replies; 74+ messages in thread From: John McCabe @ 1996-02-19 0:00 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Ada is almost useless in embedded systems 1996-02-19 0:00 ` John McCabe @ 1996-02-20 0:00 ` Robert Dewar 1996-02-21 0:00 ` Fergus Henderson 1 sibling, 0 replies; 74+ messages in thread From: Robert Dewar @ 1996-02-20 0:00 UTC (permalink / raw) "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". ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Ada is almost useless in embedded systems 1996-02-19 0:00 ` John McCabe 1996-02-20 0:00 ` Robert Dewar @ 1996-02-21 0:00 ` Fergus Henderson 1 sibling, 0 replies; 74+ messages in thread From: Fergus Henderson @ 1996-02-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 74+ messages in thread
[parent not found: <824332550.2485@assen.demon.co.uk>]
* Re: Ada is almost useless in embedded systems [not found] ` <824332550.2485@assen.demon.co.uk> @ 1996-02-17 0:00 ` Ken & Virginia Garlington 1996-02-17 0:00 ` Robert Dewar 0 siblings, 1 reply; 74+ messages in thread From: Ken & Virginia Garlington @ 1996-02-17 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Ada is almost useless in embedded systems 1996-02-17 0:00 ` Ken & Virginia Garlington @ 1996-02-17 0:00 ` Robert Dewar 1996-02-18 0:00 ` John McCabe 0 siblings, 1 reply; 74+ messages in thread From: Robert Dewar @ 1996-02-17 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Ada is almost useless in embedded systems 1996-02-17 0:00 ` Robert Dewar @ 1996-02-18 0:00 ` John McCabe 1996-02-18 0:00 ` Robert Dewar 0 siblings, 1 reply; 74+ messages in thread From: John McCabe @ 1996-02-18 0:00 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Ada is almost useless in embedded systems 1996-02-18 0:00 ` John McCabe @ 1996-02-18 0:00 ` Robert Dewar 1996-02-19 0:00 ` John McCabe 0 siblings, 1 reply; 74+ messages in thread From: Robert Dewar @ 1996-02-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Ada is almost useless in embedded systems 1996-02-18 0:00 ` Robert Dewar @ 1996-02-19 0:00 ` John McCabe 0 siblings, 0 replies; 74+ messages in thread From: John McCabe @ 1996-02-19 0:00 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 74+ messages in thread
[parent not found: <4fs7ml$cf1@rational.rational.com>]
* Re: Ada 83 in embedded systems [not found] ` <4fs7ml$cf1@rational.rational.com> @ 1996-02-26 0:00 ` Alan Brain 0 siblings, 0 replies; 74+ messages in thread From: Alan Brain @ 1996-02-26 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 74+ messages in thread
[parent not found: <RALW.96Feb28100925@vulcan.gmrc.gecm.com>]
* Re: Ada is almost useless in embedded systems [not found] ` <RALW.96Feb28100925@vulcan.gmrc.gecm.com> @ 1996-03-15 0:00 ` Robert I. Eachus [not found] ` <dirk.827148504@demokrit> 1996-03-18 0:00 ` Alan Brain [not found] ` <dewar.825775334@schonberg> 1 sibling, 2 replies; 74+ messages in thread From: Robert I. Eachus @ 1996-03-15 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 74+ messages in thread
[parent not found: <dirk.827148504@demokrit>]
* Re: Ada is almost useless in embedded systems [not found] ` <dirk.827148504@demokrit> @ 1996-03-18 0:00 ` David Weller 0 siblings, 0 replies; 74+ messages in thread From: David Weller @ 1996-03-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Ada is almost useless in embedded systems 1996-03-15 0:00 ` Ada is almost useless " Robert I. Eachus [not found] ` <dirk.827148504@demokrit> @ 1996-03-18 0:00 ` Alan Brain [not found] ` <4ik5bm$ogg@dayuc.dayton.saic.com> 1 sibling, 1 reply; 74+ messages in thread From: Alan Brain @ 1996-03-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 74+ messages in thread
[parent not found: <4ik5bm$ogg@dayuc.dayton.saic.com>]
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] [not found] ` <4ik5bm$ogg@dayuc.dayton.saic.com> @ 1996-03-18 0:00 ` Robert Dewar 1996-03-19 0:00 ` Jay Martin 1996-03-19 0:00 ` Norman H. Cohen 0 siblings, 2 replies; 74+ messages in thread From: Robert Dewar @ 1996-03-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-18 0:00 ` Side-effect arithmetic again [was: Ada ... in embedded systems] Robert Dewar @ 1996-03-19 0:00 ` Jay Martin 1996-03-21 0:00 ` Robert I. Eachus 1996-03-19 0:00 ` Norman H. Cohen 1 sibling, 1 reply; 74+ messages in thread From: Jay Martin @ 1996-03-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-19 0:00 ` Jay Martin @ 1996-03-21 0:00 ` Robert I. Eachus 0 siblings, 0 replies; 74+ messages in thread From: Robert I. Eachus @ 1996-03-21 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-18 0:00 ` Side-effect arithmetic again [was: Ada ... in embedded systems] Robert Dewar 1996-03-19 0:00 ` Jay Martin @ 1996-03-19 0:00 ` Norman H. Cohen 1 sibling, 0 replies; 74+ messages in thread From: Norman H. Cohen @ 1996-03-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 74+ messages in thread
[parent not found: <dewar.825775334@schonberg>]
[parent not found: <RALW.96Mar8113005@vulcan.gecm.com>]
[parent not found: <4hv2fb$6ra@cville-srv.wam.umd.edu>]
[parent not found: <4xybp895y6.fsf@leibniz.enst-bretagne.fr>]
[parent not found: <3144CC40.33A0@escmail.orl.mmc.com>]
[parent not found: <dewar.826604375@schonberg>]
[parent not found: <3145FF2C.6139@escmail.orl.mmc.com>]
[parent not found: <dewar.826829407@schonberg>]
[parent not found: <31499D21.1DA6@escmail.orl.mmc.com>]
* Re: Bug or Limitation? (was: Ada is almost useless in embedded systems) [not found] ` <31499D21.1DA6@escmail.orl.mmc.com> @ 1996-03-15 0:00 ` Robert Dewar 1996-03-16 0:00 ` Ted Dennison 0 siblings, 1 reply; 74+ messages in thread From: Robert Dewar @ 1996-03-15 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Bug or Limitation? (was: Ada is almost useless in embedded systems) 1996-03-15 0:00 ` Bug or Limitation? (was: Ada is almost useless in embedded systems) Robert Dewar @ 1996-03-16 0:00 ` Ted Dennison 1996-03-20 0:00 ` Side-effect arithmetic again [was: Ada ... in embedded systems] Robert I. Eachus 0 siblings, 1 reply; 74+ messages in thread From: Ted Dennison @ 1996-03-16 0:00 UTC (permalink / raw) 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 | ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-16 0:00 ` Ted Dennison @ 1996-03-20 0:00 ` Robert I. Eachus 1996-03-20 0:00 ` Robert A Duff ` (3 more replies) 0 siblings, 4 replies; 74+ messages in thread From: Robert I. Eachus @ 1996-03-20 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-20 0:00 ` Side-effect arithmetic again [was: Ada ... in embedded systems] Robert I. Eachus @ 1996-03-20 0:00 ` Robert A Duff 1996-03-21 0:00 ` Peter Hermann 1996-03-20 0:00 ` John G. Volan ` (2 subsequent siblings) 3 siblings, 1 reply; 74+ messages in thread From: Robert A Duff @ 1996-03-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-20 0:00 ` Robert A Duff @ 1996-03-21 0:00 ` Peter Hermann 1996-03-21 0:00 ` Robert Dewar 1996-03-28 0:00 ` Mats Weber 0 siblings, 2 replies; 74+ messages in thread From: Peter Hermann @ 1996-03-21 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-21 0:00 ` Peter Hermann @ 1996-03-21 0:00 ` Robert Dewar 1996-03-25 0:00 ` Robert I. Eachus 1996-03-28 0:00 ` Mats Weber 1 sibling, 1 reply; 74+ messages in thread From: Robert Dewar @ 1996-03-21 0:00 UTC (permalink / raw) "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 :-) ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-21 0:00 ` Robert Dewar @ 1996-03-25 0:00 ` Robert I. Eachus 0 siblings, 0 replies; 74+ messages in thread From: Robert I. Eachus @ 1996-03-25 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-21 0:00 ` Peter Hermann 1996-03-21 0:00 ` Robert Dewar @ 1996-03-28 0:00 ` Mats Weber 1996-03-29 0:00 ` John G. Volan 1 sibling, 1 reply; 74+ messages in thread From: Mats Weber @ 1996-03-28 0:00 UTC (permalink / raw) >Ada0x will have general procedure calls We should call it Ada 0y because we already know that x = 5 ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-28 0:00 ` Mats Weber @ 1996-03-29 0:00 ` John G. Volan 0 siblings, 0 replies; 74+ messages in thread From: John G. Volan @ 1996-03-29 0:00 UTC (permalink / raw) 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?" ); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-20 0:00 ` Side-effect arithmetic again [was: Ada ... in embedded systems] Robert I. Eachus 1996-03-20 0:00 ` Robert A Duff @ 1996-03-20 0:00 ` John G. Volan 1996-03-22 0:00 ` Alan Brain 1996-03-21 0:00 ` Geert Bosch 1996-03-26 0:00 ` Mats Weber 3 siblings, 1 reply; 74+ messages in thread From: John G. Volan @ 1996-03-20 0:00 UTC (permalink / raw) 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?" ); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-20 0:00 ` John G. Volan @ 1996-03-22 0:00 ` Alan Brain 0 siblings, 0 replies; 74+ messages in thread From: Alan Brain @ 1996-03-22 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-20 0:00 ` Side-effect arithmetic again [was: Ada ... in embedded systems] Robert I. Eachus 1996-03-20 0:00 ` Robert A Duff 1996-03-20 0:00 ` John G. Volan @ 1996-03-21 0:00 ` Geert Bosch 1996-03-26 0:00 ` Mats Weber 3 siblings, 0 replies; 74+ messages in thread From: Geert Bosch @ 1996-03-21 0:00 UTC (permalink / raw) 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. ** ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Side-effect arithmetic again [was: Ada ... in embedded systems] 1996-03-20 0:00 ` Side-effect arithmetic again [was: Ada ... in embedded systems] Robert I. Eachus ` (2 preceding siblings ...) 1996-03-21 0:00 ` Geert Bosch @ 1996-03-26 0:00 ` Mats Weber 3 siblings, 0 replies; 74+ messages in thread From: Mats Weber @ 1996-03-26 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Ada is almost useless in embedded systems [not found] <823906039.22113@assen.demon.co.uk> ` (7 preceding siblings ...) [not found] ` <RALW.96Feb28100925@vulcan.gmrc.gecm.com> @ 1996-03-16 0:00 ` Kevin Dalley 8 siblings, 0 replies; 74+ messages in thread From: Kevin Dalley @ 1996-03-16 0:00 UTC (permalink / raw) >>>>> "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 ^ permalink raw reply [flat|nested] 74+ messages in thread
end of thread, other threads:[~1996-04-01 0:00 UTC | newest] Thread overview: 74+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <823906039.22113@assen.demon.co.uk> [not found] ` <4fgrq3$mc4@qualcomm.com> [not found] ` <dewar.823962356@schonberg> 1996-02-17 0:00 ` Ada is almost useless in embedded systems Tore Joergensen 1996-02-17 0:00 ` Robert Dewar 1996-02-19 0:00 ` Keith Thompson 1996-02-19 0:00 ` John McCabe 1996-02-21 0:00 ` Richard A. O'Keefe 1996-02-21 0:00 ` Norman H. Cohen [not found] ` <824056183.18993@assen.demon.co.uk> [not found] ` <311E924E.74CE@escmail.orl.mmc.com> 1996-02-17 0:00 ` Ada is great for embedded systems (was Ada is almost useless in embedded systems) Ken & Virginia Garlington [not found] ` <4fnqpm$3nh@news.sanders.lockheed.com> 1996-02-19 0:00 ` Ada is almost useless in embedded systems AdaWorks 1996-02-21 0:00 ` Ken Garlington 1996-02-21 0:00 ` Hugh Dunne [not found] ` <4fnp37$nj1@theopolis.orl.mmc.com> 1996-02-22 0:00 ` Alan Brain 1996-02-19 0:00 ` Jon S Anthony 1996-02-19 0:00 ` AdaWorks 1996-02-21 0:00 ` Ken Garlington 1996-02-23 0:00 ` AdaWorks 1996-02-19 0:00 ` R.A.L Williams 1996-02-21 0:00 ` Richard A. O'Keefe 1996-02-26 0:00 ` R.A.L Williams [not found] ` <4h3q56$1vk@goanna.cs.rmit.EDU.AU> [not found] ` <dewar.825635955@schonberg> [not found] ` <826571250.140@assen.demon.co.uk> [not found] ` <dewar.826634800@schonberg> 1996-03-21 0:00 ` John McCabe 1996-03-23 0:00 ` Side-effect arithmetic again [was: Ada ... in embedded systems] John G. Volan 1996-03-23 0:00 ` Robert Dewar 1996-03-25 0:00 ` Tucker Taft 1996-03-25 0:00 ` Robert A Duff 1996-03-25 0:00 ` Norman H. Cohen 1996-03-26 0:00 ` John G. Volan 1996-03-26 0:00 ` Robert Dewar 1996-03-29 0:00 ` Robert I. Eachus 1996-03-26 0:00 ` Robert A Duff 1996-03-26 0:00 ` Tore Joergensen 1996-03-27 0:00 ` John G. Volan 1996-03-27 0:00 ` John G. Volan 1996-03-28 0:00 ` Tucker Taft 1996-03-28 0:00 ` Robert Dewar 1996-03-29 0:00 ` Tucker Taft 1996-03-29 0:00 ` Tucker Taft 1996-03-27 0:00 ` John G. Volan 1996-03-29 0:00 ` Robert A Duff 1996-03-30 0:00 ` John G. Volan 1996-03-31 0:00 ` AdaWorks 1996-04-01 0:00 ` Robert A Duff 1996-03-30 0:00 ` John G. Volan [not found] ` <emery-0902962215150001@line316.nwm.mindlink.net> [not found] ` <DMoA85.52I@eskimo.com> [not found] ` <823965654.4500@assen.demon.co.uk> [not found] ` <824165619.14894@assen.demon.co.uk> [not found] ` <JSA.96Feb13133713@organon.com> [not found] ` <824259217.26321@assen.demon.co.uk> 1996-02-17 0:00 ` Ada is almost useless in embedded systems Robert Dewar 1996-02-18 0:00 ` John McCabe 1996-02-18 0:00 ` Robert Dewar 1996-02-19 0:00 ` John McCabe 1996-02-20 0:00 ` Robert Dewar 1996-02-21 0:00 ` Fergus Henderson [not found] ` <824332550.2485@assen.demon.co.uk> 1996-02-17 0:00 ` Ken & Virginia Garlington 1996-02-17 0:00 ` Robert Dewar 1996-02-18 0:00 ` John McCabe 1996-02-18 0:00 ` Robert Dewar 1996-02-19 0:00 ` John McCabe [not found] ` <4fs7ml$cf1@rational.rational.com> 1996-02-26 0:00 ` Ada 83 " Alan Brain [not found] ` <RALW.96Feb28100925@vulcan.gmrc.gecm.com> 1996-03-15 0:00 ` Ada is almost useless " Robert I. Eachus [not found] ` <dirk.827148504@demokrit> 1996-03-18 0:00 ` David Weller 1996-03-18 0:00 ` Alan Brain [not found] ` <4ik5bm$ogg@dayuc.dayton.saic.com> 1996-03-18 0:00 ` Side-effect arithmetic again [was: Ada ... in embedded systems] Robert Dewar 1996-03-19 0:00 ` Jay Martin 1996-03-21 0:00 ` Robert I. Eachus 1996-03-19 0:00 ` Norman H. Cohen [not found] ` <dewar.825775334@schonberg> [not found] ` <RALW.96Mar8113005@vulcan.gecm.com> [not found] ` <4hv2fb$6ra@cville-srv.wam.umd.edu> [not found] ` <4xybp895y6.fsf@leibniz.enst-bretagne.fr> [not found] ` <3144CC40.33A0@escmail.orl.mmc.com> [not found] ` <dewar.826604375@schonberg> [not found] ` <3145FF2C.6139@escmail.orl.mmc.com> [not found] ` <dewar.826829407@schonberg> [not found] ` <31499D21.1DA6@escmail.orl.mmc.com> 1996-03-15 0:00 ` Bug or Limitation? (was: Ada is almost useless in embedded systems) Robert Dewar 1996-03-16 0:00 ` Ted Dennison 1996-03-20 0:00 ` Side-effect arithmetic again [was: Ada ... in embedded systems] Robert I. Eachus 1996-03-20 0:00 ` Robert A Duff 1996-03-21 0:00 ` Peter Hermann 1996-03-21 0:00 ` Robert Dewar 1996-03-25 0:00 ` Robert I. Eachus 1996-03-28 0:00 ` Mats Weber 1996-03-29 0:00 ` John G. Volan 1996-03-20 0:00 ` John G. Volan 1996-03-22 0:00 ` Alan Brain 1996-03-21 0:00 ` Geert Bosch 1996-03-26 0:00 ` Mats Weber 1996-03-16 0:00 ` Ada is almost useless in embedded systems Kevin Dalley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox