Re: Hypothetical variables and scope
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 \( $name:= \) ]? }
and have $name end up bound to the correct submatch even if the closing
paren is missing and the optional block fails.
> 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.
It's also a matter of syntactic consistency. It has to be := for
"inlined" bindings (i.e. rx/ $name:= /) because otherwise
we make = meta (which is *not* a good idea). So it probably should be
:= for explicit Cs as well.
Damian
Re: Argument aliasing for subs
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.
The idea of the C property is that it *changes* the external key by
which you specify the corresponding parameter when using named parameters.
That is:
sub foo ($bar is named('baz')) {
print $bar; # Okay
print $baz; # Error (not a real param)
}
foo(bar=>1);# Error (not known by this name externally)
foo(baz=>1);# Okay
Whereas the property *adds* an alias for the corresponding parameter,
when using named parameters. That is:
sub foo ($bar is aka($baz)) {
print $bar; # Okay
print $baz; # Okay (Just another name for $bar)
}
foo(bar=>1);# Okay
foo(baz=>1);# Okay (Just another key meaning bar=>1 )
> So, should it really be
>
> int $force is aka($override)
Yes.
> or
>
> int $force is aka('override')
No, not the way I intended it.
> I much prefer the latter because: a) it unquestionably marks 'override'
> as a label for $force,
It's not meant to be. That's what C would be for.
> b) the subroutine author is likely to use either
> $force or $override and not both,
Possibly. But if it's truly an alias, they should be able to use both.
> c) it gives meaning to things like "$force is aka(@override)"
True. Though it would be more useful in reverse:
sub foo (@bar is aka($baz)) {
# now @bar is an array
# and $baz is an array ref
}
> Then again, if you have good reasons for the other syntax, I would be
> more than happy to hear those as well.
Then I hope this made you happy. ;-)
Damian
Re: Hypothetical variables and scope
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 (which is *not* a good idea). So it probably should be
> := for explicit Cs as well.
If "let" only works on bindings, it really bites into the
expressiveness of the language. For example, the "natural" way
to skip text within a match is to do something like:
/ (\w+) \d+ (\w+) { let $1 _= $2; let $2 = undef } /
This feels natural too:
/ (\w+ \d+ \w+) { let $1 =~ s/\d+// } /
Binding might be really fast for some implementations of Perl,
but slow for others. Just like string eval may be impossible in
some, but trivial in others.
- Ken
Re: Hypothetical variables and scope
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 or one of the other folks from perl6-internals I think you're OK. :) Generally things are better if people clarify what they want, rather than specify optimization hints, otherwise you end up with dopey things like Java's final stuff. If the optimizer knows what you want to do it is more likely to be able generate fast code, but that works best when you clearly express the semantics -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Suggestion for perl 6 regex syntax
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 accurate. You could
certainly make your own and rules, but I bet most people won't
use them nearly enough for that sort of shortening.
Also, your sample regexps aren't exactly fair, because you're using capturing
groups all over the place for things that I'm pretty sure you don't really want
to capture, just to group. So your perl5 would have to be rewritten from
/^([+-]?)(?=\d|\.\d)\d*(\.\d*)?([Ee]([+-]?\d+))?$/ #50 chars
to
/^([+-]?)(?=\d|\.\d)(\d*(?:\.\d*)?)(?:[Ee]([+-]?\d+))?$/ #56 chars
(capturing sign, mantissa, and exponent: you could capture differnt things if
you want, or you could capture nothing. But capturing random things just
because they save you a few keystrokes isn't a good practice)
We could golf that down to
/^(+|-)?(?=\d|\.\d)(\d*(?:\.\d*)?)(?:E([+-]?\d+))?$/i #53 chars
if you really care about every last character.
The perl 6 equivalent becomes
:i/^(+|-)?(\d*[\.\d*]?)[E([+|-]?\d+)]?$/ #56 chars
So you're not losing much at all. That is, if you really want to spend forever
fighting for every last character. The point is, when you use unusual
contructs like lookaheads you pay a price in order to get more clarity. When
you use common/good things like non-capturing parens, you are rewarded in fewer
keystrokes.
Also note that we could dramatically rewrite the pattern, and instead of doing
a lookahead assertion we can use an actual code assertion to assert that the
mantissa isn't empty, making the new perl6 code actually shorter than the
(correct) perl5 version. Of course, that's because we use perl6's strengths.
:i/^(+|-)?(\d*[\.\d*]?)<($2=~/./)>[E([+|-]?\d+)]?$/#51
> While Apocolypse 5 raises some good points about problems with the old regex
> syntax, its new syntax is actually worse than in perl 5. Most regexes, such
> as this one to match a C float
>
> /^([+-]?)(?=\d|\.\d)\d*(\.\d*)?([Ee]([+-]?\d+))?$/
>
> would actually become longer:
>
> /^(<[+-]>?)\d*(\.\d*)?(<[Ee]>(<[+-]>?\d+))?$/
>
> Therefore I propose a few minor changes:
>
> character class: [...]
> non-captured group: {...}
> closure: <{...}>
> lookahead assertion:
> lookbehind assertion:
>
> This would bring the aforementioned regex back down to perl 5 size, and many
> would become even shorter than in perl 5.
>
> __
> Do You Yahoo!?
> Yahoo! Finance - Get real-time stock quotes
> http://finance.yahoo.com
>
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
Dreaming permits each and every one of us to be quietly and safely
insane every night of our lives.
--William Dement
Re: Second try: Builtins
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 that C<+> be there? I would expect chomp only to remove a single
line-break.
> sub reverse(@list) {
> my @r;
> my $last = @list.length - 1;
> for(my $i=$last;$i >= 0;$i++) {
> @r[$last-$i] = @list[$i];
> }
> return *@r;
> }
In a scalar context does C still a string with characters
reversed?
Smylers
Re: Argument aliasing for subs
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".
_
Join the worlds largest e-mail service with MSN Hotmail.
http://www.hotmail.com
Re: Argument aliasing for subs
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 expect it to output "false".
Why? I believe that, whatever you set $var to, you have marked the
variable as constantly true in booleans.
Where this gets weird is that someone might write:
sub foo {
my $result is true;
# (do stuff setting result)
if $success {
return $result;
} else {
return undef;
}
}
Thinking that the initial "is true" will cause the test
if foo()
will always be true if the sub succeeded, even if $result was zero. But I
don't think that's how it works, since the C will pass the
*value*, which has not been tagged with "but true", not the variable,
which has been tagged with "is true". So the test will fail when $result
was zero. (Unless there's something going on where the "is true" property
confers a property to the value, which I suppose is possible, but weird.)
My guess is that
return $foo but true;
will become a common piece of Perl 6 idiom.
Trey
Re: Argument aliasing for subs
>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 reference values that are true or false. That is why I want to understand if "is" sets properties of variables or values. _ Chat with friends online, try MSN Messenger: http://messenger.msn.com
s/// in list context
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 return true/false return true/false list context: match from startcontinue progressive match return list of captures if captures return list of captures else return list with all matches this confuses me enough already. But I've just about got my head round it. (strictly, I can only remember the left column, and that I need to check the camel for the rest. However I then needed to write a test program because Camel III doesn't say whether list context m//g starts from the beginning or from pos) This is from perl5-porters, and the wrong code was in a patch I sent: On Sun, Sep 08, 2002 at 03:57:44PM +0100, [EMAIL PROTECTED] wrote: > Nicholas Clark <[EMAIL PROTECTED]> wrote: > Thanks, applied as #17859. > > This bit: > -s/^(\w+)=(true|\d+)\s*$/$1='$2'\n/; > -my ($k,$v) = ($1,$2); > +my($k, $v) = s/^(\w+)=(true|\d+)\s*$/$1='$2'\n/; > .. caused a problem, reversed as #17860. (s/// returns success only, > even in list mode.) There's only 1 version of s///, but I actually find it more confusing, since I expect the left of a s/// to work just like a m// So would it be possible for s/// to have the same return values as m// in perl6? Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: Argument aliasing for subs
> "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 time error.
SC> $var=0;
SC> if ($var) {print "true"}
SC> else {print "false"}
SC> I would expect it to output "false".
it won't even compile so i don't expect output. :)
this wasn't clear enough when it was discuss. you can't set data
properties on a variable and vice versa. 'is' sets variable props and
'but' sets data props. runtime stuff will usually check data props
(maybe readonly which is a variable prop would be checked then
too). compile time stuff will deal with variable props.
OO will be a different story as all the my Dog $spot threads have
shown. until that apocalypse i won't venture how OO will deal with props.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
Re: @array = %hash
> [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) {
...
if %adverbs{keyed} = PAIR {
...
}
}
# create 2 element hash:
%hash = : { keyed=>PAIR } (1, 2, 3=>4, 5=6);
--
ralph
