String formatting and transformation
Dan Sugalski
string formatting and transformations. I know some folks have nudged
on this stuff, so lets get it going.
Here's a list of the string transformation stuff I think we need:
upcase
downcase
swapcase
upcase first letter
downcase first letter
And yes, I know these are meaningless for a good chunk of the encoded
data, but that's fine. If there are reasonable text transforms for
non-latin alphabets we can see about getting those in. If there's a
reason that the sequence "downcase/upcase first" is insufficient to
turn a string lower-case except for the first character someone speak
up and we'll add in a specialty entry for that.
As for formatting, I think we can reasonably provide both
sprintf-style formatting and more traditional COBOL-style formatting.
(Which, yes, I know, is generally viewed as nasty, but being able to
throw an integer into a "$(999,990.00)" format and get a nicely done
money display is really handy) I'm not, however, sure whether it's
worth making an op for one or both of these, or throwing them into
the standard library. (I can see a good case for building the
standard library into the Parrot executable as well, though I'm not
sure I want to do that as it'll make it tough to upgrade)
So, anyway, opinions?
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Pete Lomax
wrote:
>Well, this has been let slide far too long -- it's time to address
>string formatting and transformations. I know some folks have nudged
>on this stuff, so lets get it going.
>
>Here's a list of the string transformation stuff I think we need:
>
>upcase
>downcase
>swapcase
>upcase first letter
>downcase first letter
>
>And yes, I know these are meaningless for a good chunk of the encoded
>data, but that's fine. If there are reasonable text transforms for
>non-latin alphabets we can see about getting those in. If there's a
>reason that the sequence "downcase/upcase first" is insufficient to
>turn a string lower-case except for the first character someone speak
>up and we'll add in a specialty entry for that.
>
>As for formatting, I think we can reasonably provide both
>sprintf-style formatting and more traditional COBOL-style formatting.
>(Which, yes, I know, is generally viewed as nasty, but being able to
>throw an integer into a "$(999,990.00)" format and get a nicely done
>money display is really handy) I'm not, however, sure whether it's
Even the crummiest language that ever made the grade has a nice
feature or two...
>worth making an op for one or both of these, or throwing them into
>the standard library. (I can see a good case for building the
>standard library into the Parrot executable as well, though I'm not
>sure I want to do that as it'll make it tough to upgrade)
>
>So, anyway, opinions?
FWIW, I prefer the idea of a smaller, stable core and as much as
possible (performance/infrequently used based) out in a more easily
user-modifiable support file.
Of the above (IMO), up & downcase are core functions, the rest not.
Pete
PS If there is such a thing as the standard library, for Parrot, I
have not yet found it.
Pete Lomax
http://www.vendian.org/parrot/source/?op=pod2html&file=docs/overview.pod
I noticed
tmp.pod: cannot resolve L in paragraph 16. at Pod/Html.pm line 1575.
tmp.pod: cannot resolve L in paragraph 32. at Pod/Html.pm line 1575.
tmp.pod: cannot resolve L in paragraph 38. at Pod/Html.pm line 1575.
at the end of the page
Pete
Larry Wall
: Of the above (IMO), up & downcase are core functions, the rest not.
It's not so simple. Upcasing the first letter should really use the
Unicode title case mapping, not upper case. At least that's how
Perl 5 does it.
Larry