1. justifying compare
Here's a question for Robert:
Can you get rid of the 'compare' statement from Euphoria? If not, why?
Having used Euphoria for some time now, I've gotten used to *most* of it's
quirks, and even grown to love them.
The 'compare' statement is not one of them. If there is an error in my code,
odds are that I've written:
if compare( foo, bar ) then
instead of:
if compare( foo, bar ) = 0 then
The 'compare' seems to be the major stumbling block for beginners. It
certainly was for me.
The *only* justification I can find for it is that it forces the user to
optimize comparisons of sequence elements. For example, Euphoria does not
know what data type is associated with:
s[1]
because sequences can contain any arbitrary mix of data types. But if the
user types:
if s[1] > 2 then
then they have implicitly cast s[1] as a numeric data type, and the
expression can be optimized to a simple numeric comparison. On the other
hand,
if compare( s[1], 2 ) > 0 then
implies that a more expensive comparison routine must be called. What other
reason could there be for the existance of 'compare'? It seems it would make
like much easier just to be able to write:
if s[1] > 2 then
and have the *interpreter* take care of the details, converting the code
into:
if compare( s[1], 2 ) > 0 then
behind our backs.
But even with the explanation that using 'compare' to differentiate numeric
comparisons from complex sequence comparisons, Euphoria *still* does some
sort of type check on the data type before performing the following
comparison:
s[1] = "foo"
if s[1] > 2 then
I would imagine that, instead of branching to an error statement, the
compiler could just as easily branch to a 'compare' type subroutine.
Is there a compelling reason for Euphoria to use the 'compare' statement?
-- David Cuny
2. Re: justifying compare
On Fri, 6 Nov 1998 00:57:34 -0800, David Cuny <dcuny at LANSET.COM> wrote:
>Here's a question for Robert:
>
>Can you get rid of the 'compare' statement from Euphoria? If not, why?
>...
>The 'compare' seems to be the major stumbling block for beginners. It
>certainly was for me.
>...
I concur wholeheartedly.
>Is there a compelling reason for Euphoria to use the 'compare' statement?
In a similar vein, the other big stumbling block is getting input
from the keyboard. Specifically the linefeed that has to be removed,
and perhaps the SUCCESS flag. Neither are needed or meaningful if
the source of the input is device 0.
Maybe I've missed something here?
Irv
3. Re: justifying compare
On Fri, 6 Nov 1998, Irv Mullins wrote:
> On Fri, 6 Nov 1998 00:57:34 -0800, David Cuny <dcuny at LANSET.COM> wrote:
>
> >Here's a question for Robert:
> >
> >Can you get rid of the 'compare' statement from Euphoria? If not, why?
> >...
> >The 'compare' seems to be the major stumbling block for beginners. It
> >certainly was for me.
> >...
> I concur wholeheartedly.
Yeah, but English (wonderful language) has its idiosyncracies too. "Cough"
and "Bough" for instance. Bad spellers use "alot" to mean "a lot".
Are you suggesting we get rid of the major stumbling blocks in English
too? :| :)
Soh wee get rid ov ze stumbling blox and looz alot ov comprihensibiliti.
Not gud orr priti iz it? :)
> >Is there a compelling reason for Euphoria to use the 'compare' statement?
>
> In a similar vein, the other big stumbling block is getting input
> from the keyboard. Specifically the linefeed that has to be removed,
> and perhaps the SUCCESS flag. Neither are needed or meaningful if
> the source of the input is device 0.
> Maybe I've missed something here?
Word processors allow bad spelling, so maybe we should allow [within
reason] some form of bad coding.
Maybe someone could write a "beginner.e" for all early coders to use.
I'll even start it off:
include get.e
global type char(integer x)
return x >= 0 and x <= 255
end type
global type string(sequence x)
for i = 1 to length(x)
if not char(x[i]) then
return 0
end if
end for
end type
global function equal(object a, object b)
return compare({a},{b})=0
end function
global function input(object of_output_type, string prompt)
-- Usage: o1 = input(o1, s)
object out
out = gets(0)
out = out[1..length(out)-1]
if string(of_output_type) then
return out
else
out = value(out)
out = out[2] -- Assumes 0 on GET_FAIL
if integer(of_output_type) then
return floor(out)
else--atom *or* sequence!
return out
end if
-- use the if-statement so that it functions correctly if someone
-- [mis]uses input() like this: a1 = input(i1, s)
end if
end function
global procedure put(object a)
if string(a) then
puts(1, a)
elsif sequence(a) then
print(1, a)
elsif integer(a) then
printf(1, "%d", {a})
else--if atom(a) then
printf(1, "%1.12g, {a})
end if
end procedure
global procedure put_line(object a)
put(a)
puts(1, "\n")
end procedure
--
Carl R White -- Final Year Computer Science at the University of Bradford
E-mail...: cyrek- at -bigfoot.com -- Remove the hyphens before mailing. Ta :)
URL......: http://www.bigfoot.com/~cyrek/
Ykk rnyllaqur rgiokc cea nyemdok ymc giququezka caysgr -- B.Q.Vgesa
4. Re: justifying compare
>
Carl R White wrote ...
>
>Maybe someone could write a "beginner.e" for all early coders to use.
>
>I'll even start it off:
>
>include get.e
>
>global type char(integer x)
> return x >= 0 and x <= 255
>end type
>
<etcetera>
IMHO, as a professional software engineer, adding things like this to
*all* programs is a good idea ( even if it does seem a little childish /
unnecessary to some ). Just because we're professionals and know every
trick in the book doesn't mean that we don't make the obvious mistakes
which bits of code like this help us catch quickly.
The whole idea of putting things like this in 'typedef.e', string
manipulations 'left(), 'ltrim()' in 'strings.e' and so on is just sound
programming technique - Something that Euphoria provides excellent
support for.
5. Re: justifying compare
On Fri, 6 Nov 1998 15:09:51 +0000, Carl R. White <C.R.White at SCM.BRAD.AC.UK>
wrote:
>Yeah, but English (wonderful language) has its idiosyncracies too. "Cough"
>and "Bough" for instance. Bad spellers use "alot" to mean "a lot".
>Are you suggesting we get rid of the major stumbling blocks in English
>too? :| :)
>
>Soh wee get rid ov ze stumbling blox and looz alot ov comprihensibiliti.
>Not gud orr priti iz it? :)
Seams lyk a vewy vewy good idear, too mee.
....
>Word processors allow bad spelling, so maybe we should allow [within
>reason] some form of bad coding.
>
>Maybe someone could write a "beginner.e" for all early coders to use.
....
Good idea. We wind up writing some of these routines into every
program anyway.
Irv
6. Re: justifying compare
[I'm re-posting this directly from the Web because MSN's outbound mail
is broken again (Friday afternoons!). You'll probably see this
message again in a few hours/days/weeks?]
David Cuny writes:
> Can you get rid of the 'compare' statement from Euphoria? If not, why?
> Having used Euphoria for some time now, I've gotten used to *most*
> of it's quirks, and even grown to love them.
> The 'compare' statement is not one of them. If there is an error in
> my code, odds are that I've written:
> if compare( foo, bar ) then
> instead of:
> if compare( foo, bar ) = 0 then
I've done the same thing myself on occasion.
I've also done it in C with the strcmp() function which also
returns -1, 0 or +1.
How would you like an equal(a, b) function that returned
1 (true) when arbitrary objects a and b are equal, and 0 (false)
otherwise? e.g.
if equal(foo, bar) then
It would be a new built-in function like compare()
and would take the same amount of time to execute (it would
execute essentially the same code internally). By the way,
things are currently optimized so the extra = 0 after compare()
costs nothing.
For the time being, Carl R. White writes:
> global function equal(object a, object b)
> return compare({a},{b})=0
> end function
There's no need for the braces. Why not simply...
global function equal(object a, object b)
return compare(a,b)=0
end function
compare() will compare *any* object against any other.
with all atoms considered "less than" all sequences.
equal() would compare any object against any other for equality.
The redundancy is probably justified given the frequency with
which equal() would be used, and the error-prone nature
of compare(a,b) = 0.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
7. Re: justifying compare
Robert Craig offered:
> How would you like an equal(a, b) function that
> returned 1 (true) when arbitrary objects a and b
> are equal, and 0 (false)otherwise?
Yes, please! I very rarely do inequality tests with compare.
-- David Cuny
8. Re: justifying compare
David Cuny writes:
> Can you get rid of the 'compare' statement from Euphoria? If not, why?
> Having used Euphoria for some time now, I've gotten used to *most*
> of it's quirks, and even grown to love them.
> The 'compare' statement is not one of them. If there is an error in
> my code, odds are that I've written:
> if compare( foo, bar ) then
> instead of:
> if compare( foo, bar ) = 0 then
I've done the same thing myself on occasion.
I've also done it in C with the strcmp() function which also
returns -1, 0 or +1.
How would you like an equal(a, b) function that returned
1 (true) when arbitrary objects a and b are equal, and 0 (false)
otherwise? e.g.
if equal(foo, bar) then
It would be a new built-in function like compare()
and would take the same amount of time to execute (it would
execute essentially the same code internally). By the way,
things are currently optimized so the extra = 0 after compare()
costs nothing.
For the time being, Carl R. White writes:
> global function equal(object a, object b)
> return compare({a},{b})=0
> end function
There's no need for the braces. Why not simply...
global function equal(object a, object b)
return compare(a,b)=0
end function
compare() will compare *any* object against any other.
with all atoms considered "less than" all sequences.
equal() would compare any object against any other for equality.
The redundancy is probably justified given the frequency with
which equal() would be used, and the error-prone nature
of compare(a,b) = 0.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
9. Re: justifying compare
Hi Rob,
If you want you can add a link at the recent contributions page to the
Euphoria code editor I'm developing.
You can use a direct link:
or by the webpage:
Regards,
Daniel Berstein
daber at pair.com
