7 ms·

Can you explain how you view Typescript’s type system as ‘more advanced’ than Haskell’s type system? I am working on a language currently and wonder what gives

Can you explain how you view Typescript’s type system as ‘more advanced’ than Haskell’s type system? I am working on a language currently and wonder what gives you that impression as a user who seems knowledgeable and demes to have a preference for one style verses the other.

dwohnitmok 6y ago
Typescript has all sorts of type-level computation goodies that Haskell doesn't have (unless you turn on insane amounts of GHC extensions). Stuff like mapped types, keyOf, typeOf, ReturnType, literal types, conditional types etc. all combine to give you a certain amount of dependent types in Typescript but also a very rich way of doing type level computations (this is how e.g. in Typescript we can have type signatures that capture all sorts of very dynamic Javascript function signatures). On top of this Typescript also has a strong structural type system augmented by union types and intersection types. You can fairly easily emulate a nominal type system like what Haskell has on top of this system, especially with Typescript's string literal types, but it's quite difficult to go the other way. The only big thing I can think of that both Haskell and Scala have that Typescript doesn't is higher-kinded types. I also want to strongly caution that I don't think a more advanced type system is necessarily a better type system! E.g. I'm not convinced that Typescript really needs HKTs. Likewise I have previously programmed quite happily in Elm despite its paucity of type-level features in comparison to Typescript.
- forkerenok 6y ago
  Thanks for this write-up. What about ADTs and pattern matching? Afaik, they are not available in Typescript and the emulations that I've seen are very sloppy.
  - paavohtl 6y ago
    TypeScript supports ADTs (discriminated unions) and not-quite-pattern matching using a combination of features: union types, literal types and control-flow based type narrowing. Here's an example from the TS handbook: https://www.typescriptlang.org/docs/handbook/unions-and-intersections.html#discriminating-unions https://www.typescriptlang.org/docs/handbook/unions-and-inte.... What you need to understand about TypeScript is that it ultimately is just JavaScript. After TS 2.0 a decision was made that TS will align with standard EcmaScript and will not implement any* run-time features not part of the ES standard or ES proposals. Because of this decision TypeScript cannot have a proper dedicated pattern matching syntax until JavaScript gets one. TypeScript does support some pattern matching using ifs and switch statements and other control flow structures, but that's as good as it gets until JS improves as well.
  - Garlef 6y ago
    Here's what I use: https://github.com/gbegher/groth/blob/460852a71859f149ecf9b5154af65eb958f869f5/src/Core/Sum.ts https://github.com/gbegher/groth/blob/460852a71859f149ecf9b5... Did not cause any roadblocks so far.
- justatdotin 6y ago
  and just as the complexity of HKTs might not add value to your team/project, other type tricks may also detract. These 'goodies' can seem 'insane' (or not) irrespective of which language they're realised in. After a while, I realised that I enjoyed Elm partly because of features it doesn't have ;)
  - lmm 6y ago
    HKTs are a lot less complex than most of Typescript; in a way they're not so much a feature as just the absence of a restriction (type parameters can have parameters just like any other type).
