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

121–127 of 127 posts

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

#121

Post by munificent »

cannabis_sam wrote: post #111
munificent wrote: post #85

Earlier quoted context omitted.

Almost all of the languages I know that do "flow typing" (TypeScript, Flow, Hack), "smart casts" (Kotlin), or "type promotion" (Dart) are fairly statement-oriented. Expression-based languages tend to have pattern matching which provides another way to solve the same problem. Flow typing is most useful in imperative languages where code like this is common: if (foo is! Bar) return "not a Bar"; foo.someBarMethod(); Ear…

How does pattern matching solve the same problem?

It gives you a very nice notation for checking if a value has some type and, if so, binding a new variable that refers to it as that more specific type.

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

#122

Post by sfvisser »

chowells wrote: post #80
sfvisser wrote: post #30

Contrary to what many comments here state, I don’t think this is only useful in a dynamic runtime kind-of environment. I often think I could use some form of this in Rust and/or Haskell. In a very specific way: I often want a single constructor/branch of an enum (sum type) to a be a type as well, specifically a sub-type of the full enum. So once I learn about what branch a value is, I can treat it like that and even…

You can do this in Haskell with GADTs. data Up data Down data Foo tag a where Up :: a -> Foo Up a Down :: String -> Int -> Foo Down a When you enable all the necessary extensions for this to compile, it gives you exactly what you've asked for. If you leave the tag variable polymorphic in a function argument, you can receive values of either constructor. If you specify Foo Up a, you can only receive values with the Up…

Definitely yes!

It's a loooong time ago, but the pattern exhaustiveness checker of GHC wasn't up to this last time I tried. But my guess is things are much better now and this might actually work.

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

#123

Post by chowells »

sfvisser wrote: post #122
chowells wrote: post #80

Earlier quoted context omitted.

You can do this in Haskell with GADTs. data Up data Down data Foo tag a where Up :: a -> Foo Up a Down :: String -> Int -> Foo Down a When you enable all the necessary extensions for this to compile, it gives you exactly what you've asked for. If you leave the tag variable polymorphic in a function argument, you can receive values of either constructor. If you specify Foo Up a, you can only receive values with the Up…

Definitely yes! It's a loooong time ago, but the pattern exhaustiveness checker of GHC wasn't up to this last time I tried. But my guess is things are much better now and this might actually work.

There have been big improvements in the exhaustiveness checker. I know that it's not fully decideable with GADTs, so it will always have some holes, but it can handle this case now.

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

#124

Post by lupire »

epolanski wrote: post #96
jcranberry wrote: post #37

Earlier quoted context omitted.

Sum types are often used in cases where the type is unknown at run time. In C++ the analog would be std::variant. In Rust it would be enums. In Haskell its algebraic data types. A first class sum type in c++ ala Rust or Haskell would certainly be appreciated, as the clunkiness of std::variant/std::visit is a well known annoyance.

Could you expand on your first sentence? I don't understand what do you mean that sum types are used when the type is unknown at runtime.

They meant unknown at compile-time, not run-time.

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

#126

Post by cannabis_sam »

munificent wrote: post #121
cannabis_sam wrote: post #111

Earlier quoted context omitted.

How does pattern matching solve the same problem?

It gives you a very nice notation for checking if a value has some type and, if so, binding a new variable that refers to it as that more specific type.

How does that solve the problem of statements being devoid of return information?

Also, what? Pattern matching differentiate between values of a single type, and while the assignment mechanism is a great nice-to-have, it still completely follows the basic type consistency that actually typed functions provide.

Statements have none of these qualities..

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

#127

Post by munificent »

cannabis_sam wrote: post #126
munificent wrote: post #121

Earlier quoted context omitted.

It gives you a very nice notation for checking if a value has some type and, if so, binding a new variable that refers to it as that more specific type.

How does that solve the problem of statements being devoid of return information? Also, what? Pattern matching differentiate between values of a single type, and while the assignment mechanism is a great nice-to-have, it still completely follows the basic type consistency that actually typed functions provide. Statements have none of these qualities..

I'm sorry, but we seem to be talking past each other.

Why is it a problem that statements are "devoid of return information"? A statement occurs in a position where, by definition, no value it produces will be used.

Post reply on HN