and then... (a curiosity)

> > 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! ------

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.

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

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

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

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

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

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.

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

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? :-)