These are chat archives for ramda/ramda

31st
Mar 2016
Julien Goux
@jgoux
Mar 31 2016 10:08
Hi
I'm not sure I understand sanctuary's pipe
S.pipe([() => Future.of("foo")])() doesn't return a Future, it returns [Function]
Ivan Demchenko
@raqystyle
Mar 31 2016 10:12
@jgoux probably because you have to pass something in the last ()
I'm not sure whether that's a bug
Julien Goux
@jgoux
Mar 31 2016 10:14
oh :o
Interesting ^^
Aldwin Vlasblom
@Avaq
Mar 31 2016 10:28
S.pipe is curried in a way that it counts its arguments. So S.pipe() returns S.pipe.
@ram-bot S.pipe()()()()([x => x + 1])(1)
ram-bot
@ram-bot
Mar 31 2016 10:28
2
Aldwin Vlasblom
@Avaq
Mar 31 2016 10:33
If you really want to pass undefined into your pipeline, you should be able to do it explicitly:
@ram-bot S.pipe([() => 1])(undefined)
ram-bot
@ram-bot
Mar 31 2016 10:33
1
Aldwin Vlasblom
@Avaq
Mar 31 2016 10:34
But I'd recommend keeping your pipelines pure, so don't include functions that take no input. Instead call those functions beforehand and pass the result into your pure pipeline.
Jigar Gosar
@jigargosar
Mar 31 2016 11:19
Hey guys, when using lens, I get wierd error if destination doesn't exist. is there a way to query lens for its path so that I can log it?
Scott Sauyet
@CrossEye
Mar 31 2016 11:39
Well, lenses are really defined against known structures. Pou might have to move to Prisms or Isos to do something more. I'm not quite sure how far Ramda-Lens has come in its efforts to create those.
*You might have to...
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 11:41
@CrossEye I think there's definitely good reasons to have something like over for paths. Lenses are hard to debug, and I think from a practical perspective should only be used in situations that are more complicated than could be done with simple paths
Maybe over can support either providing a path like path provides or a Lens?
I just think that whatever functions that accept lenses should also be able to accept paths if it's applicable
Scott Sauyet
@CrossEye
Mar 31 2016 11:58
Lenses aren't particularly about properties. They can represent all sorts of structures or interpretations. That said, we do have lensPath and assocPath.
Jigar Gosar
@jigargosar
Mar 31 2016 11:58
@Risto-Stevcev to be clear, i am using lens to modify a deeply nested element. (3 levels deep), I am not sure how using path will help, could you please expand, I would like to have a simpler solution.
Ok, I understood now, I can use assoc path, or disassoc path. rather than lens.
I think I will do that. Since it is much simpler to reason about.
than lens.
@CrossEye thanks.
@Risto-Stevcev thanks.
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 12:03
@CrossEye There's no equivalet to over with paths. That's what I don't like
But someone might be tempted to use Lenses over plain paths (ie ['a','b','c']) because of things like not having over for paths
Even if they only need something like plain paths
Lenses should only be used in special cases which can't be described using the language of plain paths.
Because they're not the easiest to debug
Hardy Jones
@joneshf
Mar 31 2016 12:26
@Risto-Stevcev what does this mean, "There's no equivalet to over with paths."?
How you construct a lens is largely orthogonal to how over works.
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 12:28
?
Hardy Jones
@joneshf
Mar 31 2016 12:28
I don't understand your statement.
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 12:29
Like this:
Hardy Jones
@joneshf
Mar 31 2016 12:29
And I think I'm making assumptions based on my misunderstanding
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 12:30
R.over(['a','b','c'], R.add(1), {a:{b:{c:3}}}) -> {a:{b:{c:4}}}
You have assocPath, but it just takes a value and not a function to transform the value
Hardy Jones
@joneshf
Mar 31 2016 12:32
@ram-bot
R.over(R.lensPath(['a', 'b', 'c']), R.inc, {a: {b: {c: 3}}})
ram-bot
@ram-bot
Mar 31 2016 12:32
{ a: { b: { c: 4 } } }
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 12:32
Right, except you don't want to use lenses if you don't have to
they're hard to debug
Try to print the path of a lens
Hardy Jones
@joneshf
Mar 31 2016 12:32
why would you want to print the path of a lens?
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 12:33
If you're building up paths from other paths
Somewhere in a large map that you're updating, you have path ['a','b','c'], and then somewhere in that subtree you want to modify ['d','e','f'], so you want to do something like R.over(['a','b','c','d','e','f']...)
Regardless of whether or not you want to print the path of a lens, the user shouldn't be forced to use a more complex abstraction for no particularly good reason
Anyone coming into Ramda can figure out how assocPath works pretty fast, but it would take them considerably longer to wrap their head around Lenses. Yet there's no reason why R.over shouldn't be able to support paths
Hardy Jones
@joneshf
Mar 31 2016 12:35
While i agree with your last statement, I don't agree with the path that got you there.
There's a very good reason
It's unsound
Another good one is that it would complicate the implementation tremendously.
relatively speaking
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 12:37
What?
Yeah it makes no sense
The R.over spec could remain unchanged anyway (since R.view is analagous to R.path for lenses), and just call it R.mapPath for paths
Scott Sauyet
@CrossEye
Mar 31 2016 12:47
lenses do not have to do with properties. we already have
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 12:49
@CrossEye Would you be open to introducing a way to map (like R.over) for paths without having to create Lenses?
Hardy Jones
@joneshf
Mar 31 2016 13:00
That seems more reasonable than special casing over just for paths so that debugging might become easier in some cases.
at the very least an entry to the cookbook would be nice
@ram-bot
const mapPath = R.curry((path, f, obj) =>
  R.assocPath(path, f(R.path(path, obj)), obj)
);

