Re: Lexicals, continuations, and register allocation

Leopold Toetsch wrote: +-+--+ | ctp | interpreter state| +-+--+ | ++ | +--+-+---+--+ | prev | ctx | lexicals | volatiles| +-

Re: [netlabs #801] [PATCH] PerlArray in scalar context

Brent Dax wrote: > Keep in mind how much it could inflate the bytecode if > we render a ton of generic, N-dimensional hyper-operator logic into > bytecode. The main problem I see is that you could spend minutes executing inside that hyper op. Doesn't that screw with the plan for putting the even

Re: On writing JITs

Jason Gloudon wrote: > http://www.ddj.com/ftp/2001/2001_07/aa0701.txt > > I believe the LOOKUP method was the fastest for me on SPARC, if I recall > correctly. Did they really spend 64K to create a lookup table just to find the most significant bit? Calculating log2 for a power of two is simpler

Re: abs_i_i but no abs_i

Nicholas Clark wrote: > But there do seem already to be arguably duplicate 2 operand versions of > many ops. Hence I was surprised at the lack of consistency. Right. I suspect that as people get more experience with the new Perl 6 compiler the 2 operand ops will go away (or vice versa). At the v

Re: On writing JITs

Nicholas Clark wrote: > It seems that foo & (foo - 1) is zero only for a power of 2 (or foo == 0) > but is there a fast way once you know that foo is a power of 2, to find out > log2 foo? You're right about (foo & (foo -1)). gcc uses a repeated test and shift. That's works very nicely if foo is

Re: abs_i_i but no abs_i

Nicholas Clark wrote: > I can write more a efficient implementation of abs_i ... things will > go slightly faster The law of diminishing returns is broken for a VM. Eventually you reach a point where adding more ops actually decreases total performance. Instead of the change in performance tendin

Re: sizeof(INTVAL), sizeof(void*), sizeof(opcode_t)

James Mastros wrote: > In byteswapping the bytecode ... > > I propose that we make INTVAL and opcode_t the same size, and gaurrenteed > to be able to hold a void*. It sounds like you want portable byte code. Is that a goal? It seems like we can have either mmap'able byte code or portable byte co

Re: What happened at little languages?

Simon Cozens wrote: > Us: We're working on this, that and the other. > Them: Pshaw. We solved those problems thirty years ago. Were Perl and Python both grouped into the same category of re-inventing the wheel? Or is this just the academic distaste for Perl syntax showing through? I had hoped tha

What happened at little languages?

Can't find any articles or notes on what happened at the conference. What happened? I'm really curious about the "Worse is Better" panel and the talk that Dan and Simon gave. - Ken

Re: Proper Tail Recursion

Shlomi Fish wrote: > Proper Tail Recursion is harder to debug, but consumes less memory and is > faster to execute ... It definitely consumes less memory, but performance is the same (until the memory issue starts dominating...) I don't know what you mean by debugging -- user code or parrot inter

better parrotguts drawing

I made a couple changes to the drawing. Stacks and register structures are now a bit more conceptual -- it is much easier to see how they work. See for the latest. Keep in mind that the light blue "frame" stuff at the bottom is experimental. Anybody inte

Re: Lexical implementation work

Dan Sugalski wrote: > Nope, not stone tablet at all. More a sketch than anything else, > since I'm not sure yet of all the things Larry's got in store. Ok. I've made some more progress. There's a crude picture of some of the internals at The lexical stuff

Re: memory assumptions

Michael L Maraist wrote: > Are we allowing _any_ dynamic memory to be non-GC-managed? Parrot must allow third party libraries to use the standard system malloc/free. Playing linker games to hide malloc/free gets *really* ugly. > Can we assume that a "buffer object" is ONLY accessible by a single

Re: Mixing lightweight refcount and full GC

Michael L Maraist wrote: > No barriers for us? Generational collectors require a write barrier because old objects must never point to younger ones. ('Course Dan said he's starting with a simple copying collector, so we don't need a barrier. Hmm. I guess Dan's not *reject*ing a barrier, just reje

Re: polymorphic inline caches

Simon Cozens wrote: > You save one level of indirection, at a large complexity > cost. A lot less complexity than a JIT though. 100% portable code too. It's also something that can be bolted on later, so there's no reason to reject it now. I'm just throwing it out to the list because I know othe

polymorphic inline caches

I few days ago I suggested inlining some PMC methods would be good for performance. It turns out that this question has been heavily studied by the OO community for at least 10 years. A common solution is to dynamically replace a method call with the body of the method wrapped in an if statement.

Re: preferences for data structure diagrams?

Robert Spier wrote: > On Sun, Nov 11, 2001 at 07:38:28PM -0500, Ken Fox wrote: > | ... Powerpoint would be a better choice since everybody > | has to deal with that format anyway. > > Please, no! Powerpoint is one of the few formats which > cannot be easily read on a non Win

Lexical implementation work

Simon just chastised me for talking instead of patching. Most of the stuff I'm interested in is heavily related to the implementation of lexicals, so that's where I'm going to jump in. There are a number of decisions to make about lexicals and the current PDD is pretty slim. So, IMHO, the place t

Re: Yet another switch/goto implementation

Dan Sugalski wrote: > Gack. Looks like a mis-placed optimization in perl 5. The list of a foreach > is *supposed* to flatten at loop start and be static. Apparently not. :) Is anybody keeping a list of things that are *supposed* to be static? Is the list changing much with Perl 6? > Care to fil

Re: JIT compilation

Dan Sugalski wrote: > [native code regexps] There's a hugely good case for JITting. Yes, for JITing the regexp engine. That looks like a much easier problem to solve than JITing all of Parrot. > If you think about it, the interpreter loop is essentially: > >while (code) { > code = (fun

Instruction timings for Intel/AMD chips?

After downloading a dozen PDF files I've given up. All I need is the approximate cycle counts for instructions and address modes. The particular problem I've got now is deciding which of these three is the fastest: movl (%edi,%eax,4),%eax movl (%edi,%eax),%eax movl (%edi),%eax Same wit

Re: vmem memory manager

Michael L Maraist wrote: [an incredible amount of detailed information that will take me weeks to digest...] This looks like a malloc/free style allocator. Since the whole GC system for Parrot is on the table, you don't have to constrain yourself to malloc/free. IMHO free is not needed at all --

Re: Improved storage-to-storage architecture performance

Michael L Maraist wrote: > The only "memory" storage for scalars that I currently am conceiving of is > in name-space stashes (globals). Thus our most likely implementation of S2S > would be to have 'add "g_x", "g_y", "g_z"' which performs two stash > lookups, an add, then one stash write. Kakap

Re: Improved storage-to-storage architecture performance

ad things into registers, right? If the register allocation is good it will be fast. Poor register allocation will waste time with redundant loads, excessive register spills, etc. > Ken Fox wrote: > > What happens when you "goto middle" depends on where you started. > > Pe

Re: java vs. parrot mops

Kevin Huber wrote: > This is a comparison of mops running on Parrot (-O6 on an Athlon 700) > versus Java JDK 1.4.0 beta 2 jitted and interpreted. You can see that > Parrot performance is very comparable to Java in interpreted mode. I have an Athlon 700 too. With these compiler flags: PERL-CFLAG

Re: Improved storage-to-storage architecture performance

Uri Guttman wrote: > that is good. i wasn't disagreeing with your alternative architecture. > i was just making sure that the priority was execution over compilation > speed. I use a snazzy quintuple-pass object-oriented assembler written in equal parts spit and string (with a little RecDescent t

Re: Improved storage-to-storage architecture performance

Uri Guttman wrote: > so my point is the the speed of the VM is a separate issue from the ease > of code generation. an S2S VM would be easier to code generate for but > may be slower to run. the speed difference is still an open point as dan > has said. but since his goal is execution speed, that

Re: Improved storage-to-storage architecture performance

Uri Guttman wrote: > and please don't bring in hardware comparisons again. a VM design > cannot be compared in any way to a hardware design. I have absolutely no idea what you are talking about. I didn't say a single thing about hardware. My entire post was simply about an alternative VM architec

Re: Improved storage-to-storage architecture performance

rame[pc[3].word.hi] + pc[3].word.lo); pc += 4; goto *(pc->i_addr); I haven't counted derefs, but Parrot and Kakapo should be close. On architectures with very slow word instructions, some code bloat to store hi/lo offsets in native ints might be worth faster address calculations.

