1. New slice operator
- Posted by Fernando Bauer <fmbauer at hot?ail.?om> Apr 26, 2008
- 733 views
Jeremy Cowgar wrote: > > CChris wrote: > > > > Performing bound checking in an include file is a waste of time, since the > > backend > > will perform some bound checking regardless. Testing twice doesn't add any > > value > > and wastes CPU. Even more so as thee operations easily occur in loops. > > Bounds checking was the wrong word. What I mean to say is: I want up to the > first 30 items in a sequence. That's all I need. That's all I want to display. > So, to do that currently you must: > > }}} <eucode> > if length(s) > 30 then > s = s[1..30] > end if > puts(1, s) > </eucode> {{{ > > Now, you can simply: > > }}} <eucode> > puts(1, head(s, 30)) > </eucode> {{{ > How about this:
puts(1,s[1~30])
Matt wrote: > My thought is, "Is there really a need for this stuff?" There are better > ways to do this in euphoria. This seems like a very BASIC-y way to do > things. I don't think we should include this in the standard library. With the introduction of a new slice operator (~ in the above expression) it's possible to do what you want with functions like left()/head(), right()/tail() and mid(). This would respect the Euphoria style. I know that a new operator cannot be implemented in the standard library, but possibly the modification in the Euphoria source code (front and backend) isn't difficult. You would use the new slice operator when you DON'T know the length of a sequence, otherwise you continue to use the original slice operator '..' to have bounds checking. A possible definition of the new operator '~' is: s[a~b] =: s[min(max(1,a),$+1) .. min($,b)] I think this should be made in backend C-code. The implementation could use conditional statements instead of min and max functions. Then I think we would have the following equivalences: left(s,a) =: s[1~a] right(s,a) =: s[$-a+1~$] mid(s,a,b) =: s[a~b] Note that, by the definition, the new operator '~' would continue to alert when b<a-1 like the '..' operator. For all other cases there wouldn't be any restriction in a and b. If you access a range outside of a sequence, it results in {}. Some advantages: 1) Use Euphoria style; 2) Can use less characters than the function call; 3) Less functions to learn and memorize, more international syntax; 4) Less functions to conflict with; Disadvantages: 1) Modification in the front and backend code; 2) Learn a new operator; Examples:
name = "John" name = name[1~35] puts(1,name) -- "John" name = "John Doe" name = name[$-3+1~$] puts(1,name) -- "Doe"
For a test of the definition:
function max(atom a, atom b) if a > b then return a else return b end if end function function min(atom a, atom b) if a < b then return a else return b end if end function function tilde(sequence s, atom a, atom b) printf(1,"s[%d~%d] = ",{a,b}) return s[min(max(1,a),$+1) .. min($,b)] end function sequence s s = {0,1,2,3,4} ?tilde(s,0,1) ?tilde(s,-1,1) ?tilde(s,1,5) ?tilde(s,1,10) ?tilde(s,6,10) ?tilde(s,3,2)
Results: s[0~1] = {0} s[-1~1] = {0} s[1~5] = {0,1,2,3,4} s[1~10] = {0,1,2,3,4} s[6~10] = {} s[3~2] = {} This post doesn't mean that I'm against the implementation of that functions in the standard library. This is just an idea that maybe makes sense?? Regards, Fernando
2. Re: New slice operator
- Posted by c.k.lester <euphoric at cklester?com> Apr 26, 2008
- 697 views
Fernando Bauer wrote: > A possible definition of the new operator '~' is: > s[a~b] =: s[min(max(1,a),$+1) .. min($,b)] You're really trying to aggravate those of us with US keyboards, aren't you? :D How about the colon, instead? x[1:4] That's a little easier.
3. Re: New slice operator
- Posted by Fernando Bauer <fmbauer at hot?ail.co?> Apr 26, 2008
- 701 views
c.k.lester wrote: > > Fernando Bauer wrote: > > A possible definition of the new operator '~' is: > > s[a~b] =: s[min(max(1,a),$+1) .. min($,b)] > > You're really trying to aggravate those of us with US keyboards, aren't you? > :D After the invention of QWERTY keyboard, nothing more is so bad. > > How about the colon, instead? > > x[1:4] > > That's a little easier. I proposed the 'tilde' just because it can represent the idea of range like the character '-' and it's not used. How do you distinguish a slice s[a:b] from a variable subscript with a namespace s[a:b]? Regards, Fernando
4. Re: New slice operator
- Posted by Kat <KAT12 at coosahs?ne?> Apr 26, 2008
- 710 views
c.k.lester wrote: > > Fernando Bauer wrote: > > A possible definition of the new operator '~' is: > > s[a~b] =: s[min(max(1,a),$+1) .. min($,b)] > > You're really trying to aggravate those of us with US keyboards, aren't you? > :D > > How about the colon, instead? > > x[1:4] > > That's a little easier. It's the same keystrokes, different paws! How is it easier? Kat
5. Re: New slice operator
- Posted by yuku <yuku at ?kitek.?om> Apr 26, 2008
- 702 views
c.k.lester wrote: > How about the colon, instead? > x[1:4] > That's a little easier. Euphoria Manual, 2.2.6 Slicing of Sequences A sequence of consecutive elements may be selected by giving the starting and ending element numbers. If y has the value: {"fred", "george", "mary"} then it can be sliced using horizontal colon or vertical colon. Using horizontal colon: y[1..2] is {"fred", "george"} but y[3..9] will result in run-time error. If vertical colon is used, y[1:2] will give the same result, but y[3:9] will result in {"mary"}, the same effect achieved as if you used y[3..3]. What a ... Every programmer newbie will use : instead of .. because of the avoidance of error.
6. Re: New slice operator
- Posted by c.k.lester <euphoric at ckle?t?r.com> Apr 26, 2008
- 698 views
Kat wrote: > > It's the same keystrokes, different paws! How is it easier? I don't have to reach all the way up to the top row, corner key!!!!1!!!1!1!1 :P
7. Re: New slice operator
- Posted by c.k.lester <euphoric at ckleste?.?om> Apr 26, 2008
- 694 views
yuku wrote: > > run-time error. If vertical colon is used, y[1:2] will give the same > result, but y[3:9] will result in {"mary"}, the same effect achieved as if > you used y[3..3]. What the?! Is that real? I never knew Euphoria did that.
8. Re: New slice operator
- Posted by Jason Gade <jaygade at yahoo.??m> Apr 26, 2008
- 690 views
Fernando Bauer wrote: > How about this: > }}} <eucode> > puts(1,s[1~30]) > </eucode> {{{ > > Matt wrote: > > My thought is, "Is there really a need for this stuff?" There are better > > ways to do this in euphoria. This seems like a very BASIC-y way to do > > things. I don't think we should include this in the standard library. > > With the introduction of a new slice operator (~ in the above expression) it's > possible to do what you want with functions like left()/head(), right()/tail() > and mid(). This would respect the Euphoria style. > I know that a new operator cannot be implemented in the standard library, but > possibly the modification in the Euphoria source code (front and backend) > isn't > difficult. You would use the new slice operator when you DON'T know the length > of a sequence, otherwise you continue to use the original slice operator '..' > to have bounds checking. > A possible definition of the new operator '~' is: > s[a~b] =: s[min(max(1,a),$+1) .. min($,b)] > > I think this should be made in backend C-code. The implementation could use > conditional statements instead of min and max functions. > Then I think we would have the following equivalences: > left(s,a) =: s[1~a] > right(s,a) =: s[$-a+1~$] > mid(s,a,b) =: s[a~b] > > Note that, by the definition, the new operator '~' would continue to alert > when > b<a-1 like the '..' operator. For all other cases there wouldn't be any > restriction > in a and b. If you access a range outside of a sequence, it results in {}. > Some advantages: > 1) Use Euphoria style; > 2) Can use less characters than the function call; > 3) Less functions to learn and memorize, more international syntax; > 4) Less functions to conflict with; > > Disadvantages: > 1) Modification in the front and backend code; > 2) Learn a new operator; > > Examples: > }}} <eucode> > name = "John" > name = name[1~35] > puts(1,name) -- "John" > name = "John Doe" > name = name[$-3+1~$] > puts(1,name) -- "Doe" > </eucode> {{{ > > For a test of the definition: > > }}} <eucode> > function max(atom a, atom b) > if a > b then return a > else return b > end if > end function > > function min(atom a, atom b) > if a < b then return a > else return b > end if > end function > > function tilde(sequence s, atom a, atom b) > printf(1,"s[%d~%d] = ",{a,b}) > return s[min(max(1,a),$+1) .. min($,b)] > end function > > sequence s > s = {0,1,2,3,4} > ?tilde(s,0,1) > ?tilde(s,-1,1) > ?tilde(s,1,5) > ?tilde(s,1,10) > ?tilde(s,6,10) > ?tilde(s,3,2) > </eucode> {{{ > > Results: > s[0~1] = {0} > s[-1~1] = {0} > s[1~5] = {0,1,2,3,4} > s[1~10] = {0,1,2,3,4} > s[6~10] = {} > s[3~2] = {} > > This post doesn't mean that I'm against the implementation of that functions > in the standard library. This is just an idea that maybe makes sense?? > > Regards, > Fernando This is an interesting proposal. I was thinking more about the head/tail issue today. Hey, I guess almost anything is better than car/cdr! -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
9. Re: New slice operator
- Posted by Shawn Pringle <shawn.pringle at g?ail.c?m> Apr 26, 2008
- 710 views
Jason Gade wrote: > > Fernando Bauer wrote: > > How about this: > > }}} <eucode> > > puts(1,s[1~30]) > > </eucode> {{{ > > > > Matt wrote: > > > My thought is, "Is there really a need for this stuff?" There are better > > > ways to do this in euphoria. This seems like a very BASIC-y way to do > > > things. I don't think we should include this in the standard library. I think this is all rather redundant. We already have a slice operator. Instead of puts(1,s[1~30]) use puts(1,s[1..30])
10. Re: New slice operator
- Posted by Jason Gade <jaygade at ?ahoo.com> Apr 26, 2008
- 695 views
Shawn Pringle wrote: > > Jason Gade wrote: > > > > Fernando Bauer wrote: > > > How about this: > > > }}} <eucode> > > > puts(1,s[1~30]) > > > </eucode> {{{ > > > > > > Matt wrote: > > > > My thought is, "Is there really a need for this stuff?" There are > > > > better > > > > ways to do this in euphoria. This seems like a very BASIC-y way to do > > > > things. I don't think we should include this in the standard library. > > I think this is all rather redundant. We already have > a slice operator. Instead of puts(1,s[1~30]) use puts(1,s[1..30]) The object is to return all of the elements up to either the end or 30, whichever is longer. The normal slice operator would return an error if length(s) < 30. I'm not proposing it, I just think that it's an interesting topic for discussion. Fernando proposed it. -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
11. Re: New slice operator
- Posted by don cole <doncole at pacbell.n??> Apr 26, 2008
- 695 views
- Last edited Apr 27, 2008
Jason Gade wrote: > > Shawn Pringle wrote: > > > > Jason Gade wrote: > > > > > > Fernando Bauer wrote: > > > > How about this: > > > > }}} <eucode> > > > > puts(1,s[1~30]) > > > > </eucode> {{{ > > > > > > > > Matt wrote: > > > > > My thought is, "Is there really a need for this stuff?" There are > > > > > better > > > > > ways to do this in euphoria. This seems like a very BASIC-y way to do > > > > > > > > > > things. I don't think we should include this in the standard library. > > > > I think this is all rather redundant. We already have > > a slice operator. Instead of puts(1,s[1~30]) use puts(1,s[1..30]) > > The object is to return all of the elements up to either the end or 30, > whichever > is longer. The normal slice operator would return an error if length(s) < > 30. As it should. If the coder is asking for something longer that he/she has created then he/she should get an error. I think the coding is just perfect the way it is. > I'm not proposing it, I just think that it's an interesting topic for > discussion. > Fernando proposed it. > > -- > A complex system that works is invariably found to have evolved from a simple > system that works. > --John Gall's 15th law of Systemantics. > > "Premature optimization is the root of all evil in programming." > --C.A.R. Hoare > > j. Don Cole
12. Re: New slice operator
- Posted by Jason Gade <jaygade at y?hoo.?om> Apr 26, 2008
- 729 views
- Last edited Apr 27, 2008
don cole wrote: > > Jason Gade wrote: > > > > Shawn Pringle wrote: > > > > > > Jason Gade wrote: > > > > > > > > Fernando Bauer wrote: > > > > > How about this: > > > > > }}} <eucode> > > > > > puts(1,s[1~30]) > > > > > </eucode> {{{ > > > > > > > > > > Matt wrote: > > > > > > My thought is, "Is there really a need for this stuff?" There are > > > > > > better > > > > > > ways to do this in euphoria. This seems like a very BASIC-y way to > > > > > > do > > > > > > things. I don't think we should include this in the standard > > > > > > library. > > > > > > I think this is all rather redundant. We already have > > > a slice operator. Instead of puts(1,s[1~30]) use puts(1,s[1..30]) > > > > The object is to return all of the elements up to either the end or 30, > > whichever > > is longer. The normal slice operator would return an error if length(s) < > > 30. > > As it should. > > If the coder is asking for something longer that he/she has created then > > he/she should get an error. > > I think the coding is just perfect the way it is. > > > I'm not proposing it, I just think that it's an interesting topic for > > discussion. > > Fernando proposed it. > > > > -- > > A complex system that works is invariably found to have evolved from a > > simple > > system that works. > > --John Gall's 15th law of Systemantics. > > > > "Premature optimization is the root of all evil in programming." > > --C.A.R. Hoare > > > > j. > > > Don Cole Although I wasn't in the IRC discussion, I just read the logs and I see that the consensus was to stick with "head()" and "tail()" in the standard library, with which I can agree. No need to add new operators. It was worth discussing, though. -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
13. Re: New slice operator
- Posted by CChris <christian.cuvier at agri?ultur?.gouv.fr> Apr 27, 2008
- 703 views
- Last edited Apr 28, 2008
c.k.lester wrote: > > Fernando Bauer wrote: > > A possible definition of the new operator '~' is: > > s[a~b] =: s[min(max(1,a),$+1) .. min($,b)] > > You're really trying to aggravate those of us with US keyboards, aren't you? > :D > > How about the colon, instead? > > x[1:4] > > That's a little easier. So, is s[x:y] a single or slice assignment? No one can tell. CChris
14. Re: New slice operator
- Posted by CChris <christian.cuvier at agric??ture.gouv.fr> Apr 27, 2008
- 723 views
- Last edited Apr 28, 2008
don cole wrote: > > Jason Gade wrote: > > > > Shawn Pringle wrote: > > > > > > Jason Gade wrote: > > > > > > > > Fernando Bauer wrote: > > > > > How about this: > > > > > }}} <eucode> > > > > > puts(1,s[1~30]) > > > > > </eucode> {{{ > > > > > > > > > > Matt wrote: > > > > > > My thought is, "Is there really a need for this stuff?" There are > > > > > > better > > > > > > ways to do this in euphoria. This seems like a very BASIC-y way to > > > > > > do > > > > > > things. I don't think we should include this in the standard > > > > > > library. > > > > > > I think this is all rather redundant. We already have > > > a slice operator. Instead of puts(1,s[1~30]) use puts(1,s[1..30]) > > > > The object is to return all of the elements up to either the end or 30, > > whichever > > is longer. The normal slice operator would return an error if length(s) < > > 30. > > As it should. > > If the coder is asking for something longer that he/she has created then > > he/she should get an error. > > I think the coding is just perfect the way it is. > > > I'm not proposing it, I just think that it's an interesting topic for > > discussion. > > Fernando proposed it. > > > > -- > > A complex system that works is invariably found to have evolved from a > > simple > > system that works. > > --John Gall's 15th law of Systemantics. > > > > "Premature optimization is the root of all evil in programming." > > --C.A.R. Hoare > > > > j. > > > Don Cole No, no and no! Do you really think a function that checks whether the next word is "while" should error out if the line is shorter than 5 chars? You wind up with this
function Equals(sequence s,integer i,sequence pattern) if i<1 or i>length(s)-length(pattern)+1 then return 0 else return equal(s[i..i+length(pattern)-1],pattern) end if end function
Look at the amount of generated code (use Matt's ildisasm out of curiosity), and wonder why we get more code where less many checks are actually needed. Both hard (the current way) and soft slice assignments are needed. I'd vote for Ricardo's ~ suggestion. CChris
15. Re: New slice operator
- Posted by Jeremy Cowgar <jeremy at c??gar.com> Apr 27, 2008
- 705 views
- Last edited Apr 28, 2008
CChris wrote: > > No, no and no! > Do you really think a function that checks whether the next word is "while" > should error out if the line is shorter than 5 chars? You wind up with this > }}} <eucode> > function Equals(sequence s,integer i,sequence pattern) > if i<1 or i>length(s)-length(pattern)+1 then > return 0 > else > return equal(s[i..i+length(pattern)-1],pattern) > end if > end function > </eucode> {{{ > Look at the amount of generated code (use Matt's ildisasm out of curiosity), > and wonder why we get more code where less many checks are actually needed. > Both hard (the current way) and soft slice assignments are needed. I'd vote > for Ricardo's ~ suggestion. > In the new standard lib, there is head(), tail() now that do what you are suggesting. head("next", 10) -- "next" -- Jeremy Cowgar http://jeremy.cowgar.com