> [run time control of assignment behavior when array contains pairs]
How much have I misunderstood things from a mechanisms
available point of view (as against a practical / nice way to
do things) when I suggest something along the lines of:
my sub op:= (*@list : %adverbs) {
...
> "SC" == Steve Canfield <[EMAIL PROTECTED]> writes:
SC> Would it be accurate to say that "is" sets properties of variables,
SC> whereas "but" sets properties of values? If so, what would this output:
SC> my $var is true;
that is not a variable property so it should be a compile tim
I realise that it's almost 2 years since the RFC deadline, plus we're
several apocolypses past the appropriate Camel chapters.
IIRC there are 5 different variants of m//
normal /g
scalar context: match from startcontinue progressive match
>From: Trey Harris <[EMAIL PROTECTED]>
>To: Steve Canfield <[EMAIL PROTECTED]>
> > I would expect it to output "false".
>
>Why? I believe that, whatever you set $var to, you have marked the
>variable as constantly true in booleans.
Because in my experience variables are not true or false. They
In a message dated Sun, 8 Sep 2002, Steve Canfield writes:
> Would it be accurate to say that "is" sets properties of variables, whereas
> "but" sets properties of values? If so, what would this output:
>
> my $var is true;
> $var=0;
> if ($var) {print "true"}
> else {print "false"}
>
> I
Would it be accurate to say that "is" sets properties of variables, whereas
"but" sets properties of values? If so, what would this output:
my $var is true;
$var=0;
if ($var) {print "true"}
else {print "false"}
I would expect it to output "false".
__
Aaron Sherman wrote:
> sub chomp($string is rw){
> my $irs = ${"/"}; # XXX What is $/ now?
> if defined $irs {
> if $irs.isa(Object) {
> return undef;
> } elsif $irs.length == 0 {
> $string =~ s/ \n+ $ //;
Should
Some regexpes will be longer, but a lot will benefit from the changes, by being
shorter or clearer, or often, both. The problem with your suggestion is you're
making assumeptions about what's common and what's not (character classes more
common than closures, for instance) that probably aren't ac
At 6:59 AM + 9/7/02, Damian Conway wrote:
>Jonathan Scott Duff wrote:
>>Sounds like an optimization that should be in the hands of the
>>programmer to me.
>
>Possibly. Though leaving optimization in the hands of the programmer
>is generally a Bad Idea.
Oh, I dunno... If that programmer is me
Damian Conway wrote:
> Though leaving optimization in the hands of the programmer
> is generally a Bad Idea.
That doesn't sound like a Perl slogan.
> It's also a matter of syntactic consistency. It has to be := for
> "inlined" bindings (i.e. rx/ $name:= /) because otherwise
> we make = meta (whi
Peter Behroozi wrote:
>> sub hidden (str $name, int $force is aka($override)) {...}
>
>
> Hang on a moment! In your original answer to this question, you used
> the "is named('alias')" syntax, but now you are suggesting using the
> sigil in the syntax.
Yes, but for a *different* property.
Jonathan Scott Duff wrote:
>>Because what you do with a hypothetical has to be reversible.
>
> I thought it was just the hypothetical's existence that has to be
> reversible.
That's not my understanding. You need to be able to cope with this too:
rule alias :w { \$ $name:= [is named \(
12 matches
Mail list logo
