Re: Converting a Perl 5 pseudo-continuation to Perl 6

2009-01-26 Thread Aristotle Pagaltzis
* Aristotle Pagaltzis pagalt...@gmx.de [2009-01-02 23:00]:
 That way, you get this combination:

 sub pid_file_handler ( $filename ) {
 # ... top half ...
 yield;
 # ... bottom half ...
 }

 sub init_server {
 # ...
 my $write_pid = pid_file_handler( $optionspid_file );
 become_daemon();
 $write_pid();
 # ...
 }

It turns out that is exactly how generators work in
Javascript 1.7:
https://developer.mozilla.org/en/New_in_JavaScript_1.7

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/


Re: Converting a Perl 5 pseudo-continuation to Perl 6

2009-01-26 Thread Larry Wall
On Tue, Jan 27, 2009 at 12:27:56AM +0100, Aristotle Pagaltzis wrote:
: * Aristotle Pagaltzis pagalt...@gmx.de [2009-01-02 23:00]:
:  That way, you get this combination:
: 
:  sub pid_file_handler ( $filename ) {
:  # ... top half ...
:  yield;
:  # ... bottom half ...
:  }
: 
:  sub init_server {
:  # ...
:  my $write_pid = pid_file_handler( $optionspid_file );
:  become_daemon();
:  $write_pid();
:  # ...
:  }
: 
: It turns out that is exactly how generators work in
: Javascript 1.7:
: https://developer.mozilla.org/en/New_in_JavaScript_1.7

As I said before, it's trivially easy to return a closure, and I
generally like my closures to be explicit:

sub pid_file_handler ( $filename ) {
# ... top half ...
return {
 # ... bottom half ...
}
}

If you tell me that another language does something a particular way,
I'll take it as a possible recommendation maybe 10% of the time,
and as a dire warning the other 90% of the time.  :)

Larry


Re: Converting a Perl 5 pseudo-continuation to Perl 6

2009-01-03 Thread Mark J. Reed
On Fri, Jan 2, 2009 at 9:06 PM, Geoffrey Broadwell ge...@broadwell.org wrote:
 It does bring up a question, though.  What if pid_file_handler() needed
 to be broken into three or more pieces, thus containing multiple yield
 statements?  Does only the first one return a continuation object, which
 can be called repeatedly to continue after each yield like this?

IMO, that's not much better than not having the explicit continuation
object in the first place.  A true continuation should essentially be
an immutable value object that can be repeatedly invoked to resume
processing at the same point.

my more_pid_stuff := pid_file_handler($pid_file);

How does binding work with an rvalue like that?

 Or does each yield produce a fresh new continuation object like this?

That would definitely be my vote.

-- 
Mark J. Reed markjr...@gmail.com


Re: Converting a Perl 5 pseudo-continuation to Perl 6

2009-01-03 Thread Geoffrey Broadwell
On Fri, 2009-01-02 at 22:56 +0100, Aristotle Pagaltzis wrote:
  When I asked this question on #perl6, pmurias suggested using
  gather/take syntax, but that didn't feel right to me either --
  it's contrived in a similar way to using a one-off closure.
 
 Contrived how?

Meaning, the gather/take syntax doesn't make much sense, because we're
not gathering anything; the PID file handler has nothing to return.
We'd only be using it for the side effect of being able to pause the
callee's execution and resume it later.

 When you have an explicit entity representing the continuation,
 all of these questions resolve themselves in at once: all calls
 to the original routine create a new continuation, and all calls
 via the state object are resumptions. There is no ambiguity or
 subtlety to think about.

I like this argument.  I'm not sure it's applicable in every case, but
it certainly applies to the class of situations containing my problem.

 So from the perspective of the caller, I consider the “one-off”
 closure ideal: the first call yields an object that can be used
 to resume the call.
 
 However, I agree that having to use an extra block inside the
 routine and return it explicity is suboptimal. It would be nice
 if there was a `yield` keyword that not only threw a resumable
 exception, but also closed over the exception object in a
 function that, when called, resumes the original function.
 
 That way, you get this combination:
 
 sub pid_file_handler ( $filename ) {
 # ... top half ...
 yield;
 # ... bottom half ...
 }
 
 sub init_server {
 # ...
 my $write_pid = pid_file_handler( $optionspid_file );
 become_daemon();
 $write_pid();
 # ...
 }

