On Wed, Mar 19, 2003 at 12:35:19PM -0500, Dan Sugalski wrote: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 :-)
Well, I'm not 100% sure we need it for rules. Simon's point is well-taken, but on further reflection what we're doing is subclassing the existing grammar and reinvoking the regex engine on that subclassed grammar, rather than redefining the grammar actually in use. The former doesn't require runtime redefinitions, the latter does, and I think we're going to use the former scheme.
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
We can't add them once we hit betas. I'd as soon add them now, rather than later.
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..
Well, not to be too cranky (I'm somewhat ill at the moment, so I'll apologize in advance) but... no. No, we don't actually have to, though if we could that'd be nice.
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.
Semantics. Until Larry's nailed down what he wants, there are issues of reestablishing hypotheticals on continuation reinvocation, flushing those hypotheticals multiple times, what happens to hypotheticals when you invoke a continuation with hypotheticals in effect, what happens to hypotheticals inside of coroutines when you establish them then yield out, and when hypotheticals are visible to other threads.
I read through your proposal (I'm assuming it's the one that started this thread) and it's not sufficient unless I missed something, which I may have.
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,
Well....
Sounds like a good deal? :-)
At the moment, no. It seems like a potentially large amount of overhead for no particular purpose, really. I don't see any win in the regex case, and you're not generalizing it out to the point where there's a win there. (I can see where it would be useful in the general case, but we've come nowhere near touching that)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