Improved storage-to-storage architecture performance

A little while back I posted some code that implemented a storage-to-storage architecture. It was slow, but I tossed that off as an implementation detail. Really. It was. :) Well, I've tuned things up a bit. It's now hitting 56 mops with the mops.pasm example. Parrot turns in 24 mops on the same

Anybody write a threaded dispatcher yet?

Anybody do a gcc-specific "goto *pc" dispatcher for Parrot yet? On some architectures it really cooks. - Ken

Interesting experiment with lexical scoped VM

A while back I wondered if a higher-level VM might be useful for implementing higher-level languages. I proposed a lexically scoped machine without registers or stacks. The response wasn't encouraging. A quick tour through the library turned up a few machine designs that sounded very similar to w

Re: Thoughts on a higher-level VM

David M. Lloyd wrote: > Take it from me (the one with several abortive attempts at getting an > extra compare stuck in Perl 5's dispatch loop): You don't want to stick > another compare in there. It *kills* performance. Kills? I thought the event flag test dropped performance by a few percent.

Thoughts on a higher-level VM

I've been thinking about the possibility of building a higher-level VM. The current VM is very close to a traditional CPU. What if we did something non-traditional that made implementing higher-level lexically scoped languages easier? What if the VM (and assembler) had lexical scoping built-in at

Thoughts on a higher-level VM

[Sorry if this is a duplicate. I sent the original from work. Is there a spam filter removing messages from non-subscribers?] I've been thinking about the possibility of building a higher-level VM. The current VM is very close to a traditional CPU. What if we did something non-traditional that m

Re: String API

Dan Sugalski wrote: > If you're speaking of multiple buffers for a string or something like that, > you're looking at too low a level. That's something that should go in the > variables, not in the string bits. (We do *not* want all string ops slow to > support flexibility of this sort. Only the b

Re: PDD 6: Parrot Assembly Language

"Bryan C. Warnock" wrote: > On Monday 10 September 2001 09:30 pm, Dan Sugalski wrote: > > gotos into scopes might not be allowed. > > That's how it currently is for most scopes, and it certainly saves a > whole lot of trouble and inconsistencies. I'm not sure I understand what you mean. Perl 5 a

Re: String API

Simon Cozens wrote: > On Mon, Sep 10, 2001 at 08:38:43PM -0400, Ken Fox wrote: > > Have you guys seen Topaz? > > I may have heard of it, yes. That's it? You're rejecting all of that work without learning anything from it? Building strings on buffers looked like a really

Re: PDD 6: Parrot Assembly Language

Dan Sugalski wrote: >jump FOO > > doesn't change scope. > >newscope scope_template_in_fixup_section > > does. And > >exitscope > > leaves one. :) Ok. That clears it up a little. The current scope is part of the VM internal state and compilers need to generate state change instruc

Re: Parrot 0.0.1 is released.

Jeffrey Coleman Carlyle wrote: > Am I missing something (well, clearly I am), but are test.pasm and > test2.pasm missing from the CVS repository? Look in ./t - Ken

Re: PDD 6: Parrot Assembly Language

Dan Sugalski wrote: > At 05:41 PM 9/10/2001 -0400, Ken Fox wrote: > > You're expecting the current lexical scope to be carried implicitly > > via the PC? > > No, it'll be in the interpreter struct. But how does the interpreter know where a lexical scope begin

Re: Patch to assembler/disassembler + parrot asm inconsistancies

"Bryan C. Warnock" wrote: > On Monday 10 September 2001 06:23 pm, Dan Sugalski wrote: > > When we run out, we repeat the innermost type. > > Why are you doing right-to-left instead of left-to-right? Because it would be harder to repeat the innermost type then? ;) Most binary ops will take identi

