Re: C:: in rules

Larry Wall wrote: Speaking of which, it seems to me that :p and :c should allow an argument that says where to start relative to the current position. In other words, :p means :p(0) and :c means :c(0). I could also see uses for :p(-1) and :p(+1). Isn't that slightly inconsistent with :p meaning

Re: split /(..)*/, 1234567890

Rick Delaney wrote: On Fri, May 13, 2005 at 04:05:23AM +0800, Autrijus Tang wrote: On Thu, May 12, 2005 at 12:01:59PM -0700, Larry Wall wrote: Yes, though I would think of it more generally as ('', \$0, '', \$0, '', \$0, ...) where in this case it just happens to be ('', \$0) and \$0 expands to

Re: C:: in rules

TSa (Thomas Sandlaß) kirjoitti: Larry Wall wrote: Speaking of which, it seems to me that :p and :c should allow an argument that says where to start relative to the current position. In other words, :p means :p(0) and :c means :c(0). I could also see uses for :p(-1) and :p(+1). Isn't that

Re: split /(..)*/, 1234567890

On Thu, May 12, 2005 at 07:13:22PM +0200, Jody Belka wrote: sepsepsepsepsepsep | | | | | | 11 22 33 44 55 66 | | | | | | field field field field field field whoops. add an extra

Re: split /(..)*/, 1234567890

