Then I wasn't clear enough, sorry. This is perl -- the state of something at compile time is just a suggestion as to how things ultimately work.
Yes, hence my surprise about actually inlining stuff, luckily that was just a misunderstanding :-)
I'll nudge Larry to add it explicitly, but in general redefinitons of code that you're in the middle of executing don't take effect immediately, and it's not really any different for regex rules than for subs.
Ah, but we're not redefining the sub that's running, but the subs it's about to call. That works for subs, and Simon Cozens already pointed out we certainly also need it for rules :-)
Actually, we should be extraordinarily liberal with the application of restrictions at this phase. It's far easier to lift a restriction later than to impose it later,
This is perl 6, we can add a new restriction next week
and I very much want to stomp out any constructs that will force slow code execution. Yes, I may lose, but if I don't try...
You're absolutely right, and optimization is very important to me too. But you can't *only* look at the speed of constructs, or we'll be coding in C or assembly :-)
We'll need to meet in the middle..
The issue of hypotheticals is complex.
Well, I'm a big boy, I'm sure I can handle it. Are you even talking about semantics or implementation here? Because I already gave my insights on semantics, and I have 'em in my head for implementation too but I should probably take those to perl6-internals instead.
Ultimately the question is "How do you backtrack into arbitrary code, and how do we know that the arbitrary code can be backtracked into?" My answer is we don't, but I'm not sure how popular that particular answer is.
I say, make generic semantics first, and then optimize the heck out of it.
That's fine. I disagree. :)
Now that Simon Cozens has established that sub-rules need to be looked up at runtime, I think we can both be happy:
As far as I can see, a rule will consist of two parts: The wrapper that will handle stuff when the rule is invoked as a normal method, perhaps handle modifiers, handle searches for unanchored matches, setup the state, etc; and the actual body that does a match at the current position.
Now, what you want is that subrule-invocation goes directly from body to body, skipping the overhead of method invocation to the wrapper. I say, when you look up the method for a subrule, check if it is a regular rule and if so call its body directly, and otherwise use the generic mechanism.
I'll get my lovely generic semantics with the direct body->body calling hidden away as an optimization details, and I get the ability to write rule-methods in perl code.
You still get your low-overhead body->body calls and therefore the speed you desire (hopefully). Since you need to fetch the rule body anyway, there should be no extra overhead: where you'd normally throw an error (non-rule invoked as subrule) you'd switch to generic invocation instead.
Sounds like a good deal? :-)
-- Matthijs van Duin -- May the Forth be with you!