mapPath(['a', 'b', 'c'], R.inc, {a: {b: {c: 3}}})
ram-bot
@ram-bot
Mar 31 2016 13:01
{ a: { b: { c: 4 } } }
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 13:01
Nice
Yeah, a cookbook entry would be nice
At the very least
But I do think that a case could be made to for adding something like mapPath, because someone might be more tempted to just create Lenses and use R.over rather than make a function like the one you just made, which would introduce unnecessary complexity to what they're trying to achieve
Hardy Jones
@joneshf
Mar 31 2016 13:10
I don't know what doctoc means, but I added a recipe.
I think adding that function to a codebase introduces a different problem than adding lenses.
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 13:12
Nice
Yeah I think the recipe is probably sufficient, since it's trivial to implement. A case could be made to not overcomplicate the API with functions that are trivial to implement on their own
Hardy Jones
@joneshf
Mar 31 2016 13:14
I mean the actual user codebase, not ramdas
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 13:14
Oh
what problem would it introduce?
Denis Stoyanov
@xgrommx
Mar 31 2016 14:12
someone know about this lis but in js ? http://jwodder.freeshell.org/lambda.html
Scott Sauyet
@CrossEye
Mar 31 2016 14:34
@Risto-Stevcev, @joneshf: I for one would certainly welcome a PR to add such a function. It does seem a good companion to assocPath. @davidchambers might disagree, though.
Aldwin Vlasblom
@Avaq
Mar 31 2016 18:04
@xgrommx Benji6 writes some useful commit messages:
scrot_20160331-200356_940x594.png
Denis Stoyanov
@xgrommx
Mar 31 2016 20:14
@Avaq is it a joke?)
Stefano Vozza
@svozza
Mar 31 2016 20:51
Haha. That's brilliant.
Martin Broder
@mrtnbroder
Mar 31 2016 21:02
hey everyone
got a question regarding type notations
what would be the type notation of an object in javascript that needs to hold specific keys
e.g.:
// view : ??? -> Html
export const view = ({ dispatch, model, ...props }) => (
  <div {...props}>
    <button onClick={() => dispatch(Action.increment())}>{model}</button>
  </div>
)
or is it really just view :: Object -> Html
Michael Hurley
@buzzdecafe
Mar 31 2016 21:18

