Re: Some questions about Ada.

Re: Some questions about Ada.

[Robert A Duff]

In article <DqrD2C.Jyr@undergrad.math.uwaterloo.ca>,
Carl Laurence Gonsalves <clgonsal@undergrad.math.uwaterloo.ca> wrote:
>One thing I'm wondering about is packages. I've heard that packages are
>"better" than than the way C++ uses classes. I'm curious as to why this is.
>Modula-3 has modules (which are similar, AFAIK, to Ada's packages) and
>"object types" (classes) as two distinct entities. I'v always thought that
>C++'s way of allowing just about anything to be nested in a class much
>cleaner and simpler. (and for the record, I was programming in Modula-3
>before I was programming in C++) So are packages better? Why?

This question has been discussed endlessly here.  Some folks think the
Ada/Modula-3 way is better.  Some think the C++/Smalltalk way is better.
Check out the recent thread on Eiffel vs. Ada 95, for some arguments
both ways.  I happen to think the Ada/Modula-3 way is better, but I
don't think it's all that important -- it's mostly a notational
difference.

>Second, I've been wondering why Ada is case-insensitive. I'm aware that Ada
>was very carefully designed, so I'm thinking there must be some reason it
>was made case-insensitive rather than case-sensitive, but I can't imagine
>what that reason could be.

There are many fanatics who think case-sensitive is "obviously" the only
way to go, and many fanatics who think case-insensitive is "obviously"
the way to go.  People get very hot about this particular issue.
Apparently, you're one of the former, and the designers of Ada 83 were
the latter.

IMHO, it doesn't matter all that much.  If Ada were case sensitive, and
C++ case insensitive, I would still think Ada is better for most
purposes.  It all depends on what you're used to.  Mathemeticians are
perfectly happy to make x and X mean two different things, and they've
been around a lot longer than computers, so...

In any case, this decision was set down in Ada 83, and Ada 95 wasn't
about to change it.  (Same thing with C++ -- the reason C++ is case
sensitive is because C is case sensitive -- it has nothing to do with
whether Stroustrup thinks it's a good idea.)

The problem with case sensitivity, is that you can define two things i
and I that are different variables, and that makes code less readable.
The problem with case INsensitivity, is that you can define a variable
I, and refer to it as i, and that makes code less readable.  IMHO, the
"right" solution is neither one.  How about this rule:

    Overload resolution is performed in a case INsensitive manner.

    AFTER overload resolution, a legality rule is that each reference
    to something has to use the same case as the declaration.

    And, oh, by the way, make everything overloadable, not just
    subprogram names.

?

This would allow you to declare two things with the same name but for
case, so long as they are distinguishable by the overload resolution
rules.  And it would prevent the confusing thing of referring to I as i.

Whatever the overload resolution rules are, if they tolerate two things
called I and I, then they will tolerate two things called I and i.  But
having defined I and i, one has to refer to them in the right case.

Now, is this legal:

    procedure P(t: T);

?  Well, that depends on whether your overloading rules can distinguish
variables from types.  (In Ada, variable and type names are not
overloadable, which has nothing to do with the case-sensitivity rules.
If the above *were* legal, I wouldn't want a reference to t or T to
depend *merely* on case.  I would want the syntactic context to provide
clues as well.)

- Bob

Some questions about Ada.

[Carl Laurence Gonsalves]

I've got a couple of questions about Ada. I have to confess that I've never
written a single line of Ada code. I've got experience in C, C++, Modula-3,
Java, and Scheme, and several other languages. I've recently become
interested in finding out about Ada, partly because I've noticed that both
Java and Modula-3 seem to have been influenced by Ada's design, and I think
both languages are very good.

One thing I'm wondering about is packages. I've heard that packages are
"better" than than the way C++ uses classes. I'm curious as to why this is.
Modula-3 has modules (which are similar, AFAIK, to Ada's packages) and
"object types" (classes) as two distinct entities. I'v always thought that
C++'s way of allowing just about anything to be nested in a class much
cleaner and simpler. (and for the record, I was programming in Modula-3
before I was programming in C++) So are packages better? Why?

Second, I've been wondering why Ada is case-insensitive. I'm aware that Ada
was very carefully designed, so I'm thinking there must be some reason it
was made case-insensitive rather than case-sensitive, but I can't imagine
what that reason could be.

Any explanations would be appreciated.

(BTW, if either of these questions is a FAQ, please forgive me. I haven't
gotten around to getting a copy of the comp.lang.ada FAQ yet)

-- 
        Carl Laurence Gonsalves - clgonsal@undergrad.math.uwaterloo.ca
                   Computer Science, University of Waterloo
               http://www.undergrad.math.uwaterloo.ca/~clgonsal/
                   http://www.csclub.uwaterloo.ca/~clgonsal/

Re: Some questions about Ada.

[Dave Jones]

Carl Laurence Gonsalves wrote:
> I've got a couple of questions about Ada. I have to confess that I've never
> written a single line of Ada code. I've got experience in C, C++, Modula-3,
> Java, and Scheme, and several other languages. I've recently become
> interested in finding out about Ada, partly because I've noticed that both
> Java and Modula-3 seem to have been influenced by Ada's design, and I think
> both languages are very good.
>

My opinion:  Ada95 is the best all-around language for software engineering.  
C++ is awful.  Nevertheless, if I were starting a project today, I would 
probably choose to use C++.  Why?:  More (and better and cheaper) tools are 
available for C++, more programmers are trained to program in C++, et cetera.
 
> One thing I'm wondering about is packages. I've heard that packages are
> "better" than than the way C++ uses classes. I'm curious as to why this is.
> Modula-3 has modules (which are similar, AFAIK, to Ada's packages) and
> "object types" (classes) as two distinct entities. I'v always thought that
> C++'s way of allowing just about anything to be nested in a class much
> cleaner and simpler. (and for the record, I was programming in Modula-3
> before I was programming in C++) So are packages better? Why?
>

I would not say that packages are necessarily better.  They are, however, easier
to read and maintain than C++ classes.  (Of course, if you switched from a well-
designed language like Modula-3 to C++, maintainability and ease of reading are
probably secondary concerns for you.)  By the way, Ada95 is fully object oriented, 
so you can create classes (But be careful:  Ada uses different terms for its 
object-oriented constructs than other languages do.).
 
> Second, I've been wondering why Ada is case-insensitive. I'm aware that Ada
> was very carefully designed, so I'm thinking there must be some reason it
> was made case-insensitive rather than case-sensitive, but I can't imagine
> what that reason could be.
>

This was done on purpose.  Although it gives the programmer less flexibility, 
it does make for more reliable programs:  If you have ever tried to maintain
a C program where This and tHIS do not mean the same thing, you know what I mean.

-- Dave Jones
davedave@io.com

Re: Some questions about Ada.

[Darren C Davenport]

Dave Jones (davedave@io.com) wrote:
: Carl Laurence Gonsalves wrote:
: > I've got a couple of questions about Ada. I have to confess that I've never
: > written a single line of Ada code. I've got experience in C, C++, Modula-3,
: > Java, and Scheme, and several other languages. I've recently become
: > interested in finding out about Ada, partly because I've noticed that both
: > Java and Modula-3 seem to have been influenced by Ada's design, and I think
: > both languages are very good.
: >

: My opinion:  Ada95 is the best all-around language for software engineering.  
: C++ is awful.  Nevertheless, if I were starting a project today, I would 
: probably choose to use C++.  Why?:  More (and better and cheaper) tools are 
: available for C++, more programmers are trained to program in C++, et cetera.

This is very debatable. Development tools for C++ on Unix platforms are not
cheap and they are not very good.  Rational's Apex tool, for example, while not
terribly cheap is a much better development environment.  There are still 
not that many good C++ programmers and any that are good can easily 
transition to Ada or any other language.  I'd rather have sw engineers 
that can adapt to any language.

Darren

Re: Some questions about Ada.

[Dave Jones]

Carl Laurence Gonsalves wrote:
> 
> In article <3188F63D.3325@io.com>, Dave Jones  <davedave@io.com> wrote:
> >By the way, Ada95 is fully object oriented
> >so you can create classes (But be careful:  Ada uses different terms for its
> >object-oriented constructs than other languages do.).
> 
> I've heard about Ada 95. I wasn't able to find any books on it though, so I
> picked up a copy of "Programming in Ada" 3rd Ed. by J.G.P.Barnes. It
> doesn't cover Ada 95 (it's copyright date is '89). I'll go and look on the
> web for stuff about Ada 95, probably tomorrow, actually.
> As far as Ada95 books are concerned, the following are all pretty good:

Barnes, Programming in Ada95
Cohen, Ada as a Second Language, 2nd edition
Feldman & Koffman, Ada95: Problem Solving and Program Design, 2nd edition
Smith, Object-Oriented Software in Ada 95
Naiditch, Redezvous with Ada95

The book by Feldman is an introduction-to-programming book, but it does manage
to cover most of the features of Ada 95.

The book by Cohen is huge (and expensive!:  US$60 in paperback).  It covers 
just about every feature of a very large language.  (BTW, Cohen follows this
newsgroup.)

Barnes was a major contributor to the original version of Ada.  Unlike his 
previous books, this one is organized in more of a tutorial fashion and less
of a handbook fashion.  

The book by Smith is an introduction to Ada 95 and object-oriented methods for
programmers with some experience.  It seems to have been written to be a 
textbook.  It contains a tutorial which guides you in the building of a 
sample application.

Naiditch's book is on about the same level as Barnes' book with a similar 
target audience.

There are also some Ada on-line tutorials.  You can get a list of them from:
http://sw-eng.falls-church.va.us/AdaIC/ed-train/Welcome.html .

On another subject entirely:  Modula-3 is available for PC's (at least DEC
claims it is -- I haven't tried it out yet).  See the following for more:
http://www.research.digital.com/SRC/modula-3/html/home.html .  

-- Dave Jones
davedave@io.com

Re: Some questions about Ada.

[Spencer Allain]

In article <Dqt9nA.o5n@undergrad.math.uwaterloo.ca> clgonsal@undergrad.math.uwaterloo.ca (Carl Laurence Gonsalves) writes:

   In article <3188F63D.3325@io.com>, Dave Jones  <davedave@io.com> wrote:
   >Carl Laurence Gonsalves wrote:
   >> I've got a couple of questions about Ada. I have to confess that
   >> I've never written a single line of Ada code. I've got
   >> experience in C, C++, Modula-3, Java, and Scheme, and several
   >> other languages. I've recently become interested in finding out
   >> about Ada, partly because I've noticed that both Java and
   >> Modula-3 seem to have been influenced by Ada's design, and I
   >> think both languages are very good.
   >
   > My opinion: Ada95 is the best all-around language for software
   > engineering. C++ is awful.  Nevertheless, if I were starting a
   > project today, I would probably choose to use C++.  Why?: More
   > (and better and cheaper) tools are
   > available for C++, more programmers are trained to program in
   > C++, et cetera.

   I'm aware of the awfulness of C++. It's a lot more widespread
   though, which is one of the primary reasons I use it. It isn't the
   only language I use though, and I take every chance I get to gripe
   about the various nasties in C++.

   >> One thing I'm wondering about is packages. I've heard that
   >> packages are "better" than than the way C++ uses classes. I'm
   >> curious as to why this is. Modula-3 has modules (which are
   >> similar, AFAIK, to Ada's packages) and "object types" (classes)
   >> as two distinct entities. I'v always thought that C++'s way of
   >> allowing just about anything to be nested in a class much
   >> cleaner and simpler. (and for the record, I was programming in
   >> Modula-3 before I was programming in C++) So are packages
   >> better? Why?
   >
   > I would not say that packages are necessarily better.  They are,
   > however, easier to read and maintain than C++ classes.  (Of
   > course, if you switched from a well designed language like
   > Modula-3 to C++, maintainability and ease of reading are
   > probably secondary concerns for you.)  

   I didn't "switch" to C++. I still use Modula-3 when appropriate to
   the task. Of course, this limits it to UNIX only stuff, since
   that's pretty well the only kind of platform Modula-3 really works
   on. Modula-3's also got it's own share of problems that make my
   skin crawl.

I wouldn't say that Modula-3 only _really_ works on UNIX platforms.
Sure it works best on UNIX platforms, but there are some good DOS 
ports, and the SRC-M3 Windows NT/95 port is almost to the point
of being as good as the UNIX port.  Anyway, that's not the issue,
nor is the fact that every language contains design decisions
that make your skin want to crawl.

   As for the "ease of reading thing", I don't find Ada or Modula-3
   code especially easy to read. Yes, C++ can be heavily obfuscated,
   which is a problem with it. But well written C++ code is quite
   readable. It wouldn't be too hard to imagine a derivative of C++
   which disallows many of the constructs in C++ that lead to classic
   unreadable code.

I'm also not going to touch readability because I've also used Ada,
Modula-3, C++, Perl, etc. and have formed opinions that probably don't
apply to other people.

   In any case, I'm not here to argue about subjective issues like
   readability. Why would you say that packages are easier to maintain
   than C++ classes? From what I can tell they seem quite a lot like
   Modula-3's modules & interfaces. My main gripe about C++ (here)
   would be that the public and private parts are kept together. It
   would be nice if they could be placed, for example, in separate
   files.

I'm sure there are people who will claim that one or the other is
always superior to the other, but I believe they simply make
different trade-offs.  Classes make it easy to encapsulate most
if not all of the operations on an object type.  Packages make
it easier to group different object types and their operations
together.

Some camps will claim that all object types should be completely
independent and wholly partioned from any other object type
(excluding inheritance of course), and others will argue that
there is cross-over between different object types in the real
world that cannot be modelled through inheritance alone.  These 
associations have always been difficult to model, but classes
make you want to partition the world by almost forgetting about
them because it becomes a significant chore to by-pass the
general class concepts in a clean manner.

As to your concern about why the public and private parts need to
be specified together in C++, the best you can do to use
different files is:

class A
{
public:
  // stuff
private:
  #include "A_private.hh"
};

Whenever a change to the private section of a C++ class changes,
every other file dependent upon that class needs to know that,
unlike in Modula-3, Java, Smalltalk, etc.  The reason for this is
because C++ allows objects to exist on the stack, where the size
has to be known at compile time.  The other languages use a "pointer"
to a block of memory for their objects, and therefore don't have
to require that all modules have access to the private sections
at compile time.

   --
   Carl Laurence Gonsalves - clgonsal@undergrad.math.uwaterloo.ca
   Computer Science, University of Waterloo
   http://www.undergrad.math.uwaterloo.ca/~clgonsal/
   http://www.csclub.uwaterloo.ca/~clgonsal/


-Spencer

----------------------------------------------------------------------
Spencer Allain                    E-mail:  spencer@era.com
Engineering Research Associates   Phone :  (703) 734-8800 x1414
1595 Spring Hill Road             Fax   :  (703) 827-9411
Vienna, VA  22182-2235

<A HREF=http://www.research.digital.com/SRC/modula-3/html/home.html>
             Modula-3 Home Page DEC SRC</A>
<A HREF=http://www.vlsi.polymtl.ca/m3/>Modula-3 FAQ, etc. </A>
----------------------------------------------------------------------

Re: Some questions about Ada.

[Michael Feldman]

In article <Dqt9nA.o5n@undergrad.math.uwaterloo.ca>,
Carl Laurence Gonsalves <clgonsal@undergrad.math.uwaterloo.ca> wrote:

[snip]

>I've heard about Ada 95. I wasn't able to find any books on it though, so I
>picked up a copy of "Programming in Ada" 3rd Ed. by J.G.P.Barnes. It
>doesn't cover Ada 95 (it's copyright date is '89). I'll go and look on the
>web for stuff about Ada 95, probably tomorrow, actually.

For a list of Ada 95 books with brief reviews, look at

http://www.seas.gwu.edu/faculty/mfeldman/ada95books.html

This is also linked from Home of the Brave Ada Programmers,

http://lglwww.epfl.ch/Ada/

which contains lots of other goodies, like a very well done HTML
tutorial on Ada 95 for C++ programmers, a general HTML tutorial
on Ada 95 (Lovelace), etc.

Good luck!

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) 
http://www.seas.gwu.edu/faculty/mfeldman
------------------------------------------------------------------------
       Pork is all that money the government gives the other guys.
------------------------------------------------------------------------
Ada on the WWW: http://lglwww.epfl.ch/Ada/ or http://info.acm.org/sigada/
------------------------------------------------------------------------

Re: Some questions about Ada.

[Adam Beneschan]

clgonsal@undergrad.math.uwaterloo.ca (Carl Laurence Gonsalves) writes:
>
>I'v also had to maintain Pascal programs where "end" was capitalized in
>three different ways, at random. Case insensitivity makes the code harder
>to read and harder to maintain, because one can be misled into thinking
>that two different capitalizations of the same thing are distinct. . . .

I don't understand this at all.  As far as I can see, about the only
way you can be misled into thinking two different capitalizations mean
different things is if you're used to programming only in C/C++ (or
Modula).  Expecting different capitalizations to mean different things
doesn't come from experience with most other well-known programming
languages, since they don't care about case.  And it certainly can't
come from any of our other learning; if I see a word capitalized at
the beginning of a sentence, I am not misled into thinking its meaning
is different from an entirely lower-case word.

                                -- Adam

Re: Some questions about Ada.

[Carl Laurence Gonsalves]

In article <3188F63D.3325@io.com>, Dave Jones  <davedave@io.com> wrote:
>Carl Laurence Gonsalves wrote:
>> I've got a couple of questions about Ada. I have to confess that I've never
>> written a single line of Ada code. I've got experience in C, C++, Modula-3,
>> Java, and Scheme, and several other languages. I've recently become
>> interested in finding out about Ada, partly because I've noticed that both
>> Java and Modula-3 seem to have been influenced by Ada's design, and I think
>> both languages are very good.
>
>My opinion:  Ada95 is the best all-around language for software engineering.  
>C++ is awful.  Nevertheless, if I were starting a project today, I would 
>probably choose to use C++.  Why?:  More (and better and cheaper) tools are 
>available for C++, more programmers are trained to program in C++, et cetera.

I'm aware of the awfulness of C++. It's a lot more widespread though, which
is one of the primary reasons I use it. It isn't the only language I use
though, and I take every chance I get to gripe about the various nasties in
C++.

>> One thing I'm wondering about is packages. I've heard that packages are
>> "better" than than the way C++ uses classes. I'm curious as to why this is.
>> Modula-3 has modules (which are similar, AFAIK, to Ada's packages) and
>> "object types" (classes) as two distinct entities. I'v always thought that
>> C++'s way of allowing just about anything to be nested in a class much
>> cleaner and simpler. (and for the record, I was programming in Modula-3
>> before I was programming in C++) So are packages better? Why?
>
>I would not say that packages are necessarily better.  They are, however, easi
>to read and maintain than C++ classes.  (Of course, if you switched from a wel
>designed language like Modula-3 to C++, maintainability and ease of reading ar
>probably secondary concerns for you.)  

I didn't "switch" to C++. I still use Modula-3 when appropriate to the
task. Of course, this limits it to UNIX only stuff, since that's pretty
well the only kind of platform Modula-3 really works on. Modula-3's also
got it's own share of problems that make my skin crawl.

As for the "ease of reading thing", I don't find Ada or Modula-3 code
especially easy to read. Yes, C++ can be heavily obfuscated, which is a
problem with it. But well written C++ code is quite readable. It wouldn't
be too hard to imagine a derivative of C++ which disallows many of the
constructs in C++ that lead to classic unreadable code.

In any case, I'm not here to argue about subjective issues like
readability. Why would you say that packages are easier to maintain than
C++ classes? From what I can tell they seem quite a lot like Modula-3's
modules & interfaces. My main gripe about C++ (here) would be that the public
and private parts are kept together. It would be nice if they could be
placed, for example, in separate files.

>By the way, Ada95 is fully object oriented
>so you can create classes (But be careful:  Ada uses different terms for its 
>object-oriented constructs than other languages do.).

I've heard about Ada 95. I wasn't able to find any books on it though, so I
picked up a copy of "Programming in Ada" 3rd Ed. by J.G.P.Barnes. It
doesn't cover Ada 95 (it's copyright date is '89). I'll go and look on the
web for stuff about Ada 95, probably tomorrow, actually.

>> Second, I've been wondering why Ada is case-insensitive. I'm aware that Ada
>> was very carefully designed, so I'm thinking there must be some reason it
>> was made case-insensitive rather than case-sensitive, but I can't imagine
>> what that reason could be.
>
>This was done on purpose.  Although it gives the programmer less flexibility, 
>it does make for more reliable programs:  If you have ever tried to maintain
>a C program where This and tHIS do not mean the same thing, you know what I 
>mean.

I'v also had to maintain Pascal programs where "end" was capitalized in
three different ways, at random. Case insensitivity makes the code harder
to read and harder to maintain, because one can be misled into thinking
that two different capitalizations of the same thing are distinct. The
varying capitalizations that result from different people going in and
modifying the code results in a distracting mish-mash of capitalization
styles.

If it was intended to prevent variables that look similar except for case
then that's what should've been done: make the language case-sensitive, but
don't allow the creation of anything that has the same case-insensitive
name. ie: if I create something called "foo" then I can't create something
called "Foo", nor can I access something called "foo".

But I think that isn't a very good restriction. A very common convention in
C and in other case sensitive languages (like Modula-3) is to give a type
an upper-case name, and a local general purpose instance of that type has a
lower-case name. I imagine Ada programs are filled with variables called
"myWindow" or "theTable".

-- 
        Carl Laurence Gonsalves - clgonsal@undergrad.math.uwaterloo.ca
                   Computer Science, University of Waterloo
               http://www.undergrad.math.uwaterloo.ca/~clgonsal/
                   http://www.csclub.uwaterloo.ca/~clgonsal/

Re: Some questions about Ada.

[Laurent Guerby]

Robert A Duff writes
: In article <DqrD2C.Jyr@undergrad.math.uwaterloo.ca>,
[deleted]
: Ada/Modula-3 way is better.  Some think the C++/Smalltalk way is better.
                                                  ^^^^^^^^^

   Do you mean Eiffel here ? I don't  see C++ closer to Smalltalk than
Ada or Modula-3, in fact, Smalltalk is very close to Smalltalk ;-).

: >Second, I've been wondering why Ada is case-insensitive. I'm aware that Ada
: >was very carefully designed, so I'm thinking there must be some reason it
: >was made case-insensitive rather than case-sensitive, but I can't imagine
: >what that reason could be.
[deleted]
: The problem with case sensitivity, is that you can define two things i
: and I that are different variables, and that makes code less readable.
: The problem with case INsensitivity, is that you can define a variable
: I, and refer to it as i, and that makes code less readable.  IMHO, the
: "right" solution is neither one.  How about this rule:
: 
:     Overload resolution is performed in a case INsensitive manner.
: 
:     AFTER overload resolution, a legality rule is that each reference
:     to something has to use the same case as the declaration.
: 
:     And, oh, by the way, make everything overloadable, not just
:     subprogram names.
: 
: ?

   Note that  the GNAT  style  switch works exactly   this way  (if  I
remember well), and consider casing inconsistency as a fatal error.

-- 
--  Laurent Guerby, student at Telecom Bretagne (France), Team Ada.
--  "Use the Source, Luke. The Source will be with you, always (GPL)."
--  http://www-eleves.enst-bretagne.fr/~guerby/ (GATO Project).
--  Try GNAT, the GNU Ada 95 compiler (ftp://cs.nyu.edu/pub/gnat).

Re: Some questions about Ada.

[Robert A Duff]

In article <4xrat20zh0.fsf@leibniz.enst-bretagne.fr>,
Laurent Guerby <Laurent.Guerby@enst-bretagne.fr> wrote:
>Robert A Duff writes
>: In article <DqrD2C.Jyr@undergrad.math.uwaterloo.ca>,
>[deleted]
>: Ada/Modula-3 way is better.  Some think the C++/Smalltalk way is better.
>                                                  ^^^^^^^^^
>
>   Do you mean Eiffel here ? I don't  see C++ closer to Smalltalk than
>Ada or Modula-3, in fact, Smalltalk is very close to Smalltalk ;-).

I meant Smalltalk.  Eiffel is in this class, too.

I agree that C++ and Smalltalk are quite different animals.  However, in
the particular respect I was talking about, they are the same: the unit
of modularity is the class, and the operations are thought to live
inside each object of the class.  This leads to the prefix notation that
some love and some hate (and some erroneously think constitutes the
essence of OOP).

>   Note that  the GNAT  style  switch works exactly   this way  (if  I
>remember well), and consider casing inconsistency as a fatal error.

Makes sense.  Of course, this will not allow the convention that some
people using case-sensitive languages seem to like:

    animal: Animal;

Whereas Ada requires something like:

    Animal: Animal_Type;

or

    The_Animal: Animal;

- Bob

Re: Some questions about Ada.

[Robert A Duff]

In article <Dqt9nA.o5n@undergrad.math.uwaterloo.ca>,
Carl Laurence Gonsalves <clgonsal@undergrad.math.uwaterloo.ca> wrote:
>I've heard about Ada 95. I wasn't able to find any books on it though, so I
>picked up a copy of "Programming in Ada" 3rd Ed. by J.G.P.Barnes. It
>doesn't cover Ada 95 (it's copyright date is '89). 

Barnes has updated his book to cover Ada 95.  There's also Norman
Cohen's book, and probably others.

>...I'll go and look on the
>web for stuff about Ada 95, probably tomorrow, actually.

The Reference Manual and the Rationale can be found at
sw-eng.falls-church.va.us in directory
public/adaic/docs/standard/95lrm_rat/v6.0.

>The
>varying capitalizations that result from different people going in and
>modifying the code results in a distracting mish-mash of capitalization
>styles.

Usually true, because most projects consist of a bunch of
individualistic "artists", who think that writing "end" the same way as
everybody else will cramp their style.  :-(

For a counter-example, look at the GNAT sources.  Stylistically, they
look like they were all written by the same person.  Not just case
conventions, but all kinds of other stuff.

>If it was intended to prevent variables that look similar except for case
>then that's what should've been done: make the language case-sensitive, but
>don't allow the creation of anything that has the same case-insensitive
>name. ie: if I create something called "foo" then I can't create something
>called "Foo", nor can I access something called "foo".

In a language with overloading, you can declare both "foo" and "foo".
If *that*'s not confusing, then how can "Foo" and "foo" be confusing?
In a different article I posted a variation on your idea above, which
IMHO fits in better with the idea of overloading.

I think Smalltalk requires that class names start with a capital letter,
and method names start with a lower-case letter.  Clearly, language-wide
conventions are better than project-wide conventions.

>But I think that isn't a very good restriction. A very common convention in
>C and in other case sensitive languages (like Modula-3) is to give a type
>an upper-case name, and a local general purpose instance of that type has a
>lower-case name. ...

Shrug.  Some folks like that, some folks find it to be an abomination.
I imagine one can get used to either way.

>... I imagine Ada programs are filled with variables called
>"myWindow" or "theTable".

Yes, they are.  Well, actually, it's usually My_Window and The_Table.
Alternatively, some programs are filled with types called Window_Type
and Table_Type, so the variables can be called Window and Table.

Anyway, who cares?  This issue is hardly the most important one, when
choosing a programming language.

- Bob

Re: Some questions about Ada.

[Robert Dewar]

Bob said

"I think it's already nearly impossible to express programs by talking,
so I don't find that argument interesting.  Whenever I'm sitting in a
design session, and somebody says a piece of a program out loud, it is
nearly always necessary to write it on the blackboard for people to
understand."

I see you are not in the customer support business :-)

Re: Some questions about Ada.

[Robert Dewar]

Adam said

"I don't understand this at all.  As far as I can see, about the only
way you can be misled into thinking two different capitalizations mean
different things is if you're used to programming only in C/C++ (or
Modula).  Expecting different capitalizations to mean different things
doesn't come from experience with most other well-known programming
languages, since they don't care about case.  And it certainly can't
come from any of our other learning; if I see a word capitalized at
the beginning of a sentence, I am not misled into thinking its meaning
is different from an entirely lower-case word."

(talking about confusion arising from random casing)

I see it! I think it is terrible Ada style to be inconsistent in casing
keywords or identifiers. In fact I think it is nice if the compiler has
an option to prevent such sloppiness (when we compile in internal GNAT
mode, consistent casing is enforced).

However, I think that having case sensitivity in languages is a very
bad idea. For one thing it makes it  very difficult to talk verbally about
programs, and if people really start defining identifiers like
Time_of_Day and Time_OF_Day to mean different things, then it damages
readability badly.

Re: Some questions about Ada.

[Robert A Duff]

In article <dewar.831213757@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>I see it! I think it is terrible Ada style to be inconsistent in casing
>keywords or identifiers. In fact I think it is nice if the compiler has
>an option to prevent such sloppiness (when we compile in internal GNAT
>mode, consistent casing is enforced).

i agree.  it's not a matter of really misundERSTanding things, assuming
you know the rules.  it's just that doing things in an unconventional or
Sloppy way makes the code harder to reAD.

By the way, does the gnat switch disallow declaring two overloaded
things called, say, NonEval and NoneVal?  I assume that it merely
requires that each reference to one or the other is capitalized like its
declaration.

>However, I think that having case sensitivity in languages is a very
>bad idea. For one thing it makes it  very difficult to talk verbally about
>programs, and if people really start defining identifiers like
>Time_of_Day and Time_OF_Day to mean different things, then it damages
>readability badly.

I think it's already nearly impossible to express programs by talking,
so I don't find that argument interesting.  Whenever I'm sitting in a
design session, and somebody says a piece of a program out loud, it is
nearly always necessary to write it on the blackboard for people to
understand.

By the way, mathematicians use case sensitivity -- e.g., "Let X be the
set of all x such that x has so-and-so property."  How do mathemeticians
do that over the phone?  I suspect the answer is, they don't bother
trying.

- Bob

Re: Some questions about Ada.

[Richard Kenner]

In article <dewar.831213757@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:
>However, I think that having case sensitivity in languages is a very
>bad idea. For one thing it makes it  very difficult to talk verbally about
>programs, and if people really start defining identifiers like
>Time_of_Day and Time_OF_Day to mean different things, then it damages
>readability badly.

A counterexample to that, with which I mostly agree, are some C coding
conventions where the kind of thing is determined by the casing of the
first letter.  I've seen this sort of thing in the sources of some CAD
systems.  For example:

typedef struct wire {...} Wire;
typedef struct signal {...} Signal;

I've also seen this done with macros that call functions vs the function
they, internal and external versions of a function, etc.

I think this can be a very useful convention if it is followed
uniformly.  I can't offhand think of an Ada analog for such a
convention, though.

Re: Some questions about Ada.

[Robert Dewar]

Richard Kenner said

"A counterexample to that, with which I mostly agree, are some C coding
conventions where the kind of thing is determined by the casing of the
first letter.  I've seen this sort of thing in the sources of some CAD
systems.  For example:

typedef struct wire {...} Wire;
typedef struct signal {...} Signal;

I've also seen this done with macros that call functions vs the function
they, internal and external versions of a function, etc.

I think this can be a very useful convention if it is followed
uniformly.  I can't offhand think of an Ada analog for such a
convention, though."

I know this viewpoint, but I don't agree. It is still very much subject
to the problems of talking about the program verbally. There are good
reasons why ordinary English is pretty much case insensivity (*)

(*) with of course the exception that ADA and Ada must never be confused :-)

Re: Some questions about Ada.

[Carl Laurence Gonsalves]

In article <4me37a$ipl@krusty.irvine.com>,
Adam Beneschan <adam@irvine.com> wrote:
>clgonsal@undergrad.math.uwaterloo.ca (Carl Laurence Gonsalves) writes:
>>
>>I'v also had to maintain Pascal programs where "end" was capitalized in
>>three different ways, at random. Case insensitivity makes the code harder
>>to read and harder to maintain, because one can be misled into thinking
>>that two different capitalizations of the same thing are distinct. . . .
>
>I don't understand this at all.  As far as I can see, about the only
>way you can be misled into thinking two different capitalizations mean
>different things is if you're used to programming only in C/C++ (or
>Modula).  Expecting different capitalizations to mean different things
>doesn't come from experience with most other well-known programming
>languages, since they don't care about case.  And it certainly can't
>come from any of our other learning; if I see a word capitalized at
>the beginning of a sentence, I am not misled into thinking its meaning
>is different from an entirely lower-case word.