No, it's not inconsistant. Think about the simpler case split /a/,'a' which return a list of empty strings. Now ask to keep the separators split /(a), 'a' which will return ('', 'a', '', 'a', '', 'a', '', 'a, '', 'a'). Now look at split /(a)/, 'aaab' which returns ('', 'a', '', 'a',

S29: punt

Hello Rod, I was pointed to your p6l post (4283AAC1.6060106[at]rodadams.net) by Autrijus. I have already worked a bit on implementing/porting the functionality of builtins that I want in Perl6 (by stealing from Perl5), I can try to take over S29. I'm finding myself in a perpetual state of

Re: single element lists

Larry Wall wrote: : If yes, then (1)[0] means the same as 1.[0] and 1.[0][0][0]. If no, : (1)[0] is a runtime error just like 1.[0] -- i.e. unable to find the : matching .[] multisub under Int or its superclasses. Maybe we should just let someone poke a Subscriptable role into some class

Re: C:: in rules

Markus Laire skribis 2005-05-13 11:43 (+0300): Perhaps spec should be changed so that :p means :p(bool::true) or :p(?1) and not :p(1) aol Agreed / Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html

Re: C:: in rules

On Fri, 2005-05-13 at 00:26, Patrick R. Michaud wrote: On Thu, May 12, 2005 at 08:56:39PM -0700, Larry Wall wrote: On Thu, May 12, 2005 at 09:33:37AM -0500, Patrick R. Michaud wrote: : Also, A05 proposes incorrect alternatives to the above : : /[:w[]foo bar]/ I would just like to

Re: BEGIN and lexical variables inside subroutines

Benjamin Smith wrote: sub foo { my \$x; BEGIN { \$x = 3 }; say \$x } foo; foo; foo; Currently in perl5 and pugs this prints 3\n\n\n. Which to me looks like a mix of runtime and compile time. Actually Dave Mitchell confirmed that this is the case in Perl 5. I have difficulty to regard this as a

Re: C:: in rules

On 5/12/05, Patrick R. Michaud [EMAIL PROTECTED] wrote: I have a couple of questions regarding C :: in perl 6 rules. First, a question of verification -- in \$rule = rx :w / plane :: (\d+) | train :: (\w+) | auto :: (\S+) / ; travel by plane jet train tgv today ~~ \$rule I think

Re: C:: in rules

On 5/13/05, Patrick R. Michaud [EMAIL PROTECTED] wrote: To use the phrase from later in your message, there's still the implicit .*? followed by the rule call. Since the rule itself hasn't failed (only the group failed), we're still free to try to match the pattern at later positions. I'm

Re: C:: in rules

On Fri, May 13, 2005 at 03:36:50PM +, Luke Palmer wrote: I'm basically saying that you should treat your: \$str ~~ /abc :: def | ghi :: jkl | mn :: op/; As: \$rule = rx/abc :: def | ghi :: jkl | mn :: op/; \$str ~~ /^ .*? \$rule/; Which means that you fail the rule, your .*?

Re: Quick question: parens vs subroutine parameter

Larry Wall wrote: : Void context still exists and is not a form of singular or plural : context. Perhaps this should be called nullar context, although void : context works equally well for me and is not confusing because we have : no Void type. Nice, without Void we don't need the double headed

trait and properties thru getter/setters

There is syntax to define trait and properties but is there an API? my \$b = eval '\$a but true'; # setting a true property # API to do it without an eval? A trait setter probably does not make sense but for the implementer because it should not be set at run time. Incidentally, in a

Re: trait and properties thru getter/setters

On Fri, May 13, 2005 at 06:37:50PM +, [EMAIL PROTECTED] wrote: There is syntax to define trait and properties but is there an API? my \$b = eval '\$a but true'; # setting a true property # API to do it without an eval? I don't understand why you think you need the eval here?

Re: trait and properties thru getter/setters

On 5/13/05, Stéphane Payrard [EMAIL PROTECTED] wrote: There is syntax to define trait and properties but is there an API? my \$b = eval '\$a but true'; # setting a true property # API to do it without an eval? My question is more generic than my example. I may not know at

Re: C:: in rules

On Fri, May 13, 2005 at 11:43:42AM +0300, Markus Laire wrote: : Perhaps spec should be changed so that :p means :p(bool::true) or :p(?1) : and not :p(1) I'm still not sure I believe in booleans to that extent. I suppose we could go as far as to make it :p(0 but true). Actually, it's more like

Re: trait and properties thru getter/setters

On Fri, May 13, 2005 at 12:26:22PM -0700, Brent 'Dax' Royal-Gordon wrote: : Well, the value's pretty easy--just pass in a variable: : : my \$b = \$a is foo(\$bar); As we currently have it, that is not legal syntax. is may only be applied to declarations. You must use does or but to mixin

Re: trait and properties thru getter/setters

On Fri, May 13, 2005 at 12:31:09PM -0700, Larry Wall wrote: On Fri, May 13, 2005 at 12:26:22PM -0700, Brent 'Dax' Royal-Gordon wrote: : Well, the value's pretty easy--just pass in a variable: : : my \$b = \$a is foo(\$bar); As we currently have it, that is not legal syntax. is may only

Re: trait and properties thru getter/setters

On 5/13/05, Larry Wall [EMAIL PROTECTED] wrote: On Fri, May 13, 2005 at 12:26:22PM -0700, Brent 'Dax' Royal-Gordon wrote: : my \$b = \$a is foo(\$bar); As we currently have it, that is not legal syntax. is may only be applied to declarations. Sorry, think-o. I meant 'but' in my examples

Re: C:: in rules

On Fri, May 13, 2005 at 11:54:47AM -0500, Patrick R. Michaud wrote: : \$r1 = rx / abc :: def | ghi :: jkl | mn :: op /; : \$r2 = rx / abc ::: def | ghi ::: jkl | mn ::: op /; : \$r3 = rx / [ abc :: def | ghi :: jkl | mn :: op ] /; I would prefer that \$r1 work like \$r3, not like \$r2, for

Re: trait and properties thru getter/setters

On Fri, May 13, 2005 at 12:56:19PM -0700, Brent 'Dax' Royal-Gordon wrote: : Should I construe the fact that you didn't comment on the ::() to mean : that the symref syntax works here? Offhand I don't see any reason for it not to. Larry

Re: trait and properties thru getter/setters

On Fri, May 13, 2005 at 09:40:51PM +0200, Stéphane Payrard wrote: : And what about the getter part of my question? :) A12 discusses the relationship of traits and properties in great detail. Any trait's metadata can be stored as properties at compile time, and such metadata can be retrieved as

Re: single element lists

On Thu, May 12, 2005 at 11:52:38PM +0200, James Mastros wrote: : Larry Wall wrote: : : If yes, then (1)[0] means the same as 1.[0] and 1.[0][0][0]. If no, : : (1)[0] is a runtime error just like 1.[0] -- i.e. unable to find the : : matching .[] multisub under Int or its superclasses. : :

Re: C:: in rules

