Re: odd (lexical?) issue with Rakudo/Parrot
On Jul 18, 2008, at 5:18 PM, Jonathan Worthington wrote: Hi, Chris Fields wrote: The PGE::Match appears to be converted to a Str, regardless of the invoking object type. The following is .match (in any-str.pir, with the builtins). Also, .ACCEPTS now uses .match to retrieve the Match object. # any-str.pir .sub 'match' :method :multi(_) .param pmc x .local pmc match match = x(self) .return (match) .end # Code.pir .sub 'ACCEPTS' :method .param pmc topic .local pmc match match = topic.'match'(self) $P0 = getinterp $P1 = $P0['lexpad';1] $P1['$/'] = match .return (match) .end the following is a test p6 script (results in comments): my $x = '123.456'; my $y = $x.match(/\d+/); say $x;# 123.456 say $x.WHAT; # Str say $y;# 123 say $y.WHAT; # Str <- Should be Match Ouch! But I've tracked it down. :-) The interesting thing is that: my $x = "foo"; say ($x.match(/o+/)).WHAT; # Match So it fails in the assignment. And that's because infix:= to a scalar does: .sub 'infix:=' :method .param pmc source $P0 = source.'item'() assign self, $P0 .return (self) .end And calling item on a Match object gets the string that matched. Thus why we don't get the Match object. So, that's the cause; I'm not sure what the correct fix is, so I'll delegate to pmichaud on that one. We could special case it, but it doesn't feel very clean, and special cases in a hot code patch like infix:= probably ain't so desirable. Thanks, Jonathan Good catch, jonathan++ I would rather wait for the right fix so no hurry (special casing seems wrong to me as well). I'll start a ticket so it doesn't get lost in the ether. We can implement .match after that, doesn't make sense to have it pass back the wrong thing in the meantime. chris
Re: odd (lexical?) issue with Rakudo/Parrot
Hi, Chris Fields wrote: The PGE::Match appears to be converted to a Str, regardless of the invoking object type. The following is .match (in any-str.pir, with the builtins). Also, .ACCEPTS now uses .match to retrieve the Match object. # any-str.pir .sub 'match' :method :multi(_) .param pmc x .local pmc match match = x(self) .return (match) .end # Code.pir .sub 'ACCEPTS' :method .param pmc topic .local pmc match match = topic.'match'(self) $P0 = getinterp $P1 = $P0['lexpad';1] $P1['$/'] = match .return (match) .end the following is a test p6 script (results in comments): my $x = '123.456'; my $y = $x.match(/\d+/); say $x;# 123.456 say $x.WHAT; # Str say $y;# 123 say $y.WHAT; # Str <- Should be Match Ouch! But I've tracked it down. :-) The interesting thing is that: my $x = "foo"; say ($x.match(/o+/)).WHAT; # Match So it fails in the assignment. And that's because infix:= to a scalar does: .sub 'infix:=' :method .param pmc source $P0 = source.'item'() assign self, $P0 .return (self) .end And calling item on a Match object gets the string that matched. Thus why we don't get the Match object. So, that's the cause; I'm not sure what the correct fix is, so I'll delegate to pmichaud on that one. We could special case it, but it doesn't feel very clean, and special cases in a hot code patch like infix:= probably ain't so desirable. Thanks, Jonathan
Re: odd (lexical?) issue with Rakudo/Parrot
On Jul 17, 2008, at 9:41 PM, Patrick R. Michaud wrote: On Thu, Jul 17, 2008 at 02:20:33PM -0500, Chris Fields wrote: Okay, I'll set it up so "$foo = 'abcd'.match(/+/)" returns a Match object, and $/ would remain unset. Makes sense to me. Right now the match object is converted over to a Str; I'll take a look at the parser grammar/actions to see if that can be fixed. It is? That's odd and shouldn't be happening -- something must be incorrect there. Pm The PGE::Match appears to be converted to a Str, regardless of the invoking object type. The following is .match (in any-str.pir, with the builtins). Also, .ACCEPTS now uses .match to retrieve the Match object. # any-str.pir .sub 'match' :method :multi(_) .param pmc x .local pmc match match = x(self) .return (match) .end # Code.pir .sub 'ACCEPTS' :method .param pmc topic .local pmc match match = topic.'match'(self) $P0 = getinterp $P1 = $P0['lexpad';1] $P1['$/'] = match .return (match) .end the following is a test p6 script (results in comments): my $x = '123.456'; my $y = $x.match(/\d+/); say $x;# 123.456 say $x.WHAT; # Str say $y;# 123 say $y.WHAT; # Str <- Should be Match $x = 123.456; $y = $x.match(/\d+/); say $x;# 123.456 say $x.WHAT; # Num say $y;# 123 say $y.WHAT; # Str <- Should be Match say $/;# Nothing say $/.WHAT; # Failure, .match doesn't set $/ $x ~~ /\d+/; say $/;# 123 say $/.WHAT; # Match As shown above, calling .match from .ACCEPTS (either using smart match or using /\d+/.ACCEPTS($x) ) works fine, but calling .match as a method from p6 doesn't. Makes me think it's a mapping issue. chris
Re: odd (lexical?) issue with Rakudo/Parrot
On Thu, Jul 17, 2008 at 02:20:33PM -0500, Chris Fields wrote: > Okay, I'll set it up so "$foo = 'abcd'.match(/+/)" returns a > Match object, and $/ would remain unset. Makes sense to me. > > Right now the match object is converted over to a Str; I'll take a > look at the parser grammar/actions to see if that can be fixed. It is? That's odd and shouldn't be happening -- something must be incorrect there. Pm
Re: odd (lexical?) issue with Rakudo/Parrot
On Jul 17, 2008, at 1:56 AM, Moritz Lenz wrote: Essentially the difference is that smart-match sets $/, while a simple call to .match probably should not. Pm I can have .match not set $/ for now and simply return matches based on context IMHO that's the wrong approach. Perl 6 tries not to return stuff based on context, but to return stuff that will behave right in every context. So if you just return a match object (that one that would usually ends up in $/ ) you should be just fine all contexts. Moritz Okay, I'll set it up so "$foo = 'abcd'.match(/+/)" returns a Match object, and $/ would remain unset. Makes sense to me. Right now the match object is converted over to a Str; I'll take a look at the parser grammar/actions to see if that can be fixed. chris
Re: odd (lexical?) issue with Rakudo/Parrot
Chris Fields wrote: > On Jul 16, 2008, at 1:28 PM, Patrick R. Michaud wrote: > >> On Wed, Jul 16, 2008 at 11:20:28AM -0500, Chris Fields wrote: >>> I have submitted a simple 'match' implementation for rakudo (method >>> version of m//, RT#56970) and ran into an odd issue. The current >>> version of match which works uses a tail call: >>> >>> .sub 'match' :method >>>.param pmc x >>>.return x.ACCEPTS(self) >>> .end >> >> .ACCEPTS should be calling .match, not vice-versa. > > Okay, though ACCEPTS is currently defined in Code.pir (REJECTS as > well). Would calling .match pertain to all executable blocks, or > should we have a Regex-specific ACCEPTS that calls .match? > > BTW (and a bit OT, but probably related to the above), Rakudo > currently indicates a regex is a Block, not a Regex; haven't looked at > it in detail and don't know if it's worth worrying about for now. > > > say /foo/.WHAT > Block > >> Essentially the difference is that smart-match sets $/, while >> a simple call to .match probably should not. >> >> Pm > > I can have .match not set $/ for now and simply return matches based > on context IMHO that's the wrong approach. Perl 6 tries not to return stuff based on context, but to return stuff that will behave right in every context. So if you just return a match object (that one that would usually ends up in $/ ) you should be just fine all contexts. Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: odd (lexical?) issue with Rakudo/Parrot
On Jul 16, 2008, at 5:45 PM, Chris Fields wrote: On Jul 16, 2008, at 1:28 PM, Patrick R. Michaud wrote: On Wed, Jul 16, 2008 at 11:20:28AM -0500, Chris Fields wrote: I have submitted a simple 'match' implementation for rakudo (method version of m//, RT#56970) and ran into an odd issue. The current version of match which works uses a tail call: .sub 'match' :method .param pmc x .return x.ACCEPTS(self) .end .ACCEPTS should be calling .match, not vice-versa. Okay, though ACCEPTS is currently defined in Code.pir (REJECTS as well). Would calling .match pertain to all executable blocks, or should we have a Regex-specific ACCEPTS that calls .match? Forget that last bit; I'm re-reading the relevant parts of S03/S05 to get everything straight. chris
Re: odd (lexical?) issue with Rakudo/Parrot
On Jul 16, 2008, at 1:28 PM, Patrick R. Michaud wrote: On Wed, Jul 16, 2008 at 11:20:28AM -0500, Chris Fields wrote: I have submitted a simple 'match' implementation for rakudo (method version of m//, RT#56970) and ran into an odd issue. The current version of match which works uses a tail call: .sub 'match' :method .param pmc x .return x.ACCEPTS(self) .end .ACCEPTS should be calling .match, not vice-versa. Okay, though ACCEPTS is currently defined in Code.pir (REJECTS as well). Would calling .match pertain to all executable blocks, or should we have a Regex-specific ACCEPTS that calls .match? BTW (and a bit OT, but probably related to the above), Rakudo currently indicates a regex is a Block, not a Regex; haven't looked at it in detail and don't know if it's worth worrying about for now. > say /foo/.WHAT Block Essentially the difference is that smart-match sets $/, while a simple call to .match probably should not. Pm I can have .match not set $/ for now and simply return matches based on context (though I haven't messed with context much). If we get some clarification about whether .match should set $/ we can always change it later. chris
Re: odd (lexical?) issue with Rakudo/Parrot
On Wed, Jul 16, 2008 at 11:20:28AM -0500, Chris Fields wrote: > I have submitted a simple 'match' implementation for rakudo (method > version of m//, RT#56970) and ran into an odd issue. The current > version of match which works uses a tail call: > > .sub 'match' :method > .param pmc x > .return x.ACCEPTS(self) > .end .ACCEPTS should be calling .match, not vice-versa. Essentially the difference is that smart-match sets $/, while a simple call to .match probably should not. Pm
odd (lexical?) issue with Rakudo/Parrot
I have submitted a simple 'match' implementation for rakudo (method version of m//, RT#56970) and ran into an odd issue. The current version of match which works uses a tail call: .sub 'match' :method .param pmc x .return x.ACCEPTS(self) .end If I try the following: .sub 'match' :method .param pmc x .local pmc match match = x.ACCEPTS(self); .return (match) .end I run into 'Null PMC access in set_pmc_keyed()' with ACCEPTS (below), which is failing to get the LexPad: .sub 'ACCEPTS' :method .param pmc topic .local pmc match match = self(topic) $P0 = getinterp $P1 = $P0['lexpad';1] $P1['$/'] = match .return (match) .end If I simply change match to mimic ACCEPTS, everything works fine. This makes me think something is going on with lexicals, but I'm not quite sure. Am I missing something? chris
