Re: Apoc 5 questions/comments
On Sat, Jun 08, 2002 at 06:51:19AM +1000, Damian Conway wrote: > I have no doubt that, once Perl 6 is available, we'll see a rash of modules > released in the Grammar:: namespace. Including Grammar::HTML and Grammar::XML. I have no doubt that, once Perl 6 is available, we'll see a rash of modules released in the Grammar:: namespace. Including Grammar::Romana, Grammar::Klingon, Grammar::Buffy, Grammer::Mispelt, and others... :-) A
Re: [COMMIT] Subs and co-routines in Parrot
On Sat, Jun 08, 2002 at 03:35:39PM -0400, Melvin Smith wrote: > At 08:30 PM 6/8/2002 +0200, Jerome Vouillon wrote: > >Instead of using some space on the stack, co-routines can store all > >their local variables into their closure. Then, there is no need to > >swap in any context. > > We have to store the closure's variables somewhere, if not on a stack, > where? There are some pretty good slides on compiling functions at: http://pauillac.inria.fr/~xleroy/talks/compilation-agay.pdf >From a semantics point of view, a closure is a pair of a code pointer and an environment. The environment maps the variables defined outside the function (lexical scope) to their value. A closure is usually implemented as a flat record: the first member of the record is the code pointer, the remaining members contain the values of the external variables the function may need. When the body of a function is executed, some local variables may be needed. They are usually stored in registers and on the stack. The code pointer and environment remain unchanged from one function invocation to another. This is not the case with co-routines, where the code pointer is updated at each invocation and local variables need to preserved across co-routine invocation. So, my idea was to put the local variables in some additional entries of the closure instead of the stack. Of course, this does not work with real coroutines (i.e. cooperative threads). But you can implement Python-style coroutines (http://www.python.org/peps/pep-0255.html) this way. -- Jerome
Re: [COMMIT] Subs and co-routines in Parrot
On Sat, Jun 08, 2002 at 02:39:33PM -0400, Dan Sugalski wrote: > >Instead of using some space on the stack, co-routines can store all > >their local variables into their closure. Then, there is no need to > >swap in any context. > > You still need to store the stack frames created since the start of > the coroutine when picking up after the yield. Otherwise we're > declaring that coroutines can't use any stack at the point a yield is > called, which is a rather big thing to declare. Python-style co-routines have this very restriction. If we want real co-routines, we can build them on top of callcc, which will take care of storing the stack frames. -- Jerome
Re: Subs for parrot
On Sat, Jun 08, 2002 at 02:34:19PM -0400, Dan Sugalski wrote: > Indirect function calls will take maybe 50 cycles, so I'm not worried > about their time. Compared to perl 5, that's fast. With a JIT compiler, this starts to be significant, though. > >A continuation can be invoked just like any other function. The first > >opcode of its body can then switch the stack frames. (The register do > >not need to be switched if we specify that callcc does not preserve > >them.) > > The thing with continuations is that the code we're invoking won't > know its a continuation. That information's kept as metadata in the > sub PMC. Why? A continuation is captured by a "callcc" opcode. So, we can require this intruction to be always followed by a "execcc" intruction that perform the context switch. If the continuation is invoked, it will execute the "execc" intruction and switch to the right context. If "callcc" simply returns, it can just skip the "execcc" instruction. > (And we do need to restore the registers, otherwise we're > going to see a lot of stack pushing and popping every time we take a > continuation, and I don't know that it's worth it) I still don't understand this. "callcc" performs a function call, so why should it preserve registers? -- Jerome
Re: Apoc 5 questions/comments
> I have no doubt that, once Perl 6 is available, we'll see a rash of modules > released in the Grammar:: namespace. Including Grammar::Romana, > Grammar::Klingon, Grammar::Buffy, Grammer::Mispelt, and others... :-) Ah, Mr Wardley, I see you have finally apprehended the magnitude of my nefarious plan. Five years of plotting and scheming, of gaining influence and gradually insinuating my dastardly code creations into the community consciousness: all about to culminate in unleashing of Perl 6 on an unsuspecting populous. What a pity you shall not live to see it! Henchmen, throw him to the giant constrictive python! ;-) Damian
Re: [COMMIT] Subs and co-routines in Parrot
On Sat, Jun 08, 2002 at 03:54:06PM -0400, Melvin Smith wrote: > At 02:36 PM 6/8/2002 -0400, Dan Sugalski wrote: > >At 8:15 PM +0200 6/8/02, Jerome Vouillon wrote: > >>On Sat, Jun 08, 2002 at 12:30:36PM -0400, Melvin Smith wrote: > >>> The Java VM does this by popping values off of the local stack, and > >>> onto the callee's stack upon return. > >> > >>I think this is a design mistake of the Java VM. It would have been > >>more efficient to keep the local variables on the stack. Java separates each stack frame into a local variable array and a local stack (containing the intermediate values). During a method invocation, the method arguments are copied from the caller local stack to the callee local variable array. It would have been clearly more efficient, but slighly harder, to implement to access the argument directly from the caller frame. The Java bytecode interpreter is clearly not optimized for speed. David Gregg, Anton Ertl and Andreas Krall have experimented with an improved Java bytecode interpreter. One of the optimisations they perform is to get rid of this copying. Overall, they get a factor 5 to 10 improvement on some JavaSPEC benchmarks over other Java bytecode interpreters. (See "A fast Java interpreter" and "Implementing an efficient Java interpreter" from http://www.complang.tuwien.ac.at/papers/ By the way, Anton Ertl has written a lot of other very good papers on bytecode interpreters.) > >Yeah, that's too much work for me. I'd rather do something simpler, even > >if that boils down to "we return a single ParrotList with all the return > >values in it, stuck in P0". Yes, that would be fine. We can still optimize this later if necessary. The paper "An Efficient Implementation of Multiple Return Values in Scheme" by Ashley and Dybvig present a possible implementation. (http://citeseer.nj.nec.com/ashley94efficient.html) -- Jerome
RE: Apoc 5 questions/comments
> I have no doubt that, once Perl 6 is available, we'll see a > rash of modules released in the Grammar:: namespace. > Including Grammar::Romana, > Grammar::Klingon, Grammar::Buffy, Grammer::Mispelt, and others... :-) Grammar::Python, Grammar::Ruby, Grammar::PHP ? R.
Re: Apoc 5 questions/comments
Richard Nuttall wrote: > > > I have no doubt that, once Perl 6 is available, we'll see a > > rash of modules released in the Grammar:: namespace. > > Including Grammar::Romana, > > Grammar::Klingon, Grammar::Buffy, Grammer::Mispelt, and others... :-) > > Grammar::Python, Grammar::Ruby, Grammar::PHP ? I should imagine that the first two at least would be very likely, given that we wish both of those languages to run on top of Parrot. Damian
Re: [COMMIT] Subs and co-routines in Parrot
On Sat, Jun 08, 2002 at 02:29:53PM -0400, Dan Sugalski wrote: > There's more than just exception handlers going on the control stack. > Anything that needs rolling back or undoing (like localized variables > or scope entry) will have an undo marker put on the control stack > that gets called when we pop its entry off the control stack. It's an > easy way to remember overwritten values--you put an "overwritten" > entry on the control stack with the old value, and we restore it when > we pop the entry off the stack. With co-routines and callcc, function start and end are not always properly nested. For instance, you can start a co-routine, enter a function, run the co-routine until it ends and then exit the function. Or you can capture the current continuation inside a function and resume it until it exits the function, and then resume it again. So I don't think pushing undo markers on the control stack will work. Maybe we should implement something like Scheme's dynamic-wind. (See ftp.cs.indiana.edu/pub/scheme-repository/doc/standards/june-92-meeting.ps.gz and http://groups.google.com/groups?selm=izvhr5y4jy.fsf%40ux01.CS.Princeton.EDU for two differents implentations of dynamic-wind.) -- Jero;e
RE: Apoc 5 questions/comments
Damian Conway:
# Richard Nuttall wrote:
# >
# > > I have no doubt that, once Perl 6 is available, we'll see
# a rash of
# > > modules released in the Grammar:: namespace. Including
# > > Grammar::Romana, Grammar::Klingon, Grammar::Buffy,
# Grammer::Mispelt,
# > > and others... :-)
# >
# > Grammar::Python, Grammar::Ruby, Grammar::PHP ?
#
# I should imagine that the first two at least would be very
# likely, given that we wish both of those languages to run on
# top of Parrot.
I have to wonder how the Ruby and Python people will feel about
implementing their interpreters in Perl... ;^)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Early in the series, Patrick Stewart came up to us and asked how warp
drive worked. We explained some of the hypothetical principles . . .
"Nonsense," Patrick declared. "All you have to do is say, 'Engage.'"
--Star Trek: The Next Generation Technical Manual
[COMMIT] More function/data pointer games..
FYI. If anyone wants to provide a uintptr_t-equivalent for parrot, i'll happily switch this to use it. --Josh --- Forwarded Message Date:09 Jun 2002 16:44:35 - From:[EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: cvs commit: parrot/include/parrot parrot.h cvsuser 02/06/09 09:44:35 Modified:include/parrot parrot.h Log: Revisiting the problem we saw before, where tcc won't permit casting between function and data pointers. (this is technically undefined by ANSI C). However, it is possible to cast between them by first casting to an integer of sufficient size. Defined two macros for converting values betwen function and data pointers and inserted them in the right places. This gets things to build with tcc, and makes us more ANSI-correct. We might be able to remove the check for this in Configure.pl if everything uses these macros. (Though if JIT ever works on tcc, i will be impressed) Revision ChangesPath 1.38 +14 -1 parrot/include/parrot/parrot.h Index: parrot.h === RCS file: /cvs/public/parrot/include/parrot/parrot.h,v retrieving revision 1.37 retrieving revision 1.38 diff -u -w -r1.37 -r1.38 --- parrot.h 8 Jun 2002 21:53:20 - 1.37 +++ parrot.h 9 Jun 2002 16:44:35 - 1.38 @@ -1,7 +1,7 @@ /* parrot.h * Copyright: (When this is determined...it will go here) * CVS Info - * $Id: parrot.h,v 1.37 2002/06/08 21:53:20 grunblatt Exp $ + * $Id: parrot.h,v 1.38 2002/06/09 16:44:35 josh Exp $ * Overview: * General header file includes for the parrot interpreter * Data Structure and Algorithms: @@ -103,6 +103,19 @@ * function pointers and NULLfunc in place of NULL */ typedef void (*funcptr_t)(void); #define NULLfunc (funcptr_t)0 + +/* define macros for converting between data and function pointers. As it + * turns out, ANSI C does appear to permit you to do this conversion if you + * convert the value to an integer (well, a value type large enough to hold + * a pointer) in between. Believe it or not, this even works on TenDRA (tcc ). + * + * NOTE! UINTVAL is incorrect below. It should be UINTPTR or something lik e + * that. The equivalent of C99's uintptr_t- a non-pointer data type that can + * hold a pointer. + */ +#define D2FPTR(x) (funcptr_t)(UINTVAL) x +#define F2DPTR(x) (void*)(UINTVAL)(funcptr_t) x + /* Provide support for inline keyword where available. Just make sure to us e * "INLINE" instead and it will DTRT. */ --- End of Forwarded Message
A5: comment regexes please
like many of you i am fascinated by A5 but also my brain is overwhelmed
by it. i love that /x is the default but i would ask all of you to use
those comments liberally, even with trivial regexes while we all learn
this stuff. even simple ones are tricky looking if you don't grok the
syntax and semantics immediately and i doubt any but larry and damian
do. :)
here is a recent line from damian:
m/ if { /? ::: / and print $0.{comment} } /
i first kept thinking, where is 'if' defined in the regex syntax until
the light hit me and said, that was a literal token! i got the optional
rule but the ::: is not integrated yet. which form of
commit/backtracking was it? i have learned that $0 is the current regex
object so that last part is prints the comment. but this took a fair
amount of time to figure out as i am still learning this new line
noise. :)
so i would ask that even short perl6 regexes be written with comments
just for education and clarity. later on as it becomes real (code) and
we have a collective understanding and MRE edition 10 is out, we can
relax the comment rules :).
i would write that like (very anal i know):
m/
if # literal 'if'
{ # closure (perl code)
/# internal regex
? # optional comment rule
::: # don't backtrack past here ???
# followed by keyword rule
/# end of internal regex
and
print $0.{comment} # print comment from internal regex
} # end of closure
/
now, why does $0.{comment} refer to the internal regex and not the outer
one? is it because of it being in the closure? could you refer to the
outer one from the inner regex?
also since the comment is optional, if you found a keyword wouldn't that
try to print an undefined comment resulting in a warning?
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--- Boston Perl Classes July 1-3 http://stemsystems.com/class/
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
Re: cvs commit: parrot io.ops
At 04:34 PM 6/9/2002 +, [EMAIL PROTECTED] wrote: >cvsuser 02/06/09 09:34:43 > This needs rethinking. PIOHANDLE may not be an integer, so this > implementation is probably incorrect. For now, i'm just disabling it > unless > the UNIX io module is used, so that warnings aren't generated. fdopen should still work on stdio if on UNIX. We are saying give me an open "stream" on this descriptor, regardless of the stream implementation. I was wrong in my implemenation in assuming the opcode takes a "PIOHANDLE". I'll give it some more thought, possibly we need a union in the ParrotIO struct, and there are several places where we need to think about how we are passing addresses in Ix regs. I think the requirement must be that Ix regs are always big enough to hold pointers. -Melvin
Re: Apoc 5 questions/comments
At 10:21 PM 6/9/2002 +1000, Damian Conway wrote: >Richard Nuttall wrote: > > Grammar::Python, Grammar::Ruby, Grammar::PHP ? > >I should imagine that the first two at least would be very likely, given that >we wish both of those languages to run on top of Parrot. Given that by the time Parrot is beefy enough for people to start working on compilers for it (wait... it is already beefy enough!! ;)) I doubt you will see the real implementation of Python or Ruby done with Grammar:: as they will be racing the Perl guys to get there. And, since both of those languages are a heck of a lot simpler to write a compiler for, they will probably beat us there, not that this bothers me, it'll be good for everyone involved. Given that Python and Ruby have different semantics than Perl, there is more involved than just rejigging a grammar. You still have to get that parse tree down to some representation to hand to the backend compiler. I suppose that part means we have to expose the semantic rules somewhere for these module writers to access, or they have to emit straight Parrot instructions, which will spell y-u-c-k-y. I'm hoping we end up with an intermediate compiler that all the languages can target; one that is a step up from Parrot which will do optimization, reg allocation and a ton of other nasty stuff that language implementors will be happy to punt on. -Melvin
Re: [COMMIT] Subs and co-routines in Parrot
At 03:49 PM 6/9/2002 +0200, Jerome Vouillon wrote: Thanks for the links and references, Jerome. I'll have a go at digesting these. As soon as the new neural pathways have formed I'll try to comment on where I can see us improving our implementation. :) -Melvin
Re: [COMMIT] Subs and co-routines in Parrot
At 11:00 AM +0200 6/9/02, Jerome Vouillon wrote: >On Sat, Jun 08, 2002 at 02:39:33PM -0400, Dan Sugalski wrote: >> >Instead of using some space on the stack, co-routines can store all >> >their local variables into their closure. Then, there is no need to >> >swap in any context. >> >> You still need to store the stack frames created since the start of >> the coroutine when picking up after the yield. Otherwise we're >> declaring that coroutines can't use any stack at the point a yield is >> called, which is a rather big thing to declare. > >Python-style co-routines have this very restriction. If we want real >co-routines, we can build them on top of callcc, which will take care >of storing the stack frames. I'm not sure I want to go all the way to using continuations for coroutines. Seems a bit of overkill, especially on the return from the coroutine. Python-style restrictions are right out, of course--if we're going to do it, we might as well do it right as we don't have an existing implementation we're restricted by. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Apoc 5 questions/comments
In a message dated Sun, 9 Jun 2002, Damian Conway writes:
> Trey Harris wrote:
> > rule parsetag :w {
> > $tagname :=
> > %attrs := [ () =
> > ()
> > ]*
> >/?
> >
> > }
On second reading, it occurs to me that this wouldn't work quite right,
because the :w would imply a \s+ between and , between
the equals, and before the . Does an explicit space assertion in :w
automatically suppress the implicit ones on either side? I.e., would
rule parsetag :w {
\s* $tagname :=
%attrs := [ () = ]*
\s* /?
}
Work? Or would I have to be explicit about everything:
rule parsetag {
\s* $tagname := \s+
%attrs := [ () \s* = \s*
() \s* ]*
\s* /?
}
It strikes me that this is a problem crying out for a DWIMmy
solution--something that could deal with whitespace in a common way, i.e.,
required between tokens that can't otherwise be differentiated am I
missing something?
Trey
Re: Apoc 5 questions/comments
> >Ah, Mr Wardley, I see you have finally apprehended the magnitude of my >nefarious plan. Five years of plotting and scheming, of gaining influence and >gradually insinuating my dastardly code creations into the community >consciousness: all >about to culminate in unleashing of Perl 6 on an unsuspecting populous. What a >pity you shall not live to see it! Henchmen, throw him to the giant >constrictive python! > > Ahhh, duh . . . Docter Claw . . .er Conway, uh, the Python always throws up Perl Coders . . . Shoulds we maybe bash him with the Giant Shell, or TCL him to death . . . -Erik Is your boss reading your email? Probably Keep your messages private by using Lycos Mail. Sign up today at http://mail.lycos.com
Re: Apoc 5 questions/comments
On Sat, Jun 08, 2002 at 09:59:10AM -0700, Larry Wall wrote:
> On Fri, 7 Jun 2002, Peschko, Edward wrote:
> : Let me get this straight. the grammar of Perl is reprogrammable,
> : and expressed in perl6. And a script is parsed using this grammar,
> : on the fly, hence portions of scripts could have different grammars
> : than other parts.
>
> Where have you been for the last two years? This is not news.
ok, ok, s/Perl/regex/. I was always assuming the regular expression parser and
the perl parser would be different beasts. Guess not.
And anyways, its much more disconcerting when you actually *see* the grammar
being reparsable as opposed to hearing it in the abstract. I guess it just shows
how old school I am - I was sort of assuming a yacc/script distinction.
> No, the standard parser will be distributed as Parrot machine code.
> This is a conventional language bootstrap on an unconventional machine.
Ok, fair enough. The parrot bytecode compiler compiles the script using the
standard parser. Doing this, hooks inside the standard parser pick up any
'grammar' objects inside a given { . . . } block, and then re-interpret the
code inside the { . . . } block to be parsed in a different way.
My question(s):
The parsing of perl 6 is the application of a huge, compiled, regex, correct?
In order to parse the new syntax, perl6 is going to have to compile the
new rule, and stick it in the place of the old one, for the duration of the
scope, right?
Now what happens to the parser at large if you have dependencies on what has
changed - ex: if you change the rule for brackets, say so that all '[' are now
actually '[[' and all ']' are now ']]'. Won't the whole regex for parsing
perl need to be recompiled for the duration of the block, or at least the
dependencies on the things that you changed? And won't *that* be slow and/or
memory intensive?
And if the rules are somehow abstracted in the perl6 parser/parrot/regex engine
,so that each 'rule' is in essence a pointer to the real code corresponding to
interpreting that rule (so it can be replaced easily by user defined ones) -
well won't that abstraction hurt the performance of parsing regular perl?
And finally, if the regular expressions are in bytecode to get this flexibility
as opposed to native machine code, what sort of overhead will this impose on
the regex engine?
I know the above might be a bit simplistic, and since its an implementation
question I'm posting to perl6-internals instead, but the post is more for the
point of clarification about what's going on than anything else. I'd love to
see this happen, would use it all the time..
Ed
Re: Stack
This seems like a good time to send in this patch:
It allocates the stack content memory using a buffer. This makes the stack
chunks and the memory used to hold stack contents visible to the garbage
collector. One can incrementally add to this to support copy-on-write
semantics for the chunk contents, which I understand is going to be useful in
taking continuations. This could be done by making the stack chunks themselves
buffer headers or perhaps PMCs, which would be cool for introspection.
Index: debug.c
===
RCS file: /cvs/public/parrot/debug.c,v
retrieving revision 1.6
diff -u -p -r1.6 debug.c
--- debug.c 4 Jun 2002 14:44:52 - 1.6
+++ debug.c 6 Jun 2002 14:37:25 -
@@ -1204,7 +1204,7 @@ PDB_print_user_stack(struct Parrot_Inter
valid_chunk(chunk, command, depth, STACK_CHUNK_DEPTH, i);
-entry = &chunk->entry[depth];
+entry = (Stack_entry *)(chunk->buffer->bufstart) + depth;
switch (entry->entry_type) {
case STACK_ENTRY_INT:
Index: resources.c
===
RCS file: /cvs/public/parrot/resources.c,v
retrieving revision 1.61
diff -u -p -r1.61 resources.c
--- resources.c 4 Jun 2002 19:36:58 - 1.61
+++ resources.c 6 Jun 2002 14:37:27 -
@@ -302,6 +302,7 @@ trace_active_PMCs(struct Parrot_Interp *
unsigned int i, j, chunks_traced;
Stack_chunk *cur_stack, *start_stack;
struct PRegChunk *cur_chunk;
+Stack_entry *entry;
/* We have to start somewhere, and the global stash is a good
* place */
@@ -336,10 +337,15 @@ trace_active_PMCs(struct Parrot_Interp *
chunks_traced = 0;
/* The general stack's circular, so we need to be careful */
while (cur_stack && ((start_stack != cur_stack) || (chunks_traced == 0))) {
-for (i = 0; i < cur_stack->used; i++) {
-if (STACK_ENTRY_PMC == cur_stack->entry[i].entry_type &&
-cur_stack->entry[i].entry.pmc_val) {
-last = mark_used(cur_stack->entry[i].entry.pmc_val, last);
+if(cur_stack->buffer){
+buffer_lives(cur_stack->buffer);
+
+entry = (Stack_entry *)(cur_stack->buffer->bufstart);
+for (i = 0; i < cur_stack->used; i++) {
+if (STACK_ENTRY_PMC == entry[i].entry_type &&
+entry[i].entry.pmc_val) {
+last = mark_used(entry[i].entry.pmc_val, last);
+}
}
}
@@ -398,6 +404,7 @@ trace_active_buffers(struct Parrot_Inter
UINTVAL i, j, chunks_traced;
Stack_chunk *cur_stack, *start_stack;
struct SRegChunk *cur_chunk;
+Stack_entry *entry;
/* First mark the current set. We assume that all pointers in S
* registers are pointing to valid buffers. This is not a good
@@ -426,10 +433,14 @@ trace_active_buffers(struct Parrot_Inter
chunks_traced = 0;
/* The general stack's circular, so we need to be careful */
while (cur_stack && ((start_stack != cur_stack) || (chunks_traced == 0))) {
-for (i = 0; i < cur_stack->used; i++) {
-if (STACK_ENTRY_STRING == cur_stack->entry[i].entry_type &&
-cur_stack->entry[i].entry.string_val) {
-buffer_lives((Buffer *)cur_stack->entry[i].entry.string_val);
+if(cur_stack->buffer){
+buffer_lives(cur_stack->buffer);
+entry = (Stack_entry *)(cur_stack->buffer->bufstart);
+for (i = 0; i < cur_stack->used; i++) {
+if (STACK_ENTRY_STRING == entry[i].entry_type &&
+entry[i].entry.string_val) {
+buffer_lives((Buffer *)entry[i].entry.string_val);
+}
}
}
Index: stacks.c
===
RCS file: /cvs/public/parrot/stacks.c,v
retrieving revision 1.30
diff -u -p -r1.30 stacks.c
--- stacks.c17 May 2002 21:38:20 - 1.30
+++ stacks.c6 Jun 2002 14:37:27 -
@@ -21,15 +21,22 @@ new_stack(Interp *interpreter)
{
#ifdef TIDY
int i;
+Stack_entry *entry;
#endif
+
Stack_chunk *stack = mem_allocate_aligned(sizeof(Stack_chunk));
stack->used = 0;
stack->next = stack;
stack->prev = stack;
+stack->buffer = new_buffer_header(interpreter);
+Parrot_allocate(interpreter, stack->buffer,
+sizeof(Stack_entry) * STACK_CHUNK_DEPTH);
+
#ifdef TIDY
+entry = (Stack_entry *)stack->buffer->bufstart;
for (i = 0; i < STACK_CHUNK_DEPTH; i++)
-stack->entry[i].flags = NO_STACK_ENTRY_FLAGS;
+entry[i].flags = NO_STACK_ENTRY_FLAGS;
#endif
return stack;
}
@@ -56,7 +63,7 @@ Stack_entry *
stack_entry(Interp *interpreter, Stack_chunk *stack_base, Intval depth)
{
Stack_chunk *chunk;
-Stack_entry *entry = NULL;
+Stack_entry *entry;
size_t offset = (size_t)depth;
/* For nega
Re: A5: comment regexes please
Uri Guttman asked:
> now, why does $0.{comment} refer to the internal regex and not the outer
> one?
Technically, $0 refers to the *match object* of the inner regex, not the inner regex
itself.
> is it because of it being in the closure?
Yes. And because $0 is lexically scoped.
> could you refer to the outer one from the inner regex?
The outer what? Regex? Match object?
The answer to both is "yes". The (partial) match object of the outer regex becomes the
topic of the closure, so you refer to it as $_. To refer to the outer regex
you could either name it, and then refer to it by that name, or (possibly) there
will be a C<.self> method on the outer partial match object, so you could refer to the
outer regex as C<$_.self>.
>
> also since the comment is optional, if you found a keyword wouldn't that
> try to print an undefined comment resulting in a warning?
Yes. To avoid that, change:
/ ? /
to:
/ [|$comment:=()] /# $comment always a (possibly empty) string
or:
/ <0,1> / # $comment always an array ref
Damian
Re: Subs for parrot
At 11:26 AM +0200 6/9/02, Jerome Vouillon wrote: >On Sat, Jun 08, 2002 at 02:34:19PM -0400, Dan Sugalski wrote: > > Indirect function calls will take maybe 50 cycles, so I'm not worried > > about their time. Compared to perl 5, that's fast. > >With a JIT compiler, this starts to be significant, though. True, but that's less of a concern at the moment. As long as the semantics are sufficient without being wasteful, we can always trim the unnecessary stuff out later. > > >A continuation can be invoked just like any other function. The first > > >opcode of its body can then switch the stack frames. (The register do > > >not need to be switched if we specify that callcc does not preserve > > >them.) > > > > The thing with continuations is that the code we're invoking won't > > know its a continuation. That information's kept as metadata in the > > sub PMC. > >Why? A continuation is captured by a "callcc" opcode. So, we can >require this intruction to be always followed by a "execcc" intruction >that perform the context switch. If the continuation is invoked, it >will execute the "execc" intruction and switch to the right context. >If "callcc" simply returns, it can just skip the "execcc" instruction. callcc captures a current continuation and makes a sub call with it, true. We're not restricting continuation capture to being at sub call points, though. > > (And we do need to restore the registers, otherwise we're >> going to see a lot of stack pushing and popping every time we take a >> continuation, and I don't know that it's worth it) > >I still don't understand this. "callcc" performs a function call, so why >should it preserve registers? Who says we're only using callcc to capture continuations? We can do it anywhere, so we potentially need the registers stored so we can properly restore state when we're invoked. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Apoc 5 questions/comments
Trey Harris wrote:
> On second reading, it occurs to me that this wouldn't work quite right,
> because the :w would imply a \s+ between and , between
> the equals, and before the .
No. Under :w you get \s+ between literal sequences that are potential identifiers, and
\s* between anything else. So your:
> rule parsetag :w {
> $tagname :=
> %attrs := [ () =
> ()
> ]*
>/?
>
> }
is really:
rule parsetag :w {
\s* \s* $tagname :=
%attrs := [ \s* () \s* =
\s* ()
]*
\s* /?
\s*
}
Which matches valid tags (and some invalid ones too).
> Does an explicit space assertion in :w
> automatically suppress the implicit ones on either side?
Yes.
> I.e., would
>
> rule parsetag :w {
> \s* $tagname :=
> %attrs := [ () = ]*
>\s* /?
>
> }
>
> Work? Or would I have to be explicit about everything:
To get the (lack-of-)spacing rules you probably desire, you'd only have
to be explicit only where the default rules are inappropriate:
rule parsetag {
[$tagname:=] \s+
%attrs := [ ()=() ]*
/?
}
> It strikes me that this is a problem crying out for a DWIMmy
> solution--something that could deal with whitespace in a common way, i.e.,
> required between tokens that can't otherwise be differentiated am I
> missing something?
Yes. You're missing:
Another new modifier is :w, which causes an implicit match of
whitespace wherever there's literal whitespace in a pattern. In
--> other words, it replaces every sequence of actual whitespace in
--> the pattern with a \s+ (between two identifiers) or a \s*
--> (between anything else). So
m:w/ foo bar \: ( baz )*/
^
really means (expressed in Perl 5 form):
m:p5/\s*foo\s+bar\s*:(\s*baz\s*)*/
^^^
You can still control the handling of whitespace under :w,
since we extend the rule to say that any explicit
whitespace-matching token can't match whitespace implicitly on
either side. So:
m:w/ foo\ bar \h* \: (baz)*/
really means (expressed in Perl 5 form):
m:p5/\s*foo bar[\040\t\p{Zs}]*:\s*(baz)*/
Damian
Re: Apoc 5 questions/comments
Erik Steven Harrison henched: > Ahhh, duh . . . Docter Claw . . .er Conway, uh, the Python always throws up > Perl Coders . . . Shoulds we maybe bash him with the Giant Shell, or TCL him > to death . . . Dammit, you fools! Do I have to think of *everything*??? Just tie him to a steel bench and apply the Ruby laser! I do apologize, Mr Wardley. Good evil assistants are just impossible to get these days.
