Why don't more languages offer flow typing?

Post by alduin32 » Mon, Apr 04, 2022, 7:57 PM UTC

chriswarbo wrote: post #26

Nobody's mentioned dependent typing yet, but languages like Idris and Agda will "narrow types based on control flow" (in fact, since they're pure-functional, control-flow is the same as data-flow). For example, zipping two vectors of the same length: zip: Vec n t1 -> Vec n t2 -> Vec n (t1, t2) zip Nil Nil = Nil zip (Cons x xs) (Cons y ys) = Cons (x, y) (zip xs ys) Here the 'Vec' type has two constructors, Nil and Con…

Post by jerf » Mon, Apr 04, 2022, 8:02 PM UTC

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…

Post by alduin32 » Mon, Apr 04, 2022, 8:11 PM UTC

dragonwriter wrote: post #68

alduin32 wrote: post #66

Earlier quoted context omitted.

I don't think pattern matching and union-types makes narrow typing useless. Rust has both pattern matching and union types but still implements some specific forms of control-flow based typing. For example, consider this Rust snippet : pub fn positive1(x: isize) -> Option { if x > 0 { Some(x as usize) } else { None } } Unless I'm mistaken, without narrow typing, this cast would be impossible, and there would be no wa…

> Unless I'm mistaken, without narrow typing, this cast would be impossible same sized integer casts in Rusts are no-ops [0]; the conditional isn't type narrowing, it just avoids the cases where the cast would not preserve the same semantic value. [0] https://doc.rust-lang.org/reference/expressions/operator-exp...

Post by marcosdumay » Mon, Apr 04, 2022, 8:20 PM UTC

dragonwriter wrote: post #46

lambdasquirrel wrote: post #19

Earlier quoted context omitted.

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.)

Post by mhink » Mon, Apr 04, 2022, 8:26 PM UTC

jillesvangurp wrote: post #22

fuzzy2 wrote: post #15

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

In Kotlin this is called smart casts. It works great. Doing a null check means that after that you can treat the variable as non nullable. Doing a type check, narrows down the type to what you just checked. Or going down a switch statement branch on the type actually implicitly does the cast as well. It's both strongly typed and convenient. Kotlkin even goes a step further and introduced contracts few versions ago th…

    function isFish(pet: Fish | Bird): pet is Fish {
      return (pet as Fish).swim !== undefined;
    }

    // Both calls to 'swim' and 'fly' are now okay.
    let pet = getSmallPet();
 
    if (isFish(pet)) {
      pet.swim(); 
    } else {
      pet.fly();
    }

    function assertIsDefined(val: T): asserts val is NonNullable {
      if (val === undefined || val === null) {
        throw new AssertionError(`Expected 'val' to be defined, but received ${val}`);
      }
    }

    function doSomething(pet: Fish | undefined) {
      assertIsDefined(pet);

      // safe to use without checking for null/undefined,
      // because our assertion function narrowed the type for 
      // usage later in the function 
      pet.swim();
    }