view release on metacpan or  search on metacpan

docs/TODO.md  view on Meta::CPAN

  the success case as well?

* Consistently use "{ package Foo; ... }" or "package Foo { ... }"
  (latter if compatible with the minimal required Perl version)

* Rename `is_null` to `is_empty`? I'm torn. `null` to `empty`?

* Should I or should I not move modules that implement functions to
  `FP::Lib::` or something? They are still about a type; but
  `FP::Array` may break it (will want to use `FP::Array` as the class,
  hence `FP::Lib::Array` for the functions?)

* Rename `FP::Struct` to `FP::Define::Struct`?

* Make generic functions (for sequences) that work with both objects
  (which implement the method of the same name) and non-objects that
  are of the same kind; e.g. `first([3, 4])` and `first(list 3, 4)`
  would both return `3`. (Will conflict in the case of `map` with the
  built-in, though.) -- May not be useful enough any more given that
  there's now `FP::autobox`.

* Immutable and mutable blessed strings?

* Currently `purearray(3,4)->cons(2)->map(\&inc)` is broken. Figure out
  which way to go, perhaps implement `FP::Vec` first? How does Clojure
  handle it again?

* In `t/pod_snippets`, remove entries from the ignore list and fix
  their pod snippets. Also, now that pod snippets can be tested
  directly, remove duplicates of tests e.g. in `t/fp-struct` (and in
  general move tests to POD?)
  
* Systematically go through the docs and update it. Use/make something
  like POD snippets for markdown and change the docs to use examples
  and then automatically check that they are up to date.

* Make the remaining pure datastructures immutable, unless requested
  by user (using similar approach like taken in `FP::List`),
  e.g. StrictList; and them to `FP::Abstract::Pure`.
  
* Change `FP::Struct` to allow mutable private fields that don't
  impede `FP::Abstract::Pure` (see comments in FP::Struct)?

* Consistently `use Scalar::Util qw(reftype)`? What was the point
  again of using this over `ref` or `UNIVERSAL::isa` for `CODE` and
  such?

* die vs. croak: die is nice since `FP::Repl::Trap` will go to the real
  location, how is the situation with croak? (Also, `Chj::Backtrace`?)
  In `FP::Repl`, skip call frames within `Carp` and similar like
  `FP::Repl::WithRepl` (maybe the same way calling code from `Carp`, or
  perhaps `Trace::Mask`)?

* Would it be possible to write either an XS module that allows to
  cancel an ongoing `die` from within a `$SIG{__DIE__}` handler, or
  one that allows to set up another hook for die (in all relevant
  cases like `die ..`, `1/0`, `use warnings FATAL => ..`).

* Idea: set slots to an object that reads like "value optimized away"
  (perhaps an object of class `FP::_ValueOptimizedAway_`) instead of
  to undef when letting go of values (OK, `weaken` uses undef of
  course; but possibly weaken won't be necessary anymore once lexical
  analysis exists and the interpreter can handle deletions at the call
  site)

* Add a `boolean_eq` function?

* Show: handle cycles; pretty printing. Also, add an auto-forcing
  dynamic parameter and print immediately instead of building a string
  (have `show` just capture that)?

* Be consistent with exceptions, `array_drop [4], 3` should probably
  give one.

* Add tests (or move existing ones over?) across all sequences
  (i.e. add test suites for protocols)

* Rename FP::Abstract:: to FP::Protocol:: (and then probably also
  `FP::Interface` to `FP::Protocol`)? (Pro: "implement a protocol" or
  "using the foo protocol" sounds better than "implement an abstract
  class" or "following the foo abstract class"; con: protocol can be
  mistaken as a wire protocol. "Mixin" isn't the proper term
  especially since this term seems to be understood to not add to
  @ISA; "interface" means just the call interface (no method
  definitions in the interface), with no base functionality that is
  required to work.)

* Get `Sub::Call::Tail` working again, or replace it with something
  new (really just an OP tree transformation)?

