Re: more to ada paper critic

[dennison@telepath.com (Ted Dennison)]

Immanuel Scholz <news@kutzsche.net> wrote in message news:<aekdir$7oos6$1@ID-100557.news.dfncis.de>...
> here a (permitted) post from an email with Jim Rogers. Maybe any of you 
> find this interesting ;-) 
...
> is more some kind of report for my superior. I have already done this, but
> unhappily I do not expect him to choose Ada as language for the project he

:-(
I once had to do a compiler selection report that I was ordered to
redo (with different feature empahsis) 3 times, due to the fact that
my supervisor didn't like the implied decisions. However, that
supervisor was commonly known to be a moron, and didn't last out the
year.

So I'm not unsympathetic.

> It simple looked very unprofessional, if I report a collection of languages
> where Ada, likely even not known to my chief, get the best price and C got
> worsest. (But I think I have prevented the worst two things: C and VB ;-)

Frankly, I'd consider it unprofessional to munge the data in a report
to fit someone's preferred outcome. I know it happens all the time,
but as technical people it is critical that we present an accurate
technical picture to our managers, because we are the only place they
can possibly get it from. If they end up making a choice based on
non-technical factors, fine. There are often good reasons for that.
But its *their* job to consider those factors, not ours.



> So private is not the default? Is there a default (to public?)

True. You can sort of think of it as like C++ structs (really no
different than classes, except the default is public). I don't think
that's really a big issue, either in C++ or Ada though. The common
idiom in Ada is to put everything you can in the private part, and the
common idiom in C++ seems to be to explicitly label the privacy level
rather that use the defaults.

> >       -- Define the number of cards in a standard deck.
> >    subtype Deck_Index is integer range 1..52;
> 
> AFAIK this means a Deck_Index IS A integer, right? So maybe I would prefer
> "type Deck_Index is new integer range 1..52;", because an index is not
> normaly an integer. What do you say?

It depends. If you are never going to use it with things that aren't
Deck_Index, then indeed you should make it its own type. On the other
hand, if you are going to use it with integers a lot and would hate
having to use type conversions all over the place to do so, then a
subtype is probably better. Array constraint checking will still
prevent accces past the array bounds, which is probably the most
important thing.

> >          Deal_Next  : Deck_Index := Deck_Index'First;
> 
> I like these auto-attributes very much (like in Java the .length of array)
> :-)

Actually, the best is with "for" loops, where you can just say to loop
through the array's indexes rather than supplying a range manually.
Not only is this convienent, it spells out your intent much better.
That non only helps maintainers, it helps optimizers.

> > Note that this package specification defines the types Card and Deck
> > as private types. This allows another compilation unit to know that
> > there are types called Card and Deck, but not to know their
> > structure. The Ada package provides encapsulation and namespace.
> 
> Hm, but the other programmers still SEE the current structure. IMHO if the
> structure should be hidden, it would be better to only declare the names of
> the types so that even other _coders_ does not know the structure.
> Like C/C++ 's header-declaration approach (if you do it right in C).

This must be a C++ idiom with which I'm unfamiliar. I thought C++
class declarations did not allow any part of the class's declaration
(like one of its fields) to be declared in a separate compilation.

I agree with your logic. I just don't see an easy way to do it. The
compiler has to know how big your type/class is, so it knows the code
to generate for reserving stack space for it.

There is one trick you can use in Ada though. If your private type is
an access type, you can defer the definition of the type it points to
until the package body.

> > The types defined in this specification are not declared to
> > be "tagged" types. This prohibits any subclassing of these
> > types.
> 
> Which may be a pain in future. Better had done tagged as default and needed
> a "final" or something similar to forbid subclassing? Normally a class isn't
> sensitive to subclassing. This is juse the exception.

It would be way more of a pain in C++ than it is in Ada. Ada doesn't
rely on tagged types nearly as much as C++ relies on classes. But if
you are worried you could always define it that way.

> > Note that none of the subprograms (functions and procedures) is yet
> > defined. The package specification acts as an interface definition
> > for the entire package. The definitions are placed in a separate
> > file called the package body.
> 
> HAS they to be in a seperate file? I think not so. (But it is good, that
> they CAN ;-)

