Re: Comparing Sequences
Hi Al,
> Derek wrote:
> >>
> For example...
>
> function tester(atom X, atom Y)
> return (functionOne(X) = functionTwo(Y))
> end function
>
> There is no way you can tell if this function returns an atom or a
sequence,
> unless you find out what functionOne() and functionTwo() return.
>
> Is this a problem? Maybe, maybe not. Just thought I'd mention it though.
> <<
>
> I've noticed this a long time ago, but it isnt an issue of comparison.
You're correct, it isn't a comparison issue. What I should have made more
clear was that, because of the use of comparison operators, it looks like a
comparison issue, but it isn't. That's the problem here as I see it.
In other words, any Euphoria text fragment that has the form
<EXPRESSION> <COMPOP> <EXPRESSION>
*looks* like a boolean comparision operation whose intent is to return a
truth value, but what actually happens depends on the datatypes on the
expressions involved.
> For example, take the same function 'tester' and simplify it:
>
> function tester(atom X)
> return functionOne(X)
> end function
>
> and still cant tell what tester() returns.
> I wont go as far as to say its a problem though, as it does allow one
> to return 'objects', a 'feature' i wouldnt want to go without.
Very true. I do not see this as a problem, because there is nothing in the
text that hints or alludes to a particular expection.
> Second point:
> Some functions are better off with the ability to return an object,
> rather then a particular sub type (atom, sequence).
> For example:
>
> --Sqrt(object a) is a function that returns the sqrt of a number with
> -- real or complex result
>
> object x,a
>
> a=4
> x=Sqrt(a) --returns 2
>
> a= -4
> x=Sqrt(a) --returns {0,2}
>
> a={-3,4)
> x=Sqrt(a) --returns {1,2}
>
> Here the return value depends on the users input and has to be
> an atom or a sequence. Thats one reason why i like to be able to
> retain the ability to return objects. I think this is an advanced
> feature of the language. True you could default to all sequences,
> but i think then that would over-complicate the calculations on
> simple numbers.
I agree totally. Euphoria's typeless returns are a godsend. I love them.
They must be retained in the language.
The point I made was more dealing with meeting reader's expectations of what
code will do. For example,
function abc()
atom aBigInteger
aBigInteger = AnotherFunction() + 1
return aBigInteger
end function
At first glance, you could be excused for thinking that the abc() function
returns a very large integer value. This is because atoms are required to do
that and the name of the variable suggests that. But there is nothing to
stop it returning 0.0003333 . Its just a matter of letting the text of
program code build an accurate expectation in the minds of its readers.
I believe that comparison operators normally imply a truth value, such that
"X > Y" will either tell you that X is greater than Y or that X is not
greater than Y. I believe the text of this fragment does not prepare the
reader to expect that instead of a truth value, a sequence containing
multiple truth values is returned. There are no hints in the text fragment
to allow this.
I'm sure that we could all find examples of code fragments that also behave
differently than one would normally expect upon a simple first-reading. All
I'm asking is "is that a good thing?"
(There is a classic example in either one of Steve McGuire's or Steve
McConnells' books in which a programmer was told that literals were
forbidden. So they wrote code like ...
#define ONE 1
#define TWO 2
#define HUNDRED 99
#define THOUSAND 1000
. . .
lpBuffer = malloc( TWO * HUNDRED) /* Allocate a 200 byte buffer */
and it took people ages to find the bugs because they'd read one thing, but
the program was doing something else.)
> BTW im in favor of extending the syntax to allow comparisons on
> sequences as well i.e.
>
> "Thisa"="Thata" returns false
> "Thisa"=This" returns false
> "This"="" returns false
> ""="" returns true
> {"This","That"}={"This"} returns false
> "A"={65} returns true
> 'A'={65} returns false
> "AB"={65,66} returns true
>
> etc.
Now that you mention it, this is not a bad idea 
> although i would like to see the double equal sign come in like other
> languages:
>
> if "This"=="That" then
> dosomething()
> end if
>
> making comparisons stand out from assignments a bit more.
>
The overloading of the "=" symbol to mean assignment and equality is a small
bother. Fortunately in Euphoria the interpreter catches these, because an
assignment is not an expression in Euphoria. In 'C' and its ilk, assignments
are expressions so ...
X = (Y = Z)
sets X to the value of Z (after first setting Y to Z too), but
X = (Y == Z)
sets X to a truth value after comparing Y and Z for equality.
I've never got used to 'C's double equals sign. I'm forever forgetting to do
it. I did however find no trouble with Pascal's (Delphi and PL/I) := symbol
for assignment. I can't see Robert changing Euphoria's assignment and
equality symbols though.
----
cheers
Derek
|
Not Categorized, Please Help
|
|
