stewoconnor

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.

> congrats on the release

Thank you!

> 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.

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.

I signed the letter and I fully stand by everything it says. I have talked to Yifan and I feel sorry for her and believe her.

It was well known, and well discussed that women in the scala community knew to warn other women about Jon Pretty. I have heard this both directly and indirectly from multiple prominent women in the Scala community.

Yes this is unfortunately a problem that comes up with our current system. We had to solve this early on by distinguishing "unique" types form "structural" types. For types it is obvious that you want to make sure that these types generate a unique hash, even if they are the same structure:

type UserName = UserName Text type Password = Password Text

since the entire point in introducing types here is to actually declare them as different from one another.

But for other it might actually be beneficial to recognize that they are the same type, for example:

type Optional a = None | Some a type Maybe a = Nothing | Just a

To allow for both, you can prefix type with either "structural" or "unique" depending on what behavior you want (unique is the default). We have tossed around the idea of also introducing unique terms which would let you terms like yours as unique terms that should be salted, and let the current behavior of "structural"? terms be the default. The reality is that this hasn't been such a big problem that it has made it to the top of our list yet ;)

for us, A and B are the same Term since they have the same hash, they are just two different alias for that hash, so if you update either, you are effectively updating both.

In fact if you had the function:

double x = x + x

and you were to rewrite it to be:

double addend = addend + addend

Unison would say "this is the same function, no update needed" as it produces the same AST