Limitations of Ada

Limitations of Ada

[The Quelisher]

With all this discussion about programming different things ins Ada, I 
got to thinking......Just what are the limitations of the language? I 
mean, is it versitile enough to program a Windows program then turn right 
back around and make a kernel?

Just letting curiosity get the better of me...
-- 
#-----------------------------------------------------------------#
| _                                                   __    __    |
| \\                                                  \ \  / /    |
|  \\        GO                                     __ \ \/ / __  |
|   \\   TALLAHASSEE          * 1971 Karmann Ghia * \ \ \  / / /  |
|    \\  TIGERSHARKS!               * Coupe *        \ \/  \/ /   |
|     \\____                                          \  /\  /    |
|      \_XXX)                                          \/  \/     |
|                                                                 |
|       Live Long and Quelish!....................Kendal          |
#-----------------------------------------------------------------#

Re: Limitations of Ada

[Michael Feldman]

In article <31EF79A3.812@freenet.scri.fsu.edu>,
The Quelisher  <kendal@freenet.scri.fsu.edu> wrote:
>With all this discussion about programming different things ins Ada, I 
>got to thinking......Just what are the limitations of the language? I 
>mean, is it versitile enough to program a Windows program then turn right 
>back around and make a kernel?

Yes. It's as versatile as any other language; it is general-purpose.
I often wonder why anyone would think otherwise?

>Just letting curiosity get the better of me...

Why not satisfy that curiosity by giving it a try?

Mike Feldman

Re: Limitations of Ada

[Nasser Abbasi]

   >From: The Quelisher <kendal@freenet.scri.fsu.edu>

   >With all this discussion about programming different things ins Ada, I 
   >got to thinking......Just what are the limitations of the language? I 
   >mean, is it versitile enough to program a Windows program then turn right 
   >back around and make a kernel?

   >Just letting curiosity get the better of me...



Ada has no known limitations.

bye,
Nasser
-- 
Nasser Abbasi. C/C++/Ada Solaris. GeneAssist - A client/server application 
for Nucleic acid and protein sequence search and analysis. 
Perkin Elmer - Applied BioSystem division. email:  nasser@apldbio.com   
MSEE(control), MSCS, MSCE, FM (Fide Chess Master).

Re: Limitations of Ada

[Bob Munck]

>From: The Quelisher <kendal@freenet.scri.fsu.edu>
>With all this discussion about programming different things ins Ada, I
>got to thinking......Just what are the limitations of the language? 
> 

Ada is unable to exceed the speed of light.

Re: Limitations of Ada

[David Kristola]

In article 6EBF@acm.org, Bob Munck <munck@acm.org> () writes:
>>From: The Quelisher <kendal@freenet.scri.fsu.edu>
>>With all this discussion about programming different things ins Ada, I
>>got to thinking......Just what are the limitations of the language? 
>> 
>
>Ada is unable to exceed the speed of light.

I have been unable to write Ada code that reads a user's mind.

david kristola
Work: davidk@os1.ese.lmsc.lockheed.com
Play: DJKristola@aol.com

My suggestion for Lockheed Martin's next slogan:
"Lockheed Martin, we make things that go BOOM!"

Re: Limitations of Ada

[Ron Thompson]

davidk@OS2.ifs (David Kristola) wrote:

>
>My suggestion for Lockheed Martin's next slogan:
>"Lockheed Martin, we make things that go BOOM!"
>

Yeah, I snipped all the other about C/C++/Ada, Ada
limitations, Java vs Freeze_Dried, etc. The suggestion
above is what is REALLY important in any discussion
of real time embedded old crap that MOST of us have to
support. At least around here anyway.

That, David, is an excellent suggestion. There was a list
floating around a couple of months ago that outlined some
really good ones for the slogan du jour. Try to get yours
on it! A good laugh here that was. LM probably laughed too.

rct
The opinions above are mine and mine alone.

Re: Limitations of Ada

[Ken Garlington]

Ron Thompson wrote:
> 
> davidk@OS2.ifs (David Kristola) wrote:
> 
> >My suggestion for Lockheed Martin's next slogan:
> >"Lockheed Martin, we make things that go BOOM!"
> 
> That, David, is an excellent suggestion.

Of course, for us LM types that build flight control systems,
we might prefer:

