4 ms·

Doesn't it trivially have "sum types" since it's just arbitrary self-describing data? i.e. nobody is stopping you from passing around objects in such a way: {a

Doesn't it trivially have "sum types" since it's just arbitrary self-describing data? i.e. nobody is stopping you from passing around objects in such a way: {a:1} {a:{b:2}} {a:4} {a:{b:4}} There's no static type layer over top of this, so it's inherently up to interpretation and whatever type system you want to use to describe this data, to be able to express that the values of `a` can be of type `number | {b: number}`

valenterry 5y ago
> There's no static type layer over top of this Yeah, that's the problem. I mean, hey, why json? We could just use unstructured plaintext for everything and now we are free to do everything. But obviously that has its own drawbacks. Having built-in support for sumtypes means better and more ergonomic support from libraries, it means there is one standard and not different ways to encode things and it also means better performance and tooling.
- joshlemer 5y ago
  The point is that there's no reason to single out sumtypes here. Insofar as ions/json has support for arrays/objects/strings/numbers, it has exactly the same support for sumtypes, as in the example I showed above. Here is a list of "sumtype" `string | number | object`: [{}, "hi", 1, 2, 3, "yo", {a: "bc"}]
  - valenterry 5y ago
    No, that is not a sumtype, that's an array. In the same sense "1e-12" is not a number, it's a string. Yes, it's a string that encodes a number in a certain notion, but for alle the tooling, the IDE, the libraries, etc. it will stay a string.
    - joshlemer 5y ago
      What I mean is, it is an array of a sumtype `number | string | object`. So precisely, you could call it a `list<number | string | object>`
      - dunefox 5y ago
        That's a list union[number, string, object] or list[Any], not a sum type, no? This `data X = A | B [A, B, ...]` Is a list containing a sum type: list[X]
        joshlemer 5y ago
        There is no such thing in JSON or Ions as defining this "X" schema somewhere. So I may as well say that your [A,B,...] is a list[Any]. Now, I wouldn't actually call it a list of any, I would say you proved my point for me. Your example is functionally the same as mine. I would give this example: `[A, B, ...]` and say that that is a list of sum types. You may say "no no no! Only now is it a list of sum types!": `data X = A | B [A, B, ...]` But my point is that there is no JSON/Ion equivalent of your `data X = A | B`. Everyone in this comment tree is confusing the data itself with out-of-band schema over that data. "Sumtype" is nothing more than a fiction, or a schema. Saying that JSON/Ions don't support sumtypes is like saying JSON doesn't support "NonNegativeInteger" type. Sure it does! Here are some: 1, 2, 3, 10. What tooling or type system you use outside of the data itself to enforce constraints on the data types is orthogonal to the data format itself.
        valenterry 5y ago
        > But my point is that there is no JSON/Ion equivalent of your `data X = A | B No one disagrees - it's just that we complain about this. We _want_ to have such an equivalent. > Saying that JSON/Ions don't support sumtypes is like saying JSON doesn't support "NonNegativeInteger" type. Correct. But your conclusion is wrong. You seem to assume that no one has a problem with the fact that JSON doesn't support a "NonNegativeInteger" type. But I at least would happily use a format that explicitly supports that. I mean, look at ION. Json doesn't support the concept of (restricted) integers, but ION extends JSON and offers this type. That's great, because it means if a library reads an integer field, it can map it to an integer and knows that there are constraints. This is a _very_ relevant issue. Many json libraries in the past have had bugs or could be ddos-ed by feeding them json with large numbers, since the json spec does not constrain the size of numbers. In that sense, ION could have _also_ added support for "NonNegativeInteger" or sumtypes, or other specific types, but they haven't. And since sumtypes are very fundamental, we complain about it more than we would complain about the lack of "NonNegativeInteger".
  - quantumspandex 5y ago
    His point was type support and standard way of doing things. Using your argument we just need string type to represent everything.

valenterry 5y ago

> There's no static type layer over top of this Yeah, that's the problem. I mean, hey, why json? We could just use unstructured plaintext for everything and now we are free to do everything. But obviously that has its own drawbacks. Having built-in support for sumtypes means better and more ergonomic support from libraries, it means there is one standard and not different ways to encode things and it also means better performance and tooling.

joshlemer 5y ago
The point is that there's no reason to single out sumtypes here. Insofar as ions/json has support for arrays/objects/strings/numbers, it has exactly the same support for sumtypes, as in the example I showed above. Here is a list of "sumtype" `string | number | object`: [{}, "hi", 1, 2, 3, "yo", {a: "bc"}]
- valenterry 5y ago
  No, that is not a sumtype, that's an array. In the same sense "1e-12" is not a number, it's a string. Yes, it's a string that encodes a number in a certain notion, but for alle the tooling, the IDE, the libraries, etc. it will stay a string.
  - joshlemer 5y ago
    What I mean is, it is an array of a sumtype `number | string | object`. So precisely, you could call it a `list<number | string | object>`
    - dunefox 5y ago
      That's a list union[number, string, object] or list[Any], not a sum type, no? This `data X = A | B [A, B, ...]` Is a list containing a sum type: list[X]
      - joshlemer 5y ago
        There is no such thing in JSON or Ions as defining this "X" schema somewhere. So I may as well say that your [A,B,...] is a list[Any]. Now, I wouldn't actually call it a list of any, I would say you proved my point for me. Your example is functionally the same as mine. I would give this example: `[A, B, ...]` and say that that is a list of sum types. You may say "no no no! Only now is it a list of sum types!": `data X = A | B [A, B, ...]` But my point is that there is no JSON/Ion equivalent of your `data X = A | B`. Everyone in this comment tree is confusing the data itself with out-of-band schema over that data. "Sumtype" is nothing more than a fiction, or a schema. Saying that JSON/Ions don't support sumtypes is like saying JSON doesn't support "NonNegativeInteger" type. Sure it does! Here are some: 1, 2, 3, 10. What tooling or type system you use outside of the data itself to enforce constraints on the data types is orthogonal to the data format itself.
        valenterry 5y ago
        > But my point is that there is no JSON/Ion equivalent of your `data X = A | B No one disagrees - it's just that we complain about this. We _want_ to have such an equivalent. > Saying that JSON/Ions don't support sumtypes is like saying JSON doesn't support "NonNegativeInteger" type. Correct. But your conclusion is wrong. You seem to assume that no one has a problem with the fact that JSON doesn't support a "NonNegativeInteger" type. But I at least would happily use a format that explicitly supports that. I mean, look at ION. Json doesn't support the concept of (restricted) integers, but ION extends JSON and offers this type. That's great, because it means if a library reads an integer field, it can map it to an integer and knows that there are constraints. This is a _very_ relevant issue. Many json libraries in the past have had bugs or could be ddos-ed by feeding them json with large numbers, since the json spec does not constrain the size of numbers. In that sense, ION could have _also_ added support for "NonNegativeInteger" or sumtypes, or other specific types, but they haven't. And since sumtypes are very fundamental, we complain about it more than we would complain about the lack of "NonNegativeInteger".
- quantumspandex 5y ago
  His point was type support and standard way of doing things. Using your argument we just need string type to represent everything.