In mathematics "x" and "X" are often used to represent two distinct
objects.

And even if one wouldn't be fooled into thinking "theodolite" is different
from "TheOdoLite", it's still very distracting having to mentally "convert"
everything to the same case. It's much more obvious that "foobar" and
"foobar"  are the same.

If the intent was really to prevent two distinct things from having names
that varied only by case, then there are better alternatives that were
pointed out by myself and someone else.

-- 
        Carl Laurence Gonsalves - clgonsal@undergrad.math.uwaterloo.ca
                   Computer Science, University of Waterloo
               http://www.undergrad.math.uwaterloo.ca/~clgonsal/
                   http://www.csclub.uwaterloo.ca/~clgonsal/

Re: Some questions about Ada.

[Kevin D. Heatwole]

In article <dewar.831213757@schonberg>, dewar@cs.nyu.edu (Robert Dewar) wrote:
> 
> (talking about confusion arising from random casing)
> 
> I see it! I think it is terrible Ada style to be inconsistent in casing
> keywords or identifiers. In fact I think it is nice if the compiler has
> an option to prevent such sloppiness (when we compile in internal GNAT
> mode, consistent casing is enforced).

I agree that consistent formatting is nice, but I have been programming in
Ada since 1983 (and have debugged a lot of problems in that time) and I
have never come across an instance where inconsistent casing of keywords
or identifiers has caused a problem in Ada (I have seen this happen a couple
of times in C and assembly).