in js i think it might have to be Object -> String (unless you have some HTML type you are returning here). in OCaml, you could declare a record type, e.g.

type Html = string

type thingie = {
  dispatch : int -> int; (* idk the signature ot this function *)
  model : string;
  foo : bool;
  (* etc. *)
}

Then your function would be thingie -> Html

i suppose in js you could construct you dispatcher, e.g. var d = new Dispatcher(x) and d would have some well-defined type; then you could annotate it Dispatcher -> String (or Dispatcher -> Html)
Martin Broder
@mrtnbroder
Mar 31 2016 21:24
hmm
Martin Broder
@mrtnbroder
Mar 31 2016 21:30
I guess I have to live with Object -> String
thanks @buzzdecafe !
Scott Sauyet
@CrossEye
Mar 31 2016 21:34
You can choose to use something like that OCaml record type in your JS sigs, especially focusing only on the properties actually used by the called function.
Michael Hurley
@buzzdecafe
Mar 31 2016 21:43
what do you have in mind, @CrossEye ?
David Chambers
@davidchambers
Mar 31 2016 21:51
Presumably something like this:
//#   name :: { name :: String } -> String
const name = R.prop('name');
Michael Hurley
@buzzdecafe
Mar 31 2016 21:51
what are those double colons??? :-P
Jakub Korzeniowski
@kujon
Mar 31 2016 21:58
@mrtnbroder from what I remember, someone in this room (I think @davidchambers ) does it nicely with {foo :: String, bar :: Boolean}
Michael Hurley
@buzzdecafe
Mar 31 2016 22:01
that seems reasonable, although it isn't type notation so much as constraint notation on a pojso
but maybe as good as we can get
Martin Broder
@mrtnbroder
Mar 31 2016 22:02
wat
pojso?
Michael Hurley
@buzzdecafe
Mar 31 2016 22:02
"plain old javascript object" :wink:
Martin Broder
@mrtnbroder
Mar 31 2016 22:03
better then Object -> String :D
Michael Hurley
@buzzdecafe
Mar 31 2016 22:03
agreed, much more info
Jakub Korzeniowski
@kujon
Mar 31 2016 22:06
@buzzdecafe all type annotations are those hacky, useful little things we all do, before half of this room decides they've had enough JavaScript and move to Haskell ^^
Michael Hurley
@buzzdecafe
Mar 31 2016 22:08
@kujon if that is so even for a very small %, i think we can declare the lib a success
Martin Broder
@mrtnbroder
Mar 31 2016 22:10
very helpful btw! http://sanctuary.js.org/#types
Jakub Korzeniowski
@kujon
Mar 31 2016 22:19
@buzzdecafe immense success. It fixes JavaScript, but then you want more.
Michael Hurley
@buzzdecafe
Mar 31 2016 22:21
@davidchambers you may have to update the types section a bit.
@ram-bot R.inc('XXX')
ram-bot
@ram-bot
Mar 31 2016 22:21
'1XXX'
Michael Hurley
@buzzdecafe
Mar 31 2016 22:21
hmmm -- @ram-bot not using latest?
0.20 behavior is R.inc('XXX') //=> NaN
David Chambers
@davidchambers
Mar 31 2016 22:22
Oh, thanks for the heads-up, @buzzdecafe!
Michael Hurley
@buzzdecafe
Mar 31 2016 22:23
np, i can send you a PR if you like
David Chambers
@davidchambers
Mar 31 2016 22:23
That'd be wonderful. :)
Michael Hurley
@buzzdecafe
Mar 31 2016 22:23
prolly means gotta update R version in package.json?
Michael Hurley
@buzzdecafe
Mar 31 2016 22:24
so that's a "yes", then?
David Chambers
@davidchambers
Mar 31 2016 22:25
Indeed.
Although we also want to update the expected output of R.inc('XXX') in https://raw.githubusercontent.com/plaid/sanctuary/master/README.md.
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 22:27
I think it wouldn't be a bad idea to create a convention for type signatures
And add it to the fantasy-land or ramda specs somewhere
Michael Hurley
@buzzdecafe
Mar 31 2016 22:27
yeah @Risto-Stevcev we've made some progress in that direction but it's slow going. not exactly rewarding work...
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 22:28
That being said, I think a case can be made to provide a more descriptive type annotation for JSON objects that expect a particular signature, since it's so common in javascript
Oh, I wasn't aware of that. Where's is it hosted?
Michael Hurley
@buzzdecafe
Mar 31 2016 22:28
i'm just talking about settling on conventions for how we write sigs
not a standard doc of how we do it
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 22:29
oh
yeah, but I mean to standardize it like the fantasy land specs
Michael Hurley
@buzzdecafe
Mar 31 2016 22:29
understood. i agree that would be useful. ramda would have to be looser than FL
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 22:29
And maybe to provide a form to describe JSON objects that expect a particular signature, such as:
main :: { DOM: Observable, HTML: Observable } -> { DOM: Observable, HTML: Observable }
rather than
main :: Object -> Object
Michael Hurley
@buzzdecafe
Mar 31 2016 22:31
ok; but it might be easier reading if you could declare types
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 22:31
Well it would be impossible to enfore something like that, but having a convention helps
Michael Hurley
@buzzdecafe
Mar 31 2016 22:31
enforcement is off the table :-)
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 22:32
How would you declare the types for something like that?
Michael Hurley
@buzzdecafe
Mar 31 2016 22:32
e.g. type DomHtml = {DOM : Observable, HTML: Observable}
then
main : DomHtml -> DomHtml
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 22:34
That would be too complicated to do because libraries might return particular JSON types like that without doing that kind of signature or declaration
and also it could make a lot of code redundant
David Chambers
@davidchambers
Mar 31 2016 22:35
It is possible to enforce such types at run time. ;)
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 22:35
or maybe not
@davidchambers oh, are you talking about sanctuary-def?
yeah that's true :)
I guess that puts javascript on par with clojure then, hehe
David Chambers
@davidchambers
Mar 31 2016 22:37
Yes, I was.
Michael Hurley
@buzzdecafe
Mar 31 2016 22:38

