Re: and then... (a curiosity)

[stefan-lucks@see-the.signature]

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