Show HN: Conway's Game of Life in TypeScript's type system
41–48 of 48 posts
Re: Show HN: Conway's Game of Life in TypeScript's type system
#42Sometimes I think I don't understand TypeScript's type system and then I see something like this and I realize I know even less than I thought
Conditional types are probably rarely used in practial code, but it opens the door for a lot of geekery.
Re: Show HN: Conway's Game of Life in TypeScript's type system
#43Re: Show HN: Conway's Game of Life in TypeScript's type system
#44Sometimes I think I don't understand TypeScript's type system and then I see something like this and I realize I know even less than I thought
Typescript has conditional types, which means it can be used as a programming language itself. In theory you can write any arbitrary program - game of life is just an example. You have to define numbers and arithmetics from scratch though, so it is not very practical. Conditional types are probably rarely used in practial code, but it opens the door for a lot of geekery.
Re: Show HN: Conway's Game of Life in TypeScript's type system
#45Love it! Reminds me of the hilarious "Typing the technical interview" [1] and "Typescripting the technical interview" [2], a couple of my favorite blog posts of all time. [0] https://aphyr.com/posts/342-typing-the-technical-interview [1] https://www.richard-towers.com/2023/03/11/typescripting-the-...
https://aphyr.com/posts/353-rewriting-the-technical-intervie...
Re: Show HN: Conway's Game of Life in TypeScript's type system
#46Earlier quoted context omitted.
this is exactly what I want from the Types as Comments proposal[0] as I think it's the only way that types can feasibly become part of the language. It's hard to imagine how all of the concepts TS introduces via special syntax can be covered otherwise. [0] https://tc39.es/proposal-type-annotations
I mean this seems like a nice proposal, but I guess I’m missing something, how does it relate to my comment?
What I'm saying is that if instead we said that all type annotations must follow existing JS grammar rules, with perhaps a couple of small additions, then we'd be able to support all sorts of complex type annotations in JS directly, using existing syntax. This would mean that TS's grammar would end up changing a bit, but that's a small price to pay for ongoing interoperability.
For example, instead of
type UserProperties = keyof typeof User;
which is tied to TS's arbitrary syntax, and not supported in Flow, use type UserProperties = keyOf(typeOf(User));Re: Show HN: Conway's Game of Life in TypeScript's type system
#47At this point, TypeScript should just let us define types using plain imperative TS code that will execute during static analysis. Might as well. type MyType = someFunc(T) Of course these functions might be typed too…
I recently had the insight- surely induced by reading something on HN or listening to some podcast- that types are simply functions from the set of all possible "values" to a logical value...
Re: Show HN: Conway's Game of Life in TypeScript's type system
#48Earlier quoted context omitted.
commenting for future reference. that's a great quote.
Thanks. The Shen language takes this to its logical conclusion (pun intended) and implements a fully Turing complete type system. Types are specified with sequents which are essentially Prolog relations using a slightly different notation.[1] 1: https://shenlanguage.org/OSM/Recursive.html
IIRC the type checker is literally a Prolog.