Rethinking Syntax: Binding by Adjacency (opens in new tab)

> The drawback is that building an AST now requires a symbol table

Well, yes and no. During AST building a binding expression resolves as an untyped polyadic expression. Only later during the compiler's type attribution phase does a binding expression's structure resolve based on the operand types.

https://github.com/manifold-systems/manifold/tree/master/man...

> in typical code you don’t have the case of constant values so often.

Agreed. It's not really useful with inlined expressions:

   Schedule contacts.select(contactId) inputForm.getDateTime()

but if you write it like:

   var plumber = contacts.select(contactId)
   var date = inputForm.getDateTime()
   var building = findLocation(warehouse)
   Schedule plumber on date at building

But, honestly, I can't say I personally use it that way ;)

Initially, I wrote it as a science extension to Java: https://github.com/manifold-systems/manifold/tree/master/man...

Isn't it obvious?

It's the range from 1773100800 down to 13.

Author here.

Yes, technically this is a form of backtracking, similar to what a parser does. The key difference is that the search is drastically constrained by the type system: reductions are only attempted where the types actually support a binding operator. Unlike a parser exploring all grammar possibilities, this mechanism prunes most candidates automatically, so the compiler efficiently "solves" the expression rather than blindly exploring every syntactic alternative.

Here is the high-level explanation of the mechanism:

https://github.com/manifold-systems/manifold/tree/master/man...

But the short answer is that it’s not parser-style backtracking over a grammar.

The Java parser still produces a normal AST for the sequence of tokens. What happens afterward is a type-directed binding phase where adjacent expressions may bind if their types agree on a binding operator. The compiler effectively reduces the expression by forming larger typed expressions until it reaches a stable form.

The algorithm favors left associativity, but since a type can implement the binding operator as either the left or right operand, the overall structure of the expression can emerge in different ways depending on the participating types.

So rather than exploring grammar productions, the compiler is solving a set of type-compatible reductions across the expression.

For example:

    2026 March 10

reduces roughly like this:

    (2026 (March 10))
    → March.postfixBind(2026)  // → LocalYearMonth
    → [retreat]                // → no binding with 10
    → March.prefixBind(10)     // → LocalMonthDay
    → .postfixBind(2026)       // → LocalDate

And if `Month` binds with `Range<Integer>`:

    2026 March 10 to 13

can reduce as:

    (2026 (March ((10 to) 13)))

The meaning is therefore determined entirely by which types participate in binding e.g., `LocalDate`, `Month`, `Integer`, `Range`, etc. and which reductions they define.

If a competing interpretation exists but the types don’t support the necessary bindings, it simply never forms.

In that sense it behaves less like a traditional parser and more like a typed reduction system layered on top of the Java AST.

Yes, the empty infix operator is often called the "juxt" operator, which is an apt term here.

However, I use the term "binding expressions" intentionally because there’s more going on than ordinary juxtaposition. In a normal juxt expression such as:

    a b c

the evaluation order is static and independent of the type system:

    (a b) c

With binding expressions the precedence is type-directed, so the type system determines which grouping is valid:

    (a b) c
    a (b c)

Additionally, the operation itself can be provided by either operand. For a given expression a b, the compiler may resolve it as:

    a.prefixBind(b)
    b.postfixBind(a)

For example:

    10kg

Here kg is a MassUnit, and MassUnit defines postfixBind(Number) returning Mass, so given there is no left-to-right binding, the expression resolves right-to-left as:

    kg.postfixBind(10)

So while juxtaposition is the syntactic surface, the semantics are type-directed binding.

Haskell supports user-defined operators (made up of symbols) and also lets you use functions in infix position by surrounding the name in backticks, e.g.

    2 `plus` 3

rather than

    plus 2 3

In Postgres you can define custom operators via `create operator`[0]

    -- infix
    select a <!!!> b;

    -- prefix
    select <||> a;

A lot of custom types end up using this [1].

    select @-@ '[(0,0),(1,0),(1,1)]'::path;
    -- 2

[0] https://www.postgresql.org/docs/current/sql-createoperator.h... [1] https://www.postgresql.org/docs/current/functions-geometry.h...

Similarly, Agda has a well-typed mixfix operator syntax – you define a function like (_foo_bar_baz) and can automatically write "X foo Y bar Z baz". It does mean that the operator parser has to be extensible at runtime, but it's not a huge cost for a dependently-typed language.

StringTemplates were withdrawn.

No, stack languages can’t achieve this as described.

If you added a function to the examples, you could do a few of them, e.g.:

    2025 July 19 date

    299.8 M m / s velocity

But even this breaks down when you get to something like “Meet Alice Tuesday at 3pm”. Sure, you could contort things to make it resemble the concept, but it’d be a stretch at best.