Conversation
src/lambda_cli/core.clj
Outdated
| | LAMBDA VAR_EXP '.' L_EXP | ||
| | '(' L_EXP ')' | ||
| | L_EXP L_EXP | ||
| | '\\\\' VAR_EXP '->' L_EXP |
There was a problem hiding this comment.
Might as well just change ' \ \ \ \ ' to LAMBDA. The original intent of my ask was just to make it easier to type in "lambda" in multiple forms. If we're going to have the '->' for separating the bound expression from the LAMBDA VAR_EXP we might as well allow it everywhere.
donovansmith44
left a comment
There was a problem hiding this comment.
Allowing use of '->' operator everywhere.
donovansmith44
left a comment
There was a problem hiding this comment.
Allowed '->' to be used everywhere
donovansmith44
left a comment
There was a problem hiding this comment.
Allowed '->' to be used everywhere
donovansmith44
left a comment
There was a problem hiding this comment.
Def BINDing of abstractions of vars to L_EXPs
donovansmith44
left a comment
There was a problem hiding this comment.
I thought it might be easier to evaluate tree elements if we had keywords for construction rules, which allows for clearer bifurcation and descent.
src/lambda_cli/core.clj
Outdated
| | <'('> L_EXP L_EXP <')'> | ||
| | APPLY | ||
| | ABSTRACT | ||
| | <'('> L_EXP <')'> |
There was a problem hiding this comment.
Correct with the apply and abstract bits. Technically (and I just looked this up) line 20 is not part of the lambda calculus grammar.
There was a problem hiding this comment.
Meaning this: <'('> L_EXP <')'>
There was a problem hiding this comment.
Actually, I was wrong.
Application is what I have for line 19 (in red)
Abstraction is LAMBDA VAR BIND L_EXP
donovansmith44
left a comment
There was a problem hiding this comment.
Fixing APPLY and L_EXP definitions
In addition to your original request, I also added the explicit Haskell-style lambdas of (\x -> x) to the grammar. Let me know if you like it.