Re: C<::> in rules

2005-05-13 Thread Patrick R. Michaud
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 fo

Re: ^method ?

2005-05-13 Thread Larry Wall
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 ot

Re: Object Numify/Stringify-ing to Unique values

2005-05-13 Thread Larry Wall
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 a

Re: ^method ?

2005-05-13 Thread Luke Palmer
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

Re: ^method ?

2005-05-13 Thread Luke Palmer
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 th

Re: C<::> in rules

2005-05-13 Thread Luke Palmer
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 desi

Re: ^method ?

2005-05-13 Thread Larry Wall
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 fr

^method ?

2005-05-13 Thread Autrijus Tang
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: Object Numify/Stringify-ing to Unique values

2005-05-13 Thread Autrijus Tang
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 =

Re: Object Numify/Stringify-ing to Unique values

2005-05-13 Thread Larry Wall
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: C<::> in rules

2005-05-13 Thread Larry Wall
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 that

Re: Object Numify/Stringify-ing to Unique values

2005-05-13 Thread Yuval Kogman
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

Object Numify/Stringify-ing to Unique values

2005-05-13 Thread Stevan Little
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 num

Re: C<::> in rules

2005-05-13 Thread Luke Palmer
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 ] ]/;

Re: The Void type

2005-05-13 Thread Rod Adams
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 i

The Void type

2005-05-13 Thread Autrijus Tang
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 be

Re: C<::> in rules

2005-05-13 Thread Damian Conway
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

Re: single element lists

2005-05-13 Thread Larry Wall
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: trait and properties thru getter/setters

2005-05-13 Thread Larry Wall
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 pr

Re: trait and properties thru getter/setters

2005-05-13 Thread Larry Wall
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: C<::> in rules

2005-05-13 Thread Larry Wall
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 t

Re: trait and properties thru getter/setters

2005-05-13 Thread Brent 'Dax' Royal-Gordon
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 e

Re: trait and properties thru getter/setters

2005-05-13 Thread Stéphane Payrard
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

Re: trait and properties thru getter/setters

2005-05-13 Thread Larry Wall
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: C<::> in rules

2005-05-13 Thread Larry Wall
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

2005-05-13 Thread Brent 'Dax' Royal-Gordon
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 m

Re: trait and properties thru getter/setters

2005-05-13 Thread Stéphane Payrard
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

trait and properties thru getter/setters

2005-05-13 Thread Stéphane Payrard
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 interacti

Re: Quick question: parens vs subroutine parameter

2005-05-13 Thread TSa (Thomas Sandlaß)
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 ps

Re: C<::> in rules

2005-05-13 Thread Patrick R. Michaud
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: C<::> in rules

2005-05-13 Thread Luke Palmer
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.

Re: C<::> in rules

2005-05-13 Thread Luke Palmer
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

Re: BEGIN and lexical variables inside subroutines

2005-05-13 Thread TSa (Thomas Sandlaß)
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 f

Re: C<::> in rules

2005-05-13 Thread Aaron Sherman
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 ju

Re: C<::> in rules

2005-05-13 Thread Juerd
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) Agreed Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html

Re: single element lists

2005-05-13 Thread James Mastros
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 > cl

S29: punt

2005-05-13 Thread Max Maischein (Corion)
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 e

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

2005-05-13 Thread mark . a . biggar
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', '

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

2005-05-13 Thread Jody Belka
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 extr

Re: C<::> in rules

2005-05-13 Thread Markus Laire
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 slightl

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

2005-05-13 Thread Markus Laire
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

2005-05-13 Thread TSa (Thomas Sandlaß)
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 :p