aha yeah! good question! We have two different types of type declarations, and each has its own keyword: "structural" and "unique". So you can define two different types as as
structural type Optional a = Some a | None
structural type Maybe a = Just a | Nothing
and these two types would get the same hash, and the types and constructors could be used interchangeably. If you used the "unique" type instead:
unique type Optional a = Some a | None
uniqte type Maybe a = Just a | Nothing
Then these would be totally separate types with separate constructors, which I believe corresponds to the `BRANDED` keyword in Modula 3.
Originally, if you omitted both and just said:
type Optional a = Some a | None
The default was "structural". We switched that a couple of years ago so that now the default is "unique". We are interestingly uniquely able to do something like this, since we don't store source code, we store the syntax tree, so it doesn't matter which way you specified it before we made the change, we can just change the language and pretty print your source in the new format the next time you need it.
How does the implementation of unique types works? It seems you need to add some salt to the hashes of unique type data, but where does the entropy come from?
> Unison is among the first languages to ship algebraic effects (aka Abilities [1]) as a major feature. In early talks and blog posts, as I recall, you were still a bit unsure about how it would land. So how did it turn out?
No regrets! This Abilities system is really straightforward and flexible. You find yourself saying that you don't miss monads, if you were already of the FP affiliation. But were glad that it means that you don't have to understand why a monad is like a burrito to do FP.
> Do you like the syntax?
So this one is very loaded. Yes we LOVE the syntax and it is very natural to us, but that is because most of us that are working on the language had either already been fluent in haskell, or at least had gotten to at least a basic understanding to the point of of "I need to be able to read these slides". However we recognize that the current syntax of the language is NOT natural to the bulk of who we would like to be our audience.
But here's the super cool thing about our language! Since we don't store your code in a text/source code representation, and instead as a typechecked AST, we have the freedom to change the surface syntax of the language very easily, which is something we've done several times in the past. We have this unique possibility that other languages don't have, in that we could have more than one "surface syntax" for the language. We could have our current syntax, but also a javascript-like syntax, or a python-like syntax.
And so we have had lots of serious discussions recently about changing the surface syntax to something that would be less "weird" to newcomers. The most obvious one being changing function application from the haskell style "function arg1 arg2" style to the more familier "c?" like style of "function(arg1, arg2)". The difficulties for us will be trying to figure out how to map some of our more unique features like "what abilities are available during function application" onto a more familiar syntax.
So changing the syntax is something that we are seriously considering, but don't yet have a short term plan for.
yeah, unison cloud is like the "heroku for functions" if you wanna not think about how deployments work. But you can just run unison programs standalone or in a docker container or whatever: https://www.unison-lang.org/docs/usage-topics/docker/
> Unison seems well-designed for this use case because it seems like you could easily run untrusted Unison code without worrying about it escaping its sandbox due to the ability system. (Although this obviously requires that you typecheck the code before running it. And I don't know if Unison does that, but maybe it does.)
Indeed we do, and we use this for our Unison Cloud project [1]. With unison cloud we are inviting users to ship code to our Cloud for us to execute, so we built primitives in the language for scanning a code blob and making sure it doesn't do IO [2]. In Unison Cloud, you cannot use the IO ability directly, so you can't, for example, read files off our filesystem. We instead give you access to very specific abilities to do IO that we can safely handly. So for example, there is a `Http` ability you can call in Cloud to make web requests, but we can make sure you aren't hitting anything you shouldn't
I'm also excited about using this specifically for games. I've been thinking about how you could make a game in unison cloud and another user could contribute to the game by implementing an ability as a native service, which just becomes a native function call at runtime. I started working on an ECS [3] a while back, but I haven't had a chance to do much with it yet.
I think Alvaro's at the Unison conference was a pretty cool demonstration of what you can do with the style of algebraic effects (called "abilities" in unison)
He implements an erlang style actor system, and then by using different handlers for the algebraic effects, he can "run" the actor system, but also optionally make a live diagram of the actor communications.
It's possible that we no longer remember ALL of the evidence we had when we drafted this letter, but the letter links to two first hand accounts of wrongdoing. I also have also talked to multiple other women in the community that say that Jon was someone that women generally knew to warn each other about since there were enough believable accounts of his wrongdoing.
we absolutely did this to protect the scala community and we weren't scared and didn't jump the gun. People had been talking about him as being problematic for years before the open letter
This was absolutely not based on hearsay. We made our decision to sign the letter based on direct evidence, not hearsay. The open letter links directly to evidence which is not hearsay.
> The open letter links directly to evidence which is not hearsay.
If you're referring to the two blog posts, that is testimonial evidence only. While it /is/ possible to convict on the basis of only testimony, it's very rare, as testimony usually needs to corroborated by documentary or physical evidence, or at minimum be supported by a preponderance of other types of evidence which makes the claims against a defendant more likely to be true than that they are false.
I am not you, I don't know you, and I don't have any particularly strong opinion about this situation. That said, you're all over the comments here, trying to defend the contents of the open letter. If you believe in this so strongly, I'd advise that you provide stronger evidence to support your position. Simply believing someone else who told you something is not substantial or corroborative.
