1. RFC: Breaking existing Euphoria functionality
Has anybody written a statement like this:
result = ({'a','b','c'} = {'a','b','f'})
and expected result to look like this:
? result
{1,1,0}?
Is there any code in the archives or recent user contributions (say less than
3 years old) that takes advantage of this functionality?
I would like to change binary_ops() in be_runtime.c so that the result of
comparing two sequences with an operator (=,<,>,<=,>=,!=) returns a single
boolean rather than a sequence of booleans. The benefit to this change
would allow sequences to be compared in an if or while statement without
requiring compare or equal. The drawback is breaking existing functionality.
I expect the performance hit to be negligible.
Michael J. Sabal
2. Re: RFC: Breaking existing Euphoria functionality
Michael J. Sabal wrote:
>
> Has anybody written a statement like this:
>
> result = ({'a','b','c'} = {'a','b','f'})
>
> and expected result to look like this:
>
> ? result
> {1,1,0}?
>
> Is there any code in the archives or recent user contributions (say less than
> 3 years old) that takes advantage of this functionality?
>
> I would like to change binary_ops() in be_runtime.c so that the result of
> comparing two sequences with an operator (=,<,>,<=,>=,!=) returns a single
> boolean rather than a sequence of booleans. The benefit to this change
> would allow sequences to be compared in an if or while statement without
> requiring compare or equal. The drawback is breaking existing functionality.
> I expect the performance hit to be negligible.
>
> Michael J. Sabal
Did you ever write
result= {1,2,3}+{4,5,6}
while expecting result holding anything else than {5,7,9}?
If you answer "no" to this question, then consider that, on my keyboard at
least, '+' and '=' are on the same key. Can anyone expect different behaviour
from two operators located on the same keyboard key?
It is possible that your proposed change wouldn't break much submitted code.
But it would certainly add confusion to the syntax of the language.
equal() and compare() perform what you appear to wish to do.
What could be desirable, in code that heavily uses string comparisons, could
be a new top level "without compare" statement that woul cause relational
operators to operate on strings as atomic objects instead of collections of
objects.
If there was an "extend to sequence" operator in Eu, then the change you
propose could be more palatable; {1,1,0} could be obtained by
result=(`{'a','b','c'}=`{'a','b','f'})
denoting by a backquote the extension operator. The [] suffix could be
pretty clear too.
CChris
3. Re: RFC: Breaking existing Euphoria functionality
Michael J. Sabal wrote:
> Has anybody written a statement like this:
> result = ({'a','b','c'} = {'a','b','f'})
> and expected result to look like this:
> ? result
> {1,1,0}?
Yes. But it was a long time ago and for something trivial.
> Is there any code in the archives or recent user contributions (say less than
> 3 years old) that takes advantage of this functionality?
My guess would be probably not. :)
If you change the existing behavior, will you still allow the prior behavior
through some function or other way?
4. Re: RFC: Breaking existing Euphoria functionality
- Posted by Pete Lomax <petelomax at blueyonder.co.uk>
Feb 22, 2007
-
Last edited Feb 23, 2007
Michael J. Sabal wrote:
> Is there any code in the archives or recent user contributions (say less
> than 3 years old) that takes advantage of this functionality?
>
> I would like to change binary_ops() in be_runtime.c so that the result of
> comparing two sequences with an operator (=,<,>,<=,>=,!=) returns a single
> boolean rather than a sequence of booleans.
I have previously analysed this in detail for a few programs:
win32lib contains some 18 instances of sequence ops (out of 45,000 lines of
code), 3 of which are relational ops.
arwen contains some 6 instances of sequence ops (out of 12,000 lines of code), 0
of which are relational ops.
Edita contains some 11 instances of sequence ops (out of 30,000 lines of code),
0 of which are relational ops.
wildcard.e, routines upper() and lower(), uses relational sequence ops.
Hence I can claim with some authority that sequence ops are used on average less
than once per 2000 lines of code, relational ops even less so.
Obviously it is a trivial matter to "fix" these once you know where they are (I
can supply detailed instructions on request, along with a set of replacement
functions).
I would strongly recommend changing the compiler to recognise such sequence ops
and issue errors, if you or anyone else want to make such a change.
I will add that is not possible in many cases, eg in upper()/lower() they act on
objects, whereas eg rect[1..2]+=rect[3..4] is clearly detectable.
Regards,
Pete
5. Re: RFC: Breaking existing Euphoria functionality
- Posted by Derek Parnell <ddparnell at bigpond.com>
Feb 22, 2007
-
Last edited Feb 23, 2007
Pete Lomax wrote:
>
> win32lib contains some 18 instances of sequence ops (out of 45,000 lines of
> code), 3 of which are relational ops.
>
Shock! I didn't think there were any left. Yes, can I have details about these
please. I will want to remove them I think.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
6. Re: RFC: Breaking existing Euphoria functionality
- Posted by Pete Lomax <petelomax at blueyonder.co.uk>
Feb 22, 2007
-
Last edited Feb 23, 2007
Derek Parnell wrote:
>
> Pete Lomax wrote:
> >
> > win32lib contains some 18 instances of sequence ops (out of 45,000 lines
> > of code), 3 of which are relational ops.
> >
>
> Shock! I didn't think there were any left. Yes, can I have details about
> these please. I will want to remove them I think.
I've just uploaded a copy of my (rough) notes, see
http://palacebuilders.pwp.blueyonder.co.uk/posmods.txt
The relational ops are in textToBitmap() and createMousePointer().
Regards,
Pete
7. Re: RFC: Breaking existing Euphoria functionality
- Posted by Andy Serpa <ac at onehorseshy.com>
Feb 22, 2007
-
Last edited Feb 23, 2007
Michael J. Sabal wrote:
>
> Has anybody written a statement like this:
>
> result = ({'a','b','c'} = {'a','b','f'})
>
> and expected result to look like this:
>
> ? result
> {1,1,0}?
>
> Is there any code in the archives or recent user contributions (say less than
> 3 years old) that takes advantage of this functionality?
>
I don't know about the user contributions, but I use this very Euphorian
capability ALL THE TIME. Changing it would break almost a very high percentage
of the Eu programs I've written over the years. Doing this kind of thing easily
is one of the top reasons I use Euphoria at all.
Don't break code, just add a new operator (== or whatever). I for one would
like to see a conditional operator for sequence operations...
8. Re: RFC: Breaking existing Euphoria functionality
- Posted by Derek Parnell <ddparnell at bigpond.com>
Feb 22, 2007
-
Last edited Feb 23, 2007
Michael J. Sabal wrote:
>
> Has anybody written a statement like this:
>
> result = ({'a','b','c'} = {'a','b','f'})
>
> and expected result to look like this:
>
> ? result
> {1,1,0}?
>
> Is there any code in the archives or recent user contributions (say less than
> 3 years old) that takes advantage of this functionality?
>
> I would like to change binary_ops() in be_runtime.c so that the result of
> comparing two sequences with an operator (=,<,>,<=,>=,!=) returns a single
> boolean rather than a sequence of booleans. The benefit to this change
> would allow sequences to be compared in an if or while statement without
> requiring compare or equal. The drawback is breaking existing functionality.
> I expect the performance hit to be negligible.
I don't see the need to do this though. The sequence operations are not a bad
thing to have, generally speaking. My issue is that conditional statements should
not be doing a sequence operation but a comparision operation instead. Thus ...
if XYZ < ABC then
should be viewed as a comparision and not a sequence operation.
However ...
DEF = (XYZ < ABC)
should be a sequence operation (then an assignment) because it is not in the
context of a conditional statement ('if', 'while' ...)
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
9. Re: RFC: Breaking existing Euphoria functionality
Derek Parnell wrote:
> However ...
>
> DEF = (XYZ < ABC)
>
> should be a sequence operation (then an assignment) because it is not in
> the context of a conditional statement ('if', 'while' ...)
FWIW, I am firmly in the "must be written as 'DEF = sq_lt(XYZ,ABC)'" camp.
While I would hate to see it left as-is, I would even more hate to see mods
which mean that:
if <expr> then
is nowt like:
x = <expr>
if x then
or:
f(<expr>)
The meaning of code should not be context-sensitive like this, imo.
Regards,
Pete
10. Re: RFC: Breaking existing Euphoria functionality
I wrote:
> The meaning of code should not be context-sensitive like this, imo.
Sorry, hit post too soon; I also wanted to say (/repeat) that once, to my shame,
I wrote a paragraph entitled "Atomic Coercion and Propagation in Expressions". It
was some nasty trash. In essence/hindsight this happens:
if (a=b)=(c=d) then
becomes ambiguous under any such scheme. To illustrate, let a=b="123"; and
c=d="1234", but True=True whereas {1,1,1}!={1,1,1,1}.
I will not argue over "preferred" meaning; both are valid. It is ambiguous.
Regards,
Pete
11. Re: RFC: Breaking existing Euphoria functionality
Derek Parnell wrote:
>
> if XYZ < ABC then
>
> should be viewed as a comparision and not a sequence operation.
>
> However ...
>
> DEF = (XYZ < ABC)
>
> should be a sequence operation (then an assignment) because it is not in the
> context of a conditional statement ('if', 'while' ...)
>
The source is currently written to evaluate the comparison first, regardless
of context, then execute the context. In order to do what you are suggesting,
the parser would need to assign separate opcodes (which do not currently
exist) for a comparison in if/while than for one in an assignment.
Based on yours and other comments in this thread, it seems the community is
rather opposed to this modification. Therefore, I am reducing your
feature request on Sourceforge to the bottom of the queue. Feel free to
take these notes and work out the solution on your own. Perhaps you'll be
able to see an elegant solution that pleases most where I cannot.
Michael J. Sabal
12. Re: RFC: Breaking existing Euphoria functionality
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.
Only if all the elements of the sequences are true,
the "then" part will be executed. Otherwise, the "else" part.
So we allow if {1, 1, 1} then ... as a result of if "abc"="abc"
and it will execute the "then" part.
OK I just realized it is not possible without changing one more thing
that is comparison of sequences of different length.
(we can't have "ab" = "abc")
Michael J. Sabal wrote:
>
> Has anybody written a statement like this:
>
> result = ({'a','b','c'} = {'a','b','f'})
>
> and expected result to look like this:
>
> ? result
> {1,1,0}?
>
> Is there any code in the archives or recent user contributions (say less than
> 3 years old) that takes advantage of this functionality?
>
> I would like to change binary_ops() in be_runtime.c so that the result of
> comparing two sequences with an operator (=,<,>,<=,>=,!=) returns a single
> boolean rather than a sequence of booleans. The benefit to this change
> would allow sequences to be compared in an if or while statement without
> requiring compare or equal. The drawback is breaking existing functionality.
> I expect the performance hit to be negligible.
>
> Michael J. Sabal
13. Re: RFC: Breaking existing Euphoria functionality
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.
>
> Only if all the elements of the sequences are true,
> the "then" part will be executed. Otherwise, the "else" part.
>
> So we allow if {1, 1, 1} then ... as a result of if "abc"="abc"
> and it will execute the "then" part.
>
> OK I just realized it is not possible without changing one more thing
> that is comparison of sequences of different length.
> (we can't have "ab" = "abc")
>
>
This is what I am trying to say. By the time the runtime library realizes
it has an "if", the comparison has ALREADY been evaluated. I started looking
at it and raised this thread because I thought it would be a simple matter
of changing how "if" works. After pouring through the source, I realized the
situation is far more complex than that.
Derek, this responds to your comment in SF as well.
In order to move from breaking existing code, (which is what the community
doesn't want, Derek. I wasn't talking about the feature itself) we need to
change the way parsing works, and somehow call a completely different
binary_op if a comparison is part of an if as opposed to an assignment. That
means new opcodes and new framework. You have proven that you are a much
better programmer than I am. The only reason I looked at it is because I had
half an hour to do so and didn't have my laptop containing my other projects;
and because there were so many complaints about all the feature requests that
nobody had looked at.
So here's what I suggest. My comments and change in priority code really
don't mean a thing. Download the source, show us how to make the changes
without breaking code, and your feature will probably be implemented. I am
not coder enough to do it, and I'm moving on to something else.
14. Re: RFC: Breaking existing Euphoria functionality
Michael J. Sabal wrote:
> Download the source, show us how to make the changes
> without breaking code, and your feature will probably be implemented.
I have absolute confidence that any change that I make will never be used by
Robert in any manner whatsoever. To prove that, I'll take up your challenge and
submit an updated version to Robert - not that you guys will ever see it
released, of course.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
15. Re: RFC: Breaking existing Euphoria functionality
Derek Parnell wrote:
>
> Michael J. Sabal wrote:
> > Download the source, show us how to make the changes
> > without breaking code, and your feature will probably be implemented.
>
> I have absolute confidence that any change that I make will never be used by
> Robert in any manner whatsoever. To prove that, I'll take up your challenge
> and submit an updated version to Robert - not that you guys will ever see it
> released, of course.
>
> --
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell
May I attempt to dissuade you from playing this game?
Do you remember how Rob fixed the forward routine_id "bug", in spite of
unanmous opposition and dismay from the list?
The lesson I drew from there is that, if RC thinks some mod is well done
enough for his standards, and not utterly incompatible with his view of
the language, he may support it, even if it adds a liability
to the language. And you are able to submit such a well tested mod.
So.... the end result may not be exactly what anyone wanted.
CChris
16. Re: RFC: Breaking existing Euphoria functionality
Aren't we really just talking about making an operator alias for the compare()
function? I mean, we CAN compare sequences in "if" statements now, correct?
This is all about not getting to type what you want to type? (i.e. I don't want
to type "compare(a,b)", I want to type "a < b" instead.)
So just make some new operators (that work in "if" statements and elsewhere too)
that only do comparisons -- add a colon prefix to them, for instance:
a := b equivalent to "compare(a,b) = 0"
a :< b equivalent to "compare(a,b) < 0"
a :> b equivalent to "compare(a,b) > 0"
a :<= b equivalent to "compare(a,b) <= 0"
a :>= b equivalent to "compare(a,b) >= 0"
17. Re: RFC: Breaking existing Euphoria functionality
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
18. Re: RFC: Breaking existing Euphoria functionality
- Posted by Andy Serpa <ac at onehorseshy.com>
Feb 24, 2007
-
Last edited Feb 25, 2007
Alexander Toresson wrote:
> 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.
>
This would be very confusing.
MAKE NEW COMPARISON OPERATORS. No confusion, no ambiguity, and they would be
useful outside of "if" statements as well. Problem solved, no?
People are acting as if the current scheme doesn't make sense or is
inconsistent, when it is not. You are trying to force a sequence into a place
where a boolean value is supposed to go, no different than if you sent invalid
input to a function...
19. Re: RFC: Breaking existing Euphoria functionality
Alexander Toresson wrote:
> 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.
NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!
> Thus all of the following snippets would work:
<snip>
> }}}
<eucode>
> if (a = b) and (c = d) then
> </eucode>
{{{
But I just gave this example:
if (a=b) = (c=d) then
You are stuffed. STUFFED. UP S**T CREEK WITHOUT A PADDLE.
You ask to make the middle "=" behave different to the outers.
What you said was the "middle" "=" must yield atom, but it is clear that neither
the "(a=b)" nor the "(c=d)" need to. Horrid. And ambiguous.
Give it up. Make "=" ALWAYS return an atom, and add "sq_eq()" for the rare
cases, or don't even try. KISS.
Let me be very clear on this: I really WANT "a=b" to ALWAYS return an atom.
I think that would be an excellent improvement to the language.
Making "a=b" SOMETIMES return a sequence, for the same a and b, is utter
madness, when "sq_eq(a,b)" is a much better way forward, for the rare cases that
need it.
YOU CANNOT DO THIS HALF-HEARTEDLY.
Regards,
Pete
PS Andy Serpa seems to say replace the operator inside if statements, which imao
is clearly wrong.
PPS Naturally no real care/claim for "sq_eq" over "eq", "EQ" or whatever.
20. Re: RFC: Breaking existing Euphoria functionality
Pete Lomax wrote:
> PS Andy Serpa seems to say replace the operator inside if statements, which
> imao is clearly wrong.
I am not suggesting changing the "if" statement at all, but to add new
comparison operators to the language (operators that always return a boolean, no
matter what is being compared, just equivalents for the compare() function as I
illustrated a few posts back), which can be used anywhere. I certainly don't
want to break code, or take away existing functionality. The ability to do "a =
b" (or "a < b" or "a * b", etc) with sequences and get a sequence back is at the
very core of the language -- the thing that makes it "Euphorian".
Most of these suggestions seem madness to me -- it seems people are desperate
for some reason to do this:
if a < b then...
when a and b are sequences. I'm suggesting we do this:
if a :< b then...
which would be equivalent to:
if compare(a,b) < 0 then...
What could be simpler? And the new operators could be used outside of "if"
statements as well in any expression, which personally I'd find useful. And the
old operators would function just as they always have. What is problematic about
it?
21. Re: RFC: Breaking existing Euphoria functionality
Pete Lomax wrote:
>
> Alexander Toresson wrote:
> > 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.
>
> NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!
>
> > Thus all of the following snippets would work:
> <snip>
> > }}}
<eucode>
> > if (a = b) and (c = d) then
> > </eucode>
{{{
>
> But I just gave this example:
> }}}
<eucode>
> if (a=b) = (c=d) then
> </eucode>
{{{
>
> You are stuffed. STUFFED. UP S**T CREEK WITHOUT A PADDLE.
> You ask to make the middle "=" behave different to the outers.
> What you said was the "middle" "=" must yield atom, but it is clear that
> neither
> the "(a=b)" nor the "(c=d)" need to. Horrid. And ambiguous.
>
> Give it up. Make "=" ALWAYS return an atom, and add "sq_eq()" for the rare
> cases,
> or don't even try. KISS.
>
> Let me be very clear on this: I really WANT "a=b" to ALWAYS return an atom.
> I think that would be an excellent improvement to the language.
> Making "a=b" SOMETIMES return a sequence, for the same a and b, is utter
> madness,
> when "sq_eq(a,b)" is a much better way forward, for the rare cases that need
> it.
>
> YOU CANNOT DO THIS HALF-HEARTEDLY.
>
> Regards,
> Pete
> PS Andy Serpa seems to say replace the operator inside if statements, which
> imao is clearly wrong.
> PPS Naturally no real care/claim for "sq_eq" over "eq", "EQ" or whatever.
Haha, I'm sorry, I'm sorry. I agree wholeheartedly with you and I take back
everything I said in that post. I was just very tired at the time and my brain
was messed up by 23 hours of travelling by train. It seemed a good idea at that
time.... but well, of course it isn't.
Regards, Alexander Toresson
PS Of course, comparison operators do always return atoms in Orac.
22. 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.
23. Re: RFC: Breaking existing Euphoria functionality
Pete Lomax wrote:
>
> Alexander Toresson wrote:
> > 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.
>
> NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!
>
> > Thus all of the following snippets would work:
> <snip>
> > }}}
<eucode>
> > if (a = b) and (c = d) then
> > </eucode>
{{{
>
> But I just gave this example:
> }}}
<eucode>
> if (a=b) = (c=d) then
> </eucode>
{{{
>
> You are stuffed. STUFFED. UP S**T CREEK WITHOUT A PADDLE.
> You ask to make the middle "=" behave different to the outers.
> What you said was the "middle" "=" must yield atom, but it is clear that
> neither
> the "(a=b)" nor the "(c=d)" need to. Horrid. And ambiguous.
>
> Give it up. Make "=" ALWAYS return an atom, and add "sq_eq()" for the rare
> cases,
> or don't even try. KISS.
>
> Let me be very clear on this: I really WANT "a=b" to ALWAYS return an atom.
> I think that would be an excellent improvement to the language.
> Making "a=b" SOMETIMES return a sequence, for the same a and b, is utter
> madness,
> when "sq_eq(a,b)" is a much better way forward, for the rare cases that need
> it.
>
> YOU CANNOT DO THIS HALF-HEARTEDLY.
>
> Regards,
> Pete
> PS Andy Serpa seems to say replace the operator inside if statements, which
> imao is clearly wrong.
> PPS Naturally no real care/claim for "sq_eq" over "eq", "EQ" or whatever.
What about "equal()" in the rare cases you need only an atom and yet
compare sequences?
CChris
24. Re: RFC: Breaking existing Euphoria functionality
- Posted by Pete Lomax <petelomax at blueyonder.co.uk>
Feb 25, 2007
-
Last edited Feb 26, 2007
Andy, do you have a complete example program which uses sequence ops alot?
I'd like a go at analysing it, I couldn't find anything much in the archives.
Regards,
Pete
25. Re: RFC: Breaking existing Euphoria functionality
- Posted by Pete Lomax <petelomax at blueyonder.co.uk>
Feb 25, 2007
-
Last edited Feb 26, 2007
CChris wrote:
> 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.
This fails on everything except "=" and "!=" of the same length, eg:
if "azaz"<"zaza" then -- {1,0,1,0} treated as false
if "azaz"="azazaz" then -- crashes with sequences not the same length
Also, once you have a sequence of 1's and 0's, I believe it is too late to
figure out if it should mean true or false, eg:
if "azaz"<"zaza" then -- would need {1,0,1,0} treated as true
if "azaz"="abab" then -- would need {1,0,1,0} treated as false
Plus it would be significantly slower than compare().
> 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.
Indeed, that should be fixed as well. Once or twice a year I still write
something like "return idx and x[idx]" and am later forced to split it into two
return statements.
Regards,
Pete
26. Re: RFC: Breaking existing Euphoria functionality
- Posted by Pete Lomax <petelomax at blueyonder.co.uk>
Feb 25, 2007
-
Last edited Feb 26, 2007
CChris wrote:
> What about "equal()" in the rare cases you need only an atom and yet
> compare sequences?
Not sure if I get the joke?
27. Re: RFC: Breaking existing Euphoria functionality
Pete Lomax wrote:
>
> CChris wrote:
> > 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.
>
> This fails on everything except "=" and "!=" of the same length, eg:
> }}}
<eucode>
> if "azaz"<"zaza" then -- {1,0,1,0} treated as false
> if "azaz"="azazaz" then -- crashes with sequences not the same length
> </eucode>
{{{
Test whether lengths match first, evaluating the conditional statement to
false if they don't. That's fast enough.
> Also, once you have a sequence of 1's and 0's, I believe it is too late to
> figure
> out if it should mean true or false, eg:
> }}}
<eucode>
> if "azaz"<"zaza" then -- would need {1,0,1,0} treated as true
> if "azaz"="abab" then -- would need {1,0,1,0} treated as false
> </eucode>
{{{
For '<' and friends, you need a slightly different treatment here: go to
first 0 and compare the elements at that point.
> Plus it would be significantly slower than compare().
>
In eu.ex, yes, of course. But not too often if you check sequence lengths
firsthand.
In C, you'd just use an inlined REPZ CMPSB instruction to compare strings, or
REPZ CMPSD for general sequences. This is fast, even if Intel didn't optimize
it as much it could.
All right, this is non portable since it is asm. Who is using Eu on a non
Intel compatible CPU here? I think portability may be an issue in C, but
not in Eu. The day it becomes about as widespread as C, we can reconsider.
Note that I'd prefer Andy's solution of using new operators.
> > 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.
>
> Indeed, that should be fixed as well. Once or twice a year I still write
> something
> like "return idx and x[idx]" and am later forced to split it into two return
> statements.
>
Perhaps it is time to extend short circuiting to all expressions, and to
define non short-circuit variants of logical ops for the rare cases where
you don't want it. I like "and then" and "or else", borrowed from Eiffel,
but there are certainly other options.
CChris
> Regards,
> Pete
