Re: Suggestion for perl 6 regex syntax
Yeay! Golf... Adam D. Lopresto wrote: [...golf...] > /^([+-]?)(?=\d|\.\d)\d*(\.\d*)?([Ee]([+-]?\d+))?$/ #50 chars [...more golf...] > Of course, that's because we use perl6's strengths. > > :i/^(+|-)?(\d*[\.\d*]?)<($2=~/./)>[E([+|-]?\d+)]?$/ #51 Clever! But If we are allowed to use all of perl6 in this particular (golf-)course, I suggest: // That way I get it down to 11 characters. Perl6 will be a *great* language. David -- www.panmedia.dk - perl consulting in Denmark, Scandinavia, Europe.
Re: More A5/E5 questions
Jonathan Scott Duff wrote:
> Question #3:
>
> Related to question #2, if I didn't use hypotheticals, how would I
> access the Nth match of a repitition? For instance, in E5, there's an
> example that looks like this:
>
> rule file { ^ @adonises := * $ }
>
> If I didn't have the hypothetical @adonises, how would I retrieve the
> 3rd hunk matched? Would I need to write it like so:
>
> rule file { ^$ }
> rule hunks :e { () }
>
> and then access it with $0{file}{hunks}[2] ?
For a while worries about this have been brewing in my mind.
[worry #1]
The hypothetical 'variables' we bind to aren't really variables but keys to a hash.
Thus they shouldn't have sigils in their names at all.
Ok, that may give us problems with giving rules context, but maybe we could simplify
that, such that rules always got scalar context to work in (that's pretty close to the
truth anyhow since their results are being stored in a hash - for some definition of
'truth').
Then maybe we could differentiate between building a match object and capturing data
into variables that are defined in a higher scope.
So
/^$ /
(or alternately (the binding just changes the name
of the key in the match object))
/^ myhunk := $ /
and
/^ $hunk := $ /
would do different things, since the first only builds a match object, and the second
only binds $hunk.
[worry #2]
Since $0 has only a rather vague relation to $1..$n, maybe its name isn't that
relevant. Especially since we'll be indexing into it all the time. Maybe $MATCH,
$RESULT, $RX (those names aren't convincing me either, sorry).
If nothing else, this would at least get rid of "one more cryptically names variable".
David
--
www.panmedia.dk - Excellent Perl consulting for Denmark, Scandinavia, the World
Re: More A5/E5 questions
Nicholas Clark wrote:
> Related, I think: no-one answered my question about what happens when I
> define
>
> sub dumb ($var, @var) {
> ...
> }
>
> and then call it with the pair var=>$thing
Exception, probably. Perhaps the error would be something like:
"Dumb ambiguous binding of dumb named parameter ("var") at demo.pl line 1. Dummy."
;-)
> Presumably for clarity it is better to store the sigil in the match object,
> because if I've understood perl6 symbol tables correctly they are going to
> be storing names-with-sigils. (To allow the elimination of typeglobs)
The part about sigils being part of symbol table keys is indeed correct.
Damian
Re: reduce via ^ again
John Williams wrote: > Back in October I suggested that $a ^+= @b would act like reduce, > but in discussion > it was decided that it would act like length > I now pose the question: Is ^+= a "hyper assignment operator" or an > "assignment hyper operator"? > with a scalar involved > the method and the result is different. $a = length(@b) is the > "assignment hyper operator" > interpretation. The "hyper assignment operator" interpretation looks > like this: > > $a ^+= @b > ($a, $a, $a, ...) ^+= @b > $a += $b[0], $a += $b[1], $a += $b[2], ... I can't remember what side I argued last October (I can't remember last October! %-) I have to say that I'm with John here. That interpretation certainly seems more DWIM to me. Damian
Re: Argument aliasing for subs
Erik Steven Harrison wrote:
> Just found this hidden in my inbox.
> I didn't think anyone was paying attention ;-).
Oh, we *always* pay attention. We just don't always respond. ;-)
>>What I most like about the C syntax is (like methods in
>>OO Perl), it associates a meaningful *name* with each
>>deviation from standard behaviour.
>
> This is the argument that would win me over to the property syntax.
> Self documenting code is an admirable goal. But I wonder about our
> overuse of 'is'.
Think of it as punctuation. As a necessary alternative to the poor
overworked colon.
> The performance issues of a hash that lives with every variable aside,
They're not really relevant with C, since it's compile-time in effect.
> it all looks the same to me. And I like different things to look different.
A fair point. My counterargument is that you're looking at the wrong bit.
C, C, C, etc all look very similar,
structurally. But so do C<$obj.foo()>, C<$obj.bar()>, and C<$obj.baz()>.
Yet we cope quite well with the OO syntax, because we look at the different
method names, not the shared dot introducer.
Properties have a great deal in common with methods, and so it really
should be surprising that they're invoked in a structurally similar manner.
Think s//is/.
>>I find:
>>
>> sub hidden (str $name, int $force is aka($override)) {...}
>>
>>*much* more readable, since I can read it in English.
>
> Yeah . . . except I want at least single quotes around that darn $override.
> Required singles even. Having it be context sensitive to the type of property
> is WAY to subtle for me. And if $override is a reference I'd like that to DWIM (
> though I understand that I may be the only person for which that behavior is
>intuitive).
> And what happens with double quotes - a symref? Ack!
Then why don't you want single quotes around the C<$name> and C<$force>?
After all, they're not being evaluated there either.
The C would be a form of auxiliary declaration, so it's quite as
reasonable not to put annoying quotes around it. It just means that the
parameter list of the property would be declared with one of Larry's
postulated C/)> properties.
> If $force is aka(@override) is going to be a compile time error, then why can't we
> just $force is aka(override) and just carry the typing over.
So you can't stand a bare declarative variable, but you'd accept a bareword??? ;-)
The rason I'd do it the way I've suggested is precisely so that if someone's flawed
mental model causes them to write:
$force is aka(@override)
that *logical* bug in their thinking is detected and flagged.
> And if it's not a compile time error then what in Knuth's name
Now, now, no need to invoke deities! ;-)
> oh never mind - my head just exploded.
Hang in there. If these "mixed number" Cs were allowed then I'd suggest
the semantics be that they indicate that *either* a scalar or array is
acceptable in the corresponding argument slot. The scalar variant of the
parameter would be bound to a scalar argument, or to a reference to an array
argument. The array variant of the parameter would be bound to an array
argument, or it's zeroth element bound to a scalar argument.
> -Erik
>
>>Damian
>
> PS - Ha! My name above Damian's :-)
Letting me get the last word, eh? Very kind of you. ;-)
Damian
Re: Argument aliasing for subs
Erik Steven Harrison wrote:
> But still, what counts as a runtime property, other than true or
> false, as in the delightful '0 but true'? What other kind of runtime
> labels can I slap on a value?
Here's ten to start with...
for <> but tainted(0) {...} # note that external data is
# from a trusted source
return 255 but undef; # i.e. system() returns
# "undefined 255" on failure
return $cached_for{$arg} but Cached
//= compute_for($arg); # memoize return value
# but mark when from cache
$result = heuristic($data) but Estimated
unless %known{$data}; # indicate when value is a guess
my $temp is Units('Celsius')# indicate units of variable
= 273 but Units('Kelvin'); # indicate units of value
# (maybe autoconverted?)
return $val but Error(-1..+2); # indicate error bars
$data = $text but Encrypted($public_key);
# unusable without private key
$days = 29 but From(My.line); # record source of
# improbable value
$days = 29 but Reason("Leap year");
# so-called "active comment"...
# documents why improbable value
# used but can also be retrieved
# programmatically
$name = "Damian" but We_better_call_ya("Bruce");
# indicate correct Australian
# pronunciation ;-)
Damian
Throwing lexicals
I was thinking about regular expressions and hypotheticals again this
weekend, and something was bothering me quite a lot. How do rules create
hypotheticals?
Since a rule behaves like a closure, I can see how it could gain access
to existing lexicals, if it's declared inside of the same scope:
my $x = 1;
/ $x /;
Good so far, now we change said lexical:
my $x = 1;
/ $x := (2) /;
Ok, got that. Now what about lexicals that aren't declared:
/ $x := (2) /;
This bothers me. Yes, I can see how you could do it via %MY:: or however
that's spelled (I'm typing this in a Vermont B&B, so I can't quite go
check A2), but opening up the stack of my caller and mucking around with
their contents seems rather rude. As Pink Floyd once said, "get your
hands off of my stack!"
So, here's an immodest proposal for kinder and gentler stack mucking.
Essentially, these lexicals are out-of-band return values, and Perl 6
already has a mechanism for out-of-band return information: properties.
When you look at it like this, what you want to do is "throw" these
lexicals up the stack to your caller and let them do the right thing
with them. Here's a non-regexp version of what I'm describing:
sub a {
my $x = 1;
b();
print "x=$x y=$y\n";
}
sub b {
my $x = 2;
my $y = 3;
return undef but lexicals(x=>$x, y=>$y);
}
This has an unfortunate consequence: The existing lexical C<$x> gets
stomped with the new value of 2. While this might be what you wanted in
some cases, it's probably not a very good idea to allow it in general.
So, lets say that that would generate a warning (error?), and in order
to allow it, you would have to associate a property with your existing
lexical:
my $x is volatile = 1;
I stole this property name from C, where it means that the variable's
value might be stomped by some external side-effect, which is exactly
what it means here. Every subroutine invocation would have to check
return values for a lexicals property and instantiate any variables as
needed. Variables created this way would be considered volatile so that:
b(); b();
Would not generate warnings or errors about stomping the first call's
variables with the second's.
Going back to patterns, this gives us an added bonus. It not only
explains the behavior of hypotheticals, but also of subexpression
placeholders, which are created when the pattern returns:
$self but lexicals(0=>$self, 1=> $self.{1}, 2=> $self.{2}, etc...)
That yields the side effect that you can say:
sub match_digits($string //= $_) {
return / (\d+) /;
}
if match_digits("The time is 12:03") {
print $1;
}
I think this is a very clean and simple way to get everything that
patterns were supposed to do plus a lot of added benefit for things
like:
sub getpwuid(int $uid //= $_) {
%pwd = external("getpwuid",$uid);
return %pwd but lexicals(%pwd);
}
getpwuid($<);
print "I am $user from $dir, and I have a secret ($passwd)\n";
You should be able to "protect" yourself from these side effects. There
are two ways to do that:
{getpwuid($<)}
or
getpwuid($<) but lexicals();
I would expect either one of those to work, though the second is a bit
of magic in terms of order of events.
--
Aaron Sherman <[EMAIL PROTECTED]>
http://www.ajs.com/~ajs
Re: Argument aliasing for subs
>From: Uri Guttman <[EMAIL PROTECTED]> >that is not a variable property so it should be >a compile time error. I was under the impression that compile time properties, like runtime properties, can be arbitrarily invented and/or assigned. If that is correct, why would "my $var is true", meaningless though it is, result in a compile time error? If my perception was incorrect, what was the logic behind the decision that compile time properties must be part of a predefined set, but runtime may be arbitrarily defined? Or is there another explanation that I'm missing? I think my paradigm is shifting without a clutch. Steve _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx
Re: Argument aliasing for subs
Steve Canfield wrote: > I was under the impression that compile time properties, like runtime > properties, can be arbitrarily invented and/or assigned. Yes, but not purely lower-case ones. They're reserved for Perl 6 itself. (i.e. only Larry can invent/assign them ;-) > If that is > correct, why would "my $var is true", meaningless though it is, > result in a compile time error? Because it's lower-case, but not a standard built-in property. > If my perception was incorrect, what > was the logic behind the decision that compile time properties must > be part of a predefined set, There is no such requirement. Indeed, there will almost certainly be possible to define an property yourself (note the capitalization). And it could quite easily cause any value assigned to it to be ascribed C. Damian
Re: Argument aliasing for subs
--
On Sun, 08 Sep 2002 22:24:11
Damian Conway wrote:
>
>Think of it as punctuation. As a necessary alternative to the poor
>overworked colon.
>
Or the poor overworked dot?
>
>
>> it all looks the same to me. And I like different things to look different.
>
>A fair point. My counterargument is that you're looking at the wrong bit.
A fair counterargument (a new programming game -
badmitton!)
At this point I originally had a long reply stating my
feelings. In the course of writing it and trying to
anticiplate Damian's counter counter counter arguments
the reply grew and grew until I realized I had changed
sides. But I'll assemble what thoughts were worth
salvaging into a different post and see where they go,
and get Damian off of the CC list :-).
>Hang in there. If these "mixed number" Cs were allowed then I'd suggest
>the semantics be that they indicate that *either* a scalar or array is
>acceptable in the corresponding argument slot. The scalar variant of the
>parameter would be bound to a scalar argument, or to a reference to an array
>argument. The array variant of the parameter would be bound to an array
>argument, or it's zeroth element bound to a scalar argument.
I think that my problem here lies that I want to treat
a property as either a lvalue or a subroutine call,
and my brain keeps screaming "Watch out for variable
interpolation!". I've been bitten by that enough in my
early module writing days that the fear comes quickly.
What I need (and I hope I'm not alone, or with too
much company) is to know exactly what the is does
here. What kind argument is it taking? Value, name, or
reference? Once I pin that down, the whole thing
should be clear.
>
>
>> -Erik
>>
>>>Damian
>>
>> PS - Ha! My name above Damian's :-)
>
>Letting me get the last word, eh? Very kind of you. ;-)
Touche ('cept with an accent on the e there). Maybe were fencing, not playing
badmitton.
-Erik
>
>Damian
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: More A5/E5 questions
David Helgason wrote: > [worry #1] > The hypothetical 'variables' we bind to aren't really variables but keys to a hash. Welcome to Perl 6. Where *no* variable is really a variable, but all are keys to a hash (which is known as the symbol table) ;-) > Thus they shouldn't have sigils in their names at all. But they do in the Perl 6 symbol table. > Then maybe we could differentiate between building a match object and > capturing data into variables that are defined in a higher scope. > > So > > /^$ / >(or alternately (the binding just changes the name >of the key in the match object)) > /^ myhunk := $ / > > and > > /^ $hunk := $ / This *is* an interesting point. Allison and I have discussed this point at some length and have come up with a rather neat solution that we'll be discussing with Larry ASAP. I'll report back as soon as I can. > [worry #2] > Since $0 has only a rather vague relation to $1..$n, maybe its name isn't that >relevant. > Especially since we'll be indexing into it all the time. Maybe $MATCH, $RESULT, $RX > > (those names aren't convincing me either, sorry). I still think $0 is the right name for it. > If nothing else, this would at least get rid of "one more cryptically named >variable". But only at the expense of adding one more arbitrarily named variable. :-( Damian
Re: More A5/E5 questions
On Sun, Sep 08, 2002 at 09:50:45PM +0200, Damian Conway wrote:
> Nicholas Clark wrote:
>
> > Related, I think: no-one answered my question about what happens when I
> > define
> >
> > sub dumb ($var, @var) {
> > ...
> > }
> >
> > and then call it with the pair var=>$thing
>
> Exception, probably. Perhaps the error would be something like:
>
> "Dumb ambiguous binding of dumb named parameter ("var") at demo.pl line 1. Dummy."
>
> ;-)
What happens if I call a function (maybe not my dumb function above)
with the pair ('$var' => value) - ie the sigil is already in the name of
the pair. Presumably it "just works" for normal function.
So in this case, can I disambiguate things for my dumb function.
And if I call a function
crazy ('$param' => $value, 'param' => $other_value);
presumably that also throws some sort of exception about ambiguity?
Nicholas Clark
Re: More A5/E5 questions
Damian Conway Wrote:
>> [worry #1]
>> The hypothetical 'variables' we bind to aren't really variables
>> but keys to a hash.
>Welcome to Perl 6. Where *no* variable is really a variable, but
> all are keys to a hash (which is known as the symbol table) ;-)
Ok, you're obviously right. But $0{'$foobar'} still hurts my eyes,
not to mention how mysterious it may look to newbies trying to
cope with $h{$foo} and $h{foo} as well - unless we are really good
at educating them (but we will be!).
>> [worry #2]
>> Since $0 has only a rather vague relation to $1..$n, maybe its
>> name isn't that relevant. Especially since we'll be indexing
>> into it all the time. Maybe $MATCH, $RESULT, $RX (those
>> names aren't convincing me either, sorry).
>I still think $0 is the right name for it.
>> If nothing else, this would at least get rid of "one more
>> cryptically named variable".
>But only at the expense of adding one more arbitrarily named variable. :-(
Coming to think of it, why have a named variable at all? If the
match object gets returned anyhow there is no need for a cleverly
named magical variable ($0, $MATCH, ...).
David
--
www.panmedia.dk - Ingenious perl consulting in Denmark, Scandinavia & the World
Re: More A5/E5 questions
David Helgason wrote: > Coming to think of it, why have a named variable at all? If the > match object gets returned anyhow there is no need for a cleverly > named magical variable ($0, $MATCH, ...). Probably for the same reason that we have $1, $2, $_, etc. Because people are lazy. :-) Damian
Re: More A5/E5 questions
On Mon, Sep 09, 2002 at 03:52:30PM +0200, Damian Conway wrote:
> Hi Scott,
>
> You asked (off-list):
Oops, that should've been on-list so that everyone can benefit from my
ignorance :-)
> > Then how do I tell ^^ and $$ to only match just after and just before
> > my platform specific newline sequence? ^^ and $$ seem less useful if
> > I can't do that. (Maybe it's just an erroneous assumption on my part
> > but \n, ^^, and $$ all seem intimately related)
>
> Only in that they use the same set of values when looking for a line
> terminator. You could consider ^^ and $$ to be abbreviations of:
>
> |^>
> |$>
>
> where matches any newline sequence.
>
> So if you wanted a platform-dependent version, you'd write:
>
> rule { }
> rule { }
>
> and use those.
Okay, that makes sense. Or, presumably, I could lexically redefine ^^
and $$ just like I can any other operator.
> > Then, I'll ask again, why are we storing the sigil in the match object
> > for explicit hypotheticals? The difference between
> >
> > $0{file}{hunk}[2] # and
> > $0{file}{'@adonises'}[2]
> >
> > seems unnecessary. Or, how is
> >
> > rule file { ^ @adonises := * $ }
> >
> > different from
> >
> > rule adonises { }
> > rule file { ^ * $ }
> >
> > aside from the extra indirection?
>
> Yes, they're different. Explicitly binding to @adonises binds the (dereferenced)
> reference to the array of C match objects. The implicit binding
> of C<< * >> binds the (un-dereferenced) reference to the array
> of match objects.
>
> That is:
>
> rule file { ^ * $ }
>
> is like:
>
> rule file { ^ $adonises:=* $ }
Aha! Thanks. Can you pop back in time real quick and add these
comments to E5? :)
But it still doesn't make sense to me that we are storing the sigils.
I mean, I thought the whole point of things like:
$aref = @array;
$aref[2] = 5;
was so that we wouldn't have to know or care about the type of thing
we're dealing with and that Perl would just Do The Right Thing. It
seems that by storing the sigils in the match object, we're back to
partitioning rather than unifying.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Throwing lexicals
> Going back to patterns, this gives us an added bonus. It not only
> explains the behavior of hypotheticals, but also of subexpression
> placeholders, which are created when the pattern returns:
>
> $self but lexicals(0=>$self, 1=> $self.{1}, 2=> $self.{2}, etc...)
>
> That yields the side effect that you can say:
>
> sub match_digits($string //= $_) {
> return / (\d+) /;
> }
> if match_digits("The time is 12:03") {
> print $1;
> }
>
> I think this is a very clean and simple way to get everything that
> patterns were supposed to do plus a lot of added benefit for things
> like:
>
> sub getpwuid(int $uid //= $_) {
> %pwd = external("getpwuid",$uid);
> return %pwd but lexicals(%pwd);
> }
> getpwuid($<);
> print "I am $user from $dir, and I have a secret ($passwd)\n";
>
> You should be able to "protect" yourself from these side effects. There
> are two ways to do that:
>
> {getpwuid($<)}
>
> or
>
> getpwuid($<) but lexicals();
>
> I would expect either one of those to work, though the second is a bit
> of magic in terms of order of events.
This does bring up an interesting point. I think your solution is an
interesting idea, but not really necessary. But consider this:
my $date;
# lots of code
sub foo {
#lots more code
sub bar {
#lots more code
m/ $date := /;
}
}
This is terrible. Calling foo which calls bar mysteriously overwrites
$date? "Why is $date changing?" the programmer asks. He does an
exhaustive search through his code and finally says "ohh," and has to
change all references to the inner $date to something like $mydate.
This is obviously a problem (unless I misunderstood how hypotheticals
change their surrounding scope). For a solution, let's just look how we
do it in subroutines.
my $date;
sub foo {
my $date = 'Jul 17, 1984';
# ...
}
Oh. Duh. Why don't we have such a mechanism for matches?
m/ my $date := /
is ambiguous to the eyes. But I think it's necessary to have a lexical
scoping mechanism for matches, as to avoid the problem I addressed above.
Any ideas?
Luke
Re: Throwing lexicals
I may be missing your point, but based on my somewhat
fuzzy understanding:
> Oh. Duh. Why don't we have such a mechanism for matches?
>
> m/ my $date := /
>
> is ambiguous to the eyes. But I think it's necessary to have a
lexical
> scoping mechanism for matches
The above would at least have to be:
m/ { my $date := } /
(otherwise the 'my ' and ':=' would be matched literally.)
And you can of course do that.
But you won't be able to access $date outside the closure.
Hence the introduction of let:
m/ { let $date := } /
which makes (a symbol table like entry for) $date available
somewhere via the match object.
And has the additional effect that $date (I think the whole
variable/entry, but at the very least its value) disappears
if the match backtracks over the closure.
Right?
--
ralph
Re: Suggestion for perl 6 regex syntax
[Moved over from p6i, to more appropriate p6l]
On Sat, 2002-09-07 at 12:03, Mr. Nobody wrote:
> 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+))?$/
Longer != worse. Your example is not the norm, but the exception
(lookahead assertions are certainly not in most Perl 5 regular
expressions). A5 tried to stress the value of shortening those things
that were used most often. At a bare minimum, having gone from
C<(?:xxx)> to C<[xxx]> saves me about 2-4 characters in my AVERAGE
regexp.
Also, that's
m:i/^ (\+|-)? (\d* [\. \d*]? \d) (e [\+|-]? \d+)? $/
For what it's worth. This is not the same as your expression, but I'm
assuming that you meant to capture groups that would make sense for
later use (instead of capturing only part of the number). Otherwise,
it's the same.
One of the nice things that falls out of the Perl 6 patterns is that
it's reasonable for every module to provide an export target that
exports some of it's more commonly used rules. So you might say:
use Math::IEEE :rules;
while <> {
if / () / {
print "Floater: $1\n";
}
}
Which is certainly a lot cleaner than a big hairy pattern hanging in the
middle of your code
--
Aaron Sherman <[EMAIL PROTECTED]>
http://www.ajs.com/~ajs
Re: Throwing lexicals
On Mon, Sep 09, 2002 at 02:14:25PM -0500, Me wrote:
> Hence the introduction of let:
>
> m/ { let $date := } /
>
> which makes (a symbol table like entry for) $date available
> somewhere via the match object.
Somewhere? where it appears in in the namespace of the caller.
Apparently there is no way to use someone else's grammar and prevent it
trashing your namespace.
> And has the additional effect that $date (I think the whole
> variable/entry, but at the very least its value) disappears
> if the match backtracks over the closure.
>
> Right?
As I understand it that is the intent.
Perhaps what we need is something like @EXPORT and @EXPORT_OK for
hypotheticals in grammars. I'm not suggesting those as names, but
something along those lines. It would give the caller some degree of
protection if they had to specifically ask you to overwrite their
variables with hypothetically bound results.
I think if we don't do something like that it's going to make other
peoples grammars very hard to use. You will have to read them and know
which variables they will mess with before you start.
andrew
--
Scorpio: (Oct. 24 - Nov. 21)
It's been almost three decades, but you think you're finally beginning to
recover from the long, national nightmare of Vietnam movies.
Re: Throwing lexicals
On Mon, 9 Sep 2002, Andrew Wilson wrote:
> On Mon, Sep 09, 2002 at 02:14:25PM -0500, Me wrote:
> > Hence the introduction of let:
> >
> > m/ { let $date := } /
> >
> > which makes (a symbol table like entry for) $date available
> > somewhere via the match object.
>
> Somewhere? where it appears in in the namespace of the caller.
> Apparently there is no way to use someone else's grammar and prevent it
> trashing your namespace.
Err.. I don't think so.
# Date.pm
grammar Date;
my $date;
rule date_rule { $date := }
# uses_date.p6 (hmm.. I wonder what a nice extension would be...)
use Date;
my $date;
m/ /;
This would mess with $Date::date, not $main::date. If there was no
$Date::date, it wouldn't mess with anything, and it would store
the return value of in $0{date}.
I'm talking about just in the same namespace, how do we keep rules from
messing with file-scoped (or any-scoped, for that matter) lexicals or
globals. How do we get rule- or closure-scoped lexicals that are put into
$0?
Which of these are legal, and would provide a solution?
/ { let my $date = $something } /
/ { $0{date} = $something } /
If either, I guess I have no complaints. I'll be angry if the latter
isn't legal. Still, they seem a little bit hack-like
Luke
Re: Throwing lexicals
On Mon, Sep 09, 2002 at 02:13:55PM -0600, Luke Palmer wrote:
> Err.. I don't think so.
>
> # Date.pm
> grammar Date;
> my $date;
> rule date_rule { $date := }
>
> # uses_date.p6 (hmm.. I wonder what a nice extension would be...)
> use Date;
> my $date;
> m/ /;
>
> This would mess with $Date::date, not $main::date. If there was no
> $Date::date, it wouldn't mess with anything, and it would store
> the return value of in $0{date}.
Ok, That makes a great deal more sense. I was confused by the
discussion of dynamic scope.
andrew
--
Cancer: (June 22 - July 22)
You will soon find yourself entangled in a messy accident with a knife thrower,
although drunk driving, not knife throwing, is actually the real issue.
Re: Throwing lexicals
On Mon, 2002-09-09 at 15:12, Luke Palmer wrote:
> > Going back to patterns, this gives us an added bonus. It not only
> > explains the behavior of hypotheticals, but also of subexpression
> > placeholders, which are created when the pattern returns:
[...]
> > I think this is a very clean and simple way to get everything that
> > patterns were supposed to do plus a lot of added benefit for things
> > like:
> This does bring up an interesting point. I think your solution is an
> interesting idea, but not really necessary. But consider this:
Before we consider your concern (which I will address below), why is
this "not really necessary"? As I see it, here are the needs addressed:
1. Creating lexically scoped variables in caller's namespace
2. Protecting existing lexicals from unexpected side-effects.
One of those is mandated by A5, and one of those is, IMHO, requisite for
maintainable programming.
We also achieve the following:
1. Limiting TCL-upvar-like manipulation of caller's stack
2. Allowing "pass-through" subroutines
This last bit is kind of crucial, IMHO. It makes a lot of sense to me
that this would work:
sub match_digits($str //= $_) { /(\d+)/ }
if match_digits { print $1 }
And if C<$0> contains a property that causes the lexicals to be created
upon return, then it would (because match_digits just returns C<$0> to
the caller).
> my $date;
> # lots of code
> sub foo {
> #lots more code
> sub bar {
> #lots more code
> m/ $date := /;
> }
> }
If you used my suggestion, this would produce a warning or error
depending on strictness. That would have to be "my volatile $date" to
allow a thrown lexical to stomp it, in which case
> Oh. Duh. Why don't we have such a mechanism for matches?
My question exactly.
There is more that you can do once you can throw lexicals. For example,
you could provide a property for subroutines and rules which asserts the
lexicals which it can throw:
rule date is declaring($date) { # or is that declaring('date')?
$date := ()
}
# or
sub stat($filename//=$_) is declaring($mtime, $ctime, ...) {
# ...
return %statstruct but lexicals(%statstruct);
}
Now, the compiler can generate stomping warnings at compile-time instead
of just at run time.
--
Aaron Sherman <[EMAIL PROTECTED]>
http://www.ajs.com/~ajs
Re: Suggestion for perl 6 regex syntax
On Mon, 2002-09-09 at 06:05, David Helgason wrote: > > Yeay! Golf... > If we are allowed to use all of perl6 in this particular (golf-)course, > I suggest: Clearly I've missed a reference at some point. Presumably "golf" is used here to mean something like "stupid question". > Perl6 will be a *great* language. Cheer-leading and put-downs are probably not the best response to user questions, even those which are flawed. -- Aaron Sherman <[EMAIL PROTECTED]> http://www.ajs.com/~ajs
Re: Suggestion for perl 6 regex syntax
On Mon, Sep 09, 2002 at 05:02:18PM -0400, Aaron Sherman wrote: > On Mon, 2002-09-09 at 06:05, David Helgason wrote: > > > > Yeay! Golf... > > > If we are allowed to use all of perl6 in this particular (golf-)course, > > I suggest: > > Clearly I've missed a reference at some point. Presumably "golf" is used > here to mean something like "stupid question". No, it's not. "Golfing" is a programming game in which you try to write the smallest program possible to accomplish a task - the relation to regular golf being that a lower "score" is better. No-one was calling your question stupid; rather, they were simply drawing a connection between smaller regexes and better golf scores. The praise for Perl6's golfworthiness was quite sincere, not sarcastic. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754 -- Those who can, do; those who can't, simulate.
Re: Second try: Builtins
On Sat, 2002-09-07 at 14:22, Smylers wrote:
> Aaron Sherman wrote:
> > sub chomp($string is rw){
[...]
> > } elsif $irs.length == 0 {
> > $string =~ s/ \n+ $ //;
>
> Should that C<+> be there? I would expect chomp only to remove a single
> line-break.
Note that this is in paragraph (e.g. C<$/=''>) mode
> > 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?
Yes, but that would be:
sub reverse($string) {
return join '', reverse([split //, $string]);
}
Though this example is too inefficient, it does demonstrate the point.
--
Aaron Sherman <[EMAIL PROTECTED]>
http://www.ajs.com/~ajs
Re: Suggestion for perl 6 regex syntax
> "AS" == Aaron Sherman <[EMAIL PROTECTED]> writes: AS> On Mon, 2002-09-09 at 06:05, David Helgason wrote: >> >> Yeay! Golf... >> If we are allowed to use all of perl6 in this particular (golf-)course, >> I suggest: AS> Clearly I've missed a reference at some point. Presumably "golf" AS> is used here to mean something like "stupid question". you presume wrong. search for perl golf on google. also there is a perl golf list and plenty of it on fwp and other places AS> Cheer-leading and put-downs are probably not the best response to user AS> questions, even those which are flawed. golf is not a putdown. 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: Second try: Builtins
On Sat, 2002-09-07 at 10:53, Sean O'Rourke wrote: > On Sat, 7 Sep 2002, Chuck Kulchar wrote: > > Also, how do these perl6 builtins in perl6 work with the current > > P6C/Builtins.pm? (also, why are some that are already defined in pure > > pasm/part of the parrot core redefined as perl6 code?) > > For the moment, "they don't". Eventually, I expect there will be some > sort of a "header file" with the builtin declarations (P6C parses and > interprets function declarations for this very reason), and a .pbc file > containing their code. As for why they're written in perl 6 code, I > expect it's easier to define their semantics in Perl than in assembly. Correct in as far as it goes. The more general answer is that one of the goals of this re-write (as I was lead to believe) was that the Perl internals would be maintainable. If we write the well over 150 Perl 5 builtins in Parrot assembly, I think we can kiss that wish goodbye. Some of this will have to be done in assembly, but hopefully a very small and modular core (e.g. my proposal earlier on how to handle pack, sprintf and chr). The rest will be the subject of increasingly powerful optimizations that the compiler will have to perform for user code anyway. Ultimately I would hope that the only builtins that will be represented 100% in assembly will be those that have a 1-to-1 mapping in the parrot instruction set (e.g. scalar). BTW: Current status is that I'm preparing to make some changes to the compiler tonight. After that, I'll be ready to issue a patch against the current tree. Over the weekend I focused on getting all of the builtins to compile cleanly and I implemented a few other small pieces. We now have a sprintf that can handle C<'%d'> and C<'%s'> along with some simple modifiers, so C should work. I'm making heavy use of C, in the assumption that it will make the code easy to optimize. -- Aaron Sherman <[EMAIL PROTECTED]> http://www.ajs.com/~ajs
Re: Second try: Builtins
On Mon, Sep 09, 2002 at 05:36:42PM -0400, Aaron Sherman wrote: > Correct in as far as it goes. The more general answer is that one of the > goals of this re-write (as I was lead to believe) was that the Perl > internals would be maintainable. If we write the well over 150 Perl 5 > builtins in Parrot assembly, I think we can kiss that wish goodbye. This may sound a bit arm wavy, but when I'm off messing up the core of perl5, I don't find the perl5 ops are the maintenance problem. Most of the op functions are quite small (partly due to the use of macros) but they are all nicely self contained. (And all in 6 (4 before 5.8) source files, out of a total of 36 source files) The writhing mass of yuck comes from the interaction of the bits in the various utility functions that they call in the other 26 or so files. Plus the 2 files of the regexp engine, and the 2 files of the parser which I attempt to avoid lest I go insane. Hence I don't think that writing the perl builtins in parrot assembly (or at least the majority that really need to go really fast) would be a maintenance nightmare. Although being able to write them in perl and having an inliner and optimiser that is good enough to produce results better than calling out to general purpose parrot assembler would be nice. Although my biased opinion is that probably best to write the perl builtins as tidy C code rather than parrot assembler. But I know C better. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
Re: Second try: Builtins
On Mon, 2002-09-09 at 17:52, Nicholas Clark wrote: > On Mon, Sep 09, 2002 at 05:36:42PM -0400, Aaron Sherman wrote: > > Correct in as far as it goes. The more general answer is that one of the > > goals of this re-write (as I was lead to believe) was that the Perl > > internals would be maintainable. If we write the well over 150 Perl 5 > > builtins in Parrot assembly, I think we can kiss that wish goodbye. > > This may sound a bit arm wavy, but when I'm off messing up the core of > perl5, I don't find the perl5 ops are the maintenance problem. > Most of the op functions are quite small (partly due to the use of macros) > but they are all nicely self contained. (And all in 6 (4 before 5.8) source > files, out of a total of 36 source files) Keep in mind that the majority of Perl 5 builtins are of the form: munge parameters... call libc function of same name... munge return values In Perl 6 those will mostly be the same. Many of them will be moved out to modules (e.g. the filehandle functions) but many others will remain in the core (e.g. chdir, getppid, etc) and simply be wrappers around the C functions. When the general-purpose interface for C is defined, these functions will be implemented in a fairly short period of time. Those that are left are internal Perl utilities that I break down into several categories: string, math, list, internal and misc. Of these, about 30-50% will probably be pure Perl. Another small percentage will be assembly wrappers that call a one-for-one parrot function (e.g. exit). The rest will be a complex mix of Perl and assembly (e.g. sprintf which is mostly Perl, but needs assembly for low-level type conversion). > Although my biased opinion is that probably best to write the perl builtins > as tidy C code rather than parrot assembler. But I know C better. Yeah, that would be ideal for speed. I am willing to concede that that's the way we'll have to go for some things, eventually. However, until we have a pure Perl library (or as much so as we can), I don't think we'll know where we need the speed boost most. What's more, this will force the compiler to optimize as strongly as possible, which can only benefit users. -- Aaron Sherman <[EMAIL PROTECTED]> http://www.ajs.com/~ajs
Re: Second try: Builtins
Aaron Sherman wrote:
> Of these, about 30-50% will probably be pure Perl. Another small
> percentage will be assembly wrappers that call a one-for-one parrot
> function (e.g. exit). The rest will be a complex mix of Perl and
> assembly (e.g. sprintf which is mostly Perl, but needs assembly for
> low-level type conversion).
I'm just providing the necessary infrastructure inside imcc. The format
of current Builtin's will probably slightly change. I need the global
label (i.e. entry point) of the function for bsr fixup.
Sean did propose:
.extern sub_name _label
Plus something like (mine):
.sub sub_name {
saveall
.param PerlUndef Arg1
...
}
for PIR subs.
(Current imcc parses »ret« as end of sub, which we might change)
There is no real need to use PASM at all in the function, but imcc
(0.0.9) parses PASM instructions too.
BTW: are there any thoughts about "PackFile_FixupTable"?
leo