Larry wrote: I'm still not sure I believe in booleans to that extent. I suppose we could go as far as to make it :p(0 but true). Actually, it's more like undef but true, if you want to be able to distinguish sub foo (+\$p = 0) { # no :p at all say true if \$p; # :p with no

The Void type

On Fri, May 13, 2005 at 07:13:53PM +0200, TSa (Thomas Sandla) wrote: Larry Wall wrote: : Void context still exists and is not a form of singular or plural : context. Perhaps this should be called nullar context, although void : context works equally well for me and is not confusing because we

Re: The Void type

Autrijus Tang wrote: On Fri, May 13, 2005 at 07:13:53PM +0200, TSa (Thomas Sandlaß) wrote: Larry Wall wrote: : Void context still exists and is not a form of singular or plural : context. Perhaps this should be called nullar context, although void : context works equally well for me and is

Re: C:: in rules

On 5/13/05, Patrick R. Michaud [EMAIL PROTECTED] wrote: First, I'm quite certain that \$r2 and \$r3 are different. For illustration, let's use a variation like: \$q2 = rx / \w [ abc ::: def | ghi ::: jkl | mn ::: op ] /; \$q3 = rx / \w [ [ abc :: def | ghi :: jkl | mn :: op ] ]/;

Object Numify/Stringify-ing to Unique values

Hello all. In the processing of working with mugwump's shiny new perl6 OO Set.pm. I realized that we do not currently have a way to uniquely identify objects in Pugs like the way we have in perl5 (object stringification). So I asked Autrijus, and he promptly implemented a rudimentary object

Re: Object Numify/Stringify-ing to Unique values

On Fri, May 13, 2005 at 21:47:52 -0400, Stevan Little wrote: Hello all. In the processing of working with mugwump's shiny new perl6 OO Set.pm. I realized that we do not currently have a way to uniquely identify objects in Pugs like the way we have in perl5 (object stringification).

Re: C:: in rules

On Sat, May 14, 2005 at 01:15:36AM +, Luke Palmer wrote: : I think the misunderstanding is rather simple. You keep talking like : you prepend a .*? to the rule we're matching. I think that's wrong : (and this is where I'm making a design call, so we can dispute on this : once we're clear

Re: Object Numify/Stringify-ing to Unique values

On Fri, May 13, 2005 at 09:47:52PM -0400, Stevan Little wrote: : Hello all. : : In the processing of working with mugwump's shiny new perl6 OO Set.pm. : I realized that we do not currently have a way to uniquely identify : objects in Pugs like the way we have in perl5 (object stringification).

Re: Object Numify/Stringify-ing to Unique values

On Fri, May 13, 2005 at 07:28:03PM -0700, Larry Wall wrote: That's what .id is supposed to do, without the bogus numorstringification semantics. It should return something opaque that matches with ~~. Okay, implemented as such. What does unboxed values return for their id, though? 3 =:=

^method ?

Juerd informed me today that .method should still means \$_.method. However, for the OO modules we're writing, there still needs to be a way to invoke methods on the current invocant, when the invocant name has been omitted from the method() declaration. Currently Pugs has: \$?SELF.method

Re: ^method ?

On Sat, May 14, 2005 at 11:41:23AM +0800, Autrijus Tang wrote: : Juerd informed me today that .method should still means \$_.method. : : However, for the OO modules we're writing, there still needs to be a way : to invoke methods on the current invocant, when the invocant name has : been omitted

Re: C:: in rules

On 5/14/05, Larry Wall [EMAIL PROTECTED] wrote: On Sat, May 14, 2005 at 01:15:36AM +, Luke Palmer wrote: : I think the misunderstanding is rather simple. You keep talking like : you prepend a .*? to the rule we're matching. I think that's wrong : (and this is where I'm making a design

Re: ^method ?

On 5/14/05, Larry Wall [EMAIL PROTECTED] wrote: At the moment \$?SELF is the only canonical form, though the invocant is also in \$_ at least until it's rebound. Any other forms will probably involve a pragma or macro, since there is no consensus on a shortcut. Er, isn't that a mistake that we

Re: ^method ?

On 5/14/05, Luke Palmer [EMAIL PROTECTED] wrote: On 5/14/05, Larry Wall [EMAIL PROTECTED] wrote: At the moment \$?SELF is the only canonical form, though the invocant is also in \$_ at least until it's rebound. Any other forms will probably involve a pragma or macro, since there is no

Re: Object Numify/Stringify-ing to Unique values

On Sat, May 14, 2005 at 10:54:34AM +0800, Autrijus Tang wrote: : On Fri, May 13, 2005 at 07:28:03PM -0700, Larry Wall wrote: : That's what .id is supposed to do, without the bogus numorstringification : semantics. It should return something opaque that matches with ~~. : : Okay, implemented as

Re: ^method ?

On Sat, May 14, 2005 at 04:33:44AM +, Luke Palmer wrote: : On 5/14/05, Luke Palmer [EMAIL PROTECTED] wrote: : On 5/14/05, Larry Wall [EMAIL PROTECTED] wrote: : At the moment \$?SELF is the only canonical form, though the invocant : is also in \$_ at least until it's rebound. Any other

Re: C:: in rules

On Sat, May 14, 2005 at 04:26:44AM +, Luke Palmer wrote: On 5/14/05, Larry Wall [EMAIL PROTECTED] wrote: I want ::: to break out of *that* dynamic scope (or the equivalent matchrighthere scope), but not ::. I'm not sure that's such a good idea. When you say: rule foo() { a* :::