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.
That's not the impression I got from Simon
It would also be rather annoying.. think about balanced braces etc, take this rather contrieved, but valid example:
$x ~~ m X {
macro ... yada yada yada;
} X;It seems to be that you're really inside a grammar rule when that macro is defined. Otherwise you'd have to keep a lot of state outside the parser to keep track of such things, which is exactly what perl grammars were supposed to avoid I think.
We can't add them once we hit betas. I'd as soon add them now, rather than later.
Well, I'd rather not add it at all :-)
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.
OK, strictly speaking that's true, but I think we can
Semantics. Until Larry's nailed down what he wants, there are issues of reestablishing hypotheticals on continuation reinvocation,
They should be though, if a variable was hypothesized when the continuation was taken, then it should be hypothesized when that continuation is invoked.
flushing those hypotheticals multiple times,
Not idea what you mean
what happens to hypotheticals when you invoke a continuation with hypotheticals in effect,
Basically de-hypothesize all current hypotheticals, and re-hypothesize the ones that were hypothesized when the continuation was taken. You can ofcourse optimize this by skipping the "common ancestry", if you know what I mean
what happens to hypotheticals inside of coroutines when you establish them then yield out,
This follows directly from the implementation of coroutines: the first yield is a normal return, so if you hypothesize $x before that it'll stay hypothesized. if you then hypothesize $y outside the coroutine and call the coroutine again, $y will be de-hypothesized. If the coroutine then hypothesizes $z and yields out, $z will be de-hypothesized and $y
re-hypothesized. $x will be unaffected by all this
and when hypotheticals are visible to other threads.
I haven't thought of that, but to be honest I'm not a big fan of preemptive threading anyway. Cooperative threading using continuations is probably faster, has no synchronization issues. And the behavior of hypotheticals follows naturally there (you can use 'let' or 'temp' to create thread-
local variables in that case)
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.
Also look at Sean O'Rourke's reply and my reply to that; it contains additional info.
Sounds like a good deal? :-)
At the moment, no. It seems like a potentially large amount of overhead for no particular purpose, really.
I have to admit I don't know the details of how your system works, but what I had in mind didn't have any extra overhead at all -- under the (apparently still debatable) assumption that you need to look up subrules at runtime anyway.
You do agree that if that is possible, is *is* a good deal?
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)
We have come near it.. backtracking is easy using continuations, and we can certainly have rules set the standard for the general case.
-- Matthijs van Duin -- May the Forth be with you!
