5 ms·

A first look at records and tuples in JavaScript

28 points by flipchart 6y ago

pull_my_finger 6y ago
I've always thought it was interesting to see the parallels of PHPs growth and JSs. Both seem to add a lot of popular (at the time) features. Neither can purge old APIs or "break the web".
- ferzul 6y ago
  php purges shitty ideas quite frequently. for instance, i just upgraded some class Foo extends Bar { public Foo() { this->Bar(); } } business since it's going away soon. likewise, magic quotes.
specialist 6y ago
Why do records, tuples need new syntax?
- fnordsensei 6y ago
  Because if they went and made immutability the default, they’d break a lot of existing code that depends on it behaving in a mutable manner.
  - specialist 6y ago
    Duh. Thanks. Being tainted by tuples and records from other languages, the immutable bits didn't register. Sorry. Reading the proposal (TC39) explains all. https://github.com/tc39/proposal-record-tuple https://github.com/tc39/proposal-record-tuple Paraphrasing, if I understand TC39 correctly, an immutable map is a record and an immutable array is a tuple. Has a certain elegance. Nicely done. While I'm inclined to like TC39, I'll chew on it to be sure.
    - fnordsensei 6y ago
      Yeah seems so. It’s a shame that they can only be shallowly cast from mutable to immutable (and will even throw errors if non-primitive values are present). Seems like quite the limitation. And yeah, I’m all for immutability as a default, but breaking so pervasive an existing API is a lot of damage.
combatentropy 6y ago
Is the hash symbol the best? It already is used within classes to mean private. Syntactically for the machine parser, I assume it will work just fine for these other things. But semantically for my human brain, it is mildly incongruous. If for no reason but elegance and developer delight, I ask for a reconsideration of other punctuation.
- WorldMaker 6y ago
  Seems like a lot of options were/are debated: https://github.com/tc39/proposal-record-tuple/issues/10 https://github.com/tc39/proposal-record-tuple/issues/10 The benefit to #{}/#[] is that # is not an existing identifier character (other than private fields) in JS, and also isn't an existing binary operator. Proposals to TC39 are constrained that they must as much as possible not "break" existing JS parsing of existing code. That removes a lot of possible characters because they already have valid parses. It also makes it tough to introduce new keywords beyond those ES3/ES5 set in stone as reserved, because they might be identifier names in user applications.
- hinkley 6y ago
  and it means a javascript CLI file if it's in the first byte of the file... I'm wondering if {{}} is syntactically unambiguous. It's closer to the correct symbols at least. Or maybe there's a parallel to symbols (Ruby, Elixir, ?), and you could leverage a leading colon: let myRecord = :{ foo: "bar" }; but a little tricky with ternaries.
deleted 6y ago
[deleted]
olliej 6y ago
So from reading this it sounds like what's being asked for essentially syntactic sugar for Object.freeze(), and the function Record(obj) would be doing something along the lines of function Record(obj) let result = {}; for (let [key, value] of obj) { switch (typeof value) { case "function": case "object": throw ...; } result[key] = obj; } Object.freeze(result); return result; } Or similar. Now obviously have typeof return a new type is exciting, and of questionable value, but having a "only immutable values can be in fields" guarantee could be useful. That said, overloading # is not something I think is great, and the semantics need to be tightened up (fields in prototype chain, etc, what is the prototype of the resulting record/tuple object).
- amw-zero 6y ago
  You only looked at the conversion of an Object to a Record. That’s really not the point of this. The point of introducing true records and tuples is to bring value semantics to JS for compound data types. It seems like if you create two records with the same nested data, they will be equal when compared. This may sound small, but if you try out a language with real value semantics it changes the way you code.
amw-zero 6y ago
This is the number one feature I look for in a language now. It’s hard to describe why value semantics are useful when thinking about a language as it exists today, since the language influences what we think is possible. But having records and tuples like this changes the way you write code. The biggest example is, you don’t have to think in terms of references anymore. Again it’s hard to explain how much were forced to think about references and specific locations that data happens to live at, but that thinking is pervasive in how we write code (if you’re using a language like JS, which most popular languages are like). Value semantics means you can stop thinking about data-as-a-location or data-as-a-reference and finally start thinking about data-as-data. If two records have the same values, they are the same. This means you don’t need to know anything about where data came from, you can construct matching data and say “are these things equal?” And they will be. This inherently reduces coupling and complexity.
ryansobol 6y ago
The Value of Values with Rich Hickey https://youtu.be/-6BsiVyC1kM https://youtu.be/-6BsiVyC1kM

