These are chat archives for ramda/ramda

25th
Sep 2015
Jethro Larson
@jethrolarson
Sep 25 2015 00:33 UTC
I was just thinking about transducers and I think you can apply conceivably apply them to any monoid
Scott Christopher
@scott-christopher
Sep 25 2015 01:19 UTC
@jethrolarson That's an interesting article
I'm confused a little by this though:
type Transducer a b = forall r. (a -> Endo r) -> (b -> Endo r)
type MonoidalTransducer a b = forall m. Monoid m => (a -> m) -> (b -> m)

psi :: MonoidalTransducer a b -> Transducer a b
psi h = h
I would've expected it to be able to go from Transducer a b to MonoidalTransducer a b
Because the forall m is covariant, the type can only become more general.
... unless I'm confusing covariance and contravariance
Scott Christopher
@scott-christopher
Sep 25 2015 01:38 UTC
¯_(ツ)_/¯
Hardy Jones
@joneshf
Sep 25 2015 02:02 UTC
Can't you?
foo f g x = appEndo (f (Endo . const . g) x) mempty
I mean, it typechecks
Might not do the right thing...
Scott Sauyet
@CrossEye
Sep 25 2015 02:44 UTC
Now there's a Haskell guy for you! :smile: "It must work -- it typechecks!"
Scott Christopher
@scott-christopher
Sep 25 2015 02:44 UTC
I admittedly tried my expectation above, saw that it failed to type check and then moved on... :D
Scott Sauyet
@CrossEye
Sep 25 2015 02:49 UTC
That sounds eminently reasonable, even to those of us used to less powerful type systems. But the other way, typechecking implying that it must work, is ... let's say a bit esoteric to me.
Hardy Jones
@joneshf
Sep 25 2015 03:01 UTC
Maybe I wasn't clear. I've no clue what that actually does.
I just plumbed the functions together for about 10-15 minutes
and the compiler stopped calling me an idiot :)
Scott Christopher
@scott-christopher
Sep 25 2015 03:02 UTC
I was happy with being reminded by the compiler that I am an idiot.
Scott Sauyet
@CrossEye
Sep 25 2015 03:02 UTC
Understood. And in Haskell, that really often is the biggest step towards working software. It just sounds quite funny when stated that baldly.
Raine Virta
@raine
Sep 25 2015 11:26 UTC
is there any particular reason why name property ramda functions don't expose the name in name property or just hasn't felt useful?
Scott Sauyet
@CrossEye
Sep 25 2015 12:14 UTC
Is this suppose to be a tongue-twister? :smile:
not following
Raine Virta
@raine
Sep 25 2015 12:17 UTC
oops
> R.map.name
'f2'
Martin Algesten
@algesten
Sep 25 2015 12:21 UTC
I researched that a couple of years back. to get it to work reliably you really had to do function declaration like function map() not var map = function(). and that would be impossible with currying. but perhaps that's changed? can you perhaps assign the name prop now?
Scott Sauyet
@CrossEye
Sep 25 2015 12:21 UTC
Not intentional. A PR our discussion issue writings be welcome.
Martin Algesten
@algesten
Sep 25 2015 12:23 UTC
impossible is a strong word. perhaps unwieldy.
Raine Virta
@raine
Sep 25 2015 12:28 UTC
var map = function map() as well
Scott Sauyet
@CrossEye
Sep 25 2015 12:49 UTC
But that gets lost to var map = curry(function map() { ... })
Raine Virta
@raine
Sep 25 2015 12:51 UTC
not unless curry reports it forward somehow
but yeah, this is in the nice-to-have category probably
Scott Sauyet
@CrossEye
Sep 25 2015 12:52 UTC
But it would be nice.
Ludwig Magnusson
@TheLudd
Sep 25 2015 13:18 UTC

The mozilla docs are super clear on this:

You cannot change the name of a function, this property is read-only

And a little further down:

To change it, you could use Object.defineProperty() though.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/name

