Live data from Hacker News

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

github.com

31–40 of 84 posts

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

#31

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…

To add to this, the reason it’s important for TypeScript to support string literals as values instead of using enums or something new is interop with existing JS. For example, think of an event handler where you pass the event name as the first argument; you can ensure at compile-time that an invalid event name isn’t passed.

Or more importantly, varying the event type based on the event name.

e.g. addEventListener("click", (MouseEvent): void) versus addEventListener("input", (InputEvent): void)

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

#32
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

Man, I know this wasn't really the intention of the comment, but I just read through that thread and got a little nostalgic. Crazy that was like 13 years ago. Sheesh.

I also wonder how much of his 'tiny language' filtered through in ES6.

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

#33

This is insanely cool voodoo. But... I may be lacking in imagination here... I'm trying to think of how I'd actually use it. Maybe it'll come to me in the middle of the night 8) I do really wish TS had actual inbuilt reflective type checking along the lines of this: https://github.com/Hookyns/tst-reflect ...I can hazily see some kind of monstrosity that could come from linking these things together hah

This linked project is very cool! I wonder if this path is expressly a non-goal of the TypeScript team though…?

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

#35
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

Ah ah, another instance of "just a hobby, won't be big and professional like gnu".

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

#36

Earlier quoted context omitted.

But you probably are going to be running this as JS eventually

If you transpile it to js, you'll get empty file.

The real lesson isn't the output of our build system, it's the types we checked along the way.

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

#37

This article is intriguing, I liked the playful tone, particularly in light of the subject. I’m hoping the talk gets streamed to YouTube. This also makes me interested in the formalization attempts I have heard are ongoing for TS’s type system. Anyone with good paper/videos on that development feel free to drop a link.

Which article were you referring to?

The link in the post goes to a GitHub repo.

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

#39
post #28
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.

As others have pointed out, they're not really "strings" per se, or at least can be a lot stricter than a string might seem when used right. We use that constantly for useful things. The bigger reason why it is this way is to ensure you can write type annotations for stringly-typed Javascript. While Typescript is it's own thing really at this point, it still is very focused on making it possible to type-annotate JS c…

In a similar case TypeScript even knows the signature of the event handler for addEventListener, and what type of Element document.createElement('div') returns. Someone even built typings for querySelector that parse the selector and returns the correct element type.

In general, however, I still think APIs written in TypeScript first are a lot cleaner type-wise than typings retrofitted onto a JS API. And having TypeScript as an afterthought these days doesn't seem like a good path to go anymore.

Post reply on HN