On Friday, 15 August 2014 10:05:58 UTC+10, Christopher Layne wrote: > > On Aug 14, 2014, at 1650 PT, Ron Savage <[email protected] <javascript:>> > wrote: > > > On Friday, 15 August 2014 09:15:46 UTC+10, Christopher Layne wrote: > > On Aug 14, 2014, at 1523 PT, Ron Savage <[email protected]> wrote: > > > > > Questions: > > > > > > Are these for C or Perl or both? > > > > > > 1.) What should be its name? [Probably not doit() ]. > > > > > > I'd like it to be called process(). > > > > process() as an additional method also sounds find to me, although it's > a bit non-parser like. However, the latter probably doesn't matter as it's > an OO interface, and $parser->process() does make sense in that context. > > > > I do prefer process(), but now read_all() comes to mind. > > I also thought about read_all() but the problem is that the _all() part > implies "read all of the input." That's already what read() is doing and a > matching call would be read_partial() which also wouldn't really be > involved with what we're shooting for. I think your original process() is > better than read_all(). $parser->run() would also work, as that's kind of > what value() is already doing. I've always thought value() was named > somewhat strangely for what it actually did - regardless of the fact that > it returns value(s) for the parse. Perhaps that's because value() usually > implies something already computed whereas value() itself definitely has > significant side-effects. That wouldn't change though. >
Agreed. Forget read_all(). As for run(), I think it's too general....... As for value(), I would probably have called it result(), or perhaps even status(). -- You received this message because you are subscribed to the Google Groups "marpa parser" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
