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

[efortis]

“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

[petethepig]

"Hello everybody out there using minix -

I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things)."

https://www.cs.cmu.edu/~awb/linux.history.html

[thrwawy74]

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.

[thenberlin]

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.

[jraph]

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

[IshKebab]

Is that not referring to Coffeescript? I don't see the relevance.

[pfraze]

This is epic. There’s a parser in there.

Edit: this is explained a bit here [1]. It uses Template Literal Types[2].

1 https://blog.joshuakgoldberg.com/type-system-game-engines/

2 https://www.typescriptlang.org/docs/handbook/2/template-lite...

[staticassertion]

I'm impressed by how readable the live demo is.

I have to say, the fact that you can do something so... obscene, but in a way that's actually surprisingly readable, speaks highly of Typescript's type system and design.

[quickthrower2]

Please tell me this means you can do dependent types! I have no idea how this works, seems like magic and seems like anything is possible.

Maybe "dependent-but-stringly typed" is possible?

[dwohnitmok]

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-level integers might be completely different from run-time integers with no way to things from the latter to the former.

[noduerme]

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

[dfee]

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

[theK]

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.

[p1necone]

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 be one of many values.

  function doTheThing(color: "RED" | "GREEN") {
      //do stuff
  }

  doTheThing("RED"); //ok
  doTheThing("GREEN"); //ok
  doTheThing("ORANGE"); //doesn't compile, because the type of the param *isn't* string, it's "RED" | "GREEN"

You can also define a type like

  type Mountain = { name: "EVEREST", height: 8848 } | { name: "K2", height: 8611 };

and then at compile time know that if mountain.name === "EVEREST" then height === 8848 because the types of name and height aren't string and number, they're "EVEREST" | "K2" and 8848 | 8611, and the compiler is smart enough to work out one based on the other.

==============================================

For extra context - a lot of this is for interoptability with Javascript code - you want to call some Javascript function with a stringly typed enum, and enforce only passing in valid values, but the Javascript code still just deals with strings.

A lot of Typescripts kind of insane flexibility is so you can introduce type safety to all sorts of dynamic Javascript code, without having to make sacrifices on the dynamic-ness of it.

Turns out this flexibility is actually kinda awesome to have in general even when you're not trying to refactor an existing JS codebase.

[girvo]

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

    type Event = 'onClick' | 'onHover'

    // some stringly typed javascript can now be nicely typed
    something.triggerEvent('onClick', someData)

It lets you do some really nice things, and is quite strongly typed despite how it looks at first glace, while still letting me write some strongly-typed definitions for existing Javascript code that was very much __not__ written with types in mind.

[staticassertion]

I think it's kind of cool. It reminds me a bit of C++ templates, which are "compile time duck typed". The benefit is that you get lose typing constructs that are evaluated strictly and at type check time, which is kinda nutty. It means that you can lean really heavily on the compiler.

Sort of like using Python to generate Typescript, as random example - my Python code doesn't have to typecheck, but its output does, so I can do absurd shit in Python and still feel good about the output.

One example is something like this: https://www.typescriptlang.org/docs/handbook/2/template-lite...

These are types that are built from string templates. Since strings are loose and can be manipulated in crazy ways like appending, we can now manipulate types in the same way. We can write types that are themselves parsers.

So idk if that's good or not, the downside in C++ is that TMP errors are fucking insane, but the upside is that I can have a function that says "pass me something and I'll call "iter" on it and I don't care what that thing is".

It also feelsy kinda more "typey". Types are just values. Types are just strings or numbers or whatever. They're things, with the constraint being that they must exist concretely (or be inferrable) when the type checker runs. No distinction between types and values seems like it's the ideal.

[uninformed]

Yo dawg, I heard you like Typescript ... you know the rest.

[culi]

  interface TypeScript {
    typeScript: TypeScript;
  }

[throwaway17_17]

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.

[rrishi]

Which article were you referring to?

The link in the post goes to a GitHub repo.

[adamddev1]

This guy's like, "I see your Lisp in Lisp and raise you..."

[finiteparadox]

Incredible, one would expect this to be theoretically possible since Typescript's type system is Turing complete, but it is certainly different to see it done in practice. Wow!

[orthoxerox]

Can they do Tetris next?

https://github.com/mattbierner/Super-Template-Tetris

[phpnode]

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"

[culi]

For people used to working in TypeScript who suddenly find themselves having to work on a vanilla js app... and don't wanna use JSDoc?

[sakarisson]

I'd convince the team to switch to typed or get out of the project

[difu_disciple]

Do everything you can to introduce TS incrementally. JSDoc simply isn’t enough.

[jschrf]

Use TS locally

[revskill]

Can we read the source file from filesystem, then pass into type checker like this ?

[chii]

that sounds increasingly like a build-time macro system...

[evolveyourmind]

This is mindblowing

[andrewstuart]

I love TypeScript but its complexity is getting ridiculous.

[shepherdjerred]

What complexity do you feel is unneeded?

[tofuahdude]

> Please note that this project is meant to be used for fun and learning purposes and not for practical use.

[wikitopian]

Oh thank God. There aren't nearly enough ways to write javascript.

[munchler]

There's no Javascript (or any other runtime) code in this at all. It all happens at compile-time.