Switch to functional combinators #3

shadowhand · 2017-05-31T15:41:55Z

Replace Combinators static class with functions.

Refs #1

i-am-tom · 2017-05-31T15:57:59Z

What's the reasoning behind dropping the external lib?

shadowhand · 2017-05-31T16:25:03Z

@i-am-tom so that users have a curry implementation without using a dependency of a dependency. Cypress curry also introduces a number of additional functions into the root Cypress\Curry namespace that are not meant to be used directly.

shadowhand · 2017-05-31T17:08:26Z

Edit: I've updated the PR with an invokable implementation of curry.

Now, that being said... Cypress' version offers right curry, which I haven't tried to implement. The approach taken by yuyat/curry might be superior in this regard (the curry'd callable is a class with __invoke) because it would allow for eg Curry\Constructor\Left and Right. My example in updated README would be well served by having a right curry:

$concat = curry_exactly(3, function ($a, $b, $join = '') {
    return $a . $join . $b;
});

assert('a:b' === $concat('a', 'b', ':'));

I'd love to be able to do something like this:

$concat = curry_right(function ($a, $b, $join) { ... }, ':');

assert('a:b', $concat('a', 'b'));

Having an immutable `Curry` class allows creating a curry from any callable. Having this as a base class will allow additional functionality such as `Partial` to be added with minimal effort.

i-am-tom

Sorry for the long wait! I've left a few comments; nothing too earth-shattering. My main thought is still with curry - I'm very nervous about adding another curry implementation. It just seems more in-the-spirit to contribute to another curry implementation with anything that we feel is lacking from this one, y'know?

i-am-tom · 2017-06-13T06:55:37Z

README.md

+});
+
+// The following statements are all equivalent:
+assert(6 === $add(1, 2, 3));


I think this was mentioned elsewhere, but $add should be $sum

i-am-tom · 2017-06-13T06:56:54Z

README.md

 ```

 Note that the functions are called **from left to right**. If the opposite is desired, this can be achieved easily:

 ```php
-<?php


The reason for keeping these was that GitHub syntax highlighting didn't activate without them :(

its the

```PHP

bit that does the syntax hilighting not the open PHP tag. See this example.

i-am-tom · 2017-06-13T06:58:30Z

src/functions.php

+/**
+ * compose :: (b -> c), (a -> b) -> a -> c
+ */
+function compose(callable $f, callable $g): callable


~~Are these functions curried?~~ Ignore me - just saw the tests

i-am-tom · 2017-06-13T06:59:35Z

src/functions.php

+/**
+ * k :: a -> b ->  a
+ */
+function k($x): callable


I think, if this is being called K, I'd rather it stayed capitalised - it's a nod to the K combinator, which only makes sense if capitalised!

Maybe we should just name it 𝐊 and really confuse people. 😉 Just trying to keep PSR-2 consistency here, function names are lower_snake_case.

Tohmua · 2017-06-13T19:34:27Z

src/Curry.php

@@ -0,0 +1,77 @@
+<?php
+declare(strict_types=1);


Unfortunately this does nothing. It only affects the type checking of functions you call in this file not their declarations.

Strict typing applies to function calls made from within the file with strict typing enabled, not to the functions declared within that file. If a file without strict typing enabled makes a call to a function that was defined in a file with strict typing, the caller's preference (weak typing) will be respected, and the value will be coerced.

Source

You could however declare this on your test files where you actually make the calls and it would then have the desired affect.

It does more than that, including forcing return type checks.

But as per the note, it only makes a difference if set in the file calling the methods.

E.g.

// foo.php <?php declare(strict_types=1); class A { public function test(int $a): int { return $a; } public function test2(int $a): int { return $this->test($a); } }

// bar.php <?php require_once __DIR__ . '/foo.php'; $a = new A(); echo $a->test2('1'); // (int) 1

if you take the declare(strict_types=1); out of the foo.php file it still returns (int) 1

Ah ignore me, that was a terrible test that missed the whole point because '1' was being type juggled on the way in. :)

Tohmua · 2017-06-13T19:36:06Z

src/functions.php

@@ -0,0 +1,79 @@
+<?php
+declare(strict_types=1);


Tohmua · 2017-06-13T19:53:02Z

src/functions.php

+ */
+function compose(callable $f, callable $g): callable
+{
+    return static function ($x) use ($f, $g) {


I am not sure why this is declared static it does not impact the function.

For example:

function test($a, $b) { return function($c) use ($a, $b) { return sprintf("a: %s; b: %s; c: %s", $a, $b, $c); }; } echo test(1, 2)(3); // a: 1; b: 2; c: 3 echo test(4, 5)(3); // a: 4; b: 5; c: 3

and

function test($a, $b) { return static function($c) use ($a, $b) { return sprintf("a: %d; b: %d; c: %d", $a, $b, $c); }; } echo test(1, 2)(3); // a: 1; b: 2; c: 3 echo test(4, 5)(3); // a: 4; b: 5; c: 3

do the same thing?

In the above example you could make any of the variables $a, $b or $c static however you would then be introducing state into your functions which goes against all the principles of FP.

Or am I missing something?

In this situation, static does nothing, you are correct.

Tohmua · 2017-06-13T20:08:47Z

src/functions.php

+        return $f($g($x));
+    };
+}
+define('compose', '\PhpFp\compose');


Are these define's needed? They work, however the code looks a lot more confusing and the use function statements are a lot neater.

E.g.

namespace Foo\Bar{ function a() { return 'A'; } define('a', '\Foo\Bar\a'); } namespace Foo\Bass{ echo a; // \Foo\Bar\a echo a(); // Uncaught Error: Call to undefined function Foo\Bass\a() echo (a)(); // A use function Foo\Bar\a; echo a(); // A }

Or is there a good use case for these I have missed?

I removed them in #4.

If PR #4 is a latter version of this PR can we close this one to avoid confusion?

@Tohmua probably not a bad idea. I split them to make it clear what the steps involved were.

shadowhand · 2017-07-07T22:44:57Z

I'll leave this open for someone else to finish. We're not going to pursue using php-fp at this point.

shadowhand changed the title ~~Add curry() function~~ Switch to functional constructors May 31, 2017

shadowhand mentioned this pull request May 31, 2017

Curry all combinators #4

Open

shadowhand changed the title ~~Switch to functional constructors~~ Switch to functional combinators Jun 1, 2017

shadowhand added 10 commits June 1, 2017 09:13

Add curry() function

e21a95d

Having an immutable `Curry` class allows creating a curry from any callable. Having this as a base class will allow additional functionality such as `Partial` to be added with minimal effort.

Switch to internal curry() function

7a0fcb3

Add a changelog

9d94745

Add k() function

01b6e47

Add compose() function

e0a5ff1

Add flip() function

aae02b2

Add id() function

b25527a

Add if_else() function

a8c7c22

Add on() function

b0d8019

Remove combinators class

b70cbfe

shadowhand mentioned this pull request Jun 3, 2017

Release needs to be tagged #8

Open

i-am-tom reviewed Jun 13, 2017

View reviewed changes

Tohmua suggested changes Jun 13, 2017

View reviewed changes

Switch to functional combinators #3

Are you sure you want to change the base?

Switch to functional combinators #3

Uh oh!

Conversation

shadowhand commented May 31, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

i-am-tom commented May 31, 2017

Uh oh!

shadowhand commented May 31, 2017

Uh oh!

shadowhand commented May 31, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

i-am-tom left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shadowhand commented Jul 7, 2017

Uh oh!

Uh oh!

shadowhand commented May 31, 2017 •

edited

Loading

shadowhand commented May 31, 2017 •

edited

Loading