These are chat archives for ramda/ramda

10th
Apr 2017
Nate Martin
@NateTheGreatt
Apr 10 2017 00:29
trying to find a clever way to keep track of parent folders so i can end up with a flattened array of filepaths
Kurt Milam
@kurtmilam
Apr 10 2017 00:40
Kurt Milam
@kurtmilam
Apr 10 2017 11:27
I wonder whether there'd be any interest in either finding a way (possibly via a second library) to expose some of ramda's internals (e.g. _concat) or offering a fast implementation of the library relying on an auto curry method with better performance.
Johnny Hauser
@m59peacemaker
Apr 10 2017 11:35
@kurtmilam oooo fast currying, you say?
I might have something to offer on this subject
I don't understand your test, though
Johnny Hauser
@m59peacemaker
Apr 10 2017 11:40
I'll pm you my curry. It's the fastest of any I could find.
Kurt Milam
@kurtmilam
Apr 10 2017 11:48
@m59peacemaker Thanks! I've starred your project in github.
Casey Link
@Ramblurr
Apr 10 2017 11:51
Ooh. I'd be interested in a fast auto curry too. Working on some perf sensitive code with ramda and I'm always looking to make it faster
Kurt Milam
@kurtmilam
Apr 10 2017 11:52
If I use your curry on a function like compose = ( f, g, h ) => f( g ( h ) ), do I get back a function that I can call either like compose( a, b, c ) or compose( a )( b )( c )?
I've been writing some pre-curried replacements for ramda functions that only accept one argument at a time, but I'm pretty sure they're significantly faster than the auto curried ramda alternatives.
@m59peacemaker An auto curry function that generates a function that can take multiple arguments would be nice if the performance hit wasn't too extreme.
Johnny Hauser
@m59peacemaker
Apr 10 2017 11:56
Mine is fully featured auto-curry
So, yeah, you can definitely beat it by taking away features
of course
So, I linked you my curry-n, and curry is in that repo, too
It's just curry = f => curryN(f.length, f) of course
For the best perf, you will always want to use the non-curried currN (curry-n/core)
Kurt Milam
@kurtmilam
Apr 10 2017 11:58
Cool. It would be interesting to know what the performance hit is for autocurrying using your function over writing curried functions from the get-go. The main thing I don't like about manually curried functions is the lack of support for argument tips in my IDE.
Johnny Hauser
@m59peacemaker
Apr 10 2017 11:58
But the cool things is, no matter what you do, when invoked, the curried functions are DANGED fast
Check out my benchmarks (remember to comment out toString)
the thing you have to keep in mind when discussing this is that you have 3 points to bench
The initial curry, partially applying, and then the actual call when all arguments have been passed
I figure the last part is the most important part
So, mine is faster than many on the first two points, but they can certainly be better, but you'll greatly lose on the last step where it probably counts most
This is similar, but it has dead code, creates an array it doesn't need to, the code is otherwise ugly, and it fails some tests it ought to pass
maybe it was just this vs void 0
though I care very little about breaking context, because screw OOP
Kurt Milam
@kurtmilam
Apr 10 2017 12:02
:thumbsup:
Johnny Hauser
@m59peacemaker
Apr 10 2017 12:02
so I stole it :)
The main hold up on my lib is figuring out how I want to do transducers
and operating on k, v pairs
I've got all the hard work done. All the transducer logic is there and without using classes, unlike every other transducer lib... even Ramda :'(
just gotta decide on API
the endless debates on the Ramda issues page makes it dang scary to decide on a functional API :)
Kurt Milam
@kurtmilam
Apr 10 2017 12:06
w/r/t transducers or more generally?
Johnny Hauser
@m59peacemaker
Apr 10 2017 12:06
w/r/t ?
Kurt Milam
@kurtmilam
Apr 10 2017 12:06
sorry, w/r/t = with regards to.
Johnny Hauser
@m59peacemaker
Apr 10 2017 12:06
ahh
Just googled it haha
Kurt Milam
@kurtmilam
Apr 10 2017 12:07
:D
Johnny Hauser
@m59peacemaker
Apr 10 2017 12:07
man my brain just melts on all this. So, I've got transducers such that I can do:
into([], compose(
  map(inc),
  filter(isEven),
  // etc
)
and I did the ramda thing such that map and filter, etc, when given data as a second argument, will just be regular map, filter, etc
but, the idea of transducers is to not reinvent that logic for everything, so I just have them call into internally
then you lose perf there by not deferring to [].map
however, it turns out that [].reduce, at least in my benches, is faster than the [].map equivalent... so that's interesting
but, if you defer to [].reduce rather than using the transducer supporting reduce, you lose the ability to short circuit by returning Reduced(value)
The simple thing would be to keep it all separate.
You have array operators that are just like [].operators but they are curried
and then you have operators that will operate on anything and are curried
Johnny Hauser
@m59peacemaker
Apr 10 2017 12:12
those can use transducers underneath just because transducers can already work on iterables and such
and then you have the actual transducer API for when you want stuff to transform item by item in that manner
but, that's also 3x the api
Kurt Milam
@kurtmilam
Apr 10 2017 12:13
so it's mostly a call between better performance and more functionality?
Johnny Hauser
@m59peacemaker
Apr 10 2017 12:13
I suppose
A very important thing to me is that this stuff stays very modular
I want to have little to no regret pulling in some packages on a small npm package
Kurt Milam
@kurtmilam
Apr 10 2017 12:14
Maybe offer two transducers - one for performance and one for the added functionality, and let the 'user' decide which one to use based on their use-case?
Johnny Hauser
@m59peacemaker
Apr 10 2017 12:14
So, overloading the operators to act as transducers AND regular operators is bothersome
Perhaps. It's just hard to decide without knowing what problems I and others will be facing in all possible situations.
If performance is really such a big deal, you should probably write uglier code with some one off functions, right?
I think if you're at that point, you abandon anything with curried functions
other things floating around my brain - chaining transformations with transducers turned out to be definitely faster than native operators or anything else
Kurt Milam
@kurtmilam
Apr 10 2017 12:18
Would explicit, single-argument currying be an option / be helpful? fn( a )( b )( c )
Johnny Hauser
@m59peacemaker
Apr 10 2017 12:18
but, you also end up with into({}, etc ALL OVER the place
mmm, not sure
I don't favor it, but I've never seen a debate on the merits
Kurt Milam
@kurtmilam
Apr 10 2017 12:24
Unfortunately, my brain is too focused on other things to give your api situation the proper attention it would deserve in order to come up with well-considered responses.
Limited multitasking capacity :)
Johnny Hauser
@m59peacemaker
Apr 10 2017 12:26
I totally get it. I feel the same way about it myself haha
Kurt Milam
@kurtmilam
Apr 10 2017 12:26
Starts to sound like Charlie Brown's teacher on the telephone after a few sentences, with just one or two words coming through clearly :)
Michael Rosata
@mrosata
Apr 10 2017 12:44
@m59peacemaker Thanks for tip yesterday
Aaron Mc Adam
@aaronmcadam
Apr 10 2017 13:26
Hi all, can I get a few ideas on getting some keys out of an object? https://goo.gl/NrNTUP
Johnny Hauser
@m59peacemaker
Apr 10 2017 13:47
@mrosata no problem! Glad to help!
Ryan Stegmann
@rstegg
Apr 10 2017 14:44
quick nub question, what are the options for ramda in a scenario like this? (sorry about the intentional naive for optimal answer :laughing:)
      if(!a.b.c.1) {
       log('err1')
      }
      if(!a.b.c.2) {
       log('err2')
      }
      if(!a.z.y) {
        log('err3')
      }
      if(!a.f.g) {
        log('err4')
      }
     (..)
Rick Medina
@rickmed
Apr 10 2017 14:46
are you talking about the branching or the side effects?
Ryan Stegmann
@rstegg
Apr 10 2017 14:46
the branching
side effects just to show that they aren't the same
Rick Medina
@rickmed
Apr 10 2017 14:49
branching is not covered by ramda (other than R.ifElse, R.when, etc sugar) or are you asking in the more broad fp terms?
Kurt Milam
@kurtmilam
Apr 10 2017 14:50
@rstegg have you taken a look at cond for branching?
Ryan Stegmann
@rstegg
Apr 10 2017 14:52
@kurtmilam thanks! cond works pretty good
Kurt Milam
@kurtmilam
Apr 10 2017 14:52
:thumbsup:
Ryan Stegmann
@rstegg
Apr 10 2017 14:52
i was looking for more of a persp with lens, is it not pref. here?
Kurt Milam
@kurtmilam
Apr 10 2017 14:55
I mean, you can use lenses to get the nested properties, but I can't think of a straightforward way off the top of my head to use lenses to do the branching part.
So lenses + cond if what you really need is to branch based on nested properties.
Ryan Stegmann
@rstegg
Apr 10 2017 14:56
awesome,, thanks!
Brad Compton (he/him)
@Bradcomp
Apr 10 2017 15:01
@rstegg R.cond will only run a single branch, whereas the code above will run the failure branch for each falsey property above. This might be something to consider depending on what your goals are.
Kurt Milam
@kurtmilam
Apr 10 2017 15:02
@Bradcomp good point.
Ryan Stegmann
@rstegg
Apr 10 2017 15:04
@Bradcomp it's actually a req parameter logging system - to check if properties don't exist in the request
Brad Compton (he/him)
@Bradcomp
Apr 10 2017 15:07
So it just logs and moves on?
Ryan Stegmann
@rstegg
Apr 10 2017 15:08
after it hits one condition it stops [so like switch]
Brad Compton (he/him)
@Bradcomp
Apr 10 2017 15:14
Consider having the paths as a list of lists: [['b', 'c', 1], ['b', 'c', 2], /*...*/], and then using reduceWhile or find with path (or pathSatisfies) to retrieve the first path that fails?
Ryan Stegmann
@rstegg
Apr 10 2017 15:17
i'll play with it. thanks! :smile:
Michael Rosata
@mrosata
Apr 10 2017 16:19
@aaronmcadam Here's an implementation of your API spec. If anyone makes improvements I'd like to check them out -- https://goo.gl/RDuMCR
Aaron Mc Adam
@aaronmcadam
Apr 10 2017 17:20
Thanks a ton @mrosata!
Robert Mennell
@skatcat31
Apr 10 2017 17:21
... Really wishing vanillla Promises offered a fold method right about now...
or chain...
Gabe Johnson
@gabejohnson
Apr 10 2017 17:27
@skatcat31 what would fold do? And how would your use of chain differ from then?
Robert Mennell
@skatcat31
Apr 10 2017 17:31

@gabejohnson fold removes the value from context

Context.of( 1 ).fold( ) === 1;

... as for the chain method, don't they allow you to prevent a context wrapping from map or in this case then( pretty much a transformative fold )?

Context.of( 1 ).chain( fn ) === fn(1);
Afterall it's be really nice to Promise.resolve(1).chain( Promise.resolve ) to avoid nested promises... or I may just be using promises incorrectly
Gabe Johnson
@gabejohnson
Apr 10 2017 17:34
@skatcat31 then is overloaded with the behavior of map and chain
returning a Promise from a function passed to then doesn't nest
Robert Mennell
@skatcat31
Apr 10 2017 17:36
... man I'm tired. Totally forgot that...
Michael Rosata
@mrosata
Apr 10 2017 17:36
@aaronmcadam no problem!
Robert Mennell
@skatcat31
Apr 10 2017 17:36
Been sitting here for like 30 minutes trying to figure out a way to prevent a nest and I forgot the spec specifies it shouldn't -.-
@gabejohnson thanks. I'm... gonna go get some coffee
Gabe Johnson
@gabejohnson
Apr 10 2017 17:36
As for fold, Promises are async. There's not much you can do about that besides using async functions
np
@skatcat31 I wasted a bunch of time on something simple last night when I was tired. Lesson...don't code when you're tired
Michael Rosata
@mrosata
Apr 10 2017 17:42
@skatcat31 sounds like you want a stream with scan or write a recursive fold function using a generator. Like @gabejohnson said there is async. To keep the discussion ramda though, you might find something you like using http://ramdajs.com/docs/#composeP or http://ramdajs.com/docs/#pipeP
Robert Mennell
@skatcat31
Apr 10 2017 17:47
@gabejohnson understatement of the century. I can program inhibreated out of my mind... but tired... that's when I'm done for
@mrosata I'm not allowed to use Ramda in this context sadly
Michael Rosata
@mrosata
Apr 10 2017 17:48
what are your constraints? Just vanilla?
In production is the recommendation typically to import every ramda function individually? import map from 'ramda/src/map'?
Robert Mennell
@skatcat31
Apr 10 2017 17:57
vanilla or vetted libraries only(client)
Brad Compton (he/him)
@Bradcomp
Apr 10 2017 17:59
The closest thing a Promise has to fold IMO is just the 2 parameter version of then: .then(successHandler, errHandler) which still returns a promise, but lets you handle both cases and return the result.
Rick Medina
@rickmed
Apr 10 2017 18:08
.then such a great example of simple vs easy
Michael Rosata
@mrosata
Apr 10 2017 18:08
then does the trick
Rick Medina
@rickmed
Apr 10 2017 18:11
a trick on who? :)
Robert Mennell
@skatcat31
Apr 10 2017 18:13
I might just import bluebird and use generators...
Gabe Johnson
@gabejohnson
Apr 10 2017 18:13
I don't see anything wrong w/ then in isolation (aside from it being overloaded).
but in the wider JS ecosystem a consistent API would have been better
Robert Mennell
@skatcat31
Apr 10 2017 18:14
@gabejohnson no language is perfect afterall
Gabe Johnson
@gabejohnson
Apr 10 2017 18:19
@skatcat31 incorrect http://shenlanguage.org/
:smile:
Robert Mennell
@skatcat31
Apr 10 2017 18:21
@gabejohnson ... this reminds me of emacs... great OS, horrible editor XD
Gabe Johnson
@gabejohnson
Apr 10 2017 18:22
What do you think my gitter client is?
j/k
Galileo Sanchez
@galileopy
Apr 10 2017 21:07
is there an easier way to do this?
R.over(
    R.lens(
        R.prop('id'),
        R.assoc('value')
    ),
    R.identity
)
Kurt Milam
@kurtmilam
Apr 10 2017 21:35
@galileopy have you tried:
R.set(
    R.lens(
        R.prop('id'),
        R.assoc('value')
    )
)
R.set( lens ) is like R.over( lens, R.identity)
To be more clear, set is just a derivation of over, where set( lens ) = over( lens, identity )
Galileo Sanchez
@galileopy
Apr 10 2017 23:33
@kurtmilam I ended up implementing a small copy function that receives the src and dest,