At 12:00 AM + 3/20/03, Simon Cozens wrote:
[EMAIL PROTECTED] (Matthijs Van Duin) writes:
OK, I suppose that works although that still means you're moving the
complexity from the perl implementation to its usage: in this case,
the perl 6 parser which is written in perl 6
No, I don't believe
--- Matthijs van Duin [EMAIL PROTECTED] wrote:
On Wed, Mar 19, 2003 at 03:46:50PM -0500, Dan Sugalski wrote:
They should be though, if a variable was hypothesized when the
continuation was taken, then it should be hypothesized when that
continuation is invoked.
Should they? Does
On Thu, Mar 20, 2003 at 08:49:28AM -0800, Austin Hastings wrote:
--- Matthijs van Duin [EMAIL PROTECTED] wrote:
you seem to have a much complexer model of hypotheses
than what's in my head.
The complex model is right -- in other words, if hypotheses are to be a
first-class part of the language
On Tue, Mar 18, 2003 at 09:28:43PM -0700, Luke Palmer wrote:
Plan 1: Pass each rule a Isuccess continuation (rather than a
backtrack one), and have it just return on failure. The big
difference between this and your example is that Clets are now
implemented just like Ctemps. Too bad Clet needs
Matthijs van Duin wrote:
Which system is likely to run faster on parrot?
I would propose, estimate the ops you need and test it :)
E.g. call a continuation 1e6 times and communicate state with one global
(a lexical is probably the same speed, i.e. a hash lookup)
$ cat a.pasm
new P5,
On Wed, Mar 19, 2003 at 10:38:54AM +0100, Leopold Toetsch wrote:
I would propose, estimate the ops you need and test it :)
Hmm, good point
Or even better.. I should just implement both examples and benchmark them;
they're simple enough and the ops are available.
I guess it's time to familiarize
On Wed, Mar 19, 2003 at 01:01:28PM +0100, Matthijs van Duin wrote:
On Wed, Mar 19, 2003 at 10:38:54AM +0100, Leopold Toetsch wrote:
I would propose, estimate the ops you need and test it :)
Hmm, good point
Or even better.. I should just implement both examples and benchmark them;
they're simple
On Wed, Mar 19, 2003 at 10:38:54AM +0100, Leopold Toetsch wrote:
I would propose, estimate the ops you need and test it :)
I haven't completed testing yet, however it's becoming clear to me that
this is likely to be a pointless effort
There are so many variables that can affect performance here
At 10:05 AM +0100 3/19/03, Matthijs van Duin wrote:
But.. say you have:
foo bar
Would would this be implemented? When bar fails, it needs to
backtrack into foo, which has already returned. Are you saying
every rule will be an explicit state machine?
By compile-time interpolation. foo isn't
On Wed, Mar 19, 2003 at 10:40:02AM -0500, Dan Sugalski wrote:
By compile-time interpolation. foo isn't so much a subroutine as a
macro. For this to work, if we had:
foo: \w+?
bar: [plugh]{2,5}
then what the regex engine *really* got to compile would be:
(\w+?) ([plugh]{2,5})
with names
At 4:52 PM +0100 3/19/03, Matthijs van Duin wrote:
On Wed, Mar 19, 2003 at 10:40:02AM -0500, Dan Sugalski wrote:
By compile-time interpolation. foo isn't so much a subroutine as
a macro. For this to work, if we had:
foo: \w+?
bar: [plugh]{2,5}
then what the regex engine *really* got to
On Wed, Mar 19, 2003 at 11:09:01AM -0500, Dan Sugalski wrote:
At the time I run the regex, I can inline things. There's nothing
that prevents it. Yes, at compile time it's potentially an issue,
since things can be overridden later,
OK, but that's not how you initially presented it :-)
you
Matthijs van Duin wrote:
sweepoff# or bus error
collectoff# or segmentation fault
Please try :
/* set this to 1 for tracing the system stack and processor registers */
#define TRACE_SYSTEM_AREAS 1
in dod.c (works for me).
Though I don't know, if processor registers on PPC gets
On Wed, Mar 19, 2003 at 11:09:01AM -0500, Dan Sugalski wrote:
By the time the regex is actually executed, it's fully specified. By
definition if nothing else--you aren't allowed to selectively
redefine rules in the middle of a regex that uses those rules. Or,
rather, you can but the update
On Wed, 19 Mar 2003, Jonathan Scott Duff wrote:
Are you implying that
$fred = rx/fred/;
$string ~~ m:w/ $fred { $fred = rx/barney/; } rubble /
won't match barney rubble?
Or, worse, that
$fred = rx/fred/;
$string ~~ m:w/ { $fred = rx/barney/; } $fred rubble /
At 10:41 AM -0600 3/19/03, Jonathan Scott Duff wrote:
On Wed, Mar 19, 2003 at 11:09:01AM -0500, Dan Sugalski wrote:
By the time the regex is actually executed, it's fully specified. By
definition if nothing else--you aren't allowed to selectively
redefine rules in the middle of a regex that
At 5:38 PM +0100 3/19/03, Matthijs van Duin wrote:
On Wed, Mar 19, 2003 at 11:09:01AM -0500, Dan Sugalski wrote:
At the time I run the regex, I can inline things. There's nothing
that prevents it. Yes, at compile time it's potentially an issue,
since things can be overridden later,
OK, but
[EMAIL PROTECTED] (Dan Sugalski) writes:
you aren't allowed to selectively redefine
rules in the middle of a regex that uses those rules.
This is precisely what a macro does.
--
How should I know if it works? That's what beta testers are for. I only
coded it.
(Attributed to Linus Torvalds,
At 5:47 PM + 3/19/03, Simon Cozens wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
you aren't allowed to selectively redefine
rules in the middle of a regex that uses those rules.
This is precisely what a macro does.
Not once execution starts, no.
--
[EMAIL PROTECTED] (Dan Sugalski) writes:
At 5:47 PM + 3/19/03, Simon Cozens wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
you aren't allowed to selectively redefine
rules in the middle of a regex that uses those rules.
This is precisely what a macro does.
Not once execution
At 5:54 PM + 3/19/03, Simon Cozens wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
At 5:47 PM + 3/19/03, Simon Cozens wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
you aren't allowed to selectively redefine
rules in the middle of a regex that uses those rules.
This is
[EMAIL PROTECTED] (Dan Sugalski) writes:
Compilation's just execution of a regex, albeit the Perl6::Grammar::program
regex, and that regex will need to be modified while it's in operation in
order to pick up macro is parsed definitions and apply them to the rest
of what it's parsing.
Ah,
On Wed, Mar 19, 2003 at 12:35:19PM -0500, Dan Sugalski wrote:
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
At 8:04 PM +0100 3/19/03, Matthijs van Duin wrote:
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
On Wed, Mar 19, 2003 at 02:31:58PM -0500, Dan Sugalski wrote:
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
At 9:14 PM +0100 3/19/03, Matthijs van Duin wrote:
On Wed, Mar 19, 2003 at 02:31:58PM -0500, Dan Sugalski wrote:
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
On Wed, Mar 19, 2003 at 03:46:50PM -0500, Dan Sugalski wrote:
Right. Macro definition ends, you subclass off the parser object,
then immediately call into it
...
You, as a user-level programmer, don't have to track the state. The
parser code will, but that's not a big deal.
OK, I suppose that
[EMAIL PROTECTED] (Matthijs Van Duin) writes:
OK, I suppose that works although that still means you're moving the
complexity from the perl implementation to its usage: in this case,
the perl 6 parser which is written in perl 6
No, I don't believe that's what's happening. My concern is that at
I would like to express my sincere gratitude to all of you for working
through these issues. I bent my brain on the Perl 5 regex engine,
and that was just a simple recurse-on-success engine--and I'm not
the only person it drove mad. I deeply appreciate that Perl 6's
regex engine may drive you
On Tue, 18 Mar 2003, Matthijs van Duin wrote:
and maybe also:
What is the current plan?
although I got the impression earlier that there isn't any yet for invoking
subrules :-)
See line 1014, languages/perl6/P6C/rule.pm. The hack I used was to call
rules like ordinary subs, and have them
A quick note before I begin: the stuff in this email isn't just an
implementation detail - it impacts the language too, that's why I'm
posting it here. Should I cross-post to perl6-internals ? (I'm not
really familiar with that list yet)
I've recently spent thought on backtracking into
My main questions are:
Is there a simpler system I'm overlooking?
Which of the two systems would you prefer if speed isn't the issue?
Mechanism 1.
Which system is likely to run faster on parrot?
They're both likely to be very slow.
and maybe also:
What is the current plan?
32 matches
Mail list logo