Of course, that isn't to say it can't cause a problem, but I think it is
rare (e.g., Use clauses sometimes make visible very similar names).  Now, 
I have seen some problems due to inconsistent indentation (which is closely
related to case).  I have also seen some problems with short variable names
that use similar letters (like i and j).

I generally like a compilation unit to be consistently formatted, but I
don't mind if separate compilation units use different formatting/casing.

Kevin Heatwole
OC Systems, Inc.

Re: Some questions about Ada.

[Robert A Duff]

In article <dewar.831268468@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>I see you are not in the customer support business :-)

:-)

Actually, I have been, and I found it extremely frustrating to
communicate programs by telephone.  Except for very simple things, it
was generally much easier (for both customer and supporter) to deal with
e-mail or fax or even paper or tape sent via regular mail.  In the bad
old days, that wasn't always feasible, but nowadays almost anybody with
a computer has access to some form of high-speed written communication.

I've also had the experience of reading my AUTOEXEC.BAT file over the
telephone.  It consisted of a single call to some other file, which
completely mystified the support person.  :-(

- Bob

Re: Some questions about Ada.

[Richard Kenner]

In article <dewar.831218670@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:
>I know this viewpoint, but I don't agree. It is still very much subject
>to the problems of talking about the program verbally.

Not necessarily. The existance of the convention allows you to
"pronounce" the case difference by using the meaning of the
capitalization in the convention.

So you have "type wire" vs "struct wire" or "public make_wire" vs
"private make_wire" or "macro alloc" vs "function alloc".

Re: Some questions about Ada.

[Robert Dewar]

Richard Kenner said

"Not necessarily. The existance of the convention allows you to
"pronounce" the case difference by using the meaning of the
capitalization in the convention."

That only helps if both people are following the same convention. Since
there are no standards for these conventions, that is unlikely. Maybe I
am unusual, but I have participated/overheard conversations a zillion
times that go like:

type in command bla bla

I did, it said unrecognized command

Oh sorry, the M is upper case

...

Re: Some questions about Ada.

[Arthur Evans Jr]

In article <DqxKEz.Cs0@world.std.com>,
bobduff@world.std.com (Robert A Duff) wrote:

> In article <dewar.831268468@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
> >I see you are not in the customer support business :-)
> 
> Actually, I have been, and I found it extremely frustrating to
> communicate programs by telephone.

