STR-264: collect-all: recurse to current term instead of children of current term
Reported by Ron de Bruijn:
> I don’t understand the reason for the semantics of collect-all/3.
>
> This is my definition for collecting all variables (but not those on the
> LHS etc.).
> strategies
> collectAllRHS = collect-all(?Var(), conc, ignoreFirstArgAssign <+
> ignoreFunctionCall)
>
> rules
> ignoreFirstArgAssign:Assign(, e) -> e
> ignoreFunctionCall:Call(, arglist) -> arglist
>
> If I run this on Assign(Var(“x”),Var(“y”)) I would expect [Var(“y”)],
> but I get []
> The only explanation I can think of is that after Assign(, e) -> e has
> been applied, it’s not matched with ?Var(_). I solved it by putting the
> explanatory Useless around e in ignoreFirstArgAssign. Why would anyone
> want this behaviour? Is this a bug?Interesting point. I agree that this behaviour is weird and I cannot think of a case where this behaviour might be useful. Weird that this didn’t come up earlier.
I think this should be fixed in some way, but the obvious fix might cause problems:
collect-all(s, un, skip) =
rec x(
![ | <crush(![],un,x)>]
<+ skip; crush(![],un,x)
<+ crush(![],un,x)
)If the crush(![],un,x) after the skip would be replaced by an x (that would solve this bug), then this could lead to non-termination if the skip argument is an identity. I’m not sure if that should be allowed.
I’ve created an issue for this. Any opinions?
For now, you can create you’re own collect-all variant if you want to.
Submitted on 25 February 2005 at 22:47
Log in to post comments