On Sun, Aug 06, 2000 at 10:10:39PM -0400, Uri Guttman wrote:
> >>>>> "JT" == John Tobey <[EMAIL PROTECTED]> writes:
> JT> For consistency with Perl's use of callbacks for other purposes, the
> JT> method names should be all caps.
>
> having the default callback names in caps is a good idea. but you can
> always override them with any others including lower case names.
Override a method with one with a different name? This makes no
sense. Anything that Perl calls (i.e., the method name is special to
Perl), should be all caps. Of course, your packages may define other
methods, too.
> >> I propose that Perl6 threads be in the core (not a compile time option)
> >> and with a proper design and implementation will be effective and
> >> efficient.
>
> JT> Huh?! You mean, allocate mutexes and lock and unlock everything when
> JT> you know you don't want threads? Making threads the default
> JT> configuration is probably what we want instead.
>
> that is not what i meant (i think). what i seem to be trying t say is
> that only one binary of perl gets built. threads are enabled by some
> pragma which will include any thread support from a precompiled
> dynlib. the pragma also enables shared vars to be used and that will
> affect the compilation of that perl code. whereas i don't think there
> should be any impact on a single default perl thread as it won't share
> anything.
Hmm, it sounds sweet if it can actually work. Default Perl will
already be running by the time it gets to the pragma. Don't you need
a command-line switch to select thread support? Is this being
discussed elsewhere?
> JT> Oh, I guess this partly answers my last question. You mean ithreads.
> JT> I think we may see non-i-threads, too, in a bit nicer form than 5.005
> JT> had.
>
> please explain i-threads.
In i-threads, data is unshared and invisible to other threads except
through special interfaces. I.e., each thread runs its own
interpreter (the `i') with its own symbol table. Const stuff like ops
can be shared to reduce memory footprint. i-threads have the flavor
of separate processes and (I think - they're not really supported yet,
though) fewer problems than raw, native, system threads.
> >> =head2 Continuations
>
> i don't know what continuations are. they sounded flow controlish so i
> just put in a slot for them here. if they don't belong, out they
> go.
Oh, well I'm not sure, maybe they do belong. A continuation is
(abstractly) a copy of the stack. It's the reverse of eval (or, in C,
setjmp) in that it lets you back out of a stack frame and later come
back to continue it, possibly many times.
-John
