Hacker News Reader

Comment by dcposch | Hacker News Reader

Cool to see people thinking this big!

One challenge I foresee is unintentional coupling. Say you have two functions:

func serialize(MyRecord) ...

func debugToString(MyRecord) ...

Now if you ever make the mistake of having giving those the same implemention, then in Unison they'd be the same hash reference, right?

Then if you want to update, say the debug print later it would update all callsites for that hash including the ones that originally called serialize(). The two are no longer distinguishable.

View on HN

Hello, Unison author here.

This is definitely an issue that is real, and is currently a problem, and that we will fix; probably by giving the function author an option to salt the hash of new definitions that have some semantic meaning beyond their implementations (appropriate for most application/business logic). No salt for definitions whose meanings are defined by their implementations (appropriate for most generic "library" functions like `List.map`).

We already make this distinction for data types, but not yet for value/function definitions.

Why not also show that your definition already exists elsewhere, together with with a warning? Or is it doing that too?

Why not simply record where each reference occurs and ensure that if one definition is modified, the other is not? The programmer shouldn't have to think about salting any hashes, it should be automatic and hidden under the hood.

This seems to be very developer hostile.

Not only do they have to provide a salt themselves but on top of that, they need to make a judgment call of when something has "more semantic meaning beyond their implementation" (to use your words) rather than being some more "fundamental" code.

I'm also surprised that you haven't solved this problem yet: at least once a day, IDEA warns me that some portion of my code is duplicated exactly in some other area of my code, so this kind of duplicated logic is already quite common.

Nice, makes sense!

The names are just pointers, and they're both pointing to the same definition in your example. But when you redefine one of those, you would point one of the names to a new definition.

It's similar to how DNS can have two domains point to the same IP, but then you can change one of those domains point to a new IP.

> The names are just pointers, and they're both pointing to the same definition in your example. But when you redefine one of those, you would point one of the names to a new definition.

But how do you know which name was called where if the callers referenced the content hash not the name?

Would it not be correct for those callers to keep calling the old (shared) implementation?

well it would be nice to have a way to update old code

I also think that the DNS analogy is wrong because all callers are hash-based. The only solution I see is to go through the list of all callers and manually update selected ones.

If I understand Unison right, the names are used only on the developer's layer(to write code), but when you save code, it's all hash-based.

Still, Unison got my attention.

It knows what name you intended to use, because that's in your source, so I'm pretty sure it isn't a problem if implementations converge and diverge.

Reply on news.ycombinator.com