"Lockheed Martin, we make things that make _other_ things go BOOM!"

since, when _our_ systems go BOOM, this is considered a Bad Thing :)

-- 
LMTAS - "Our Brand Means Quality"

Re: Limitations of Ada

[Byron B. Kauffman]

Ken Garlington wrote:
> 
> Ron Thompson wrote:
> >
> > davidk@OS2.ifs (David Kristola) wrote:
> >
> > >My suggestion for Lockheed Martin's next slogan:
> > >"Lockheed Martin, we make things that go BOOM!"
> >
> > That, David, is an excellent suggestion.
> 
> Of course, for us LM types that build flight control systems,
> we might prefer:
> 
> "Lockheed Martin, we make things that make _other_ things go BOOM!"
> 
> since, when _our_ systems go BOOM, this is considered a Bad Thing :)
> 
> --
> LMTAS - "Our Brand Means Quality"


Hey, whattaya expect from an ex A-12 avionics guy?

Byron Kauffman
LMTAS - "We Do Falcons Right"

Things that go BOOM (was Re: Limitations of Ada)

[David Kristola]

Just to set the record straight, i am currently working on a missile program
(hopefully, it will go BOOM when and where it is supposed to).

Ken Garlington wrote:
> Of course, for us LM types that build flight control systems,
> we might prefer:
> 
> "Lockheed Martin, we make things that make _other_ things go BOOM!"

That too.

> Byron Kauffman
> LMTAS - "We Do Falcons Right"

An F-16 can make a nice sonic BOOM.

david kristola
Work: davidk@os1.ese.lmsc.lockheed.com
Play: DJKristola@aol.com

My *revised* suggestion for Lockheed Martin's next slogan:
"Lockheed Martin, we make things that go BOOM!, whoosh, ping, wherrrr, pop, shhhh,
hummm (not necessarily the same thing, or at the same time)."

Re: Things that go BOOM (was Re: Limitations of Ada)

[Theodore E. Dennison]

David Kristola wrote:
> 
> Just to set the record straight, i am currently working on a missile program
> (hopefully, it will go BOOM when and where it is supposed to).
> 
> Ken Garlington wrote:
> > Of course, for us LM types that build flight control systems,
> > we might prefer:
> >
> > "Lockheed Martin, we make things that make _other_ things go BOOM!"
> 
> That too.
> 
> > Byron Kauffman
> > LMTAS - "We Do Falcons Right"
> 
> An F-16 can make a nice sonic BOOM.
> 
> david kristola
> Work: davidk@os1.ese.lmsc.lockheed.com
> Play: DJKristola@aol.com
> 
> My *revised* suggestion for Lockheed Martin's next slogan:
> "Lockheed Martin, we make things that go BOOM!, whoosh, ping, wherrrr, pop, shhhh,
> hummm (not necessarily the same thing, or at the same time)."

Well, our engine control/sensor monitoring/actuator controlling software should
neither go BOOM, nor make anything else go BOOM (unless you count the combustion
chamber inside the engine).

Additionally, the folks across the aisle from me in simulations just make things
LOOK like they went BOOM.

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

Re: Things that go BOOM (was Re: Limitations of Ada)

[Ken Garlington]

Theodore E. Dennison wrote:
> 
> Well, our engine control/sensor monitoring/actuator controlling software should
> neither go BOOM, nor make anything else go BOOM (unless you count the combustion
> chamber inside the engine).

Unless of course, your software is used in a weapon system that makes other things
go BOOM (like my software)!

> ..here to help.

Re: Limitations of Ada

[Keith Thompson]

In <31F54DE2.6EBF@acm.org> Bob Munck <munck@acm.org> writes:
> >From: The Quelisher <kendal@freenet.scri.fsu.edu>
> >With all this discussion about programming different things ins Ada, I
> >got to thinking......Just what are the limitations of the language? 
> > 
> 
> Ada is unable to exceed the speed of light.

Why must people continue to spread the myth that Ada is inherently slower
than C?

8-)}

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
"As the most participatory form of mass speech yet developed, the Internet
deserves the highest protection from government intrusion." -- ACLU v. Reno

Re: Limitations of Ada

[David Weller]

In article <31F54DE2.6EBF@acm.org>, Bob Munck  <munck@acm.org> wrote:
>Ada is unable to exceed the speed of light.

