1. Comparing Sequences
- Posted by Lewis Townsend <keroltarr at HOTMAIL.COM>
Oct 06, 2000
-
Last edited Oct 07, 2000
Hello David, Rob, others interested...
>[ The Problem ]
>
>Euphoria allows logical and comparison binary operators to return
>sequences.
David, I am sorry to have to cast yet another vote AGAINST your
idea. I will explain. I am another person that LIKES the fact
that ALL operators work on sequences. I use '=' on sequences
rather often and not just for graphics. I also DISAGREE that
using the '=' to make a transparency effect in an image should
be considered a "trick". I considder it as legitamite as
normal boolean math. But, to get off that subject, I want to
make as suggestion that could easily and sensibly (IMO) resolve
the issue. In fact it is so simple that I'm surprised it hasn't
been suggested by someone selse:
Don't change how the operators work, change how the conditional
statements work. If conditional statements could handle
sequences as boolean values, instead of breaking code it would
allow new code to work. For example:
if "Hello" = "Help!" then
which becomes
if {1,1,1,0,0} then
which becomes
if (1 or 1 or 1 or 0 or 0) then -- notice "or" instead of "and"
which becomes
if 0 then
It makes sense to me. I know there would be a few kinks to work
out of the concept like what if we compare sequences of different
length? But I think that should obviously return false rather
than error out. Also what if we try to use complex sequences?
I think this would have to be Rob's call (not that the rest isn't).
Should only 1 dimensional sequences be allowed in comparisons?
That way we still have a use for equal(). Or should conditional statements
go as far as to always work even if the structure is
different by simply returning zero? And what about this:
if {} = {} then
which becomes
if {} then
Should an empty sequence evaluate to true or false? considdering
the original statement, I would say "true" but what does everyone
else think.
I like this idea, probably because it's my own, but it makes a
lot of sense to me. Sure there will be a few special cases like
the above that would need some deeper discussion to resolve but
I still think it would be MUCH prefered to changing the way that
comparison operators work!
later,
Lewis Townsend
. __ _____ __ __ __ __ _____
. /\ \ /\ \|\ \ /\ \ /\ \ /\ \ /\ \
. / \_\ / \____\ \_\/ \_\/ \_\/ \_\/ \____\
. / / / / / ___/ | | / | / / / /\ / __ \
. / / / / / /_\ | | | / | / / / /\_\/ /_ \/
./ / /\ / / ___/ | | |/ | / / / /\ \ \__ \
.\ / /__\\ / /__\ \ | /| |/ /\ / / \/\_\/ /
. \/_____/ \/_____/ \|___/\|___/ \/_/ \_____/
keroltarr at hotmail.com http://geocities.com/keroltarr/
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
2. Re: Comparing Sequences
- Posted by Irv <irv at ELLIJAY.COM>
Oct 06, 2000
-
Last edited Oct 07, 2000
On Fri, 06 Oct 2000, Lewis Townsend wrote:
> Hello David, Rob, others interested...
>
>
> >[ The Problem ]
> >
> >Euphoria allows logical and comparison binary operators to return
> >sequences.
>
> David, I am sorry to have to cast yet another vote AGAINST your
> idea. I will explain. I am another person that LIKES the fact
> that ALL operators work on sequences. I use '=' on sequences
> rather often and not just for graphics....
>But, to get off that subject, Iwant to
> make as suggestion that could easily and sensibly (IMO) resolve
> the issue. In fact it is so simple that I'm surprised it hasn't
> been suggested by someone selse:
>
> Don't change how the operators work, change how the conditional
> statements work. If conditional statements could handle
> sequences as boolean values, instead of breaking code it would
> allow new code to work. For example:
>
> if "Hello" = "Help!" then
>
> which becomes
>
> if {1,1,1,0,0} then
>
> which becomes
>
> if (1 or 1 or 1 or 0 or 0) then -- notice "or" instead of "and"
>
> which becomes
>
> if 0 then
>
>
> It makes sense to me. I know there would be a few kinks to work
> out of the concept like what if we compare sequences of different
> length? But I think that should obviously return false rather
> than error out.
This all makes perfect sense (I think I've seen something similar suggested
previously).
Rob keeps talking about "orthogonality", yet this is an example
(one of many) where Euphoria's instruction set is currently
anything BUT orthogonal.
"IF" is BOOLEAN, so you only get two choices TRUE | FALSE,
so why _can't_ Euphoria evaluate the truth or falsity of {1,1,1,1} just
as easily as it can evaluate 1 or 0? It really doesn't matter how many
ones or zeros there are, does it? No matter how many there are, if all
of them are 1, then it's true, else it's false.
Having a program abort because Euphoria can't figure out if "Bill" = "Bill"
is one of the most frustrating features* of the language, and one that could
have been so easily avoided.
Irv
*as Microsoft uses the word
3. Re: Comparing Sequences
- Posted by David Cuny <dcuny at LANSET.COM>
Oct 06, 2000
-
Last edited Oct 07, 2000
Lewis Townsend wrote:
> I use '=' on sequences rather often and
> not just for graphics.
With all these warnings that lots of code would break, I decided to take an
entirely unscientific sampling of some Euphoria code. First, since you said
you use '=' on sequence "rather often", I decided to take a look at your
submissions to see what I was missing:
BALEN
FNS
LAGUI
LEWISART
LOOP
Of these, the construct occurs twice. In BALEN/GAMES.E/make_screen:
dude2 = (dude = 0)
this appears to build a mask of a bitmap. In FNS/FNS.EX/fall:
s = rand (2)
i = (((s=1) * -1) + (s=2))
which appears to intialize a sequence to random values.
Slightly emboldened, I took a look at include files that come with Euphoria:
DLL.E
FILE.E
GET.E
GRAPHICS.E
IMAGE.E
MACHINE.E
MISC.E
MOUSE.E
MSGBOX.E
SAFE.E
SORT.E
WILDCARD.E
Of these, the idom only appears in WILDCARD.E, in lower and upper. Robert
has already submitted these as an example of the '=' operation on sequences:
-- wildcard.e
global function lower(object x)
-- convert atom or sequence to lower case
return x + (x >= 'A' and x <= 'Z') * TO_LOWER
end function
global function upper(object x)
-- convert atom or sequence to upper case
return x - (x >= 'a' and x <= 'z') * TO_LOWER
end function
I agree with Robert's conclusion that code would break if he implemented my
suggestions. However, after looking through the code, I'm now even less
convinced that using '=' on sequences is a significant idiom in Euphoria.
-- David Cuny
4. Re: Comparing Sequences
This discussion is heading in an interesting direction. I don't really
have much to comment on this issue simply because I doubt it would affect
much, if any of my code (and I would suspect that the previous lack of
comments on the subject would be due to this very reason). I'm one of
those people who do things 'according to spec'. But looking at the
arguments, I'd have to lean more towards David's side of the issue. But
what do I know...
The real purpose of this reply is to get clarification on the following:
On Fri, 6 Oct 2000 20:21:48 CDT, Lewis Townsend wrote:
>Don't change how the operators work, change how the conditional
>statements work. If conditional statements could handle
>sequences as boolean values, instead of breaking code it would
>allow new code to work. For example:
>
>if "Hello" = "Help!" then
>
>which becomes
>
>if {1,1,1,0,0} then
>
>which becomes
>
>if (1 or 1 or 1 or 0 or 0) then -- notice "or" instead of "and"
>
>which becomes
>
>if 0 then
While there is a point made to emphasize 'or' instead of 'and', somehow the
result of (1 or 1 or 1 or 0 or 0) is 0. Doesn't (1 OR whatever) get 'short
circuited' to 1? Did I miss something in the argument or is Lewis
suggesting we redefine logic?
-- Brian
5. Re: Comparing Sequences
To Derek (and others):
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.
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.
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.
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.
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.
--Al
ps. i should be posting a math library soon that has many more examples.
6. Comparing Sequences
Rob,
I feel that your last remark to David Cuny was inappropriate--an attack on
the person rather than a dispute about ideas.
In terms of the substance of the dispute, I rather like Derek's suggestion
to silently transmute comparison operators to calls to compare() when used
on sequences in if and while statements. This would be a special rule,
admittedly--but would be symmetric to the special short-circuiting rule. No
existing code would be broken, but an alternative syntax that many users
prefer would become available. I don't know if I'd want to go along with
Derek's suggestions for further change down the line, but I wouldn't mind if
if "Help" = "Help" then
were legal Eu syntax. Also I would like to see greater() and less() to go
along with equal().
-- Mike Nelson
7. 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
8. Re: Comparing Sequences
Hello all,
Brian wrote:
>The real purpose of this reply is to get clarification on the following:
>
>On Fri, 6 Oct 2000 20:21:48 CDT, Lewis Townsend wrote:
>
> >Don't change how the operators work, change how the conditional
> >statements work. If conditional statements could handle
> >sequences as boolean values, instead of breaking code it would
> >allow new code to work. For example:
> >
> >if "Hello" = "Help!" then
> >
> >which becomes
> >
> >if {1,1,1,0,0} then
> >
> >which becomes
> >
> >if (1 or 1 or 1 or 0 or 0) then -- notice "or" instead of "and"
> >
> >which becomes
> >
> >if 0 then
>
>While there is a point made to emphasize 'or' instead of 'and', somehow the
>result of (1 or 1 or 1 or 0 or 0) is 0. Doesn't (1 OR whatever) get 'short
>circuited' to 1? Did I miss something in the argument or is Lewis
>suggesting we redefine logic?
>
>-- Brian
Sorry folks, my bad. I of course meant "AND" instead of
"OR". I was so focused on getting it right that I got it
wrong! :( Just in case my mistake caused anyone to
completely misunderstand what I was suggesting, here is a
revised and hopefully acurate version:
Conditional statements should accept objects (that's both
atoms and sequences). A TRUE sequence would be defined
as a sequence in which all atoms are TRUE atoms (non zero).
Empty sequences {} or sequences without any atoms at any
level would be TRUE. This is to make the case: {} = {}
return true as it logically should. However I wonder about
1 = {} and similar expressions. Perhaps special code could
be used to anylize these special conditions such as using
compare(). The ONLY FALSE sequence would be a sequence in
which there is a ZERO.
Since a conditional expression can return a sequence why
shouldn't sequences be allowed in conditional expressions?
I hope this clarifies my stand on the issue.
later,
Lewis Townsend.
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