That's pretty nice.  Perhaps we can make it even cleaner with a few
small tweaks to init_server():

sub init_server(:$pid_file, ...) {
# ...
my write_pid := pid_file_handler($pid_file);
become_daemon();
write_pid();
# ...
}

So far, this variant is winning for me, I think.  It's slightly more
verbose on the caller's side than the yield variant I had proposed, but
it's also more explicit, and allows (as you said) a clean syntactic
separation between starting the PID file handler and continuing it.

It does bring up a question, though.  What if pid_file_handler() needed
to be broken into three or more pieces, thus containing multiple yield
statements?  Does only the first one return a continuation object, which
can be called repeatedly to continue after each yield like this?

sub init_server(:$pid_file, ...) {
# ...
my more_pid_stuff := pid_file_handler($pid_file);
become_daemon();

more_pid_stuff();
do_something();

more_pid_stuff();
do_something_else();

more_pid_stuff();
# ...
}

Or does each yield produce a fresh new continuation object like this?

sub init_server(:$pid_file, ...) {
# ...
my write_pid   := pid_file_handler($pid_file);
become_daemon();

my fold_pid:= write_pid();
do_something();

my spindle_pid := fold_pid();
do_something_else();

spindle_pid();
# ...
}

(Note that I assume you can simply ignore the returned object if you
don't plan to continue the operation any more, without raising a
warning.)

Certainly the first version has less visual clutter, so I tend to lean
that way by default.  But the second design would allow one to create a
tree of partial executions, by calling any earlier continuation object
again.  That's a very powerful concept that I don't want to give up on.

Supporting both feels like it might be an adverb on the invocation
(possibly with a frosty sugar coating available).  It would be nice to
support invoking a continuation in ratcheting and forgetful modes.

Thoughts?


-'f




Re: Converting a Perl 5 pseudo-continuation to Perl 6

2009-01-02 Thread Aristotle Pagaltzis
* Geoffrey Broadwell ge...@broadwell.org [2009-01-01 21:40]:
 In the below Perl 5 code, I refactored to pull the two halves of the PID
 file handling out of init_server(), but to do so, I had to return a sub
 from pid_file_handler() that acted as a continuation.  The syntax is a
 bit ugly, though.  Is there a cleaner way to this in Perl 6?

 ##
 sub init_server {
 my %options  = @_;

 # ...

 # Do top (pre-daemonize) portion of PID file handling.
 my $handler = pid_file_handler($options{pid_file});

 # Detach from parent session and get to clean state.
 become_daemon();

 # Do bottom (post-daemonize) portion of PID file handling.
 $handler-();

 # ...
 }

 sub pid_file_handler {
 # Do top half (pre-daemonize) PID file handling ...
 my $filename = shift;
 my $basename = lc $BRAND;
 my $PID_FILE = $filename || $PID_FILE_DIR/$basename.pid;
 my $pid_file = open_pid_file($PID_FILE);

 # ... and return a continuation on the bottom half (post-daemonize).
 return sub {
 $MASTER_PID  =  $$;
 print $pid_file $$;
 close $pid_file;
 };
 }
 ##

 When I asked this question on #perl6, pmurias suggested using
 gather/take syntax, but that didn't feel right to me either --

 it's contrived in a similar way to using a one-off closure.

Contrived how? I always found implicit continuations distasteful
in the same way that `each` and the boolean flip-flop are bad in
Perl 5: because they tie program state to a location in the code.
When there is state, it should be passed around explicitly. So I
think the return-a-closure solution is actually ideal.

F.ex. it keeps you entirely clear of the troublesome question of
when a subsequent call should restart the sub from the beginning
or resume it – should that happen when identical arguments are
passed? Or when no arguments are passed? Are there any rules
about the proximity of the calls in the code? Or does the
coroutine state effectively become global state (like with `each`
and `pos` in Perl 5)?