28 points by flipchart 6y ago

I've always thought it was interesting to see the parallels of PHPs growth and JSs. Both seem to add a lot of popular (at the time) features. Neither can purge old APIs or "break the web".

ferzul 6y ago
php purges shitty ideas quite frequently. for instance, i just upgraded some class Foo extends Bar { public Foo() { this->Bar(); } } business since it's going away soon. likewise, magic quotes.

specialist 6y ago

Why do records, tuples need new syntax?

fnordsensei 6y ago
Because if they went and made immutability the default, they’d break a lot of existing code that depends on it behaving in a mutable manner.
- specialist 6y ago
  Duh. Thanks. Being tainted by tuples and records from other languages, the immutable bits didn't register. Sorry. Reading the proposal (TC39) explains all. https://github.com/tc39/proposal-record-tuple https://github.com/tc39/proposal-record-tuple Paraphrasing, if I understand TC39 correctly, an immutable map is a record and an immutable array is a tuple. Has a certain elegance. Nicely done. While I'm inclined to like TC39, I'll chew on it to be sure.
  - fnordsensei 6y ago
    Yeah seems so. It’s a shame that they can only be shallowly cast from mutable to immutable (and will even throw errors if non-primitive values are present). Seems like quite the limitation. And yeah, I’m all for immutability as a default, but breaking so pervasive an existing API is a lot of damage.

combatentropy 6y ago

Is the hash symbol the best? It already is used within classes to mean private. Syntactically for the machine parser, I assume it will work just fine for these other things. But semantically for my human brain, it is mildly incongruous. If for no reason but elegance and developer delight, I ask for a reconsideration of other punctuation.

WorldMaker 6y ago
Seems like a lot of options were/are debated: https://github.com/tc39/proposal-record-tuple/issues/10 https://github.com/tc39/proposal-record-tuple/issues/10 The benefit to #{}/#[] is that # is not an existing identifier character (other than private fields) in JS, and also isn't an existing binary operator. Proposals to TC39 are constrained that they must as much as possible not "break" existing JS parsing of existing code. That removes a lot of possible characters because they already have valid parses. It also makes it tough to introduce new keywords beyond those ES3/ES5 set in stone as reserved, because they might be identifier names in user applications.
hinkley 6y ago
and it means a javascript CLI file if it's in the first byte of the file... I'm wondering if {{}} is syntactically unambiguous. It's closer to the correct symbols at least. Or maybe there's a parallel to symbols (Ruby, Elixir, ?), and you could leverage a leading colon: let myRecord = :{ foo: "bar" }; but a little tricky with ternaries.

deleted 6y ago

[deleted]

olliej 6y ago

So from reading this it sounds like what's being asked for essentially syntactic sugar for Object.freeze(), and the function Record(obj) would be doing something along the lines of function Record(obj) let result = {}; for (let [key, value] of obj) { switch (typeof value) { case "function": case "object": throw ...; } result[key] = obj; } Object.freeze(result); return result; } Or similar. Now obviously have typeof return a new type is exciting, and of questionable value, but having a "only immutable values can be in fields" guarantee could be useful. That said, overloading # is not something I think is great, and the semantics need to be tightened up (fields in prototype chain, etc, what is the prototype of the resulting record/tuple object).

amw-zero 6y ago
You only looked at the conversion of an Object to a Record. That’s really not the point of this. The point of introducing true records and tuples is to bring value semantics to JS for compound data types. It seems like if you create two records with the same nested data, they will be equal when compared. This may sound small, but if you try out a language with real value semantics it changes the way you code.

amw-zero 6y ago

This is the number one feature I look for in a language now. It’s hard to describe why value semantics are useful when thinking about a language as it exists today, since the language influences what we think is possible. But having records and tuples like this changes the way you write code. The biggest example is, you don’t have to think in terms of references anymore. Again it’s hard to explain how much were forced to think about references and specific locations that data happens to live at, but that thinking is pervasive in how we write code (if you’re using a language like JS, which most popular languages are like). Value semantics means you can stop thinking about data-as-a-location or data-as-a-reference and finally start thinking about data-as-data. If two records have the same values, they are the same. This means you don’t need to know anything about where data came from, you can construct matching data and say “are these things equal?” And they will be. This inherently reduces coupling and complexity.

ryansobol 6y ago

The Value of Values with Rich Hickey https://youtu.be/-6BsiVyC1kM https://youtu.be/-6BsiVyC1kM