At 06:28 PM 12/2/00 -0500, Bradley M. Kuhn wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
It's more than just the parser. You've got the bytecode compiler and
possibly the optimizer as well, and they're probably going to be all, or
mostly, C. On the other hand they might not have any
On Wed, Nov 29, 2000 at 02:57:23PM -0500, Dan Sugalski wrote:
My only worry is, how do we reconcile this with the idea of
Perl having an easily modifiable grammar and being a good environment for
little-language stuff?
That's a good question, and it depends on what Larry's thinking of for
On Thu, Nov 30, 2000 at 11:54:31AM +, Simon Cozens wrote:
I categorically do *NOT* want perl6-internals to turn into a basic course in
compiler design, purely for the benefit of those who know nothing at all about
what they're trying to achieve. I'd like Perl 6 to be a masterwork, and
On Thu, 30 Nov 2000, Simon Cozens wrote:
On Thu, Nov 30, 2000 at 11:54:31AM +, Simon Cozens wrote:
I categorically do *NOT* want perl6-internals to turn into a basic course in
compiler design, purely for the benefit of those who know nothing at all about
what they're trying to achieve.
At 04:16 PM 11/28/00 -0800, Steve Fink wrote:
Perl5 is parseable with a single token of lookahead and lots of
parser/lexer communication. Sort of. It would be nice to prevent it from
getting any worse.
I'm really thinking that the lexer, parser, and tokenizer can't be anywhere
near as separate
Simon Cozens [EMAIL PROTECTED] wrote:
On Wed, Nov 29, 2000 at 02:02:31PM -0500, Dan Sugalski wrote:
I'm really thinking that the lexer, parser, and tokenizer can't be
anywhere
near as separate as we'd like. I think we're going to end up with a
rather
odd mutant beast. Hopefully
At 01:38 PM 11/29/00 +, David Grove wrote:
That's basically where I've been talking about a "creole processor", which
would in these terms be a pre-preprocessor, I imagine. This was also my
original source of confusion, since I thought that this was the primary
goal of the "pre-processor".
On Tue, Nov 28, 2000 at 06:58:57PM +, Tom Hughes wrote:
I didn't say that having infinite lookahead was better than allowing
backtracking. I simply said that the two were equivalent and that any
problem that can be solved by one can be solved by the other.
Fair enough.
That's quite a
Tom Hughes wrote:
In message [EMAIL PROTECTED]
Simon Cozens [EMAIL PROTECTED] wrote:
In a sense, though, you're right; this is a general problem. I'm currently
trying to work out a design for a tokeniser, and it seems to me that
there's going to be a lot of communicating of
Okay, here's a question for those of you with more experience at parsers
than I have. (Which would be about everyone)
Is there any reasonable case where we would need to backtrack over
successfully parsed source and redo the parsing? I'm not talking about the
case where regular expressions
On Mon, Nov 27, 2000 at 04:41:34PM -0500, Dan Sugalski wrote:
Okay, here's a question for those of you with more experience at parsers
than I have. (Which would be about everyone)
Is there any reasonable case where we would need to backtrack over
successfully parsed source and redo the
At 04:50 PM 11/27/00 -0500, Kurt D. Starsinic wrote:
On Mon, Nov 27, 2000 at 04:41:34PM -0500, Dan Sugalski wrote:
Okay, here's a question for those of you with more experience at parsers
than I have. (Which would be about everyone)
Is there any reasonable case where we would need to
12 matches
Mail list logo