When you have an explicit entity representing the continuation,
all of these questions resolve themselves in at once: all calls
to the original routine create a new continuation, and all calls
via the state object are resumptions. There is no ambiguity or
subtlety to think about.

So from the perspective of the caller, I consider the “one-off”
closure ideal: the first call yields an object that can be used
to resume the call.

However, I agree that having to use an extra block inside the
routine and return it explicity is suboptimal. It would be nice
if there was a `yield` keyword that not only threw a resumable
exception, but also closed over the exception object in a
function that, when called, resumes the original function.

That way, you get this combination:

sub pid_file_handler ( $filename ) {
# ... top half ...
yield;
# ... bottom half ...
}

sub init_server {
# ...
my $write_pid = pid_file_handler( $optionspid_file );
become_daemon();
$write_pid();
# ...
}

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/


Re: Converting a Perl 5 pseudo-continuation to Perl 6

2009-01-02 Thread Larry Wall
On Fri, Jan 02, 2009 at 06:06:31PM -0800, Geoffrey Broadwell wrote:
: Meaning, the gather/take syntax doesn't make much sense, because we're
: not gathering anything; the PID file handler has nothing to return.
: We'd only be using it for the side effect of being able to pause the
: callee's execution and resume it later.

Leaving aside for the moment the question of how much we want mere
mortals to know about continuations when normal closures would do,
I think you're falling into a kind of P5Think here, that all forms
of nothing are equivalent.  A take always returns a Capture object,
so at minimum you're gathering a list of Captures, even if they're
empty.  If you like, you could also think of gathering continuations
or closures, depending on whether the object you take closes over
return context or just the rest of the current call.

In any case, I dislike the overloading of the function interface that
happens with many standard coroutine designs.  That's why gather/take
is orthogonal to the function call interface.

As for syntactic relief, that will always be a macro away in Perl 6,
if you really want it.  But I think return {...} and take {...}
are nice, explicit idioms for returning a closure, and we've gone to
some pains in Perl 6 to make a bare block behave that way without a
keyword, so I'm not in a hurry to huffmanize away a mere two characters
for what what many readers would view as a form of obfuscation.

As for true reusable continuations, I'm not opposed to having them
available in the language per se, but they're hard to implement on some
architectures, and I'll certainly frown on any attempt to confuse them
with either normal closures or even single-use continuations in the
minds of mere mortals.  Using bare continuations where gather/take or
closures will do is like throwing out your steak knives because they
duplicate the functionality of your chain saw.  :)

Larry


Re: Converting a Perl 5 pseudo-continuation to Perl 6

2009-01-01 Thread Leon Timmermans
I can't help wondering why does pid_file_handler need to be split up
in the first place? Why wouldn't it be possible to simply call
pid_file_handler after become_daemon?

Regards,

Leon Timmermans

