* Re: FIXED bug in Medidian 4.1.1?
@ 1993-04-29 15:18 17% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-04-29 15:18 UTC (permalink / raw)
Well I am not sure that this kind of tutorial is an appropriate use of
comp.lang.ada bandwidth (this sort of question about fixed point should be
dealt with in the FAQ, and then people referred there when they ask about it)
However, since there was a follow-up which was incorrect, it needs correcting.
When you give a fixed point declaration where the end points are not model
numbers, it is not only allowed but *required* that the end points be
excluded from the representable range. It is thus not only allowable, but
required behavior that use of the end point values in this situation will
cause Constraint_Error.
The Meridian compiler is behaving according to the RM, and thus the subject
heading in this thread is incorrect, and the answer to the question mark at the
end of it is NO! I would suggest that people reserve the use of the word bug,
until they find out what is going on -- "Query regarding fixed point" would
have been a more appropriate title for the original posting.
Meanwhile, follow these simple suggestions for avoiding running into problems
with fixed-point.
1. Always make the end point values a multiple of the declared delta value
2. If the declared delta is not a power of 2, always put in a small
2.
declaration, of the form:
for Fixed_Type'Small use 0.01;
where the value is the same as the declared delta value. Your compiler
may reject this representation clause, in which case it just can't
handle this choice of delta. If it accepts it, then everything should
work as expected. Put the Small declaration right after the fixed
point declaration (this avoids some other curiosities that I don't
want to describe in detail)
^ permalink raw reply [relevance 17%]
* Re: A measure of Ada's death in the database world
@ 1993-04-29 16:02 18% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-04-29 16:02 UTC (permalink / raw)
class type x is new a,b,c;
Well first of all, that syntax isn't quite right, since it doesn't allow
for extensions, and also we don't use class in 9X in this way, so what I
would expect would be something like:
type x is new a,b,c with ...;
It's easy enough to write syntax like this, but there are big semantic problems
and big implementation problems (just to mention a couple, what about virtual
base classes, and how do you avoid distributed overehead from the *possibility*
of MI even if it isn't used -- C++ compilers usually pay such a distributed
overhead).
It's these semantic and implementation problems that make one think twice (or
perhaps ten times) before including MI in 9X. I certainly haven't seen anyone
complete a thorough design for such a feature which addresses all these
problems.
The real question is whether it is worth it. The post that this responds to
talks about using kludges, but one guys kludge is another guys elegant
approach. For instance, to an Ada programmer, having to use classes in C++
for what are better represented as packages, and then having to use multiple
inheritance for what is better represented by multiple package dependencies
is indeed a kludge -- but the kludge is in C++, not in Ada.
Despite a lot of attempts and requests, the discussion of MI in 9X has
generated a lot of suggestions that it should be included, but precious
few examples of programming examples that make this case in even a
semi-convincing form.
^ permalink raw reply [relevance 18%]
* Re: ADA Performance
@ 1993-04-29 16:12 17% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-04-29 16:12 UTC (permalink / raw)
The subject line of this thread is seriously misleading. The post had nothing
to do with Ada performance per se, but rather with the performance of a
particular Ada compiler compared to a particular Fortran compiler. Well no
one would claim that Ada (or Fortran for that matter) has a secret guarantee
that it is impossible to write slow compilers! Indeed we all know counter
examples.
But that should not lead one to believe that somehow there is something
inherently wrong with Ada performance. Certainly for example in GCC, if
you write a program in C, and then you write the same program in Ada, using
GNAT, you will get exactly the same optimized code because it's going through
the same back end. At least that's true if you use roughly the same level of
abstraction. Clearly introducing extra levels of non-inlined calls will slow
things down, but many Ada semantic features like packages, overloading,
generic instantiations, won't affect the code in any way, sinc they are
essentially front end abstractions that are lost long before the code
generator is reached. Similarly if you have checks on, you can expect a
(not terribly big) degradation -- FORTRAN looping type code is actually a
best case for minimal impact of checks in a decent Ada compiler.
That being said, comparing performance on type Complex between Fortran and
Ada 83 is definitely a worst case comparison from Ada's point of view. That's
because Fortran has the Complex abstraction built in, and it is always easier
to get a built-in abstraction working at high efficiency. Ada 9X recognizes
this particular problem by proividing Complex as a predefined abstraction in
the numerics annex. This doesn't guarantee efficient implementation, but in
practice it will help.
What would be useful from the original poster, is not so much the names of
the products involved, but rather an analysis of where the inefficiency is
coming from. Random mucking with the sources won't give this information.
What is really needed is to look at and analyze the resulting object code.
^ permalink raw reply [relevance 17%]
* Re: Incorporating 9X into Ada courses
@ 1993-05-01 6:55 17% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-05-01 6:55 UTC (permalink / raw)
I must say I find Feldman's comment on Ada pricing naive. All this talk of
gouging tax payers reads well as rabble rousing to the gallery, but does it
really make sense?
The issue that faces an Ada company is where to price its products in a market
whose elasticity is not known, but which is suspected to be much less than 1
(i.e. halving prices will not as much as double sales), and of course in
practice the elasticity must be much greater than 1 if halving the price is
to leave profits stable, let alone growing.
As you know, a fair number of people have lost a lot of money betting on the
Ada market. Now it may be that Ada companies have got the sums wrong, and that
they would make more money if they reduced prices.
However, when Mike says that "if an Ada company reduced prices and it didn't
work they would lose the ability to gouge the taxpayers" he has got it
completely wrong. On the contrary, the penalty for such a misstep would almost
certainly be that the company would fail.
As it is, several Ada companies have in effect failed (Alsys, Telesoft,
Systeam), and certainly no one is getting rich in the Ada business. In a
situation where everyone is losing money, or at best not making much money,
it is rather absurd to make accusations of venality. One can accuse Ada
companies of making the wrong choices -- Mike has gone of on this thetorical
tact quite effectively in the past -- but it seems silly to accuse someone of
price gouging when they are losing money!
How elastic is the Ada market? If you really believe the elasticity is
greater than 1, and that hence it would benefit Ada companies to reduce
prices, then concentrate on that point, and save the accusatory approach
for a situation in which it is more appropriate!
^ permalink raw reply [relevance 17%]
* Re: FIXED bug in Medidian 4.1.1?
@ 1993-05-04 4:05 20% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-05-04 4:05 UTC (permalink / raw)
Tucker Taft shouldn't apologize for disagreeing with me when I am wrong!
I think his analysis is probably exactly correct, and it does indeed appear
that there is a bug.
Also, when I said that a compiler was required to excluded end-points that
are declared in some declarations, I didn't mean all declarations, just that
the rules do require such exclusion in some cases. This remains a mighty
peculiar feature to many programmers, who find it mysterious to get
a constraint error when they write:
type x is delta x range y .. z;
vx : x := y; -- ce raised here
We thought about trying to fix this in 9X, but decided against it (at least
according to my current understanding), because it would have introduced
subtle incompatibities, and not than many people use fixed point. The new
information systems annex *does* provide the necessary facilities, based on
use of a specialized form of fixed-point, for financial calculations.
^ permalink raw reply [relevance 20%]
* Re: Passing procedures as parameters to procedures.
@ 1993-05-05 17:35 21% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-05-05 17:35 UTC (permalink / raw)
I actually think that in languages at the level of Ada/C etc, the notion of
pointer to procedure is clearer than the idea of a procedure as a value.
An interesting note here is that one Algol-68 text book contained in its
helpful advice the suggestion that it was better to pass procedures by
reference rather than by value, because it would avoid inefficient copying
of the code of the procedure. This may be an extreme case, but it is a nice
indication of the confusion that can be caused by considering procedures as
values in this level of language.
^ permalink raw reply [relevance 21%]
* Re: Passing procedures as parameters to procedures.
@ 1993-05-05 17:39 22% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-05-05 17:39 UTC (permalink / raw)
Now I've seen it all:
"Of course you can do this in Ada, just use package machine code to construct
the code that you want to execute."
Hmmm! why bother wih Ada/9X, just require Ada/83 compilers to implement
package machine code and we can do anything we like :-)
^ permalink raw reply [relevance 22%]
* Re: Ada Mflops vs Fortran Mflops (RESULTS)
@ 1993-05-19 3:22 22% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-05-19 3:22 UTC (permalink / raw)
Just so there is no confusion on this point, my observations on what you
could expect comparing code from Ada (GNAT) via the GCC backend and similar
C code are not "theories", but are based on detailed knowledge of the
implementations, and observations of the code in action. For example, inlining
in GCC is done in the backend so there is no question of the front end somehow
missing inlining opportunities.
^ permalink raw reply [relevance 22%]
* Re: verdix kisses off Ada
@ 1993-05-20 13:44 14% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-05-20 13:44 UTC (permalink / raw)
I am sorry to puncture a "wonderful irony", but GNU Ada is NOT being developed
in C or C++. Here is the exact story:
GNAT (the official name for GNU/Ada, it stands for GNU NYU Ada Translator)
uses the existing GCC backend. That is, for understandable historical reasons
written in C, and we are using it pretty much as is, with some minor changes
to accomodate Ada (minor here means that the total impact is a small fraction
of the original work). We are *not* going to rewrite this in Ada -- there are
good technical and non-technical reasons for this decision, and note that even
if this were a project covered by the mandate, no one would suggest that it
makes sense to rewrite several hundred thousand lines of code in Ada just for
the sake of doing so!
The front end of GNAT, which is really where the development of the project
is, is in Ada. Currently, for obvious bootstrap reasons, it is in Ada 83, but
may eventually shift to 9X as we bootstrap (a point we are close to right
now). The GNAT front end is currently about 68,000 lines (23,000 if you count
semicolons).
Finally there is a relatively small interface module, called Gigi (*), that
takes the Ada tree and constructs the GCC tree for the backend. This is
written in C because it needs to connect intimately to the C structures in
the backend. Actually if we were fully bootstrapped, we probably COULD
rewrite this in Ada, since GNAT will inter-operate very closely with GNU C,
but there was no way to do this early on, and in any case Gigi is only
a couple of thousand lines of pretty straightforward C.
So, in terms of new code being written, GNAT is over 90% in Ada. The
percentage will increase as time goes on, because we have a lot more
additions still to go in the front end. Furthermore, the runtime will
also be all in Ada, except for the usual tiny operating system interface
stuff that is needed at a low level.
So, no irony here! Furthermore, I should report that the experience in
switching from C to Ada in our Ada group at NYU (the old Ada Ed code was,
as I think people are aware, all in C), was quite remarkable.
Our C code suffered from all the usual defects that people associate with
C (lack of documentation, lack of clear interface design, incompatible
coding styles, very variable quality etc.)
When we started coding in Ada, our whole approach changed. We started having
regular design meetings which focussed on package spec design etc. etc. You
all know this story, I don't have to repeat it in detail, but it certainly
is interesting to see it happening again in ones own back yard!
Robert Dewar (codirector with Ed Schonberg of GNAT project at NYU)
(*) For the curious, the etymology of the name Gigi is that this program
translates from the GNAT tree to the GCC tree, hence it came to be called
G-to-G or G-squared, and thus Gigi became a natural, somewhat more colorful
version of the same name.
^ permalink raw reply [relevance 14%]
* Re: verdix kisses off Ada
@ 1993-05-20 17:30 20% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-05-20 17:30 UTC (permalink / raw)
Ooh boy, calling the GNU Ada team "hackers" is really asking for
trouble. I suggest you quickly put on your flame-proof suit...
Not to worry, no real flames on that score. Hacker after all is a venerable
term with all sorts of connotations. What I think I can say is that the
project at NYU is run in a manner comparable to a typical compiler project
in a commercial compiler company (apart from being willing to share what
we are doing!) We operate with a source control system, a fairly rigid set
of coding standards, well defined specifications, and a heavy emphasis on
design and structure, and so far this seems to be working well for us. If
anyone is in New York and would like to visit us, they would be welcome,
send me email, and you can see for yourself! I am afraid it won't completely
satisfy those who like to think of us working in a "true" hacker mode!
^ permalink raw reply [relevance 20%]
* Re: what languages Ada 9X compilers are being written in
@ 1993-05-28 6:37 22% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-05-28 6:37 UTC (permalink / raw)
With respect to the idea of using an enumeration type and 'VAL to read and
parse keywords, it's cute, but no serious compiler would use such a technique
since it is likely to be seriously inefficient, and any gains in simplicity
are probably illusion in the context of a complete lexical scanner.
^ permalink raw reply [relevance 22%]
* Re: Study shows Ada tools ten times more costly
@ 1993-05-28 6:40 22% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-05-28 6:40 UTC (permalink / raw)
-- Sort of irrelevent. We are talking cross-development tools. Also
-- the Ada/Ed translator is currently available from the FSF, and the
-- GNAT Ada 9X front end will shortly be bundled with the above.
This information is incorrect. The Ada/Ed translator is available by
anonymous FTP from NYU, but there is no connection with the FSF. It
is true that we hope to bundge GNAT with the standard GCC distribution
^ permalink raw reply [relevance 22%]
* Re: VERDIX KISSES OFF ADA
@ 1993-05-28 6:41 20% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-05-28 6:41 UTC (permalink / raw)
"If it [Turbo-Ada] is to compete with Turbo-Pascal, it had better be
written in hand coded assembler"
I think that's a wrong conclusion. In fact I think that Turbo-Pascal is
disappointingly slow given the fact that it operates in memory and is
written in assembler. I would think it should be ten times faster than
it is under these conditions. My hand coded scanner and parser for Ada
runs at nearly 3,000,000 lines a minute on a top end PC, so I would
certainly think that a complete compilr (generating pretty straightforward
code, as TP does) should be able to achieve 500,000 - 1,000,000 lines/minute.
Another point of comparison is that Turbo-Pascal is not significantly
faster than Realia COBOL, but the latter compiler is written entirely in
COBOL and is a six pass compiler that definitely does *not* keep everything
in memory (in fact even the symbol table is on disk, though of course these
disk files are in practice buffered in avaiolable memrory wheere possible).
^ permalink raw reply [relevance 20%]
* Re: Learning C and C++
@ 1993-05-28 20:22 20% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-05-28 20:22 UTC (permalink / raw)
One interesting point (for the fellow who is falling off the good ship USS
Ada and will have to fend for himself among the C and C++ reefs) is that
a good background in Ada is excellent preparation for C programming. As is
so often the case in moving from one language to another, you can carry
good habits from one place to another. Often we scorn people who write
language X in the style of Y, but actually I think this is an excellent idea
when X=C and Y=Ada. In particular, the discipline of careful design of package
specs can carry right over to a very disciplined approach to the design,
coding and documentation of C headers.
This certainly won't solve all your problems, and when you jump overboard
I strongly recommend grabbing onto the nearest debugger, you'll find yourself
living in it much more than you did in Ada!
^ permalink raw reply [relevance 20%]
* Re: Ada name space (was: Re: good software engineering)
@ 1993-06-02 18:12 18% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-06-02 18:12 UTC (permalink / raw)
One of the problems in choosing names for Ada packages that are to be shared
is that the naming style that one wants is indeed very different depending
on whether or not you expect to use qualification.
The most sensible thing would be for each portable package to simply specify
whether or not it was intended to be used with "use" clauses or not.
The trouble is that if you design a package with names chosen to be appropriate
if the package is used, then when people import it into an environment where,
for whatever reasons, the use of use is restricted, they end up with horrible
names.
One can of course decide that all portable packages should have names designed
for fully qualified use, but you have to remember that a lot of Ada programmers
prefer *not* to use fully qualified names all the time.
I don't intend to start a futile flame war as to whether one should or not
make use of use clauses, or insist on full qualification. This has been
discussed to death. The bottom line is that there are really two schools
of thought, and the real world contains people with both points of view
(I dislike the fully qualified style, but I quite understand that there
are many Ada programmers who prefer it, and I am not about to argue that
they should change -- anti-use people should show the same curtesy in the
other direction!)
So we are left with trying to compromise between the two viewpoints. Certainly
I think most people dislike thinks like:
Posix.Posix_Exceptions
Robert Dewar
^ permalink raw reply [relevance 18%]
* Re: Learning C and C++
@ 1993-06-03 12:48 19% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-06-03 12:48 UTC (permalink / raw)
Of course I agree with Bob, the use of the C macro processor to distort the
syntax is a truly horrible practice. Indeed it is this kind of abuse of
macro processors that helped result in the rather draconian approach of
Steelman which required that Ada NOT have a macro processor.
When I talked of using Ada style in C, I was referring not to low level
syntactical stuff, where you are stuck (or blessed, depending on your
point of view, or perhaps whether you are a reader or writer) with the
C syntax, but rather to high level structuring approaches.
In particular, I think most C programming would benefit from a much more
disciplined view of header files, to elevate these to the same level of
importance, design and control as package specs in Ada. Of course in C one
has to depend on people's good behavior or the use of external tools where
in Ada the language provides the necessary control, but it's quite possible
to write C using the Ada package style.
^ permalink raw reply [relevance 19%]
* Re: Meridian and ADA
@ 1993-06-03 12:56 22% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-06-03 12:56 UTC (permalink / raw)
Damian, have you contacted Meridian technical support. That seems the first
place to go with such a problem, and it is always interesting to here from
people what their experiences with technical support is. Of course no vendor
can spend time finding bugs in arbitrary user programs, but they may be
able to help point you in the direction of how to use tools such as debuggers
to track down your problems.
^ permalink raw reply [relevance 22%]
* Re: Meridian and Ada (not ADA)
@ 1993-06-06 23:21 22% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-06-06 23:21 UTC (permalink / raw)
Sam, do you in fact know that your algorithm for computing E was
stable under Brown rule semantics?
^ permalink raw reply [relevance 22%]
* Re: How to Make Ada more widely used?
@ 1993-06-08 12:45 22% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-06-08 12:45 UTC (permalink / raw)
Greg Aharonian uses an interesting form of argument. His thesis is that
the mandate is responsible for the lack of libraries etc. He never gives
any hard data to support such a viewpoint (indeed it's hard to imagine how
any such data could be obtained). So apparently he feels that an acceptable]
substitute is simply to repeat the unsubstantiated claim seven times a day.
^ permalink raw reply [relevance 22%]
* Re: References in Ada exceptions
@ 1993-06-25 12:37 17% news.intercon.com!panix!netnews!schonberg!dewar
0 siblings, 0 replies; 200+ results
From: news.intercon.com!panix!netnews!schonberg!dewar @ 1993-06-25 12:37 UTC (permalink / raw)
Well of course I is defined within the exception handler. This is a normal
consequence of fundamental rules of visibility etc. Thus no ruling is
needed or available, and there is no specific "hard reference" to point
to (after all you can't find a hard reference that says that there is no
problem in referencing an identifier starting in column 51!)
^ permalink raw reply [relevance 17%]
* Re: Is there a GNU ADA compiler?
@ 1993-07-21 15:02 17% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-07-21 15:02 UTC (permalink / raw)
Could whoever is in charge of the FAQ for this newsgroup update the
information on the GNAT (GNU Ada) project appropriately, it would help
to reduce requests for information. It would also help if the FAQ mentioned
the contact address gnat-request@cs.nyu.edu
^ permalink raw reply [relevance 17%]
* Re: Underscore ("_") in numeric literals
@ 1993-07-27 20:17 17% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-07-27 20:17 UTC (permalink / raw)
Charlie's note pretty much reflects what I would think of as standard
Ada style, and a reasonable recipe for making use of a very useful
lexical convention.
What would be interesting is to understand why the question was asked in
the first place?
^ permalink raw reply [relevance 17%]
* Re: Ada 9X compiler for the PC
@ 1993-07-28 12:09 16% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-07-28 12:09 UTC (permalink / raw)
To repeat a message posted before, nothing is "finalized" at NYU. Don't
believe everything you read in Infoworld, except perhaps the letter from
Ed Schonberg in the latest issue which corrects the mistake. Note
incidentally that while the article in question was a bit over enthusiastic
about the NYU effort, or perhaps I should say a bit premature, its general
enthusiasm for Ada ("the theme was 'can I persuade you to use this great
language'") was encouraging reading that week.
^ permalink raw reply [relevance 16%]
* Re: ADA arithmetic
@ 1993-07-28 12:11 17% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-07-28 12:11 UTC (permalink / raw)
To put my 2c in on this issue, I thought the assignment in question was
pretty easy, well within reach of a first programming course if the
algorithmic points are discussed a little in class.
^ permalink raw reply [relevance 17%]
* Re: ADA arithmetic
@ 1993-07-28 12:13 16% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-07-28 12:13 UTC (permalink / raw)
Of course Simon's suggestion of how to program multi-precision numbers in
Ada is reasonable as a crude approach for beginning students, but is
ludicrously inefficient. Probably it is likely that a well written routine
(I believe brother Eachus is hard at work on a portable efficient 64-bit
integer package) will be an order of magnitude faster.
Of course in assembler one can do much better. This is one of the very few
times that assembler is not only more efficient but much easier to program
than typical high level languages like Ada. Why: because these languages
don't give access to the crucial primitives such as unsigned add with a
carry indication.
^ permalink raw reply [relevance 16%]
* Re: Ada is not a failure.
@ 1993-07-31 2:54 17% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-07-31 2:54 UTC (permalink / raw)
My goodness, TH is back. I probably wouldn't have noticed but when we
installed a new mail system, all the old kill files got lost. Actually
if TH is back online, I think I'll wait a bit before updating the old
kill list. Might be interesting to see TH and GA conducting a "debate" :-)
^ permalink raw reply [relevance 17%]
* Re: Are 'best' universities being targeted for Ada9X
@ 1993-07-31 3:13 14% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-07-31 3:13 UTC (permalink / raw)
While I agree one should not overemphasize the role of a particular language
as an initial teaching language in the first programming course, one should
also not make the mistake of underestimating the influence of the particular
language chosen.
I was amazed at the time by the reaction in the US to EWD's letter on
"gotos considered harmful". I am sure that EWD did not think he was saying
something profound or new, because anyone who was exposed to Algol-60 at
the time knew perfectly well that it was obvious that the use of gotos
should be minimized.
The storm that it caused in the US was I think directly related to the
comparative prevalence of FORTRAN as a first teaching language, and to
typical programmers trained in FORTRAN, the idea of not using gotos was
indeed novel, as was (much more importantly) the notion of microstructure
in programs, which was the underlying issue.
^ permalink raw reply [relevance 14%]
* Re: Are 'best' universities being targeted
@ 1993-07-31 3:18 13% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-07-31 3:18 UTC (permalink / raw)
In discussing computer science at the "best universities" [whatever that may
mean], I think it is important to understand that very little of computer
science is concerned with programming per se, or software at all for that
matter. Consequently the number of CS faculty who know much about programming
is typically quite small, they are experts in their fields, and programming
does not have much to do with many fields in CS. The number of faculty members
who know anything about software engineering is even smaller.
I recall one instance at a large university in the CS department where there
was energetic debate and breast-beating over the fact that some undergraduate
had interviewed for a job and not known what a finite state machine was. Now
actually I suspect the student had probably been taught this several times
[faculty membes will persist in confusing curriculum with student knowledge!]
but my reaction was something like:
"well, sure it's disappointing that a student doesn't know what an FSM is,
but in some respects I am more disturbed by the fact that are undergrads
are much more unlikely to know what CASE is all about."
The reaction from most of the faculty was "what the heck is CASE?" :-)
^ permalink raw reply [relevance 13%]
* Re: Query about monitor (passive) task optimization
@ 1993-07-31 3:27 14% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-07-31 3:27 UTC (permalink / raw)
Mike assumes that automatic recognition of passive tasks is a good thing.
He is apparently unaware that this is by no means obvious, and indeed most
of the Ada folks in realtime areas that I have talked to do not AT ALL like
the idea of such automatic recognition, and much prefer explicit control
over thread structure.
Many of us felt in the Ada 9X process that the needs for efficient
tasking would better be met by formalizing and structuring the opportunities
for this kind of task optimization, but it was quite clear that the realtime
community much prefers the explicit approach as exemplified by the protected
type feature of 9X.
I also know that Alsys found in deciding how to proceed that people in
general much preferred the kind of explicit pragma approach that Verdix
uses to the kind of automatic recognition that DDC does.
So, sure it's nice to see different vendors doing different things and taking
different approaches, but Mike's "finally! at last! someone doing something
reasonable for tasking!" approach is plainly inappropriate.
^ permalink raw reply [relevance 14%]
* Re: An Apology to Mr. Ada on "Ada Sucks"
@ 1993-07-31 17:29 17% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-07-31 17:29 UTC (permalink / raw)
Actually it is instructive to see this kind of abusive language in people's
posts, because it allows one to make an appropriate judgment as to the
general reliability of the poster!
^ permalink raw reply [relevance 17%]
* Re: Query about monitor (passive) task optimization
@ 1993-08-09 4:41 7% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-08-09 4:41 UTC (permalink / raw)
First of all, Mike says that "we are in disagreement". If we means Robert and
Mike, then he is reading my original message carelessly, since nowhere in that
message did I express my opinion on the matter -- I merely reported the
empirical fact that a substantial number of real-time people object to
automatic recognition of passive tasks.
Well disagreeing with that would say you did not believe this was the case,
but the rest of Mike's message makes it clear that he does recognize this
(although he doesn't like it).
Now, what do I think about this? Well I don't really see a huge market for
optimized tasking that is not under control of the user. Mike says he want
s this factility, but I have trouble believing this, because I doubt he has
applications where this kind of optimization is important. Instead I would
guess he is speaking not for himself, but for a constituency that he imagines
exists. This consituency is not the hard real-time folks [Mike it isn't just
some psychological glitch that makes these people want to control thinks, they
have to have close control if they are to ensure that deadlines are met etc.]
Does this constituency in fact exist? Well I doubt it is significant. Most
people either don't care very much about efficiency of tasking or they care
very much. If you care very much, then you just can't afford to leave it to
some unknown algorithm in the compiler for passive tasking optimization,
resulting in a situation where you have no idea whether a task you write
represents a real thread of control with its attendant overhead or not.
Mike speaks glibly of improving compiler technology, but the trouble with
optimizations of this kind is that the only technology that is in sight is
the ability to recognize certain special cases. Either these cases are
extremelye easy to describe and program or they are not. If they are, then
you at least want compiler support to make sure that you do not stray outside
the recognized idioms, and you might as well have a pragma for this purpose.
Otherwise you get a situation where a small maintenance change breaks the
optimization pattern, and suddenly there is a big non-linear response in the
performance of the program. If on the other hand the description of what cases
can be optimized is complex (as is likely to be the case, because the compiler
typically will be operating at that stage on a tree that has been subjected
to a series of hard to specify and describe transformations), then you are
in really deep water, since no one can tell what is going on.
A similar sort of situation arises in transformational programming in general.
Should a compiler try major transformations on its own (e.g. replacing a
simple high level statement of a sort with a complex algorithmn such as
heap sort, or do recursion rearrangement to reduce space usage to linear
instead of exponential?) Well of course such transformations are of course
possible automaticaly in a limited set of circumstances, but you tend to get
a very difficult to use system if you try to do things automatically.
In short, I think it is probably a bad idea to put too much effort into this
kind of optimization. Believe me, there are *plenty* of opportunities for
more straightforward optimization that have by no means been fully exploited.
As a result I think it would be a bad idea for vendors to put much effort
in this area.
One more thing. As we well know, Mike is on the lookout for cheap compilers
for educational use, which is fair enough, but he cannot at the same time
expect to influence the commercial vendors in terms of what optimizations
they might offer. If indeed the constituency that he imagines exists, it
would presumably have resources to encourage the vendors to move in this
direction. The fact that vendors have not heard people clamoring for this
kind of support I think legitimately indicates that this constuency does
not in fact exist.
The facile belief that compilers can do amazing optimizations is often
heard. Indeed I think the original Ada design was in some cases badly
influenced by this belief (why for instance is there no proper control
over storage management in Ada 83 -- at least part of the answer is that
some people thought that compilers would be able to do an amazing job
of implementing garbage collectors and special storage management
optimizations. Well ten years ago I would have said this was an unrealistic
expectation. Ten years later my opinion is not changed one iota, since
there has been essentially no advance in compiler optimization technology
(of a relevant kind) in this time.
Robert
Robert
Robert tt
^ permalink raw reply [relevance 7%]
* Re: Query about monitor (passive) task optimization
@ 1993-08-09 4:47 12% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-08-09 4:47 UTC (permalink / raw)
Jonothan Shilling asks why people do not want automatic task optimization.
After all, he asks, it only makes programs run faster.
Well the point is that in realtime programs, running faster is not typically
a requirement. The requirement is that all tasks complete their assigned
tasks on schedule. General optimizations that may or may not speed up some
tasks, depending on what the compiler can figure out, are not much help to
a programmer who must demonstrate that the program he writes will meet its
deadlines.
Imagine a worst case. Suppose a compiler used some probabilistic algorithm
to estimate how it should optimize tasks. This is not unreasonable. The
compiler has incomplete information about the program being compiled, so
game theory would suggest that an optimizal strategy would be a mixed
stratecy involving probabilistic choices. Well such a compiler would be
unusable in real-time contexts -- every time you compiled, you might find
that different tasks were optimized and the program would change its
execution characteristics and perhaps correctness.
\
On the other hand, this compiler would, on average, execute Ada programs
faster than a compiler which did not do such probabistic optimization.
The question is: are there applications which use tasking, and are basically
interested in overall speed throughput, rather than simply that tasks
meet their deadlines. Well certainly one can construct examples, but I
suspect that in real life such examples are few and far between.
Anyone care to report experience with applications of this type (i.e. ones
where the issue is not meeting deadlines, but just generally fast execution.
Remember they must also be applications where tasking performance is
in fact important to overall performance).
Robert
^ permalink raw reply [relevance 12%]
* Re: Query about monitor (passive) task optimization
@ 1993-08-09 4:57 12% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-08-09 4:57 UTC (permalink / raw)
Mike certainly seems to be in ranting an raving mode again ("Beltway
bandit mentality") etc.
I think his comments betray a real lack of familiarity with the reality of
production compilers. Elaborate optimizations are almost always a mistake.
They don't pay off in real life nearly as much as people hope, and they
tend to make compilers very expensive to produce, very expensive to maintain
and unreliable.
The maintenance issue in particular is important. A typical situation is that
a complex optimization is installed. It works on all the test programs, and
works well for a while, then a customer discovers a bug where the optimizer
screws up [I don't suppose anyone reading this newsgroup has *ever* had
such an experience :-) ]
The maintenance required is a complete reanalysis of the optimization
algorithms to fix the problems arising presumably from some bad analysis
in the first place. In practice maintenance people are not capable of this,
and the easy maintenance fix is simply to disconnect the optimization. Fran
Allen, of IBM, once said in a talk I heard (I don't know if this is in print)
that nearly half of the optimizations in the IBM optimizating PL1 compiler
were disconnected during the maintenance process.
Certainly one might criticize the Ada vendors and second guess how they
had spent their money (Mike you might want to talk to one of the many
investors who lost their money and tell them that you are irritated that
Ada compiler companies have never invested money up front to try to make
money!) However, it is clear to me that if Mike directed the spending of
such money he would manage to blow it much faster.
You want to know where I would spend money: bindings, bindings, and then
if any was left over, bindings.
Robert
^ permalink raw reply [relevance 12%]
* Re: Are 'best' universities being targeted
@ 1993-08-09 5:00 17% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-08-09 5:00 UTC (permalink / raw)
please move discussion of undergraduate curricula to the appropriate
newsgroups. Specific discussion of Ada's place in such a curriculum is
appropriate here, general discussion of issues is not.
^ permalink raw reply [relevance 17%]
* Re: Are 'best' universities being targeted
@ 1993-08-09 5:02 17% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-08-09 5:02 UTC (permalink / raw)
Well spoke John Biedler! In fact I think a lot of the "leading
universities" are turning out computer science students who not
only do not know anything about software engineering and construction
of large programs, but, much worse, they *think* they *do* know
something which makes them dangerous rather than useless. This is not
surprising given that the majority of the faculty members in such
departments know nothing about such things themselves.
^ permalink raw reply [relevance 17%]
* Re: QUERY ABOUT MONITOR
@ 1993-08-09 5:08 16% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-08-09 5:08 UTC (permalink / raw)
I couldn't tell whether Mike's post was intended to be facetious or not.
I will assume that it was serious. If not, sorry!
Really! if the only reason you can't reuse Fortran code is array mapping,
have you ever considered the amazing technique of reversing the order of
the subscripts in the declaration on the Ada side? That is ALL we are
talking about. Let's not make mountains out of mole hills here. The feature
is useful, but not essential, it's just a minor convenience to have the
compiler do this flipping of subscripts automaticaly.
^ permalink raw reply [relevance 16%]
* Re: Ada is not a failure.
@ 1993-08-09 5:12 16% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-08-09 5:12 UTC (permalink / raw)
John Doner says "The way to make money in the personal computer market is
to price low and sell lots of copies" or words to that effect, and suggests
we look at Borland.
I think it's a good idea to look at Borland. What you will find is a company
whose stock has plummeted and which is in pretty shaky shape, at least partly
because they believed in the low price approach too long.
^ permalink raw reply [relevance 16%]
* Re: storing arrays for Fortran (was: QUERY ABOUT MONITOR)
@ 1993-08-09 5:18 16% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-08-09 5:18 UTC (permalink / raw)
Mike misplaces the blame here. The issue is not "a strong standard", but
rather the question of whether the language should have checks or not, which
is a language related issue that has pretty much nothing to do with
standarization. The trouble is that once you say you want checks, you tend
to introduce notions of canonical order which clearly do not exist in
languages like Fortran and C that do not have the notion of checks built
into the language. It'
s basically a question of safety vs efficiency, nothing to to with
standardization.
^ permalink raw reply [relevance 16%]
* Re: Ada and C++: A request for comparison/contrast/relative benifits
@ 1993-08-09 5:25 17% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-08-09 5:25 UTC (permalink / raw)
Harry is too facile in awarding C++ the prize for greater functionality.
There are those who think that exceptions, control over bit placement in
records, built in tasking, etc. etc. might be quite useful [perhaps even
more useful than OOP features, who knows?]
^ permalink raw reply [relevance 17%]
* Re: Query about monitor (passive) task optimization
@ 1993-08-09 12:14 13% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-08-09 12:14 UTC (permalink / raw)
Regarding Richard's notes on GCC: one point here is that GCC realy does not
do any complex global optimizations of the type attempted in the optimizing
PL1 compiler, at least as far as I understand its structure. Perhaps the
experience that Richard reports is actually a confirmation that such
optimizations are the ones that tend to cause trouble. GCC generates extremely
good local code, and its success in competing against what on paper would
seem to be much more ambitious attempts at optimization just go to show that
concentrating on good local code gets you most of the way without needing
very complex optimizations.
The kind of optimizations we are talking about here: recognizing entire
tasks as obeying a set of restrictions (typically involving intermodule
link time analysis if the bodies are separately compiled), and then performing
(again at link time in the general case) extensive transformations on the
program tree are definitely not the kind of thing that GCC goes in for (GCC
does not even attempt intermodule register allocation, a la MIPS, let alone
more complex intermodule transformations).
Incidentally, if you think that compiling the spec and body of a task in the
same unit is an acceptable restriction for activating this kind of optimizat
ion, then I would react that I would *much* prefer a pragma in the spec to
this kind of severely destructuring kind of restriction.
^ permalink raw reply [relevance 13%]
* Re: forth/fifth generation languages?
@ 1993-08-09 22:00 13% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-08-09 22:00 UTC (permalink / raw)
Just for the record, there was a fair amount of "primordial ooze" in
Algol-60 (see for example Knuth's article on "The Remaining Trouble Spots
in Algol-60") Speaking as one who was involved in the attempted
standardization of Algol-60-modified ten years later, I can assure you
that there were even at that point a number of serious holes.
I also find the syntax junky in places (e.g. the dangling else rule), and
the semantics of procedure calls remains murky (although it was cleared
up in a60-modified, in particular what does it mean if you don't give
types to the formal parameters -- no one implemented this of course on
typical machines where it is quite important to distinguish integers and
reals).
Also there were huge functional holes in A60, including lack of I/O,
lack of any string handling capability, lack of any parallelism, and lack
of any kind of data abstraction.
Sure I realize that there were elegant features, but, even though this is
a bit off subject for the Ada newsgroup, I think it is important to
counteract a false impression that somehow A60 was this jewel of perfection.
It failed for many reasons, but one of the reasons was errors of judgment
on the part of the designers -- it was by no means perfect
^ permalink raw reply [relevance 13%]
* Re: Ada and C++: A request for comparison/contrast/relative benifits
@ 1993-08-09 22:06 16% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-08-09 22:06 UTC (permalink / raw)
Regarding the note on the difference in the Booch components between the
Ada and C++ versions.
First, part of the imnprovement simply comes from the recoding.
Second, as Ed Schonberg has described in more details, the work we did
as the IAT here at NYU showed that the C++ versions could be recoded in
Ada 9X in a straightforward manner leading to a version that was about the
same length, but, in our opinion was much more readable [we are not great
fans of the C++ syntax -- probably one of the languages poorer features]
^ permalink raw reply [relevance 16%]
* Re: Query about monitor (passive) task optimization
@ 1993-08-10 13:44 14% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-08-10 13:44 UTC (permalink / raw)
Grumble, grumble! Mike, don't over-generalize what I say. I have not said that
I though that there was in general no constituency for trying to improve Ada
compilers. Instead I just expressed opinions on specific areas: automatic
passivization of tasks (I now think this is probably an idea that does not
fly effectively in the Ada context), and specialized Fortran interface
stuff (I think that's quite worthwhile, but I would not hold my breath
for the Fortran crowd to come beat down our walls -- rather I think of it
as a way of letting Ada users take better advantage of all that Fortran
stuff out there!) As you know, my emphasis is on bindings. If I want to
write an enterprise wide application using an OS/2 client-server network,
would I choose Ada? At the moment I have to say no because I do not have
an effective PM binding with any of the commercial compilers [the binding
supplied with the Alsys compiler is welcome, but is fairly thin, and probably
suitable only for limited mucking around].
^ permalink raw reply [relevance 14%]
* Re: Query about monitor (passive) task optimization
@ 1993-08-10 13:51 13% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-08-10 13:51 UTC (permalink / raw)
Mike, one point that I keep making. It is absolutely NOT fair to paint all
Ada vendors as entirely defence oriented. In fact Alsys was founded by JDI
on the principle of specifically going after the non-military market. While
this succeeded fairly well in France, it was of limited success in the US.
I think part of the problem is that even though there were some successes
(you have the list!) compiler companies for any compiler for any language
have a heck of a hard time making money. It is true that Alsys has turned
to the defence industry more in recent years -- you go where the money is
in any business. It may also be true that Alsys did not make the right
decisions, who knows? but it is truly unfair to include Alsys in your
blanket criticism of Ada companies attitudes.
I suspect the criticism is also inappropriate for several other Ada vendors,
but I am not close enough to speak for them so I will let them speak for
themselves [just an example: Rational's involvement with the new government
information system in Singapore seems to me a clear counter-example and I
think there are probably many others].
^ permalink raw reply [relevance 13%]
* Re: QUERY ABOUT MONITOR
@ 1993-08-10 14:00 11% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-08-10 14:00 UTC (permalink / raw)
Mike repeats a common myth about Fortran, namely that it requires arrays to
be passed by reference. This is rubbish. In fact Ada tried to copy Fortran's
approach carefully. Both Ada and Fortran allow composite objects to be passed
by reference or value, as decided by the compiler. Any Fortran code that
counts on pass by reference is faulty (Mike if you don't believe this, settl
down with the Fortran standard, it's perfectly clear there).
However, in practice, both in Ada and Fortran, arrays are typically passed by
reference, so this is from a pragmatic point of view a non-issue.
All Ada compilers I know of lay out arrays contiguously (interestingly enough
Mike makes the opposite mistake here, Fortran DOES require arrays to be laid
out contiguously, it's not an obvious requirement, but it is a ramification
of the rules for passing arrays in Fortran). So that also is not in practice
a problem.
Now what about passing descriptors etc. Well we obviously must have pragma
Interface FORTRAN available in an Ada compiler to interface to Fortran. To
try such an interface if the Ada compiler does not intend to allow it is
of course hazardous at best, and unlikely to work. If pragma Interface
FORTRAN is available, then of course any reasonable implementation of it
will pass arrays in the Fortran manner (typically passing the address of
the first element, or perhaps the virtual array origin if this is how the
fortran compiler works).
On the other hand you would neither expect nor want it to make a copy of
the array into column-major form, so you would normally expect, in an Ada 83
context, to have to flip the subscripts on the Ada side, which is an annoyance
but not a disaster (I certainly think it's a reasonable frill to add the
relevant pragma in Ada 9X).
The point here is that the mapping of arrays is not the fundamental issue
in a Fortran binding. If Mike is working with a compiler that tries to
pass array descriptors to a subprogram to which pragma Interface FORTRAN
is applied, then that compiler is broken. If he is working with a compiler
that has no pragma Interface FORTRAN at all, then clearly that is not the
tool to interface Ada and Fortran!
P.S. I keep forgetting, but the name FORTRAN has been officially changed to
Fortran now, very confusing!
^ permalink raw reply [relevance 11%]
* Re: Are 'best' universities being targeted
@ 1993-08-10 14:02 17% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-08-10 14:02 UTC (permalink / raw)
function End_Of_Thread return Boolean is
begin
return Feldman.Opinion = Dewar.Opinion;
end End_Of_Thread;
-- :-)
^ permalink raw reply [relevance 17%]
* Re: Ada and C++: A request for comparison/contrast/relative benifits
@ 1993-08-11 4:49 14% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-08-11 4:49 UTC (permalink / raw)
Of course. Had to be Ted Holden! Quite revealing his choice of selections
from the revision requests (so quaintly retitled as complaints) don't you
think. I particularly enjoyed the idea that the failure of the grammar in
the description to be LR(m,n) constitutes a serious defect.
Thanks Ted for a good laugh and an interesting insight into your technical
tastes!
P.S. the 780-odd RR's do make interesting reading. There is a lot of
incredible junk, I won't quote some of my favorites for fear of
embarassing those who submitted them, but there is also a lot of good
stuff -- good suggestions and good examples. This input proved extremely
useful in the design of 9X, and is well worth going back to to understand
the 9X process.
P.P.S. I guess Ted must have got up one day and been hit on the head by
a mandate carelessly dropped out of someone's high level office. One can
only sympathize ...
^ permalink raw reply [relevance 14%]
* Re: POSIX P1003.5
@ 1993-08-11 11:35 17% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-08-11 11:35 UTC (permalink / raw)
Regarding this issue, is the IEEE spec copyrighted, I mean the actual Ada
code in the spec. If so, then what is the implication of this copyright.
Can people freely copy just the Ada code? Can they modify it?
The whole business of copyrighting specs (just one small step removed from
copyrighting the look and feel of interfaces) is worrisome.
^ permalink raw reply [relevance 17%]
* Re: Ada compiler for Windows NT
@ 1993-08-11 11:49 11% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-08-11 11:49 UTC (permalink / raw)
Alsys has certainly announced its intentions in this area (I hope I am not
giving away company secrets by saying that the intentions are backed up by
some very nice technical work, but I don't know the release status, contact
Alsys directly). Meridian was demonstrating an NT compiler at the last
Tri-Ada a year ago.
One thing to understand here is that there are many ways of writing a piece
of software that is nominally NT, ranging all the way from a thin warming
over of a Windows app to a full reimplemtation that takes advantage of NT.
The other thing to realize is that NT is realy a collection of operating
subsystems with a common Kernel. Usually people are talking about Win32 whn
they ask this kind of question, but you need to be sure the guy who is
answering your question is on the same wavelength.
Finally, people have asked, and will no doubt ask more energetically now,
whether there is an NT version of GNAT. The answer is that we have waited
till NT is available to even think about this, but now that I can get NT
in my local Software Etc (a bunch of $295 boxes were up on the wall), I
guess that time has come! In fact we definitely expect an NT port of GNAT,
since NT is perfectly capable of supporting GNAT. We will still concentrate
on the OS/2 version for now, since our main priority is on impleementing
additional functionality on our current ports (OS/2 and Sparc) rather than
doing new ports of what we have. Eventually of course we expect to have
lots of ports (our experience so far is that in fact it has been easy to
port what we have if you know enough about GCC to do cross-compilations,
we have in house ports to Alpha, RS-6000, HP, MIPS etc).
By the way, one of the reasons that we think the OS/2 version more significant
is that, especially with glue factory disasters, we think it likely that there
will be more PC's around with th 6 megs (8 megs really) that OS/2 requires
rather than the 16 megs (20 megs really) that NT requires!
^ permalink raw reply [relevance 11%]
* Re: Ada and C++: A request for comparison/contrast/relative benefits
@ 1993-08-11 16:55 17% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-08-11 16:55 UTC (permalink / raw)
h yes, and this thorough testing of the phone system by the public includes
we, the public, being kind enough to find the bug that brought down the AT&T
long lines for a period of time which was probably sufficient to exhaust their
quota for downtime for the next hundred years.
^ permalink raw reply [relevance 17%]
* Re: WilTel chooses Objective C - another loss for Ada
@ 1993-08-11 16:58 17% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-08-11 16:58 UTC (permalink / raw)
I wonder if perhaps GA could devise a macro system with abbreviations for
many of the points which he keeps recycling endlessly, perhaps $# could mean
"repeated incompetence of the DoD", etc. This would save a LOT of disk space,
and be a big help to those of us who cannot quite bring ourselves to put srctra
n
in our kill files (though we probably ought to).
^ permalink raw reply [relevance 17%]
* Re: Language runtime requirements (was Re: DoD asks Microsoft ...)
@ 1993-08-12 11:53 11% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-08-12 11:53 UTC (permalink / raw)
The issue of Ada wanting to be the main program is, I think, basically a
matter of implementation, rather than language. The difficulty in getting
a multi-language environment to work nicely is that it is hard to do if
you do not have control over the full range of implementation of all the
languages. After all, even typical C compilers tend to have some notions of
initializing their runtimes (malloc etc.)
In the context of GCC, where the C, Ada, Fortran, C++, Modula-3 etc compilers
are all part of the same implementation environment, the multi-language
problems are much easier to address. Even the current embryonic version of
GNAT has a C main program (the GCC driver) rather than an Ada main program,
and is built from an smoothly bound amalgam of C and Ada (Ada for the GNAT
front end, C for the existing GCC backend).
Our eventual plans are to have the smooth integration between languages
work fine throughout the runtime environment. For example, there will be
no problem in a C++ procedure handling an exception raised in Ada, or
if Ada sets up an ATC (Asynchronous Transfer of Control), then if the ATC
event is triggered, any destructors in active C++ (i.e. g++) procedures
will be executed as part of the cleanup actions.
Of course such integration is not easy, and in particular, the generalized
exception/finalization model is quite ambitious, but we don't see any
fundamental problems in achieving full language integration for both the
compiler and debugger. Of course this depends on being able to modify the
other-language compilers (e.g. for this to work, G++ will have to use the
same exception management approach as Ada). If we just had to fit into
whatever had already been decided for these languages, as is typically the
case for an Ada vendor who must try to interface to existing C and C++
compilers, then it's a much harder problem, and one cannot hope to achieve
the same level of integration.
For another example of effective inter-language integration, have a look
at Dec Ada. Here again, the suite of languages has been designed around a
common environment (e.g. the VMS system exception manager).
^ permalink raw reply [relevance 11%]
* Re: Unconstrained arrays
@ 1993-08-12 15:00 10% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-08-12 15:00 UTC (permalink / raw)
Wayne did not put it quite right. It is not that the compiler "cannot figure
it out", since of course in many cases (and in this case in particular) it
certainly could figure out what you meant IF it was legal Ada, but it is not
legal Ada. As is clear in the RM, Ada deliberately outlaws these one element
aggregates, partly because they seem confusing at a programmer level, and
partly because there are (more obscure) situations in which allowing the
resulting additional overloading cases would be tricky. Consider for example:
"abc" & ('d')
Is the right operand a one element string, resulting in the use of the
string&string concatenation, or is it a character with redundant parentheses
resulting in the use of the string&character concatenation.
Of course the result would be the same, but you can't have this kind of
semantic ambiguity hanging around (suppose both versions of concatenation
had been redefined to do something completely different from the standard
version, and different from one another).
So often in language design you run across a simple case which you think
should be easy to handle, but then more complex cases come and bite you.
You can take the approach of distinguishing between the cases but this
definitely adds complexity (have a look for example at Algol-68, which
resolved such ambiguities by distinguishing the "strength" of a position,
[roughly the extent to which the required type is known a priori]. There
were several different strengths (including weak, firm and strong), and
the rules of what expressions were valid depended on the strength.
In particular, the rowing coercion in Algol-68, which converts a single
element to a one dimensional array with one element (just what we are talking
about here), applies in a strong position (the original example given would
correspond to a strong position, where you know what type you wanted), but
not in a firm position (the operands of a binary operator are firm positions).
Very nice, problem solved! But many folks found these coercion rules in
Algol-68 tricky, so in practice the Ada approach: "since we can't have it
everywhere, let's not allow it anywhere" seems the right one in this particular
case, although you can't generalize this phiolosophy always, sometimes you
prefer a special exception (e.g. the one in Ada that allows you to omit
the type of array bounds if it is INTEGER, on the other hand, I know people
who DON'T like that particular special case).
"A designer's lot is not a happy one"
(adapted from W.S. Gilbert: Norman, care to fill in the rest of the
(adapted from W.S. Gilbert: Norman, care to fill in the rest of the
words for this :-)
^ permalink raw reply [relevance 10%]
* Re: Unconstrained arrays
@ 1993-08-12 21:23 12% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-08-12 21:23 UTC (permalink / raw)
Jim Crigler suggests:
Viewers : str_array (1 .. 1) := str_array'(Creat("text_artist"));
No, no, no! The qualification is useful only to determine the type wanted,but
we know what type we want (str_array!) The trouble is that the expression
(Creat("Text_artists")) just isn't of that type, as I hope the previous
answers have made clear.
I would strongly suggest that people make a habit of testing out replies
to queries of this kind by doing trial compilations with a reasonable Ada
compiler. I certainly do (and I am supposed to know Ada!) I think this would
result in fewer correcter responses to technical queries.
In this case, I ran it on an Alsys version 5 compiler and got:
. 8 Viewers2 : src_array (1 .. 1) := src_array'(Create("text_artist"));
. <--------1--------->
.1 **IDE There is a type inconsistency in this expression.
.
.
.
. =================================================== More Information =
=
. -> The context requires the following type(s):
. - MAIN.SRC_ARRAY at line 3, an array type of STANDARD.INTEGER
. -> But the expression has the following type(s) :
. - STANDARD.INTEGER
. ======================================================================
=
A rather lengthy, but absolutely accurate, error message!
I also ran it under GNAT, and got:
8. Viewers2 : src_array (1 .. 1) := src_array'(Create("text_artist"));
|
|
error: expect type "src_array" in this context
which isn't quite so verbose as the Alsys message, but is also accurate.
Actually we generally operate in brief, Unix-compatible error message mode,
which gives:
"t.ada", line 8: error: expect type "src_array" in this context
We usually find that the error flags aren't needed, and in any case we have
added a column positioning feature to EMACS so that the error message handling
in EMACS will position the cursor to the point of the error flag.
^ permalink raw reply [relevance 12%]
* Re: GNAT for PC
@ 1993-09-02 2:26 15% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-09-02 2:26 UTC (permalink / raw)
The primary targets for GNAT are Sparc (SunOS) and PC (OS/2). Versions of
GNAT for these two targets are available by anonymous FTP now.
We expect to make available ports for PC (NT), Alpha, MIPS, HP700 in the
relatively near future.
A port to PC (Linux) has also been completed (not by us, but its around)
There are no plans (no do we consider it practical) to consider porting
GNAT to DOS or Windows. In any case GNAT requires a substantial PC (8 megs
is a realistic minimum), and on such a machine it makes little sense to
run DOS or Windows in any case in a development environment.
The usual disclaimer, that this is a very preliminary prerelease, whose
successful installation requires knowledge of and familiarity with GCC
applies!
^ permalink raw reply [relevance 15%]
* Re: Hoare's gripes about Ada (should be so what)
@ 1993-09-02 2:38 14% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-09-02 2:38 UTC (permalink / raw)
Boy this is getting off the topic, but it's hard to stand by quietly and
see blatantly incorrect technical comments.
"Sorting has been proved to take O(n log n) time"
is plain wrong. This bound applies only if the sorting is restricted to
comparisons. If arithmetic operations are required, this bound obviously
does not apply. Consider a trivial case of sorting a huge pile of numbers
in the range 1 .. 100.
This has an obvious O(N) implementation (just keep an array of 100 entries
which count the number of occurrences of each possible entry). By using
linked lists, other associated data can be carried along, still in O(N)
time.
Address distribution sorting has an expected average performance much
better than O (N long N), in fact it approaches linear performance
asymptotically in the average case if your distribution function is
well behaved. A lot of large scale sorting (the kind done on giant mainframes
with zillions of records) uses address calculation sorting.
Finally, note that in this day of parallel machines, even if you are
restricted to comparisons, you can do much better than O (N log n).
^ permalink raw reply [relevance 14%]
* Re: Hoare's gripes about Ada (should be so what)
@ 1993-09-02 2:40 17% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-09-02 2:40 UTC (permalink / raw)
How about a small sort contest. Suppose you want to write an Ada sort with
the spec:
type x is array (integer range <>) of integer;
procedure sort (data : in out x); -- sorts into ascending order
What's the least number of Ada tokens (counting from the IS to the semicolon
following the END) that implements this spec?
^ permalink raw reply [relevance 17%]
* Re: Hoare's gripes about Ada (was Re: Ada and C++ ...)
@ 1993-09-02 2:52 14% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-09-02 2:52 UTC (permalink / raw)
Reading N.B. Hedd's diatribe against Hoare (I saved a copy and will send it
to Tony, I am sure he will be greatly amused) reminds me of a wonderful line
in the movie "The Abyss" [at least this line is in the director's cut, it
might have got removed in the horrible cut down theatrical release]. When
the first person reports sightings of the aliens, no one believes her,
except a rather nutty conspiracy theory buff, who starts spouting really
far out explanations for what she has seen.
She says to him "Get off my side!"
I think many of us who support Ada could sympathize with that sentiment
in this case!
By the way, one of Tony's many important contributions is CSP, and it is
interesting to note that the rendezvous model in Ada is based on CSP. It
is essentially a generalization of CSP. A commercial language which used
CSP in purer form of course is Occam, the base programming language for
the Transputer, which was designed by Tony Hoare.
So, Mr Hedd, *please* get off our side! Thankyou.
^ permalink raw reply [relevance 14%]
* Re: Unchecked_Conversion question
@ 1993-09-02 3:00 14% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-09-02 3:00 UTC (permalink / raw)
You cannot rely on unchecked conversion not raising a constraint error
if the value is out of range. In fact you cannot rely on the compiler
not generating code to erase your system disk if the value is out of
range, since the program execution is erroneous at that point!
It is in fact possible to construct an example where it is not beyond the
bounds of belief that an optimizing compiler WOULD do something drastic
like wipeout your system disk if your program was erroneous in this way.
9X tries where possible to limit the effects of erroneousness of this type,
but in Ada 83, there are no such limitations.
That being said, I think that in practice you will find this code to be
fairly portable. Just isolate this use of unchecked conversion with
clear comments as to what you are expecting from the compiler. One should
never be to worried by writing code at this level when that is what is
needed!
^ permalink raw reply [relevance 14%]
* Re: Computational scientists ignoring and ignored by Ada
@ 1993-09-03 0:52 16% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-09-03 0:52 UTC (permalink / raw)
"It will shame vendors into action '''
What a wierd academic view of the world. Mike, companies do things because
they make profits doing things. If you want a vendor to do X, show that
vendor that doing X will earn at least enough in revenue to cover the
cost of doing X, and hopefully more. The idea of "shaming" a company to
take a decision not in its financial interest is silly!
^ permalink raw reply [relevance 16%]
* Re: Johnny AdaSeed (aka Greg Aharonian)
@ 1993-09-03 18:44 16% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-09-03 18:44 UTC (permalink / raw)
I certainly think it can only help to drop CD Roms around the place. However,
I think people are fooling themselves if they think that small steps like this
can make a significant difference. Mostly I think they just make people feel'go
od that *something* is being done
(sort of like security at US airports).
That doesn't mean I discourage people doing these kind of things, it's just
that I hope that it does not substitute for effective action and policy.
^ permalink raw reply [relevance 16%]
* Re: TRI-Ada '94 Topics
@ 1993-09-03 18:51 15% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-09-03 18:51 UTC (permalink / raw)
Mike Feldman says yes! yes! yes! to the suggestion of Tucker talking about
Intermetrics marketing efforts for C.
I guess this is another instance of desparately wanting there to be a simple
formula hiding around the corner, and if only we knew the secret formula (i.e.
the one that Tuck will reveal in this amazing keynote address), then all will
be well, since we can just adopt that marketing approach and Ada will seel
like hotcakes.
All this reminds me why I mistrust companies whose marketing strategies are'
run by technical people!
Of course it's too bad that Mike isn't right in his fantasy, it would be
so nice!
(Gee, I guess the only reason IBM failed with PL/1 was that they didn't ask
Intermetrics how to market it :-)
^ permalink raw reply [relevance 15%]
* Re: TRI-Ada '94 Topics
@ 1993-09-03 18:53 17% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-09-03 18:53 UTC (permalink / raw)
The suggestion of a talk from an organization using Ada in a non-mandated
setting seems a good one to me. An obvious candidate is Silicon Graphics.
Not only are they using Ada for all their virtual reality stuff, but also
they strongly claim that they could not have succeeded in this task using
C++ and it would be interesting to here why.
^ permalink raw reply [relevance 17%]
* Re: Unchecked_Conversion question
@ 1993-09-04 0:13 13% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-09-04 0:13 UTC (permalink / raw)
Wes makes an incorrect assumption that a compiler is not free to assume
that the output of unchecked conversion is valid. Since a program execution
is erroneous if the value is not valid, the compiler is free to do anything
it wants in this case, and in particular it can skip the check which seems
to be otherwise required.
It is this same freedom which allows A:= B to skip a check if A and B
are the same subtype. The check is required by the RM even in the case
of the values being the same subtype (that's because the value of B is
just a value of the base type, and assignment to A always requires a
check that the value of the base type meets its constraints).
The only case however if the subtypes are the same, where the check could
really be needed is if B is uninitialized, but then the program is erroneous
anyway, so the compiler can omit the check (and most all compilers do in this
case, maybe all).
Ada 9X cleans up a lot of these issues with its introduction of the notion of
a bounded error. This is an error which is not necesssarily detected, but
unlike the erronoues case, there are a limited set of consequences.
^ permalink raw reply [relevance 13%]
* Re: Generic Pointer Type
@ 1993-09-04 0:17 16% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-09-04 0:17 UTC (permalink / raw)
Well of course you can't declare a "pointer to void" or anything like that
in Ada, since this the epitome of unsafe programming (a pointer that you
want to keep secret, i.e. you refuse to tell me what it points to, and
intend to make it point to anything you like later on).
To the limited extent that such a notion is required, explicit
unchecked conversions must be used.
What's the exact problem, it is probably instructive to look at it to see
why a C programmer would want a void pointer, and how an Ada programmer
would avoid it, or never even think of it in the first place!
^ permalink raw reply [relevance 16%]
* Re: ARPA,Air Force,Navy publicly brag about a great C++ code
@ 1993-09-04 0:45 17% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-09-04 0:45 UTC (permalink / raw)
At last, Ted Holden said something I agree with. He said he would have a
hard time convincing X of Y, for some X, Y, hardly important what. Since
this is just a special case of the obvious universal truth that Ted Holden
would have a hard time convincing anyone of anything, his claim must be
trivially true :-)
^ permalink raw reply [relevance 17%]
* Re: ARPA,Air Force,Navy publicly brag about a great C++ code
@ 1993-09-07 3:16 17% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-09-07 3:16 UTC (permalink / raw)
It's an interesting comment on the state of software engineering and softwar4e
production that Harry categorizes "maintainable applications" as a niche
area!
^ permalink raw reply [relevance 17%]
* Re: One DoD programmer's hostility towards Ada and the Mandate
@ 1993-09-07 3:18 17% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-09-07 3:18 UTC (permalink / raw)
There was not, and has never been, a "mandate" for the US to convert to
metric measures. The issue has often been discussed, but as a result of
popular opposition (and blatant ignorance on the part of our politicians,
the transcripts of the hearings make amusing reading), no legislation
was ever passed that I am aware of.
Anyone know enough to contradict this?
^ permalink raw reply [relevance 17%]
* Re: Bug in AdaEd???
@ 1993-09-07 3:20 17% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-09-07 3:20 UTC (permalink / raw)
This probably is a bug in Ada Ed. However, it is interesting to note that
there is NO requirement for this program to raise CE. Why not? Well 11.6
optimizations allow the removal of the dead assignments so the offending
expression need never be evaluated.
Most programs that try to raise CE deliberately like this are wrong!
^ permalink raw reply [relevance 17%]
* Re: obj'size for constants
@ 1993-09-07 21:22 17% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-09-07 21:22 UTC (permalink / raw)
Tell the pesky user to buzz off. It is clear that returning 0 is OK,
raising Program_Error might be even kinder, since the user is doing
something that makes no sense whatsoever.
Note that in 9X, you could specify that the constant is aliased, in
which case, it is in memory and has an address.
^ permalink raw reply [relevance 17%]
* Re: TRI-Ada '94 Topics
@ 1993-09-09 19:22 17% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-09-09 19:22 UTC (permalink / raw)
Now there's some really impressive technology (Sonic the Hedghog)
^ permalink raw reply [relevance 17%]
* Re: Hoare's gripes about Ada (should be so what)
@ 1993-09-09 21:07 15% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-09-09 21:07 UTC (permalink / raw)
Mr. Bruck, I am afraid that perhaps you have not quite got the spirit of
Ada yet. Whereas in some other languages, particularly those with a one
letter name, there may be a tradition that brevity is more important than
correctness, I have to report to you that in the Ada world, we are quite
interested in correct reliable programs. I realize that this consigns Ada
to a small niche, the niche of reliable software, but that's the way it is!
Consequently, I am afraid that the judges will have to reject your
submission in the "shortest search contest".
Better luck next time
:-) :-) :-) :-) :-) :-)
(big row of smiley's just in case someone takes this seriously! :-)
^ permalink raw reply [relevance 15%]
* GNAT is alive
@ 1993-09-09 21:10 16% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-09-09 21:10 UTC (permalink / raw)
We just found out that all the posts we have sent to comp.lang.ada have not
been making it out of the building (we saw them here at NYU, but no one
else did). This accounts for what must have been a mysterious silence from
us in this newsgroup (we have always posted immediate responses to any
messages wondering about GNAT).
We apologize for this SNAFU (the acronym unfortunately is quite appropriate
for the state of our network and newsgroup access). We will shortly post
messages giving updated status information on GNAT etc.
^ permalink raw reply [relevance 16%]
* Re: Pascal or C as a first lang
@ 1993-09-12 12:05 11% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1993-09-12 12:05 UTC (permalink / raw)
Edward Hartnett's comments regarding teaching C -- his point is basicaly
that since C is widespread, that must be the appropriate first language
is a nice example of the most disastrous kind of thinking when it comes
to figuring out what to teach at this or any other level.
Despite our frequent language wars on this newsgroup, we should never forget
that language is very much a secondary issue. I would far rather see C
written by someone competent than Ada written by someone incompetent. Now
what is the competency about here? Certainly not about any particular
language.
So how do we teach this competency? This is a fundamental question, and we
spend a lot of time arguing about the right answer, but we know for sure
that the wrong answer is to focus on a particular language and concentrate
on teaching coding skills in that particular language.
Language is nothing more than a vehicle for teaching at this level. The only
conceivable argument for Ada or C or any other language is that it helps in
the fundamental goal of learning what programming, software engineering if
you like [I see little value in considering these terms as significantly
distinct], is all about.
In practice, the worst thing about C is the trial-and-error hacking culture
that comes with it. It is hard (but not impossible) to teabeginning level witho
ut getting sucked into the
trap of this culture..
The best thing about Ada is the culture that comes with it, which tends to
be at the opposite extreme from this trial-and-error approach.
Now language does not dictate the associated culture, but it is also false
to assume that it has nothing to do with it. In practice the structure
and design of the Ada language are better oriented to teaching abstraction.
For example, it's hard but not impossible, to teach about data abstraction
and data hiding in C. Ada on the other hand
makes such teaching much more natural.
^ permalink raw reply [relevance 11%]
* Re: DOS ALSYS ADA and DOS=HIGH
@ 1994-09-08 13:45 42% Rick Ballard
0 siblings, 0 replies; 200+ results
From: Rick Ballard @ 1994-09-08 13:45 UTC (permalink / raw)
To: dewar
On 2 Sep 1994 11:17:42 -0400,
Robert Dewar <dewar@cs.nyu.edu> wrote:
>I would be interested in knowing if you had originally contacted Alsys
>support on this question. It is the sort of thing that I would expect
>them to be able to provide quick help with no hassle.
>
My 6 volumes of documentation do not include the 1-800 support number. I
finally got an email reply providing an email address for an apparent
support person at ALSYS, who was very helpful. I now have the 1-800 number,
but have not yet had occasion to try it.
So, I actually did not contact ALSYS first. I assumed they read CLA, since
I saw a note from thier legal department on the newsgroup earlier.
--
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
| Rick Ballard | Email: ballard@atl.sofkin.ca|
| Software Kinetics Ltd. | Voice: 902-427-7196 (CFFS) |
| 201 Brownlow Ave | |
| Nova Scotia, Canada B3B 1W2 | |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
^ permalink raw reply [relevance 42%]
* Re: Multiple compilation-units (was: Re: GWU/ADA Interface)
@ 1994-09-09 1:46 22% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-09 1:46 UTC (permalink / raw)
John, you have a misconception, the time of compilation plays no role whatsoever
in the GNAT system. The time stamps are the time stamps of the sources.
^ permalink raw reply [relevance 22%]
* Re: Ada 9X features
@ 1994-09-09 13:22 15% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-09 13:22 UTC (permalink / raw)
In regard to Ken Garlington's post regarding access types, it is interesting
to note historically that this particular use of access-to-object was *the*
most convincing argument that this feature should be added to Ada 9X. It
is indeed the case that there was no good way of solving the problem in
Ada 83. The nervousness about the feature is that it opens the way to
undiscimplined aliasing, and any usage guide for 9X should discuss the
issues of minimizing the use of the aliased keyword.
Regarding Bevin's general view of 9X. One of the dynamics of the devlopment
of 9X has been a large scale discussion (that's American for argument) about
the scale of the change. If you look back to say mapping document 2.0, you
can see that the design team originally wanted a much more extensive change,
and on the other hand the "Swedish letter" [sorry I forget the author, it's
always referred to by that code name :-) recommended doing almost nothing to
Ada 83. Various people lay somewhere between these extremes. Jean Ichbiah
for example would have liked to see some OO stuff, character stuff fixed up
and pretty much nothing else. Bevin was certainly on the conservative end
of this debate (worrying, quite legitimately, about the difficulty of getting
implementations starting with existing Ada 83 bases).
Speaking personally, I also felt that the original proposals were far too
extensive, and indeed argued, oops excuse me, discussed, pretty fiercely
the need to cut things back. The result is a compromise which has left
most people but certainly not everyone, satisfied that we have found the
right level. The fact that it is likely that there will be unanimous
approval of the standard at the ISO level tends to confirm this judgment.
I certainly feel that from a language point of view, we are at about the
right level, although with my implementors hat on, I sure have to agree that
implementing Ada 9X is not easy [although, interestingly, in the GNAT project,
we find the most difficult parts of Ada 9X are elements of Ada 83 that are
pretty much unchanged (e.g. %$#@# private types, discriminants, aggregates
and generics).
Interesting note: the word compromise, used as a noun rather than a verb, has
pretty much positive connotations in British English, and if a meeting reaches
a compromise that people can agree on, people feel they have accomplished
what they set out to do. In American English, the noun compromise is more
closely related to the verb compromise, and tends to have negative
connotations. When I use compromise in the previous paragraph, I am definitely
using it in the positive sense.
Robert
(now back to another attack on those private types and aggregates :-)
^ permalink raw reply [relevance 15%]
* Re: Government Policy on Ada Acquisitions
@ 1994-09-09 23:43 17% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-09 23:43 UTC (permalink / raw)
It is true that GNAT is not finished, but it is using the GCC backend which is
(a) quite mature at this point and
(b) highly optimizing
If you write a chunk of Ada code that is essentially equivalent to some C code,
and of course you turn on the optimizer (-O2), you get code that is equivalent
to what you would get from C, which means in practice very good, comparable to
the best C compilers around. Someone at the London SigAda remarked to me that
he was amazed at the Whetstone performance of GNAT, "it was essentially the
same as C". I would have been amazed if this were NOT the case.
Now Ada 9X specific stuff, such as aggregates, pointers to unconstrained arrays,etc. is still quite unoptimizied. The performance of GNAT is by no means terrible
for such things, but it can be greatly improved. Right now, that kind of
optimization is of course low priority for us.
Similarly, the library packages can stand a lot of improvement. Until the most
recent release, Text_IO was checking (with a system call) for the console case
on every character. That was really a bug, but not one that showed up as a
functionality problem in our tests. That bug iis now fixed, but there may
well be other similar performance problems.
In any case, running GCC unoptimized and reporting its performance is quite
ludicrous and gives no useful hints at all about the real performance of
GNAT code. The compiler itself is always generated using -O2. It would not
occur to us to leave optimization off. Similarly all our test programs are
typically run using -O2. Indeed it is often the case that the compiler is
more reliable with optimization turned on, simply because that's the way
people run it for any real code.
^ permalink raw reply [relevance 17%]
* Re: Multiple compilation-units (was: Re: GWU/ADA Interface)
@ 1994-09-10 15:22 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-10 15:22 UTC (permalink / raw)
Jonothan mentions that he has built a utility which uses the unit listing
from GNAT to generate dependencies. Much better is using the ALI files.
The D lines in the ALI files are EXACTLY the list of source file
dependencies. That's how we generate dependencies.
Much better than either approach is an Ada make utility that calculates
the dependencies dynamically as it goes along. We are working on such a
utility and hope to have it available soon.
Jonathan, I think you would find it *much* easier to parse the ALI files!
Robert
^ permalink raw reply [relevance 21%]
* Re: Creating markets (long)
@ 1994-09-10 23:19 19% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-10 23:19 UTC (permalink / raw)
A particular instance of market creation that is relevant these days is
Ada 9X. Early on I know of a couple of vendors who asked their users
whether they were planning on using Ada 9X. Since most of them hadn't
heard about Ada 9X, they were NOT planning on using it. It is all to
easy to conclude from such data "none of our users are interested in
Ada 9X".
Clearly this can be self-fullfilling, if you decide as a consequence not
to emphasize Ada 9X, then naturally, your Ada customers will continue
"not to be interested" in something they don't know about.
If we are going to get people to use Ada 9X, even among existing Ada users,
we indeed need to try to create a new market.
Note that's it's not necessarily easy. IBM put a huge amount of resources into
trying to promose PL/1 as a successor to COBOL, and clearly failed, although I
think some of this can be ascribed to lousy early implementations (the Sears
reversal was a watershed in this process).
^ permalink raw reply [relevance 19%]
* Re: TRI-Ada '94 advance program
@ 1994-09-11 1:49 22% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-11 1:49 UTC (permalink / raw)
I am surprised that the titles are taken from the preliminary submissions
and not the final papers. No big deal, but you have had the final papers
in hand for quite some time now!
^ permalink raw reply [relevance 22%]
* Re: TRI-Ada '94 advance program
@ 1994-09-11 1:50 22% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-11 1:50 UTC (permalink / raw)
Oops, very sorry for broadcasting by mistake, it's a mistake I seldom make
and I realized as soon as my finger left the keyboard, but too late!
^ permalink raw reply [relevance 22%]
* Re: Ada ad in Embedded Systems Programming stinks
@ 1994-09-11 12:20 15% ` Robert Dewar
1994-09-11 13:29 19% ` Robert Dewar
0 siblings, 2 replies; 200+ results
From: Robert Dewar @ 1994-09-11 12:20 UTC (permalink / raw)
Mike says:
"Ada compilers include LRM references so the programmer can figure out the
error"
This of course is an attribute of an implementation not a language (C
compilers and Lint could equally well include references to the ANSI
standard).
There are however real language differences that show up, e.g. when in C
you casually write an unchecked conversion from pointer to integer, or
you casually assume that pointers and integers occupy the same amount of
space, or, or, or ... these are not errors in the sense of being static
violations of some rule that Lint can easily catch.
That being said, the fact that in Ada, the compiler is required to catch
things means that it certainly will. A given implementation of Lint may
or may not catch all the possible static errors (which were not designed
into C in a manner guaranteeing that they could be detected). It's really
that fundamental philosophical difference that is important. Standards like
the COBOL, Fortran and C standards are basically only positive standards,
they tell you what a legal program *is*, and what a conforming implementation
must do with a legal program. The Ada standard is equally concerned with
the class of illegal programs, and worries about what a conforming
implementation must do with an illegal program.
This isn't just theory, IBM has at least in one incident I know of, officially
refused to accept as a valid bug report from an important COBOL user, a
complaint that the compiler did not diagnose an error.
Speaking of LRM references, especially with Ada 9X, where parts of the RM
are very technical and do not even pretend to be simple easy to read English,
I am not at all sure that routinely sending people off to look at the RM is
a favor.
In GNAT we really concentrate on giving an error message that is clear enough
at a simple informal level to avoid the need to rummage in the LRM. Our
eventual plans are to have an auxiliary utility which will further explain
an error message, using additional text as well as references to the RM,
AARM, Rationale or whatever.
We haven't started work on that utility, but we have a good name for it
GNOME (GNAT Online Message Explanation).
That seems the best compromise. After all, remember that the user who is
most likely to need further help is also the user least likely to be able
to read the RM. If you really know the RM well, you shouldn't be making
errors in the first place, and you certainly should be able to figure
them out :-)
^ permalink raw reply [relevance 15%]
* Re: Ada ad in Embedded Systems Programming stinks
1994-09-11 12:20 15% ` Robert Dewar
@ 1994-09-11 13:29 19% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-11 13:29 UTC (permalink / raw)
ABOUT SUBJECT LINES
You will notice that a long thread now, mostly discussing the issues of
error detection in Ada and C, has had the above inflammatory subject,
inherited from the original GA post. Now of course, many of us posting
in this thread don't agree at all with the premise of the subject (I
certainly don't), but I hesitate to change the subject since this will
make it harder for some folks to follow the thread in thread reading
news readers.
It's an old trick in the newsgroup world to editorialize like this in
subject lines, but it's really rather poor netiquette. It's better to
post a neutral subject line (e.g. in this case leave of the stinks), and
keep the flaming to the body of the text. That way we don't get misleading
subject lines as the thread extends.
Greg, we know from the author the tone of the message in advance anyway, so
could you please try to use more neutral subjects. I think it will help the
tone of discourse. Certainly it would be nice if others will follow this
simple rule!
^ permalink raw reply [relevance 19%]
* Re: Ada ad in Embedded Systems Programming stinks
@ 1994-09-11 23:47 16% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-11 23:47 UTC (permalink / raw)
But Erik, surely you can't think the RM is the right place to learn Ada
style. Indeed much of the RM, of necessity, discusses marginal cases and
rules that are there for semantic consistency, but are hardly valuable
tools in the Ada programmer's arsenal.
In the past, I have been a big supporter of the idea of all Ada programmers
using the Ada RM as a major reference tool, but the Ada 9X RM, partly as a
result of the increased complexity of the language, particularly in its
type model, and partly because of the greater emphasis on a somewhat more
formal style (in an attempt to be more precise), is considerably more
difficult to understand than the Ada 83 RM.
Erik, I would be interested if your opinions are arrived at with a thorough
familiarity with the 9X RM, or are more just the way you hope things should
be.
Anyway, I continue to think that having optional RM references is what
serves the community of people using GNAT best. 95% of the time, the
RM reference would be completely unnecessary, even for a novice
programmer, and only in a faction of the remaining 5% of cases would
it really be a big help, and that's the case in which you can look it
up.
Note also that the GNOME approach gives much MORE than simply an RM
reference, it gives a more thorough explanation, of which the RM
reference is only one aspect.
THe issue of how accessible defining documents should be is an interesting
one. I am one of the relatively few people who got to know the Algol-68
revised report thoroughly. At that level of knowledge, it is a superb
document, extremely precise, very complete, and very accessible.
However, the great majority of people found it completely inpenetrable,
and it clearly contributed to the demise of the language.
I am afraid that if people's first introduction to using Ada at a simple
level points to the RM, this will NOT be helpful in convincing people
that Ada is simple to learn and easy to use.
Of course experienced programmers will continue to use the RM as a primary
reference source, and that's why it is valuable to get the error references
when you need them.
^ permalink raw reply [relevance 16%]
* Re: Eiffel gripe (was Ada vs. Eiffel)
@ 1994-09-12 13:52 20% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-12 13:52 UTC (permalink / raw)
If we are on the subject of loop syntax, how about the loop kit for SETL
that I (probably in a fit of over-complex thinking) designed:
init <stuff to do before loop.
doing <stuff to do at start of each loop>
step <stuff to do at end of each loop>
while <condition to test at start of loop>
loop
...
end
within the loop there was both a quit and a continue for early exits to
either outside the loop or the next iteration (actually to the step code)
Well you sure could do anything with that. As in C, one of the powerful
uses of general iteration schemes like this is in connection with macros,
which allow you to do lots of nice things, but are so open to major
abuse that in the final analysis I prefer Ada's approach of excluding
macros as a first class capability (SETL *did* have a powerful macro
facility as well).
^ permalink raw reply [relevance 20%]
* Re: GNAT 1.82 for Linux
@ 1994-09-12 13:57 21% ` Robert Dewar
0 siblings, 2 replies; 200+ results
From: Robert Dewar @ 1994-09-12 13:57 UTC (permalink / raw)
Thanks Gene for preparing the 1.82 Linux release (at this stage Linux is
one of the most popular platforms for GNAT use from what we see). Sometime
in the future, we hope to support Linux here at NYU, but meanwhile outside
help such as you have provided is invaluable!
Incidentally, we are hoping to get a 1.83 out in the next couple of days.
There were a number of annoying little regressions that we have fixed both
in the compiler and in the release script (the switch to GCC 2.6.0 was
a bit of an earthquake, and now things should have settled down from that)
^ permalink raw reply [relevance 21%]
* Re: GNAT for rs6k
@ 1994-09-12 13:59 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-12 13:59 UTC (permalink / raw)
1.79 can definitely NOT build 1.82
In general at the moment we only guarantee that you can build N+1 from N,
and even then there can be some difficult cases (in particular building
1.81 from 1.80 is tricky, the readme has full details but they are tricky
to follow -- some have succeeded, but some have had trouble).
There are two reasons for bootstrap path problems of this type. First we
are using more features as we go along and as they are available to us.
Second runtime library incojmpatibilties cause trouble (we are trying to
work out an approach to minimize the second problem)
^ permalink raw reply [relevance 21%]
* Re: KUDOS and hats off to Rational !!!!!!!!
@ 1994-09-13 5:44 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-13 5:44 UTC (permalink / raw)
Dave, are you aware of Chris Anderson's updated picture of Ada (rather
smartly but not *too* modernly dressed).
^ permalink raw reply [relevance 22%]
* Re: CAUTION: Network Police patrolling c.l.a
@ 1994-09-13 15:41 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-13 15:41 UTC (permalink / raw)
John could you elaborate on your highly mysterious message, or was
it just meant to be provocative? :-)
^ permalink raw reply [relevance 22%]
* Re: A proposal for Tri-Ada '94
@ 1994-09-13 17:49 16% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-13 17:49 UTC (permalink / raw)
Greg, why not spend some more of YOUR OWN MONEY, which you seem quite happy
to spend on your quest, whatever it is (assuming that for you like all of
us, time is money), and produce your accurate number. I am sure it will
be treated with the respect it deserves. As for me, I must not be part of
the world, since I find I can proceed without knowing this number :-)
More seriously, I think such a raw overall number would in fact be about
as meaningful as Greg's statistics on theses (one of the few of his numbers
that I am in a position to know its significance, accuracy and value).
What would be much more significant is to know the number of recently started
projects that include coding either in 3GL's, 4GL's or Case Tools that do
not use Ada.
Incidentally, I importantly include Case Tools, since people, especially
at a high management level in industry and in DoD are being seduced by
the story that Case tools eliminate the need for programming completely,
and therefore, since there is no programming, there is no more issue of
what programming language is being used.
(In fact of course, Case Tools are little more than compilers for very high
level languages which work very nicely on appropriate examples, but when
pushed into areas not best suited for them, end up being processors for
highly incompetently designed languages and lots of junk code results. I
found 4GL's a more honest term frankly. Interestingly, as far as I am
concerned, it matters not one whit whether the case tool generates Ada,
C or double dutch, if the generated code is never seen by humans, and
never treated as anything else than an intermediate language by the
compilation system. THe point is that you are programming in input to the
case tool, and that's what should be examined for legitimate consideration
of whether it should be in Ada.)
Thought for the week: how much in taxpayers money is being taken up by
GA's postings (or anyone elses for that matter). You have to consider
disk space on govt funded machines, traffic on govt funded networks,
and time spent by govt funded employees (Let's me off the hook, not one
cent of my time is paid by the government :-)
Robert
^ permalink raw reply [relevance 16%]
* Re: Ada9X Features
@ 1994-09-13 20:04 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-13 20:04 UTC (permalink / raw)
Mike, you are wrong about Fortran and conformant arrays, Fortran does
NOT have this feature, at least not in anything like the form of ISO
Pascal. Arrays in Fortran are passed by address only, and bounds information
is not passed (note I am talking up through 77 here, who knows what they
have wrought in 90 -- well probbaly some reader of this group does :-)
^ permalink raw reply [relevance 22%]
* Re: Air Force shows how meaningless Ada waiver process is
@ 1994-09-13 20:14 18% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-09-13 20:14 UTC (permalink / raw)
Mike, to your claim that Ada companies bet on sales to the DoD under the
Mandate. Poppycock! at least if you are talking about all companies. ALsys
was a French company which always had far more employees in France than
in the US, and concentrated on sales in Europe where there is no mandate.
Alsys has shifted its emphasis somewhat with the Telesoft merger, but I
would still be willing to bet that a big part of its revenue comes from
non-DoD sources (including such US customers as NASA and Boeing commercial).
As for the claim that the mandate is responsible for the perceived poor
quality of Ada tools (a broad brush characterization that is not at all
generally fair -- there are good Ada tools and bad Ada tools around), I
know this is a popular view from the vendor-bashers club of which you
seem to be one of the founding members, but apart from a lot of rhetoric,
I have never seen any convincing argument that this is the case.
In fact, you could well argue that the failure of vendors to generate
sufficient revenue to support continued improvement etc was due to the
mandate not being enforced well enough, although that's also a hard
after-the-fact argument to make convincingly.
There - that should start a nice thread of diatribe. Perhaps I should
have changed the subject line to something more flamboyant :-)
^ permalink raw reply [relevance 18%]
* Re: Portable way to read/write from a binary file?
@ 1994-09-14 3:51 22% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-14 3:51 UTC (permalink / raw)
sequential_io instantiated for a byte or character type may work, but is
not guaranteed, and may well be gruseomely slow.
best get is just to use pragma interface and use the appropriate unix
routines directly, whjy not>
^ permalink raw reply [relevance 22%]
* Re: Vendor bashing? Sort of.
@ 1994-09-15 13:28 14% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-15 13:28 UTC (permalink / raw)
Note also that the complaints about pricing of Ada products have also often
been made with a very narrow viewpoint (i.e. what C costs). In fact decent
COBOL compilers for example, with tools, have always cost about $3000 on
the PC, and still do!
It is true that C brought down the price level for compilers in general (and
in the process made it VERY difficult for anyone to make money making
compilers for anything -- there are a lot of good C compilers scattered
by the roadside!)
I think the main reason that (some) Ada tools were not better was simply
a lack of resources, so when Mike complains that the vendors blew it by
not providing better tools, he has to have an idea of where the resources
would have come from. There are two possibilities:
o Vendors spent money on something else, which they should not have
This is hard to see, Mike if you think this, what do you have in mind.
o If only Ada had been pricede at $100 (or some other low figure), the market
was so elastic (elasticity >> 1.0) that they would have made a ton of money
and been able to fund all sorts of stuff. If you believe that you are in my
opinion a card carrying member of the land of Oz, or some other fantasy world.
In fact there was a relatively huge amount of capital injected into the
Ada market, some of which did indeed generate some very good tools (e.g.
the support of hardware emulators that Alsys provides, or the Rational
APex environment), and my guess is that the *only* reason that this money
was available was the mandate. A possible exception is the support of
French banks for Alsys, which might well have been based on being sold
more generally on the future of Ada [of course the banks lost all their
money, so in retrospect, they certainly made a bad investment decision].
My own view is that the critical thing is for Ada NOT to rely on inventing
its own tools, but instead to concentrate on being able to take advantage
of tools for other languages that already exist. Now with my GNAT hat on,
one of the very important aspects of GNAT is that its compilation model,
an commitment to system standards (calling sequences, debugging information,
object module formats etc) make taking advantage of existing tools a lot
easier, and I would certainly like to see other Ada compilers move in the
same direction (good ideas in GNAT are free for the taking. A number of
vendors are still afraid of even reading GNAT sources because they are
afraid of contaminating themselves by doing so -- that's silly, but there
is only so much effort that I am willing to put in trying to convince other
vendors to take advantage of GNAT in this way :-) Incidentally, this doesn't
apply to all vendors, some of whom are looking VERY closely at GNAT and
definitely copying our ideas, which we find most pleasing. [I know that
sounds strange to people more accustomed to locking up their sources in
a safe with armed guards, but free software is another world!]
^ permalink raw reply [relevance 14%]
* Re: Vendor bashing? Sort of.
@ 1994-09-15 13:30 22% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-09-15 13:30 UTC (permalink / raw)
Mike Ryer points out that the Ada mandate perhaps encouraged too many
basic technologies to be developed, and guesses that with no mandate,
there might have been a smaller more reasonable number. I am afraid
that number might well have been zero (consider as an example Algol-68 or
many other languages designed since then).
^ permalink raw reply [relevance 22%]
* Re: Static in 9X
@ 1994-09-15 13:37 19% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-15 13:37 UTC (permalink / raw)
These seem very straightforward questions, answered in an accessible
way by the rules in the RM (and note I am not one to generally say
that the 9X RM is easy to read).
1,2,3,5 are of course non-static. I have no idea why anyone would think
that the rules in the RM even suggest for a moment that they are static,
so it is hard to quote specific rules. The RM rules basically say what
*is* static, and none of these rules cover any of these cases.
4 is static, because of para 9 ("a type conversion whose subtype mark denotes
a static scalar subtype, and whose operand is a potentially static expression)
I don't see that an Ada vendor is particularly in the business of
interpreting language rules like this, though in practice quite a few
"bugs" submitted are just misunderstandings of the language (we find this
in GNAT bugs for example).
What would be useful is for you to explain why you thought that the
other cases (1 = composite type, 2 = record field, 3 = user defined
function, 5 = unchecked conversion) were possibly covered by any
of the items in paras 3-12. That might give a clue as to something
that is not as clear as it should be in the RM.
^ permalink raw reply [relevance 19%]
* Re: GNAT 1.82 for Linux
@ 1994-09-15 13:39 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-15 13:39 UTC (permalink / raw)
In general we will do our best to echo any versions of GNAT that we know
about. It is a good idea to send messages to gnat-report@cs.nyu.edu,
as well as posting to CLA, if you have a new port that we should put up!
And this is a good opporunity to again thank those who are generating
these additional ports.
^ permalink raw reply [relevance 22%]
* Re: How to check for characters in input stream?
@ 1994-09-15 13:42 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-15 13:42 UTC (permalink / raw)
"is there a way to do this [get a character at a time] in Ada?"
there is in fact an explicit feature in 9X for doing this within text io,
but the best answer for Ada 83 is that of course there is a way, call the
appropriate getchar routine or whatever in C. Remember that pragma Interface
is part of Ada!
^ permalink raw reply [relevance 22%]
* Re: GNAT 1.8? for OS/2 (was Re: GNAT 1.82 for Linux)
@ 1994-09-15 13:44 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-15 13:44 UTC (permalink / raw)
The delay in 1.82 OS/2 version is a hopefully one time glitch related to
the new version of GCC. At this stage we will go straight to a 1.83
release, and hope to have them all out.
P.S. As usual, I remind that questions like this should ALSO be directed
to gnat-report!
^ permalink raw reply [relevance 22%]
* Re: Portable way to read/write from a binary file?
@ 1994-09-15 17:08 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-15 17:08 UTC (permalink / raw)
There is a set of C/Unix/ANSIC routines (some intersection) that is VERY
portable, as portable as anything else. The GNU porting guide (perhaps Richard
can give a better reference) has details on what can typically be counted on.
^ permalink raw reply [relevance 22%]
* Re: DEC Ada for Alpha Computers
@ 1994-09-16 1:06 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-16 1:06 UTC (permalink / raw)
We will be making a binary release of Alpha GNAT (OSF1) available on the
NYU FTP site sometime next week.
^ permalink raw reply [relevance 22%]
* Re: Vendor bashing? Sort of.
@ 1994-09-17 0:11 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-17 0:11 UTC (permalink / raw)
Greg, let me get this right, you wanted to charge for an hour of time to
come in and make a sales pitch? Well that's a novel way of doing business
(well perhaps one should say it would be novel if it worked). Charging
for sales pitches, well, well, that's the second strangest thing I heard
about today (the first is too long a story ...)
^ permalink raw reply [relevance 22%]
* Re: Compilation order?
@ 1994-09-17 0:14 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-17 0:14 UTC (permalink / raw)
Get GNAT! then you won't have to worry about compilation order!
Sorry couldn't resist.
Seriously, note that compilation order is not a trivial thing to figure out
if you include optimizing effectiveness of pragma inline. Certainly
Alsys has a good tool for doing this which does not have the limitations
you mention. It generates a script for their compiler, but you can easily
interprete this script.
^ permalink raw reply [relevance 22%]
* Re: Static in 9X
@ 1994-09-17 3:13 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-17 3:13 UTC (permalink / raw)
"Our vendor decides whether or not to put objects in ROM via the definition of
static (in part). We're trying to get better performance in this area for
composite objects."
Have a little chat with your vendor. We are talking 9X here right? It is
clear that preelaborability should be the issue (see the systems
programming annexe). Whether something is static should have nothing
whatever to do with whether things are static.
^ permalink raw reply [relevance 22%]
* Re: Main (function) program with exit(status)
@ 1994-09-17 3:18 20% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-17 3:18 UTC (permalink / raw)
"Most coding standards, and even the LRM, state that the main program
must be a parameterless procedure. However, it seems that there's
nothing to prevent the main program from being a parameterless function!"
The LRM says nothing of the kind. It says "A subprogram that is a library
unit can be used as a main program ...".
It then goes on to say that an implementation *may* but certainly not
*must* limit main programs, but must in any case allow parameterless
procedures.
Given this, when writing portable code, stick to parameterless procedures.
But there is nothing to stop an implementor allowing functions to return
a status (or whatever), or even to accept arguments (argc, argv???)
GNAT allows either parameterless procedures, or functions returning any
integer type, and interpretes the integer as a return code, as in this
example.
Still, don't use this in portable code!
^ permalink raw reply [relevance 20%]
* Greg and charging for sales pitch, NOT?
@ 1994-09-17 11:55 20% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-17 11:55 UTC (permalink / raw)
The other Keith (Keith Thompson) points out to me that it is quite likely
that what Greg was saying is that the company in question wouldn't pay
*their* employees to listen to him (which I misinterpreted as an issue
of paying Greg). If that's right, which I think it probably is, then
I apologize to Greg, although I must say, with a new hat on acquired
recently, the idea of charging for sales presentations doesn't seem
such a bad idea :-) :-) :-)
Just think, if I were still using DOS, and only could do one thing at a time,
then I wouldn't be able to post to CLA while waiting for GNAT to finish
compiling. Isn't OS/2 wonderful (of course there may be some readers of
this group who think that this particular feature of OS/2 is NOT so
wonderful :-)
^ permalink raw reply [relevance 20%]
* Re: Vendor bashing? Sort of.
@ 1994-09-19 3:52 17% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-19 3:52 UTC (permalink / raw)
"Naturally, we can all speculate forever on this point. But I find it one
of the more bizarre I've seen lately. If, indeed, Ada was a solid and
sound design for its times, why on earth would nobody have been willing
to invest in its development, even if the DoD did not sound like it would
mandate use?"
Yes, well there are two big mistakes that non-business oriented technical
people make. First, they think that being technically best is a guarantee
of success, and second, they think that not being technically best is a
recipe for failure. Mike, there are dozens of companies around that have
been destroyed by technically oriented management that did not understand
how relatively unimportant technical superiority ranks on the scale of
things.
Such matters as perceived and actual levels of support, estimation of
financial soundness of the companies involved, size of the companies
involved, time to market, etc. etc often play a much larger role.
If you think of Modula-2 and Modula-3 as commercial successes which you
are sad that Ada was not able to emulate, then you really have a peculiar
view of the market.
Mike, there is an easy experiment you can perform now. See if you can
get any venture capitalist to put up money to support work on Ada 9X.
All I can say is good luck if you try this! To be fair, you should inform
the venture capitalists that you do not expect the mandate to be maintained,
and they should discount the effect of the mandate in estimating the future
market potential of Ada.
I am certainly not saying that you can succeed with rubbish products, no
matter how good other things look (consider IBM's failures with the
PC Jr and the RT as illustrations of this). Equally, there are cases where
a product really *does* succeed on technical excellence alone, but they
are few and far between.
^ permalink raw reply [relevance 17%]
* Re: Creating markets (long)
@ 1994-09-19 3:57 19% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-19 3:57 UTC (permalink / raw)
How many Ada programmers do you know who use Macs?
Well that's a little misleading. THe very real marketing question you can
ask is how many developers or programmers use Macs in *any* language. THe
answer is very few, and going hand in hand with this is the observable
fact that the market for C compilers on the Mac is very small. It is no
surprise that a small slice of a very small pie is not very tasty.
There is of course some value in the educational environment of Mac based
compilers, but as Mike likes to constantly remind us, educational folks
don't care to spend much money on software. For educational use, for
example, GNAT on the MAC would be very nice, and it would be nice to see
it happen, but I would guess that "real" use of GNAT on the Mac would be
slim compared to other, more programming development oriented, systems.
And Mike, before you try to figure out how a company can make money selling
compilers to students, just remember that Borland is going broke, despite
the fact that it has an essentially massive control of the educational
compiler market.
^ permalink raw reply [relevance 19%]
* Re: Vendor bashing and pushing Ada....and an ad from SGI.
@ 1994-09-20 2:19 22% ` Robert Dewar
[not found] ` <35mpre$1fb2@watnews1.watson.ibm.com>
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-09-20 2:19 UTC (permalink / raw)
Dave, I agree with essentially everything you say.
P.S. those ain't fireworks between Mike and me, them's merely
animated discussions :-)
^ permalink raw reply [relevance 22%]
* Re: Fibonacci Numbers?
@ 1994-09-20 16:25 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-20 16:25 UTC (permalink / raw)
Keith, I can't believe you would make such a mistake, 34 indeed, doesn't
everyone know that THE ANSWER is 42.
By the way, I have a suggestion. When people
ask a truly elementary question, defined as one which
we can pretty much assume that all the readers of the newsgroup know the
answer to, then it's probably better to EMAIL responses, we have now had
half a dozen posts giving the formula for Fibonacci numbers, which is not
very enlightening.
Now if someone knows the question to which 42 is the answer, that would
be really interesting and worth posting, though probably not to this
newsgroup.
^ permalink raw reply [relevance 21%]
* Re: Eiffel for DoD development?
@ 1994-09-20 17:18 22% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-20 17:18 UTC (permalink / raw)
Wayne, your idea that the mandate is restricted to embedded combat systems
is indeed hopelessly out of date, and YES, business systems are also covered
by the mandate (and the usual possible exceptions to the mandate).
And also, it isn't a matter of DoD changing its policy, the mandate is a
matter of law.
^ permalink raw reply [relevance 22%]
* Re: C++ bashing (was Re: Vendor bashing? Sort of.)
@ 1994-09-20 21:51 20% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-09-20 21:51 UTC (permalink / raw)
I would not quite put C-Front in the same category as GNAT. The big difference
is whether you are generating source code as an intermediate step. The
wword preprocessor is normally reserved for translator systems that do
generate intermediate source. In no sense whatever does GNAT generate C,
it links directly to the GCC backend, and by no stretch of the imagination
can GNAT be called a preprocessor (if GNAT is a preprocessor, so are all
the front ends of GCC, including C itself).
Now of course ideally, if the intermediate source code is 100% hidden from
the user, then it is not so important a distinction, however, it can
certainly effect efficiency (there is no efficient way of handling Ada OR
C++ exceptions if you have to generate C source code).
^ permalink raw reply [relevance 20%]
* Re: Vendor bashing and pushing Ada....and an ad from SGI.
[not found] ` <35mpre$1fb2@watnews1.watson.ibm.com>
@ 1994-09-22 13:53 22% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-09-22 13:53 UTC (permalink / raw)
Right, for us fireworks is associated with the bad guys
(do they teach about Guy Fawkes in the US?) :-)
^ permalink raw reply [relevance 22%]
* Re: Transition from 32 to 64 bit
[not found] ` <35n81h$1fb2@watnews1.watson.ibm.com>
@ 1994-09-22 14:06 14% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-22 14:06 UTC (permalink / raw)
I don't often disagree with Norm, but I don't like his use of Float_6
and Float_15. This is reminsent of the PL/1 style in which 32 bit integers
were hard coded into all programs in the name of portability.
If you choose to define your own types, then PLEASE don't just pick up
the hardware parameters of the machine you are on, because that decreases
portability rather than increases it.
If you have done a careful analysis that 6 and 15 digis of precision are
indeed exactly what you need, then fine, but I BET that you have not made
such an analysis.
In fact, better advice would be to name the two types Single and DOuble,
and define them as new Short_Float and new Long_Float respectively. This
will lead to the right choices on pretty much all machines, and you canm
easily change them if you are on a nasty compiler that does not follow
the relevant uniformity recommendation (that short should be single
precision, long, double precision, and Float itself chosen as the more
efficient of these two formats).
The trouble with 6 and 15 is that it causes trouble on some machines.
For example, suppose your compiler provides only 6 and 14. Then you will
have to perform a very careful analysis of whether you can run at all on
that machine, because with Norm's approach you imply that you have carefully
analyzed things and determined that 15 is the minimum precision available.
If that's the case, fine, if not, please don't pretend!
Similarly, suppose your compiler provides 6, 14 and a special very slow
software format with digits 64. Do you really want to imply that you
demand the digits 64 type because the digits 14 type is inadeqaute.
This business of using supposedly portable features to build in
non-portability is common. Consider:
type x is range -2**31 .. +2**31-1;
Such type declarations are not uncommon, and are the frequent product of
people who are deathly afraid of using type Integer directly. When I read
such a type declaration I very much doubt that this is really the requird
range, instead I am almost sure that it is merely copied from the hardware.
But I don't know for sure.
Consequently when I try to port that application to a 32 bit ones complement
implementation (or an implementation, like the old rational machines, that
used the largest negative number as an undefined value), I don't know
whether I can safely adjust the low bound by 1.
The proper solution for integer is to use the actual range your application
requires. Sometimes this generates rafts of junk software checks, so in
that case, the nice solution is:
type hidden_type_not_used is <range-actually-needed>;
type actual_type_to_use is range hidden_type_not_used'first
.. hidden_type_not_used'last;
In Ada, you can use the Base attribute to write this neatly.
Oops, I should have written 'base'last and 'base'first in the above
example, and what I meant in Ada 9X is that you can use
type actual_type_to_use is new hidden_type_not_used'base
which is a little neater. These give you a type that has the range you need
but the range is increased to the next efficient hardware type.
Incidentally, the use of Integer is not necessarily inappropriate if when
you write Integer you mean (some efficient type suitable for indexing
arrays, and I am quite willing to be limited by whatever the machine provides
for efficient array indexing).
^ permalink raw reply [relevance 14%]
* Re: Transition from 32 to 64 bit
[not found] ` <35qp39$8mk@Starbase.NeoSoft.COM>
@ 1994-09-22 14:09 20% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-22 14:09 UTC (permalink / raw)
There are definitely machines in which double precision float (64 bits) is
much more efficient than single precision float (32 bits). This can arise
from two sources. First, you can have problems with checks (e.g. on the
x86 with 64-bit precision mode set, the checks are free for 64-bit but
require expensive store instructions for 32-bit). The permissions in
Ada 9X for going outside the range of unconstrained floating-point types
help a lot in eliminating this annoying glitch.
Secondly there are machines where all machine arithmetic is always done in
64-bit (notably the RS6000, but NOT the power PC). On such machines you may
well find that 32-bit fpt is slower.
That's why incidentally the uniformity recommendation is that short_float
should be 32 bits (or whatever makes sense for single precision), long_float
should be 64 bits (or whatever makes sense for double precision), and
float should be whichever of these two types is more efficient in practice.
^ permalink raw reply [relevance 20%]
* Re: Naive question about system dependencies
[not found] ` <85B716C4188@annwfn.com>
@ 1994-09-22 14:15 17% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-22 14:15 UTC (permalink / raw)
The whole idea in using separate bodies should be to completely avoid
code duplication. Only the code that is system dependent, and hence
NOT duplicated, i.e. the code that would go inside the range of an
ifdef, should be in separate bodies, code outside the ifdef can be
shared.
This isn't possible to achieve completely in all cases, but you can come
very close by building appropriate abstractions, and if you have a decent
compiler which does inlining properly, there should be no efficienc y
loss from this kind of abstraction.
To emphasize, this is a design princinple which cannot always be met, but
far too much code is duplicated in situations where there has not been
nearly enough effort in attempting to meet this requirement.
Note that the disastrous thing about ifdefs is that it gets very hard to
even make sure that the module is free of syntax errors for all cases.
Suppose we have 20 ifdefs in one module, each with two settings. THen it
takes 1,000,000 compilations just to make sure that all possibilities
compile (and 1,000,000 careful test runs to make sure they all work).
If on the other hand, you have one common module, and two versions each
of 20 little modules, then you have to compile only 41 files to check
syntax correctness, and you can at least do 41 separate unit tests (the
full integration testing would of course take 1,000,000 runs, there's
no way around that, but at least it's better to have unit testing than
nothing at all).
Best of all is to try to avoid special casing in the first place. That's
cerainly the approach we try to use in GCC, where we have several hundred
possible configurations, and we are VERY unfriendly to target dependent
code, though we can't completely avoid it.
In my experience, the ability to use ifdef's is a disaster for big systems.
All to often, you get ifdefs all over the place, and the sources become
completely unmanagable.
^ permalink raw reply [relevance 17%]
* Re: Student views on Ada
[not found] <INFO-ADA%94092110295932@VM1.NODAK.EDU>
@ 1994-09-22 14:17 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-22 14:17 UTC (permalink / raw)
Marin, front panel lights are for sissies! The first time I programmed
an Incoterm terminal, I had to enter a boot loader from the keyboard
one hex digit at a time, completely blind with no feedback of any kind
at all. It took 600 keypresses to enter it. Now that's REAL programming :-)
^ permalink raw reply [relevance 22%]
* Re: 64 bit integer support as native type
@ 1994-09-23 15:34 20% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-23 15:34 UTC (permalink / raw)
The 83 RM is not even slightly in the business of defining what integer
types are available. The 9X RM has some very minimal, pretty much
meaningless requirements, about integer sizes.
The one notable exception is that decimal types must support decent
precision, equivalent to 64 binary bits, if the IS annex is supported,
so that is one possible totally portable route in Ada 9X.
For integer types, the idea is that your implementor provides the
appropriate set of integer types.
You have two choices. Either use a compiler that supports 64-bit integer
types. FOr example, all versions of GNAT support at least 64-bit integer
types.
OR, put your own multiple preicision routines to gether (I think that
Bob Eachus has some portable routines for high precision integer arithmetic!)
^ permalink raw reply [relevance 20%]
* GNAT for Sun Solaris 2.3
@ 1994-09-23 20:11 22% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-23 20:11 UTC (permalink / raw)
Someone sent us a message this morning concerning a successfully completed
port of GNAT to Solaris 2.3, which is of course of great interest to a lot
of people including us. Unfortuantely due to a local comms glitch, this
message got lost, so please retransmit the message, thanks!
^ permalink raw reply [relevance 22%]
* Re: Free Software using AdaEd (Announcement)
@ 1994-09-23 20:12 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-23 20:12 UTC (permalink / raw)
NYU no longer supports Ada/Ed, this support is being done (very ably with
all sorts of nice goodies added) by Mike Feldman, so you should contact him
regarding Ada/Ed.
^ permalink raw reply [relevance 22%]
* Re: Ada83 or DEC Ada: Feature or bug?
@ 1994-09-26 12:54 18% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-26 12:54 UTC (permalink / raw)
In Ada 83, you declare an unsigned value like this:
type x is range 0 .. 2**32 - 1;
whether your compiler accepts this or not is up to the implementation (trying
to use this on many compilers won't work, but that's not a feature of Ada 83,
merely a (nasty) shortcoming of the implementation).
Note that you won't get wrap around arithmetic with this type, if you want
wrap around arithmetic, then you have to program it, or also check with
your implementor to see if they provide support for unsigned types (both
Dec and Alsys provide some support in separate packages -- other vendors
may too).
If your compiler rejects the above declaration, and if your vendor does not
provide any support for unsigned arithmetic in separate packages you are
out of luck. This is the same situation as the guy who wanted 64-bit signe
arithmetic maybe being out of luck if his compiler did not support it.
Trying to use 32-bit signed for 32-bit unsigned is very unlikely to be
satisfactory. Suppressing checks may work, but many compilers don't do
all possible suppression (it's not required), and you are then writing
erroneous programs which may or may not work.
Note that Ada 94 has mcuh better support for unsigned. Any reasonable
Ada 84 compiler will provide support for 32-bit unsigned arithmetic in
a convenient form:
type unsigned is mod 2 ** 32;
as you might guess from this declaration, the arithmetic is the normal
wrap around (2's complement representation) unsigned arithmetic.
^ permalink raw reply [relevance 18%]
* Re: Is Ada being used on this?
@ 1994-09-26 12:56 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-26 12:56 UTC (permalink / raw)
Doesn't Alsys also have a compiler for the IBM mainframes (they certainly
used to). In practice all three compilers for IBM mainframes found that
the total number of Ada mainframe customers was limited, so the shelves
that these compilers sit on are pretty dusty!
^ permalink raw reply [relevance 22%]
* Re: 2167A
@ 1994-09-26 13:32 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-26 13:32 UTC (permalink / raw)
The biggest weakness of documentation in my experience occurs when it is
prepared independently from the source code. It is almost inevitable that
in this case the documentation does NOT get properly maintained, and quickly
becomes useless.
That's why I *much* prefer the practice of putting extensive high level
documentation in the source files, and then insisting that they be updated
as the sources are updated.
This is very hard to achieve.
Many projects which appear to have wonderful documentation, as measured
by quantity and surface appearence of the documentation, in fact are in
terrible shape. This is especially true when the existence of the external
documentation persuades people that it is unnecssary to document the
code.
^ permalink raw reply [relevance 21%]
* Re: LOC counting standards, anyone?
@ 1994-09-26 13:33 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-26 13:33 UTC (permalink / raw)
Another LOC thread!
I guess this should really be in the FAQ
^ permalink raw reply [relevance 22%]
* Re: Verdix VADS ADA or GNU ADA on an SGI...
@ 1994-09-26 15:02 18% ` Robert Dewar
2 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-26 15:02 UTC (permalink / raw)
Martin Connor's question seems a good opportunity to make an informal
announcement that SGI has signed a contract with Ada Core Technologies
that provides for validation and full product-level documentation for
GNAT on SGI workstations. SGI is currently integrating GNAT into its
high level toolset, and GNAT will be fully supported in this environment.
A note to Martin's accountants. This may seem surprising coming from me,
but I think it is a big mistake to base your selection of Ada technology
on cost alone. I would much prefer that you select GNAT only if it makes
technical sense. For example, if you need to deliver a mission critical
application using a validated Ada 83 compiler in the very near future, then
it is hard for me to believe that GNAT is the sensible choice. If on the
other hand your needs are more flexible, and Ada 9X support is important
then it's worth doing a careful evaluation of GNAT.
Also, be careful to fully evaluate costs. Sure you can get a copy of
GNAT for $0, but that doesn't represent the full costs of using fully
supported software with appropriate tools.
It is important to compare apples with apples here. In particular, it would
be very misleading to compare the cost of acquisition of an unsupported
version of GNAT with the acquisition of fully supported proprietary software.
Remember the Cygnus slogan (they are the company that supports GCC): "we
make free software affordable".
It would be too bad if people inappropriately selected GNAT based on
misleading and incompletely cost issues alone. That won't do anyone
any good.
^ permalink raw reply [relevance 18%]
* Re: Guy Fawes (Was Re: Vendor bashing and pushing Ada....and an ad from SGI.)
@ 1994-09-26 23:47 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-26 23:47 UTC (permalink / raw)
Who is this rascal Andres Dunstan who is sticking up for Guy Fawkes?
Ah-ha! I see an Australian, that explains it :-)
I fear me this thread has wandered far from Ada, time for those of you out
there who actually expect to read about Ada in comp.lang.ada to add another
entry to your kill file :-)
^ permalink raw reply [relevance 22%]
* Re: Verdix VADS ADA or GNU ADA on an SGI...
@ 1994-09-26 23:53 19% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-26 23:53 UTC (permalink / raw)
Ted is basically accurate in his assessment of GNAT (I am pleased to hear
that he has managed to gte it to work for him). Just one amendment is that
the tasking is available on some other platforms besides Suns, and in
particular, the tasking will be available on several other machines including
the SGI very shortly.
An important factor in risk mitigation with using early versions of GNAT is
indeed to be careful about what features you use. GNAT itself has been using
nothing but GNAT to compile itself for over 15 months, and we have found
it to be a VERY reliable compiler, but we certainly don't use some of the
more difficult aspects of Ada (complex private types, aggregates, complex
variant records etc), which helps to account for our good experience.
It's certainly early to be using GNAT for mission critical stuff, but a
number of projects have done, and are doing so successfully already, and
each new version of GNAT improves the stability and completeness
substantially (keep those bug reports coming in!)
^ permalink raw reply [relevance 19%]
* Re: Tagged type feature, or GNAT bug?
@ 1994-09-28 11:14 19% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-28 11:14 UTC (permalink / raw)
Obviously you can't have an array of type'Class, because the whole point is
that you don't know till link time what the maximum size of such an object
would be. So if you think about it Mike, you have no implementation model
for how that would work except to introduce pointers, and the solution is
simple enough: introduce the pointers in the code. Always work with pointers
to T'Class, not T'Class objects themselves.
Actually that's good advice in the variant record case too. In general the
business of allocating the maximum possible space doesn't work so well even
for variant records where you know all the possibilities statically. Some
Ada 83 compilers (RR?) introduce hidden pointers in this case, and others
(ALsys) allocate the maximum space, but place an arbitrary limit on the
maximum size permitted.
It's helpful always to think about what your implementation model is when
you run into something like this. If you can't think of a simple model, then
very likely there is a problem!
Robert
^ permalink raw reply [relevance 19%]
* Re: Modulus and Remainder operations (Was Re: Help with a bit of C code)
@ 1994-09-28 13:56 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-28 13:56 UTC (permalink / raw)
In traditional C, the result of applying / or % to negative integers is
implementation dependent and hence undefined at the language level. Likely
it will be remainder type semantics rather than modulus type semantics
because most machines do things that way by default, but on the ICL1900
series C gave modular semantics, since that's the way the machine was.
I think this is unchanged in the ANSI C standard, can someone confirm this?
^ permalink raw reply [relevance 21%]
* Re: Types with physical dimension
@ 1994-09-28 13:59 22% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-28 13:59 UTC (permalink / raw)
"What do Ada programmers do to guard against dimensional errors"
Probably not much, because in practice, at least in my experience, such
errors are rare, although they are an obvious target for theoretical
discussions.
Using private types is of course the appropriate way to do things in
Ada 83. In Ada 9X, abstract operations can be used to eliminate unwanted
operations.
^ permalink raw reply [relevance 22%]
* Re: Where's Ada OCompiler?!
@ 1994-09-28 19:33 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-09-28 19:33 UTC (permalink / raw)
fpt gnat from cs.nyu.edu. there are versions for Linux, OS/2 and DOS
you are better off with the Linux or OS/2 versions if possible, but
the DOS version does work (it uses the DJPP extender which you will
have to obtain separately).
^ permalink raw reply [relevance 22%]
* Re: line 1(1) ilegal character
@ 1994-09-28 21:26 21% ` Robert Dewar
0 siblings, 2 replies; 200+ results
From: Robert Dewar @ 1994-09-28 21:26 UTC (permalink / raw)
please send bug reports for GNAT to gnat-report@cs.nyu.edu, that's where
the people are who can help you. In this case, you have apparently
got something misintalled, and anyway I can tell that you are using a
very ancient version of GNAT. Please get the latest version, follow
the installation instructions TO THE LETTER, and then try again.
The current version of GNAT is 1.83. Binary releases for OS/2, DOS, Linux,
SunOS, Solaris, RS6000, Alpha + others can be FTP'ed from cs.nyu.edu.
Flash: we have just completed the port for NT, and this will also be made
available at cs.nyu.edu in the near future.
^ permalink raw reply [relevance 21%]
* Re: generic call backs
@ 1994-09-28 21:29 22% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-09-28 21:29 UTC (permalink / raw)
Are you really saying that Dec Ada allows two package specs to with one
another? surely not, this is a clearly illegal program, which any Ada
compiler should be expected to detect and disallow.
^ permalink raw reply [relevance 22%]
* Re: Types with physical dimension
@ 1994-09-29 4:11 19% ` Robert Dewar
0 siblings, 2 replies; 200+ results
From: Robert Dewar @ 1994-09-29 4:11 UTC (permalink / raw)
"Of course it would be nice to have more direct support for units"
In the "of course" here likes a rather fundamental assumption which I
question, namely that it is always desirable to have features at hand
that do exactly what you want in the most convenient way. While that
may seem locally optimal, I am afraid that following this inclination
repeatedly leads to too much complexity in language design. Remember
that a reader must be able to read the code, that means that a reader
has to be able to pretty much understand the whole language since there
is no restriction on what the writer can write. A big language is not
so bad from the writer's point of view, since you only learn what you
need, but from the reader's point of view, the complexity is much
harder to handle.
To me, the units case crosses the line. I think you can build this well enough
in Ada, esp in Ada 9X with the abstract feature, and I think that (even
given infinite resources :-) it would be a mistake to add an additional
(inevitably somewhat complex) feature that would handle this more
directly.
^ permalink raw reply [relevance 19%]
* Re: Types with physical dimension
@ 1994-10-03 4:37 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-03 4:37 UTC (permalink / raw)
Peter, your meters * meters not being allowed to give meters can be
done in a perfectly straightforward manner using abstract subprograms
in Ada 9X, why isn't that solution good enough for you?
^ permalink raw reply [relevance 22%]
* Re: Types with physical dimension
@ 1994-10-03 4:40 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-03 4:40 UTC (permalink / raw)
Tuck takes me to task for not including the "given infinite resources :-)
from his original message.
But of course the point is that infinite resources for implementation are
totally besides the point, I have no concern for implementors in this
discussion, only for readers, and unless infinite resources also gives
readers infinite brain power, it won't help :-)
^ permalink raw reply [relevance 22%]
* Re: line 1(1) ilegal character
@ 1994-10-03 4:44 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-03 4:44 UTC (permalink / raw)
Sorry the Sun SOlaris 2.0 version is NOT yet available for FTP from cs.nyu.edu,
we hope to have it packaged up, along with the Solaris 386 version sometime
this coming week.
^ permalink raw reply [relevance 22%]
* Re: line 1(1) ilegal character
@ 1994-10-03 4:46 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-03 4:46 UTC (permalink / raw)
Sorry Norm, you are quite right, I should have clarified, we are talking
about NT for x86. We also have done some work on NT for ALpha, but that
will not be available for a while. We are currently not looking at all
at NT for other machines (such as the power PC ??? :-)
^ permalink raw reply [relevance 22%]
* Re: generic call backs
@ 1994-10-03 4:50 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-03 4:50 UTC (permalink / raw)
Wayne says
"I hate to say this Robert, but this is a dumb question. You of all people
should know better than to even ask this."
fine, it's a dumb question, but that's what I took someone to say, and I
still don't know if I am being dumb because the answer is "of course Dec
doesn't allow this", or because it is obvious from the original post that
Dec does allow this. I trust it is the first, but I do not have ESP! As
my original post makes clear I hope, I would be amazed to find that Dec
allowed this, even with the peculiar special switch that was mentioned
in the original post.
^ permalink raw reply [relevance 21%]
* Re: New to ada.
@ 1994-10-03 5:03 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-03 5:03 UTC (permalink / raw)
All GNAT compilers support integers of 64 bits, and to a somewhat limited
extent (basically arithmetic only) up to 128 bits using the so far
undocumented :-( entity Standard'Huge_Integer. Of course use of the
latter is not likely to be portable to other compilers, it is really
intended for internal library use.
^ permalink raw reply [relevance 22%]
* Re: Gnat Ada 9X - What sort of PC does it need???
@ 1994-10-03 12:06 19% ` Robert Dewar
1994-10-03 12:15 17% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-03 12:06 UTC (permalink / raw)
Small programs can be compiled and run successfully in 4 megs of memory
if the OS environment is compatible with such a small memory size. Using
DJPP or Warp (i.e. OS/2 version 3.0, or the current Warp Beta), you can
probably manage fine with 4 megs. Of course these are virtual memory
systems, so memory is jut an aspect of performance, not capacity. Large
programs will begin to thrash the disk badly, but for example you may
still find that a 90MHz Penitum with 4 megs (what a horrible thought!)
out performs a 16 MHz 386 with 8 megs on a large program. You really have
to try yourself to see what performance you get and whether it is acceptable
to you.
Certainly we strongly recommend getting more memory, a reasonable lower
limit would be 8 megs for DJPP or OS/2, 12 megs for Linux, and 20 megs
for NT (when that GNAT port comes out, or perhaps less for Daytona).
Remember these days 4 megs of memory costs $150, and there is no better
investment you can make for improving performance of a PC for running
large 32-bit applications (such as GNAT or the 32-bit OS environments
that support it!)
^ permalink raw reply [relevance 19%]
* Re: Gnat Ada 9X - What sort of PC does it need???
1994-10-03 12:06 19% ` Robert Dewar
@ 1994-10-03 12:15 17% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-03 12:15 UTC (permalink / raw)
Here is a more general idea of what hardware we recommend for running
the PC version of GNAT, using either OS/2 or DJPP:
Minimum:
486 25 MHz
200 meg hard drive
8 megs of memory
such systems should be available with 14" color monitor in the $1250 range
or even cheaper if you settle for a no-name clone (but be sure to check
OS compatibility in this case, make sure you have a money back guarantee)
The $1250 is for a minstream machine (e.g. Compaq Presario 433, which is
actually a 33MHz machine, in fact you may as well go for a 33 MHz, really
they cost so little more today). Note that SZ or DX does not really affect
GNAT performance, since the compiler itself does not use floating-point.
Desirable:
Pentium
400 meg drive
16 megs of memory
now you are in the $2000-$2500 range, although in the latest computer
shopper, there was a Pentium clone for less than $1500.
One of the nice things about the timing of GNAT is that the hardware that
you buy today has caught up nicely with the requirements of GCC/GNAT. A
couple of years ago, specs like the above would have seemed much too
luxurious, but these days, minimal student machines are likely to at
least match the "minimum" spec above (with the possible need to add
4 megs of memory).
Of course when compiling large programs or systems, more power will never
hurt. In particular, more memory is always helpful, and GNAT should be
able to take convenient advantage of the new symmetric multi processing
systems coming out (running OS/2 MP or NT with the soon to be available
GNAT port to NT/x86). THe lack of a required order of compilation is
particularly helpful when compiling large programs on an MP system.
^ permalink raw reply [relevance 17%]
* Re: Is Ada the future? [was: Is C++ the future?]
@ 1994-10-04 14:44 22% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-04 14:44 UTC (permalink / raw)
My goodness, it sure is suprising for someone to ask what the difference
between correctness and reliability is.
They are only vaguely related, there are reliable incorrect programs,
and unrealiable correct programs.
^ permalink raw reply [relevance 22%]
* Re: Eiffel for DoD development?
@ 1994-10-04 14:49 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-04 14:49 UTC (permalink / raw)
GA logic is known to have some unusual rules, does GA arithmetic also
have unusual rules and not consider 10% to be greater than 5% :-)
^ permalink raw reply [relevance 22%]
* Re: Types with physical dimension
@ 1994-10-04 14:56 16% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-04 14:56 UTC (permalink / raw)
strong typing is like anything else, fine in moderation, but dangerous to
health if overdoses are encountered.
there is a common tendency in Ada programming to assume that since strong
typing is a GOOD THING, it must make sense to use it as much as possible.
This leads to programs which thousands of different integer types and
conversions all over the place. For my taste that actually decreases
reliability, since
(a) it makes the code less readable
(b) once you get in the habit of freely breaking type barriers by writing
conversions, then the value of the type barriers is diminished.
I much prefer a style in which different integer types are used only when
it is very rare that the need for conversions will arise, or when the
necessary conversions can be nicely abstracted.
Similarly, if setting up an abstraction requires writing a huge amount of
code, which might itself have errors, then the mere fact that you can use
the abstraction neatly when you are done may not leave you ahead (this is
an instance of the common behavior of spending your time building tools
to increase your productivity, spending all your time on this is NOT
a good idea :-)
Obviously everyone knows that strong typing is helpful (says he after
spending a frstrating half hour finding a bug in an idiotic little C
program -- left the & off in a call to sscanf, resulting in unimaginable
and hard to debug chaos). But that doesn't mean "the more strong typing
tne better".
Good software engineering is the art of choosing the right abstractions,
and structures, and it is not the case that it is always preferable to
raise the level of abstraction as far as possible -- it needs to be at
just the right level.
The units case is an interesting one. Sure there are are programming
situations where providing some automatically type checked units checking
makes sense, but there are also situations where the attempt to provide
such checking is precisely abstraction overkill. It's a nice example that
way, because it lies somewhere near the borderline, and you need the skill
to make the right cut on this border.
^ permalink raw reply [relevance 16%]
* Re: PC ada compiler...
@ 1994-10-04 15:00 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-04 15:00 UTC (permalink / raw)
Sorry for all of those who see this message posted every couple of weeks, but
since there are two outstanding requests, it seems reasonable to repost.
There are two free compilers for the PC
One is a nicely packaged version of the original Ada/Ed system, an
interepretor for Ada 83. THis is available from MIke Feldman at
George Washington University.
The other is a GNU implementation of Ada 9X, called GNAT. This is a real
compiler, and is available (for OS/2, DOS/Windows, and Linux) by anonymous
FTP from cs.nyu.edu
^ permalink raw reply [relevance 21%]
* Re: Gnat Ada 9X - What sort of PC does it need???
@ 1994-10-04 15:07 17% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-04 15:07 UTC (permalink / raw)
If you are restricted to 8+3 file names (either because you are using DOS,
or using OS/2 on a FAT partition, or -- most aggravating of all if you ask
me -- you insist on using a junk editor that does not handle long file names)
you are not completely stuck
instead you can use the -gnatk8 switch when you compile, which uses a
crunching algorithm to crunch file names down to the 8+3 limit. The
associated gnatk8 utility that is part of the GNAT system can be used
to find the crunched name for a unit (although it is quite a simple
algorithm, see source of krunch.adb, and after a while easy to do in
your head).
Of course this does not guarantee uniqueness, and so you might have to
juggle unit names a bit, but in practice it works pretty well, and you
may well find you don't have any name clashes.
of course the other possibility, suitable for educational use, and actually
a convention we follow in GNAT itself, is simply to keep unit names short.
That's not so terrible:
if you use "use" clauses, then you don't often mention unit names anyway,
only in with clauses, so keeping them short does not have a big readability
effect.
if you don't use "use" clauses, then often people resort to doing local
renamings using abbreviated unit names because they can't stand giant
names before the dots. By keeping unit names short, you can use the real
unit names in qualification, which is often clearer.
Anyway, there are two ways of dealing with the "problem" that are a little
less drastic than repartioning the disk or switching editors.
My personal advice if you are using OS/2: probably worth taking the plunge.
Repartition and setup a big HPFS partition, and learn a new editor (I find
epm very nice, but also consider learning EMACS).
^ permalink raw reply [relevance 17%]
* Re: C++ bashing (was Re: Vendor bashing? Sort of.)
@ 1994-10-04 18:44 15% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-04 18:44 UTC (permalink / raw)
Jonothan, if you reread my original post, I never said that C-Front was
not a compiler, I said that it was a preprocessor. These two classes are
certainly *not* mutually exclusive. Actually I don't even think that
compiler and interpretor are mutually exclusive.
Of these three terms, I find preprocessor to be the most precise. To me
it means precisely that you have a processor that takes one source language
and generates another which is then subsequently fed into an existing
compiler for the generated language. How much error checking the PP does
seems quite irrelevant to me (there can be compilers that do no checking
and PP's that do lots of checking). The two important charactersitics of
PP's to watch out for are end-to-end environment issues like debugging,
and inefficiencies that come from trying to map into an intermediate
language that cannot be changed (because it is defined, and the downstream
compiler cannot be modified), and might not in fact be appropriate. These
are not necessary problems, since C is set up to accomodate a preprocessor
of its own in any case, the end-to-end problems are often solved, and for
the initial version of C++ there are no serious inefficiencies that come
from the PP approach.
For either the current version of C++ (notably in the exception area), or
Ada (nested subprograms, subunits, and in particular checked arithmetic),
preprocessing into C is sure to cause significant inefficiencies since
these concepts just do not map efficiently into C. Of course one can
partially, but definitely not fully, mitigate these effects by providing
library routines.
So in short there is nothing inherently bad about the idea of preprocessing.
However, it is important to understand that, unlike C front, GNAT in no
sense generates intermediate C code. The reason that is important is that
if it did, it would have no chance of being really efficient. Since it in
fact does NOT generate C code, and since the backend of GCC can be and is
being modified to accomodate Ada efficiently, there are no arbitrary
barriers to efficiency in GNAT (it's just a matter of time and effort
to get rid of known sources of inefficiency).
Note that in a certain sense you could call all GCC compilers preprocessors
since they generate assembly language (a choice that is not necessarily the
most efficient in compile time, but carries no runtime penalty, and greatly
eases portability of the GCC system). However, the two possible penalties
for preprocessors are largely absent. Certainly ASM has on arbitrary
restrictions on what you can do. And in most systems, end to end issues
are well handled (although there are exceptions, GCC depends on an assembler
that can accept debugging information, and this is problematic in some
environments -- which is why, for example, there is still no GDB for OS/2).
^ permalink raw reply [relevance 15%]
* Re: GNAT and emx ( GDB ) ?? OS/2, PM Tools for GNAT ?
@ 1994-10-04 18:47 20% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-04 18:47 UTC (permalink / raw)
It may well be possible to port GNAT to the EMX version of GCC for OS/2.
We haven't done so, because, as far as I know, EMX remains proprietary
and undistributable by FSF. Still if someone is successful doing the port,
by all means let us know. It sure would be nice to have GDB running. We
are still trying to get GDB running with our native GCC port, but we have
not succeeded yet.
P.S. Be sure to at least copy questions like this to gant-report, many of
the people who might answer such questions from the GNAT team do not
read CLA, and generally that is the team of people potentially most
knowledgable in answering questions about GNAT.
What kind of tools are you looking for?
^ permalink raw reply [relevance 20%]
* Re: ClearCase and Ada -- Config. Management
@ 1994-10-05 1:42 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-05 1:42 UTC (permalink / raw)
There is an active project underway at SGI to interface Clearcase to
GNAT, and this combination will, as I understand it, be the basis of
the SGI GNAT/based Ada product. Conctact Wes Embry at SGI for further
details.
^ permalink raw reply [relevance 22%]
* Re: Verdix VADS ADA or GNU ADA on an SGI...
@ 1994-10-05 11:35 22% ` Robert Dewar
1994-10-05 11:45 19% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-05 11:35 UTC (permalink / raw)
Fred, not only has GNAT been ported to Irix, but SGI has signed a contract
with ACT under which GNAT will be validated under ACVC 2.0 early next year.
^ permalink raw reply [relevance 22%]
* Re: Verdix VADS ADA or GNU ADA on an SGI...
1994-10-05 11:35 22% ` Robert Dewar
@ 1994-10-05 11:45 19% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-05 11:45 UTC (permalink / raw)
I am a bit hesitant to respond further in too much detail to Fred's note,
since it seems like it could be interpreted as advertising. But since there
is clear false information there, it seems like it should be corrected. Fred
assumes that he can fall in the gap between SGI support and GNAT support.
That's a real concern, and is why the ACT approach is to work cooperatively
with SGI. SGI will provide front line support, and then as needed ACT will
provide support (to SGI, and via them to SGI customers as needed) for the
central GNAT technology. We believe that this is the most viable approach
for support of GNAT from a customers point of view. Of course, large
customers can also talk to us directly if they feel they need direct ACT
support. There is quite a bit more to be said, but as I noted earlier, I
don't like to use CLA for advertising. For more information, contact me
as president of ACT, or Wes Embry, the manager of the Ada/GNAT project
at SGI.
Robert Dewar
Ada Core Technologies
^ permalink raw reply [relevance 19%]
* Re: Gnat Ada 9X - What sort of PC does it need???
@ 1994-10-05 11:50 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-05 11:50 UTC (permalink / raw)
Incidentally, I made a casual remark about EMACS which awakened at least
one VI disciple. To make it clear that I am not guilty of religeous
discrimination, let me rush to point out that there is also a VI for
OS/2 that works fine, and handles long file names.
Yes, there is a utility that renames files, and, optionally do the
8+3 krunching. It is called gnatchop, and is, even in our rather
incomplete documentation, reasonably fully described :-)
^ permalink raw reply [relevance 21%]
* Re: Syntax question
@ 1994-10-05 11:52 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-05 11:52 UTC (permalink / raw)
Put_On (Who => Jack, What => "the box", Where => On ("the table"));
^ permalink raw reply [relevance 22%]
* Re: Ada compared to C++
@ 1994-10-05 12:02 16% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-05 12:02 UTC (permalink / raw)
Of course the key here is not out-of-date, but inconsistent, and indeed
Ed's arguments would be clearer with this modification.
Make is, as I have found out, having used it for GNAT for some time now,
totally inadequate. The fundamental problem is that the comparison of
greater than on time stamps just doesn't work. If you go back to a previous
version of the source with an old time stamp, then make thinks it's up to
date. Of course in the GNAT case, the binder complains, so you can't actually
build the inconsistent application that make thinks is just fine (but of
course you could in C or C++).
Now of course I realize that there are much more sophisticated tools than
make for ensuring consistency (e.g. clearcase from SGI, recently mentioned
in this newsgroup). If someone will promise me that all C++ applications
are built with such tools, and no one uses make or worse still, nothing at
all, then all would be well, but you know perfectly well this is not the
case (or perhaps I should say not the clearcase :-)
With Ada on the other hand, I know that everyone is using tools to ensure
consistency because you can't get around them (without doing something
very deliberate).
Note that there is nothing to stop the Ada approach from being grafted into
C++. An interesting project in the GCC world would be to make g++ share the
same consistency mechanisms that are used by GNAT. However, it is clear that
there is a real advantage in having these mechanisms clear at the language
level.
Going back to GNAT, we will continue to use make files indefinitely (unless
someone follows the GCC thoughts in the previous paragraph), since GNAT is
a mixed C/Ada application, and we need the make for the C part (and in any
case we use make for higher level control like building distributions and
running bootstraps).
However, the explicit list of dependencies in the GNAT makefile for the
compiler Ada sources is very irritating. For one thing, it is always one
step out of date, it is yesterdays dependencies, not todays. The solution
of course is a decent make program, and we are now working on one (its
actually quite simple to do) called gnatmake, and then the make file will
simply call gnatmake.
^ permalink raw reply [relevance 16%]
* Re: Is Ada the future? [was: Is C++ the future?]
@ 1994-10-05 13:15 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-05 13:15 UTC (permalink / raw)
OK, so Denver was C++, but let's avoid the mistake of assuming that the
problems were due to the language, until we know more.
^ permalink raw reply [relevance 22%]
* Re: Easily-Read C++?
@ 1994-10-05 13:28 17% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-05 13:28 UTC (permalink / raw)
The point that C and C++ programmers tend to use abreviations and in general
short identifiers, where as Ada programmers tend to use long fully spelled
out names is a pretty important one. Because, good choice of names is often
critical to readability of code (more critical than the basic syntactic
structure of the language -- Basic with good names can be much more readable
than Ada with junk short names).
So, it isn't a language issue at all? right? you can perfectly well use nice
names in C++ (or for that matter Basic) if you want to.
Well, I am not so sure that this is not a language issue. THe trouble with
C, inherited by C++, is that it has a lot of very neat notations that
somehow are much nicer and neater with short names (much the same could
be said of many traditional mathematical notations, mathematicians tend
to call a function f, rather than Second_Order_Bessel_Function, but then
their "programs" are usually short).
i++
that's a nice neat notation, especially when composed in a complex
expression, but
Average_Daily_Rate_Of_Pay++
makes people laugh (I tell that as a joke, and C programmers as well as
Ada programmers laugh).
somehow, the ++ just ain't so neat in the context of long names.
How important is this effect? I don't know!
To what extent does it explain the empirical observation of difference
in style between C++ programmers and Ada programmers? I don't know!
I hasten to add that the universal quantifiers here are of course bogus,
not ALL C++ programmers choose junk names, and not all Ada programmers
choose good names (the most noticable counter examples I have seen in
both cases come from recently translplanted programmers, C++ programmers
trying to write Ada, or vice versa).
I would also add to this thread that the mere fact that there exists a
person who can easily read X does not mean that X is readable. I once
had a student who gaily wrote thousands of lines of uncommented assembly
language, and could read it just fine :-)
^ permalink raw reply [relevance 17%]
* Re: GNAT pragma IMPORT and type conversions
@ 1994-10-05 21:14 21% ` Robert Dewar
1994-10-05 21:15 22% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-05 21:14 UTC (permalink / raw)
The conversion from Ada types to C types in the GNAT environment is
quite canonical. FOr example integer always corresponds to int, and
system.unsigned_types.unsigned always corresponds to the C unsigned type.
The GNAT documentation is certainly not very complete in this area, I will
try to have it updated a bit in this particular area for the next release.
Meanwhile, if you have specific questions, address them to gnat-report
as usual.
^ permalink raw reply [relevance 21%]
* Re: GNAT pragma IMPORT and type conversions
1994-10-05 21:14 21% ` Robert Dewar
@ 1994-10-05 21:15 22% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-05 21:15 UTC (permalink / raw)
please send questions to gnat-report, we will bne happy to help you out.
^ permalink raw reply [relevance 22%]
* Re: Easily-Read C++?
@ 1994-10-05 22:02 22% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-10-05 22:02 UTC (permalink / raw)
Right, and comments also slow down you reading because they add unnecessary
characters .. I certainly know far too many programmers who think that
way ...
^ permalink raw reply [relevance 22%]
* Re: Is Ada the future? [was: Is C++ the future?]
[not found] ` <37dp17$gp6@goanna.cs.rmit.oz.au>
@ 1994-10-11 13:37 20% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-11 13:37 UTC (permalink / raw)
OK Richard, you are right, it isn't LISP that likes debuggers. That for me was
a shorthand for "typical LISP programmers", or "the spirit of LISP" or
somesuch.
I think the reason that highly dynamic languages tend to like to use
debuggers (in the same general sense as para 1 above :-) is that almost
all error detection is put off till runtime, and so the normal style is
throw code together, try to run it, and then remove the bugs. Second it
is easy to change code on the fly from within the debugger in LISP, so
one gets to a point where the debugger is not merely a debugger but
essentially a programming environment.
I am not saying this is good, and I am not saying this is the only way to
program Lisp. I am just observing what from what I see and hear around me
seems to be the most typical usage patterns.
^ permalink raw reply [relevance 20%]
* Re: Easily-Read C++?
[not found] ` <124377@cup.portal.com>
@ 1994-10-11 18:43 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-11 18:43 UTC (permalink / raw)
There are to my mind three justifications for comments:
Saying WHY you are doing something, and WHY you did it that way
Saying WHY you did NOT do something, and WHY you did NOT
Describing WHAT the code does, but at a higher level of abstraction
than the code itself.
^ permalink raw reply [relevance 22%]
* Re: Easily-Read C++?
@ 1994-10-11 18:52 18% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-11 18:52 UTC (permalink / raw)
Robert (Firth), you didn't look at my question quite carefully enough.
Of course it can be the case that ++c clobbers a value stored by someone
else, but I asked the following:
is it permissible for ++c to STORE a different value from what it returns?
Now of course on all machines, as illustrated by your second code example
(which is really the only possibility on all RISC machines, and is the
best code on all modern machines), it is possible to generate code so
the answer is NO
x := x + 1; (x left in a register)
(use the value in the register)
I would expect that this code is what is generated by most C compilers. The
only possible exception is on CISC machines with increment memory or add to
memory instructions, when in fact it certainly can answer YES to my question,
as illustrated by the first example.
Reading the C standard clearly does not answer my question, so we must
presume that the two sequences of code have quite a different effect.
Note that we ought to assume that the variable involved is volatile, and
you would expect that a volatile variable would be accessed in a
comprehensible canonical style (this is certainly true in Ada), but the
++c and c++ constructs definitely mean that even if c is volatile you
don't know how often it is read and written.
I certainly agree with your parting thought! (how can anyone write
parallel code in C that is portabl).
^ permalink raw reply [relevance 18%]
* Re: Easily-Read C++?
[not found] ` <37eej8$6ie@siberia.gatech.edu>
@ 1994-10-11 18:55 21% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-10-11 18:55 UTC (permalink / raw)
John (Mills), I assume that you see from my previous post that the question
I posed is indeed a well defined one. I assumed that we are dealing with
a volatile variable here, since otherwise all bets are off of course in
the presence of concurrent access), but assuming the variable is atomic in
the Ada sense (something you can't specify in C, but you can in practice
count on, given a reasonable guess about the hardware and the compiler),
there is still a fundamental question: how many reads are you allowed,
only 1, or are you allowed 2?
^ permalink raw reply [relevance 21%]
* Re: Easily-Read C++?
@ 1994-10-11 19:03 17% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-11 19:03 UTC (permalink / raw)
Casper, you say that shared access to global data requires locking. This
plain isn't true, there are all sorts of algorithms that work fine with
shared variables. THe purpose of volatile (in either Ada or C/C++) and of
atomic in Ada, is precisely to facilitate this kind of usage. Sure in
some sense it is cleaner not to use shared variables (in another context
we would say it is cleaner not to use global variables, or even, if you
are a functional programming fan, that it is cleaner not to use *any*
variables).
However, both C and Ada recognize that in certain cases, the use of shared
variables is useful and legitimate (a bounded buffer with one consumer and
one producer is a classical case, see for example the coding of the keyboard
buffer in the PC BIOS).
THe point is that Ada's definition is considerably more secure that C/C++
here. That's the original point I was making. Ada naturally has to worry
about non-sequential semantics, since the standard includes non-sequential
execution. In the C standard however, there is no serious consideration of
concurrent semantics (that's what I mean by non-sequential here) because
the language itself has no such notion. However, lots of C programs do
have multiple threads and concurrent execution, and in such contexts,
asking what is atomic, and how many times volatile variables are accessed
is of semantic significance.
Actually even in the absence of concurrent semantics, if a volatile
variable refers to a memory mapped I/O location, it may be quite important
to know how many times a variable is referenced, since the references may
have external semantic effects.
Of course a cautious programmer will simply avoid the use of ++mem for
such a variable, but it is a little uncomfortable for things to be so
ill-defined.
^ permalink raw reply [relevance 17%]
* Re: ARPA still undermining Ada
@ 1994-10-11 19:49 22% ` Robert Dewar
1 sibling, 1 reply; 200+ results
From: Robert Dewar @ 1994-10-11 19:49 UTC (permalink / raw)
absolutely, the base technology I was referring to was in these particular
cases g++ (the GNU version of c++). I know of a couple efforts using g++
where I think that GNAT would at least have been considered if it had been
around!
^ permalink raw reply [relevance 22%]
* Re: ARPA still undermining Ada
@ 1994-10-12 13:08 16% ` Robert Dewar
[not found] ` <37gnv0$j5u@cmcl2.nyu.edu>
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-10-12 13:08 UTC (permalink / raw)
A couple of points in response To Tarjei's note.
First, I was talking about research projects where it is aboslutely vital
to have full access to the sources, because the whole point of the project
is to make language extensions etc to test out some research theory. That's
a different world from the world of mission critical applications.
Second, the free in free software means freely available, not free in $$$.
Now of course you can pick up a copy of any FSF software free, but as many
people point out, the lack of guaranteed maintenance etc. may mean that
the software is unusable, and $0 is not necessarily a good price for something
you can't use. One motto of Cygnus Corp is "we make free software affordable",
and this nicely goes to the heart of things. If you need to use free software
on a mission critical project, you need to think about maintenance costs.
You can maintain the software yourself (an option not available with
proprietary products), or probably more practical in most cases, you can
pay someone else to maintain it. That's what companies like Cygnus are
all about.
As to whether a particular piece of free software competes well technically
with some particular piece of proprietary software, that has to be judged
on a case by case basis. It would be a mistake to understand from Tarjei's
comment that proprietary software is always superior in all cases to free
software. That's just not so, there are lots of people and projects that
choose to use free software because it is the best technical choice for the
job (indeed there are systems, like Nextstep, where the vendor themselves
has decided that GCC is the best available compiler, and thus it is the
only one available).
It is equally silly for anyone to maintain that in all cases free software
is better than proprietary software. That's also clearly not so.
THe basic point is that, as I have stressed before, you should choose the
best tool for the job. If the best tool is free software fine, if the best
tool is proprietary software fine, that's just part of the normal
selection process.
In making this decision, you naturally take into account the extent to
which the availablility of sources affects your project, and as I mentioned,
for a pure research project this may be decisive, much morwe important than
cost considerations.
^ permalink raw reply [relevance 16%]
* Re: Easily-Read C++?
@ 1994-10-12 19:48 18% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-12 19:48 UTC (permalink / raw)
atomic is certainly listed in my LRM index (we *are* talking Ada 9X here, so
I am talking about the 9X 5.0 RM). If you want to talk Ada 83, then pragma
Shared serves the purpose of pragma Volatile and pragma Atomic rolled into
one (9X sensibly separates these concerns).
Obviously if you write:
x = x + 1;
in either language, you know EXACTLY the meaning if x is atomic and
volatile. Sure some other thread can come in, but the exact range of
possible effects is well understood, and for example, you can easily
implement Djkstra's semaphore algorithm to get coordination of two
processes without any explicit system level communication or rendez-vous
etc. I am not particularly suggesting you want to do this, but you can.
Now if in C, we replace this with:
++x;
then we really are not quite sure what that means. No one thinks it means
that you can only reference x once, because unless you are on a specialized
machine with a fetch-and-add (like the x86), then there is no instruction
or instruction sequence that can achieve this in one reference.
So, is it the case (remembering that x is volatile and atomic) that there
can be at most two references? Well that seems a possible reasonable thing
to say, but there is nowhere in the C reference manual that you can deduce
such a rule.
I trust that makes this clear, or at least clearer.
^ permalink raw reply [relevance 18%]
* Re: Q: common types?!
@ 1994-10-12 21:37 20% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-12 21:37 UTC (permalink / raw)
The argument that the common types package will be frequently changed and
frequently withed AND THEREFORE cause the whole system to be recompiled
is bogus.
Whether or not this occurs is a characteristic of your implementation. If
you are using an incremental system like Dec or Rational, adding declarations
to a common types package will not cause you to have to recompile any
existing clients.
This might happen in some systems, and needs to be considered, but it is
wrong to assume it is true as a matter of course.
P.S. GNAT currently does not have smart recompilation (probably a bvetter
phrase than incremental system that I used above), but there is an interesting
paper being given at Tri-Ada which will describe a smart recompilation
system being built for use with GNAT.
^ permalink raw reply [relevance 20%]
* Re: ARPA still undermining Ada
@ 1994-10-13 3:55 22% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-10-13 3:55 UTC (permalink / raw)
Mark, I couldn't agree more that it would have made sense for ARPA to fund
a GNAT-like effort earlier. I flew down to Washington a couple of times
a few years ago (i.e. several years before the GNAT work finally started)
to try to sell this idea, but it didn't fly. We have Chris Anderson to
thank for finally seeing that this was an important target of opportunity.
^ permalink raw reply [relevance 22%]
* Re: Interfacing Ada to Unix/execl var. arg. list function?
@ 1994-10-13 12:22 15% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-10-13 12:22 UTC (permalink / raw)
#2 won't work because attributes can only be applied to names (i.e. it is
a simple case of a syntax error). GNAT does indeed give a confusing
error message:
6. v := "abc"'access;
|
>>> binary operator expected
LRM references aren't the issue here, since GNAT would merely point to
some syntax rule about binary operators which would not be the slightest
help. The important thing about error messages is that they have to guess
right what you did wrong. What is happening here is that GNAT has parsed a
primary (the string literal) that cannot possibly be a name, so it doesn't
even consider the possibility of an attribute, and then it flails around
for what might appear.
Clearly what is needed is a decent error message, something like:
6. v := "abc"'access;
|
>>> attribute prefix must be a name
The RM reference if one was given would simply point to the syntax rule
for attributes showing that the prefix of an attribute must be a name,
so would not add much.
Unless the compiler correctly guesses what you had in mind, no amount of
extra explanation of what it THINKS is the error will help, in fact it will
simply confuse further.
Anyway, I have put this error case on my list of things to look at, and
I would really appreciate if more people would send in cases like this
where GNAT does a poor job of giving error messages -- we can only
improve this if we see examples. I collect/fix my own errors, but I am
disappointed I don't get more complaints/suggestions in this area
-- I guess people have grown accustomed to poor error messages in Ada
compilers -- let's fix that!
Back to the problem at hand. The proper solution is
execv (pathname, strings_array'(new string'("a"), new string'("bc"), ....))
For problem #2, it is indeed a glitch that to declare a null array
constant you have to provide a junk initialization value for all the
values, except of course there AREN'T any values, so that's a bit
annoying. Of course again you don't need a separate junk variable:
null_arg_list : constant string_array := (1..0 => new string'(""));
will do fine.
Note: pointers to aggregates certainly make sense at the implementation
level, and at that level we have something called a reference which can
be applied to any expression to get a pointer to that expression. It
would be easy enough to provide this as an extension to Ada, but GNAT
is not (yet) in the language extension business :-)
^ permalink raw reply [relevance 15%]
* Re: Ada Deutschland
@ 1994-10-13 12:29 20% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-13 12:29 UTC (permalink / raw)
this use of catholic, to mean universal, is of course quite legitimate,
but not very familiar to American English speakers.
IN the old Episcopal prayer book, there was a reference to "one holy
catholic and apostolic church", it is in the apostle's creed (I am not
sure whether that language survives into the most recent version of the
prayer book).
Naturally this surprises some Episcopaleans, and it has to be explained
here that catholic (ordinary english adjective with lower case c) simply
means universal, whereas the Catholic church (proper name, upper case C,
is QUITE a different matter, short for Roman Catholic -- which if you
think about the general meaning is a bit of a contradiction in terms :-)
Anyway, all those who believe in "the holy catholic and apostolic Ada"
keep up the crusade :-)
^ permalink raw reply [relevance 20%]
* Re: Modulus and Remainder operations (Was Re: Help with a bit of C code)
@ 1994-10-13 12:30 22% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-13 12:30 UTC (permalink / raw)
I might add to Magus' comment about the limited type issue being solved in
Ada 9X is that this is not some accident, but rather an important consequence
of a quite deliberate review of the status of limited objects in Ada, no
doubt informed by useful contributions from Henry and others :-)
^ permalink raw reply [relevance 22%]
* Re: Eiffel for DoD development?
@ 1994-10-13 14:28 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-13 14:28 UTC (permalink / raw)
Rob, why don't you think Ada (I am talking Ada 9X of course) is suitable
for report writing? I would be interested to know. I know traditionally
that specialized report writers have seemed reasonable, but ultimately
they are less successful than one might suppose. For example the REPORT
WRITER module of COBOL turns out to be of dubious value.
Given the rapidly changing nature of the world, I wonder whether traditional
views of report writing are very relevant. One may soon find that writing
Mosaic pages automatically is more important than executing trees. Almost
all aspects of programming have this kind of flux.
^ permalink raw reply [relevance 21%]
* Re: Interfacing Ada to Unix/execl var. arg. list function?
@ 1994-10-13 18:46 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-13 18:46 UTC (permalink / raw)
Indeed, Mark, the junk allocation of a null string constant is just that
junk! Just goes to show how you can be lead down the garden path :-)
^ permalink raw reply [relevance 22%]
* Re: Ada NEWS -- Week Ending 7 Oct 1994
@ 1994-10-13 19:55 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-13 19:55 UTC (permalink / raw)
I also vote in favor of retaining 9X!
By the way, how many people know that Ada 83 should really be called Ada 87
(I guess there is some country out there in the New World that thinks the
standardization happened in 1993, but I see no reason for the world
community to pay any attention to local affairs of that kind).
^ permalink raw reply [relevance 22%]
* Re: Modulus and Remainder operations (Was Re: Help with a bit of C code)
@ 1994-10-13 20:59 16% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-13 20:59 UTC (permalink / raw)
There is a big difference between the different kinds of "errors", and chief
among them is that some of them are not considered errors.
Implementation dependent means that the effect is a function of the
implementation, but the implementation is not required to document
what it does. It is not in any sense an error to write such code,
but its effect is non-deterministic, and so it would be wrong in
some sense to "rely" on a particular behavior, whatever that means.
The fact that it is impossible to formally characterize is why we
have abandoned statements like "relying on xxx is erronoues", such
statements are semantically vacuous.
Implementation defined means that the effect must be defined by the
implementation. The effect is entirely deterministic for a given
implementation, and there is nothing WHATSOEVER wrong in relying on
the documented behavior. Of course the code is potentially non-portable,
but there are many ways to write non-portable code, and many situations
in which it is quite legitimate to write non-portable code (e.g. in
device drivers). Writing non-portable code when you should be writing
portable code is a mistake, but is not somehow "wrong" at the language
level.
Erroneous means that the compiler is free to do anything at all, and
we definitely intend to imply that erroneous execution is an error in the
general sense, to be avoided. While it can be quite legitimate to write
a program that exploits an implementation dependent or implentation
defined feature, it is never legitimate to write an erroneous program,
and the compiler is free to for example raise program error (or worse)
if it detects the error (or if it doesn't).
A bounded error is a special case of erroneousness where the possible
things the compiler can do are limited. IN purely formal terms it is
no different from a non-deterministic behavior. However, the
non-formalizable, but very important difference, is that it is definitely
considered an error, essentially as bad as writing erroneous programs,
to write programs containing bounded errors. The reason we go to the trouble
of limiting the damage is to (a) make programs easier to debug and (b) attempt
to limit the damage that occurs if a program accidentally runs into a bounded
error.
^ permalink raw reply [relevance 16%]
* Re: Is Ada the future? [was: Is C++ the future?]
@ 1994-10-14 0:37 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-14 0:37 UTC (permalink / raw)
Matt, exactly what *is* the *right thing*?
^ permalink raw reply [relevance 22%]
* Re: Is Ada the future? [was: Is C++ the future?]
@ 1994-10-14 1:38 20% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-14 1:38 UTC (permalink / raw)
It is true that you can "defeat" the private abstraction by making an
"unauthorized" child package, but then you can also do this by simply
editing the spec or body of the package in the first place. A child is
an extension of a package. Generally speaking one would expect from a
configuration management point of view that writing children would be
strictly controlled, on a level comparable with the control used over
the package providing the abstraction in the first place.
Basically you can extend a package either by adding declarations to it,
or by adding a child package. The latter may be more convenient from a
modularity point of view, but from a configuration management point
of view the two methods of extension should be treated as both requiring
appropriate and comparable control.
^ permalink raw reply [relevance 20%]
* Re: HELP
@ 1994-10-14 13:21 22% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-10-14 13:21 UTC (permalink / raw)
Time for another reminder. It is useless to ask questions about features
like this that are implementation dependent unless you tell us what
compiler you are using, what version, what operating system, what
machine etc.
^ permalink raw reply [relevance 22%]
* Re: GNAT for Windows NT
@ 1994-10-14 18:28 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-14 18:28 UTC (permalink / raw)
There will be a port to NT available on cs.nyu.edu sometime net week if all
goes smoothly. This has been worked on by Doug Rupp, who did the DOS port,
and will be one of the standard NYU supported ports. The next release of
GCC will include full support for NT as well.
^ permalink raw reply [relevance 22%]
* Re: Where's Waldo? Where's Ada?
@ 1994-10-14 21:52 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-14 21:52 UTC (permalink / raw)
"But why talk about a language with no future ...."
Why indeed, if you feel that way Greg, I have a great idea: follow your
own good advice!
^ permalink raw reply [relevance 22%]
* Re: Modulus and Remainder operations (Was Re: Help with a bit of C code)
@ 1994-10-14 22:11 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-14 22:11 UTC (permalink / raw)
Well Henry, of course anyone can play the part of "completely bamboozled by
yet another incomprehensible Ada rule from those language lawyers", but
*really* the rule on limited types is quite easy to understand, and the
design and motivation behind the rule seems quite clear.
^ permalink raw reply [relevance 22%]
* Re: HELP
@ 1994-10-18 16:31 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-18 16:31 UTC (permalink / raw)
OK< sorry if I was over-harsh, but it is ALWAYS helpful if people asking
the question "how do I do this in Ada?" include information on the host
envrionment and target environment. The FAQ for this group could usefully
make that clear. It saves a lot of unnecessary iterations.
Even in the case of things that ARE in the language, there are implementation
dependencies that make it helpful to *always* have this information at hand
if people want the most effective help.
^ permalink raw reply [relevance 21%]
* Re: ARPA still undermining Ada
@ 1994-10-18 16:35 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-18 16:35 UTC (permalink / raw)
[languages like] C, Lisp and Unix
|
error: type mismatch, expected language, found operating system!
Richard Stallman writes primarily in GNU C, although clearly he works with
Lisp too in the EMACS context!
^ permalink raw reply [relevance 22%]
* Re: ARPA still undermining Ada
@ 1994-10-18 16:39 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-18 16:39 UTC (permalink / raw)
Actually Mike, I think a "full-bore" version of Ada-Ed could have appeared
significantly before 1989 if the support had been there for such an
effort.
I first started talking about the idea of a GCC-like effort for Ada quite
a bit earlier than 1989!
^ permalink raw reply [relevance 22%]
* Re: Variable Args, Ada
@ 1994-10-18 16:44 20% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-18 16:44 UTC (permalink / raw)
"Why should any modern high-level language allow a programmer to code
something that will be "unsafe" or "dangerous". Weren't the terse
grammar and compiler designed (in part) to prevent that?"
Any generally usable programming language that intends to be useful for
systems programming (e.g. writing device drivers, or other low level
stuff) needs some access to "unsafe" stuff.
Similarly there are times when even at a relatively high level of
abstraction it is reasonable to break the type security (consider
for example the problem of efficient hashing of floating-point
values).
The point is that the language should be designed so that such unsafe
usage is well advertised and can be easily controlled. That is why in
Ada you need to write a lot of "junk", including a notice at the top of
your file ("with unchecked conversion") to do what in some languages
could be done in a very straightforward way, TOO straightforward and
too easily abused.
^ permalink raw reply [relevance 20%]
* Re: ADA compiler on Mac?
@ 1994-10-18 19:06 22% ` Robert Dewar
1994-10-19 13:12 41% ` Arthur Evans Jr
1 sibling, 1 reply; 200+ results
From: Robert Dewar @ 1994-10-18 19:06 UTC (permalink / raw)
I would also suggest that people who want Ada on the MAC also make
sure that Apple knows about it. After all, consider Art's threat to
move to another platform, that doesn't mean much to Rational, indeed
perhaps it would be convenient for them if he switches platforms, but
it sure means something to Apple. THe more people who let Apple know
they need Ada, the better.
^ permalink raw reply [relevance 22%]
* Re: Child packages
@ 1994-10-18 19:09 21% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-10-18 19:09 UTC (permalink / raw)
One thing that should be emphasized about child packages (since some of
the posts of this thread have not been clear on this point) is that
child packages in no way change their parents. If you have a parent A,
and a child A.B, then if A.B does horrible things to the abstractions
in A, it still does not affect anyone who with's only package A. It is
only if package A.B is with'ed that the effects of the child are
noticable.
^ permalink raw reply [relevance 21%]
* Re: C-Ada Import of struct's -- Help
@ 1994-10-18 19:11 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-18 19:11 UTC (permalink / raw)
"Also remember that a C string must be null terminated"
be careful not to confuse here, there is no such requirement in C.
Certain C library routines (but by no means all) require strings to
be null terminated, and string constants are null terminated, but there
is no general requirement in C that corresponds to this quote.
^ permalink raw reply [relevance 22%]
* Re: ADA compiler on Mac?
@ 1994-10-19 0:16 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-19 0:16 UTC (permalink / raw)
"There will be NO commercial Ada compiler for the Mac"
I don't quite see how you conclude this from talking to one vendor! You
can certainly talk with certainty about the present, but I would hesitate
a little to talk with such certainty about the future!
^ permalink raw reply [relevance 22%]
* Re: ADA compiler on Mac?
1994-10-18 19:06 22% ` Robert Dewar
@ 1994-10-19 13:12 41% ` Arthur Evans Jr
0 siblings, 0 replies; 200+ results
From: Arthur Evans Jr @ 1994-10-19 13:12 UTC (permalink / raw)
Cc: evans, dewar
In article <3816bn$n23@schonberg.cs.nyu.edu>, dewar@cs.nyu.edu
(Robert Dewar) wrote:
> I would also suggest that people who want Ada on the MAC also make
> sure that Apple knows about it. After all, consider Art's threat to
> move to another platform, that doesn't mean much to Rational, indeed
> perhaps it would be convenient for them if he switches platforms, but
> it sure means something to Apple. THe more people who let Apple know
> they need Ada, the better.
Yes, good idea! But, how best to do this? Apple's such a big
organization that it's hard to see how to influence it.
Apple, like most hardware vendors, produces little of the software that
runs on the Mac. Now they even seem to be getting out of software
development, as MPW seems not to be moving towards PowerPC. I think
that Apple is perfectly happy to let CodeWarrior from Metrowerks take
over this segment of the market. So, it seems to me that the best
leverage for us is to push on MetroWerks to provide Ada support. They
support C, C++ and Pascal; why not Ada 94 too?
If you think MPW is the way to go, push on APDA, the part of Apple that
sells products to software developers. I called them and asked about
Ada support; they never heard of it. Or push on Symantec, which sells
several products for C, C++ and Pascal.
Other suggestions?
Art Evans
Arthur Evans Jr, PhD Phone: 412-963-0839
Ada Consulting FAX: 412-963-0927
461 Fairview Road
Pittsburgh PA 15238-1933
evans@evans.pgh.pa.us
^ permalink raw reply [relevance 41%]
* Re: Interface GNAT with Oracle
@ 1994-10-19 13:23 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-19 13:23 UTC (permalink / raw)
I don't know anything specific about GNAT and ORACLE working together, but
an important thing to remember is that the GNAT calling sequence is exactly
the C calling sequence, and the GNAT datatypes correspond to the C
datatypes (e.g. int = integer, char = character). Access types and
address values in GNAT look like C pointers EXCEPT for access types for
unconstrained arrays, which are quite different, so avoid their use in
low level interface code.
^ permalink raw reply [relevance 21%]
* Re: Magnavox consultant trashes Ada tools in IEEE Computer
@ 1994-10-19 13:31 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-19 13:31 UTC (permalink / raw)
a WEEK of compile time on the 486!!!
Gads, on my thinkpad, which is not such a fast 486 since it lacks an L2
cache, I figure I could compile 15 million lines of Ada using GNAT in a
week, and that's using the crippled version of GNAT with all the debugging
checks (the only version we distribute right now!) Just how big is this
system anyway?
^ permalink raw reply [relevance 22%]
* Re: Is Ada the future? [was: Is C++ the future?]
@ 1994-10-19 15:51 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-19 15:51 UTC (permalink / raw)
Stephen, believe me, the *great* majority of Lisp programmers would feel
lost without a debugger. There may be some singular exceptions (in all the
hundreds of lisp programmers I have met, I never found one, but of course
no universal quantification is likely to be accurate when it is done over
people :-)
^ permalink raw reply [relevance 22%]
* Re: Child packages
@ 1994-10-19 18:54 16% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-19 18:54 UTC (permalink / raw)
I think it is Robert Eachus who is being misleading and alarmist here. First
of all, it is perfectly possible to write packages now which break the
private type interface, by using unchecked conversion, and do all sorts
of horrible things.
Why is this not a disaster? Because you know from the package (with
unchecked conversion) that is is potentially a problem, and you know
that you DON'T have anything to worry about if the package is not
included in a program.
Exactly the same holds true for child packages. I really think all this
worrying about them is bogus. In fact you are much better off with a
child package than you are if someone simply mucks directly with the
source of a supposedly secure package. OK, you say, we have these wonderful
configuration managers that prevent that sort of thing -- fine have these
wonderful cm's also restrict what people can do with child packages.
The bottom line is that child packages add no fundamental functionality.
There is nothing that you can do with them that you cannot do without them,
including busting abstractions. What they allow is much more convenient
package of a program into components, and indeed some of these components
may be mucking with abstractions, possibly in a naughty way, but you are
still ahead.
Consider the following two possibilities:
someone has mucked with the source of a critical package and broken the
abstraction. All programs that with this package are bust.
someone has added a child package to a critical package, and broken the
abstraction. Only programs that with the child package are bust.
It seems clear that situation two is a huge improvement over the "ada 83"
way of breaking abstractions represented by situation one.
Of course you can still illegally muck with packages you shouldn't touch
in Ada 9X, but given the possibility of child packages, it is now practical
to really "lock the door" and forbid any mucking with critical packages and
to forbid the use of unchecked conversions.
This kind of draconian action could be done in Ada 83, but then there is
no way out for an isolated special program to get its hands on the private
data. Ada 9X allows such a method, if you care to permit it.
^ permalink raw reply [relevance 16%]
* Re: GNAT and Command Line Arguments
@ 1994-10-19 18:58 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-19 18:58 UTC (permalink / raw)
first, the usual reminder, if you want to ask questions about gnat, be sure
to at least copy them to gnat-report, where the gnat team stands ready to
help, but can only help if it sees the questions!
as to the particular question, there is a defined command line package in
Ada 9X. THe easiest way for you to get the spec is to look at file
a-comlin.ads in your GNAT library which has a copy of the spec which is
quite well commented, and should be adeqaute for your purposes.
^ permalink raw reply [relevance 21%]
* Re: Child packages
@ 1994-10-19 23:13 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-19 23:13 UTC (permalink / raw)
Norman, there is still a big difference between modifying the text of a
package and adding a child, much to big for tantamout :-)
The big difference is that if you modify the text of a package you can
blow up existing clients of that package in different programs.
If you write a child, it is completely separate, and affects on programs
that use the child,
so the level of access controls needed is quite different. a given program
may want to lock out any additional child units, and another program may
wish to allow them, but neither could permit the mucking with a shared
package's text.
^ permalink raw reply [relevance 21%]
* Re: In-Circuit Emulators with Ada support
@ 1994-10-20 5:41 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-20 5:41 UTC (permalink / raw)
contact Alsys, they have a line of cross compilers with emulator support
for various emulators.
^ permalink raw reply [relevance 22%]
Results 1-200 of ~7510 next (newer) | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
1993-04-29 15:18 17% FIXED bug in Medidian 4.1.1? Robert Dewar
1993-04-29 16:02 18% A measure of Ada's death in the database world Robert Dewar
1993-04-29 16:12 17% ADA Performance Robert Dewar
1993-05-01 6:55 17% Incorporating 9X into Ada courses Robert Dewar
1993-05-04 4:05 20% FIXED bug in Medidian 4.1.1? Robert Dewar
1993-05-05 17:35 21% Passing procedures as parameters to procedures Robert Dewar
1993-05-05 17:39 22% Robert Dewar
1993-05-19 3:22 22% Ada Mflops vs Fortran Mflops (RESULTS) Robert Dewar
1993-05-20 13:44 14% verdix kisses off Ada Robert Dewar
1993-05-20 17:30 20% Robert Dewar
1993-05-28 6:37 22% what languages Ada 9X compilers are being written in Robert Dewar
1993-05-28 6:40 22% Study shows Ada tools ten times more costly Robert Dewar
1993-05-28 6:41 20% VERDIX KISSES OFF ADA Robert Dewar
1993-05-28 20:22 20% Learning C and C++ Robert Dewar
1993-06-02 18:12 18% Ada name space (was: Re: good software engineering) Robert Dewar
1993-06-03 12:48 19% Learning C and C++ Robert Dewar
1993-06-03 12:56 22% Meridian and ADA Robert Dewar
1993-06-06 23:21 22% Meridian and Ada (not ADA) Robert Dewar
1993-06-08 12:45 22% How to Make Ada more widely used? Robert Dewar
1993-06-25 12:37 17% References in Ada exceptions news.intercon.com!panix!netnews!schonberg!dewar
1993-07-21 15:02 17% Is there a GNU ADA compiler? Robert Dewar
1993-07-27 20:17 17% Underscore ("_") in numeric literals Robert Dewar
1993-07-28 12:09 16% Ada 9X compiler for the PC Robert Dewar
1993-07-28 12:11 17% ADA arithmetic Robert Dewar
1993-07-28 12:13 16% Robert Dewar
1993-07-31 2:54 17% Ada is not a failure Robert Dewar
1993-07-31 3:13 14% Are 'best' universities being targeted for Ada9X Robert Dewar
1993-07-31 3:18 13% Are 'best' universities being targeted Robert Dewar
1993-07-31 3:27 14% Query about monitor (passive) task optimization Robert Dewar
1993-07-31 17:29 17% An Apology to Mr. Ada on "Ada Sucks" Robert Dewar
1993-08-09 4:41 7% Query about monitor (passive) task optimization Robert Dewar
1993-08-09 4:47 12% Robert Dewar
1993-08-09 4:57 12% Robert Dewar
1993-08-09 5:00 17% Are 'best' universities being targeted Robert Dewar
1993-08-09 5:02 17% Robert Dewar
1993-08-09 5:08 16% QUERY ABOUT MONITOR Robert Dewar
1993-08-09 5:12 16% Ada is not a failure Robert Dewar
1993-08-09 5:18 16% storing arrays for Fortran (was: QUERY ABOUT MONITOR) Robert Dewar
1993-08-09 5:25 17% Ada and C++: A request for comparison/contrast/relative benifits Robert Dewar
1993-08-09 12:14 13% Query about monitor (passive) task optimization Robert Dewar
1993-08-09 22:00 13% forth/fifth generation languages? Robert Dewar
1993-08-09 22:06 16% Ada and C++: A request for comparison/contrast/relative benifits Robert Dewar
1993-08-10 13:44 14% Query about monitor (passive) task optimization Robert Dewar
1993-08-10 13:51 13% Robert Dewar
1993-08-10 14:00 11% QUERY ABOUT MONITOR Robert Dewar
1993-08-10 14:02 17% Are 'best' universities being targeted Robert Dewar
1993-08-11 4:49 14% Ada and C++: A request for comparison/contrast/relative benifits Robert Dewar
1993-08-11 11:35 17% POSIX P1003.5 Robert Dewar
1993-08-11 11:49 11% Ada compiler for Windows NT Robert Dewar
1993-08-11 16:55 17% Ada and C++: A request for comparison/contrast/relative benefits Robert Dewar
1993-08-11 16:58 17% WilTel chooses Objective C - another loss for Ada Robert Dewar
1993-08-12 11:53 11% Language runtime requirements (was Re: DoD asks Microsoft ...) Robert Dewar
1993-08-12 15:00 10% Unconstrained arrays Robert Dewar
1993-08-12 21:23 12% Robert Dewar
1993-09-02 2:26 15% GNAT for PC Robert Dewar
1993-09-02 2:38 14% Hoare's gripes about Ada (should be so what) Robert Dewar
1993-09-02 2:40 17% Robert Dewar
1993-09-02 2:52 14% Hoare's gripes about Ada (was Re: Ada and C++ ...) Robert Dewar
1993-09-02 3:00 14% Unchecked_Conversion question Robert Dewar
1993-09-03 0:52 16% Computational scientists ignoring and ignored by Ada Robert Dewar
1993-09-03 18:44 16% Johnny AdaSeed (aka Greg Aharonian) Robert Dewar
1993-09-03 18:51 15% TRI-Ada '94 Topics Robert Dewar
1993-09-03 18:53 17% Robert Dewar
1993-09-04 0:13 13% Unchecked_Conversion question Robert Dewar
1993-09-04 0:17 16% Generic Pointer Type Robert Dewar
1993-09-04 0:45 17% ARPA,Air Force,Navy publicly brag about a great C++ code Robert Dewar
1993-09-07 3:16 17% Robert Dewar
1993-09-07 3:18 17% One DoD programmer's hostility towards Ada and the Mandate Robert Dewar
1993-09-07 3:20 17% Bug in AdaEd??? Robert Dewar
1993-09-07 21:22 17% obj'size for constants Robert Dewar
1993-09-09 19:22 17% TRI-Ada '94 Topics Robert Dewar
1993-09-09 21:07 15% Hoare's gripes about Ada (should be so what) Robert Dewar
1993-09-09 21:10 16% GNAT is alive Robert Dewar
1993-09-12 12:05 11% Pascal or C as a first lang Robert Dewar
1994-09-08 13:31 Government Policy on Ada Acquisitions Ted Dennison
1994-09-08 19:47 ` Bevin R. Brett
1994-09-09 14:08 ` Ted Dennison
1994-09-09 16:41 ` Richard Kenner
1994-09-09 23:43 17% ` Robert Dewar
1994-09-08 13:45 42% DOS ALSYS ADA and DOS=HIGH Rick Ballard
1994-09-08 13:53 Air Force shows how meaningless Ada waiver process is Rhoda Metzger
1994-09-13 9:46 ` Richard A. O'Keefe
1994-09-13 16:14 ` Michael Feldman
1994-09-13 20:14 18% ` Robert Dewar
1994-09-14 2:46 ` Vendor bashing? Sort of Michael Feldman
1994-09-14 13:17 ` Mitch Gart
1994-09-15 13:28 14% ` Robert Dewar
1994-09-16 1:56 ` Michael Feldman
1994-09-16 14:16 ` Gregory Aharonian
1994-09-17 0:11 22% ` Robert Dewar
1994-09-14 14:30 ` Mike Ryer
1994-09-15 13:30 22% ` Robert Dewar
1994-09-19 2:19 ` Michael Feldman
1994-09-19 3:52 17% ` Robert Dewar
1994-09-20 13:58 ` C++ bashing (was Re: Vendor bashing? Sort of.) -mlc-+Schilling J.
1994-09-20 21:51 20% ` Robert Dewar
1994-09-24 18:53 ` Fred McCall
1994-10-04 16:03 ` -mlc-+Schilling J.
1994-10-04 18:44 15% ` Robert Dewar
1994-09-08 23:12 Ada 9X features Ken Garlington
1994-09-09 13:22 15% ` Robert Dewar
[not found] <1994Sep1.122026.17797@sei.cmu.edu>
[not found] ` <347b20$jf9@theopolis.orl.mmc.com>
[not found] ` <347r7s$8nk@gnat.cs.nyu.edu>
1994-09-07 16:28 ` Multiple compilation-units (was: Re: GWU/ADA Interface) John M. Mills
1994-09-09 1:46 22% ` Robert Dewar
1994-09-10 12:46 ` Jonathan AH Hogg
1994-09-10 15:22 21% ` Robert Dewar
1994-09-10 20:59 Creating markets (long) Michael Feldman
1994-09-10 23:19 19% ` Robert Dewar
1994-09-12 13:46 ` Norman H. Cohen
[not found] ` <359ujr$ep@cmcl2.nyu.edu>
1994-09-19 2:22 ` Michael Feldman
1994-09-19 3:57 19% ` Robert Dewar
1994-09-11 1:49 22% TRI-Ada '94 advance program Robert Dewar
1994-09-11 1:50 22% Robert Dewar
[not found] <CvFI4J.D5M@world.std.com>
[not found] ` <1994Sep1.084046.21595@sei.cmu.edu>
[not found] ` <344u9q$di5@gnat.cs.nyu.edu>
[not found] ` <347idh$15ss@watnews1.watson.ibm.com>
1994-09-11 3:41 ` Ada ad in Embedded Systems Programming stinks Michael M. Bishop
1994-09-11 12:20 15% ` Robert Dewar
1994-09-11 13:29 19% ` Robert Dewar
1994-09-11 21:48 ` Erik Naggum
1994-09-11 23:47 16% ` Robert Dewar
1994-09-12 12:44 GNAT 1.82 for Linux Gene McCulley
1994-09-12 13:57 21% ` Robert Dewar
1994-09-14 5:06 ` D Elson
1994-09-15 13:39 22% ` Robert Dewar
1994-09-14 21:47 ` GNAT 1.8? for OS/2 (was Re: GNAT 1.82 for Linux) Howard Holm
1994-09-15 13:44 22% ` Robert Dewar
1994-09-12 12:55 GNAT for rs6k Gene McCulley
1994-09-12 13:59 21% ` Robert Dewar
[not found] <DERWAY.94Aug23180251@alumni.ndc.com>
[not found] ` <DERWAY.94Aug31133058@alumni.ndc.com>
[not found] ` <1994Sep1.094653@lglsun.epfl.ch>
[not found] ` <34473c$ru5@info2.rus.uni-stuttgart.de>
[not found] ` <344isl$brd@Starbase.NeoSoft.COM>
[not found] ` <3450li$t04@disuns2.epfl.ch>
[not found] ` <1994Sep4.100449.205@aldur.demon.co.uk>
[not found] ` <34e4rgINNqdg@ephor.tusc.com.au>
1994-09-12 9:35 ` Eiffel gripe (was Ada vs. Eiffel) Matthias Ernst
1994-09-12 13:52 20% ` Robert Dewar
1994-09-12 15:12 Ada9X Features Michael Hagerty
1994-09-13 16:08 ` Michael Feldman
1994-09-13 20:04 22% ` Robert Dewar
1994-09-12 15:50 KUDOS and hats off to Rational !!!!!!!! Gregory Aharonian
1994-09-12 16:22 ` Lewis Berman
1994-09-12 17:15 ` David Weller
1994-09-13 5:44 22% ` Robert Dewar
1994-09-13 13:22 CAUTION: Network Police patrolling c.l.a John R. Cobarruvias
1994-09-13 15:41 22% ` Robert Dewar
1994-09-13 16:40 A proposal for Tri-Ada '94 Gregory Aharonian
1994-09-13 17:49 16% ` Robert Dewar
1994-09-14 1:40 Portable way to read/write from a binary file? Dale Stanbrough
1994-09-14 3:51 22% ` Robert Dewar
1994-09-14 22:39 ` Dale Stanbrough
1994-09-15 17:08 22% ` Robert Dewar
1994-09-14 13:00 Static in 9X Ken Garlington
1994-09-15 13:37 19% ` Robert Dewar
1994-09-14 14:02 How to check for characters in input stream? Norman W Cramer
1994-09-15 13:42 22% ` Robert Dewar
1994-09-15 16:15 DEC Ada for Alpha Computers Loic Briand
1994-09-16 1:06 22% ` Robert Dewar
1994-09-15 17:17 Free Software using AdaEd (Announcement) Charles Lindsey
1994-09-19 2:23 ` Michael Feldman
1994-09-22 23:42 ` Peter Burwood
1994-09-23 20:12 22% ` Robert Dewar
1994-09-16 3:03 Static in 9X Ken Garlington
1994-09-17 3:13 22% ` Robert Dewar
1994-09-16 14:04 Compilation order? David C. Brown
1994-09-17 0:14 22% ` Robert Dewar
1994-09-16 15:05 Main (function) program with exit(status) John J Cupak Jr CCP
1994-09-17 3:18 20% ` Robert Dewar
1994-09-17 11:55 20% Greg and charging for sales pitch, NOT? Robert Dewar
1994-09-17 16:23 Naive question about system dependencies Mats Weber
[not found] ` <85B716C4188@annwfn.com>
1994-09-22 14:15 17% ` Robert Dewar
1994-09-17 20:54 Fibonacci Numbers? S. Hegede
1994-09-20 2:15 ` Keith Thompson @pulsar
1994-09-20 16:25 21% ` Robert Dewar
1994-09-19 14:57 Is Ada being used on this? Gregory Aharonian
1994-09-23 11:10 ` Fred McCall
1994-09-25 12:26 ` Tucker Taft
1994-09-26 12:56 22% ` Robert Dewar
1994-09-19 23:59 Vendor bashing and pushing Ada....and an ad from SGI David Weller
1994-09-20 2:19 22% ` Robert Dewar
[not found] ` <35mpre$1fb2@watnews1.watson.ibm.com>
1994-09-22 13:53 22% ` Robert Dewar
1994-09-25 10:15 ` Guy Fawes (Was Re: Vendor bashing and pushing Ada....and an ad from SGI.) Andrew Dunstan
1994-09-26 23:47 22% ` Robert Dewar
1994-09-20 16:07 Transition from 32 to 64 bit Bill Davis
[not found] ` <35n81h$1fb2@watnews1.watson.ibm.com>
1994-09-22 14:06 14% ` Robert Dewar
[not found] <DERWAY.94Aug31155314@alumni.ndc.com>
[not found] ` <ROCK.94Sep3181528@twratl.atlanta.twr.com>
[not found] ` <1994Sep9.072456.1302@gtewd.mtv.gtegsc.com>
1994-09-09 18:48 ` Eiffel for DoD development? (Was Re: Why Commit to Eiffel?) David Weller
1994-09-20 11:10 ` Eiffel for DoD development? Wayne Dernoncourt
1994-09-20 17:18 22% ` Robert Dewar
1994-09-24 18:44 ` Fred McCall
1994-09-30 13:38 ` Kevin Weise
1994-10-03 23:01 ` Richard Riehle
1994-10-04 5:18 ` Gregory Aharonian
1994-10-04 14:49 22% ` Robert Dewar
[not found] <1994Sep21.111428.24972@sydney.DIALix.oz.au>
[not found] ` <1994Sep21.122657.729@sydney.DIALix.oz.au>
[not found] ` <35qgno$ivk@gnat.cs.nyu.edu>
[not found] ` <35qp39$8mk@Starbase.NeoSoft.COM>
1994-09-22 14:09 20% ` Transition from 32 to 64 bit Robert Dewar
[not found] <INFO-ADA%94092110295932@VM1.NODAK.EDU>
1994-09-22 14:17 22% ` Student views on Ada Robert Dewar
1994-09-22 14:38 Verdix VADS ADA or GNU ADA on an SGI martin connor
1994-09-26 12:19 ` Ted Dennison
1994-09-26 23:53 19% ` Robert Dewar
1994-09-26 15:02 18% ` Robert Dewar
1994-10-04 11:35 ` Fred McCall
1994-10-05 11:35 22% ` Robert Dewar
1994-10-05 11:45 19% ` Robert Dewar
1994-09-22 17:29 64 bit integer support as native type Brent Slone
1994-09-23 15:34 20% ` Robert Dewar
1994-09-23 20:11 22% GNAT for Sun Solaris 2.3 Robert Dewar
1994-09-24 5:45 Ada83 or DEC Ada: Feature or bug? Stephen M. Youndt
1994-09-26 12:54 18% ` Robert Dewar
1994-09-25 13:53 2167A Ken Garlington
1994-09-26 13:32 21% ` 2167A Robert Dewar
1994-09-25 15:08 LOC counting standards, anyone? Lewis Berman
1994-09-26 13:33 22% ` Robert Dewar
1994-09-27 14:40 Modulus and Remainder operations (Was Re: Help with a bit of C code) David A. Cobb
1994-09-28 13:56 21% ` Robert Dewar
1994-09-27 16:36 Tagged type feature, or GNAT bug? Michael Feldman
1994-09-28 11:14 19% ` Robert Dewar
1994-09-27 17:08 generic call backs Ewan Benson
1994-09-28 12:13 ` Kevin V. Sobilo
1994-09-28 21:29 22% ` Robert Dewar
1994-09-29 21:03 ` Wayne Magor
1994-10-03 4:50 21% ` Robert Dewar
1994-09-27 17:30 line 1(1) ilegal character Hans Petter Fasteng
1994-09-28 21:26 21% ` Robert Dewar
1994-09-29 15:23 ` Pascal OBRY
1994-10-03 4:44 22% ` Robert Dewar
1994-09-29 15:25 ` Norman H. Cohen
1994-10-03 4:46 22% ` Robert Dewar
1994-09-27 22:18 Types with physical dimension Paul Graham
1994-09-28 13:59 22% ` Robert Dewar
1994-10-03 17:31 ` Stephen A. Leake
1994-10-04 14:56 16% ` Robert Dewar
1994-09-28 9:06 Where's Ada OCompiler?! Tung-lin Tsai
1994-09-28 19:33 22% ` Robert Dewar
1994-09-28 15:16 Q: common types?! Tony Leavitt
1994-10-05 4:40 ` Daniel Wengelin
1994-10-12 17:39 ` gamache
1994-10-12 21:37 20% ` Robert Dewar
[not found] <GRAHAM.94Sep27181841@canopus.clsi.com>
1994-09-28 21:41 ` Types with physical dimension Tucker Taft
1994-09-29 4:11 19% ` Robert Dewar
1994-09-29 11:19 ` Peter Hermann
1994-10-03 4:37 22% ` Robert Dewar
1994-09-29 13:37 ` Tucker Taft
1994-10-03 4:40 22% ` Robert Dewar
1994-09-29 20:08 Is Ada the future? [was: Is C++ the future?] John DiCamillo
1994-09-30 13:45 ` David Weller
1994-10-01 21:40 ` John DiCamillo
1994-10-03 9:53 ` Robert I. Eachus
1994-10-03 20:41 ` John DiCamillo
1994-10-04 8:41 ` Robb Nebbe
1994-10-13 22:01 ` Val Kartchner
1994-10-14 1:38 20% ` Robert Dewar
1994-10-17 11:52 ` Child packages [nn,pedo,incest,cons] Robert I. Eachus
1994-10-18 10:30 ` Child packages Robb Nebbe
1994-10-18 9:37 ` Robert I. Eachus
1994-10-18 19:09 21% ` Robert Dewar
1994-10-19 11:03 ` Robert I. Eachus
1994-10-19 16:24 ` Norman H. Cohen
1994-10-19 23:13 21% ` Robert Dewar
1994-10-19 18:54 16% ` Robert Dewar
1994-10-04 14:44 22% ` Is Ada the future? [was: Is C++ the future?] Robert Dewar
[not found] ` <36h4pc$9dd@starbase.neosoft.com>
1994-10-02 16:30 ` Robin Rowe
1994-10-03 9:22 ` Andrew Lees
1994-10-03 21:31 ` John DiCamillo
1994-10-04 23:29 ` John DiCamillo
1994-10-05 3:52 ` Robin Rowe
1994-10-05 13:15 22% ` Robert Dewar
1994-10-05 13:54 ` David Weller
[not found] ` <36uhnl$4c1@gnat.cs.nyu.edu>
[not found] ` <37dp17$gp6@goanna.cs.rmit.oz.au>
1994-10-11 13:37 20% ` Robert Dewar
1994-10-19 11:24 ` Stephen J Bevan
1994-10-19 15:51 22% ` Robert Dewar
[not found] ` <36msgr$qq2@starbase.neosoft.com>
1994-10-04 7:21 ` Ada compared to C++ Robin Rowe
1994-10-05 6:44 ` Bob Kitzberger
1994-10-05 12:02 16% ` Robert Dewar
1994-09-30 17:55 ClearCase and Ada -- Config. Management Daniel Schwepker
1994-10-05 1:42 22% ` Robert Dewar
1994-09-30 23:30 PC ada compiler Todd Allen Lowe
1994-10-04 0:43 ` Stephen Wagner
1994-10-04 15:00 21% ` Robert Dewar
1994-10-03 1:24 New to ada Seth Hettich
1994-10-03 5:03 22% ` Robert Dewar
1994-10-03 7:48 Gnat Ada 9X - What sort of PC does it need??? Michael Coburn
1994-10-03 12:06 19% ` Robert Dewar
1994-10-03 12:15 17% ` Robert Dewar
1994-10-04 1:50 tmoran
1994-10-04 15:07 17% ` Robert Dewar
1994-10-04 13:43 GNAT and emx ( GDB ) ?? OS/2, PM Tools for GNAT ? Ralph Paul
1994-10-04 18:47 20% ` Robert Dewar
1994-10-05 3:00 Easily-Read C++? Ken Garlington
1994-10-05 9:42 ` Pierre Castori
1994-10-05 13:28 17% ` Robert Dewar
1994-10-05 17:47 ` Kevin Cline
1994-10-05 22:02 22% ` Robert Dewar
1994-10-05 22:23 ` Richard Kenner
[not found] ` <124377@cup.portal.com>
1994-10-11 18:43 22% ` Robert Dewar
1994-10-05 3:39 Gnat Ada 9X - What sort of PC does it need??? tmoran
1994-10-05 11:50 21% ` Robert Dewar
1994-10-05 5:19 Syntax question Adrian Cho
1994-10-05 11:52 22% ` Robert Dewar
1994-10-05 18:42 GNAT pragma IMPORT and type conversions mcnett michael david
1994-10-05 21:14 21% ` Robert Dewar
1994-10-05 21:15 22% ` Robert Dewar
[not found] <371a3p$nos@gnat.cs.nyu.edu>
[not found] ` <1994Oct7.153254.29848@swlvx2.msd.ray.com>
[not found] ` <374uke$8mo@delphi.cs.ucla.edu>
[not found] ` <37bno4$ko4@gnat.cs.nyu.edu>
1994-10-11 13:00 ` Easily-Read C++? Robert Firth
1994-10-11 13:44 ` Casper H.S. Dik
1994-10-11 19:03 17% ` Robert Dewar
1994-10-11 18:52 18% ` Robert Dewar
[not found] ` <37eej8$6ie@siberia.gatech.edu>
1994-10-11 18:55 21% ` Robert Dewar
1994-10-12 13:35 ` John M. Mills
1994-10-12 19:48 18% ` Robert Dewar
[not found] <Cx94z7.Jn7@world.std.com>
[not found] ` <37ab0v$n82@newsbf01.news.aol.com>
[not found] ` <37bph1$naq@gnat.cs.nyu.edu>
1994-10-11 17:01 ` ARPA still undermining Ada Kevin Priest~
1994-10-11 19:49 22% ` Robert Dewar
1994-10-12 9:43 ` Tarjei Jensen
1994-10-12 13:08 16% ` Robert Dewar
[not found] ` <37gnv0$j5u@cmcl2.nyu.edu>
1994-10-17 14:25 ` Michael Feldman
1994-10-17 19:14 ` Jay Martin
1994-10-18 16:35 22% ` Robert Dewar
1994-10-12 19:13 ` Mark C. Chu-Carroll
1994-10-13 3:55 22% ` Robert Dewar
1994-10-17 14:35 ` Michael Feldman
1994-10-18 16:39 22% ` Robert Dewar
1994-10-11 20:48 Magnavox consultant trashes Ada tools in IEEE Computer Gregory Aharonian
1994-10-17 23:48 ` TOM
1994-10-19 2:07 ` Bob Duff
1994-10-19 13:31 22% ` Robert Dewar
1994-10-12 14:28 Ada Deutschland Ted Dennison
1994-10-13 8:05 ` Matthias Suilmann
1994-10-13 12:29 20% ` Robert Dewar
1994-10-13 7:44 Interfacing Ada to Unix/execl var. arg. list function? Dale Stanbrough
1994-10-13 12:22 15% ` Robert Dewar
1994-10-13 17:37 ` Mark A Biggar
1994-10-13 18:46 22% ` Robert Dewar
[not found] <CxAypC.CpH@actrix.gen.nz>
[not found] ` <377864$tv@Starbase.NeoSoft.COM>
[not found] ` <CxEuJv.B2L@ois.com>
[not found] ` <379632$9to@starbase.neosoft.com>
1994-10-13 11:42 ` Eiffel for DoD development? Robert M. Wilkinson
1994-10-13 14:28 21% ` Robert Dewar
1994-10-13 14:40 Is Ada the future? [was: Is C++ the future?] John Volan
1994-10-13 21:14 ` Matt Kennel
1994-10-14 0:37 22% ` Robert Dewar
[not found] <1994Oct7.181343.9070@sei.cmu.edu>
1994-10-12 18:35 ` Ada NEWS -- Week Ending 7 Oct 1994 Lance Kibblewhite
1994-10-13 3:32 ` Tucker Taft
1994-10-13 15:23 ` Dave McAllister
1994-10-13 19:55 22% ` Robert Dewar
[not found] <hbakerCxFK2p.4wp@netcom.com>
[not found] ` <1994Oct11.161048.1058@nosc.mil>
1994-10-11 20:06 ` Modulus and Remainder operations (Was Re: Help with a bit of C code) Norman H. Cohen
1994-10-13 1:51 ` Henry G. Baker
1994-10-13 8:27 ` Magnus Kempe
1994-10-13 12:30 22% ` Robert Dewar
1994-10-14 15:45 ` Henry G. Baker
1994-10-14 22:11 22% ` Robert Dewar
1994-10-13 18:13 ` Charles H. Sampson
1994-10-13 20:59 16% ` Robert Dewar
1994-10-14 3:33 HELP Chiu Bo (Hung Chiu Hung)
1994-10-14 13:21 22% ` HELP Robert Dewar
1994-10-15 14:56 ` HELP Bob Duff
1994-10-18 16:31 21% ` HELP Robert Dewar
1994-10-14 16:44 GNAT for Windows NT Brian Wentz
1994-10-14 18:28 22% ` Robert Dewar
1994-10-14 17:34 Where's Waldo? Where's Ada? Gregory Aharonian
1994-10-14 21:52 22% ` Robert Dewar
1994-10-15 21:57 Variable Args, Ada Paul Santa Maria
1994-10-18 16:44 20% ` Robert Dewar
1994-10-17 13:26 Interface GNAT with Oracle Jeff Etrick
1994-10-19 13:23 21% ` Robert Dewar
1994-10-18 6:39 ADA compiler on Mac? Yingwu Fang
1994-10-18 13:58 ` Arthur Evans Jr
1994-10-18 17:58 ` Beth Walker
1994-10-19 0:16 22% ` Robert Dewar
1994-10-18 19:06 22% ` Robert Dewar
1994-10-19 13:12 41% ` Arthur Evans Jr
1994-10-18 10:20 C-Ada Import of struct's -- Help Bob Wells #402
1994-10-18 9:58 ` David Emery
1994-10-18 19:11 22% ` Robert Dewar
1994-10-19 14:32 GNAT and Command Line Arguments Jim Rogers
1994-10-19 18:58 21% ` Robert Dewar
1994-10-19 19:37 In-Circuit Emulators with Ada support David Steele
1994-10-20 5:41 22% ` Robert Dewar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox