Re: and then... (a curiosity)

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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