Rumor has it that IBM is working on a practical solution to this by
redefining 'c' :-)  (A dual pun if there ever was :-)
-- 
    Visit the Ada 95 Booch Components Homepage: www.ocsystems.com/booch
           This is not your father's Ada -- lglwww.epfl.ch/Ada

Re: Limitations of Ada

[Klaus Wyss]

The Quelisher wrote:
> 
> With all this discussion about programming different things ins Ada, I
> got to thinking......Just what are the limitations of the language? I
> mean, is it versitile enough to program a Windows program then turn right
> back around and make a kernel?
> 
> Just letting curiosity get the better of me...
> --

There are no limitations, as long as you stay in the in the nice clean
ADA world.
If you go to the real dirty computer world, with all the C libraries
(Windows,X11,DCE, DB access .... ) you get a lot of limitations.
For example if your ADA is not based on pthreads you run into problems
with DCE. 

Klaus Wyss
UBS Switzerland

Re: Limitations of Ada

[Robert Dewar]

Klaus says

"There are no limitations, as long as you stay in the in the nice clean
ADA world.
If you go to the real dirty computer world, with all the C libraries
(Windows,X11,DCE, DB access .... ) you get a lot of limitations.
For example if your ADA is not based on pthreads you run into problems
with DCE."


Well of course if you are going to interface to the outside world, you
must make sure that your Ada compiler has the appropriate capabilities.
For example, if you want to interface to C, make sure that the systems
programming annex is supported.

Similarly, it is quite true that if you want to interface to an outside
threads package, then this has implications on the runtime. The statement
above is not quite correct, since DCE uses DCE threads, which are not
compatible with Pthreads (I assume Pthreads means Posix threads), since
they are based on Draft 4, rather than the final version (which was 
draft 10). However, the differences are small.

GNAT uses the DCE threads interface on a number of different machines, and
even on a machine where it uses pthreads (e.g. SGI Irix), it would be
quite easy to build a version based on DCE threads is this were a
requirement.

Re: Limitations of Ada

[David Emery]

...
>, since
> [DCE threads] are based on Draft 4, rather than the final version (which was 
> draft 10). However, the differences are small.
> 

Not THAT small, particularly for an Ada RTS!

            dave

Re: Limitations of Ada

[Theodore E. Dennison]

The Quelisher wrote:
> 
> With all this discussion about programming different things ins Ada, I
> got to thinking......Just what are the limitations of the language? I
> mean, is it versitile enough to program a Windows program then turn right
> back around and make a kernel?

My understanding is that BLISS is required to code a VMS device driver. 
That's the only "Can't" that I ever came across.

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

Re: Limitations of Ada

[Marin David Condic, 407.796.8997, M/S 731-93]

David Weller <dweller@DFW.NET> writes:
>In article <31F54DE2.6EBF@acm.org>, Bob Munck  <munck@acm.org> wrote:
>>Ada is unable to exceed the speed of light.
>
>Rumor has it that IBM is working on a practical solution to this by
>redefining 'c' :-)  (A dual pun if there ever was :-)
>
    But have you heard of IBMs new ultra-super-computer? It's supposed
    to be so fast that it will execute an infinite loop in three
    minutes.

    186,000 mi/sec. It's not just a good idea... It's the law!

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        407.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        407.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "Government is not reason. It is not eloquence. It is a force.
    Like fire, a dangerous servant and a fearful master."

        --  George Washington
===============================================================================

Re: Limitations of Ada

[Kazimir Majorinc]

Hello everybody!

This are limitations of Ada:

1) Not 100 % OO, see Smalltalk
2) Without distributed objects, see Modula-3
3) Lack of MACROS, see C++
4) Small number of operators to overload, see  C++
5) Lack of multiple inheritance, see C++
6) Big language, see BASIC

But, I love her more than C++ although I did wrote only 'hello world'
in Ada. 

________________________________________________
Author:         Kazimir Majorinc, 
Education:      dipl. ing. mathematics           
Address:        Vinagorska 7,                       
                10 000 Zagreb,                      
                Croatia.                           
Work:           prof. math. & comp.sci.              
                XIII. Gimnazija, Zagreb, Croatia
E-mail address: Kazimir.Majorinc@public.srce.hr
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
One who know the secret of the seventh stair

