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
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 hypoth
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
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 me
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 e
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
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:
>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", meaningle
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,
--
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 counterargume
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 thei
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, prob
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
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. :-)
Damia
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 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
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 hav
[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
>
> /^([+-]?
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
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
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
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 simp
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
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 "
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
> "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
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?)
>
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 Parr
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 maintainab
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
>
30 matches
Mail list logo
