On Tue, Oct 17, 2000 at 08:57:43PM -0400, Dan Sugalski wrote:
> On Tue, 17 Oct 2000, Adam Turoff wrote:
> > Dammit, I'm not finding the message in the thread, but someone casually
> > mentioned writing the important bits of parsing Perl in Perl5, generating
> > bytecode, and starting Perl6 by writ
On Tue, 17 Oct 2000, Adam Turoff wrote:
> On Tue, Oct 17, 2000 at 07:18:54PM -0400, Bradley M. Kuhn wrote:
> > Adam Turoff wrote:
> > > to write the Perl tokenizer in a Perl[56] regex, which is more easily
> > > parsable in C. All of a sudden, toke.c is replaced by toke.re, which
> > > would be
On Tue, Oct 17, 2000 at 07:18:54PM -0400, Bradley M. Kuhn wrote:
> Adam Turoff wrote:
> > to write the Perl tokenizer in a Perl[56] regex, which is more easily
> > parsable in C. All of a sudden, toke.c is replaced by toke.re, which
> > would be much more legible to this community (which is more
Adam Turoff wrote:
> to write the Perl tokenizer in a Perl[56] regex, which is more easily
> parsable in C. All of a sudden, toke.c is replaced by toke.re, which
> would be much more legible to this community (which is more of a strike
> against toke.c instead of a benefit of some toke.re).
La
On Tue, Oct 17, 2000 at 01:18:39PM -0400, Ken Fox wrote:
> Those are hard to understand because so much extra work has to be done to
> compensate for lack of top-down state when doing a bottom-up match.
I haven't found this to be true.
> Since Perl is much more difficult than C++ to parse...
Pe
On Tue, Oct 17, 2000 at 01:18:39PM -0400, Ken Fox wrote:
> The other down-side is that we'd be doing a whole lot of custom work designed
> just for parsing Perl instead of creating something more general and powerful
> that can be used for other problems as well. For example, I'd imagine the PDL
>
Simon Cozens wrote:
> To be perfectly honest, my preferred solution would be to have the tokenizer,
> lexer and parser as a single, hand-crafted LR(k) monstrosity.
Those are hard to understand because so much extra work has to be done to
compensate for lack of top-down state when doing a bottom-u
At 06:53 PM 10/17/00 +1100, Jeremy Howard wrote:
>In terms of bootstrapping, however, we either need to:
> - Write the Perl subset in C (or some other portable language), or
> - Use Perl 5 as the 'Perl subset', and distribute that with Perl 6.
>
>The 2nd of these options seems unlikely to be pra
At 10:22 AM 10/17/00 -0400, John Porter wrote:
>Simon Cozens wrote:
> >
> > Currently, the tokeniser and the lexer are a combined entity.
>
>Yes, in the vast majority of languages; so people get used to thinking
>that it has to be this way.
I'd just as soon we thought a bit differently. I'm not s
Simon Cozens wrote:
> It's time to drag out my quote of the week:
>
> Recursive-descent, or predictive, parsing ONLY works on grammars
> where the first terminal symbol of each subexpression provides
> enough information to choose which production to use.
Recursive-descent parsers ar
Simon Cozens wrote:
> This would have to take account of the fact that Perl's tokeniser is
> aware of what's going on in the rest of perl. Consider
>
> print foo;
>
> What should the tokeniser return for "foo"? Is it a bareword? Is it a
> subroutine call? Is it a class? Is it - heaven forbi
Simon Cozens wrote:
>
> Currently, the tokeniser and the lexer are a combined entity.
Yes, in the vast majority of languages; so people get used to thinking
that it has to be this way.
> my preferred solution would be to have the tokenizer,
> lexer and parser as a single, hand-crafted LR(k) m
On Tue, Oct 17, 2000 at 11:22:02AM +0100, Nicholas Clark wrote:
> [Seriously, I was under the impression that the perl tokenizer was
> influenced by the state of the lexer]
Currently, the tokeniser and the lexer are a combined entity. It doesn't have
to be this way, though. At least, I don't thin
On Tue, Oct 17, 2000 at 11:00:35AM +0100, Simon Cozens wrote:
> On Tue, Oct 17, 2000 at 10:37:24AM +0100, Simon Cozens wrote:
> > What should the tokeniser return for "foo"?
>
> Uh, tokenizer != lexer. Insert coffee. Yes, writing a tokeniser in a regexp
> should be very doable.
To allow the lex
On Tue, Oct 17, 2000 at 10:37:24AM +0100, Simon Cozens wrote:
> What should the tokeniser return for "foo"?
Uh, tokenizer != lexer. Insert coffee. Yes, writing a tokeniser in a regexp
should be very doable.
--
Building translators is good clean fun.
-- T. Cheatham
On Tue, Oct 17, 2000 at 03:56:20AM -0400, Adam Turoff wrote:
> > We could learn quite a bit by looking through the code from
> > Parse::RecDescent, switch.pm, and friends. Damian's done a lot of parsing
> > (including parsing Perl) with Perl, so this would be a good place to start.
It's time to d
On Tue, Oct 17, 2000 at 06:53:47PM +1100, Jeremy Howard wrote:
> Leon Brocard wrote:
> > Hmmm, I wonder what kind of subset would be necessary - surely the
> > most useful constructs are also the most complicated...
>
> We could learn quite a bit by looking through the code from
> Parse::RecDescen
Leon Brocard wrote:
> Bradley M. Kuhn sent the following bits through the ether:
>
> > It should be noted that in Larry's speech on Friday, he said that he
wanted
> > to write the Lexer and Parser for Perl in some subset of Perl. :)
>
> Is there a writeup somewhere for those who couldn't attend?
Bradley M. Kuhn sent the following bits through the ether:
> It should be noted that in Larry's speech on Friday, he said that he wanted
> to write the Lexer and Parser for Perl in some subset of Perl. :)
Is there a writeup somewhere for those who couldn't attend?
Hmmm, I wonder what kind of s
Dan Sugalski wrote:
> At 07:48 PM 10/12/00 +, John van V wrote:
>
>
> > * It also means we can write bits of perl in Perl, and similarly not
> > have
> >to care about this fact.
> >
> >Granted, some developers are thick as a brick...
> >If you are writing perl in Perl, then, pr
Dan Sugalski wrote:
>
> At 08:57 PM 10/12/00 +0100, Simon Cozens wrote:
> >On Thu, Oct 12, 2000 at 03:43:07PM -0400, Dan Sugalski wrote:
> > > Doing this also means someone writing an app with an embedded perl
> > > interpreter can call into perl code the same way as they call into any C
> > > li
At 10:16 AM 10/13/00 +0100, Nicholas Clark wrote:
>On Thu, Oct 12, 2000 at 03:24:23PM -0700, Russ Allbery wrote:
> > Dan Sugalski <[EMAIL PROTECTED]> writes:
> >
> > > C's vararg handling sucks in many sublime and profound ways. It does,
> > > though, work. If we declare in advance that all C-visi
On Thu, Oct 12, 2000 at 03:24:23PM -0700, Russ Allbery wrote:
> Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > C's vararg handling sucks in many sublime and profound ways. It does,
> > though, work. If we declare in advance that all C-visible perl functions
> > have an official parameter list of
At 11:21 PM 10/12/00 -0400, John Porter wrote:
>Jarkko Hietaniemi wrote:
> > On Thu, Oct 12, 2000 at 10:55:52PM -0400, John Porter wrote:
> > >
> > > I don't think it's that big a deal. Easy enough to wrap in a macro.
> >
> > I thought (hoped) that the plan was the avoid the cpp like the plague
>
Jarkko Hietaniemi wrote:
> On Thu, Oct 12, 2000 at 10:55:52PM -0400, John Porter wrote:
> >
> > I don't think it's that big a deal. Easy enough to wrap in a macro.
>
> I thought (hoped) that the plan was the avoid the cpp like the plague
> and cancer it is.
Well, yes, definitely; but we're j
On Thu, Oct 12, 2000 at 10:55:52PM -0400, John Porter wrote:
> Dan Sugalski wrote:
> >
> > Well, damn. And I mean that sincerely. :(
>
> I don't think it's that big a deal. Easy enough to wrap in a macro.
I thought (hoped) that the plan was the avoid the cpp like the plague
and cancer it is.
Dan Sugalski wrote:
>
> Well, damn. And I mean that sincerely. :(
I don't think it's that big a deal. Easy enough to wrap in a macro.
--
John Porter
At 12:07 AM 10/13/00 +0100, Simon Cozens wrote:
>On Thu, Oct 12, 2000 at 03:24:23PM -0700, Russ Allbery wrote:
> > Can't. ISO C requires that all variadic functions take at least one named
> > parameter. The best you can do is something like (void *, ...).
Well, damn. And I mean that sincerely.
On Thu, Oct 12, 2000 at 03:24:23PM -0700, Russ Allbery wrote:
> Can't. ISO C requires that all variadic functions take at least one named
> parameter. The best you can do is something like (void *, ...).
Argh. Can't we just use a stack? I like stacks. Stacks make sense.
--
..you could spend *
Dan Sugalski <[EMAIL PROTECTED]> writes:
> C's vararg handling sucks in many sublime and profound ways. It does,
> though, work. If we declare in advance that all C-visible perl functions
> have an official parameter list of (...), then we can make it work. The
> calling program would just fetch
At 08:57 PM 10/12/00 +0100, Simon Cozens wrote:
>On Thu, Oct 12, 2000 at 03:43:07PM -0400, Dan Sugalski wrote:
> > Doing this also means someone writing an app with an embedded perl
> > interpreter can call into perl code the same way as they call into any C
> > library.
>
>Of course, the problem
On Thu, Oct 12, 2000 at 03:43:07PM -0400, Dan Sugalski wrote:
> Doing this also means someone writing an app with an embedded perl
> interpreter can call into perl code the same way as they call into any C
> library.
Of course, the problem comes that we can't have anonymous functions in C.
That
At 07:48 PM 10/12/00 +, John van V wrote:
> * It also means we can write bits of perl in Perl, and similarly not
> have
>to care about this fact.
>
>Granted, some developers are thick as a brick...
>If you are writing perl in Perl, then, presumably, you would know this.
But pe
* It also means we can write bits of perl in Perl, and similarly not have
to care about this fact.
Granted, some developers are thick as a brick...
If you are writing perl in Perl, then, presumably, you would know this.
Excatly where is the added value, or is it purely for entertai
34 matches
Mail list logo
