fantasy land: add Fantasy Land functions #216

davidchambers · 2016-05-11T11:31:07Z

Closes #178; closes #252

This pull request adds the following functions:

alt :: Alt f => f a -> f a -> f a
ap :: Apply f => f (a -> b) -> f a -> f b (ap replaces S)
apFirst :: Apply f => f a -> f b -> f a
apSecond :: Apply f => f a -> f b -> f b
bimap :: Bifunctor f => (a -> b) -> (c -> d) -> f a c -> f b d
chain :: Chain m => (a -> m b) -> m a -> m b
chainRec :: ChainRec m => TypeRep m -> (a -> Either (m b) (m b)) -> a -> m b
empty :: Monoid a => TypeRep a -> a
equals :: Setoid a => a -> a -> Boolean
extend :: Extend w => (w a -> b) -> w a -> w b
extract :: Comonad w => w a -> a
filter :: (Applicative f, Foldable f, Monoid (f a)) => (a -> Boolean) -> f a -> f a
filterM :: (Monad m, Monoid (m a)) => (a -> Boolean) -> m a -> m a
join :: Chain m => m (m a) -> m a
map :: Functor f => (a -> b) -> f a -> f b (map replaces B and lift)
of :: Applicative f => TypeRep f -> a -> f a
promap :: Profunctor p => (a -> b) -> (c -> d) -> p b c -> p a d
sequence :: (Applicative f, Traversable t) => TypeRep f -> t (f a) -> f (t a)
toString :: Any -> String
traverse :: (Applicative f, Traversable t) => TypeRep f -> (a -> f b) -> t a -> f (t b)
zero :: Plus f => TypeRep f -> f a

Original description:

sanctuary-js/sanctuary-type-classes#2 hasn't yet generated the excitement I expected, so I thought I'd open a pull request to add all the Fantasy Land functions except equals and of while removing code.

🌈

svozza · 2016-05-11T18:13:43Z

Ah so this is where old map functions go to die. ;) Looks great. I wasn't sure how to handle those test failures in S.match either, I presume it's because of the weird object/array that you get back from using the native regex function in JS?

svozza · 2016-05-11T18:18:02Z

index.js

  }

