At 11:07 AM -0700 9/12/06, [EMAIL PROTECTED] wrote:
+=head1 Cross operators
+
+The final metaoperator is the C metaoperator. It applies the
+modified operator across all permutations of its list arguments. All
+C operators are of list infix precedence, and are list associative.
AT LAST!
I re
svn log, speaking on larry's behalf (>):
+The string concatenating form is:
+
+ X~X <1 2> # 'a1', 'a2', 'b1', 'b2'
+
+The C operator desugars to something like:
+
+[~]«( X <1 2> ) # 'a1', 'a2', 'b1', 'b2'
...and later...
+The C variant crosses the arrays but concatenates
Author: larry
Date: Tue Sep 12 21:09:33 2006
New Revision: 11975
Modified:
doc/trunk/design/syn/S03.pod
Log:
tweaks to crossop syntax
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod
Author: audreyt
Date: Tue Sep 12 19:35:59 2006
New Revision: 11974
Modified:
doc/trunk/design/syn/S03.pod
Log:
* S03: Typographical and stylistic cleanups.
Also, clarify that identity values of reduce hyperoperators
is more logically defined by the way of a multi variant of zero
arity,
On Wed, Sep 13, 2006 at 10:20:31AM +1200, Sam Vilain wrote:
> Larry Wall wrote:
> > : There is currently a mismatch between S12 and Pugs. The former specifies
> > $obj.META, the latter has implemented $obj.meta.
> >
> > .META is more correct at the moment.
> >
>
> Does making it all upper cap
在 Sep 12, 2006 6:59 PM 時，Gaal Yahas 寫到：
What invocant is constructed in this signature then?
method foo ($just_a_named_param)
Is the signature for &foo really the same as that of bar?
sub bar ($just_a_named_param)
As Larry said, they shouldn't be the same; the first one is
&f
Larry Wall wrote:
> : There is currently a mismatch between S12 and Pugs. The former specifies
> $obj.META, the latter has implemented $obj.meta.
>
> .META is more correct at the moment.
>
Does making it all upper caps really help? It's still a pollution of the
method space, any way that you
Larry Wall schreef:
> Dr.Ruud:
>> larry:
>>> +Likewise, from the fact that list context flattens inner arrays and
>>> +lists, it follows that a reduced assignment does no special
>>> syntactic +dwimmery, and hence only scalar assigments are
>>> supported. Therefore +
>>> +[=] $x, @y, $z, 0
>>
> +Note that only the first term of an C operator may reasonably be
> +an infinite list.
Now all we need is a variant that does the diagonal order and we'll be
home and dry.
'a'..* diagX 1..*
->
['a', 1],
['a', 2],
['b', 1],
['a', 3],
['b', 2],
['c', 1],
['a', 4],
['b', 3],
['c', 2],
['d', 1],
Author: larry
Date: Tue Sep 12 11:20:04 2006
New Revision: 11971
Modified:
doc/trunk/design/syn/S03.pod
Log:
Further clarifications and fixups.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.p
Author: larry
Date: Tue Sep 12 11:07:01 2006
New Revision: 11969
Modified:
doc/trunk/design/syn/S03.pod
Log:
New X operator and metaoperator.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod
On Tue, Sep 12, 2006 at 06:16:26PM +0200, Dr.Ruud wrote:
: larry schreef:
:
: > +Likewise, from the fact that list context flattens inner arrays and
: > +lists, it follows that a reduced assignment does no special syntactic
: > +dwimmery, and hence only scalar assigments are supported. Therefore
Larry Wall wrote:
>
> I'm trying to decide if
>
>sub ($self: $just_a_named_param)
>
> can meaningfully put anything into $self. It seems doubtful, and it should
> probably be
>
>submethod ($self: $just_a_named_param)
I agree. If
sub ($self: $foo)
works than it reduces privacy, sinc
larry schreef:
> +Likewise, from the fact that list context flattens inner arrays and
> +lists, it follows that a reduced assignment does no special syntactic
> +dwimmery, and hence only scalar assigments are supported. Therefore
> +
> +[=] $x, @y, $z, 0
> +[+=] $x, @y, $z, 1
> +
> +are e
Author: larry
Date: Tue Sep 12 07:51:14 2006
New Revision: 11965
Modified:
doc/trunk/design/syn/S03.pod
Log:
Allow [=] and [+=].
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(orig
On Tue, Sep 12, 2006 at 01:59:23PM +0300, Gaal Yahas wrote:
: On Tue, Sep 12, 2006 at 06:46:50PM +0800, Audrey Tang wrote:
: > >Does this mean a single named parameter called $x, or a default invocant
: > >and a single required positional named $x?
: >
: > "A default invocant" prolly doesn't make
2006/9/12, Gaal Yahas <[EMAIL PROTECTED]>:
Does this mean a single named parameter called $x, or a default invocant
and a single required positional named $x?
"A default invocant" prolly doesn't make sense there... There's
nothing to "default" to. :-)
Audrey
On Tue, Sep 12, 2006 at 06:46:50PM +0800, Audrey Tang wrote:
> >Does this mean a single named parameter called $x, or a default invocant
> >and a single required positional named $x?
>
> "A default invocant" prolly doesn't make sense there... There's
> nothing to "default" to. :-)
What invocant i
I was writing tests for signatures and came across this ambiguity:
:(:$x)
Does this mean a single named parameter called $x, or a default invocant
and a single required positional named $x?
--
Gaal Yahas <[EMAIL PROTECTED]>
http://gaal.livejournal.com/
19 matches
Mail list logo