Indeed.  Some years ago a vendor I was associated with had a customer
who couldn't compile a body stub and complained by telephone.  The
support staff could not recreate the problem, at all.  After much agony,
they found out that the customer had written

    seperate (FOO)
    package BAR is ...

Art Evans

Arthur Evans Jr, PhD        Phone: 412-963-0839
Ada Consulting              FAX:   412-963-0927
461 Fairview Road
Pittsburgh PA  15238-1933
evans@evans.pgh.pa.us

If you don't yet see it, ...
\f
... check for spelling errors.

Re: Some questions about Ada.

[Robert Dewar]

Bob Duff said

"> In article <dewar.831268468@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
> >I see you are not in the customer support business :-)
>
> Actually, I have been, and I found it extremely frustrating to
> communicate programs by telephone.


Sure everyone agrees with this, the point is that having to deal with
casing adds one more additional, avoidable, frustration.

Re: Some questions about Ada.

[Robert Dewar]

I was shocked to find that GNAT 3.04 did not immediately diagnose Art's
little telphone example, and sure enough there was an obvious oversight.
This is fixed in 3.05, and we now get

     1.     seperate (FOO)
            |
        >>> Incorrect spelling of keyword "separate"

Re: Some questions about Ada.

[Norman H. Cohen]

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

|> This is fixed in 3.05, and we now get
|>
|>      1.     seperate (FOO)
|>             |
|>         >>> Incorrect spelling of keyword "separate"

