-operators.pod
Log Message:
---
[S03] Finally, finally move =head1 Adverbs to =head2
newbie_Perl6++ for reminding me this still needed to be done :) .
:
M S02-bits.pod
Log Message:
---
Add :chop adverb to quoting adverbs
The idea being that in combination with :to, a .chop could be done at compile
time already if there is no interpolation happening at the end of the result.
:
M S02-bits.pod
Log Message:
---
Small clarification in subscript adverbs
After masak++ made me think about it more
:
M S02-bits.pod
Log Message:
---
Some clarifications on using adverbs with subscripts
Please consider this a draft, a discussion piece if you will. I simply
got inspired by http://irclog.perlgeek.de/perl6/2013-05-21#i_7098764
-bits.pod
Log Message:
---
Allow false booleans into slice adverbs
Martin D Kealey said (in the a..b thread):
>> So then, "a" cmp "ส้" is always defined, but users can change the
>> definition.
>
> I take the opposite approach; it's always undefined (read, unthrown
> exception) unless the user tells us how they want it treated. That can be a
> command-line switch
HaloO,
Larry Wall wrote:
The whitespace proposal is essentially to
require whitespace between any operator any following pair if the
pair is intended to be a noun and not an adverb.
So, then my log:base(2) would still look for the positional argument,
right?
Alternately, we could force eve
is a bit lengthy and
>
>$x = log $y, :base(2);
>
> looks more like a two element list assigned to $x.
That's because it *is* a two element list. In the current scheme of
things, you have to put:
$x = log $y :base(2);
The point being that adverbs are recognized only where
HaloO,
John M. Dlugosz wrote:
So do they have to go at the end of the whole expression in the current
grammar? I don't follow about the spaces.
The problem is term versus operator parsing.
Do you write
$a lt:lc $b le:lc $c
I think that works and looks best. My favorite hope is that
Larry Wall larry-at-wall.org |Perl 6| wrote:
> As for
> marking each op individually, it might be possible if we add a
> whitespace dependency between "lt:lc" and "lt :lc", but 1 ..:by(2) 100
> is pretty ugly.
>
> Larry
So do they have to go at the end of the whole expression in the current gram
On Wed, May 10, 2006 at 08:09:45AM +0100, Daniel Hulme wrote:
: > qX ::= "q:x:y:z";
: >
: > as a simple, argumentless "word" macro.
: But would that DWIM when I come to write
:
: qX(stuff, specifically not an adverb argument);
:
: ?
Just looking at it, I would expect qX() to call a function
> qX ::= "q:x:y:z";
>
> as a simple, argumentless "word" macro.
But would that DWIM when I come to write
qX(stuff, specifically not an adverb argument);
?
--
"The rules of programming are transitory; only Tao is eternal.
Therefore you must contemplate Tao before you receive en
On Tue, May 09, 2006 at 11:15:24PM -0700, jerry gay wrote:
: according to S02, under 'Literals', generalized quotes may now take
: adverbs. in that section is the following comment:
:
:
: [Conjectural: Ordinarily the colon is required on adverbs, but the
: "quote" decl
according to S02, under 'Literals', generalized quotes may now take
adverbs. in that section is the following comment:
[Conjectural: Ordinarily the colon is required on adverbs, but the
"quote" declarator allows you to combine any of the existing adverbial
forms above wi
Larry Wall wrote:
> You might have to write that
>
>@list ==> $foo.act :bar('baz');
>
> I think or the colon on the method would be taken as starting a list.
> I dunno, depends on whether .act: is considered a "longest token",
> I guess. I could argue it the other way as well, and :bar is a lo
One other point:
act $foo, @list, bar => 'baz';
is actually the same as:
act($foo, @list, bar => 'baz');
which might or might not dispatch to a method on $foo,
depending on whether (and how) &act is defined.
Jonathan probably meant:
act $foo: @list, bar => 'baz';
for the indirec
On Mon, Apr 24, 2006 at 08:30:04PM -0700, Jonathan Lang wrote:
: Larry Wall wrote:
: > Jonathan Lang wrote:
: > : How do you define new adverbs, and how does a subroutine go about
: > : accessing them?
: >
: > Adverbs are just optional named parameters. Most of the magic is in
: &g
Larry Wall wrote:
> Jonathan Lang wrote:
> : How do you define new adverbs, and how does a subroutine go about
> : accessing them?
>
> Adverbs are just optional named parameters. Most of the magic is in
> the call syntax.
Ah. So every part of a Capture Object has an alt
On Mon, Apr 24, 2006 at 06:58:04PM -0700, Jonathan Lang wrote:
: How do you define new adverbs, and how does a subroutine go about
: accessing them?
Adverbs are just optional named parameters. Most of the magic is in
the call syntax.
Larry
How do you define new adverbs, and how does a subroutine go about
accessing them?
--
Jonathan Lang
On Tue, Apr 19, 2005 at 02:14:04AM +0300, wolverian wrote:
: On Mon, Apr 18, 2005 at 04:00:53PM -0700, Larry Wall wrote:
: > %num_of_lines = [EMAIL PROTECTED];
: >
: > : because the Perl 5 way would put a reference to @file in the hash.
: > : Scalar context always makes references now, from wh
On Mon, Apr 18, 2005 at 04:00:53PM -0700, Larry Wall wrote:
> %num_of_lines = [EMAIL PROTECTED];
>
> : because the Perl 5 way would put a reference to @file in the hash.
> : Scalar context always makes references now, from what I understand.
>
> Interestingly, a stored reference would track t
On Mon, Apr 18, 2005 at 06:44:55PM -0400, Kurt Hutchinson wrote:
: On Mon, Apr 18, 2005 at 11:23:34PM +0300, Roie Marianer wrote:
: > That makes sense, but that would make
: > %num_of_lines = @file
: > not DWIM... of course that would translate into
: > %num_of_lines = scalar @file
: > so maybe t
On Mon, Apr 18, 2005 at 11:23:34PM +0300, Roie Marianer wrote:
> That makes sense, but that would make
> %num_of_lines = @file
> not DWIM... of course that would translate into
> %num_of_lines = scalar @file
> so maybe that's OK.
In order to promote proper syntactical thinking, note that this is
On Mon, Apr 18, 2005 at 11:23:34PM +0300, Roie Marianer wrote:
: > : But when you start interpolating, you get into a big mess:
: > : h<\qq[$interpolated]> = want(); # ???
: > : h<<$foo>> = want(); # ???
: >
: > I think that, as with functions called in unknown context, we should
: > just force t
> : But when you start interpolating, you get into a big mess:
> : h<\qq[$interpolated]> = want(); # ???
> : h<<$foo>> = want(); # ???
>
> I think that, as with functions called in unknown context, we should
> just force the RHS here to list context, and rely on the RHS to add
> extra context as
On Sun, Apr 17, 2005 at 08:00:00PM -0700, Brent 'Dax' Royal-Gordon wrote:
: Larry Wall <[EMAIL PROTECTED]> wrote:
: > : First, context of hash slices:
: > : Hash slices with {} notation are trivially either scalars or lists:
: > : $h{'foo'} = want(); # Scalar
: > : $h{'foo','bar'} = want(); # Lis
Larry Wall <[EMAIL PROTECTED]> wrote:
> : First, context of hash slices:
> : Hash slices with {} notation are trivially either scalars or lists:
> : $h{'foo'} = want(); # Scalar
> : $h{'foo','bar'} = want(); # List
>
> Right.
Tangentially, that makes me wonder: is there a difference between
sca
); # ???
I think that, as with functions called in unknown context, we should
just force the RHS here to list context, and rely on the RHS to add
extra context as necessary if they really mean scalar. If something
really is always producing a scalar value, it doesn't matter if it's
c
appens:
$h = want(); # Scalar
$h = want(); # List
But when you start interpolating, you get into a big mess:
h<\qq[$interpolated]> = want(); # ???
h<<$foo>> = want(); # ???
Secondly, quotation adverbs (S02) that take arguments could theoretically be
variables that only exist duri
izer
: at this level. :bar will get tokenized before : will, so that's how
: it's interpreted.
Or at least, the parser functions as a tokener at this level.
: > : Larry also shows this example:
: > :
: > : > @a.sort:quick:{ +$_ } # both adverbs apply to .sort
: > :
: > : Would that work for
uld be confused with a longer term starting
> with colon. And /^\:\w+/ is always a named pair of some sort. Otherwise
> we couldn't string together :foo:bar:baz:utf($ate).
This nice effect is a result of the fact that Perl will use a tokenizer
at this level. :bar will get toke
On Fri, Aug 20, 2004 at 04:18:55PM -0700, Larry Wall wrote:
: Only a sig of () makes it *not* look for an argument as a list operator.
That's overstated. Only a sig of () or ($x) or (?$x) suppresses
list operator-ness on ordinary function names.
Larry
On Fri, Aug 20, 2004 at 04:15:43PM -0600, John Williams wrote:
: Adverbs are confusing me mightily lately.
:
: It may be that Larry's A12 revision just needs a few examples
: *with* parenthesis to straighten me out.
:
: Here are some semi-coherent attempts to sort it out
: in my mind. P
Adverbs are confusing me mightily lately.
It may be that Larry's A12 revision just needs a few examples
*with* parenthesis to straighten me out.
Here are some semi-coherent attempts to sort it out
in my mind. Please correct me where I have made mistakes.
What is the rule(s) for when :foo
On 10/10/01 7:27 AM, Piers Cawley wrote:
> Bart Lateur <[EMAIL PROTECTED]> writes:
>> On Sat, 06 Oct 2001 22:20:49 -0400, John Siracusa wrote:
>>
>>> So, in the
operator, the filter is the adverb:
>>>
>>>$sum =
@costs : {$^_ < 1000};
>>
>> WTF is that operator? All I see is a black bloc
Bart Lateur <[EMAIL PROTECTED]> writes:
> On Sat, 06 Oct 2001 22:20:49 -0400, John Siracusa wrote:
>
> >So, in the
operator, the filter is the adverb:
> >
> >$sum =
@costs : {$^_ < 1000};
>
> WTF is that operator? All I see is a black block. We're not in ASCII any
> more, Toto...
I'm g
On Sat, 06 Oct 2001 22:20:49 -0400, John Siracusa wrote:
>So, in the
operator, the filter is the adverb:
>
>$sum =
@costs : {$^_ < 1000};
WTF is that operator? All I see is a black block. We're not in ASCII any
more, Toto...
--
Bart.
> So, does that mean that, to keep C and
> Cnew($baz, $frob)> doing the same thing, the object will always
> come in before the colon?
Yes.
> Is unary . gonna refer to the "one and only"
> argument before the colon?
Yes.
> Cool.
Yes.
;-)
Damian
On 10/7/01 4:17 AM, Damian Conway wrote:
>> Does that mean that in the built-in print, the file handle is the only
>> "in-band" argument, and all the actual items to be printed are merely
>> adverbs?
>
> Yep. Although the "in-band"/"out-of-band
tems to be
# printed are merely
#> adverbs?
#
# Yep. Although the "in-band"/"out-of-band" distinction is only one of
# convention.
#
# In reality, Perl 6 will merely distinguish between those
# arguments that
# come before a colon (and are bound to parameters before the
# colon i
>From EX3:
> A subroutine's adverbs are specified as part of its normal parameter list, but
> separated from its regular parameters by a colon:
>
> my sub operator:
is prec(\&operator:+($)) ( *@list : $filter //= undef)
> { ...
>
> This specifies that operator:
> use strict 'recursive';
If this is not yet done and is deemed a good idea, I'd add that it
seems to me to be equally applicable to perl 5.
Further, considering the more general
[pragma] 'recursive';
I can imagine pragma adverbs / attributes.
I searched p
43 matches
Mail list logo