I guess that puts javascript on par with clojure then, hehe

Only on a very strange golf course

Risto Stevcev
@Risto-Stevcev
Mar 31 2016 22:39
lol
well, I guess in terms of being dynamically typed... not the other goodies like immutability and being homoiconic
Michael Hurley
@buzzdecafe
Mar 31 2016 22:40
as @davidchambers knows, i am skeptical of run-time type-checking
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 22:40
@buzzdecafe For performance reasons? or
I've been too busy to get around to trying it out, but from what I've seen on the chat it seems like you can disable it for production environments
Michael Hurley
@buzzdecafe
Mar 31 2016 22:41
no; more frustration that many of these problems have elegant solutions available in other languages
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 22:41
Which would mean that your unit and e2e tests could run with the type checking enabled which would provide the same level of protection that clojure would give on that front
Michael Hurley
@buzzdecafe
Mar 31 2016 22:41
and that type-checking is particularly valuable statically
David Chambers
@davidchambers
Mar 31 2016 22:42
I don't follow that logic, @buzzdecafe. There are better languages, sure. But if one finds oneself writing JavaScript, why force oneself to debug undefined is not a function?
Michael Hurley
@buzzdecafe
Mar 31 2016 22:42
run-time checks will help you if your particular data fails for some reason. but a static type-checker gives you a lot more protection than that
David Chambers
@davidchambers
Mar 31 2016 22:42
Absolutely.
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 22:42
@buzzdecafe I disagree though
Static typing can also slow down progress significantly because you can't do stuff like rapid prototyping
David Chambers
@davidchambers
Mar 31 2016 22:43
But you're comparing run-time checking to compile-time checking. You should be comparing run-time checking to no checking.
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 22:43
I think a better solution which seems to be catching on is to provide a mechanism for gradual typing
Michael Hurley
@buzzdecafe
Mar 31 2016 22:43
hey! one at a time!
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 22:43
lol
Michael Hurley
@buzzdecafe
Mar 31 2016 22:44
i'm glad @davidchambers is pursuing that line. I just get frustrated by it, since i know to some extent what i am missing
and @davidchambers is right that run-time is better than nothing
@Risto-Stevcev I'm not sure you can't do rapid prototyping in a strongly typed way
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 22:46
given the domain of js, I don't think you're really missing all that much if you have 100% code coverage with your unit test and you run the dynamic type checker
There are placeholders you can use (I forgot the one for Haskell someone needs to remind me), but it's not really the same
Michael Hurley
@buzzdecafe
Mar 31 2016 22:46
or you could write in a different language and let the comiler help you
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 22:47
You need to change every piece of code that touches the code you're rapidly changing around before even compiling
Which can slow down just rapidly throwing something together to see if it's what you want even
A better option is to just allow type checking when you're ready for it, once you've settled on a solution
@buzzdecafe What do you mean?
Michael Hurley
@buzzdecafe
Mar 31 2016 22:49

