-
Notifications
You must be signed in to change notification settings - Fork 661
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
[Proposal] Generics/macros in Leo #479
Comments
It was casually discussed we use this syntax instead:
Which seems more general purpose, and is already supported syntax. On top of that, I have found an issue with input-based branched calling of recursion. I.e.
This makes the recursion count depend on runtime data not as a function of what we are recursing on, but whether we call the recursive function or not. To deal with this issue, the following semantic constraints are proposed:
This should close this hole, and provide a safe compile-time recursion bound that is based on concrete semantics. An alternative is runtime bounds checking, but that seems like a bad approach. |
The proposed (and already supported) syntax seems appropriate. I'm expecting that the inlining of bounded recursion will take place alongside the other "flattening" transformations -- loop unrolling, constant propagation/folding, etc. If a recursion is
An approach is to allow only certain forms of recursion that are clearly seen to terminate (e.g. decrease Another approach is to keep inlining, but fail when a certain limit is reached, or when previously seen Borrowing ideas from the termination analysis in theorem provers like ACL2, a recursion should be
but in the
The requirement applies to every cycle in the call graph, whether it involves a single recursive function or multiple mutually recursive functions. The proposed restriction that the governing tests do not depend on runtime data seems unnecessary in general. This is a manual inlining of a slight variant of the
This is a manual inlining of a version without the
|
💥 Proposal
To support functionality, such as bounded recursion, and generalized algorithms, I propose adding the following notation in Leo for generics/macros:
The text was updated successfully, but these errors were encountered: