Is this something like GADT's?
Why don't more languages offer flow typing?
11–20 of 127 posts
Re: Why don't more languages offer flow typing?
#12The answer is simple: because other languages don't need it - they have different features to deal with it. The author even mentions it: pattern matching.
Just that he picks a language that doesn't support union-types. But that doesn't mean that flow typing would be necessary here - it means that the language(s) should support union-types and extend their pattern matching accordingly.
In fact, I would say that flow typing is almost like a workaround for missing pattern matching.
Re: Why don't more languages offer flow typing?
#13I'm trying to design a programming language that can be compiled into C99 and it's not at all clear to me how you represent these things statically.
The idea from a programming point of view is really nice and in a dynamic programming language environment everything is an object and you can pass whatever through any function. This doesn't work all that well if you want to translate your program into a statically typed environment, in a cost effective way.
You need some way to reason about the type information that hopefully doesn't create memory allocations all over the place.
This can be done by introducing tagged data types but it can also lead to a combinatorial nightmare where you need to generate a lot of extra code.
In general, I don't think all this complexity is warranted in a statically typed environment and depending what you are doing this doesn't end up being that important. Even if, it's a nice to have, it's mostly that, a nice to have.
Re: Why don't more languages offer flow typing?
#14It's not really called out as such, but the C# 8 feature Nullable Reference Types is an example of deeply embedding flow typing into a language. The nullability state of a reference type can change based on many things you can do in code. It's really neat and extremely intricate.
Re: Why don't more languages offer flow typing?
#15This is called Type Narrowing by the way. Control flow analysis is only one way this works in TypeScript.
Most languages don’t have the type system necessary to make this work in a sensible way.
Re: Why don't more languages offer flow typing?
#16fyi Java 16 did add pattern matching for instance of so you can avoid the cast.
I was going to point this out, too.
I thought it also supported cases like:
if (foo instanceof Bar) { // foo is typed as Bar in this block }
Is that true, or did I get that wrong?
Re: Why don't more languages offer flow typing?
#17This is not a complete answer, but covers some languages. If you program too exclusively in dynamically-typed languages, you can be too used to not thinking about how physically large your types are, because you work in a world where everything is boxed, and allocations so plentiful you don't even hardly have a way of thinking about them because your language does them at the drop of a hat, and so on. But there are m…
Isn't this sort of an orthogonal problem? Flow typing implies that your type is in some way unknown at the time the code fragment is evaluated. I think this can mostly happen in two situations:
1) The type is generic: A function may be called with a different type on each call site - but for each particular call site, the type is known at compile time.
2) The type is polymorphic - i.e. the full type is not known at compile time at all.
When the first case occurs, a compiler could either go the C++ way and generate different, non-generic variants of the function - or go the Java way and just pretend the type is polymorphic.
For the "C++" option, I think flow typing would fit very well without introducing additional complexity: For each variant the compiler generates, it knows which concrete type is used, so it can evaluate the condition at compile-time and just drop the branches that don't apply for a particular variant of the function.
For polymorphic types, on the other hand, the additional complexity is already priced in: You need some kind of mechanism to represent values of different structure anyway (pointers, unions, whatever) - so flow typing wouldn't be much more than some syntactic sugar to save you from writing casts you'd have to do anyway.
Re: Why don't more languages offer flow typing?
#18This is not a complete answer, but covers some languages. If you program too exclusively in dynamically-typed languages, you can be too used to not thinking about how physically large your types are, because you work in a world where everything is boxed, and allocations so plentiful you don't even hardly have a way of thinking about them because your language does them at the drop of a hat, and so on. But there are m…
Pretty much. Flow typing like TypeScript does it is only really sensible when your run-time supports dynamic typing but your compiler checks types statically. In other words only a language similar to TypeScript could have a type system similar to TypeScript's.
Re: Why don't more languages offer flow typing?
#19The answer is simple: because other languages don't need it - they have different features to deal with it. The author even mentions it: pattern matching. Just that he picks a language that doesn't support union-types. But that doesn't mean that flow typing would be necessary here - it means that the language(s) should support union-types and extend their pattern matching accordingly. In fact, I would say that flow t…
Yeah, the same code would look much clearer in a language with union types. Heck even Swift cribbed them.
switch resp {
case Result(val, meta):
doStuff(val)
case Error(msg, code):
logger.main.debug(msg)
}Re: Why don't more languages offer flow typing?
#20Doesn't "flow typing" seem more like a bandage for the if-statement in languages that have nothing better.
There is a language construct which is purpose built for unpacking sum types: The case expression (sometimes called match expression)
case resp of
Views n -> ...
Error e -> ...