With Gnat they do, but with most other Ada compilers they don't. They
have to be in another "compilation unit" (the package body, instead of
the spec). Gnat has a (unusual) restriction that there can be only one
compilation unit in a source file. Its not really much of a
restriction in practice, because I've never seen any code that had a
package body in the same file as the spec. That's not considered good
Ada style.

> Are there any swap - template (or "generic" ;-) in the standard-library?

I don't think so. Its too trivial to just make yourself. :-) Anyway, a
general case one would have to worry about wierd cases like
overlapping array slices.

> >       Max_Search : Deck_Index := Deck_Index'Pred(Deck_Index'Last);
> 
> What will happen if the deck was empty?

This is just saying that Max_Search is initialized to the second to
last value in the *type* "Deck_Index". The only possible problem I can
see with this is if Deck_Index only had one value (in which case
Constraint_Error would be raised here at runtime, if the compiler
didn't catch it for you at compile time).

> >    procedure Deal(The_Card : out Card; From : in out Deck) is
> >    function Cards_Left(In_Deck : Deck) return Natural is
> 
> The difference between procedure and function seem to be, that procedure has
> in/out modifiers while function has a return-value, right? What is the
> default for functions? Are the parameter all "in" or "in out" ?

All function parameters have to be "in" or "access". This is just like
C, where all function parameters are "in" only, and if you want
something different you have to fake it with pointers. The difference
is that Ada also gives you procedures with "out" and "in out".

> > Variable initialization is performed during an elaboration step
> > which is performed before normal program execution begins. This
> > ensures that the All_Decks variable is properly initialized with
> > no race conditions.
> 
> Oh come. Arent there race conditions when initializing more than these
> "before the main"s. This solution seems quite similar to C++'s problem of
> initializing global statics. Example: (forgive any syntax-errors I havent
> got GNAT to run until now ;-)

You are quite right. Not only can there still be race conditions
(tasks can be created during elaboration), but there can be
elaboration order dependancy issues. However, Ada does have a set of
elaboration pragmas you can use to help straighten things out if they
are starting to get hairy.

> >       Cards.Deal(The_Card => This_Card, From => My_Deck);
> 
> looks funny :)

The lack of "designated reciever" notation does look a bit odd to
those who are used to it. But one thing this means is that you can
actually dispatch on *multiple* parameters (don't get too excited,
they still have to be the same type).
 
> What happens if you do not catch the exception? Will then some kind of
> terminate() be called (similar to C++?) or just reported and step on (like
> Java)?

The task in which the exception occurred (and was not handled) will be
termiated. However, the program will continue to run if there are
other tasks in it. If it happened to be the main task, you will
probably get some kind of note that this happened to stdout or stderr,
but if it was not you will most likely see nothing. This can actually
be a bit of a problem. We generally handle this in Ada by putting a
last-ditch exception handler in every task that reports the exception
info.

> Can I declare exceptions, so that user of my functions MUST catch the
> exception?

No. There's no notation for this. There's been a great deal of
discussion lately in language design circles about whether doing this
is a good thing or not, so I'm kind of glad we didn't try out this
unproven concept in Ada.

> Yes. But this is really only sugar and does not improve calling security.
> The most important thing about order of Parameters is, when a library
> supporter has to decide to swap Parameters of functions. Since he cannot
> decide this safely (because there might be callings without naming) it is
> almost useless to know, that user of libraries MIGHT call with secure
> naming...

You can only say this because you've never used a language that has
it. Without this feature, parameters of the same type (eg: X and Y
coordinates to a draw function) can easily match with the wrong
formals. If I used named association I have an extra level of checking
that this kind of thing doesn't happen. Also, it presents an extra
level of documentation to the reader of what my code is trying to
accomplish. In addition, it insulates my code from a lot of formal
parameter changes in code I'm calling. If I use named-notation in
calling, my API can rearrange the formals to his heart's content
without causing me any grief past a blind recompile.

> The only advantage comes from more readible code.

You say that like its a small deal! Readability is *huge*, and most
design decisions in Ada were based on it.

> Or are there possibilities to force the parameter-naming? This would be
> great!
Every project I've ever worked on forced it in the coding standards,
except when calling single-parameter routines. Its kind of a shame
that Gnat doesn't include that in its style checks, but I suppose if
it really bothered me I could add it.