On Wed, 12 May 2004, Larry Wall wrote:
In fact, I'd go so far as to say that it's almost impossible to do
recursive descent when you allow for defining new operator precedence
levels on the fly as Perl 6 does.
: Operator precedence can be done in
: a recdescent grammar straightforwardly
On Thu, May 13, 2004 at 10:26:32AM -0500, Abhijit A. Mahabal wrote:
:
: On Wed, 12 May 2004, Larry Wall wrote:
:
: In fact, I'd go so far as to say that it's almost impossible to do
: recursive descent when you allow for defining new operator precedence
: levels on the fly as Perl 6 does.
:
At 9:35 AM -0700 5/13/04, Larry Wall wrote:
On Thu, May 13, 2004 at 10:26:32AM -0500, Abhijit A. Mahabal wrote:
:
: On Wed, 12 May 2004, Larry Wall wrote:
:
: In fact, I'd go so far as to say that it's almost impossible to do
: recursive descent when you allow for defining new operator
On Wednesday 12 May 2004 22:16, Leopold Toetsch wrote:
We still need to consider what's an opcode and what not. We are going to
blow reasonable code size soon.
Yes. Thats why I've added them to experimental.ops and not to math.ops
I'll add a note that it contains ops for that no decision is made
Dan Sugalski wrote:
Okay, so I'm working on redoing the events document based on the
critiques from folks so far. (Which have been quite helpful) I should
have a second draft of the thing soon.
It does, though, sound like we might want an alternate name for this
stuff. While event is the right
I am finally going to teach myself C, so I should be
fairly quiet for a while (i.e. no more
incomprehensible ramblings of a mad man).
I did want to take this chance to explain some things
about where Cygwin is right now.
1. config/init/hints/cygwin.pl needs to have link =
'c++', added to it.
Dan Sugalski writes:
And personally I'd be happy to do violence to the dragon book. (Not
that it's *entirely* horrible, as I occasionally need to prop doors
open or shim a broken table leg temporarily...)
But, anyway, snipping out the rest of this stuff...
The big problem is that I
On Thu, 13 May 2004, Dan Sugalski wrote:
The big problem is that I don't know *how* to implement a mixed-type
parser generator. I'm not big on parsers in general, so I'm mostly
stuck with the literature if I need to write one from scratch.
I have been thinking the following about what larry
All~
I think Page already has a different meaning in computers, namely a page
of memory. This one might be going to far afield for names. For what it
is worth, I support event as the name.
Matt
James Mastros wrote:
Dan Sugalski wrote:
Okay, so I'm working on redoing the events document
Matt Fowles wrote:
I think Page already has a different meaning in computers,
namely a page of memory.
Not to mention a web page.
For what it is worth, I support event as the name.
Being as I think I'm largely responsible for the sense that the name
needs to be changed, I should point out
On Thu, May 13, 2004 at 01:01:12PM -0500, Abhijit A. Mahabal wrote:
: I have been thinking the following about what larry said earlier. Is this
: what you meant, larry?
:
: $grammar = q{
: class_defn: class block .. etc (normal top-down stuff)
: ...
: term: { call Parse::Yapp or
At 12:22 PM -0700 5/13/04, Larry Wall wrote:
I'd take the latter approach myself, since in any event it will
probably need tweaks that are foreign to whatever tool you choose.
In particular, the fact that Perl 6 uses string comparison rather than
numeric comparison to do precedence levels is going
On Thu, May 13, 2004 at 03:27:43PM -0400, Dan Sugalski wrote:
: I think the prudent thing to do there, since we're going to very
: rarely be adding new operators, is to assign the darned things real
: precedence numbers which get dynamically set. Add a new operator
: between two others and
On Thu, May 13, 2004 at 12:22:09PM -0700, Larry Wall wrote:
No, you still have the four basic actions. Subparsing is all hidden in
the lexer.
Hence why the lexer in Perl 5 is 8000 lines long ;-)
--
Wesley Crusher gets beaten up by his classmates for being a smarmy git,
and consequently has a
On Thu, May 13, 2004 at 09:41:54PM +0100, Dave Mitchell wrote:
: On Thu, May 13, 2004 at 12:22:09PM -0700, Larry Wall wrote:
: No, you still have the four basic actions. Subparsing is all hidden in
: the lexer.
:
: Hence why the lexer in Perl 5 is 8000 lines long ;-)
Well, actually, the lexer
On 12 May 2004, at 17:38, Brent 'Dax' Royal-Gordon wrote:
It's Parrot telling you that something happened.
Squawk?
Mike
On May 12, 2004, at 1:26 PM, Ron Blaschke wrote:
I have finally sorted out the details of the flags stuff, which I will
present below. Any comments are highly appreciated. Be warned: I am
going
to implements this if there are no objections. ;-)
- Targets shared and static are provided, to
Jeff Clites wrote:
Alternatively, we could just parse embed.h -- all and only symbols
defined there should be exported. (I believe that's the plan.)
Nope. Any symbol in a file included from embed.h and outside of an #if
defined(PARROT_IN_CORE) is fair game for embedders. See interpreter.h
for
On Thu, 13 May 2004, Jeff Clites wrote:
- When building / using a shared parrot the compiler macro
PARROT_LIB_DYNAMIC will be defined, for static PARROT_LIB_STATIC
What will these be used for? Traditionally, there aren't compile-time
difference when building a static v. dynamic library, I
At 5:47 PM -0700 5/13/04, Brent 'Dax' Royal-Gordon wrote:
Jeff Clites wrote:
Alternatively, we could just parse embed.h -- all and only symbols
defined there should be exported. (I believe that's the plan.)
Nope. Any symbol in a file included from embed.h and outside of an
#if
At 5:23 PM -0700 5/13/04, Jeff Clites wrote:
[Most commentary snipped, as it's dead-on]
- When building / using a shared parrot the compiler macro
PARROT_LIB_DYNAMIC will be defined, for static PARROT_LIB_STATIC
What will these be used for? Traditionally, there aren't
compile-time difference when
21 matches
Mail list logo
