Question

I currently have an issue in my DLR language implementation where subsequent calls to a method defined in the language occur with the same input parameters used by the first call to that method.

So… if I do this in my language:

PrintType( 34 ); PrintType( 34.1 ); 

… the output is:

Integer

Integer

Where I would expect:

Integer

Decimal

I suspect (but cannot yet confirm) that the issue results from the following:

1. my call binder (InvokeAction subclass) generates an appropriate Call Expression and then returns a new MetaObject with that expression and Restrictions.Empty

2. therefore, I think what might be happening is that the Restrictions parameter informs the DLR as to when this construct can be re-used for subsequent calls to this method, and since I place no inherent restrictions, the first construct is always re-used (sorry, my terminology here is probably wrong… hopefully you get the idea)

So… I’m thinking that I need to use a merge of Restrictions generated for each parameter… by type, or perhaps by instance.

Can someone confirm or deny my thinking? Any other possibilities I should explore, for the behavior I’m seeing?

TIA…

Answer 1

Your thinking is correct. In this case you’ll want a type restriction – in general you want to have as few as restrictions as possible so the code can be shared from as many call sites as possible.

The way this works is that before asking your binder for a rule the DLR is searching for a cached rule. The restrictions are what would prevent the cached rule from being applicable to a new set of inputs.