These are chat archives for ramda/ramda

12th
Mar 2016
Nathan Ridley
@axefrog
Mar 12 2016 02:42
@Risto-Stevcev thanks for the reply, just saw it just now. Will take a look at those links and see what I can learn :) ( :point_up: March 11, 2016 5:09 AM)
Quick question for anyone here: though the docs describe R.length as retrieving the length of an array, the function works with strings too. Is it safe for me to use it for strings, or does it only work "accidentally" and should not be relied upon for strings (from a future proofing perspective)
Nathan Ridley
@axefrog
Mar 12 2016 03:13
Paging anyone at all, in addition to the above question, where can I find information on how to interpret this: (acc → x → (acc, y)) → acc → [x] → (acc, [y])? Ramda is a JavaScript library. I'd prefer not to have to learn Haskell in order to write JavaScript. (Though am open to learning it at some point in the future if I ever get time)
Nathan Ridley
@axefrog
Mar 12 2016 03:19
I found a some mentions (in this channel and the github issues list) referring to the alien nature of this notation and some nonchalant references to Haskell. I dunno if anyone with any authority is reading this, but if you are, please do offer some links in the documentation to help people learn and understand the notation. Assuming that only Haskell developers want to use Ramda, or that people who want to use Ramda also have time (and inclination) to learn Haskell first, seems... unreasonable. Also, the link "Introducing Ramda by Buzz de Cafe" is broken.
Scott Sauyet
@CrossEye
Mar 12 2016 03:37

@axefrog: This document isn't quite complete, but it's close:

https://github.com/ramda/ramda/wiki/Type-Signatures

The goal is to eventually make that part of the documentation pages, with a link from the top of the API page. I want to create another one for any non-native types we use in our documentation, too.

James Forbes
@JAForbes
Mar 12 2016 03:37

Also, the link "Introducing Ramda by Buzz de Cafe" is broken.

Good catch

where can I find information on how to interpret this: (acc → x → (acc, y)) → acc → [x] → (acc, [y])

On the docs you can click Expand Parameters and it will walk through the type signature.

Scott Sauyet
@CrossEye
Mar 12 2016 03:38
Hmm, we had an issue for the broken link, and I thought that had already been fixed. I'll take a look.
Nathan Ridley
@axefrog
Mar 12 2016 03:38
@JAForbes I know that that is the intention, but in practice, the correlation between the two is not always clear
Let me illustrate what I mean:

(acc → x → (acc, y)) → acc → [x] → (acc, [y])

PARAMETERS
function fn
The function to be called on every element of the input list.

  • acc
    The accumulator value.

Array list
The list to iterate over.

Returns *
The final, accumulated value.

