1. RFC: Breaking existing Euphoria functionality
- Posted by Michael J. Sabal <m_sabal at yahoo.com> Feb 22, 2007
- 610 views
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
- Posted by CChris <christian.cuvier at agriculture.gouv.fr> Feb 22, 2007
- 580 views
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
- Posted by c.k.lester <euphoric at cklester.com> Feb 22, 2007
- 571 views
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
- 581 views
- 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
- 555 views
- 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
- 570 views
- 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
- 579 views
- 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
- 584 views
- 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
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Feb 23, 2007
- 565 views
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
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Feb 23, 2007
- 568 views
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
- Posted by Michael J. Sabal <m_sabal at yahoo.com> Feb 23, 2007
- 587 views
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
- Posted by Aku <akusaya at gmx.net> Feb 23, 2007
- 575 views
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
- Posted by Michael J. Sabal <m_sabal at yahoo.com> Feb 23, 2007
- 569 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. > > 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
- Posted by Derek Parnell <ddparnell at bigpond.com> Feb 23, 2007
- 567 views
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
- Posted by CChris <christian.cuvier at agriculture.gouv.fr> Feb 23, 2007
- 556 views
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
- Posted by Andy Serpa <ac at onehorseshy.com> Feb 23, 2007
- 562 views
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
- Posted by Alexander Toresson <alexander.toresson at gmail.com> Feb 24, 2007
- 572 views
- Last edited Feb 25, 2007
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
- 591 views
- 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
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Feb 25, 2007
- 558 views
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
- Posted by Andy Serpa <ac at onehorseshy.com> Feb 25, 2007
- 568 views
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
- Posted by Alexander Toresson <alexander.toresson at gmail.com> Feb 25, 2007
- 568 views
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
- Posted by CChris <christian.cuvier at agriculture.gouv.fr> Feb 25, 2007
- 571 views
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
- Posted by CChris <christian.cuvier at agriculture.gouv.fr> Feb 25, 2007
- 563 views
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
- 563 views
- 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
- 599 views
- 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
- 579 views
- 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
- Posted by CChris <christian.cuvier at agriculture.gouv.fr> Feb 26, 2007
- 588 views
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