and then... (a curiosity)

and then... (a curiosity)

[mockturtle]

Dear.all,
today while I was writing in my favorite language
(PERL with C extensions, of course :-)))) I wondered why in Ada the
"shortcut and"  is "and then", while the simple "and" has not
a shortcut  behaviour.  My curiosity stems from the fact that
I am not able to envision any situation where the "non shortcut"
version would preferable, but I immagine that there was some
reason for this choice.  Do anyone have any hint?

Thank you in advance.

Re: and then... (a curiosity)

[Samuel Tardieu]

> I wondered why in Ada the "shortcut and" is "and then", while the
> simple "and" has not a shortcut behaviour.  My curiosity stems from
> the fact that I am not able to envision any situation where the "non
> shortcut" version would preferable, but I immagine that there was
> some reason for this choice.  Do anyone have any hint?

Sometimes, you want to ensure that both sides of the boolean operator
have been evaluated. Here is an example:

  --  Send the message to the log and return True if it
  --  has been logged at least at one place succesfully.

  function Log (Message : String) return Boolean is
  begin
     return Log_To_Network (Message) or Log_To_Disk (Message);
  end Log;

 Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/

Re: and then... (a curiosity)

[Adam Beneschan]

On Aug 29, 2:06 pm, mockturtle <framefri...@gmail.com> wrote:
> Dear.all,
> today while I was writing in my favorite language
> (PERL with C extensions, of course :-)))) I wondered why in Ada the
> "shortcut and"  is "and then", while the simple "and" has not
> a shortcut  behaviour.  My curiosity stems from the fact that
> I am not able to envision any situation where the "non shortcut"
> version would preferable, but I immagine that there was some
> reason for this choice.  Do anyone have any hint?

Aside from Samuel's comment (sometimes you want both sides evaluated),
there are some very important differences.  "and" is a predefined
function and can be used wherever a function can (you can rename it,
pass it as parameter for a generic formal function, etc.).  Besides
the "and" on Booleans, there are predefined "and" functions on arrays
of Booleans and on modular types [both of those do bitwise AND's].
You can define your own "and" on other types if you like.  Like every
other function, the use of "and" requires that all (both) of its
arguments be evaluated.  The language also defines "or", "xor", and
"not" with similar properties.

"and then" is not a function, however, and has none of these
properties.

To make "and" [and "or"] on two Booleans behave like the short-circuit
form would introduce a major inconsistency into the language.

                                -- Adam

Re: and then... (a curiosity)

[Jeffrey R. Carter]

Adam Beneschan wrote:
> 
> "and then" is not a function, however, and has none of these
> properties.
> 
> To make "and" [and "or"] on two Booleans behave like the short-circuit
> form would introduce a major inconsistency into the language.

In addition to the other reasons, there's the question of processor 
optimization. Although we have a sequential view of how code is executed, modern 
processors do all sorts of strange optimizations, such as speculative execution, 
that violate that sequential view. It's my understanding that the short-circuit 
forms can prevent such optimizations. Apparently, code that may evaluate only 
one of the 2 expressions can actually be slower than code that must evaluate both.

-- 
Jeff Carter
"If I could find a sheriff who so offends the citizens of Rock
Ridge that his very appearance would drive them out of town ...
but where would I find such a man? Why am I asking you?"
Blazing Saddles
37

Re: and then... (a curiosity)

[Dmitry A. Kazakov]

On Fri, 29 Aug 2008 15:28:16 -0700 (PDT), Adam Beneschan wrote:

> "and then" is not a function, however, and has none of these
> properties.

It could be made a function if Ada had lazy arguments.

I am unsure if the arguments of "and" are eager. You are a language lawyer,
I am not. But I used to think that the eagerness of evaluation is rather
unspecified, so that the compiler is free "not to care," when it optimizes
the code, as Jeff Carter has pointed out.

So basically, provided the above is correct, the choice was motivated by
least strong precondition (=unspecified eagerness), rather than by choosing
between eager and lazy evaluation.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: and then... (a curiosity)

[Peter C. Chapin]

Dmitry A. Kazakov wrote:

> I am unsure if the arguments of "and" are eager. You are a language lawyer,
> I am not. But I used to think that the eagerness of evaluation is rather
> unspecified, so that the compiler is free "not to care," when it optimizes
> the code, as Jeff Carter has pointed out.

I thought all function arguments must be evaluated, but that it is
unspecified in which order this evaluation is done.

Peter

Re: and then... (a curiosity)

[Maciej Sobczak]

On 29 Sie, 23:47, Samuel Tardieu <s...@rfc1149.net> wrote:

> Sometimes, you want to ensure that both sides of the boolean operator
> have been evaluated. Here is an example:
>
>   --  Send the message to the log and return True if it
>   --  has been logged at least at one place succesfully.
>
>   function Log (Message : String) return Boolean is
>   begin
>      return Log_To_Network (Message) or Log_To_Disk (Message);
>   end Log;

This is actually a bad example. It might use "or else" and still
retain the semantics as described in the comment above.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: and then... (a curiosity)

[Georg Bauhaus]

Maciej Sobczak wrote:
> On 29 Sie, 23:47, Samuel Tardieu <s...@rfc1149.net> wrote:
> 
>> Sometimes, you want to ensure that both sides of the boolean operator
>> have been evaluated. Here is an example:
>>
>>   --  Send the message to the log and return True if it
>>   --  has been logged at least at one place succesfully.
>>
>>   function Log (Message : String) return Boolean is
>>   begin
>>      return Log_To_Network (Message) or Log_To_Disk (Message);
>>   end Log;
> 
> This is actually a bad example. It might use "or else" and still
> retain the semantics as described in the comment above.

"At least one" of the logs should, I guess, mean to try both.
I.e., the Log subprogram is not about its return value alone.
"Or" achieves all of that (the semantics).

"Or else" might also establish a strict preference for the
network log. "Or" should not.

Re: and then... (a curiosity)

[Ray Blaak]

Georg Bauhaus <rm.tsoh.plus-bug.bauhaus@maps.futureapps.de> writes:
> Maciej Sobczak wrote:
> > On 29 Sie, 23:47, Samuel Tardieu <s...@rfc1149.net> wrote:
> > 
> >> Sometimes, you want to ensure that both sides of the boolean operator
> >> have been evaluated. Here is an example:
> >>
> >>   --  Send the message to the log and return True if it
> >>   --  has been logged at least at one place succesfully.
> >>
> >>   function Log (Message : String) return Boolean is
> >>   begin
> >>      return Log_To_Network (Message) or Log_To_Disk (Message);
> >>   end Log;
> > 
> > This is actually a bad example. It might use "or else" and still
> > retain the semantics as described in the comment above.
> 
> "At least one" of the logs should, I guess, mean to try both.
> I.e., the Log subprogram is not about its return value alone.
> "Or" achieves all of that (the semantics).
> 
> "Or else" might also establish a strict preference for the
> network log. "Or" should not.

This kind of confusion makes me prefer an unambiguous if-then-else statement.

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

Re: and then... (a curiosity)

[Martin Krischik]

Maciej Sobczak schrieb:
> On 29 Sie, 23:47, Samuel Tardieu <s...@rfc1149.net> wrote:
> 
>> Sometimes, you want to ensure that both sides of the boolean operator
>> have been evaluated. Here is an example:
>>
>>   --  Send the message to the log and return True if it
>>   --  has been logged at least at one place succesfully.
>>
>>   function Log (Message : String) return Boolean is
>>   begin
>>      return Log_To_Network (Message) or Log_To_Disk (Message);
>>   end Log;
> 
> This is actually a bad example. It might use "or else" and still
> retain the semantics as described in the comment above.

Actually it is good example - for both:

1) Log to both Disk and Network and return true if at least one was
successful:

Log_To_Network (Message) or Log_To_Disk (Message)

2) Log to Network and if that fails log to Disk and return true if at
least one was successful:

Log_To_Network (Message) or else Log_To_Disk (Message)

And it shows nicely the why there are two: The programmer can decide
which behaviour he / she wants.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: and then... (a curiosity)

[Ray Blaak]

Martin Krischik <krischik@users.sourceforge.net> writes:
> Actually it is good example - for both:
> 
> 1) Log to both Disk and Network and return true if at least one was
> successful:
> 
> Log_To_Network (Message) or Log_To_Disk (Message)
> 
> 2) Log to Network and if that fails log to Disk and return true if at
> least one was successful:
> 
> Log_To_Network (Message) or else Log_To_Disk (Message)
> 
> And it shows nicely the why there are two: The programmer can decide
> which behaviour he / she wants.

My problem is not with the theoretical elegance as such, but rather that "or"
vs "or else" is not immediately clear to me.

As a multi-language programmer, I am really really used to thinking of boolean
or as "if one is true we don't care about the other". This instinct is
reenforced both from the current popular languages as well as from formal
proof styles in programming methodology.

So, I don't like relying the execution of both disjuncts. Sure, I could use
"or else" consistently, but I like thinking of boolean or as good old regular
boolean or.

So, my preference for the first log example (do both, return success of at
least one is:

  declare
    Network_Logged : Boolean := Log_To_Network(Message);
    Disked_Logged : Boolean := Log_To_Disk(Message); 
  begin
    return Network_Logged or Disked_Logged;
  end;

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

Re: and then... (a curiosity)

[Steve]

"mockturtle" <framefritti@gmail.com> wrote in message 
news:18b41828-bda4-4484-8884-ad62ce1c831d@f36g2000hsa.googlegroups.com...
> Dear.all,
> today while I was writing in my favorite language
> (PERL with C extensions, of course :-)))) I wondered why in Ada the
> "shortcut and"  is "and then", while the simple "and" has not
> a shortcut  behaviour.  My curiosity stems from the fact that
> I am not able to envision any situation where the "non shortcut"
> version would preferable, but I immagine that there was some
> reason for this choice.  Do anyone have any hint?
>
> Thank you in advance.

There are cases where both arguments to an "and" operator should always be 
used.  For example if you have Function A and Functon B involved in a 
condition:

  if A(x) and B(y) then
    ... do something
  end if;

If short circuit evalution is permitted then more complex logic is required 
to assure that both arguments are evaluated:

  resultA := A(x);
  resultB := B(z);
  if resultA and resultB then
    ... do something
  end if;

With Ada you can choose whether or not you want short circuit evaluation. 
If you require short circuit evaluation you must convey that information to 
the compiler.  If you do not require short circuit evaluation you can convey 
that information as well.  The more the compiler knows about your 
requirements, the greater the potential for optimization.

The form used also conveys information about the code to programmers reading 
the code.

Regards,
Steve 

Re: and then... (a curiosity)

[Martin Krischik]

Ray Blaak schrieb:
> Martin Krischik <krischik@users.sourceforge.net> writes:
>> Actually it is good example - for both:
>>
>> 1) Log to both Disk and Network and return true if at least one was
>> successful:
>>
>> Log_To_Network (Message) or Log_To_Disk (Message)
>>
>> 2) Log to Network and if that fails log to Disk and return true if at
>> least one was successful:
>>
>> Log_To_Network (Message) or else Log_To_Disk (Message)
>>
>> And it shows nicely the why there are two: The programmer can decide
>> which behaviour he / she wants.
> 
> My problem is not with the theoretical elegance as such, but rather that "or"
> vs "or else" is not immediately clear to me.



> As a multi-language programmer, I am really really used to thinking of boolean
> or as "if one is true we don't care about the other".

Funny I am not - probably because my first languages where Basic and
Pascal - and Basic and Pascal do not guarantee short cut boolean. Modern
Basic and Pascal dialects might have it but it is not guaranteed in the
language itself.

> This instinct is
> reenforced both from the current popular languages as well as from formal
> proof styles in programming methodology.

When I was at Polytechnic first language was PL/1, second Pascal and
therefore methodology was different. i.E. Don't rely on the execution
order of boolean expressing.

> So, I don't like relying the execution of both disjuncts. Sure, I could use
> "or else" consistently, but I like thinking of boolean or as good old regular
> boolean or.

They are not necessarily both executed with plain old OR and AND either.
Plain old OR and AND leaves all options open to the optimizer: Out of
order execution Common subexpression elimination or dead code elimination.

If the optimizer determines that the 2nd expression has no side effects
it might optimize it away. But note that raising CONSTRAINT_ERROR is a
side effect. So:

if X /= null and x.all = 5 then
  Do_Something;
end if;

will most likely become:

if x = null then
  raise CONSTRAINT_ERROR;
elif x.all = 5 then
  Do_Something;
end if;

Or - for a CPU with hardware null pointer detection - it might become:

if x.all = 5 then
  Do_Something;
end if;

Ada is a language which highly rely on the existence of an optimizer.
Unlike the C style languages - the very first C did not have an
optimizer and it still show in the syntax and semantic.- One should
always remember C's main design goal: compiler must fit's into 8 kb of
memory. It explains a lot.

Anyway by default Ada leaves all option options open to the optimizer.
For example:

type Byte is range -128 .. 127;

might not actually be a byte - especially when optimized for
performance. By default all options are open to the optimizer to make
the best of you wish. Only when you start restricting the optimizer with

for Byte'Size use 8;

you are guaranteed an 8 bit type.

You consider this when thinking of "or else" and "and then" - both
restrict the optimizer in it's doing and the result might not be faster.

Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: and then... (a curiosity)

[stefan-lucks]

On Mon, 1 Sep 2008, Steve wrote:
> If short circuit evalution is permitted then more complex logic is required 
> to assure that both arguments are evaluated:
> 
>   resultA := A(x);
>   resultB := B(z);
>   if resultA and resultB then
>     ... do something
>   end if;

If I actually require to run both functions A and B, I always write 
something like the above (typically inside a declare ... begin ... end), 
because I think that makes my intention clearer than by just writing 
"and" (or "or"). 

> With Ada you can choose whether or not you want short circuit evaluation. 
> If you require short circuit evaluation you must convey that information to 
> the compiler.  If you do not require short circuit evaluation you can convey 
> that information as well.  The more the compiler knows about your 
> requirements, the greater the potential for optimization.

