[jbrot]

Very neat project! One question about content addressed programs: how does this play out with types that are structurally equivalent but semantically distinct?

For instance, assuming C definitions, an integer and a file descriptor have the same content but probably should not be treated as the same type (I wouldn’t want arithmetic to type check against file descriptors…).

Another scenario: say I have a type “Foo” which contains an integer. In version 1 of my library, this integer must be even, but in version 2 I add support for odd integers, too. The Foo data type, from a content perspective, is unchanged. However, the invariants around it have changed and it’s therefore essential that it becomes a new type. Otherwise, someone might create a Foo containing an odd integer using the version 2 API and then pass it to a function from the version 1 API, resulting in bad things since the version 1 API believes Foo can never contain an odd integer.

[refried_]

The language has "unique" types, meaning they have their own semantic meaning apart from their structure; they get a unique hash (currently implemented by adding a random salt to the hash of the structure, though it might as well be a guid). So "unique" types and "structural" types.

The same question came up for terms, here: https://news.ycombinator.com/item?id=27654045

[jbrot]

Glad to hear there’s a solution for this! Thanks for responding :)

[kroltan]

It looks from the other discussions that it's specifically content-addressed, not "semantic-addressed", so if your code has any redundant syntax (the given example being `x -> x + 2` vs `x -> x + 1 + 1`) it's still distinct.

In that case, I guess data types can have a 0-size marker member, kind of like Rust's `PhantomData` type, that could ensure distinctness.