This thread’s change in direction seems to be getting out of control very rapidly without providing much value to anyone involved. Please take a break and come back to this another day.
12 Likes
Again, resorting to personal attacks is really not going to get you anywhere. Not certain what point you are trying to make, so I’ll just take the opening that you’ve given to highlight something I realized recently.
People from fields other than computer science have contributed heavily to the Julia ecosystem. I think that’s important to note for a few reasons. First, that’s probably because of just how computational and quantitative many other fields, including economics, have become. In social sciences, people used to just do regressions. Now, they do structural models and machine learning that require supercomputing clusters. Second, does this really happen in any other language? Not really. Julia allows this because you can do it all in Julia and because of how composable the neat features are.
13 Likes
Back to the sum types, I don’t know about the theoretical underpinnings but I have used Swift and liked its handling of optional values a lot. It was just very reassuring to know in which cases values could be undefined and in which they definitely couldn’t. But I think the greatest value for me was always while writing code, because all these properties could be checked by the IDE before compilation. And I think that’s the point that Julia lacks, everything is very dynamic and flexible, but even if you write code that doesn’t need maximum dynamicism your IDE can’t help you with more than the most basic things. In Swift, I also really liked how it forced you to handle all options of an enum, and in each subbranch it would autocomplete the fields of the different enum instances. That saved so much thinking and typing, but I’m not sure if techniques like that are possible in Julia.
3 Likes
Yes, this is actually something I’ve been thinking about recently following some discussion on Zulip. My current idea is that whenever you define a sumtype, I also want to to define a function cases that would be like (but hopefully with a better API)
julia> using SumTypes
julia> @sum_type Either{A, B} begin
Left{A,B}(::A)
Right{A,B}(::B)
end
julia> function cases(e::Either, f_Left, f_Right)
if e.data isa Left
f_Left(e.data._1)
else #e.data must be a Right since Either is closed
f_Right(e.data._1)
end
end
cases (generic function with 1 method)
julia> cases(Left{Int, Nothing}(1), x -> x + 1, identity)
2
julia> cases(Right{Int, Nothing}(nothing), x -> x + 1, identity)
This would be an alternative to @match that forces you to deal with every case of the sum type.
Still working on an API for it though. Ideas and suggestions welcome.
1 Like
No worries, I am ignoring these kind of things. Those 
s went to others though 
I think that @Mason understands that I am just curious about the uses of sum types, that’s all. But writing a package to explore something is also a valid reason — essentially an essay (in the sense Montaigne used the the word, as an attempt at understanding something) written in a programming language.
FWIW, I think that Julia needs fewer of these advanced concepts in the type system because it’s not statically compiled (in the sense that the compiler needs to be able to figure out the type of everything), so it has an escape valve. Statically compiled languages have to invest a lot in type system formalism instead.
11 Likes
Not too sure if it helps, but an interesting way to think about tuples (categorically) is to consider that a function that returns a tuple, say f(x::S)::Tuple{T, U}, is actually the same as two functions, one f(x::S)::T (the first component), and the other f(x::S)::U (the second component).
Sum types do the dual thing, so a function f(x::Sum{S, T})::U is the same as a function f(x::S)::U (what to do when x::S) and a function f(x::T)::U (what to do when x::T). Of course in julia, thanks to multiple dispatch, one would just write the two methods separately. So, from my intuition, sum types exist already in the form of multiple dispatch: what you are doing here is provide a formal notion of a type that does this.
In terms of category theory, one thing that would maybe be interesting to think about are coequalizers and pushouts, which in terms of multiple dispatch would be a way to guarantee that given another type (say R) both in S and T (say R <: S and R <: T), then the methods f(x::S) and f(x::T) are indistinguishable for x::R.
10 Likes
I’m studying category theory for programming and I really appreciate that you made the type equivalent to sum type (tagged union) in category theory.
The absence of the type in julia was making me crazy this week.
Thank you!
4 Likes
Okay, so I’ve done some fixes and improvements to SumTypes.jl. I’ve implemented a native case matcher for the members of the sum types: GitHub - MasonProtter/SumTypes.jl: An implementation of Sum types in Julia, I’ve fixed some bugs and I’ve also improved the printing of sum types to make them a bit more legible.
As far as finding a use-case for these things, @jakobnissen is experimenting with a Rust style result type system which dovetails with this work nicely: GitHub - jakobnissen/ErrorTypes.jl: Rust-like error types in Julia
6 Likes
As a general opinionated comment, it is fun for me to observe the evolution of the Julia language. Although there are notable exceptions, I feel that Julia has so far been about “packages”. Packages are great for research and form the foundation for more commercial uses. As Julia matures, it seems clear that, in addition to packages, we’ll start seeing more “applications”. When it comes to building applications, having multiple dispatch available for an end product (although still useful for developing said end product) is less important because you have tighter control of what your users are allowed to do. With this shift, having static compilation of Julia applications is, I think, becoming more important so it is great to see progress in this area and packages like this seem important for the future of Julia 
Personally, if I had to write a statically compiled application, I would STILL want to write it in Julia 
4 Likes