Front page | perl.perl6.language |
Postings from October 2001
Re: sloppy midrash 3
From: Damian Conway
October 4, 2001 00:33
Re: sloppy midrash 3
Message ID: 200110040733.RAA40029@indy05.csse.monash.edu.au
> 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.
A false economy. We should encourage Larry as often as we can.
After all, is it any wonder that it's so long between Apocalypses when
every time he releases one, he gets nothing but negative feedback?
> 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.
User-defined operators will almost certainly be able to be "inserted"
between existing precedence levels.
> 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.
Perl 6 will use C<$(...)> to denote an explicit scalar context
(and C<@(...)> to denote an explicit list context).
> > 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"?
Within the function call, both C<want 'LIST'> and C<want 'BOOL'> will be true.
And C<want()> without args will return C<(Inf,'LIST','RVALUE', 'BOOL')>.
> > 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!
I really hope I'm just missing the implicit smiley there.
> NaN is NaN, not zero. Hmm. So to get perl5 semantics, one must
> do stuff like
> $X = + function();
> $X == NaN and $X = 0;
Err. What Perl 5 semantics are you trying to "get" here?
> or is NaN false?
> $X = +function() || 0;
I would imagine NaN is likely to be false.
> 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
No. I believe *any* failure to numerify would produce a 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.
As I explained above, the new scalar context operator is C<$(...)>.