Hacker News Reader

Comment by oftenwrong | Hacker News Reader

Content-addressed ASTs make so many problems go away. No dependency hell. No merge conflicts. Fully incremental build, test, distribution, etc. Everyone can use their preferred formatting, or even their own syntax. I think the future of programming will involve this paradigm.

View on HN

Just content-addressability isn’t enough, there should be also canonical forms, I.e.

h = hash(to_canonical_form(AST))

Preferably, there should be one-and-only-one way to perform or compute things, but modern PLs plagued by flexibility syndrome.

Also, the same should be done for the binaries, since the same AST may produce different binaries, unless you take into account all the compiler options, and runtime differences.

I think this is impossible in theory (but maybe not in practice ;))

Determining if two programs are equivalent is generally as hard as running the programs for every input and comparing them.

Yes, I'm talking about practical solutions, similarly like Halting Problem doesn't have a solution according to the CS, but there are practical solutions like the one used in Ethereum with its gas-based metering, or disallowing recursion or unbounded loops.

Some practical solutions:

- reduce code variability, by removing similar/alternative programming constructs / flexibility syndrome

- stick to a single programming paradigm

- remove syntactic sugar, or provide a clear rules to reduce it to a sugarless canonical form

- use a rich standard library (to avoid reimplementing the same functionality in different ways)

- use rich standard data types (to avoid definition of the similar types in different ways)

- sort every unordered construct, similarly how AWS signature sorts the keys before calculating the API call signature

- reduce the use of macros, custom eDSLs, or highly personalized code (by making writing this kind of code inconvinient)

- etc.

> no merge conflicts

In what sense?

I mean, in the following code

  # version 0
  name = "bob"

I branch and change to

  # version 1
  name = "alice"

And you update the main branch to

  # version 2
  name = "clair"

Then I'll still have a merge conflict right?

How does a content addressed AST solve the problem of having a different intent?

Definitions are immutable. Changes to the codebase may add new definitions, but cannot change existing definitions. The codebase only grows larger as it is changed. To give an analogy, it's like having a git repo where the only change you can commit is to add new files; you will never have a conflict with such a restriction. However, Unison does make use of names. You can change 'name' to point to a new definition, but it does not affect existing definitions that depended on the old definition for 'name'.

https://www.unison-lang.org/learn/usage-topics/workflow-how-...

I’m surprised I haven’t seen a Lisp with content-addressed ASTs, given that it already is authored at the AST level.

Do you have any follow up links on this topic by chance? I seem to have missed it in the docs.

https://www.youtube.com/watch?v=gCWtkvDQ2ZI&

This video is a little old but I remember finding it really interesting and I think dives into it a bit.

Reply on news.ycombinator.com