On Wed, Apr 20, 2005 at 10:11:35AM -0700, Larry Wall wrote:
> We will certainly be pushing all the time interfaces of Perl 6 toward
> using floating-point time values.  The only question is whether alarm()
> is the right name for one of the interfaces, and whether we even need an
> interface whose *default* behavior is to send a signal, ugh.  We should
> probably be encouraging timed callbacks instead.  We could even force
> people to define their own alarm if they want one.  Assuming we
> rehuffmanize "kill" to "sendsignal" or some such, we have:
(FWIW, this is called "signalProcess" in Haskell.)

>     sub alarm ($secs) {
>       { sendsignal $*PID, Signal::ALARM }.cue(:delay($secs));
>     }
> Though I suppose people really mostly just want something like
>     sub alarm ($secs) {
>       { sendsignal $*PID, Signal::ALARM }.delay($secs);
>     }
> The actual verb/adverb names are negotiable, but they need to handle
> relative vs absolute times intuitively.  Different words have different
> connotations in that regard.  "delay" is definitely relative, while
> "after" tends toward absolute, though can be used relatively too.
> "at" is definitely absolute time, but maybe too overloaded with
> positional meanings.  "later" is unfortunately completely ambiguous.

We also want repeat events; I can think of two ways to do it. Either
require everything to be explicit with adverbs, or have the closure's
return value determine whether to keep calling back or to quit. GLib
does the latter, and there's a cleanliness in how the closure itself can
control when to stop, but the former means you can schedule arbitrary
code without changing it.

Is there anybody from the perl-loop gang around here? I'm sure they've
thought about these things a lot.


Reply via email to