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

HypeScript: Simplified TypeScript type system in TypeScript's own type system

github.com

Post reply on HN
Print view View original

51–60 of 84 posts

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#51

Post by Quekid5 »

tcard wrote: post #50
dwohnitmok wrote: post #44

Earlier quoted context omitted.

TypeScript has a very limited form of dependent typing made available through `typeof`, but it does not have dependent typing as e.g. Idris does. However, in general, these sorts of demonstrations do nothing to show that a language can be dependently typed. These sorts of demonstrations show that a type system is Turing complete. However, a type system can be Turing complete without being dependent. For example, type…

Sure, but plenty of type systems are Turing complete. What makes this demo impressive is the (unique?) feature of string literal types and template literal types, which lets you operate on text (like, actual text, with no weird type-level encodings).

Well, certainly string literal types have been around in GHC Haskell for quite a while (7.10.x). They've also been a thing in Scala 2.12.x although the 'implementation' was some sort of weird type checker 'hack'. I believe Scala 3 supports them natively.

I can't speak to the ergonomics of actually implementing anything which uses them internally since I've never really had much use for them outside using the surface-level API of a couple of libraries.

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#52

Post by Sirenos »

p1necone wrote: post #12
theK wrote: post #10

Am I the only one that feels uncomfortable with all that usage of strings in TS’s type system? Why not use pure literals instead of string literals? This is a genuine question, I’m trying to find out what the pros and cons where in the decision making process.

In the context of type definitions, strings aren't really regular bare strings. I.e. if I write type foo = { bar: "Vodka" } I'm guaranteeing that the value of 'bar' on any object of that type must be "Vodka" - the type of bar is not string, it's literally "Vodka" because string values can be types. This seems a little obscure and pointless, but you can put these string types in a union, and enforce that a value must…

That's really interesting.

    doTheThing(readFromUser())
What does the compiler do in cases where you have strings coming in like this?

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#53

Post by thrwawy74 »

efortis wrote: post #14

“I'm not about to start using it for real projects, it's really just a thought experiment about how nice JavaScript could be with an alternative syntax.” - jashkenas 2009 https://news.ycombinator.com/item?id=1014225

I still use coffeescript over javascript because I feel like I can be as expressive as I want. I understand why most left for typescript (type safety), but I feel like everyone just gave up on reducing boilerplate for things in javascript. Switch statements, list comprehensions, array slicing, better equality operators... a lot of things that made coffeescript a great experience have never carried over.

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#54

Post by paavohtl »

Sirenos wrote: post #52
p1necone wrote: post #12

Earlier quoted context omitted.

In the context of type definitions, strings aren't really regular bare strings. I.e. if I write type foo = { bar: "Vodka" } I'm guaranteeing that the value of 'bar' on any object of that type must be "Vodka" - the type of bar is not string, it's literally "Vodka" because string values can be types. This seems a little obscure and pointless, but you can put these string types in a union, and enforce that a value must…

That's really interesting. doTheThing(readFromUser()) What does the compiler do in cases where you have strings coming in like this?

It gives a type error, because strings are not assignable to string literals.

https://www.typescriptlang.org/play?#code/FAEwpgxgNghgTmABAM...

However, if you check or assert that the returned value is one of the accepted literals, compiler accepts it:

https://www.typescriptlang.org/play?#code/FAEwpgxgNghgTmABAM...

This is one of the classic examples of flow-sensitive typing in TS.

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#55

Post by phpnode »

Sirenos wrote: post #52
p1necone wrote: post #12

Earlier quoted context omitted.

In the context of type definitions, strings aren't really regular bare strings. I.e. if I write type foo = { bar: "Vodka" } I'm guaranteeing that the value of 'bar' on any object of that type must be "Vodka" - the type of bar is not string, it's literally "Vodka" because string values can be types. This seems a little obscure and pointless, but you can put these string types in a union, and enforce that a value must…

That's really interesting. doTheThing(readFromUser()) What does the compiler do in cases where you have strings coming in like this?

it'll tell you that `string` cannot be assigned to type `"RED" | "GREEN"`, and so you'll need to write a function that refines the type correctly, e.g.

    function isValidInput(input: unknown): input is "RED" | "GREEN" {
      return input === "RED" || input === "GREEN";
    }

    const input = readFromUser();
    if (isValidInput(input)) {
      doTheThing(input); // no type error
    }

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#56

Post by moron4hire »

Sirenos wrote: post #52
p1necone wrote: post #12

Earlier quoted context omitted.

In the context of type definitions, strings aren't really regular bare strings. I.e. if I write type foo = { bar: "Vodka" } I'm guaranteeing that the value of 'bar' on any object of that type must be "Vodka" - the type of bar is not string, it's literally "Vodka" because string values can be types. This seems a little obscure and pointless, but you can put these string types in a union, and enforce that a value must…

That's really interesting. doTheThing(readFromUser()) What does the compiler do in cases where you have strings coming in like this?

It's an error, as the plain `string` type doesn't satisfy the union. You'll need to perform type assertions to make the return type down before passing it as a parameter.

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#57

Post by faichai »

thrwawy74 wrote: post #53
efortis wrote: post #14

“I'm not about to start using it for real projects, it's really just a thought experiment about how nice JavaScript could be with an alternative syntax.” - jashkenas 2009 https://news.ycombinator.com/item?id=1014225

I still use coffeescript over javascript because I feel like I can be as expressive as I want. I understand why most left for typescript (type safety), but I feel like everyone just gave up on reducing boilerplate for things in javascript. Switch statements, list comprehensions, array slicing, better equality operators... a lot of things that made coffeescript a great experience have never carried over.

I loved it to. I'd love to make a typed coffeescript variant, which transpiles to TypeScript rather than JavaScript. My pet name for this is `tycoscript`.

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#58

Post by giancarlostoro »

thrwawy74 wrote: post #53
efortis wrote: post #14

“I'm not about to start using it for real projects, it's really just a thought experiment about how nice JavaScript could be with an alternative syntax.” - jashkenas 2009 https://news.ycombinator.com/item?id=1014225

I still use coffeescript over javascript because I feel like I can be as expressive as I want. I understand why most left for typescript (type safety), but I feel like everyone just gave up on reducing boilerplate for things in javascript. Switch statements, list comprehensions, array slicing, better equality operators... a lot of things that made coffeescript a great experience have never carried over.

I never tried CoffeeScript since nobody pays me for it, though I am curious about ReasonML as an alternative, there's a Neovim front-end[0] coded in Reason that compiles natively[1], and supports existing VS Code plugins from the VSCodium plugin repository[2] which I still have yet to look at how the heck they pulled that bit off, but it is pretty interesting.

My thinking is, not only can I do amazing front-end stuff on the web, but I can do front-end GUI applications that aren't reliant on Electron thanks to OCaml magic.

[0]: https://github.com/onivim/oni2#introduction

[1]: https://github.com/revery-ui/revery

[2]: https://open-vsx.org/

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#59

Post by phpnode »

orthoxerox wrote: post #42

Can they do Tetris next? https://github.com/mattbierner/Super-Template-Tetris

Tetris is challenging because TS escapes newlines in type output, so you'd end up with a bunch of\nwhich makes it\nhard to read the output. It could probably be done using arrays instead, but that gets truncated so you'd have to have a very small "screen"

Re: HypeScript: Simplified TypeScript type system in TypeScript's own type system

#60

Post by epolanski »

LAC-Tech wrote: post #48
schwartzworld wrote: post #47

Earlier quoted context omitted.

I think OP means that if your project / job doesn't support typescript, you can write .ts files on your local machine and then compile them to .js. I think it would be very challenging though to be the only person on a project using TS though.

Yeah that would be weird. Using tsc to type check javascript - with JSDoc type annotations - works fine. You're really not missing much from "real" typescript, and you can save yourself a transpile.

It doesn't really work fine beyond a single file.

I tried the experiment of .js files driven by typescript in JSDocs for around 10k lines and there is a night and day difference in what you can express, how and reuse it at the type level.

Post reply on HN