Very nice, but at least as of 3.03, you did not issue a warning about a
controlled type with a primitive operation named Initialise.   ;-)

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

Re: Some questions about Ada.

[Robert Dewar]

Norman said

"I presume you're talking about consistency among different occurrences of
the same identifier rather than mechanical adherence to a uniform set of
capitalization rules.  I also hope that you're talking only about
consistency among user-written occurrences, and not enforced conformance
to the capitalization that the compiler vendor used in the declaration of
predefined packages.

I certainly don't want to be forced to write Text_Io and Cpu_Cycles
instead of Text_IO and CPU_Cycles--or C.Interfaces.Int instead of
C.Interfaces.int!"

Robert replies

In fact the -gnatg switch just enforces consistency, but that does include
conformance to the capitalization that the compiler vendor (us) used int
the declaration of predefined pcakages (since we is us, we quite like this
particular choice).

Of course in GNAT, it is Text_IO and C.Interfaces.int in the library :-)
These are incidentally the capitalizations that appear in the Ada 95 RM.
We exactly follow the RM casing conventions for all such entities.

Re: Some questions about Ada.

[Christopher J. Henrich]

In article <evans-0505961547050001@ppp2.pgh.net>, evans@evans.pgh.pa.us
(Arthur Evans Jr) wrote:

