Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why don't more languages offer flow typing?

ayazhafiz.com

Post reply on HN
Print view View original

41–50 of 127 posts

Re: Why don't more languages offer flow typing?

#41

Post by _old_dude_ »

valenterry wrote: post #12

The 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…

You need flow typing when you do pattern matching on generalized abstract data type (GADT). Here is an example in Java

    sealed interface Foo permits Impl {}  // union type
    record Impl() implements Foo {}  // product type

     T m(Foo foo) {
      return switch(foo) {
        case Impl impl -> "hello";  // flow typing T=String 
      };
    }

Re: Why don't more languages offer flow typing?

#43

Post by dragonwriter »

jerf wrote: post #4

This 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…

Dynamic and strong typing are not opposed (dynamic and static typing are opposed, and, to the extent the distinction is valid, weak and strong typing are opposed), dynamic doesn't mean everything is physically boxed (most dynamic language implementations don't box some subset of small primitive values, usually including bools and small ints), and, in any case, flow typing is a feature of static type systems (though some of those offering it are optional static typing systems for dynamic languages.)

But you kind of get at the real answer toward the end despite talking around it most of your post: Sum types plus pattern matching solves the same set of problems union types with flow typing solves, and a bunch that the latter doesn't (like composability.)

Re: Why don't more languages offer flow typing?

#44

Post by yxhuvud »

baby wrote: post #39

What’s the difference with type inference? Is it that flow typing can happen at runtime for just in time /noncompiled languages?

Flow typing is basically a kind of type inference where the derived type of a variable is allowed to be different in different places of the code, based on control flow. However, not all type inference is flow typing.

Flow typing is definitely a thing also in compiled languages, one example is Crystal, which is both compiled and has flow typing.

Re: Why don't more languages offer flow typing?

#45

Post by yxhuvud »

colonwqbang wrote: post #20

Doesn'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 -> ... Inside each branch, we have access to a value of the more specific type.

Why should type narrowing be limited to just case, and not both case and if? I'd argue that both of these are examples of flow typing.

Re: Why don't more languages offer flow typing?

#46

Post by dragonwriter »

lambdasquirrel wrote: post #19
valenterry wrote: post #12

The 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) }

You mean sum types, not union types (TypeScript has union types, your example uses sum types.)

Re: Why don't more languages offer flow typing?

#47

Post by noveltyaccount »

cmrdporcupine wrote: post #40
noveltyaccount wrote: post #35

Earlier quoted context omitted.

I really enjoy Typescript, but every time I use it I think to myself, this would be so much better if were built on top of something other than JavaScript. Maybe AssemblyScript or some other TS to WASM target will come along with a better underlying type system and a good standard library. Dare to dream.

Yep. Except that the base semantics of the language really are tuned for JavaScript. So I can't see a separation being feasible between the two. It would have to be a new language, sharing maybe 90% of syntax etc. but differing in some places where interoperability with JS has forced compromises (base number types is one thing I can think of. I'd like separate int and floats, etc.) and, yeah, targeting WASM etc. And…

Yes that's what I meant by proper type system - int, float, decimal... proper date/time/timezone support. To name a few :)

Re: Why don't more languages offer flow typing?

#49

Post by dllthomas »

dragonwriter wrote: post #43
jerf wrote: post #4

This 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…

Dynamic and strong typing are not opposed (dynamic and static typing are opposed, and, to the extent the distinction is valid, weak and strong typing are opposed), dynamic doesn't mean everything is physically boxed (most dynamic language implementations don't box some subset of small primitive values, usually including bools and small ints), and, in any case, flow typing is a feature of static type systems (though s…

> dynamic and static typing are opposed

Any given typing judgement we might want to make about a particular term can be checked statically or not, and it can be checked dynamically or not.

If the language has terms (... that might be evaluated) that don't get checked statically or dynamically, then it is going to be weakly typed (with respect to those typing judgements we're considering).

If we've already checked something statically, we "know" that it will always hold, and checking it dynamically is in some sense redundant (provided we actually believe our checking to be correct and our environment to be sufficiently robust that things don't change out from under us) and I think that's a part of the reason the two feel opposed, but in principle you could check a property both statically and dynamically for a particular term.

Step back a little to the language level and they aren't at all opposed; you might want to check some properties statically and some dynamically (eg. static checking of class/interface vs dynamic nullability in Java) or check a given property statically for some terms and dynamically for others (eg. gradual typing).

Re: Why don't more languages offer flow typing?

#50

Post by zozbot234 »

jerf wrote: post #4

This 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…

> In these languages, this sort of narrowing is a great deal more complicated, because it implies a new type, which will probably require more allocation.

Flow typing need not imply any kind of "narrowing", though. It could simply endow a control-flow branch with a statically-typed proof object, asserting whatever post-conditions were established in the branch. The "narrowing" could then become a separately-coded step, taking that proof object as part of its input arguments.

Post reply on HN