HaloO,
Daniel Ruoso wrote:
So the questions are:
* Are there any imperative barriers in Perl 6?
I would think that at least every method call is a barrier.
An object's lifetime is a sequence of states and methods are either
returning information about the state or calculate a new state. The
latter cannot be concurrent. Furthermore it is usually a bad idea
to have an object in several concurrent computations such that
streams of mutating method calls interleave. So objects destined
for parallel computing need some explicit locking mechanism.
* Does that mean we need to spec a common way of implementing
implicit-threading and implicit event-based programming?
I doubt that implicit threading is feasible in an imperative
language like Perl. Lazy lists are comparatively easy because
they are sequential values produced by a single closure. But
a lazy object has a lot of methods that can be invoked in complicated
patterns. So there must be explicit locking or continuation mechanisms
that allow the programmer to stall certain calls or to enforce the
completion of dependent threads.
I can envision a lazy object's state to branch whenever a method
doesn't run to completion. So a single object becomes an overlay
of different states of execution that eventually collapse to a state
of interest or are never realized. This non-realization of expensive
state calculations is the benefit of lazy objects but the branching
of the states is a heavy burden. In summary I believe it doesn't
pay off. IOW, objects are best kept eager.
Regards TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