> Indeed.  Some years ago a vendor I was associated with had a customer
> who couldn't compile a body stub and complained by telephone.  The
> support staff could not recreate the problem, at all.  After much agony,
> they found out that the customer had written
> 
>     seperate (FOO)
>     package BAR is ...
> 
> Art Evans
> If you don't yet see it, ...
> \f
> ... check for spelling errors.
This gave me a good laugh - I had fallen for it like a ton of bricks.
But, you know, that really shold be "package body".

-- 
Christopher J. Henrich
chenrich@monmouth.com

Re: Some questions about Ada.

[David Weller]

In article <4mljpe$sau@watnews1.watson.ibm.com>,
Norman H. Cohen <ncohen@watson.ibm.com> wrote:
>Very nice, but at least as of 3.03, you did not issue a warning about a
>controlled type with a primitive operation named Initialise.   ;-)
>

As one British professor admonished to me once: "Because, in the
civilised world, that spelling is entirely correct!" :-)

-- 
    Visit the Ada 95 Booch Components Homepage: www.ocsystems.com/booch
           This is not your father's Ada -- lglwww.epfl.ch/Ada

Re: Some questions about Ada.

[Matthew M. Lih]

Dave Jones wrote:

> My opinion:  Ada95 is the best all-around language for software engineering.
> C++ is awful.  Nevertheless, if I were starting a project today, I would
> probably choose to use C++.  Why?:  More (and better and cheaper) tools are
> available for C++, more programmers are trained to program in C++, et cetera.

