A case where Ada defaults to unsafe?

A case where Ada defaults to unsafe?

[Hyman Rosen]

The conventional belief (at least on CLA :-) is that one of the
main distinctions between Ada and C/C++ is that Ada defaults to
safe behavior and C/C++ defaults to unsafe behavior (eg., array
indexing, automatic type conversions, and overflow checking).

It occurs to me that there is a case where the opposite seems to
be true. In C/C++, the && and || binary operators short-circuit,
evaluating their right operand only if necessary. In Ada, it is
necessary to specify "and then" and "or else" for this behavior,
otherwise the order of evaluation of the two sides is unspecified
if the simple "and" and "or" forms are used.

So in Ada, one could say 'if a /= 0 and b/a > 3' and fall into a
trap that would not happen in C/C++. Discuss?

Re: A case where Ada defaults to unsafe?

[Darren New]

Hyman Rosen wrote:
> So in Ada, one could say 'if a /= 0 and b/a > 3' and fall into a
> trap that would not happen in C/C++. Discuss?

Or, in C, you could say
  if (func_with_side_effects(1) || func_with_side_effects(2)) {...}
and also not get the answer you might expect.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
               "This wine goes good with feet."

Re: A case where Ada defaults to unsafe?

[Hyman Rosen]

Darren New wrote:

> Hyman Rosen wrote:
>>So in Ada, one could say 'if a /= 0 and b/a > 3' and fall into a
>>trap that would not happen in C/C++. Discuss?
> Or, in C, you could say
>   if (func_with_side_effects(1) || func_with_side_effects(2)) {...}
> and also not get the answer you might expect.


It would be the answer *I* expect :-) In Ada, the answer would be
indeterminate as well if the order of the side effects mattered.

Re: A case where Ada defaults to unsafe?

[Wes Groleau]

Hyman Rosen wrote:
> 
> Darren New wrote:
> 
> > Hyman Rosen wrote:
> >>So in Ada, one could say 'if a /= 0 and b/a > 3' and fall into a
> >>trap that would not happen in C/C++. Discuss?
> > Or, in C, you could say
> >   if (func_with_side_effects(1) || func_with_side_effects(2)) {...}
> > and also not get the answer you might expect.
> 
> It would be the answer *I* expect :-) In Ada, the answer would be
> indeterminate as well if the order of the side effects mattered.

Personally, I agree with the AQS philosophy: If the order of evaluation
matters, the code should show that.  And if it doesn't matter, then
nothing implying that it does matter should clutter up the code.

Requiring the compiler to do a particular order, even if it doesn't
matter conceptually, is preventing the compiler from optimizing the
order when it affects efficiency.  (And requiring people to use
"and then" all the time also interferes with the optimizer, as well
as adding misleading clutter to the code.)

On the other hand, there's something to be said for determinism.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: A case where Ada defaults to unsafe?

[James Rogers]

Hyman Rosen wrote:
> 
> The conventional belief (at least on CLA :-) is that one of the
> main distinctions between Ada and C/C++ is that Ada defaults to
> safe behavior and C/C++ defaults to unsafe behavior (eg., array
> indexing, automatic type conversions, and overflow checking).
> 
> It occurs to me that there is a case where the opposite seems to
> be true. In C/C++, the && and || binary operators short-circuit,
> evaluating their right operand only if necessary. In Ada, it is
> necessary to specify "and then" and "or else" for this behavior,
> otherwise the order of evaluation of the two sides is unspecified
> if the simple "and" and "or" forms are used.
> 
> So in Ada, one could say 'if a /= 0 and b/a > 3' and fall into a
> trap that would not happen in C/C++. Discuss?

My experience is that any such unsafe condition in Ada will result
in an exception. The same cannot be expected of C++. The very fact
that Ada has a stronger type system than C++ ensures that an
exception will be raised in Ada, while the condition may go
undetected for quite a while in C++.

This is not meant to imply that raising exceptions is as safe as 
avoiding errors. It simply means that, through analysis and/or 
testing, the Ada programmer is likely to find the need for the
short-circuit form and apply it. 

Jim Rogers
Colorado Springs, Colorado USA

Re: A case where Ada defaults to unsafe?

[Frank J. Lhota]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3C34BF2C.6030500@mail.com...
> It occurs to me that there is a case where the opposite seems to
> be true. In C/C++, the && and || binary operators short-circuit,
> evaluating their right operand only if necessary. In Ada, it is
> necessary to specify "and then" and "or else" for this behavior,
> otherwise the order of evaluation of the two sides is unspecified
> if the simple "and" and "or" forms are used.

The situation is quite similar in C/C++; if you use the siumpler & and |
operators, they do not short-circuit. In either C/C++ or Ada, experienced
programmers know what needs to be done in order to get short-circuiting.

Re: A case where Ada defaults to unsafe?

[Hyman Rosen]

Frank J. Lhota wrote:

> The situation is quite similar in C/C++; if you use the siumpler & and |
> operators, they do not short-circuit. In either C/C++ or Ada, experienced
> programmers know what needs to be done in order to get short-circuiting.


In C/C++ "everyone" knows that & and | are for bit twiddling and && and ||
are for combining logical expressions.

But get away from C/C++ for a moment. In pure Ada terms, isn't it less safe
for the defaults to be "and" and "or" instead of "and then" and "or else"?

Re: A case where Ada defaults to unsafe?

[Ted Dennison]

In article <3C34D252.4070307@mail.com>, Hyman Rosen says...
>But get away from C/C++ for a moment. In pure Ada terms, isn't it less safe
>for the defaults to be "and" and "or" instead of "and then" and "or else"?

Perhaps for ex-C programmers it is. But that's certianly not the only pitfall in
the language for ex-C programmers.

If you were instead brought up to believe that boolean "and" is communitive,
like they teach in math/logic classes, then it makes perfect sense. In that
case, "and then" is just a nice shorthand for " then if ... then".

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: A case where Ada defaults to unsafe?

[Hyman Rosen]

Ted Dennison wrote:

> In article <3C34D252.4070307@mail.com>, Hyman Rosen says...
> 
>>But get away from C/C++ for a moment. In pure Ada terms, isn't it less safe
>>for the defaults to be "and" and "or" instead of "and then" and "or else"?
>>
> 
> Perhaps for ex-C programmers it is. But that's certianly not the only pitfall in
> the language for ex-C programmers.
> 
> If you were instead brought up to believe that boolean "and" is communitive,
> like they teach in math/logic classes, then it makes perfect sense. In that
> case, "and then" is just a nice shorthand for " then if ... then".


You haven't answered my question, though. Isn't the commutative semantic
less safe than the short circuit one?

Re: A case where Ada defaults to unsafe?

[Nick Williams]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3C34E43E.5070906@mail.com...

> >>But get away from C/C++ for a moment. In pure Ada terms, isn't it less
safe
> >>for the defaults to be "and" and "or" instead of "and then" and "or
else"?

> > Perhaps for ex-C programmers it is. But that's certianly not the only
pitfall in
> > the language for ex-C programmers.

> > If you were instead brought up to believe that boolean "and" is
communitive,
> > like they teach in math/logic classes, then it makes perfect sense. In
that
> > case, "and then" is just a nice shorthand for " then if ... then".

> You haven't answered my question, though. Isn't the commutative semantic
> less safe than the short circuit one?

It's 'unsafe' to the extent that someone who is badly informed, or who
expects Ada to behave the same way as C, might use it unsafely: you might as
well say signed integer types are unsafe. You ask the question in 'pure Ada
terms', but in 'pure Ada terms' they're just as safe as each other: a 'pure
Ada' programmer would have no baggage in terms of preconceived expectation
of short-circuiting behaviour from boolean operators.

Cheers,

Nick.

Re: A case where Ada defaults to unsafe?

[Florian Weimer]

Hyman Rosen <hyrosen@mail.com> writes:

> You haven't answered my question, though. Isn't the commutative semantic
> less safe than the short circuit one?

IMGO, it's just different.  If the code doesn't work using (the
equivalent of) "and", why should it work reliably using "and then"?

However, there is not much choice from a language design point of
view: The short-circuit form of the operator cannot be meaningfully
redefined, but the commutative form can (perhaps) be.

