Re: Strings and the like.
Gabriel Boehme wrote:
>Everett Williams wrote:
>
>>Basic rules of logic require a different kind of consistency...that of the
>>statement as it stands. The relational statement
>>
>> s = floor(s)
>>
>>has "a" truth value.
>
>AH!!! I get it, you mean you want to do this!
>
>if equal(s, floor(s)) then...
>
>equal() always returns 1 (true) or 0 (false), reflecting the overall
>equality of the two values. Using equal() instead of = is analogous to using
>compare() instead of >, <, >=, <=, !=, or =. The operators act recursively
>upon objects, "diving in" to compare them in detail, while the equal() and
>compare() functions only deal with the surface value of an object, treating
>it as "flat" and merely reflecting their overall equality/inequality. (I
>don't know much technical computer terminology, so I hope this is all making
>sense!) 
Your definitions fit the language as presented and as I have now finally
picked up on...except for compare. Compare is not a logical function by
the definition of logic that we have. It represents a ternary or triple valued
logic. It can be used with short circuiting to swiftly get to a binary form.
>
>>The greater question, though,
>>is still the one asked by the following line. Is the sequence represented
>by s
>>equal to the sequence represented by the result of floor(s)? The "if"
>>statement shows this in it's purest form. "If" statements store no values,
>>but act on a single logical value that is the result of relational and
>logical
>>operators. What we are doing in Euphoria is ignoring the global result in
>>favor of the interim results.
>
>Ah, NOW I see what you're getting at. You're operating under the assumption
>that any expression contained within an "if" statement (and also,
>presumably, within a "while" statement as well) should always evaluate to an
>atomic TRUE or FALSE value. This is not the case, although I think I can see
>where you might be getting the idea that it should be.
It may not be the case, but it should be.
>Before Euphoria v2.1, expressions in "if" and "while" statements were
>treated no differently than expressions used anywhere else in a program.
>Thus, you could always expect logical expressions within "if" statements to
>execute identically to logical expressions anywhere else (like on a "return"
>statement). However, since v2.1 and the implementation of short-circuit
>evaluation, expressions are now handled slightly differently when they're in
>"if" or "while" statements. While this change made excellent practical sense
>(IMHO), it did nevertheless create a precedent for treating "if" and "while"
>expressions differently from other expressions. Nevertheless, the current
>differences arise only in the handling of the "and"/"or" operators; the
>other expression evaluation rules remain the same.
All true and interesting, but not relevant other than in the fact of the
existence
of special handling. And I am not against short-circuiting. It's convenience
outweighs any minor inconsistency.
>So, although I can see where you *may* have gotten your idea from, I still
>do not agree that we need to force all "if" and "while" statements to
>evaluate all expressions as simply TRUE or FALSE. For one thing, this could
>allow errors to slip through (at least, "if" expressions which evaluate to
>sequences are errors in *my* programs...), and we already have equal() and
>compare() for higher-level comparisons anyway.
"If" expressions need not and should not evaluate to sequences. Consecutive
"and" ing of results solves this problem and provides short-circuiting to boot.
The only other proper result of such a comparison is invalid...apples and
oranges, sequence and atom, etc.
>I hope this addresses your concerns more directly.
At last some meat and potatoes. I NOW see the equal function. Somehow,
I had missed it previously. I still don't see the need for it. The highest level
comparison is the natural one, all others should be handled either implicitly
or by function where functions return values. In the syllogism, logic is
binary. The equal sign means equivalence. It does not deal with values.
It deals with the path to be followed. It is a switch set by the values on
either side of it. There is no problem when a function returns multiple
values in a sequence. That is consistency. The equal sign as assignment
operator deals with values. It creates no inconsistency when it allows
multiple values to be assigned. When multiple values are returned by
an equivalence that "can" have and demands a single value, consistency is
not served. It is not difficult for the interpreter to distinguish situations
where a single value is required. There is no inconsistency or programmatic
problem when comparing any two values or sets of values in a structure as
long as both the structure and the values are equivalent. But, they are
either equal or unequal, true or false, then or else.
Everett L.(Rett) Williams
rett at gvtc.com
|
Not Categorized, Please Help
|
|
