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
48 matches
Mail list logo
