# 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
# 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 #31631]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31631 >
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
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
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
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
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 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
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 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
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 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
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
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
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 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
* 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
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
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
27 matches
Mail list logo