Re: String API

Simon Cozens wrote: > =head1 The Parrot String API Have you guys seen Topaz? One of many things I think Chip did right was to build strings from a low-level buffer concept. This moves memory management (and possibly raw-io) out of the string class and into the buffer class. The other major sugge

PMC vtable vs other overloading techniques

Simon Cozens wrote: > FWIW, it's just dawned on me that if we want all of these things to be > overloadable by PMCs, they need to have vtable entries. The PMC vtable > is going to be considerably bigger than we anticipated. Surely you don't expect the PMC vtable to be the only mechanism for overl

Re: PDD 6: Parrot Assembly Language

Dan Sugalski wrote: > =item if tx, X, Y What's the purpose of providing Y? Does it make anything easier allowing Y != 0? > =item jump tx I expected a "call" op too. Not a named sub call, but just "call tx" where tx has the same semantics as in "jump". A "return" op is needed too. > =item iton

Re: pads and lexicals

Dan Sugalski wrote: > > Dan Sugalski <[EMAIL PROTECTED]> wrote: > > > Where do they come from? Leave a plate of milk and cookies on your back > > > porch and the Temp PMC Gnomes will bring them. :) > Bad Dan! No cookie for me. You aren't fooling anybody anymore... You might just as well stop the

Re: An overview of the Parrot interpreter