True. But the case that you want both expressions to be evaluated is a 
rare exception. On a *logic* level, "A and B" implies "if A is false, the 
result is false, regardless of B". So short-circuit evaluation is a 
natural and good thing for a programming language, and it is regrettable 
that Ada needs a more complex syntax for this. (Well, "A and B" also 
implies "if B is false, don't care about A", but in a programming language 
you can't have it both ways.)

But, as others pointed it: IF the default "and" supported 
short-circuit-evaluation, THEN this "and" could not be an ordinary Ada 
operator. At the language semantic level, it is much more reasonable to 
treat "and" like any other operator or function, such as "+" and "-". So 
the inventors of Ada decided on a special syntax for short-circuit 
evaluation. But I wish Ada would support some sort of lazy evaluation for 
subprogram arguments. 

So long

Stefan

-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: and then... (a curiosity)

[Martin Krischik]

stefan-lucks@see-the.signature schrieb:

> True. But the case that you want both expressions to be evaluated is a 
> rare exception. On a *logic* level, "A and B" implies "if A is false, the 
> result is false, regardless of B". So short-circuit evaluation is a 
> natural and good thing for a programming language, and it is regrettable 
> that Ada needs a more complex syntax for this.

That's not what I learned in my boolean arithmetic classes.

> (Well, "A and B" also 
> implies "if B is false, don't care about A", but in a programming language 
> you can't have it both ways.)

That is what I learned in my boolean arithmetic classes. It's either
way. There is no preference that the left parameter if more important
then the right. A Human seeing "A∧0" won't evaluate A. And if you see
"f(x)∧g" you would probably evaluate g first as a variable is usually
easier to evaluate then a function.

And it is what you have in Ada - with plain old "and" and "or" the
optimizer is free to do out of order evaluation and dead code
elimination which could well lead to B being evaluated first and A being
optimized away if B already determines the final result.

This - of course - only if the compiler can also determine that A and B
have no side effect. Side effect are that little difference between
arithmetic and programming. The CONSTRAINT_ERROR in:

if X /= null and x.all = 5 then
  Do_Something;
end if;

or the global variable which f(x) might change:

function f(x:Integer) is
begin
   if x > 10 then
     g = false;
   end if;
   return x > 5;
end f;

It's all about those side effect which make order of evaluation so
important. Otherwise it should not matter.

Note that once you add:

pragma Inline (f);

to the example above things become very interesting for the optimizer
;-) (do remember that the optimizer will use goto without shame).

> But, as others pointed it: IF the default "and" supported 
> short-circuit-evaluation, THEN this "and" could not be an ordinary Ada 
> operator. At the language semantic level, it is much more reasonable to 
> treat "and" like any other operator or function, such as "+" and "-".

Well again, in my arithmetic classes I learned that a+b is the same and
b+a - which includes that the order of evaluation is of no importance.
If you want that ∧ operates the same way as + then "a∧b" must be the
same as "b∧a".

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: and then... (a curiosity)

[Ludovic Brenta]

stefan-lu...@see-the.signature wrote:
> True. But, at the logic level, the Ada-statement
>
>   if (X >= A'First) and (X <= A'Last) and (A[X]=Y) then
>     ...
>   else
>     ...
>   end if;
>
> should *not* raise a Constraint_Error if X < A'First or X > A'Last, but
> instead handle the "else" case.

Except that X may be a function returning a different value for each
call!

> True enough, at the logic level the same should hold for
>
>   if (A(x)=Y) and (X >= A'First) and (X <= A'Last) then ... end if;
>
> > It's all about those side effect which make order of evaluation so
> > important. Otherwise it should not matter.
>
> The bad thing is that Constraint_Error counts as a valid side effect here.

And what would be an "invalid" side effect?

> Ideally, the program should check the other branches of the "and"
> expression, and only propagate the exception if none of them evaluates to
> false without raising an exception of its own.

No, because the Constraint_Error (or other exception, or other side
effect such as logging, assignment to a variable, etc.) may be
intentional! The compiler does not and should not try to read your
mind. At least I would find it very disturbing to program in a
language that would try to "do what I mean, not what I say".

> Consider a programm fragment like
>
>   if X and Y then
>     ...
>   end if
>
> Assume Y raises a Constraint_Error if X is false. This appears to be a
> common bug pattern in Ada. I have seen this several times in Ada
> sourcecode, and *never* it was the programmer's intention to raise an
> exception if X is false ... except when an exception was raised
> explicitely in the else branch. Even then, the programmers typically
> expected the exception they raised there, not Constraint_Error.

I have seen this bug a couple of times and always concluded it was
*my* fault and that I should have used "and then" to specify that the
order of evaluation was important. In such situation the mathematical
"and" (where "X and Y" is strictly equivalent to "Y and X") is not
what I want.

I definitely like the fact that Ada gives me the choice (short-circuit
or full evaluation) and the means ("and" vs. "and then") to express my
intent exactly.

--
Ludovic Brenta.

Re: and then... (a curiosity)

[stefan-lucks]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2685 bytes --]

> > (Well, "A and B" also 
> > implies "if B is false, don't care about A", but in a programming language 
> > you can't have it both ways.)
> 
> That is what I learned in my boolean arithmetic classes. It's either
> way. There is no preference that the left parameter if more important
> then the right. A Human seeing "A∧0" won't evaluate A. And if you see
> "f(x)∧g" you would probably evaluate g first as a variable is usually
> easier to evaluate then a function.

True. But, at the logic level, the Ada-statement

  if (X >= A'First) and (X <= A'Last) and (A[X]=Y) then 
    ...
  else
    ...
  end if;

should *not* raise a Constraint_Error if X < A'First or X > A'Last, but 
instead handle the "else" case. 

True enough, at the logic level the same should hold for 

  if (A(x)=Y) and (X >= A'First) and (X <= A'Last) then ... end if;

> It's all about those side effect which make order of evaluation so
> important. Otherwise it should not matter.

The bad thing is that Constraint_Error counts as a valid side effect here.
 
Ideally, the program should check the other branches of the "and" 
expression, and only propagate the exception if none of them evaluates to 
false without raising an exception of its own. 

Consider a programm fragment like

  if X and Y then
    ...
  end if

Assume Y raises a Constraint_Error if X is false. This appears to be a 
common bug pattern in Ada. I have seen this several times in Ada 
sourcecode, and *never* it was the programmer's intention to raise an 
exception if X is false ... except when an exception was raised 
explicitely in the else branch. Even then, the programmers typically 
expected the exception they raised there, not Constraint_Error. 

I admit, we will not get this "ideal" behavoiur in any usable programming 
language. What happens, e.g., if two different exceptions are raised when 
evaluating "A and B"? Which exception should be propagated?

In the absence of this "ideal" behaviour, a short-circuit behaviour of 
"and" and "or" would eliminate a common bug pattern in Ada. I would 
consider it the lesser evil, compared to the current situation.

> Note that once you add:
> 
> pragma Inline (f);
> 
> to the example above things become very interesting for the optimizer
> ;-) (do remember that the optimizer will use goto without shame).

Funny idea! ;-) 

But at the end, there are lots of gotos ("jumps", "branches") in assembler 
code, with or without pragma inline or optimisation.


-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: and then... (a curiosity)

[Ludovic Brenta]

> But do you really dispute that following the mathematical conventions
> as much as possible would improve readability?

Of course not. That's wgy "and" should have its mathematical meaning -
i.e it should not impose an order of evaluation and it should not
avoid evaluating its operands. That's what "and then" is for.

> A short-circuit "and" (instead of "and then") would not remove that choice
> -- see the "much better style" above.

But it would break the mathematical purity of "and".

--
Ludovic Brenta.

Re: and then... (a curiosity)

[stefan-lucks]

On Tue, 2 Sep 2008, Ludovic Brenta wrote:

> stefan-lu...@see-the.signature wrote:
> >   if (X >= A'First) and (X <= A'Last) and (A[X]=Y) then
> >     ...
> >   else
> >     ...
> >   end if;
> >
> > should *not* raise a Constraint_Error if X < A'First or X > A'Last, but
> > instead handle the "else" case.
> 
> Except that X may be a function returning a different value for each
> call!

On the level of formal logic, there isn't really space for side effects. 

> > The bad thing is that Constraint_Error counts as a valid side effect here.
> 
> And what would be an "invalid" side effect?

A "valid" side effect would, e.g., be changing a global variable. On the 
other hand, a function which raises an exception is essentially a function 
returning some value outside its domain (but inside an extended domain). 
This isn't quite like a side-effect -- only Ada pretends it is. 

> > Ideally, the program should check the other branches of the "and"
> > expression, and only propagate the exception if none of them evaluates to
> > false without raising an exception of its own.
> 
> No, because the Constraint_Error (or other exception, or other side
> effect such as logging, assignment to a variable, etc.) may be
> intentional! The compiler does not and should not try to read your
> mind. At least I would find it very disturbing to program in a
> language that would try to "do what I mean, not what I say".

Well, if the program requirements are that the side effects for A and B 
actually occur, I consider it poor programming style if people just write

  if A(X) and B(Y) then ... end if;

IMHO, much better style is the following:

  declare
    Tmp_A: Boolean := A(X);
    Tmp_B: Boolean := B(X);
  begin
    if Tmp_A and Tmp_B then ... end if;
  end;

This makes the programmers intention clear, "if A(X) and B(X)" doesn't. 

> > Consider a programm fragment like
> >
> >   if X and Y then
> >     ...
> >   end if
> >
> > Assume Y raises a Constraint_Error if X is false. This appears to be a
> > common bug pattern in Ada. 
[...]
> I have seen this bug a couple of times and always concluded it was
> *my* fault and that I should have used "and then" to specify that the
> order of evaluation was important. In such situation the mathematical
> "and" (where "X and Y" is strictly equivalent to "Y and X") is not
> what I want.

Right! 

But do you really dispute that following the mathematical conventions 
as much as possible would improve readability? 

> I definitely like the fact that Ada gives me the choice (short-circuit
> or full evaluation) and the means ("and" vs. "and then") to express my
> intent exactly.

A short-circuit "and" (instead of "and then") would not remove that choice 
-- see the "much better style" above. 

In any case, instead of an explicit syntax for short-circuit "and" an 
explict syntax for the rare non-short-circuit cases would be preferable, 
perhaps "if A(X) and all B(Y) then ... end if;".




-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: and then... (a curiosity)

[stefan-lucks]

> > And what would be an "invalid" side effect?
> 
> A "valid" side effect would, e.g., be changing a global variable. On the 
> other hand, a function which raises an exception is essentially a function 
> returning some value outside its domain (but inside an extended domain). 
> This isn't quite like a side-effect -- only Ada pretends it is. 

To be clear, if "function F(...) return Boolean" may raise an exception, 
such as Constrained_Error, we essentially have a three-valued logic -- the 
function can return

  - either "true2,
  - or "false2,
  - or raise an exception, which is tantamount to returning
    "undefined".



-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: and then... (a curiosity)

[stefan-lucks]

>   if A(X) and B(Y) then ... end if;
> 
> IMHO, much better style is the following:
> 
>   declare
>     Tmp_A: Boolean := A(X);
>     Tmp_B: Boolean := B(X);

      Tmp_B: Boolean := B(Y) -- sorry for the typo!

>   begin
>     if Tmp_A and Tmp_B then ... end if;
>   end;

-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: and then... (a curiosity)

[Adam Beneschan]

On Aug 30, 2:28 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On 29 Sie, 23:47, Samuel Tardieu <s...@rfc1149.net> wrote:
>
> > Sometimes, you want to ensure that both sides of the boolean operator
> > have been evaluated. Here is an example:
>
> >   --  Send the message to the log and return True if it
> >   --  has been logged at least at one place succesfully.
>
> >   function Log (Message : String) return Boolean is
> >   begin
> >      return Log_To_Network (Message) or Log_To_Disk (Message);
> >   end Log;
>
> This is actually a bad example. It might use "or else" and still
> retain the semantics as described in the comment above.

I don't think the example is bad at all, but the comment might be
ambiguous.  I understood Samuel's point to be that the function logs
to the network if possible, and it logs to disk if possible---ideally
it should log to both places, but we're hoping it logs to at least
one.  If you use "or else" it will never log to both.  That apparently
isn't what is desired.

                                -- Adam

Re: and then... (a curiosity)

[Adam Beneschan]

On Sep 1, 11:53 pm, Martin Krischik <krisc...@users.sourceforge.net>
wrote:

> > My problem is not with the theoretical elegance as such, but rather that "or"
> > vs "or else" is not immediately clear to me.
> > As a multi-language programmer, I am really really used to thinking of boolean
> > or as "if one is true we don't care about the other".
>
> Funny I am not - probably because my first languages where Basic and
> Pascal - and Basic and Pascal do not guarantee short cut boolean. Modern
> Basic and Pascal dialects might have it but it is not guaranteed in the
> language itself.

Yeah, and I don't think COBOL or Fortran guarantee "or else" semantics
either.  I was happy when I first started working in Ada because it
had this.  C has this feature, although like everything else in the
language it was represented in proto-Egyptian hieroglyphics rather
than in English, but this was a new and exciting feature to me.  I
guess Ray must be a young'un who only learned all them durn newfangled
languages and never had to struggle with REEL languages like us
dinosaur REEL programmers did back when we had to put all our programs
on punch cards and then lug them five miles through the snow to the
computer operator, uphill both ways.....

                                   -- Adam

Re: and then... (a curiosity)

[Adam Beneschan]

On Aug 30, 8:35 am, "Peter C. Chapin" <pcc482...@gmail.com> wrote:
> Dmitry A. Kazakov wrote:
> > I am unsure if the arguments of "and" are eager. You are a language lawyer,
> > I am not. But I used to think that the eagerness of evaluation is rather
> > unspecified, so that the compiler is free "not to care," when it optimizes
> > the code, as Jeff Carter has pointed out.
>
> I thought all function arguments must be evaluated, but that it is
> unspecified in which order this evaluation is done.

Correct.  If an argument to a subprogram contains another function
call that has side-effects, that argument must be evaluated, and the
compiler is generating incorrect code if it doesn't (which is *not*
the case with "or else").  I think that if the compiler can determine
that the only possible side effect would be to raise a predefined
exception, the compiler doesn't have to actually do any evaluation---
the code isn't required to perform computations just for the sake of
doing the computations.  I'm not sure how far the predefined-exception
thing goes, though.  If you say

   if X = null or X.ID < 0 then ...    -- "or", not "or else"!

even though the right side is supposed to be evaluated, I suppose that
a compiler could in theory generate code that doesn't bother to
evaluate it if X is null, because there would be no point to reading
that field (assuming no memory-mapped I/O is involved here!!).  I
think that behavior is allowed by the Implementation Permissions in
11.6, but of course it would be quite foolish to write code like this
and rely on the optimization.

                               -- Adam