(In fact, your claim "In C/C++, the && and || binary operators
short-circuit",is wrong for C++.)

Re: A case where Ada defaults to unsafe?

[Preben Randhol]

On Thu, 03 Jan 2002 18:07:42 -0500, Hyman Rosen wrote:
> 
> You haven't answered my question, though. Isn't the commutative semantic
> less safe than the short circuit one?

Why shouldn't both sides be evaluated? I mean if you base your if
sentences on that left of and/or must be true for the right side to be
valid then I would say that "and then" and "or else" is better as IMHO
this should not be the general way you make an if sentence. It shouldn't
matter really whether it is the right side or left side that gets
evaluated first.

Preben
-- 
 ()   Join the worldwide campaign to protect fundamental human rights.
'||}
{||'                                           http://www.amnesty.org/

Re: A case where Ada defaults to unsafe?

[Wes Groleau]

Hyman Rosen wrote:
> You haven't answered my question, though. Isn't the commutative semantic
> less safe than the short circuit one?

Not necessarily.  A person who could type
the example you gave and not know that the
order matters could just as easily type them
in the wrong order.

And there's a big difference between something
that's raises an exception at _one_place_ in
_one_unit_ and something that makes other things
unreliable in other files.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: A case where Ada defaults to unsafe?

[Ted Dennison]

In article <3C34E43E.5070906@mail.com>, Hyman Rosen says...
>
>Ted Dennison wrote:
>
>> In article <3C34D252.4070307@mail.com>, Hyman Rosen says...
>> 
>>>But get away from C/C++ for a moment. In pure Ada terms, isn't it less safe
>>>for the defaults to be "and" and "or" instead of "and then" and "or else"?
>>>
>> 
>> Perhaps for ex-C programmers it is. But that's certianly not the only pitfall in
>> the language for ex-C programmers.
>> 
>> If you were instead brought up to believe that boolean "and" is communitive,
>> like they teach in math/logic classes, then it makes perfect sense. In that
>> case, "and then" is just a nice shorthand for " then if ... then".
>
>
>You haven't answered my question, though. Isn't the commutative semantic
>less safe than the short circuit one?

Yes I have, but I'll do it again: Its only less safe if you are an ex-C
programmer that expects the world to look like C. 

Let's analyze this a little deeper, shall we? Under what conditions is this
unsafe?

The typical use of "and" and "or" is to perform clasical boolean math, and
perhaps to do different things based on the result. Which is more "unsafe" in
this typcial circumstance? Neither really. 

What you are talking about is a different situation where you may realise that
something like dereferencing a pointer will cause problems when the pointer is
null. So you tell yourself, "self, I'd better prevent an error by first putting
in a check to see if the pointer is invalid, then not performing that second
operation if that's the case". So you consciously put in the check. 

So here we are, consciously adding code to implement a "don't do this check
unless this other check works out" operation. The only way to screw this up is
to use the wrong language features, and the only way we are ever going to do
that would be if somewhere along the line something (eg: C) convinced us that
these two quite different types of operations are actually the same.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: A case where Ada defaults to unsafe?

[Eric Merritt]

--- Ted Dennison <dennison@telepath.com> wrote:
> In article <3C34D252.4070307@mail.com>, Hyman Rosen
> says...
> >But get away from C/C++ for a moment. In pure Ada
> terms, isn't it less safe
> >for the defaults to be "and" and "or" instead of
> "and then" and "or else"?
> 

Who said these where the defaults? Does the language
put them in for you? no. So they are not a default in
any way. You (and me really) just tend to think of
these as the default becuase of our history in other
langauges.  For someone that used Ada day in and day
out these may not be a default at all. So just becuase
we think a certain way about a syntatic construct does
not mean it is an inherent flaw in the langauge.


__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

Re: A case where Ada defaults to unsafe?

[Robert A Duff]

Eric Merritt <cyberlync@yahoo.com> writes:

> --- Ted Dennison <dennison@telepath.com> wrote:
> > In article <3C34D252.4070307@mail.com>, Hyman Rosen
> > says...
> > >But get away from C/C++ for a moment. In pure Ada
> > terms, isn't it less safe
> > >for the defaults to be "and" and "or" instead of
> > "and then" and "or else"?
> > 
> 
> Who said these where the defaults? Does the language
> put them in for you? no. So they are not a default in
> any way. You (and me really) just tend to think of
> these as the default becuase of our history in other
> langauges.

I think it's fair to call the shorter syntax the "default".
You have to say something extra to get short-circuit behavior
(and I think that's a good thing).

It's got nothing to do with other languages.

Similarly, I would say "The default parameter mode is 'in'."
And "objects are variable by default" and "objects are not aliased by default".

- Bob

Re: A case where Ada defaults to unsafe?

[Robert A Duff]

Hyman Rosen <hyrosen@mail.com> writes:

> But get away from C/C++ for a moment. In pure Ada terms, isn't it less safe
> for the defaults to be "and" and "or" instead of "and then" and "or else"?

I think an expression where the right-hand side is meaningful only if
the left-hand side is True is "special" and should be marked as such
("and then").  A more usual expression, where the two halves of "and"
are symmetric, doesn't deserve the "extra" notation.  I guess I'm
arguing from a readability point of view, rather than safety per se.
But readability promotes safety in general.

Some people *always* use "and then", perhaps on the theory that it's
more efficient.  I don't like that style.

If you're looking for cases where Ada makes the default less safe, I can
think of a few.  Here's one: "X: T := ...;" is a variable, whereas
"X: constant T := ...;" is a constant.  IMHO, it should be the other way
around ("X: var T := ...;" for a variable), since constants are safer
than variables.

- Bob

Re: A case where Ada defaults to unsafe?

[Larry Kilgallen]

In article <wccwuyycht9.fsf@shell01.TheWorld.com>, Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> If you're looking for cases where Ada makes the default less safe, I can
> think of a few.  Here's one: "X: T := ...;" is a variable, whereas
> "X: constant T := ...;" is a constant.  IMHO, it should be the other way
> around ("X: var T := ...;" for a variable), since constants are safer
> than variables.

Only if testing is thorough.

Re: A case where Ada defaults to unsafe?

[Ted Dennison]

In article <wccwuyycht9.fsf@shell01.TheWorld.com>, Robert A Duff says...
>
>Hyman Rosen <hyrosen@mail.com> writes:
>
>> But get away from C/C++ for a moment. In pure Ada terms, isn't it less safe
>> for the defaults to be "and" and "or" instead of "and then" and "or else"?
>
>I think an expression where the right-hand side is meaningful only if
>the left-hand side is True is "special" and should be marked as such
>("and then").  A more usual expression, where the two halves of "and"
>are symmetric, doesn't deserve the "extra" notation.  I guess I'm
>arguing from a readability point of view, rather than safety per se.
>But readability promotes safety in general.

Right. For example, suppose we "fix" things so that all boolean ops
short-circuit. Now there's no way for a reader to tell the difference between
boolean ops that are ordered the way they are for safety, or just accidentally.
But the most common occurance is always going to be the latter. So when Joe
Maintainence comes in and adds a condition to an "if" statement (as is *very*
common), he is now much more likely to screw up the code, since he can't tell by
just looking at it if the order of the existing conditions is important.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: A case where Ada defaults to unsafe?

[Ted Dennison]

In article <wccwuyycht9.fsf@shell01.TheWorld.com>, Robert A Duff says...
>If you're looking for cases where Ada makes the default less safe, I can
>think of a few.  Here's one: "X: T := ...;" is a variable, whereas
>"X: constant T := ...;" is a constant.  IMHO, it should be the other way
>around ("X: var T := ...;" for a variable), since constants are safer
>than variables.

I think this is another example of the *real* design principle here, which is to
make the more common and more general form take the least syntax, and use added
syntax to specify a more constrained and/or less common form. 

If I try real hard I can come up with reasons why just about any design decision
might have error-prone implications (particularly if I start with the postulate
that everyone thinks like a C programmer).

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: A case where Ada defaults to unsafe?

[Robert A Duff]

Ted Dennison<dennison@telepath.com> writes:

> In article <wccwuyycht9.fsf@shell01.TheWorld.com>, Robert A Duff says...
> >If you're looking for cases where Ada makes the default less safe, I can
> >think of a few.  Here's one: "X: T := ...;" is a variable, whereas
> >"X: constant T := ...;" is a constant.  IMHO, it should be the other way
> >around ("X: var T := ...;" for a variable), since constants are safer
> >than variables.

> I think this is another example of the *real* design principle here,
> which is to make the more common and more general form take the least
> syntax, and use added syntax to specify a more constrained and/or less
> common form.

I do not agree with that design principle.  The default should be the
thing that is safer/less-powerful.  To use the
more-powerful/more-dangerous option should require extra syntax.
What's more common is irrelevant.

Of course, one hopes that the safer thing is also the most common thing.
For example, if programmers have to do type conversions or unsafe casts
on every other line of code, then something is wrong with the language
design -- whether those casts are explicit or implicit.  So in practise,
your principle will often come up with the same answer as mine.

Many Ada programs use variables where they should use constants.  Making
the default the other way around (i.e. not punishing the safer case with
verbosity) would somewhat alleviate that problem.

The choice of "variable by default, constant requires explicit notation"
is particularly annoying to me because it is inconsistent: for
parameters, it's the other way 'round.

An interesting question is whether variables are more common than
constants in Ada.  I have no idea.  If you adopt a "mostly functional"
style, you'll have a lot of constants...

> If I try real hard I can come up with reasons why just about any
> design decision might have error-prone implications (particularly if I
> start with the postulate that everyone thinks like a C programmer).

My point above has nothing to do with C or C programmers.

- Bob

Re: A case where Ada defaults to unsafe?

[Dmitry A. Kazakov]

On Thu, 10 Jan 2002 21:22:05 GMT, Robert A Duff
<bobduff@shell01.TheWorld.com> wrote:

>Ted Dennison<dennison@telepath.com> writes:
>
>> In article <wccwuyycht9.fsf@shell01.TheWorld.com>, Robert A Duff says...
>> >If you're looking for cases where Ada makes the default less safe, I can
>> >think of a few.  Here's one: "X: T := ...;" is a variable, whereas
>> >"X: constant T := ...;" is a constant.  IMHO, it should be the other way
>> >around ("X: var T := ...;" for a variable), since constants are safer
>> >than variables.

Why not "X : in out T := ...;" for variables, and "X : [in] T := ...;"
for constants?

[too many keywords already]

>> I think this is another example of the *real* design principle here,
>> which is to make the more common and more general form take the least
>> syntax, and use added syntax to specify a more constrained and/or less
>> common form.
>
>I do not agree with that design principle.  The default should be the
>thing that is safer/less-powerful.  To use the
>more-powerful/more-dangerous option should require extra syntax.
>What's more common is irrelevant.

Argee

If we continue the logic of providing extra syntax for dangerous
things, then IMO, it would be safer to require an initial value to be
given if there is no default. I.e. to have an uninitialized variable
one should write something like:

X : out T; -- No initial value

or even:

X : [in] out T := abstract; -- No initial value

X : [in out] T; -- Error, if T provides no initialization of its
instances

Regards,
Dmitry Kazakov

Re: A case where Ada defaults to unsafe?

[Brian Rogoff]

On Fri, 4 Jan 2002, Robert A Duff wrote:
> If you're looking for cases where Ada makes the default less safe, I can
> think of a few.  Here's one: "X: T := ...;" is a variable, whereas
> "X: constant T := ...;" is a constant.  IMHO, it should be the other way
> around ("X: var T := ...;" for a variable), since constants are safer
> than variables.

I know I'm digressing a bit, but I'd prefer that ":=" not be used for
declaring the value of a constant, since I think of that as being
different from assignment. Better to use "=" IMO. Of course I am now
spoiled by functional (quasifunctional :) languages like ML where
assignment is far less frequent than in Ada or C++. Assignment and
equality hide a lot of complexity behind a simple facade; that seems to
have been recognized by the Ada designers.

-- Brian

Re: A case where Ada defaults to unsafe?

[Ted Dennison]

In article <Pine.BSF.4.40.0201041614240.84382-100000@bpr.best.vwh.net>, Brian
Rogoff says...
>I know I'm digressing a bit, but I'd prefer that ":=" not be used for
>declaring the value of a constant, since I think of that as being
>different from assignment. Better to use "=" IMO. Of course I am now

That's actually a pretty good point (but boolean equality is even further off
the mark). I'd think using "=>" would be more appropriate. The arrow probably
points the wrong way, but that's the way aggregates and parameter associations
do it, and that's alot more akin to what is going on here.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: A case where Ada defaults to unsafe?

[Mark Lundquist]

"Brian Rogoff" <bpr@bpr.best.vwh.net> wrote in message
news:Pine.BSF.4.40.0201041614240.84382-100000@bpr.best.vwh.net...
>
> I know I'm digressing a bit, but I'd prefer that ":=" not be used for
> declaring the value of a constant, since I think of that as being
> different from assignment.

Yes, and unfortunately it goes deeper than that, because in Ada the binding
of a value to a constant really *is* an assignment.  The same is true for
the other case in which an initial value must be supplied: indefinite types.
In both cases there are practical ramifications, so it's more than just an
aesthetic point or a preference for some way of thinking.

These are the cases where "if you have the object, you have a value" (almost
like a dual of limitedness, since limitedness says "if you have a value, you
have an object").

Anyway... the practical ramifications are:

1) Can't have a constant of a limited type (constant declared by the user of
an abstraction; not talking about deferred constants)

2) To have complete control over instances of an abstraction, we often
declare the type to be publicly limited and indefinite.  But then if objects
of the type are to be created, they must be created on the heap and a
pointer returned to the client.
    In many situations where heap allocation would be necessary in some
other languages, the design of Ada (functions returning indefinite types;
discriminants) allows it to be avoided.  The call stack can be thought of
(if we must) as serving as a kind of "scoped heap".  Defining the binding of
an initial value as "assignment" eliminates this advantage for limited
types.

3) Sometimes the type must be publicly indefinite for other reasons, and
then we still have the same problem as (2), i.e. we are forced to choose
between making the type nonlimited (when we may wish -- or indeed require --
it to be limited) vs. using the heap (if the type must be limited, then we
must use the heap).

4) For many types we would like to ensure that objects of the type always ha
ve a defined value.  In the case of limited types, we might be able to use
default initialization for this, but that may or may not be possible and it
may or may not be enough or really what we want.  So the object of the type
can be declared, but until an initialization procedure can be called it may
not have a defined value, or not the kind of value we want it to have.
(There are workarounds for this, though...)

It seems like this might be fixable in Ada0X (although you'll probably be
stuck with ":=" for constant initialization :-) -- it just would have to
mean something different than assigment there)

-- mark

Re: A case where Ada defaults to unsafe?

[Matthew Heaney]

"Mark Lundquist" <no.spam@getalife.com> wrote in message
news:91J_7.1831$fG.7284@rwcrnsc51.ops.asp.att.net...
> 2) To have complete control over instances of an abstraction, we often
> declare the type to be publicly limited and indefinite.  But then if
objects
> of the type are to be created, they must be created on the heap and a
> pointer returned to the client.

That depends how you define "heap."  Officially you allocate instances from
a "storage pool," and the pool object may or may not be on the heap.  I've
written storage pools that were statically allocated, and so instances
allocated via new come from static storage, not the heap.

Actually, it's not even necessary to use an allocator, for example:

package P is
   type T (<>) is limited private;
   type T_Access is access all T;
   function New_T return T_Access;
end P;

and then you can implement New_T by removing the head of a linked list of
objects of type T.

The point is that whatever decision you make is hidden behind function
New_T.

Re: A case where Ada defaults to unsafe?

[Robert A Duff]

"Matthew Heaney" <mheaney@on2.com> writes:

> That depends how you define "heap."

I define "a heap" as a synonym for "a storage pool".  Now "*the* heap"
is another matter.  ;-)

User defined storage pools can take advantage of special properties of
the allocated type to produce efficient allocation.  But still, nothing
beats the normal allocation in the stack frame of a procedure.

- Bob

Re: A case where Ada defaults to unsafe?

[Robert A Duff]

Brian Rogoff <bpr@bpr.best.vwh.net> writes:

> On Fri, 4 Jan 2002, Robert A Duff wrote:
> > If you're looking for cases where Ada makes the default less safe, I can
> > think of a few.  Here's one: "X: T := ...;" is a variable, whereas
> > "X: constant T := ...;" is a constant.  IMHO, it should be the other way
> > around ("X: var T := ...;" for a variable), since constants are safer
> > than variables.
> 
> I know I'm digressing a bit, but I'd prefer that ":=" not be used for
> declaring the value of a constant, since I think of that as being
> different from assignment.

It seems to me that initializing an object is conceptually different
from an assignment statement, and therefore deserves a different
notation.  But I would use the same notation for initializing both
constants and variables.  I'm not sure I like "=", because we already
use that for equality tests.  How about ":=" for init, and ":==" for
assignment statements?  (Imagine you're designing a language from
scratch, here.)

