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
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 := hunk* $ }
If I didn't have the
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
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
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 Cis syntax is (like methods in
OO Perl), it associates a meaningful *name* with each
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
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, meaningless
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
--
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
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
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
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
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
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
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
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 := 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
[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 := 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 := date } /
which makes (a symbol table like entry for) $date available
somewhere via the match object.
Somewhere? where it appears in
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 := something }
# uses_date.p6 (hmm.. I wonder what a nice extension would be...)
use Date;
my
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
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
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
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
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
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
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
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
29 matches
Mail list logo