Re: Limitations of Ada

[Brian Rogoff]

kmajor@jagor.srce.hr (Kazimir Majorinc) writes:

   Hello everybody!

Hi!

   This are limitations of Ada:

   1) Not 100 % OO, see Smalltalk

Not a limitation. Ada allows you to write code at a lower level than 
Smalltalk. I see this as a feature, Ada 95 is a multiparadigm language.

   2) Without distributed objects, see Modula-3

A distributed object system could be written in Ada. See also the Distributed 
Systems Annex of Ada 95.

   3) Lack of MACROS, see C++

I'm sympathetic, since I know real (Lisp, not C++) macros are powerful, but 
I found reading Common Lisp macro code pretty painful. Maybe the pain subsides 
after a lot of reading, but I understand the argument in favor of readability 
here. Besides, you can always write a macro language for Ada if you really 
want. There is just no "standard" one.

   4) Small number of operators to overload, see  C++

Agreed. But where do you stop? Do you allow user defined operators? I suppose 
I would like to be able to create user defined arrays that behaved just like 
built-ins.

   5) Lack of multiple inheritance, see C++

Show me a problem which requires MI and can't be solved fairly easily in 
Ada 95. There are quite a few online papers describing what you can do.

   6) Big language, see BASIC

Is that a limitation?

-- Brian

Re: Limitations of Ada

[Robert Dewar]

Kazimir commented on alledged limitations of Ada

1) Not 100 % OO, see Smalltalk

    Shrug, this is more of a religeous comment than a technical one!

2) Without distributed objects, see Modula-3

    This is wrong, read annex E

3) Lack of MACROS, see C++

    This is an intentional part of the design, see Steelman

4) Small number of operators to overload, see  C++

    Incomprehensible, all operators and subprograms are overloadable in Ada

5) Lack of multiple inheritance, see C++

    Not necessarily a lack at all, see Tucker Taft's paper

6) Big language, see BASIC

    More of a comment, than a limitation. After all you could equally say
    that it is a limitation of BASIC that it is a small language.

Re: Limitations of Ada

[Robert A Duff]

In article <4tlpfa$cr9@bagan.srce.hr>,
Kazimir Majorinc <kmajor@jagor.srce.hr> wrote:
>This are limitations of Ada:
>...
>2) Without distributed objects, see Modula-3

Ada has this.  See E.4.2.

- Bob

Re: Limitations of Ada

[Fraser Wilson]

kmajor@jagor.srce.hr (Kazimir Majorinc) writes:

>This are limitations of Ada:

As Douglas Adams would say, this is obviously some new use of the
word "limitation" that I haven't been previously aware of. :-)

>1) Not 100 % OO, see Smalltalk

That's good, because OO isn't appropriate for everything.

>2) Without distributed objects, see Modula-3

Depending on your definition of distributed objects, Annexe E is
probably what you're looking for.

>3) Lack of MACROS, see C++

Lack of macros is known as a Good Thing.

>4) Small number of operators to overload, see  C++

Also known as a Good Thing.

>5) Lack of multiple inheritance, see C++

Does this mean that multiple inheritance in C++ is the One True Way?
There's different ways of doing MI, and it's not clear which flavour
is best.  Under such conditions, it seems that leaving it out of the
standard was a good decision.

>6) Big language, see BASIC

So is C++.  In fact, the C++ standard is bigger than the Ada standard.
However, Ada is very good at letting you take only the bits you need.

>But, I love her more than C++ although I did wrote only 'hello world'
>in Ada. 

It's a good start.  And she is fabulous :-)

Fraser.
--
    ____ Fraser Wilson          | email: fraser@cs.mu.oz.au     __o
    \  / The more I learn of    | voice: +61 3 9287 9193      _-\<,_
     \/  C++, the more I like   | fax:   +61 3 9348 1184     (_)/ (_)
           --- Ada 95 ---       | www:   http://www.cs.mu.oz.au/~fraser/

Re: Limitations of Ada

[Brian Rogoff]

dewar@cs.nyu.edu (Robert Dewar) writes:
   Kazimir commented on alledged limitations of Ada

   4) Small number of operators to overload, see  C++

       Incomprehensible, all operators and subprograms are overloadable in Ada

