mkscope ignores incoming bindings

[miner]

I think mkscope should call the rule with the incoming bindings, not the empty map {} as it does now. I use a rule that needs bindings from the outside scope. However, I don't want the rule's new bindings to escape the inner scope. As a work-around, I used a slightly modified version of mkscope to do what I want.

[ericnormand]

Hi Steve,

Thanks for the issue request. May I ask what the use case is? It sounds
like something I might want to incorporate.

The original idea behind mkscope was as a unit for building independent
rules. You should be able to call rules without worrying about leaking
bindings between them. It sounds like you don't want independent rules.
Instead, you want something like a lexical scope, which sounds like a
different case, though still valid.

I'll see about adding it.

In the meantime, can I ask what you are using squarepeg for? It's always
good to hear my code is being used!

Eric

On Tue, May 28, 2013 at 11:37 AM, Steve Miner [email protected]:

I think mkscope should call the rule with the incoming bindings, not the
empty map {} as it does now. I use a rule that needs bindings from the
outside scope. However, I don't want the rule's new bindings to escape the
inner scope. As a work-around, I used a slightly modified version of
mkscope to do what I want.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/5
.

[ericnormand]

I've created a gist with a potential solution. I want to keep mkscope's current functionality, but I understand the need for bindings that comes in but don't leak out. Please check it out and give me your comments.

https://gist.github.com/ericnormand/5692047

[miner]

In my case, I'm trying to match something where one element is the same as a previously seen one: for example, a vector where every element is the same integer, such as [3 3 3]. I used one rule to bind to the first element and other rules to say that subsequent elements must match the first. My implementation was to gensym a new binding for each element and mkpred with an equality test for the two bindings. I didn't want the gensym bindings to escape so I tried to use mkscope, which failed for not having the first binding available. My solution was exactly your proposed mklex. Admittedly, my usage is less modular than your intention for mkscope, but as a practical matter, I don't see the problem with allowing the bindings to come it from the outside. I mean, they can't cause a problem if you don't use them. And I believe they would be shadowed if you try to rebind within your mkscope. So is there really a practical use for the current mkscope where the proposed mklex would not work? Not a big deal, but I'd go with just one if it's good enough just so that I don't have to explain the difference.