R.map doesn't support Sparse Arrays like the standard map about ramda HOT 11 CLOSED

At the very least, this difference should be documented. It probably wouldn't be hard to create a third version of map that worked the same was as the native Array.prototype.map for sparse arrays, but first I'd like to know a little more about use-cases. Why would you want this behaviour?

If the answer is simply to be more consistent with Array.prototype.map, that's probably not enough. In some very important sense, Ramda's fundamental data type is a list. The only comfortable way to work with lists in Javascript is through arrays.¹ The fact that arrays can also be used to house other sorts of structures is from our point of view mostly an unfortunate implementation accident.

I'm curious if you think this should match the native map more for reasons of consistency or if you have real use cases for mapping over sparse arrays.

¹ But for a very fun alternative see @buzzdecafe's cons, car, cdr gist, which builds up LISP-style lists from pure functions.

from ramda.

https://twitter.com/jashkenas/status/464121883961851904

from ramda.

chrome and ff already no longer "compact" the input array. tried it in the console, the above examples output

[undefined, 2, 3]

btw, i don't recall: do we have a fn to compact an array with undef's in it?

from ramda.

Well, I do get different behaviour from Ramda.map and Array.prototype.map. Ramda includes an 0 property in the output with value undefined. I just am not sure how important that is, especially given the tweet @megawac noted.

from ramda.

ah, i see, my examples were crazy weird js behavior; the '0' property is omitted but the length of the output array is still 3. Simplest impl:

R.map.sparse = function(fn, list) { return list.map(fn); };

which should play nice with functors et al.

from ramda.

Unless you're worried about compat

Sent from my HTC

----- Reply message -----
From: "Michael Hurley" [email protected]
To: "CrossEye/ramda" [email protected]
Cc: "Graeme Yeates" [email protected]
Subject: [ramda] R.map doesn't support Sparse Arrays like the standard map (#96)
Date: Fri, Jun 27, 2014 8:37 AM
ah, i see, my examples were crazy weird js behavior; the '0' property is omitted but the length of the output array is still 3. Simplest impl:

R.map.sparse = function(fn, list) { return list.map(fn); };

which should play nice with functors et al.

—
Reply to this email directly or view it on GitHub.

from ramda.

@megawac i agree with @CrossEye, compatibility alone is not a design goal.

from ramda.

@buzzdecafe: that would of course have to be curried if we chose to use it.

@megawac: what compat issues concern you?

But my main concern is that I have yet to see an actual reason to include it. That our map isn't a drop-in replacement for the one on Array.prototype should be clear. The callback function has a different signature, supplied only the element and not the index and the entire list as well. So the question is whether a third version of map is warranted. I'm waiting for a rationale. @cscalfani: any suggestions?

from ramda.

Sparse arrays should be avoided, theres plenty of articles about why a dictionary should be used to cover sparse array cases. Anyway, map is an es5 method, if you do want to support sparse arrays I recommend you create a composable each helper for normal and slow (sparse) cases. Just needs to have an extra if (i in arr) check. Seeing you don't suport context in your iterator functions es5 parity clearly isnt realistic

from ramda.

I think that support for sparse arrays as the default in the standard is a TERRIBLE idea. I agree that at least the documentation should note the lack of sparse array support. I can imagine people using these functions as drop-ins for the standard functions.

So @CrossEye, I cannot provide any reason that Ramda should support them and only made the suggestion for an alternative function if standard support was desirable, which appears, from this thread, to be non-existent.

from ramda.

ok, i think we all agree--we gotta document the difference in R.map from Array.prototype.map w/r/t sparse arrays, but otherwise, we're not going to support it until someone provides some convincing use cases

from ramda.