Re: and then... (a curiosity)

[Ray Blaak]

Martin Krischik <krischik@users.sourceforge.net> writes:
> When I was at Polytechnic first language was PL/1, second Pascal and
> therefore methodology was different. i.E. Don't rely on the execution
> order of boolean expressing.

This I also agree with, although I admit being used to the short circuit &&
forms in the C-like languages.

But my point is about having the source code be clearer when both operands are
required to be evaluated, especially when this is a possibility:

> They are not necessarily both executed with plain old OR and AND either.
> Plain old OR and AND leaves all options open to the optimizer: Out of
> order execution Common subexpression elimination or dead code elimination.


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

Re: and then... (a curiosity)

[Ray Blaak]

Adam Beneschan <adam@irvine.com> writes:
> I guess Ray must be a young'un who only learned all them durn newfangled
> languages and never had to struggle with REEL languages like us dinosaur
> REEL programmers did back when we had to put all our programs on punch cards
> and then lug them five miles through the snow to the computer operator,
> uphill both ways.....

Missed the punchcards, fortunately, although I was forced to suffer the use of
paper-only terminals in my first few years of comp sci.

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

Re: and then... (a curiosity)

[Dmitry A. Kazakov]

On Tue, 2 Sep 2008 15:32:40 +0200, stefan-lucks@see-the.signature wrote:

> A short-circuit "and" (instead of "and then") would not remove that choice 
> -- see the "much better style" above. 

Disagree.

I think a far better idea would be to introduce pure functions and
procedures with results. Functions with side effects and access parameters
is an insanity.

It is also worth to consider introduction of commutative, associative,
inverse operations per contract. This would allow the compiler to prevent a
procedure with the result from appearing in a commutative "and". The
evaluation order of non-associative etc operations could be fixed.

Later it would also allow to manage a combinatory explosion variants in
multi-methods ("and", "or", "+", "*" etc).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: and then... (a curiosity)

[Keith Thompson]

stefan-lucks@see-the.signature writes:
[...]
> Well, if the program requirements are that the side effects for A and B 
> actually occur, I consider it poor programming style if people just write
>
>   if A(X) and B(Y) then ... end if;
>
> IMHO, much better style is the following:
>
>   declare
>     Tmp_A: Boolean := A(X);
>     Tmp_B: Boolean := B(X);
>   begin
>     if Tmp_A and Tmp_B then ... end if;
>   end;
>
> This makes the programmers intention clear, "if A(X) and B(X)" doesn't. 
[...]

(As you said in a later followup, you meant B(Y) rather than B(X).)

I disagree.  The shorter form

    if A(X) and B(Y) then ... end if;

makes the programmer's intent absolutely clear to anyone who knows
what "and" means in Ada.  If I saw the other version my first thought
would be to wonder why the programmer didn't just write "if A(X) and
B(Y)".  After a moment's thought, I'd assume that the order of
evaluation of A(X) and B(Y) is significant.  It would never occur to
me that the long form was used to ensure that both A(X) and B(Y) are
evaluated, since the "and" operator already does that.

All programming languages have their quirks, and none of them exactly
follow mathematical notation (in part because there is no single
mathematical notation).  If you try to write code that will be
understandable to someone who doesn't know the language, you'll end up
with an overly verbose mess that can hardly be understood by someone
who *does* know the language.

If I were doing the equivalent of the above in C, whose logical "and"
operator "&&" does do short-circuit evaluation, I probably would
declare the two temporaries.  In Ada, it's just not necessary.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: and then... (a curiosity)

[Georg Bauhaus]

stefan-lucks@see-the.signature schrieb:

> IMHO, much better style is the following:
> 
>   declare
>     Tmp_A: Boolean := A(X);
>     Tmp_B: Boolean := B(X);
>   begin
>     if Tmp_A and Tmp_B then ... end if;
>   end;
> 
> This makes the programmers intention clear, "if A(X) and B(X)" doesn't. 
> 

> 
> But do you really dispute that following the mathematical conventions 
> as much as possible would improve readability? 

I agree with all of the above. However, after having seen much suffering
from what people think are mathematical conventions used in programs,
I think mathematical conventions should be verboten.

Mathematical conventions are, unfortunately, *much* too vague
to be good guidance. Most of the time they don't apply
in computer programs. On the contrary, digital computers started
their lives for exactly this reason: mathematics had
no formalized steps and finite sets of numbers were uncommon.

Mathematical assumptions make us think that Integer is an integer,
which it isn't!  As you have explained, there is no _|_ in the
set of mathematical integers.

A mathematics for computer programs would be different.
Not like "high school operators" between "high school numbers".


--
Georg Bauhaus
Y A Time Drain  http://www.9toX.de

Re: and then... (a curiosity)

[Georg Bauhaus]

Ludovic Brenta schrieb:
>> But do you really dispute that following the mathematical conventions
>> as much as possible would improve readability?
> 
> Of course not. That's wgy "and" should have its mathematical meaning -
> i.e it should not impose an order of evaluation and it should not
> avoid evaluating its operands. That's what "and then" is for.

There is no order, but still the trouble is that mathematics
is not usually about evaluation at all. The process of
evaluating is not explicitly present in the mathematical
meaning of "and". It does not build on "process" or "procedure".

*

Another issue with "and then" short-circuits apparears
in some "elsif"s:

if This_Thing and then Another_Thing then

elsif This_Thing and then Yet_Another_Thing then

... more of the same ...

else
  -- this catches, errhhm, how many of which of
  -- the alternatives and when?
end if


Nest instead and an "unambiguous if-then-else statement"
removes the need of low-level source code optimization
such as too many short-circuits. Makes your fuses blow :) :)

--
Georg Bauhaus
Y A Time Drain  http://www.9toX.de

Re: and then... (a curiosity)

[Simon Wright]

Keith Thompson <kst-u@mib.org> writes:

> If you try to write code that will be understandable to someone who
> doesn't know the language, you'll end up with an overly verbose mess
> that can hardly be understood by someone who *does* know the language.

A sad but all too common situation!

Re: and then... (a curiosity)

[Robert A Duff]

Keith Thompson <kst-u@mib.org> writes:

> follow mathematical notation (in part because there is no single
> mathematical notation).  If you try to write code that will be
> understandable to someone who doesn't know the language, you'll end up
> with an overly verbose mess that can hardly be understood by someone
> who *does* know the language.
>
> If I were doing the equivalent of the above in C, whose logical "and"
> operator "&&" does do short-circuit evaluation, I probably would
> declare the two temporaries.  In Ada, it's just not necessary.

Perhaps I agree, but this discussion is (at least in part) about
language design, not just how to write good Ada (or good C or whatever).

At AdaCore, we always say "and then", never "and".  I don't like that
style (but of course I obey it, because obeying coding conventions is a
good thing in itself).

It seems to me, side effects on globals in the operands of "and" or
"and then" are just plain Bad.  The only distinction is whether the
right-hand operand makes sense when the left-hand one is False, as in
"X /= null and then X.all....".

- Bob

Re: and then... (a curiosity)

[Robert A Duff]

Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:

> Martin Krischik <krischik@users.sourceforge.net> writes:
>> When I was at Polytechnic first language was PL/1, second Pascal and
>> therefore methodology was different. i.E. Don't rely on the execution
>> order of boolean expressing.
>
> This I also agree with, although I admit being used to the short circuit &&
> forms in the C-like languages.
>
> But my point is about having the source code be clearer when both
> operands are required to be evaluated, especially when this is a
> possibility:

It seems to me that two cases come up in practise, for "A and [then] B".
Either I don't care which gets evaluated first, and don't care whether
or not both get evaluated, because there are no important side effects
(that's "A and B"), or I care about order (that's "A and then B").

I never see cases where it is important that A and B both be evaluated.

Counterexamples, please?  ;-)  Realistic ones, I mean.

- Bob

Re: and then... (a curiosity)

[Jeffrey R. Carter]

Robert A Duff wrote:
> 
> At AdaCore, we always say "and then", never "and".  I don't like that
> style (but of course I obey it, because obeying coding conventions is a
> good thing in itself).

I've noticed that. What is the justification for it? I presume that, being 
compiler writers, AdaCore has some specialized knowledge that led them to make 
that choice.

-- 
Jeff Carter
"C++: The power, elegance and simplicity of a hand grenade."
Ole-Hjalmar Kristensen
90

Re: and then... (a curiosity)

[Robert A Duff]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> writes:

> Robert A Duff wrote:
>> At AdaCore, we always say "and then", never "and".  I don't like that
>> style (but of course I obey it, because obeying coding conventions is a
>> good thing in itself).
>
> I've noticed that. What is the justification for it? I presume that,
> being compiler writers, AdaCore has some specialized knowledge that led
> them to make that choice.

No, as far as I know (being fairly new to AdaCore), there's no
specialized compiler knowledge that led to that choice.  It's just a
style choice.  Programmers on the project agreed that "and then"-always
is the best idea stylistically, and now that's just the way it's done.

- Bob

Re: and then... (a curiosity)

[Santiago Urueña]

> I've noticed that. What is the justification for it? I presume that, being
> compiler writers, AdaCore has some specialized knowledge that led them to make
> that choice.
>
I think that the idea is to always use "and then" / "or else" when
there is a function call because maybe thanks to lazy evaluation some
of those calls can be avoided. In contrast, the AdaCore style guide
suggest using plain "and" / "or" operators when just boolean flags are
involved because it is usually faster to evaluate all the variables
than using lazy evaluation.

Branches and jumps instructions really hurt performance in modern
processors, so when just a set of boolean variables must be evaluated
it is faster to read all of them instead of generating some branches.
When function calls are involved you will have those jump instructions
anyway, so it is better to use lazy evaluation to avoid the overhead
of the function call.

--
Santiago Urueña-Pascual <suruena@gmail.com>

Re: and then... (a curiosity)

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccprnm708a.fsf@shell01.TheWorld.com...
...
> At AdaCore, we always say "and then", never "and".  I don't like that
> style (but of course I obey it, because obeying coding conventions is a
> good thing in itself).

I can't speak for AdaCore, but we (and me personally) have a similar 
convention. It originated in code quality concerns: on the original 8086, 
"and then" could be optimized far better than "and" (because the former is 
branching, and all conditionals on the 8086 required branching; the latter 
requires Boolean values, which had to be created out of branching). These 
days, it's mostly premature optimization.

Note that I avoid the convention in two cases: where a bunch of Boolean 
values are involved (no excess branching is needed), and in rare cases when 
I need both operands evaluated. And I always comment expressions where the 
order is significant or evaluation is significant.

                              Randy.

Re: and then... (a curiosity)

[Stephen Leake]

stefan-lucks@see-the.signature writes:

> True. But the case that you want both expressions to be evaluated is a 
> rare exception. On a *logic* level, "A and B" implies "if A is false, the 
> result is false, regardless of B". 

It can also be read "if B is false, the result is false, regardless of
 A".

Which is precisely why the Ada semantics are what they are; 

    in some unspecified order: evaluate A, evaluate B
    compute 'and' of result

> So short-circuit evaluation is a natural 

By 'natural' I suspect you really mean 'what I'm used to from
experience'.

That's valid, but it's not like it's built into the human genome, or
dicated by the laws of physics. It's more of a cultural issue, and
therefore it varies from programmer to programmer.

> and good thing for a programming language, 

Why is it "good"?

Being the same as what you are used to makes it easy. But when
comparing languages, you need more than that. 

Something like:

    Given two sets of typical programmers, one thoroughly familiar
    with language Red, which has C-like boolean operator semantics,
    and the other thoroughly familiar with language Green, which has
    Ada-like boolean operator semantics, the number of errors made in
    using boolean operators is higher in Red than Green.

or vice-versa :). I haven't seen anyone make a claim like that.

Then you need to get the sets of programmers from China, India, and
Serbia to be really valid :).

> and it is regrettable that Ada needs a more complex syntax for this.
> (Well, "A and B" also implies "if B is false, don't care about A",
> but in a programming language you can't have it both ways.)

Ah, but you can! That's what speculative execution gives you. Ada
allows for that, under user control. In C, you must use nested 'if' to
achieve control.

-- 
-- Stephe

Re: and then... (a curiosity)

[tmoran]

After determining whether "and/and then" or "and/and also" is better,
perhaps this discussion could continue and determine whether
adjectives should appear before or after nouns in human languages.

Re: and then... (a curiosity)

[Robert A Duff]

Santiago Urue�a <suruena@gmail.com> writes:

> suggest using plain "and" / "or" operators when just boolean flags are
> involved because it is usually faster to evaluate all the variables
> than using lazy evaluation.

I don't buy that argument, because the semantics of "A and B and C"
are identical to the semantics of "A and then B and then C" (when A, B,
and C are Boolean variables), so the compiler is free to generate
identical code for both.  If efficiency is important in this case,
the compiler should be trained to make it efficient, and the programmer
shouldn't have to worry about it.

Your point for (non-inlined) function calls is valid, though -- the
compiler can't be expected to know what's in the function in general.

- Bob

Re: and then... (a curiosity)

[Santiago Urueña]

> I don't buy that argument, because the semantics of "A and B and C"
> are identical to the semantics of "A and then B and then C" (when A, B,
> and C are Boolean variables), so the compiler is free to generate
> identical code for both.  If efficiency is important in this case,
> the compiler should be trained to make it efficient, and the programmer
> shouldn't have to worry about it.
>
Yes, I suppose that's why at AdaCore the convention is to use always
short-circuit boolean operators, because gnat can generate the
optimized code anyway for just boolean flags.

> Your point for (non-inlined) function calls is valid, though -- the
> compiler can't be expected to know what's in the function in general.
>
It is interesting that in Spark the compiler can always optimize these
two cases completely, because the functions are always pure. Idea:
pragma Profile (Spark)

Having said that, even if the performance can be improved, I don't
like that rule neither because then when the maintainer sees an "and
then" operator she cannot know whether it is just for performance
reasons or you really want to avoid some side effects (unless some
comments are added).

I agree that those micro-optimizations should be done by the compiler,
so even if the programmer doesn't write the short-circuit operators
when function calls are involved, the compiler should be smart enough
to generate lazy evaluation (if the functions are pure).

Cheers,

Re: and then... (a curiosity)

[Pascal Obry]

My experiences shows that the "and then" is almost always what you want.
An example is when dealing with access types:

   if Ptr /= null and then Ptr.X = 8 then

You really want to evaluate Ptr.X only if Ptr is not null.

I could verify but I do not remember having used "and" at all in fact.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: and then... (a curiosity)

[Brian Drummond]

On Tue, 02 Sep 2008 16:50:34 -0400, Robert A Duff
<bobduff@shell01.TheWorld.com> wrote:

>Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:
>
>> Martin Krischik <krischik@users.sourceforge.net> writes:
>>> When I was at Polytechnic first language was PL/1, second Pascal and
>>> therefore methodology was different. i.E. Don't rely on the execution
>>> order of boolean expressing.
>>
>> This I also agree with, although I admit being used to the short circuit &&
>> forms in the C-like languages.
>>
>> But my point is about having the source code be clearer when both
>> operands are required to be evaluated, especially when this is a
>> possibility:
>
>It seems to me that two cases come up in practise, for "A and [then] B".
>Either I don't care which gets evaluated first, and don't care whether
>or not both get evaluated, because there are no important side effects
>(that's "A and B"), or I care about order (that's "A and then B").
>
>I never see cases where it is important that A and B both be evaluated.
>
>Counterexamples, please?  ;-)  Realistic ones, I mean.