I expect that what Kazimir meant was something like 

   4) Small number of binary infix (and unary prefix ) operators whose 
      meanings can be assigned by the user.

Overloading is an orthogonal issue; note that Eiffel 3 allows one to define 
brand new infix operators, but does not have overloading. 

This is a legitimate complaint. I have wanted additional operators for image 
processing operations. However, it is not really a "limitation", just a 
tiny syntactic inconvenience. I assume the same reasoning that led to the 
ban on macros (readability and potential for abuse) led to this decision.

-- Brian

Re: Limitations of Ada

[Spasmo]

Kazimir Majorinc (kmajor@jagor.srce.hr) wrote:
: Hello everybody!

: This are limitations of Ada:

: 1) Not 100 % OO, see Smalltalk

Why is this a limitation?  Not being 100% OO is not a limitation,
it's a design decision.  You can use OO in Ada or you can choose
not to, this to me is a superior choice to being forced to use
OO in a 100% OO language like Smalltalk.


: 2) Without distributed objects, see Modula-3

Not quite sure what you mean by this.  


: 3) Lack of MACROS, see C++

That's an advantage.  If you notice in C++ one of the first
things they tell you when you get to inlining functions is
"Now you don't have to use macros!".  Since macros are
textual substitution you can really mess things up in a
big way.  Arguments to function like macros aren't evaluated
which can lead to innaccurate results (this is a famous
problem of macros, therefore the ugly notation where
everything is fully parenthesized in an attempt to
combat this deficency), and since macros are just
pure textual substitution you can do some very strange
things with them that can send readability out the
window.  You can assemble functions to be called that
won't be seen until preprocessing time, you can have
really wacked out notation, etc...  C can keep its
macros, I couldn't care less about them.  I've
done fine without them in other languages and I
have no doubt I will continue to do well without
them in the future.


: 4) Small number of operators to overload, see  C++

This is a two pronged situation.  On the one hand you've
got a ton of C++ operators which are really useful for
saving typing and obfusicating code (something C and C++
are famous for), but in all reality they don't do anything
new.  ie: ++, --, +=, etc... are just shorthand and
can be accomplished by the standard operators +, and -.
I was about to get on a tangent about C++ and how the
way it treats operators plays havoc with generic functions
(requiring ugly hacks and kludges) but I won't :)


: 5) Lack of multiple inheritance, see C++

There are those who would say this is an advantage.  Even in C++
folks recommend that if you use multiple inheritance, you do so
very sparingly and if I'm not mistaken there was serious consideration
as to whether or not include this "feature" since many say it does
more harm than good.  


: 6) Big language, see BASIC

Even if it is, so what?  As long as a language is easy to use, 
powerful, and helps me produce better programs, I couldn't
care less about the size.


: But, I love her more than C++ although I did wrote only 'hello world'
: in Ada. 

I've done more, and while I'm still an Ada newbie, I can say that
this is one sweet language.  The more I look at Ada, the more I
look down on C and C++.



: ________________________________________________
: Author:         Kazimir Majorinc, 
: Education:      dipl. ing. mathematics           
: Address:        Vinagorska 7,                       
:                 10 000 Zagreb,                      
:                 Croatia.                           
: Work:           prof. math. & comp.sci.              
:                 XIII. Gimnazija, Zagreb, Croatia
: E-mail address: Kazimir.Majorinc@public.srce.hr
: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: One who know the secret of the seventh stair


--
Spasmo
"Everyone has secrets, but sometimes you get caught,
 So if it's just between us, my silence can be bought"
	"Blackmail" by Sloppy Seconds

Re: Limitations of Ada

[mpost]

Spasmo (cosc19z5@Bayou.UH.EDU) wrote:
: Kazimir Majorinc (kmajor@jagor.srce.hr) wrote:
: : 5) Lack of multiple inheritance, see C++
: 
: There are those who would say this is an advantage.  Even in C++
: folks recommend that if you use multiple inheritance, you do so
: very sparingly and if I'm not mistaken there was serious consideration
: as to whether or not include this "feature" since many say it does
: more harm than good.  

Just a side note, I've been watching this thread as an interested student 
of computer science who knows C++ but currently has an internship with a 
DoD contractor doing Ada coding.  As far as MI goes, you're invited to 
check out a paper I wrote for my OOP class which discusses MI.  I found 
it to be an interesting topics and I welcome comments both on the subject 
and the paper.  The paper can be found on my homepage at 
http://w3.gwis.com/~mpost.