You have there a list of parameters you're referencing, but the function signature doesn't seem to map to the descriptions. I assume you're just listing the parameters in order, but still, it's confusing.
Scott Sauyet
@CrossEye
Mar 12 2016 03:41
No, it's significantly different. The signatures talk about types, not names. Often those types are generic.
Generic types get single-letter names, such as a, b, etc.
Nathan Ridley
@axefrog
Mar 12 2016 03:42
Sure. In any case, thanks for that link. You guys should definitely make a point of putting it front and centre on the Ramda homepage; you don't want Ramda to just be the domain of elite functional programmers who already understand everything.
Sorry if I come across antagonistically... am having fun learning to build functional code, and Ramda is fantastic, but I do get frustrated when I hit documentation that appears to assume prior knowledge of other functional languages, or uses symbology that is only accessible to those with specific prior knowledge.
Anyway, back to it, keep up the good work :D
Scott Sauyet
@CrossEye
Mar 12 2016 03:46
These signatures are starting to become a standard way to describe FP Javascript. There is no consensus yet on how to cover the things not available in ML or Haskell or other places where these are used. But they are getting much more widespread.
I don't feel any hostility. I understand what it's like to be given "documentation" that explains nothing to me because it makes assumptions that aren't true for me.
The point of these sigs, though, is that once you do learn to use them, are extremely valuable. They are useful enough that we really considered forgoing the parameter table altogether. Some languages do so. It just didn't quite seem feasible for JS folks, but it was a close call.
Nathan Ridley
@axefrog
Mar 12 2016 03:47
I do think it's ok to tell a programmer to learn the notation, as long it's something that can be read up on quickly.
The point of course has simply been that there was no link or obvious explanation as to how to read the signatures.
Scott Sauyet
@CrossEye
Mar 12 2016 03:48
I will try to figure out how to get that documentation linked to the main docs page in the next few days.
Nathan Ridley
@axefrog
Mar 12 2016 03:48
cool :+1:
Scott Sauyet
@CrossEye
Mar 12 2016 03:48
I have a bit more content for it, and I still want to do the Types one, but I might as well get that underway.
Nathan Ridley
@axefrog
Mar 12 2016 03:49
hey, anything is better than nothing
Scott Sauyet
@CrossEye
Mar 12 2016 03:49
Thanks for bringing it up. I started this a while ago, but have gone heads-down on something else. That something is more interesting... but not actually more important.
Nathan Ridley
@axefrog
Mar 12 2016 03:51
no worries, thanks for responding :D
James Forbes
@JAForbes
Mar 12 2016 03:55
@axefrog I'm not sure how accurate this is, but this is my interpretation: https://tonicdev.com/jaforbes/ramda-type-signatures-and-arrow-functions
Nathan Ridley
@axefrog
Mar 12 2016 03:56
@JAForbes you wrote this just now?
James Forbes
@JAForbes
Mar 12 2016 03:56
yep
lately I've been writing short posts for stuff that comes up in gitter because it always comes up more than once
Nathan Ridley
@axefrog
Mar 12 2016 03:57
Ah, thanks, am reading it now, as well as the wiki link that @CrossEye mentioned too.
James Forbes
@JAForbes
Mar 12 2016 03:58
Again I should really say, I'm not sure how accurate that is. I'm not a Haskell guy
Nathan Ridley
@axefrog
Mar 12 2016 04:05
hmmm so (acc → x → (acc, y)) → acc → [x] → (acc, [y]) seems to say that I need to pass in a single argument that is a function. That function will be provided with the accumulator value, and it will expect me to return another function. That function will be passed a value x, and be expected to return another function, which takes two parameters; acc and y.
And I'm only describing the top-level function argument so far.
So... then the return value for this top-level function is itself a function taking an argument acc. When called, it will return a function too, and this function will take an array of type x and return a function that takes arguments acc and an array of y.
My head hurts.
Scott Sauyet
@CrossEye
Mar 12 2016 04:11
Where is that sig from? (acc → x → (acc, y)) → acc → [x] → (acc, [y])?
Oh, mapAccum?
We need to fix that one.
Nathan Ridley
@axefrog
Mar 12 2016 04:11
yeah mapAccum
Scott Sauyet
@CrossEye
Mar 12 2016 04:11
That's not following our normal conventions.
Nathan Ridley
@axefrog
Mar 12 2016 04:11
ah, k
i guess i just got unlucky :D
Scott Sauyet
@CrossEye
Mar 12 2016 04:11
acc is not a name we would use for a type.
Nathan Ridley
@axefrog
Mar 12 2016 04:12
ah, right so the sig is correct, but you'll rename the type reference
Scott Sauyet
@CrossEye
Mar 12 2016 04:12
Number, Boolean, String, etc. for known types, a, b, c most commonly for arbitrary but unknown types.
checking...
Nathan Ridley
@axefrog
Mar 12 2016 04:13
right. in that case, my head still hurts ;)
Scott Sauyet
@CrossEye
Mar 12 2016 04:15
But yes, the basic structure looks correct. We would usually write it like this: (a → b → (a, c)) → a → [b] → (a, [c])
Nathan Ridley
@axefrog
Mar 12 2016 04:16
Revisiting the documentation for that one, I guess it's a slightly more complex function than normal.
Scott Sauyet
@CrossEye
Mar 12 2016 04:17
It is, but we can probably get at it relatively quickly.
Nathan Ridley
@axefrog
Mar 12 2016 04:17
sure.
Scott Sauyet
@CrossEye
Mar 12 2016 04:17
So we have a function that takes three parameters and returns a pair ... a tuple... really implemented as a two-element array.
Nathan Ridley
@axefrog
Mar 12 2016 04:18
the first value is the aggregate and the second is a list of the intermediates involved in building the aggregate
Scott Sauyet
@CrossEye
Mar 12 2016 04:18
That return -- (a, [c]) -- contains an element of one of our given types, a, and a list of another, c.
yes.
The second parameter is simply a, a value of that aggregate type.
The third is a list of the other unknown type, b.
That leaves only the complex first one: (a → b → (a, c)).
Nathan Ridley
@axefrog
Mar 12 2016 04:21
Aaaah ok and the visitor function (append in the example) itself returns a tuple of the aggregate and the intermediate value?
Scott Sauyet
@CrossEye
Mar 12 2016 04:21
exactly.
It's a function that takes one a and one b and returns that tuple.
Nathan Ridley
@axefrog
Mar 12 2016 04:23
Hang on... so the signature, when it says it returns (acc, y), that means a tuple of acc and y? I thought it meant it returns a function with args of type acc and y
which would mean x -> (y, z) means function(a) { return [b, c]; }
Scott Sauyet
@CrossEye
Mar 12 2016 04:24
(a → b → (a, c)) wrapped in parentheses like this represents a function on its own.
This message was deleted
yes
although we usually start our type variables at a and work up from there, unless there are good reasons for exceptions. (Sometimes k and v for key and value, for instance.)
Nathan Ridley
@axefrog
Mar 12 2016 04:25
the confusion there is that in the wiki documentation, it only talks about parentheses in terms of function signatures
(i think, i haven't finished reading it properly)
Scott Sauyet
@CrossEye
Mar 12 2016 04:26
That might be one of the gaps. I think it's in the notes I haven't yet posted anywhere to add those types. I will try to get to it soon.
Nathan Ridley
@axefrog
Mar 12 2016 04:26
right
Scott Sauyet
@CrossEye
Mar 12 2016 04:27
We have a hard time because many of us are still new to this ourselves, and those who are not take many things for granted. The language difference between JS and ML/Haskell makes for a substantial difference too.
Nathan Ridley
@axefrog
Mar 12 2016 04:28
sure, it can be hard to identify what one takes for granted when trying to explain something
Scott Sauyet
@CrossEye
Mar 12 2016 04:34
Bedtime for me. But I just updated that document with some additional material. I guess I still don't have anything about tuples in there (or at least the word "tuple") so that still has to come.
But feel free to critique, add changes, questions, suggestions, whatever. Probably anything other than simple changes to the page should just go in a new issue on the site.
Nathan Ridley
@axefrog
Mar 12 2016 04:39
Cool, one last note, this page might be worth linking:
https://drboolean.gitbooks.io/mostly-adequate-guide/content/ch7.html
Scott Sauyet
@CrossEye
Mar 12 2016 04:56
There's actually a link to that in the document.
Nathan Ridley
@axefrog
Mar 12 2016 05:25
ah, my bad