Tuple / Pair / Triple structures

[astorije]

Disclaimer: I am using JavaScript only, so I don't know the potential specifics of TypeScript for this topic

Scala defines Tuple structures, from Tuple1 to... Tuple22!

Along the way, Tuple2 and Tuple3 are pretty nice, they come with extra methods (like swap for Tuple2. These two are so common that they respectively are aliased to Pair and Triple (were actually, since they got deprecated in favor of a syntax we unfortunately cannot use here).

Right now, if I want to make a pair, I can either use an Array (and therefore be mutable) or a List (and therefore abuse the types):

var a = ['foo', 42];
var l = List.of('foo', 42);

Isn't the second one a violation of the types?

I think it'd be nicer to have specific data structures like:

var p = new Pair('foo', 42);
var t = new Tuple2('foo', 42);

Among other things, a nice consequence of this, for those who are using JavaScript and JSDoc is that the former version has to be documented with {List.<*>}, while the latter one can be documented with {Pair.<string, number>}, which is much more precise and useful documentation!

Am I completely missing the point here?

[samwgoldman]

Both TypeScript and Flow have support for tuple types, which are based on array values, but the type checker verifies the number and type of elements.

Overall, I agree that tuple structures are handy. Materialized (new Tuple(a, b)) and functional (type Tuple<A,B,C> = (a: A, b: B) => C) representations are useful. The later is already useful in zipWith.

What kind of code are you writing that you want a tuple structure?

[astorije]

Both TypeScript and Flow have support for tuple types, which are based on array values, but the type checker verifies the number and type of elements.

Well, I didn't know that, and it makes sense. Points to them then. I see why it's not implemented in this library because of that, but any chance to consider it for those using the library in plain JavaScript?

Materialized (new Tuple(a, b)) and functional (type Tuple<A,B,C> = (a: A, b: B) => C) representations are useful.

I was merely talking about the former one. Can the latter one still be considered a tuple, if it's essentially a function?

What kind of code are you writing that you want a tuple structure?

I opened this issue after faking a tuple structure here and there, but this code is going to evolve soon to actually use a List for what it's purposed.

However, I am using an Array-based tuple here. I'd happily switch to a nicer Pair/Tuple2 structure. And oftentimes I feel like using such thing, increasingly since starting to use Promise objects.

[samwgoldman]

Sure, the functional variant is a kind of "final encoding," where if you know how you will use the tuple, you can structure your code a bit differently. Say I know I am going to use the second half of a tuple and ignore the first, I can pass (a, b) => b as my "tuple."

Of course, you could also name the fields of your tuple and use an object/record with two properties.

[myitcv]

I'm also after a Tuple, but a special instance of one, one that represents an "entry" in a *Map. Let's call this type a MapTuple for the sake of what follows.

A MapTuple would be a tuple (two values), (K,V). In addition to the regular Tuple interface, a MapTuple would also expose the interface .key() and .value() that allows you to extract the key (type K) and value (type V)

In this way you could (as I need to do) convert a *Map into a List/Seq of MapTuple entries.

For now we are working around this by converting to a List/Seq of Seq which has two entries, 0/1 indexed. But having a .key() and .value() interface would be more explicit.

I note it's not currently possible/desirable to extend Immutable types #368

[ghost]

Thank you for reporting this issue and appreciate your patience. We've notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.

[gf3]

i'm also abusing Lists for this functionality

[leebyron]

Closing this aging issue

However It would be really exciting to see someone make this happen in a PR in the future