+1 for sum types/discriminated unions. We should try to add these to Go, if a good syntax & implementation can be brought forward. Interfaces are not a fully satisfactory alternative.
On Sun, Jun 12, 2016 at 2:52 PM Jesper Louis Andersen < jesper.louis.ander...@gmail.com> wrote: > > On Sun, Jun 12, 2016 at 11:09 PM, 'Axel Wagner' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > >> I'm actually not sure what safety means in this case. >>> >> >> Less opportunity for people to make mistakes that make a program panic. >> >> > > In the context of types, it often means that the system has two properties: > > progress - which roughly means that any well-typed program fragment either > is a value (i.e., fully reduced) or can take a step (towards full > reduction). > > preservation - which informally means that if a program has type T before > reduction, it preserves that type throughout the computation. I.e., it is > not possible to switch the type of a program in the middle of the > computation. > > Together, they form a protective barrier for a well typed program in that > it cannot go wrong with a type error. Typical things which destroys this > property are stuff like type casts (C-style), since preservation is > thwarted. > > If I have a function from AST to Stmt, say, then if I'm able to return > something of type Expr, say, it isn't type safe in the above sense. It > switches the return type from an Stmt to an Expr. > > You can argue that sum types should not be added to a language[0], but > they are absolutely indispensable as a tool for understanding program > semantics. The sum type is a generalization of a lot of patterns you see in > typical "mainstream" languages: exceptions, the Go error type, dynamic > dispatch (i.e., OOP), and "dynamic typing" are all concepts enjoying an > embedding in the fabric of sum types. So the study of these subjects are > greatly helped along if you cast them as sum types in your semantic logic. > > [0] Given that a language has products, i.e., structs/records, I find it > quite natural to add it's logical dual, sums, as well. If you think about > it, a product/struct correspond to "type X AND type Y AND ...", logical > conjunction, whereas the sum is "type X OR type Y OR ..." which is logical > disjunction. A logic with only one side is severely limited in expression. > So this is one of the places I politely disagree with the Go stance. Once > sums are inside the language, you can write optimization passes in the > compiler for them, which is a necessity; otherwise you end up wasting > allocations you could have avoided in the first place. > > > -- > J. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
