Re: Not a bug?
Ovid ():
$ perl6 -e 'my $foo = foo;say { ~ $foo ~ }'
~ foo ~
Easy solution: only use double quotes when you want to interpolate. :)
This is not really an option when running 'perl6 -e' under bash, though.
// Carl
Read access to class-scope variables from the class scope
Writing something like this in Rakudo yesterday, I was slightly
surprised to find it not working:
class SomeClass {
my $.warn_limit = 1000;
my $.stern_warn_limit = $.warn_limit * 1.05;
my $.expel_limit = $.warn_limit * 1.10;
# ...
}
The specific error from Rakudo is Lexical 'self' not found, which
translated into English means You're trying to access an object [the
protoobject] that doesn't exist yet.
I think that the above is a very reasonable way to declare class-scope
variables in Perl 6, and I just wanted to get confirmation that this
should in fact work in Perl 6. I don't see read access to class-scope
variables from the same class scope addressed in the specification.
// Carl
Re: Extending classes in a lexical scope?
Ovid wrote: Is it possible to modify the core Perl6Array class like that (without extra keywords)? If so, is it possible for each programmer to make such a change so that it's lexically scoped? AFAIK, it is not possible to modify a core class; however, I believe that it _is_ possible to derive a new class whose name differs from an existing class only in terms of version information, such that it is substituted for the original class within the lexical scope where it was defined, barring explicit inclusion of version information when the class is referenced. -- Jonathan Dataweaver Lang
Re: Not a bug?
On Mon, Jan 12, 2009 at 2:15 AM, Carl Mäsak cma...@gmail.com wrote:
Ovid ():
$ perl6 -e 'my $foo = foo;say { ~ $foo ~ }'
~ foo ~
Easy solution: only use double quotes when you want to interpolate. :)
This is not really an option when running 'perl6 -e' under bash, though.
$ perl6 -e 'my $foo = foo;say q:qq({ ~ $foo ~ })'
...or something to that effect.
--
Jonathan Dataweaver Lang
Re: [PATCH] Add .trim method
- Original Message From: Ovid publiustemp-perl6interna...@yahoo.com This patch implements the .trim() method for strings. Now that I'm reading S29, I see there is no .trim() method there. I got that because it was referenced in pugs in the cookbook (not in tests, though) and I was trying to get the examples to run. Bummer :( Sorry for constant spamming, but now that I've put disparate pieces together, I see what's going on here. I'll stop soon, but I am *sick* of rewriting the trim() function over and over :) There are no tests because it's not in the spec. If there's a spec, I know where to write the tests and will happily commit tests for them to Pugs and I'll submit a new patch against any-str.pir and t/spectest.data to get them to pass. http://tinyurl.com/4xjnh, a mailing list thread where Larry wrote: : (Replying to p6l instead of p6c as requested.) : : On Mon, Apr 04, 2005 at 10:39:16AM -0700, Larry Wall wrote: : (Now that builtins are just functions out in * space, we can probably : afford to throw a few more convenience functions out there for common : operations like word splitting and whitespace trimming. (Specific : proposals to p6l please.)) So even though it's not in the spec, it seems like something Larry is not entirely opposed to (or wasn't back in 2005). So here's my proposal (copied to p6l): =item trim our Str multi Str::trim ( Str $string ) Removes leading and trailing whitespace from a string. =cut I could optionally make the following work: $string.trim(:leading0); $string.trim(:trailing0); Setting leading or trailing to false (they default to true) would result in either leading or trailing whitespace not being trimmed. Setting both to false would be a no-op. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: [PATCH] Add .trim method
Ovid (): =item trim our Str multi Str::trim ( Str $string ) Removes leading and trailing whitespace from a string. =cut I could optionally make the following work: $string.trim(:leading0); $string.trim(:trailing0); Setting leading or trailing to false (they default to true) would result in either leading or trailing whitespace not being trimmed. Setting both to false would be a no-op. Unless someone protests loudly, I can add this to S29, and I (or someone else with tuits) can implement it in Rakudo. // Carl
Re: [PATCH] Add .trim method
- Original Message =item trim our Str multi Str::trim ( Str $string ) Removes leading and trailing whitespace from a string. =cut I could optionally make the following work: $string.trim(:leading0); $string.trim(:trailing0); Setting leading or trailing to false (they default to true) would result in either leading or trailing whitespace not being trimmed. Setting both to false would be a no-op. Unless someone protests loudly, I can add this to S29, and I (or someone else with tuits) can implement it in Rakudo. I've already submitted a patch for Rakudo which implements this for the trivial $string.trim and trim($string) case. The optional :leading and :trailing parameters aren't there. I'm happy to finish the work according to whatever spec is agreed upon. I want this badly enough that it's important to me :) Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: [PATCH] Add .trim method
- Original Message I could optionally make the following work: $string.trim(:leading0); $string.trim(:trailing0); Alternatively, those could be ltrim() and rtrim(). If you need to dynamically determine what you're going to trim, you'd couldn't just set variables to do it, though. You'd have to figure out which methods to call. Or all could be allowed and $string.trim(:leading0) could all $string.rtrim internally. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: [PATCH] Add .trim method
* Ovid publiustemp-perl6langua...@yahoo.com [2009-01-12 16:05]: Or all could be allowed and $string.trim(:leading0) could all $string.rtrim internally. ++ Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: [PATCH] Add .trim method
Aristotle Pagaltzis wrote: * Ovid publiustemp-perl6langua...@yahoo.com [2009-01-12 16:05]: Or all could be allowed and $string.trim(:leading0) could all $string.rtrim internally. ++ Note you can write it :!leading too. :-) Jonathan
Re: Not a bug?
On Sun, Jan 11, 2009 at 04:41:12PM -0800, Ovid wrote:
I really don't think this is a bug, but it did confuse the heck out of me at
first. This *is* expected behavior due to how {} is interpolated in strings,
yes?
$ perl6 -e 'my $foo = foo;say ~ $foo ~ '
foo
$ perl6 -e 'my $foo = foo;say { ~ $foo ~ }'
~ foo ~
I presume string interpolation is, er, set-up, at compile-time.
So it only happened here because { ~ $foo ~ } was rewritten to
{$foo} at compile-time. And if { and } were replaced with
variables, for example, then the interpolation wouldn't have happened.
Right?
Tim.
Re: [PATCH] Add .trim method
On Mon, Jan 12, 2009 at 05:04:50AM -0800, Ovid wrote: : ...the trivial $string.trim and trim($string) case. Hmm, I'd think .trim should work like .chomp, and return the trimmed string without changing the original. You'd use $str.=trim to do it in place. Can't say I really like the negated options though. They smell funny. Larry
Re: [PATCH] Add .trim method
Ovid wrote: - Original Message In the pir, doesn't the s = self line copy self, thus ensuring that I'm changing s and not self? No, it's binding. Or do I need s = clone self (or however it's written). Yeah, but also note that substr would return a copy... Can't say I really like the negated options though. They smell funny. Agreed, but ltrim and rtrim will disappoint Israelis and dyslexics alike. Suggestions welcome as I can't think of anything better. The .Net framework calls 'em TrimStart and TrimEnd (and has a Trim that does both). So maybe trim_start and trim_end if we wanted to take that lead... Jonathan
Re: [PATCH] Add .trim method
Jonathan (), Ovid (), Larry (): Can't say I really like the negated options though. They smell funny. Agreed, but ltrim and rtrim will disappoint Israelis and dyslexics alike. Suggestions welcome as I can't think of anything better. The .Net framework calls 'em TrimStart and TrimEnd (and has a Trim that does both). So maybe trim_start and trim_end if we wanted to take that lead... How about .trim(:start) and .trim(:end)? // Carl
Re: [PATCH] Add .trim method
On Mon, 2009-01-12 at 07:01 -0800, Ovid wrote: - Original Message I could optionally make the following work: $string.trim(:leading0); $string.trim(:trailing0); Alternatively, those could be ltrim() and rtrim(). If you need to dynamically determine what you're going to trim, you'd couldn't just set variables to do it, though. You'd have to figure out which methods to call. Or all could be allowed and $string.trim(:leading0) could all $string.rtrim internally. When I saw your proposed syntax above, instead of reading don't trim leading/trailing whitespace, I read change the definition of 'whitespace' to 'codepoint 0' for leading/trailing. That of course raises the question of how one *would* properly override trim's concept of whitespace -'f
Re: [PATCH] Add .trim method
- Original Message Agreed, but ltrim and rtrim will disappoint Israelis and dyslexics alike. Suggestions welcome as I can't think of anything better. The .Net framework calls 'em TrimStart and TrimEnd (and has a Trim that does both). So maybe trim_start and trim_end if we wanted to take that lead... How about .trim(:start) and .trim(:end)? So if: 1. No params, trim all 2. :start or :end, only trim that bit (not a negated option :) 3. If both, goto 1 Sound good? Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: [PATCH] Add .trim method
- Original Message From: Geoffrey Broadwell ge...@broadwell.org When I saw your proposed syntax above, instead of reading don't trim leading/trailing whitespace, I read change the definition of 'whitespace' to 'codepoint 0' for leading/trailing. That of course raises the question of how one *would* properly override trim's concept of whitespace Change your locale to one with a different concept of whitespace (are there any?) Otherwise, would this be trying to stuff too much into one function? Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: [PATCH] Add .trim method
On Mon, Jan 12, 2009 at 09:33:32AM -0800, Geoffrey Broadwell wrote: : That of course raises the question of how one *would* properly override : trim's concept of whitespace Well, given that .trim is essentially just .comb(/\S.*\S/), which in turn is really just m:g/(\S.*\S)/, I don't see much need for alternate trimmings. Larry
Re: [PATCH] Add .trim method
Larry Wall wrote: On Mon, Jan 12, 2009 at 05:04:50AM -0800, Ovid wrote: : ...the trivial $string.trim and trim($string) case. Hmm, I'd think .trim should work like .chomp, and return the trimmed string without changing the original. You'd use $str.=trim to do it in place. Can't say I really like the negated options though. They smell funny. Larry I'm +1 on adding a trim, I do a lot of csv import (with trimming) in perl 5. On a side note, between modifying the original and returning a fixed string, which one would we expect to be faster? And I assume either would be faster than the regex method of trimming? -Andy
Re: [PATCH] Add .trim method
* Ovid publiustemp-perl6langua...@yahoo.com [2009-01-12 18:40]: 1. No params, trim all 2. :start or :end, only trim that bit (not a negated option :) 3. If both, goto 1 Also `:!start` to imply `:end` unless `:!end` (which in turn implies `:start` unless `:!end`)? I’d like not to have to type `.trim(:start)` when I could just do `.ltrim` though. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: [PATCH] Add .trim method
On Mon, Jan 12, 2009 at 2:50 PM, Aristotle Pagaltzis pagalt...@gmx.de wrote: I'd like not to have to type `.trim(:start)` when I could just do `.ltrim` though. As long as we gloss .ltrim as leading trim rather than left trim. Then the other end could be .ttrim for trailing? We really ought to avoid using left and right to refer to the beginning and end of text strings. -- Mark J. Reed markjr...@gmail.com
Re: [PATCH] Add .trim method
- Original Message Also `:!start` to imply `:end` unless `:!end` (which in turn implies `:start` unless `:!end`)? I’d like not to have to type `.trim(:start)` when I could just do `.ltrim` though. So what would .ltrim do with this? בָּרוּךְ שֵׁם כְּבוֹד מַלְכוּתוֹ לְעוֹלָם וָעֶד. If you can't see that in your client, that's Hebrew from http://www.i18nguy.com/unicode/shma.html and means Hear O Israel, the Lord is our God, the Lord is One. Since that's RTL (Right To Left) text, should ltrim remove the leading or trailing whitespace? I like Jonathan's trim_start and trim_end. Side note: I'm implementing the tests now, but only for bog-standard .trim. I won't do the rest until we settle this. So far I only have one failing test: is_deeply(trim(()), (), trim on empty list); Results in: not ok 10 - trim on empty list # have: # want: [] Note that this output is from my locally hacked version of Test.pm which is kind enough to tell you what the failure is. I'll submit a patch for that later. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: [PATCH] Add .trim method
* Aristotle Pagaltzis pagalt...@gmx.de [2009-01-12 20:55]: Also `:!start` to imply `:end` unless `:!end` (which in turn implies `:start` unless `:!end`)? Ugh, forget this, I was having a blank moment. Actually that makes me wonder now whether it’s actually a good idea at all to make the function parametrisable at all. Even `.ltrim.rtrim` is shorter and easier than `.trim(:start,:end)`! Plus if there are separate `.ltrim` and `.rtrim` functions it would be better to implement `.trim` by calling them rather than vice versa, so it wouldn’t even be less efficient two make two calls rather than a parametrised one. And if anyone really needs to be able to decide the trimming based on flags, they can do that themselves with `.ltrim`/ `.rtrim` with rather little code anyway. So I question the usefulness of parametrisation here. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: [PATCH] Add .trim method
* Ovid publiustemp-perl6langua...@yahoo.com [2009-01-12 21:20]: Since that's RTL (Right To Left) text, should ltrim remove the leading or trailing whitespace? I like Jonathan's trim_start and trim_end. Let me ask you first: does a string that runs Right-to-Left start at the left and end at the right or start at the right and end at the left? Now to answer your question, *I* know where the *left* side is in a string that runs from right to left: it’s at the *left*, same as if the string ran from the left to the right, because left is at the *left*. :-) I mean, if the the meaning of “left” was inverted by “right-to-left”, in which it is contained, then what does the latter even mean? (OK, we’re on a Perl 6 list so I guess the answer is it’s a juction… :-) ) Clearly one of us has an inversed sense of which pair of terms is ambiguous, and I don’t think it’s me… ;-) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: [PATCH] Add .trim method
On Mon, Jan 12, 2009 at 09:18:03PM +0100, Aristotle Pagaltzis wrote: : Plus if there are separate `.ltrim` and `.rtrim` functions it : would be better to implement `.trim` by calling them rather than : vice versa, so it wouldn’t even be less efficient two make two : calls rather than a parametrised one. Depends on your string implementation if they're non-destructive, since they potentially have to copy the middle of the string twice if your implementation can't support one string pointing into the middle of another. And again, I think .trim should be non-destructive, and .=trim should be the destructive version. Larry
Re: [PATCH] Add .trim method
Aristotle Pagaltzis wrote: Actually that makes me wonder now whether it’s actually a good idea at all to make the function parametrisable at all. Even `.ltrim.rtrim` is shorter and easier than `.trim(:start,:end)`! How about .trim(:l, :r) with both as the default? And if the rtl crowd makes a furor, we can add :a/:o or :ת/:א or something. So I question the usefulness of parametrisation here. Useful for doing infrequent things. IMO, left and right trimming are infrequent compared to the frequency of basic input editing. =Austin
Re: [PATCH] Add .trim method
- Original Message From: Aristotle Pagaltzis pagalt...@gmx.de I like Jonathan's trim_start and trim_end. Let me ask you first: does a string that runs Right-to-Left start at the left and end at the right or start at the right and end at the left? Now to answer your question, *I* know where the *left* side is in a string that runs from right to left: it’s at the *left*, same as if the string ran from the left to the right, because left is at the *left*. :-) I see your point, but it complicates the internals of the trim method because then I have to detect if a string is RTL and reverse it, then unreverse it when done (or something conceptually similar). I'd rather not toss in said complications for a problem space I don't know very well. On the other hand, this is a core feature, not a quick CPAN jobbie, so it's important to get it RIGHT or it will be LEFT out. (I kill me. I really do :) Beers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: [PATCH] Add .trim method
* Larry Wall la...@wall.org [2009-01-12 21:55]: * Aristotle Pagaltzis pagalt...@gmx.de [2009-01-12 21:20]: Plus if there are separate `.ltrim` and `.rtrim` functions it would be better to implement `.trim` by calling them rather than vice versa, so it wouldn’t even be less efficient two make two calls rather than a parametrised one. Depends on your string implementation if they're non-destructive, since they potentially have to copy the middle of the string twice if your implementation can't support one string pointing into the middle of another. And again, I think .trim should be non-destructive, and .=trim should be the destructive version. Sure, but that doesn’t affect my point: if `.trim` is implemented as calling `.ltrim` + `.rtrim`, as I assumed, then all ways of trimming a string at both ends will be equally efficient or inefficient depending on whether or not the implementation supports offsetted strings. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Not a bug?
On Mon, Jan 12, 2009 at 03:43:47AM -0800, Jon Lang wrote:
: On Mon, Jan 12, 2009 at 2:15 AM, Carl Mäsak cma...@gmail.com wrote:
: Ovid ():
: $ perl6 -e 'my $foo = foo;say { ~ $foo ~ }'
:~ foo ~
:
: Easy solution: only use double quotes when you want to interpolate. :)
:
: This is not really an option when running 'perl6 -e' under bash, though.
:
: $ perl6 -e 'my $foo = foo;say q:qq({ ~ $foo ~ })'
:
: ...or something to that effect.
Assuming that's what was wanted. I figgered they want something more
like:
$ perl6 -e 'my $foo = foo; say q[{] ~ $foo ~ q[}];'
Larry
Re: [PATCH] Add .trim method
* Ovid publiustemp-perl6langua...@yahoo.com [2009-01-12 22:05]: I see your point And now I see yours. I was visualising the memory layout of a string, wherein a right-to-left string gets displayed from the right end of it’s in-memory representation so “left” and “right” are absolutes in that picture. But of course RTL reverses the relation of left/right in memory and left/right on screen. I think a week’s worth of wolf sleep is catching up to me, sorry. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Not a bug?
On Mon, Jan 12, 2009 at 1:08 PM, Larry Wall la...@wall.org wrote:
On Mon, Jan 12, 2009 at 03:43:47AM -0800, Jon Lang wrote:
: On Mon, Jan 12, 2009 at 2:15 AM, Carl Mäsak cma...@gmail.com wrote:
: Ovid ():
: $ perl6 -e 'my $foo = foo;say { ~ $foo ~ }'
:~ foo ~
:
: Easy solution: only use double quotes when you want to interpolate. :)
:
: This is not really an option when running 'perl6 -e' under bash, though.
:
: $ perl6 -e 'my $foo = foo;say q:qq({ ~ $foo ~ })'
:
: ...or something to that effect.
Assuming that's what was wanted. I figgered they want something more
like:
$ perl6 -e 'my $foo = foo; say q[{] ~ $foo ~ q[}];'
True enough. Either one of these would be more clear than the
original example in terms of user intent.
As well, isn't there a way to escape a character that would otherwise
be interpolated? If the intent were as you suppose, the original
could be rewritten as:
$ perl6 -e 'my $foo = foo;say \{ ~ $foo ~ }'
(Or would you need to escape the closing curly brace as well as the
opening one?)
--
Jonathan Dataweaver Lang
Re: [PATCH] Add .trim method
* Austin Hastings austin_hasti...@yahoo.com [2009-01-12 22:00]: How about .trim(:l, :r) with both as the default? Liveable. And if the rtl crowd makes a furor, we can add :a/:o or :ת/:א or something. *grin* Maybe :h and :t (head/tail). Useful for doing infrequent things. IMO, left and right trimming are infrequent compared to the frequency of basic input editing. Good point, rings true. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: [PATCH] Add .trim method
- Original Message From: Aristotle Pagaltzis pagalt...@gmx.de * Austin Hastings [2009-01-12 22:00]: How about .trim(:l, :r) with both as the default? Liveable. I've just committed the pugs tests for trim. However, it's just 'trim' with no left/right, leading/trailing, Catholic/Protestant implementation. I'll submit a patch for trim with the spectest data updated and work on the rest after the dust settles. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: [PATCH] Add .trim method
- Original Message From: jesse je...@fsck.com On Mon, Jan 12, 2009 at 07:01:25AM -0800, Ovid wrote: I could optionally make the following work: $string.trim(:leading0); $string.trim(:trailing0); Alternatively, those could be ltrim() and rtrim(). 'left' and 'right' are probably not the right names for functions which trim leading and/or trailing space, since their meanings get somewhat ambiguous if a language renders right-to-left instead of left-to-right or vice-versa Um, er. Damn. Now I'm wondering how my leading and trailing trimming works with Hebrew. How are the strings implemented internally? And then there are languages such as Manchu and Uygher which can be written vertically. http://www.omniglot.com/writing/direction.htm Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: [PATCH] Add .trim method
On 2009-01-12 Ovid publiustemp-perl6interna...@yahoo.com wrote: Um, er. Damn. Now I'm wondering how my leading and trailing trimming works with Hebrew. How are the strings implemented internally? RTL (and bidi) languages are written in strings so that the character order is the logical, reading, order. That is, the character nearer to the beginning of the string is the first one to be read by a human reader (so, such character would be displayed on the right for a RTL language, on the left for a LTR language, at the top for a TTB language) Short answer: your implementation is right :) -- Dakkar - Mobilis in mobile GPG public key fingerprint = A071 E618 DD2C 5901 9574 6FE2 40EA 9883 7519 3F88 key id = 0x75193F88 You possess a mind not merely twisted, but actually sprained. signature.asc Description: PGP signature
Re: [PATCH] Add .trim method
On Mon, Jan 12, 2009 at 9:01 AM, Ovid publiustemp-perl6langua...@yahoo.comwrote: - Original Message I could optionally make the following work: $string.trim(:leading0); $string.trim(:trailing0); Alternatively, those could be ltrim() and rtrim(). If you need to dynamically determine what you're going to trim, you'd couldn't just set variables to do it, though. You'd have to figure out which methods to call. Or all could be allowed and $string.trim(:leading0) could all $string.rtrim internally. If I were going to have ltrim() and rtrim(), I'd implement them in terms of trim() rather than the other way around. -Scott -- Jonathan Scott Duff perlpi...@gmail.com
Re: [PATCH] Add .trim method
- Original Message From: Larry Wall la...@wall.org On Mon, Jan 12, 2009 at 05:04:50AM -0800, Ovid wrote: : ...the trivial $string.trim and trim($string) case. Hmm, I'd think .trim should work like .chomp, and return the trimmed string without changing the original. You'd use $str.=trim to do it in place. In the pir, doesn't the s = self line copy self, thus ensuring that I'm changing s and not self? Or do I need s = clone self (or however it's written). Can't say I really like the negated options though. They smell funny. Agreed, but ltrim and rtrim will disappoint Israelis and dyslexics alike. Suggestions welcome as I can't think of anything better. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: [PATCH] Add .trim method
Ovid wrote: $string.trim(:leading0); $string.trim(:trailing0); Setting leading or trailing to false (they default to true) would result in either leading or trailing whitespace not being trimmed Alternatively, those could be ltrim() and rtrim(). If you need to dynamically determine what you're going to trim, you'd couldn't just set variables to do it, though. You'd have to figure out which methods to call. Or all could be allowed and $string.trim(:leading0) could all $string.rtrim internally. I like having the options, I think. If the default value of :trailing was /ws*/, then someone could change it to /ws*\#\N*/ to chomp trailing line comments. (Assuming they don't simply redefine the ws token)
Re: Not a bug?
On Mon, Jan 12, 2009 at 01:19:12PM -0800, Jon Lang wrote:
: As well, isn't there a way to escape a character that would otherwise
: be interpolated? If the intent were as you suppose, the original
: could be rewritten as:
:
: $ perl6 -e 'my $foo = foo;say \{ ~ $foo ~ }'
Sure, though in any case I'd probably prefer:
$ perl6 -e 'my $foo = foo; say Qs/{$foo}/'
: (Or would you need to escape the closing curly brace as well as the
: opening one?)
Not unless something outside of it all was attempting to count braces.
But the P6 parser has sworn off all such activities for P6-derived
code. Parsing something first as a string and then again as some
other language is generally looked upon as a Bad Plan these days.
Which is, of course, why { is a problem now. Perhaps use of nested
double quotes deserves a warning.
Larry
Re: [PATCH] Add .trim method
On Mon, Jan 12, 2009 at 07:01:25AM -0800, Ovid wrote: I could optionally make the following work: $string.trim(:leading0); $string.trim(:trailing0); Alternatively, those could be ltrim() and rtrim(). 'left' and 'right' are probably not the right names for functions which trim leading and/or trailing space, since their meanings get somewhat ambiguous if a language renders right-to-left instead of left-to-right or vice-versa -jesse
Re: [PATCH] Add .trim method
On Jan 12, 2009, at 11:27 AM, Carl Mäsak wrote: How about .trim(:start) and .trim(:end)? And .trim(:both) for orthogonality. -- Andy Lester = a...@petdance.com = www.petdance.com = AIM:petdance
Re: Extending classes in a lexical scope?
- Original Message
From: Moritz Lenz mor...@faui2k3.org
That is the preferred way to avoid action-at-a-distance in P6.
so if I do that, will a 'my @a' use that new Array class?
Actually I'd prefer it if there were some kind of mechanism to set a
default implementation type, so that I could write something along these
lines:
class MyArray is Array { ... }
use Container :Array;
then is this lexical scope all Array declarations and all Prelude
operations that return Arrays return one of the type that I specified.
Actually, I'd prefer to go much further than this:
use Core 'MyCore';
And have that override core classes lexically.
That solves the but I want it MY way issue that many Perl and Ruby
programmers have, but they don't shoot anyone else in the foot.
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: [PATCH] Add .trim method
Carl Mäsak wrote: Jonathan (), Ovid (), Larry (): Can't say I really like the negated options though. They smell funny. Agreed, but ltrim and rtrim will disappoint Israelis and dyslexics alike. Suggestions welcome as I can't think of anything better. The .Net framework calls 'em TrimStart and TrimEnd (and has a Trim that does both). So maybe trim_start and trim_end if we wanted to take that lead... How about .trim(:start) and .trim(:end)? That would be my favourite: our Str multi method trim (Str $string:, :start = True, :end = True) So $str.=trim would trim both start and end, and if you want only one, you can say $str.=trim(:!end);. Cheers, Moritz
Trimming arrays
What should this output? my @array = ' foo ', ' bar '; @array .= trim; say @array.perl; And what if I have an array of hashes of hashes of arrays? Currently you can call 'trim' on arrays, but it's a no-op. Similar issues with chomp and friends. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: Trimming arrays
On Mon, Jan 12, 2009 at 03:05:21PM -0800, Ovid wrote: : What should this output? : : my @array = ' foo ', ' bar '; : @array .= trim; : : say @array.perl; : : And what if I have an array of hashes of hashes of arrays? : : Currently you can call 'trim' on arrays, but it's a no-op. Similar issues with chomp and friends. It should probably say No such method. We have hyperops now to apply scalar operators to composite values explicitly: @array».=trim Larry
Re: Trimming arrays
- Original Message From: Larry Wall la...@wall.org : my @array = ' foo ', ' bar '; : @array .= trim; : : say @array.perl; : : And what if I have an array of hashes of hashes of arrays? : : Currently you can call 'trim' on arrays, but it's a no-op. Similar issues with chomp and friends. It should probably say No such method. We have hyperops now to apply scalar operators to composite values explicitly: @array».=trim Won't that fail with 'No such method' on an array of hashes? Or are hyperops applied recursively? Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: [PATCH] Add .trim method
On Mon, Jan 12, 2009 at 06:36:55PM +0100, Moritz Lenz wrote:
: Carl Mäsak wrote:
: Jonathan (), Ovid (), Larry ():
: Can't say I really like the negated options though. They smell funny.
:
: Agreed, but ltrim and rtrim will disappoint Israelis and dyslexics alike.
: Suggestions welcome as I can't think of anything better.
:
: The .Net framework calls 'em TrimStart and TrimEnd (and has a Trim that
does
: both). So maybe trim_start and trim_end if we wanted to take that lead...
:
: How about .trim(:start) and .trim(:end)?
:
: That would be my favourite:
:
: our Str multi method trim (Str $string:, :start = True, :end = True)
Er, that would make .trim(:start) also default :end to True...
Well, except it won't parse either. For at least two reasons. :)
: So $str.=trim would trim both start and end, and if you want only one,
: you can say $str.=trim(:!end);.
HEY! Don't ignore my nose. At least, not this time. :)
Switches should almost never default to true. It's more like:
our Str multi method trim (Str $string:
:$start = False,
:$end = False,
:$both = not $start || $end)
or really, since start/end really mean startonly/endonly:
our Str multi method trim (Str $string:
:start($start_only) = False,
:end($end_only) = False)
{
my $do_start = not $end_only;
my $do_end = not $start_only;
...
}
I really shouldn't be participating in the bikeshedding though...
Larry
Re: Extending classes in a lexical scope?
Ovid wrote: Actually, I'd prefer to go much further than this: use Core 'MyCore'; And have that override core classes lexically. That solves the but I want it MY way issue that many Perl and Ruby programmers have, but they don't shoot anyone else in the foot. Since 'use' imports its elements into the current lexical scope, the version-based approach can do this. The only catch that I can think of has to do with derived classes: does the existence of a customized version of a class result in same-way-customized versions of the classes that are derived from the original class? That is, if I added an updated version of Foo, and Bar has previously been defined as being derived from Foo, would I get a default updated version of Bar as well? Or would I have to explicitly update each derived class to conform to the updated base class? -- Jonathan Dataweaver Lang
Re: Extending classes in a lexical scope?
- Original Message From: Jon Lang datawea...@gmail.com Actually, I'd prefer to go much further than this: use Core 'MyCore'; And have that override core classes lexically. That solves the but I want it MY way issue that many Perl and Ruby programmers have, but they don't shoot anyone else in the foot. Since 'use' imports its elements into the current lexical scope, the version-based approach can do this. The only catch that I can think of has to do with derived classes: does the existence of a customized version of a class result in same-way-customized versions of the classes that are derived from the original class? That is, if I added an updated version of Foo, and Bar has previously been defined as being derived from Foo, would I get a default updated version of Bar as well? Or would I have to explicitly update each derived class to conform to the updated base class? I'm not sure I understand you. If 'Bar' inherits from 'Foo' and 'Foo' has extended the core Array class to lexically implement a .shuffle method, then I would expect 'Bar' to have that also. There are two things involved: 1. Liskov should be respected, when appropriate (http://www.oreillynet.com/onlamp/blog/2008/02/the_liskov_substitution_princi.html) 2. 'Bar' is coupled to 'Foo' and needs to know 'Foo's implementation (a charming anti-inheritance argument). See #1 :) Or did you mean something completely different? Note that Liskov is great, but has issues at times when composition is unclear. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: [PATCH] Add .trim method
On Mon, Jan 12, 2009 at 9:07 AM, jesse je...@fsck.com wrote: 'left' and 'right' are probably not the right names for functions which trim leading and/or trailing space, since their meanings get somewhat ambiguous if a language renders right-to-left instead of left-to-right or vice-versa I'm in favor of using the proposed syntax, but I will agree with lwall that it seems like overkill to have the specialized trims. .trim should be non-destructive and .=trim should be destructive (these seems intuitive). Some languages run in the direction of left-to-right, some in the direction right-to-left (some even top-to-bottom). No matter what language you speak or which direction your native language reads, left is the same for everyone as well as right. If we wanted to simplify matters, use :left, :right and :both. Those have the same meaning everywhere. If we wanted language dependent version, use :leading, :trailing, and :both. That will require each implementation properly handle the language variations. By the way, good work on this. Everyone loves useful string functions. -Jason s1n Switzer
Trimming; left or start? (was: Re: [PATCH] Add .trim method)
Can I make a suggestion? From my point of view, it'd be nice if the trim method supported: - left/right (leftmost/rightmost part of the string; language-independent) - start/end (start and end of string; could be leading/trailing instead) - both How would that work? :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
Re: [PATCH] Add .trim method
- Original Message From: jason switzer jswit...@gmail.com If we wanted language dependent version, use :leading, :trailing, and :both. That will require each implementation properly handle the language variations. I think :start and :end are my favorites. Huffman++ (maybe :begin and :end for consistency?). Still raises the question of what to do with arrays of hashes of arrays with @array .= trim; I can't trim keys of pairs because they're used as unique identifiers in hashes and conflicts will occur. So recursive trimming needs have a special case for keys or it needs to not be allowed (and thus fail with AoHoA and similar complex data structures). By the way, good work on this. Everyone loves useful string functions. Thanks. It's been lots of fun :) Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: Not a bug?
On Mon, Jan 12, 2009 at 3:54 PM, Larry Wall la...@wall.org wrote:
On Mon, Jan 12, 2009 at 01:19:12PM -0800, Jon Lang wrote:
: As well, isn't there a way to escape a character that would otherwise
: be interpolated? If the intent were as you suppose, the original
: could be rewritten as:
:
: $ perl6 -e 'my $foo = foo;say \{ ~ $foo ~ }'
Sure, though in any case I'd probably prefer:
$ perl6 -e 'my $foo = foo; say Qs/{$foo}/'
: (Or would you need to escape the closing curly brace as well as the
: opening one?)
Not unless something outside of it all was attempting to count braces.
But the P6 parser has sworn off all such activities for P6-derived
code. Parsing something first as a string and then again as some
other language is generally looked upon as a Bad Plan these days.
Which is, of course, why { is a problem now. Perhaps use of nested
double quotes deserves a warning.
masak++ was right, if you use single quotes it works properly. Here's how
you do it from a bash prompt:
$ ./perl6 -e 'my $foo = '\''foo'\''; say '\''{'\'' ~ $foo ~ '\''}'\'' '
{foo}
Notice the overly redundant single-quotes; in fact, all of those quotes are
single quotes.
-Jason s1n Switzer
Re: Extending classes in a lexical scope?
On Mon, Jan 12, 2009 at 02:43:37PM -0800, Ovid wrote: : Actually, I'd prefer to go much further than this: : : use Core 'MyCore'; : : And have that override core classes lexically. We're already speccing a way to substitute a different prelude from the command line, in order to desugar -n and -p switches. There could certainly be a use-ish way to do that too. And maybe substitute is the wrong concept here. It probably needs to be nestable, so that we are installing an additional lexical wrapper outside the current scope, but inside whatever the previous prelude scope provided. Maybe call it underriding instead of overriding. :) So given something like: #!/usr/bin/perl6 -p use prelude MyPrelude; Then OUTER of MyPrelude might be a -p looping scope, and OUTER of the -p scope might be the standard Perl 6 Prelude. And this happens a compilation time, so the compiler knows while it's parsing that any reference to Array mean MyArray, including any implicit references. The mechanism by which we freeze a snapshot of the language (nice mixed metaphor there) for the prelude is also the mechanism by which we freeze a snapshot so we know what language eval() defaults to. It doesn't default to standard Perl 6, but rather the language existing at the moment the eval is compiled, which might have little resemblence to standard Perl 6. I really do believe in lexically-scoped language mutations: it's not just a bullet point--it's what Perl 6 is Really All About, in my ever-so-humble opinion. To make that work right, every part of your lexical scope needs to know *exactly* what language it's in, including the parts that are intentionally inexact; any parts of the language that are generic need to be explicitly parameterized, not nebulously defined by some environment variable or by some rc file or even by the current perl implementation. As far as I'm concerned, everything else about Perl 6 is a bikeshed in comparison, because everything else about Perl 6 can change gracefully over time if we get this part right. The current lexical context determines the types that are visible, as well as the multimethods that are visible on those types, including the operations used to parse and mutute the language itself. Seems simple enough... :) Larry
Re: Extending classes in a lexical scope?
Ovid wrote: - Original Message From: Jon Lang datawea...@gmail.com Actually, I'd prefer to go much further than this: use Core 'MyCore'; And have that override core classes lexically. That solves the but I want it MY way issue that many Perl and Ruby programmers have, but they don't shoot anyone else in the foot. Since 'use' imports its elements into the current lexical scope, the version-based approach can do this. The only catch that I can think of has to do with derived classes: does the existence of a customized version of a class result in same-way-customized versions of the classes that are derived from the original class? That is, if I added an updated version of Foo, and Bar has previously been defined as being derived from Foo, would I get a default updated version of Bar as well? Or would I have to explicitly update each derived class to conform to the updated base class? I'm not sure I understand you. If 'Bar' inherits from 'Foo' and 'Foo' has extended the core Array class to lexically implement a .shuffle method, then I would expect 'Bar' to have that also. No, you don't understand me. The Foo/Bar example I was giving was independent of your example. Rephrasing in your terms, consider the possibility of a class that's derived from Array, for whatever reason; call it Ring. Now you decide that you want to redefine Array to include a shuffle method, and so you implement an Array version 2.0. Would you be given a Ring version 2.0 that derives from Array version 2.0, or would you have to explicitly ask for it? As long as you limit your use of class inheritance, the above remains manageable. But consider something like the Tk widgets implemented as a class hierarchy; then consider what happens if you reversion one of the root widgets. If you manually have to reversion each and every widget derived from it, and each and every widget derived from those, and so on and so forth, in order for your changes to the root to propagate throughout the class hierarchy... Instead, I'd rather see an approach where you need only reversion the base class and those specific derived classes where problems would otherwise arise due to your changes. -- Jonathan Dataweaver Lang
Re: [PATCH] Add .trim method
On Mon, Jan 12, 2009 at 6:26 PM, Ovid publiustemp-perl6langua...@yahoo.comwrote: - Original Message From: jason switzer jswit...@gmail.com If we wanted language dependent version, use :leading, :trailing, and :both. That will require each implementation properly handle the language variations. I think :start and :end are my favorites. Huffman++ (maybe :begin and :end for consistency?). My best advise is to keep it consistant. .chomp makes references to chomping from the end, not the trailing. .substr makes reference to start. I think that's better to just find terminology that has already been agreed upon and keep abusing it.
Re: Extending classes in a lexical scope?
On Mon, Jan 12, 2009 at 04:38:07PM -0800, Jon Lang wrote: : No, you don't understand me. The Foo/Bar example I was giving was : independent of your example. Rephrasing in your terms, consider the : possibility of a class that's derived from Array, for whatever reason; : call it Ring. Now you decide that you want to redefine Array to : include a shuffle method, and so you implement an Array version 2.0. : Would you be given a Ring version 2.0 that derives from Array : version 2.0, or would you have to explicitly ask for it? When a Ring object refers to Array that reference is supposed to be virtual, so at least going that direction, the Ring object will be implemented in terms of Array 2.0, if that is the meaning of Array to the current object. Extending that back into BUILD time, this implies that in class Ring is Array, the new Ring object needs to know how to make Array virtual even though the object isn't constructed yet. Neat trick, if we can pull it off... Possibly when we compile the Ring protoobject in a lexical scope with Array ::= Array:ver2.0, at that point we can record with the new Ring alias that any new Ring object made with that protoobject must use Array:ver2.0. Or something like that. For the situation to arise, the lexical scope must know about Ring objects somehow. This would handle the explicit use Ring; case, but I'm not so sure about indirect Ring objects that come in from elsewhere. They might have already been constructed with Array:ver1.0. Not sure what we can do about that. It doesn't seem like the kind of info you want to carry around with every object, so you end up attaching it to the type. If you get an object of two different versions, at some point you end up re-inventing version control merges for object attributes, and then you're probably just hosed. Or you just call it a sync and pretend it's no problem. :) Larry
