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
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
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
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
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
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
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
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
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
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
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
11 matches
Mail list logo
