Herein are drafty grumblings.
Part of quitting smoking is that my hubris has gone back up.
Here are critical first-impression notes on Apo3. Praise has
been eliminated to save space.
http://www.perl.com/pub/a/2001/10/02/apocalypse3.html?page=1
> Operator precedence should be as simple as possible. Perl's
> precedence table currently has 24 levels in it. This might or
> might not be too many. We could probably reduce it to about 18
> levels, if we abandon strict C compatibility of the C-like
> operators.
Which we're not about to do, I hope, at least not without an
explicit statement that we've done it. If there were
metapragmata that allowed one to reassign the precedence level,
or create new levels between the levels that were there, that
might be interesting.
A delayed parser -- the "block and clarify" parser that defers
interpretation as long as possible -- is interesting to think
about.
> People don't actually want to think about precedence much
well, sometimes.
> a language that is artificially simple induces artificial
> complexity in all solutions written in that language.
eminently quotable!
> anything that will cause widespread confusion.'' Mind you, I'm
> not proposing a specific use for a unary = at this point.
Although you did suggest "scalar" and prefixing with = looks a lot like a no-op, so
the only confusion would be between
if ($a == 4)
and
if ($a = = 4)
the second is a syntax error in p5, so is
print = @flavors ;
Unary = is certainly prettier than the p5 short version of scalar, which, if you've
been paying very close attention,
is ~~
I wonder what it will be revealed to be.
> [the ability to disambiguate based on if an operator or a term
> is expected] also implies that we can't use
> the ``juxtaposition'' operator.
Does not. It just reduces the set of situations in which ju9on
could be used without parenthesis to very few. I believe that if
you consider ju9on to be the fundamental operator that the
parser uses to link tokens together, in a parse-and-clarify
interpretation paradigm, you could get to a the point in the
precedence descent (assuming one pass for each level -- whew)
where juxtaposition happens -- I would put it immediately above
the comma-as-list-separator operator, but below indirect method
call binding, so if there is an indirect method call it would go
first, before the juxtaposition -- that it would make a viable
concatenator. And some sunny day I might write a preprocessor
that does that.
> you can't just put two terms next to each other, and expect
> something to happen (such as string concatenation, as in awk).
> What if the second term started with something looked like an
> operator? It would be misconstrued as a binary operator.
So you'd have to wrap it in parentheses, or not start the second
term with something that looks like an operator. Jux needs to
have very carefully selected precedence.
> RFC 025: Operators: Multiway comparisons
> ...
> is accepted.
> RFC 320: Allow grouping of -X file tests and
> add filetest builtin
What about drawing the compromise at rewriting
if (-d -r -w -x $file ) { ... }
into
if ( -d $file && -r _ && -w _ && -x _ ) { ... }
instead of switching the order around in order to pretend that
the file test might return the name of the file? You could even
allow bangs in there if you like.
> RFC 290: Better english names for -X
> ... And returning a stat buffer instead of $file prevents the
> confusing:
>
> $handle = open -r -w -x $file or die;
>
> Unless, of course, we decide to make a stat buffer object
return the filename in a string context. :-)
Or allow open to work directly on a stat buffer object, or both:
stat $file unless _ eq $file;
...;
open F, _;
But later, the _ is taken from us, since we don't need it
any more.
> RFC 283: tr/// in array context should return a histogram
> But there can certainly be a histogram option in there
> somewhere.
do I have this right -- if we are taking the return value to mean
counting, but it would be a hash of the chars on the output each
valued with their occurrence count. Starting at 0 or
nonexistence? So instead of Cozen's
(%foo) = "xyzzy" =~ tr/xyz//
# %foo is ( x => 1, y => 2, z => 2);
we could do, assuming assign-to-ref means alias syntax
my constant $table = join'','v'x5,'V'x5,'c'x26,'C'x26;
\%foo = ($Textcopy=$Text) =~ tr/aeiouAEIOUa-zA-Z/$table/;
with the caveat that the whole enterprise may go to pieces
out of view of shore.
This does look like exactly the sort of thing that
makes Schwern hopping mad.
> RFC 084: Replace => (stringifying comma) with => (pair
> constructor)
>
> if we use pair objects to implement
> entries in hashes, the key must be immutable, or there must be
> some way of re-hashing the key if it changes.
Wouldn't that be up to the hash implementor?
I'm enduring a graduate CS course, with its neverending binary
trees, and wondering how many fast binary tree node
implementations using Inline C have been uploaded to CPAN so
far, but I digress
> RFC 081: Lazily evaluated list generation functions
> We can't quite implement ?: as a : modifier on ?, because the
> precedence would be screwey, unless we limit : to a single
> argument, which would preclude its being used to
> disambiguate indirect objects. More on that later.)
Right. Where was the RFC on Use Colons To Disambiguate Indirect
Objects last year? Sorry, too late...
I Gotta write up the coro.pm implementation -- had some notes on
it around here somewhere -- start with very incomplete and add
features instead of the waterfall method.
> RFC 285: Lazy Input / Context-sensitive Input
>
> It will be tricky to make this one work right:
>
> ($first, @rest) = 1 .. Inf;
No trickier than many other trickier tricky things.
> RFC 082: Arrays: Apply operators element-wise in a list context
>
> APL, here we come... :-)
> ...
> There is currently an uparrow operator meaning
> exclusive-or, but that is rarely used in
> practice, and is not typically followed by
> other operators when it is used.
Never used that way. It is a binary operator: it must be
followed by a term.
> represent exclusive-or with ~ instead. (I like that idea
> anyway, because the unary ~ is a 1's complement, and the binary
> ~ would simply be doing a 1's complement on the second argument
> of the set bits in the first argument. On the other hand,
> there's destructive interference with other cultural meanings
> of tilde, so it's not completely obvious that it's the right
> thing to do. Nevertheless, that's what we're doing.)
So tilde isn't the concatenation operator then. The suspense is
giving me a shoulder cramp.
> Anyway, in essence, I'm rejecting the underlying premise of
> this RFC, that we'll have strong enough typing to intuit the
> right behavior without confusing people. Nevertheless, we'll
> still have easy-to-use (and more importantly,
> easy-to-recognize) hyper-operators.
I think you read too much into it. I interpret it to mean that
the coercion of arrays into scalars in the face of certain
well-defined magical binary operators was to be suspended and
instead the expressions would get rewritten.
@R = @A * @B;
becomes
@R = map {$A[$_] * $B[$_]} ($[ .. max @A,@B);
and that is that, modulo the possible appearance of multidimensional laziness.
The withholding of the rewrite except when:
The expression is in an array-context
The operator involved is clearly designated this way
Hmm. Okay, the clear designation, although not required if the feature works merely
on one or two specially designated magic
builtins, implies the hyper-sigill.
> And we should point out again that even though the base
> language will not try to intuit which operators should be
> hyperoperators, there's no reason in principle that someone
> couldn't invent a dialect that does. All is fair if you
> predeclare.
I resolve to read the whole RFC piece before writing anything more from here on down.
> RFC 045: || and && should propagate result context to both
> sides and return either a boolean value or a list, depending on
> the context. And it will be possible to apply both contexts to
> the first argument simultaneously. (Of course, the computer
> actually looks at it in the boolean context first.)
But what is the value of wantarray() or it's replacement within
@a = function() || @b;
is it true or what? "dual"?
> RFC 054: Operators: Polymorphic comparisons
Entrepreneurship class showed a videotape of an interview with
Dr. James "Built To Last" Collins this evening, in which he
recalled product engineers at HP refusing to participate in the
IBM clone market because they wouldn't be adding anything to the
field.
I was a little bit disappointed, after rereading 54 and then the
apocalyptic discussion of 54, that Mr. Wall didn't point out that
rewriting
my $compare = $key <=> $self->{key};
as
my $compare = mycomparison \$key,\($self->{key});
is trivial, furthermore stating that enforcing the number/string
dichotomy is much safer than the errors that would arise from
beginners finding the place where the dwimmery breaks, and ending
the discussion of the RFC with a hearty
"You can't change the laws of nature, captain!"
> ...
> That means that a hypersubstitution is really spelled:
>
> @foo ^=~ s/foo/bar/;
>
> Admittedly, that's not the prettiest thing in the world.
It reminds me of the tunneling vehicle with the big drill on its
nose, from the Flash Gordon comic book.
> Non-RFC considerations
>
...
> [ the new concat op is (drumroll) underscore ]
> The only downside to that is the space between a variable name
> and the operator is required. This is to be construed as a
> feature.
Hear ye, hear ye, Ming of Mongo has declared!
> Unary _
>
> Since the _ token indicating stat buffer is going away, a unary
> underscore operator will force stringification, just as
> interpolation does, only without the quotes.
>
> Unary +
>
> Similarly, a unary + will force numification in Perl 6, unlike
> in Perl 5. If that fails, NaN (not a number) is returned.
NaN is NaN, not zero. Hmm. So to get perl5 semantics, one must
do stuff like
$X = + function();
$X == NaN and $X = 0;
or is NaN false?
$X = +function() || 0;
Or do perl5 conversion semantics apply except when you do an explicit unary plus?
$X = "cheese" / 27; # $X is zero
$Y = +"Richard M. Nixon" / 27; # $Y is NaN
And our scalar operator, such as it was, has been
taken away. Both of them, in fact! Although the
distinction between perl5 unary + and unary ~~ is
very subtle -- the second puts its arg in scalar context,
the first does not.
> Binary :=
>
> We need to distinguish two different forms of assignment. The
> standard assignment operator, =, works just as it does Perl 5,
> as much as possible. That is, it tries to make it look like a
> value assignment. This is our cultural heritage.
>
> But we also need an operator that works like assignment but is
> more definitional. If you're familiar with Prolog, you can
> think of it as a sort of unification operator (though without
> the implicit backtracking semantics). In human terms, it treats
> the left side as a set of formal arguments exactly as if they
> were in the declaration of a function, and binds a set of
> arguments on the right hand side as though they were being
> passed to a function. This is what the new := operator does.
> More below.
Intrgiguing. No mention of rfc 75. I await this "More."
Whew. Yes, many CS faculty here are Chinese.
> Unary *
>
> Unary * is the list flattening operator. (See Ruby for prior
> art.) When used on an rvalue, it turns off function signature
> matching for the rest of the arguments, so that, for instance:
>
> @args = (\@foo, @bar);
> push *@args;
>
> would be equivalent to:
>
> push @foo, @bar;
>
> In this respect, it serves as a replacement for the
> prototype-disabling &foo(@bar) syntax of Perl 5. That would be
> translated to:
>
> foo(*@bar)
Eeek! It's a whole new language!
[discussion of * as list flattenor]
> Every proposed use of colon in the RFCs conflicted with the ?:
> operator. I think that says something.
Not if you add enough parentheses, and still have a colon
meaningless in most places, I think. All the new colons bind
tightly, the old ternary colon only comes into effect following a
ternary ?. It doesn't get used a lot because it is tricky to
read, but when you Really Care About Packing That Complex
Expression Into One Line On The VT100, (is anyone reading this on
a real vt100?) the fact that ternary if is only two letters is
very very good. Although ??:: at four is still better golf than if(){}.
Besides, theres the whole Learn Better C By Writing In Perl
factor.
> I can't list here all the possible spellings of ?: that I
> considered. I just think ??:: is the most visually appealing
> and mnemonic of the lot of them.
uh, okay
> Binary ;
>
> The binary ; operator separates two expressions in a list, much
> like the expressions within a C-style for loop. Obviously the
> expressions need to be in some kind of bracketing structure to
> avoid ambiguity with the end of the statement. Depending on the
> context, these expressions may be interpreted as arguments to a
> for loop, or slices of a multi-dimensional array, or whatever.
> In the absence of other context, the default is simply to make
> a list of lists. That is,
>
> [1,2,3;4,5,6]
>
> is a shorthand for:
>
> [[1,2,3],[4,5,6]]
Does this go deeper than 2 dimensions? No, how could it.
> Unary ?
>
> Reserved for future use.
It's not PRINT, like in commodity basics of the early 1980s?
> Binary ~~
>
> This is a logical XOR operator. It's a high precedence version
> of the low precedence xor operator.
i yi yi
Thank you very much.
