Live data from Hacker News

Making sense of TypeScript using set theory

blog.thoughtspile.tech

61–70 of 94 posts

Re: Making sense of TypeScript using set theory

#61

Unrelated set theory thing: They say Typescript is a "superset" of Javascript, but plenty of valid JS code won't work in TS. For example, `let foo = 4; foo = "4";`

That isn't what "TS is a superset of JavaScript" means. That phrase means "TS syntax is a superset of JavaScript syntax". Your example is syntactically valid in TS -- it just fails a type checking

Re: Making sense of TypeScript using set theory

#62
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?

> Fair enough, "is assignable to" is another synonym for "is subset of".

Only if you're happy to conflate members and sets, which is pretty confusing IMO. If I write a = b I don't generally think of b as being a set, even though in some sense it is; "b is an expression with this type" is a much more natural way of thinking to me.

Re: Making sense of TypeScript using set theory

#63

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…

In your example with marbles, the superset has the property of every element being comprised of a set of colors, let's say {black, red, blue}. The subset is {red}. Can't every possible property we can conceive of a subset be constructed in a similar fashion such that the superset contains at least the same number of elements and never less?

> Can't every possible property we can conceive of a subset be constructed in a similar fashion such that the superset contains at least the same number of elements and never less?

What do you mean? A superset always contains at least the same number of elements as a subset, by definition. A superset generally has fewer or at least weaker properties; "colour is one of A, B or C" is a weaker property than "colour is A", and there's no real difference between that and saying the superset doesn't have the property at all (I could say "my subset consists of shiny marbles; my subset has the property that they're shiny and my superset does not have that property", or I could say "my subset has the property that shininess is true, and my superset has the property that shininess is true or false", and there isn't really any difference once you get down to the set-theoretic level - a property is just a boolean-valued function). The only superset that has exactly the same properties as the set itself is the set itself (since "is a member of the subset" is a valid property).

Re: Making sense of TypeScript using set theory

#64

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…

In your example with marbles, the superset has the property of every element being comprised of a set of colors, let's say {black, red, blue}. The subset is {red}. Can't every possible property we can conceive of a subset be constructed in a similar fashion such that the superset contains at least the same number of elements and never less?

The way "subset of properties" is being used here is loose and that's where the confusion is arising from. If we want to be a bit more rigorous:

* Define O as a set of possible (finite) objects

* Define properties as functions P: O -> {0, 1}

* A given property then is a function of the form p(o) = 1 for all o in O that satisfy the property p.

You can use property functions to generate subsets of O ({ o for o in O where p(o) = 1 }). The intersection of these generated subsets of multiple property functions will be strict subsets (strictly "smaller" as O is finite) of O as long as at least one property function is not of the form P(o) = 1 for * in O. Generally assuming that each property function generates strict subsets, applying more properties derives a smaller intersection set. That's all.

Re: Making sense of TypeScript using set theory

#65
post #63

Earlier quoted context omitted.

In your example with marbles, the superset has the property of every element being comprised of a set of colors, let's say {black, red, blue}. The subset is {red}. Can't every possible property we can conceive of a subset be constructed in a similar fashion such that the superset contains at least the same number of elements and never less?

> Can't every possible property we can conceive of a subset be constructed in a similar fashion such that the superset contains at least the same number of elements and never less? What do you mean? A superset always contains at least the same number of elements as a subset, by definition. A superset generally has fewer or at least weaker properties; "colour is one of A, B or C" is a weaker property than "colour is A…

Ok, how about I define a new property that my superset contains a 'rainbow' of colors. The subset has only one of the colors, it doesn't contain the rainbow property. The original post claimed that the superset always has the same or fewer properties. I was questioning whether this was true.

You've mentioned that it is generally true, which seems like a better way to describe the concept.

-- edit: I understand now, in my example above the subset must contain a property by which it could be identified. The original rainbow property is lost but a new one is gained.

Re: Making sense of TypeScript using set theory

#66

Earlier quoted context omitted.

In your example with marbles, the superset has the property of every element being comprised of a set of colors, let's say {black, red, blue}. The subset is {red}. Can't every possible property we can conceive of a subset be constructed in a similar fashion such that the superset contains at least the same number of elements and never less?

The way "subset of properties" is being used here is loose and that's where the confusion is arising from. If we want to be a bit more rigorous: * Define O as a set of possible (finite) objects * Define properties as functions P: O -> {0, 1} * A given property then is a function of the form p(o) = 1 for all o in O that satisfy the property p. You can use property functions to generate subsets of O ({ o for o in O whe…

Thanks for that, it makes sense using your definition. I'm curious as to whether you agree with the parent comment that the subset could contain 'more' properties than the superset.

My understanding from your stricter definition is that (by definition) all potential properties (o for o in O where p(o) = 1) must be contained within O.

If the answer is that the superset O has fewer properties where every p(o) = 1 then I agree, and I was overthinking it

Re: Making sense of TypeScript using set theory

#67
post #50

Earlier quoted context omitted.

> superset of objects can only have the same or fewer properties This is potentially misleading. A superset will include more objects and therefore may include more individual properties. But type checking is about what can be safely assumed about all members of a set, so more different objects in the set will constrain the type more. Object is a superset of Date because the set of objects includes alle Dates but als…

> object is more constrained because there are fewer properties which all members of the set are guaranteed to have. In my mind it's the opposite: object is less constrained, because there are fewer requirements you need to fulfill to be considered an object. Object type is very permissive. The more constrained type is, the fewer objects it's set will contain. The more constrained the type is, the more rules it enfor…

[deleted]

Re: Making sense of TypeScript using set theory

#68
post #63

Earlier quoted context omitted.

> Can't every possible property we can conceive of a subset be constructed in a similar fashion such that the superset contains at least the same number of elements and never less? What do you mean? A superset always contains at least the same number of elements as a subset, by definition. A superset generally has fewer or at least weaker properties; "colour is one of A, B or C" is a weaker property than "colour is A…

Ok, how about I define a new property that my superset contains a 'rainbow' of colors. The subset has only one of the colors, it doesn't contain the rainbow property. The original post claimed that the superset always has the same or fewer properties. I was questioning whether this was true. You've mentioned that it is generally true, which seems like a better way to describe the concept. -- edit: I understand now, i…

> Ok, how about I define a new property that my superset contains a 'rainbow' of colors. The subset has only one of the colors, it doesn't contain the rainbow property.

You're mixing levels. The property is something satisfied by members of the set, not by the set as a whole.

Re: Making sense of TypeScript using set theory

#69

I might be missing something, but isn't this line backwards? > Subtype of type A is a subset of type A. Supertype is a superset. Easy. Subtype of type A is actually a superset of type A, since it contains at least all the properties of A. If you had (contrived example) a Dog class that inherited from an Animal class, Dog would be a sub type of Animal, but its additional properties (say, a bark() method) mean that it…

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…

I think that interfaces in TypeScript unfortunately contribute to that confusion. I can do

  interface Point2D {
    x: number
    y: number
  }
And then I can do

  interface Point3D extends Point2D {
    z: number
  }
And that "extends" really throws off many people because in reality the type of Point2D is implicitly

  {
    x: number
    y: number
    [anything_else in string]: unknown
  }
So Point3D actually narrows the type of Point2D even though the notation suggests that it widens it. Fortunately, the type notation is less misleading because I can do

  type Point3D = Point2D & {
    z: number
  }
Without any misleading "extensions".

It seems like it all stems from the tight coupling between types and classes in a typical OOP paradigm. When you create a class Animal you create a type Animal that should conform to specific rules, but when you instantiate that class you create an object that conforms to a narrower set of rules. E.g. an object instantiated from class Animal won't be able to woof() even though the type "Animal" easily allows it. This leads to the mental model of "extending" base class with new fields and methods. And even though it indeed extends the class Animal, it narrows the type Animal.

Re: Making sense of TypeScript using set theory

#70
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…

Yeah, `extends` seems like a misnomer that confuses people.
Post reply on HN