the eval-cond Primus signal is broken
Closed this issue · 2 comments
Since Primus Lisp branches now trigger the eval-cond observation it is impossible to use any branching in the eval-cond method implementation as it will trigger an infinite loop. As a temporary workaround the jumping observation should be used. We are working on the long term solution.
Status yellow. We removed the offending signal, probably breaking some downstream Primus Lisp analyses, but the general problem exists. We use Primus Lisp both for analysis and modeling, i.e., both as the meta language and the object language. It would be nice to be able to select in which mode they would like to operate. We already have a mechanism of contexts and ad-hoc polymorphism, which we can leverage, and overload primitives based on the current mode of execution.
E.g., declaring either (context (mode analysis)) or (context (mode modeling)) will let us select the right definition.
The effort doesn't look very high. We do not allow primitive overloading but it should be easy to enable, with minimal impact on the existing code, both Lisp and OCaml. We may also need to publish the context model to enable context specifications for primitives, alternatively, we can keep contexts private and use them only in Primus Lisp. And the main effort would be providing two sets of primitives one for the meta language another for the object language. I would expect that it would hard, sometimes, to strike the boundary between the two.
It looks like that jumping suits our needs and no more changes are needed so we can close it.