Adam Kennedy writes:
> perl itself would also appear unable to understand perl source,
> instead doing what I would call RIBRIB parsing, "Read a bit, run a
> bit".
RIBRIB? RABRAB, surely!
Smylers
Luke has answered this better than I would have. In particular, he wrote:
> Perl's contextual sensitivity is part of the language. So the best you
> can do is to track everything like you mentioned. It's going to be
> impossible to parse Perl without having perl around to do it for you.
That firs
Adam Kennedy writes:
> Getting (finally) to perl6, I could have sworn I saw an RFC early on
> which said "Make perl6 easier to parse".
>
> But it would appear the opposite is occurring. Source filters have
> become grammars and will now be officially approved and acceptable
> (yes?) while so far
> gather @bin1, @bin2 -> $bin1, $bin2{
> for @words {
> $bin1.take if /^^a/;
> $bin2.take if /e$$/;
> }
> }
Juerd point out (private email) that my example doesn't really make any
sense in that it doesn't do anything over and above s/take/push.
However, I think the concept of multiple
Hi folks
I thought it was about time I brought some concerns I've been having
lately to the list. Not so much on any particular problem with perl6,
but on problems with perl5 we would seem to have the opportunity to fix
but aren't. (So far as I can tell).
One of the biggest problems I have had
I was wondering just how much once can do with gather/take: is it possible
to have multiple bins?
@words = << abc def ade afe ade agc >>;
gather @bin1, @bin2 -> $bin1, $bin2{
for @words {
$bin1.take if /^^a/;
$bin2.take if /e$$/;
}
}
?
David Ross skribis 2004-11-24 12:00 (-0500):
> I have been studying PERL 5 core and modules to identify options and
> issues for meta-architectures and automated code generation. PERL 6
> documents and discussion provide insight essential to effectively using
> PERL 5 and preparing for PERL 6.
If
David Ross writes:
> How much of the overhead for method dispatch/return is or can be
> incurred at compile time? If call and return signatures are defined at
> compile time is it possible to eliminate switch code and/or jump
> tables as an optimumization?
We hope so, in the absence of a pragma te
On Wed, 2004-11-24 at 01:10, Larry Wall wrote:
> On the other hand, in a language like Perl, it's easy to come up
> with contexts that don't specify the type context as well as the user
> might expect. Plus asking for your return context is not necessarily
> going to be terribly efficient anyway