These are chat archives for ramda/ramda

31st
Oct 2015
David Chambers
@davidchambers
Oct 31 2015 00:14
@joneshf, does this representation seem right to you?
Maybe [Maybe String]
{ typeName: "sanctuary/Maybe",
  arguments: [ { typeName: "sanctuary/List",
                 arguments: [ { typeName: "sanctuary/Maybe",
                                arguments: [ { typeName: "String",
                                               arguments: [] } ] } ] } ] }
[Either a b]
{ typeName: "sanctuary/List",
  arguments: [ { typeName: "a", arguments: [] },
               { typeName: "b", arguments: [] } ] }
Hardy Jones
@joneshf
Oct 31 2015 00:17
I think it depends on what you're trying to accomplish
Also, the second one is missing the Either
Danielle McLean
@00dani
Oct 31 2015 00:19
It seems a little odd to include an empty arguments list on types that can't take arguments, I think. Although I suppose it's more consistent to process possibly. Again, depends what you're doing with it.
Hardy Jones
@joneshf
Oct 31 2015 00:22
What part is odd?
Danielle McLean
@00dani
Oct 31 2015 00:26
I dunno. Either is a function of two types, String is just a type? Then again, values are essentially nullary functions so whatever. :p
Asaf
@asaf-romano
Oct 31 2015 01:13
@CrossEye So, I think it worked for very different reasons in 0.17 and 0.18 (and also for different reasons in 0.15). Long story short, there's nothing here that checks if the returned value is a promise or a function before it calls then:
In 0.17, pipeP was curried by default, so you'd not get into the first function before supplying all arguments
that is, _pipeP was only invoked after all arguments were supplied
Asaf
@asaf-romano
Oct 31 2015 01:19
@CrossEye So it turns out that's not just pipeP, pipe is also broken, it just manifests in different ways
Both pipe and pipe assume that all of the args for the first function are supplied.
Asaf
@asaf-romano
Oct 31 2015 01:26
As for the pre-0.17 implementation, I think I'm too tired atm to make sense of what was going on in createCompose and the like.
but it worked ;)
Asaf
@asaf-romano
Oct 31 2015 09:13
Full details on the issue now. Hope it helps.
Raine Virta
@raine
Oct 31 2015 09:14
@asaf-romano wasn't that an intended effect from reverting the "pipe/compose return curried functions" change?
Asaf
@asaf-romano
Oct 31 2015 09:20
@raine sort of, but I don't think the case of the first function being already curried was discussed. If we could actually tell that a function is curried (see the details there), I think it'd be safe for pipe/compose to return curried functions in that case (but not in the case of (R.pipe((a, b) => ..., ...)
@raine http://bit.ly/1khY7Nc - something like this cannot be broken, IMO.
Raine Virta
@raine
Oct 31 2015 09:26
is the ACTIVITY feed on right working for you?
okay, might be working now. gitter wasn't configured in the services
Asaf
@asaf-romano
Oct 31 2015 09:31
in other news, I don't get the "Use ramda-fantasy Future to wrap AJAX" example in the cookbook; "fetch" is just a function that returns a future.... but then the code shows it calls fetch.chain
i see one activity in the feed (mergeWith)
Raine Virta
@raine
Oct 31 2015 09:33
it was the "Test service" message, I guess
Raine Virta
@raine
Oct 31 2015 10:03
trying to keep functions pure in javascript as much as possible by passing impure thing as argument makes code a lot noisier and apis less concise
is it just necessary evil or am i missing a trick?
Asaf
@asaf-romano
Oct 31 2015 10:25
are you referring to something specific?
Raine Virta
@raine
Oct 31 2015 10:27
not really, i'm just talking about the general pattern of passing "environment" as an argument instead of using require/rewire hacks to shadow variables or modules
Asaf
@asaf-romano
Oct 31 2015 10:30
Ah, that. Working in both ramda and Java-8-with-spring everyday, I'm still looking for a good cross between FP and DI :) For now, I'm using proxyquire for tests (as a workaround for no-DI) and require (well, import) in the normal workflow. And my functions are technically impure.
in client side, angular code I'm sometimes falling into the "injects" argument pattern I think you're talking about. And that's indeed, very unpretty.
Raine Virta
@raine
Oct 31 2015 10:34
might just be better of using proxyquire or rewire to hack the value of process to custom object
Asaf
@asaf-romano
Oct 31 2015 10:39
that works until you get greedy and start wondering about reusing server-side code on the client side and vice versa
e.g. a data-provider that works with the db on the server side, and with test on the client side
Raine Virta
@raine
Oct 31 2015 10:40
purely node lib in this case, thankfully
Asaf
@asaf-romano
Oct 31 2015 10:40
proxyquire and move on :)
Raine Virta
@raine
Oct 31 2015 10:40
i'm now trying something where all environment is in a single object called ui
so i don't at least have to pass the extra variables 3 functions deep
Hardy Jones
@joneshf
Oct 31 2015 15:03
I'm very confused about all this compose/pipe stuff.
Why does ramda look at or care what the functions are, or if they're curried, or how many arguments they have?
Martin Algesten
@algesten
Oct 31 2015 15:05
the only thing that makes sense to me is currying the resulting function to the arguments of the first function. the rest for me are unary. however just assuming a unary first would be ok too.
Hardy Jones
@joneshf
Oct 31 2015 15:12
That's what i mean. It shouldn't be doing any of that.
Martin Algesten
@algesten
Oct 31 2015 15:13
you mean ramda should not curry the resulting function?
Hardy Jones
@joneshf
Oct 31 2015 15:15
Yes, compose should only compose functions.
Martin Algesten
@algesten
Oct 31 2015 15:16
looks like it does exactly that now. it preserves arity, which i assume you agree with?
Eric Gjertsen
@ericgj
Oct 31 2015 16:42

@asaf-romano:

@raine http://bit.ly/1khY7Nc - something like this cannot be broken, IMO.

curry the composed function? http://bit.ly/1XHrt6A

Eric Gjertsen
@ericgj
Oct 31 2015 18:43

@raine:

i'm just talking about the general pattern of passing "environment" as an argument instead of using require/rewire hacks to shadow variables or modules

Looking at ramda-t... could you have yourwrapFunction return an Either String Function , then deal with writing to stderr at the top level for Either.Left cases?

Asaf
@asaf-romano
Oct 31 2015 20:13
@ericgj yes, i know that workaround. this is why it worked in 0.17
Raine Virta
@raine
Oct 31 2015 20:19
@ericgj wrapFunction can't really produce Either I think because the errors happen much later when the wrapped functions are used
Eric Gjertsen
@ericgj
Oct 31 2015 23:35
or what about one step down then - validate could return an Either which gets dealt with in wrapFunction.