Introduce autocurring and function composition about functional-php HOT 16 CLOSED

Hi Piotr,

thanks for a lot of interesting suggestions. I will try to untangle the issues and address them separately and also lay out the plans I have with functional PHP for PHP >= 5.6.

New primitives

Introducing new primitives for pipe() and compose() makes a lot of sense to me. A separate pull request for those primitives would make sense.

Partial function application aka currying

Introducing partial application is something I’ve been thinking about for a long time. For now I tended to to use react/partial. I am more and more leaning towards proxying to react/partial and exposing aliases for it.

Automatic PFA

Automatic partial application is an interesting idea although I would rather see it in PHP itself (which is not gonna happen for good reason). I am not sure if it is worth to only have it in the library. What are your thoughts here?

Changing the function signatures

Changing the function signatures to take the function first and the collection second something we cannot do without preserving BC. It makes sense for partial function application and could be done in a backwards compatible way.

Plans for functional PHP in the post 5.6 ecosystem

As it becomes harder and harder to maintain the C extension and the benefits are not that obvious I am thinking of deprecating the C extension and embracing the new variadic argument features available in PHP 5.6.

The other feature Functional PHP profits from is use function in PHP 5.6 which makes code more readable. I plan on having a conversion script for that.

Going forward

I would propose to start working on separate pull requests addressing issue per issue. Sounds good?

from functional-php.

I think all those changes together would give a really big step forward, but each change in isolation is not as valuable as together. Of course, we must start from somewhere.

Automatic PFA, in my opinion, is a "killer" feature. Those all changes was suggested only to make possible to introduce it. That would be fantastic to see auto PFA in php as native feature, but I think this is not possible in the nearest (few years) future, especially php is very far to call it a functional language. I think the problem could be a performance, I have done some simple benchmarks that compares rfp to functional php and there is two times difference (of course in favour of functional php).

I didn't tought only about compose and pipe function when I was talking about new primitives. There are few primitives that would be very useful when auto PFA will be available - for example the simplest: multiply, add and other arithmetic operations, converge, prop, eq (and other predicates) and more. unary function would be useful right now (even without auto pfa), because it allows us to use native php function to be used as mapping function in map without using Closure, for example count.

Yes, changing the function signatures will be a BC-break but I think this is inevitable, so eventual new release with that changes should be major release (for example 2.0 etc). Second idea is to create completely new library that uses functional php in the backend and applies those changes in similar way as rfp does - but I'm not sure the next library for functional programming is necessary.

Branch features/pfa is welcome ;)

from functional-php.

Primitives: I am very open for more primitives if they help and are easily explainable to a new user of the library.

On auto PFA: as I said, I am not ruling it out, I just would prefer something else. As this will be the last feature to add anyway we do not need to rush on how it would behave. Could you address my point about the island nature of the the auto PFA?

BC Break: with type detection we should be able to make it work in a compatible way.

from functional-php.

BC Break: parameters reordering is reliable only in auto PFA context, so maybe the better way to mantain BC is to use placeholder feature of reactphp/partial library? placeholder would be used as first argument of function ($collection argument), so reordering would be unnecessary. Type detection does not sound good for me, this would be error prone.

auto PFA: I'm not sure do I understand you correctly (my English is far to be perfect ;)) . Your idea is to make auto PFA generic mechanism abstracted from functional php and make it for example external lib? There is reactphp/partial already, so I'm not sure there is a sense to do that.

from functional-php.

1+ for PFA

from functional-php.

@psliwa using the placeholder feature makes tons of sense, let’s do it!

On auto PFA: I am still undecided, although I like it. The reason for that is, that Functional PHP would be the only library behaving like this (although I like the behavior very much) but it’s still a thing you need to tell people a rule like this: "you know, PHP functions will complain when you don't pass all the arguments, except in Functional PHP, there it will return an automatically PFA’d function". That’s what I am struggling with.

Nevertheless, let’s start implementing the suggestions with auto PFA last and we can decide on the go.

from functional-php.

I thought over PFA in functional php again and maybe the better solution will be to keep pure functional php functions unchanged, but add auto PFA'd versions under, for example, Functional\AutoPFA namespace?

The advantages of this soulution would be:

• no BC-breaks
• parameters order in Functional\AutoPFA namespace could be changed, so no magic (placeholders from react/partial or arguments type detection)
• separation between functions implementation and PFA mechanism, easier testing. In Functional\AutoPFA would be only PFA logic.
• pure functions without auto PFA would have to still exist, so it could exist in Functional namespace

Sample implementation is available in commit: psliwa@6f4dc72 - what do you think about this?

from functional-php.

A very good idea to use that as some kind of playground. Once the API is settled one can still think of moving it. A few comments:

• Parameter checking should not be lazy
• We probably need a better namespace thanAutoPFA
• How much does it impact performance or how slow is the autocurrying implementation?

from functional-php.

* Parameter checking should not be lazy

Yes, that would be great. But I have not idea how to apply parameter checking in autocurry level function. Maybe some array of constraints for arguments as fourth argument?

* How much does it impact performance or how slow is the autocurrying implementation?

I tested autocurried map function vs pure map function on php 5.3 using that code:

$square = function($a){
    return $a*$a;
};

$squareMap = \Functional\AutoPFA\map($square);

$numbers = range(0, 1000);

$start = microtime(true);
$result = $squareMap($numbers);
var_dump(microtime(true) - $start);

$start = microtime(true);
$result = \Functional\map($numbers, $square);
var_dump(microtime(true) - $start);

And autocurried function was about 35%-40% slower. This difference is from 2 x call_user_func_array calls and ~5 times arguments coping overhead. I will test that on newer php version - I think the difference should be smaller.

from functional-php.

Parameter validation: having a constraints map could be indeed an option, let’s try that.
Performance: 35%-40% is quite something for primitive operations but let’s try with PHP 5.6

from functional-php.

Ok, non-lazy parameter validation is implemented: psliwa@e9f9c83.

For php 5.4 and 5.5 the difference in performance is about 10-15%

from functional-php.

As i understand pipe() and compose() is still not merged?

from functional-php.

Yes, is still not merged. I'm preparing PR with pipe, composer and auto PFA - so be patient ;)

from functional-php.

Ok, it will be great.

from functional-php.

Some very interesting thoughts here. I was inspired by Ramda.js (as I believe @psliwa also was) and have been working on a similar library for PHP where automatic currying is the main feature: Phamda. Currently most of the core functionality is implemented, but for example parameter validation is missing.

Only supporting PHP 5.6 simplifies things a lot. Besides getting rid of all the call_user_func*s, variadic functions and argument unpacking can also be really helpful. Automatic currying can still be slow, especially with placeholder arguments and small data sets.

from functional-php.

Closing for now

from functional-php.