Your statement perplexes me. If Ada95 is the best language, I would hope
that means it's more "cost-effective" than other languages. (Use C++
for argument's sake.) But your statement effectively says this is outweighed
by the tool factor and training factor, and other minor issues. I could
argue against this, but I guess my question is really "How good does
Ada have to be to outweigh the popularity of C++?"


Matthew M. Lih
Software Lead, SAIN Project
TRW Enterprise Solutions

Re: Some questions about Ada.

[Laurent Guerby]

Richard Kenner writes
[talking about casing]
: A counterexample to that, with which I mostly agree, are some C coding
: conventions where the kind of thing is determined by the casing of the
: first letter.  I've seen this sort of thing in the sources of some CAD
: systems.  For example:
: 
: typedef struct wire {...} Wire;
: typedef struct signal {...} Signal;
: 
: I've also seen this done with macros that call functions vs the function
: they, internal and external versions of a function, etc.
: 
: I think this can be a very useful convention if it is followed
: uniformly.  I can't offhand think of an Ada analog for such a
: convention, though.

   For this  kind of  macros,  the Ada equivalent  is Inline (standard
since the good old days ;-) and a good compiler :  nightmare for a few
compiler writers, easy and maintainable  for zillions of users, sounds
like the optimal  scheme in language  design for me (IMHO, but there's
of  course counter arguments,  like time to market  a  compiler, but I
think the Ada world is not the same than in the eighties and has taken
into account previous mistakes and experiences).

   For the useful casing convention, from a safety point of view, it's
