1. left, right? head, tail? which one?
- Posted by Jeremy Cowgar <jeremy at co??ar.com> Apr 24, 2008
- 766 views
Ok... We have some functions that are dealing with sequences (can be applied to sequences or "strings"). I am waffling between using left/right or head/tail naming conventions. What are your thoughts? Functions that use these are, for instance:
left("John Doe", 4) -- "John" left({{1,2},{3,4},{5,6}}, 2) -- {{1,2},{3,4}} right("John Doe", 3) -- "Doe" tail("John Doe", 3) -- "Doe" pad_left("ABC", 6) -- " ABC" pad_head("ABC", 6) -- " ABC" pad_tail("ABC", 6) -- "ABC " trim_tail("ABC \r\n\t", 0) -- "ABC" trim_head("...ABC", '.') -- "ABC" trim_head("\r\t\nDEF ABC", "\tFD\n E") -- "ABC"
I am wondering if the naming scheme of head/tail is better than left/right. When I think of head/tail I think of lists, which these functions do work on (I only gave the one example of left() as to not be too verbose in my example). Left/Right seem to apply more to strings (which these functions will work on as well, as you see). Thoughts? -- Jeremy Cowgar http://jeremy.cowgar.com
2. Re: left, right? head, tail? which one?
- Posted by Matt Lewis <matthewwalkerlewis at gmai?.?om> Apr 24, 2008
- 725 views
Jeremy Cowgar wrote: >
left("John Doe", 4) -- "John" left({{1,2},{3,4},{5,6}}, 2) -- {{1,2},{3,4}} right("John Doe", 3) -- "Doe" tail("John Doe", 3) -- "Doe" pad_left("ABC", 6) -- " ABC" pad_head("ABC", 6) -- " ABC" pad_tail("ABC", 6) -- "ABC " trim_tail("ABC \r\n\t", 0) -- "ABC" trim_head("...ABC", '.') -- "ABC" trim_head("\r\t\nDEF ABC", "\tFD\n E") -- "ABC"
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. Well, the trim stuff is useful, but should probably live in string.e. Matt
3. Re: left, right? head, tail? which one?
- Posted by Jeremy Cowgar <jeremy at cowg?r.c?m> Apr 24, 2008
- 716 views
Matt Lewis wrote: > > Jeremy Cowgar wrote: > > > }}} <eucode> > left("John Doe", 4) -- "John" > left({{1,2},{3,4},{5,6}}, 2) -- {{1,2},{3,4}} > right("John Doe", 3) -- "Doe" > tail("John Doe", 3) -- "Doe" > pad_left("ABC", 6) -- " ABC" > pad_head("ABC", 6) -- " ABC" > pad_tail("ABC", 6) -- "ABC " > trim_tail("ABC \r\n\t", 0) -- "ABC" > trim_head("...ABC", '.') -- "ABC" > trim_head("\r\t\nDEF ABC", "\tFD\n E") -- "ABC" > </eucode> {{{ > > 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. > > Well, the trim stuff is useful, but should probably live in string.e. Matt, How would you do left, right?, pad left, pad right? Left you can do: str[1..3] for instance, but what about:
name = "John" name = left(name, 35) -- "John" -- otherwise if length(name) > 35 then name = name[1..35] end if name = "John Doe" name = right(name, 3) -- "Doe" -- otherwise if length(name) > 3 then name = name[$-3..$] end if name = "John" name = pad_tail(name, 45) -- otherwise if length(name) < 45 then name = name & repeat(32, 45 - length(name)) end if
Are there better ways to do the "otherwise" parts? All of the above functions are important for string processing, in which is a lot of programs. -- Jeremy Cowgar http://jeremy.cowgar.com
4. Re: left, right? head, tail? which one?
- Posted by Jules <jdavy at dsl??ipex.com> Apr 24, 2008
- 714 views
Jeremy Cowgar wrote: > > Ok... We have some functions that are dealing with sequences (can be applied > to sequences or "strings"). I am waffling between using left/right or > head/tail > naming conventions. What are your thoughts? Functions that use these are, for > instance: > > }}} <eucode> > left("John Doe", 4) -- "John" > left({{1,2},{3,4},{5,6}}, 2) -- {{1,2},{3,4}} > right("John Doe", 3) -- "Doe" > tail("John Doe", 3) -- "Doe" > pad_left("ABC", 6) -- " ABC" > pad_head("ABC", 6) -- " ABC" > pad_tail("ABC", 6) -- "ABC " > trim_tail("ABC \r\n\t", 0) -- "ABC" > trim_head("...ABC", '.') -- "ABC" > trim_head("\r\t\nDEF ABC", "\tFD\n E") -- "ABC" > </eucode> {{{ > > I am wondering if the naming scheme of head/tail is better than left/right. > When I think of head/tail I think of lists, which these functions do work on > (I only gave the one example of left() as to not be too verbose in my > example). > Left/Right seem to apply more to strings (which these functions will work on > as well, as you see). > > Thoughts? > > -- > Jeremy Cowgar > <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a> What about using "Drop" and "Take", as found in Ricardo Forno's general functions library?
5. Re: left, right? head, tail? which one?
- Posted by Mike777 <anon4321 at gmail.?o?> Apr 24, 2008
- 715 views
- Last edited Apr 25, 2008
Matt Lewis wrote: > > Jeremy Cowgar wrote: > > > }}} <eucode> > left("John Doe", 4) -- "John" > left({{1,2},{3,4},{5,6}}, 2) -- {{1,2},{3,4}} > right("John Doe", 3) -- "Doe" > tail("John Doe", 3) -- "Doe" > pad_left("ABC", 6) -- " ABC" > pad_head("ABC", 6) -- " ABC" > pad_tail("ABC", 6) -- "ABC " > trim_tail("ABC \r\n\t", 0) -- "ABC" > trim_head("...ABC", '.') -- "ABC" > trim_head("\r\t\nDEF ABC", "\tFD\n E") -- "ABC" > </eucode> {{{ > > 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. > > Well, the trim stuff is useful, but should probably live in string.e. Somebody earlier stated that they were probably the least competent Euphoria programmer commenting here. I beg to differ. With that in mind, sometimes the "old" way of doing things is the best way as it leverages prior knowledge, lowers barriers to understanding and generally makes the language easier to propagate. Unless there is a compelling reason to use a descriptor which is different, I would argue for using the BASIC-y way of doing things. That is, if the descriptor is perfectly apt when dealing with strings, let the standard be that anything which does work with strings also will work with sequences. It has taken me a while to get my head around the overloading of the sequences type with both strings and sequences (oh, if I had a nickel for each compilation that resulted in the "sequence found within character string" error). But now that I have, I don't want to forget the fact that this most elegant of features is, as the documentation says, "IT" and that just because the documentation says it doesn't mean that the reader actually GETS it until later. In my case, MUCH later. With that said as more background, I'll restate the above in the following manner: for each function I can immediately understand because it is BASIC-y, the barrier for me to adopt Euphoria for my programming needs lowers. The best way to communicate that to the EU newbie is a name which is both familiar and apt. Please don't interpret the above as saying you should always use names that are archaic. New concepts scream out for new descriptors. Hacking the first few things off for later use (or the last) is about as basic (not BASIC) as one can get. Mike
6. Re: left, right? head, tail? which one?
- Posted by CChris <christian.cuvier at agric?lture.gouv.?r> Apr 25, 2008
- 710 views
Jeremy Cowgar wrote: > > Ok... We have some functions that are dealing with sequences (can be applied > to sequences or "strings"). I am waffling between using left/right or > head/tail > naming conventions. What are your thoughts? Functions that use these are, for > instance: > > }}} <eucode> > left("John Doe", 4) -- "John" > left({{1,2},{3,4},{5,6}}, 2) -- {{1,2},{3,4}} > right("John Doe", 3) -- "Doe" > tail("John Doe", 3) -- "Doe" > pad_left("ABC", 6) -- " ABC" > pad_head("ABC", 6) -- " ABC" > pad_tail("ABC", 6) -- "ABC " > trim_tail("ABC \r\n\t", 0) -- "ABC" > trim_head("...ABC", '.') -- "ABC" > trim_head("\r\t\nDEF ABC", "\tFD\n E") -- "ABC" > </eucode> {{{ > > I am wondering if the naming scheme of head/tail is better than left/right. > When I think of head/tail I think of lists, which these functions do work on > (I only gave the one example of left() as to not be too verbose in my > example). > Left/Right seem to apply more to strings (which these functions will work on > as well, as you see). > > Thoughts? > > -- > Jeremy Cowgar > <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a> Eu has no strings as distinct from lists of characters. The point of whether Eu should or could have such a type has been hacked to death in the past. AFAIK, the conclusion so far is that it might be nice, but requires a complete overhaul of the type system implementation, and possibly slight loss in general performance. No attempt has been made so far. So, since we *only* have lists, head and tail make more sense for the very reasons ou exposed. CChris
7. Re: left, right? head, tail? which one?
- Posted by CChris <christian.cuvier at agric??ture.gouv.fr> Apr 25, 2008
- 702 views
Mike777 wrote: > > Matt Lewis wrote: > > > > Jeremy Cowgar wrote: > > > > > }}} <eucode> > > left("John Doe", 4) -- "John" > > left({{1,2},{3,4},{5,6}}, 2) -- {{1,2},{3,4}} > > right("John Doe", 3) -- "Doe" > > tail("John Doe", 3) -- "Doe" > > pad_left("ABC", 6) -- " ABC" > > pad_head("ABC", 6) -- " ABC" > > pad_tail("ABC", 6) -- "ABC " > > trim_tail("ABC \r\n\t", 0) -- "ABC" > > trim_head("...ABC", '.') -- "ABC" > > trim_head("\r\t\nDEF ABC", "\tFD\n E") -- "ABC" > > </eucode> {{{ > > > > 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. > > > > Well, the trim stuff is useful, but should probably live in string.e. > > Somebody earlier stated that they were probably the least competent Euphoria > programmer commenting here. I beg to differ. > > With that in mind, sometimes the "old" way of doing things is the best way as > it leverages prior knowledge, lowers barriers to understanding and generally > makes the language easier to propagate. > > Unless there is a compelling reason to use a descriptor which is different, > I would argue for using the BASIC-y way of doing things. That is, if the > descriptor > is perfectly apt when dealing with strings, let the standard be that anything > which does work with strings also will work with sequences. > > It has taken me a while to get my head around the overloading of the sequences > type with both strings and sequences (oh, if I had a nickel for each > compilation > that resulted in the "sequence found within character string" error). But now > that I have, I don't want to forget the fact that this most elegant of > features > is, as the documentation says, "IT" and that just because the documentation > says it doesn't mean that the reader actually GETS it until later. In my > case, > MUCH later. > > With that said as more background, I'll restate the above in the following > manner: > for each function I can immediately understand because it is BASIC-y, the > barrier > for me to adopt Euphoria for my programming needs lowers. The best way to > communicate > that to the EU newbie is a name which is both familiar and apt. > I'm sorry, but how many people today (not back in 1993) come to Eu after non-Visual Basic? My guesstimate is 0. What had attracted me in the language, in spite of all its drawbacks, is the intuitiveness of sequences. I have read some stuff about it being hard to hrasp, all right, but I simply don't understand what the problem is, and hence of how to alleviate it. You know, Windows XP comes with some version of Python. Lots of newbie programmers will start, and have started, with Python. If they later come to Eu because of the simplicity/performance mix, they won't be newbies in programming any more. Add in a few that started tinkering with VBA/VBE at the office. Sure, it's Basic, but already object Basic. And again, if these people come to Eu, it's because they understand what they are doig, so are not real newbies. In a nutshell, I think that centering on what newbies are supposed to understand easily or not is not the right target for Eu, since people ocoming to it nowadays are usually not newbies in programming. CChris > Please don't interpret the above as saying you should always use names that > are archaic. New concepts scream out for new descriptors. Hacking the first > few things off for later use (or the last) is about as basic (not BASIC) as > one can get. > > Mike
8. Re: left, right? head, tail? which one?
- Posted by c.k.lester <euphoric at ckl?ster.?om> Apr 25, 2008
- 716 views
CChris wrote: > > In a nutshell, I think that centering on what newbies are supposed to > understand > easily or not is not the right target for Eu, since people coming to it > nowadays > are usually not newbies in programming. I agree. And n00bs have to cut their teeth somewhere (that is, there will be easy concepts and hard concepts about any programming language). Besides, no dummies will be using Euphoria. ;)
9. Re: left, right? head, tail? which one?
- Posted by Jeremy Cowgar <jeremy at co?gar.c?m> Apr 25, 2008
- 716 views
CChris wrote: > > You know, Windows XP comes with some version of Python. Lots of newbie > programmers > will start, and have started, with Python. And Python has these methods too. Well, they do not have the left/right ones, but the pad and trim. In python they are called: strip, lstrip, rstrip, ljust, rjust, center -- Jeremy Cowgar http://jeremy.cowgar.com
10. Re: left, right? head, tail? which one?
- Posted by Jason Gade <jaygade at ?ah?o.com> Apr 25, 2008
- 725 views
CChris wrote: > > I'm sorry, but how many people today (not back in 1993) come to Eu after > non-Visual > Basic? My guesstimate is 0. *raises hand* I had (and still have) zero VB experience. > > What had attracted me in the language, in spite of all its drawbacks, is the > intuitiveness of sequences. I have read some stuff about it being hard to > hrasp, > all right, but I simply don't understand what the problem is, and hence of how > to alleviate it. > > You know, Windows XP comes with some version of Python. Lots of newbie > programmers > will start, and have started, with Python. It does? That's news to me. Tell me, where is python in a standard XP install? Because the few times that I've used it (to run third-party stuff, not my own) I've had to install Python separately. > If they later come to Eu because > of the simplicity/performance mix, they won't be newbies in programming any > more. Add in a few that started tinkering with VBA/VBE at the office. Sure, > it's Basic, but already object Basic. And again, if these people come to Eu, > it's because they understand what they are doig, so are not real newbies. > > In a nutshell, I think that centering on what newbies are supposed to > understand > easily or not is not the right target for Eu, since people ocoming to it > nowadays > are usually not newbies in programming. > > CChris I agree that people coming to Euphoria aren't necessarily absolute newbies to programming, and that there are probably better systems out there for people who are absolute newbies. Of course, I don't see the relevance of the comment with regards to the quoted section. -- 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: left, right? head, tail? which one?
- Posted by CChris <christian.cuvier at agricul?ure.g?uv.fr> Apr 25, 2008
- 721 views
Jason Gade wrote: > > CChris wrote: > > > > I'm sorry, but how many people today (not back in 1993) come to Eu after > > non-Visual > > Basic? My guesstimate is 0. > > *raises hand* > I had (and still have) zero VB experience. > > > > > What had attracted me in the language, in spite of all its drawbacks, is the > > intuitiveness of sequences. I have read some stuff about it being hard to > > hrasp, > > all right, but I simply don't understand what the problem is, and hence of > > how > > to alleviate it. > > > > You know, Windows XP comes with some version of Python. Lots of newbie > > programmers > > will start, and have started, with Python. > > It does? That's news to me. Tell me, where is python in a standard XP install? > Because the few times that I've used it (to run third-party stuff, not my own) > I've had to install Python separately. > C:\Program Files\Python 2.2 iirc (not writing from home right now). On a brand new machine I bought in Aug 2005 with XP Home. I assumed it was standard. > > If they later come to Eu because > > of the simplicity/performance mix, they won't be newbies in programming any > > more. Add in a few that started tinkering with VBA/VBE at the office. Sure, > > it's Basic, but already object Basic. And again, if these people come to Eu, > > it's because they understand what they are doig, so are not real newbies. > > > > In a nutshell, I think that centering on what newbies are supposed to > > understand > > easily or not is not the right target for Eu, since people ocoming to it > > nowadays > > are usually not newbies in programming. > > > > CChris > > I agree that people coming to Euphoria aren't necessarily absolute newbies to > programming, and that there are probably better systems out there for people > who are absolute newbies. > > Of course, I don't see the relevance of the comment with regards to the quoted > section. > The section mentioned that which routines to have and how to name them should take the learning curve for newbies into account. To which I'm replying that these are not the primary newcomers to Eu, and that, as a consequence, taking these needs into account wasn't the right way to go imho. Is that irrrelevant, really? CChris > -- > 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.
12. Re: left, right? head, tail? which one?
- Posted by Jason Gade <jaygade at yaho?.?om> Apr 25, 2008
- 720 views
CChris wrote: > > Jason Gade wrote: > > I agree that people coming to Euphoria aren't necessarily absolute newbies > > to > > programming, and that there are probably better systems out there for people > > who are absolute newbies. > > > > Of course, I don't see the relevance of the comment with regards to the > > quoted > > section. > > > > The section mentioned that which routines to have and how to name them should > take the learning curve for newbies into account. To which I'm replying that > these are not the primary newcomers to Eu, and that, as a consequence, taking > these needs into account wasn't the right way to go imho. Is that irrrelevant, > really? > > CChris No, I think it's relevant, just that your position wasn't very clear to me. (Hint: I'm agreeing with your basic premise). Some of these forms already have an idiom in Euphoria (left, right). The pad and trim stuff might be useful, I'm not sure. I kinda agree with Matt up above. Jeremy, have you looked into Kat's strtok library? -- 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: left, right? head, tail? which one?
- Posted by Jeremy Cowgar <jeremy at cow?ar.co?> Apr 25, 2008
- 724 views
Jason Gade wrote: > > Some of these forms already have an idiom in Euphoria (left, right). The pad > and trim stuff might be useful, I'm not sure. I kinda agree with Matt up > above. Can you give me an example of how you would do:
sequence s s = head({1,2,3,4,5}, 3) -- {1,2,3} s = head({1,2}, 55) -- {1,2} s = head("John Doe", 30) -- "John Doe" s = head("John Doe" 3) -- "Joh"
I do a lot of string processing and checking length each time is the pits, thus most languages provide some form of left, right, mid that do bounds checking. [1..3] will not work. [3..$] will not work. In regards to trim and pad... yes, in string processing they are very helpful, again, the reason that most languages (even python as stated previously) have them. > Jeremy, have you looked into Kat's strtok library? I have it downloaded, but I have not got into the section yet of the standard library of string tokenizing so I have not spent any real time with it. -- Jeremy Cowgar http://jeremy.cowgar.com
14. Re: left, right? head, tail? which one?
- Posted by Jason Gade <jaygade at y?hoo?com> Apr 25, 2008
- 711 views
Jeremy Cowgar wrote: > > Jason Gade wrote: > > > > Some of these forms already have an idiom in Euphoria (left, right). The pad > > and trim stuff might be useful, I'm not sure. I kinda agree with Matt up > > above. > > Can you give me an example of how you would do: > > }}} <eucode> > sequence s > s = head({1,2,3,4,5}, 3) -- {1,2,3} > s = head({1,2}, 55) -- {1,2} > s = head("John Doe", 30) -- "John Doe" > s = head("John Doe" 3) -- "Joh" > </eucode> {{{ > > I do a lot of string processing and checking length each time is the pits, > thus > most languages provide some form of left, right, mid that do bounds checking. > [1..3] will not work. [3..$] will not work. I'd just do the bounds checking manually, or if I was doing a lot of it as you say you do then I would roll my own. Tomayto-tomahto. I don't have a strong opinion about it, just my 2 cents. It would probably fit right into an include dedicated to string or list processing. -- 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.
15. Re: left, right? head, tail? which one?
- Posted by Jeremy Cowgar <jeremy at ?owgar.?om> Apr 25, 2008
- 718 views
Jason Gade wrote: > > It would probably fit right into an include dedicated to string or list > processing. Which is where it is. sequence.e -- Jeremy Cowgar http://jeremy.cowgar.com
16. Re: left, right? head, tail? which one?
- Posted by Matt Lewis <matthewwalkerlewis at gm?i?.com> Apr 25, 2008
- 721 views
CChris wrote: > > You know, Windows XP comes with some version of Python. "Comes with," or "is available for?" I wasn't aware of MS shipping a python interpreter (.NET or otherwise). Matt
17. Re: left, right? head, tail? which one?
- Posted by CChris <christian.cuvier at agr?c?lture.gouv.fr> Apr 25, 2008
- 708 views
Jason Gade wrote: > > Jeremy Cowgar wrote: > > > > Jason Gade wrote: > > > > > > Some of these forms already have an idiom in Euphoria (left, right). The > > > pad > > > and trim stuff might be useful, I'm not sure. I kinda agree with Matt up > > > above. > > > > Can you give me an example of how you would do: > > > > }}} <eucode> > > sequence s > > s = head({1,2,3,4,5}, 3) -- {1,2,3} > > s = head({1,2}, 55) -- {1,2} > > s = head("John Doe", 30) -- "John Doe" > > s = head("John Doe" 3) -- "Joh" > > </eucode> {{{ > > > > I do a lot of string processing and checking length each time is the pits, > > thus > > most languages provide some form of left, right, mid that do bounds > > checking. > > [1..3] will not work. [3..$] will not work. > > I'd just do the bounds checking manually, or if I was doing a lot of it as you > say you do then I would roll my own. Tomayto-tomahto. > > I don't have a strong opinion about it, just my 2 cents. > > It would probably fit right into an include dedicated to string or list > processing. > > -- > 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. 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. So let's have these builtin, so as to both spare useless typing and useless testing. Removing the extra bound checking has the added benefit of making the code leaner, hence clearer. CChris
18. Re: left, right? head, tail? which one?
- Posted by Jason Gade <jaygade at ??hoo.com> Apr 25, 2008
- 709 views
CChris wrote: > > Jason Gade wrote: > > > > Jeremy Cowgar wrote: > > > > > > Jason Gade wrote: > > > > > > > > Some of these forms already have an idiom in Euphoria (left, right). The > > > > pad > > > > and trim stuff might be useful, I'm not sure. I kinda agree with Matt up > > > > above. > > > > > > Can you give me an example of how you would do: > > > > > > }}} <eucode> > > > sequence s > > > s = head({1,2,3,4,5}, 3) -- {1,2,3} > > > s = head({1,2}, 55) -- {1,2} > > > s = head("John Doe", 30) -- "John Doe" > > > s = head("John Doe" 3) -- "Joh" > > > </eucode> {{{ > > > > > > I do a lot of string processing and checking length each time is the pits, > > > thus > > > most languages provide some form of left, right, mid that do bounds > > > checking. > > > [1..3] will not work. [3..$] will not work. > > > > I'd just do the bounds checking manually, or if I was doing a lot of it as > > you > > say you do then I would roll my own. Tomayto-tomahto. > > > > I don't have a strong opinion about it, just my 2 cents. > > > > It would probably fit right into an include dedicated to string or list > > processing. > > > > -- > > 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. > > 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. > > So let's have these builtin, so as to both spare useless typing and useless > testing. Removing the extra bound checking has the added benefit of making the > code leaner, hence clearer. > > CChris No one is talking about making these built-in. I don't think that I would be in favor of that. -- 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.
19. Re: left, right? head, tail? which one?
- Posted by Matt Lewis <matthewwalkerlewis at gmai?.co?> Apr 25, 2008
- 722 views
Jeremy Cowgar wrote: > > I do a lot of string processing and checking length each time is the pits, > thus most languages provide some form of left, right, mid that do bounds > checking. [1..3] will not work. [3..$] will not work. As do I. And yeah, it can be a pain, but I like to know when the data doesn't look like I think it should. That's usually an error condition that should be handled, rather than keep going obliviously. It reminds me of putting February 30th into MySQL. Matt
20. Re: left, right? head, tail? which one?
- Posted by Jeremy Cowgar <jeremy at cow??r.com> Apr 25, 2008
- 718 views
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:
if length(s) > 30 then s = s[1..30] end if puts(1, s)
Now, you can simply:
puts(1, head(s, 30))
This is so common of an operation, I am very surprised we are having this much troubles agreeing on it's usefulness. > So let's have these builtin, so as to both spare useless typing and useless > testing. Removing the extra bound checking has the added benefit of making the > code leaner, hence clearer. You cannot have what I did above built in. It was my mistake saying bounds checking. You want the following to err out, as it does currently, because Euphoria already does bounds checking (correct use of the term this time).
sequence s s = "ABC" puts(1, s[1..30])
That needs to err out, as it does. -- Jeremy Cowgar http://jeremy.cowgar.com
21. Re: left, right? head, tail? which one?
- Posted by CChris <christian.cuvier at agricult?re.gouv.fr> Apr 25, 2008
- 720 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> {{{ > > This is so common of an operation, I am very surprised we are having this much > troubles agreeing on it's usefulness. > I certainly don't disagree on its usefulness. > > So let's have these builtin, so as to both spare useless typing and useless > > testing. Removing the extra bound checking has the added benefit of making > > the > > code leaner, hence clearer. > > You cannot have what I did above built in. It was my mistake saying bounds > checking. Eh? Just insert a if (assignment done through head() && index > s->length) index = s->length; statement at the appropriate place (I don't have the source code available right now). That way yu differentiate between a raw slice assignment, which should err out, and a head() assignment that never does. > You want the following to err out, as it does currently, because Euphoria > already > does bounds checking (correct use of the term this time). > > }}} <eucode> > sequence s > s = "ABC" > puts(1, s[1..30]) > </eucode> {{{ > > That needs to err out, as it does. And I agree here. > > -- > Jeremy Cowgar > <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
22. Re: left, right? head, tail? which one?
- Posted by Jeremy Cowgar <jeremy at c?wga?.com> Apr 25, 2008
- 713 views
CChris wrote: > > > You cannot have what I did above built in. It was my mistake saying bounds > > checking. > > Eh? > Just insert a > > if (assignment done through head() && index > s->length) > index = s->length; > I'm probably confused as to what you were speaking about having built in. I thought you meant this:
sequence s s = "John" s = s[1..45] puts(1, s) -- "John"
From your last message, I see that was not the case. You too want the above code to err out. That is what I was saying cannot (or actually, shouldn't) be built in. -- Jeremy Cowgar http://jeremy.cowgar.com
23. Re: left, right? head, tail? which one?
- Posted by yuku <yuku at ikit?k.com> Apr 25, 2008
- 702 views
Jeremy Cowgar wrote: > Now, you can simply: > > }}} <eucode> > puts(1, head(s, 30)) > </eucode> {{{ > > This is so common of an operation, I am very surprised we are having this much > troubles agreeing on it's usefulness. It had been very useful to me! That is the 2nd function I wrote in my own stdlib file (aku.e) back in year 2000 after timer() -- a high resolution version of time().
24. Re: left, right? head, tail? which one?
- Posted by Kat <KAT12 at ?oo?ahs.net> Apr 25, 2008
- 731 views
> > }}} <eucode> > > sequence s > > s = "ABC" > > puts(1, s[1..30]) > > </eucode> {{{ > > > > That needs to err out, as it does. > > And I agree here. I don't. So s[4..30] don't exist, they just shouldn't be printed out. Otherwise, you haveto do:
if length(s) then -- so line 5 doesn't error if length(s) > 30 then puts(1,s[1..30] (5) else puts(1,s[1..length(s)] end if else puts(1,"") end if
And i vote for left/right, AND head/tail. Whichever is provided, i'll likely alias it to the word i prefer for that operation. Kat
25. Re: left, right? head, tail? which one?
- Posted by Jason Gade <jaygade at yah?o.c?m> Apr 25, 2008
- 711 views
Kat wrote: > > > > > }}} <eucode> > > > sequence s > > > s = "ABC" > > > puts(1, s[1..30]) > > > </eucode> {{{ > > > > > > That needs to err out, as it does. > > > > And I agree here. > > I don't. So s[4..30] don't exist, they just shouldn't be printed out. > Otherwise, > you haveto do: > > }}} <eucode> > if length(s) > then -- so line 5 doesn't error > if length(s) > 30 > then puts(1,s[1..30] > (5) else puts(1,s[1..length(s)] > end if > else puts(1,"") > end if > </eucode> {{{ > > And i vote for left/right, AND head/tail. Whichever is provided, i'll likely > alias it to the word i prefer for that operation. > > Kat Line 5 would not error out if you did it this way:
if length(s) > 30 then puts(1, s[1..30]) else puts(1, s) -- old line 5. I was going to use s[1..$] but that would have been redundant. end if
And if you are unsure whether s is a sequence then wrap it with if sequence(s). -- 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.