On Tue, 24 Aug 2004, Aaron Sherman wrote:
> On Tue, 2004-08-24 at 11:50, Dave Whipp wrote:
>
> > You're assuming that C in a ternary operator. It
> > could be a binary operator, defined as {eval $RHS if $LHS; return $LHS}. For
> > that interpretation, one might choose a different name (e.g. C).
>
On 24 Aug 2004, at 22:14, Aaron Sherman wrote:
You don't HAVE to use auto-topicalization. You CAN always write it
long-hand if you find that confusing:
for @words -> $word {
given ($chars($word) > 70) -> $toolong {
say abbreviate($word) ?? $word;
On Tue, 2004-08-24 at 15:55, Adam D. Lopresto wrote:
> On Tue, 24 Aug 2004, Aaron Sherman wrote:
> > Yep, and since ~~ auto-topicalizes its lhs for its rhs, your binary ??
> > is all you need. I wish I'd seen your message before I sent my recent
> > one, as I would have just started from there.
>
Dave Whipp <[EMAIL PROTECTED]> wrote:
>
> "Brent 'Dax' Royal-Gordon" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > The overloading of 'or' there is (IMHO) far more dangerous than the
> > overloading of '::' being discussed in this thread.
>
> Not necessarily. You're assuming tha
On Tue, 2004-08-24 at 11:50, Dave Whipp wrote:
> You're assuming that C in a ternary operator. It
> could be a binary operator, defined as {eval $RHS if $LHS; return $LHS}. For
> that interpretation, one might choose a different name (e.g. C).
> We could actually define ?? as a binary operator in
"Brent 'Dax' Royal-Gordon" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Aaron Sherman <[EMAIL PROTECTED]> wrote:
> > I've always thought that particular bit of sugar was rather dangerous.
> > I'd even prefer a longhand:
> >
> > $foo either 0 or split();
>
> The overloading of
Luke Palmer wrote:
Aaron Sherman writes:
$foo??0::split()
ouch!
Yeah, seriously. I mean, what a subtle bug! It would take him hours to
figure out went wrong!
Sarcasm is an ugly thing.
One thing that I just thought of that could be intersting:
$foo => 'a' or 'b'
My thought was that l
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> I've always thought that particular bit of sugar was rather dangerous.
> I'd even prefer a longhand:
>
> $foo either 0 or split();
The overloading of 'or' there is (IMHO) far more dangerous than the
overloading of '::' being discussed in this thread.
"Alexey Trofimenko" <[EMAIL PROTECTED]> writes:
> I wanna ask, could be there in perl6 any difficulties with
> recognizing C<::> as part of C<... ?? ... :: ...> and C<::> as
> "module sigil"? Does it involve some DWIM?
Among other things, the ?? will tip off the parser that it's looking
for an ex
Aaron Sherman writes:
> Luke Palmer wrote:
>
> > $foo??split()::0;
> >
> >Ought to be fine
> >
>
> Imagine the shock of the first guy who rezlizes he got the logic
> backwards and "bug-fixes" it to:
>
> $foo??0::split()
>
> ouch!
Yeah, seriously. I mean, what a subtle bug! It would take
I think I'd prefer that as well, since it has the advantage of not having
to use the evil shift key. Though i don't think it stands out as much as
it should.
I hate to reply to my own message, but...
How about
$foo??split()!!0;
for a touch of craziness. Or is !! not usable? Actually, just igno
I've always thought that particular bit of sugar was rather dangerous. I'd
even prefer a longhand:
$foo either 0 or split();
to the troublesome double-usage of C<::>
I think I'd prefer that as well, since it has the advantage of not having to
use the evil shift key. Though i don't think it s
Luke Palmer wrote:
$foo??split()::0;
Ought to be fine
Imagine the shock of the first guy who rezlizes he got the logic
backwards and "bug-fixes" it to:
$foo??0::split()
ouch!
I've always thought that particular bit of sugar was rather dangerous.
I'd even prefer a longhand:
$foo either 0
Juerd writes:
> Where :: (in a module name) can be used, an operator could have been
> used.
>
> How is $foo??Bar::Baz::Quux parsed?
$foo ?? Bar::Baz::Quux; # error, :: expected
Indeed, this is illegal:
Bar::Baz :: Quux.new;
No whitespace allowed.
> I hope it's an error, although so
Matthew Walton skribis 2004-08-23 23:12 (+0100):
> I doubt that's a problem, as C<::> as part of the ternary operator is
> only going to be found where an operator is expected, and C<::> as part
> of a module name is only going to be found where an identifier is
> expected, so it's a matter of l
Alexey Trofimenko wrote:
On Fri, 20 Aug 2004 09:21:02 +0100, Matthew Walton
<[EMAIL PROTECTED]> wrote:
On 19 Aug 2004, at 18:04, Luke Palmer wrote:
[...]
my $num = $param == 0 ?? 0 : rand $param;
my $num = $param == 0 ?? 0 :: rand $param;
surely?
a little off theme.. I wanna ask, could be
On Fri, 20 Aug 2004 09:21:02 +0100, Matthew Walton
<[EMAIL PROTECTED]> wrote:
On 19 Aug 2004, at 18:04, Luke Palmer wrote:
[...]
my $num = $param == 0 ?? 0 : rand $param;
my $num = $param == 0 ?? 0 :: rand $param;
surely?
a little off theme.. I wanna ask, could be there in perl6 any difficul
> "AS" == Aaron Sherman <[EMAIL PROTECTED]> writes:
AS> Matthew Walton wrote:
>> Larry Wall wrote:
>>
>>> I suspect there's an argument that [0,0) ought to be considered undef
>>> (which would conveniently numerify to 0 with an optional warning).
>>
>> In the absence of a parad
Matthew Walton wrote:
Larry Wall wrote:
I suspect there's an argument that [0,0) ought to be considered undef
(which would conveniently numerify to 0 with an optional warning).
In the absence of a paradox value, undef would be fine there I think :-)
Too bad we don't have NaRN (Not a Random Number).
Larry Wall wrote:
On Fri, Aug 20, 2004 at 09:21:02AM +0100, Matthew Walton wrote:
: It would be nice if rand behaved a bit more sanely in Perl 6. I can
: understand the reasoning for making rand 0 produce between 0 and 1, but
: that doesn't mean I have to like it.
What makes you think there was
On Fri, Aug 20, 2004 at 09:21:02AM +0100, Matthew Walton wrote:
: It would be nice if rand behaved a bit more sanely in Perl 6. I can
: understand the reasoning for making rand 0 produce between 0 and 1, but
: that doesn't mean I have to like it.
What makes you think there was any "reasoning" in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19 Aug 2004, at 18:04, Luke Palmer wrote:
The one in Perl 5 that stands out most was the cause for the only patch
I ever sent to p5p: the rand function. "rand $x" will give you a
uniformly distributed random number in [0, $x) for any $x EXCEPT 0. I
On Aug 19, 2004, at 11:07 AM, Aaron Sherman wrote:
First off, in Perl 6, I *think* that that C<< => >> will enforce a
scalar context (it's a tuple operator, last I recall).
W00t!
Second, in Perl 5 it should not be hard to identify such situations for
warning purposes. C<< => >> may be a synonym for
On Aug 19, 2004, at 9:41 AM, Matt Diephouse wrote:
If the parameter does not exist at all, then param() will return
undef in a scalar context, and the empty list in a list context.
Sure enough. And I've even read a large percentage of the (unwieldy)
CGI.pm docs. But I was using C as an exam
On Thu, 2004-08-19 at 10:03, Luke Palmer wrote:
> Matt Diephouse writes:
> > use CGI qw(:standard);
> >
> > my $foo = Bar->new(
> > name => "Baz",
> > value => param('baz'),
> > something => 'else'
> > );
> >
> > See the problem?
>
> Yikes, yeah, that see
Matt Diephouse writes:
> The point that it's documented for C and for C doesn't
> remove the fact that while this DWIM the majority of the time, it can
> be the cause of a subtle bug. I'm sure many people don't know about
> the DWIM behavior. Or aren't actively aware of it.
As is the case with man
On Thu, 19 Aug 2004 17:52:18 +0200, Juerd <[EMAIL PROTECTED]> wrote:
> Ouch. You have foo-bar-baz code *at work*? :)
Unfortunately, some of the code here is much worse than that.
> In fact, this was anticipated and the doesn't-exist case is explicitly
> documented as:
>
> If the parameter do
Matt Diephouse skribis 2004-08-19 9:35 (-0400):
> But I came across this code at work this week:
> use CGI qw(:standard);
> my $foo = Bar->new(
> name => "Baz",
> value => param('baz'),
> something => 'else'
> );
Ouch. You have foo-bar-baz code *at work*? :)
>
Matt Diephouse writes:
> use CGI qw(:standard);
>
> my $foo = Bar->new(
> name => "Baz",
> value => param('baz'),
> something => 'else'
> );
>
> See the problem?
Yikes, yeah, that seems so innocent.
> C uses C. In this example, it's called in list
> cont
I recently got bit by C in Perl 5, which leads me to wonder
about Perl 6. C, when called without an expression, tries to
DWIM, returning an empty list in list context and undef in scalar
context, which is generally a good thing. But I came across this code
at work this week:
use CGI qw(:standa
30 matches
Mail list logo
