hm.
> [ R.head([]), R.head('') ]
Array [ undefined, '' ]
it would be reasonable for them to be the same. but which is better?
neither?
you want an error thrown?
nope
but you do want consistency?
is this equivalent to head?
> [[][0], ''[0]]
[undefined, undefined]
Hi all,
how can I implement analog lodash.defaults with ramda?
how can I implement analog lodash.defaults with ramda?
ask @jdalton ;)
What are analog defaults?
it's this right? https://lodash.com/docs#defaults
@CrossEye I think there was a word or two missing.
i imagine @AlexeyKhristov wanted what @algesten linked to.
@algesten I want this:
[S.head([]), S.head('')] //=> [Nothing(),Nothing()]
R.head('') should evaluate to '', in my view. Its type in this case is String -> String. Those disturbed by the handling of empty inputs (as I am) can use S.head instead.
thanks @algesten, yes, with lodash I use defaults function
imagin I have 3 objects
let a = {prop1: ‘a', prop2: ‘a'}
let b = {prop1: ‘b'}
let c = {prop2: ‘c'}how implement next transformation: f(a, c) -> a' and f(b, c) -> b' and get
a' = {prop1: ‘a', prop2: ‘a’}
b' = {prop1: ‘b', prop2: ‘c’}
Ramda has made the decision to not attempt to force on JS users such foreign-to-js concepts as Maybe, even if they are clearly helpful. I think having Sanctuary as well for those who want it is a great compromise.
wait, that's not right.
at least from your given output.
maybe?
@davidchambers isn't
R.head('') -> '' sort of also an expression of you being disturbed by empty inputs? .. i mean a why shy away from undefined? ;)
@joneshf: note that there's a button in the REPL to let you create a nice short link. It usually works. :smile:
I would rather the types be
head :: [a] -> a?
head :: String -> Stringthan
head :: [a] -> a?
head :: String -> String?One can view head(s) as taking a slice of s from index 0 to index 1, which gives '' when s is ''.
That's my justification, at any rate. ;)
@davidchambers and the asymmetry between string and array is not upsetting to you? ... i find that a bit jarring.
I do too!
The fact that in one case we have
[a] -> a and in the other case we have a -> a is very odd!
yes. the unwrapping.
hm. dual purpose functions.
But there's no way for us to pretend that
String is really [Char], since we don't even have Char.
if we had char, would you argue head for string is
string -> char?
Sure.
You don't view it as
head working with an interface?
What do you mean by that?
[R.head(''), R.tail(''), R.last('')] // => ["", "", ""]
[R.head([]), R.tail([]), R.last([])] // => [undefined, [], undefined]
okay, that is hella confusing.
like, jquery level of confusing.
@joneshf go on...
i mean, give it a more generic type.
The problem is that String is both an atom and a collection of atoms.
that's only a problem if you think the interface needs to work on collections.
Break a string into pieces, and what are the pieces? Strings!
What are you suggesting, @joneshf? I'm intrigued.
If the interface has
head, tail, cons as the things you need to implement, then you have certain laws, cons(head(xs), tail(xs)) == xs or whatever.
but you could perhaps argue that
undefined, as a value, is as much part of the type string as it is part of the type array.
so string should satisfy that.
along with array.
then you dont worry about how it's implemented
just whether it will satisfy the laws.
or maybe a differnt formulation of operations and laws
so to satisfy those rules
cons(undefined, []) really should be []
in which case
cons(undefined, '') should be ''
That's a nice way to view the situation, Hardy!
so. i'm obviously being dense here. but @joneshf are you happy or not happy with the current situation of R.head/tail/last? i don't know if there's a
R.cons to arbitrate whether those rules are upheld.
We have R.prepend, which for some reason does this:
> R.prepend('', '')
['']It's not supposed to accept a string as its second argument, of course.
Yes. Not optimal.
> R.prepend('a', 'bc')
["a", "b", "c"]
@algesten sure, but i'd like to hope there are more laws than just that one.
@algesten laws that would make what you stated not be true.
I'd hope that
length(cons(x, xs)) == length(xs) + 1
in which case, that definition of
cons you gave above would not be true any longer.
also, to be clear, I'm not suggesting any changes to ramda.
@joneshf got ya
@hemanth, your definition of currying is imprecise. My understanding is that currying is the process of transforming
(a, b, c) => … into a => b => c => ….
@davidchambers :) Thanks. Yeah as you mentioned it's
(a, b, c) => into a => b => c => the crowd there was very new to FP, so was trying to simplify.
there were like 400 devs in the crowd, out of them even if 40 picks up FP, it's a win for me.
Absolutely! Thank you for sharing FP!
MP. Thank you all for Ramda!
BTW I am trying to define all the FP jargons at https://github.com/hemanth/functional-programming-jargons
It would great to get PRs from this room :shipit:
"Jargon" is a mass noun, so you should remove the "s" from the name unless there's a reference I'm missing (which could easily be the case).
The repo is a great idea! I'll look at it later today.
@joneshf: I'm a little confused by the types of what you'd want: You made two suggestions very close together. You want
head([]); //=> Nothingwhich presumably implies:
head :: [a] -> Maybe(a)But cons, as I've always thought of it, is something like
cons: a -> [a] -> [a]So with those two, I can make little sense of your proposed law that
cons(head(xs), tail(xs)) == xsIt's not that I don't like the law, but I can't see how it works with Maybe(a) for its first parameter. Am I missing something simple?
nope, you're not missing anything.
I conflated my concerns.
Sorry about that.
So, going with the primitive types, it'd be nice for that law to hold, but with more complex types, then the law cannot hold as stated.
NP. I'd actually like to see if we can support a law like that.
his way of currying with just lambdas in the example is cool
It's by far the simplest way to write such curried functions, but then it only allows you to call the function as
fn(a)(b)(c)(d), and never as fn(a, b, c, d) or fn(a, b)(c)(d), etc.
yep. definitely going to explore that library
definitely want to look into his coroutine stuff!