I did some experimentation but did not succeed http://bit.ly/1NYqxsv
Denis Stoyanov
@xgrommx
Sep 25 2015 13:50 UTC
Vladimir Starkov
@iamstarkov
Sep 25 2015 14:02 UTC
hello
I want to use some side-effect free function to extend object with another one, like Object.assign https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Object/assign
I found "merge", but seems it doing it some another way. http://ramdajs.com/0.17/docs/#merge
Raine Virta
@raine
Sep 25 2015 14:04 UTC
extending an object is inherently side-effect-ing
I mean if you want to retain the reference to the object
merge is what you're looking for if you want a new object as a result
Vladimir Starkov
@iamstarkov
Sep 25 2015 14:05 UTC
its acceptable to get new object merged from to passed
yes
if object contain functions, then result object will also have them?
Raine Virta
@raine
Sep 25 2015 14:07 UTC
it should
Dave Keen
@ccapndave
Sep 25 2015 14:42 UTC
I'm a bit confused as to why this pipeline doesn't return anything http://bit.ly/1QCWc03
Ah, I've just figure it out
filter wants to work on an array. What should I use if I want to filter values out of an object?
pickBy
:)
Scott Sauyet
@CrossEye
Sep 25 2015 14:45 UTC
Glad we could help. :smile:
Dave Keen
@ccapndave
Sep 25 2015 14:45 UTC
Good work everyone
Ludwig Magnusson
@TheLudd
Sep 25 2015 15:08 UTC
If I have function f and argument x, do I apply f to x or x to f? What is the proper terminology?
David Chambers
@davidchambers
Sep 25 2015 15:09 UTC
Apply f to x.
Ludwig Magnusson
@TheLudd
Sep 25 2015 15:09 UTC
Sounds backwards to me but I beleive you =)
Raine Virta
@raine
Sep 25 2015 15:09 UTC
@TheLudd I've had trouble with that as well
must stem from fn.apply and "calling function with arguments"
Dave Keen
@ccapndave
Sep 25 2015 15:12 UTC
I think it comes out of maths - you apply a function to a value in order to transform it
Martin Algesten
@algesten
Sep 25 2015 15:14 UTC

which probably also explains why coffeescript vs haskell interprets this differently:

h = f g x

if you think that you apply f to g and then that to x, it's haskell. however as a programmer those functions looks like things we put values into. so x goes into g that in turn goes into f. coffeescript way.

Ludwig Magnusson
@TheLudd
Sep 25 2015 15:16 UTC
ok. but h = f(g(x)) would be the same for both right?
Martin Algesten
@algesten
Sep 25 2015 15:16 UTC
i assume so.
for coffee it certainly is the same.
thinking about it. i actually just started using the f g x style quite a lot. wonder if that's a bad habit given how un-mathematical it is.
Jethro Larson
@jethrolarson
Sep 25 2015 17:50 UTC
@iamstarkov Object.assign({}, toExtend, extendWith)
lazy es6 merge implementation could be
const merge = (a, b) =>  Object.assign({}, a, b)
@scott-christopher Unfortunately I'm of little help, my haskell-fu is white belt at best.
Which makes it hard to study this stuff!
Denis Stoyanov
@xgrommx
Sep 25 2015 17:57 UTC
why not const merge = (a, b) => ({...a, ...b}) ?
Raine Virta
@raine
Sep 25 2015 17:58 UTC
I had no idea ...a worked with objects
Denis Stoyanov
@xgrommx
Sep 25 2015 18:00 UTC
@raine this is ES7 maybe
Raine Virta
@raine
Sep 25 2015 18:01 UTC
I don't now if I like that syntax, for arrays the splat makes sense, but it's not immediately obvious what it would do on objects
Denis Stoyanov
@xgrommx
Sep 25 2015 18:02 UTC
@raine with babel to work fine
const merge = (a, b) => ({...a, ...b});

let a = {x: 10, y: 20};
let b = {x: 30, y: 40, z: 50};

