Copied from p5p as it seemed kinda relevant.
Dan Sugalski wrote:
> >Roll on perl6...
>
> Well, besides "Just don't *do* that," any thoughts on how to handle this
> properly in p6?
Hmm. I've been half-following the async IO and signals thread in
perl6-internals. The first thing I would say is
> Respectfully, as with the other
> issues, let's please give Larry his time at bat with the RFC as it stands
> rather than second guessing ourselves again redundantly after the fact.
very good, here's your lollipop ;)
> "RC" == Rocco Caputo <[EMAIL PROTECTED]> writes:
RC> Re: Writing the subsystems together.
RC> I think you misunderstand the other message's intent. The main loop,
RC> the interpreter, and I/O, are three separate subsystems. I think
RC> everyone agrees with you that they should b
Rocco Caputo wrote:
> Re: Writing the subsystems together.
>
> I think you misunderstand the other message's intent. The main loop,
> the interpreter, and I/O, are three separate subsystems. I think
> everyone agrees with you that they should be interchangeable, but
> their public interfaces are
On Mon, 8 Jan 2001 23:12:15 -0200, Filipe Brandenburger wrote:
>Rocco Caputo wrote:
>
>> ...
>> [ *** code *** ]
>>
>>This could very well be an event driven program, with all the tedious
>>mucking about with callbacks done under the hood. Regardless, it could
>>run the same as long as either th
Nicholas Clark wrote:
>Branden wrote:
>> That's actually something I'd like to say about this ``subsystem''-based
>> design of perl6. For it to be successful, it's imperative that all the
>> modules
>> don't know about each other, so that it's possible to replace a subsystem
>> c
On Mon, Jan 08, 2001 at 11:12:15PM -0200, Filipe Brandenburger wrote:
> Rocco Caputo wrote:
>
> > ...
> > [ *** code *** ]
> >
> >This could very well be an event driven program, with all the tedious
> >mucking about with callbacks done under the hood. Regardless, it could
> >run the same as lon
On Mon, Jan 08, 2001 at 11:12:15PM -0200, Filipe Brandenburger wrote:
> In the other way around, what matters to the design of the file i/o
> subsystem is exactly the same thing: whether it will or won't be using
> blocking syscalls. I believe after the decision of whether we will or not
> allow b
On Sun, Jan 07, 2001 at 08:27:21PM -0600, Jarkko Hietaniemi wrote:
> Could you explain why do you think going more GPL would be a good thing
> for Perl?
I do not think that Bradley is suggesting that Perl would "go more GPL",
because that would be indefensibly insane. Bradley is proposing that