Paolo Molaro wrote: > If anyone has any > evidence that coding a stack-based virtual machine or a register one > provides for better instructions scheduling in the dispatch code, > please step forward. I think we're going to have some evidence in a few weeks. I'm not sure which side the evidence

Re: An overview of the Parrot interpreter

Simon Cozens wrote: > I want to get on with writing all the other documents like this one, but > I don't want the questions raised in this thread to go undocumented and > unanswered. I would *love* it if someone could volunteer to send me a patch > to the original document tightening it up in the

Re: pads and lexicals

Dave Mitchell wrote: > So how does that all work then? What does the parrot assembler for > > foo($x+1, $x+2, , $x+65) The arg list will be on the stack. Parrot just allocates new PMCs and pushes the PMC on the stack. I assume it will look something like new_pmc pmc_register[0] a

Re: pads and lexicals

Dave Mitchell wrote: > The Perl equivalent $a = $a + $a*$b requires a > temporary PMC to store the intermediate result ($a*$b). I'm asking > where this tmp PMC comes from. The PMC will stashed in a register. The PMC's value will be stored either on the heap or in a special memory pool reserved fo

Re: Should MY:: be a real symbol table?

Bart Lateur wrote: > On Mon, 03 Sep 2001 19:29:09 -0400, Ken Fox wrote: > > The concept isn't the same. "local" variables are globals. > > This is nonsense. > ... > How are globals conceptually different than, say, globally scoped > lexicals? Your descri

Re: pads and lexicals

Dave Mitchell wrote: > Hmmm, except that at the hardware level, registers can store the actual > temporary values themselves register struct value *hardware_registers_can_be_pointers_too; The PMC registers act like pointer-to-struct registers. Other register sets can hold immediate values. This

Re: Should MY:: be a real symbol table?

Dan Sugalski wrote: > Good. It should. It's a scary feature, and hopefully that same fear will > strike anyone else who uses it But all it takes is one fool^Wbrave person to mess up somebody else's perfectly working code. Basically I think this throws us back to the bad old days when we only had

Re: Should MY:: be a real symbol table?

Dan Sugalski wrote: > Oh, it gets better. Imagine injecting a lexically scoped sub into the > caller's lexical scope. Overriding one that's already there. (Either > because it was global, or because it was lexically defined at the same or > higher level) > > Needless to say, this makes the optimi

Re: Should MY:: be a real symbol table?

"Bryan C. Warnock" wrote: > Except that Perl 6 will have the ability to inject lexical variables in its > scope, and in any dynamic parent's scope. (It isn't clear whether that is > write-only access or not - which it probably should be for lexicals.) > > That, invariably, forces at least some r

Re: Should MY:: be a real symbol table?

Dan Sugalski wrote: > First, of course, runtime and compiletime are mixed on perl. String eval > has to go walk back up the pads *at runtime* and resolve the variable names. Sure, if you use eval, the symbol table for the current scope needs to be available. There's no reason to have more than on

Re: Should MY:: be a real symbol table?

Dan Sugalski wrote: > At 05:44 PM 9/3/2001 -0400, Ken Fox wrote: > > Lexicals are fundamentally different from Perl's package (dynamically > > scoped) variables. > > No, actually, they're not. How can you possibly think that lexical scoping and dynamic scoping

