Re: RFC: Breaking existing Euphoria functionality
Alexander Toresson wrote:
>
> 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:
>
> }}}
<eucode>
>
> 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
>
> </eucode>
{{{
>
> 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
I have at least one issue with this approach:
function f()
sequence a,b
a="fao" b="bar"
return a=b
end function
Should the return value be 0 or {0,1,0}? No way to know since the return type
of a function is not defined. And looking fo the mode of the temp or var
that will get that value won't help often.
So let's just do this:
* don't change the way things are evaluated;
* if a sequence comes out as the "value" of an if/while statement,
convert it to 1 if it has no zeroes inside, else to 0. That would be done
at runtime, and only replaces the code that currently throws a fatal error.
The conversion would take place inside if/while condition clauses, but
nowhere else, just like short-circuit evaluation.
CChris
As an aside for Pete: in Eu, there are already pieces of code which do not
behave the same according to context, namely all those, part of which can
be short-circuited. It's just that the difference would increase.
|
Not Categorized, Please Help
|
|