Given the speed penalty for branches, there are circumstances where it
is faster to evaluate both cases than branch around one. In that sense,
it would be important (for performance, rather than semantics) to
evaluate both cases. But that is properly the compiler's decision to
make.

I don't think that's what you meant; I believe you meant "important for
semantics"

But it does illustrate that (I) "and then" (short circuit form, order
guaranteed) and (II) "and" (short circuit permitted, but not guaranteed,
order not guaranteed) are properly separate operations.

For cases such as the logging example (semantics require both to be
evaluated) my personal choice would be to explicitly evaluate both, and
combine their evaluation results, as elsewhere in this thread. 

Is my understanding of Ada correct in expecting this is the only way to
guarantee evaluation of both? ( i.e. Ada handles "and" as (II) above)

- Brian

Re: and then... (a curiosity)

[Dmitry A. Kazakov]

On Wed, 3 Sep 2008 15:14:15 +0200, stefan-lucks@see-the.signature wrote:

>>> A short-circuit "and" (instead of "and then") would not remove that choice
>>> -- see the "much better style" above.
>> 
>> But it would break the mathematical purity of "and".
> 
> Well, if "False and F(X)" is allowed to raise an exception, this is even 
> worse (more far away from mathematical purity) than if "False and F(X)" is 
> just false -- whatever F(X) would do.

Well, it depends. Consider:

   function F (...) return Boolean; -- May raise Some_Error exception

This breaks the contract that promises a *Boolean* result. Mathematically
it means that the result is not Boolean but a value from some other type
Boolean_Ex is (False, True, Some_Error_Fired). Here Some_Error_Fired is an
ideal "value" of Some_Error being propagated. But then "and" is also broken
in its arguments and the result. In particular for "and" defined on
Boolean_Ex and returning Boolean_Ex, the theorem

   False and X <=> X

does not hold anymore. Therefore it cannot be implied. A similar logic
applies to side effects. You just do the Cartesian product of the effect
and the written set of values. This becomes the "true" set of values.

As somebody already pointed out. People using "and" on arguments with side
effects, are fooling themselves and those who are to read the program.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: and then... (a curiosity)

[stefan-lucks]

> > A short-circuit "and" (instead of "and then") would not remove that choice
> > -- see the "much better style" above.
> 
> But it would break the mathematical purity of "and".

Well, if "False and F(X)" is allowed to raise an exception, this is even 
worse (more far away from mathematical purity) than if "False and F(X)" is 
just false -- whatever F(X) would do.


-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: and then... (a curiosity)

[stefan-lucks]

> > and it is regrettable that Ada needs a more complex syntax for this.
> > (Well, "A and B" also implies "if B is false, don't care about A",
> > but in a programming language you can't have it both ways.)
> 
> Ah, but you can! That's what speculative execution gives you. Ada
> allows for that, under user control. In C, you must use nested 'if' to
> achieve control.

AFAIK, you cannot write "if (A>0) and (B/A<100) then ..." and then trust 
that no constraint_error is raised if A=0 in Ada. 

On the other hand, im Mathematics, such expressions are quite usual. 

-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: and then... (a curiosity)

[Adam Beneschan]

On Sep 2, 10:56 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> Santiago Urueña <suru...@gmail.com> writes:
> > suggest using plain "and" / "or" operators when just boolean flags are
> > involved because it is usually faster to evaluate all the variables
> > than using lazy evaluation.
>
> I don't buy that argument, because the semantics of "A and B and C"
> are identical to the semantics of "A and then B and then C" (when A, B,
> and C are Boolean variables),

*Almost* true.  It isn't true when some of those Boolean variables
have 'Address clauses that cause them to be mapped to hardware I/O
registers!!  But I know what you meant.  I'd go so far as to say a
good compiler should generate the exact same code when the arguments
are (normal, non-volatile) Boolean variables whether or not you use
"and" or "and then", and similarly "or" or "or else".  It should just
pick whatever is fastest.

                                -- Adam

Re: and then... (a curiosity)

[Robert A Duff]

Brian Drummond <brian_drummond@btconnect.com> writes:

> On Tue, 02 Sep 2008 16:50:34 -0400, Robert A Duff
> <bobduff@shell01.TheWorld.com> wrote:
>>It seems to me that two cases come up in practise, for "A and [then] B".
>>Either I don't care which gets evaluated first, and don't care whether
>>or not both get evaluated, because there are no important side effects
>>(that's "A and B"), or I care about order (that's "A and then B").
>>
>>I never see cases where it is important that A and B both be evaluated.
>>
>>Counterexamples, please?  ;-)  Realistic ones, I mean.
>
> Given the speed penalty for branches, there are circumstances where it
> is faster to evaluate both cases than branch around one. In that sense,
> it would be important (for performance, rather than semantics) to
> evaluate both cases. But that is properly the compiler's decision to
> make.
>
> I don't think that's what you meant; I believe you meant "important for
> semantics"

Yes, that's what I meant.  And I would like the compiler to worry about
efficiency for me, although I admit that's not always feasible.

> But it does illustrate that (I) "and then" (short circuit form, order
> guaranteed) and (II) "and" (short circuit permitted, but not guaranteed,
> order not guaranteed) are properly separate operations.
>
> For cases such as the logging example (semantics require both to be
> evaluated) my personal choice would be to explicitly evaluate both, and
> combine their evaluation results, as elsewhere in this thread. 
>
> Is my understanding of Ada correct in expecting this is the only way to
> guarantee evaluation of both? ( i.e. Ada handles "and" as (II) above)

No.  Ada guarantees that both arguments of "and" are evaluated.
Of course if the compiler knows that evaluation has no effect, it
doesn't need to generate any code -- that would be the case for
"X > 0", for example.  Ada allows the two operands to be evaluated
in either order (but not in parallel, if that matters).

So in the example you mention, "F(...) and G(...)" where the bodies of F
and G write some output to a log file, both outputs will be written --
in some order, but not intermixed.

- Bob

Re: and then... (a curiosity)

[Vinzent Hoefler]

On Tue, 02 Sep 2008 16:50:34 -0400, Robert A Duff wrote:

> Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:
> 
>> Martin Krischik <krischik@users.sourceforge.net> writes:
>>> When I was at Polytechnic first language was PL/1, second Pascal and
>>> therefore methodology was different. i.E. Don't rely on the execution
>>> order of boolean expressing.
>>
>> This I also agree with, although I admit being used to the short circuit &&
>> forms in the C-like languages.
>>
>> But my point is about having the source code be clearer when both
>> operands are required to be evaluated, especially when this is a
>> possibility:
> 
> It seems to me that two cases come up in practise, for "A and [then] B".
> Either I don't care which gets evaluated first, and don't care whether
> or not both get evaluated, because there are no important side effects
> (that's "A and B"), or I care about order (that's "A and then B").
> 
> I never see cases where it is important that A and B both be evaluated.
> 
> Counterexamples, please?  ;-)  Realistic ones, I mean.

Hmm. Digging in *really* old (Turbo-Pascal) sourcecode, I found an old map
editor:

Example #1:

-- 8< --
    {$IFOPT B+} {$DEFINE OPTB} {$B-} {$ENDIF}
    for i := 0 to TESTFUNCS - 1 do
      b := b and MapTest[i](Contents);
    {$IFDEF OPTB} {$UNDEF OPTB} {$B+} {$ENDIF}
-- 8< --

MapTest is a list of procedures I wanted to execute to check the validity
of an edited map prior to exporting it.

#2:

-- 8< --
      {$IFOPT B-} {$DEFINE OPTB} {$B+} {$ENDIF}
      repeat
        P := Message (Desktop, evBroadCast, cmClose, @C);
      until ((P = NIL) or (C = cmCancel));
      {$IFDEF OPTB} {$UNDEF OPTB} {$B-} {$ENDIF}
-- 8< --

Not quite sure, why I did it here. Seems, more than 10 years ago, I lacked
commenting properly. ;)

Finally #3 (and one of those MapTest functions mentioned above, so one can
see why I did it):

-- 8< --
{$A+,B-,D+,E-,F+,G+,I+,L+,N-,O+,R-,S-,V+,X-}
{    ^^ important!!!}

[...]

function AtLeastOneActor;
var
  b : boolean;
  i,
  j : byte;

begin
  b := False;

  for i := 1 to 62 do
  for j := 1 to 62 do
    b := b or (X.mpObj_Data[i][j].odActors <> 0);

  AtLeastOneActor := b or SaveMsgBox (NOACTOR);
end; {AtLeastOneActor}
-- 8< --

(Uh, bad code, literal constants...)

So, maybe I would generally write it different today, but for an example,
it is as real as it gets.


Vinzent.

Re: and then... (a curiosity)

[Stephen Leake]

stefan-lucks@see-the.signature writes:

>> > (Well, "A and B" also 
>> > implies "if B is false, don't care about A", but in a programming language 
>> > you can't have it both ways.)
>> 
>> That is what I learned in my boolean arithmetic classes. It's either
>> way. There is no preference that the left parameter if more important
>> then the right. A Human seeing "A∧0" won't evaluate A. And if you see
>> "f(x)∧g" you would probably evaluate g first as a variable is usually
>> easier to evaluate then a function.
>
> True. But, at the logic level, the Ada-statement

What is the "logic level"?

I you mean "abstract Boolean logic, like in college", then there is no
such thing as Constraint_Error, nor side effects. So of course it
gives you a bad understanding of programming languages.

-- 
-- Stephe

Re: and then... (a curiosity)

[stefan-lucks]

> > True. But, at the logic level, the Ada-statement
> 
> What is the "logic level"?
> 
> I you mean "abstract Boolean logic, like in college", then there is no
> such thing as Constraint_Error, nor side effects. So of course it
> gives you a bad understanding of programming languages.

Actually, there is Constraint_Erorr, though under a different name. ;-)

If your Boolean function is allowed to raise an exception, this is the 
same as returning "undefined" in three-valued logic, as I pointed out in 
another posting in this mail.

This is the point I had been trying to make in all my postings to this 
thread: "False and Undefined" is False, not Undefined! Thus, "if X/=0 and 
Y/X<100" should go into the else-branch, instead of raising an exception.
The shortcut version "if X/=0 and then Y/X<100" does exactly the right 
thing. 

Perhaps that is the reason why people at AdaCore always write "and then" 
instead of "and". 


-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: and then... (a curiosity)

[Dmitry A. Kazakov]

On Thu, 4 Sep 2008 08:45:03 +0200, stefan-lucks@see-the.signature wrote:

>>> True. But, at the logic level, the Ada-statement
>> 
>> What is the "logic level"?
>> 
>> I you mean "abstract Boolean logic, like in college", then there is no
>> such thing as Constraint_Error, nor side effects. So of course it
>> gives you a bad understanding of programming languages.
> 
> Actually, there is Constraint_Erorr, though under a different name. ;-)
> 
> If your Boolean function is allowed to raise an exception, this is the 
> same as returning "undefined" in three-valued logic, as I pointed out in 
> another posting in this mail.

Why "undefined", it is rather "contradictory" (in four-state Belnap logic)

> This is the point I had been trying to make in all my postings to this 
> thread: "False and Undefined" is False, not Undefined! Thus, "if X/=0 and 
> Y/X<100" should go into the else-branch, instead of raising an exception.
> The shortcut version "if X/=0 and then Y/X<100" does exactly the right 
> thing. 

Well, indeed

    0 /\ _|_ = 0
    0 /\ T = 0

Here 0 = False, 1 = True, _|_ = Uncertain, T = Contradiction. False under
/\ always renders False.

Nevertheless Boolean logic /= Belnap logic, though the former is contained
in the latter. 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: and then... (a curiosity)

[Karel Th�nissen]

<stefan-lucks@see-the.signature> schreef in bericht 
news:Pine.LNX.4.64.0809040835270.21815@medsec1.medien.uni-weimar.de...

>> What is the "logic level"?

>> I you mean "abstract Boolean logic, like in college", then there is no
>> such thing as Constraint_Error, nor side effects. So of course it
>> gives you a bad understanding of programming languages.

Exactly. Programming is not mathematics and the resemblance is so close that 
it is dangerous.

> Actually, there is Constraint_Erorr, though under a different name. ;-)

> If your Boolean function is allowed to raise an exception, this is the
> same as returning "undefined" in three-valued logic, as I pointed out in
> another posting in this mail.


> This is the point I had been trying to make in all my postings to this
> thread: "False and Undefined" is False, not Undefined!

That depends on the type of ternary logic that you consider. If the third 
value stands for 'unknown' then:
   false and unknown => false
However, if the third value is used for contradiction, then:
   false and contradiction => contradiction
That is what Ada does with exceptions.

> Thus, "if X/=0 and Y/X<100" should go into the else-branch, instead of 
> raising an exception.
> The shortcut version "if X/=0 and then Y/X<100" does exactly the right
> thing.

That would be a very bad idea. With that in place, an exception raised by a 
simple programming error, /any/ programming error, would give control to the 
else-branch. Nice if the exception is the one that you know that could 
happen, otherwise disasterous. It has become a exception handler in 
disguise, but one that confuses falsity with exceptions. If this is what you 
want you should invent a 3-branched selection statement.