Re: Should MY:: be a real symbol table?

Brent Dax wrote: > Ken Fox: > # Lexicals are fundamentally different from Perl's package (dynamically > # scoped) variables. > > *How* are they "fundamentally different"? Perl's "local" variables are dynamically scoped. This means that they are *

Re: An overview of the Parrot interpreter

Thanks for the info. If you guys maintain this level of documentation as the code develops, Perl 6 will be easy for first-timers to work on. One goal down, N-1 to go... ;) Simon Cozens wrote: > To be more specific about the software CPU, it will contain a large > number of registers. The registe

Re: An overview of the Parrot interpreter

Dan Sugalski wrote: > For those of you worrying that parrot will be *just* low-level ops, > don't. There will be medium and high level ops in the set as well. I was going to cite , but you guys have already read that, eh? ;) One thing I was expec

Re: Should MY:: be a real symbol table?

Brent Dax wrote: > What I'm suggesting is that, instead of the padlist's AV containing > arrays, it should contain stashes, otherwise indistinguishable from > the ones used for global variables. Lexicals are fundamentally different from Perl's package (dynamically scoped) variables. Even if you c

Re: Should MY:: be a real symbol table?

Brent Dax wrote: > Perl, however, is such a dynamic language you can't do a lot of that > resolution at compile-time. What happens when I say: > $x="foo"; > $::{"x"}=\"bar"; > print $x; Just so we're clear, $x is a global variable -- there's only one $x and it never goes

Re: Deoptimizations

"Bryan C. Warnock" wrote: > No. We're optimizing on what we know at the time. Um, it looked like you were generating a graph with all possible optimizations inserted. At what point do you commit to an optimization? If you only commit at run-time, you need to do a *lot* of state management. It se

Re: Deoptimizations

Wizard wrote: > Johan Vromans wrote: > > 'use constant FOO => "foo"' could add some magic to never let FOO > > being redefined (not a bad coice for a constant). > > I like this idea best (for now). Perhaps 'constant sub foo' or 'sub > foo:constant'? I wouldn't consider this an optimization. Perl

Re: Should MY:: be a real symbol table?

Brent Dax wrote: > Is there any real reason my() variables are stored in a pad instead > of a symbol table? Simon already told you why a pad is used. But I think you misunderstand what a symbol table is. Variables aren't *stored* in the symbol table. Only the definitions and storage locations of

Re: Something to hash out

Dan wrote: > I like it. It's a race between those and Randal's .par and .rot (for the > bytecode) extensions. Please say the file extensions are only needed to prevent a clash of the source file and bytecode if they're stored in the same directory... We can say "parrot foo.whatever" and parrot w

Re: PDD for the debugger API

Uri Guttman <[EMAIL PROTECTED]> wrote: > > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: > DS> At 03:22 PM 8/18/2001 -0400, Uri Guttman wrote: > >> i didn't see any references to support debugging an external perl > >> process. ... > > DS> Good point. ... listen on some port/pipe/do

Re: Garbage collection (was Re: JWZ on s/Java/Perl/)

Hong Zhang wrote: > The memory barriers are always needed on SMP, whatever algorithm > we are using. I was just pointing out that barriers are an alternative to mutexes. Ref count certainly would use mutexes instead of barriers. > The memory barrier can be easily coded in assembly, or intrinsic

Re: PDD 2: sample add()

David Mitchell wrote: > To get my head round PDD 2, I've just written the the outline > for the body of the add() method for a hypophetical integer PMC class: [... lots of complex code ...] I think this example is a good reason to consider only having one argument math ops. Instead of dst->add(a

Re: Please shoot down this GC idea...

Damien Neil wrote: DN> { DN>my $fh = IO::File->new("file"); DN>do_stuff($fh); DN> } DN> DN> sub do_stuff { ... } Simon Cozens wrote: SC> No, it can't, but it can certainly put a *test* for not having SC> references there. Dan Sugalski wrote: DS> Yes it can tell, actually--we do have the

Re: Garbage collection (was Re: JWZ on s/Java/Perl/)

