[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

> 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

Stephen Compall

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]