trim() and words() functions?
Gcomnz
information, but I used trim() as a function in a cookbook example,
then realized that it's not even in S29...
There is a brief mention of trim(), as well as words() (odd as the
words() function may seem, to me at least), at
http://tinyurl.com/6fjda but it hardly seems definitive.
Trim sure is handy and would get used a lot, I think. But boy do I
need to study up on my Unicode: I have such a hard time believing that
words() is practical for CJK. It sure would be cool I guess, if that
did work.
Any validation on whether either, both, or neither of those functions
is supposed to exist?
Just to throw another question in the works and perhaps gunk up the
machine, the link above also talks about whether or not these
functions would exist as methods to strings and arrays. I'm certainly
not clear on what the outcome of that is? I've been writing examples
as if that's a possibility and no one seems to be disputing those, so
I apologize if I just need to be pointed to where methods v functions
is clarified.
Perhaps a good "next" synopsis would be to start putting some docs
around the String and Array object methods? Again, sorry if I'm
missing that in some obvious location already.
Thanks!
Marcus
Rod Adams
>Hey all, not sure if I'm just missing some obvious source of
>information, but I used trim() as a function in a cookbook example,
>then realized that it's not even in S29...
>
>There is a brief mention of trim(), as well as words() (odd as the
>words() function may seem, to me at least), at
>http://tinyurl.com/6fjda but it hardly seems definitive.
>
>Trim sure is handy and would get used a lot, I think. But boy do I
>need to study up on my Unicode: I have such a hard time believing that
>words() is practical for CJK. It sure would be cool I guess, if that
>did work.
>
>Any validation on whether either, both, or neither of those functions
>is supposed to exist?
>
>
Well, some form of words() exists... only spelled q:w//, with various
doublings of q and w available, some of which can be spelled <> or 姣,
though to be honest, I've lost track of how often the meanings of those
as quoters has changed. I suspect S02 or S03 would have that answer.
As for whether or not these actually exist, I'd like a bit more
consensus that they are actually needed as builtins. One side of me says
"Hey, we've got them all seperated into different namespaces now, so
we're not really getting polluted, so sure, let's add anything that's in
the least bit useful". The other side of me then starts to say
"bloated". I'm not sure where the balance on this lies, and will yield
to the will of those better at language design than myself.
>Just to throw another question in the works and perhaps gunk up the
>machine, the link above also talks about whether or not these
>functions would exist as methods to strings and arrays. I'm certainly
>not clear on what the outcome of that is? I've been writing examples
>as if that's a possibility and no one seems to be disputing those, so
>I apologize if I just need to be pointed to where methods v functions
>is clarified.
>
>
Many of them will happen in S29, since there's an odd duality that class
based multi subs exist in. I don't pretend to fully understand it, but
look at http://www.nntp.perl.org/group/perl.perl6.language/19802 for
insight.
-- Rod Adams
Gcomnz
> a string into words" function, I was thinking to myself bloat, but
> then I was also reminding myself that Perl's power as a natural
> language text processor has always been a premium feature (somehow
> even prior to full Unicode).
On the other hand: words() as i (mis-)understood it, probably is
perfectly covered by Rules, sure does seem like bloat that's unlikely
to be in the final spec now that I continue thinking about it :)
Marcus Adair
Gcomnz
> Well, some form of words() exists... only spelled q:w//, with various
> though to be honest, I've lost track of how often the meanings of those
> as quoters has changed. I suspect S02 or S03 would have that answer.
I must have misunderstood the original discussion that I linked to.
When i saw words() I assumed words($string), and that it was a split
by 'words' function. Sorry if that was my dumb error.
I'm aware of q:w//, just didn't realize that's what I was seeing.
> As for whether or not these actually exist, I'd like a bit more
> consensus that they are actually needed as builtins. One side of me says
> "Hey, we've got them all seperated into different namespaces now, so
> we're not really getting polluted, so sure, let's add anything that's in
> the least bit useful". The other side of me then starts to say
> "bloated". I'm not sure where the balance on this lies, and will yield
> to the will of those better at language design than myself.
I agree, with my (probably wrong) impression that words() was a "split
a string into words" function, I was thinking to myself bloat, but
then I was also reminding myself that Perl's power as a natural
language text processor has always been a premium feature (somehow
even prior to full Unicode).
Marcus Adair
Larry Wall
: gcomnz wrote:
:
: >Hey all, not sure if I'm just missing some obvious source of
: >information, but I used trim() as a function in a cookbook example,
: >then realized that it's not even in S29...
: >
: >There is a brief mention of trim(), as well as words() (odd as the
: >words() function may seem, to me at least), at
: >http://tinyurl.com/6fjda but it hardly seems definitive.
: >
: >Trim sure is handy and would get used a lot, I think. But boy do I
: >need to study up on my Unicode: I have such a hard time believing that
: >words() is practical for CJK. It sure would be cool I guess, if that
: >did work.
A words() function would only be useful for space-separated CJK.
: >Any validation on whether either, both, or neither of those functions
: >is supposed to exist?
: >
: >
: Well, some form of words() exists... only spelled q:w//, with various
: doublings of q and w available, some of which can be spelled <> or «»,
: though to be honest, I've lost track of how often the meanings of those
: as quoters has changed. I suspect S02 or S03 would have that answer.
Yes, it's a dup of «$string», so we probably don't need words().
On the other hand, there's no trivially obvious way to trim whitespace
from both ends of a string. (Not that «$string» is *entirely*
obvious either...) Of course, generations of Perl programmers have
made do with various forms of s///, trudging miles through the snow,
uphill both ways.
: As for whether or not these actually exist, I'd like a bit more
: consensus that they are actually needed as builtins. One side of me says
: "Hey, we've got them all seperated into different namespaces now, so
: we're not really getting polluted, so sure, let's add anything that's in
: the least bit useful". The other side of me then starts to say
: "bloated". I'm not sure where the balance on this lies, and will yield
: to the will of those better at language design than myself.
Hmm, where there's a way, there's a will, I guess.
Larry
Juerd
> [words() and trim()]
I thought split'd still split on /\s+/ by default? $string.split is easy
to use, and because join uses ' ' by default (this is my interpretation
of the /lists in scalar context/ thread), $string.split.join trims all
excess whitespace, even between words. Handy :)
trim would be nice though, because I miss BASIC's ltrim and rtrim.
Perhaps those can be written as trim(:left) and trim(:right),
abbreviated to trim :l and trim :r?
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Terrence Brannon
> Of course, generations of Perl programmers have
> made do with various forms of s///,
I have found String::Strip on CPAN to work well for my needs in this
area.