These are chat archives for ramda/ramda

19th
May 2015
Simon Friis Vindum
@paldepind
May 19 2015 05:45
@scott-christopher Yes. You are right! I don't know what I was thinking.
Scott Christopher
@scott-christopher
May 19 2015 05:56
Have you had any luck with the recursive types, like your Tree example?
Simon Friis Vindum
@paldepind
May 19 2015 06:21

I have not tried implementing it yet. But my current idea is that it should look something like this:

var Tree = Type.constructor((Tree, a) => {Empty: [], Leaf: [a, Tree(a), Tree(a)]}));

So Type.constructor defines a type constructor from a function that returns a type. The functions first argument is a representation of the type being defined and any additional parameters are types for the type constructor. This is however not so pretty if you're not creating a recursive definition since you will receive the self constructor anyway. So maybe using a special object is better:

var Tree = Type.constructor((a) => {Empty: [], Leaf: [a, Type.Self(a), Type.Self(a)]}));
Scott Christopher
@scott-christopher
May 19 2015 06:49
Yeah, I have been thinking about this on and off today, and I thought Type could be overloaded to either accept a function that can be used to pass type variables, or an object like it currently does.
I’ve got a few ideas around this that I might try to find some time for this weekend to play with.
Simon Friis Vindum
@paldepind
May 19 2015 07:36
Overloading is not a bad idea. I might actually be more elegant and readable. Ideally I'd love to take this further than only union types. But I'm running into some gaps in my knowledge regarding some of the issues pointed out by @joneshf. I'm only somewhat familiar with Haskells type system and union types as they are in Elm.

One could of course create a type constructor like this:

var Maybe = (a) = > Type({Just: [a], Nothing: []});

But then the type constructor is nothing but a plain function and you have not way to write a function over Maybe a.

Maciej Filipiak
@suside
May 19 2015 08:53

Hello
is there a way to use R.pick with nested objects? Something like:

var x = {
  a: 1,
  b: {
    c: 2
  }
}
R.pick(['a', 'b.c'], x);

?

Simon Friis Vindum
@paldepind
May 19 2015 09:36
@suside This is my best suggestion:
R.compose(R.evolve({b: R.pick(['c'])}),
          R.pick(['a', 'b'])(x);
Maciej Filipiak
@suside
May 19 2015 10:44
@paldepind Thanks!
Maciej Filipiak
@suside
May 19 2015 10:59
However my pick list is dynamic so it will be hard to use compose like that.
Anyways my current approach is simple R.pick + npmjs.com/package/flat
Raine Virta
@raine
May 19 2015 11:01
R.path might help
Maciej Filipiak
@suside
May 19 2015 11:10
@raine Thanks!
Hardy Jones
@joneshf
May 19 2015 11:12

@paldepind i'm not really sure I understand the purpose of the function. Is it just so that you can later make your polymorphic type monomorphic?

While it seems like a good idea to be able to constrain things like this (and sometimes it is necessary), what has been found is that things end up too restricted for this to make sense--at least in haskell. I don't have an example off-hand, but you can do similar things with existentially quantified type variables, but what usually ends up happening is that you'd have a better situation if you didn't do that in the first place.

What usually works better is if you have a fully polymorphic data type, and just constrain the functions that operate on the data.

as i mentioned, I don't really understand what you want to accomplish. So, I might have gone in the wrong direction.
Simon Friis Vindum
@paldepind
May 19 2015 12:28

@joneshf I want type constructors. Like type constructors in Haskell:

data Maybe a = Nothing | Just a

Here Maybe is not a type, but a type constructor. A function that takes one or more types and returns a new type. And then ideally there should both be a way to define polymorphic functions that works on any type constructed by Maybe and functions that only works on concrete types created by Maybe. Does that makes sense?

Hardy Jones
@joneshf
May 19 2015 13:04
But you can't have that in js. There are no types to speak of. All you can have are the right hand sides, i.e. values and value constructors. So you can't really differentiate between the two things you want because one of them doesn't exist.
Also, I think we've sort of walked away from ramda discussion at this point...I dunno if it's good manners to continue this discussion here or not.
I'm sure someone can suggest a nicer way to write this?
["foo:bar","meh:bleh"] -> {"foo":"bar", "meh": "bleh"}
Hardy Jones
@joneshf
May 19 2015 16:07
R.pipe(R.map(R.split(':')), R.fromPairs)
Raine Virta
@raine
May 19 2015 16:07
joneshf beat me to it
Tobias Pflug
@gilligan
May 19 2015 16:12
perfect - thank you guys :)
Chad Adams
@chadams
May 19 2015 18:22
can this be shortened and more elegant?
    const layouts = R.reduce((acc, val)=>{
      if(!R.contains(val.layout, acc)){
        acc.push(val.layout);
      }
      return acc;
    }, [], storyScenes);
Chad Adams
@chadams
May 19 2015 18:31
actually this works...
const getLayouts = R.compose(R.pluck('layout'), R.uniq);
Scott Sauyet
@CrossEye
May 19 2015 19:49
@joneshf: I think this is a fine place for such discussions. Even if they're at most tangentially related to Ramda, if they have to do with FP in JS I think they're well within bounds.
Hardy Jones
@joneshf
May 19 2015 19:49
cool!
Raine Virta
@raine
May 19 2015 20:02
does pluck have the correct signature? String → {*} → [*]
Hardy Jones
@joneshf
May 19 2015 20:18
doesn't look like it
isn't it just pipe(prop, map)?
Raine Virta
@raine
May 19 2015 20:20
yep
Michael Hurley
@buzzdecafe
May 19 2015 21:29

I think this is a fine place for such discussions.

totally agree

Stefano Vozza
@svozza
May 19 2015 21:30
I'm just a lurker here but I find these discussions fascinating, not many places online where you can see people hashing this sort of stuff out.
David Chambers
@davidchambers
May 19 2015 21:31
Yep! The best thing about Ramda is the wonderful community that has grown around it. I appreciate these discussions. I’m hoping to increase my intelligence via osmosis. :)
Michael Hurley
@buzzdecafe
May 19 2015 21:34
btw @joneshf i started looking at that paper on object algebras. then i realized it's 25 pages and got discouraged.
Hardy Jones
@joneshf
May 19 2015 22:04
heh
Michael Hurley
@buzzdecafe
May 19 2015 22:06
will try to soldier on
Brandon Wilhite
@JediMindtrick
May 19 2015 23:17
I'm coming to a better understanding of FP beyond the various ways we can manipulate functions....i.e. how do we deal with data. So I'm glad for the discussions as well.