Tuples in JavaScript | Hacker News Reader

Tuples in JavaScript

oli.me.uk

36 pointsshawndumas22 comments

The main value of a tuple is as a type-safe alternative to an array/list (e.g. scala tuples don't even have named elements). This makes them a lot less useful in a language like Javascript.

I like the "unpack" idea of using a function to name the parts of the tuple, it's elegant and fits well into JavaScript. I'm a bit less sure about exposing the "pack" method outside the constructor. That makes tuples mutable, which isn't what I normally want. Normally I want immutable collections of possibly mutable objects for my tuples. If I wanted a mutable collection I would use an array.

I absolutely hate the idea of "valueOf". Why would you ever in your life want to add together tuple values by default? It's a misfeature that is begging to cause bugs. A better feature would be some way of applying functions across tuples of the same size (map and fold type operations) to make it easy to build up correct comparison functions.

So what if I made immutable. You can only set once and unpack to a function that can name the values. I could also drop the valueOf usage.

Does that sound saner? It is definitely simpler and a lot closer to an actual tuple implementation.

I want to turn this into a small repository so maybe I will take the little good bits and drop anything unnecessary.

Actually thinking about it more you might want to have "Tuple" and "MutableTuple" objects. In languages that use parentheses notation for tuples you need to decide which one you want, but since you have names you can have both just with different names.

An alternative would be the old lambda-calculus trick of just saving the function with values in the closure.

    function Tuple(/* args... */) {
      var args = arguments;
      this.unpack = function(fn) {
        return fn.apply(null, args);
      }
    }

The problem with that being that you redefine the unpack function every time a tuple is created. The this._NAME = VALUE; may look awful but it's more efficient.

You are just relying on your users to not abuse _ prefixed variables. It's far from ideal.

Actually, good js implementations (like v8, for example) will only create one code object shared by all the unpack functions, with separate closures assigned to each. And since closures can (usually) be statically determined, they can use an offset lookup for the closured variable in place of a hashtable. So it's not quite as inefficient as it looks :).

Huh, I never knew that. Thanks! As long as you're in a decent environment that kind of definition becomes a lot smoother. I like it.

Streamlined, removed the insanity, tested and documented. Any better? https://github.com/Wolfy87/tuple

Why does it even have that pack method, let alone fill the array backwards? You could just do this._store = Array.prototype.slice.call(arguments). Tuple.unpack(callback) isn't any better than callback.apply(x, array), so not sure what value it offers there either. The valueOf definition is the sort of thing that makes me cringe because it would undoubtedly lead to hard-to-diagnose bugs in JS applications. Not sure what anyone would use this type for.

Cute demonstration of ways to extend JS, I guess, but please don't use anything like this code.

It fills the array backwards because that is the most efficient loop possible within JavaScript when the order does not matter.

I added a pack method to enforce some weak limiting on the size of the array. This will only allow you to set an amount of values equal to the initial values that were set.

I know you can do it with `slice` etc, but the point was to make something a little different to an array or object inspired by the things I have been learning about functional programming.

Please, by all means, treat it as a cute demonstration. That's fine. I personally could see myself using something like this in some situations as a base type to extend from for example. Maybe as a generic coordinate storage system as I have shown in the post.

It has many flaws and might not fit in with your opinions or views, but saying "don't use anything like this code" seems a bit heavy handed to me. I think it has a time and a place, no matter how minute that time or place may be.

Adding an implicit coercion to number to a tuple type that contains multiple elements in a dynamically typed language is just a bad idea. Period.

Okay, that isn't integral though. This could easily be left out if desired. It's not coercing to a number either, it's simply concatenating. This would work with strings too or any other type that supports valueOf.

You have valid points though. I just didn't like to think of this as something that could never be used in the real world. Or at least contain little ideas that could be used in the real world. It has at least some relevance.

This seems like a solution in search of a problem.

Sometimes porting features from other languages into one you are familiar with helps you get a better feel for them, even if they are useless due to not aligning with the feel/philosophy of the language at all.

"I recently read Functional JavaScript and can’t physically recommend it enough".

I believe this is a must read book for all advanced JavaScript developers. Michael Fogus uses UnderScore.js library by Jeremy Ashkenas, to teach functional programming using JavaScript. It changed my perspective on how to create reusable javascript functions that are easy to maintain.

Nice use of the valueOf override. Those interested in set theory in javascript may also find Set.js handy: https://github.com/gkatsev/set.js

Not sure what value tuples really provide in JS (as other comment pointed out, they are offer the most utility in strongly-typed languages)... but this is a neat technique nonetheless and an interesting read.

How does this differ than using a magnetized needle and a steady hand?

Why so much code? A closure is shorter and simpler. https://gist.github.com/strager/6107955

where is data matching operations like in Erlang?

If wishing made it so.

Reply on news.ycombinator.com