if you have 100% code coverage with your unit test and you run the dynamic type checker

So I have suspenders, a belt, and duct tape, so my pants don't fall down. I'm suggesting it might be better to get pants that fit

Risto Stevcev
@Risto-Stevcev
Mar 31 2016 22:50
lol
I don't know, rocking a duct-tape belt would be pretty hipster cool :)
Michael Hurley
@buzzdecafe
Mar 31 2016 22:51
This message was deleted
:laughing:
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 22:52
Yeah, I agree it would be nice to have something a little better. But I like gradual typing more, with the option of strong static typing as your app grows and stabilizes
Michael Hurley
@buzzdecafe
Mar 31 2016 22:52
fair enough. the irony is my first language (and therefore first love) was perl ....
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 22:53
yeah, I used perl for work a couple years back. It's definitely some strange syntax, but it brought some good ideas to the mainstream
like more powerful regex
Michael Hurley
@buzzdecafe
Mar 31 2016 22:54
i still like it
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 22:56
Which isn't really a finite automata anymore (from my impression it's a pushdown automata with a 1-element or at least very small stack?). Though it's still plenty fast for almost all use cases
My teacher once met Larry Wall and thought he was really cooky
Michael Hurley
@buzzdecafe
Mar 31 2016 22:58
nice
i'm glad this is a discipline that embraces kookiness
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 22:59
Well he didn't say it like it was the good kind of cooky, but he was kind of a douche sometimes
LeonineKing1199
@LeonineKing1199
Mar 31 2016 22:59
JavaScript is typed, man. It's just duck-typed. It's what C++ wants to be with its use of Concepts
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 22:59
Yeah I agree, I like cooky smart people
LeonineKing1199
@LeonineKing1199
Mar 31 2016 23:00
In JS, if you call .length, you're really saying that you want a "length-able" type
It's, like, uber generic programming
Risto Stevcev
@Risto-Stevcev
Mar 31 2016 23:01
JS has type coercion though, which makes it significantly less safe than python which is also duck-typed
It's not obvious or intuitive how the coerced value would look like, same with what is truthy or falsy
It does end up on interview questions though, which is really beyond my understanding why employers think that's useful time spent on gauging the quality of a candidate
LeonineKing1199
@LeonineKing1199
Mar 31 2016 23:04
That's fair. Which is why you can use the natively-typed constructors (Date, Number, Boolean, etc.) which do_ throw upon an invalid type. So if you _need to co-erce type-ness, you can use a constructor and validate from that
Oh God, that came out so garbled.