>... Better to use "=" IMO. Of course I am now
> spoiled by functional (quasifunctional :) languages like ML where
> assignment is far less frequent than in Ada or C++. Assignment and
> equality hide a lot of complexity behind a simple facade; that seems to
> have been recognized by the Ada designers.

A related issue is limited types: you ought to be able to return a
nonlocal object from a function, you ought to be able to use aggregates,
and you ought to be able to do initialization.  It's really the "fetch
value out of object" operation that should be considered naughty for
limited types.  Not the assignment operation.

- Bob

Re: A case where Ada defaults to unsafe?

[Dmitry A. Kazakov]

On Thu, 10 Jan 2002 21:29:05 GMT, Robert A Duff
<bobduff@shell01.TheWorld.com> wrote:

>It seems to me that initializing an object is conceptually different
>from an assignment statement, and therefore deserves a different
>notation.  But I would use the same notation for initializing both
>constants and variables.  I'm not sure I like "=", because we already
>use that for equality tests.  How about ":=" for init, and ":==" for
>assignment statements?  (Imagine you're designing a language from
>scratch, here.)

Someone has already pointed that in Ada there are two different
keywords for initialization. One is ":=", another is "is". For
instance:

procedure Foo is
begin
  ---
end Foo;

is imaginary

Foo :constant Some_anonymous_routine_type := begin ... end Foo;
 
One could always use "is", like:

Count : Integer is 5;

Regards,
Dmitry Kazakov

Re: A case where Ada defaults to unsafe?

[Brian Rogoff]

On Thu, 10 Jan 2002, Robert A Duff wrote:
> Brian Rogoff <bpr@bpr.best.vwh.net> writes:
> > On Fri, 4 Jan 2002, Robert A Duff wrote:
> > > If you're looking for cases where Ada makes the default less safe, I can
> > > think of a few.  Here's one: "X: T := ...;" is a variable, whereas
> > > "X: constant T := ...;" is a constant.  IMHO, it should be the other way
> > > around ("X: var T := ...;" for a variable), since constants are safer
> > > than variables.
> >
> > I know I'm digressing a bit, but I'd prefer that ":=" not be used for
> > declaring the value of a constant, since I think of that as being
> > different from assignment.
>
> It seems to me that initializing an object is conceptually different
> from an assignment statement, and therefore deserves a different
> notation.  But I would use the same notation for initializing both
> constants and variables.  I'm not sure I like "=", because we already
> use that for equality tests.  How about ":=" for init, and ":==" for
> assignment statements?  (Imagine you're designing a language from
> scratch, here.)

I assume that you are assuming that assignment will be less frequent than
object initialization, and so assignment gets the longer token?

I'm not sure I like this proposal. Do we really want to think of constant
initialization as being like assignment? It seems that we're really just
declaring its value, and that =, or "is" as someone else suggested, is
better.

-- Brian

Re: A case where Ada defaults to unsafe?

[Robert A Duff]

Brian Rogoff <bpr@bpr.best.vwh.net> writes:

> I assume that you are assuming that assignment will be less frequent than
> object initialization, and so assignment gets the longer token?

Well, if you program in a mostly-functional style, that would be true.
But that's not why.  It just seems like the "safer" thing should usually
be shorter.

> I'm not sure I like this proposal. Do we really want to think of constant
> initialization as being like assignment?

I think so.  I want to think of constant initialization as being like
variable initialization.  In fact, I want the semantics to be
identical.  In other words, a constant and a variable are the same thing
-- except you can't assign into a constant.

>... It seems that we're really just
> declaring its value, and that =, or "is" as someone else suggested, is
> better.

Yeah, "is" seems nice for constants, but it makes no sense for
variables.  Surely you don't want a different notation for variable
initialization?!

- Bob

Re: A case where Ada defaults to unsafe?

[Brian Rogoff]

On Sat, 19 Jan 2002, Robert A Duff wrote:
> Brian Rogoff <bpr@bpr.best.vwh.net> writes:
>
> > I assume that you are assuming that assignment will be less frequent than
> > object initialization, and so assignment gets the longer token?
>
> Well, if you program in a mostly-functional style, that would be true.

In my pet language, OCaml, you can only assign to record fields which are
declared mutable. There is also syntactic sugar for SML style refs, which
are just polymorphic records with a single mutable field. Initialization
of constants and vars uses "=", and there are two notations for assignment
depending on whether you're assigning to a ref or the mutable field of a
record. Is that kind of like what you want?

Somehow, I don't think of Ada as being a mostly functional language, nor
do I think of a future Ada like language as being one, though I certainly
look to ML and Haskell as inspirations.

> But that's not why.  It just seems like the "safer" thing should usually
> be shorter.

Of course, forgive me ;-).

> > I'm not sure I like this proposal. Do we really want to think of constant
> > initialization as being like assignment?
>
> I think so.  I want to think of constant initialization as being like
> variable initialization.  In fact, I want the semantics to be
> identical.  In other words, a constant and a variable are the same thing
> -- except you can't assign into a constant.

OK. Given that view, the ML approach may appeal to you (or not, as you're
a contentious fellow :-).

> >... It seems that we're really just
> > declaring its value, and that =, or "is" as someone else suggested, is
> > better.
>
> Yeah, "is" seems nice for constants, but it makes no sense for
> variables.  Surely you don't want a different notation for variable
> initialization?!

No, but "is" doesn't seem as bad for "variables" if the mutability is part
of the type, as in OCaml. My gut feeling is that ultimately type systems
like those of Clean and Mercury which have uniqueness types are the way to
go, and that OCaml style mutable declarations, and Ada's limited and
controlled types, and Haskell's monadic state machinery, are all just a
bit hacky or unsafe. I don't know if that kind of thing makes sense for a
low level language like Ada though. Any language which provides control
over underlying representations, like Ada, will never be really safe.

-- Brian

Re: A case where Ada defaults to unsafe?

[Robert Dewar]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<3C34D252.4070307@mail.com>...
> Frank J. Lhota wrote:
> 
> > The situation is quite similar in C/C++; if you use the siumpler & and |
> > operators, they do not short-circuit. In either C/C++ or Ada, experienced
> > programmers know what needs to be done in order to get short-circuiting.
> 
> 
> In C/C++ "everyone" knows that & and | are for bit twiddling and && and ||
> are for combining logical expressions.

Well any vaguely competent Ada programmer should equally
well know that in Ada "and then" and "or else" short circuit and "and"
and "or" do not.

If you think, as apparently you think C programmers think,
that all combination of logical expressions should be done
using the more verbose operator (about twice as long in
both C and Ada) then always use "and then" and "or else".
This is more or less the philosophy in GNAT (the one exception is when
logical variables are combined, and
indeed in C it is reasonable if Is_Undefined and Is_Unsafe
are booleans to say

   if (Is_Undesigned | Is_Unsafe) then

Indeed with some not very clever C compilers, the above
will give significantly better code than using || :-)

> But get away from C/C++ for a moment. In pure Ada terms, isn't it less safe
> for the defaults to be "and" and "or" instead of "and then" and "or else"?

Defaults? What are you talking about? There are two operators, one is
called AND and one is called AND THEN,
and neither is chosen by default, you use the one you
want.

Exactly the same as in C, where you use either & or &&.
You claim that the difference is that in C everyone knows
which to use, and think that this is not the case in Ada,
but is it not the case that you are simply saying you are
more familiar with C than with Ada? Which may of course be
true, but does not lead to an even playing field analysis.

This is in fact a place where C and Ada take a very similar
approach, both providing a more verbose operator for the
short circuiting case. As in C, the AND in Ada can also
mean bit wise AND (like &) as well as being used for
combining boolean values.

I do think there is an argument for making AND mean short
circuiting, and having a separate operator for bit-wise
AND. I would apply the same argument to C, and say that it
would have been better if the normally used and/or were
spelled & | instead of the awkward && and ||

(yes, I know, && and || seem "perfectly natural" since you
have used them so long, sort of like English spelling seems
logical to those who have had to deal with it for ever :-)

Re: A case where Ada defaults to unsafe?

[Hyman Rosen]

Robert Dewar wrote:

> Well any vaguely competent Ada programmer should equally
> well know that in Ada "and then" and "or else" short circuit

 > and "and" and "or" do not.

Sure. But what do you gain from the non-short-circuit ones,
except for the risk that you've used them incorrectly?


> Exactly the same as in C, where you use either & or &&.


In C, you cannot use & and | in the same way that you use
&& and ||, because the former accept only integer operands.
For example, if you have a pair of pointers, p and q, and
wish to test whether both are not null, you must use p&&q.
If you were to use p&q, the compiler would reject it.

C++ does have the horrible trap that user-defined && and ||
operators don't short-circuit. Expert advice is to never
define these except in the rarest of circumstances.

Re: A case where Ada defaults to unsafe?

[Matthew Heaney]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3C35E733.6030603@mail.com...
> In C, you cannot use & and | in the same way that you use
> && and ||, because the former accept only integer operands.

But you have to know that.  How is learning the difference between "&" and
"&&" any different from learning the difference between "and" and "and
then"?


> For example, if you have a pair of pointers, p and q, and
> wish to test whether both are not null, you must use p&&q.
> If you were to use p&q, the compiler would reject it.

This is a specious comparison, because your question was about an expression
that compiles using either operator.  Suppose you have a pair of integers:
how does a programmer learn the difference between

   if (i & j)

and

  if (i && j)


> C++ does have the horrible trap that user-defined && and ||
> operators don't short-circuit. Expert advice is to never
> define these except in the rarest of circumstances.

Well if we're talking about having an expert's knowledge then this thread is
irrelevant.

Re: A case where Ada defaults to unsafe?

[Darren New]

Matthew Heaney wrote:
> how does a programmer learn the difference between
>    if (i & j)
> and
>   if (i && j)

When i==1 and j==2 ?

This is why some versions of BASIC define "true" as "-1". 

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
 Why do "stressed" and "distressed" mean the same thing?

Re: A case where Ada defaults to unsafe?

[Hyman Rosen]

Matthew Heaney wrote:

> But you have to know that.  How is learning the difference between "&" and
> "&&" any different from learning the difference between "and" and "and
> then"?


"&" does integer bit combinations, while "&&" does a boolean
conjunction on (lhs != 0) and (rhs != 0), short-circuiting as
needed. The operations are totally different.

On the other hand, "and" and "and then" perform the same logical
operation. To use "and", the programmer must make a decision that
the order of evaluation of the operands doesn't matter. If he is
wrong, he has introduced a subtle bug. If he is right, he has
gained nothing over using "and then".

Re: A case where Ada defaults to unsafe?

[Matthew Heaney]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3C35FE2A.9020802@mail.com...
> "&" does integer bit combinations, while "&&" does a boolean
> conjunction on (lhs != 0) and (rhs != 0), short-circuiting as
> needed. The operations are totally different.

The operations are totally different because you learned that they are
totally different.


> On the other hand, "and" and "and then" perform the same logical
> operation.

No, they do not.  "and then" is a short circuit operator.

> To use "and", the programmer must make a decision that
> the order of evaluation of the operands doesn't matter.

When order of evaluation is significant, the Ada designers decided that a
special syntax is called for.


> If he is
> wrong, he has introduced a subtle bug. If he is right, he has
> gained nothing over using "and then".

There are many ways to have a subtle bug.  Just think of all the operator
precedence headaches in C; see below.

http://www.lysator.liu.se/c/dmr-on-or.html#main

Of all the problems I've had in Ada, getting short-circuit evaluation wrong
is waaayyyy at the bottom of the list...

Re: A case where Ada defaults to unsafe?

[Ted Dennison]

In article <u3c2lgenii1m55@corp.supernews.com>, Matthew Heaney says...
>
>Of all the problems I've had in Ada, getting short-circuit evaluation wrong
>is waaayyyy at the bottom of the list...

