Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

the eval-cond Primus signal is broken #1124

Closed
ivg opened this issue Jun 12, 2020 · 2 comments
Closed

the eval-cond Primus signal is broken #1124

ivg opened this issue Jun 12, 2020 · 2 comments
Assignees

Comments

@ivg
Copy link
Member

ivg commented Jun 12, 2020

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.

@ivg
Copy link
Member Author

ivg commented Jun 30, 2020

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.

@ivg
Copy link
Member Author

ivg commented Mar 1, 2022

It looks like that jumping suits our needs and no more changes are needed so we can close it.

@ivg ivg closed this as completed Mar 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant