OpenEuphoria

Re: RFC: Breaking existing Euphoria functionality

• Posted by Alexander Toresson <alexander.toresson at gmail.com> Feb 24, 2007
• 571 views

Aku wrote:
> 
> I have a suggestion for this that will not break 
> existing code at all.
> 
> Instead of changing the behavior of comparison operators,
> why don't we just change the behavior of "if" ?
> 
> Normally only atoms are allowed for "if", 
> like if 1 then.. if 0 then.. if a = b then (where a, b are atoms),
> we change it to allow sequences.

I think there's a much more elegant and generic way of doing this than changing
the way 'if' statements work. Instead of changing how an 'if' statement works,
change how expressions with comparison operators work.

There's a problem with the approach with changing how 'if' statements work. What
if the comparison operator is not at the 'top' level, like if you had '(foo =
bar) and (baz = quux)'? Of course, we could assume this behaviour for all levels
in an expression in an 'if' statement, but there may very well be legitimate
cases where you should not. I'm too tired to come up with any right now, though.

Basically, if the result of a comparison between two objects or sequences would
need to be an atom or integer, make the operation return an integer instead.

Thus all of the following snippets would work:

sequence a, b
integer c
-- set the sequences
c = a = b
-- c is 1 if a and b are equal

sequence a, b, c
-- set the sequences
c = a = b
-- a and b are compared by element and a sequence is generated as result
-- and is put into c

sequence a, b, c, d
-- set the sequences
if (a = b) and (c = d) then
    -- do something if a and b and then c and d are equal
end if

Yes, this would require a way of knowing what type is expected as the result of
an expression. This can be done quite easy by representing an expression as a
tree in a sequence. I wouldn't be surprised if this is already done, as this
enables some other quite massive optimizations in the IL/C code that is emitted.

Regards, Alexander Toresson