On Thu, Jan 1, 2009 at 10:34 PM, Geoffrey Broadwell ge...@broadwell.org wrote:
 In the below Perl 5 code, I refactored to pull the two halves of the PID
 file handling out of init_server(), but to do so, I had to return a sub
 from pid_file_handler() that acted as a continuation.  The syntax is a
 bit ugly, though.  Is there a cleaner way to this in Perl 6?

 ##
 sub init_server {
my %options  = @_;

# ...

# Do top (pre-daemonize) portion of PID file handling.
my $handler = pid_file_handler($options{pid_file});

# Detach from parent session and get to clean state.
become_daemon();

# Do bottom (post-daemonize) portion of PID file handling.
$handler-();

# ...
 }

 sub pid_file_handler {
# Do top half (pre-daemonize) PID file handling ...
my $filename = shift;
my $basename = lc $BRAND;
my $PID_FILE = $filename || $PID_FILE_DIR/$basename.pid;
my $pid_file = open_pid_file($PID_FILE);

# ... and return a continuation on the bottom half (post-daemonize).
return sub {
$MASTER_PID  =  $$;
print $pid_file $$;
close $pid_file;
};
 }
 ##

 When I asked this question on #perl6, pmurias suggested using
 gather/take syntax, but that didn't feel right to me either -- it's
 contrived in a similar way to using a one-off closure.

 pmichaud offered several possibilities (I've converted some of his
 suggestions expressed as prose into code, so the errors there are mine):

 1. Take advantage of Perl 6 syntax reduction to turn 'return sub {...}'
   into 'return {...}' (or even just fall of the end with '{...}', I
   suppose).  This is visually slightly better, but still leaves the
   bottom half inside a block that merely exists to satisfy Perl, not
   actually representing anything intrinsic about the problem.

 2. Throw a resumable exception in the middle:

   sub init_server {
   # ...
   pid_file_handler($options{pid_file});
   become_daemon();
   pid_file_handler();
   # ...
   }

   sub pid_file_handler {
   # ... top half ...
   throw ResumableException;
   # ... bottom half ...
   }

   He also suggested a variant syntax with an adverb on return:

   sub pid_file_handler {
   # ... top half ...
   return :resumable;
   # ... bottom half ...
   }

   I suggested a naked yield syntax:

   sub pid_file_handler {
   # ... top half ...
   yield;
   # ... bottom half ...
   }

   These all desugar to the same thing, of course.

 3. Make become_daemon a part of pid_file_handler, or vice-versa.
   I rejected both of these on the basis of separating different
   things into different subs.  The two tasks are only tangentially
   related, and neither really seems like a subordinate op of the
   other.

 4. In order to keep the sub separate, but still not split the
   pid_file_handler call, I came up with a variation of #3 in which
   pid_file_handler takes a callback parameter:

   sub init_server {
   # ...
   pid_file_handler($options{pid_file}, become_daemon);
   # ...
   }

   sub pid_file_handler($pid_file, callback) {
   # ... top half ...
   callback();
   # ... bottom half ...
   }

   That seems like a silly contortion to hide the problem, and
   doesn't represent my intent well -- the pid file handler doesn't
   need to send a message, it needs to yield control while waiting
   for something else to happen.

 5. Make a new PidHandler class and address the problem in OO fashion:

   sub init_server {
   # ...
   my $pid_handler = PidHandler.new(file = $options{pid_file});
   $pid_handler.top();
   become_daemon();
   $pid_handler.bottom();
   #...
   }

   This is certainly workable, but again feels like a contrived
   workaround in the same way that gather/take and return {...} do.
   Plus, writing a new class and using OO/method call syntax just to
   allow a sub to be split seems like pointless busy work.  Not
   as bad in Perl 6 as in Perl 5, but still.

 In the end, I think I like the 'naked yield' idea best of the ones we
 have so far.  Any comments or other ideas? [1]


 -'f

 [1] Other than that I've used the word 'contrived' too many times.  :-)





Re: Converting a Perl 5 pseudo-continuation to Perl 6

2009-01-01 Thread Geoffrey Broadwell
On Fri, 2009-01-02 at 00:30 +0200, Leon Timmermans wrote:
 I can't help wondering why does pid_file_handler need to be split up
 in the first place? Why wouldn't it be possible to simply call
 pid_file_handler after become_daemon?

Two answers:

1. If an error occurs that will not allow the PID file to be created
   (another copy of the daemon is already running, the user doesn't
   have required root permissions, or what have you), the program
   should die visibly at the command line, rather than *appearing* to
   launch but actually just spitting an error into the syslog and
   disappearing silently.  Checking for another running daemon and
   taking ownership of the pid file should be an atomic operation
   (or at the very least err on the side of failing noisily if
   something fishy happens), so I can't just check for an existing
   pid file before daemonizing, and then create the new pid file after.

   It's not visible in the code I posted, but the program should also
   do a number of other sanity checks before it daemonizes, for the
   very same reasons.  For example, it should load all modules it
   expects to use before becoming a daemon, and complain loudly if
   it can't.

2. The particular code I used is just a decent example to ask about
   the general question of a better syntax for interrupting and
   continuing a sub.  So even if I could do what you say, I'd still
   have the question.  :-)


-'f