console.log(merge(a, b)) // => {"x":30,"y":40,"z":50}
Scott Sauyet
@CrossEye
Sep 25 2015 18:05 UTC
I think I could hey used to that, but it's certainly not immediately obvious.
Raine Virta
@raine
Sep 25 2015 18:07 UTC
@xgrommx not for me, which flags did you use?
Denis Stoyanov
@xgrommx
Sep 25 2015 18:11 UTC
@raine in .babelrc use stage: 0
Raine Virta
@raine
Sep 25 2015 18:12 UTC
got it,
$ babel-node --stage 0
> const obj = { a: 1, b: 2, c: 3 };
> { ...obj }
{ a: 1, b: 2, c: 3 }
yeah I could get used to that
Jethro Larson
@jethrolarson
Sep 25 2015 18:14 UTC
I program at perl at work so it's pretty familiar
Denis Stoyanov
@xgrommx
Sep 25 2015 18:14 UTC
@raine Also this approach work with arrays
Raine Virta
@raine
Sep 25 2015 18:14 UTC
@xgrommx I'm more used to ...list yep
Scott Sauyet
@CrossEye
Sep 25 2015 18:15 UTC
It seems more familiar for arrays, though.
Denis Stoyanov
@xgrommx
Sep 25 2015 18:15 UTC
but probably you should use stage: 2 https://github.com/sebmarkbage/ecmascript-rest-spread
Scott Sauyet
@CrossEye
Sep 25 2015 18:16 UTC
@algesten: since fibrosis composition is associative, I think f g x is perfectly clear.
Damn auto correct
Martin Algesten
@algesten
Sep 25 2015 18:16 UTC
that made no sense :D
Scott Sauyet
@CrossEye
Sep 25 2015 18:16 UTC
Functional cimposition
Martin Algesten
@algesten
Sep 25 2015 18:17 UTC
aha!! xD
Scott Sauyet
@CrossEye
Sep 25 2015 18:17 UTC
damn
Jethro Larson
@jethrolarson
Sep 25 2015 18:17 UTC
I was about to google to see if it was a thing
Scott Sauyet
@CrossEye
Sep 25 2015 18:17 UTC
Please don't. I don't want to know. :smile:
Jethro Larson
@jethrolarson
Sep 25 2015 18:18 UTC
FP Fibrosis
Scott Sauyet
@CrossEye
Sep 25 2015 18:18 UTC
I don't know why gitter sometimes keys me edit for a few minutes and other times doesn't. Very frustrating.
Martin Algesten
@algesten
Sep 25 2015 18:18 UTC
ok. well. fibrosis composition doesn't come out of the box in javascript. so f g x could really never do what we think it would do, right? that's why we have R.pipe
or R.compose rather
Jethro Larson
@jethrolarson
Sep 25 2015 18:19 UTC
Form of tendonitis that is unique to pipe-dreaming academics
Scott Sauyet
@CrossEye
Sep 25 2015 18:19 UTC
Like it.
babel-node --optional es7.objectRestSpread also should working
Martin Algesten
@algesten
Sep 25 2015 18:24 UTC
thinking about it. coffee doesn't solve h = f g where f and g are functions. so the whole h = f g x is a bit of a syntactic hack that looks a bit like the real deal, but can only do half of it (application).
Jethro Larson
@jethrolarson
Sep 25 2015 18:27 UTC
h = f g x
is
coffeescript:
var h = f(g(x))
livescript:
var h = f(g, x)
Martin Algesten
@algesten
Sep 25 2015 18:30 UTC
ok. that solves a thing where coffeescript is a bit bad for relying a lot on curried functions. quite often i write map(f) as because map f as is something entirely different.
Jethro Larson
@jethrolarson
Sep 25 2015 18:30 UTC
I've abandoned coffeescript for es6. It's been good
Martin Algesten
@algesten
Sep 25 2015 18:31 UTC
if only es6 ensured everything returned something. that's the last bit i love with coffeescript.
Jethro Larson
@jethrolarson
Sep 25 2015 18:31 UTC
CS returns some weird stuff though
Martin Algesten
@algesten
Sep 25 2015 18:32 UTC
nah. it's ok :)
Scott Sauyet
@CrossEye
Sep 25 2015 18:32 UTC
I simply never went there. It always looked almost but not quite right to me. But ES6 - yes!
Raine Virta
@raine
Sep 25 2015 18:34 UTC
@algesten why not livescript?
Jethro Larson
@jethrolarson
Sep 25 2015 18:36 UTC
LiveScript looks cool, I think I prefer to use a superset of js to write js though
Martin Algesten
@algesten
Sep 25 2015 18:37 UTC
we invested quite heavy in coffee at
work two years ago
Jethro Larson
@jethrolarson
Sep 25 2015 18:37 UTC
The syntax of CS was nicer but there's a translation step that is smaller with ES6. LiveScript has the same issue
Martin Algesten
@algesten
Sep 25 2015 18:37 UTC
both front end code and backend is coffee
so even if I jump ship to es6, we still have a ton of front end that will need translation.
and now everyone else at work are sort of settling in with significant white space. so curly brackets feels like a step back.
Raine Virta
@raine
Sep 25 2015 18:40 UTC
writing LiveScript with ramda is a very pleasant experience
too bad the future of the language doesn't seem that bright from development point of view
Martin Algesten
@algesten
Sep 25 2015 18:44 UTC
coffee totally revolutionized our work. people were getting totally bored with Java and c#. one of the main architects expressed it as "the best thing since elisp"
and he's a die hard emacs fan
Jethro Larson
@jethrolarson
Sep 25 2015 18:46 UTC
Coffee really is just js with syntax improvements and some macros. I guess there really are some Good Parts ;)
Martin Algesten
@algesten
Sep 25 2015 18:52 UTC
indeed there is. also having One environment front to back is very good. we added elasticsearch/rabbitmq and got untranslated json from database to browser. so refreshing considering how much time i spent with crap like getting data in/out of databases/soap/rest/and and. the coffee translating we solve by using things like brunch as front end build tool. with source maps you hardly ever think about it.
Jethro Larson
@jethrolarson
Sep 25 2015 19:03 UTC
@raine You try using prelude.ls?
Raine Virta
@raine
Sep 25 2015 19:04 UTC
no but I looked at it, and it doesn't provide anything over ramda
similar principles though
curried, data-last functions
Jethro Larson
@jethrolarson
Sep 25 2015 19:05 UTC
Obv it's the standard lib of LS, figured it'd be more idiomatic
Raine Virta
@raine
Sep 25 2015 19:07 UTC
perhaps in the sense it might be that it doesn't provide functions for things that are simple to do with LS features
but i haven't looked closely
joneshf-work1
@joneshf-work1
Sep 25 2015 21:06 UTC
livescript requires quite a bit of discipline to not let it turn into a pile of mush.