ace411/bingo-functional

A simple functional programming library for PHP

bingo-functional's Issues

Property tests

Property tests are a great way to ensure function completeness - they help validate the invariants in a function's intended behavior. I currently feel that the unit tests written for this library, though accurate, are not complete. I currently envisage an adoption of property testing ideas for the library. For example:

public function testIdentityFunctionConveysInputAsOutput()
{
  $this->forAll(
    Generator\int(),
    Generator\string(),
    Generator\float(),
    Generator\bool()
  )
    ->then(function ($value) {
      $id = A\identity($value);
      
      $this->assertEquals($value, $id);
      $this->assertTrue(gettype($value) == gettype($id));
    });
}

The snippet above utilizes the Eris package to perform property tests. The result is a litany of assertions which ordinarily - constitute atomic use cases.

Improve the Pattern Matching Algorithm

Implemented in v1.9.0 along with a variety of helper functions was the patternMatch() function. It has undergone several modifications since its inception and still feels a bit incomplete. Why - one might ask? The snippet below evaluates to a wildcard pattern when it should not.

use function \Chemem\Bingo\Functional\PatternMatching\patternMatch;

$match = patternMatch(
  [
    '[_, "foo"]' => function () { return 'first-pattern'; },
    '_' => function () { return 'wildcard'; }
  ],
  explode('/', 'api/foo')
);

The snippet above is a syntactical facsimile of the Haskell code shown below which evaluates to the string, first-pattern.

patternMatch :: [a] -> a
patternMatch (_,  foo) = "first-pattern"
patternMatch _ = "wildcard"

I intend to fix the problem that is the current patternMatch function's inability to reconcile list patterns that contain wildcards in them.

Integrate the coding style tool/service

As we see, the package doesn't follow the PSR-2 coding style.
To fix this coding style issue automatically, I suggest we can use the PHP-CS-Fixer or StyleCI to complete this issue.

Replace the self-defined functions with the PHP native functions

As title. According to the Unique function, it looks like we use the foreach loop to try to get the unique array on specific array collection.

But the PHP has the native array_unique function to help us to get the unique array quickly without using the foreach loop.

I think we can use the native PHP functions easily and it will be better than using foreach loop.

Fatal error when using Nothing::flatMap

Consider the following code:

$maybe = Maybe::fromValue(null)
    ->flatMap(function () {
        return Maybe::fromValue('some value');
    })
    ->getOrElse('default');

It causes the error: PHP Fatal error: Uncaught Error: Call to a member function getOrElse() on null. Probably Nothing::flatMap should return an instance of Nothing instead of null.

Anomalous `assocPath` function behavior

The purpose of the assocPath() function is to create a shallow clone of a list with an overwritten value assigned to the index at the end of a (specified) traversable path. The current behavior is such that a call to the said function appends - to a target list - a discretionary value whose index is the first item in the specified path - in the event that the said path does not exist. Consider the example to follow.

use function Chemem\Bingo\Functional\assocPath;

$list = assocPath(['foo', 'bar'], 2, ['bar' => 2]);

var_dump($list);

The output of the snippet above - per the current constitution of the assocPath() function signature - is as follows.

array(2) {
  ["bar"]=>
  int(2)
  ["foo"]=>
  int(2)
}

The result depicted above is erroneous and invalidates the assocPath() function. The correct result is a clone of the original array - that contains a new entry: a hashtable with a single dimension that corresponds to the path 'foo' -> 'bar'. The aberrant behavior depicted in the previous snippet - upon correction - should produce output similar to that in the snippet below.

array(2) {
  ["bar"]=>
  int(2)
  ["foo"]=>
  array(1) {
    ["bar"]=>
    int(2)
  }
}

Migrating to GitHub Action

Since the Travis CI building has been very slow, I think it's time to migrate the Travis CI to GitHub Actions.

Manual autoloader

In installation section, I think the manual awesome package installation without Composer is not the proper way.
It should create the autoloader.php in project root folder so that it can be friendly with the package users 👍 . And I also prefer the psr-4 autoloader.

What do you think?

Anomalous `assocPath` function behavior

The purpose of the assocPath() function is to create a shallow clone of a list with an overwritten value assigned to the index at the end of a (specified) traversable path. The current behavior is such that a call to the said function appends - to a target list - a discretionary value whose index is the first item in the specified path - in the event that the said path does not exist. Consider the example to follow.

use function Chemem\Bingo\Functional\assocPath;

$list = assocPath(['foo', 'bar'], 2, ['bar' => 2]);

