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

Making sense of TypeScript using set theory

blog.thoughtspile.tech

Post reply on HN
Print view View original

31–40 of 94 posts

Re: Making sense of TypeScript using set theory

#31

Post by thoughtspile »

yitr wrote: post #29
RyanCavanaugh wrote: post #23

Earlier quoted context omitted.

Nope. This is a common confusion. The set of properties of objects and the sets of objects themselves have a complementary relationship when it comes to union / intersection and subset / superset. Let's define a "property" as being a predicate that is true for all elements of a set. For example, a collection of red objects has the "red" property. A subset of a set of objects can only have the same or more properties…

maybe a dumb question, but why does wikipedia say typescript is a superset of javascript? https://en.wikipedia.org/wiki/TypeScript

Because all valid JS code is also valid TS code (considering implicit any). Or, put another way, the set of all valid JS programs is a subset of all valid TS programs.

Re: Making sense of TypeScript using set theory

#32

Post by sirmarksalot »

yitr wrote: post #29
RyanCavanaugh wrote: post #23

Earlier quoted context omitted.

Nope. This is a common confusion. The set of properties of objects and the sets of objects themselves have a complementary relationship when it comes to union / intersection and subset / superset. Let's define a "property" as being a predicate that is true for all elements of a set. For example, a collection of red objects has the "red" property. A subset of a set of objects can only have the same or more properties…

maybe a dumb question, but why does wikipedia say typescript is a superset of javascript? https://en.wikipedia.org/wiki/TypeScript

Because Typescript is designed to accept any valid Javascript program, the set of valid statements in a Typescript program is a superset of the set of valid statements in a Javascript program. Typescript contains all the rules of Javascript, and then adds some more, but never in a way that contradicts the requirement that a plain Javascript program should compile, so that also means the language specification itself is a strict superset of Javascript.

Re: Making sense of TypeScript using set theory

#33

Post by clord »

> unknown is the set of all JS values. any is a paradoxical set that includes everything, but might also be empty.

Not really a paradox.

- `unknown` is the intersection (&) of all types, including an internal one that has no shape or characteristics. `unknown | {int: number}` should be `{int: number}`. `unknown & T` is always `unknown`, any characteristic T has will be discarded by the intersection.

- `any` is the union (|) of all types, including that internal one that can be anything, and yes, `unknown` too. `(any & {int: number})` should be `{int: number}`. also, `const x: any = 5 as unknown`. Union with `any` should always produce `any`.

Re: Making sense of TypeScript using set theory

#34

Post by sirmarksalot »

thoughtspile wrote: post #6
maxfurman wrote: post #3

The difference between `any` and `unknown` is that `any` is an escape hatch from the type system. `any` can be used anywhere and will satisfy any type constraint. `any` is how the developer says to the type system "trust me, I know what I'm doing, don't worry about this particular value." Unknown, on the other hand, is for untyped code from an imported JS library, JSON data received from the network that may or may n…

I think "unknown" is more than that! Basically it's a way to say you don't care about the type, as in Record or P extends Promise

This is technically correct, but I suspect it's pretty rare that you would choose "unknown" over a generic parameter. Even if you're writing an algorithm that doesn't care about the data type, it's still probably going to be used by application code that does care, and you'll want to support that need by passing the type through, otherwise the application will be forced to downcast.

Re: Making sense of TypeScript using set theory

#36

Post by thoughtspile »

clord wrote: post #33

> unknown is the set of all JS values. any is a paradoxical set that includes everything, but might also be empty. Not really a paradox. - `unknown` is the intersection (&) of all types, including an internal one that has no shape or characteristics. `unknown | {int: number}` should be `{int: number}`. `unknown & T` is always `unknown`, any characteristic T has will be discarded by the intersection. - `any` is the un…

I'm afraid you're confusing something!

The intersection of all types is never, because, say, number and string don't intersect. The union of all types is unknown.

any doesn't show set-like properties and yields ternary logic in clauses like any extends T, which makes it a paradox.

Re: Making sense of TypeScript using set theory

#38

Post by bazoom42 »

clord wrote: post #33

> unknown is the set of all JS values. any is a paradoxical set that includes everything, but might also be empty. Not really a paradox. - `unknown` is the intersection (&) of all types, including an internal one that has no shape or characteristics. `unknown | {int: number}` should be `{int: number}`. `unknown & T` is always `unknown`, any characteristic T has will be discarded by the intersection. - `any` is the un…

I think you have switched union and intersection. ’Unknown’ is a type which can be anything, so it is the union of all types. ‘Never’ is the empty set of types.

‘Any’ does not really fit into a set theoretical model because it can be assigned to anything and anything can be assigned to it, so it is both a supertype of anything and a subtype of anything. Basically it just disables type checking.

Re: Making sense of TypeScript using set theory

#39

Post by thoughtspile »

sirmarksalot wrote: post #34
thoughtspile wrote: post #6

Earlier quoted context omitted.

I think "unknown" is more than that! Basically it's a way to say you don't care about the type, as in Record or P extends Promise

This is technically correct, but I suspect it's pretty rare that you would choose "unknown" over a generic parameter. Even if you're writing an algorithm that doesn't care about the data type, it's still probably going to be used by application code that does care, and you'll want to support that need by passing the type through, otherwise the application will be forced to downcast.

I often use it to infer one generic parameter:

type Output = Fn extends ((a: unknown) => infer Out) ? Out : never;

Re: Making sense of TypeScript using set theory

#40

Post by scotty79 »

thoughtspile wrote: post #4
scotty79 wrote: post #2

> Why does 0 | 1 extends 0 ? true : false evaluate to false? Because 'extends' really means 'is assignable to'. I feel like most of the questions from the post might be answered fairly easily by using reasoning of 'is assignable to'. Things assignable to A&B are things assignable to both A and B. Things assignable to A|B are things assignable to A or to B. 'never' means a type that nothing is assignable to and is ass…

Fair enough, "is assignable to" is another synonym for "is subset of". I find it much easier to reason about things I can visualize, like sets, which is why I love my set interpretation. Edit: besides, it's quite unintuitve that "never" is assignable to anything. How can never be something?

> it's quite unintuitve that "never" is assignable to anything

Yeah, at first I was mislead by this.

Initially I thought never is opposite of any while, it turns out, it's opposite of unknown. And any is just super weird, dynamic wildcard thing that is as large or as small as needed for any given operation (but not as small as never).

Post reply on HN