Luke Palmer wrote:
I think it would fall trivially out of the events mechanism, which is
planned for Parrot.
I have heard rumours of such a thing, but no details of how it will be
exposed in the language...
Dave.
> "Piers Cawley" <[EMAIL PROTECTED]> wrote
> > Threads and Progress Monitors
> > Dave Whipp had some more thread questions, and wondered what would be
> a
> > good Perl 6ish way of implementing a threaded progress monitor. Whilst
> > the discussion of all this was interesting, I'm not
"Piers Cawley" <[EMAIL PROTECTED]> wrote
> Threads and Progress Monitors
> Dave Whipp had some more thread questions, and wondered what would be
a
> good Perl 6ish way of implementing a threaded progress monitor. Whilst
> the discussion of all this was interesting, I'm not sure that i
On Mon, 2 Jun 2003, Benjamin Goldberg wrote:
> All values needing timely destruction would inherit from a class
> RefCounted.
I like this concept a lot, but maybe we can take it a little further and
make it transparent to the programmer. Suppose that the internals only
tracked objects that have
Piers Cawley wrote:
>
> The Perl 6 Summary for the week ending 20030601
> Another Monday, another Perl 6 Summary. Does this man never take a
> holiday? (Yes, but only to go to Perl conferences this year, how did
> that happen?)
>
> We start with the internals list as usual.
>
>
> A better fitting solution wouldn't focus on classic
> MMD, but simply "Dispatch", where type- and value-based
> dispatching are two of many kinds of dispatching supported.
I've always liked the sound of Linda's tuple spaces
and view that as a nice generalized dispatch approach.
Procedure calls
> A better fitting solution wouldn't focus on classic
> MMD, but simply "Dispatch", where type- and value-based
> dispatching are two of many kinds of dispatching supported.
I've always liked the sound of Linda's tuple spaces
and view that as a nice generalized dispatch approach.
Procedure calls
The Perl 6 Summary for the week ending 20030601
Another Monday, another Perl 6 Summary. Does this man never take a
holiday? (Yes, but only to go to Perl conferences this year, how did
that happen?)
We start with the internals list as usual.
More on timely destruction
The dis
On Mon, Jun 02, 2003 at 10:34:14AM -0600, Luke Palmer wrote:
> And I don't see what's stopping someone from writing Dispatch::Value.
>
> use Dispatch::Value;
> sub foo($param is value('param1')) {...}
> sub foo($param is value('param2')) {...}
>
> What it seems you're wanting is it to
Michael Lazzaro <[EMAIL PROTECTED]> writes:
> On Monday, May 26, 2003, at 06:10 PM, Dave Whipp wrote:
>> So, in summary, its good to have a clean abstraction for all the
>> HCCCT things. But I think it is a mistake to push them too
>> close. Each of the HCCCT things might be implemented as facades
On Mon, Jun 02, 2003 at 10:34:14AM -0600, Luke Palmer wrote:
> What it seems you're wanting is it to be in the core. And I'm saying
> that's irrelavent. There are thousands of great ideas out there, and
> they can't all fit into Perl's core. That's why there's thousands of
> modules on CPAN.
H
Adam Turoff writes:
> On Sun, Jun 01, 2003 at 10:44:02PM -0600, Luke Palmer wrote:
> > It will still have a lot of power in text processing, and still be a
> > powerful "quicky" language, but that's no longer its primary focus --
> > not to say that highly structured programming is. Some applicati
12 matches
Mail list logo
