-
Notifications
You must be signed in to change notification settings - Fork 23
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
Mutual recursive objects - when to allow them? #600
Labels
Comments
Leveraging boxing, we could think it's possible to:
But this fails with
|
This is an interesting question, which is also related to #274. In general, we need to rethink / redesign the "object-system" anyways. Other aspects are:
Maybe the different aspects can be collected somewhere in a "super-ticket"? |
10 tasks
Note: Workaround(-ish) I use for local mutually "recursive" objects via unrolling:
|
marzipankaiser
changed the title
Mutual recursive interface definitions - when to allow them?
Mutual recursive objects - when to allow them?
Sep 24, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Assume we defined:
Then, the following top-level definition is accepted by Effekt (albeit not working for LLVM):
(let's ignore non-termination here, we could add a counter).
Locally in a function, this does not compile (
ponger
is not defined):Also, the following (which uses boxing implicitly) doesn't work (locally or globally):
IIUC, this means that mutually recursive interface definitions are only possible on the toplevel, and not in LLVM.
Is this the behavior we want? Which of those should work? (Are there interesting other variants?)
The text was updated successfully, but these errors were encountered: