On Tue, Jul 13, 2004 at 03:44:11PM -0600, John Williams wrote:
: On Tue, 13 Jul 2004, Larry Wall wrote:
: > On Tue, Jul 13, 2004 at 07:24:55AM -0600, Luke Palmer wrote:
: > : But in Perl 6, you don't have to specify things like that through the
: > : mode string: you can specify them through named parameters:
: > :
: > : my $fh = open ">$filename" :excl;
: >
: > While that probably works, I think better style would be to use a comma:
: >
: > my $fh = open ">$filename", :excl;
: >
: > That explicitly passes :excl to open as a term in a list rather
: > than relying on the magical properties of :foo to find the preceding
: > operator adverbially when used where an operator is expected. We may
: > have to tighten up the definition of operator :foo a bit, since it's
: > not always going to be clear which preceding operator is intended.
: > Even quotes are operators if you squint.
: [snip]
: > I see several directions we could go to clarify this, and I don't
: > entirely like any of them. [snip]
: >
: > Operator adverbs are, in essence, postfix operators with weird
: > precedence. We're going to have to be very explicit about what we
: > mean by "weird" here. Unfortunately, this morning I don't feel
: > very explicit.
:
: My understanding is that the :adverb is at the end because it is passed as
: a named argument, which must be after the positional arguments. And that
: is certainly unambiguous with the comma.
It's unambiguous becase a term is expected at that point, so :adverb
isn't really an adverb--it's just a pair constructor.
: However we have a precedent in m:i// where the :adverb comes directly
: after the operator. It's probably special because it "is parsed" that
: way, but it's so common that I feel I can use it as a precedent anyway.
:
: So if :adverbs are having such a weird time finding their verbs, wouldn't
: it be easier to allow them to be placed directly after the verb all the
: time? Then the magic is merely moving it into the named args section
: instead of wondering which operator's named args section it belongs to.
:
: Then
:
: my $fh = open ">$filename" :excl;
:
: is unambiguously
:
: my $fh = open (circumfix:""('>$filename', :excl));
:
: while what was actually wanted is written as either of
:
: my $fh = open ">$filename", :excl; # part of the arg list
: my $fh = open :excl ">$filename"; # adverb to open
:
: And besides, I think it reads better when the adverb is next to the verb.
:
: yes, no, maybe?
Except that you've but :excl where the parse is expecting a term, so it
isn't an adverb. It's just a pair constructor. Which means that after
it the parser is expecting an operator, and blows up on the string literal.
The adverb notation as currently defined only works where an operator
is expected. Which means it can't really be used on unary operators
unless there's some kind of pecking order where we try to apply it to
the unary operator, and if that fails, apply it to the preceding binary
operator. But that's a headache waiting to happen. I'm more inclined
to say that the adverb notation only works for binary operators, and
you have to use pair args with unaries. So you can't write
$x = rand 20 :bell_curve
because it would try to apply :bell_curve to the assignment, but you
can write
$x = rand(20, :bell_curve)
I know it seems like the adverb syntax is misplacing the modifier with
respect to the binary operator it's modifying, but I think most of its
uses are actually very short:
1..100:by(3)
If you really want something fancy, you'd be better off to write it
in functional form with a normal named pair argument:
infix:..(1, <some_big_hairy_expression>, :by(3))
instead of
1 .. <some_big_hairy_expression> :by(3)
Alternately, I do see an easy formatting hack:
1 .. (<some_big_hairy_expression>)
:by(3)
Just don't anyone suggest that we indicate what's modified
*syntactically* by placing the adverb directly under it...
Hmm. Maybe with an extra uparrow?
1 .. (<some_big_hairy_expression>)
^:by(3)
Yow. Two-dimensional programs. Reminds me of BF...
But we'd have to pay really close attention to how indenting is done.
Maybe we should just pass this suggestion on to Guido... :-)
Larry