I don't think I've *ever* had such a bug. It is fairly common for me to forget
to guard a pointer with a short circuit " /= null" expression (on those rare
occasions when I'm using pointers in the first place), but I don't think I've
ever done that and left out the "then".

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: A case where Ada defaults to unsafe?

[Hyman Rosen]

Matthew Heaney wrote:

> When order of evaluation is significant, the Ada designers decided that a
> special syntax is called for.


Forget that any other programming languages exist, for the moment.

If I use "and" and I'm wrong in assuming that the order doesn't matter,
then I have introduced a subtle bug. If I'm right, then I haven't gained
anything. So why not always use "and then"?

Re: A case where Ada defaults to unsafe?

[Larry Kilgallen]

In article <3C360E76.3070308@mail.com>, Hyman Rosen <hyrosen@mail.com> writes:
> Matthew Heaney wrote:
> 
>> When order of evaluation is significant, the Ada designers decided that a
>> special syntax is called for.
> 
> 
> Forget that any other programming languages exist, for the moment.
> 
> If I use "and" and I'm wrong in assuming that the order doesn't matter,
> then I have introduced a subtle bug. If I'm right, then I haven't gained
> anything.

You have gained the ability for the compiler to optimize better
and for a maintainer to alter the order knowing there is no ordering
requirement.

Re: A case where Ada defaults to unsafe?

[Ted Dennison]

In article <3C360E76.3070308@mail.com>, Hyman Rosen says...
>Forget that any other programming languages exist, for the moment.
>
>If I use "and" and I'm wrong in assuming that the order doesn't matter,
>then I have introduced a subtle bug. If I'm right, then I haven't gained
>anything. 

I can't possibly be reading this right. It seems you are trying to argue that
all of the following are true:

o  communative "and" has no practical benifits (a debatable point, but one which
we have answered multiple times),
o  documenting the fact that you shouldn't move the components of a particular
condition around is of no benifit.
o  "and then" somehow saves you when you get the order of conditions backwards.


>So why not always use "and then"?

There are some who do that. I think the documentation issue alone is worth not
doing things that way though.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: A case where Ada defaults to unsafe?

[Hyman Rosen]

Ted Dennison wrote:

> I can't possibly be reading this right. It seems you are trying to argue that
> all of the following are true:
> 
> o  communative "and" has no practical benifits (a debatable point, but one which
> we have answered multiple times),


I can see only one *practical* benefit, which is that you can write
an overloaded version for your own data types which then has the same
semantics as the built-in version, i.e., both operands are always
evaluated. I haven't seen multiple answers otherwise, except for dubious
claims about optimization.


> o  documenting the fact that you shouldn't move the components of a particular
> condition around is of no benifit.

> o  "and then" somehow saves you when you get the order of conditions backwards.


No, you misunderstand - I'm claiming that except for point one, "and" semantics
are useless and that the program is better served by "and then".

Re: A case where Ada defaults to unsafe?

[Ted Dennison]

In article <3C39C120.1060706@mail.com>, Hyman Rosen says...
>
>Ted Dennison wrote:
>
>> o  communative "and" has no practical benifits (a debatable point, but one which
>> we have answered multiple times),
>evaluated. I haven't seen multiple answers otherwise, except for dubious
>claims about optimization.

As I said, its debateable. However, that is the rationale that is in the
Rationale.

>> o  documenting the fact that you shouldn't move the components of a particular
>> condition around is of no benifit.
>No, you misunderstand - I'm claiming that except for point one, "and" semantics
>are useless and that the program is better served by "and then".

Fair enough. I wouldn't so blithely throw out point one, myself. But that's me.
Clearly others (such as ACT) have no problem with doing so. Then again, they
also have the benifit of writing code targetted to a single compiler, the
optimization capabilities of which they are intamately famililar with and in
farily complete control of.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: A case where Ada defaults to unsafe?

[Larry Kilgallen]

In article <3C39C120.1060706@mail.com>, Hyman Rosen <hyrosen@mail.com> writes:

> I can see only one *practical* benefit, which is that you can write
> an overloaded version for your own data types which then has the same
> semantics as the built-in version, i.e., both operands are always
> evaluated. I haven't seen multiple answers otherwise, except for dubious
> claims about optimization.

What is dubious about optimizing:

	if my_function (arg1, arg2, arg3, arg4) and not suppression_mode
        then

where suppression_mode is a boolean variable ?

Re: A case where Ada defaults to unsafe?

[Hyman Rosen]

Larry Kilgallen wrote:

> What is dubious about optimizing:
> 	if my_function (arg1, arg2, arg3, arg4) and not suppression_mode
>         then
> where suppression_mode is a boolean variable ?


What is it you're asking me here? In this case Ada requires that
my_function is called, regardless of the value of suppression_mode,
so what optimization do you have in mind? Remember, "and" is
required to evaluate both operands. You seem to think that "and" is
allowed to short-circuit one of the operands.

Re: A case where Ada defaults to unsafe?

[Pat Rogers]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3C39D86C.7030704@mail.com...
> Larry Kilgallen wrote:
>
> > What is dubious about optimizing:
> > if my_function (arg1, arg2, arg3, arg4) and not suppression_mode
> >         then
> > where suppression_mode is a boolean variable ?
>
>
> What is it you're asking me here? In this case Ada requires that
> my_function is called, regardless of the value of suppression_mode,
> so what optimization do you have in mind? Remember, "and" is
> required to evaluate both operands. You seem to think that "and" is
> allowed to short-circuit one of the operands.

Well of course "and" is allowed to ignore one of the operands; if the first one
evaluated is false, there is no need to evaluate the second.  We are just not
guaranteed which is evaluated first.


--
---
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com          Real-Time/OO Languages
progers@classwide.com               Hard Deadline Schedulability Analysis
(281)648-3165                                 Software Fault Tolerance

Re: A case where Ada defaults to unsafe?

[Hyman Rosen]

Pat Rogers wrote:

> Well of course "and" is allowed to ignore one of the operands; if the first one
> evaluated is false, there is no need to evaluate the second.  We are just not
> guaranteed which is evaluated first.


You are quite wrong. So much for the claim that experienced Ada
programmers simply learn the difference between "and" and "and then"!
See, for example, 3.8 in the Ada83 Rationale.

Re: A case where Ada defaults to unsafe?

[FGD]

Hyman Rosen wrote:

> Pat Rogers wrote:
> 
>> Well of course "and" is allowed to ignore one of the operands; if the 
>> first one
>> evaluated is false, there is no need to evaluate the second.  We are 
>> just not
>> guaranteed which is evaluated first.
> 
> You are quite wrong. So much for the claim that experienced Ada
> programmers simply learn the difference between "and" and "and then"!
> See, for example, 3.8 in the Ada83 Rationale.
> 


That's not quite right either, the end result of "cond_1 and cond_2" 
must be *as if* both cond_1 and cond_2 were evaluated. The Boolean 
operator and is just like any function, but it is expanded inline and 
may be optimized by the compiler. So the compiler could omit the 
evaluation of a condition if it is known not to have side effects. This 
happens frequently when the conditions are comparisons of numeric types 
for example.

-- Frank

Re: A case where Ada defaults to unsafe?

[Pat Rogers]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3C39E520.6030508@mail.com...
> Pat Rogers wrote:
>
> > Well of course "and" is allowed to ignore one of the operands; if the first
one
> > evaluated is false, there is no need to evaluate the second.  We are just
not
> > guaranteed which is evaluated first.
>
>
> You are quite wrong. So much for the claim that experienced Ada
> programmers simply learn the difference between "and" and "and then"!
> See, for example, 3.8 in the Ada83 Rationale.

Although it is questionable to base arguments on the Rationale, especially for
the obsolete version of the language, let me suggest you consider 3.10 of the
Ada 83 Rationale, which says in part, when introducing the short-circuit forms:

"The operands of a boolean expression such as A and B can be evaluated in any
order. Depending on the complexity of the term B, it may be more efficient ...
to evaluate B only when the term A has the value TRUE.  This, however, is an
optimization decision taken by the compiler ..."

But thanks for the compliment anyway.  :-)

---
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com          Real-Time/OO Languages
progers@classwide.com               Hard Deadline Schedulability Analysis
(281)648-3165                                 Software Fault Tolerance

Re: A case where Ada defaults to unsafe?

[Nick Roberts]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3C35FE2A.9020802@mail.com...

> ...
> On the other hand, "and" and "and then" perform the same
> logical operation. To use "and", the programmer must make
> a decision that the order of evaluation of the operands
> doesn't matter.

Quite correct.


> If he is wrong, he has introduced a subtle bug.

Not necessarily subtle (but it could be).


> If he is right, he has gained nothing over using "and then".

Wrong, and I hope you can follow my explanation. I think it's quite
important!


Correct use of "and" or "or" is indeed an implicit assertion that the order
of evaluation of the operands will not affect the result. It is often
important that these operators are used (instead of the short-circuit forms)
when they can be, specifically so as to make this implicit assertion; it may
not matter to the compiler, but it could matter to the programmer
(revisiting the code). It could matter because it could very well affect
that programmer's reasoning when modifying the code. Perhaps the following
example will illustrate.

Original code:


   if Fire_Alarm(Engine) and Gearbox_Alarm(Engine) then -- A
      Activate_Extinguisher(Engine,Trickle_Mode);
   end if;
   if Gearbox_Alarm(Engine) then -- B
      Display.Activate(Gearbox_Alert(Engine));
   end if;


Supposing a programmer comes back to this code, having been told to do her
best to make indications code precede actions code. She might make the
following change:


   if Gearbox_Alarm(Engine) then -- B
      Display.Activate(Gearbox_Alert(Engine));
   end if;
   if Fire_Alarm(Engine) and Gearbox_Alarm(Engine) then -- A
      Activate_Extinguisher(Engine,Trickle_Mode);
   end if;


based on the simple deduction that since the call to Gearbox_Alarm could be
made before the call to Fire_Alarm in line A, she can assume that Fire_Alarm
does not need to be called before Gearbox_Alarm, and that it is therefore
safe to move the call the Gearbox_Alarm in line B to precede the call to
Fire_Alarm in line A.

