Grant M. [EMAIL PROTECTED] writes:
I am reading various discussions regarding threads, shared objects,
transaction rollbacks, etc., and was wondering if anyone here had any
thoughts on instituting an event model for Perl6? I can see an event model
allowing for some interesting solutions to some
Ken Fox [EMAIL PROTECTED] writes:
Short
circuiting should not be customizable by each type for example.
We are already having that argument^Wdiscussion elsewhere ;-)
But I agree variable vtables are not the place for that.
--
Nick Ing-Simmons
Dear All
I wrote a large C++ program which used embedded Perl. Later, this was changed to
embedded Python. The reasons for this included:
1) Python allows you to pass a pointer to an object from C/C++ to the embedded Python
interpreter, wheras Perl makes you push and pop off the stack (as far
RFC 178 proposes a shared data model for Perl6 threads. In a shared
data model
- globals are shared unless localized
- file-scoped lexicals are shared unless the thread recompiles the
file
- block scoped lexicals may be shared by
- passing a reference to them
- closures
- declaring one
"SWM" == Steven W McDougall [EMAIL PROTECTED] writes:
SWM If you actually compile a Perl program, like
SWM$a = $b
SWM and then look at the op tree, you won't find the symbol "$b", or "b"
SWM anywhere in it. The fetch() op does not have the name of the variable
SWM $b; rather, it
SWM If you actually compile a Perl program, like
SWM $a = $b
SWM and then look at the op tree, you won't find the symbol "$b", or "b"
SWM anywhere in it. The fetch() op does not have the name of the variable
SWM $b; rather, it holds a pointer to the value for $b.
Where did you