* Get a prototype for lexical analysis (for automating the letting go
  of stream heads) in Scheme and produce Perl code to do the
  same. Then see how to implement it in the Perl interpreter (enabled
  with pragma).

* Implement a recursive let syntax, `my rec`?

* Implement a range abstraction/data type. Implement sequence
  protocol.

* Sequence optimization:
  `$foo->prep->map(..)->filter(..)->map(..)->list` to optimize away
  intermediate data structures. (See Clojure's transducers.)

* Reference count based optimization: mutate if there's only a single
  holder.

* Consistency check: any method/function that returns a maybe or
  perhaps type must be named appropriately, otherwise throw exceptions
  on errors. Or: Error data type above?

* Implement `FP::Vec`, a data structure with both efficient functional
  updates and efficient random access. RandomAccessSequence
  protocol. Then hash maps with the same properties. (In C for speed?
  For algorithms, see Clojure.)

* Add ->[$i] to RandomAccessSequence protocol. Move ref and set over
  to RandomAccessSequence protocol?

* `FP::Repl::Trap`, `FP::Repl::AutoTrap`, tests: check `DEBUG` or `BACKTRACE`
  or similar env var(s) to make it possible to enable permanently in
  the code but stay really safe (never break the situation for any

docs/TODO.md  view on Meta::CPAN

- `Sub::Call::Tail` depends on `B::Hooks::OP::Check::EntersubForCV`
  which doesn't work on current bleadperl. Get this fixed.

  Reimplement it on top of `Devel::CallChecker` or
  `Devel::CallParser`?

  (Would it be obsolete if automatic TCO is implemented?)

- replace Chj::IO::* with something else?

- work on getting perl issues fixed, see failing tests `t/perl-*`

- disable stringification and numerification lexically using "no
  stringification"? But it currently doesn't work with bleadperl
  anymore. -> Just suggest in docs?

- extend Data::Dumper (or alternative dumper(s)) to show a simpler
  syntax for linked lists, and streams (and perhaps more) (mostly for
  the repl, but also in general):

        FP::list(1,2,3)  # instead of bless [1, bless [2, bless ...],...

  (Show only evaluated part of streams (and the rest as a promise), or
  force evaluation of the first n items then cut off the same way as
  for lists?)


### Code structure

- fix the now horrible hand-optimized-but-convoluted code in
  `PXML::Serialize` (and figure out an automatic way to make it fast).

- finish PXML's HTML5 support.

- improve sequences class hierarchy

    - look at Ord (Ordering) in Haskell etc.

    - avoid the duplication between `FP::List` and `FP::Stream` as much as
      possible.

        - those not using lazy internally: implement the List variants using
          Keep and the stream variants.

- what to do about data types that have both a class and some
  functions, like `is_sequence`, that now lives in `FP::Predicates`,
  and might be moved elsewhere in the future, breaking code importing
  it...?

- messages like "expecting 2 arguments" are unclear and inconsistently
  used for functions reused as methods. How should it be? `flip`
  should work, for example, so do we have to live with methods
  including $self in their argument count? (For this reason, much of
  the code is now simply throwing the message "wrong number of
  arguments" without any indication of the expected
  count. `Function::Parameters` issues "Too many arguments" and "Not
  enough arguments", `Method::Signatures` says "missing required
  argument $a" or "was given too many arguments", both of which are
  good.)

- should `rest` (`cdr`) weaken its argument in the case of streams? 
  (`first` clearly shouldn't, right?)

- add `FP::List`'s `none` and the `all` alias (also, remove `every`
  *or* `all`?) to `FP::Stream`, or to common base class.


### Security, safety

- check 'XX.*[Ss]ecurity' comments


### Possibilities

- port `PXML::Element` to `FP::Struct` (it was originally written
  before that existed, iirc). Create a version/extension of
  `FP::Struct` that uses arrays instead of hashes,
  or is that irrelevant and stupid? (benchmark cpu and memory)

</with_toc>