These are chat archives for ramda/ramda

29th
May 2015
Jethro Larson
@jethrolarson
May 29 2015 00:25
This message was deleted
Hardy Jones
@joneshf
May 29 2015 00:32
haha
Raine Virta
@raine
May 29 2015 06:51
i've heard this name discussed before singleton(k, v) http://bilby.brianmckenna.org/#singletonk-v
Asaf
@asaf-romano
May 29 2015 12:51
Hey all, is there some documentation for the build process?
just running mocha in the top dir fails for me
var mapIndexed = R.addIndex(R.map);
                   ^
TypeError: undefined is not a function
Raine Virta
@raine
May 29 2015 12:55
it's probably because API has changed, and in the process also the code used to build ramda with ramda from npm (0.14)
nope, not this time.
you have to build ramda first with make
Raine Virta
@raine
May 29 2015 13:01
because dist/ramda.js is not built on every commit
Asaf
@asaf-romano
May 29 2015 13:06
thanks!
Asaf
@asaf-romano
May 29 2015 13:22
@raine sorry, I only saw your comment there after I posted the PR
Asaf
@asaf-romano
May 29 2015 13:22
maybe mapByKeys or something like that.
Raine Virta
@raine
May 29 2015 13:27
I wonder if that operation exists in other libs or languages
Asaf
@asaf-romano
May 29 2015 13:32
no clue. it's quite a common way to generate a pseudo enum in js.
Asaf
@asaf-romano
May 29 2015 14:03
@davidchambers looking at your Map work, is forEach intentionally left out? technically, it could be dispatched
(in fact, that's true for all es iterables... leaving Arrays out, ramda could dispatch forEach and support all es iterables there plus all other libs that implement forEach, e.g. immutable.js)
Michael Hurley
@buzzdecafe
May 29 2015 16:44
forEach is a bit of a red-headed stepchild, since it is for side effects. That said, since we do include it, we probably should dispatch on it
Marc Harter
@wavded
May 29 2015 19:18

Is this a decent way to go about a mapThenFlatten function?

let mapThenFlatten = R.curry(R.compose(R.flatten, R.map))

I had to R.curry because it was returning an array and not a function.

Raine Virta
@raine
May 29 2015 19:19
Marc Harter
@wavded
May 29 2015 19:20
Thx @raine , this seems to work R.chain(R.flatten, R.map)
Hmm.. actually looks like just R.chain does the trick. Sweet :)
Raine Virta
@raine
May 29 2015 19:55
bleh, pushing to a wiki repo on github not possible for mere mortals
Scott Sauyet
@CrossEye
May 29 2015 19:55
What's the issue @raine?
Raine Virta
@raine
May 29 2015 19:56
i was looking into automating toc generation for the cookbook
Scott Sauyet
@CrossEye
May 29 2015 19:57
@wavded chain is known is some languages/libraries as flatmap :smile:
@raine about to be offline for an hour or two, but if you want to email me what you're trying to do, I'll see what I can do when I'm back online. scott@sauyet.com
Asaf
@asaf-romano
May 29 2015 20:58
@CrossEye did you see my comment regarding R.of in the uniq bug? I was wondering if there's some other function in R that's supposed to do the trick
(I want to PR uniq sometime soon)
Scott Sauyet
@CrossEye
May 29 2015 22:50
@asaf-romano: Have now. Responded to the issue, saying I'd love to see a PR. Do you feel up for it?
Asaf
@asaf-romano
May 29 2015 22:55
@CrossEye PR for uniq?
yes, planing to; but there I was referring to Array.from vs. R.of
I'll probably add an _internal function that mimics Array.from as I did there; it's another discussion whether that one should be public
Scott Sauyet
@CrossEye
May 29 2015 23:00
I don't know that there is a great function besides the R.into you mentioned there. R.of is there mostly to satisfy FantasyLand specification, and it tries to do something useful for lists, but I don't know that we can make it beautiful.
Once you have your implementation working, why don't you propose making that public in a separate issue?
Asaf
@asaf-romano
May 29 2015 23:02
yeah, that's what I was planning to do; it's just, like mapKeys, something that's hard to name.
Scott Sauyet
@CrossEye
May 29 2015 23:05
Well, we all know the classic line, right? There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
Asaf
@asaf-romano
May 29 2015 23:06
:)
Raine Virta
@raine
May 29 2015 23:08
right now i feel like adding testing I/O into that list
Scott Sauyet
@CrossEye
May 29 2015 23:12
off-by-two?
hey @raine, what was it you wanted to do with the wiki? Can I help?
Asaf
@asaf-romano
May 29 2015 23:13
should I add tests for _internal functions?
Scott Sauyet
@CrossEye
May 29 2015 23:14
No, don't bother yet. That's always subject to being refactored away.
Asaf
@asaf-romano
May 29 2015 23:14
ok
Scott Sauyet
@CrossEye
May 29 2015 23:14
If it's the one we're thinking of making public, then a separate PR for that one should include tests...
Asaf
@asaf-romano
May 29 2015 23:16
btw, is it legit to include R in internal/* too?
as some public funcs do
Scott Sauyet
@CrossEye
May 29 2015 23:17
In tests?
Asaf
@asaf-romano
May 29 2015 23:17
no
sec
ah, you're right, they always include just-what-they-need.
Scott Sauyet
@CrossEye
May 29 2015 23:19
But I'm not sure if it's an issue if an internal one does a require('../someMainFunc'). Feels like crossing the streams. But somehow, I suspect we already do so, somewhere.
Asaf
@asaf-romano
May 29 2015 23:21
i think i've seen some.
Raine Virta
@raine
May 29 2015 23:24
@CrossEye well I experimented with a programmatically generated TOC for https://github.com/raine/ramda-cli/wiki/Cookbook, it uses doctoc.
was setting up the same thing for ramda cookbook but unfortunately github requires same level of access for wiki pushes as for repos
Asaf
@asaf-romano
May 29 2015 23:28
what's the purpose of _curry1 in practice?
e.g. in of.js
Scott Sauyet
@CrossEye
May 29 2015 23:29
To drive @buzzdecafe crazy.
Asaf
@asaf-romano
May 29 2015 23:30
I'll stick to it then.
Scott Sauyet
@CrossEye
May 29 2015 23:30
The main goal is so that we can support placeholders and currying with consistent laws.
Asaf
@asaf-romano
May 29 2015 23:30
ah, so R.of(R.) returns a functions?
function*
Scott Sauyet
@CrossEye
May 29 2015 23:30
yes
And so we can say a function of n parameters if called with m parameters (m <= n) returns a function of (n - m) parameters.
@buzzdecafe has never liked this. I lost an earlier battle around curry(f)() for some positive arity f. I wanted it to behave like it does now, and return the equivalent of curry(f). @buzzdecafe argued for throwing an error, because calling it like that is just stupid. We did it that way for some time. But when @davidchambers was trying to make the placeholders more universal, this got turned back to the way I preferred, as it matched a simpler-to-state, and simpler-to-enforce law. I believe @buzzdecafe is playing around with a fork that changes a lot of this, and tries to simplify some of this substantially.
Asaf
@asaf-romano
May 29 2015 23:38
I wouldn't expect R.of(R.) to throw, that is: the current behavior makes sesne; OTOH, curry1 is plain BS..
AssertionError: '_toArray' === '_toArrayJs'
Asaf
@asaf-romano
May 29 2015 23:43
@CrossEye sigh, "'has R.equals semantics" test for uniq obviously fails after this change.
to be precise, it works as expected for NaN and -0 vs. +0
but not for the Just case, of course.
Scott Sauyet
@CrossEye
May 29 2015 23:51
@asaf-romano: Ahh, interesting. That sort of rule is something we probably want to keep.
Asaf
@asaf-romano
May 29 2015 23:55
time to wontfix I guess. There's no way to alert Set's logic.
alter*
though the ticket is technically fixed.. it's titled "Consider..." and it was, indeed, considered.
Scott Sauyet
@CrossEye
May 29 2015 23:58
After seeing the perf numbers, I would really like to take another swing it this somehow, even if the Set implementation is not it. Would you be willing to write a quick comment on the issue, and people can see if they have another approach that might help?
Just describing what you tried and why it failed.
Asaf
@asaf-romano
May 29 2015 23:59
I commented already. I could elaborate a bit.
Scott Sauyet
@CrossEye
May 29 2015 23:59
We can discuss whether we want the delegate-to-equals behavior, too.
ok
I think we want that behavior as shown by the Just test, but it's worth discussing.
thanks.
Sorry it was a dead end.