These are chat archives for ramda/ramda

11th
Jul 2015
Scott Sauyet
@CrossEye
Jul 11 2015 03:12
@nomosyn: I haven't had time yet, although I've certainly read the Backus paper before. I expect to have time this weekend.
Hardy Jones
@joneshf
Jul 11 2015 03:25
@kedashoe I guess I meant what was the process
but i see it uses jsdoc with a custom template
Scott Sauyet
@CrossEye
Jul 11 2015 14:11
@joneshf: Not sure what you're looking for, but if you have https://github.com/ramda/ramda.github.io cloned (and have done npm install) you should just be able to build the docs through npm run docs, which delegates much to the Gruntfile, so you can see the details in there.
Hardy Jones
@joneshf
Jul 11 2015 14:16
I was looking for a template with search
Scott Sauyet
@CrossEye
Jul 11 2015 15:05
full-text search or name-search like ours?
Hardy Jones
@joneshf
Jul 11 2015 15:20
yes
Scott Sauyet
@CrossEye
Jul 11 2015 15:21
@nomosyn: I'm not really getting your ideas from those papers. What sort of APIs would you think are a good fit for Ramda? (BTW, the author of the second one is a member of the Ramda community.)
David Chambers
@davidchambers
Jul 11 2015 15:48
What are the downsides of having our curried functions report their lengths an one (in line with f(a)(b)(c)) rather than n (in line with f(a, b, c))?
Scott Sauyet
@CrossEye
Jul 11 2015 18:12
I think it's substantial. But I may be alone in this. What's the harm if someone else passes a function to us that ill-reports its own arity? If we curry it -- and we're adding automatic currying in various places and considering it in still others -- then we may well break things. So a user that used a different decorator library on their functions (call counting, logging, whatever) before they passed them to us might rightly feel that that library was at fault for abusing their functions. I feel that we shouldn't be doing it either.
David Chambers
@davidchambers
Jul 11 2015 18:13
Strictly speaking, though, curry(f) should return a unary function.
Scott Sauyet
@CrossEye
Jul 11 2015 18:15
In environments where all functions are unary, certainly. Ramda has chosen a different notion of curry, though, so that you don't have to call curry(f)(a)(b)(c) when curry(f)(a, b, c) or curry(f)(a, b)(c) is more convenient.
David Chambers
@davidchambers
Jul 11 2015 18:16
So it depends on whether you see curry(f)(a, b, c) as sugar for curry(f)(a)(b)(c) or the other way around.
Geert Pasteels
@Enome
Jul 11 2015 18:34
If I for example have an array ['foo', 'bar', 'baz'] that I want to filter but the filter method is different for each item what would be a good way to structure this with Ramda? I mostly end up with something like R.filter(filterWithRules(rules), array) but I was wondering if there are better approaches.
Asaf
@asaf-romano
Jul 11 2015 19:33
well, js is not haskell. js speaking, in no context f(a, b, c) may be considered "sugar".
@davidchambers let me look again
Hardy Jones
@joneshf
Jul 11 2015 19:50
maybe it would help to change the name from curry to something else?
because people seem to attach their own connotations to what the function should do based on the name
not because it's a bad name
I do the same with compose all the time
I think it should behave a certain way, and it doesn't
nomosyn
@nomosyn
Jul 11 2015 20:55

@CrossEye My purpose was to see if someone found these ideas relevant enough to
have implemented something in Javascript using ramda (and maybe sweet.js),
similar to what Slobodan Blazeski
did in lisp (but with js instead). (Maybe it's even not possible to do so)

My hope is that following these arguments by Backus, and thus implementing
similar functions to those in
J, it might be possible
to do more with less.

In particular, using ramda daily (thx to you all), we ended up centralizing
"axiomatic data" (data that have to be given) into arrays then
projecting/transforming the pieces that we wanted where we wanted using ramda
based point free style functions, instead of having "axiomatic data" spread all
over the place and verbose definitions. I thought that the "dicing" (slicing
sub tables in tables) part of multi-dimensional arrays could be enhanced by
ideas coming from J...

At that point, since something like this has not been done so far, I'll try to
do this and if ever something interesting comes out of this, will share it with
who is interested.

Thx for you time!