-
Notifications
You must be signed in to change notification settings - Fork 14
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
Add letrec
terms
#469
base: main
Are you sure you want to change the base?
Add letrec
terms
#469
Conversation
eaf448a
to
775d5e7
Compare
Oh wow, neat. Do you have any ideas about how this might interact with termination checking? IIUC some type theories have a type for “well founded recursion”, but this might not be the best for an actual implementation? Syntax wise, I think I like I wonder if we can find binary formats that might exercise this feature? Might be useful to test it on some real world stuff. I’m unsure about merging this right now, but I really appreciate the exploration! I’ve found recursive bindings to a bit intimidating, so this stuff is very helpful! Takes a bit to understand and synthesise some of the research, and turn it into an implementation. |
Sometime down the line we could add recursion checking, but I don't think its a priority since our type theory is already inconsistent (we have |
I decided to do local recursive binding first, because it allows me to test out the typechecking rules without needing to implement lazy evaluation: just return |
Yeah I had been planning to remove this at some point – just hadn’t got around to it yet! See #316 😓 |
6713eaf
to
9b1dac7
Compare
Adds new
letrec
term. Type-checking is surprisingly easy:The hard part is evaluation. I think this would require lazy evaluation. At the moment any letrec definitions just evaluate to
#error
, so you can check thatletrec
type-checks, but can't run itTodos
def
items. Will leave for a later PRletrec
definitions are safe to evaluate. I believe we can use the algorithm from A Practical Mode System for Recursive Definitions. Will leave for a later PRletrec
be spelledletrec
(as in Scheme) orlet rec
(as in ML)?;
, but I cannot figure out how to do so without LALRPOP complaining about ambiguity, so for now the separator is,