Jonathan Scott Duff wrote:
- for minimal matching the ? is too far away from the operator that it
applies to. It looks like it's doing something to the closure (and
maybe it is) Should that be [foo]**?{$m..$n} instead?
- Bringing a closure into the picture seems to put too much power in
such
Jonathan Scott Duff wrote:
I think you meant something akin to C< /(.) { use PIR; print P0;}/ > and
C< /(.) { use Forth; P0 print}/ > :-) As long as we're special-casing
things and "hand parsing" we might as well use a small subset of Perl)
Is perl actually going to allow arbitrary languages in t
* Nicholas Clark <[EMAIL PROTECTED]> [2004-09-08 17:37:52 +0100]:
> The probing is going to *have* to get written in something that compiles
> down to parrot bytecode to work on the autoconf-deprived systems, so with
> that as a given there's no need for autoconf ahead of that.
How feasable would
On Fri, Sep 17, 2004 at 08:19:37AM -0600, Patrick R. Michaud wrote:
: I'm going to go with a syntactic shortcut for the time being, albeit
: something more complex than the suggestion above. I don't want to force
: people to make multi-line closures. It will probably look for matching
: braces, s
On Sat, Sep 18, 2004 at 08:36:06AM -0700, Larry Wall wrote:
: I think in the long run we'll have those inner compilers that know how to
: stop themselves and can be handed a closure, and those that don't know how
: to stop, and must be spoonfed the right amount, which is almost always
: an even num
On Sat, Sep 18, 2004 at 12:29:52AM -0500, Dan Hursh wrote:
> Jonathan Scott Duff wrote:
> >I think you meant something akin to C< /(.) { use PIR; print P0;}/ > and
> >C< /(.) { use Forth; P0 print}/ > :-) As long as we're special-casing
> >things and "hand parsing" we might as well use a small su
Please forgive me if these ideas have been discussed before. I don't
remember having read them elsewhere.
For specifying in-rule repetitions, why not use the rule modifer we
already have for specifying whole-rule repetitions; namely, C<:x>. Allow
:x inside rules like :i and :w, and we get somethin
Dan Hursh writes:
> Second, if it is a problem that '?' is too far away, how about this?
>
> [foo]**{5..3} # greedy
> [foo]**{3..5} # lazy
Because 5..3 is the empty list. This wasn't a mistake in Perl 5, so
it's staying in Perl 6.
> Oh, is there a way to trick this closure syntax into being
Kurt Hutchinson writes:
> For specifying in-rule repetitions, why not use the rule modifer we
> already have for specifying whole-rule repetitions; namely, C<:x>. Allow
> :x inside rules like :i and :w, and we get something like this:
> rx :w/ three m's\: [:3xm] /
> rx :w/ t
On Sep 18, 2004, at 2:09 AM, [EMAIL PROTECTED] wrote:
* Nicholas Clark <[EMAIL PROTECTED]> [2004-09-08 17:37:52 +0100]:
The probing is going to *have* to get written in something that
compiles
down to parrot bytecode to work on the autoconf-deprived systems, so
with
that as a given there's no nee
Hi Paul et al.,
In an iterator class I've written, I have this method:
sub do {
my ($self, $code) = @_;
while (local $_ = $self->next) {
return unless $code->($_);
}
}
I've written tests for when the code reference returns true and when it
returns false. However, Devel::Cover
On Sat, Sep 18, 2004 at 12:27:36PM -0700, Jeff Clites wrote:
: Ha, I'm sure it could probably be done, but of course "most" of what
: the shell does it invoke other programs, so in the common case it still
: wouldn't give you portability to non-Unix-like platforms.
Just translate it to a languag
At 11:36 AM -0500 9/18/04, Jonathan Scott Duff wrote:
I'm by no means an expert, but I'd say that the inner languages don't
need to have any idea of closure or of curly braces; those are Perl's
responsibility.
Rather it's the rules parser's responsibility. Don't forget, more
languages than just pe
On Sat, Sep 18, 2004 at 03:00:09PM -0400, Kurt Hutchinson wrote:
> Repitition is a kind of assertion, after all, and it seems like it
> should get to play in the same angle-bracket sandbox as the other
> assertions.
Once I got to thinking about **{}, the less and less it looked like an
assertion t
On Sat, Sep 18, 2004 at 03:41:37PM -0400, Dan Sugalski wrote:
> At 11:36 AM -0500 9/18/04, Jonathan Scott Duff wrote:
> >I'm by no means an expert, but I'd say that the inner languages don't
> >need to have any idea of closure or of curly braces; those are Perl's
> >responsibility.
>
> Rather it's
On Fri, 17 Sep 2004 21:24:35 -0700, Steve Fink <[EMAIL PROTECTED]> wrote:
> On Sep-17, Matt Diephouse wrote:
> > o Calling subroutines from an eval creates a copy of the user stack,
> > so all changes are lost (rendering my Forth code unusable). Is this
> > behavior correct? If so, how should I go
At 3:32 PM -0500 9/18/04, Jonathan Scott Duff wrote:
On Sat, Sep 18, 2004 at 03:41:37PM -0400, Dan Sugalski wrote:
At 11:36 AM -0500 9/18/04, Jonathan Scott Duff wrote:
>I'm by no means an expert, but I'd say that the inner languages don't
>need to have any idea of closure or of curly braces; th
At 4:57 PM -0400 9/18/04, Matt Diephouse wrote:
On Fri, 17 Sep 2004 21:24:35 -0700, Steve Fink <[EMAIL PROTECTED]> wrote:
On Sep-17, Matt Diephouse wrote:
> o Calling subroutines from an eval creates a copy of the user stack,
> so all changes are lost (rendering my Forth code unusable). Is this
Rod Adams <[EMAIL PROTECTED]> writes:
> One solution I see to this would be to have a "lazy return" of some
> kind, where you can send out what results you have so far, but not
> commit that your execution is over and still allow further results to
> be posted. For lack of better word coming to mi
Jonadab the Unsightly One writes:
> Rod Adams <[EMAIL PROTECTED]> writes:
>
> > One solution I see to this would be to have a "lazy return" of some
> > kind, where you can send out what results you have so far, but not
> > commit that your execution is over and still allow further results to
> > b
Luke Palmer wrote:
Jonadab the Unsightly One writes:
Rod Adams <[EMAIL PROTECTED]> writes:
One solution I see to this would be to have a "lazy return" of some
kind, where you can send out what results you have so far, but not
commit that your execution is over and still allow further result
Juerd <[EMAIL PROTECTED]> writes:
> Jonadab the Unsightly One skribis 2004-09-17 10:46 (-0400):
>> * They are of critical importance on Apache-based webservers.
>
> They are not. See mod_mime_magic.
Magic, as far as I know, only works for filetypes that have known byte
sequences.
>> * They ins
James Mastros <[EMAIL PROTECTED]> writes:
>As a special case, if the "filename" argument to perl is a
>directory, and the directory contains a file named "main.pl",
>then the directory is prepended to @*INC, and main.pl is run.
I think it would be useful if the "directory" could also
Rod Adams writes:
> Better documentation on gather/take is merited.
Without a doubt.
> I would question the need for C, however. Could not a lone
> C/C force the return value of the enclosing routine/closure
> to be a lazy list, and here's a few values to get things started?
C is necessary. C
# New Ticket Created by Will Coleda
# Please include the string: [perl #31631]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31631 >
# New Ticket Created by Will Coleda
# Please include the string: [perl #31632]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31632 >
# New Ticket Created by Will Coleda
# Please include the string: [perl #31633]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31633 >
That is:
Contrive things so that no code whatsover must be maintained outside of the
27 matches
Mail list logo
