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.
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
On Thursday 11 March 2004 16:41, Dan Sugalski wrote:
> At 4:34 PM +0100 3/11/04, Jens Rieks 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"()
> 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
# got: 'error:imcc:parse error, unexpected '.', expecting '='
# in file 't/pmc/object-meths_8.imc' line 32
# expected: 'A::foo
# './parrot t/pmc/object-meths_8.imc' failed with exit code 1
# Looks like you failed 1 tests of 8.
> 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.
Thanks for the test,
Gotcha. Test applied, then, and we'll see where we go from here.
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
x = x . x
VAR '=' VAR '.' VAR
target '=' target ptr target
target '=' the_sub
target '=' sub_call
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.
> x = x . x
Ah yes. Or course, Thanks a lot, applied.
But how should the two interpretations of x.x be resolved? Is that
concatenation or method calling?
currently, the pir line
S5 = S5 . 'foo'
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
also is there a good reason that .= is missing from imcc?
Well, Perl 6 uses ~ . I think that would be a fair replacement:
S5 = S5 ~ 'foo'
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.
Or follow perl6 and use ~ for string concatenation. (Currently being
used for xor, which could use ^.)
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
>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.
> foo.baz is a method or member access
> foo . baz is concatenation
So it is now. CONCAT requires whitespace on either side.