1. left, right? head, tail? which one?
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?
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?
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?
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
-
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
> > }}}
<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?
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.
