Re: r24711 - docs/Perl6/Spec

[Darren Duncan]

pugs-comm...@feather.perl6.nl wrote:

--name  :name
--name=value:namevalue
--name=spacy value:name«'spacy value'»
--name='spacy value':name«'spacy value'»
--name=val1,'val 2',etc :name«val1 'val 2' etc»
+-n :name
+-n=value   :namevalue
+-n=spacy value   :name«'spacy value'»
+-n='spacy value'   :name«'spacy value'»
+-n=val1,'val 2',etc:name«val1 'val 2' etc»
 
 --name :name# only if declared Bool

 --name=value   :namevalue # don't care


Is that right?  Should the right column example not also be shortened to :n ?  I 
thought the single-dash names only allowed a single character in a name on 
purpose, since multiple chars after a - were multiple options. -- Darren Duncan

Re: Bug or feature? Hash autovivification

[Patrick R. Michaud]

On Wed, Dec 31, 2008 at 08:06:48AM -0800, Ovid wrote:
 Just stumbled across this, but I can't tell from S09 if this is a bug or 
 feature:
 
   $ ./perl6 -e 'my %foo; if %fooa {}; say %foo.perl'
   {a = undef}

It's a bug.  In order to simplify the slicing implementation
Rakudo currently autovivifies elements on read access.  This
will be fixed again very soon -- I just want to get the other
variable refactors for Rakudo worked out first.

Pm

Converting a Perl 5 pseudo-continuation to Perl 6

[Geoffrey Broadwell]

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

[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

[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

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

[Steve Lukas]

Hello,
I'd vote for the OO-style. 
My reason is that the major criteria should be the reader perspective.
It should be as clear as possible what's going on in the main code 
even if the reader doesn't know the hottest p6 tricks!
What you are doing here is: two operations on the same thing (the pidfile).
So the code should point out that it works twice on the same thing.

I think it's best to have an object to show this
whereas returning the sub/closure feels a bit confusing.
Your right, this style is busy work, but it's not pointless.

I would suggest a locally visible class to bring out the 
local, one time usage of that class. Btw. what is the best way to do so?

Kind regards
Stefan


--- On Thu, 1/1/09, Geoffrey Broadwell ge...@broadwell.org wrote:
From: Geoffrey Broadwell ge...@broadwell.org
Subject: Converting a Perl 5 pseudo-continuation to Perl 6
To: perl6-us...@perl.org, perl6-language@perl.org
Date: Thursday, January 1, 2009, 3:34 PM

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]