Alan Burlison wrote: > I think you'll find that both GC *and* reference counting scheme will > require the heay use of mutexes in a MT program. There are several concurrent GC algorithms that don't use mutexes -- but they usually depend on read or write barriers which may be really hard for us to

Re: Thought for the day

I like Linus' quote, but that spirit would probably push Perl too far into the computer scientists' language traps. Here's a Frank Lloyd Wright quote I think works a bit better: Five lines where three are enough is stupidity. Nine pounds where three are sufficient is stupidity. But to elimi

Re: Guidelines for internals proposals and documentation

I agree with Dan's proposals for PDDs. In particular I like the idea of the WG chairs having decision power -- it should protect us somewhat from design-by-committee syndrome. However, I don't want to see early (premature) adoption of fundamental pieces like the VM or parser. It makes sense to me

Re: Elk - another paragon for us

I used the Elk 2.x series extensively in several engineering applications I wrote for Ford Motor. It was a nice system in general, but perl's XS (and guts documentation) was much better than Elk's. One of the biggest problems with Elk is that it has a scanning garbage collector, not a ref count co

Re: Design

John van V wrote: > I have been predicting for a year now that perl6 will spawn another > language which will be a marriage of perl/python/scheme/sh, hopefully > enabling a billion or so humans in defiance of AOL and Microsoft. Wow! You're good! Most people were caught by surprise with the Perl

Re: virtual machine implementation options

Steve Fink wrote: > and I get the same numbers for -O (I used -O3) but different numbers > without optimization. Maybe we should assume optimization? The difference was probably -fomit-frame-pointer that I used in both the -g and -O cases. Some of my code was fragile to optimization so I wanted t

Re: virtual machine implementation options

Jarkko Hietaniemi wrote: > FWIW, I would like to see results for these little tests also for > other platforms than just gcc on Intel (on Linux...) :-) I tried > quickly hacking the test script and C source to be more portable > but it took me more than a few minutes so I gave up... I just tried

Re: Design

