[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-smalltalk] ParseTreeRewriter tests & behavior
From: |
Stephen Compall |
Subject: |
Re: [Help-smalltalk] ParseTreeRewriter tests & behavior |
Date: |
Wed, 10 Jan 2007 14:14:15 -0600 |
On Wed, 2007-01-10 at 13:21 +0100, Paolo Bonzini wrote:
> I agree with the first, which is probably a bug (it's also in VW, by the
> way).
As with Squeak. The Refactory-Parser code seems to be largely untouched
from when it was last released by Brant & Roberts.
The fix is to add 'notFound add: each.' just below the warning that gets
printed if a replacement node isn't a message or cascade.
Do all the tests (taking out the gst-specific code, of course) pass in
VW?
> The second I cannot parse:
>
> > self rewrite: 'qqq display: (qqq display: sss);
> > display: [qqq display: sss]'
> > from: 'address@hidden display: address@hidden'
> > to: 'address@hidden'
> > shouldBe: 'qqq display: (qqq display: sss);
> > display: [[sss]]'.
>
> I would think that it becomes "qqq: display: [sss]; display: [[sss]]".
> Why shouldn't this be the case?
In the second message, qqq display: [qqq display: sss]: before
recusivelySearchInContext is sent from the rule, after match:inContext:
but before foundMatchFor:, which produces the final expansion:
RBVariableNode('address@hidden') -> RBVariableNode(qqq)
RBVariableNode('address@hidden') -> RBBlockNode([qqq display: sss])
The block node doesn't match. So you descend into its body, which
descends into its statements, and matches the message, replacing it:
RBVariableNode('address@hidden') -> RBBlockNode([[sss]])
The RBBlockNode that is the value of the Association above is == to the
block node that was originally destructured from the source. So it
doesn't matter whether we accept [[sss]] as an expansion; even if we
don't, the originally matched message now is qqq display: [[sss]].
> What happens if you fix the first bug?
That will hide the example I've given, because arguments in the notFound
messages are rewritten. This means, however, that certain arguments, or
parts thereof, will be rewritten *again*. This can be seen by adding a
'address@hidden value' => 'address@hidden' rewrite rule. I'll add this to
ptrtests.st
later.
--
Stephen Compall
http://scompall.nocandysw.com/blog
signature.asc
Description: This is a digitally signed message part
- [Help-smalltalk] ParseTreeRewriter tests & behavior, Stephen Compall, 2007/01/10
- Re: [Help-smalltalk] ParseTreeRewriter tests & behavior, Paolo Bonzini, 2007/01/10
- Re: [Help-smalltalk] ParseTreeRewriter tests & behavior,
Stephen Compall <=
- Re: [Help-smalltalk] ParseTreeRewriter tests & behavior, Stephen Compall, 2007/01/10
- Re: [Help-smalltalk] ParseTreeRewriter tests & behavior, Stephen Compall, 2007/01/11
- [Help-smalltalk] ParseTreeRewriter refactoring, Stephen Compall, 2007/01/11
- Re: [Help-smalltalk] ParseTreeRewriter refactoring, Paolo Bonzini, 2007/01/11
- Re: [Help-smalltalk] ParseTreeRewriter refactoring, Stephen Compall, 2007/01/11
- Re: [Help-smalltalk] ParseTreeRewriter refactoring, Paolo Bonzini, 2007/01/11
- Re: [Help-smalltalk] ParseTreeRewriter refactoring, Stephen Compall, 2007/01/11
- Re: [Help-smalltalk] ParseTreeRewriter refactoring, Paolo Bonzini, 2007/01/11
- Re: [Help-smalltalk] ParseTreeRewriter refactoring, Stephen Compall, 2007/01/11
- Re: [Help-smalltalk] ParseTreeRewriter refactoring, Paolo Bonzini, 2007/01/11