Re: ForTran-Ada + flamette + questi

Re: ForTran-Ada + flamette + questi

[gore]

>[ Discussion about lack of pointers to procedures in Ada ]
>
>You've gotta draw the line somewhere.  I'm continually amazed how
>people complain that Ada has either too much or not enough because
>it's left out their favorite feature from language X.  Considering the
>design goals for Ada, I think they did a good (not perfect) job of
>designing a language with which you can write both efficient and
>abstract, safe programs.

Personally, my complaint is more about the incomplete orthogonality of Ada 
than about lack of specific features.  If task types (and hence pointers to
tasks) are allowed, why not allow procedure types, package types, entry types?
We should not automatically assume that addition of these automatically means
making the language bigger.  For example, if there was a way to maintain
structures of entries, there would be no need for "families of entries".

Another example:  If only 'in' parameters are allowed in functions, why allow
access to external variables from inside a function?

Jacob Gore
Northwestern Univ
Comp Sci Research Lab
ihnp4!nucsrl!gore

Functions and external values

[Erland Sommarskog]

In article <4000001@nucsrl> gore@nucsrl.UUCP writes:
>
>Another example:  If only 'in' parameters are allowed in functions, why allow
>access to external variables from inside a function?

Think before you talk, man! Let's say you have a data structure, a table
for example which is totally embedded inside of a package. I.e. neither
the type nor a variable reference is available outside the package. The only
way to change AND achieve data is through procedure and function calls.
So a function reading data from the table, must of course be able to refer
to the table, which, also of course, is declared outside the function. 
You could discuss whether this is a good programming technique, but I use
it regulary, though not in Ada.

Erland Sommarskog
ENEA Data, Stockholm