Nathan Torkington wrote: > Robustness > Portability > Maintainability > Testability > Reusability > Speed > Simplicity > Size Hey, whoa. Aren't we pre-maturely optimizing the development process? IMHO we're still in the day dreaming "what if" mode of development. (We don't even ha

Re: virtual machine implementation options

Anybody have ideas for making this *fast*? - Ken P.S. Sorry for that inane add.dat file I posted. I should have posted the 10 line script that generated it. Anyways, nobody chewed me out for posting MIME attachments so I guess I'll keep doing it... /* This code is in the public domain. Ken

virtual machine implementation options

0 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 1 10 2 /* This code is in the

Re: Threaded Perl bytecode (was: Re: stackless python)

Chaim Frenkel wrote: > We may not even need to copy the body. The nice thing about the "copy body and replace with stub" solution is that it doesn't impose any costs on threaded subs that don't get re-bound at run-time. I agree with you that there are lots of solutions though so re-binding should

Re: Threaded Perl bytecode (was: Re: stackless python)

Adam Turoff wrote: > when dealing with threaded bytecode is that the threading specifically > eliminates the indirection in the name of speed. Yes. Chaim was saying that for the functions that need indirection, they could use stubs. You don't need to guess in advance which ones need indirection b

Re: Special syntax for numeric constants [Was: A tentative list of vtable functions]

David Mitchell wrote: > Well, I was assuming that there would be *a* numeric class in scope > - as defined be the innermost lexical 'use foo'. And that numeric class would remove int and num from the scope? > I assumed that Perl wouldn't be clever enough to know about all available > numberic ty

Re: Special syntax for numeric constants [Was: A tentativelist of vtable functions]

Dan Sugalski wrote: > Numeric constants will probably fall into two classes--those perl's parser > knows about and can convert to, and those it doesn't and just treats as > strings. I'm really excited to see what magic Larry is going to cook up for extending the lexer and parser. His talk made it

Re: stackless python

Joshua N Pritikin wrote: > http://www.oreillynet.com/pub/a/python/2000/10/04/stackless-intro.html That talks about moving from the C stack to a frame stack, continuations, co-routines and microthreads. None of it made much sense. (Choosing continuations as the basis of the system would be very Sc

Semantic analysis [Was: compile-time taint checking and the halting problem]

"David L. Nicol" wrote: > So what would be involved in adding hooks for arbitrary semantic analysis? At the most fundamental level all you need is a parse tree with attributes that you can write constraints against. IMHO there isn't much difference in technique between "semantic analysis" and "op

Special syntax for numeric constants [Was: A tentative list of vtable functions]

David Mitchell wrote: > Now of course if we have the luxury of deciding that core perl 'knows' > about complex numbers, then of the parser can be made to recognise ... The core doesn't need to know -- that was my point. All the core needs is the basic constant folding rules _it_already_has_ comb

Re: A tentative list of vtable functions

David Mitchell wrote: > Jarkko Hietaniemi wrote: > > Assume I want > > > > $a = 2 + 3i; > > > > to work... > > Which I what I suggest we abandon attempts to make the parser do intellignet > decisons on numeric liternal, and instead just grab all the characters > that appear to make up thye

Re: A tentative list of vtable functions

"ye, wei" wrote: > One C++ problem I just found out is memory management. It seems > that it's impossible to 'new' an object from an specified memory block. > So it's impossible to put free'd objects in memory pool and re-allocate > them next time. Stuff like that isn't the problem with using C+

Re: Perl's parser and lexer will likely be in Perl (was Re: RFC 334 (v1) I'm {STILL} trying to understand this...)

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

Re: Perl's parser and lexer will likely be in Perl (was Re: RFC 334 (v1) I'm {STILL} trying to understand this...)

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

Re: RFC 326 (v1) Symbols, symbols everywhere

Dave Storrs wrote: > It isn't terribly clear to me either Well, he does give a couple references that would clear it up. X11 Atoms are well documented. > saying is that you can qs() a method name, get a "thingie" out, store the > thingine in a scalar, and then that scalar becomes a direct portal

Re: Perl Implementation Language

Simon Cozens wrote: > On Tue, Sep 12, 2000 at 03:17:47PM -0400, Ken Fox wrote: > > That's fine for the VM and the support libraries, but I'd *really* like > > to see the parser/front-end in Perl. There are dozens of RFCs that require > > some non-trivial extensions

Re: A tentative list of vtable functions

Nick Ing-Simmons wrote: > Ken Fox <[EMAIL PROTECTED]> writes: > >Dan Sugalski wrote: > >> For something like: > >> > >>@foo = @bar || @baz; > >> > >> I have no problem with the call sequence looking like (pseudo-codish here): >

Re: New Perl rewrite - embedded Perl

"ye, wei" wrote: > Tom Christiansen wrote: > > It [miniperl] isn't substantially smaller, so that does you no good. The socket library seems to be the poster child for what to leave out, but that's a weak argument. If Perl 6 gets all the functionality requested by Damian or the PDL folks, it woul

Re: Perl Implementation Language

Dan Sugalski wrote: > As for the language we implement perl in (and thus ultimately need to > translate to the compiler-target language), I'm thinking of something like > Chip's PIL. That's fine for the VM and the support libraries, but I'd *really* like to see the parser/front-end in Perl. There

Re: A tentative list of vtable functions

Dan Sugalski wrote: > For something like: > >@foo = @bar || @baz; > > I have no problem with the call sequence looking like (pseudo-codish here): > > set_context(ARRAY, ASSIGN); > foo->store(bar->log_or(bar, baz)); But log_or must short circuit -- I think we have to preserve that b

Re: A tentative list of vtable functions

Dan Sugalski wrote: > At 05:30 PM 8/31/00 -0400, Ken Fox wrote: > > before_get_value > > after_get_value > > before_set_value > > after_set_value > > > >There ought to be specializations of get_value and set_value > >that call these hooks

Re: the C JIT

"David L. Nicol" wrote: > No, I'm not, it's the direction that RFC 61 ends up if you let it > take you there. You seem to be confusing: (1) linking C code with Perl with (2) compiling Perl to C code There is a world of difference. Swig does (1) pretty well already. If you want a first c

Re: A tentative list of vtable functions

Dan Sugalski wrote: > get_value > set_value Wouldn't these go on the SV and not on the inner type? Maybe I'm thinking value when you're saying variable? The following seem useful on variables too: before_get_value after_get_value before_set_value after_set_value There ought to b

  1   2   >