Mike

Re: Limitations of Ada

[Bob Kitzberger]

Kazimir Majorinc (kmajor@jagor.srce.hr) wrote:

: This are limitations of Ada:
: 3) Lack of MACROS, see C++

That's a feature.



--
Bob Kitzberger	      Rational Software Corporation       rlk@rational.com
http://www.rational.com http://www.rational.com/pst/products/testmate.html

Re: Limitations of Ada

[Jack W Scheible]

In article <4tr86p$fvd@rational.rational.com> rlk@rational.com (Bob Kitzberger) writes:
>Kazimir Majorinc (kmajor@jagor.srce.hr) wrote:
>
>: This are limitations of Ada:
>: 3) Lack of MACROS, see C++
>
>That's a feature.
>
There is no reason at all that the C pre-processor cannot be
run on Ada source before sending it to the compiler.  Therefore,
one _can_ use macros, but it is neither standard nor advisable - 
macros can be a source of very hard-to-find bugs.

-jack

Re: Limitations of Ada

[Robert Dewar]

Jack said

"There is no reason at all that the C pre-processor cannot be
run on Ada source before sending it to the compiler.  Therefore,
one _can_ use macros, but it is neither standard nor advisable -
macros can be a source of very hard-to-find bugs."

Actually there is one reason: attributes will cause troubles, since they
don't look like valid C tokens.

But largely this is true, and in any case, other macro processors can be
used.

Re: Limitations of Ada

[Keith Thompson]

In <4tsvs7$ctk@portal.gmu.edu> jscheibl@mason2.gmu.edu (Jack W Scheible) writes:
> There is no reason at all that the C pre-processor cannot be
> run on Ada source before sending it to the compiler.  Therefore,
> one _can_ use macros, but it is neither standard nor advisable - 
> macros can be a source of very hard-to-find bugs.

Actually, there is a reason.  The C preprocessor chokes on some Ada
constructs.  The ISO C standard requires the input to the preprocessing
phase to be a valid token stream.  I don't remember the exact details,
but one consequence is that an apostrophe that's not part of a character
literal (e.g., in an Ada attribute) is illegal.

Here's an example:

package Foo is
#ifdef FIRST
   X : Integer := Integer'First;
#else
   X : Integer := Integer'Last;
#endif
end Foo;

The "cc -E" command under Solaris complains:

"foo.ads", line 5: invalid input token: 'Last;

Of course, there's nothing in the ISO C standard that requires the
preprocessor to exist as a separate program, or "cc -E" to behave in any
particular fashion.  Similarly, there's nothing preventing someone from
implementing a C-like preprocessor with fewer restrictions.  However,
using the C preprocessor on Ada code is likely to cause problems, as
the example above shows.

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
"As the most participatory form of mass speech yet developed, the Internet
deserves the highest protection from government intrusion." -- ACLU v. Reno

Re: Limitations of Ada

[Jack W Scheible]

In article <DvJyKB.9DC@thomsoft.com> kst@thomsoft.com (Keith Thompson) writes:
>In <4tsvs7$ctk@portal.gmu.edu> jscheibl@mason2.gmu.edu (Jack W Scheible) writes:
>> There is no reason at all that the C pre-processor cannot be
>> run on Ada source before sending it to the compiler.  Therefore,
>> one _can_ use macros, but it is neither standard nor advisable - 
>> macros can be a source of very hard-to-find bugs.
>
>Actually, there is a reason.  The C preprocessor chokes on some Ada
>constructs.  The ISO C standard requires the input to the preprocessing
>phase to be a valid token stream.  I don't remember the exact details,
>but one consequence is that an apostrophe that's not part of a character
>literal (e.g., in an Ada attribute) is illegal.
>
>Here's an example:
>
>package Foo is
>#ifdef FIRST
>   X : Integer := Integer'First;
>#else
>   X : Integer := Integer'Last;
>#endif
>end Foo;
>
>The "cc -E" command under Solaris complains:
>
>"foo.ads", line 5: invalid input token: 'Last;
>

The above code works just fine with the command "cpp -P" under Solaris.
It is _still_ a bad idea.

-jack