I agree with other posters that the choice between conditional and 
unconditional AND should be explicit and documented. One may not like the 
syntax chosen in Ada, but it is the only sensible design.

Groeten, Karel

Re: and then... (a curiosity)

[stefan-lucks]

> Well, indeed
> 
>     0 /\ _|_ = 0
>     0 /\ T = 0
> 
> Here 0 = False, 1 = True, _|_ = Uncertain, T = Contradiction. False under
> /\ always renders False.
> 
> Nevertheless Boolean logic /= Belnap logic, though the former is contained
> in the latter. 

I never said "Boolean logic", I said "logic", which was ment to include 
multi-valued logic. ;-)


-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: and then... (a curiosity)

[stefan-lucks]

> > Thus, "if X/=0 and Y/X<100" should go into the else-branch, instead of 
> > raising an exception.
> > The shortcut version "if X/=0 and then Y/X<100" does exactly the right
> > thing.
> 
> That would be a very bad idea. With that in place, an exception raised by a 
> simple programming error, /any/ programming error, would give control to the 
> else-branch. 

You misread what I wrote. A statement such as "if Y/X<000" should 
definitively propagate an exception for X=0, and I never said anything 
otherwise.

But when "if X/=0 and Y/X<100" propagates an exception for X=0, as, alas, 
done in Ada, something is logically wrong.


BTW, why do you think that an exception, such as a Constraint_Error, 
should logically count as a contradiction? 

Dividing something by zero is undefined, not a contradiction.


-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: and then... (a curiosity)

[Dmitry A. Kazakov]

On Thu, 4 Sep 2008 14:04:10 +0200, stefan-lucks@see-the.signature wrote:

>> Well, indeed
>> 
>>     0 /\ _|_ = 0
>>     0 /\ T = 0
>> 
>> Here 0 = False, 1 = True, _|_ = Uncertain, T = Contradiction. False under
>> /\ always renders False.
>> 
>> Nevertheless Boolean logic /= Belnap logic, though the former is contained
>> in the latter. 
> 
> I never said "Boolean logic", I said "logic", which was ment to include 
> multi-valued logic. ;-)

There are many multi-valued logics. But the problem is that taking such a
logic for the base, you need to reconsider everything based on inference.
In such logics inference is sufficiently more difficult, especially when
the results need to be interpreted. The Boolean type is heavily used in the
language. As an example, consider "when others" of a case statement. It
uses the reasoning if X not in A then X in not A (not A = the complement
set of A). But when "in A" is uncertain then its counterpart is too. How
case is supposed to work, then? In fact, especially evident it becomes in
fuzzy logic, in such frameworks you need to keep track on multiple
competing alternatives, because at no point you can discard anything
different from False. On the contrary, in Boolean logic there is only one
right path.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: and then... (a curiosity)

[Georg Bauhaus]

stefan-lucks@see-the.signature schrieb:

> But when "if X/=0 and Y/X<100" propagates an exception for X=0, as, alas, 
> done in Ada, something is logically wrong.

What seems wrong to me is the premise that "and" has a
meaning which is not defined the LRM.

Unfortunately, "and" is the conventional word for this subprogram.
However, switching context to mathematics when the subject
is programming has the obvious effects displayed in this thread.

With Ada requirements in mind (real-time systems,
hardware, predictable execution, ...), then I guess

 Standard."and"(F(X), G(Y))

should normally mean: call subprograms F and G,
just like

  Foo(F(X), G(Y))

should normally mean: call subprograms F and G.
(If at all, deviate from this rule when pragma Pure
applies to F or G and an optimizer is allowed to work.)

Re: and then... (a curiosity)

[Karel Th�nissen]

<stefan-lucks@see-the.signature> schreef in bericht 
news:Pine.LNX.4.64.0809041404570.22581@medsec1.medien.uni-weimar.de...

>> > Thus, "if X/=0 and Y/X<100" should go into the else-branch, instead of
>> > raising an exception.
>> > The shortcut version "if X/=0 and then Y/X<100" does exactly the right
>> > thing.

>> That would be a very bad idea. With that in place, an exception raised by 
>> a
>> simple programming error, /any/ programming error, would give control to 
>> the
>> else-branch.

> You misread what I wrote. A statement such as "if Y/X<000" should
> definitively propagate an exception for X=0, and I never said anything
> otherwise.

So if I understand you correctly this time, the raising (or not) of an 
exception for "if Y/X<000" should in your view depend on the context where 
it is used: /do not raise/ inside branching conditions of a certain pattern, 
but /do raise/ when used as an ordinary statement. I fear that you 
underestimate the complexities of putting that smartness in a compiler and 
you overestimate the abilities of the ordinary programmers to understand 
what is going on.

No, I do not think I misread. Your writing was not precise: you wrote

   "if X/=0 and Y/X<100" should go into the else-branch, instead of raising 
an exception.

But in Ada it does not go to the else-branche for X=0. So you are proposing 
a language change, and I point out that that would be a vey bad idea.

We cannot expect the compiler to be so smart to distinguish exceptions that 
are avoidable if the left operand had been evaluated first (as with 
conditional boolean operators) from the other exceptions in general. So the 
only viable options are: not doing it like this at all (my choice) or 
picking the else branche for all exceptions. That would make it in invisible 
exception handler. Bad, bad, bad. And as noted above, it would also 
introduce context sensitivity whether exceptions should be raised or not. 
Again very bad.

And if you do want conditional evaluation, you choose 'and then'. What is 
wrong with it? Okay, it is wordy, but the formantics in Ada are very 
precise. That is more important than 5 characters saved.

Maybe you meant 'and' in your example in a more abstract sense without 
providing the precision is demanded by Ada. Unfortunately, you expressed it 
as valid Ada.

> But when "if X/=0 and Y/X<100" propagates an exception for X=0, as, alas,
> done in Ada, something is logically wrong.

So you do think that it should not raise an exception and go to the 
else-branche????? Now what do you want? You contradict yourself. Or this the 
reason you came up with the context dependent interpretation of source code? 
The problem is probably that you use the words 'and' and 'should' in two 
different ways. Seems to be the whole point of this discussion.

How much intelligence do you expect from a compiler? And even if the 
compiler where that smart, would we mere programmers understand what was 
going on. How smart should the compiler be? Should it also start using 
inference, perhaps using whole program analysis?

Computing just is not standard logic. Simple boolean logic will not help us 
out and we should stop looking at mathematics and logic as the holy grail in 
computing. It is a different subject.

> BTW, why do you think that an exception, such as a Constraint_Error,
> should logically count as a contradiction?
>
> Dividing something by zero is undefined, not a contradiction.

That again shows my point that mathematics and computing are two different 
beasts. A mathematician will put the pencil done and stop immediately when 
asked to do an undefined operation, such as a division by zero. That just is 
not an option if you are flying 1000 km/h. Then you raise an exception and 
try to make the best of it, probably working from an unknown or even 
corrupted state, regaining control over the machine and bringing the 
passengers to safety.

If the mathematician were to continue anyway and tried to find his way out 
like our software, he could easily obtain contradicitonary results. This 
should be compared with invariants that are broken because of the reaching 
of an undefined operation/ raising an exception in software.

Comparing undefined/raising an exception allowed because they share the 
property: that the result is neither true nor false:

   false AND raisingAnException => raisingAnException
   false AND contradictionary      => contradictionary

Remember that I introduced this point about contradictions where someone 
(you?) equated ternary logic with Kleene's logic. There are other ternary 
logics.

Just to be nitpicking: coming from a DbC-background, a division by zero 
should raise a *violation* of contract, not an exception. A violation indeed 
is a contraction with the explicitly stated contracts. After a violation 
anything goes.

*Exceptions* should be used for things that can be expected, but that should 
be very rare and that are to hard to handle using standard control 
structures. Think of printers that break down, or network failures.

Groeten, Karel 

Re: and then... (a curiosity)

[Dmitry A. Kazakov]

On Thu, 4 Sep 2008 17:16:05 +0200, Karel Th�nissen wrote:

> Just to be nitpicking: coming from a DbC-background, a division by zero 
> should raise a *violation* of contract, not an exception. A violation indeed 
> is a contraction with the explicitly stated contracts. After a violation 
> anything goes.

This contradiction is not the contradiction T of multi-valued logic.
Violation of DbC is a contradiction in the interpretation of a formula F.
It tells that F is incorrect <=> F is not a language statement. On the
contrary, the symbol T (or an exception propagation) is itself correct, it
is a language term.

Whether division by zero is illegal (a contract violation) or T
(exceptional), is a question of type language/design. Ada uses the latter,
because the former would make illegal programs compilable, which nobody
wants.
 
> *Exceptions* should be used for things that can be expected, but that should 
> be very rare and that are to hard to handle using standard control 
> structures. Think of printers that break down, or network failures.

Yes.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: and then... (a curiosity)

[Dmitry A. Kazakov]

On Thu, 4 Sep 2008 14:12:57 +0200, stefan-lucks@see-the.signature wrote:

> BTW, why do you think that an exception, such as a Constraint_Error, 
> should logically count as a contradiction? 
> 
> Dividing something by zero is undefined, not a contradiction.

Undefined is a too vague term.

When a mathematician tells that X/0 > 100 is undefined he usually means
that X/0 > 100 has no interpretation.

But "X/0 > 100 = _|_" has an interpretation. Namely: m(X/0 in ]100,oo[)=1,
m(X/0 not in = ]100,oo[)=1. I.e. it is both possible for X/0 be in ]100,oo[
or in its complement. This is uncertainty.

"X/0 > 100 = T" means that neither is possible (contradiction). This
"contradiction" is closer to an intuitive understanding of X/0 > 100, yet
it is not the standard mathematical meaning of, which is that X/0 > 100 is
not a formula at all.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: and then... (a curiosity)

[stefan-lucks]

> >> Nevertheless Boolean logic /= Belnap logic, though the former is contained
> >> in the latter. 
> > 
> > I never said "Boolean logic", I said "logic", which was ment to include 
> > multi-valued logic. ;-)
> 
> There are many multi-valued logics. 

You are trying to build an overly complex theory, which I am not 
interested in. The issue is very simple:

1. If the A- or the B-part in "if A and B" raises an exception, but the 
   other part is false, the "right thing" (TM) to do would be to transfer 
   control to the else clause (or below "end if", when there is no else). 
   The intermediate result can be viewed as a three-valued logic 
   expression, but the final outcome of the Boolean expression must be 
   Boolean, of course. 

2. If both raise A and B an exception, of if one raises an exception and 
   the other one is true, an exception is propagated. (*)

3. I would be willing to pragmatically sacrifice mathematical purity for a 
   shortcut rule: If A is false, the expression is false, whatever B does. 
   If A raises an exception, of if A is true and B raises an exception, 
   the exception is propagated.
 
----

(*) Funny problem: *Which* exception should be propagated? 
  
   
 


-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: and then... (a curiosity)

[stefan-lucks]

On Thu, 4 Sep 2008,  wrote:

> <stefan-lucks@see-the.signature> schreef in bericht 
> news:Pine.LNX.4.64.0809041404570.22581@medsec1.medien.uni-weimar.de...
> 
> >> > Thus, "if X/=0 and Y/X<100" should go into the else-branch, instead of
> >> > raising an exception.
> >> > The shortcut version "if X/=0 and then Y/X<100" does exactly the right
> >> > thing.
> 
> >> That would be a very bad idea. With that in place, an exception raised by 
> >> a
> >> simple programming error, /any/ programming error, would give control to 
> >> the
> >> else-branch.
> 
> > You misread what I wrote. A statement such as "if Y/X<000" should
> > definitively propagate an exception for X=0, and I never said anything
> > otherwise.
> 
> So if I understand you correctly this time, the raising (or not) of an 
> exception for "if Y/X<000" should in your view depend on the context where 
> it is used: [...]

No, you misread me again. If you had read some earlier posts from me in 
this thread, what I am trying to express is that "and" should better do 
what "and then" actually does. That is it, so simple!

> I fear that you underestimate the complexities of putting that smartness 
> in a compiler and you overestimate the abilities of the ordinary 
> programmers to understand what is going on.

Very strange that the Ada compiler is able to compile stuff if you write 
"and then" instead of "and". Following your point, the designers of Ada 
did overestimate the smartness of compilers. ;-)

Now really, the whole thing seems to work quite well for "and then". And 
in quite a few languages other than Ada for "and".

> No, I do not think I misread. Your writing was not precise: you wrote
> 
>    "if X/=0 and Y/X<100" should go into the else-branch, instead of raising 
> an exception.
> 
> But in Ada it does not go to the else-branche for X=0. So you are proposing 
> a language change, and I point out that that would be a vey bad idea.

I am not trying to propose to change Ada -- regrettably this would break 
compatibility too much. But if it where not for compatibility reasons, I 
would consider to propose that change. 

> We cannot expect the compiler to be so smart to distinguish exceptions that 
> are avoidable if the left operand had been evaluated first (as with 
> conditional boolean operators) from the other exceptions in general. So the 
> only viable options are: not doing it like this at all (my choice) or 
> picking the else branche for all exceptions. 

Strange that the compiler is smart enough to do the right thing if we just 
write "and then" instead of "and". ;-)

> That would make it in invisible exception handler. Bad, bad, bad. And as 
> noted above, it would also introduce context sensitivity whether 
> exceptions should be raised or not. Again very bad.

Where is the context sensitivity about exceptions when you write "and 
then"? 

> And if you do want conditional evaluation, you choose 'and then'. What is 
> wrong with it? Okay, it is wordy, but the formantics in Ada are very 
> precise. That is more important than 5 characters saved.

I could not care less about the five characters. 

But the designers of Ada (and the designers of almost any other language 
out there) have chosen the identifier "and" for a reason. And the reason 
is that the language "and" actually attempts to mimic the mathematical 
"and".

> Maybe you meant 'and' in your example in a more abstract sense without 
> providing the precision is demanded by Ada. Unfortunately, you expressed it 
> as valid Ada.

No, I simply complained about a (minor) design flaw of Ada. 

> > But when "if X/=0 and Y/X<100" propagates an exception for X=0, as, alas,
> > done in Ada, something is logically wrong.
> 
> So you do think that it should not raise an exception and go to the 
> else-branche????? Now what do you want? You contradict yourself. 

