Re: Return with no expression
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 expression followed by the :: operator, so under normal
conditions the namespace-oriented :: will never be mistaken for the ::
that goes with ??, because the parser won't be looking for that kind
of :: except after a ??.
It may be though that if you need to put the namespace-oriented ::
between a ?? and its corresponding ::, you might need parentheses:
my $foo = $bar ?? ($baz::wibble) :: $baz::quux; # This is clear and good.
Otherwise...
my $foo = $bar ?? $baz::wibble :: $baz::quux; # This is more questionable.
The parser _might_ try to pair the first :: with the ??, in which case
it's going to get confused -- probably when it tries to figure out
what wibble is, or definitely when it hits the second :: -- and would
then have to either backtrack or complain. (Complaining is easier;
backtracking is DWIMmier and arguably more Perlish in the long run but
could be added in the post-6.0 era if desired; turning a former error
into something valid is usually considered to be backward-compatible.)
But that case -- using the namespace :: between ?? and :: -- should be
the only situation where any ambiguity could arise over ::, and so it
seems reasonable to require (or at least strongly recommend) the
parentheses in that case.
I am assuming here that we don't need to have a unary or binary ??
operator. That would complicate matters rather substantially.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: Return with no expression
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. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker There is no cabal.
Re: Return with no expression
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 logic operators could treat a pair specially by testing C.key, but returning C.value... hence no overloading of Cor... it's the way everything works (or everything is overloaded, depending on how you look at it). The problem would be that that C'a' would be evaluated regardless of C$foo's value. There it makes no difference, but here: $foo = a() or b() it's huge... But it seems to me that something like this would be the way to go if you could make it work.
Re: Return with no expression
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 'or' there is (IMHO) far more dangerous than the
overloading of '::' being discussed in this thread.
Not necessarily. You're assuming that Ceither 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. Cimplies).
We could actually define ?? as a binary operator in much the same way.
Dave.
Re: Return with no expression
On Tue, 2004-08-24 at 11:50, Dave Whipp wrote:
You're assuming that Ceither 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. Cimplies).
We could actually define ?? as a binary operator in much the same way.
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.
Precedence worries me a bit, since I don't know how ~~ and ?? would fit,
but it's certainly nice to have this construct use a generic Perl 6
operator like ~~ and not have to have any ternary constructs in the
language.
--
781-324-3772
[EMAIL PROTECTED]
http://www.ajs.com/~ajs
Re: Return with no expression
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;
}
}
But, I find:
for @words - $word {
say $word ~~ abbreviate($word) ?? $word;
}
much simpler! Overall, I would discourage the use of C$_ as topic in
most situations. We spent so long in Perl 5 wanting the ability to
default to whatever variable we wanted, to keep using C$_ in the
general case now that we have that is kind of a step backwards.
But you are re-creating the same problem that we had in Perl 5.
By only allowing $_ to decide which expression to evaluate you are
prohibiting the use of anything that acts on the default topic of
the enclosing block in those expressions. This is exactly the problem
of nested maps etc. in Perl 5.
Don't get me wrong, I like the idea. But it does not come without its
own set of limitations.
Graham.
Re: Return with no expression
On Tue, 24 Aug 2004, Aaron Sherman wrote:
On Tue, 2004-08-24 at 11:50, Dave Whipp wrote:
You're assuming that Ceither 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. Cimplies).
We could actually define ?? as a binary operator in much the same way.
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.
Precedence worries me a bit, since I don't know how ~~ and ?? would fit,
but it's certainly nice to have this construct use a generic Perl 6
operator like ~~ and not have to have any ternary constructs in the
language.
My problem is that then you can't get to the original topic. I think too much
topic-clobbering will be confusing.
say chars($_) 70 ~~ abbreviate($_) ?? $_; #oops, prints the length
--
Adam Lopresto
http://cec.wustl.edu/~adam/
[MacGyver] is the Martha Stewart of action.
--Patrick J. Mooney
Re: Return with no expression
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 difficulties with recognizing C:: as part of C... ?? ... :: ... and C:: as module sigil? Does it involve some DWIM? Would we have mandatory space after C?? :: ? I didn't get perl6 syntax well yet, so if it's true, you can give better examples yourself..
Re: Return with no expression
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 there in perl6 any difficulties with recognizing C:: as part of C... ?? ... :: ... and C:: as module sigil? Does it involve some DWIM? Would we have mandatory space after C?? :: ? I didn't get perl6 syntax well yet, so if it's true, you can give better examples yourself.. 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 looking for different things in different places, I suspect. And if this message comes out with strange and stranger formatting, that's because Thunderbird's doing some very odd things in the compose window and I'm not entirely sure how it's going to come out.
Re: Return with no expression
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 some people aren't going to like mandatory whitespace around an already rather fat operator. It's only manditory where it would be misinterpreted as a package sigil/separator. $foo??split()::0; Ought to be fine, though: $foo??split::0; Would croak on you. Luke
Re: Return with no expression
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 or split(); to the troublesome double-usage of C::
Re: Return with no expression
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 stands out as much as it should.
Re: Return with no expression
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 ignore this suggestion, I know it's a terrible one :)
Re: Return with no expression
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 him hours to figure out went wrong! Luke
Re: Return with no expression
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 any reasoning involved? As far as I can recall, it was entirely due to random factors. :-) Sush, I'm giving you credit from pure blind faith here ;-) 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 :-)
Re: Return with no expression
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)... that's in the IEEE spec, isn't it? ;-)
Re: Return with no expression
-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. If you say rand 0, it gives you a random number between 0 and 1, which was supposed to be What I Meant. That led to code like this (Perl6ized as usual): my $num = $param == 0 ?? 0 : rand $param; my $num = $param == 0 ?? 0 :: rand $param; surely? Repeating the test that it did itself, just to get consistent behavior. We must be careful not to repeat mistakes like this in the design of Perl 6 [1]. 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. If that behaviour is required, then rand undef; would behave as expected (call with no parameters to get [0, 1), with one param to get [0, $param) ), but really if you want a random number between 0 and 1 why aren't you calling rand 1? Feels like a Cism. Ick. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBJbRx0UvYjCBpIlARAjV2AJ0TSuchOHcVMqg3HUPLJ6G5zhnRYwCfQ/26 C6DCRHq0BjxqX4eH5vUeWwk= =ctmb -END PGP SIGNATURE-
Re: Return with no expression
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 involved? As far as I can recall, it was entirely due to random factors. :-) I suspect there's an argument that [0,0) ought to be considered undef (which would conveniently numerify to 0 with an optional warning). Larry
Re: Return with no expression
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.
Cparam uses Creturn;. In this example, it's called in list
context. So if there is no 'baz' parameter, the list will get shifted
like so:
my $foo = Bar-new(
name = Baz,
value = something,
else = undef
);
I can't imagine how much trouble this would have caused me if I didn't
know about the Creturn; special case. Any chance this will work
differently in Perl 6?
Yep. First of all, param('baz') would be called in scalar context,
since it's on the right side of a pair constructor, as you're about to
say.
I'd be tempted to suggest that C=, in its new role as pair
constructor, put things in scalar context, but lately I've started to
write join's like so:
my $string = join , = @array;
No such luck. I use = in all sorts of places where , usually goes.
But I'm going to have to change my ways for Perl 6. All in all, I think
the pair object gives us too many wins over the fat comma.
On the other hand, you can now write your join in any of the following
ways:
join ,, @array;
@array.join(,);
join @array: ,;
*join(q{,}[EMAIL PROTECTED]);
:-)
Luke
Re: Return with no expression
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*? :)
See the problem?
Yes, you forgot scalar. param() is *documented* to behave differently in
list context. It's not an unfortunate side-effect, but the official,
documented API.
In fact, this was anticipated and the doesn't-exist case is explicitly
documented as:
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.
I can't imagine how much trouble this would have caused me if I didn't
know about the Creturn; special case.
There is no need to know about the special case, because you can read
exactly how it works in the documentation.
The bare return is there only to avoid a warning. param's behaviour
wouldn't be different with only the second return statement:
return wantarray ? @{$self-{$name}} : $self-{$name}-[0];
my $string = join , = @array;
my $string = join , == @array;
It's a 180, but it'll workforme.
Juerd
Re: Return with no expression
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 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 Cparam as an example. The behavior would exist with any subroutine that used Creturn;. I can't imagine how much trouble this would have caused me if I didn't know about the Creturn; special case. There is no need to know about the special case, because you can read exactly how it works in the documentation. The point that it's documented for Cparam and for Creturn 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. my $string = join , = @array; my $string = join , == @array; It's a 180, but it'll workforme. I think I'm going to go with C @array.join(,) . :) -- matt Juerd
Re: Return with no expression
Matt Diephouse writes: The point that it's documented for Cparam and for Creturn 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 many forms of DWIM. This is something we must always consider when adding a DWIMity. How could it subtly introduce bugs, or how could it be a pain? Some DWIMs become a major pain when you're dealing with generics, for instance, by requiring the user to duplicate the type switch used internally just go get consistent behavior. 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. If you say rand 0, it gives you a random number between 0 and 1, which was supposed to be What I Meant. That led to code like this (Perl6ized as usual): my $num = $param == 0 ?? 0 : rand $param; Repeating the test that it did itself, just to get consistent behavior. We must be careful not to repeat mistakes like this in the design of Perl 6 [1]. Luke
Re: Return with no expression
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 Cparam as an example. The behavior would exist with any subroutine that used Creturn;. It would be nice if Perl thought that = was scalar context for the expression that follows it. But then it wouldn't be just like a comma, would it? Regards, David smime.p7s Description: S/MIME cryptographic signature
Re: Return with no expression
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 C,, but that doesn't mean that you can maintain some little smidge of state in the op that tells you that your right hand side should not be and expression that returns a list of more or less than one element. Yes, that would be very helpful. I get bit by this all the time myself. But even more helpful would be if C = enforced a scalar context in Perl 5, too. Regards, David smime.p7s Description: S/MIME cryptographic signature