- lifthrasiir 6y ago
  > Stuff [...] all combine to give you a certain amount of dependent types in Typescript but also a very rich way of doing type level computations [...]. I think this is a wrong use of the term "dependent types". For example, you can't write this in TypeScript (yet): function concat<alen: number, blen: number>( a: ArrayOfLength<alen>, b: ArrayOfLength<blen>, ): ArrayOfLength<alen + blen> { return [...a, ...b]; } Sure, you can have a type-level object that corresponds to the numbers and use the type-level expression to compute the equivalent of alen + blen, but they are not dependent types. You have just shifted values to the type level. The type-level expression is awesome---but not because they are dependent types. TypeScript is also not a typical type system you can compare with others. Most famously it is intentionally unsound [1], meaning that it can mostly but not entirely prevent a certain class of runtime errors, because it can't guarantee the behavior of external JS code anyway. Most static type systems are or at least try to be sound because that's what users expect them to be: preventing a wrong code beforehand. Dependent type systems are complex because they also want to be sound. TypeScript has an entirely different goal for a reason and you can't compare it with other type systems not sharing that goal. [1] https://www.typescriptlang.org/docs/handbook/type-compatibility.html#a-note-on-soundness https://www.typescriptlang.org/docs/handbook/type-compatibil...
  - Garlef 6y ago
    Actually, this is mostly possible. Except for some issues regarding the stack size when resolving the types. (But I think there are more efficient implementations using more copy and paste, making this actually work) playground link: https://www.typescriptlang.org/play?#code/C4TwDgpgBAggTnAPAOyhAHsCyAmBnKZAVwFsAjCOAGigBUBeAQ2RBoH024IBjNTbfFGYgA2gF164gHxR6AKCiLCpCnD5ZcBZAqW6A-EJbiduxQC4TUDl24iARABtsAc2AALO2PUCtl-Vc4ePyUzWAQUGloaEQA6OOseGmExKTk00EgrbgB7ZG5GYEQYb01DUTEaACESwWFpWUtickoaghh7J2RXDzFgxQM63tMQxpUWjA1BSo6Xd08+qAGjIeGoC11qiZ8oEQBLZAAzFsqABho4mP2jtQAlFeGDNhy8gsRYuJgqk4qoG9TVtaWGBpOQZaBsRg4HAoVrKZrUKAkWFNVQyeS6AD0GKgAAFgHgALS7ZzIbJcKAEglQACi6G4EDweF2ADdoHhgIxuABrKA4CBgdyWLFQAAUAEkoO59jz3JRoLsCIxEWToBADgddtxdthgFBdiQwE4SDqCrtclAyERdRKDmTnNldbtgDEAJSWJ65fKFeBIZBSGg+xAkKRSGZdOa9dLgaBYdmyLKe14iACMNAATD8U+mUqDo5KGcA0-GPS9ClmoBnoqmKykw915lHMsgTvHAydUmDCMnW+Fkx288gi-Qwkg06lc5kNazi5DoQBmdPjuTPOPPL3xxBRQjIsYIpFbUooyhSEWWRgIZOhQPISL+s8INNX8IkW9UIXYgCyCttcGARGQBQQA4rCSm4CpQAcjC7A4BA4EQMbZFA7KcjyTIAF4QDElguk+SAQlCESIv6dBov8qzCnihLEqSXALO8MTnnA1YXIxGYgiuuroOg8ZrgUIrlpWOwLlAAAsNAAKxiC6QA https://www.typescriptlang.org/play?#code/C4TwDgpgBAggTnAPAO...
- girvo 6y ago
  TypeScripts type level operators are brilliant. They’re somewhat necessary to be able to type semi common JS patterns, but still, they’re brilliant. “Brands” allow you to somewhat hack HKTs into Flow/TS, which is used by fp-ts to great effect.

dwohnitmok 6y ago

Typescript has all sorts of type-level computation goodies that Haskell doesn't have (unless you turn on insane amounts of GHC extensions). Stuff like mapped types, keyOf, typeOf, ReturnType, literal types, conditional types etc. all combine to give you a certain amount of dependent types in Typescript but also a very rich way of doing type level computations (this is how e.g. in Typescript we can have type signatures that capture all sorts of very dynamic Javascript function signatures). On top of this Typescript also has a strong structural type system augmented by union types and intersection types. You can fairly easily emulate a nominal type system like what Haskell has on top of this system, especially with Typescript's string literal types, but it's quite difficult to go the other way. The only big thing I can think of that both Haskell and Scala have that Typescript doesn't is higher-kinded types. I also want to strongly caution that I don't think a more advanced type system is necessarily a better type system! E.g. I'm not convinced that Typescript really needs HKTs. Likewise I have previously programmed quite happily in Elm despite its paucity of type-level features in comparison to Typescript.

forkerenok 6y ago
Thanks for this write-up. What about ADTs and pattern matching? Afaik, they are not available in Typescript and the emulations that I've seen are very sloppy.
- paavohtl 6y ago
  TypeScript supports ADTs (discriminated unions) and not-quite-pattern matching using a combination of features: union types, literal types and control-flow based type narrowing. Here's an example from the TS handbook: https://www.typescriptlang.org/docs/handbook/unions-and-intersections.html#discriminating-unions https://www.typescriptlang.org/docs/handbook/unions-and-inte.... What you need to understand about TypeScript is that it ultimately is just JavaScript. After TS 2.0 a decision was made that TS will align with standard EcmaScript and will not implement any* run-time features not part of the ES standard or ES proposals. Because of this decision TypeScript cannot have a proper dedicated pattern matching syntax until JavaScript gets one. TypeScript does support some pattern matching using ifs and switch statements and other control flow structures, but that's as good as it gets until JS improves as well.
