Patrick R. Michaud wrote:
Alas, it doesn't seem to be quite that straightforward. Or maybe
it is, and I'm just not seeing it yet. So, I'll just "think out
loud" here for a bit...
I like it if that is happening on the list instead of off-list.
Thanks.
I think the state object ought to have some sort of base type --
is it Grammar? Rule? If we say it's a "Rule", then we're
effectively saying that "applying a Rule to a target results
in a Rule object containing the state of the match", which just
sounds completely wrong to my ears/eyes (even though it may in
fact be correct).
It sounds perfectly to my ears. You should think of ordinary
subs as classes and calls to them as instances of that class.
The environment created at runtime for such an invokation actually
*is* a sub object. The code you write is a class specifying the
behaviour of running instances. In a multi-threaded application
there might be several long-living invocations/instances that
spawn other shorter living ones. But this is the same as with
dynamic memory allocation for data objects.
Suspended coroutines are just the same as data objects that no code
instance is working with. The CPS of Parrot makes the implementation
of this unification of code and data instances easier than caring
for a central call stack in other VMs or real silicon.
The programming language rules are written in is of course a
sublanguage of Perl 6---but that you know better than I.
I'll be appreciative of any illumination that others can provide
to the above, especially from @Larry.
Sorry, I'm neither one(@Larry) nor a good Illuminati ;)
--
TSa (Thomas Sandlaß)