Are you trolling? That quote of mine is a repetition, not a contradiction!

> > Dividing something by zero is undefined, not a contradiction.
> 
> That again shows my point that mathematics and computing are two different 
> beasts. A mathematician will put the pencil done and stop immediately when 
> asked to do an undefined operation, such as a division by zero. 

Agreed!

But in a lot of mathematical papers, descriptions of algorithms and the 
like, you actually find expressions like "X/=0 and Y/X<1000". Such an 
expression does have a well-defined meaning, even for X=0. Nobody would 
drop his or here pencil.

BTW, even the order is an issue -- if you write "Y/X<1000 and X/=0" in a 
mathematical paper, that would be logically correct, but you could bet on 
the reviewers asking you to rewrite it to "X/=0 and Y/X<1000".


-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: and then... (a curiosity)

[stefan-lucks]

On Thu, 4 Sep 2008, Dmitry A. Kazakov wrote:

> "X/0 > 100 = T" means that neither is possible (contradiction). This
> "contradiction" is closer to an intuitive understanding of X/0 > 100, yet
> it is not the standard mathematical meaning of, which is that X/0 > 100 is
> not a formula at all.

Well, "X/=0 and Y/X<100" is a common notation with a well-defined meaning, 
even for X=0 (false, of course). On the other hand an isolated "Y/X<100" 
only has a well-defined meaning if X/=0. 



-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: and then... (a curiosity)

[Georg Bauhaus]

stefan-lucks@see-the.signature wrote:

> 1. If the A- or the B-part in "if A and B" raises an exception, but the
>    other part is false, the "right thing" (TM) to do would be to transfer
>    control to the else clause (or below "end if", when there is no else).

With all due respect, professor, you are suggesting circumstances
could warrant the automatic assignment of value False to expection
occurrences?

Re: and then... (a curiosity)

[stefan-lucks]

On Thu, 4 Sep 2008, stefan-lucks@see-the.signature wrote:

> On Thu, 4 Sep 2008,  wrote:
> > So if I understand you correctly this time, the raising (or not) of an 
> > exception for "if Y/X<000" should in your view depend on the context where 
> > it is used: [...]
> 
> No, you misread me again. If you had read some earlier posts from me in 
> this thread, what I am trying to express is that "and" should better do 
> what "and then" actually does. That is it, so simple!

To be precise, here is a cut-and-paste from what I wrote in another 
posting:

1. If the A- or the B-part in "if A and B" raises an exception, but the
   other part is false, the "right thing" (TM) to do would be to transfer
   control to the else clause (or below "end if", when there is no else).
   The intermediate result can be viewed as a three-valued logic
   expression, but the final outcome of the Boolean expression must be
   Boolean, of course.

2. If both raise A and B an exception, of if one raises an exception and
   the other one is true, an exception is propagated. 

3. I would be willing to pragmatically sacrifice mathematical purity for a
   shortcut rule: If A is false, the expression is false, whatever B does.
   If A raises an exception, of if A is true and B raises an exception,
   the exception is propagated.

1. and 2. describe some "ideal" behaviour, but 3. describes what the one 
can realistically expect from the compiler. BTW, the compiler would not 
need to be that incredibly smart. If an exception is raised when 
evaluating a Boolean expression, the exception could be handled inernally, 
to finish evaluating the Boolean expression, and re-raised if neccessary. 

-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: and then... (a curiosity)

[Karel Th�nissen]

<stefan-lucks@see-the.signature> schreef in bericht 
news:Pine.LNX.4.64.0809042128350.25707@medsec1.medien.uni-weimar.de...
> On Thu, 4 Sep 2008, Dmitry A. Kazakov wrote:
>
>> "X/0 > 100 = T" means that neither is possible (contradiction). This
>> "contradiction" is closer to an intuitive understanding of X/0 > 100, yet
>> it is not the standard mathematical meaning of, which is that X/0 > 100 
>> is
>> not a formula at all.
>
> Well, "X/=0 and Y/X<100" is a common notation with a well-defined meaning,
> even for X=0 (false, of course). On the other hand an isolated "Y/X<100"
> only has a well-defined meaning if X/=0.

No, the very fact that we have this discussion shows that it does not have a 
well-defined meaning in computing (outside Ada). And the meaning in two 
valued logic is well-defined, but a different beast.

Claiming 'false of course' is retorics.

And again, you propose a contextual interpretation of "Y/X<100" (for X=0). 
That is totally beyond what program analysis can achieve.

> -- 
> ------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
>               Stefan dot Lucks at uni minus weimar dot de
> ------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------
> 

Re: and then... (a curiosity)

[Karel Th�nissen]

> On Thu, 4 Sep 2008, stefan-lucks@see-the.signature wrote:
>
>> On Thu, 4 Sep 2008,  wrote:
>> > So if I understand you correctly this time, the raising (or not) of an
>> > exception for "if Y/X<000" should in your view depend on the context
>> > where
>> > it is used: [...]
>>
>> No, you misread me again. If you had read some earlier posts from me in
>> this thread, what I am trying to express is that "and" should better do
>> what "and then" actually does. That is it, so simple!

If that /were the only thing you wrote/, then it would indeed be simple. But
in your earlier posting, /and/ a few lines down in the very post I am
replying to now (as a quote from an earlier posting), you write something
different. See few lines further down.

I personally could life with the idea that in Ada, 'and' would have had
conditional formantics (now  and-then)and some other operator would have
unconditional formantics (now and). That is just swapping tokens at the
lexical level. Fine. What is your point?

> To be precise, here is a cut-and-paste from what I wrote in another
> posting:
>
> 1. If the A- or the B-part in "if A and B" raises an exception, but the
>   other part is false, the "right thing" (TM) to do would be to transfer
>   control to the else clause (or below "end if", when there is no else).
>   The intermediate result can be viewed as a three-valued logic
>   expression, but the final outcome of the Boolean expression must be
>   Boolean, of course.

Thank you, there it is.

Contrary to what you write above, this is /not/ the formantics of and-then
in Ada. In Ada, the conditional boolean operators are not symmetric: "A
and-then B" is not equivalent to "A and-then B". So you are proposing
something new in the language beyond the mere choice of lexemes.

The formantics you propose would be an exception handler that does not
discriminate neither for the type of the exception, nor for the side of the
operator where it was raised. The ambiguity of both sides raising an
exception is handled by rule 2 below.

The formantics you propose would execute the else-branch for *any*
exception, not just the divide by zero in the example, but also overflows
and Gods knows what else. A nice place for bugs to hide. It is even worse
than that: if there is no else-branch, then the execution silently continues
after the end-if. Great. Bugs now go completely undetected. The worst
possible thing you could do for high-integrity software.

> 2. If both raise A and B an exception, of if one raises an exception and
>   the other one is true, an exception is propagated.

Why not follow your own logic and really use a three-valued logic and
introduce a three-branched if-then-else structure with a third branch for
handling "undefined and undefined" or whatever you call it.

> 3. I would be willing to pragmatically sacrifice mathematical purity for a
>   shortcut rule: If A is false, the expression is false, whatever B does.
>   If A raises an exception, of if A is true and B raises an exception,
>   the exception is propagated.

Congratulations, you just reinvented the and-then in Ada.

> 1. and 2. describe some "ideal" behaviour, but 3. describes what the one
> can realistically expect from the compiler. BTW, the compiler would not
> need to be that incredibly smart. If an exception is raised when
> evaluating a Boolean expression, the exception could be handled inernally,
> to finish evaluating the Boolean expression, and re-raised if neccessary.

1+2 may appear ideal for a mathematician, because of the symmetry it
provides. But we are not doing mathematics. I am a professional software
engineer and I do not want my stupid mistakes, that I do make, caught by
contracts that raise all sorts of violations (program exceptions), go
unnoticed because the exception is silently handled in the else-branche or
not at all if there is no such branche.

Ideal behavior is a fata morgana from lala-land. We have to deal with
fallible developers and machinery.

> ------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
>               Stefan dot Lucks at uni minus weimar dot de
> ------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: and then... (a curiosity)

[Karel Th�nissen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6528 bytes --]

>> <stefan-lucks@see-the.signature> schreef in bericht
>> news:Pine.LNX.4.64.0809041404570.22581@medsec1.medien.uni-weimar.de...

>> So if I understand you correctly this time, the raising (or not) of an
>> exception for "if Y/X<000" should in your view depend on the context
>> where
>> it is used: [...]
>
> No, you misread me again. If you had read some earlier posts from me in
> this thread, what I am trying to express is that "and" should better do
> what "and then" actually does. That is it, so simple!

Refuted in another reply.

>> I fear that you underestimate the complexities of putting that smartness
>> in a compiler and you overestimate the abilities of the ordinary
>> programmers to understand what is going on.
>
> Very strange that the Ada compiler is able to compile stuff if you write
> "and then" instead of "and". Following your point, the designers of Ada
> did overestimate the smartness of compilers. ;-)

My objections are targeted at the thing that you propose (elsewhere called
1+2). That beast would either allow bugs to hide, or would require whole
program analysis and perhaps mind-reading capabilties.

> Now really, the whole thing seems to work quite well for "and then". And
> in quite a few languages other than Ada for "and".

If course it works. It is a different thing thing you propose.

>> No, I do not think I misread. Your writing was not precise: you wrote
>>
>>    "if X/=0 and Y/X<100" should go into the else-branch, instead of
>> raising
>> an exception.
>>
>> But in Ada it does not go to the else-branche for X=0. So you are
>> proposing
>> a language change, and I point out that that would be a vey bad idea.
>
> I am not trying to propose to change Ada -- regrettably this would break
> compatibility too much. But if it where not for compatibility reasons, I
> would consider to propose that change.

>> We cannot expect the compiler to be so smart to distinguish exceptions
>> that
>> are avoidable if the left operand had been evaluated first (as with
>> conditional boolean operators) from the other exceptions in general. So
>> the
>> only viable options are: not doing it like this at all (my choice) or
>> picking the else branche for all exceptions.
>
> Strange that the compiler is smart enough to do the right thing if we just
> write "and then" instead of "and". ;-)

You still seem to think that the conditional-and in a programming language
can be symmetric.

>> That would make it in invisible exception handler. Bad, bad, bad. And as
>> noted above, it would also introduce context sensitivity whether
>> exceptions should be raised or not. Again very bad.
>
> Where is the context sensitivity about exceptions when you write "and
> then"?

There is no need in Ada, for the simple reason that the compiler can see the
difference between "A and B" and "A and then B" without knowing anything at
all about the context in which it is used. Therefore, the choice of
formantics is known while parsing that particular expression/ production in
the grammar.

>> And if you do want conditional evaluation, you choose 'and then'. What is
>> wrong with it? Okay, it is wordy, but the formantics in Ada are very
>> precise. That is more important than 5 characters saved.
>
> I could not care less about the five characters.
>
> But the designers of Ada (and the designers of almost any other language
> out there) have chosen the identifier "and" for a reason. And the reason
> is that the language "and" actually attempts to mimic the mathematical
> "and".

Yes, I agree and that is very unfortunate. But while we are at it. The
'designers' of logic made the same mistake: they have chosen an
interpretation that difference from the word "and" in English. Take a
semiologist to explain the difference. The important thing is that the
formantics of the operator be well-defined. That is the case in the various
logics as is the case in Ada (but not in most other programming languages).

>> Maybe you meant 'and' in your example in a more abstract sense without
>> providing the precision is demanded by Ada. Unfortunately, you expressed
>> it
>> as valid Ada.
>
> No, I simply complained about a (minor) design flaw of Ada.
>
>> > But when "if X/=0 and Y/X<100" propagates an exception for X=0, as,
>> > alas,
>> > done in Ada, something is logically wrong.
>>
>> So you do think that it should not raise an exception and go to the
>> else-branche????? Now what do you want? You contradict yourself.
>
> Are you trolling? That quote of mine is a repetition, not a contradiction!
>
>> > Dividing something by zero is undefined, not a contradiction.
>>
>> That again shows my point that mathematics and computing are two
>> different
>> beasts. A mathematician will put the pencil done and stop immediately
>> when
>> asked to do an undefined operation, such as a division by zero.
>
> Agreed!
>
> But in a lot of mathematical papers, descriptions of algorithms and the
> like, you actually find expressions like "X/=0 and Y/X<1000". Such an
> expression does have a well-defined meaning, even for X=0. Nobody would
> drop his or here pencil.
>
> BTW, even the order is an issue -- if you write "Y/X<1000 and X/=0" in a
> mathematical paper, that would be logically correct, but you could bet on
> the reviewers asking you to rewrite it to "X/=0 and Y/X<1000".

Then the author is not using boolean Algebra, but some three valued logic.
Quite possible. Perhaps a logic with:

   false and undefined  <=> undefined and false <=> false

If that is the definition, then that would be possible. But this is not the
na�ve definition from Boolean algebra. This definition must be learned, but
then you could equally well learn both well-defined definitions as from Ada.

But you may still prefer above definition from a three-valued logic. I
agree, the logic is well-defined and mathemtically elegant. However, it is
an engineering disaster. We write millions of lines of code and we must deal
with violations, exceptions, and validations errors. In general exceptions
are a fact of life in computing. And I do not want my exceptions
(violations, errors) to get uncaught because of some interpretation of
boolean operators that sends them to else clause or silently resumes
execution, no matter how elegant the notation for completely correct
programs.

> ------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
>               Stefan dot Lucks at uni minus weimar dot de
> ------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------
>

Re: and then... (a curiosity)

[Dmitry A. Kazakov]

On Thu, 4 Sep 2008 21:31:21 +0200, stefan-lucks@see-the.signature wrote:

> On Thu, 4 Sep 2008, Dmitry A. Kazakov wrote:
> 
>> "X/0 > 100 = T" means that neither is possible (contradiction). This
>> "contradiction" is closer to an intuitive understanding of X/0 > 100, yet
>> it is not the standard mathematical meaning of, which is that X/0 > 100 is
>> not a formula at all.
> 
> Well, "X/=0 and Y/X<100" is a common notation with a well-defined meaning, 
> even for X=0 (false, of course). On the other hand an isolated "Y/X<100" 
> only has a well-defined meaning if X/=0.

Hmm, in the texts I can still remember comma was used instead of /\:

   X /= 0, Y/X < 100   (when a set of pairs (X,Y) is specified)

   A, A => B
   --------------     (inference rule)
      B

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: and then... (a curiosity)

