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
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