- Garlef 6y ago
  Here's what I use: https://github.com/gbegher/groth/blob/460852a71859f149ecf9b5154af65eb958f869f5/src/Core/Sum.ts https://github.com/gbegher/groth/blob/460852a71859f149ecf9b5... Did not cause any roadblocks so far.
justatdotin 6y ago
and just as the complexity of HKTs might not add value to your team/project, other type tricks may also detract. These 'goodies' can seem 'insane' (or not) irrespective of which language they're realised in. After a while, I realised that I enjoyed Elm partly because of features it doesn't have ;)
- lmm 6y ago
  HKTs are a lot less complex than most of Typescript; in a way they're not so much a feature as just the absence of a restriction (type parameters can have parameters just like any other type).
lifthrasiir 6y ago
> Stuff [...] all combine to give you a certain amount of dependent types in Typescript but also a very rich way of doing type level computations [...]. I think this is a wrong use of the term "dependent types". For example, you can't write this in TypeScript (yet): function concat<alen: number, blen: number>( a: ArrayOfLength<alen>, b: ArrayOfLength<blen>, ): ArrayOfLength<alen + blen> { return [...a, ...b]; } Sure, you can have a type-level object that corresponds to the numbers and use the type-level expression to compute the equivalent of alen + blen, but they are not dependent types. You have just shifted values to the type level. The type-level expression is awesome---but not because they are dependent types. TypeScript is also not a typical type system you can compare with others. Most famously it is intentionally unsound [1], meaning that it can mostly but not entirely prevent a certain class of runtime errors, because it can't guarantee the behavior of external JS code anyway. Most static type systems are or at least try to be sound because that's what users expect them to be: preventing a wrong code beforehand. Dependent type systems are complex because they also want to be sound. TypeScript has an entirely different goal for a reason and you can't compare it with other type systems not sharing that goal. [1] https://www.typescriptlang.org/docs/handbook/type-compatibility.html#a-note-on-soundness https://www.typescriptlang.org/docs/handbook/type-compatibil...
- Garlef 6y ago
  Actually, this is mostly possible. Except for some issues regarding the stack size when resolving the types. (But I think there are more efficient implementations using more copy and paste, making this actually work) playground link: https://www.typescriptlang.org/play?#code/C4TwDgpgBAggTnAPAOyhAHsCyAmBnKZAVwFsAjCOAGigBUBeAQ2RBoH024IBjNTbfFGYgA2gF164gHxR6AKCiLCpCnD5ZcBZAqW6A-EJbiduxQC4TUDl24iARABtsAc2AALO2PUCtl-Vc4ePyUzWAQUGloaEQA6OOseGmExKTk00EgrbgB7ZG5GYEQYb01DUTEaACESwWFpWUtickoaghh7J2RXDzFgxQM63tMQxpUWjA1BSo6Xd08+qAGjIeGoC11qiZ8oEQBLZAAzFsqABho4mP2jtQAlFeGDNhy8gsRYuJgqk4qoG9TVtaWGBpOQZaBsRg4HAoVrKZrUKAkWFNVQyeS6AD0GKgAAFgHgALS7ZzIbJcKAEglQACi6G4EDweF2ADdoHhgIxuABrKA4CBgdyWLFQAAUAEkoO59jz3JRoLsCIxEWToBADgddtxdthgFBdiQwE4SDqCrtclAyERdRKDmTnNldbtgDEAJSWJ65fKFeBIZBSGg+xAkKRSGZdOa9dLgaBYdmyLKe14iACMNAATD8U+mUqDo5KGcA0-GPS9ClmoBnoqmKykw915lHMsgTvHAydUmDCMnW+Fkx288gi-Qwkg06lc5kNazi5DoQBmdPjuTPOPPL3xxBRQjIsYIpFbUooyhSEWWRgIZOhQPISL+s8INNX8IkW9UIXYgCyCttcGARGQBQQA4rCSm4CpQAcjC7A4BA4EQMbZFA7KcjyTIAF4QDElguk+SAQlCESIv6dBov8qzCnihLEqSXALO8MTnnA1YXIxGYgiuuroOg8ZrgUIrlpWOwLlAAAsNAAKxiC6QA https://www.typescriptlang.org/play?#code/C4TwDgpgBAggTnAPAO...
girvo 6y ago
TypeScripts type level operators are brilliant. They’re somewhat necessary to be able to type semi common JS patterns, but still, they’re brilliant. “Brands” allow you to somewhat hack HKTs into Flow/TS, which is used by fp-ts to great effect.