Re: Temporal changes

[Graham Barr]

On Feb 23, 2009, at 3:56 PM, mark.a.big...@comcast.net wrote:


Instant
Moment
Point
PointInTime
Timestamp
Event
Jiffy
Time


Juncture

[perl #63360] [PATCH] Update configure script and makefiles for installed Parrot

[Allison Randal via RT]

On Fri Feb 20 00:36:36 2009, alli...@perl.org wrote:
> 
> - There's still a problem with the installed test libraries. I'll look 
> into it and provide an additional patch.

Ah, it wasn't a problem with the test libraries, just with Rakudo's
t/harness (using a hardcoded path to the parrot executable). Attached
git patch to fix the test target.

Allison
>From 90672654a8f2600dbc8b67f4f46286d1ed2b7279 Mon Sep 17 00:00:00 2001
From: Allison Randal 
Date: Mon, 23 Feb 2009 18:03:30 -0800
Subject: [PATCH] Also fix t/harness to use installed Parrot executable when requested, instead of looking for the executable in a 'parrot/' subdirectory.

---
 build/Makefile.in |4 ++--
 t/harness |   16 ++--
 2 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/build/Makefile.in b/build/Makefile.in
index 3244ff0..9c88b2e 100644
--- a/build/Makefile.in
+++ b/build/Makefile.in
@@ -149,7 +149,7 @@ CLEANUPS = \
 
 # NOTE: eventually, we should remove --keep-exit-code and --fudge
 #   as the goal is that all tests must pass without fudge
-HARNESS_WITH_FUDGE = $(PERL) t/harness --fudge --keep-exit-code
+HARNESS_WITH_FUDGE = $(PERL) -I$(TOOLS_DIR) t/harness --bindir=$(BIN_DIR) --fudge --keep-exit-code
 HARNESS_WITH_FUDGE_JOBS = $(HARNESS_WITH_FUDGE) --jobs
 
 
@@ -243,7 +243,7 @@ codetest:
 
 coretest: perl6.pbc
 #	prove t/pmc
-	$(PERL) t/harness t/00-parrot t/01-sanity
+	$(PERL) -I$(TOOLS_DIR) t/harness --bindir=$(BIN_DIR) t/00-parrot t/01-sanity
 
 fulltest: coretest spectest codetest
 
diff --git a/t/harness b/t/harness
index 48f2aab..26327fe 100644
--- a/t/harness
+++ b/t/harness
@@ -20,21 +20,25 @@ our %harness_args = (
 verbosity => 0,
 );
 
-if (-d 'parrot') {
-$harness_args{exec} = ['parrot/parrot', 'perl6.pbc'];
-} else {
-$harness_args{compiler} = 'perl6.pbc';
-}
-
 GetOptions(
 'tests-from-file=s' => \my $list_file,
 'fudge' => \my $do_fudge,
 'verbosity=i'   => \$harness_args{verbosity},
+'bindir=s'  => \$harness_args{bindir},
 # A sensible default is num_cores + 1.
 # Many people have two cores these days.
 'jobs:3'=> \$harness_args{jobs},
 );
 
+if ($harness_args{bindir}) {
+$harness_args{exec} = [$harness_args{bindir}.'/parrot', 'perl6.pbc'];
+} elsif (-d 'parrot') {
+$harness_args{exec} = ['parrot/parrot', 'perl6.pbc'];
+} else {
+$harness_args{compiler} = 'perl6.pbc';
+}
+
+
 
 my @pass_through_options = grep m/^--?[^-]/, @ARGV;
 my @files = grep m/^[^-]/, @ARGV;
-- 
1.5.6.3

S28

[Richard Hainsworth]

The official Perl6 Documentation site  list 
this document as

special-names
not special-variables

variables is more constrictive, so suggest a change in name of pod.

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

Author: wayland
Date: 2009-02-23 04:47:22 +0100 (Mon, 23 Feb 2009)
New Revision: 25490

Added:
   docs/Perl6/Spec/S28-special-variables.pod
Log:
Created the draft spec here.  It's very drafty, but no more than some.  



  

Rules mentioned in specifications, etc

[Richard Hainsworth]

Here is a list of rules (see below) that are spread around the language 
design documents, but which lack a home in which they are systematically 
canonically defined.


I suggest they be added to the new S28 (which is possible if S28 is 
special-names, not special-variables)


Richard


Where can I find a list of rules that are provided by default?


I don't know that a canonical list exists.  
However, I can tell you what rules PGE provides by default

(these came from scraping various versions of the synopses,
apocalypses, and exigeses):

   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   

Pm

Re: Signals question for S16: IPC / IO / Signals

[Daniel Ruoso]

Em Seg, 2009-02-23 às 19:49 -0800, Larry Wall escreveu:
> On Tue, Feb 24, 2009 at 04:01:40PM +1300, Martin D Kealey wrote:
> : Conceptually I think they should all go in add-on(s), however I suspect that
> : when an exception is thrown inside a signal handler, cleanly unwinding the
> : call chain will need special support in the core.
> Which should already be there, presumably, as defined in S04 and such.
> Some signals like CONT want to get translated to resumable exceptions
> and others like SEGV to non-resumable.

Agreed, every signal could just be a control exception with no special
behavior (except being potentially resumable), simply:

 * ControlExceptionSigHUP
 * ControlExceptionSigTERM
 * ControlExceptionSigINT
 * and so on...

Then defining a signal handler is just a matter of a CONTROL block that
catches that exception. This would mean something that is very important
in terms of concurrency, which is that the signal handling code that is
registered in the OS is simply there to raise the exception, once that
happens, the regular execution flows to the CONTROL block.

We would just need to decide if a signal should be seen by all of the
concurrent threads (green-threads or os-threads), or if there is a
"main" thread that would receive the exceptions or how the user can
tweak that behavior...

Then the outermost dynamic scope would define a CONTROL that would
implement the default behavior for each control exception (as it already
does for ControlExceptionWarn, for instance.

> These signal events will
> presumably be processed by some kind of underlying event handler that
> mediates among any and all user-visible event handlers within the
> process.
 
Now *that* made my eyes shine. ;)

Adding a library-agnostic event loop at the core is something that might
be very much powerfull. The AnyEvent p5 modules is one of the most
interesting things in this regard in CPAN, it works with any event loop
(including POE, Event and EV). 

So the default code that raises the control exception for each signal
would be registered in this event loop, as well as any code that wanted
to perform asynchronous IO, which would just register a listener for
"can_read" in soe IO handle.

We just need to sketch an API around that...

daniel

Re: Temporal changes

[Mark J. Reed]

On Mon, Feb 23, 2009 at 5:01 PM, Graham Barr  wrote:
> Juncture

As has already been pointed out, that has extremely high potential for
being confused with Junctions.

-- 
Mark J. Reed 

"$!foo mapped to $foo", say what?

[Carl Mäsak]

I read this line in S02, and was distraught:

$!foo   object attribute private storage (mapped to $foo though)

I read this as meaning "when you declare $!foo, you will then also be
able to refer to it as $foo".

Jonathan Worthington pointed out on #perl6 that S12 says the exact opposite:

has $brain; # also declares $!brain;

So, which of the following is true?

(1) The spec is inconsistent on this point, and should be straightened out.
(2) "Mapped to" means the opposite of what I thought, and all is well.
(3) The spec actually doesn't contradict itself, but "mapped to" is
too imprecise a term to use here.

// Carl

r25523 - docs/Perl6/Spec

[pugs-commits]

Author: lwall
Date: 2009-02-24 17:02:03 +0100 (Tue, 24 Feb 2009)
New Revision: 25523

Modified:
   docs/Perl6/Spec/S02-bits.pod
Log:
remove confusing sidenote


Modified: docs/Perl6/Spec/S02-bits.pod
===
--- docs/Perl6/Spec/S02-bits.pod2009-02-24 12:50:13 UTC (rev 25522)
+++ docs/Perl6/Spec/S02-bits.pod2009-02-24 16:02:03 UTC (rev 25523)
@@ -12,9 +12,9 @@
 
   Maintainer: Larry Wall 
   Date: 10 Aug 2004
-  Last Modified: 20 Feb 2009
+  Last Modified: 24 Feb 2009
   Number: 2
-  Version: 153
+  Version: 154
 
 This document summarizes Apocalypse 2, which covers small-scale
 lexical items and typological issues.  (These Synopses also contain
@@ -1416,7 +1416,7 @@
 $?foo   compiler hint variable
 $=foo   pod variable
 $  match variable, short for $/{'foo'}
-$!foo   object attribute private storage (mapped to $foo though)
+$!foo   object attribute private storage
 
 Most variables with twigils are implicitly declared or assumed to
 be declared in some other scope, and don't need a "my" or "our".

Re: Rules mentioned in specifications, etc

[Larry Wall]

On Tue, Feb 24, 2009 at 02:04:05PM +0300, Richard Hainsworth wrote:
> Here is a list of rules (see below) that are spread around the language  
> design documents, but which lack a home in which they are systematically  
> canonically defined.
>
> I suggest they be added to the new S28 (which is possible if S28 is  
> special-names, not special-variables)

If they're provided by the standard regex implementation, they
should go in S05, where many of them are already.  For now you could
just add another bullet item listing them all.  If you want to turn
some of those bullet lists into a real outline while you're at it,
feel free.  :)

Larry

Re: min= (from "Rakudo Built-ins Can Now Be Written In Perl 6")

[Ruud H.G. van Tol]

David Green wrote:


my $foo is limited(100..200);
$foo = 5;   # really does $foo = 100


Where does that MySQ smell come from?
Why not undef (or NaN)?

--
Ruud

Re: min= (from "Rakudo Built-ins Can Now Be Written In Perl 6")

[Mark J. Reed]

On Tue, Feb 24, 2009 at 11:16 AM, Ruud H.G. van Tol  wrote:
> David Green wrote:
>
>>    my $foo is limited(100..200);
>>    $foo = 5;                       # really does $foo = 100
>
> Where does that MySQ smell come from?
> Why not undef (or NaN)?

How about Failing instead of any of the above?   Silently replacing
the assigned value seems like a Bad Idea.

-- 
Mark J. Reed 

Re: "$!foo mapped to $foo", say what?

[Larry Wall]

On Tue, Feb 24, 2009 at 04:49:24PM +0100, Carl Mäsak wrote:
: I read this line in S02, and was distraught:
: 
: $!foo   object attribute private storage (mapped to $foo though)
: 
: I read this as meaning "when you declare $!foo, you will then also be
: able to refer to it as $foo".
: 
: Jonathan Worthington pointed out on #perl6 that S12 says the exact opposite:
: 
: has $brain; # also declares $!brain;
: 
: So, which of the following is true?
: 
: (1) The spec is inconsistent on this point, and should be straightened out.
: (2) "Mapped to" means the opposite of what I thought, and all is well.
: (3) The spec actually doesn't contradict itself, but "mapped to" is
: too imprecise a term to use here.

It should have said "mappable".  The intent was not to imply that it was
the default behavior.  You only get the mapping if you declare has $brain,
which apparently I hasn't.  :)

Larry

Re: min= (from "Rakudo Built-ins Can Now Be Written In Perl 6")

[Larry Wall]

Alternately, if you want a purer FP solution:

sub infix: is looser(&infix:<..>) (Num $x, Range $r) {
given $x {
when $x < $r.min { $r.min }
when $x > $r.max { $r.max }
default  { $x }
}
}

...
take $foo clamp 100..200;
take $bar clamp $midpoint ± $epsilon;

Larry

r25527 - docs/Perl6/Spec

[pugs-commits]

Author: lwall
Date: 2009-02-24 19:23:06 +0100 (Tue, 24 Feb 2009)
New Revision: 25527

Modified:
   docs/Perl6/Spec/S03-operators.pod
   docs/Perl6/Spec/S06-routines.pod
   docs/Perl6/Spec/S28-special-variables.pod
Log:
clarify what happens when associativity conflicts arise
allow both tighter and looser at the same time
remove all the synthetic @? variables; use the symbol tables directly


Modified: docs/Perl6/Spec/S03-operators.pod
===
--- docs/Perl6/Spec/S03-operators.pod   2009-02-24 17:53:22 UTC (rev 25526)
+++ docs/Perl6/Spec/S03-operators.pod   2009-02-24 18:23:06 UTC (rev 25527)
@@ -12,9 +12,9 @@
 
   Maintainer: Larry Wall 
   Date: 8 Mar 2004
-  Last Modified: 12 Feb 2009
+  Last Modified: 24 Feb 2009
   Number: 3
-  Version: 153
+  Version: 154
 
 =head1 Overview
 
@@ -95,6 +95,13 @@
 Similarly, if the only implementation of a list-associative operator
 is binary, it will be treated as right associative.
 
+The standard precedence levels attempt to be consistent in their
+associativity, but user-defined operators and precedence levels may mix
+right and left associative operators at the same precedence level.
+If two conflicting operators are used ambiguously in the same
+expression, the operators will be considered non-associative with
+respect to each other, and parentheses must be used to disambiguoate.
+
 If you don't see your favorite operator above, the following
 sections cover all the operators in precedence order.  Basic operator
 descriptions are here; special topics are covered afterwards.

Modified: docs/Perl6/Spec/S06-routines.pod
===
--- docs/Perl6/Spec/S06-routines.pod2009-02-24 17:53:22 UTC (rev 25526)
+++ docs/Perl6/Spec/S06-routines.pod2009-02-24 18:23:06 UTC (rev 25527)
@@ -13,9 +13,9 @@
 
   Maintainer: Larry Wall 
   Date: 21 Mar 2003
-  Last Modified: 20 Feb 2009
+  Last Modified: 24 Feb 2009
   Number: 6
-  Version: 101
+  Version: 102
 
 
 This document summarizes Apocalypse 6, which covers subroutines and the
@@ -1667,10 +1667,21 @@
 =item C/C/C
 
 Specifies the precedence of an operator relative to an existing
-operator.  C and C operators default to being left
-associative.
+operator.  C and C precedence levels default to
+being left associative.  They define a new precedence level slighty
+tighter or looser than the precedence level on which they're based.
+Both C and C may be specified, in which case the new
+precedence level is generated midway between the specified levels.
 
-C on the other hand also clones other traits, so it specifies
+Two different declarations using the same precedence derivation end
+up at the same precedence level, as if C was specified instead
+of C/C, and the second will clone the associativity
+of the first.  If the second explicitly specifies an associativity
+that differs from the first, unexpected parsing conflicts may result.
+(See S03.)
+
+In addition to cloning the precedence level,
+C also clones other traits, so it specifies
 the default associativity to be the same as the operator to which
 the new operator is equivalent.  The following are the default
 equivalents for various syntactic categories if neither C nor

Modified: docs/Perl6/Spec/S28-special-variables.pod
===
--- docs/Perl6/Spec/S28-special-variables.pod   2009-02-24 17:53:22 UTC (rev 
25526)
+++ docs/Perl6/Spec/S28-special-variables.pod   2009-02-24 18:23:06 UTC (rev 
25527)
@@ -46,10 +46,8 @@
  $0, $1, $2  S05   # first captured value from match: $/[0]
  @*ARGS  S06   # command-line arguments
  &?BLOCK S06   # current block (itself)
- @?BLOCK S06   # current blocks (themselves)
  ::?CLASS  # current class (as package name)
  $?CLASS   # current class (as variable)
- @?CLASS   # current classes
  %?CONFIG  # configuration hash
  $=DATA# data block handle (=begin DATA ... =end)
  $*EGID# effective group id
@@ -59,14 +57,11 @@
  $*EXECUTABLE_NAME # executable name
  $?FILE# current filename of source file
  $?GRAMMAR # current grammar
- @?GRAMMAR # current grammars
  $*GID # group id
  $*INS16   # Standard input handle; is an IO object
  $?LABEL   # label of current block
- @?LABEL   # labels of current blocks
  $?LINE# current line number in source file
  $?MODULE  # current module
- @?MODULE  # current modules
  %*OPTS  S19   # Options from command line
  %*OPT...S19   # Options from command line to be passed down
  %*OPTS  S19   # Options from command line
@@ -77,7 +72,6 @@
  $*OSVER   # operating s

r25528 - docs/Perl6/Spec

[pugs-commits]

Author: rhr
Date: 2009-02-24 19:33:56 +0100 (Tue, 24 Feb 2009)
New Revision: 25528

Modified:
   docs/Perl6/Spec/S28-special-variables.pod
Log:
[S28] we don't have both $*IN and $*STDIN etc.


Modified: docs/Perl6/Spec/S28-special-variables.pod
===
--- docs/Perl6/Spec/S28-special-variables.pod   2009-02-24 18:23:06 UTC (rev 
25527)
+++ docs/Perl6/Spec/S28-special-variables.pod   2009-02-24 18:33:56 UTC (rev 
25528)
@@ -80,9 +80,6 @@
  ::?ROLE   # current role (as package name)
  $?ROLE# current role (as variable)
  &?ROUTINE   S06   # current sub or method (itself)
- $*STDERRS16   # standard error handle; is an IO object
- $*STDIN S16   # standard input handle; is an IO object
- $*STDOUTS16   # standard output handle; is an IO object
  $*UID # system user id
 
 Note that contextual variables such as C<$*OUT> may have more than

Re: min= (from "Rakudo Built-ins Can Now Be Written In Perl 6")

[David Green]

On 2009-Feb-23, at 11:30 pm, Carl Mäsak wrote:
For what it's worth, I write a lot of Perl 6, and I'm already used  
to it.


OK.  Of course, you might be smarter than the average coder, but I  
agree it's not a huge deal.



On 2009-Feb-24, at 9:29 am, Mark J. Reed wrote:
On Tue, Feb 24, 2009 at 11:16 AM, Ruud H.G. van Tol > wrote:

David Green wrote:

   my $foo is limited(100..200);
   $foo = 5;   # really does $foo = 100


Where does that MySQ smell come from?  Why not undef (or NaN)?
How about Failing instead of any of the above?   Silently replacing  
the assigned value seems like a Bad Idea.


MySQL does stuff like that silently, which is a problem.  But it's OK  
if you ask for it.

In fact, why not all of the above:

my Int where {100 <= $_ <= 200} $foo;
$foo = 5;# failure!

my Int where {100 <= $_ <= 200} $foo is silently-set-to(NaN);
$foo = 5;# does $foo = NaN

my Int where {100 <= $_ <= 200} $foo is auto-kept-within-limits;
$foo = 5;# does $foo = 100

Except with better names...


On 2009-Feb-24, at 10:30 am, Larry Wall wrote:

Alternately, if you want a purer FP solution:
   take $foo clamp 100..200;
   take $bar clamp $midpoint ± $epsilon;


That's a much better name!  But why "take" instead of "$foo clamp=  
100..200"?

(Maybe the answer is "why not?", but I might be missing the point.)


-David

Re: Comparing inexact values (was "Re: Temporal changes")

[Larry Wall]

On Mon, Feb 23, 2009 at 11:54:44PM -0600, Chris Dolan wrote:
> On Feb 23, 2009, at 11:16 PM, Larry Wall wrote:
>
>> if $x ~~ $y ± $epsilon {...}
>>
>> where infix:<±> turns the single value into a range for the  
>> smartmatch.
>
>
> That's very cool.  However, my first impression is that "$y ± $epsilon" 
> maps more naturally to "any($y-$epsilon, $y+$epsilon)" than to a range.

I'm using ±  more in the engineering sense than the mathematical sense.
Maybe there's some way to finesse it to mean both, though I suspect
any such scheme would make it difficult to catch brainos.  If there's
a subtle distinction between

if $x ~~ $y ± $epsilon {...}

and

if $x == $y ± $epsilon {...}

then it will be sure to trip people up.

It would be possible to make it a method:

if $x ~~ $y.within($epsilon)

but that does late binding, too late to give info to the optimizer.
The adverbial solution might or might not have the same problem.
In any case, adverbs on operators tend to be a design smell.

So it might be better as a (very tight?) operator, regardless of
the spelling:

$x ~~ $y within $epsilon

For what it's worth, ± does happen to be in Latin-1, and therefore
officially fair game for Standard Perl.  By the way, the mathematical
definition can be derived from the engineering definition with

if $x == ($x ± $epsilon).minmax.any

The problem with defining it the other direction is that junctions
tend to lose ordering information of their eigenstates, and we can't
just flip mins and maxes when we feel like it, or degenerate null
ranges get broken.

Larry

Re: min= (from "Rakudo Built-ins Can Now Be Written In Perl 6")

[TSa (Thomas Sandlaß)]

On Tuesday, 24. February 2009 07:30:05 Carl Mäsak wrote:
> >    my $foo is limited(100..200);
> >    $foo = 5;                       # really does $foo = 100
>
> Sounds like a good idea for a CPAN module. You can already do
> something similar with the subset keyword, though:
>
>  subset Percentage of Int where { 0 <= $^perc <= 100 };
>
>  sub set_percentage(Percentage $perc is rw, Int $value) {
>try {
>  return $perc = $value;
>  CATCH {
>return $perc = 0 if $value < 0;
>return $perc = 100
>  }
>}
>  };
>
>  my Percentage $p;
>  say set_percentage($p, 50);
>  say set_percentage($p, 101)

I would use a parametric role to implement that:

   role Limited[Order ::Type, Order $lower, Order $upper]
   {
  multi sub infix:<=> (Limited $lhs is rw, Type $rhs --> Type)
  {
 if $rhs before $lower { $lhs.STORE($lower) }
 elsif $rhs after $upper { $lhs.STORE($upper) }
 else { $lhs.STORE($rhs) }
 return $rhs; # provide original for outer scope
  }
   }

   my Limited[Int,0,100] $p;

   $p = 50; # assigns 50
   $p = 101; # assigns 100

This is an interesting example of a role that can be instanciated
without a class unless one regards the generated multi target an
instance of a code class. I used STORE to avoid an infinite recursion
in dispatch of infix:<=>. I could also have called infix:<=>:(Type is rw,
Type --> Type) explicitly. This is necessary if it is overloaded as
well.

I'm unsure if parametric roles work like that, especially the use of
Limited inside the sub.

This role should be an easy candidate for inline expansion by the
compiler. Also the 'is rw' on the first parameter enforces an exact
match so there's no need for dynamic dispatch. I assume that an
'is rw' actually dispatches on the declared container type of the
lhs.


Regards, TSa.
-- 
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

r25529 - docs/Perl6/Spec

[pugs-commits]

Author: lwall
Date: 2009-02-24 20:58:11 +0100 (Tue, 24 Feb 2009)
New Revision: 25529

Modified:
   docs/Perl6/Spec/S02-bits.pod
   docs/Perl6/Spec/S06-routines.pod
Log:
initial whack at describing how settings are snapshotted
and how they interact with invocation of MAIN for settings
that want to install flow control around the user code.


Modified: docs/Perl6/Spec/S02-bits.pod
===
--- docs/Perl6/Spec/S02-bits.pod2009-02-24 18:33:56 UTC (rev 25528)
+++ docs/Perl6/Spec/S02-bits.pod2009-02-24 19:58:11 UTC (rev 25529)
@@ -1823,7 +1823,12 @@
 in which case C remains the scope of the standard language,
 while C represents the scope defining the DSL that functions
 as the setting of the current file.  See also the C<-L>/C<--language>
-switch described in L.
+switch described in L.  If a setting wishes
+to gain control of the main execution, it merely needs to declare
+a C routine as documented in S06.  In this case the ordinary
+execution of the user's code is suppressed; instead, execution
+of the user's code is entirely delegated to the setting's C routine,
+which calls back to the user's lexically embedded code with C.
 
 Note that, since the C of an eval is the eval string itself,
 the C of an eval is the language in effect at the point

Modified: docs/Perl6/Spec/S06-routines.pod
===
--- docs/Perl6/Spec/S06-routines.pod2009-02-24 18:33:56 UTC (rev 25528)
+++ docs/Perl6/Spec/S06-routines.pod2009-02-24 19:58:11 UTC (rev 25529)
@@ -15,7 +15,7 @@
   Date: 21 Mar 2003
   Last Modified: 24 Feb 2009
   Number: 6
-  Version: 102
+  Version: 103
 
 
 This document summarizes Apocalypse 6, which covers subroutines and the
@@ -2370,8 +2370,7 @@
 };
 
 You can get the current routine name by calling C<&?ROUTINE.name>.
-(The outermost routine at a file-scoped compilation unit is always
-named C<&MAIN> in the file's package.)
+Outside of any sub declaration, this call returns failure.
 
 Note that C<&?ROUTINE> refers to the current single sub, even if it is
 declared "multi".  To redispatch to the entire suite under a given short
@@ -2839,6 +2838,34 @@
 particular parameter, an attempt will be made to match it as if it
 had been written C<-a -b -c>.
 
+=head2 Relationship of MAIN routine with lexical setting
+
+The preceding section describes the use of C in the user's code.
+There may also be an implicit C routine supplied by the setting
+of the current compilation unit.  (The C<-n> and C<-p> command-line
+switches are implemented this way.)  In this case the user's mainline
+code is not automatically executed; instead, execution is controlled
+by the setting's C routine.  That routine calls C
+at the point where the user's code is to be lexically inserted (in
+the abstract).  A setting may also call C outside of
+a C routine, in which case it functions as a normal setting,
+and the C merely indicates where the user's code
+goes logically.  (Or from the compiler's point of view, which the
+lexical scope to dump a snapshot of for later use by the compiler
+as the setting for a different compilation unit.)  In this case the
+execution of the user code proceeds as normal.  In fact, the C
+setting ends with a C to dump the C lexical
+scope as the standard setting.  In this sense, C functions as
+an ordinary prelude.
+
+If a C routine is declared both in the setting and in the
+user's code, the setting's C functions as the actual mainline
+entry point.  The user's C functions in an embedded fashion;
+the setting's invocation of C functions as the main
+invocation from the point of view of the user's code, and the
+user's C routine will be invoked at the end of each call to
+C.
+
 =head2 Implementation note on autothreading of only subs
 
 The natural way to implement autothreading for multi subs is to

Re: Comparing inexact values (was "Re: Temporal changes")

[Jon Lang]

Larry Wall wrote:
> So it might be better as a (very tight?) operator, regardless of
> the spelling:
>
>    $x ~~ $y within $epsilon

I like this: it's readable and intuitive.  As well, it leaves ±
available for use in its mathematical sense.

> For what it's worth, ± does happen to be in Latin-1, and therefore
> officially fair game for Standard Perl.  By the way, the mathematical
> definition can be derived from the engineering definition with
>
>    if $x == ($x ± $epsilon).minmax.any
>
> The problem with defining it the other direction is that junctions
> tend to lose ordering information of their eigenstates, and we can't
> just flip mins and maxes when we feel like it, or degenerate null
> ranges get broken.

OTOH, there aren't going to be very many cases where you're going to
want to derive either from the other.  You're more likely to derive
both from the same base stock:

  $y ± 5  # same as ($y - 5) | ($y + 5)
  $y within 5 # same as ($y - 5) .. ($y + 5)

-- 
Jonathan "Dataweaver" Lang

Re: Comparing inexact values (was "Re: Temporal changes")

[Daniel Ruoso]

Em Ter, 2009-02-24 às 08:59 -0800, Larry Wall escreveu:
> I'm using ±  more in the engineering sense than the mathematical
> sense.

What about...

  if $x ~~ [..] $x ± $epsilon {...}

That would mean that $x ± $epsilon in list context returned each value,
where in scalar context returned a junction, so the reduction operator
could do its job...

daniel

Re: Comparing inexact values (was "Re: Temporal changes")

[TSa (Thomas Sandlaß)]

On Tuesday, 24. February 2009 17:59:31 Larry Wall wrote:
> So it might be better as a (very tight?) operator, regardless of
> the spelling:
>
> $x ~~ $y within $epsilon

This is a pretty add-on to smartmatch but I still think
we are wasting a valueable slot in the smartmatch table
by making numeric $x ~~ $y simply mean $x == $y. What
is the benefit?


Regards, TSa.
-- 
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Re: Comparing inexact values (was "Re: Temporal changes")

[Geoffrey Broadwell]

On Tue, 2009-02-24 at 12:31 -0800, Jon Lang wrote:
>   $y ± 5  # same as ($y - 5) | ($y + 5)
>   $y within 5 # same as ($y - 5) .. ($y + 5)

Oh, that's just beautiful.


-'f

Re: Comparing inexact values (was "Re: Temporal changes")

[Jon Lang]

Daniel Ruoso wrote:
> What about...
>
>  if $x ~~ [..] $x ± $epsilon {...}
>
> That would mean that $x ± $epsilon in list context returned each value,
> where in scalar context returned a junction, so the reduction operator
> could do its job...

(I'm assuming that you meant something like "if $y ~~ [..] $x ±
$epsilon {...}", since matching a value to a range that's centered on
that value is tautological.)

Junctions should not return individual values in list context, since
it's possible for one or more of said values to _be_ lists.  That
said, I believe that it _is_ possible to ask a Junction to return a
set of its various values (note: set; not list).  Still, we're already
at a point where:

  if $y ~~ $x within $epsilon {...}

uses the same number of characters and is more legible.  _And_ doesn't
have any further complications to resolve.

-- 
Jonathan "Dataweaver" Lang

Re: Comparing inexact values (was "Re: Temporal changes")

[Daniel Ruoso]

Em Ter, 2009-02-24 às 13:34 -0800, Jon Lang escreveu:
> Daniel Ruoso wrote:
> >  if $y ~~ [..] $x ± $epsilon {...}
> Junctions should not return individual values in list context,

It is not the junction that is returning the individual values, but the
infix:<±> operator...

daniel

Re: Comparing inexact values (was "Re: Temporal changes")

[Jon Lang]

TSa wrote:
> Larry Wall wrote:
>> So it might be better as a (very tight?) operator, regardless of
>> the spelling:
>>
>>     $x ~~ $y within $epsilon
>
> This is a pretty add-on to smartmatch but I still think
> we are wasting a valueable slot in the smartmatch table
> by making numeric $x ~~ $y simply mean $x == $y. What
> is the benefit?

Larry's suggestion wasn't about ~~ vs. ==; it was about "within" as an
infix operator vs. "within" as a method or an adverb.

-- 
Jonathan "Dataweaver" Lang

Re: Comparing inexact values (was "Re: Temporal changes")

[Jon Lang]

On Tue, Feb 24, 2009 at 1:39 PM, Daniel Ruoso  wrote:
> Em Ter, 2009-02-24 às 13:34 -0800, Jon Lang escreveu:
>> Daniel Ruoso wrote:
>> >  if $y ~~ [..] $x ± $epsilon {...}
>> Junctions should not return individual values in list context,
>
> It is not the junction that is returning the individual values, but the
> infix:<±> operator...

Hmm... true point.  Thinking through it some more, I'm reminded of an
early proposal to do something similar with square roots in
particular, and with non-integer exponents in general.  e.g., "sqrt(4)
=== ±2".  IIRC, the decision was made that such a capability would
work best as part of an advanced math-oriented module, and that things
should be arranged such that sqrt($x).[0] in that advanced module
would be equivalent to sqrt($x) in Perl's default setting.  That would
mean that sqrt(4) would have to produce (+2, -2) in list context,
rather than (-2, +2) - which, in turn, would mean that ±2 should do
likewise.  And however prefix:<±> works, infix:<±> should follow suit,
returning addition first and subtraction second.

Which would further mean that you should use the reversal metaoperator as well:

  if $y ~~ [R..] $x ± $epsilon {...}

-- 
Jonathan "Dataweaver" Lang

Re: Comparing inexact values (was "Re: Temporal changes")

[Doug McNutt]

Thinking about what I actually do. . .

A near equal test of a float ought to be a fractional error based on 
the current value of the float.


$x  tested for between $a*(1.0 + $errorfraction) and $a*(1.0 - $errorfraction)

If you're dealing with propagation of errors during processing of 
data the fractional error is usually the one that's important. 
Finances might be different  but floating dollars have their own set 
of problems relating to representation of decimal fractions.

--

--> A fair tax is one that you pay but I don't <--

Re: Comparing inexact values (was "Re: Temporal changes")

[Jon Lang]

Doug McNutt wrote:
> Thinking about what I actually do. . .
>
> A near equal test of a float ought to be a fractional error based on the
> current value of the float.
>
> $x  tested for between $a*(1.0 + $errorfraction) and $a*(1.0 -
> $errorfraction)
>
> If you're dealing with propagation of errors during processing of data the
> fractional error is usually the one that's important. Finances might be
> different  but floating dollars have their own set of problems relating to
> representation of decimal fractions.

Half-baked idea here: could we somehow use some dwimmery akin to
Whatever magic to provide some meaning to a postfix:<%> operator?
Something so that you could say:

  $x within 5%

And it would translate it to:

  $x within 0.05 * $x

?

Something along the lines of:

1. infix: sets Whatever to its lhs while evaluating its rhs
2. postfix:<%> returns the requested percentage of Whatever; if
Whatever is undefined, return the requested percentage of 1.

-- 
Jonathan "Dataweaver" Lang

S14 markup

[Jon Lang]

Someone should go through the Parametric Roles section and properly
indent the code blocks.  They're not rendering properly at
http://perlcabal.org/syn/S14.html

-- 
Jonathan "Dataweaver" Lang

r25536 - docs/Perl6/Spec

[pugs-commits]

Author: lwall
Date: 2009-02-25 02:58:36 +0100 (Wed, 25 Feb 2009)
New Revision: 25536

Modified:
   docs/Perl6/Spec/S14-roles-and-parametric-types.pod
Log:
indent examples


Modified: docs/Perl6/Spec/S14-roles-and-parametric-types.pod
===
--- docs/Perl6/Spec/S14-roles-and-parametric-types.pod  2009-02-24 22:42:08 UTC 
(rev 25535)
+++ docs/Perl6/Spec/S14-roles-and-parametric-types.pod  2009-02-25 01:58:36 UTC 
(rev 25536)
@@ -409,27 +409,27 @@
 wanted to factor out a "greet" method into a role, which takes somebody's name 
and greets 
 them. We want to parameterize it on the greeting.
 
-role Greet[Str $greeting] {
-method greet() { say "$greeting!"; }
-}
-class EnglishMan does Greet["Hello"] { }
-class Slovak does Greet["Ahoj"] { }
-class Lolcat does Greet["OH HAI"] { }
-EnglishMan.new.greet(); # Hello
-Slovak.new.greet(); # Ahoj
-Lolcat.new.greet(); # OH HAI
+role Greet[Str $greeting] {
+method greet() { say "$greeting!"; }
+}
+class EnglishMan does Greet["Hello"] { }
+class Slovak does Greet["Ahoj"] { }
+class Lolcat does Greet["OH HAI"] { }
+EnglishMan.new.greet(); # Hello
+Slovak.new.greet(); # Ahoj
+Lolcat.new.greet(); # OH HAI
 
 Similarly, we could do a role for requests.
 
-role Request[Str $statement] {
-method request($object) { say "$statement $object?"; }
-}
-class EnglishMan does Request["Please can I have a"] { }
-class Slovak does Request["Prosim si"] { }
-class Lolcat does Request["I CAN HAZ"] { }
-EnglishMan.new.request("yorkshire pudding");
-Slovak.new.request("borovicka");
-Lolcat.new.request("CHEEZEBURGER");
+role Request[Str $statement] {
+method request($object) { say "$statement $object?"; }
+}
+class EnglishMan does Request["Please can I have a"] { }
+class Slovak does Request["Prosim si"] { }
+class Lolcat does Request["I CAN HAZ"] { }
+EnglishMan.new.request("yorkshire pudding");
+Slovak.new.request("borovicka");
+Lolcat.new.request("CHEEZEBURGER");
 
 Sadly, the Slovak output sucks here. Borovicka is the nominative form of the 
word, and we 
 need to decline it into the accusative case. But some languages don't care 
about that, and 
@@ -438,27 +438,27 @@
 the right one for you. So we write something to produce the accusative case in 
Slovak and 
 pass it in. Here's the new code.
 
-role Request[Str $statement] {
-method request($object) { say "$statement $object?"; }
-}
-role Request[Str $statement, &transform] {
-method request($object) {
-say "$statement " ~ transform($object) ~ "?";
+role Request[Str $statement] {
+method request($object) { say "$statement $object?"; }
 }
-}
-module Language::Slovak {
-sub accusative($nom) {
-# ...and before some smartass points it out, I know
-# I'm missing some of the masculine animate declension...
-return $nom.subst(/a$/, 'u');
+role Request[Str $statement, &transform] {
+method request($object) {
+say "$statement " ~ transform($object) ~ "?";
+}
 }
-}
-class EnglishMan does Request["Please can I have a"] { }
-class Slovak does Request["Prosim si", &Language::Slovak::accusative] { }
-class Lolcat does Request["I CAN HAZ"] { }
-EnglishMan.new.request("yorkshire pudding");
-Slovak.new.request("borovicka");
-Lolcat.new.request("CHEEZEBURGER");
+module Language::Slovak {
+sub accusative($nom) {
+# ...and before some smartass points it out, I know
+# I'm missing some of the masculine animate declension...
+return $nom.subst(/a$/, 'u');
+}
+}
+class EnglishMan does Request["Please can I have a"] { }
+class Slovak does Request["Prosim si", &Language::Slovak::accusative] { }
+class Lolcat does Request["I CAN HAZ"] { }
+EnglishMan.new.request("yorkshire pudding");
+Slovak.new.request("borovicka");
+Lolcat.new.request("CHEEZEBURGER");
 
 Which means we can now properly order our borovicka in Slovakia, which is 
awesome. Until 
 you do it in a loop and find the Headache['very bad'] role got mixed into 
yourself 
@@ -466,23 +466,23 @@
 
 Role attributes can also be used to initialise attributes:
 
- role AttrParams[$a, $b] {
- has $.x = $a;
- has $.y = $b;
- }
+role AttrParams[$a, $b] {
+has $.x = $a;
+has $.y = $b;
+}
 
 ...and to constrain types.  
 
- role TypeParams[::T] {
-method x(T $x) { return "got a " ~ T ~ " it was $x" }
- }
+role TypeParams[::T] {
+   method x(T $x) { return "got a " ~ T ~ " it was $x" }
+}
 
- class IntShower does TypeParams[Int] { } # Shows Ints
- class StrShower does TypeParams[Str] { } # Shows Strs
+class IntShower does TypeParams[Int] { } # Shows Ints
+class StrShower does TypeParams[Str] { } # Shows Strs
 
- print IntShower.new.x(42); # Prints 'got a Int it was 42'
- print StrShower.new.x("OH HAI"); # Prints 'got a Str it was OH HAI'
- p

Re: Synopsis for Signatures?

[Jon Lang]

On Fri, Feb 13, 2009 at 11:49 AM, Larry Wall  wrote:
> On Fri, Feb 13, 2009 at 10:24:14AM -0800, Jon Lang wrote:
> : Given that signatures have grown well beyond their origins as
> : subroutine parameter lists, and given that signatures have their own
> : syntax, perhaps they should be moved out of S06?  I could see S08
> : being retasked to address signatures (and perhaps captures, given the
> : intimate connection between these two), since its original purpose
> : (i.e., references) has been deprecated.
>
> That has been the intent, though nobody's got around to doing it.

Some questions:

Can anyone think of a use for an invocant or a slurpy code block in a
signature that's being used to initialize variables or to parameterize
a role?

Can anyone think of a use for named parameters in a signature that's
being used to initialize variables?

In general, what features of subroutine signatures might not be
applicable to role signatures and/or variable declaration signatures?

-- 
Jonathan "Dataweaver" Lang

r25538 - docs/Perl6/Spec

[pugs-commits]

Author: wayland
Date: 2009-02-25 04:48:08 +0100 (Wed, 25 Feb 2009)
New Revision: 25538

Modified:
   docs/Perl6/Spec/S05-regex.pod
Log:
Added Predefined Metasyntax section, as per richard++


Modified: docs/Perl6/Spec/S05-regex.pod
===
--- docs/Perl6/Spec/S05-regex.pod   2009-02-25 03:39:17 UTC (rev 25537)
+++ docs/Perl6/Spec/S05-regex.pod   2009-02-25 03:48:08 UTC (rev 25538)
@@ -1617,6 +1617,60 @@
 
 =back
 
+=head2 Predefined Metasyntax
+
+The following symbols are predefined entries in the metasyntax.  
+
+=over
+
+=item * ident
+
+=item * null
+
+=item * fail
+
+=item * upper
+
+=item * lower
+
+=item * alpha
+
+=item * digit
+
+=item * xdigit
+
+=item * space
+
+=item * print
+
+=item * graph
+
+=item * blank
+
+=item * cntrl
+
+=item * punct
+
+=item * alnum
+
+=item * sp
+
+=item * lt
+
+=item * gt
+
+=item * dot
+
+=item * ws
+
+=item * wb
+
+=item * before
+
+=item * after
+
+=back
+
 =head1 Backslash reform
 
 =over

Re: Rules mentioned in specifications, etc

[Timothy S. Nelson]

On Tue, 24 Feb 2009, Larry Wall wrote:


On Tue, Feb 24, 2009 at 02:04:05PM +0300, Richard Hainsworth wrote:

Here is a list of rules (see below) that are spread around the language
design documents, but which lack a home in which they are systematically
canonically defined.

I suggest they be added to the new S28 (which is possible if S28 is
special-names, not special-variables)


If they're provided by the standard regex implementation, they
should go in S05, where many of them are already.  For now you could
just add another bullet item listing them all.  If you want to turn
some of those bullet lists into a real outline while you're at it,
feel free.  :)


I've added them in a "Predefined Metasyntax" section.

HTH,

-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y-

-END GEEK CODE BLOCK-

Re: r25490 - docs/Perl6/Spec

[Brandon S. Allbery KF8NH]

On 2009 Feb 22, at 22:47, pugs-comm...@feather.perl6.nl wrote:

+$?PUGS_VERSION # Pugs version (not canonical)
+$*PUGS_HAS_HSPLUGINS # True if Pugs was compiled with support  
for hsplugins

+ # (not canonical)


These should not be part of the standard.  But while Pugs is free to  
keep providing them, I would suggest the more general:


> $?PERL6_IMPLEMENTATION (pugs, rakudo, ...)
> $?PERL6_IMPL_VERSION
> $?PERL6_IMPL_FEATURES (it's possible this should be part of %?CONFIG)

(BTW, why is a "this impl compiled with support for" not a ? twigil?   
It's not going to change at runtime.)


+There were threads on p6l about unifying all variables which  
concern the OS or
+the VM ($*UID, $*PROGRAM_NAME, etc.) into two variables, $?ENV  
(compile-time
+environment) and $*ENV (runtime environment). Larry did like the  
idea, but


%?PERL6_ENV
%*PERL6_ENV

BTW, I also agree with the earlier observation that $*OUT vs. $*DEFOUT  
(etc.) both violates Huffman coding and encourages use of the wrong  
one.  $*OUT vs. $*STDOUT (meanings inverted relative to the above)  
maybe?


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
Description: This is a digitally signed message part

Re: Comparing inexact values (was "Re: Temporal changes")

[Larry Wall]

On Tue, Feb 24, 2009 at 04:54:35PM -0800, Jon Lang wrote:
: Half-baked idea here: could we somehow use some dwimmery akin to
: Whatever magic to provide some meaning to a postfix:<%> operator?
: Something so that you could say:
: 
:   $x within 5%
: 
: And it would translate it to:
: 
:   $x within 0.05 * $x
: 
: ?
: 
: Something along the lines of:
: 
: 1. infix: sets Whatever to its lhs while evaluating its rhs
: 2. postfix:<%> returns the requested percentage of Whatever; if
: Whatever is undefined, return the requested percentage of 1.

The semantic magic is trivial; what we'd say is that if C has
a 1-ary closure for its right argument, it calls that with its left
argument to calculate the epsilon.  The syntactic magic is another
matter.  We could easily define postfix:<%> that just translates 5% to
{ 0.05 * $_ }, but we'd have to weigh that against the infix use of %.
So basically it could be done, but we'd have to require whitespace
on the infix:<%> form.

Interestingly, though, assuming we have multies for Code:($) as well
as as Whatever, things like $x * 5% would also work automatically.
Which we'll probably have anyway, if we want things like

grep (* % 3) == 1, @list

to work.  It basically looks like Whatever is mutating into a
mechanism for currying 1-ary functions, though of course it won't
work if you try to curry infix:<..> with it, or any other operator
that treats Whatever idiosyncratically.  You'd basically have to
know which operators Do What You Mean, which could be construed as an
arbitrary list.  Makes me wonder if this is one of those "new mistakes"
we're trying to make with Perl 6.  :)

But my gut-level feel is that, although this is a feature that
you can easily shoot your foot off with, the actual code comes
out quite readable.  And I think people can pretty easily learn
the default transformation of (* op 42) to { $_ op 42 }.  On the other
hand, * is so hardwired in to our consciences as wildcarding and
quantifying that constructs like "abc" xx * also look natural.

So I'm gambling that this is a new mistake we want to make.  The
alternative would be to create a different way of writing simple
closures, but we already have that in { $_ op 42 } if you want it.

I do very much like the fact that, unlike in Haskell, you curry
with an explicit placeholder, not by leaving things out.  (Of course,
this is a requirement in Perl anyway because its parser depends
heavily on term/infix alternation.)

Larry

Re: [perl #63408] [PATCH] use PCT::HLLCompiler.addstage()

[Patrick R. Michaud]

On Sun, Feb 22, 2009 at 06:53:33PM -0800, Chris Dolan wrote:
> This trivial patch to perl6.pir changes Perl6::Compiler to use its  
> superclass' addstage() mutator instead of directly editing the  
> @stages attribute.  This should make for better forward  
> compatibility, as it avoids repeating the list of stages.

Note that the entire stages interface and implementation
are expected to change soon.

Pm

Re: r25490 - docs/Perl6/Spec

[Brandon S. Allbery KF8NH]

On 2009 Feb 23, at 22:43, Timothy S. Nelson wrote:

On Mon, 23 Feb 2009, jason switzer wrote:
On Sun, Feb 22, 2009 at 9:47 PM,   
wrote:

+$*PROGRAM_NAME # name of the program being executed


How does this differ from $*EXECUTABLE_NAME?


Good question.  Anyone?


I would assume $*PROGRAM_NAME is the script, and $*EXECUTABLE_NAME is  
the name of the interpreter.  Or the same as $*PROGRAM_NAME if it has  
been compiled to native code?  Not sure this is useful, which suggests  
you don't so much want $*EXECUTABLE_NAME as $?PERL6_IMPLEMENTATION  
(see my earlier message).



+&?ROUTINE  # current sub or method (itself, see S06)
+@?ROUTINE  # current subs or methods (themselves)


I'm sure this is a typo for $?ROUTINE. Besides, I think $?SUB makes  
more

sense.


Well, Larry says this in S02:

   &?ROUTINE   Which routine am I in?
   @?ROUTINE   Which nested routines am I in?
   &?BLOCK Which block am I in?
   @?BLOCK Which nested blocks am I in?


&?ROUTINE is a CODE ref to the current routine.  @?ROUTINE is an array  
of CODE refs.  I assume if you want a name you can invoke a method on  
&?ROUTINE to retrieve it (may return undef if it's an anonymous CODE  
ref).



+ $* and $# have been deprecated half of forever and are gone.  $[
+ is a fossil that I suppose could turn into an evil pragma, if we
+ try to translate it at all.  (Frees up * twigil for $*FOO syntax.)


I'm not even sure this makes sense to me. Is this saying that $*  
and $# are

largely not in use anymore (in perl6)?


	Read the section on "twigils" in S02.  Hopefully things will make  
more sense after that.  It says that $* is no longer a separate  
variable, but is used for $*OSNAME, $*VM, and the like.


The perl5 $*, $#, $[ have been deprecated for a long time, and are not  
in perl6 at all.  (And I would strongly discourage any attempt to  
support $[ by pragma.  But @Larry.grep: "allb...@ece.cmu.edu" is  
Failure :)


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
Description: This is a digitally signed message part

Re: Signals question for S16: IPC / IO / Signals

[Timothy S. Nelson]

On Tue, 24 Feb 2009, Daniel Ruoso wrote:


These signal events will
presumably be processed by some kind of underlying event handler that
mediates among any and all user-visible event handlers within the
process.


Now *that* made my eyes shine. ;)


I'm in favour of discussing this idea too (I like it myself :) ).


Adding a library-agnostic event loop at the core is something that might
be very much powerfull. The AnyEvent p5 modules is one of the most
interesting things in this regard in CPAN, it works with any event loop
(including POE, Event and EV).

So the default code that raises the control exception for each signal
would be registered in this event loop, as well as any code that wanted
to perform asynchronous IO, which would just register a listener for
"can_read" in soe IO handle.

We just need to sketch an API around that...


	I've never heard of AnyEvent before now, but after a quick skim over, 
I'd say the AnyEvent API looks good.  Any opinions on that?



-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y-

-END GEEK CODE BLOCK-

Re: Temporal changes

[Brandon S. Allbery KF8NH]

On 2009 Feb 23, at 8:34, Ruud H.G. van Tol wrote:

Martin D Kealey wrote:

Ah, we want a noun that isn't readily confused as an adjective.
Suitable terms might include: Instant Jiffy Juncture Moment  
Occasion Snap Tick ...


Once :)


"Then"?

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
Description: This is a digitally signed message part

Re: r25490 - docs/Perl6/Spec

[Timothy S. Nelson]

On Tue, 24 Feb 2009, Brandon S. Allbery KF8NH wrote:


On 2009 Feb 23, at 22:43, Timothy S. Nelson wrote:

On Mon, 23 Feb 2009, jason switzer wrote:

On Sun, Feb 22, 2009 at 9:47 PM,  wrote:

+$*PROGRAM_NAME # name of the program being executed


How does this differ from $*EXECUTABLE_NAME?


Good question.  Anyone?


I would assume $*PROGRAM_NAME is the script, and $*EXECUTABLE_NAME is the 
name of the interpreter.  Or the same as $*PROGRAM_NAME if it has been 
compiled to native code?  Not sure this is useful, which suggests you don't 
so much want $*EXECUTABLE_NAME as $?PERL6_IMPLEMENTATION (see my earlier 
message).


	I discovered where to answer this.  Both $EXECUTABLE_NAME and 
$PROGRAM_NAME are documented in perl 5's perlvar page.  See that documentation 
for more information.


:)


-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y-

-END GEEK CODE BLOCK-

AnyEvent

[Timothy S. Nelson]

Am I right in guessing that the AnyEvent stuff should go in S17 ?

:)


-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y-

-END GEEK CODE BLOCK-

@*INPLACE_AUTOSPLIT_FIELDS

[Timothy S. Nelson]

In the table I'm assembling, the following entry was added:

 Perl 5  Perl 6 Comment
 --- ------
 @F  @*INPLACE_AUTOSPLIT_FIELDS   ..or some such


	Can I just speak in favour of retaining the @F name?  My reason for 
this is because it's used in one-liners, and who wants to type 
@*INPLACE_AUTOSPLIT_FIELDS in a one-liner?  It's enough to make one reach for 
awk.


:)


-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y-

-END GEEK CODE BLOCK-

r25539 - docs/Perl6/Spec

[pugs-commits]

Author: lwall
Date: 2009-02-25 06:19:17 +0100 (Wed, 25 Feb 2009)
New Revision: 25539

Modified:
   docs/Perl6/Spec/S05-regex.pod
Log:
document which assertions are on the endangered list


Modified: docs/Perl6/Spec/S05-regex.pod
===
--- docs/Perl6/Spec/S05-regex.pod   2009-02-25 03:48:08 UTC (rev 25538)
+++ docs/Perl6/Spec/S05-regex.pod   2009-02-25 05:19:17 UTC (rev 25539)
@@ -1627,8 +1627,12 @@
 
 =item * null
 
+Deprecated, use 
+
 =item * fail
 
+Deprecated, use 
+
 =item * upper
 
 =item * lower
@@ -1655,12 +1659,20 @@
 
 =item * sp
 
+Deprecated, use ' '
+
 =item * lt
 
+Deprecated, use '<'
+
 =item * gt
 
+Deprecated, use '>'
+
 =item * dot
 
+Deprecated, use '.'
+
 =item * ws
 
 =item * wb

Re: Signals question for S16: IPC / IO / Signals

[Timothy S. Nelson]

On Tue, 24 Feb 2009, Daniel Ruoso wrote:


Em Seg, 2009-02-23 às 19:49 -0800, Larry Wall escreveu:

On Tue, Feb 24, 2009 at 04:01:40PM +1300, Martin D Kealey wrote:
: Conceptually I think they should all go in add-on(s), however I suspect that
: when an exception is thrown inside a signal handler, cleanly unwinding the
: call chain will need special support in the core.
Which should already be there, presumably, as defined in S04 and such.
Some signals like CONT want to get translated to resumable exceptions
and others like SEGV to non-resumable.


Agreed, every signal could just be a control exception with no special
behavior (except being potentially resumable), simply:

* ControlExceptionSigHUP
* ControlExceptionSigTERM
* ControlExceptionSigINT
* and so on...

Then defining a signal handler is just a matter of a CONTROL block that
catches that exception. This would mean something that is very important
in terms of concurrency, which is that the signal handling code that is
registered in the OS is simply there to raise the exception, once that
happens, the regular execution flows to the CONTROL block.

We would just need to decide if a signal should be seen by all of the
concurrent threads (green-threads or os-threads), or if there is a
"main" thread that would receive the exceptions or how the user can
tweak that behavior...


	Well, now that we seem(?) to have eliminated the need for %*SIG, could 
we use that for defining which thread gets the signals?


:)


-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y-

-END GEEK CODE BLOCK-

r25540 - docs/Perl6/Spec

[pugs-commits]

Author: wayland
Date: 2009-02-25 06:31:24 +0100 (Wed, 25 Feb 2009)
New Revision: 25540

Modified:
   docs/Perl6/Spec/S16-io.pod
   docs/Perl6/Spec/S28-special-names.pod
Log:
S16: Added some information about signal processing.  
S28: Pushed the Perl5 to Perl6 special variable translation table as far as 
possible 
without receiving more information (well, maybe I could fix one or two 
things...)


Modified: docs/Perl6/Spec/S16-io.pod
===
--- docs/Perl6/Spec/S16-io.pod  2009-02-25 05:19:17 UTC (rev 25539)
+++ docs/Perl6/Spec/S16-io.pod  2009-02-25 05:31:24 UTC (rev 25540)
@@ -71,6 +71,24 @@
 S32-setting-library/IO.pod.  The main functions used are listed in S29 with 
references to 
 S32-setting-library/IO.pod.  
 
+=head1 POSIX Signals
+
+The standard POSIX signals simply raise control exceptions that are handled as 
normal 
+through the signal handler, except for the fact that some of them are 
resumeable.  The 
+exception names are:
+
+=over
+
+=item * ControlExceptionSigHUP
+
+=item * ControlExceptionSigTERM
+
+=item * ControlExceptionSigINT
+
+=back
+
+See L for details on how to handle exceptions.  
+
 =head1 Additions
 
 Please post errors and feedback to perl6-language.  If you are making

Modified: docs/Perl6/Spec/S28-special-names.pod
===
--- docs/Perl6/Spec/S28-special-names.pod   2009-02-25 05:19:17 UTC (rev 
25539)
+++ docs/Perl6/Spec/S28-special-names.pod   2009-02-25 05:31:24 UTC (rev 
25540)
@@ -137,104 +137,109 @@
 
 =back
 
-=head1 PERL 6 / PERL 5 COMPARISON
+=head2 Perl5 to Perl6 special variable translation
 
-=over 4
+If a column has a "-" in it, it means that item is unavailable in that version 
of Perl.  
 
-Because a blank entry in either column could be taken to mean either 
-"not in Perl 6" or "unknown", the information as presented 
-below presumes an entry in both columns for every entry. 
-Options are:
-
-=over 6
-
-thing  as the var in question
-
--  for "not in this Perl"
-
-?  for "don't know yet"
-
-=back
-
-Other organizational
-schemes may become appropriate when the table is more complete.
-
-=back
-
  Perl 5  Perl 6 Comment
  --- ------
  STDIN   $*IN   See S16; actual variable is $PROCESS::IN
  STDOUT  $*OUT  See S16; actual variable is $PROCESS::OUT
  STDERR  $*ERR  See S16; actual variable is $PROCESS::ERR
- $_  $_ More lexically aware
+ $_ $ARG $_ More lexically aware
  $_[1],$_[2]..   $^a,$^b..  
  $a,$b   -  Just params to anonymous block
  -   $/ Object with results of last regex match
  $1,$2,$3... $1,$2,$3...
- $&, $MATCH  $<>
- $`, $PREMATCH   substr based on $/.from
- $', $POSTMATCH  substr based on $/.to
+ $& $MATCH   $<>
+ $` $PREMATCHsubstr based on $/.from
+ $' $POSTMATCH   substr based on $/.to
  $+  -  But info can now be retrieved from $/
  $^N $*MOST_RECENT_CAPTURED_MATCH  ...or some such. 
-  or $/[-$n]   ...or omit 
+   or $/[-$n]   ...or omit 
  @-  $1.start, etc
  @+  $1.end, etc.
- $*  -
- $#  -
- $.  $*IN.input_record_number()
- $/  $*IN.input_record_separator()
+ %!  -
+ $[  -  This feature has been removed
+ $*  -  Deprecated long ago
+ $#  -  Deprecated long ago
+ $^H -  These were only ever internal anyway
+ %^H -
+ -   $! Current exception (see L)
+ $! $ERRNO $OS_ERROR -  Can get some info from new $!
+ $?  $CHILD_ERROR-
+ $@  $EVAL_ERROR -  Just throws an exception now (see 
L)
+ $^E -
+ $. $NR  $*IN.input_record_number()
+ $/ $RS  $*IN.input_record_separator()
  $|  $*OUT.autoflush()
- $,  $*OUT.output_field_separator()
+ $, $OFS $*OUT.output_field_separator()
  $\  $*OUT.output_record_separator()
- $$, $PID$*PID
- $<, $UID$*UID  Real UID (User ID)
- $(, $GID$*GID  Real GID (Group ID)
- $>, $EUID   $*EUID Effective UID
- $), $EGID   $*EGID Effective GID
- $0, $PROGRAM_NAME   $*PROGRAM_NAME
- $^C, $COMPILING $*COMPILING
- $^D, $DEBUGGING $*DEBUGGING
- $^F, $SYS_FD_MAX$*SYS_FD_MAX   ...or some such
- $^I, $INPLACE_EDIT  $*INPLACE_EDIT ...or some such
+ $" $LIST_SEPARATOR  -
+ $; $SUBSEP  -
+ $$ $PID $*P

Re: Comparing inexact values (was "Re: Temporal changes")

[Martin D Kealey]

On Tue, 24 Feb 2009, Jon Lang wrote:
>   $y ± 5  # same as ($y - 5) | ($y + 5)
>   $y within 5 # same as ($y - 5) .. ($y + 5)

I suspect that we're running against Huffman here, given the likely
usage -- ranges *should* be used at pretty much every floating point
"equality" test, whereas "any(-x,+x)" would mostly be useful for
expressing solutions to polynomials.

Perhaps we could define infix:± as a range generator and prefix:± as a
set generator:

  $y + ±5   # same as ($y - 5) | ($y + 5) (also same as $y - ±5)
  $y ± 5# same as ($y - 5) .. ($y + 5)

-Martin

Re: r25490 - docs/Perl6/Spec

[Timothy S. Nelson]

On Tue, 24 Feb 2009, Brandon S. Allbery KF8NH wrote:


+ $* and $# have been deprecated half of forever and are gone.  $[
+ is a fossil that I suppose could turn into an evil pragma, if we
+ try to translate it at all.  (Frees up * twigil for $*FOO syntax.)


I'm not even sure this makes sense to me. Is this saying that $* and $# 
are

largely not in use anymore (in perl6)?


	Read the section on "twigils" in S02.  Hopefully things will make 
more sense after that.  It says that $* is no longer a separate variable, 
but is used for $*OSNAME, $*VM, and the like.


The perl5 $*, $#, $[ have been deprecated for a long time, and are not in 
perl6 at all.  (And I would strongly discourage any attempt to support $[ by 
pragma.  But @Larry.grep: "allb...@ece.cmu.edu" is Failure :)


	I'm in favour of retaining the $[ functionality, but lets give it some 
name like $*INDEX_BEGINNING or something like that, so that it's quite long 
for people to type :).


:)


-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y-

-END GEEK CODE BLOCK-

Re: Comparing inexact values (was "Re: Temporal changes")

[Martin D Kealey]

On Wed, 25 Feb 2009, I wrote:
>   $y + ±5   # same as ($y - 5) | ($y + 5)   (also same as $y - ±5)
>   $y ± 5# same as ($y - 5) .. ($y + 5)

A further question: should such ranges be [closed], (open) or [half-open)?

I would argue for half-open because then exactly one of a set of consecutive
ranges will match; back to the original question, I'd only expect one match
from:

$time ~~ $date-yesterday
$time ~~ $date-today
$time ~~ $date-tomorrow

even if $time falls precisely on midnight.

-Martin

r25541 - docs/Perl6/Spec

[pugs-commits]

Author: wayland
Date: 2009-02-25 07:08:52 +0100 (Wed, 25 Feb 2009)
New Revision: 25541

Modified:
   docs/Perl6/Spec/S28-special-names.pod
Log:
S28: Incorporated some more stuff from the old documentation lower down, and a 
few 
variables from S02.  


Modified: docs/Perl6/Spec/S28-special-names.pod
===
--- docs/Perl6/Spec/S28-special-names.pod   2009-02-25 05:31:24 UTC (rev 
25540)
+++ docs/Perl6/Spec/S28-special-names.pod   2009-02-25 06:08:52 UTC (rev 
25541)
@@ -50,6 +50,7 @@
  $?CLASS   # current class (as variable)
  %?CONFIG  # configuration hash
  $=DATA# data block handle (=begin DATA ... =end)
+ $?DISTROS02   # Which OS distribution am I compiling under
  $*EGID# effective group id
  %*ENV # system environment
  $*ERR   S16   # Standard error handle; is an IO object
@@ -71,16 +72,20 @@
  $?OSVER   # operating system version compiled for
  $*OSVER   # operating system version running under
  $*OUT   S16   # Standard output handle; is an IO object
+ $?PARSERS02   # Which Perl grammar was used to parse this 
statement?
  $?PACKAGE # current package (as object)
  $?PACKAGENAME   S10   # name of current package
- $?PERLVER # perl version compiled for
- $*PERLVER # perl version running under
+ $?PERL  S02   # Which Perl am I compiled for?
+ $*PERL# perl version running under
  $*PROGRAM_NAME# name of the program being executed
  $*PID # system process id
  ::?ROLE   # current role (as package name)
  $?ROLE# current role (as variable)
  &?ROUTINE   S06   # current sub or method (itself)
+ $?SCOPE S02   # Current "my" scope
  $*UID # system user id
+ $?VMS02   # Which virtual machine am I compiling under
+ $?XVM   S02   # Which virtual machine am I cross-compiling for
 
 Note that contextual variables such as C<$*OUT> may have more than
 one current definition in the outer dynamic context, in which case
@@ -166,10 +171,11 @@
  $^H -  These were only ever internal anyway
  %^H -
  -   $! Current exception (see L)
- $! $ERRNO $OS_ERROR -  Can get some info from new $!
- $?  $CHILD_ERROR-
- $@  $EVAL_ERROR -  Just throws an exception now (see 
L)
- $^E -
+ $! $ERRNO $OS_ERROR -  Use shiny new $!
+ $?  $CHILD_ERROR-  Use shiny new $!
+ $@  $EVAL_ERROR -  Use shiny new $!
+ $^E -  Use shiny new $!
+ $^S -
  $. $NR  $*IN.input_record_number()
  $/ $RS  $*IN.input_record_separator()
  $|  $*OUT.autoflush()
@@ -203,14 +209,22 @@
  ARGVOUT $*ARGVOUT  Another IO object
  @F  @*INPLACE_AUTOSPLIT_FIELDS   ..or some such
  %ENV%*ENV
+ ${^OPEN}-  This was internal; forget it
 
 =head2 Old stuff for p5/p6 comparison
 
 This section will eventually die, but for now, it contains some old 
information on which 
-Perl5 special variables will turn into Perl6 special variables.  
+Perl5 special variables will turn into Perl6 special variables.  The reason 
they are 
+retained is either:
 
-=over 4
+=over
 
+=item * Their status is undecided
+
+=item * They have some commentary on stuff that needs consideration
+
+=back
+
 Because a blank entry in either column could be taken to mean either 
 "not in Perl 6" or "unknown", the information as presented 
 below presumes an entry in both columns for every entry. 
@@ -229,29 +243,25 @@
 Other organizational
 schemes may become appropriate when the table is more complete.
 
-=back
-
  *** XXX the columns seem to have switched! *
 
  ?   ${^ENCODING}
+ ?   ${^UNICODE} Pending S15 Unicode
 
-
  -   $^V $PERL_VERSION
  -   $] version + patchlevel / 1000 of Perl interpreter
 Replacement for the above two is unclear.
+Is this $?PERL?  
 
 
- -   ${^OPEN}
+ ?   ${^TAINT}  Pending, among other things, infectious trait spec
 
- ?   ${^TAINT}
- ?   ${^UNICODE}
-
  -   $^W $WARNING   Probably gone. But we need a reasonably
 granular way to suppress specific (groups
 of) warnings within both lexical and 
 dynamic scopes.
 
- ?   $ARGV
+ ?   $ARGV   Can this be handled with $*IN.name, etc?  
  
  ?   @INCUncertain but we need a way to add to search path
  ?   %INCUncertain but we need a way to add to sea

S28 update?

[Timothy S. Nelson]

	Is there any chance someone could have a look at the stuff in the 
section labelled "Old stuff for p5/p6 comparison" of S28, and give me some 
info on what's going on with them?  In particular, I want to know:


-   What's going to replace $^V  / $PERL_VERSION / $] -- is it $?PERL ?
-   What's going to replace $^W / $WARNING ?
-   Am I right about $ARGV being replaceable with $*IN.name(), or have I
misunderstood $ARGV?
-   What's going to replace @INC / %INC ?
-   Is there going to be a replacement for @_ ?

If anyone knows the answers to any of these, please let me know.

Thanks,


-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y-

-END GEEK CODE BLOCK-

Re: Comparing inexact values (was "Re: Temporal changes")

[Larry Wall]

On Wed, Feb 25, 2009 at 07:03:27PM +1300, Martin D Kealey wrote:
: On Wed, 25 Feb 2009, I wrote:
: >   $y + ±5   # same as ($y - 5) | ($y + 5)   (also same as $y - ±5)
: >   $y ± 5# same as ($y - 5) .. ($y + 5)

That seems a little cheesy to me.

: A further question: should such ranges be [closed], (open) or [half-open)?
: 
: I would argue for half-open because then exactly one of a set of consecutive
: ranges will match; back to the original question, I'd only expect one match
: from:
: 
:   $time ~~ $date-yesterday
:   $time ~~ $date-today
:   $time ~~ $date-tomorrow
: 
: even if $time falls precisely on midnight.

Half-open, certainly, so really same as ($y - 5) ..^ ($y + 5).

Larry