hard  to rely on  a single letter for  such a semantic gap. IMHO, just
adding a _Type if no  good name can be found  is better (I've not said
"the best") and safer.

   But I agree that if strictly everybody  on a large project agree on
such a uniform convention, it can work. This is not common case.

   On the  mathematical side, I've seen a   lot of stupid  but hard to
find mistakes (including my own  ones ;-) introduced by the convention
"x"  "X" "i"  etc ...  For  my own  calculus  I started to use  longer
indices (i_something), so when  I discovered Ada,  I was very happy to
type   five  more characters a  few   times instead  of spending hours
reading obscure things to   find a typo.  I've  choosen to agree  with
case-insensitivity for programming languages on the  same basis, and I
don't rely a priori on casing for meaning.

-- 
--  Laurent Guerby, student at Telecom Bretagne (France), Team Ada.
--  "Use the Source, Luke. The Source will be with you, always (GPL)."
--  http://www-eleves.enst-bretagne.fr/~guerby/ (GATO Project).
--  Try GNAT, the GNU Ada 95 compiler (ftp://cs.nyu.edu/pub/gnat).

Re: Some questions about Ada.

[Norman H. Cohen]

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

|> I see it! I think it is terrible Ada style to be inconsistent in casing
|> keywords or identifiers. In fact I think it is nice if the compiler has
|> an option to prevent such sloppiness (when we compile in internal GNAT
|> mode, consistent casing is enforced).

I presume you're talking about consistency among different occurrences of
the same identifier rather than mechanical adherence to a uniform set of
capitalization rules.  I also hope that you're talking only about
consistency among user-written occurrences, and not enforced conformance
to the capitalization that the compiler vendor used in the declaration of
predefined packages.

I certainly don't want to be forced to write Text_Io and Cpu_Cycles
instead of Text_IO and CPU_Cycles--or C.Interfaces.Int instead of
C.Interfaces.int!

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

Re: Some questions about Ada.

[Robert Dewar]

Dave Weller said

">Very nice, but at least as of 3.03, you did not issue a warning about a
>controlled type with a primitive operation named Initialise.   ;-)
>

As one British professor admonished to me once: "Because, in the
civilised world, that spelling is entirely correct!" :-)"

Interesting, I guess that the Oxford English Dictionary is uncivilized
then (it does not permit this variation in spelling, let alone, as some
British spellers would demand, allow only the "s" spelling).

Seriously, to Norm's point, is it worth a warning in GNAT? I thhink so
(is is easy to do).

Re: Some questions about Ada.

[Dave Jones]

Matthew M. Lih wrote:
> 
> Dave Jones wrote:
> 
> > My opinion:  Ada95 is the best all-around language for software engineering.
> > C++ is awful.  Nevertheless, if I were starting a project today, I would
> > probably choose to use C++.  Why?:  More (and better and cheaper) tools are
> > available for C++, more programmers are trained to program in C++, et cetera.
> 
> Your statement perplexes me. If Ada95 is the best language, I would hope
> that means it's more "cost-effective" than other languages. 

By itself, Ada is more "cost-effective" than most other languages (by themselves).
However, there are some other factors to consider:  Is the institution funding your
project going to give you the time and money necessary to train programmers *properly*
in Ada?  Probably not.  Will the institution funding your project be happy about 
paying $3000 for an Ada development tool which is not as good as a C++ development 
tool that costs $500?  Probably not.  

I agree with those who say that, in the *long* run, using Ada would save a company 
money.  However, the bean counters that you rely on for your funding aren't 
thinking that way.  They want to save money *now*  (In fact, at most companies,
they *need* to save money now, or they could lose their jobs.  Sadly, most companies 
punish managers for thinking ahead, and reward them for "living for the day".)

> (Use C++
> for argument's sake.) But your statement effectively says this is outweighed
> by the tool factor and training factor, and other minor issues. I could
> argue against this, but I guess my question is really "How good does
> Ada have to be to outweigh the popularity of C++?"

An interesting question.  First of all, we have to realize that C++ and Ada actually
fulfill slightly different roles:  C++ is an improved version of C which was designed
to be a portable replacement for Assembler.  C and C++ have, in fact, fulfilled 
their design goals:  They are now the most popular languages for applications which
used to be developed in Assembler (shrink-wrap software, system-level programming, 
high-speed routines, etc.).   

Ada, on the other hand, was designed to replace languages like Jovial, Pascal and COBOL. 
 Ada has succeeded fairly well in more "technical" areas like the aerospace/defense 
industry.  However, in the area of business applications, Ada has largely lost out to the 
4GLs (here in the U.S. -- things are different in Europe).  The same can be said of other 
well-designed languages like Modula-3 and Eiffel.

For Ada to become as popular as C/C++, one of two things needs to happen:    

1) A "paradigm shift" will have to take place in the programming community:  Developers 
will have to realize that improved compilers and high-speed CPUs mean that there is no 
longer a need for a language to offer them the same power/flexibility that Assembler 
does.  They will then be more likely to concentrate on things like reliability and 
maintainability.  If this happens, then Ada will have a chance to compete directly with 
C/C++ on its home turf. 

2) Someone needs to develop a Delphi-like application based on Ada.  They will have to 
sell it at a reasonable price (less than $300).  This will allow Ada to compete with the 
4GLs.

-- Dave Jones
davedave@io.com

Re: Some questions about Ada.

[Geert Bosch]

Robert Dewar (dewar@cs.nyu.edu) wrote:
`` Seriously, to Norm's point, is it worth a warning in GNAT? I thhink so
   (is is easy to do). ''

British people are not the only ones who make mistakes like that. In the
Netherlands We're also taught English instead of American, and yes, I've
also used the English spelling in cases were I shouldn't. Anyway, if 
somebody defines a procedure Initialise for a controlled type not knowing
that that name is really close to the special procedure Initialize, he
should be warned too.
-- 
E-Mail: geert@sun3.iaf.nl     *** The moon may be smaller than ***
 Phone: +31-53-4303054        ** Earth,  but it's further away. **