bash / cauliflambda Goto Github PK

λa b f x . a (b f) x can be simplified to λa b f . a (b f)

If a normal form exists, annotate it with a list of nominal definitions it matches.

E.g. for the following term:

True -> (&t f . t)
False -> (&t f . f)
0 --> (&f x. x)

(False)

The normal form should be shown as:

->> (λ(λ1))
    ^^^^^^^
    Also known as False, 0.

• #12
• #22

This would be helpful for testing that a building block indeed does what it's supposed to.

A special built-in definition should do the trick:

assert (EXPECTED_TERM) (ACTUAL_TERM)

Or a dedicated syntax maybe?

• #1
• #27
• #20

Syntax is very similar to schematic definitions

True -> (λt f.t)
False -> (λt f.f)

Definitions may reference other definitions but they may not be
mutually recursive to prevent infinite loops while expanding definitions.
(You should use a Y-combinator if you need mutual recursion)

The reducer using namefree expressions was very easy to implement (and educational ^^). However it comes with a few drawbacks concerning debuggability:

• (obviously) The names are gone, which makes the expressions unreadable to humans
• With the current plan for definitions (#1) the expressions would have gotten very large as I planned to implement them in terms of abstractions and applications.

My new goal is to implement a reducer for expressions with names, which means I need to implement ɑ-Conversion after all :/

The reducer should expand definitions lazily i.e. when a definition is on the left side of the outermost application.

Ideally the renaming of the ɑ-Conversion is also done in a separate step for a better user experience.

To do

• #26
• #27
• #35
• #18

Syntax:

[a + b] -> (TERM)

• #2

• Maximum for automatic church numerals (large numbers can overflow the stack)
• Maximum steps for beta-reduction
• Predefined definitions (with a warning if you shadow it)
• Option to disable syntax sugar such as automatic church numerals, definitions, etc.
• Spans that point to different files (so that the embedder can surround the user code with an application to pass in data–errors should point to a different "file" in that case)

API shape that I have in mind:

pub fn reduce_to_normal_form(
    expression: Expression<'_>,
    max_reductions: u64,
) -> impl Iterator<Item = DiagnosticsResult<Expression<'_>>>;

I'm not sure what the best return type would be, but I think having the iterator is a good idea
because it allows my UI to display all steps and then an diagnostics message if we do to many reductions.
The diagnostic message should point to the application that was last applied.

Returning a diagnostic depends on #7.

Haskell is pretty liberal with the allowed operator symbols, that sounds nice:
https://www.haskell.org/onlinereport/haskell2010/haskellch2.html#x7-160002.2
Unicode categories:
https://www.unicode.org/reports/tr41/tr41-30.html#Unicode

• Abstractions
• Applications
• Comments

The AST should be as close to the entered syntax as possible. This makes warnings / suggestions much more powerful.

Some differences:

• The parser allows abstractions with more than one variable.
• The parser allows grouping using parenthesis.