[HN Gopher] Rethinking Syntax: Binding by Adjacency
___________________________________________________________________
Rethinking Syntax: Binding by Adjacency
Author : owlstuffing
Score : 35 points
Date : 2026-03-08 05:03 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| owlstuffing wrote:
| What if these were real, type-safe expressions in Java:
| 2025 July 19 // - LocalDate 300M m/s // -
| Velocity 1 to 10 // - Range<Int>
| Schedule Alice Tues 3pm // - CalendarEvent
|
| That's the idea behind binding expressions -- a compiler plugin I
| built to explore what it would mean if adjacency had operator
| semantics. It lets adjacent expressions bind based on their
| static types, forming new expressions through type-directed
| resolution.
|
| Details here: https://github.com/manifold-
| systems/manifold/blob/master/doc...
| evanb wrote:
| Mathematica has Infix [0], which expresses the adjacency with a ~
| (because Mathematica reserves pure blankspace for
| multiplication). But it works fine to do eg.
| `"hello"~StringJoin~" world"`; I was always surprised we could
| only have the predefined operators in many other languages and we
| couldn't define our own.
|
| This seems like a great attempt. I would be worried about how
| much parsing and backtracking might be required to infer the
| infix precedence in a totally general system (like garden-path
| sentences[1]) or actually ambiguous parse trees (which is cured
| by adopting some rule like right precedence and parens, but what
| rule you pick makes some 'natural language' constructions work
| over others).
|
| [0] https://reference.wolfram.com/language/ref/Infix.html
|
| [1] https://en.wikipedia.org/wiki/Garden-path_sentence
| nxobject wrote:
| 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.
| measurablefunc wrote:
| Congratulations, you reinvented yet another stack language.
| antonvs wrote:
| 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.
| ape4 wrote:
| Maybe with a Java string templates: var myDate
| = MAGIC"2025 July 19"
| jnpnj wrote:
| Sorry for this sounds absurd, but with diffusion language models,
| who generate text non-linearly (from the few that I get, they
| relate terms without a simpler order), I wonder if new syntactic
| ideas will come up.
| layer8 wrote:
| The drawback is that building an AST now requires a symbol table
| and resolving imports, possibly performing type inference and
| whatnot. It constitutes a higher barrier for various types of
| tooling. You really want your programming language to avoid
| becoming context-sensitive in that way.
|
| It's similar for the human reader: The examples are only
| intelligible to the reader incidentally, due to the names used
| and some natural-text conventions. In the general case, you have
| a seemingly random token sequence where you have no idea what
| binds to what, without looking up the type definitions or having
| an IDE present the expression in some structured way again.
|
| Furthermore, in typical code you don't have the case of constant
| values so often. You'll rather have things like:
| nextYear thisMonth.previous() lastDayOf(thisMonth.previous())
| Double.parse(speedInput) m/s startPos to (startPos +
| length - 1) Schedule contacts.select(contactId)
| inputForm.getDateTime()
| tgv wrote:
| I don't think this is useful in complex situations/expressions.
| Structure has to be encoded in the same place as meaning somehow.
| Natural language does it by using an extraordinarily large set of
| signifiers. That's not feasible for a formal language.
|
| You could of course affix all lemmata with structural
| information, as free word order languages do, but that's
| introducing syntactic structure via the backdoor.
| thesz wrote:
| An old paper on the expressiveness of the programming languages
| [1] had to add an implicit binary operator into whitespace to
| make Haskell not be ten times more expressive than most
| imperative languages.
|
| [1]
| https://www.researchgate.net/publication/2743686_Are_Ours_Re...
|
| So, yes, it can be done and it was done. Yes, expressiveness
| rises. No, reading comprehension of such languages does not
| suffer. Yes, it has to have a lot of scaffolding.
| bawolff wrote:
| I'm sorry, but that sounds like it would be a debugging nightmare
| when it doesn't work right.
| derefr wrote:
| The formal name for the "empty" binary infix operator that gets
| implied in the AST when doing this, is the "juxtaposition" (or
| "juxtapose", or "juxt") operator. The implicit multiplication
| operator between `3` and `a` in the polynomial expression `3a +
| 4`, and the implicit function-application operator in the Lambda-
| calculus expression `f x y`, are both instances of an implied
| juxtaposition operator (with different semantics for it in each
| of the two cases, as befits each type of algebra/calculus.)
___________________________________________________________________
(page generated 2026-03-09 23:00 UTC)