by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Joshua Derocher
@thebedivere
Crocks also has a lot of functions that are similar to Ramda.
Michał Chruściel
@majkelch
Thanks @thebedivere
David Chambers
@davidchambers
Thank you, @thebedivere. I appreciate your summary.
Joshua Derocher
@thebedivere
You're both welcome! I love both libraries and use both for different projects :)
David Chambers
@davidchambers
:heart:
David
@DavidBernal
Hi folks, are there any good vscode formatter to work with sanctuary?
David Chambers
@davidchambers
I'm not aware of one, @DavidBernal.
Diego Ceresuela
@dicearr
Hi :wave: Is there an easy way to go from [Either a b] to Either [a] [b]? I've tried S.sequence (S.Either) but it gives me Either a [b].
Diego Ceresuela
@dicearr
And I am not really happy with this approach:
const collect = eithers => {
  const errors = S.lefts (eithers);
  const values = S.rights (eithers);
  return errors.length > 0 ? S.Left (errors) : S.Right (values);
}
Diego Ceresuela
@dicearr
I also noticed that S.sequence (Array) (S.Left ([1, 2, 3])) returns [S.Left ([1, 2, 3])]. I didn't expect that :) I guess I will need to create my own weird sequencing function or think about a different approach.
David Chambers
@davidchambers
@silly-goat
//    partition :: Array (Either a b) -> Either (Array a) (Array b)
const partition =
S.reduce (S.either (ls => S.either (l => S.Left (S.append (l) (ls)))
                                   (r => S.Left (ls)))
                   (rs => S.either (l => S.Left (S.append (l) ([])))
                                   (r => S.Right (S.append (r) (rs)))))
         (S.Right ([]));

//    testCases :: Array (Array (Either String Number))
const testCases = [
  [],
  [S.Left ('xxx'), S.Left ('xxx')],
  [S.Right (1), S.Right (2), S.Right (3)],
  [S.Right (1), S.Left ('xxx'), S.Right (2), S.Left ('xxx'), S.Right (3)],
];

S.map (partition) (testCases);
silly-goat
@silly-goat
[Right ([]), Left (["xxx", "xxx"]), Right ([1, 2, 3]), Left (["xxx", "xxx"])]
David Chambers
@davidchambers
:point_up: How is this, @dicearr?
Michał Chruściel
@majkelch
M.A.G.I.C ;)
Vladimir Kapustin
@kapooostin
Hi, folks. Is it a correct way to unwrap an Either: Either.value? Or should I always use either()()()?
David Chambers
@davidchambers
Are you working with Either a a, @kapooostin?
If so, either (I) (I) (e) is the way to go (although e.value also works).
Vladimir Kapustin
@kapooostin
Do you mean, whether I have both Left and Right values of the same type? No. I wanted to check value in test, but now I realise I should just wrap in Right a value I assert against. Am I right?
David Chambers
@davidchambers
Ah, you want to assert that the result of some computation is Right (42), say?
I like to do this in my test suite:
eq (<expr>) (S.Right (42));
Vladimir Kapustin
@kapooostin
Yes. I refactor existing code to use Eithers and Futures, and the old test compares the result to an object. So the first move was to get value from an Either
David Chambers
@davidchambers
I define eq like so:
const eq = actual => expected => {
  assert.strictEqual (show (actual), show (expected));
  assert.strictEqual (Z.equals (actual, expected), true);
};
Vladimir Kapustin
@kapooostin
Why do you need the first assertion? To confirm that the types are the same?
David Chambers
@davidchambers
The reason I use two assertions is that comparing string representations produces useful assertion errors.
Vladimir Kapustin
@kapooostin
Ah
David Chambers
@davidchambers
Otherwise all one sees is false !== true.
Vladimir Kapustin
@kapooostin
Sanctuary-testing-library :)
David Chambers
@davidchambers
Yep!
Here's sample output:
> assert.strictEqual (S.show (S.Left ('xxx')), S.show (S.Right (42)))
Thrown:
AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:
+ actual - expected

+ 'Left ("xxx")'
- 'Right (42)'
Fernando Canteruccio
@naripok
Hey guys, how are you today?
Hey, I have a question:
Where is the bind operator?
Do you guys just flip the chain arguments, or implement it using map and join?
Is there a reason for the absence of (>>=)?
David Chambers
@davidchambers
@silly-goat
S.chain
silly-goat
@silly-goat
chain :: Chain m => (a -> m b) -> m a -> m b
Fernando Canteruccio
@naripok
but bind type is:
bind :: m a -> (a -> m b) -> m b
right?
do you just flips the application order?
David Chambers
@davidchambers
The argument order of S.chain is convenient because one often wants to fix the (a -> m b) and let the m a flow through at run-time.
In Haskell the order does not matter so much because both (m >>=) and (>>= f) are possible.
Have you encountered a situation in which you have wanted a flipped version of S.chain, @naripok?
Fernando Canteruccio
@naripok
thx for the response, dude!
I'm working through the rational of using chain.
Yesterday I was working on a transformation where I was thinking about the flowing values on my maybe monad.
I'm trying to translate my purescript pratice into sanctuary and still working through the details.
I guess chain is more convenient because of the S.compose syntax, right?
David Chambers
@davidchambers
That's right.
You might be interested in solving this challenge, @naripok.
Fernando Canteruccio
@naripok
something like this: S.compose (chain (\b -> mc)) (chain (\a -> mb)) (ma)

You might be interested in solving this challenge, @naripok.

hey, I ll take a look! thx!

David Chambers
@davidchambers
This is also a common pattern:
const asdf = S.pipe ([
  ...,
  S.chain (...),
  S.chain (...),
  S.map (...),
  S.chain (...),
]);
Fernando Canteruccio
@naripok
man, I was composing S.composes..... S.compose ((S.compose (S.compose () ()) ()) ()

This is also a common pattern:

const asdf = S.pipe ([
  ...,
  S.chain (...),
  S.chain (...),
  S.map (...),
  S.chain (...),
]);

that is much better.... lol

clearly I have much to learn kkkkkkk
David Chambers
@davidchambers
With your PureScript background you will know the concepts. :)
Fernando Canteruccio
@naripok
yea... that and Bartosz Milewski...
by the way, thx for bringing us these marvelous abstractions to js.
it makes so much easier to understand something when you can use it daily and even be paid for doing it... hahaha
David Chambers
@davidchambers
Thanks. I agree. :)