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 t
--- 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 t
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 t
[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
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 wor
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 engin
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 redefini
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 r
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 misundersta
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 e
[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.
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 pr
[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
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.
--
Da
[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 Torvald
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 that's
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 uses
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> rub
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 upda
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 tr
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 aren'
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. 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 w
On Wed, Mar 19, 2003 at 10:40:02AM -0500, Dan Sugalski wrote:
By compile-time interpolation. 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 atta
At 10:05 AM +0100 3/19/03, Matthijs van Duin wrote:
But.. say you have:
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. isn't so much a s
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 th
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 t
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 e
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
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, .Perl
On Tue, Mar 18, 2003 at 09:28:43PM -0700, Luke Palmer wrote:
Plan 1: Pass each rule a I continuation (rather than a
backtrack one), and have it just return on failure. The big
difference between this and your example is that Cs are now
implemented just like Cs. Too bad C needs non-regex
behavior
> 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?
>
31 matches
Mail list logo
