1. Re: type string
- Posted by Daniel Berstein <daber at PAIR.COM>
Mar 11, 1999
-
Last edited Mar 12, 1999
At 05:18 PM 11-03-1999 , you wrote:
>Daniel Berstein <daber at PAIR.COM> wrote
>
>>I tried with a direct return statement, but short-circuit evaluation only
>>works for if and while statements. I understand that short-circuit may
>>render unwanted results for general purpose boolean operations, but in the
>>context of a type declaration, where only true/false values can be returned
>>(same case as if and while) there could be a way to override the default
>>behaviour. [snip]
>
>You're forgetting the possibility of recursive type declarations. The end
>result of the type should be a boolean value, this is true. But if a type is
>recursively calling itself, it *may* wish to return a sequence of boolean
>values to itself. (I can't currently think of any examples, but I'm assuming
I can't think of an example either ;)
>there are situations where this would be handy.) Euphoria can't just
>"assume" we always want short-circuit evaluation for our type-function
>return statements.
>Besides, if return statements worked differently for types than they did for
>functions, how much confusion do you think *that* would cause? Would a
>type's return statement have to work differently when called as a function,
>as opposed to being called internally as part of a type-check? I'd love to
>have short-circuit evaluation for type return statements, but I don't see a
>way of doing it that wouldn't create more confusion than it would solve.
Oh yes! Thats why I suggested with/with short_circuit or special
short_circuit logical operator. I would like to be able to disable at will
short-circuit evaluation on if/while statements as well.
In fact the current way short circuit evaluation is implemented is a bit
confusing. The same expresion executes different depending on it's context.
I love short-circuit (we had to "lobby" Rob to obtain it!), but more
control would be nicer.
Regards,
Daniel Berstein
[daber at pair.com]
