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ß)Thread Previous | Thread Next