var_dump($list);

The output of the snippet above - per the current constitution of the assocPath() function signature - is as follows.

array(2) {
  ["bar"]=>
  int(2)
  ["foo"]=>
  int(2)
}

The result depicted above is erroneous and invalidates the assocPath() function. The correct result is a clone of the original array - that contains a new entry: a hashtable with a single dimension that corresponds to the path 'foo' -> 'bar'. The aberrant behavior depicted in the previous snippet - upon correction - should produce output similar to that in the snippet below.

array(2) {
  ["bar"]=>
  int(2)
  ["foo"]=>
  array(1) {
    ["bar"]=>
    int(2)
  }
}

Optimize Any function

It looks like the \Chemem\Bingo\Functional\Algorithms\any function filters the collection at first and then applies the predicate. Can you think of any reason why we can't remove the filter and return the result immediately when the predicate returns true?
For example: https://github.com/DusanKasan/Knapsack/blob/7189f5bfc9acca1bca07eeff242743c61ddda1ff/src/collection_functions.php#L579

Shouldn't IO::bind be lazy?

Consider the following code:

use Chemem\Bingo\Functional\Functors\Monads\IO;

$io = IO::of(function () {
    echo 'LOG 1', PHP_EOL;
})
->bind(function () {
    return IO::of(function () {
        echo 'LOG 2', PHP_EOL;
    });
});

It prints LOG 1 even $io->exec() is not called.

Anomalous `assocPath` function behavior

The purpose of the assocPath() function is to create a shallow clone of a list with an overwritten value assigned to the index at the end of a (specified) traversable path. The current behavior is such that a call to the said function appends - to a target list - a discretionary value whose index is the first item in the specified path - in the event that the said path does not exist. Consider the example to follow.

use function Chemem\Bingo\Functional\assocPath;

$list = assocPath(['foo', 'bar'], 2, ['bar' => 2]);

var_dump($list);

The output of the snippet above - per the current constitution of the assocPath() function signature - is as follows.

array(2) {
  ["bar"]=>
  int(2)
  ["foo"]=>
  int(2)
}

The result depicted above is erroneous and invalidates the assocPath() function. The correct result is a clone of the original array - that contains a new entry: a hashtable with a single dimension that corresponds to the path 'foo' -> 'bar'. The aberrant behavior depicted in the previous snippet - upon correction - should produce output similar to that in the snippet below.

array(2) {
  ["bar"]=>
  int(2)
  ["foo"]=>
  array(1) {
    ["bar"]=>
    int(2)
  }
}

Compact function purges TRUE from an array.

The description of the Compact function says that it purges an array of falsey values (null, false). It means that true should stay in the array, right? Though, that test will fail:

$mixed = [1, 2, 'foo', false, null, true];
$purged = A\compact($mixed);
$this->assertEquals([1, 2, 'foo', true], $purged);

It seems that either the function description is incorrect or the function does not function properly.

getJust method in Nothing class is strange

Consider the following code snippet:

public function getJust()
{
}

It looks strange because this method does nothing after using that.

I think it should return null because it's the Nothing class 👍.

Just::ap should pass a callable to the Monadic::map method

Take a look at this line

bingo-functional/src/Functors/Maybe/Just.php

Line 85 in 4ce0f4d

return $app->map($this);

At present it passes $this but the Monadic::map method requires a callable.

getOrElse method in Nothing class is strange

Consider the following code snippet:

public function getOrElse($default)
{
        return $this;
}

I don't know the type of $default and pass the correct variable to this method.

And the getter method should not require any argument I think.

Maybe this method should be changed into:

public function getOrElse(Maybe $maybe)
{
        return $this->orElse(Maybe $maybe);
}

@ace411 , what do you think?

PHP 8+ compatibility

The dependency functional-php/pattern-matching (which looks unmaintained) is using match, which is a reserved word in PHP 8.0 since it now has a built-in pattern matching. That breaks library's compatibility with newer PHP versions, which should be warned in readme while the problem is being addressed.

Recursion vs Loop structures

I have implemented recursive functions in the structures of multiple helper functions map, filter, and fold inclusive. I recently ran some tests to ascertain the potency of said implementations and the results - higher memory usage for large data sets even with trampoline optimization - triggered a contemplation of the perks of PHP loops. I ran some more tests centered around the usage of foreach loops and discovered a performance increment for large datasets.

My current dilemma is this: I am not willing to revert to PHP loops but want to find a way to justify the recursion implemented in the library.