FAST

 view release on metacpan or  search on metacpan

lib/FAST/List/Gen.pm  view on Meta::CPAN

passed their object, the fastest way to call the method is:

    my $obj = Closure::Object->new('tim', 3);
    my $set = $obj->{set};                  # fetch the closure
         # or $obj->can('set')

    $set->(undef, $_) for 1 .. 1_000_000;   # call without first arg

which is around 70% faster than pre-caching a method from a normal object for
short getter/setter methods, and is the method used internally in this module.

=back

=head1 SEE ALSO

=over 4

=item * see L<FAST::List::Gen::Cookbook> for usage tips.

=item * see L<FAST::List::Gen::Benchmark> for performance tips.

=item * see L<FAST::List::Gen::Haskell> for an experimental implementation of
haskell's lazy list behavior.

=item * see L<FAST::List::Gen::Lazy> for the tools used to create
L<FAST::List::Gen::Haskell>.

=item * see L<FAST::List::Gen::Lazy::Ops> for some of perl's operators implemented
as lazy haskell like functions.

=item * see L<FAST::List::Gen::Lazy::Builtins> for most of perl's builtin functions
implemented as lazy haskell like functions.

=item * see L<FAST::List::Gen::Perl6> for a source filter that adds perl6's meta
operators to use with generators, rather than the default overloaded operators

=back

=head1 CAVEATS

version 0.90 added C< glob > to the default export list (which gives you
syntactic ranges C<< <1 .. 10> >> and list comprehensions.).  version 0.90 also
adds many new features and bug-fixes, as usual, if anything is broken, please
send in a bug report. the ending conditions of C< zip > and C< zipgen > have
changed, see the documentation above. C< test > has been removed from the
default export list. setting C< $FAST::List::Gen::LIST > true to enable list context
generators is no longer supported and will now throw an error. C< list > has
been added to the default export list.  C< genzip > has been renamed C< zipgen >

version 0.70 comes with a bunch of new features, if anything is broken, please
let me know.  see C< filter > for a minor behavior change

versions 0.50 and 0.60 break some of the syntax from previous versions,
for the better.

=over 4

=item code generation

a number of the syntactic shortcuts that FAST::List::Gen provides will construct and
then evaluate code behind the scenes.  Normally this is transparent, but if you
are trying to debug a problem, hidden code is never a good thing.  You can
lexically enable the printing of evaled code with:

    local $FAST::List::Gen::SAY_EVAL = 1;

    my $fib = <0, 1, *+*...>;

    #   eval: ' @pre = (0, 1)' at (file.pl) line ##
    #   eval: 'FAST::List::Gen::iterate { if (@pre) {shift @pre}
    #            else { $fetch->(undef, $_ - 2) + $fetch->(undef, $_ - 1) }
    #        } 9**9**9' at (file.pl) line ##

    my $gen = <1..10>->map('$_*2 + 1')->grep('some_predicate');

    #   eval: 'sub ($) {$_*2 + 1}' at (file.pl) line ##
    #   eval: 'sub ($) {some_predicate($_)}' at (file.pl) line ##

a given code string is only evaluated once and is then cached, so you will not
see any additional output when using the same code strings in multiple places.
in some cases (like the iterate example above) the code is closing over external
variables (C< @pre > and C< $fetch >) so you will not be able to see everything,
but C< $SAY_EVAL > should be a helpful debugging aid.

any time that code evaluation fails, an immediate fatal error is thrown.  the
value of C< $SAY_EVAL > does not matter in that case.

=item captures of compile time constructed lists

the C< cap > function and its twin operator C< &\ > are faster than the
C< [...] > construct because they do not copy their arguments.  this is why the
elements of the captures remain aliased to their arguments.  this is normally
fine, but it has an interesting effect with compile time constructed constant
lists:

    my $max = 1000;
    my $range = & \(1 .. $max); #  57% faster than [1 .. $max]
    my $nums  = & \(1 .. 1000); # 366% faster than [1 .. 1000], but cheating

the first example shows the expected speed increase due to not copying the
values into a new empty array reference. the second example is much faster at
runtime than the C< [...] > syntax, but this speed is deceptive.  the reason is
that the list being passed in as an argument is generated by the compiler before
runtime begins.  so all perl has to do is place the values on the stack, and
call the function.

normally this is fine, but there is one catch to be aware of, and that is that
a capture of a compile time constant list in a loop or subroutine (or any
structure that can execute the same segment of code repeatedly) will always
return a reference to an array of the same elements.

    # two instances give two separate arrays
    my ($a, $b) = (&\(1 .. 3), &\(1 .. 3));
    $_ += 10 for @$a;
    say "@$a : @$b"; # 11 12 13 : 1 2 3

    # here the one instance returns the same elements twice
    my ($x, $y) = map &\(1 .. 3), 1 .. 2;
    $_ += 10 for @$x;
    say "@$x : @$y"; # 11 12 13 : 11 12 13



( run in 0.951 second using v1.01-cache-2.11-cpan-e1769b4cff6 )