If line A had contained "and then" instead of "and", she would not have been
able to make this deduction, and may have not made an improvement to the
code (which just might save a pilot's life one day).

In conclusion, I would humbly suggest that it is extremely important for
student programmers to be taught to use the different forms of Boolean
operator correctly!

NB: The very thought of flight systems being programmed in C++ scares the
willies out of me. God help us all. (Maybe the JSF will actually work ;-)


--
Best wishes,
Nick Roberts

Re: A case where Ada defaults to unsafe?

[Simon Wright]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes:

> Original code:
> 
> 
>    if Fire_Alarm(Engine) and Gearbox_Alarm(Engine) then -- A
>       Activate_Extinguisher(Engine,Trickle_Mode);
>    end if;
>    if Gearbox_Alarm(Engine) then -- B
>       Display.Activate(Gearbox_Alert(Engine));
>    end if;
> 
> 
> Supposing a programmer comes back to this code, having been told to do her
> best to make indications code precede actions code. She might make the
> following change:
> 
> 
>    if Gearbox_Alarm(Engine) then -- B
>       Display.Activate(Gearbox_Alert(Engine));
>    end if;
>    if Fire_Alarm(Engine) and Gearbox_Alarm(Engine) then -- A
>       Activate_Extinguisher(Engine,Trickle_Mode);
>    end if;
> 
> 
> based on the simple deduction that since the call to Gearbox_Alarm could be
> made before the call to Fire_Alarm in line A, she can assume that Fire_Alarm
> does not need to be called before Gearbox_Alarm, and that it is therefore
> safe to move the call the Gearbox_Alarm in line B to precede the call to
> Fire_Alarm in line A.
> 
> If line A had contained "and then" instead of "and", she would not have been
> able to make this deduction, and may have not made an improvement to the
> code (which just might save a pilot's life one day).

I find it quite hard to imagine this scenario, I must say.

We have a safety-related system where it is important that the
extinguisher is set off as soon as possible and activating the gearbox
alert takes sufficiently long that it can delay the extinguisher
activation beyond tolerance[1]. And we are allowing a programmer to
change this code without any process to ensure that the safety
properties of the system aren't compromised?

[1] If I'm wrong about why you think your example causes a problem,
that (to my mind) reinforces the point that making subtle deductions
about the intent of the designer from details of the implementation is
a big mistake.

Re: A case where Ada defaults to unsafe?

[Nick Roberts]

"Simon Wright" <simon@pushface.org> wrote in message
news:x7vn0ztysj6.fsf@smaug.pushface.org...

> I find it quite hard to imagine this scenario, I must say.
>
> We have a safety-related system where it is important that the
> extinguisher is set off as soon as possible and activating the gearbox
> alert takes sufficiently long that it can delay the extinguisher
> activation beyond tolerance[1]. And we are allowing a programmer to
> change this code without any process to ensure that the safety
> properties of the system aren't compromised?

You are probably quite right! This is a failure of my example, rather than
of the point it was intended to illustrate. For many kinds of less
safety-critical Ada software such an elaborate software process is not
warranted, and my argument would apply better.

> [1] If I'm wrong about why you think your example causes a problem,
> that (to my mind) reinforces the point that making subtle deductions
> about the intent of the designer from details of the implementation is
> a big mistake.

It does reinforce the point. You are wrong (you might have been right if the
changed version were the original and vice versa). The problem I was
assuming the original version might be percieved as suffering from was that,
in accordance with the principle 'make indications code precede actions',
the action code Activate_Extinguisher(...) might get stuck (if it has a
bug), and dangerously delay the indication code Display.Activate(...). This
idea does depend on the assumption that the indicator code (having much less
to do) is much less likely to have a bug that would cause it to get stuck.

In reality, one might well use ATC time-outs to protect vital code like this
from being baulked. Furthermore, I suspect indicator code would in reality
be very separate from emergency actions code (different tasks, or probably
different devices).

Perhaps I would have done better to present the example thus:


Original code:


   if A and B then -- L1
      P;
   end if;
   if B then -- L2
      Q;
   end if;


Supposing a programmer, for whatever reasons, would like to make the
following improvement:


   if B then -- L2
      Q;
   end if;
   if A and B then -- L1
      P;
   end if;


Based on the simple deduction that since the call to B could be made before
the call to A in line L1, she can assume that A does not need to be called
before B, and that it is therefore
safe to move the call the B in line L2 to precede the call to A in line L1.

If line L1 had contained "and then" instead of "and", she would not have
been able to make this deduction, and may have felt unable to make the
improvement to the code.

--
Best wishes,
Nick Roberts

Re: A case where Ada defaults to unsafe?

[Stuart Palin]

Nick Roberts wrote:
> 
> "Simon Wright" <simon@pushface.org> wrote in message
> news:x7vn0ztysj6.fsf@smaug.pushface.org...
> 
> > I find it quite hard to imagine this scenario, I must say.
> >
> > We have a safety-related system where it is important that the
> > extinguisher is set off as soon as possible and activating the gearbox
> > alert takes sufficiently long that it can delay the extinguisher
> > activation beyond tolerance[1]. And we are allowing a programmer to
> > change this code without any process to ensure that the safety
> > properties of the system aren't compromised?
> 
> You are probably quite right! This is a failure of my example, rather than
> of the point it was intended to illustrate. For many kinds of less
> safety-critical Ada software such an elaborate software process is not
> warranted, and my argument would apply better.
> 
> 
> It does reinforce the point. You are wrong (you might have been right if the
> changed version were the original and vice versa).

I think the important point in Simon's message was:

> > making subtle deductions about the **intent of the designer** from
> > **details of the implementation** is a big mistake.

If a designer is being 'clever' or has done something in a particular
way for a good reason, then this should be explicitly documented
(comments at least).

It is a big mistake to **have to** deduce detailed intent by attributing
subtle meanings to code.

Relating to the current thread I think I understand where Hyman is
coming from; but feel that ** if this is an issue ** for a particular
system that it is not difficult to adopt 'house rule' that mandate using
'and then' and 'or else' (and accepting all the downside aspects).

I think Hyman is mistaken to think that Ada is 'by default' a ** safe
language **; it has features that enhance safety by preventing (or
allowing the detection of) certain types of programming error.  Even in
subsets like SPARK it is quite possible to write unsafe programs
(Simon's and Nick's posts illustrate this).  Safety is a system property
and software safety can not be assessed in total isolation from the
system.  Quite what makes a system ** unsafe ** will depend on the
hazards facing the system and what are and are not permitted actions.


My own pet peeve in Ada is the choice of comment token;
  A := very_long_name_B - very_long_name_C
       + very_long_name_D -- very_long_name_E
       - very_long_name_F;

While thorough forms of testing should readily detect the 'missing'
reference to E, it just seems silly to introduce the risk of a simple
typo involving a commonly used mathematical symbol; especially when
there seem to be plenty of (otherwise) unused symbols available. 

--
Stuart Palin
Principal Software Engineer
BAE SYSTEMS Avionics Ltd, Rochester
G-NET 791 3364    mailto:stuart.palin@baesystems.com

Re: A case where Ada defaults to unsafe?

[Nick Roberts]

"Stuart Palin" <stuart.palin@baesystems.com> wrote in message
news:3C3C1438.FBF10FC3@baesystems.com...

> ...
> I think the important point in Simon's message was:
>
> > > making subtle deductions about the **intent of the designer** from
> > > **details of the implementation** is a big mistake.
>
> If a designer is being 'clever' or has done something in a particular
> way for a good reason, then this should be explicitly documented
> (comments at least).
>
> It is a big mistake to **have to** deduce detailed intent by attributing
> subtle meanings to code.

I agree with this principle in a big way.

However, for a lot of Ada code (maybe not flight management code), there are
always going to be situations where the designer is not available, and the
documentation and/or comments do not cover a particular design decision in
the code. Then it is, unfortunately, necessary to make deductions about the
intent of the designer from details of the implementation.

> Relating to the current thread I think I understand where Hyman is
> coming from; but feel that ** if this is an issue ** for a particular
> system that it is not difficult to adopt 'house rule' that mandate using
> 'and then' and 'or else' (and accepting all the downside aspects).

But Hyman and I can argue against such house rules (and I do!).

> I think Hyman is mistaken to think that Ada is 'by default' a ** safe
> language **; it has features that enhance safety by preventing (or
> allowing the detection of) certain types of programming error.  Even in
> subsets like SPARK it is quite possible to write unsafe programs
> (Simon's and Nick's posts illustrate this).  Safety is a system property
> and software safety can not be assessed in total isolation from the
> system.  Quite what makes a system ** unsafe ** will depend on the
> hazards facing the system and what are and are not permitted actions.

I suspect Hyman wouldn't put Ada's safety in quite such stark terms. I think
he was trying to say that Ada's features are normally safe by default,
rather than that the language as a whole is somehow magically safe (and so
programs written in Ada will never fail).

My experience is that the biggest number, and worst kind, of 'bugs' in a
safety-critical system are introduced long before the coding stage. No kind
of coding can eliminate these bugs. [This is why the strategy of hedging
with multiple codings (based on one specification) horrifies me so much, but
that's another argument.]

> My own pet peeve in Ada is the choice of comment token;
>   A := very_long_name_B - very_long_name_C
>        + very_long_name_D -- very_long_name_E
>        - very_long_name_F;
>
> While thorough forms of testing should readily detect the 'missing'
> reference to E, it just seems silly to introduce the risk of a simple
> typo involving a commonly used mathematical symbol; especially when
> there seem to be plenty of (otherwise) unused symbols available.

Hmm. How about:

   A := B + C; \~~~@@@^^^$$$^^^@@@~~~\ comment here

:-)

NB: I use a German server which is pretty good, but (in common with most
Usenet servers, I gather) it doesn't get everything posted to comp.lang.ada;
I didn't get Simon's most recent reply to me in this thread. So if my
comments appear disjointed in this way, you know why.

:-( ;-)

--
Best wishes,
Nick Roberts

Re: A case where Ada defaults to unsafe?

[Robert A Duff]

Stuart Palin <stuart.palin@baesystems.com> writes:

> While thorough forms of testing should readily detect the 'missing'
> reference to E, it just seems silly to introduce the risk of a simple
> typo involving a commonly used mathematical symbol; especially when
> there seem to be plenty of (otherwise) unused symbols available. 

Which symbol(s) would you choose?

- Bob

Re: A case where Ada defaults to unsafe?

[Stuart Palin]

Robert A Duff wrote:
> 
> Stuart Palin <stuart.palin@baesystems.com> writes:
> > While thorough forms of testing should readily detect the 'missing'
> > reference to E, it just seems silly to introduce the risk of a simple
> > typo involving a commonly used mathematical symbol; especially when
> > there seem to be plenty of (otherwise) unused symbols available.
> 
> Which symbol(s) would you choose?

Looking at my keyboard (and without studying whether it might have been
available on some 1960's keyboard) ...

Something like '{' (I would also make a syntax error not to have the
closing '}' at the end of the line).

Some potential candidates are ruled out by the Allowable Replacement
Characters (LRM[83] 2.10 - what happened to that section in LRM[95]?). 
Something like '%' would have been nice, or even '!'; perhaps even used
in a double character token.

Other possibilities could be '~' (tilde), '@'.

Even using a '##' [OK for SPARK '###' might not be pretty ;-)] might
have been better since misuse in a based literal would (seem to) be more
readily detectable.  Of course the allowable replacement character (':')
then creates a load of other possibilities (particularly with
assignment).  But again my 'first cut' thoughts are that mistakes with
these would be more readily detectable by the compiler and (given that
most people probably don't use the replacement characters) have less
potential for messing up in the first place (= less risk of a silent
error).

Anyhow it is all water under the bridge, the die is cast - but it still
peeves me!

Regards
--
Stuart Palin
Principal Software Engineer
BAE SYSTEMS Avionics Ltd, Rochester
G-NET 791 3364    mailto:stuart.palin@baesystems.com

Re: A case where Ada defaults to unsafe?

[Robert A Duff]

Stuart Palin <stuart.palin@baesystems.com> writes:

> Something like '{' (I would also make a syntax error not to have the
> closing '}' at the end of the line).

That's the same as Pascal, except that you require it to go at
end-of-line.

> Some potential candidates are ruled out by the Allowable Replacement
> Characters (LRM[83] 2.10 - what happened to that section in LRM[95]?). 

It moved to J.2.

> Anyhow it is all water under the bridge, the die is cast - but it still
> peeves me!

I don't take that attitude at all.  Ada isn't the be-all and end-all of
programming languages, so it's reasonable to discuss alternatives.

- Bob

Literate Programming [was: A case where ...]

[Nick Roberts]

What I think just be might be a worthwhile feature to add to a future
revision would be some kind of line-oriented Ada 'on/off switch'.

This is best explained by an example. Suppose the (new) standard defined a
line in source code, which contained just two lexemes, the first === and the
second an identifier, as being a (say) 'mode switch'. If the identifier is
ADA (ignoring case), the following text lines are parsed as Ada source code,
up to the next mode switch or the end of the file. If the identifier is
anything else, the following text lines are ignored, up to the next mode
switch or the end of the file.

A file could then contain e.g.


[begin snippet]


=== docbook

<para>The next function returns the opposite direction
to the one given as its parameter.</para>

=== ada

   function Opposite (Way: in Direction) return Direction;

=== docbook

<para>The next function ...


[end snippet]


This would mean that normal text files could be used to contain mixed
content, including Ada source code, and yet any standard Ada compiler could
directly compile such files. This would be a huge advantage over having to
pre-process ('tangle') the files before compiling them, which tends to
render the automatic 'make' tools supplied with Ada systems useless.

For the unfamiliar, the essence of 'literate programming' (invented by the
heroic Prof. Don Knuth) is to combine software documentation, in its own
suitable markup language (e.g. TeX or DocBook), with the source code itself,
in the same source file. This simply means you can neatly update both source
code and documentation at the same place, in the same file, at the same
time.

In the above example, with DocBook combined with Ada, the file would be
pre-processed ('weaved') to produce pure DocBook, which would then be
processed to be rendered on the screen (e.g. in a web browser) or formatted
and printed. This pre-processing could be obviated by making the mode
switches something like "<programlisting proglang="Ada"><![CDATA[" and
"]]></programlisting>".

It would be advantageous for the switches to be defined by the standard, so
that all Ada compilers would recognize them.

It would be a splendid opportunity to add a great buzzword to Ada: we could
say it was a "literate programming language". Gotta help with advocacy!

--
Best,
Nick Roberts

Re: Literate Programming [was: A case where ...]

[Georg Bauhaus]

Several things might be interesting to consult here:
ANNA,
Lout (with Ada support, can turn on Lout mode in Ada comments)

How would you deal with the multi-syntax problem that Ada/Non-Ada
switching will entail?

: For the unfamiliar, the essence of 'literate programming' (invented by the
: heroic Prof. Don Knuth) is to combine software documentation, in its own
: suitable markup language (e.g. TeX or DocBook), with the source code itself,
: in the same source file.

Plus the capability to add readability by reordering chunks
of source language code to help the reader, not the compiler
(ex.: body of nested subprograms defined outside the declarative
region of the enclosing subprogram in AdaWEB source, yet not making
it separate, big switches squeezed to one half page or so, that from
a readers point of view may seem similar to a limited PERFORM in COBOL).

A variant of this is found in Booch's Software Components with Ada.

: It would be a splendid opportunity to add a great buzzword to Ada: we could
: say it was a "literate programming language". Gotta help with advocacy!

How would that be advocacy given empirical results of advocating
literate programming? :-)


Georg

Re: Literate Programming [was: A case where ...]

[Nick Roberts]

"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:a1pop2$lgk$1@a1-hrz.uni-duisburg.de...

> Several things might be interesting to consult here:
> ANNA,
> Lout (with Ada support, can turn on Lout mode in Ada comments)

Will do.

> How would you deal with the multi-syntax problem that Ada/Non-Ada
> switching will entail?

If the switching token must be on a line on its own, and is different to
anything else (likely) to be written in any other syntax, it shouldn't be
too much of a problem?

> : For the unfamiliar, the essence of 'literate programming' (invented by
the
> : heroic Prof. Don Knuth) is to combine software documentation, in its own
> : suitable markup language (e.g. TeX or DocBook), with the source code
itself,
> : in the same source file.
>
> Plus the capability to add readability by reordering chunks
> of source language code to help the reader, not the compiler
> (ex.: body of nested subprograms defined outside the declarative
> region of the enclosing subprogram in AdaWEB source, yet not making
> it separate, big switches squeezed to one half page or so, that from
> a readers point of view may seem similar to a limited PERFORM in COBOL).

Indeed, but then that would certainly require a tangle pre-processor; there
would be some advantages (for Ada code, at least) in avoiding the need for a
tangler. An alternative (perhaps a better one) would be make/build tools
that would work with (or have built-in) a tangler.

> How would that be advocacy given empirical results of advocating
> literate programming? :-)

Well *I'm* going to keep plugging away!

--
Best wishes,
Nick Roberts

Re: Literate Programming [was: A case where ...]

[Eric Merritt]

Nick,

 Not to be simplistic but isn't this just a multi-line
comment? I realize that the purpose is to support
literate programming but what you describe seems to be
a multi-line comment line C's /**/. Of course, this
does not mean to imply that the multi-line comments
could not be parsed to extract content by a literate
tool. That being said the syntax you describe could
probably be a bit cleaner so that both those who want
to use literate techniques and those who do not would
be comfortable with it.

--- Nick Roberts <nickroberts@adaos.worldonline.co.uk>
wrote:
> What I think just be might be a worthwhile feature
> to add to a future
> revision would be some kind of line-oriented Ada
> 'on/off switch'.
> 
> This is best explained by an example. Suppose the
> (new) standard defined a
> line in source code, which contained just two
> lexemes, the first === and the
> second an identifier, as being a (say) 'mode
> switch'. If the identifier is
> ADA (ignoring case), the following text lines are
> parsed as Ada source code,
> up to the next mode switch or the end of the file.
> If the identifier is
> anything else, the following text lines are ignored,
> up to the next mode
> switch or the end of the file.
> 
> A file could then contain e.g.
> 
> 
> [begin snippet]
> 
> 
> === docbook
> 
> <para>The next function returns the opposite
> direction
> to the one given as its parameter.</para>
> 
> === ada
> 
>    function Opposite (Way: in Direction) return
> Direction;
> 
> === docbook
> 
> <para>The next function ...
> 
> 
> [end snippet]
> 
> 
> This would mean that normal text files could be used
> to contain mixed
> content, including Ada source code, and yet any
> standard Ada compiler could
> directly compile such files. This would be a huge
> advantage over having to
> pre-process ('tangle') the files before compiling
> them, which tends to
> render the automatic 'make' tools supplied with Ada
> systems useless.
> 
> For the unfamiliar, the essence of 'literate
> programming' (invented by the
> heroic Prof. Don Knuth) is to combine software
> documentation, in its own
> suitable markup language (e.g. TeX or DocBook), with
> the source code itself,
> in the same source file. This simply means you can
> neatly update both source
> code and documentation at the same place, in the
> same file, at the same
> time.
> 
> In the above example, with DocBook combined with
> Ada, the file would be
> pre-processed ('weaved') to produce pure DocBook,
> which would then be
> processed to be rendered on the screen (e.g. in a
> web browser) or formatted
> and printed. This pre-processing could be obviated
> by making the mode
> switches something like "<programlisting
> proglang="Ada"><![CDATA[" and
> "]]></programlisting>".
> 
> It would be advantageous for the switches to be
> defined by the standard, so
> that all Ada compilers would recognize them.
> 
> It would be a splendid opportunity to add a great
> buzzword to Ada: we could
> say it was a "literate programming language". Gotta
> help with advocacy!
> 
> --
> Best,
> Nick Roberts
> 
> 
> 
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada


__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

Re: Literate Programming [was: A case where ...]

[Nick Roberts]

"Eric Merritt" <cyberlync@yahoo.com> wrote in message
news:mailman.1011017881.956.comp.lang.ada@ada.eu.org...

>  Not to be simplistic

Not in the least.

> but isn't this just a multi-line comment?

Yes, I think you're quite right.

> I realize that the purpose is to support
> literate programming but what you describe seems to be
> a multi-line comment line C's /**/. Of course, this
> does not mean to imply that the multi-line comments
> could not be parsed to extract content by a literate
> tool. That being said the syntax you describe could
> probably be a bit cleaner so that both those who want
> to use literate techniques and those who do not would
> be comfortable with it.

Certainly!

The only slight variation I had in mind with my suggested syntax was: the
switch is on a line on its own, and of a form unlikely to infere with the
syntax of any programming language or text markup language; the syntax of
the switch permits multiple named 'threads' of text, allowing perhaps
maintenance documentation, the user guide, a tutorial, and other types of
document to be generated from the one source file.

I suspect, on reflection, that this kind of facility lies in the realm of
macro processors (or maybe some sort of combined super-editor APSE), and
more advanced make/build tools, and not Ada compilers as such. It was just a
thought. Perhaps it's the ancient concept of a 'straight text file' that
really needs to be rethought these days?

--
Best wishes,
Nick Roberts

Re: Literate Programming [was: A case where ...]

[Eric Merritt]

> The only slight variation I had in mind with my
> suggested syntax was: the
> switch is on a line on its own, and of a form
> unlikely to infere with the
> syntax of any programming language or text markup
> language; the syntax of
> the switch permits multiple named 'threads' of text,
> allowing perhaps
> maintenance documentation, the user guide, a
> tutorial, and other types of
> document to be generated from the one source file.

  I agree more or less, I have always liked the
concept of literate programming though I have never
felt comfortable enough with the tools to use it
outside of Sun's Javadoc.

> I suspect, on reflection, that this kind of facility
> lies in the realm of
> macro processors (or maybe some sort of combined
> super-editor APSE), and
> more advanced make/build tools, and not Ada
> compilers as such. It was just a
> thought. Perhaps it's the ancient concept of a
> 'straight text file' that
> really needs to be rethought these days?

I would agree, but the 'straight text file' has so
many pros and so few cons that I do not think it is
going to go away any time soon. 

Now comes the question, is literate programming really
required with Ada? It is already designed to be a very
readable language overall. In fact, in many cases I
tend to feel that only a little comment at a
subprogram header is enough, along with the code
itself, to provide adequate documentation. Now don't
get me wrong in Java or C++ I tend to provide comments
profusely, but that is indicative of syntax problems
in those other languages that Ada just does not seem
to have. 

Now of couse, some type of high level documentation is
always very nice, but I dont see how this could be
incorporated into the source of a language. Even if it
was many programmers eschew design work altogether so
many times this high level documentation does not and
will not exist no matter where it is located.

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

Re: Literate Programming [was: A case where ...]

[Stephen Leake]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes:

> What I think just be might be a worthwhile feature to add to a future
> revision would be some kind of line-oriented Ada 'on/off switch'.
> <snip>
> A file could then contain e.g.
> 
> === docbook
> 
> <para>The next function returns the opposite direction
> to the one given as its parameter.</para>
> 
> === ada
> 
>    function Opposite (Way: in Direction) return Direction;
> 
> === docbook
> 
> <para>The next function ...
> 
> This would mean that normal text files could be used to contain mixed
> content, including Ada source code, and yet any standard Ada compiler could
> directly compile such files. 

It is tempting to put documentation in the code files, and it works
well when the system has only a few code files. But when you have 100
files, most of them small child subprograms, where do you look for the
documentation that describes the whole system?

I prefer to keep documentation in a separate file, but in the same
directory as the code (or at least the same directory tree), and build
it from the same makefile (I use LaTeX for documents).

> This would be a huge advantage over having to pre-process ('tangle')
> the files before compiling them, which tends to render the automatic
> 'make' tools supplied with Ada systems useless.

Preprocessors do not render Ada make tools useless. The preprocessor
just requires it's own 'make' step, which is easy to handle with a
generic make (such as gnu make). The generic makefile does two things;
check that all the preprocessed files are up-to-date, and then invoke
the Ada make to check that the object files are up-to-date. I've used
this technique with GNAT and ObjectAda.

One thing preprocessors do screw up is the interface between an editor
and the compiled information, used for cross-referencing code. For
example, Emacs Ada mode + GNAT normally allows a single keystroke to
bring up the source code for any definition. However, if the GNAT
preprocessor is used, that keystroke brings up the preprocessor
_output_ file, but we want the preprocessor _input_ file. In this
particular case, the GNAT compiler and preprocessor already provide
the necessary information; the Emacs Ada mode does not properly use
it (one of these days I'll fix it :).

-- 
-- Stephe

Re: A case where Ada defaults to unsafe?

[Stuart Palin]

Robert A Duff wrote:
> 
> Stuart Palin <stuart.palin@baesystems.com> writes:
> > Some potential candidates are ruled out by the Allowable Replacement
> > Characters (LRM[83] 2.10 - what happened to that section in LRM[95]?).
> 
> It moved to J.2.

Ta!
 
> > Anyhow it is all water under the bridge, the die is cast - but it still
> > peeves me!
> 
> I don't take that attitude at all.  Ada isn't the be-all and end-all of
> programming languages, so it's reasonable to discuss alternatives.

Agree that Ada is not the be-all & end-all; and discussing alternatives
is reasonable.

But for those using Ada today the 'die is cast'; and just to be clear -
my peeve is not that the die is cast (that's life!) - it is that the
language team did loads of other things to stop 'silly' mistakes -
including terminating comments at the end of line - but chose a token
that might easily occur in a mis-typing and could be difficult to spot
in a code inspection (depending on font etc).

--
Stuart Palin

Re: A case where Ada defaults to unsafe?

[Preben Randhol]

On Mon, 14 Jan 2002 13:14:33 +0000, Stuart Palin wrote:

> But for those using Ada today the 'die is cast'; and just to be clear -
> my peeve is not that the die is cast (that's life!) - it is that the
> language team did loads of other things to stop 'silly' mistakes -
> including terminating comments at the end of line - but chose a token

I like that the comments are terminated at the end of the lines. It
makes things safer. You only need a good editor like vim or emacs and
you will not be troubled one bit by adding -- infront of each line. I
see that the C/C++/Java Pitfalls document at
http://libre.act-europe.fr/Software_Matters/ recommends that one do not
use the /* */ in C++.

> that might easily occur in a mis-typing and could be difficult to spot
> in a code inspection (depending on font etc).

Which is why I like the more verbose Ada syntax to all the special
characters one use in C/C++ and friends. In the same document as I
mentioned above there are some simple examples that compare the C++ and
Ada source code.

Preben
-- 
 ()   Join the worldwide campaign to protect fundamental human rights.
'||}
{||'                                           http://www.amnesty.org/

Re: A case where Ada defaults to unsafe?

[Simon Wright]

Stuart Palin <stuart.palin@baesystems.com> writes:

> But for those using Ada today the 'die is cast'; and just to be clear -
> my peeve is not that the die is cast (that's life!) - it is that the
> language team did loads of other things to stop 'silly' mistakes -
> including terminating comments at the end of line - but chose a token
> that might easily occur in a mis-typing and could be difficult to spot
> in a code inspection (depending on font etc).

Check out GNU Enscript, it's got nice Ada support and comments are
printed in oblique -- very easy to spot. And if you use emacs ada-mode
or ObjectAda (7.2 at least) comments are coloured.

Re: A case where Ada defaults to unsafe?

[David Starner]

On 16 Jan 2002 06:00:37 +0000, Simon Wright <simon@pushface.org> wrote:
> Check out GNU Enscript, it's got nice Ada support and comments are
> printed in oblique -- very easy to spot. And if you use emacs ada-mode
> or ObjectAda (7.2 at least) comments are coloured.

Likewise with Vim. I'm not sure why anyone would use a code editor that
doesn't at least color code the source.

-- 
David Starner - starner@okstate.edu, dvdeug/jabber.com (Jabber)
Pointless website: http://dvdeug.dhis.org
When the aliens come, when the deathrays hum, when the bombers bomb,
we'll still be freakin' friends. - "Freakin' Friends"

Re: A case where Ada defaults to unsafe?

[Georg Bauhaus]

David Starner <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote:
 
:  I'm not sure why anyone would use a code editor that
: doesn't at least color code the source.
 
Someone who will have to read source code where no
such editor/terminal is available, for esample when hot
fixing.
I find it highly instructive to look at sources in
different editors with different fonts on different
terminal types, with different option settings.
Keeping source code readable "outside" your aesthetical
preferences--that might be good for you and your productivity,
but not necessarily for others--should be in the spirit
of the much stressed Ada readability.

(E.g., many don't hesitate to write lines of a length 
hardly ever found in texts written or printed on paper,
probably encouraged by what current displays offer; the single
advantage I can see here is that long sequences of statments
in deeply nested if statements fit on one display page.)

-- Georg
---
Microsoft Windows--a fresh perspective on information hiding

Re: A case where Ada defaults to unsafe?

[Simon Wright]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> (E.g., many don't hesitate to write lines of a length 
> hardly ever found in texts written or printed on paper,
> probably encouraged by what current displays offer; the single
> advantage I can see here is that long sequences of statments
> in deeply nested if statements fit on one display page.)

Yeah, pet hate there. -gnaty warns if you go over 79 columns .. (and
lots of other stylistic checks too, well worth it).

Re: A case where Ada defaults to unsafe?

[Stuart Palin]

Simon Wright wrote:
> 
> Stuart Palin <stuart.palin@baesystems.com> writes:
> 
> > But for those using Ada today the 'die is cast'; and just to be clear -
> > my peeve is not that the die is cast (that's life!) - it is that the
> > language team did loads of other things to stop 'silly' mistakes -
> > including terminating comments at the end of line - but chose a token
> > that might easily occur in a mis-typing and could be difficult to spot
> > in a code inspection (depending on font etc).
> 
> Check out GNU Enscript, it's got nice Ada support and comments are
> printed in oblique -- very easy to spot. And if you use emacs ada-mode
> or ObjectAda (7.2 at least) comments are coloured.

The two edged sword of 'clever' text editors in safety-critical
situations ;-)

+ve - The context sensitive representation does make it easier to see
what is going on
-ve - Are you actually seeing what is in the file or what the editor is
choosing
      to show you?

The safety-case could probably be finessed by using different tools for
creating and reviewing the software (and making sure the tools have an
appropriate pedigree).

When we get development off the Vaxes onto these new-fangled PC's these
things may come to pass ;-).
--
Stuart Palin
Principal Software Engineer
BAE SYSTEMS Avionics Ltd, Rochester
G-NET 791 3364    mailto:stuart.palin@baesystems.com

Re: A case where Ada defaults to unsafe?

[Simon Wright]

Stuart Palin <stuart.palin@baesystems.com> writes:

> +ve - The context sensitive representation does make it easier to see
> what is going on
> -ve - Are you actually seeing what is in the file or what the editor is
> choosing
>       to show you?

Gordon Bennett

> The safety-case could probably be finessed by using different tools
> for creating and reviewing the software (and making sure the tools
> have an appropriate pedigree).

Well, emacs & enscript are both GNU but from completely different
authors. If you want a capable non-SOUP editor you are going to have
to look a long way, I think, and pay thorugh the nose. I've seen TPU
eat lines!

> When we get development off the Vaxes onto these new-fangled PC's
> these things may come to pass ;-).

I guess in about 8 years you may have to.

Re: A case where Ada defaults to unsafe?

[Preben Randhol]

On Fri, 11 Jan 2002 09:45:34 +0000, Stuart Palin wrote:
> Looking at my keyboard (and without studying whether it might have been
> available on some 1960's keyboard) ...
> 
> Something like '{' (I would also make a syntax error not to have the
> closing '}' at the end of the line).

And your keyboard is American/English? What about us that have special
letters at these positions?

Preben
-- 
 ()   Join the worldwide campaign to protect fundamental human rights.
'||}
{||'                                           http://www.amnesty.org/

Re: A case where Ada defaults to unsafe?

[Robert A Duff]

Preben Randhol <randhol+abuse@pvv.org> writes:

> > Something like '{' (I would also make a syntax error not to have the
> > closing '}' at the end of the line).
> 
> And your keyboard is American/English? What about us that have special
> letters at these positions?

The solution in Pascal is to allow "(*" and "*)" as replacements for
"{" and "}".

- Bob

Re: A case where Ada defaults to unsafe?

[Simon Wright]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes:

> In reality, one might well use ATC time-outs to protect vital code
> like this from being baulked. Furthermore, I suspect indicator code
> would in reality be very separate from emergency actions code
> (different tasks, or probably different devices).

I suspect that your ISA would choke on the idea of using ATC in
high-integrity software ..

Re: A case where Ada defaults to unsafe?

[Robert Dewar]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<3C35E733.6030603@mail.com>...
> Robert Dewar wrote:
> 
> > Well any vaguely competent Ada programmer should equally
> > well know that in Ada "and then" and "or else" short circuit
>  
>  > and "and" and "or" do not.
> 
> Sure. But what do you gain from the non-short-circuit ones,
> except for the risk that you've used them incorrectly?
> 
> 
> > Exactly the same as in C, where you use either & or &&.
> 
> 
> In C, you cannot use & and | in the same way that you use
> && and ||, because the former accept only integer operands.
> For example, if you have a pair of pointers, p and q, and
> wish to test whether both are not null, you must use p&&q.
> If you were to use p&q, the compiler would reject it.
> 
> C++ does have the horrible trap that user-defined && and ||
> operators don't short-circuit. Expert advice is to never
> define these except in the rarest of circumstances.

No, I am talking about the case of boolean operands. With
non-boolean operands you are in a completely different
domain. I personally find the usage p&&q here frightful,
and think it much better to introduce the explicit null
tests. But anyway I am only talking about the boolean case.

Why use AND instead of AND THEN, or OR instead of OR ELSE

The argument on this side goes like this. We only want to
use AND THEN if we specifically want to imply that there
is a serial dependence, which we think should be pointed
out. If there is no serial dependence, then some people
find it cleaner to use AND.

After all, if we write

      A = B and C > D

as opposed to

      A = B and then C > D

it is clear that these are semantically equivalent, so a
compiler can freely convert one into another, so there is
no efficiency issue in many cases.

Where there is an efficiency issue, it is often hard for
a programmer to tell what is more efficient.

Pascal has a more general rule. In Pascal,

   A and B

can be evaluated left to right, right to left, with or
without short circuiting, giving the compiler maximum
flexibility.

P.S. this is a peculiar thread, there is an extraordinary
number of very bizarre and misleading posts. I am only
responding to posts that are not in this category, but
beware :-)

Re: A case where Ada defaults to unsafe?

[Matthieu Moy]

Hyman Rosen <hyrosen@mail.com> writes:

> Frank J. Lhota wrote:
> 
> > The situation is quite similar in C/C++; if you use the siumpler & and |
> > operators, they do not short-circuit. In either C/C++ or Ada, experienced
> > programmers know what needs to be done in order to get short-circuiting.
> 
> 
> In C/C++ "everyone" knows that & and | are for bit twiddling and && and ||
> are for combining logical expressions.

But in Java, which is supposed to look like C++, | and & are what
Frank said they were. That may be the origin of the mistake.

-- 
| Matthieu MOY

Re: A case where Ada defaults to unsafe?

[Hyman Rosen]

Matthieu Moy wrote:

> But in Java, which is supposed to look like C++, | and & are what
> Frank said they were. That may be the origin of the mistake.


Huh? In Java, &, |, &&, and || work just like they do in C (except
that Java defines order of evaluation).

Re: A case where Ada defaults to unsafe?

[Jim Rogers]

Hyman Rosen wrote:

> Matthieu Moy wrote:
> 
>> But in Java, which is supposed to look like C++, | and & are what
>> Frank said they were. That may be the origin of the mistake.
> 
> 
> 
> Huh? In Java, &, |, &&, and || work just like they do in C (except
> that Java defines order of evaluation).
> 

Both of you are correct, sort of :-).  Java does use & and | for
bitwise evaluation. It also uses & and | for boolean evaluation.
This is a case where Java overloads the operator based on the
return type of the operator, something not allowed for people
writing their own Java methods.

Jim Rogers

Re: A case where Ada defaults to unsafe?

[Ray Blaak]

Jim Rogers <jimmaureenrogers@worldnet.att.net> writes:
> Both of you are correct, sort of :-).  Java does use & and | for
> bitwise evaluation. It also uses & and | for boolean evaluation.
> This is a case where Java overloads the operator based on the
> return type of the operator, something not allowed for people
> writing their own Java methods.

Actually, it still overloads based on the operands, just like usual Java
overloading. Consider:

 void foo(boolean b) {System.out.println("foo(" + b + ")");}
 void foo(int i) {System.out.println("foo(" + i + ")");}

and then:

        boolean a = true;
        boolean b = false;
        int x = 1;
        int y = 2;
        foo(a & b);
        foo(x & y);

the & chosen depends on the operands. The foo is then chosen in turn based on
its parameter types, just like normal Java evaluation. E.g. consider also:

   boolean bar(boolean b) {return b;}
   int bar(int i) {return i;}

and then:

        foo(bar(a));
        foo(bar(x));

Finally, consider this:

	int i_and = a & b;
	boolean b_and = x & y;

I get the following errors, which indicate that the & is chosen without
considering the required result type, for otherwise the errors would be about
the invalid operands:

Test.java:13: error:Variable "i_and" cannot be initialized by a value of type
 "boolean" [JLS 4.5.4]
Test.java:14: error:Variable "b_and" cannot be initialized by a value of type
 "int" [JLS 4.5.4]

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@telus.net                                The Rhythm has my soul.

Re: A case where Ada defaults to unsafe?

[Ted Dennison]

In article <3C34BF2C.6030500@mail.com>, Hyman Rosen says...
>So in Ada, one could say 'if a /= 0 and b/a > 3' and fall into a
>trap that would not happen in C/C++. Discuss?

..only if one incorrectly assumes they short-circuit. This is basicly
equivalent to saying Ada is bad because it doesn't behave exactly like C.

The reason things were done this way was so that the optimizer could rearrange
and short-circuit the expression itself (or not) depending on what is more
efficient on its architecture. See the Ada 83 Rationale 3.10 if you really want
a discussion ( online at
http://archive.adaic.com/standards/83rat/html/ratl-03-10.html#3.10 )

If you are going to complain about things that are unsafe in Ada but not in C,
you'd better get started on assuming an integer is passed by value too. And then
tasking introduces a world of possible errors that C doesn't have...

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: A case where Ada defaults to unsafe?

[Preben Randhol]

On Thu, 03 Jan 2002 22:07:52 GMT, Ted Dennison wrote:
> The reason things were done this way was so that the optimizer could rearrange
> and short-circuit the expression itself (or not) depending on what is more
> efficient on its architecture. See the Ada 83 Rationale 3.10 if you really want
> a discussion ( online at

Does this mean that one cannot know whether both sides will be evaluated
or not? How can the optimiser know whether to use short-circuit or not.
i mean what does it look for?

Preben
-- 
 ()   Join the worldwide campaign to protect fundamental human rights.
'||}
{||'                                           http://www.amnesty.org/

Re: A case where Ada defaults to unsafe?

[Jean-Marc Bourguet]

Preben Randhol <randhol+abuse@pvv.org> writes:

> On Thu, 03 Jan 2002 22:07:52 GMT, Ted Dennison wrote:
> > The reason things were done this way was so that the optimizer
> > could rearrange and short-circuit the expression itself (or not)
> > depending on what is more efficient on its architecture. See the
> > Ada 83 Rationale 3.10 if you really want a discussion ( online at
> 
> Does this mean that one cannot know whether both sides will be
> evaluated or not? How can the optimiser know whether to use
> short-circuit or not.  i mean what does it look for?

If the compiler can show that there is no side effect, it can short
circuit either part of a non short circuit operator.

In the context of "a, b : boolean;", "a and b" can be implemented like
"a and then b" or "b and then a".

Yours,

-- 
Jean-Marc

Re: A case where Ada defaults to unsafe?

[Ted Dennison]

In article <slrna3bok2.8t3.randhol+abuse@kiuk0156.chembio.ntnu.no>, Preben
Randhol says...
>Does this mean that one cannot know whether both sides will be evaluated
>or not? How can the optimiser know whether to use short-circuit or not.
>i mean what does it look for?

That's what it means. But this is the Ada *83* rationale. I don't know what the
rule in Ada 95 ended up being. 

I'm not too sure what an optimizer would look for, and it would likely be very
hardware dependant (which is why its better to leave these things to the
optimizer). It could be that for a CPU that doesn't do branch prediction, you'd
want to not short-circuit register-based booleans, as the integer unit's AND
logic will be way quicker than a series of conditional branches. However, on a
CPU that does do branch prediction that may not buy you anything. You might also
prefer to put boolean variable evaluations first, and have their result
short-circuit any boolean function calls that might be in the expression. A
really sexy optimizer might even try to transform boolean expressions using
DeMorgan's rule so that all the function calls can be put on the outside
together and short-circutited.

But again, you'd have to have a compiler vendor tell you if your compiler does
this. I understand Gnat does not, and I take it most others don't either.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: A case where Ada defaults to unsafe?

[Larry Kilgallen]

In article <3C34BF2C.6030500@mail.com>, Hyman Rosen <hyrosen@mail.com> writes:

> So in Ada, one could say 'if a /= 0 and b/a > 3' and fall into a
> trap that would not happen in C/C++.

Since you did not propose:

	if b/a > 3 and a /= 0

I gather you are talking about the case where the programmer really
intended that the a /= 0 test should happen first.  If the programmer
really wanted to specify the order, "and then" should be used.  If the
programmer insists on writing a program that differs from what they
mean, they might as well write:

	if a /= 0 OR b/a > 3

Even though I have used other programming languages in the past,
I have found the concept of "and then" quite easy to understand,
though I have the advantage that my natural language is English.

Re: A case where Ada defaults to unsafe?

[Thierry Lelegard]

Maybe the actual question should be "why are there two distinct formats,
with and without short-circuit?"

"and then" has an actual added value over "and" (the short-circuit).
On the other hand, what is the added value of "and"? What can be
achieved by "and" that could not be by "and then" (except side-effect,
which is a dirty practice)?

If have been using Ada for 16 years and I have never understood why there
are two formats. Let's assume that "and then" never existed and that "and"
was defined as short-circuit (same for "or" and "or else"). Wouldn't it
be better (safer) for everyone?

-Thierry
____________________________________________________________________________

Thierry Lelegard, "The Jazzing Troll", Email: thierry.lelegard@canal-plus.fr
CANAL+ Technologies, 34 place Raoul Dautry, 75906 Paris Cedex 15, France
Tel: +33 1 71 71 54 30   Fax: +33 1 71 71 52 08   Mobile: +33 6 03 00 65 75
____________________________________________________________________________

Re: A case where Ada defaults to unsafe?

[tmoran]

If you write programs as procedures to be followed, short circuit is
natural.  But if you write with a logic structure and assertions in mind,
then short circuit is un-natural.  I think the latter is a better way to
program, and short circuit should be reserved for the compiler to choose
as an implementation optimization, or as a shorthand notation for those
cases where you really do want an "if ...  then if" structure.

Re: A case where Ada defaults to unsafe?

[Thierry Lelegard]

tmoran@acm.org wrote :
> 
> If you write programs as procedures to be followed, short circuit is
> natural.  But if you write with a logic structure and assertions in mind,
> then short circuit is un-natural. 

I do not agree. You mix up the functional definition and the implementation.
Both "and" and "and then" are logic operators. The short-circuit is just an
implementation detail.

If you just need the logic operator (ie. you need the function and you
don't care about the implementation), "and then" is just as good as
"and". 

So, again, an "and" with the implementation of an "and then" (and no "and
then") would be sufficient.

-Thierry
____________________________________________________________________________

Thierry Lelegard, "The Jazzing Troll", Email: thierry.lelegard@canal-plus.fr
CANAL+ Technologies, 34 place Raoul Dautry, 75906 Paris Cedex 15, France
Tel: +33 1 71 71 54 30   Fax: +33 1 71 71 52 08   Mobile: +33 6 03 00 65 75
____________________________________________________________________________

Re: A case where Ada defaults to unsafe?

[Wes Groleau]

Thierry Lelegard wrote:
> 
> tmoran@acm.org wrote :
> >
> > If you write programs as procedures to be followed, short circuit is
> > natural.  But if you write with a logic structure and assertions in mind,
> > then short circuit is un-natural.
> 
> I do not agree. You mix up the functional definition and the implementation.
> Both "and" and "and then" are logic operators. The short-circuit is just an
> implementation detail.

Exactly.  It's an implementation detail, so it should not be
required where it isn't a logical requirement.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: A case where Ada defaults to unsafe?

[Ted Dennison]

In article <3C356FE8.5DEB48C8@canal-plus.fr>, Thierry Lelegard says...
>I do not agree. You mix up the functional definition and the implementation.
>Both "and" and "and then" are logic operators. The short-circuit is just an

No they are not. Try redefining "and then" some time (hint: you can't). It is
not a logic operator like "and" and "or". Its a shorthand for "then if ...".

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: A case where Ada defaults to unsafe?

[Wes Groleau]

> No they are not. Try redefining "and then" some time (hint: you can't). It is
> not a logic operator like "and" and "or". Its a shorthand for "then if ...".

Eight keystrokes is a shorthand for seven keystrokes.  :-)

(Actually, the latter also has an extra "end if;"--seven more)

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: A case where Ada defaults to unsafe?

[Ted Dennison]

In article <3C35DA2F.9890444F@spamcop.net>, Wes Groleau says...
>
>
>
>> No they are not. Try redefining "and then" some time (hint: you can't). It is
>> not a logic operator like "and" and "or". Its a shorthand for "then if ...".
>
>Eight keystrokes is a shorthand for seven keystrokes.  :-)
>
>(Actually, the latter also has an extra "end if;"--seven more)

..and the extra level of indention each time, which is the real killer (as per
the Rationale).

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: A case where Ada defaults to unsafe?

[Larry Kilgallen]

In article <3C35675D.276C2D81@canal-plus.fr>, Thierry Lelegard <thierry.lelegard@canal-plus.fr> writes:
> Maybe the actual question should be "why are there two distinct formats,
> with and without short-circuit?"
> 
> "and then" has an actual added value over "and" (the short-circuit).
> On the other hand, what is the added value of "and"? What can be
> achieved by "and" that could not be by "and then" (except side-effect,
> which is a dirty practice)?
> 
> If have been using Ada for 16 years and I have never understood why there
> are two formats. Let's assume that "and then" never existed and that "and"
> was defined as short-circuit (same for "or" and "or else"). Wouldn't it
> be better (safer) for everyone?

You say "better (safer)", but performance-sensitive applications
may need the speed provided by letting the compiler optimize away
one evaluation.  For simpler cases, the compiler can decide which
branch to evaluate first, based on likely performance characteristics.

For more complex cases, the programmer can specify an order with the
"and then" operator.

Re: A case where Ada defaults to unsafe?

[M. A. Alves]

On Fri, 4 Jan 2002, Thierry Lelegard wrote:
> . . .
>
> If have been using Ada for 16 years and I have never understood why there
> are two formats. Let's assume that "and then" never existed and that "and"
> was defined as short-circuit (same for "or" and "or else"). Wouldn't it
> be better (safer) for everyone?

I came to Ada 95 from C and this was one of the things of Ada that pleased
me a lot.

I find

  N /= 0 and then X / N

perfectly clear.

And there are in fact cases when you _cannot_ short-circuit viz. when you
need to evaluate both expressions e.g. because there produce required
effects.  In C you must either evaluate the expression previously into a
variable (then test the variable) or use the bitwise operator. Any option
is not without problems, and of inferior quality to the Ada idiom.

Just my 2 cents,

-- 
   ,
 M A R I O   data miner, LIACC, room 221   tel 351+226078830, ext 121
 A M A D O   Rua Campo Alegre, 823         fax 351+226003654
 A L V E S   P-4150-180 PORTO, Portugal    mob 351+939354002

Re: A case where Ada defaults to unsafe?

[Ted Dennison]

In article <3C35675D.276C2D81@canal-plus.fr>, Thierry Lelegard says...
>
>Maybe the actual question should be "why are there two distinct formats,
>with and without short-circuit?"
>
>"and then" has an actual added value over "and" (the short-circuit).
>On the other hand, what is the added value of "and"? What can be
>achieved by "and" that could not be by "and then" (except side-effect,
>which is a dirty practice)?

Again, I wish people would read the rationale before saying stuff like this. It
is exaplained there. 

One issue is that you may indeed want the side effects of both expressions
(dirty practice or no). Another is that the compiler is not free to reorder your
expressions for efficiency with the short-circuit forms, even if it turns out
that you really don't care what order they are performed in (which is usually
going to be the case). Another is that there are some circumstances where a
short-circuit is going to be *slower* than a non-short circuit calculation.
After all, a short-circuit implies an extra branch instruction, whereas normal
"and" is a simple integer-unit operation. Plus, if the typical eventuality is to
make it through to the last expression, then all those extra checks are a big
waste.

Now I know Robert Dewar is on record as saying that most of these issues either
don't apply on modern processors, or were never taken advantage of by any
compiler. But the above was the initial reasoning for not short-circuiting.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: A case where Ada defaults to unsafe?

[Hyman Rosen]

Ted Dennison wrote:

> In article <3C35675D.276C2D81@canal-plus.fr>, Thierry Lelegard says...
>>Maybe the actual question should be "why are there two distinct formats,
>>with and without short-circuit?"
> 
> Again, I wish people would read the rationale before saying stuff like this. It
> is exaplained there.


It is not. The rationale explains the need for short-circuit
forms. It does not explain the need for the commutative forms,
merely taking it as a given that those forms exist. (Section
3.10 of the Ada83 Rationale.)


> One issue is that you may indeed want the side effects of both expressions


Which will happen in an indeterminate order, so they had better
not affect each other. Shrug. It doesn't seem like much of a
reason to me.


> Another is that the compiler is not free to reorder your
> expressions for efficiency with the short-circuit forms


The compiler is always free to reorder expressions provided
the result is as if they were evaluated in the correct order.

> Another is that there are some circumstances where a
> short-circuit is going to be *slower* than a non-short

 > circuit calculation.

Then why wouldn't the compiler just use the more efficient way?

Re: A case where Ada defaults to unsafe?

[Ted Dennison]

In article <3C35E37D.30408@mail.com>, Hyman Rosen says...
>
>Ted Dennison wrote:
>> Another is that there are some circumstances where a
>> short-circuit is going to be *slower* than a non-short
>> circuit calculation.
>
>Then why wouldn't the compiler just use the more efficient way?

That's the whole point. The way it is currently defined, it can. If we were to
define the operators as short-circuiting, it could not. 

For example, suppose I write:

X : Pointer_To_Some_Structure;

Re: A case where Ada defaults to unsafe?

[Matthew Woodcraft]

Thierry Lelegard <thierry.lelegard@canal-plus.fr> writes:
> Maybe the actual question should be "why are there two distinct
> formats, with and without short-circuit?"

> "and then" has an actual added value over "and" (the short-circuit).
> On the other hand, what is the added value of "and"? What can be
> achieved by "and" that could not be by "and then" (except side-effect,
> which is a dirty practice)?

One example of a side effect is raising an exception, which can make
code safer.

Suppose my condition is 'a = 3 and b/c = 2'. In some circumstances I
would prefer to get the exception now if c is 0.

-M-

Re: A case where Ada defaults to unsafe?

[Steve Doiel]

My 2 cents.

I disagree with your initial statement.  In my view Ada has no "default"
behaviour.
You have been describing 4 distinct operations:
  "and"
  "or"
  "and then"
  "or else"

Each of these operators perform distinct and well defined functions.

The American Heritage dictory describes the word "and" as:
  Together with or along with; also; in addition; as well as.

I belive the definition of the "and" operator fits this description more
closely than
"and then".

When I learned simple boolean logic I was taught that "a and b" is true if
and only if both
"a" and "b" are both true.  Sure you can get smart and figure out how to
short circuit things
but the most obious behavior does not.

In my opinion the behavior of "and" and "or" are what you would expect,
unless you're
coming from the 'C' world, where you've been forced to pound a plethora of
implicit rules
into your head.  By the way I think that's one of the main reasons Ada is
safer, rules in Ada
are (usually) explicit rather than implicit (although I still gripe about
the scope of a tagged
type being implicit).

SteveD


"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3C34BF2C.6030500@mail.com...
> The conventional belief (at least on CLA :-) is that one of the
> main distinctions between Ada and C/C++ is that Ada defaults to
> safe behavior and C/C++ defaults to unsafe behavior (eg., array
> indexing, automatic type conversions, and overflow checking).
>
> It occurs to me that there is a case where the opposite seems to
> be true. In C/C++, the && and || binary operators short-circuit,
> evaluating their right operand only if necessary. In Ada, it is
> necessary to specify "and then" and "or else" for this behavior,
> otherwise the order of evaluation of the two sides is unspecified
> if the simple "and" and "or" forms are used.
>
> So in Ada, one could say 'if a /= 0 and b/a > 3' and fall into a
> trap that would not happen in C/C++. Discuss?
>

Re: A case where Ada defaults to unsafe?

[Robert A Duff]

"Steve Doiel" <nospam_steved94@attbi.com> writes:

> The American Heritage dictory describes the word "and" as:
>   Together with or along with; also; in addition; as well as.

How does that dictionary define the word "xor"?  ;-)

- Bob