[Dmitry A. Kazakov]

On Thu, 4 Sep 2008 21:05:02 +0200, stefan-lucks@see-the.signature wrote:

>>>> Nevertheless Boolean logic /= Belnap logic, though the former is contained
>>>> in the latter. 
>>> 
>>> I never said "Boolean logic", I said "logic", which was ment to include 
>>> multi-valued logic. ;-)
>> 
>> There are many multi-valued logics. 
> 
> You are trying to build an overly complex theory,

I though you wanted to expose these values. But see below.

> which I am not interested in.

(You should be interested in making a consistent proposal...)

> The issue is very simple:
>
> 1. If the A- or the B-part in "if A and B" raises an exception, but the 
>    other part is false, the "right thing" (TM) to do would be to transfer 
>    control to the else clause (or below "end if", when there is no else). 
>    The intermediate result can be viewed as a three-valued logic 
>    expression, but the final outcome of the Boolean expression must be 
>    Boolean, of course. 

   0 /\ T = 0  (as you see the theory is very simple)

> 2. If both raise A and B an exception, of if one raises an exception and 
>    the other one is true, an exception is propagated. (*)

   T /\ T = T (ditto)
 
> 3. I would be willing to pragmatically sacrifice mathematical purity for a 
>    shortcut rule:

There is absolutely no reason to sacrifice purity for impurity.

>    If A is false, the expression is false, whatever B does. 
>    If A raises an exception, of if A is true and B raises an exception, 
>    the exception is propagated.

   1 /\ T = T (it works!)

As you see the theory works fine, even if you don't like it.

Anyway now I see what you want. That is (more or less formally):

Boolean'Base is Belnap logical values. All Boolean expressions are
evaluated in Boolean'Base, as it is already done for numeric types. Nothing
drastically new. (Compare also how Float overflow is converted to IEEE
Infinity.) Like universal numbers, Boolean'Base may have no variables
declared.

> (*) Funny problem: *Which* exception should be propagated? 

This is not funny. This one kills the idea, unless you forcefully convert
all exceptions into Constraint_Error, when a non-Boolean value is converted
to Boolean.

But the main problem is that this is not what people want. They do lazy
evaluation in order to control side effects (and exception is considered
rather as a side effect). Your proposal does not deal with eagerness. Yes
the compiler might optimize away evaluation of one of the arguments of
"and" if another is False. But to do so it still needs a proof that there
is no side effects other than an exception. Unlikely to exceptions, you
cannot pack all side effects into T or _|_.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: and then... (a curiosity)

[Brian Drummond]

On Wed, 03 Sep 2008 11:56:15 -0400, Robert A Duff
<bobduff@shell01.TheWorld.com> wrote:

>Brian Drummond <brian_drummond@btconnect.com> writes:

>> But it does illustrate that (I) "and then" (short circuit form, order
>> guaranteed) and (II) "and" (short circuit permitted, but not guaranteed,
>> order not guaranteed) are properly separate operations.
>>
>> For cases such as the logging example (semantics require both to be
>> evaluated) my personal choice would be to explicitly evaluate both, and
>> combine their evaluation results, as elsewhere in this thread. 
>>
>> Is my understanding of Ada correct in expecting this is the only way to
>> guarantee evaluation of both? ( i.e. Ada handles "and" as (II) above)
>
>No.  Ada guarantees that both arguments of "and" are evaluated.
>Of course if the compiler knows that evaluation has no effect, it
>doesn't need to generate any code -- that would be the case for
>"X > 0", for example. 

In the process it must give up some opportunities for optimisation
(though I suspect, not as many as e.g. mandating the short-circuit form
in a particular order). 
Note: I am not complaining that this is an unreasonable design decision.

- Brian

Re: and then... (a curiosity)

[Ray Blaak]

stefan-lucks@see-the.signature writes:
> > This is not funny. This one kills the idea, unless you forcefully convert
> > all exceptions into Constraint_Error, when a non-Boolean value is converted
> > to Boolean.
> 
> If I would actually propose something like that, I would probably propose 
> to raise Program_Error if the exceptions aren't all the same. 

If you have a situation where all operands are evaluated, then the exceptions
raised should only be those from the operand expressions themselves under
normal language rules: Constraint_Error if appropriate, whatever explicit
exception a function raises, etc.

To do anything else gives way to madness. If nothing else, it would be quite
difficult to determine the root cause of an exception, and examining source
code would not give obvious reasons.

The only way out is to have partial evaluation of boolean expressions, so that
you can have guard operands *and* consistent exception rules. But Ada already
has that with "and then" and "or else", so consistently use that if you wish.

The reasons of having "and" and "or" evaluate both operands is a least
consistent and logical according to Ada rules, especially given that they are
semantically function calls.

It's just that for me, if I see a boolean expression, I am by instinct
evaluating the boolean logic, not seeing the side effect of evaluating all
operands. If that needs to be stressed, i.e., is an explicit requirement, I
prefer the code to more clearly spell out that required evaluation, and leave
the boolean combination of the results as a separate step.

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

Re: and then... (a curiosity)

[Ray Blaak]

stefan-lucks@see-the.signature writes:
> But "if False and Function_Call_That_Raises_An_Exception" ideally should 
> not propagate the exception raised in the function call, but evaluate to 
> false.

If the function executes, then of course the exception should be
propogated. Otherwise you have silent errors.

The only way out is to not evaluate the function at all.

But that is just "and then".

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

Re: and then... (a curiosity)

[Ray Blaak]

stefan-lucks@see-the.signature writes:
> Now, a really ugly issue is that both the evaluation of A and the 
> evaluation of B might raise an exeption, and we cannot re-raise both 
> exceptions. 

They are executed sequentially, in some arbitrary order, so one wins
first. That is the exception that gets propataged

> If not for other reasons, that suffices not to propagate that. 

This is the worst thing to do, for that silently hides error situations.

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

Re: and then... (a curiosity)

[Vinzent Hoefler]

On Fri, 05 Sep 2008 09:44:33 +0200, stefan-lucks wrote:

> I didn't invent or re-invent anything. I just pointed out that the fact 
> that "and then" does, what "and" should do. This is un-intiutive and 
> error-prone.

Well, for me the "and" disguising as "and then" would be unintuitive.
I had the same issues, as you seem to have now, adjusting to C's
IMO "illogical" statements like "if ((NULL != p) && (p->something))"
suddenly being totally valid.

So, the "intuition" obviously depends on the observer. ;)


Vinzent.

Re: and then... (a curiosity)

[stefan-lucks]

On Thu, 4 Sep 2008, Dmitry A. Kazakov wrote:

> There is absolutely no reason to sacrifice purity for impurity.

Fine! ;-)

> >    If A is false, the expression is false, whatever B does. 
> >    If A raises an exception, of if A is true and B raises an exception, 
> >    the exception is propagated.
> 
>    1 /\ T = T (it works!)
> 
> As you see the theory works fine, even if you don't like it.
> 
> Anyway now I see what you want. That is (more or less formally):
> 
> Boolean'Base is Belnap logical values. All Boolean expressions are
> evaluated in Boolean'Base, as it is already done for numeric types. Nothing
> drastically new. (Compare also how Float overflow is converted to IEEE
> Infinity.) Like universal numbers, Boolean'Base may have no variables
> declared.

> > (*) Funny problem: *Which* exception should be propagated? 
> 
> This is not funny. This one kills the idea, unless you forcefully convert
> all exceptions into Constraint_Error, when a non-Boolean value is converted
> to Boolean.

If I would actually propose something like that, I would probably propose 
to raise Program_Error if the exceptions aren't all the same. 

> But the main problem is that this is not what people want. They do lazy
> evaluation in order to control side effects (and exception is considered
> rather as a side effect). 

Well, exceptions are treated like side effects, but they actually are 
something different. 

E.g., pure functions are free from "real" side effects, but they can still 
raise an exception. Even if you employ the SPARK verifier, you can be sure 
that no Constraint_Error occurs, but you still don't know about 
Storage_Error.




-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: and then... (a curiosity)

[stefan-lucks]

> stefan-lucks@see-the.signature wrote:
> 
> > 1. If the A- or the B-part in "if A and B" raises an exception, but the
> >    other part is false, the "right thing" (TM) to do would be to transfer
> >    control to the else clause (or below "end if", when there is no else).
> 
> With all due respect, professor, you are suggesting circumstances
> could warrant the automatic assignment of value False to expection
> occurrences?

For heaven's sake, no!

But "if False and Function_Call_That_Raises_An_Exception" ideally should 
not propagate the exception raised in the function call, but evaluate to 
false.


-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: and then... (a curiosity)

[stefan-lucks]

On Thu, 4 Sep 2008,  wrote:

> > Very strange that the Ada compiler is able to compile stuff if you write
> > "and then" instead of "and". Following your point, the designers of Ada
> > did overestimate the smartness of compilers. ;-)
> 
> My objections are targeted at the thing that you propose (elsewhere called
> 1+2). That beast would either allow bugs to hide, or would require whole
> program analysis and perhaps mind-reading capabilties.

Firstly, I have been very clear that I didn't "propose" that. 

Secondly, it is easy to implement. Replace "if A and B then ... else ... 
end if" by:

declare 
  T_A := A;
begin
  if T_A then 
    return B; -- may raise an exception
  end if;
exception
  when others =>
    if B -- may raise an exception
    then 
      raise; -- propagate the exception raised by A 
    else
      return False;
    end if;
end;

Hey, do you need mind-reading capabilities for that? I would consider 
this an exercise for Students -- and a really easy one.;-)

Now, a really ugly issue is that both the evaluation of A and the 
evaluation of B might raise an exeption, and we cannot re-raise both 
exceptions. If not for other reasons, that suffices not to propagate that. 
Well, one could raise a Program_Error in that case, but that is ugly 
anyway. But note that even in Ada-as-it-is, it is not defined which of 
both exceptions is raised!

> > is that the language "and" actually attempts to mimic the mathematical
> > "and".
> 
> Yes, I agree and that is very unfortunate. But while we are at it. The
> 'designers' of logic made the same mistake: they have chosen an
> interpretation that difference from the word "and" in English. 

OK, here we disagree. They wanted the "and", because they wanted to mimic 
the mathematical and -- as much as the designers of most other languages. 
As much as integer addition mimics the addition over the integers ... 

> Quite possible. Perhaps a logic with:
> 
>    false and undefined  <=> undefined and false <=> false
> 
> If that is the definition, then that would be possible. But this is not the
> nave definition from Boolean algebra. This definition must be learned, but
> then you could equally well learn both well-defined definitions as from Ada.
> 
> But you may still prefer above definition from a three-valued logic. I
> agree, the logic is well-defined and mathemtically elegant. However, it is
> an engineering disaster. We write millions of lines of code and we must deal
> with violations, exceptions, and validations errors. 

The better it would be to focus on actual violations. Instead of hunting 
an exception raised in fragments such as "if X/=0 and Y/X<Z".


-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: and then... (a curiosity)

[stefan-lucks]

On Thu, 4 Sep 2008,  wrote:

> And again, you propose a contextual interpretation of "Y/X<100" (for X=0). 
> That is totally beyond what program analysis can achieve.

No, I am not. I claim that the shortcut "and" (which in Ada unfurtunately 
is written as "and then") is the more natural and human-readable 
interpretation of "and" expressions.

-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: and then... (a curiosity)

[stefan-lucks]

On Thu, 4 Sep 2008,  wrote:

> > On Thu, 4 Sep 2008, stefan-lucks@see-the.signature wrote:
> >> No, you misread me again. If you had read some earlier posts from me in
> >> this thread, what I am trying to express is that "and" should better do
> >> what "and then" actually does. That is it, so simple!
[...]
> I personally could life with the idea that in Ada, 'and' would have had
> conditional formantics (now  and-then)and some other operator would have
> unconditional formantics (now and). That is just swapping tokens at the
> lexical level. Fine. What is your point?

That was my point. I don't know why this raised such a lengthy thread. 

> > To be precise, here is a cut-and-paste from what I wrote in another
> > posting:
> >
> > 1. If the A- or the B-part in "if A and B" raises an exception, but the
> >   other part is false, the "right thing" (TM) to do would be to transfer
> >   control to the else clause (or below "end if", when there is no else).
> >   The intermediate result can be viewed as a three-valued logic
> >   expression, but the final outcome of the Boolean expression must be
> >   Boolean, of course.
> 
> Thank you, there it is.

Please don't take me out of context! As I pointed out, there are reasons 
not to do exactly the "right thing" in a pragmatic language. I had been 
very explicit, that if I where proposing a language change (I am not, as 
this would break compatibilty), I would propose the following:

> > 3. I would be willing to pragmatically sacrifice mathematical purity for a
> >   shortcut rule: If A is false, the expression is false, whatever B does.
> >   If A raises an exception, of if A is true and B raises an exception,
> >   the exception is propagated.
> 
> Congratulations, you just reinvented the and-then in Ada.

I didn't invent or re-invent anything. I just pointed out that the fact 
that "and then" does, what "and" should do. This is un-intiutive and 
error-prone. Exceptions may be raised which the programmer would not 
really expect to be raised. 

I described an "ideal" interpretation. You would not need "mind reading" 
capabilities to impleent it, but it would still be too heavy-weight and 
complex. And I pointed out an easy and pragmatic approach which could 
handle the issue, and which is used in quite a few other programming 
languages. 

> 1+2 may appear ideal for a mathematician, because of the symmetry it
> provides. [...]
> 
> Ideal behavior is a fata morgana from lala-land. We have to deal with
> fallible developers and machinery.

Thank you for making my point! 


-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: and then... (a curiosity)

[stefan-lucks]

> > If not for other reasons, that suffices not to propagate that. 
> 
> This is the worst thing to do, for that silently hides error situations.

Sorry, I meant to write not to *propose* that. So I agree with you.

-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: and then... (a curiosity)

[Ludovic Brenta]

Stefan Lucks wrote:
> On Thu, 4 Sep 2008,  wrote:
>
> > And again, you propose a contextual interpretation of "Y/X<100" (for X=0).
> > That is totally beyond what program analysis can achieve.
>
> No, I am not. I claim that the shortcut "and" (which in Ada unfurtunately
> is written as "and then") is the more natural and human-readable
> interpretation of "and" expressions.

