[BUG] can not call methods with "self"
Dan Sugalski
Before I go and apply this, could you sync and retry? I'm not seeing
any test failures here, so there might be a crossing in the CVS.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Jens Rieks
On Thursday 11 March 2004 16:41, Dan Sugalski wrote:
> At 4:34 PM +0100 3/11/04, Jens Rieks wrote:
> >Hi,
> >
> >attached is a patch to t/pmc/object-meths.t that adds a test that is
> > currently failing because IMCC rejects code like self."blah"()
>
> Before I go and apply this, could you sync and retry? I'm not seeing
> any test failures here, so there might be a crossing in the CVS.
Its neither working on my computer nor on blao (tinderbox)...
t/pmc/object-meths....ok 7/8# Failed test (t/pmc/object-meths.t at line
185)
# got: 'error:imcc:parse error, unexpected '.', expecting '='
#
# in file 't/pmc/object-meths_8.imc' line 32
# '
# expected: 'A::foo
# A::blah
# B::blah
# A::blah
# B::foo
# '
# './parrot t/pmc/object-meths_8.imc' failed with exit code 1
# Looks like you failed 1 tests of 8.
jens
Leopold Toetsch
> attached is a patch to t/pmc/object-meths.t that adds a test that is
> currently failing because IMCC rejects code like self."blah"()
Yep. It produces reduce/reduce conflicts. Something's wrong with
precedence. I'd be glad if someone can fix it.
One more bug was in the code: P2 wasn't preserved around method calls.
Fixed too.
> jens
Thanks for the test,
leo
Dan Sugalski
>Hi,
>
>On Thursday 11 March 2004 16:41, Dan Sugalski wrote:
>> At 4:34 PM +0100 3/11/04, Jens Rieks wrote:
>> >Hi,
>> >
>> >attached is a patch to t/pmc/object-meths.t that adds a test that is
>> > currently failing because IMCC rejects code like self."blah"()
>>
>> Before I go and apply this, could you sync and retry? I'm not seeing
>> any test failures here, so there might be a crossing in the CVS.
>Its neither working on my computer nor on blao (tinderbox)...
Gotcha. Test applied, then, and we'll see where we go from here.
Steve Fink
> Jens Rieks <par...@jensbeimsurfen.de> wrote:
>
> > attached is a patch to t/pmc/object-meths.t that adds a test that is
> > currently failing because IMCC rejects code like self."blah"()
>
> Yep. It produces reduce/reduce conflicts. Something's wrong with
> precedence. I'd be glad if someone can fix it.
The attached patch should remove all of the conflicts, and replace
them with a single shift/reduce conflict that appears to be a bug in
the actual grammar, namely:
x = x . x
can be parsed as
x = x . x
VAR '=' VAR '.' VAR
target '=' var '.' var
assignment
or
x = x . x
VAR '=' VAR '.' VAR
target '=' target ptr target
target '=' the_sub
target '=' sub_call
assignment
Personally, I'd probably also rename 'target' to 'lhs', and 'var' (and
its variants) to 'rhs'. But maybe that's just me. Oh, and 'lhs' is
available because this patch eliminates it.
I didn't try the test mentioned, though.
Leopold Toetsch
> The attached patch should remove all of the conflicts, and replace
> them with a single shift/reduce conflict that appears to be a bug in
> the actual grammar, namely:
> x = x . x
Ah yes. Or course, Thanks a lot, applied.
leo
Steve Fink
But how should the two interpretations of x.x be resolved? Is that
concatenation or method calling?
Luka Frelih
> concatenation or method calling?
currently, the pir line
S5 = S5 . 'foo'
produces
error:imcc:object isn't a PMC
concatenation with . seems to be gone
i cannot think of a good replacement for it
wouldnt it be better to keep . as string glue
and have method calls use the arrow -> or some
such?
also is there a good reason that .= is missing from imcc?
LF
Luke Palmer
> >But how should the two interpretations of x.x be resolved? Is that
> >concatenation or method calling?
>
> currently, the pir line
> S5 = S5 . 'foo'
> produces
> error:imcc:object isn't a PMC
>
> concatenation with . seems to be gone
> i cannot think of a good replacement for it
Well, Perl 6 uses ~ . I think that would be a fair replacement:
S5 = S5 ~ 'foo'
Luke
Steve Fink
That currently means binary xor in imcc, so if we changed it we'd
break compatibility with current compilers and scripts.
OTOH, it sounds like I already broke it by changing the outcome of the
ambiguous x.x interpretation -- oops. I can change it back with
precedence games, but would rather not exert the effort, since I think
using ~ is a better way to go. (Barring other better ideas, that is.)
I tend to use the 'concat' op in my own code anyway. So I'll abide by
Leo's or Melvin's ruling.
Kenneth A Graves
> > But how should the two interpretations of x.x be resolved? Is that
> > concatenation or method calling?
>
> and have method calls use the arrow -> or some
> such?
Or follow perl6 and use ~ for string concatenation. (Currently being
used for xor, which could use ^.)
--kag
Melvin Smith
> > > currently, the pir line
> > > S5 = S5 . 'foo'
> > > produces
> > > error:imcc:object isn't a PMC
> > >
> > > concatenation with . seems to be gone
> > > i cannot think of a good replacement for it
> >
This should be fixable with some lexer or parser tweaking.
>Well, Perl 6 uses ~ . I think that would be a fair replacement:
> >
> > S5 = S5 ~ 'foo'
We don't have the same ambiguity problems in PIR that we do
in Perl6 since PIR is very simple and uniform.
foo.baz is a method or member access
foo . baz is concatenation
For an intermediate language for multiple front end compilers
1) Strict rules are just fine
2) Eventually compilers will simply use the AST API and skip the
textual mode.
>I tend to use the 'concat' op in my own code anyway. So I'll abide by
>Leo's or Melvin's ruling.
Explicit concat works for me too.
Parsing PIR is not too complex, so I'm not worried about a lexer
kludge here or there. I prefer to keep the . for concat.
-Melvin
Leopold Toetsch
> foo.baz is a method or member access
> foo . baz is concatenation
So it is now. CONCAT requires whitespace on either side.
> -Melvin
leo