Re: adverbs o operators
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 grammar? I don't follow about the spaces. Do you write $a lt:lc $b le:lc $c or $a lt :lc $b le :lc $c or $a lt $b :lc le $c :lc ? Making the default a contextual variable would allow the library to do it with no core syntax concerns: $+Str::compare = 'lc'; # applies to rest of lexical scope if $a lt $b le $c ... --John
Re: adverbs o operators
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 $x = log:2 $y; flies, as well. $x = log:base(2) $y; is a bit lengthy and $x = log $y, :base(2); looks more like a two element list assigned to $x. or $a lt :lc $b le :lc $c That is a parse error two terms in a row. or $a lt $b :lc le $c :lc No problem here. 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: adverbs o operators
On Thu, Aug 07, 2008 at 06:15:07PM +0200, TSa wrote: Do you write $a lt:lc $b le:lc $c I think that works and looks best. My favorite hope is that $x = log:2 $y; flies, as well. $x = log:base(2) $y; 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 an infix is expected. Otherwise they're just pairs used as nouns. Currently after log a term is expected, so log:base(2) would be parsed as log(:base(2)). 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. We actually thought of this years ago in the design meeting and rejected it at the time because, in particular 123,:foo would surprise a lot of people by looking for the ,:foo operator. But maybe we could put in an exception for confusing forms that are guaranteed not to work. I can't imagine why anyone would want a ,:foo operator, for instance. Doubtless there are other confusing operators though. Alternately, we could force everyone to put space after comma. :) Larry
Re: adverbs o operators
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 everyone to put space after comma. :) Wouldn't it suffice to enforce to disambiguate ',:' as ', :'? 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: Adverbs
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
Re: Adverbs
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 alternate call syntax:
act $foo, @list, bar = 'baz';
is the same as
@list == $foo.act:bar('baz');
right?
(And if this is the case, the one capability that the adverb notation
provides that the more traditional named parameter notation doesn't
have is a way to let a particular key to exist without being defined.)
--
Jonathan Dataweaver Lang
Re: Adverbs
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
: the call syntax.
:
: Ah. So every part of a Capture Object has an alternate call syntax:
:
: act $foo, @list, bar = 'baz';
:
: is the same as
:
: @list == $foo.act:bar('baz');
:
: right?
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 longest
token compared to :.
: (And if this is the case, the one capability that the adverb notation
: provides that the more traditional named parameter notation doesn't
: have is a way to let a particular key to exist without being defined.)
Without being specified, anyway. The default values are always defined.
Larry
Re: Adverbs
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 indirect object syntax. Damian
Re: Adverbs
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 longest
token compared to :.
Eh? What's this bit about lists and colons? (This is one of the
things that worries me about Perl 6: there seem to be all sorts of
edge cases which crop up at the most unexpected times.)
--
Jonathan Dataweaver Lang
Re: adverbs
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. Please correct me where I have made mistakes.
:
: What is the rule(s) for when :foo is an adverb, and when :foo
: is just a pair constructor?
:
: So far I think that :foo is an adverb where an operator
: is expected, but :for is a pair constructor where a term
: is expected.
:
: Why is this difference important?
:
: Perhaps because an adverb goes looking for something to
: apply itself to.
Yes.
: How does it decide what to apply itself to?
:
: 4) Adverbs apply to the previous unparenthesized prefix, infix,
: or postfix operator, bypassing simple terms and other pill
: operators such as circumfix or postcircumfix.
:
: But what about the rules for additional arguments as adverbs?
:
: 1d) Additional [function] arguments may occur as adverbs *only* if
: there are explicit parens.
:
: 2d) Given 2c, additional [method] arguments may occur as adverbs
: whether or not there is an argument pill:
:
: I assume rule 1d only applies to arglist parenthesis,
: and not grouping parenthesis?
Yes.
: The legal syntaxes below all mean the same thing, right?
:
:func(1,2,3,:foo); # ok
:func 1,2,3,:foo ; # ok
Those two are the same.
:func(1,2,3):foo ; # ok
That one is a little different. Adverbs are always bound as named
arguments. Pair arguments are bound as named arguments only if they
come between The Positional Arguments and The List. So this example
is the same only if the function is declared with three positional
arguments:
func(:foo, 1,2,3) (+$foo, [EMAIL PROTECTED])
func(1, :foo, 2,3) ($a, +$foo, [EMAIL PROTECTED])
func(1,2, :foo, 3) ($a, $b, +$foo, [EMAIL PROTECTED])
func(1,2,3, :foo) ($a, $b, $c, +$foo, [EMAIL PROTECTED])
Which is why it's good to use == to be explicit about where your
list starts in these cases.
:func(1,2,3 :foo); # ok (explicit parens)
That one is illegal because the comma between 2 and 3 doesn't take a
:foo adverb. Rule 1d should probably read something like: ...only
if there are explicit parens before it.
Basically, the parens have to be there to direct the gaze of the adverb
at the function name.
:func 1,2,3 :foo ; # ILLEGAL (according to A12 revision)
Illegal for the same reason--the rules apply it to the comma.
: And for 2d, these are the same:
:
:.meth(1,2,3):foo ;
:.meth(1,2,3 :foo);
The second one is illegal for the same reason.
: Does rule 1d or rule 4 does apply inside this parenthesized arglist?
:
:func( eeney, meeny, miney :moe );
:
: Does :moe apply to func (rule 1d) or miney (rule 4)?
It can never apply to func. It can only apply to comma or miney.
: Does it depend on the declaration of miney?
Yes.
:sub miney {...} # simple term: moe applies to func
No, that's not a simple term, but a list operator. So you get miney(:moe)
instead of infix:,(miney, :moe). If you want a bare term you need to say
sub miney () {...}
:sub miney(*%adv) {...} # does a slurpy hash make a function a list operator?
Only a sig of () makes it *not* look for an argument as a list operator.
:sub miney($+moe) {...} # I'll take that moe
You can have it. :-)
(But only if you reverse the $ and the +.)
:sub miney($+curly) {...} # Arg OK, but not that one!
Correct (except for the reversed $ and + again).
: Is this correct according to 2d, assuming func and meth are 0-ary:
:
:say func :foo; # say( func, foo=1 )
This one's illegal. Gotta have a comma to expect a term.
:say .meth :foo;# say( .meth( foo=1 ) )
That one works.
: but if func is 2-or-more-ary, then:
:
:say func :foo; # say( func( foo=1 ) )
Yes.
: A unary function cannot take an adverb, because it has no slurpy hash.
Don't need a slurpy hash for adverbs. Only a matching named parameter.
Unary just means there's exactly one non-optional positional parameter,
so this is a unary operator:
sub prefix:-($x, +$with_prejudice) { negate($x, $with_prejudice) }
and can be called with any of:
-$foo
-$foo:with_prejudice
-$foo:with_prejudice(0)
Likewise
sqrt($x):both
could return both the positive and negative root. In this case it's
ambiguous whether
sqrt $x, :both
should treat sqrt as a named unary or a list operator. I don't know
offhand which way to bias that, or whether the parser should just
throw up its hands in disgust. Or just throw up...
: Is a function with a slurpy hash automatically a list operator,
: even if it has 0 or 1 positional arguments?
Yes. Functions are strongly biased towards being list operators.
Which probably means that we should bias the sqrt example to a list
operator on the basis of the named argument. (But not symbolic
Re: adverbs
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
Re: adverbs
Larry Wall writes:
On Fri, Aug 20, 2004 at 04:15:43PM -0600, John Williams wrote:
:
:say .meth :foo;# say( .meth( foo=1 ) )
That one works.
But that's because :foo is an adverb to .meth, not because .meth is
taking an argument 'foo' = 1, right?
Likewise
sqrt($x):both
could return both the positive and negative root. In this case it's
ambiguous whether
sqrt $x, :both
should treat sqrt as a named unary or a list operator. I don't know
offhand which way to bias that, or whether the parser should just
throw up its hands in disgust. Or just throw up...
Well, in this case, I'd be tempted to look at which one's more likely to
blow up sooner when you do it wrong. If we have:
my $root = sqrt $x, :both;
And it assumes sqrt is unary, then you get the equivalent of:
my $root = [ sqrt($x), 'both' = 1 ];
If you have the extremely unlikely:
my $list = sqrt $x, :foo;
Then you get a sqrt doesn't know what :foo means. That combined with
the fact that you'll much more rarely see a function call followed by a
pair, I like that better. On the other hand:
my @check = splice @nums, 0, sqrt $max, :something
:something looks an awful lot more like an argument to splice than to
sqrt. But again, sqrt will probably blow up immediately, and you can
fix it. So making it a list op looks far advantageous. That's also an
argument against using the slurpy hash whenever you can manage.
: Do I have my whitespace rules right below?
:
:say foo :bar; # say( foo( bar=1 ) ) assuming foo is listy
:say .foo :bar; # say( .foo( bar=1 ) )
:say foo: bar; # foo.say(bar)
Yes, but works only if foo is predeclared as a class.
Or function name.
:say foo:bar ; # ?? say foo :bar ??
Yes, like the label colon, the invocant-terminating colon requires
whitespace after it if it would 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 tokenized before : will, so that's how
it's interpreted.
: Larry also shows this example:
:
: @a.sort:quick:{ +$_ } # both adverbs apply to .sort
:
: Would that work for the functional form too?
:
: sort :quick :{ +$_ } @a;
Not unless you put a comma after the closing curly. Otherwise it's
expecting an operator.
Very nice. I was worried about that one, too, where list operators with
their first argument a closure would require options between the closure
and the list, which feels wrong (to me). That's assuming that you can
declare:
sub sort(*code, +$quick, [EMAIL PROTECTED]) {...}
Perhaps if there's only one something argument, it automatically
becomes *something as to aid usability?
Luke
Re: adverbs
On Fri, Aug 20, 2004 at 06:12:06PM -0600, Luke Palmer wrote:
: Larry Wall writes:
: On Fri, Aug 20, 2004 at 04:15:43PM -0600, John Williams wrote:
: :
: :say .meth :foo;# say( .meth( foo=1 ) )
:
: That one works.
:
: But that's because :foo is an adverb to .meth, not because .meth is
: taking an argument 'foo' = 1, right?
Correct.
: Likewise
:
: sqrt($x):both
:
: could return both the positive and negative root. In this case it's
: ambiguous whether
:
: sqrt $x, :both
:
: should treat sqrt as a named unary or a list operator. I don't know
: offhand which way to bias that, or whether the parser should just
: throw up its hands in disgust. Or just throw up...
:
: Well, in this case, I'd be tempted to look at which one's more likely to
: blow up sooner when you do it wrong. If we have:
:
: my $root = sqrt $x, :both;
:
: And it assumes sqrt is unary, then you get the equivalent of:
:
: my $root = [ sqrt($x), 'both' = 1 ];
:
: If you have the extremely unlikely:
:
: my $list = sqrt $x, :foo;
:
: Then you get a sqrt doesn't know what :foo means. That combined with
: the fact that you'll much more rarely see a function call followed by a
: pair, I like that better. On the other hand:
:
: my @check = splice @nums, 0, sqrt $max, :something
:
: :something looks an awful lot more like an argument to splice than to
: sqrt. But again, sqrt will probably blow up immediately, and you can
: fix it. So making it a list op looks far advantageous. That's also an
: argument against using the slurpy hash whenever you can manage.
Agreed. It's not likely to be a big problem either way unless we go
nuts on trying to give consistent modifier names to different sorts
of operators. In particular we should probably try to avoid giving
adverbial arguments to things like assignment and comma.
: : Do I have my whitespace rules right below?
: :
: :say foo :bar; # say( foo( bar=1 ) ) assuming foo is listy
: :say .foo :bar; # say( .foo( bar=1 ) )
: :say foo: bar; # foo.say(bar)
:
: Yes, but works only if foo is predeclared as a class.
:
: Or function name.
Righto. Actually, it always assumes listop for an unrecognized bareword,
so we have to make sure it never eats the colon that indicates indirect
object.
: :say foo:bar ; # ?? say foo :bar ??
:
: Yes, like the label colon, the invocant-terminating colon requires
: whitespace after it if it would 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 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 the functional form too?
: :
: : sort :quick :{ +$_ } @a;
:
: Not unless you put a comma after the closing curly. Otherwise it's
: expecting an operator.
:
: Very nice. I was worried about that one, too, where list operators with
: their first argument a closure would require options between the closure
: and the list, which feels wrong (to me). That's assuming that you can
: declare:
:
: sub sort(*code, +$quick, [EMAIL PROTECTED]) {...}
:
: Perhaps if there's only one something argument, it automatically
: becomes *something as to aid usability?
Maybe...have to think about the pragmatic ramifications of that.
Larry
