view release on metacpan or  search on metacpan

docs/design.md  view on Meta::CPAN

<small><sup>1</sup> But this is mainly done just because it's
(currently) faster, and since currently Perl does not offer
first-class continuations.  Avoiding loop syntax and using function
calls everwhere makes it possible to suspend and resume execution
arbitrarily in a language like Scheme, without mutation getting in the
way; but this doesn't apply to current Perl 5.</small>

### Try to limit dependencies if sensible.

E.g. avoiding the use of `Sub::Call::Tail`, `Method::Signatures`,
`MooseX::MultiMethods` or `autobox` in the core modules. (Some tests,
[examples](../examples/README.md) and [Htmlgen](../htmlgen/README.md)
use them.) Declaring dependencies in `FunctionalPerl::Dependencies` so
that tests can skip modules with such dependencies.

### Generally provide functionality both as functions and methods.

*NOTE: since this was written, the method call based style has become
 the primary way to provide functionality, and function based access
 is spotty now. TODO: rewrite this section. BTW, providing functions
 would be good but provide generic wrappers (which also work for

docs/design.md  view on Meta::CPAN

whether to continue providing functions, perhaps reduce the offer to
those strictly needed and otherwise request the user to build them on
the fly using `the_method`? Or figure out a way to generate them for
whole packages easily. The second reason other than the need to use
`the_method` is that the functions can take arguments in the same
order as traditional functional programming languages (the object does
not need to come first, and with multiple objects it can be unclear
which to use as the one to dispatch on).

Idea: use `Class::Multimethods` or `Class::Multimethods::Pure` or
`MooseX::MultiMethods` to provide multimethods as alternative to
methods; this would allow to retain the traditional argument positions
and still use short names. (Perhaps look at Clojure as an example?)

### Use of `*foo` vs `\&foo`

Both of these work for passing a subroutine as a value, with the
following differences:

The code reference (`\&foo`):

docs/ideas.md  view on Meta::CPAN

  application of the fix point combinator, like:
  
        my rec ($foo,$bar) =
            sub { $bar->() },
            sub { $foo->() };

* change `FP::Struct` into a Moose extension? Is Moose ok to have as a
  hard dependency? (Because why are there all these Moose alternatives
  like `Moo`?)

  Are `MooseX::Locked`, `MooseX::MultiMethods` good?

  What about the nice-and-simple predicate approach? Extend that to
  make multimethod dispatch still fast? Would that then (really?) be
  the same as `Moose::Util::TypeConstraints`? 

* add functional vector implementation with good computational
  complexity (see paper from which Clojure implemented theirs),
  perhaps base FP::PureArray on it, implement functional hashmap on
  it, implement set with it. (There are implementations on JavaScript
  too, already. Are there any in C?)