`s-expr` dynamics can currently conflict with interfaces

[scolsen]

Right now, since s-expr relies on our evaluation strategies, dynamic bindings are always preferred. Consider the case of inc which has an interface and dynamic definition, calling s-expr will only ever return:

鲤 (s-expr inc)
=> (dynamic Dynamic.inc [x] (+ x 1))

But users may want the interface definition.

We need to add a facility for disambiguating such cases.

[scolsen]

@hellerve FYI in case you have any good ideas on how to approach this!

[eriksvedang]

I think that when using the name unqualified you're likely most interested in the interface. Perhaps that's a general thing and we can change the priorities in the dynamic evaluator lookup code? Then you'd have to do Dynamic.inc to get the dynamic version, which is fine (and much clearer).

[scolsen]

That sounds good to me! We can try it out and see how it goes.

[eriksvedang]

Does this work already?

[scolsen]

Not yet! I have everything in place, but making this change has a huge impact on core, so we'll have to prepend Dynamic to tons of calls

[scolsen]

That said, that seems like the right approach unless we're in the context of a defndynamic

[scolsen]

We can either augment the compiler w/ logic that makes it smart (e.g. automatically preferring dynamic bindings in contexts like defndynamic bodies, or we can keep it simple and force users to type Dynamic.foo when making dynamic calls.