CPS
view release on metacpan or search on metacpan
NAME
CPS - manage flow of control in Continuation-Passing Style
OVERVIEW
Note: This module is entirely deprecated now. It is maintained for
compatibility for any code still using it, but please consider
rewriting to use Future instead, which offers a far neater method of
representing asynchronous program and data flow. In addition,
Future::AsyncAwait can further improve readability of Future-based
code by letting it use the familiar kinds of Perl control structure
while still being asynchronous.
At some later date this entire CPS module distribution may be
deleted.
The functions in this module implement or assist the writing of
programs, or parts of them, in Continuation Passing Style (CPS).
Briefly, CPS is a style of writing code where the normal call/return
mechanism is replaced by explicit "continuations", values passed in to
functions which they should invoke, to implement return behaviour. For
more detail on CPS, see the SEE ALSO section.
What this module implements is not in fact true CPS, as Perl does not
natively support the idea of a real continuation (such as is created by
a co-routine). Furthermore, for CPS to be efficient in languages that
natively support it, their runtimes typically implement a lot of
optimisation of CPS code, which the Perl interpreter would be unable to
perform. Instead, CODE references are passed around to stand in their
place. While not particularly useful for most regular cases, this
becomes very useful whenever some form of asynchronous or event-based
programming is being used. Continuations passed in to the body function
of a control structure can be stored in the event handlers of the
asynchronous or event-driven framework, so that when they are invoked
later, the code continues, eventually arriving at its final answer at
some point in the future.
In order for these examples to make sense, a fictional and simple
asynchronisation framework has been invented. The exact details of
operation should not be important, as it simply stands to illustrate
the point. I hope its general intention should be obvious. :)
read_stdin_line( \&on_line ); # wait on a line from STDIN, then pass it
# to the handler function
This module itself provides functions that manage the flow of control
through a continuation passing program. They do not directly facilitate
the flow of data through a program. That can be managed by lexical
variables captured by the closures passed around. See the EXAMPLES
} );
} );
},
sub { exit }
);
FUNCTIONS
In all of the following functions, the \&body function can provide
results by invoking its continuation / one of its continuations, either
synchronously or asynchronously at some point later (via some event
handling or other mechanism); the next invocation of \&body will not
take place until the previous one exits if it is done synchronously.
They all take the prefix k before the name of the regular perl keyword
or function they aim to replace. It is common in CPS code in other
languages, such as Scheme or Haskell, to store a continuation in a
variable called k. This convention is followed here.
kloop( \&body, $k )
CPS version of perl's while(true) loop. Repeatedly calls the body code
until it indicates the end of the loop, then invoke $k.
The following are equivalent
$kadd->( 10, 20, sub { print "The total is $_[0]\n" } );
$add = dropk { } $kadd;
print "The total is ".$add->( 10, 20 )."\n";
In the general case the CPS function hasn't yet invoked its
continuation by the time it returns (such as would be the case when
using any sort of asynchronisation or event-driven framework). For
dropk to actually work in this situation, it requires a way to run the
event framework, to cause it to process events until the continuation
has been invoked.
This is provided by the block, or the first passed CODE reference. When
the returned function is invoked, it repeatedly calls the block or wait
function, until the CPS function has invoked its continuation.
EXAMPLES
C<CPS> - manage flow of control in Continuation-Passing Style
=head1 OVERVIEW
=over 4
B<Note>: This module is entirely deprecated now. It is maintained for
compatibility for any code still using it, but please consider rewriting to
use L<Future> instead, which offers a far neater method of representing
asynchronous program and data flow. In addition, L<Future::AsyncAwait> can
further improve readability of C<Future>-based code by letting it use the
familiar kinds of Perl control structure while still being asynchronous.
At some later date this entire C<CPS> module distribution may be deleted.
=back
The functions in this module implement or assist the writing of programs, or
parts of them, in Continuation Passing Style (CPS). Briefly, CPS is a style
of writing code where the normal call/return mechanism is replaced by explicit
"continuations", values passed in to functions which they should invoke, to
implement return behaviour. For more detail on CPS, see the SEE ALSO section.
What this module implements is not in fact true CPS, as Perl does not natively
support the idea of a real continuation (such as is created by a co-routine).
Furthermore, for CPS to be efficient in languages that natively support it,
their runtimes typically implement a lot of optimisation of CPS code, which
the Perl interpreter would be unable to perform. Instead, CODE references are
passed around to stand in their place. While not particularly useful for most
regular cases, this becomes very useful whenever some form of asynchronous or
event-based programming is being used. Continuations passed in to the body
function of a control structure can be stored in the event handlers of the
asynchronous or event-driven framework, so that when they are invoked later,
the code continues, eventually arriving at its final answer at some point in
the future.
In order for these examples to make sense, a fictional and simple
asynchronisation framework has been invented. The exact details of operation
should not be important, as it simply stands to illustrate the point. I hope
its general intention should be obvious. :)
read_stdin_line( \&on_line ); # wait on a line from STDIN, then pass it
# to the handler function
This module itself provides functions that manage the flow of control through
a continuation passing program. They do not directly facilitate the flow of
data through a program. That can be managed by lexical variables captured by
the closures passed around. See the EXAMPLES section.
} );
},
sub { exit }
);
=cut
=head1 FUNCTIONS
In all of the following functions, the C<\&body> function can provide results
by invoking its continuation / one of its continuations, either synchronously
or asynchronously at some point later (via some event handling or other
mechanism); the next invocation of C<\&body> will not take place until the
previous one exits if it is done synchronously.
They all take the prefix C<k> before the name of the regular perl keyword or
function they aim to replace. It is common in CPS code in other languages,
such as Scheme or Haskell, to store a continuation in a variable called C<k>.
This convention is followed here.
=cut
=head2 kloop( \&body, $k )
The following are equivalent
$kadd->( 10, 20, sub { print "The total is $_[0]\n" } );
$add = dropk { } $kadd;
print "The total is ".$add->( 10, 20 )."\n";
In the general case the CPS function hasn't yet invoked its continuation by
the time it returns (such as would be the case when using any sort of
asynchronisation or event-driven framework). For C<dropk> to actually work in
this situation, it requires a way to run the event framework, to cause it to
process events until the continuation has been invoked.
This is provided by the block, or the first passed CODE reference. When the
returned function is invoked, it repeatedly calls the block or wait function,
until the CPS function has invoked its continuation.
=cut
sub dropk(&$)
lib/CPS/Functional.pm view on Meta::CPAN
}
CPS::_governate "g$_" => $_ for @CPS_PRIMS;
=head1 EXAMPLES
The following aren't necessarily examples of code which would be found in real
programs, but instead, demonstrations of how to use the above functions as
ways of controlling program flow.
Without dragging in large amount of detail on an asynchronous or event-driven
framework, it is difficult to give a useful example of behaviour that CPS
allows that couldn't be done just as easily without. Nevertheless, I hope the
following examples will be useful to demonstrate use of the above functions,
in a way which hints at their use in a real program.
=head2 Implementing C<join()> using C<kfoldl()>
use CPS::Functional qw( kfoldl );
my @words = qw( My message here );
lib/CPS/Functional.pm view on Meta::CPAN
},
sub {
my @primes = ( 2, 3, @_ );
print "Primes are @primes\n";
}
);
=head2 Forward-reading Program Flow
One side benefit of the CPS control-flow methods which is unassociated with
asynchronous operation, is that the flow of data reads in a more natural
left-to-right direction, instead of the right-to-left flow in functional
style. Compare
sub square { $_ * $_ }
sub add { $a + $b }
print reduce( \&add, map( square, primes(10) ) );
(because C<map> is a language builtin but C<reduce> is a function with C<(&)>
prototype, it has a different way to pass in the named functions)
lib/CPS/Governor.pm view on Meta::CPAN
C<CPS::Governor> - control the iteration of the C<CPS> functions
=head1 DESCRIPTION
Objects based on this abstract class are used by the C<gk*> variants of the
L<CPS> functions, to control their behavior. These objects are expected to
provide a method, C<again>, which the functions will use to re-invoke
iterations of loops, and so on. By providing a different implementation of
this method, governor objects can provide such behaviours as rate-limiting,
asynchronisation or parallelism, and integration with event-based IO
frameworks.
=cut
=head1 CONSTRUCTOR
=cut
=head2 $gov = CPS::Governor->new
( run in 0.294 second using v1.01-cache-2.11-cpan-0d8aa00de5b )