* Re: Paradise-3.4 ported to GNAT/Ada9X?
@ 1994-10-24 4:50 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-24 4:50 UTC (permalink / raw)
Laurence, please be sure to send GNAT trouble reports to
gnat-report@cs.nyu.edu
(I post this as a general reminder!!!)
^ permalink raw reply [relevance 22%]
* Re: Private/incomplete type differences...?
[not found] ` <Cy6K8v.8xH@inmet.camb.inmet.com>
@ 1994-10-24 15:45 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-24 15:45 UTC (permalink / raw)
Although GNAT was indeed right in this situation, everyone should be aware
that you can't trust GNAT 100% as an arbiter of language semantics. In
particular, there are still missing checks in GNAT (for example we are
not doing accessibility checks at all yet).
We are working away to complete the checking, and by all means report missing
checks as bugs, but it's worth reminding people that GNAT ain't complete yet!
^ permalink raw reply [relevance 22%]
* Re: compilation time [was Re: Magnavox consult
@ 1994-10-25 22:23 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-25 22:23 UTC (permalink / raw)
one million lines of C++ compiling in 6 hours on a 486.
That sounds reasonable, GNAT will generally compile about the same speed
as g++. On my thinkpad, a 75MHz 486 with no 2nd-level cache, it takes
about 50 minutes to compile the GNAT sources, which are about 150,000
lines of Ada.
^ permalink raw reply [relevance 22%]
* Re: compilation time [was Re: Magnavox consultant]
@ 1994-10-25 23:33 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-25 23:33 UTC (permalink / raw)
"making the unit a child allows it to reference the facilities ..
without using a with clause"
true, so what, this doesn't mean that it compiles faster (in fact child
units tend to increase compile time if you are not careful, because they
do implicit with's that you might not always need).
^ permalink raw reply [relevance 22%]
* Re: Generic Child Packages
@ 1994-10-26 0:05 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-26 0:05 UTC (permalink / raw)
instantiation of library units works fine in GNAT, so I don't quite
know what that comment was about. they are of course separate
compilation units, and so must be submitted on their own in a file
if you are not using gnatchop.
^ permalink raw reply [relevance 22%]
* Re: Flags in Ada?
@ 1994-10-26 11:01 20% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-26 11:01 UTC (permalink / raw)
The natural way of representing flags, i.e. words in which individual bits
have names and can be manipulated is to use pragma pack (some implementations
may require you to use a record representation clause, but this should not
be necessary, and is a weakness in the implementation).
type Flag_Byte is record
Flag1 : Boolean;
...
Flag8 : Boolean;
end record;
for Flag_Byte'Size use 8;
pragma Pack (Flag_Byte);
That should work fine (certainly works fine on GNAT, where it is equivalent
to the obviously corresponding C declaration with bit fields of length 1)
If sometimes you need to regard this as an integer, then you need to use
unchecked conversion -- quite an appropriate use of unchecked conversion,
since you are asking to view the same data as two totally different types.
^ permalink raw reply [relevance 20%]
* Re: Flags in Ada?
@ 1994-10-26 14:33 21% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-26 14:33 UTC (permalink / raw)
As I noted in a previous message, pragma pack should work just fine on
records, it is NOT necessary to give record representation clauses unless
they are needed to match an external specification. In Ada 9X in particular,
one would assume that even in the latter case, the use of:
pragma COnvention (C, rectype);
should be adequate to ensure a match up with the C type. In GNAT, convention
C is the default (i.e. for datatypes that match, convention Ada and
convention C are identical), so it works even in the absnece of this
pragma.
^ permalink raw reply [relevance 21%]
* Re: Interfaces.Fortran
@ 1994-10-26 22:28 20% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-10-26 22:28 UTC (permalink / raw)
First, the usual reminder, please at least copy questions about GNAT to
gnat-report if you want them seen and answered by members of the devlopment
team!
Second, pragma interface FOrtran is not implemented, but are you sure you
need it! on most GCC targets it won't have any effect anyway.
Third, interfaces.fortran is implemented, though untested, but it is
basically unnecessary in the GNAT environment on most targets.
One thing to understand about the interfaces packages is that they are
basically there to bridge the gap between language xyz data structures
and Ada data structures. Most of the time, in the GCC environment, no
such bridge is needed.
The best thing would be to send a message to gnat-report saying exactly
what you are interested in doing.
^ permalink raw reply [relevance 20%]
* Re: Lines of documentation per LOC
@ 1994-10-26 22:30 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-26 22:30 UTC (permalink / raw)
what possible bizarre thinking leads to the conclusion that COBOL requires
ten times the density of comments as Ada for simple sequential
algorithms ...
^ permalink raw reply [relevance 22%]
* Re: Flags in Ada?
@ 1994-10-26 22:32 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-26 22:32 UTC (permalink / raw)
well to me Dave's approach seems overkill
I really don't see the objection to a packed record. OK, some implementations
are deficient and don't implement this feature properly, but that's not
Ada's fault -- insist on compilers that have this feature if you need it,
it's required by the language definition.
^ permalink raw reply [relevance 22%]
* Re: Flags in Ada?
@ 1994-10-27 13:29 17% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-27 13:29 UTC (permalink / raw)
That's quite right, C does NOT specify how the bits are layed out. It lacks
anything equivalent to record rep clauses, and this can often be a real pain
when interfacing to external hardware. The bit fields of C correspond most
closely to Ada in which you have given the size of each component and then
you say pragma Pack for the record. There is no guarantee here either of
any specific ordering or layout, although simple cases, like 8 booleans in
a byte, should certainly work, but the ordering of the fields will still be
indeterminate.
What is true is that if you use pragma Convention (C,..) on such a type in
Ada 9X, then this packed record should be layed out the same way that C
would lay it out, whatever that is, and for some applications it is this
correspondence with the way some other language does things that is important,
not the specific layout. As I noted before, in GNAT, Ada and C by default
share the same convention for data layout, so pragma Converion (C, ...)
would do nothing.
Of course if you *do* need to specify the exact layout, then you are in
much better shape in Ada, because of the record representation clause.
The Bit_Order capability of Ada 9X further adds to the degree of control
that is the hands of an Ada programmer. This is one of the respects in
which people who make the common assumption that C is somehow inherently
better than Ada for low level systems stuff are quite wrong, in this
particular area, Ada has much stronger tools than C. Of course you need
a decent Ada compiler that implements all these tools correctly, and
in the past, there have been some legitimate complaints in this area, but
the cure is to insist on better implementations, not to complain about
non-existent shortcomings in the language itself.
^ permalink raw reply [relevance 17%]
* Re: Flags in Ada?
@ 1994-10-27 13:47 21% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-10-27 13:47 UTC (permalink / raw)
I certainly agree that normally a record is a better representation of a
set of heterogenous flags. The justifications for using an array are to
take advantage of the boolean array operators, if the flags are really
homogenous, or if indexing will be useful (again implying homogenous
flags).
Note that in Ada 9X, yet a third possibility is to use unsigned (modular)
numbers, which also have logical operations defined, with constant values
for the bits. This of course is even more low-level (and C-like, although
in C, bit specs are being more widely used these days), but may be
appropriate for algorithms where arithmetic and logical operations are
intermixed in wierd ways.
^ permalink raw reply [relevance 21%]
* Re: Flags in Ada?
@ 1994-10-27 23:00 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-27 23:00 UTC (permalink / raw)
I think it is quite wrong for a compiler to initialize or otherwwise pester
values with address clauses as a result of calling type support subprorams.
^ permalink raw reply [relevance 22%]
* Re: Ada replacements for DOS I/O
@ 1994-10-27 23:04 20% ` Robert Dewar
1 sibling, 1 reply; 200+ results
From: Robert Dewar @ 1994-10-27 23:04 UTC (permalink / raw)
The failure to do concurrent I/O is certainly not a bug (nothing in the
Ada standard requires, or even implies, that I/O done from one task is
concurrent with the execution of other tasks).
Furthermore, using DOS I/O, such concurrency is very hard to achieve, since
DOS is basically single threaded, and any processing that continued during
I/O would have to promise not to use ANY DOS calls at all explicit or
implicit, not so easy to arrange, and even with this restriction, it is
very difficult to arrange for this kind of concurrent I/O under DOS>
If you need concurrent I/O, put an operating system on your PC (many
choices including OS/2, NT, Solaris, SCO Unix, Linux, BSD386, Lynx,
Nextstep), and then shop for a compiler that definitely supports the
concurrency that you need.
You burned yourself on this one by making a totally unwarranted assumption!
^ permalink raw reply [relevance 20%]
* Re: Initialization Params for Controlled Types
@ 1994-10-27 23:06 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-27 23:06 UTC (permalink / raw)
to pass parameters to initialization routines, use discriminants, works
nicely, that's how we do storage pools in GNAT.
^ permalink raw reply [relevance 22%]
* Re: Easily-Read C++?
@ 1994-10-27 23:09 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-27 23:09 UTC (permalink / raw)
Bob Duff guesses that if you store virtual origins and suppress checks you
do not need to pass bounds around.
It's tricky, since we intend in GNAT to use virtual origins at some point
(it is exactly why we use "fat" pointers for unconstrained types), we have
looked into this issue in some detail.
The trouble is that there are a number of subsidiary language features
that will require the bounds ('Address, 'Access, passing array to a
foreign routine ...)
^ permalink raw reply [relevance 21%]
* Re: Flags in Ada?
@ 1994-10-28 3:51 20% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-28 3:51 UTC (permalink / raw)
"you are asking it [GNAT] to use the GNU C [conventions] .."
True, but an important part of the GCC design is that it tries to stay as
close as possible to system standards, and one of the requirements that is
aimed at is smooth interoperability with the manufacturers C compiler if
there is one, so that programs can be built in GNU C using libraries
compiled with the manufacturers C compiler.
Now in some environments like the PC, there is more than one C compiler in
use, but there is less variation than you might think even here in data
layouts, because everyone is interested in interoperability.
Certainly on most targets you will find that the data layouts used by GNAT
correspond not only to GNU C, but also to other C compilers on the target.
This isn't guaranteed, just something that is aimed at, and nearly always
achieved.
^ permalink raw reply [relevance 20%]
* Re: Flags in Ada?
@ 1994-10-28 13:43 17% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-10-28 13:43 UTC (permalink / raw)
To follow up tmoran's comment [sorry I can't find the real name in the
message], I absolutely agree that the use of modular types for flag mucking
is usually inappropriate, this is also very much true in C.
Nevertheless there are cases where mixed integer and logical operations
are handy. Consider for instance the following
with text_io; use text_io;
procedure c is
type m is mod 2**8;
x : m := 2#10100000#;
c : natural := 0;
begin
-- count number of bits on in x
while x /= 0 loop
c := c + 1;
x := x and (x - 1);
end loop;
put_line (c'img);
end c;
this is a very efficient algorithm for counting bits (the number of loops
is the number of one bits).
this sort of "trick" is why logical operations have been provided for
modular types. The trouble of course is that once they are available,
they are subject to tremendous abuse, especially from C programmers
used to committing the same kind of abuse in C. Coding standards should
stress that the use of logical operations on modular types should be
very much restricted to specialized cases of this type.
P.S. in case you are wondering, 'Img is a GNAT implementation defined
attribute that can be applied to objects as well as being used with a
subtype name like Image. The output differs only in that the darned blank
is omitted for positive values. Eventually we want to extend Img to handle
various types, e.g. arrays, but this is not done yet.
P.P.S. I am embarrassed to admit that the first time I compiled this program,
I received the following error diagnostic:
12. x := x & (x - 1);
|
>>> invalid operand types for operator "&"
maybe we should special case this message to something like
"and" expected here :-)
^ permalink raw reply [relevance 17%]
* Re: Another One Bites the Dust!
@ 1994-10-28 16:04 17% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-28 16:04 UTC (permalink / raw)
Prototyping an application that is eventually to be written in Ada by
using C or C++ is not uncommon, but it is almost always a bad idea. First
of all, C (or even Ada for that matter) is much too low a level language
for prototyping. If you are serious about prototpying you should be using
appropriate prototyping tools.
Secondly, the phenonemon that was just reported in this thread is a danger,
I don't mean a danger to Ada, I mean a danger to the customer. The fact
that something works fine is just NOT GOOD ENOUGH. You would think that
people would realize this by now, but somehow the lesson never seems to
sink in.
The fact that something works gives no indication whatsoever of the quality
of the code, or its maintainability or long term reliability, or of the
life cycle costs that will be incurred in maintaining it.
Now of course Ada does not *guarantee* an improvement in these areas, but
it helps, and one certainly assumes that the reason that Ada is spec'ed (in
an environment where the choice exists) is that a judgment has been made that
these factors are important. It is probably also true in many environments
that with Ada it is easier than C to get a program working in the first place,
but that's not usually the primary justification for the use of Ada.
So it seems quite short sighted to choose Ada, and then be seduced by
"but it's working fine now" observations.
Of course if circumstances have changed to affect the validity of the
original judgment to use Ada, that's fair enough. FOr example, if Ada
was sold on the basis "you'll never have a chance of getting it working
in C", then clearly the observation is significant, but I certainly hope
that Ada is NOT sold on such a transparently bogus basis, it is obviously
*possible* to get anything working in any language, even in assembler for
that matter.
^ permalink raw reply [relevance 17%]
* Re: Access type representations.
@ 1994-10-28 16:52 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-28 16:52 UTC (permalink / raw)
In addition to Tucker's list of non-pointer representations of access types,
consider also the GNAT representation for pointers to unconstrained types.
These are two words long, one word points to the template containing the
bounds, and the other word points to the data of the array. Eventually we
expect to change this second word so that it points to the virtual origin
of the array, instead of the actual origin, thus avoiding the need to
subtract lower bounds when indexing into the array, but we have not don
e this yet.
^ permalink raw reply [relevance 21%]
* Re: Flags in Ada?
@ 1994-10-30 13:31 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-30 13:31 UTC (permalink / raw)
It is true that it is a bit awkward to define bit strings for the record
representation case. Yes, I know that a nice named notation is often
better anyway, but if you are just copying down bit strings it is sometimes
useful to spell them that way.
Note that if you use a packed array, then you can (with appropriate
declarations), use constants that look like
"01000101"
which is quite nice.
^ permalink raw reply [relevance 22%]
* Re: Elaboration
@ 1994-10-30 13:39 19% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-30 13:39 UTC (permalink / raw)
It is an unfortunate fact that in many implementations of Ada, pragma
Inline does indeed create dependencies of this nature, and can lead to
circular dependencies. Of course compilers are not *required* to introduce
these dependencies.
Using the source library approach of GNAT, you can never get circular
dependencies from pragma Inline, since the only dependencies are from
objects to sources, there are no inter-unit dependencies, or order of
compilation requirements for pragma Inline to work.
I believe that the Telesoft compiler (as opposed to the Alsys compiler) could
also achieve this kind of freedom using the back end optimizer feature that
allowed a number of units to be optimized to gether (of course this approach
gets a bit marginal for really large programs, but it has advantages beyond
simply handling inline "correctly")
SUbunits in particular introduce situations in which inline simply doesn't
work "right" in some Ada implementations. For example, if the body of
a subunit provides the body for an inlined function, the parent will not
be able to inline the function, since it must be compiled before its
subunits.
^ permalink raw reply [relevance 19%]
* Re: Say it isn't so! (Formerly: Ada replacements for DOS I/O)
@ 1994-10-30 15:31 16% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-30 15:31 UTC (permalink / raw)
THe important thing to realize is that the Ada language has nothing to
say about whether I/O operations allow other tasks to proceed, nor could
it, since this is a highly operating systems dependent feature. In some
operating systems (e.g. DOS) it is close to impossible to do overlapping.
In a Unix without threads, it is also difficult.
In a Unix with threads, you cannot assume that Ada tasks are mapped to
different threads. If they are, then almost certainly I/O is overlapped.
THe bottom line here is that you need to ask specific questions about
your implementation before making assumptions that are unwarranted. If
you require overlap, then make sure that your implementation supports it.
Calling it appalling or a bug, or whatever is really besides the point. THere
are many implementation dependent features in Ada (or in C or Fortran for
that matter), and one of the jobs of any programmer in any language is to
make sure that the compiler you are using supports the features that you
required.
Note that even in DOS, there are *some* cases where overlap can be achieved.
FOr example, it is definitely possible and desirable (though not required!)
to allow overlap of tasks with keyboard I/O, but disk I/O is pretty much
a lost cause.
Going back to the threads issue, it is very important for you to know
whether you need your Ada tasks mapped to threads, and if so, to insist
on this mapping. Typically mapping Ada tasks to threads introduces a lot
of extra overhead (light weight threads in most Unices aren't!) so a vendor
may assume that high performance on tasking is more important than this
mapping, and that decision may be right, it all depends on expectations
and planned usage.
In GNAT, we base our tasking implementation on posix threads. On a system,
like SunOS, which has no threads, we simulate the threads. This means that
we expect to take advantage of multiple threads if the operating system
provides them, and the implementation of GNAT tasking on the SGI does map
to separate threads.
^ permalink raw reply [relevance 16%]
* Re: Access type representations.
@ 1994-10-30 16:02 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-30 16:02 UTC (permalink / raw)
Note also that in Ada 9X, for a function that is pragma Interfaced C,
parameters of type Char_Array are required to be passed by passing the
address of the first element.
Note that GNAT does not yet do this correctly (it's on the list!), and in
fact our plan is that for any function that has convention C, we will
pass unconstrained arrays by simply passing the address of the first
element.
It is of course possible to use pragma Interface (Ada, .. and still write
the body in C, and then the C function must know exactly how Ada passes
unconstrained parameters.
^ permalink raw reply [relevance 21%]
* Re: Interfaces.Fortran
@ 1994-10-30 17:19 18% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-30 17:19 UTC (permalink / raw)
Well sure, it would be neater to say pragma Interface (Fortran, and we will
certainly put that in soon, but it probably has the same effect as
pragma Interface (C, so it's an elegance issue, not a functoinality issue).
Now of course pragma Convention (Fortran, arr), where arr is a multi
dimensional array is more significant, because that causes proper column
wise storage. We don't have that in GNAT et, but definitely plan to
implement it.
Finally pragma export is indeed useful, and is definitely high on our
priority list. The valuable feature is the ability to specify link names.
Right now, all library entities in GNAT are by default exported with their
default names (all lower case with periods replaced by __ (double underline).
From C you can of course use these names directly, not very elegant, but
it certainly works (we use this extensively in GNAT, writing typically)
#define Enter_Name sem_util__enter_name
so that we can from then on use the "proper" name in the C code, but it
would certainly be nicer to be able to give a clean link name, and we
definitely have plans to implement this!
Note that the version of GNAT about to be released *does* finally have
pragma Import for variables, which will be useful.
So I don't know quite what you were asking me if I was sure about, but I
hope the above answers your questions.
^ permalink raw reply [relevance 18%]
* Re: SOLVED! Decoupled Mutual Recursion Challenger
@ 1994-10-31 13:17 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-10-31 13:17 UTC (permalink / raw)
To clarify RIchard's remarks. Now that the entire GCC system, with all its
front ends, is getting larger and larger, the distribution setup is being
changed so that you are not forced to download the entire set of front ends.
This doesn't mean that GNAT and the other front ends will not be distributed
"with GCC", it just means that you decide which pieces of the system to
pick up when you get GCC, but it will still be the case that GNAT will
eventually be available by the normal GCC distribution paths.
^ permalink raw reply [relevance 21%]
* Re: Ada replacements for DOS I/O
@ 1994-10-31 13:21 22% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-10-31 13:21 UTC (permalink / raw)
Of course simultaneous text_io from separate tasks to the same file (e.g.
standard output) is pretty hard to define anyway (at what level does the
output get interleaved - lines, text_io calls, characters, pixels?)
^ permalink raw reply [relevance 22%]
* Re: Interfaces.Ada
@ 1994-11-03 11:15 21% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-03 11:15 UTC (permalink / raw)
"Fortran generally requires parameters to be passed by reference"
a common myth, but one that has never been true, not even array parameters
are required to be passed by reference in Fortran.
In fact the Ada permission to pass composites either by copy or by
reference is conciously copied from the Fortran standard!
Back to GNAT and Fortran. The only piece of functionality that I see
missing is the columnwise arrays (which has nothing to do with either
pragma Import, or with Interfaces.Fortran, but rather with pragma
Convention applied to an array.
^ permalink raw reply [relevance 21%]
* Re: Interfaces.Ada
@ 1994-11-03 11:18 20% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-03 11:18 UTC (permalink / raw)
It is actually the columnwise choice in Fortran that is peculiar. In most
languages it doesn't matter how arrays are stored (you can't normally
tell), and rowwise is somewhat the more natural choice for ENglish speakers
(note how you are reading rows of this message and not columns).
Why Fortran chose column-wise I don't know, but the choice of using
row-wise is well established (all Algol compilers I know of used row
wise), and basically we just have another one of those incompatiilities
which is a nuisance.
At this stage, obviously you can't be compatible with everyone automatically,
but the pragma Convention (Fortran seems a nice approach in Ada 9X (it was
actually my idea to put it in in this general form, so I'm of course biased
in liking the way this is done :-)
^ permalink raw reply [relevance 20%]
* Re: Ada replacements for DOS I/O
@ 1994-11-03 11:23 20% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-11-03 11:23 UTC (permalink / raw)
Mark says:
"Yes, but lets be clear what burned him. Not Alsys Ada, but making
assumptions about MS-DOS's capabilities!"
no, that's not really right. even if you are using a wonderful multi-threaded
operating system with fully overlapped I/O, you cannot assume that an Ada
compiler will give access to this capability. THere is no requirement for
how Ada tasks map to an operating system, this is an implementation
dependent choice.
Even with an operating system with multiple-threads, it may make perfectly
good sense to map all Ada tasks to a single thread if tasking performance
is more important than I/O overlap.
So the moral is, don't make *any* assumptions about how Ada tasks will map
to an OS, ASK!
^ permalink raw reply [relevance 20%]
* Re: Flags in Ada?
@ 1994-11-03 11:26 22% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-03 11:26 UTC (permalink / raw)
Regarding the choice of our name (Img) [and norman's nice suggestion of mage]
the reason we chose Img was because we thought there was a rule in Ada
requiring attribute names to be abbrevaitions (Succ, Pred, Min, Max, ...)
:-) :-)
^ permalink raw reply [relevance 22%]
* Re: Type System.ADDRESS
@ 1994-11-03 11:30 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-03 11:30 UTC (permalink / raw)
Bob, what do you mean by implementing Address as static? this is a use
of the term static that does not seem to correspond to its technical
meaning in Ada, and I just don't understand what you mean. Can you give
a specific example of the problems you are having.
It is certainly legitimate to implement Address as a static subtype, but
I don't thing this is what you are talking about!
^ permalink raw reply [relevance 22%]
* Re: Type System.ADDRESS
@ 1994-11-03 11:31 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-03 11:31 UTC (permalink / raw)
" Any assignments to type System.Address require a static expression."
clearly an unwarrented and incorrect assumption. I am surprised that a
compiler can validate with this mistake.
^ permalink raw reply [relevance 22%]
* Re: DOS GNAT 1.83 returns 'unknown file type' on compilation
@ 1994-11-03 11:34 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-03 11:34 UTC (permalink / raw)
Roger, I hope you sent your installation question to gnat-report@cs.
It is *particularly* the case that those on the GNAT team most likely
to be able to answer installation questions do not read CLA!
^ permalink raw reply [relevance 22%]
* Re: Another One Bites the Dust!
@ 1994-11-03 11:36 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-03 11:36 UTC (permalink / raw)
well the "bloody obvious" sometimes escapes people, and apparently continues
to do so:
NO AMOUNT OF TESTING CAN GUARANTEE MAINTAINABILITY
Indeed, I trust that this *is* BO!
^ permalink raw reply [relevance 22%]
* Re: Ada replacements for DOS I/O
@ 1994-11-03 23:05 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-03 23:05 UTC (permalink / raw)
The limitation in DOS on simultaneous I/O has nothing to do with device
drivers, it comes from the fact that the Int 21h handler is single
threaded!
^ permalink raw reply [relevance 22%]
* Re: Flags in Ada?
@ 1994-11-03 23:08 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-03 23:08 UTC (permalink / raw)
We have lots of implementation dependent attributes and pragmas, and yes
it is true that they compromise protability. We are planning to have
them controlled by the -pedantic GCC switch which would make them
unavailable, thus answering Mats (quite legitimate) concern.
^ permalink raw reply [relevance 22%]
* Re: Paige's How To Get An Automatic Ada Waiver memo
@ 1994-11-03 23:10 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-03 23:10 UTC (permalink / raw)
Programs written in Dbase are just that, programs written in Dbase. The
fact that the Dbase compiler is COTS is totally irrelevant. If someone
let's someone less get away with this, the party of the first part has
been bamboozled by the part of the second part.
Now of course if you can make an appropriate argument that the program
you are writing is more appropriately written in Dbase than Ada, fine,
but that's the argument that has to be made, the COTS issue is irrelevant.
^ permalink raw reply [relevance 21%]
* Re: Ada replacements for DOS I/O
@ 1994-11-05 5:37 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-05 5:37 UTC (permalink / raw)
I don't see where chapter 14 is wriotten to require proper interleaving
of characters ???
^ permalink raw reply [relevance 22%]
* Re: WE NEED A GOOD Ada SORT PACKAGE!
@ 1994-11-05 5:43 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-05 5:43 UTC (permalink / raw)
Jahn, the idea of doing quicksort directly on a disk gives me a headache
just thinking about the poor disk arm!
no, you definitely can't do this if you are interested in efficiency,
even on disk files you definitely need some multi-phase merge sort.
For Realia-COBOL, I implemented the disk sort with a 64 way polyphase
merge, and it seems to be the fastest external sort around, or at least
was at the time I was paying attention to COBOL!
^ permalink raw reply [relevance 21%]
* Re: Ada replacements for DOS I/O
@ 1994-11-06 21:03 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-06 21:03 UTC (permalink / raw)
I think I have posted this before, but since it is asked again, here goes.
Implementation of tasking in GNAT. The Tasking is based on a low level
interface for which we currently have posix threads and OS/2 threads
implementations (the latter is in final testing before being released).
THe threads implementation can map either to read pthreads, e.g. on the
SGI, or to a pthreads simulator we have for SunOS. The latter is in C,
but is not yet very portable, it really assumes it is on a Sun.
^ permalink raw reply [relevance 21%]
* Re: POSIX and symbolic links ????
@ 1994-11-06 21:04 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-06 21:04 UTC (permalink / raw)
In a way it is a shame if a program *can* detect a symbolic link, because
then it means that symbolic links would not be transparent, and the great
attraction of this facility is precisely the transparency.
^ permalink raw reply [relevance 22%]
* Re: GNAT and AdaSage
@ 1994-11-12 2:12 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-12 2:12 UTC (permalink / raw)
If the objection to "freeware and shareware" is based on a dislike for
low prices for software licenses, then there is nothing much that can
be done (although there is nothing illegal about selling GNAT for high
prices if someone insists on paying :-)
If the objection is based on lack of guaranteed high quality support, then
that's reasonable, if your application requires such support. That's why
support is being made available on an unbundled basis. Right now, ACT,
Ada Core Technologies, is getting into this business, as are some other
companies.
^ permalink raw reply [relevance 21%]
* Re: GNAT-Problem Set_Line(), Set_Col()
@ 1994-11-12 15:49 22% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-12 15:49 UTC (permalink / raw)
Andreas asks about Set_Col not working with a variable.
First, such problems should be addressed to gnat-report
second, we need sources that duplicate the problem or we can't do anything
with such reports
^ permalink raw reply [relevance 22%]
* Re: Systemless use of 'Address.
@ 1994-11-12 20:38 20% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-12 20:38 UTC (permalink / raw)
Actually I don't see why you would expect a "with" of System to be required,
since no entity from system is mentioned, and hence accessibility to
System is not required.
The use of the 'Address attribute in the absence of visibility into System
is certainly a little peculiar. A strict reading of 1815 probably indicates
that there is no requirement for package system to be present, but this is
obviously peculiar, and AI-00043/08-BI-WA addresses this issue by requiring
that the unit using 'Address must depend directly or indirectly on System
(but still does not require an explicit with of system). Ada 9X makes this
rule a clear part of the language.
Note: I stronly recommend having at hand a copy of the Annotated Ada
Reference Manual from Karl Nyberg if you are still using Ada 83. It's well
layed out, and allows you to answer questions like this, complete with
appropriate AI references, easily.
^ permalink raw reply [relevance 20%]
* Re: GNAT-Problem / Please Help !!
@ 1994-11-13 12:41 21% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-13 12:41 UTC (permalink / raw)
GNAT problems should be reported to gnat-report@cs.nyu.edu. Always include
full sources, it is usually impossible for us to deal with problems without
the full sources. FOr example, in this case, Set_Col is certainly not
broken to the extent that is claimed, so it is probably a programming
error, but we can't guess what the error might be without the sources!
Also remember to say what machine and what version you are using (the
latest GNAT BUG box includes this information automatically).
^ permalink raw reply [relevance 21%]
* Re: Installing GNAT 1.83 on DOS
@ 1994-11-15 17:27 19% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-15 17:27 UTC (permalink / raw)
I guess this needs posting pretty frequently!
Please send GNAT trouble reports to gnat-report@cs.nyu.edu.
(since this is one of the directions that is prominent in the readme file,
it's a reasonable guess that people NOT sending trouble reports to that
address who have installation problems probably are seeing results of not
following the installation instructions carefully. Anyway we are happy
to help out but most of the team does not read CLA, or if they do, they
certainly don't try to keep current with it. So send your questions to the
official address please. It's fine as far as I am concerned to post them
here too, but the important thing is to get them to gnat-request.)
Thanks
P.S. we know that the installation procedures for the PC versions are not
anywhere as smooth as they should be, and on our list is to improve these,
but this is not at the top of our list yet, so for the moment, be careful
to follow the directions very carefully!
^ permalink raw reply [relevance 19%]
* Re: Command line package for Alsys Ada Compiler
@ 1994-11-16 13:46 22% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-11-16 13:46 UTC (permalink / raw)
Alsys Ada is of course programmed in Ada, hence they use an Ada compiler
all the time to compile the Ada compiler. I *suppose* it would be possible
to compile Alsys Ada using some other Ada compiler, but I certainly never
saw anyone try it, and I can certainly tell you that in my contacts with
Alsys, everyone was using the Alsys Ada compiler all the time!
Robert
^ permalink raw reply [relevance 22%]
* Re: GNAT-Problem Set_Line(), Set_Col()
@ 1994-11-16 13:48 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-16 13:48 UTC (permalink / raw)
Ah that triggers the memory, yes indeed, we discussed the problem of files
being limited to integer size lines, which on 16-bit machines (e.g. compilers
for DOS) would be an intolerable restriction.
^ permalink raw reply [relevance 22%]
* Re: Why don't large companies use Ada?
@ 1994-11-16 23:47 18% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-16 23:47 UTC (permalink / raw)
Why do universities teach Ada?
presumably because they feel it is a good vehicle for teaching basic
programming and software engineering concepts. Note that this has nothing
to do with whether it is or is not used. For years, Pascal has been taught
in universities because it is an effective teaching tool, not because it
is widely used in real programming projects.
The argument that language X should be taught because X is used widely is
what kept US universities teaching FOrtran when the rest of the world had
moved on (see the survey in the British Journal of Computing, around 1971).
It is a badly flawed argument which does students tremendous disservice
and one that in the last 20 years has largely been rejected (how many
major universities have used COBOL to teach the beginning course, because
of the quite correct observation that it was -- and probably *still* is, the
most widely used programming language)?
It is a shame to see people use this decrepit line of reasoning to justify
teaching C in beginning courses. I guess part of the reason for this is
that we are now seeing the graduate students who learned C hacking in
universities under the illusion that it is programming in positions as
university professors eager to teach C under the illusion that they are
teaching programming :-)
^ permalink raw reply [relevance 18%]
* Re: Systemless use of 'Address.
@ 1994-11-16 23:50 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-16 23:50 UTC (permalink / raw)
Why on earth should unchecked_access require system? it has nothing to do
with entities declared in system, and its semantics is not system
dependent.
Sure it can be used to construct erroneous programs whose behavior is
implementation dependent, but hey, you can do that with uninitialized
variables, and you don't have to with system to create those!
^ permalink raw reply [relevance 22%]
* Re: SGI inheriting C++ classes ...
@ 1994-11-19 7:12 20% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-11-19 7:12 UTC (permalink / raw)
"Did SGI demonstrate ..."
GNAT supports fully interoperable dispatching and inheritance between GNAT
Ada and C++. FOr example, you can import a C++ class, then extend it on
the Ada side, using dynamic dispatching with it, and then reexport the
extended version back to C++. THe interface is procedurable allowing
customization for all C++ compilers we know about.
SGI has written an automatic binding generator that uses the GNAT features
(consisting of a set of specialized pragmas) to generate Ada bindings from
C++.
The demo at Tri-Ada involved the semi-automatic translation of some 40,000
lines of C++ headers from the inventor toolset. The actual demo was a 200
line main program, driving, via about 30,000 lines of generated CAda
bindings, an existing C++ code to implement the Puck game.
It's all in a quite preliminary stage, and this was definitely a demo, but
GI fully intends to develop this capabality.
P.S. the invenrot demo was completed in a period of 4 days.
^ permalink raw reply [relevance 20%]
* Re: GNAT for Mac?
@ 1994-11-19 7:15 22% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-19 7:15 UTC (permalink / raw)
"GNAT, why is there not a port for the MAC?"
because no one has done one! There is no technical reason why GCC and GNAT
cannot be ported to the Mac. Apple did a version 1 port of GCC, but did not
keep it up. I believe Cygnus may be working on a port of GCC version 2.
^ permalink raw reply [relevance 22%]
* Re: GNAT-Problem / Please Help !!
@ 1994-11-19 7:19 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-19 7:19 UTC (permalink / raw)
Regarding Keith's comment on the error message, that's quite right, we don't
give a helpful error message for an incorrect use of Set_Col.
The reason is that Set_Col is overloaded. If a function is not overloaded,
there is no problem, and we give a nice message, but overloading makes
it tricky.
We disussed specially recognizing the case of varying number of parameters,
which is a special case (which applies to Set_Col) and might be a path
for a better error message.
^ permalink raw reply [relevance 21%]
* Re: Ada Portability... NOT!
@ 1994-11-19 16:55 17% ` Robert Dewar
0 siblings, 2 replies; 200+ results
From: Robert Dewar @ 1994-11-19 16:55 UTC (permalink / raw)
It is probably a reasonable implementation choice to restrict reals to be
on a properly aligned boundary, since it is an annoying amount of fiddling
to deal with unaligned floating-point stuff, and yes, of course most
processors *do* require floating-point values to be aligned. When you use
rep clauses you are definitely wandering into the area of implementation
dependent non-portable constructs (most appropriately, since one of the
functions of rep clauses is to deal with special target dependent
requirements).
There is certainly no *requirement* that an implementation reject these
declarations on a RISC machine, the code generator could generate the
code to fiddle around and copy the value. Is it a good idea to do this
behind the scenes? Not clear. Suppose a user just casually wrote rep
clauses to pack the data in a way that worked fine on one machine but
generated long inefficient sequences of code on another, do you want
to be allowed or stopped? Either answer is possible.
I certainly would never have written the original code, and I certainly
would never have written it expecting it to be portable. Writing portable
code in Ada does not come for free, it requires some consideration of
what is and what is not implementation dependent, and this is especially
true of writing portable code containing rep clauses.
A more portable approach in your particular case is to read the data into
a byte stream (in Ada 9X, use a Storage_Array), and then use unchecked
conversion to convert the data to usable floating-point form.
Isn't that interesting? The above advice says that you can make the code
*more* portable by using unchecked_conversion. Often people have a knee-jerk
reaction to avoid UC in portable code, but that's quite misinformed. Just as
a careful C programmer will use (carefully chosen) cross-type casts to
achieve portability, a careful Ada programmer can use (carefully chosen)
unchecked conversions.
Actually in Ada 9X, this sort of problem is much better handled using
streams in any case.
^ permalink raw reply [relevance 17%]
* Re: Range Check Query
@ 1994-11-19 16:58 20% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-19 16:58 UTC (permalink / raw)
"If the compiler is smart enough [to recognize that a comparison of a value
of limited range with a constant is always False], it should probably warn .."
First, that's not an easy check to do, it certainly doesn't fall out free,
because it requires the generalized notion of the subtype of a result, where
in the language we are only ever interested in the base type for operands
of an operator. Certainly it could be done with a special check.
Second, are you really *sure* that you want this warning. Yes I know you
can suppress warnings, but the trick is to keep warnings useful so that
people don't need to suppress them in normal cases.
I an very dubious that this is a desirable approach
Robert Eachus' analysis of the original question is certainly quite
correct, there is no basis to expect range constraint to be raised
in either situation.
^ permalink raw reply [relevance 20%]
* Re: GNAT for Mac?
@ 1994-11-19 17:07 17% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-19 17:07 UTC (permalink / raw)
Laurent Gasser is spreading a common piece of misinformation when he
incorrectly conjectures that the lack of a MAC port of GCC (and hence
GNAT) is due to the LPF boycott of Apple (which is in any case, as far
as I know, ended).
The one and only reason that there is no version of GCC for GNAT is that
no one has done the port. There is nothing stopping anyone from doing
this port [were the boycott in place, the port would not be included
in the standard FSF distribution, but so what, lots of important ports
of GCC, including for example the popular EMX port for OS/2) are not
distributed by FSF. Of course it's nice to have everything in the main
distribution, but you can't in any case distribute what doesn't exist,
and in this case it is more to the point to worry about how to get the
port to exist, than to worry about how it is distributed when it does
exist!
THe history is that there was a GCC version 1 port for the MAC, done I
think by someone at Apple. But this port ran under MPW, so it was of
limited use.
What is needed is a native port of GCC 2.6.2. As I noted in a previous
message, I believe there is some activity at Cygnus. If you want a port
of GCC there are three things you can do:
1) do it yourself, the most useful, but the most difficult alternative
2) let the folks at Apple know you really want a port
3) let the folks at Cygnus (gumby@cygnus.com) know that you really
want a port.
Note that Cygnus is interested in selling support for GCC, so your
interest is more interesting to them if you are need to use MAC/GCC
or MAC/GNAT for serious work requiring commercial support :-)
^ permalink raw reply [relevance 17%]
* Re: Command line package for Alsys Ada Compiler
@ 1994-11-19 23:34 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-19 23:34 UTC (permalink / raw)
Of course I know that the Alsys compiler has been compiled on other compilers
from time to time to test compatibility, but I was talking about everyday
development, which is in practice done exclusively on Alsys compilers
themselves.
I mistrust the observation about Ada compilers written in Ada and those
written in C, it's too much of a simplification, and also more than one
of the major Ada compilers is written in neither of thee two languages.
^ permalink raw reply [relevance 21%]
* Re: defaults on discriminants
@ 1994-11-20 17:14 19% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-20 17:14 UTC (permalink / raw)
This is such a common question that it should be in the Ada FAQ
When you give a default discriminant, then one method (I actually think it
is the preferred method) of implementation is to allocate the maximum
possible length. Since your discriminant is of type Natural, this clearly
won't work!
GNAT may compile it, but it won't run it, and indeed I consider it a GNAT
bug (on the todo list) that no warning is issued at compile time for this
misuse.
Some compilers, notably Alsys and RR, have at least partially "solved"
this problem by introducing hidden pointers, but this to me is an undesirable
implementation choice.
First, it means there is hidden heap activity, which seems undesirable. In
a language where pointers are explicit, it is generally a good idea if
allocation is also explicit, and certainly for real-time work, hidden anything
is worrisome.
Second, it is not easy to do uniformly. Alsys ends up introducing arbitrary
restrictions on the composition of such types (try making an array of them),
and RR introduces non-contiguous representations, which are legal but
troublesome.
To "solve" the problem yourself, just declare a reasonable maximum length,
and use a subtype representing this length as the subtype of the
discriminant.
^ permalink raw reply [relevance 19%]
* Re: Why don't large companies use Ada?
@ 1994-11-20 17:18 20% ` Robert Dewar
1994-11-20 17:21 20% ` Robert Dewar
2 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-20 17:18 UTC (permalink / raw)
Following Bill's comments on rewriting C++ interfaces (we really *should*
change the title of this thread, it is long ago obsolete, and was never
reasonable, since it presumes a false fact :-)
Indeed, rewrites may be appropriate for important standard interfaces, but
realistically, it is inconceivable to rewrite all interfaces. Tom Quiggle
got the Puck program operating in four days with the reuse approach.
Rewriting Inventor in Ada 9X would be, I would guestimate, a several
person-year project.
One other approach here is to put the energy in at a slightly different
level. Use a tool to generate a thin binding, and then build a thick
binding with the desired abstractions above it. This has the advantage of
presenting a more appropriate interface without rewriting the C++ class
definitions, and may be the appropriate approach in many situations.
^ permalink raw reply [relevance 20%]
* Re: Why don't large companies use Ada?
1994-11-20 17:18 20% ` Robert Dewar
@ 1994-11-20 17:21 20% ` Robert Dewar
2 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-20 17:21 UTC (permalink / raw)
Note also that Bill made his decision to rewrite in Ada 9X long before we
completed or even designed the GNAT C++ interface. It is not possible to
duplicate this interface manually, because among other things, it depends
on GNAT using exactly the same dispatch table structure as C++, which is
something we have only recently achieved.
In addition, neither the C++ interface facilities in GNAT, nor the SGI
binding tool that takes advantage of them is complete, so Tom's experience
is only a hint of what will eventually be achieved.
Nevertheless, I agree with Bill that in some situations it definitely WILL
make sense to rewrite interfaces in Ada 9X.
Indeed, I am much less concerned about bindings to standard interfaces like
CORBA, X, Motif etc than I am about situations like SGI's Inventor. It is
the latter more specialized cases where huge interfaces exist in C and
C++ and it is vital to be able to reuse them.
^ permalink raw reply [relevance 20%]
* Re: Delphi and SGI's GNAT Ada access of C++ class libraries
[not found] <199411200820.IAA02428@stout.entertain.com>
@ 1994-11-21 1:45 21% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-21 1:45 UTC (permalink / raw)
Most peculiar, and a little unfortunate, that Colin James III does not
follow his own advice and wastes his time following comp.lang.ada.
Colin, your post was full of techni9cal misinformation, but I suppose
there is no point in posting details to a newsgroup which you won't
be reading anyway :-)
ANyway, for those interested in knowing about the technical issues of
the GNAT/C++ interface, technical documentation is available by
anonymous ftp from cs.nyu.edu.
^ permalink raw reply [relevance 21%]
* Re: Ada Portability... NOT!
@ 1994-11-21 13:17 20% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-21 13:17 UTC (permalink / raw)
Carlos, you wouldn't believe how many "bad" assignment "cases" I have seen
in Ada code written by various people, but that does not make me decided
that assignments are a bad thing.
Properly handled, unchecked conversion is a powerful and important part of
the Ada language, and is often a critical tool in writing portable code. By
portable code, I mean code that can be ported across architectures.
Typically this involves writing code that is from a formal point of view
entirely implementation dependent, but which, based on rather detailed
knowledge of multiple architectures, which of course few programmers
posess, does in fact work.
It is for example quite possible to defend against endianness differences
using such approaches, but it is by no means easy.
^ permalink raw reply [relevance 20%]
* Re: Delphi and SGI's GNAT Ada access of C++ class libraries
@ 1994-11-22 3:52 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-22 3:52 UTC (permalink / raw)
Object COBOL is not, as far as I know, an ISO standard. The new COBOL
standard, including the OO stuff, is not expected to become an ISO
standard until 1977 at the earliest according to the latest post
in comp.lang.cobol.
Ada is indeed the first object oriented langauge to be standarized by ISO
(any counter claims???)
^ permalink raw reply [relevance 22%]
* Re: Ada Portability... NOT!
@ 1994-11-22 3:53 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-22 3:53 UTC (permalink / raw)
"Whaddya think?"
I think it's an abuse of the semantics of pragma Pack :-)
^ permalink raw reply [relevance 22%]
* Re: Why don't large companies use Ada?
@ 1994-11-22 13:56 15% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-22 13:56 UTC (permalink / raw)
First, I don't think that there is as much disagreement between Bill and
Jean as appears on the surface. Bill is not saying that everything should
be reengineered, and Jean is not saying that nothing should be reengineered.
I do think Bill goes much too far when he says that reuse is for projects
not products. Let's take the SGI Inventor example. If SGI is to succeed in
promoting Ada 9X, they have to provide usable interfaces to their primary
capital advantage, which is a huge library of impressive graphics stuff.
If the Ada enthusiasts inside SGI told management that this entails a lot
of reengineering, it is simply a nail in Ada's coffin in terms of being
accepted as a feasible alternative. SGI needs to be able to provide
productized versions of these interfaces, which are heavily object based,
and require the capbility of extending existing classes, with absolutely
minimal effort. Reuse is *the* key to seeing Ada 9X as a feasible
technology in this environment.
I am not saying that everything can or should be done this way, but the
important point is that in the past we have always had the necessary
tools for doing the kind of reengineering that Bill is talking about, and
there are indeed examples of positive results from this (one reimplementation
of Motif for Ada turned out to be much more reliable and efficient than the
original), but missing was a reasonable technology for reuse.
What is exciting to me is that the combination of
New features in Ada 9X promoting easier interfacing
New features in Ada 9X to interface to (notably the OO stuff)
Technologies for more direct binding to C++ (as implemented in GNAT,
and hopefully similiar or superior approaches will appear in other
Ada 9X compilers)
AUtomatic binding generating tools of the kind demonstrated by SGI
seem to point in the direction of a practical reuse technology for Ada 9X
which was sorely lacking in the Ada 83 case.
This does not mean that I think Bill is going in the wrong direction in
his efforts, on the contrary, I think he is on track to providing some
very powerful, and very comfortable-to-use interfacing to some important
technology. What it *does* mean is that we don't have to depend on such
re-engineering efforts for cases where at least at first it will be
impractical to follow anything other than a reuse path.
Now if Ada 9X becomes so successful that Microsoft, Borland, ... do all
their programming in Ada 9X, then presumably all these wonderful interfaces
will indeed be reengineered in Ada 9X, but till then ... :-) :-)
^ permalink raw reply [relevance 15%]
* Re: SGI inheriting C++ classes ...
@ 1994-11-22 14:24 20% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-22 14:24 UTC (permalink / raw)
Bill, regarding your "no more than 200 calls". You have a very peculiar
idea of what is going on. The bindings are not just a bunch of procedure
calls that are independent and may or may not be used.
For each C++ class that is duplicated exactly on the Ada side, there is
a large body of C++, and hence Ada 9X binding, code that describes the
structure of the class. When you use such a class in Ada 9X, you may not
explicitly be calling all the member functions, but they all have to be
properly declared and understood by the 9X binding, so that the data
structures, including dispatching tables, are layed out right.
Thus a single call, or declaration of an object, in the 9X code, can
very well involve hundreds of lines of interface code, which must be
exactly right for the single call to work right.
^ permalink raw reply [relevance 20%]
* Re: PART/pthreads for GNAT under Linux
@ 1994-11-23 21:56 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-23 21:56 UTC (permalink / raw)
Tasking is not currently available for GNAT running on Linux.
^ permalink raw reply [relevance 22%]
* Re: Why don't large companies use Ada?
@ 1994-11-28 14:00 22% ` Robert Dewar
1994-11-28 14:02 22% ` Robert Dewar
2 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-28 14:00 UTC (permalink / raw)
You can add to Mike's list of "military
"
^ permalink raw reply [relevance 22%]
* Re: Why don't large companies use Ada?
1994-11-28 14:00 22% ` Robert Dewar
@ 1994-11-28 14:02 22% ` Robert Dewar
2 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-28 14:02 UTC (permalink / raw)
Add to Mike's list of "military" inventions: Internet itself, which presumably
most participants in this newsgroup find useful :-)
^ permalink raw reply [relevance 22%]
* Re: Help Wanted
@ 1994-11-28 15:42 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-28 15:42 UTC (permalink / raw)
Well at least this chap is above board in his attempt to use the internet
to do his homework assignments for him :-)
^ permalink raw reply [relevance 22%]
* Re: Interesting OS/2 product for GNAT users....
@ 1994-11-29 0:32 20% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-29 0:32 UTC (permalink / raw)
It is quite possible to install GNAT on an OS/2 FAT partition. There are
a couple of minor glitches in past releases, but they are easily got by.
THe new release should be free of these glitches. We know lots of people
running OS/2 GNAT on a FAT partition.
Of course, in the absence of extra tools, you are stuck with 8 char file
names, and you may well want to use the -o switch of the binder to specify
an alternative name (otherwise the main program will be limited to 6
characters).
To stick to 8-char file names, either keep library unit names short, or use
the -gnatk8 switch to crunch longer names to 8 characters.
^ permalink raw reply [relevance 20%]
* Availability of GNAT version 2.0
@ 1994-11-29 13:17 18% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-29 13:17 UTC (permalink / raw)
"GNAT new version when?"
First, please please send such messages to gnat-report (I don't care if
you copy them to CLA, but if you don't send them to gnat-report, the
reply may be delayed by several days, or simply never be forthcoming,
since not all members of the GNAT team have time to read CLA :-)
Version 2.0 will hopefully be out later this week, we are waiting to
send it out till we have killed some known regressions. If you need
a prerelease version for some specific reason, that can be arranged,
depending on the reason [normally we only make the prereleases available
to those who are working closely with us reporting bugs etc. since it is
not worth while for most users to spend time installing prereleases
which change every day when the final release is coming out soon.
One thing that is important to let us know is the motivation for asking
a question like this. If it is just that you are enthusiastic to get the
latest release and kick the tires, fine, but if you are blocked and eithe
really need, or at least think you really need, the new release ASAP, then
let us know!
Let me take this chance to also comment that when you submit bugs, it is
very helpful if you note to us bugs which are really causing you blocking
problems, as opposed to those that you have run into but can navigate
around. We can often, but by no means always, guess which, so please tell
us. Obviously we try to prioritize bug fixes (and new features) to meet
what people most urgently need.
Robert for the GNAT team.
^ permalink raw reply [relevance 18%]
* Re: Multithreading
@ 1994-11-29 13:19 21% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-29 13:19 UTC (permalink / raw)
No current version of GNAT allows selection of whether or not to use OS
threads, but the design certainly allows the construction of such a runtime,
or more likely selection of runtimes.
FOr example, on the SGI, we use OS threads, but it is probably not THAT
difficult to take the threads emulator we use on SunOS and get it working
on the SGI, and it should be even easier to create this kind of option
for Solaris. But we aren't doing anything along these lines at the moment.
^ permalink raw reply [relevance 21%]
* Re: Ada crosscompiler for a Intel 386 target
@ 1994-11-29 13:22 20% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-29 13:22 UTC (permalink / raw)
Paul Grabow asks
"We are looking for a crosscompiler (including an Ada development
environment) that can create an executable for an Intel 386 processor.
It would be nice if the crosscompiler could run under UNIX (or Linux)
on a 386/486. Sun would be okay, too.
THis is a little confusing because the target environment is not clear
(bear board, DOS, Linux ?....)
But it is worth pointing out that it is quite practical to build versions
of GNAT that cross-compile from any host supporting GCC to any target
supporting GCC (that's quite a lot of possible cross-compilers, well into
the tens of thousands :-)
THe only trick is tasking, depending on whether the target environment
is Posix-threads compliant, you may have to do a fair amount of fiddling
to get tasking working.
^ permalink raw reply [relevance 20%]
* Re: Help with gnat IO
@ 1994-11-29 22:05 18% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-29 22:05 UTC (permalink / raw)
Woodrew, first please read the documentation, which specifically asks
that you send copies of all questions on GNAT to gnat-report@cs.nyu.edu.
Second, if you are reading the July 1980 version of the reference manual,
you qualify as an Ada historian, this is an interim version that was never
finalized, and the final version is different in important respects, so you
had better get a relevant version of the standard. Better still, since you
are obviously running into pretty elementary problems, you will do better
with a good book on Ada, such as the one by John Barnes.
To use integer_io, you must with text_io and then instantiate integer_io
(there will be examples in any Ada text book, follow them). Alternatively
use the string put with Integer'Image(value).
There is no Get_String function (was there really a procedure with that
name in Ada 80??) There are however versions of get that get from a string,
which is presumably what you are looking for. For example:
procedure Get
(From : in String;
Item : out Num;
Last : out Positive);
this is a subprogram inside the generic package Integer_IO.
I posted this just because I thought people would be entertained at the
idea of an Ada beginner somehow getting hold of the July 1980 version of
the RM! Perhaps we should have burnt all the copies :-)
^ permalink raw reply [relevance 18%]
* Re: cross linking packages
@ 1994-11-29 22:07 22% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-11-29 22:07 UTC (permalink / raw)
"The GNAT compiler stumbles into a circular ..."
How about instead
"The GNAT compiler correctly diagnoses an illegal circular dependency"
This is definitely wrong, you have to put both types in the same
package if they have this sort of mutual dependence.
(and now we can rerun the long dialog on mutually recursive types :-)
^ permalink raw reply [relevance 22%]
* Re: GNAT
@ 1994-11-30 23:01 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-30 23:01 UTC (permalink / raw)
eager waiting should be soon rewarded, the new version of GNAT, called
version 2.00 should be released tomorrow if all stays on schedule, and
certainly within a couple of days. This will be the SunOS version, the
others should follow closely behind.
Then on to 2.01 ...
^ permalink raw reply [relevance 22%]
* Re: What is OO (Was Why don't large companies use Ada?)
@ 1994-11-30 23:26 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-11-30 23:26 UTC (permalink / raw)
the notion that inheritance is impossible in Ada 83 is bogus, obviously
you can program inheritance using nested components, it's not as pretty,
and you have to mess to get dispatching, but it's certainly doable.
^ permalink raw reply [relevance 22%]
* Re: Why don't large companies use Ada?
[not found] ` <house.786178243@helios>
@ 1994-12-01 21:02 19% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-12-01 21:02 UTC (permalink / raw)
Ron, you don't need zillions of declarations. if you want to make
an operation unavailable, then just make it abstract.
basically there are only two possibilities for this sort of thing. specificlly
define all the operators you need, or by default define all of them, and then
specifically remove the ones you don't want. Ada 9X allows both approaches.
There are various approaches to more automated approaches to the units
problem, which have been discussed on the net in great detail, but many
of the contributors to this discussion (including me) felt that it was
overkill, and that in practice the basic mechanisms of defining the operators
you need (using one of the above two approaches) is sufficient.
Really the only step you could go further is to specifically add units
support to the language, but for most people that is feature overkill.
IN practice, I find the strong type protection of different integer types
to be of minimal value, strong typing is most important at a higher level
than that, but that's a matter of personal taste.
^ permalink raw reply [relevance 19%]
* Re: Why don't large companies use Ada?
@ 1994-12-01 21:24 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-01 21:24 UTC (permalink / raw)
David, regarding your demand to Ian that he clarify or retract his
silly statement, it's probably a waste of time. People who make statements
like that obviously don't know what they are talking about. It is
particularly interesting that in the programming language field, people
feel free to make technical pronouncements about languages they know
NOTHING about (how many Ada folks have done that to COBOL :-)
^ permalink raw reply [relevance 22%]
* Re: Why don't large companies use Ada?
@ 1994-12-01 22:29 16% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-01 22:29 UTC (permalink / raw)
Gareth's idea that knowing C means that learning C++ is easy, and his
view that Ada is a much more complex language than C++ are laughable, but
the programming language field is one in which people seem happy to say
stupid things about programming lanuages (in all directions) without
knowing anything about the languages they are talking about.
What is for sure is that most students coming out of universities are
woefully unequipped for writing serious, realiable software. THe idea
that knowing how to hack around in C or Basic (or any other language
for that matter) has anything to do with serious software engineering
only goes to show the lack of awareness.
Sometimes I wonder whether, regardless of the language you intend to use,
you would do better to specifically hire people who do *not* know the
language so that they don't bring a load of misconceptions to the table.
Maybe the best thing is if they don't know any languages at all. The
teaching of programming is often so bad that it has definitely overall
negative value.
The arguments that one should use language X because that's what everyone
knows and what systems support most easily etc. is a recipe for using
obsolete technology. For years, Fortran marched on in the US under this
banner.
I am happy to see technical points in comparison of languages, but this
argument is non-technical and in the long run less relevant than people
imagine. Note that the only technical point that Gareth made was that
somehow all the strong typing etc. in Ada would make people's life
harder, which is of course nonsense, and presumably is nonsense borne
of ignorance.
It is amazing how programming languages get characterized by second
hand opinions. For example, looking at the cross-posting of this thread,
how many of out out there don't know COBOL at all, but are sure that it
is extremely verbose and this is one of its disadvantages. Totally false
of course, COBOL programs are often considerably more compact than Pascal
programs doing similar things because of some very nice concise COBOL
grammar. Also of course totally irrelevant, counting the number of characters
on the page is NOT the way to determine the best language (otherwise we
would automatically conclude that a language that disallowed comments
was best :-)
^ permalink raw reply [relevance 16%]
* Re: Why don't large companies use Ada?
@ 1994-12-02 5:25 22% ` Robert Dewar
0 siblings, 2 replies; 200+ results
From: Robert Dewar @ 1994-12-02 5:25 UTC (permalink / raw)
Note that one significant reason that PL/1 failed was the very poor initial
implementations that IBM produced early on, leading for example to the
rather disastrous reversal of the Sears commitment and their reversion
to COBOL, which had nothing to do with the DoD or procurement as I remember!
^ permalink raw reply [relevance 22%]
* Re: Why don't large companies use Ada?
@ 1994-12-02 5:29 22% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-02 5:29 UTC (permalink / raw)
People are furiously cross-posting this thread, and many of the messages
are quite inappropriate outside comp.lang.ada. Please be careful,
inappropriate cross-posting quite understandably antagonizes people.
^ permalink raw reply [relevance 22%]
* Re: s-algol
@ 1994-12-02 14:09 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-02 14:09 UTC (permalink / raw)
anyone who has trouble adjusting from one language to another and finds that
an impediment to entering the commercial marketplace shouldn't (i.e
should not enter that market place), since they are clearly unqualified.
^ permalink raw reply [relevance 22%]
* Re: HELP: GNAT for HP 9000/755.
@ 1994-12-03 2:57 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-03 2:57 UTC (permalink / raw)
It is hopeless to try to build GNAT 1.83 from 1.79. THe only thing we
guarantee is that version N+1 can be built from version N. HP binaries
for 1.83 are available. The release after 1.83 is 2.00, the current
release, and 2.00 can be built from 1.83.
^ permalink raw reply [relevance 22%]
* Re: Why don't large companies use Ada?
@ 1994-12-05 22:57 22% ` Robert Dewar
1 sibling, 1 reply; 200+ results
From: Robert Dewar @ 1994-12-05 22:57 UTC (permalink / raw)
if you are writing PL/1, you use ISUB to swap indices of arrays automatically
^ permalink raw reply [relevance 22%]
* Re: Why don't large companies use Ada?
@ 1994-12-05 22:59 22% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-12-05 22:59 UTC (permalink / raw)
Mike, have you REALLY met engineers who walked away from PL/1 because of
the array subscripting order "problem". If so their behavior is peculiar
given the fact that PL/1 allows the specification of subscripting regimes
in full generality using ISUB (swapping indices is a trivial application).
^ permalink raw reply [relevance 22%]
* Re: Running GNAT from the VB3 Shell Command
@ 1994-12-05 23:03 22% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-12-05 23:03 UTC (permalink / raw)
Lots of people have got the DOS version of GNAT to work. I don't know
what problem Lance Kibblewhite
had, as far as I remember he did not contact us.
remember if you have problems, send mail to gnat-report@cs.
^ permalink raw reply [relevance 22%]
* Re: Why don't large companies use Ada?
@ 1994-12-06 13:22 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-06 13:22 UTC (permalink / raw)
Regarding the famous DO loop bug (the Venus probe I think if I remember right)
there is a nice addition to this story.
IBM issued an APAR against Fortran IV under IBSYS on the 7094 that said
something like:
DO 10 I = 1.5
is misclassified and treated as an assignment statement. This will be
corrected in a fututure release.
Needsless to say, this was NOT corrected in a future release, and I would
guess that the APAR is still open :-)
^ permalink raw reply [relevance 21%]
* cross-posting and selling Ada
@ 1994-12-06 13:31 18% Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-06 13:31 UTC (permalink / raw)
For some time now a thread has been running called "Why large companies
don't use Ada", which has been heavily cross-posted.
Many of the posts are Ada specific, and many are from people supporting
Ada. Yet, we are all sending out a barrage of messages to multiple
newsgroups over and over again emphasizing that large companies don't
use Ada.
I think it would be useful if at least all the posters to CLA would be
careful with this thread. Change both the subject and the cross-list
post to avoid sending out unintentional negative messages and annoying
other newsgroup readers with ireelevant Ada messages.
No one is forcing or asking anyone to support Ada in any way, but it seems
worth taking the effort to avoid sending negative publicity by accident :-)
If readers of C++ newsgroups etc see a long sequence of known Ada people
sending out dozens of messages at least tacitly aggreing to the subject
post, they are bound to assume that it is correct.
Sure it is the case that not many large companies are using Ada, but it
would sure be nice if the subject had read something like
"Why aren't more large companies using Ada"
or
"Why don't more large companies see the benefits of Ada"
or something even more neutral!
Robert Dewar
"Working hard, but according to my records, I seem to have missed my 30%
message quota for CLA nearly every day for the last 1000 days!"
^ permalink raw reply [relevance 18%]
* Re: intermediate results causing constraint errors
@ 1994-12-06 13:40 18% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-12-06 13:40 UTC (permalink / raw)
OK, there are two issues here, and I think Bob is talking about one, and
Richard about the other.
From what I understand of Richard's position, he would like a guarantee
that no intermediate results cause constraint error ever. That seems
quite impractical, since it would result in harmless expressions like
Mid := (hi + lo) / 2
generating calls to runtime multiple precision packages etc. which you
certainly don't want. I just sent Richard a much more detailed discussion
of this point (Richard, feel free to repost that response here if you think
it is useful to do so).
Bob is noting that the optimization rules (the infamous 11.6 section of
the RM (which was briefly 11.7 in 9X, but this section number is so well
known, that people complained, and now it is once more 11.6 again in 9X :-)
allow compilers to avoid giving the constraint error if they give the
"right result".
This of course introduces non-portabilities, but if one insisted that
intermediate results always be checked it would generate annoying extra
code. Consider:
X := A * B / C;
on many machines multiply and divide handle double length results free, so
the check would make things inefficient.
It would be nice if Ada compilers at least had an option to guarantee
that they checked all intermediate results, so you could be sure your
code was portable, although there are still problems with different
base types for integers.
^ permalink raw reply [relevance 18%]
* Re: Reference Counting (was Re: Searching Method for Incremental Garbage Collection)
@ 1994-12-06 14:15 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-06 14:15 UTC (permalink / raw)
CISC instructions like add to memory usually are inefficient, of course in
the context of a CISC machine, they may be no more inefficient than any
other instructions on the machine, but I think you will find that most
machines having add to memory cannot execute this operation any faster
than a modern RISC can get the same effect with a sequence of instructions.
^ permalink raw reply [relevance 22%]
* Re: GNAT (v1.83 and v2.0) and Booch Components
@ 1994-12-06 14:16 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-06 14:16 UTC (permalink / raw)
Dan (Coyne), if you run into GNAT bugs, please send them to us at
gnat-report@cs following the directions in the documentation!
^ permalink raw reply [relevance 22%]
* Re: Elaboration order [was: cross linking packages]
@ 1994-12-06 16:11 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-06 16:11 UTC (permalink / raw)
John's analysis is right, and of course I was talking about specs mutually
with'ing one another, which is illegal, and typically caught at compile time.
^ permalink raw reply [relevance 22%]
* Re: Using procedures
@ 1994-12-07 23:35 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-07 23:35 UTC (permalink / raw)
my comment
doing a student's homework is going too far
(and typically, if the student does not acknowledge the help received,
you are really an unintending participant in education fraud!)
The trick is always to help without actually providing the solution.
I am not sure that the main CLA newsgroup is the right forum for this
in any case, maybe there should be a special subgroup.
^ permalink raw reply [relevance 22%]
* Re: Why don't large companies use Ada?
@ 1994-12-08 4:10 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-08 4:10 UTC (permalink / raw)
Mike, I think you misunderstand ISUB, it does exactly what you want and
was largely intended for that purpose. Yes of course it transposes the
array, that's what swapping subscripts does (logically) to an array!
^ permalink raw reply [relevance 22%]
* Re: Why don't large companies use Ada?
@ 1994-12-08 4:11 22% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-12-08 4:11 UTC (permalink / raw)
As far as I know ISUB was always in PL/1, it may not have been in the
G subset.
^ permalink raw reply [relevance 22%]
* Re: Why don't large companies use Ada?
@ 1994-12-08 10:48 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-08 10:48 UTC (permalink / raw)
"Can someone out there confirm that Alsys
' first compiler was written in PL/1"
No, because it's not true, but there is a germ of truth. Alsys decided
to write in Ada from the very start (they believed in the advantages
of the language, unlike some other vendors who even today are writing
Ada compilers in other languages :-)
That meant they needed a bootstrap path, and the path they used was a
temporary partial subset translator that translated the Ada into PL/1,
so they were using PL/1 not as a source language, but as an intermediate
object language.
^ permalink raw reply [relevance 21%]
* Re: Why don't large companies use Ada?
@ 1994-12-08 10:49 22% ` Robert Dewar
1994-12-08 10:51 22% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-08 10:49 UTC (permalink / raw)
Interesting that PL/1 creates an image of an ISUB'ed array passed to Fortran.
As far as I can see, this is not at all required by the language, it is just
a bit of bad implementation, isn't that right?
^ permalink raw reply [relevance 22%]
* Re: Why don't large companies use Ada?
1994-12-08 10:49 22% ` Robert Dewar
@ 1994-12-08 10:51 22% ` Robert Dewar
1 sibling, 1 reply; 200+ results
From: Robert Dewar @ 1994-12-08 10:51 UTC (permalink / raw)
Keith, the array conversion case is really not a special one. In general
an array conversion may involve a massive and possibly complex copy, and
most compilers will just generate a loop to do the copy, which handles
all possible cases, including the swapping of indices.
^ permalink raw reply [relevance 22%]
* Re: GNAT problem: Hello World
@ 1994-12-08 20:05 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-08 20:05 UTC (permalink / raw)
alwys send messages to gnat-report for help on GNAT. Proibably the error
her is the failure to run cofftoexe (see DJPP documentation). The requirement
for doing this is eliminated in versiuon 2.00 (where GNATBL does this
automatically).
^ permalink raw reply [relevance 22%]
* Re: GNAT Port To WIN or WINNT?
@ 1994-12-09 4:37 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-09 4:37 UTC (permalink / raw)
ports are available at NYU for DOS/Windows, NT, OS/2 and many other
environments as well.
^ permalink raw reply [relevance 22%]
* Re: Why don't large companies use Ada?
@ 1994-12-09 11:49 19% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-09 11:49 UTC (permalink / raw)
Not just EQUIVALENCE, but much more importantly in Fortran you can pass
a two dimensional array to a routine that treats it as a one dimensional
array, and also you can pass a single column (but not a single row) of
a two dimensional array as a one dimensional array. These features are
often used.
Since we have pragma convention in Ada 9X, I don't see much need for
Fortran to muck around.
Interesting note: if you are trying to convert FOrtran code to Ada, and
it does use the column slicing trick, then you are in trouble, or more
accurately, you will have to play low level games with unchecked
conversion of access types, because Ada does not allow slicing of
multi-dimensional arrays.
Note incidentally that the ability in Fortran to pass columns is exactly
what defines the requirement for array mapping in Fortran, whereas in
Ada there are no such semantics, so the array ordering is not specified
by the language (although it is slightly suggested by the form of array
aggregates for multi-dimensional arrays).
^ permalink raw reply [relevance 19%]
* Re: GNAT-Problem '+'-operator with Count
@ 1994-12-09 15:33 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-09 15:33 UTC (permalink / raw)
it is either a bug in GNAT or a bug in your program, and it is impossible
to tell which without the full sources. If you want help from the GNAT
group, please send full sources to gnat-report@cs.nyu.edu!
^ permalink raw reply [relevance 22%]
* Re: Running GNAT from the VB3 Shell Command
@ 1994-12-09 15:36 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-09 15:36 UTC (permalink / raw)
Peter (and those reading his post). Please be aware that the script you
posted is obsolete with respect to GNAT version 2.00, because in GNAT version
2.00, gnatbl automatically does the coff2exe step (something we should have
done in the first place, to avoid this common confusion, but sometimes
the obvious is not as obvious as it should be.
^ permalink raw reply [relevance 22%]
* Re: Anybody else having problems with GNAT 2 and OS2 Warp?
@ 1994-12-09 21:56 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-09 21:56 UTC (permalink / raw)
this certainly is strange, gnabl seems to be working fine for us under WARP
^ permalink raw reply [relevance 22%]
* Re: iSUB in PL/I (was: Re: Why don't large <you-know-whats> use <you-know what>?)
@ 1994-12-10 1:36 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-10 1:36 UTC (permalink / raw)
Two ancient books in the same place!!!
My goodness we will have to send round the firemen :-)
^ permalink raw reply [relevance 22%]
* Re: intermediate results causing constraint errors
@ 1994-12-10 13:41 20% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-10 13:41 UTC (permalink / raw)
The idea of Fortran users getting confused by the Brown model does not hold
water for a second.
Fortran has no arithmetic model, and Fortran programmers do not think
in terms of such models. The actual code generated by an Ada compiler
will be no different from that generated by a Fortran compiler with
respect to numeric operations in practice.
Remember that the Brown model has essentially ZERO effect on the generated
code of an Ada compiler, and also remember that the change to the floating
point model in Ada 9X will also in practice have zero effect on the
generated code.
As for the fixed-point "anomoly", this is only anomolous i you don't
understand fixed-point, and a good rule is not to use that which you
do not understand.
You will always get surprised if you try to use things you don't
understand, and only in that sense would I agree that Ada 83 is full of
little surprises in numerics.
^ permalink raw reply [relevance 20%]
* Re: Robert Dewar's horrible posts
@ 1994-12-10 13:43 22% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-10 13:43 UTC (permalink / raw)
Actually my news reader will quote stuff fine, but I hate wading through
quotes! Sometimes I don't give enough context, so that can be a problem
the other way, especially for people who are only occasional readers,
but the quote to information ratio in many CLA messages asymptotically
approaches infinity :-)
^ permalink raw reply [relevance 22%]
* Re: Why don't large companies use Ada?
@ 1994-12-10 13:50 22% ` Robert Dewar
1994-12-10 13:51 22% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-10 13:50 UTC (permalink / raw)
Michael, I think you are confused about ISUB, and barking up a wrong tree
to say that Ada 9X is superior to PL/1 here. ISUB is a much more powerful
feature than pragma Convention Fortran in Ada 9X, and subsumes it.
^ permalink raw reply [relevance 22%]
* Re: Why don't large companies use Ada?
1994-12-10 13:50 22% ` Robert Dewar
@ 1994-12-10 13:51 22% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-10 13:51 UTC (permalink / raw)
With respect to array transposition, Keith was just pointing out something
to compiler implementors, I agree it is relatively unlikely that one would
do conversion between fortran style arrays and normal row major arrays, but
an OBVIOUS situation is when you are passing data between existing fortran
libraries and existing Ada libraries, and it is nice to have a simple
notation for the necessary array conversion.
^ permalink raw reply [relevance 22%]
* Re: Why don't large companies use C/C++/OOP?
@ 1994-12-10 13:56 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-10 13:56 UTC (permalink / raw)
Remembr that a LOT of programming is still done in COBOL, and of course a lot
is done using 4GL's.
One of the big surprises we had at Realia in marketing the Realia compiler
was that we thought the main market would be for offloading mainframe
development, but the main market is in fact new applications written in
COBOL for the PC, surprising! Now you can get CICS, 370 JCL, 370 assembler
and all kinds of junk on the PC. People are actually writing NEW 370
assembly language programs for the PC!
^ permalink raw reply [relevance 21%]
* Re: Ada Run-Time Royalties - Opinions?
@ 1994-12-12 4:29 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-12 4:29 UTC (permalink / raw)
Presumably runtime licesnse fees should mean a lower cost for the compiler
itself, so in answering the question about such fees, this should be taken
into account.
^ permalink raw reply [relevance 22%]
* Re: Free Ada compiler for PC wanted
@ 1994-12-12 4:30 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-12 4:30 UTC (permalink / raw)
Oliver, do you really mean an 8086 based PC, this would be a truly historical
piece of junk!
If you are talking about a regular PC (i.e. 386 or higher), get GNAT
from cs.nyu.edu
^ permalink raw reply [relevance 22%]
* Re: Terseness
@ 1994-12-12 4:39 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-12 4:39 UTC (permalink / raw)
John (Volan), I trust you use a news reader that follows threads, if not
it is VERY hard to follow and respond to news coherently. In particular,
the example message you just gave indeed had no context, because you
started a brand new thread. It is true that if you follow messages blindly
in sequence, then you might even get to like these horrible quotes.
So, John, just for interest, do you follow threads, or do you read messages
sequentially (I bet the latter!)
^ permalink raw reply [relevance 21%]
* Re: Rational releases a C++/Smalltalk tool ???
@ 1994-12-12 4:44 20% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-12 4:44 UTC (permalink / raw)
"Some of us tried to bring this up [alledged hypocricy of Ada companioes
in dealing with multiple langauges] ... but were ignored. Why?"
Possibly because most people think this is an idiotic issue. THe idea that
companies should center on one particular language seems silly to me. This
is purely a marketing matter.
If I see Microsoft selling a Visual Basic compiler and a Visual C++ compiler,
do I sit around bemoaning their hypocricy! Of course not.
Probably if Microsoft DID decide to sell an Ada compiler, GA would expect
them to drop all other languages.
Greg, you keep beating on this horse, but as should be pretty apparent
to you, most of us think this horse died long ago, or more properly was
mythical and never alive in the first place :-)
^ permalink raw reply [relevance 20%]
* Re: PM bindings for OS/2 gnat?
@ 1994-12-12 4:57 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-12 4:57 UTC (permalink / raw)
We definitely plan to switch GNAT to EMX, but it is not at the top of
our priority list. The original decision to use the native compiler was
partly just a matter of choosing one of two possibilities, and partly
motivated by licensing problems with the EMX library at the time.
^ permalink raw reply [relevance 22%]
* Re: Ada can't initialize (aggregate) array of length 1?
@ 1994-12-14 3:21 22% ` Robert Dewar
1 sibling, 2 replies; 200+ results
From: Robert Dewar @ 1994-12-14 3:21 UTC (permalink / raw)
"I use GNAT v 2.0 on OS/2"
really? that's surprising, because GNAT goes out of its way to give
a clear error message here:
1. procedure k is
2. type stone is array (1..2) of character;
3. shapes: constant array (1..1) of stone := ("[]");
|
>>> positional aggregate cannot have one component
4. begin
5. null;
6. end;
and that's exactly right, the fix is to make the aggregate named
(1 => "[]")
^ permalink raw reply [relevance 22%]
* Re: Ada can't initialize (aggregate) array of length 1?
@ 1994-12-14 3:23 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-14 3:23 UTC (permalink / raw)
Gentle's response to this question:
: type stone is array (1..2) of character;
: shapes: constant array (1..1) of stone := ("[]");
: ____________________________________________^
You're trying to squash a string of length 2 into a character space.
Try initializing like this:
shapes: constant array (1..1) of stone := (1 => ('[',']'));
is wrong, it is perfectly fine to initialze an object of type stone with
the string literal "[]
" which is essentially identical to the aggregate ('[',']')
the ONLY problem is the one element aggregate.
^ permalink raw reply [relevance 21%]
* Re: Marketing Ada: Is the Sky Falling?
@ 1994-12-14 13:17 22% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-12-14 13:17 UTC (permalink / raw)
In response to Richard Pattis' comment on C++, I certainly feel that
it makes sense for Ada implementations to have very good interfaces
to C++ so that C++ bindings can be used with little or no effort.
^ permalink raw reply [relevance 22%]
* Re: Marketing Ada: Is the Sky Falling?
@ 1994-12-14 20:34 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-14 20:34 UTC (permalink / raw)
I don't see the different mangling schemes as a significant problem for
Ada binding to C++, yes it is a problem, but relatively minor.
^ permalink raw reply [relevance 22%]
* Re: Digital and Ada ?
@ 1994-12-16 4:41 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-16 4:41 UTC (permalink / raw)
In addition, just because there is a GCC for a machine does not mean there
is a GNAT automatically. Paritcularly in the case of VMS, with its unusual
structure of directory names, there is some special tailoring of the GNAT
system interface code. Also tasking does not pop out free. Bevin is quite
right, making a version of GNAT that is a fully functional susbtitute for
current Dec Ada compilers is not zero work!
^ permalink raw reply [relevance 22%]
* Re: Conformance problem in VAX Ada?
@ 1994-12-16 13:49 19% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-16 13:49 UTC (permalink / raw)
I certainly agree that this is a compiler problem (failure to diagnose
different default expressions as conformance problem). Here is the GNAT
output:
1. with Text_IO;
2. procedure Test is
3.
4. procedure Error (I : in Integer := Integer'First);
5.
6. procedure Error (I : in Integer := Integer'Last) is
|
>>> not fully conformant with declaration at line 4
>>> default expression for "I" does not match
7. begin
8. Text_IO.Put_Line (Integer'Image (I));
9. end Error;
10.
11. begin
12. Error;
13. end Test;
THe checking of default expressions is tricky, because they don't have
to be identical (for instance X.A can match A, and things get worse in
9X where "+(a,b) can match a+b. On the other hand 3 does not match 1+2,
so if your compiler folds 1+2 to 3 (which you can expect given that 1+2
is static), it had better make sure this does not happen at a point that
will result in false conformance.
Still this particular case seems pretty straightforward, and would suggest
that the compiler(s) involved are taking some shortcuts on conformance
analysis.
^ permalink raw reply [relevance 19%]
* Re: Addressing functions
@ 1994-12-16 14:53 19% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-16 14:53 UTC (permalink / raw)
Michael (Feldman), I think you missed the point of the question about
address applied to subprograms. What the original poster wants is a way
of using (i.e. CALLING) these subprograms given the address.
This is of course the feature that has been added to Ada 9X. There is no
guaranteed way of doing it in Ada 83, it is completely outside the
standard. Nevertheless, it is often possible to set up kludges for
a particular compiler.
If your compiler gives the entry point of the function as the 'Address,
then at least for global level functions, you can probably use some
assembly glue to call them. This won't work for nested functions, because
you won't be able to materialize the static link or display.
On some compilers it will work to do something like:
procedure p is ...
x : address;
x := p'address; -- or whatever ..
now to call the procedure:
declare
procedure dummy;
for dummy'address use x;
pragma interface (Ada, dummy);
begin
dummy;
end;
this is not guaranteed to work, but it may work on some compilers.
Best answer to original question: use Ada 95!
^ permalink raw reply [relevance 19%]
* Re: Marketing Ada
@ 1994-12-16 14:54 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-16 14:54 UTC (permalink / raw)
This sure is a peculiar thread (the one about macho programming!) :-)
^ permalink raw reply [relevance 22%]
* Re: How does the Ada 95 Streams package Index?
@ 1994-12-16 15:16 20% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-16 15:16 UTC (permalink / raw)
Tim, your question on stream files is confusing, streams do not have any
concept of records. Indeed that might be considered to be THE
distinguishing characteristic of streams. Certainly there is no filling
out of these (non-existent) records to their maximum size.
The Set_Index function is like lseek in C, although a little more
abstracted. It sets the position to the indicated storage element.
If you are writing "variable length records" to the stream, it is
up to the program to know the proper starting position for a record
that you want to point to (possibly by use of the Index function).
Actually, if you think of record = one storage element, then your
view of things is correct, but then of course there is no issue
of variable length records, or filling out a record to its maximum
size :-)
^ permalink raw reply [relevance 20%]
* Re: Addressing functions
@ 1994-12-16 16:56 20% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-16 16:56 UTC (permalink / raw)
Robert Eachus points out the same possible solution (using an address
clause) that I did, but he is too optimistic about its chance of success.
The effect of this sequence of code, or even its legality, cannot be
determined from the RM. It works on some compilers but not on others.
That you expect it might work is based on knowledge of implementation
models. There are many legitimate reasons for a compiler to reject the
program as illegal, and also many legitimate reasons for a compiler
to accept the program and then do the wrong thing.
At ome point CIFO included a requirement that this approach work, but
CIFO is not a standard, and so you can't count on this.
Ada/95 solves this problem directly!
^ permalink raw reply [relevance 20%]
* Re: Tri-Ada CD ROM Gnat for DOS
@ 1994-12-17 1:17 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-17 1:17 UTC (permalink / raw)
Isaac, how about asking gnat-report instead of relying on some mysterious
internet source :-)
^ permalink raw reply [relevance 22%]
* Re: GNAT-2.00 for FreeBSD 1.1.5, NetBSD and BSDI386 available
@ 1994-12-17 15:08 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-17 15:08 UTC (permalink / raw)
We are also starting a contrib directory at nyu, specifically for software
that is GNAT compatible, so by all means let us know where it is too.
^ permalink raw reply [relevance 22%]
* Re: Addressing functions
@ 1994-12-17 17:27 22% ` Robert Dewar
1994-12-17 17:32 21% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-17 17:27 UTC (permalink / raw)
Art Evans asks if Ada 83 requires support of pragma Interface to Ada. THe
answer is clearly NO, in fact Ada 83 does not require that you support
pragma Interface for any language.
This is one of several respects in which the code example from Bob Eachus
may be considered illegal by an Ada 83 compiler.
^ permalink raw reply [relevance 22%]
* Re: Addressing functions
1994-12-17 17:27 22% ` Robert Dewar
@ 1994-12-17 17:32 21% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-17 17:32 UTC (permalink / raw)
Moreover, Art reads into B.1(11) a requirement in Ada 95 to support
pragma Interface (Ada,...)
I don't see any such requirement. The sentence in 11 merely says that
the convention name Ada is not implementation dependent, it does not
say that you have to support it. Obviously you can't support pragma
Intrinsic for arbitrary entities, so clearly the implementation can
decide in general what pragma Import's to allow (there is implementation
advice in para 41, but that is only advice).
^ permalink raw reply [relevance 21%]
* Re: Array mappings
@ 1994-12-17 17:41 18% ` Robert Dewar
1 sibling, 1 reply; 200+ results
From: Robert Dewar @ 1994-12-17 17:41 UTC (permalink / raw)
Mike, you sure have posted lots of messages on the Fortran array issue. My
own feeling is that this is a nice feature, but not particularly critical.
Having to reorder array subscripts is not exactly the biggest barrier to
the use of Ada arrays in Fortran programs! You ask if vendors explicitly
ran around trying to "dig up" this market. I doubt it. Instead they probably
assumed that this was not a major issue, because no customers bought it up.
As for it being a possibly lucrative market, I VERY much doubt it. THere
were much more important targets of opportunity than this one.
It is true that it would not have been very hard to implement, which just
goes to show the estimate of value placed on this feature by vendors, and
personally I think that this was a reasonable estimate.
Ada 9X requires this support. Whether that requirement is justified
remains to be seen. That will really show whether Mike is right. If we
see a huge army of Fortran programmers suddenly saying "great, now that
I can write my subscripts the "right" way round in Ada 95, I will switch
to using Ada", then we will know that Mike was rigt, and that Ada vendors
missed an important opportunity.
Note: Many Fortran programmers are moving to C, C doesn't have any help
for Fortran array ordering, and I never heard of this being an adoption
barrier.
^ permalink raw reply [relevance 18%]
* Re: In search of Set/Get Variable reference tool
@ 1994-12-17 17:43 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-17 17:43 UTC (permalink / raw)
This information is obtainable from the GNAT compiler cross-referencer
^ permalink raw reply [relevance 22%]
* Re: Question about IO on Unix-machines
@ 1994-12-17 17:44 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-17 17:44 UTC (permalink / raw)
George, feel free to "bother" the New York group about GNAT anytime you
like :-)
Indeed Get_Immediate is not implemented, it is high up on our list.
^ permalink raw reply [relevance 22%]
* Re: Ada can't initialize (aggregate) array of length 1?
@ 1994-12-17 17:52 18% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-17 17:52 UTC (permalink / raw)
Scott is surprised that GNAT can give a clear error message for the case
of an invalid attempt to use a one-element positional aggregate.
Indeed this error message can't possibly be given in all situations (because
otherwise the language could allow it!)
Basically the cases that GNAT cannot correct are cases where you write
valid Ada 95 code that simply isn't quite what you meant:
procedure x (a : integer);
procedure x (a : array_of_integer);
now you write
x ((1));
thinking that you are calling the second version with an aggregate, when
in fact you have written a valid call to the first version.
However, if there is an error, GNAT does the following:
if I expect type vector of clunk
and I actually have something of type clunk
and the expression in question is parenthesized
then output the appropriate error message complaining about misuse
of 1-element positional aggregates.
of course no error message can always be "right". When a compiler detects
an error, it is in the business of producing the best guess as to what
was intended. The above check is just one of many heuristics in the GNAT
error detection intended to give more accurate messages.
By the way, whenever you get an error message you don't like from GNAT,
send a note to gnat-report. It is impossible to always give good error
messages, but often such suggestions are useful in tuning up the error
messages.
^ permalink raw reply [relevance 18%]
* Re: Reference Counting (was Re: Searching Method for Incremental Garbage Collection)
@ 1994-12-17 20:36 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-17 20:36 UTC (permalink / raw)
Bob says that most compilers return variable length objects on the stack.
THat's a little misleading. What some compilers do is to return them on
a secondary stack. It is a little tricky to return them on the primary
stack, it requires a specialized calling sequence (similar to what alloca
has to use), and in many ABI's, you can't do this without violating the
standard calling sequence.
^ permalink raw reply [relevance 22%]
* Re: Reaching traditional engineering, was: Array mappings
@ 1994-12-18 1:34 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-18 1:34 UTC (permalink / raw)
I assume you are aware of the Cray/Ada effort which was certainly aimed
at least partly at their Fortran community.
As for FOrtran engineers wondering why Ada sales people had not knocked
on their door -- that's easy, none of the Ada companies could have BEGUN
to afford this level of marketing effort!
^ permalink raw reply [relevance 22%]
* Re: PL/1 vs PL/I (Re: Why don't large companies use Ada?)
@ 1994-12-18 13:47 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-18 13:47 UTC (permalink / raw)
I think it is wrong to say that PL/I was called this because of lack of
confidence. In fact it was more like the "one" in
A-1 Autobody Repair Inc.
i.e. the "we're number one" of programming languages
the original title in all the papers was NPL (new programming language).
^ permalink raw reply [relevance 22%]
* Re: Marketing Ada
@ 1994-12-18 15:17 22% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-18 15:17 UTC (permalink / raw)
If the "C hacker culture is a turn off to women", maybe we should hire
more women as programmers :-) :-)
^ permalink raw reply [relevance 22%]
* Re: Array mappings
@ 1994-12-19 3:41 16% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1994-12-19 3:41 UTC (permalink / raw)
Mike, I know you enjoy vendor bashing, but let's keep facts straignt (and
this particular point is one I have made before). You DEFINITELY cannot
say that Alsys was "fixated" on the DoD market when it was first formed.
For years, it agressively persued the non-DoD market, and please note that
there is not very much US DoD business in France, where Alsys had some
considerable success in penetrating various application fields.
Indeed, Jean always thought of Ada as a general purpose language with
possible application to a wide variety of fields. Some people even
criticized Jean for not being sufficiently concentrated on the US DoD
market!
As for your question of what is more important than the array ordering
matter, I would say two things:
Realiability and maturity (note the posting we already saw on this issue)
Performance. This is a really tough one, Fortran compilers typically have
been squeezed furiously on performance of numerical loops, and are where
you find the most aggressive optimization of this type of code. The
effort of competing in code quality with mature optimizing Fortran
compilers was and is huge and very expensive.
You keep saying that what you want to be sure is that vendors did extensive
market surveys of this part of the market. I don't know how much business
experience you have, but this is the sort of thing that is often recommended
by people without such experience. THe fact of the matter is that meaningful
surveys of markets are VERY difficult and VERY expensive. The trick in a
market like the Ada market is to be able to guess where to go WITHOUT blowing
huge amounts of capital in studies like this that do not turn out to be
useful.
My own feeling is that the performance issue was so central at the time,
that there was little chance for Ada to make serious headway (one of the
problems with the Cray compiler was that, espeically early on, it was a
little bit less efficient than Fortran).
As to why numerical people are moving to C, it is partly because they are
moving to work stations where C is perceived as part of the general
environment, and yes, I do think this represents an opportunity!
^ permalink raw reply [relevance 16%]
* Re: Array mappings
@ 1994-12-19 3:46 20% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-19 3:46 UTC (permalink / raw)
"An Ada implementor who really cared would have delivered [more reliable
compilers]"
This is really silly. THe implication that bugs in early Ada compilers were
due to lack of care and concern for specific markets has no basis in fact.
Ada has always had extremely high reliability requirements in all markets
(one can argue that the embedded real-time market is a much higher
reliability-requirement market than numerical computation). Sure early
Ada compilers had bugs (early anything compilers have bugs), but this
was a matter of maturity, and you can be sure that all Ada vendors were
working extremely hard to improve reliability. Perhaps they did not succeed
as well as you might hope, but to ascribe that to deliberate lack of care
won't wash."
If you rest your case on this weak and unsupportable observation, it is
indeed a weak case!
^ permalink raw reply [relevance 20%]
* Re: Ada can't initialize (aggregate) array of length 1?
@ 1994-12-19 14:20 16% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-19 14:20 UTC (permalink / raw)
"IN that case the error message was confusing"
As I said earlier giving the "right" message when an attempt is made to
use a one element aggregate is not generally always possible (because
otherwise the language could allow it).
In the case of an inner aggregate, which was the case at hand, it is
theoretically possible to still give the "right" message, but much
harder, because the expected type is not at hand (remember that
aggregates are resolved independent of context in a situation like
this).
The GNAT processing is:
if type array-of-x is expected, and we have a parenthesized x instead
then give special error message.
What would be needed in the other case is much more complex:
attempt to resolve array aggregate
if it fails, see if there are cases of parenthesized expression(s) in
the aggregate, and treat them as positional aggregates, and retru the
resolution. if it works, then give the special error message
much more complex! furthermore if there are several parenthesized expressions
in the aggregate, say K of them, a really thorough attempt would require
2**K attempts at resolution, which is getting a bit out of hand..
The error message game is an interesting one of trading off effort vs
return. Correctness is not involved, since you can't always be correct
in the real sense (that would require telepathy), and it is trivial to
be formally correct (any error message at all, even a bomb saying simply
error, would be officially correct).
So you do the best you can!
As I requested before, always send in examples of confusing error messages,
it is pretty much impossible to tell how easy it is to "fix" such cases.
One more point is that the amount of effort that it is worth putting in
very much depends on ones estimate of the frequency of the error, and how
bad the consequences are of messing up.
For example, GNAT goes to rather strenous and complex efforts to diagnose
the misuse of IS for semicolon and vice versa in procedure specs and bodies.
But this is a case where the error is common, and the failure to do correct
error recovery can lead to VERY mysterious error messages.
^ permalink raw reply [relevance 16%]
* Re: Array mappings
@ 1994-12-19 14:27 18% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-19 14:27 UTC (permalink / raw)
Following up on Mark's comments, I feel that the COBOL market is in practice
a much better opportunity for Ada 95 than the Fortran market.
I have three reasons for thinking this:
1. It is a much bigger market, and is now in the business of climbing off
mainframes, so systems are being rethought anyway.
2. The COBOL world has always been much more forward thinking when it
comes to language. This is the land of 4GL's, and it is interesting
for instance to note the interest in Smalltalk. People are by no means
wedded to COBOL, and they are looking around.
3. For a Fortran user, Ada 95 and C++ look somewhat similar. Sure we can
argue the usual "Ada is better because xxx" line where xxx has to do
with reliability etc. etc. but in terms of raw functionality, C++ and
Ada 95 look rather similar (and both are weaker than Fortran 90 when
it comes to manipulating multi-dimensional arrays).
When I say weaker here, I am talking about for example the slicing
features of F90. Of course I still think that F90 users would be
ahead in using Ada 95, because they would gain so much from the
improved abstraction features, but as I said this is a sell based
on somewhat abstract issues :-)
On the other hand, C++ does NOT look good to COBOL folks. It signally
lacks facilities for decimal arithmetic, which cannot be smoothly
integrated (consider handling of literals for example) into C++.
On the other hand, Ada 95 has gone out of its way to be COBOL
friendly, and even includes editing modeled directly on COBOL pictures.
C
^ permalink raw reply [relevance 18%]
* Re: Array mappings
@ 1994-12-20 14:09 18% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-20 14:09 UTC (permalink / raw)
Mike wonders about the difficulty of applying traditional fortran optimization
techniques to Ada.
There is no conceptual problem in writing highly optimizing Ada backends.
I don't think the "highly structured for loop" of Ada is any particular
help, it is essentially identical to the do loop of Fortran in any case.
THe only conceptual problem arises as a result of the dynamic lower bounds,
which threaten to generate extra instructions in some cases, although
address reduction in loops will generally eliminate this extra work in
most loops. Another approach is to use virtual origins for arrays, which
is our eventual plan in GNAT.
The difficulty is that the amount of technical resources to do a highly
optimizing backend of this case is HUGE, and I can't believe it would have
been worth the investment of tens of person years to develop Ada optimization
to this level, especially early on. Furthermore, such an expenditure of
effort would have harmed stability and reliability.
Fortran users tend to be more concerned with speed than with reliability (the
infamous Cray division which gives wrong results very fast is an indicator of
this general attitude), and that of course is the wrong way round for most
Ada users.
Obviously the way to get high performance is to borrow an existing backend,
which of course is what we have done with GNAT. The performance of GNAT for
a simple arithmetic loop should be entirely comparable to that of
GNU Fortran or GNU C, which is pretty darned good, but probably STILL not
as good as the really hot commercial Fortran compilers on which huge
optimziation efforts have been spent.
^ permalink raw reply [relevance 18%]
* Re: GNAT and gdb
@ 1994-12-21 4:55 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1994-12-21 4:55 UTC (permalink / raw)
in general gdb works with gnat pretty well, although it needs to be taught
some Ada manners to really look nice (this is work that is under way).
Still it is very usable, it is our main tool for debugging GNAT itself.
However, the bad news is that it does not work at ALL with the current
OS/2 version of GNAT. We are planning to investigate moving to the EMX
port of GCC to host GNAT< and that should give gdb support.
^ permalink raw reply [relevance 21%]
* Re: GNAT not 'getting' CR or LF?
@ 1995-01-02 4:42 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-02 4:42 UTC (permalink / raw)
Get will certainly NOT see CR/LF etc, that is its spec.
For now, until Get_Immediate is implemented, the best thing
is simply to write an interface to the appropriate C routine getchar or
whatever.
^ permalink raw reply [relevance 22%]
* Re: Language Lawyers help on rep_specs
@ 1995-01-03 15:06 22% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-03 15:06 UTC (permalink / raw)
You mention in your message comparing "two vendors Ada 95 compilers". Since
no vendor has an Ada 95 compiler yet, this can't be literally the case,
so we must assume you are dealing with two prereleases of partial
implementations.
The rep clause (not spec please!) is perfectly valid, and conversions are
static in Ada 95 (but not in Ada 83).
^ permalink raw reply [relevance 22%]
* Re: Language Lawyers help on rep_specs
@ 1995-01-03 18:04 22% ` Robert Dewar
1995-01-03 18:07 22% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-03 18:04 UTC (permalink / raw)
Ted says that Integer (x'First) is not static, and quotes something
about functions, but there is no function call involved here. Integer is
a static conversion, not a function call, and the expression
Integer (x'First) is most definitely static assuming x is a static subtype.
^ permalink raw reply [relevance 22%]
* Re: Language Lawyers help on rep_specs
1995-01-03 18:04 22% ` Robert Dewar
@ 1995-01-03 18:07 22% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-03 18:07 UTC (permalink / raw)
Incidentally, I hereby declare that since we are now in 1995, that when
I say Ada, I mean Ada 95 by default, and I will specifically say Ada 83
if that is what I mean, should I for some reason need to refer to obsolete
languages :-)
^ permalink raw reply [relevance 22%]
* Re: FORTRAN Translation to Ada
@ 1995-01-04 1:13 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-04 1:13 UTC (permalink / raw)
One obvious place to look is the GCC Fortran compiler
^ permalink raw reply [relevance 22%]
* Re: Avionic Proximity Warning
@ 1995-01-04 18:48 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-04 18:48 UTC (permalink / raw)
"A two-voter vote [on which way to fly to avoid collision"
no problem, I execute that algorithm on the street frequently:
let me go to the right, oh, you want to go to the right, ok I'll go to
the left, oh, you changed your mind too, never mind, I'll go to the right
after all, oh ....
^ permalink raw reply [relevance 22%]
* Re: GNAT NT 2.0c & LINK32 vs. LINK
@ 1995-01-05 17:38 20% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-05 17:38 UTC (permalink / raw)
Sorry you had difficulties, a point worth making here is that we find that
something like 90% of installation difficulties come from either not reading
or not believing the directions. Of course it would be nice if GNAT
installation were more bullet proof, but meanwhile you can definitely
do yourself a favor by following the directions to the letter :-)
A good example is with the restore step on OS/2. Backup/restore is indeed
a nuisance program, and on our list is to get rid of it, but meanwhile
virtually all problems with this step come from people not following the
directions of what directories to be in, people just assume, wrongly, that
they know what they are doing and can diverge from the instructions!
^ permalink raw reply [relevance 20%]
* Re: "Subtract C, add Ada"
@ 1995-01-05 23:56 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-05 23:56 UTC (permalink / raw)
"Where is C sucks, Ada rules"
I'll tell you where, in inappropriate posts to comp.lang.ada, that's where!
John's papres are excellently presented, and I think giving them more of a
langauge wars slant would be a big mistake. Yes, if you read the papers
you will get an important message if you are not deaf, but the critical
issue here is not simple us vs them language comparisons.
^ permalink raw reply [relevance 22%]
* Re: Programming Libraries in Ada
@ 1995-01-06 20:44 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-06 20:44 UTC (permalink / raw)
Kai, please at least copy questions on GNAT to gnat-report, since they will
be seen by people who can answer them, in particular, if you do that, the
person who wrote gnatbl will see it, although the easiest way to answer
the quetion of what gnatbl does in detail is to look at the source.
^ permalink raw reply [relevance 22%]
* Re: Data Format Brainstorm
@ 1995-01-07 14:45 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-07 14:45 UTC (permalink / raw)
did you really have to cross-post your reply to all those groups? The guy
asked for email to prevent this. It is clearly not the kind of question whose
answer is of interest to all these groups.
I find it annoying when people to this kind of blanket post to find
info when they are too lazy to do a bit of preliminary research first
to find references, but the followups compound the irritiation. Especially
when you read several of the groups involved.
^ permalink raw reply [relevance 21%]
* Re: Reference Manual ?
@ 1995-01-08 14:13 19% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-08 14:13 UTC (permalink / raw)
Mark Fearer asks where he can find a copy of the Ada reference manual. I
suspect he is asking for the soon to be obsolete document describing the
soon to be obsolete language Ada 83 (or Ada 87 if you are of the ISO
persuasion). Probably the best source is the annotated reference manual
from Grebyn Corp, I assume that Carl Nyberg still has copies available.
If you want the Ada 95 reference manual, that is not yet available in
paper printed form, but you can FTP postscript versions (from many sites
including cs.nyu.edu) and print a copy yourself.
P.S. Please note that when I refer to Ada 83 as obsolescent, I am not under
the illusion that it will go away over night. I have recently been hiding
out in comp.lang.cobol (with a mission of planting an occasional Ada 95
seed over there), and one of the surprising things to me is how incomplete
the switch over to COBOL 85 is. Ten years later, it seems many shops are
still insisting on the COBOL 74 standard.
^ permalink raw reply [relevance 19%]
* Re: GNAT NT & Ada.Direct_IO
@ 1995-01-09 6:07 20% ` Robert Dewar
1995-01-09 6:10 22% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-09 6:07 UTC (permalink / raw)
Mark, please be sure to send basic questions like this to gnat-report
where they will get answered immediately.
THe answer to your question about direct_io is trivial, it is a generic unit,
and compiling generic units, like compiling specs, with GNAT does not
generate code.
It is only when a generic is instantiated that code is generated.
Actually in the case of generics, but not package specs, it is conceivable
that this will change in the future. Note also that there is a current
bug which causes a null object file to be generated for generics.
But anyway, the bottom line for the moment is use the -gnatc when
compiling generics, since no code is generated. THe only reason for
compiling a generic unit like direct_io is to check it out semantically.
P.S. the capitlization is because this particular error message always
generates mixed case output. It is too much trouble to copy the actual
capitalization from he source in this particular case.
^ permalink raw reply [relevance 20%]
* Re: GNAT NT & Ada.Direct_IO
1995-01-09 6:07 20% ` Robert Dewar
@ 1995-01-09 6:10 22% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-09 6:10 UTC (permalink / raw)
Note incidentally that it is generally "not permitted" to recompile
children of Ada, Interfaces and System, in accordance with the permission
in the RM.
This restriction can be bypassed by the use of the -gnatg option, but then
you must follow the GNAT style restrictions (documented in the body of
the module style.adb)
^ permalink raw reply [relevance 22%]
* Re: Task Scheduling in Applications Written in Ada
@ 1995-01-09 16:37 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-09 16:37 UTC (permalink / raw)
Dar, it would be most interesting to know in more detail what "scheduling
algorithms" you have in mind for accept, select etc.
^ permalink raw reply [relevance 22%]
* Re: Large Integers?
@ 1995-01-11 2:39 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-11 2:39 UTC (permalink / raw)
Note that you can also find arbitrary precision integer arithmetic and
ratoinal arithmetic packages in the GNAT sources, in files uintp and
urealp respectively.
^ permalink raw reply [relevance 22%]
* Re: GNAT NT & Ada.Direct_IO
[not found] <INFO-ADA%95011109284406@VM1.NODAK.EDU>
@ 1995-01-12 13:57 19% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-12 13:57 UTC (permalink / raw)
Marin Condic suggests that GNAT display version and bug information etc.
always, in listings, and on errors.
I don't want to do it always, that would be too annoying to most users
I think ??? Of course there is a verbose option now that displays the
version (-gnatv) and it is not a bad idea to make this also print the
send bug information to message. Right now, -gnatv gives:
NYU GNAT Compiler Version 2.01w (C) Copyright NYU, 1992,1993,1994
for example.
We do give full information on submitting bugs if a bomb occurs that we can
intercept. Right now we are not intercepting signals, which is unfortuate,
and we are trying to fix this obvious shortcoming.
Program listings (obtained with the -gnatl option) also contain the version
information, and could perhaps include the send bug information message.
I am a little reluctant actually to unconditionally output this on listings,
because then all students see this message, and we already get too many
messages from beginning students asking us how Ada works :-) This morning
I got a message which roughly said:
"I am very enthusiastic about Ada 9X, and I understand it has object
oriented facilities, can you please email me a complete description
of how these are used".
:-)
^ permalink raw reply [relevance 19%]
* Re: Run-time checking and speed
[not found] ` <3f0prq$3bq@theopolis.orl.mmc.com>
@ 1995-01-12 14:13 16% ` Robert Dewar
[not found] ` <3fa2pk$kbi@felix.seas.gwu.edu>
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1995-01-12 14:13 UTC (permalink / raw)
T.E.D. says
"As for constraint checks, try to leave them in until your product is
THOROUGHLY debugged. They are worth their weight in gold during the
debugging phase."
I would be stronger, I would say leave them in for the production code.
Knuth once said that removing checks for the production code is like
using life-jackets for training outings, and then leaving them at home
for the final trans-atlantic sailing on the grounds that they add too
much weight.
Of course in some cases, the delivered code does not run fast enough, and
you have to cut corners to meet processing efficiency requirements, and in
this situation you may have to abandon the checks, but do this only when
you have to, not as a matter of course. I have seen too many Ada environments
in which the assumption is that checks will be turned off for production code.
The penalty of run time checks can run anywhere from 5-50% depending on the
code. Enthusiastic vendors will tell you that it is never more than 10%, but
that depends very much on your code and it may be higher. But suppose that
it is 20%. It is amazing how many programs really don't care about 20%, and
it is often the case that next months version of the processor chip will make
up the 20% anyway.
Don't get me wrong, I quite appreciate that there are situations, particulary
embedded situations with critical deadlines running on junk old hardware,
where processing deadlines are indeed very pushed, and there may be some
general applications where speed is pushed (a one day weather forcasing
program that takes 2 days to run is not much use to anyone :-)
So I quite appreciate that checks must be turned off in some cases, I just
argue that this should not be the default assumption.
Another situation where it is quite appropriate to turn off run time checks
is in verified safety critical code where part of the verification ensures
that the checks are not needed. You have to be *very* sure of your
verification technology to depend on this!
^ permalink raw reply [relevance 16%]
* Re: "No" Ada jobs in the Boston area
@ 1995-01-12 14:18 19% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-12 14:18 UTC (permalink / raw)
Dave Emery says:
"I think that the Ada compiler industry has been guilty of trying to
recoup profits too quickly, and thereby charging too much for its
entry-level products.
Hmm! there are a lot of investors in Ada companies who sure don't see it
that way, since they lost their shirts. Maybe the vendors were trying to
recoup their profits too quickly, but they sure did not succeed!
The accusation would be more credible if there were examples of Ada
vendors making big profits!
Now one may disagree with the pricing levels, that's a different discussion
based on the perception of the elasticity of the market. If it is really
the case that charging $200 instead of $2000 would have multiplied Ada
users by a factor of 20, then of course the pricing was set wrong. But
that's an argument we have gone through many times before. If the market
really is that elastic, then the availability of GNAT should presumably
greatly increase the number of Ada users, which is certainly the hope!
^ permalink raw reply [relevance 19%]
* Re: "No" Ada jobs in the Boston area
[not found] ` <3f12uq$ef1@rational.rational.com>
@ 1995-01-12 14:20 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-12 14:20 UTC (permalink / raw)
Kent, I think your position is perfectly reasonable, and I have always
supported the idea that diversification by Ada companies helps rather
than hurts Ada.
Still, you don't have to be Greg Aharonian to be a little disappointed when
Rational works so hard to hide its Ada connections at trade shows. FOr
example, at the Object Expo in New York last summer, Rational had a huge
booth with absolutely no mention of Ada anywhere at all.
That's carrying things a little far I think ...
^ permalink raw reply [relevance 21%]
* Re: Ada.strings.bounded problems?
[not found] <TARJEIJ.95Jan11183331@ulrik.uio.no>
@ 1995-01-12 14:24 21% ` Robert Dewar
[not found] ` <EACHUS.95Jan11170317@spectre.mitre.org>
[not found] ` <D29L78.J9@nntpa.cb.att.com>
2 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-12 14:24 UTC (permalink / raw)
Tarjei, you can certainly write a generic package on top of bounded
strings. Simply include a parameter that is a formal derived pacakge,
then the user of your generic will supply the instantiation.
In GNAT, we are thinking of redoing the bounded strings so that they lie
on top of a non-generic package where there is a discriminant giving the
maximum length.
Not only will this avoid unnecessary duplication of code, but we could
also think of giving direct access to the underlying package. Of course
programs that took advantage of this would be potentially non-portable
(although not really, they could just include the GNAT version of these
packages, even if they were using some other compiler).
^ permalink raw reply [relevance 21%]
* Re: Ada to C translator
[not found] ` <3f1kig$p0d@newstand.syr.edu>
@ 1995-01-12 16:10 20% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-12 16:10 UTC (permalink / raw)
Polar asks:
"Can anyone give me a pointer to an Ada to C language translator that
*supports Ada tasking*.
I am getting the impression that GNAT does not. However, I would prefer
C to C++ as that C++ would just require yet another compiler."
The comment on GNAT seems to suggest that GNAT might be an Ada to C
translator. It is most certainly nothing of the kind, it is an Ada
compiler, and no more relevant to the issue of translating Ada to C
(with or without Ada), than any other Ada compiler.
Doing an accurate translation of tasking Ada to C would be a big job,
since you would have to have a complete, and usable, version of the Ada
tasking support library written in C.
^ permalink raw reply [relevance 20%]
* Re: Ada.strings.bounded problems?
[not found] ` <EACHUS.95Jan11170317@spectre.mitre.org>
@ 1995-01-12 18:10 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-12 18:10 UTC (permalink / raw)
Robert Eachus says just use the Bounded Strings package and it should do
just what you want.
Suppose what you want is the following (easily provided by PL/1 for example).
I want several different strings, all bounded, with different maximum lengths,
and I want to be easily able to do operations between them.
True I can do:
if To_String (A) = To_String (B) then
but first of all, it is annoying to have to write the To_String calls, and
second, I will be willing to bet that all compilers will generate extra
copies to implement this (at least one for each call, and possibly more
than one).
I think that's the sort of thing that was being requested ...
^ permalink raw reply [relevance 21%]
* Re: GNAT on Solaris: Help!
[not found] <3f1tj4$15q@gap.cco.caltech.edu>
@ 1995-01-12 18:50 18% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-12 18:50 UTC (permalink / raw)
John -- how about reading the documentation :-)
you will find two things if you do. First that problems and questions are
to be addressed to gnat-report. There is no point in posting basic questions
like this to comp.lang.ada, since they can be answered immediately by
gnat-report, and you can't always count on the necessary people from the
GNAT group reading comp.lang.ada.
Second, if you read the features file (please do!), you will find:
Tasking is currently implemented only on the following platforms
SGI IRIX 5.2, Sun Sparc (SunOS 4.1), i386 running IBM OS/2
So tasking is documented NOT to be available on Sun Solaris, and the
documentation tells the truth!
We are currently working on tasking that will work with Solaris threads,
no definite date yet, but things are beginning to work!
I am posting this reply as my periodic reminder that GNAT problems should
be sent to gnat-report.
Incidentally, one thing to mention while I am at it is the following. We
can't provide formal support at NYU or guaranteed response on bugs. However
we do our best, and you can help us by being sure to let us know if a bug
you report is particularly critical (i.e. no work around known, and an
important program being held up), then we will try to give the report the
highest priority we can.
^ permalink raw reply [relevance 18%]
* Re: ADA-9x done? Any good PC compilers?
[not found] <1995Jan11.154250@clstac>
@ 1995-01-12 22:14 21% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1995-01-12 22:14 UTC (permalink / raw)
You asked for Ada on a PC platform, so it is worth pointing out that the
OS/2 version of GNAT on the PC does support tasking.
P.S. the delay bug is fixed in the latest development version people will
be glad to hear!
Actually it was not technically a bug, since compilers are allowed to
take longer than the minimum for a delay, if you had waited 25,000 years,
the delay would have expired :-) :-)
^ permalink raw reply [relevance 21%]
* Re: Ada.strings.bounded problems?
[not found] ` <D29L78.J9@nntpa.cb.att.com>
@ 1995-01-12 22:17 22% ` Robert Dewar
[not found] ` <D2D8DC.JvM@nntpa.cb.att.com>
[not found] ` <D2J8H0.DMu@aplcenmp.apl.jhu.edu>
3 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1995-01-12 22:17 UTC (permalink / raw)
Kenneth says it is a weakness of Ada that you cannot implement bounded
strings of different lengths.
Sorry I don't see this at all, a type like
type str (max_length : natural) is record
current_length : natural;
S : String (1 .. Max_Length);
end record;
will do just fine, what's the problem?
In fact we were thinking of implementing the Ada 95 bounded string in terms
of this abstraction.
^ permalink raw reply [relevance 22%]
* Re: string literals
[not found] <cary-110195174515@macsac09.esl.com>
@ 1995-01-12 22:21 21% ` Robert Dewar
[not found] ` <D2Dnpv.41u@alsys.com>
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1995-01-12 22:21 UTC (permalink / raw)
"but don't want to use [the package with character literals]"
why on earth not? this is what use is for! There is a certain style of
Ada question that goes like:
How do I do X without using Y
where Y is exactly the feature intended to support X. Most odd!
If you are worried that the use clause would clutter up the name space, a
nice way of doing things is to put the definition of the character type
into a nested package:
package Stuff is
...
package Char_Type_Package is
type Char_Type is ( ....
end Char_Type_Package;
end Stuff;
now you can just say use Stuff.Char_Type_Package and you have access to the
literals.
^ permalink raw reply [relevance 21%]
* Re: Strange behaviour with protected objects
[not found] <"Jwic53.0.fY6.3v06l"@autan>
@ 1995-01-16 3:25 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-16 3:25 UTC (permalink / raw)
Note that the designation 2.01w is a temporary designation that covers
the wavefront version. It is not in general the case that 2.01w = 2.01w,
so telling someone you are using 2.01w does not mean much!
Pretty soon 2.01 will be out (a few days we would hope), at which time
there will be a stable version to run tests against!
^ permalink raw reply [relevance 22%]
* Re: string literals
[not found] ` <3fcdf4$65n@uuneo.neosoft.com>
@ 1995-01-16 17:30 20% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-16 17:30 UTC (permalink / raw)
An absolute rule against all use clauses is misconceived and ill-advised,
but you can live with it, because the consequence is just junky hard to
read source code, and tools can hide the junk from you.
An absolute rule against all use of unchecked conversion is true folly. There
are all sorts of situations in which UC is an important tool, and completely
forbidding its use seriously cripples the language.
Sure it can be misused, so can addition and integers, but that doesn't mean
you should ban addition and integers.
Indeed the requirement of an explicit with of unchecked conversion is
precisely intended to allow *control* of the use of this important feature,
not its *elimination*.
I can't tell you how many times I have seen people decide that you can't do
something in Ada, and therefore resort to C, or whatever, just because they
have crippled Ada with silly restrictions.
^ permalink raw reply [relevance 20%]
* Re: Math Lib. for Ada? Ada for X11R6?
[not found] ` <3fcf8f$dm6@Starbase.NeoSoft.COM>
@ 1995-01-16 17:53 21% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-16 17:53 UTC (permalink / raw)
OK, I understand that math libraries may go beyond the RM stuff, but surely
this is a case where it makes little sense to reinvent the wheel. If we have
good interface to Fortran, then using existing FOrtran libraries makes
good sense.
Perhaps we need a nice Ada layer on top of them in some cases, but I
certainly would not try to rewrite them.
Note: version 2.01 of GNAT fully supports interface to Fortran, including
storing arrays columnwise if pragma Convention FOrtran is applied to an
array type. We haven't tested this out much yet, perhaps someone interested
in interfacing to this kind of library can see if it works!
^ permalink raw reply [relevance 21%]
* Re: "Subtract C, add Ada"
[not found] ` <3fcjgt$b0v@cronkite.seas.gwu.edu>
@ 1995-01-16 18:47 20% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-16 18:47 UTC (permalink / raw)
"Dennis Ritchie once said in an interview that there is *nothing* in the
C language that keeps compiler writers from issuing stringent warnings
about stuff that most Ada people take for granted."
Dennis may have said this, but it is misleading. Yes, there is stuff that
Ada people take for granted that C compilers could (and in some compilers
*do*) check for.
But there are lots of things that Ada people take for granted that cannot
be checked in C, there just isn't enough information. C has no separation
of scalar types, no ranges on scalar types, and the ubquitous use of
pointers, and their similarity to arrays means that sophisticated aliasing
analysis is required to even approximate the type checking that occurs
in the context of access types in Ada. There are many other examples.
^ permalink raw reply [relevance 20%]
* Re: C++ Envy
[not found] ` <3fcjp5$b0v@cronkite.seas.gwu.edu>
@ 1995-01-16 18:48 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-16 18:48 UTC (permalink / raw)
Yes, I typed CFM for CM, sorry, configuration management.
If you don't precompile headers, then I don't see how a CM system easily
stops you using macros to subvert headers that are simply included (that's
what starting this particular thread as I remember).
^ permalink raw reply [relevance 22%]
* Re: Ada.strings.bounded problems?
[not found] ` <D2J8H0.DMu@aplcenmp.apl.jhu.edu>
@ 1995-01-18 5:01 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-18 5:01 UTC (permalink / raw)
Mars worries whether the use of unbounded strings is incompatible with
programs that run for ever.
Not at all, or more accurately, no more or less incomaptible than any use
of the heap. You have to make sure that you don't have memory leaks in
your implementation, and that you have sufficient heap memory to avoid
fragmentatino problems, but other than that ...
^ permalink raw reply [relevance 22%]
* Re: ADA Objects Help!
@ 1995-01-18 17:47 20% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1995-01-18 17:47 UTC (permalink / raw)
"why not packages and package types"
why not indeed? it is always interesting to see people joining the party
late and treading previously trodden realms :-)
Yes, this is an attractive idea, one that some important Ada folks have
championed, and which has been examined extensively.
Basically the conclusion is that following this line of thought leads
(a) to excessive complexity, it is very tricky to work out all the
ramifications
(b) to a confusion of concepts, packages are not happy extended in this
direction, and it causes a confusion (unification???) of types and packages.
The final decision of the Ada design is that this would have confused rather
than unified.
(c) the building of the OOP notions on top of derived types is much more
powerful and general, and avoids some of the limitations that come from
a narrow, distinguished object approach.
Tuck may want to add to this, clearly a full answer will saturate the internet
bandwidth for some time!
^ permalink raw reply [relevance 20%]
* Re: Ada.strings.bounded problems?
[not found] ` <Mats.Weber-1701951908250001@mlma11.matrix.ch>
@ 1995-01-18 17:48 22% ` Robert Dewar
1 sibling, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-18 17:48 UTC (permalink / raw)
I think probably the best thing if you want to follow this idea for
bounded strings is to make them a limited type and live with the
inconvenience of no initialization.
^ permalink raw reply [relevance 22%]
* Re: Ada95: New_Page at end of file
@ 1995-01-18 23:16 20% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-18 23:16 UTC (permalink / raw)
The Ada standards (83 and 95) both require a page mark at the end of a
text file, and the representation of this page mark is implementation
dependent.
GNAT currently represents ALL page marks by form feed characters, including
the one at the end of the file.
This is not incorrect, but it is unfriendly, a more friendly, though
obviously slightly trickier, representation is to have the page mark at
the end of file have a different representation (namely null).
This is on our list of things to do.
However, please note that text files in Ada have implementation dependent
formats, and you cannot count on this as a transportable format without
additional, possibly implementation dependent, guarantees. See also the
URG discussion of this issue (perhaps Dave can supply us with the proper
UI number).
^ permalink raw reply [relevance 20%]
* Re: ADA-9x done? Any good PC compilers?
[not found] ` <EACHUS.95Jan17120531@spectre.mitre.org>
@ 1995-01-18 23:17 22% ` Robert Dewar
0 siblings, 1 reply; 200+ results
From: Robert Dewar @ 1995-01-18 23:17 UTC (permalink / raw)
I was talking about when a delay expires, this has nothing to do with the
required preemption by a higher priority task!
(responding to Eachus' note on my note about infinite delays)
^ permalink raw reply [relevance 22%]
* Re: Large Integers?
[not found] ` <3fhjr1$4h8@rational.rational.com>
@ 1995-01-18 23:22 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-18 23:22 UTC (permalink / raw)
Kent, do you know which compilers supported 64-bit integers, it is my
impression that yes indeed, it is true that very few 83 compilers have
such support. Of course no quarrel with your observation that this is not
a REQUIRED limitation.
^ permalink raw reply [relevance 22%]
* Re: Run-time checking and speed
[not found] ` <3fjhrj$9b3@oahu.cs.ucla.edu>
@ 1995-01-20 5:11 19% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-20 5:11 UTC (permalink / raw)
In response to Jay's concern that global suppres may be suicidal due to
some piece of code relying on checks for normal flow of control. He
calls such code "pinhead" code but that is unfair.
In particular, it does not seem wrong to rely on constraint error to
raise constraint error. Suppose the spec of some operation requires
constraint error to be raised if some condition is true. I am talking
about a user packagee here. Then you may not want this to be suppressed,
yet it may well be the case that you use constraint checking to achieve
the constraint checking so to speak.
An examlple is raising time_error in calendar. You probably do not want
this suppressed by turning checks off, yet in Ada 95, calendar has been
carefully tweaked to invite you to get time error by raising a constraint
error on a normal arithmetic operation (this was not possible in Ada 83
due to minor glitches).
In GNAT, we have introduced an implementation defined pragma Unsuppress
that undoes a previous suppression, including one applied by command
line argument, precisely to deal with this kind of situation, so a module
that REALLY needs checks should contain a pragma Unsuppress.
^ permalink raw reply [relevance 19%]
* Re: Ada.strings.bounded problems?
[not found] ` <3fja22$fab@source.asset.com>
@ 1995-01-20 5:12 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-20 5:12 UTC (permalink / raw)
"The traditional response is that a good optimizing compiler will remove
the discriminant"
Not likely, this is a VERY hard optimization, and not one that I have seen
any Ada compiler do except in VERY specific cases.
^ permalink raw reply [relevance 22%]
* Re: Memory overwrite?
@ 1995-01-20 5:19 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-20 5:19 UTC (permalink / raw)
In response to Mark, worrying about out of array stores in Ada 83, this
is fixed in Ada 95, where the check cannot be elided in the case he
worries about.
^ permalink raw reply [relevance 22%]
* Re: Need help with DEC Ada
@ 1995-01-20 5:22 20% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-20 5:22 UTC (permalink / raw)
Mats says:
"the original (2**31)-1 should not cause any problem. Ae you really sure it
generates a warning ?"
sorry Mats, that is wrong, in Ada 83, this expression was not a static
expression evaluated at compile time, and hence a compiler is allowed to
compute it at runtime, insisting that all intermediate values are in
range of the type (in this case a 32 bit integer).
So Dec Ada is perfectly correct (just not very friendly) in raising CE
in this situation.
Whatever model you have that says that this should not cause any problem
is flawed with respect to Ada 83. However, as I pointed out in a previous
message, Ada 95 has "fixed" this "problem" by requiring static expressions
to be evaluated exactly, even when they appear as subexpressions of non
static exprssions, or in contexts not requiring static expressions.
^ permalink raw reply [relevance 20%]
* Re: Ada explanation?
@ 1995-01-20 5:25 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-20 5:25 UTC (permalink / raw)
One of the most aggravating mis-statements here is the claim that Ada
was designed by a committee. NOTHING could be further from the truth
(I speak as a member of the only committee in sight at the time, the
DR's, who certainly did NOT act as designers in any sense).
Oh well, who can control what hackers say :-)
Incidentally, I guess that hackers will also find the exception handling
facilities in C++ hilarious. Perhaps they just find it hilarious that anyone
would bother to waste time worrying about error situations in code :-)
^ permalink raw reply [relevance 21%]
* Re: Math Lib. for Ada? Ada for X11R6?
@ 1995-01-20 5:27 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-20 5:27 UTC (permalink / raw)
"It [interfacing Fortran] gets much harder when you have to deal with
packages that take Fortran routines for callbacks."
At least in GNAT, and I would hope in all Ada 95 compilers, there is
no trouble in passing Fortran routines for callbacks, or indeed passing
routines written in Ada (with pragma Convention Fortran) for this purpose.
^ permalink raw reply [relevance 22%]
* Re: Ada Objects Help!
[not found] ` <131279@cup.portal.com>
@ 1995-01-20 16:52 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-20 16:52 UTC (permalink / raw)
"How can Ada be object oriented if you always have to pass the data to the
function?"
I have a clearer version of this question
"How can Ada be object oriented if the second and third characters of its
name are not special characters?"
:-)
^ permalink raw reply [relevance 22%]
* Re: C programmer with Newbie question
@ 1995-01-20 16:55 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-20 16:55 UTC (permalink / raw)
Peter, there were all sorts of constraints in numbering annexes, including
some formal ISO rules. We discussed this at length. In particular, your
R for real time could not fly unless there were annexes A-Q :-)
^ permalink raw reply [relevance 22%]
* Re: pragma import problem ( also OS/2 : gnat 4emx )
@ 1995-01-20 16:58 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-20 16:58 UTC (permalink / raw)
Regarding the use of link name (incidentally I did send a direct message
already, so if it didn't arrive, must be an email addressing problem).
Generally NEVER use link name, use external name instead, and use for the
external name the name as it appears in the external language. This
is much more portable. If you use link name, then you have to know
system dependent things like whether an underscore is prefixed.
Note: there has been some glitch in the OS/2 version in this area in the
past, but you should still use external name. Anyway, this will clean up
in the EMX vesion we are hopeing to distribute soon.
^ permalink raw reply [relevance 21%]
* Re: Ada.strings.bounded problems?
[not found] ` <1995Jan19.124412@lglsun.epfl.ch>
@ 1995-01-20 17:00 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-20 17:00 UTC (permalink / raw)
There would be problems in implementation of generics with shared code if
equal were always compositional. Certainly a consideration (it would mean
that equality had to be passed in for all types, quite expensive).
Second: it IS possible to define equality on non-limited types in Ada 83
using the generic trick. This trick is well known, and widely used, so you
cannot ignore it in considering upwards compatibility.
^ permalink raw reply [relevance 22%]
* Re: string literals
@ 1995-01-21 5:20 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-21 5:20 UTC (permalink / raw)
"Since this tool will be so "trivial", I hope you plan on including
it in the GNAT effort. Can we expect it by, oh, say, next month?"
certainly not by next month, but I would hope this would happen soon.
Tools for GNAT have to be mostly fashioned outside NYU, since NYU (and
the GNAT contract) are concentrated on the compiler itself. However,
I do expect various interesting things to be happening in the tool
department, stay tuned!
^ permalink raw reply [relevance 21%]
* Re: Ada.strings.bounded problems?
@ 1995-01-21 5:28 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-21 5:28 UTC (permalink / raw)
Mats says:
"So sad ! I think it is the biggest defect I know of in Ada 95."
[it is not having introduced the upwards incompatible feature of user
defined equality being compositional]
Gosh Mats, if that's the biggest defect, then Ada 95 must be in
*very* good shape!
^ permalink raw reply [relevance 22%]
* Re: ADA-9x done? Any good PC compilers?
@ 1995-01-21 5:31 22% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-21 5:31 UTC (permalink / raw)
Robert Eachus is wrong in thinking System.Tick has anything to do with
delays in Ada 83 (I guess he missed the ARG meeting where we discussed
this :-)
^ permalink raw reply [relevance 22%]
* Re: "Subtract C, add Ada"
@ 1995-01-21 15:18 18% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-21 15:18 UTC (permalink / raw)
Laurent Gasser says:
>"Personally, the lack of this sort of compactness in Ada, and things like
> pre- and post-increment/decrement are one of my minor gripes about the
> language. OK, its no big thing to write:
>
> P(I) := Q(I);
> I := I + 1;
>
> instead of
>
> *p++ = *q++;
>
> but I actually *do* find the C representation easier/better etc. (perhaps
> I'm wierd?)"
The trouble with these notations in C is that they work better with short
variable names, as in the example above. This is reminiscent of typical
mathematical notations (like ! for factorial) that also are predicated on
typical mathematical style of one character variables like x. Now look at
Next_Predicted_Value (Iteration_Index) :=
Previous_Calculated_Value (Iteration_Index);
and
*Next_Predicted_Value++ = *Previous_Calculated_Value++;
There are two problems with the second form. First the * and ++ seem to get
a bit lost with the long names. Second, we are missing the name
Iteration_Index which may be quite helpful in understanding what is going on.
Note also that the C style is implying the use of pointers, which are less
comfortable than the use of arrays, because the pointers could be pointing
to anything, while we know what is involved with the arrays.
All in all, the Ada in the second example seems much clearer, and of course
once you use long identifiers, the advantage of the compact notation is
reduced.
There is no rule saying use long identifiers in Ada, and use short identifiers
in C (and I am sure we have all seen code with short identifiers in Ada, and
long identifiers in C), but it is not an accident that even though there are
no rules, there are effectively stylistic customs in these directions, and
I think that the neat compact C syntax gizmos are at least partly responsible.
^ permalink raw reply [relevance 18%]
* Re: Ada.strings.bounded problems?
@ 1995-01-21 18:57 16% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-21 18:57 UTC (permalink / raw)
Magnus may not like the fact that you can legitimately override equality
for non-limited types in Ada 83, but you can, and it is well known how
to do it.
Upwards compatibility means that existing code must work, it does not mean
that existing code that meets Magnus' criterion for what he thinks is OK
must work!
Also, as Norm points out, the incompatibility extends beyond the use of
the Goodneough tecnnique for redefinition of equality.
It's easy to get heated up over minor things in the environment of suitable
heated statements, but in practice I think this is a fairly small issue.
After all it is up to an Ada 95 programmer whether to take advantage
of the new capability or not. It will often mean that the proper decision
is to either make the type limited or tagged.
It is important to realize the hit on shared generics. THe design of Ada 95
has been carefully done to preserve the practicality of using shared
generics, as is currently done by at least two implementations. In particular,
suppose we have a simple generic with some discrete types as arguments. It
seems unfortunate (both in terms of implementation complexity, and in
efficiency) to require all equality operations to be done with thunks.
Note that in the case of tagged types, the comparison operations are complex
in any case, and often dispatching, so it is not a significant additional
burden (just always dispatch inside the shared generic).
As is so often the case in language design, delicate compromises are the
order of the day. THis is particularly true when upwards compatibility
must be maintained. It is true that the upwards compatibility criterion
can result in some compromises that one might prefer not to settle for
(look after all at C and C++!) Some during the ADa 95 felt that we were
not adventurous enough in being incompatible, and some thought we should
have been much MORE compatible. I think that the middle path steered was
about right.
Note incidentally that the non-upwards compatibilities here are of the
worst possible kind: old code compiles fine and executes giving wrong
results.
^ permalink raw reply [relevance 16%]
* Re: ADA Objects Help!
@ 1995-01-21 18:59 21% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-21 18:59 UTC (permalink / raw)
Mats, if you don't see any problems in package types, then you have not even
started to scratch the surface. I don't know if there are any easily
accessible written discussions of this issue or not. The amount of
discussion that has occurred on this issue would certainly fill many books.
It would be helpful to have a summary so that people don't keep rewalking
the same path without knowing where it leads, but I certainly don't have
time to do it!
^ permalink raw reply [relevance 21%]
* Re: ADA Objects Help!
@ 1995-01-22 18:06 14% ` Robert Dewar
0 siblings, 0 replies; 200+ results
From: Robert Dewar @ 1995-01-22 18:06 UTC (permalink / raw)
Rob Wilkinson, if you cannot see that from a purely semantic point of view
there is nothing particularly special about member functions, then maybe
it is you who need a better C++ book.
You are viewing them through a semantic filter which says that you will
view these member functions in a special way, corresponding to a particular
paradigm that you (and the language design!) have in mind. However, if you
can manage to take a more basic viewpoint, you will see that member functions
are just functions, nothing more and nothing less. THey have a special
syntax and visibility, but that does not mean they are semantically
fundamentally different from ordinary functions.
YOu may just be to wrapped up in your viewpoint to see the point that several
people have made to you, certainly it does not seem to be registering.
Basically we have functions that can be used as ordinary functions and
functions that you want to associate with a particular "object". Note
incidentally that at the language level, C++ does not have objects, it
has special structures that are called classes that may be particularly
well suited for the representation of objects, but they are not objects,
because the concept of object has to do with programming paradigms, NOT
with the language design.
In Ada 95, this same programming paradigm (objects and member functions,
probably better called methods in this context, since member functions is
just a syntactic designation), are represented by tagged types and associated
primitive subprograms with controlling arguments.
Just as in C++, classes and member functions may be used to represent
objects and methods, but of course have many other uses, in Ada 95,
tagged types and primitive operations of these types may be used
to present objects and methods.
The semantics in this correspondence are pretty much identical, although the
Ada 95 model is a little more flexible in that one can have more than one
appearence of the tagged type in the parameter list, which together act as
a controlling operand. THis is not important if you are strictly representing
objects and methods, but can be very useful in other contexts.
I think the reason that no one understands what you are saying, and
consequently that you are getting frustrated, is that you are starting
out from some fundamental assumptions that are false:
classes in C++ represent objects, false, they can be used to represent
objects, but that is a programmer choice.
member functions in C++ are methods. again false, they can be used for
this purpose, but that is a programmer design choice.
Then you add to it your apparent feeling that this particular usage is
critical enough that it is important to give it a separate syntax. The
trouble is that this introduces multiple syntaxes for identical semantic
concepts (at the language level), and in the Ada 95 design we consider
it an advantage that no separate syntax is used. It leads to a much more
flexible capability, with all the power of the corresponding C++ constructs
and additional capabilities.
In C++, classes are often used for purposes other than the representation of
objects. For instance, in the absence of name spaces, they are used to
represent packaging of entities quite often, and in this context the special
syntax for member functions can definitely get in the way (e.g. if the
function is a binary operator operating on the class type).
^ permalink raw reply [relevance 14%]
Results 201-400 of ~7510 next (newer) | prev (older) | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
1994-10-14 21:13 Easily-Read C++? Kevin Cline
1994-10-21 14:38 ` Thomas M. Breuel
1994-10-22 3:10 ` Michael M. Bishop
1994-10-26 0:39 ` -mlc-+Schilling J.
1994-10-27 14:54 ` Bob Duff
1994-10-27 23:09 21% ` Robert Dewar
1994-10-20 7:29 compilation time [was Re: Magnavox consultant] tmoran
1994-10-20 19:05 ` compilation time [was Re: Magnavox consult Richard L. Conn
1994-10-25 18:08 ` Eric C. Newton
1994-10-25 22:23 22% ` Robert Dewar
1994-10-21 21:37 Paradise-3.4 ported to GNAT/Ada9X? SrA Tim Miller
1994-10-21 22:04 ` Larry Kahn
1994-10-24 4:50 22% ` Robert Dewar
[not found] <38fhhq$fma@goanna.cs.rmit.oz.au>
[not found] ` <Cy6K8v.8xH@inmet.camb.inmet.com>
1994-10-24 15:45 22% ` Private/incomplete type differences...? Robert Dewar
1994-10-25 10:36 Flags in Ada? Andre Spiegel
1994-10-26 0:36 ` Dale Stanbrough
1994-10-26 11:01 20% ` Robert Dewar
1994-10-27 8:23 ` Henri Altarac
1994-10-27 23:00 22% ` Robert Dewar
1994-10-25 15:54 SOLVED! Decoupled Mutual Recursion Challenger John Volan
1994-10-28 4:28 ` Jay Martin
1994-10-29 0:38 ` Bob Duff
1994-10-29 11:59 ` Richard Kenner
1994-10-31 13:17 21% ` Robert Dewar
1994-10-25 19:32 Generic Child Packages Jack Beidler
1994-10-26 0:05 22% ` Robert Dewar
1994-10-25 21:00 Lines of documentation per LOC Loic Briand
1994-10-25 19:00 ` Robert I. Eachus
1994-10-26 13:45 ` Loic Briand
1994-10-26 22:30 22% ` Robert Dewar
[not found] <38afut$8m9@news.delphi.com>
1994-10-24 11:15 ` compilation time [was Re: Magnavox consultant] Robert I. Eachus
1994-10-24 23:19 ` Bob Duff
1994-10-25 13:58 ` Norman H. Cohen
1994-10-25 23:33 22% ` Robert Dewar
1994-10-26 3:19 Flags in Ada? tmoran
1994-10-26 9:59 ` David Emery
1994-10-26 22:32 22% ` Robert Dewar
1994-10-26 14:33 21% ` Robert Dewar
1994-10-26 15:40 Interfaces.Fortran Kyongsuk Pace
1994-10-26 22:28 20% ` Interfaces.Fortran Robert Dewar
1994-10-28 17:13 ` Interfaces.Fortran paus
1994-10-30 17:19 18% ` Interfaces.Fortran Robert Dewar
1994-10-27 5:05 Flags in Ada? tmoran
1994-10-27 13:29 17% ` Robert Dewar
1994-10-27 17:15 ` Norman H. Cohen
1994-10-28 3:51 20% ` Robert Dewar
1994-10-27 5:06 tmoran
1994-10-27 13:47 21% ` Robert Dewar
1994-10-28 2:41 ` Tucker Taft
1994-10-30 13:31 22% ` Robert Dewar
1994-10-27 9:44 Initialization Params for Controlled Types Angel Alvarez
1994-10-27 23:06 22% ` Robert Dewar
1994-10-27 11:25 Ada replacements for DOS I/O Elgar the Idiot aka Chris Warwick
1994-10-27 23:04 20% ` Robert Dewar
1994-10-31 15:08 ` Mark Bayern
1994-11-03 11:23 20% ` Robert Dewar
1994-11-04 8:17 ` Samuel Tardieu
1994-11-06 21:03 21% ` Robert Dewar
1994-10-28 12:17 ` Ted Dennison
1994-10-31 13:21 22% ` Robert Dewar
1994-11-03 9:24 ` Robert I. Eachus
1994-11-05 5:37 22% ` Robert Dewar
1994-10-28 3:59 Flags in Ada? tmoran
1994-10-28 13:43 17% ` Robert Dewar
1994-10-31 14:19 ` Norman H. Cohen
1994-11-02 14:06 ` Mats Weber
1994-11-03 23:08 22% ` Robert Dewar
1994-11-03 11:26 22% ` Robert Dewar
1994-10-28 11:26 Another One Bites the Dust! Bob Wells #402
1994-10-28 16:04 17% ` Robert Dewar
1994-10-28 11:31 Access type representations Bob Wells #402
1994-10-28 13:36 ` Tucker Taft
1994-10-28 16:52 21% ` Robert Dewar
1994-10-28 17:03 ` Mitch Gart
1994-10-30 16:02 21% ` Robert Dewar
1994-10-28 14:22 Paige's How To Get An Automatic Ada Waiver memo Gregory Aharonian
1994-11-02 14:38 ` Robert I. Eachus
1994-11-03 1:40 ` Richard Riehle
1994-11-03 23:10 21% ` Robert Dewar
1994-10-28 18:59 Say it isn't so! (Formerly: Ada replacements for DOS I/O) Bennett, Chip (KTR) ~U
1994-10-30 15:31 16% ` Robert Dewar
1994-10-29 0:48 Elaboration Ken Garlington
1994-10-30 13:39 19% ` Elaboration Robert Dewar
1994-10-31 15:33 Interfaces.Ada Kyongsuk Pace
1994-11-01 18:06 ` Interfaces.Ada Michael Feldman
1994-11-01 21:04 ` Interfaces.Ada Matt Kennel
1994-11-03 11:18 20% ` Interfaces.Ada Robert Dewar
1994-11-03 11:15 21% ` Interfaces.Ada Robert Dewar
1994-10-31 20:28 Type System.ADDRESS Bob Gilbert
1994-11-03 11:30 22% ` Robert Dewar
1994-11-01 3:11 Tucker Taft
1994-11-01 13:04 ` Bob Gilbert
1994-11-03 11:31 22% ` Robert Dewar
1994-11-01 14:28 GNAT-Problem Set_Line(), Set_Col() Andreas Krohn
1994-11-12 15:49 22% ` Robert Dewar
1994-11-15 13:30 ` Norman H. Cohen
1994-11-15 17:36 ` Michael Feldman
1994-11-16 0:04 ` Norman H. Cohen
1994-11-16 13:48 22% ` Robert Dewar
1994-11-01 15:20 Another One Bites the Dust! Bob Wells #402
1994-11-03 11:36 22% ` Robert Dewar
1994-11-02 2:06 DOS GNAT 1.83 returns 'unknown file type' on compilation Roger Labbe
1994-11-03 11:34 22% ` Robert Dewar
1994-11-02 21:19 WE NEED A GOOD Ada SORT PACKAGE! Bennett, Chip (KTR) ~U
1994-11-03 17:42 ` Jahn Rentmeister
1994-11-05 5:43 21% ` Robert Dewar
1994-11-03 3:15 Ada replacements for DOS I/O tmoran
1994-11-03 23:05 22% ` Robert Dewar
1994-11-04 12:34 POSIX and symbolic links ???? Fredrik Olsson
1994-11-06 21:04 22% ` Robert Dewar
1994-11-07 13:54 GNAT-Problem / Please Help !! Andreas Krohn
1994-11-13 12:41 21% ` Robert Dewar
1994-11-17 23:27 ` Keith Thompson
1994-11-19 7:19 21% ` Robert Dewar
1994-11-08 5:49 GNAT and AdaSage
1994-11-12 2:12 21% ` Robert Dewar
1994-11-10 15:14 Systemless use of 'Address Bob Wells #402
1994-11-11 20:32 ` Cary Jamison
1994-11-12 20:38 20% ` Robert Dewar
1994-11-14 21:36 ` Norman H. Cohen
1994-11-16 16:11 ` Mats Weber
1994-11-16 23:50 22% ` Robert Dewar
1994-11-14 2:20 Command line package for Alsys Ada Compiler jgs0132
1994-11-15 8:51 ` Paul Warren
1994-11-16 13:46 22% ` Robert Dewar
1994-11-17 16:18 ` Michael Feldman
1994-11-18 21:29 ` Pascal Martin @lone
1994-11-19 23:34 21% ` Robert Dewar
1994-11-14 4:17 Why don't large companies use Ada? Jamie Jamison
1994-11-14 14:19 ` R. William Beckwith
1994-11-14 22:07 ` Jeff Reinholz
1994-11-18 22:19 ` Christopher K. Krebs
1994-11-19 17:44 ` Jean D. Ichbiah
1994-11-20 7:09 ` R. William Beckwith
1994-11-20 17:18 20% ` Robert Dewar
1994-11-20 17:21 20% ` Robert Dewar
1994-11-20 23:37 ` Jean D. Ichbiah
1994-11-21 14:53 ` R. William Beckwith
1994-11-22 13:56 15% ` Robert Dewar
1994-11-14 23:04 ` Robert Temple
1994-11-16 14:14 ` Doug Robertson
1994-11-16 23:47 18% ` Robert Dewar
1994-11-22 16:43 ` James Hopper
1994-11-25 18:32 ` Carlos Perez
1994-11-25 20:26 ` Michael Feldman
1994-11-28 8:47 ` Tarjei Jensen
1994-11-28 16:23 ` Michael Feldman
[not found] ` <house.786178243@helios>
1994-12-01 21:02 19% ` Robert Dewar
1994-12-02 21:36 ` Michael Feldman
1994-12-05 15:37 ` Norman H. Cohen
1994-12-06 13:22 21% ` Robert Dewar
1994-11-28 14:00 22% ` Robert Dewar
1994-11-28 14:02 22% ` Robert Dewar
1994-11-23 15:40 ` Jules
1994-11-24 15:28 ` Alistair James Robert Young
1994-11-27 11:55 ` Andrew Dunstan
1994-12-01 3:10 ` s-algol Alistair James Robert Young
1994-12-02 14:09 22% ` s-algol Robert Dewar
1994-11-15 3:29 Installing GNAT 1.83 on DOS Apinetr Unakul
1994-11-15 17:27 19% ` Robert Dewar
1994-11-15 11:55 Why don't large companies use Ada? David Weller
1994-11-28 14:27 ` Robert I. Eachus
1994-11-29 4:05 ` Michael Feldman
1994-11-29 18:24 ` IanMaclure
1994-11-30 16:26 ` David Weller
1994-12-01 21:24 22% ` Robert Dewar
1994-11-30 20:15 ` Richard Riehle
1994-12-02 5:25 22% ` Robert Dewar
1994-12-02 21:45 ` Michael Feldman
1994-12-03 5:43 ` Keith Thompson
1994-12-04 22:39 ` Michael Feldman
1994-12-05 22:57 22% ` Robert Dewar
1994-12-06 2:48 ` Michael Feldman
1994-12-08 4:10 22% ` Robert Dewar
1994-12-06 3:29 ` Keith Thompson
1994-12-08 10:49 22% ` Robert Dewar
1994-12-08 10:51 22% ` Robert Dewar
1994-12-09 3:16 ` Michael Feldman
1994-12-10 13:50 22% ` Robert Dewar
1994-12-10 13:51 22% ` Robert Dewar
1994-12-05 0:03 ` Matt Kennel
1994-12-05 22:59 22% ` Robert Dewar
1994-12-06 2:51 ` Michael Feldman
1994-12-08 4:11 22% ` Robert Dewar
1994-12-08 17:52 ` iSUB in PL/I (was: Re: Why don't large <you-know-whats> use <you-know what>?) Norman H. Cohen
1994-12-10 1:36 22% ` Robert Dewar
1994-12-03 21:09 ` Why don't large companies use Ada? Paige Vinall
1994-12-06 7:16 ` Richard Riehle
1994-12-08 10:48 21% ` Robert Dewar
1994-11-15 22:54 defaults on discriminants Gene McCulley
1994-11-20 17:14 19% ` Robert Dewar
1994-11-16 23:28 GNAT for Mac? Francesco Stiffoni
1994-11-18 17:56 ` Laurent Gasser
1994-11-19 17:07 17% ` Robert Dewar
1994-11-19 7:15 22% ` Robert Dewar
1994-11-17 21:46 SGI inheriting C++ classes Bennett, Chip (KTR) ~U
1994-11-19 7:12 20% ` Robert Dewar
1994-11-21 15:09 ` R. William Beckwith
1994-11-22 14:24 20% ` Robert Dewar
1994-11-18 15:27 Range Check Query Bob Wells #402
1994-11-18 12:11 ` Robert I. Eachus
1994-11-19 16:58 20% ` Robert Dewar
1994-11-18 21:04 Ada Portability... NOT! Capt. Britt Snodgrass
1994-11-19 16:55 17% ` Robert Dewar
1994-11-21 2:11 ` Carlos Perez
1994-11-21 13:17 20% ` Robert Dewar
1994-11-21 23:56 ` Keith Thompson
1994-11-22 3:53 22% ` Robert Dewar
[not found] <199411200820.IAA02428@stout.entertain.com>
1994-11-21 1:45 21% ` Delphi and SGI's GNAT Ada access of C++ class libraries Robert Dewar
1994-11-21 19:24 ` Tom Quiggle
1994-11-22 3:52 22% ` Robert Dewar
1994-11-22 14:28 PART/pthreads for GNAT under Linux rosensti
1994-11-23 21:56 22% ` Robert Dewar
1994-11-23 16:14 GNAT Scott Leschke
1994-11-29 15:33 ` GNAT Jack Beidler
1994-11-30 23:01 22% ` GNAT Robert Dewar
1994-11-25 13:39 Help Wanted Ian M Wilks
1994-11-28 15:42 22% ` Robert Dewar
1994-11-25 17:18 C functions for GNAT ? Thierry Nodenot
1994-11-30 14:31 ` Running GNAT from the VB3 Shell Command Jack Beidler
1994-12-05 3:06 ` Lance Kibblewhite
1994-12-05 23:03 22% ` Robert Dewar
1994-12-06 16:15 ` Lance Kibblewhite
1994-12-07 14:59 ` Peter Hermann
1994-12-09 15:36 22% ` Robert Dewar
1994-11-26 10:40 Interesting OS/2 product for GNAT users David Weller
1994-11-29 0:32 20% ` Robert Dewar
1994-11-27 11:58 What is OO (Was Why don't large companies use Ada?) Andrew Dunstan
1994-11-29 15:48 ` Shawn Willden
1994-11-30 23:26 22% ` Robert Dewar
1994-11-28 11:28 Help with gnat IO Woodrow Yeung
1994-11-29 22:05 18% ` Robert Dewar
1994-11-28 12:56 cross linking packages Rene Burema
1994-11-29 22:07 22% ` Robert Dewar
1994-11-30 23:03 ` Matt Kennel
1994-12-05 20:57 ` Elaboration order [was: cross linking packages] John Volan
1994-12-06 16:11 22% ` Robert Dewar
1994-11-29 13:17 18% Availability of GNAT version 2.0 Robert Dewar
1994-11-29 13:19 21% Multithreading Robert Dewar
1994-11-29 13:22 20% Ada crosscompiler for a Intel 386 target Robert Dewar
1994-11-29 15:42 Why don't large companies use Ada? Dave Vernest
1994-11-30 16:46 ` An Amoeba
1994-12-01 22:29 16% ` Robert Dewar
1994-12-01 10:40 HELP: GNAT for HP 9000/755 john
1994-12-01 20:15 ` Eric Slutz
1994-12-03 2:57 22% ` Robert Dewar
1994-12-02 5:29 22% Why don't large companies use Ada? Robert Dewar
1994-12-02 7:44 PM bindings for OS/2 gnat? Geert Bosch
1994-12-04 4:17 ` David Weller
1994-12-09 18:21 ` Dirk Zoller
1994-12-12 4:57 22% ` Robert Dewar
1994-12-02 13:23 GNAT-Problem '+'-operator with Count Andreas Krohn
1994-12-09 15:33 22% ` Robert Dewar
1994-12-03 15:17 Reference Counting (was Re: Searching Method for Incremental Garbage Collection) Henry G. Baker
1994-12-09 22:07 ` Bob Duff
1994-12-11 23:59 ` Gary McKee
1994-12-12 5:04 ` Henry G. Baker
1994-12-16 19:35 ` Bob Duff
1994-12-17 20:36 22% ` Robert Dewar
1994-12-05 0:34 In search of Set/Get Variable reference tool Mike Winslow
1994-12-16 19:01 ` Kevin Weise
1994-12-17 17:43 22% ` Robert Dewar
1994-12-05 20:41 GNAT (v1.83 and v2.0) and Booch Components Dan Coyne D054
1994-12-06 14:16 22% ` Robert Dewar
1994-12-05 21:42 Using procedures Bennett, Chip (KTR) ~U
1994-12-07 23:35 22% ` Robert Dewar
1994-12-05 23:51 GNAT problem: Hello World Jacob Sparre Andersen
1994-12-06 12:18 ` W ALI
1994-12-08 20:05 22% ` Robert Dewar
1994-12-06 13:06 Why don't large companies use Ada? Paige Vinall
1994-12-07 14:15 ` Norman H. Cohen
1994-12-10 20:55 ` Array mappings Michael Feldman
1994-12-13 15:01 ` Norman H. Cohen
1994-12-16 18:55 ` Michael Feldman
1994-12-17 0:43 ` Keith Thompson
1994-12-17 17:17 ` Reaching traditional engineering, was: " Michael Feldman
1994-12-18 1:34 22% ` Robert Dewar
1994-12-17 20:42 ` Rolf Ebert
1994-12-19 2:19 ` Michael Feldman
1994-12-19 3:46 20% ` Robert Dewar
1994-12-19 5:53 ` Mark S. Hathaway
1994-12-19 14:27 18% ` Robert Dewar
1994-12-17 17:41 18% ` Robert Dewar
1994-12-19 2:01 ` Michael Feldman
1994-12-19 3:41 16% ` Robert Dewar
1994-12-20 3:23 ` Michael Feldman
1994-12-20 14:09 18% ` Robert Dewar
1994-12-06 13:31 18% cross-posting and selling Ada Robert Dewar
[not found] <3bn3l9$pa2@gnat.cs.nyu.edu>
1994-12-05 18:41 ` intermediate results causing constraint errors Bob Duff
1994-12-06 13:40 18% ` Robert Dewar
1994-12-07 17:17 ` Richard Riehle
1994-12-10 13:41 20% ` Robert Dewar
[not found] <D06r8x.JBy@inmet.camb.inmet.com>
1994-12-02 17:32 ` Reference Counting (was Re: Searching Method for Incremental Garbage Collection) Henry G. Baker
1994-12-05 20:59 ` Robert Firth
1994-12-06 14:15 22% ` Robert Dewar
1994-12-06 18:00 Why don't large companies use Ada? Bob Wells #402
1994-12-08 17:51 ` PL/1 vs PL/I (Re: Why don't large companies use Ada?) Michael D Shapiro
1994-12-18 13:47 22% ` Robert Dewar
1994-12-07 12:49 Ada Run-Time Royalties - Opinions? R.A.L Williams
1994-12-12 4:29 22% ` Robert Dewar
1994-12-07 20:32 GNAT Port To WIN or WINNT? Mike Gardner
1994-12-09 4:37 22% ` Robert Dewar
1994-12-08 0:36 Free Ada compiler for PC wanted Oliver Kiddle
1994-12-12 4:30 22% ` Robert Dewar
1994-12-08 2:00 Why don't large companies use Ada? Kenneth G. Hamilton
1994-12-09 11:49 19% ` Robert Dewar
1994-12-08 4:17 Anybody else having problems with GNAT 2 and OS2 Warp? Pat Rogers
1994-12-09 21:56 22% ` Robert Dewar
1994-12-08 22:37 Why don't large companies use C/C++/OOP? Curtis
1994-12-10 13:56 21% ` Robert Dewar
1994-12-09 16:43 Digital and Ada ? Scott Leschke
1994-12-10 23:26 ` Tucker Taft
1994-12-12 14:53 ` Garlington KE
1994-12-13 12:41 ` Richard Kenner
1994-12-14 1:27 ` Bevin R. Brett
1994-12-16 4:41 22% ` Robert Dewar
1994-12-09 17:29 Rational releases a C++/Smalltalk tool ??? Gregory Aharonian
1994-12-12 4:44 20% ` Robert Dewar
1994-12-10 8:54 Conformance problem in VAX Ada? Dave Papay M/S 7G32 x2791
1994-12-12 16:10 ` Norman H. Cohen
1994-12-16 13:49 19% ` Robert Dewar
[not found] <199412031821.LAA27900@hops.entertain.com>
1994-12-04 4:25 ` Robert Dewar's horrible posts David Weller
1994-12-04 5:43 ` Dave Retherford
1994-12-08 18:14 ` -mlc-+Schilling J.
1994-12-09 16:52 ` Terseness John Volan
1994-12-12 4:39 21% ` Terseness Robert Dewar
1994-12-10 13:43 22% ` Robert Dewar's horrible posts Robert Dewar
1994-12-11 19:56 Marketing Ada tmoran
1994-12-13 3:18 ` Michael Feldman
1994-12-13 5:35 ` Carlos Perez
1994-12-14 1:53 ` Michael Feldman
1994-12-16 14:54 22% ` Robert Dewar
1994-12-18 15:17 22% ` Robert Dewar
1994-12-12 7:12 Ada can't initialize (aggregate) array of length 1? Dirk Zoller
1994-12-12 12:54 ` Gentle
1994-12-14 3:23 21% ` Robert Dewar
1994-12-14 3:21 22% ` Robert Dewar
1994-12-16 10:37 ` Dirk Zoller
1994-12-19 14:20 16% ` Robert Dewar
1994-12-16 16:41 ` Scott Leschke
1994-12-17 17:52 18% ` Robert Dewar
1994-12-13 1:36 Addressing functions Bill Buckley
1994-12-13 10:14 ` Robert I. Eachus
1994-12-16 14:18 ` Arthur Evans Jr
1994-12-17 17:27 22% ` Robert Dewar
1994-12-17 17:32 21% ` Robert Dewar
1994-12-16 16:56 20% ` Robert Dewar
1994-12-14 1:48 ` Michael Feldman
1994-12-16 14:53 19% ` Robert Dewar
1994-12-13 19:48 Marketing Ada: Is the Sky Falling? Richard Pattis
1994-12-14 13:17 22% ` Robert Dewar
1994-12-14 19:47 ` Marco Antoniotti
1994-12-14 20:34 22% ` Robert Dewar
1994-12-14 16:01 Tri-Ada CD ROM Gnat for DOS ISAAC PENTINMAKI
1994-12-17 1:17 22% ` Robert Dewar
1994-12-15 9:38 GNAT-2.00 for FreeBSD 1.1.5, NetBSD and BSDI386 available Cornelis van der Laan
1994-12-16 18:46 ` Michael Feldman
1994-12-17 15:08 22% ` Robert Dewar
1994-12-16 5:54 How does the Ada 95 Streams package Index? Timothy Halloran
1994-12-16 15:16 20% ` Robert Dewar
1994-12-16 9:58 Question about IO on Unix-machines Joerg Rodemann
1994-12-17 17:44 22% ` Robert Dewar
1994-12-20 14:43 GNAT and gdb Al Niessner III
1994-12-21 4:55 21% ` Robert Dewar
1994-12-29 23:05 GNAT not 'getting' CR or LF? Smilin' Ron Finkbine
1995-01-02 4:42 22% ` Robert Dewar
1994-12-30 16:06 "Subtract C, add Ada" Mitch Gart
1995-01-04 22:45 ` Jay M. Martin
1995-01-05 4:37 ` Michael Feldman
1995-01-05 18:08 ` Jay Martin
1995-01-05 23:56 22% ` Robert Dewar
1995-01-03 12:49 Language Lawyers help on rep_specs Jeff Etrick
1995-01-03 14:50 ` Theodore E. Dennison
1995-01-03 18:04 22% ` Robert Dewar
1995-01-03 18:07 22% ` Robert Dewar
1995-01-03 15:06 22% ` Robert Dewar
1995-01-03 15:59 Avionic Proximity Warning CONDIC
1995-01-04 14:48 ` Norman H. Cohen
1995-01-04 18:48 22% ` Robert Dewar
1995-01-03 19:55 FORTRAN Translation to Ada Alexy V. Khrabrov
1995-01-04 1:13 22% ` Robert Dewar
1995-01-05 5:17 GNAT NT 2.0c & LINK32 vs. LINK Mark Riordan
1995-01-05 17:38 20% ` Robert Dewar
1995-01-05 22:38 Data Format Brainstorm Stephen Cacclin
1995-01-07 3:56 ` Mariusz Zydyk
1995-01-07 14:45 21% ` Robert Dewar
1995-01-06 11:45 Programming Libraries in Ada Kai Strempel
1995-01-06 20:44 22% ` Robert Dewar
1995-01-08 5:33 Reference Manual ? Mark Fearer
1995-01-08 14:13 19% ` Robert Dewar
1995-01-09 4:33 GNAT NT & Ada.Direct_IO Mark Riordan
1995-01-09 6:07 20% ` Robert Dewar
1995-01-09 6:10 22% ` Robert Dewar
1995-01-09 14:13 Task Scheduling in Applications Written in Ada Dar_Tzen
1995-01-09 16:37 22% ` Robert Dewar
1995-01-09 21:23 "No" Ada jobs in the Boston area Gregory Aharonian
1995-01-10 19:25 ` Kent Mitchell
1995-01-11 14:31 ` David Emery
1995-01-12 14:18 19% ` Robert Dewar
1995-01-10 10:56 Large Integers? Andre Spiegel
1995-01-10 20:45 ` Charles H. Sampson
1995-01-11 2:39 22% ` Robert Dewar
[not found] ` <SPIEGEL.95Jan11111040@berlin.bruessel.informatik.uni-stuttgart.de>
[not found] ` <3fhjr1$4h8@rational.rational.com>
1995-01-18 23:22 22% ` Robert Dewar
1995-01-10 22:19 "No" Ada jobs in the Boston area Alexy Khrabrov
[not found] ` <3f12uq$ef1@rational.rational.com>
1995-01-12 14:20 21% ` Robert Dewar
1995-01-10 22:20 Run-time checking and speed Tony Leavitt
[not found] ` <3f0prq$3bq@theopolis.orl.mmc.com>
1995-01-12 14:13 16% ` Robert Dewar
[not found] ` <3fa2pk$kbi@felix.seas.gwu.edu>
[not found] ` <EACHUS.95Jan17151835@spectre.mitre.org>
[not found] ` <3fjhrj$9b3@oahu.cs.ucla.edu>
1995-01-20 5:11 19% ` Robert Dewar
1995-01-12 9:39 C++ Envy R.A.L Williams
[not found] ` <3f9bha$r16@gnat.cs.nyu.edu>
[not found] ` <3fcjp5$b0v@cronkite.seas.gwu.edu>
1995-01-16 18:48 22% ` Robert Dewar
[not found] <INFO-ADA%95011109284406@VM1.NODAK.EDU>
1995-01-12 13:57 19% ` GNAT NT & Ada.Direct_IO Robert Dewar
[not found] <TARJEIJ.95Jan11183331@ulrik.uio.no>
1995-01-12 14:24 21% ` Ada.strings.bounded problems? Robert Dewar
[not found] ` <EACHUS.95Jan11170317@spectre.mitre.org>
1995-01-12 18:10 21% ` Robert Dewar
[not found] ` <D29L78.J9@nntpa.cb.att.com>
1995-01-12 18:16 ` Norman H. Cohen
1995-01-13 19:29 ` Mats Weber
[not found] ` <3fduto$ta7@watnews1.watson.ibm.com>
[not found] ` <Mats.Weber-1701951908250001@mlma11.matrix.ch>
1995-01-18 14:27 ` Norman H. Cohen
1995-01-19 16:49 ` Mats Weber
1995-01-21 5:28 22% ` Robert Dewar
[not found] ` <1995Jan19.124412@lglsun.epfl.ch>
1995-01-20 17:00 22% ` Robert Dewar
1995-01-18 17:48 22% ` Robert Dewar
1995-01-12 22:17 22% ` Robert Dewar
[not found] ` <D2D8DC.JvM@nntpa.cb.att.com>
[not found] ` <3fja22$fab@source.asset.com>
1995-01-20 5:12 22% ` Robert Dewar
[not found] ` <D2J8H0.DMu@aplcenmp.apl.jhu.edu>
1995-01-18 5:01 22% ` Robert Dewar
1995-01-19 1:36 ` Keith Thompson
1995-01-19 17:53 ` Jacob Sparre Andersen
1995-01-20 11:12 ` Robb Nebbe
1995-01-20 16:03 ` Magnus Kempe
1995-01-21 18:57 16% ` Robert Dewar
[not found] <3f10sf$9t1@news.dtc.hp.com>
[not found] ` <3f1kig$p0d@newstand.syr.edu>
1995-01-12 16:10 20% ` Ada to C translator Robert Dewar
[not found] <3f1tj4$15q@gap.cco.caltech.edu>
1995-01-12 18:50 18% ` GNAT on Solaris: Help! Robert Dewar
[not found] <1995Jan11.154250@clstac>
1995-01-12 22:14 21% ` ADA-9x done? Any good PC compilers? Robert Dewar
1995-01-13 14:02 ` Howard.Gilbert
[not found] ` <3f9m5u$rc8@gnat.cs.nyu.edu>
[not found] ` <EACHUS.95Jan17120531@spectre.mitre.org>
1995-01-18 23:17 22% ` Robert Dewar
1995-01-19 19:08 ` Robert I. Eachus
1995-01-21 5:31 22% ` Robert Dewar
[not found] <cary-110195174515@macsac09.esl.com>
1995-01-12 22:21 21% ` string literals Robert Dewar
[not found] ` <D2Dnpv.41u@alsys.com>
[not found] ` <3fbtgk$501@gnat.cs.nyu.edu>
[not found] ` <3fcdf4$65n@uuneo.neosoft.com>
1995-01-16 17:30 20% ` Robert Dewar
1995-01-18 13:24 ` Richard G. Hash
1995-01-21 5:20 21% ` Robert Dewar
1995-01-13 8:35 Memory overwrite? Rick Wouters
[not found] ` <3fe5cp$fnq@theopolis.orl.mmc.com>
1995-01-18 18:20 ` Mark A Biggar
1995-01-20 5:19 22% ` Robert Dewar
[not found] <"Jwic53.0.fY6.3v06l"@autan>
1995-01-16 3:25 22% ` Strange behaviour with protected objects Robert Dewar
[not found] <D2Dq0t.Mo4@acsu.buffalo.edu>
[not found] ` <3fbtk3$50o@gnat.cs.nyu.edu>
[not found] ` <3fcf8f$dm6@Starbase.NeoSoft.COM>
1995-01-16 17:53 21% ` Math Lib. for Ada? Ada for X11R6? Robert Dewar
1995-01-18 20:50 ` Matt Kennel
1995-01-20 5:27 22% ` Robert Dewar
[not found] <3etund$hnr@miranda.gmrc.gecm.com>
1995-01-13 1:51 ` "Subtract C, add Ada" David O'Brien
1995-01-14 10:37 ` Keith Thompson
[not found] ` <3fcjgt$b0v@cronkite.seas.gwu.edu>
1995-01-16 18:47 20% ` Robert Dewar
1995-01-17 21:01 Need help with DEC Ada Phil Dennis
1995-01-18 18:23 ` Mats Weber
1995-01-20 5:22 20% ` Robert Dewar
1995-01-17 23:15 Ada95: New_Page at end of file Tom Griest
1995-01-18 23:16 20% ` Robert Dewar
1995-01-18 16:27 Ada explanation? Bob Wells #402
1995-01-20 5:25 21% ` Robert Dewar
1995-01-19 10:43 pragma import problem ( also OS/2 : gnat 4emx ) Ralph Paul
1995-01-20 16:58 21% ` Robert Dewar
1995-01-20 10:20 "Subtract C, add Ada" R.A.L Williams
1995-01-21 15:18 18% ` Robert Dewar
[not found] <m-bartz-1701950936420001@macgalois.ee.memst.edu>
[not found] ` <3fgsin$kc6@info4.rus.uni-stuttgart.de>
[not found] ` <3fhub3$4gv@Starbase.NeoSoft.COM>
1995-01-18 13:50 ` C programmer with Newbie question David O'Brien
[not found] ` <D2MB10.33w@world.std.com>
1995-01-19 9:32 ` Peter Hermann
1995-01-20 16:55 22% ` Robert Dewar
[not found] <3f9g1u$j4m@nps.navy.mil>
[not found] ` <1995Jan16.132400@lglsun.epfl.ch>
[not found] ` <131279@cup.portal.com>
1995-01-20 16:52 22% ` Ada Objects Help! Robert Dewar
[not found] ` <D2H5un.FEr@nntpa.cb.att.com>
[not found] ` <3fcs59$70s@nps.navy.mil>
[not found] ` <3ff186$c19@gnat.cs.nyu.edu>
1995-01-17 17:57 ` ADA " Mats Weber
1995-01-18 17:47 20% ` Robert Dewar
1995-01-20 16:04 ` Mats Weber
1995-01-21 18:59 21% ` Robert Dewar
1995-01-19 11:57 ` Robert M. Wilkinson
1995-01-22 18:06 14% ` Robert Dewar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox