Re: Signature for the series operator

2009-06-26 Thread Jon Lang
On Thu, Jun 25, 2009 at 1:20 PM, Moritz Lenzmor...@faui2k3.org wrote:
 Hi,

 I had the pleasure to implement the series operator (infix:...) in
 Rakudo(*), and came across the difficulty to come up with a signature
 for it. These are the use cases I want to cover:

 1, 2 ... { $^a + $^b }
 1 ... { $_ + 1 }

 The first one can clearly be written as

 sub infix:...(@values, Code $geneator)

 but the second will fail to bind to that signature, because the 1 isn't
 a list. I'd like to write

 sub infix:...(*...@values, Code $generator)

 instead, but I think that required positional parameters are forbidden
 after slurpy arrays. Do I have to install another multi that accepts a
 single scalar? Or is there a neat trick to cover both use cases with a
 single signature?

I'm surprised that '1, 2 ... { $^a + $^b }' binds properly.  I suppose
that it's because of the relative precedences of '...' vs ','.  ','
gets evaluate first, combining 1 and 2 into a two-element list; then
that list gets fed into the left side of '...'.  If that's not the
case, then I don't see why '...' isn't just grabbing the '2', and then
failing to bind it because '2' isn't a list.

Perhaps non-associating infix operators should be an exception to the
usual rules concerning signatures, seeing as how you are guaranteed to
have exactly two positional parameters.  In particular, I'm thinking
that a non-associating infix operator might be permitted to have a
slurpy array as either _or both_ of its positional parameters, on the
theory that Perl 6 should strive to allow as much flexibility as
possible within the constraints of ambiguity.  (Currently, I believe,
it's sheer nonsense to have a slurpy array in either position.)

Or perhaps not; this may open a can of worms that we don't want to
mess with.  I can think of two complications off the top of my head:
pipes and reducing operators.  If you allow a slurpy list on either
side of an infix operator, how does that interact with piping
operators?  If you allow one on both sides, how do you determine which
one you're piping to?  If you reduce the operator so that it operates
according to function syntax (i.e., name first; then parameters) and
the first parameter is a slurpy list, how will you know when the first
parameter ends and the second begins?  Do you use an all but the
last rule?  etc.

-- 
Jonathan Dataweaver Lang


r27264 - docs/Perl6/Spec

2009-06-26 Thread pugs-commits
Author: lwall
Date: 2009-06-26 16:37:04 +0200 (Fri, 26 Jun 2009)
New Revision: 27264

Modified:
   docs/Perl6/Spec/S06-routines.pod
Log:
[S06] only prefix:foo makes named unary, not sub foo ($)


Modified: docs/Perl6/Spec/S06-routines.pod
===
--- docs/Perl6/Spec/S06-routines.pod2009-06-26 12:05:11 UTC (rev 27263)
+++ docs/Perl6/Spec/S06-routines.pod2009-06-26 14:37:04 UTC (rev 27264)
@@ -4,19 +4,20 @@
 
 Synopsis 6: Subroutines
 
-=head1 AUTHOR
+=head1 AUTHORS
 
-Damian Conway dam...@conway.org and
+Damian Conway dam...@conway.org
 Allison Randal a...@shadowed.net
+Larry Wall la...@wall.org
 
 =head1 VERSION
 
-  Maintainer: Larry Wall la...@wall.org
-  Date: 21 Mar 2003
-  Last Modified: 23 May 2009
-  Version: 109
+  Created: 21 Mar 2003
 
+  Last Modified: 26 Jun 2009
+  Version: 110
 
+
 This document summarizes Apocalypse 6, which covers subroutines and the
 new type system.
 
@@ -1742,17 +1743,37 @@
 sub postfix:! ($x) is equiv++ {...}
 sub postfix:! ($x) {...}  # since equiv++ is the default
 
-Prefix operators that are identifiers are handled specially.  Both of
+Prefix operators that are identifiers are handled specially.  The
+form with one argument defaults to named unary precedence
+instead of autoincrement precedence:
 
-sub foo ($) {...}
-sub prefix:foo ($) {...}
+sub prefix:foo ($x) {...}
+foo 1, 2, 3;# means foo(1), 2, 3
 
-default to named unary precedence despite declaring a prefix operator.
 Likewise postfix operators that look like method calls are forced to
 default to the precedence of method calls.  Any prefix operator that
 requires multiple arguments defaults to listop precedence, even if it
-is not an identifier.
+is not an identifier:
 
+sub prefix:☎ ($x,$y) {...}
+☎ 1;# ERROR, too few arguments
+☎ 1, 2; # okay
+☎ 1, 2, 3;  # ERROR, too many arguments
+
+You must use the C prefix:foo  form in order to mutate
+the grammar to parse as a named unary operator.  Normal function
+definitions never change the grammar, and when called always parse
+as listops, even if defined with a single argument:
+
+sub foo ($x) {...}  # a listop
+foo(1), 2, 3;   # okay
+(foo 1), 2, 3;  # okay
+foo 1, 2, 3;# ERROR, too many arguments
+
+Likewise 0-ary functions parse as listops.  Use C term:foo 
+(or a constant or enum declaration) to declare a term that expects
+no arguments.
+
 =item Cis assoc
 
 Specifies the associativity of an operator explicitly.  Valid values are:



Re: Signature for the series operator

2009-06-26 Thread yary
S02 says-

Anywhere you can use a single type you can use a set of types, for
convenience specifiable as if it were an or junction:

my Int|Str $error = $val;  # can assign if $val~~Int
or $val~~Str

so would
sub infix:...(Array|Scalar $values, Code $generator)
be kosher?

I'm with Jon, wondering about two slurpies for infix operators.


r27265 - in docs/Perl6/Spec: . S32-setting-library

2009-06-26 Thread pugs-commits
Author: lwall
Date: 2009-06-26 17:38:29 +0200 (Fri, 26 Jun 2009)
New Revision: 27265

Modified:
   docs/Perl6/Spec/S01-overview.pod
   docs/Perl6/Spec/S02-bits.pod
   docs/Perl6/Spec/S03-operators.pod
   docs/Perl6/Spec/S04-control.pod
   docs/Perl6/Spec/S05-regex.pod
   docs/Perl6/Spec/S06-routines.pod
   docs/Perl6/Spec/S07-iterators.pod
   docs/Perl6/Spec/S09-data.pod
   docs/Perl6/Spec/S10-packages.pod
   docs/Perl6/Spec/S11-modules.pod
   docs/Perl6/Spec/S12-objects.pod
   docs/Perl6/Spec/S13-overloading.pod
   docs/Perl6/Spec/S14-roles-and-parametric-types.pod
   docs/Perl6/Spec/S16-io.pod
   docs/Perl6/Spec/S17-concurrency.pod
   docs/Perl6/Spec/S19-commandline.pod
   docs/Perl6/Spec/S21-calling-foreign-code.pod
   docs/Perl6/Spec/S22-package-format.pod
   docs/Perl6/Spec/S28-special-names.pod
   docs/Perl6/Spec/S29-functions.pod
   docs/Perl6/Spec/S31-pragmatic-modules.pod
   docs/Perl6/Spec/S32-setting-library/Abstraction.pod
   docs/Perl6/Spec/S32-setting-library/Basics.pod
   docs/Perl6/Spec/S32-setting-library/Callable.pod
   docs/Perl6/Spec/S32-setting-library/Containers.pod
   docs/Perl6/Spec/S32-setting-library/Exception.pod
   docs/Perl6/Spec/S32-setting-library/IO.pod
   docs/Perl6/Spec/S32-setting-library/Numeric.pod
   docs/Perl6/Spec/S32-setting-library/Rules.pod
   docs/Perl6/Spec/S32-setting-library/Str.pod
   docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
[Spec] treat all authors equally
[Spec] make whitespace unugly
[Spec] rename Date to Created
[Spec] separate header things you edit from Created


Modified: docs/Perl6/Spec/S01-overview.pod
===
--- docs/Perl6/Spec/S01-overview.pod2009-06-26 14:37:04 UTC (rev 27264)
+++ docs/Perl6/Spec/S01-overview.pod2009-06-26 15:38:29 UTC (rev 27265)
@@ -4,17 +4,17 @@
 
 Synopsis 1: Overview
 
-=head1 AUTHOR
+=head1 AUTHORS
 
-Larry Wall la...@wall.org
+Larry Wall la...@wall.org
 
 =head1 VERSION
 
-  Maintainer: Larry Wall la...@wall.org
-  Date: 10 Aug 2004
-  Last Modified: 30 Jan 2007
-  Version: 6
+Created: 10 Aug 2004
 
+Last Modified: 30 Jan 2007
+Version: 6
+
 This document originally summarized Apocalypse 1, which covers the
 initial design concept.  That original summary may be found below
 under Random Thoughts.  However, these Synopses also contain

Modified: docs/Perl6/Spec/S02-bits.pod
===
--- docs/Perl6/Spec/S02-bits.pod2009-06-26 14:37:04 UTC (rev 27264)
+++ docs/Perl6/Spec/S02-bits.pod2009-06-26 15:38:29 UTC (rev 27265)
@@ -4,17 +4,17 @@
 
 Synopsis 2: Bits and Pieces
 
-=head1 AUTHOR
+=head1 AUTHORS
 
-Larry Wall la...@wall.org
+Larry Wall la...@wall.org
 
 =head1 VERSION
 
-  Maintainer: Larry Wall la...@wall.org
-  Date: 10 Aug 2004
-  Last Modified: 17 Jun 2009
-  Version: 171
+Created: 10 Aug 2004
 
+Last Modified: 17 Jun 2009
+Version: 171
+
 This document summarizes Apocalypse 2, which covers small-scale
 lexical items and typological issues.  (These Synopses also contain
 updates to reflect the evolving design of Perl 6 over time, unlike the

Modified: docs/Perl6/Spec/S03-operators.pod
===
--- docs/Perl6/Spec/S03-operators.pod   2009-06-26 14:37:04 UTC (rev 27264)
+++ docs/Perl6/Spec/S03-operators.pod   2009-06-26 15:38:29 UTC (rev 27265)
@@ -5,17 +5,18 @@
 
 Synopsis 3: Perl 6 Operators
 
-=head1 AUTHOR
+=head1 AUTHORS
 
-Luke Palmer l...@luqui.org
+Luke Palmer l...@luqui.org
+Larry Wall la...@wall.org
 
 =head1 VERSION
 
-  Maintainer: Larry Wall la...@wall.org
-  Date: 8 Mar 2004
-  Last Modified: 10 Jun 2009
-  Version: 168
+Created: 8 Mar 2004
 
+Last Modified: 10 Jun 2009
+Version: 168
+
 =head1 Overview
 
 For a summary of the changes from Perl 5, see L/Changes to Perl 5 operators.

Modified: docs/Perl6/Spec/S04-control.pod
===
--- docs/Perl6/Spec/S04-control.pod 2009-06-26 14:37:04 UTC (rev 27264)
+++ docs/Perl6/Spec/S04-control.pod 2009-06-26 15:38:29 UTC (rev 27265)
@@ -4,17 +4,17 @@
 
 Synopsis 4: Blocks and Statements
 
-=head1 AUTHOR
+=head1 AUTHORS
 
-Larry Wall la...@wall.org
+Larry Wall la...@wall.org
 
 =head1 VERSION
 
-  Maintainer: Larry Wall la...@wall.org
-  Date: 19 Aug 2004
-  Last Modified: 16 Jun 2009
-  Version: 80
+Created: 19 Aug 2004
 
+Last Modified: 16 Jun 2009
+Version: 80
+
 This document summarizes Apocalypse 4, which covers the block and
 statement syntax of Perl.
 

Modified: docs/Perl6/Spec/S05-regex.pod
===
--- docs/Perl6/Spec/S05-regex.pod   2009-06-26 14:37:04 UTC (rev 27264)
+++ docs/Perl6/Spec/S05-regex.pod   2009-06-26 15:38:29 UTC (rev 27265)
@@ -6,17 +6,18 @@
 
 =head1 AUTHORS
 
-Damian Conway dam...@conway.org and
-Allison Randal a...@shadowed.net
+ 

Re: r27265 - in docs/Perl6/Spec: . S32-setting-library

2009-06-26 Thread Nicholas Clark
On Fri, Jun 26, 2009 at 05:38:30PM +0200, pugs-comm...@feather.perl6.nl wrote:

 [Spec] treat all authors equally
 [Spec] make whitespace unugly
 [Spec] rename Date to Created
 [Spec] separate header things you edit from Created

and one stowaway:

 +=head2 Abstract vs Concrete types [Conjectural]
 +
 +For any named type, certain other types may automatically be derived
 +from it by appending an appropriate adverbial to its name:
 +
 +Int:A   Allow either defined or undefined Int values   
 +Int:U   Allow only undefined (abstract) Int values
 +Int:D   Allow only defined (concrete) Int values
 +
 +That is, these are equivalent:
 +
 +Int:A   Any where Int
 +Int:U   Int where !*.defined
 +Int:D   Int where *.defined
 +
 +A bare CInt may default differently in different circumstances.
 +In a variable declaration, C:A is assumed, whereas in a formal
 +parameter that is not an invocant, C:D is assumed.
 +

Nicholas Clark