-}(function(R, $) {
+}(function(R, λ, $) {


What's the quickest way to type this symbol without having to resort to copy and paste?

I'm not sure. I placed it in the l register in Vim so I was able to type " l p to insert it.

We should probably switch to an identifier that's easier to type. _, perhaps? I like one-character identifiers for dependencies we reference dozens of times. :)

L for lambda?

Yeah, L sounds good.

davidchambers · 2016-05-11T18:39:13Z

I wasn't sure how to handle those test failures in S.match either, I presume it's because of the weird object/array that you get back from using the native regex function in JS?

The problem actually lies with optional non-capturing groups. Since there's no type of which both 'foo' and undefined are members, ['foo', undefined] is heterogeneous and therefore considered invalid.

S.map(S.I, /(foo)?(bar)?/.exec('foobar'));
// => ['foobar', 'foo', 'bar']

S.map(S.I, /(foo)?(bar)?/.exec('foo'));
// ! TypeError: Type-variable constraint violation
//
//   map :: (Functor a, Functor b) => Function -> a -> b
//                                                ^
//                                                1
//
//   1)  ["foo", "foo", undefined, "index": 0, "input": "foo"] :: Array ???
//
//   Since there is no type of which all the above values are members, the type-variable constraint has been violated.

The problematic expression is map(toMaybe, match). The solution is to replace this with a for loop (match.map(toMaybe) wouldn't work since toMaybe would complain about receiving three arguments).
The fact that we must work around the type system when bringing inconsistent values into the consistent world doesn't worry me – in fact, it's a sign that the type system is doing its job. :)

svozza · 2016-05-11T20:30:32Z

The fact that we must work around the type system when bringing inconsistent values into the consistent world doesn't worry me – in fact, it's a sign that the type system is doing its job. :)

I agree completely, it's better to deal with these sort of oddities in the safety of a function's scope rather than having them leak out, even if it's at the cost of the implementation's elegance.

svozza · 2017-01-16T22:26:09Z

index.js

+  //. > S.bimap(S.toUpper, Math.sqrt, S.Right(64))
+  //. Right(8)
+  //. ```
+  S.bimap =


Does that mean we don't need S.either anymore?

@svozza S.either is for unpacking an Either a b, it returns the return value of the mapper. S.bimap returns a new Either of the value returned by the mapper.

Oh yes, of course, either is similar to fromMaybe.

Indeed, although it's most similar to maybe and maybe_:

maybe :: b -> (a -> b) -> Maybe a -> b maybe_ :: (() -> b) -> (a -> b) -> Maybe a -> b either :: (a -> c) -> (b -> c) -> Either a b -> c

fromMaybe and fromEither are also closely related:

fromMaybe :: a -> Maybe a -> a fromEither :: b -> Either a b -> b

safareli

Laws looks good, but chainRec signature is not correct.

safareli · 2017-01-18T15:09:55Z

index.js

+  //. > S.equals(S.Just([1, 2, 3]), S.Just(['1', '2', '3']))
+  //. false
+  //. ```
+  S.equals = def('equals', {}, [a, b, $.Boolean], Z.equals);


Returns true if its arguments are of the same type and equal according to the type's fantasy-land/equals method; false otherwise.

Shouldn't it be (Setoid a) => a -> a -> Boolean instead of a -> b -> Boolean ?

That depends on whether we think S.equals('foo', 42) should evaluate to false or throw a type error. I'm in favour of the former, since the latter would make S.equals cumbersome to use in test suites. What do you think?

Returning false is more practical indeed. What if we add equalsStrict or something which has a -> a -> bool and throws type error? but it could be done in other PR, after we are we really want it, personally I think it would be good, as it will prevent some type errors in programs.

I see value in providing a second function. We might want to name it something bland like equals_, though, to avoid confusion with strict (===) equality.

nice ⚡️

I've added equals_ :: Setoid a => a -> a -> Boolean. I'm now wondering whether equals and equals_ should be switched. The _ suffix is used elsewhere in the library as a subtle warning to users, and I believe we should discourage users from comparing values of different types. Do you agree?

I think in "your" codebase where you know types of values, you will only use equals when two values have same type, as if you know that one value has different type then the other, it's useless to use equals as it will return false for every value of those types.

But one might use equals in library like code, when someone outside of the library could pass some value of any type. But for cases like this one could just use S.unchecked.equals.

So after writing/thinking on it i think equals:: a -> a -> Boolean would be nice if one could also do this S.unchecked.equals to access unchecked version of equals

So after writing/thinking on it i think equals:: a -> a -> Boolean would be nice if one could also do this S.unchecked.equals to access unchecked version of equals

Great idea! Using the checkTypes switch to avoid having two versions of the same function is very elegant. I've pushed a commit to replace S.equals with the stricter variant.

In #262 Aldwin and I have been talking about bringing back S.unchecked, which would allow S.unchecked.equals as you suggest.

safareli · 2017-01-18T15:18:30Z

index.js

+  //. Nothing
+  //. ```
+  S.zero =
+  def('zero', {f: [Z.Plus]}, [TypeRep($.TypeVariable('f')), f(a)], Z.zero);


why is it needed to have TypeRep($.TypeVariable('f')) instead of TypeRep(f)?

f :: Type -> Type is not a member of sanctuary-def's internal Type type. Should it be? I don't know. For now, at least, we need to provide a value of type Type.

not sure, just looked strange

safareli · 2017-01-18T15:28:04Z

index.js

+  //. Nothing
+  //. ```
+  function traverse(typeRep, f, traversable) {
+    function pure(x) { return Z.of(typeRep, x); }


I think this part (and sequence) should be updated once sanctuary-js/sanctuary-type-classes#28 is merged

safareli · 2017-01-18T15:45:22Z

index.js

+  //. ```
+  S.join = def('join', {m: [Z.Chain]}, [m(m(a)), m(a)], Z.join);
+
+  //# chainRec :: ChainRec m => TypeRep m -> (a -> Either (m b) (m b)) -> a -> m b


Full implementation of chainRec (I think it should be correct, but isn't tested)

def('chainRec', {m: [Z.ChainRec]}, [TypeRep($.TypeVariable('m')), Fn(a, m($Either(a, b))), a, m(b)], // :: ChainRec m => TypeRep m -> (a -> m (Either a b)) -> a -> m b function chainRec(typeRep, f, x) { // :: (a -> c, b -> c) -> Either a b -> c function mapper(next, done) { // :: Either a b -> c return function mapper$inner(either) { return either.fold(next, done) } } // :: (a -> c, b -> c, a) -> m c function step(next, done, x) { // :: m Either a b var mEither = f(x) // :: Either a b -> c var g = mapper(next,done) return Z.map(g, mEither) } return Z.chainRec(typeRep, step, x) }) )

Also Would be nice to note in comments, which part of Either represent Done and which Loop.

safareli · 2017-01-18T15:49:15Z

index.js

+  //. ```
+  S.filter =
+  def('filter',
+      {f: [Z.Applicative, Z.Foldable, Z.Monoid]},


(f a) should be a Monoid not f, (same for Monoid (m a) in filterM), but looks like there is no other way right?

This is a limitation of sanctuary-def. I'd love to work out how to properly capture this constraint.

safareli · 2017-01-18T16:22:57Z

test/internal/Compose.js

    };

    ComposeFG.prototype[FL.ap] = function(other) {
-      return ComposeFG(Z.ap(Z.map(function(u) { return function(y) { return Z.ap(u, y); }; }, other.value), this.value));
+      return ComposeFG(Z.ap(Z.map(S.ap, other.value), this.value));


Is the reason to mix Z and S the fact that Z has uncurried functions?

That's right. Perhaps it would be better to use our internal ap function instead (in both cases). What do you think?

I think that would a good approach, as when we move this laws in a separate module, we might not want it to be depend on sanctuary, because it has curried functions .

safareli · 2017-01-18T16:27:20Z

test/sequence.js

+  eq(typeof S.sequence, 'function');
+  eq(S.sequence.length, 2);
+  eq(S.sequence.toString(), 'sequence :: (Applicative f, Traversable t) => TypeRep f -> t (f b) -> f (t b)');
+


safareli · 2017-01-18T16:27:26Z

test/promap.js

+  eq(typeof S.promap, 'function');
+  eq(S.promap.length, 3);
+  eq(S.promap.toString(), 'promap :: Profunctor p => (a -> b) -> (c -> d) -> p b c -> p a d');
+


safareli · 2017-01-18T16:27:30Z

test/of.js

+  eq(typeof S.of, 'function');
+  eq(S.of.length, 2);
+  eq(S.of.toString(), 'of :: Applicative f => TypeRep f -> a -> f a');
+


safareli · 2017-01-18T16:28:25Z

test/join.js

+  eq(S.join([[[1, 2, 3]]]), [[1, 2, 3]]);
+  eq(S.join(S.Just(S.Just(1))), S.Just(1));
+  eq(S.join(S.Just(S.Just(S.Just(1)))), S.Just(S.Just(1)));
+


maybe also add failing case?

+ eq(S.join(S.Nothing)), S.Nothing);

safareli

As chainRec is fixed, this LGTM. only adding of some tests is left which is not a big issue ✌️

davidchambers · 2017-02-04T15:10:12Z

index.js

+  //. [[1, 2, 3]]
+  //.
+  //. > S.join(S.concat)('abc')
+  //. 'abcabc'


Yesterday when I asked about \x -> f x x @brendanhay told me that join is the W combinator! Very cool! See Stack Overflow if you're interested in the substitutions which show that S.join(f) is equivalent to x => f(x)(x).

I was just looking at it. Quite something. So we have:

map = B ap = S join = W

I'll add them to my table. ;)

Avaq · 2017-02-05T17:39:10Z

index.js

+  //.     Function a (b -> c) -> Function a b -> Function a c
+  //.     (a -> b -> c) -> (a -> b) -> (a -> c)
+  //.
+  //. This is the S combinator from combinatory logic.


Maybe move the conclusion above the explanation, so a reader knows why he's reading it, and may choose beforehand to skim over it.

Good idea. "This" in the sentence above refers to (a -> b -> c) -> (a -> b) -> (a -> c) rather than to ap, which is more general. We could, though, combine this sentence with the sentence preceding the substitutions:

Replacing Apply f => f with Function x produces the S combinator from combinatory logic:

Avaq · 2017-02-05T17:40:52Z

index.js

+  //.     (b -> c) -> Function a b -> Function a c
+  //.     (b -> c) -> (a -> b) -> (a -> c)
+  //.
+  //. [`compose`](#compose) is thus a specialized form of `map`.


Same remark as with ap

Avaq · 2017-02-05T17:41:17Z

index.js

+  //.     Function a (Function a b) -> Function a b
+  //.     (a -> a -> b) -> (a -> b)
+  //.
+  //. This is the W combinator from combinatory logic.


Same remark as with ap.

rjmk · 2017-02-12T17:32:29Z

test/chainRec.js

+                      : map(S.Left)(function(env) { return n + env.step; });
+  }
+
+  eq(S.chainRec(Function, stepper, 0)({step: 2, inc: 100}), 3100);


If I'm correct that this test is as much to examine stack behaviour as output, perhaps that warrants a comment?

Good idea.

⚡

Avaq

I'm really excited about this!

rjmk · 2017-02-12T17:41:06Z

test/alt.js

@@ -0,0 +1,28 @@
+'use strict';


It strikes me that it would be nice to test these typeclass functions on as minimal a case as possible i.e. the FreeFoo.

Certainly out of scope for this PR, and I'm not sure where you get your functors from, but what do you think about it in principle?

Are you suggesting defining a type which provides only the methods and/or TypeRep functions necessary to satisfy the requirements of the type class?

Pretty much. I was thinking we could use the free structures (free monoids, applicatives, monads ...). You do need a base functor for those, though, and I'm not sure whether the natural choice (Identity) actually gives you much assurance.

rjmk · 2017-02-12T17:45:36Z

index.js

+  //.
+  //.     Chain m => m (m a) -> m a
+  //.     Function x (Function x a) -> Function x a
+  //.     Function x (Function x b) -> Function x b


I don't know how much the variable renaming helps understanding here

Are you suggesting this instead?

Chain m => m (m a) -> m a Function x (Function x a) -> Function x a (x -> x -> a) -> (x -> a)

I'm happy to make this change.

Are you suggesting removing the alpha-renaming from the map and ap documentation as well, or were you commenting on join specifically?

I find the alpha-renaming useful for map and ap as I find the signatures more recognizable when the conventional identifiers are used. Also, it's a good idea to perform alpha-renaming one variable at a time if one is reusing identifiers. Otherwise variables may appear to move, which is not the correct interpretation.

Only chain really stuck out to me, but perhaps it's better to be consistent

Consistency led me to the longer version, but I like your shorter version. When there are only two type variables I'm happy to deal with x and a. :)

rjmk

Awesome!

davidchambers · 2017-02-12T20:50:15Z

🦄

davidchambers mentioned this pull request May 11, 2016

Add S.map function #142

Closed

svozza reviewed May 11, 2016
View reviewed changes

davidchambers mentioned this pull request May 16, 2016

sanctuary-def@0.6.x #217

Merged

davidchambers force-pushed the dc-fantasy-land branch 3 times, most recently from 61547af to 10f9831 Compare May 18, 2016 01:36

davidchambers force-pushed the dc-fantasy-land branch 2 times, most recently from 32436ce to 1f11c7d Compare July 4, 2016 07:19

davidchambers force-pushed the dc-fantasy-land branch 2 times, most recently from ce4f395 to 082d153 Compare September 14, 2016 02:12

This was referenced Sep 14, 2016

v0.12.0 checklist #255

Closed

Type Safe Ramda Functions #145

Closed

davidchambers mentioned this pull request Sep 23, 2016

Fantasy Land method aliases #257

Closed

davidchambers force-pushed the dc-fantasy-land branch from b051ce7 to c465bdd Compare September 23, 2016 16:30

This was referenced Sep 24, 2016

expand documentation of type signatures and fix inconsistencies #259

Merged

provide a placeholder value sanctuary-js/sanctuary-def#82

Merged

davidchambers force-pushed the dc-fantasy-land branch from 2fc09c2 to 0a67de9 Compare September 28, 2016 11:42

davidchambers mentioned this pull request Oct 1, 2016

ADTs defined using S functions are compatible only with types known to S #262

Closed

davidchambers force-pushed the dc-fantasy-land branch from 7246268 to 16c093a Compare October 2, 2016 13:49

davidchambers mentioned this pull request Oct 5, 2016

apis not reasonable fantasyland/fantasy-land#181

Closed

davidchambers force-pushed the dc-fantasy-land branch 7 times, most recently from a0d31c9 to 2b807c0 Compare October 17, 2016 07:31

davidchambers force-pushed the dc-fantasy-land branch from 67d160b to 22d2f66 Compare January 14, 2017 06:41

svozza reviewed Jan 16, 2017

View reviewed changes

safareli suggested changes Jan 18, 2017

View reviewed changes

davidchambers force-pushed the dc-fantasy-land branch 2 times, most recently from 46a83e5 to 1488ac7 Compare January 21, 2017 15:13

safareli approved these changes Jan 21, 2017

View reviewed changes

davidchambers force-pushed the dc-fantasy-land branch from 0223cc4 to 80c0696 Compare February 4, 2017 14:13

davidchambers commented Feb 4, 2017

View reviewed changes

Avaq mentioned this pull request Feb 4, 2017

Remove extraneous combinators #330

Merged

3 tasks

davidchambers force-pushed the dc-fantasy-land branch from 15bcb69 to eca1ece Compare February 5, 2017 13:23

Avaq reviewed Feb 5, 2017

View reviewed changes

davidchambers force-pushed the dc-fantasy-land branch 2 times, most recently from ca13bf2 to 982f175 Compare February 12, 2017 16:36

rjmk reviewed Feb 12, 2017

View reviewed changes

Avaq approved these changes Feb 12, 2017

View reviewed changes

rjmk reviewed Feb 12, 2017

View reviewed changes

rjmk approved these changes Feb 12, 2017

View reviewed changes

davidchambers force-pushed the dc-fantasy-land branch 3 times, most recently from 2c5feff to 18792e1 Compare February 12, 2017 20:05

fantasy land: add Fantasy Land functions

7e54645

davidchambers force-pushed the dc-fantasy-land branch from 18792e1 to 7e54645 Compare February 12, 2017 20:44

davidchambers merged commit 7656d0f into master Feb 12, 2017

davidchambers deleted the dc-fantasy-land branch February 12, 2017 20:50

davidchambers mentioned this pull request Feb 13, 2017

v0.12.0 release notes #332

Closed

davidchambers mentioned this pull request Apr 3, 2017

maybe, either: fix "fantasy-land/traverse" descriptions #372

Merged

fantasy land: add Fantasy Land functions #216

fantasy land: add Fantasy Land functions #216

Conversation

davidchambers commented May 11, 2016 • edited Loading

svozza commented May 11, 2016

svozza May 11, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

davidchambers commented May 11, 2016

svozza commented May 11, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

safareli left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

safareli Jan 21, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

safareli left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Avaq Feb 4, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Avaq left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rjmk Feb 12, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rjmk left a comment

Choose a reason for hiding this comment

davidchambers commented Feb 12, 2017

davidchambers commented May 11, 2016 •

edited

Loading

svozza May 11, 2016 •

edited

Loading

svozza commented May 11, 2016 •

edited

Loading

safareli left a comment •

edited

Loading

safareli Jan 21, 2017 •

edited

Loading

Avaq Feb 4, 2017 •

edited

Loading

rjmk Feb 12, 2017 •

edited

Loading