At 02:17 PM 12/13/00 +, Nicholas Clark wrote:
>On Wed, Nov 29, 2000 at 03:33:16PM -0500, Dan Sugalski wrote:
> > Good integration with source filters may well solve a large chunk of our
> > little language problem. They're a pain and a half to write now but if we
> > can get them easier to wri
On Wed, Nov 29, 2000 at 03:33:16PM -0500, Dan Sugalski wrote:
> Good integration with source filters may well solve a large chunk of our
> little language problem. They're a pain and a half to write now but if we
> can get them easier to write that'd be a good thing. ('Specially if we can
> man
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 an
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 internal hooks for
> perl code to wedge into, in which c
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 01, 2000 at 08:42:57PM -0500, Bradley M. Kuhn wrote:
> > I believe that to do a true port to the JVM (e.g., supporting
> > eval($STRING)), we'll need to implement a bootstrapping parser for the
> > parser code in Java.
> Uhm, and then in ever
At 08:42 PM 12/1/00 -0500, Bradley M. Kuhn wrote:
>I believe that to do a true port to the JVM (e.g., supporting
>eval($STRING)), we'll need to implement a bootstrapping parser for the
>parser code in Java.
>
>My concern is that the more integrated the lexer, parser and tokenizer are
>integrated,
On Fri, Dec 01, 2000 at 08:42:57PM -0500, Bradley M. Kuhn wrote:
> I believe that to do a true port to the JVM (e.g., supporting
> eval($STRING)), we'll need to implement a bootstrapping parser for the
> parser code in Java.
Uhm, and then in every other language we port it to. Are you *sure* that
[Sorry for chiming in late here...]
> 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.
Simon Cozens <[EMAIL PROTECTED]> wrote:
> This would *honestly* be my preferenc
Today around 2:12pm, Dan Sugalski hammered out this masterpiece:
: At 01:23 PM 11/30/00 -0500, Buddha Buck wrote:
: >
: >Here here! Is there a place where PAWB's can sign up?
:
: Not at the moment, at least not formally. Want to set something up? (And
: yes, I'm serious. A good master/apprenti
On Thu, 30 Nov 2000, Dan Sugalski wrote:
> At 01:23 PM 11/30/00 -0500, Buddha Buck wrote:
> >Here here! Is there a place where PAWB's can sign up?
>
> Not at the moment, at least not formally. Want to set something up? (And
> yes, I'm serious. A good master/apprentice thing would help a lot of
At 01:23 PM 11/30/00 -0500, Buddha Buck wrote:
>At 11:47 AM 11-30-2000 -0500, Bryan C. Warnock wrote:
>>I forget who proposed it originally, but I thought it an excellent
>>analogy, and
>>an excellent model for Perl development. Like any tradecraft, there are
>>masters, apprentices, and the comm
At 11:47 AM 11-30-2000 -0500, Bryan C. Warnock wrote:
>I forget who proposed it originally, but I thought it an excellent
>analogy, and
>an excellent model for Perl development. Like any tradecraft, there are
>masters, apprentices, and the common consumer. The apprentice shouldn't
>master, just
On Thu, 30 Nov 2000, Dan Sugalski wrote:
> What we're doing is *designing* the building. A more appropriate analogy is
> one where you walk into the architect's conference room and start
> commenting on and fiddling with the design of the building. While the sign
> says "Open Meeting", the expe
At 10:07 AM 11/30/00 -0500, Andy Dougherty wrote:
>On Thu, 30 Nov 2000, Bryan C. Warnock wrote:
>
> > You don't want the compiler design to be a 'hands-on experiment' for us
> > inexperienced folk? That's not elitist, that's pragmatic.
> >
> > You don't want this to be a learning experience - (co
At 05:07 AM 11/30/00 +, David Grove wrote:
>Dan: In any PDD generated from this group, we really need to define for
>the "semantically challenged" the terms that are used within it:
No, I don't think that's appropriate.
Any new terminology specific to the PDD should be defined, but that's it
On Thu, 30 Nov 2000, Andy Dougherty wrote:
> On Thu, 30 Nov 2000, Bryan C. Warnock wrote:
>
> > You don't want the compiler design to be a 'hands-on experiment' for us
> > inexperienced folk? That's not elitist, that's pragmatic.
> >
> > You don't want this to be a learning experience - (correc
"Bryan C. Warnock" <[EMAIL PROTECTED]> wrote:
> 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 tho
On Thu, 30 Nov 2000, Bryan C. Warnock wrote:
> You don't want the compiler design to be a 'hands-on experiment' for us
> inexperienced folk? That's not elitist, that's pragmatic.
>
> You don't want this to be a learning experience - (corrections, observations,
> answers) - to the same? *That's
Simon Cozens <[EMAIL PROTECTED]> 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 t
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 ac
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
>
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 30, 2000 at 05:07:32AM +, David Grove wrote:
> > >From my understanding, "API" is the set of functions internal to
Perl
> and
> > PerlXS that allow C to access Perl internal structures, functions,
etc.,
> > for the purpose (or effect
On Thu, Nov 30, 2000 at 05:07:32AM +, David Grove wrote:
> >From my understanding, "API" is the set of functions internal to Perl and
> PerlXS that allow C to access Perl internal structures, functions, etc.,
> for the purpose (or effect) of "writing" "Perl" in "C" (SvPV(whatsis)).
Uhm, no. A
then... "either in perl, or in C"
better?
>From my understanding, "API" is the set of functions internal to Perl and
PerlXS that allow C to access Perl internal structures, functions, etc.,
for the purpose (or effect) of "writing" "Perl" in "C" (SvPV(whatsis)).
I'm talking about either writing i
On Thu, Nov 30, 2000 at 03:30:28AM +, David Grove wrote:
> For this, I'd probably look for it to be writable either in perl or in api
You keep using that word. I do not think it means what you think it means.
--
Pray to God, but keep rowing to shore.
-- Russian Proverb
It can be done any which way but loose, and I'm trying to keep my thinking
flexible for any applied use in this sense. What I'm _doing_ for my own
work at this point is simply making a creole filter (or source filter),
and spitting out perl5 which is then sucked into eval_pv(). For this, I'd
proba
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 o
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".
At 07:07 PM 11/29/00 +, Simon Cozens 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. Hop
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. H
Dan Sugalski wrote:
>
> 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
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 one that's understandable by reasonably sane
> p
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 separat
At 09:58 AM 11/29/00 -0800, Steve Fink wrote:
>As soon as the lexer sees "s#", it
>starts treating # as a delimiter -- it doesn't need to conditionally
>treat the # as either a delimiter or a comment. (Especially since
>there's nothing following it that could resolve the ambiguity!)
One thing I'v
Chaim Frenkel wrote:
>
> > "SF" == Steve Fink <[EMAIL PROTECTED]> writes:
>
> SF> Handling the parser's state can be done in a backtracking DFA-like or a
> SF> direct NFA-like way. The NFA way is to keep track of all possible parse
> SF> states and advance each one in parallel based on the n
> "SF" == Steve Fink <[EMAIL PROTECTED]> writes:
SF> Handling the parser's state can be done in a backtracking DFA-like or a
SF> direct NFA-like way. The NFA way is to keep track of all possible parse
SF> states and advance each one in parallel based on the next token. The DFA
SF> way is recu
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 comm
In message <[EMAIL PROTECTED]>
Simon Cozens <[EMAIL PROTECTED]> wrote:
> Parsing Perl is not easy. :)
You can say that again ;-)
> At some points, you have to say, well, heck, I don't *know* what this token
> is. At the moment, perl guesses, and it guesses reasonably well. But
> guess
At 06:58 PM 11/28/00 +, Tom Hughes wrote:
>In message <[EMAIL PROTECTED]>
> Simon Cozens <[EMAIL PROTECTED]> wrote:
>
> > I doubt it; I get the feeling that what Dan is talking about is infinite
> > look-*behind*. Nine times out of ten, you won't need to redo your parsing,
> > so hav
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
In message <[EMAIL PROTECTED]>
Simon Cozens <[EMAIL PROTECTED]> wrote:
> I doubt it; I get the feeling that what Dan is talking about is infinite
> look-*behind*. Nine times out of ten, you won't need to redo your parsing,
> so having an infinite lookahead will just slow everything down
> 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 run over text and ultimately fail, but
> rather cases where we need to chuck out part of what we have and restart?
]-
On Mon, Nov 27, 2000 at 11:49:30PM +, Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > 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
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> 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 run over text and ultimately fail, bu
> [I'm assuming that you're implying that regular files (determinate length,
> seekable) are easy so we don't worry about optimising them until we make the
> harder stuff work. So we forget I ever sent that last paragraph for some
You mean I cannot start up the parser on a socket and feed it perl
On Mon, Nov 27, 2000 at 05:03:05PM -0500, Dan Sugalski wrote:
> 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:
> > In current perl, we do something _like_ that to disambiguate certain
> >situations. Grep the sources for `
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
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 th
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 run
49 matches
Mail list logo
