Experiment.

[matthewhammer]

Experiment: Incremental Motoko.

Add a small handful of general-purpose incremental computing primitives to Motoko (see adapton.org).

Specifically, this PR adds the following:

• put a value or expression into the incremental graph, pointing by "name":
  • either with an explicit programmer-chosen symbol value, producing a pointer based on that symbol (written as in @ e1 := e2),
  • or with an explicit name, and an implicit force of the internal expression body (written as do @ e1 { e2 }).
  • or with an implicit name as the closed expression itself, and an implicit force (written as in memo e).
• get value from graph, by name or pointer (written as @ e).
• thunk { e } (new value introduction form for thunk values).
• force thunk.
• force thunk pointer.
• symbolic constants, to act as programmer-chosen names.

Symbol literals

Generally written $( ... )), act as programmer-chosen names:

• numbers as symbols ($(1), and also just $1)
• identifiers as symbols ($(foo), and also just $foo)
• dashes, dots and underscores as separators between other symbols ($(foo-1) or $(foo.1), where outer parens are required in each case).

Numbers as symbols

Numbers are implicitly coerced into symbols when a symbol is needed to put, or get, etc.

(In the future, Text values can also easily be implicitly converted into identifier symbols, if we so choose that, but they may contain a lot of strange characters, so it's a reason to avoid it now.)

Basic properties of operators

The following assertions pass:

    assert_eq("force (thunk { 2 })", "2");

    assert_eq("@(memo {137 + 137})", "274");

    assert_eq("force (memo { thunk {137 + 137}})", "274");

    assert_eq("@(@1 := 4)", "4");

    assert_eq("do @1 { 2 + 3 }", "5");

    assert_eq("force(@1 := (thunk { 13 + 13 }))", "26");

Symbol operators

Symbol operators . and - combine symbol values operationally.
Just as with the existing syntax cases, the . operator binds tighter than -, and both associate to the left.

    assert_eq("$foo - $bar", "$(foo-bar)")

    assert_eq("$foo - $bar - $baz", "$(foo-bar-baz)");

    // '-' associates to the left.
    assert_eq("( $foo - $bar ) - $baz", "$(foo-bar-baz)")

    assert_eq("$foo . $bar", "$(foo.bar)")

    assert_eq("$foo . $bar . $baz", "$(foo.bar.baz)");

    // '.' associates to the left.
    assert_eq("( $foo . $bar ) . $baz", "$(foo.bar.baz)")

    // dot binds tighter than dash.
    // dash binds looser than dot.
    assert_eq(
        "$foo . $bar - $baz . $goo",
        "( $foo . $bar )  - ( $baz  . $goo )",
    )

[rvanasa]

Cool! Because this diverges from the documented Motoko grammar / semantics, it might make sense to keep this on a separate fork or branch (similar to the Motoko-san VS Code extension). WDYT?

[matthewhammer]

it might make sense to keep this on a separate fork or branch

Good idea.

FWIW, I also want this project to still act like "the spec" of Motoko when desired, where these features are disabled entirely.