-
Notifications
You must be signed in to change notification settings - Fork 5
syntax guide
Lambda Calculus syntax consists of terms, which can be:
- variables
- function expressions ( abstractions )
- function calls ( applications )
There are also:
- parentheses ( for overriding precedence )
- whitespace ( separates names and may continue lines, but otherwise ignored )
Lambda Calculus compiler syntax consists of:
- definitions
- comments
Comments start with a hash # and continue until the end of the current line.
User comments should have whitespace immediately following the hash; comments immediately followed by non-whitespace text are reserved for future use ( compiler pragmas, eg. #define ).
Comments are currently completely ignored for all purposes, specifically including ending line continuations by indentation.
The one exception is #debug, which toggles strict mode for syntax highlighting, but does not affect compilation in any way.
Definitions are of the form $NAME = $TERM.
Definitions can be overwritten. The last earlier definition will be used when referenced.
A definition starts with non-whitespace, non-comment text at the left margin and continues until ( not including ) the next non-whitespace, non-comment text at the left margin, or until the end of the source file.
Whitespace satisfies JavaScript /\s+/.
Whitespace can be used anywhere but within identifiers.
If a line starts with whitespace it is considered to continue the previous definition.
Empty lines are allowed and do not break line continuations.
Identifiers are names.
They must start with a letter or an underscore, and may have any number of letters, digits, underscores ( _ ), dashes ( - ) or primes ( ' ) after that.
In v1.0.5 or later, they may also end with a question mark ( ? ), which is then part of the identifier.
The compiler is case-sensitive and case-preserving.
Names may be used as variables or as binders in a lambda abstraction.
Names that start with an underscore are not actually bound to values; evaluating them is an error, but assigning a value to them is not. For performance reaons, it is recommended not to bind unused arguments of functions to defined names; bind them to any name starting with _ so the binding will be skipped.
Numbers are immediate numeric values. They will be compiled according to the numEncoding in effect and inserted as abstractions.
Variables are of the form $NAME.
Functions are of the form \ $NAME . $TERM. The backslash \ is displayed as a lambda λ.
Functions have exactly one argument, which is an identifier, but the compiler syntax allows ( but does not mandate ) contracting \ fst . \ snd . term to \ fst snd . term. ( This defines a curried function. )
Identifier names starting with an underscore will capture, but not actually bind, an applied value.
Functions have exactly one body, which may be a value, abstraction, or application.
Function bodies extend as far right as syntactically possible.
Applications are of the form $TERM $TERM.
The compiler syntax, with parentheses (), allows empty applications; evaluating them is an error, but applying them to a term is not.
A single term may be considered a trivial application.
Terms may be a variable, abstraction, or application.
Application is left associative.