Maybe my college years are too far behind but I differ here. When I
see "and", I intuitively think of a _symmetric_ operator with the same
meaning for Booleans as for arrays of Booleans and modular types (i.e.
bitwise, mathematical, pure Boolean-logic "and"). When I see "and
then", I intuitively think of an _asymmetric_ operator which only
evaluates the right hand side if the left-hand side is True.

--
Ludovic Brenta.

Re: and then... (a curiosity)

[Robert A Duff]

stefan-lucks@see-the.signature writes:

> But when "if X/=0 and Y/X<100" propagates an exception for X=0, as, alas, 
> done in Ada, something is logically wrong.

So what do you think "if Y/X<100 and X/=0" should do in Ada when X = 0?

The original poster asked for "and" to behave like "and then",
which is asymmetric.

- Bob

Re: and then... (a curiosity)

[Robert A Duff]

I wrote:

> stefan-lucks@see-the.signature writes:
>
>> But when "if X/=0 and Y/X<100" propagates an exception for X=0, as, alas, 
>> done in Ada, something is logically wrong.
>
> So what do you think "if Y/X<100 and X/=0" should do in Ada when X = 0?

Ah, I see you answered this question elsewhere.  You said 1+2 is what
you prefer, because you believe it to be mathematically elegant,
but you would settle for 3.

Well, that seems inconsistent, to me: you can't argue for 3 ("and"
should behave as "and then" does, and we can presumably eliminate
the "and then" syntax from the language) on the basis that 1+2
is elegant.

- Bob

Re: and then... (a curiosity)

[Robert A Duff]

stefan-lucks@see-the.signature writes:

> On Thu, 4 Sep 2008,  wrote:
>
>> > Very strange that the Ada compiler is able to compile stuff if you write
>> > "and then" instead of "and". Following your point, the designers of Ada
>> > did overestimate the smartness of compilers. ;-)
>> 
>> My objections are targeted at the thing that you propose (elsewhere called
>> 1+2). That beast would either allow bugs to hide, or would require whole
>> program analysis and perhaps mind-reading capabilties.
>
> Firstly, I have been very clear that I didn't "propose" that. 
>
> Secondly, it is easy to implement.

What is "it" here?  In the below, are you implementing the 1+2 idea,
or the 3 idea?  Neither one seems right (even ignoring the minor
syntax errors)...

>... Replace "if A and B then ... else ... 
> end if" by:
>
> declare 
>   T_A := A;
> begin
>   if T_A then 
>     return B; -- may raise an exception
>   end if;
> exception
>   when others =>
>     if B -- may raise an exception
>     then 
>       raise; -- propagate the exception raised by A 
>     else
>       return False;
>     end if;
> end;

In the above, if B raises an exception the first time, we evaluate B
again (and maybe it raises the exception again, or maybe not).
Surely that's not what you meant!  And the comment 
"propagate the exception raised by A" is wrong, since the
handler doesn't apply to exceptions raised by A.

> Hey, do you need mind-reading capabilities for that?

Yes, I need to read your mind to know what you meant above.  ;-)

>...I would consider 
> this an exercise for Students -- and a really easy one.;-)

;-)

> Now, a really ugly issue is that both the evaluation of A and the 
> evaluation of B might raise an exeption, and we cannot re-raise both 
> exceptions. If not for other reasons, that suffices not to propagate that. 
> Well, one could raise a Program_Error in that case, but that is ugly 
> anyway. But note that even in Ada-as-it-is, it is not defined which of 
> both exceptions is raised!

Sure, that's a little ugly, but in practice it doesn't matter -- the
fact that something went wrong is not lost.

- Bob

Re: and then... (a curiosity)

[Robert A Duff]

stefan-lucks@see-the.signature writes:

>> >> Nevertheless Boolean logic /= Belnap logic, though the former is contained
>> >> in the latter. 
>> > 
>> > I never said "Boolean logic", I said "logic", which was ment to include 
>> > multi-valued logic. ;-)
>> 
>> There are many multi-valued logics. 
>
> You are trying to build an overly complex theory, which I am not 
> interested in. The issue is very simple:
>
> 1. If the A- or the B-part in "if A and B" raises an exception, but the 
>    other part is false, the "right thing" (TM) to do would be to transfer 
>    control to the else clause (or below "end if", when there is no else). 
>    The intermediate result can be viewed as a three-valued logic 
>    expression, but the final outcome of the Boolean expression must be 
>    Boolean, of course. 
>
> 2. If both raise A and B an exception, of if one raises an exception and 
>    the other one is true, an exception is propagated. (*)
>
> 3. I would be willing to pragmatically sacrifice mathematical purity for a 
>    shortcut rule: If A is false, the expression is false, whatever B does. 
>    If A raises an exception, of if A is true and B raises an exception, 
>    the exception is propagated.

Some more questions about 3.

Do you want to say that "and" is not a function (just like "and then" is
not a function)?  So you can't pass "and" as a generic formal parameter,
pass it as a downward closure to an iterator, or rename it?

Or are you saying that if "and" is passed to a generic formal function
called Mumble, then Mumble gets this special property (of not evaluating
its second argument in some cases)?

Do you want that "and" on array-of-Boolean is no longer defined in terms
of "and" on each component pair?  (There's no such thing as "and then"
on arrays.)  Same question for modular "and".  Or maybe just eliminate
these other "and" operators?

Do believe that "0 * F(X)" should return 0, even if F raises
an exception?  Must return 0, or might return 0?

I'm just trying to explore the consequences of this seemingly-simple
language design choice.  It doesn't seem so simple to me.

- Bob

Re: and then... (a curiosity)

[Dmitry A. Kazakov]

On Fri, 05 Sep 2008 10:14:47 -0400, Robert A Duff wrote:
 
> Some more questions about 3.

(The proposal is, as I understood it, IMO workable, but it potentially has
a heavy overhead and it does not solve the problem. It is not the
mathematical interpretation of "and", and its semantics is not better than
one of "and then". Further IMO the problem lies elsewhere. Nevertheless, I
will take the liberty of explaining the semantics, and consequences)
 
> Do you want to say that "and" is not a function (just like "and then" is
> not a function)?  So you can't pass "and" as a generic formal parameter,
> pass it as a downward closure to an iterator, or rename it?

It will be a normal function. Surely this would require a lot of re-work of
the existing compilers, because exception occurrence will become an
extended "Universal_Boolean" value. It will likely mean a lot of
distributed overhead, because an exception which is already underway needs
to be convertible into a value everywhere a "Universal_Boolean" is
expected.

> Or are you saying that if "and" is passed to a generic formal function
> called Mumble, then Mumble gets this special property (of not evaluating
> its second argument in some cases)?

No, all arguments are eagerly evaluated. It is simply so that exception
becomes a legal value of "Universal_Boolean". The exception is raised when
such value is converted to Boolean in the context where a Boolean is
expected. Like in "if". But "and", "or", "xor", "not" operate on
"Universal_Boolean".

> Do you want that "and" on array-of-Boolean is no longer defined in terms
> of "and" on each component pair?  (There's no such thing as "and then"
> on arrays.)  Same question for modular "and".  Or maybe just eliminate
> these other "and" operators?

This is no problem either, because "Universal_Boolean" is not Boolean like
Universal_Integer is not Integer. So the array of Boolean remains what it
was.

> Do believe that "0 * F(X)" should return 0, even if F raises
> an exception?  Must return 0, or might return 0?

That's the case for IEEE numbers. The idea is to replace a potential or
real (shudder) exception propagation with a value, which may or may not
raise the exception later. This value may participate in expressions. It
can even be stored as NaN is. (Though, not in this case.)

BTW, I am not a fan of IEEE numbers. But considering it rationally,
evaluation of expressions in terms of wider ranges or ideal values has some
advantages. After all 1-3+4 is OK for Positive, even if (1-3) is not a
positive.

> I'm just trying to explore the consequences of this seemingly-simple
> language design choice.  It doesn't seem so simple to me.

(I hope Stefan will correct me if I misinterpreted his proposal)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: and then... (a curiosity)

[Hyman Rosen]

Robert A Duff wrote:
> I'm just trying to explore the consequences of this seemingly-simple
> language design choice.  It doesn't seem so simple to me.

There are two kinds of "and" - the one that's involved in
control flow, and should therefore be short-circuited, and
the one that combines booleans, which is just an arithmetic
function like addition and should therefore not be short-
circuited.

Both C and Ada have this, C through "&&" and "&" and Ada
through "and then" and "and". Given the nature of code,
the control flow variant appears far more often than the
arithmetic one, so I guess some people are disturbed by
the fact that the most common variant is wordier. As a
long-time reader of this newsgroup, I know the mantra that
"Ada is designed for readers, not writers. Shorter is not
necessarily better." :-)

By the way, C++ made the design mistake of allowing && and
|| to be overloaded, whereupon they lose their short-circuit
behavior and become normal evaluate-both-operands functions.
Just awful.

Re: and then... (a curiosity)

[Adam Beneschan]

On Sep 5, 8:14 am, Hyman Rosen <hyro...@mail.com> wrote:

> By the way, C++ made the design mistake of allowing && and
> || to be overloaded, whereupon they lose their short-circuit
> behavior and become normal evaluate-both-operands functions.
> Just awful.

Hey, at least they haven't allowed the "if" and "while" keywords to be
overloaded.  Yet.  Maybe they'll find a way to overload the curly
braces too.

                                 -- Adam

Re: and then... (a curiosity)

[Hyman Rosen]

Adam Beneschan wrote:
> Hey, at least they haven't allowed the "if" and "while"
 > keywords to be overloaded.

I take it you haven't seen some of the most fancy expression
template code, then? :-)

Re: and then... (a curiosity)

[Gautier]

stefan-lucks@see-the.signature:

 > I think, there are three options:
 >
 > 1. Differentiate between the control flow "and", and the Boolean 
function
 >    "and". The first has the shortcut property, the second doesn't.
 >
 > (This is the worst option, but it would be the easy one.)

The worst of the three maybe, but not the worst possible ;-). For 
instance Delphi does it a lot worse (really difficult to beat):

http://www.delphibasics.co.uk/RTL.asp?Name=$B

Cheers
_________________________________________________________
Gautier's Ada programming -- http://sf.net/users/gdemont/

NB: For a direct answer, e-mail address on the Web site!

Re: and then... (a curiosity)

[stefan-lucks]

On Fri, 5 Sep 2008, Robert A Duff wrote:

> stefan-lucks@see-the.signature writes:
> 
> > 3. I would be willing to pragmatically sacrifice mathematical purity for a 
> >    shortcut rule: If A is false, the expression is false, whatever B does. 
> >    If A raises an exception, of if A is true and B raises an exception, 
> >    the exception is propagated.
> 
> Some more questions about 3.

Interesting questions! 

I like to point out, that I don't actually *propose* something, I just 
share some unfinished ideas. 

> Do you want to say that "and" is not a function (just like "and then" is
> not a function)?  

Not quite!

> So you can't pass "and" as a generic formal parameter, pass it as a 
> downward closure to an iterator, or rename it?

I think, there are three options:

1. Differentiate between the control flow "and", and the Boolean function 
   "and". The first has the shortcut property, the second doesn't. 

(This is the worst option, but it would be the easy one.)

2. Define the function "and" to operate over a type "Universal_Boolean", 
   similarly to what Dmitry suggested in another posting.

3. Extend the syntax of Ada subprograms to allow teh specification of 
   parameters in lazy evaluation mode. E.g., the function "and" could be 
   specified as follows:
      "function and(A: in Boolean; B: lazy in Boolean) return Boolean;
   Note that A is in eager mode, B in lazy mode. 

My preferred option would be 3., followed by 2. One reason is that I would 
like to have lazy evaluation in Ada, anyway. 

> Or are you saying that if "and" is passed to a generic formal function
> called Mumble, then Mumble gets this special property (of not evaluating
> its second argument in some cases)?

Assuming lazy evaluation in Ada, this would not be a "special property". 
And to pass the shortcut "and" to "Mumble", the first parameter of 
"mumble" must be of mode (eager) in, the second of mode lazy in. So there 
would be no surprise to the programmer.

> Do you want that "and" on array-of-Boolean is no longer defined in terms
> of "and" on each component pair?  (There's no such thing as "and then"
> on arrays.)  Same question for modular "and".  Or maybe just eliminate
> these other "and" operators?

For heaven's sake, no! 

> Do believe that "0 * F(X)" should return 0, even if F raises
> an exception?  Must return 0, or might return 0?

Good question! Given lazy evaluation, we *could* implement "*" that way. 
But the exception could imply that F(X) is infinite, and "0*infinite" is 
undefined. So I don't think we *should* implement "*" that way. Except, 
perhaps, modular types. 

> I'm just trying to explore the consequences of this seemingly-simple
> language design choice.  It doesn't seem so simple to me.

As I wrote before, I wouldn't even think of proposing such things without 
having a plausible idea how to implement such stuff.

-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: and then... (a curiosity)

[stefan-lucks]

On Fri, 5 Sep 2008, Dmitry A. Kazakov wrote:

> On Fri, 05 Sep 2008 10:14:47 -0400, Robert A Duff wrote:
>  
> > Some more questions about 3.
> 
> (The proposal is, as I understood it, IMO workable, but it potentially has
> a heavy overhead and it does not solve the problem. It is not the
> mathematical interpretation of "and", and its semantics is not better than
> one of "and then". Further IMO the problem lies elsewhere. Nevertheless, I
> will take the liberty of explaining the semantics, and consequences)

Once again, I didn't actually *propose* anything. But you described some 
ideas I had very well, Dmitry, thank you. 

> No, all arguments are eagerly evaluated. It is simply so that exception
> becomes a legal value of "Universal_Boolean". The exception is raised when
> such value is converted to Boolean in the context where a Boolean is
> expected. Like in "if". But "and", "or", "xor", "not" operate on
> "Universal_Boolean".

I would consider both the option of introducing lazy evaluation (not as a 
special "compiler magic" thing only for "and", but in general), or 
extending the type Boolean, as described by you.

> (I hope Stefan will correct me if I misinterpreted his proposal)

No problem! You expressed one of the ideas I had in my mind better than I 
would have done it myself. But once again, I didn't make a proposal. I 
just shared some thoughts about the non-shortcut-and (and -or) in "if" 
expressions, which in my experience is a common error-pattern in Ada. 
(Other languages have more and worse traps than Ada, but nevertheless ...)



-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------