So… I love the fact that Unison stores functions based on their ASTs with names separate. This means as long as you’ve written code once, and added it to UCM, it’s forever available. — not with Exercism exercises though.
My Isogram solution uses a method from my Acronym solution — which works perfectly locally.
When I upload this to Exercism, the run fails — obviously — because I doubt there’s a reference to acronym.wordBoundary in the test runner instance. A simple solution here would be to duplicate .wordBoundary in isogram, but something tells me that’s not very Unison-esque.
Ask: Would it be possible to reuse our methods from previous solutions in subsequent ones?
I’m asking because I know there’s a public exercism namespace on Unison. Now I know that if people’s solutions are made public, everyone could easily use the existing methods and pass the exercises. What I’m asking for is a protected — in terms of OO — scope where I can access my methods on Exercism, but no one else can.
Hi @igbanam! That’s a very interesting idea. You’re right that one of Unison’s benefits is immutable code sharing, and also correct in the observation that there’s no reference to wordBoundary in the test runner without prepending it to the file being submitted.
Unfortunately, the runs submitted to the exercism test-runner are sandboxed in such a way that a user’s submitted exercise can’t have access to previous implementations and don’t have access to a user’s codebase. The state is wiped clean each submission. Within the UCM, though, things are different. You can reference terms from other exercism namespaces freely.
One thing to note is that having duplicate instances of a useful shared term, like wordBoundary in multiple namespaces in the UCM isn’t considered a defect in organization because those terms are identical according to the UCM and won’t take up more space in the codebase. You can even give them two different names and it won’t matter.
As for the public Exercism stubs namespace, it’s public in that everyone can view and pull it, but only folks with unison credentials can update it, so it’s unlikely that it would contain answers in the future. We’ve thought about adding a protected scope to functions as a language feature, as that may help with tree-shaking function dependencies, but I suspect we’re a ways away from implementing that.
1 Like
Ah right right. Because a definition is stored as its AST anyways, it shouldn’t matter. I guess I was unsure if that behaviour carried across namespaces. Thanks for clearing my doubts.
Echoing what I understand for clarity and validation: if namespace1.method has the exact definition as namespaceN.elsewhere, both would be names under the Unison hash for that AST/form. So copying functions under different names for the purposes of Exercism exercises does not impact Unison adversely since the new names just register as yet-another-alias for the AST’s hash.
Right, assuming namespace.method was added first, and both terms are in the same project, Unison would ingest namespaceN.elsewhere, examine its AST, see that it was the same as namespace.method and add the new name as metadata associated with that AST.
There can be some surprises as a result of this. Unison will pick the alphabetically first name when viewing the body of a function, which is something we want to fix in the future, as that can cause confusion. You can check how many names a function has with names myFunction in the UCM to help see how many mappings your AST has.
