Re: RFC 124 usefulness & implementation suggestion

Bart Lateur wrote: > But isn't there going to be a large overhead, in populating such a > "hash"? If you need an ordered data structure the overhead would be lower than using a hash. > Doesn't the tree have to be reorganized every time you add a > single new entry? No. Sometimes you may have to

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

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

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: 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

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: 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

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: 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: 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: safe signals + sub-second alarms [was: sleep(0.5) should DWIM]

Bart Lateur wrote: > What if we take the ordinary sleep() for the largest part of the > sleeping time (no busy wait), and the 4 argument select for the > remainder, i.e. subsecond? You're trying to solve a problem that doesn't exist. Sleep doesn't have the signal delivery problems that alarm has

safe signals + sub-second alarms [was: sleep(0.5) should DWIM]

Branden wrote: > Actually, with event loops and threading issues, probably things like > the perl built-ins sleep and alarm won't ever be passed to the syscalls > sleep(3) and alarm(3). Sleep isn't usually a syscall -- it's often a library routine that sets an alarm and blocks or uses some other

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: Really auto autoloaded modules

Dan Sugalski wrote: > At 02:04 PM 2/1/2001 -0500, Ken Fox wrote: > >Isn't the trick to detect the necessary modules at compile time? > > Nope, no trick at all. The parser will have a list of functions--if it sees > function X, it loads in module Y. (Possibly version Z) N

Re: Really auto autoloaded modules

Dan Sugalski wrote: > At 12:33 PM 2/1/2001 -0500, Michael G Schwern wrote: > > Have a look at AnyLoader in CPAN. > > Looks pretty close to what's needed. Care to flesh it out (and streamline > it where needed) to a PDD? Isn't the trick to detect the necessary modules at compile time? Run-time ca

Re: Why shouldn't sleep(0.5) DWIM?

Dan Sugalski wrote: > At 11:57 PM 1/31/2001 +0100, [EMAIL PROTECTED] wrote: > > On Wed, Jan 31, 2001 at 05:35:03PM -0500, Michael G Schwern wrote: > > > grossly UNIX specific things like getpwnam's [can be pulled] > > > > But why? What is it going to buy you? > > Not that much. More than anything

Re: JWZ on s/Java/Perl/

Branden wrote: > I actually don't understand how traversing a graph can be faster than > incrementing/decrementing/testing for zero on a refcount. There are two main reasons advanced garbage collectors are fast: 1. Cheap allocations. Most fast collectors have a one or two instruction malloc

Re: JWZ on s/Java/Perl/

Branden wrote: > Ken Fox wrote: > > Some researchers have estimated that 90% or > > more of all allocated data dies (becomes unreachable) before the > > next collection. A ref count system has to work on every object, > > but smarter collectors only work on 10% of the

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

Dan Sugalski wrote: > At 04:09 PM 2/9/2001 -0200, Branden wrote: > > If I change the way some objects are used so > > that I tend to create other objects instead of reusing the old ones, I'm > > actually not degrading GC performance, since its work is proportional to > > live data. Right? > > Cor

Re: more POST recitation

"David L. Nicol" wrote: > # with POST > sub find_first_line_matching_array($\@){ > open F, shift or die "could not open: $!"; > POST{close F}; > while(){ > foreach $w (@{$_[0]}){ >

Re: JWZ on s/Java/Perl/

Bart Lateur wrote: > On Fri, 09 Feb 2001 12:06:12 -0500, Ken Fox wrote: > > 1. Cheap allocations. Most fast collectors have a one or two > >instruction malloc. In C it looks like this: > > > > void *malloc(size) { void *obj = heap; heap += size; return obj; }

Re: JWZ on s/Java/Perl/

[Please be careful with attributions -- I didn't write any of the quoted material...] Russ Allbery wrote: > >> sub test { > >> my($foo, $bar, %baz); > >> ... > >> return \%baz; > >> } > That's a pretty fundamental aspect of the Perl language; I use that sort

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: 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: 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: 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 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: explicitly declare closures???

Dave Mitchell <[EMAIL PROTECTED]> wrote: > John Porter <[EMAIL PROTECTED]> wrote: > > Dave Mitchell wrote: > > > I think closures are a lot harder (or at least subtler) than > > > people think ... > > > > ... The scenario you gave seems rather far-fetched to me, in terms > > of real-world program

Re: Semi-OT: Good compiler book?

Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 04:38 PM 8/8/2001 +, Brian J. Kifiak wrote: > > > Unfortunately all the references I have for alternatives really > > > require what the Dragon Book teaches as a foundation. > > > > What are the references? > > ... Advanced Compiler Design & Implem

Re: Expunge implicit @_ passing

Michael G Schwern wrote: > I can't think of any reason why this feature is useful anymore, and it > can be a really confusing behavior, so what say we kill it in Perl 6? I've always thought is was pretty useful for implementing generic redirectors. I wrote a frame system that allows instances to

Re: Expunge implicit @_ passing

Michael G Schwern wrote: > Any time you want to implicitly pass @_, you can just as easily > *explicitly* pass it or use goto. I never thought of using goto actually. "goto &$method;" actually looks clearer than the code I'm using. (Although with re-directors we want to minimize cost so the 10% p

Re: explicitly declare closures???

Dave Mitchell wrote: > The whole point is that closed variables *aren't* 'just local variables'. > The inner $x's in the following 2 lines are vastly different: > > sub foo { my $x= ... { $x } } > sub foo { my $x= ... sub { $x } } You really need to learn what a closure is. There's a

Re: Expunge implicit @_ passing

Michael G Schwern wrote: > If you *really* wanted to write an optimized redirector, you'd > have the redirector eliminate itself. That's not always appropriate. In my frame system, an instance can over-ride its class method. An instance can also remove the over-ride and return to using the class

Re: explicitly declare closures???

Garrett Goebel wrote: > From: Dave Mitchell [mailto:[EMAIL PROTECTED]] > > Okay, to humour me for a mo', what should the following 2 examples > > output if Perl were doing the "right" thing? > > > > sub pr { print $_[0] || 'undef', "\n" } > > > > { my $x = 'X'; sub f { $F = sub {pr $x} }} > > f();

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: Will subroutine signatures apply to methods in Perl6

Uri Guttman wrote: [Re: use strict 'typing'; my $rex = new Dog; $rex.bark] > then it should be a compile time error at the assignment to $rex > and not later. you can't trace $rex at compile time to see what > kind of object (if any) was assigned to it. so the illegal method > call can't (easily)

Re: Multiple-dispatch on functions

[EMAIL PROTECTED] wrote: > Dan, I don't immediately see how per object/class dispatch > control helps to make multimethods pluggable. The way to approach this problem is to profile Class::MultiMethods and figure out (a) where the hot spots are and (b) what core support would help eliminate those

Re: Multiple-dispatch on functions

Damian Conway wrote: > Ken wrote: >> The one thing I'm curious about is whether different syntactic >> conventions affect the dispatcher or whether this is all just >> sugar for a single dispatch. > > Multiple dispatch is certainly not (practically) implementable via single > dispatch

Re: !< and !>

"Bryan C. Warnock" wrote: > I'm waiting for someone to say that in tri-state logic, '!<' != '>=' That's what I thought it was. "$a !< $b" might be "!defined($a) || $a >= $b". In SQL this is "$a IS NULL or $a >= $b". - Ken

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: 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: 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: 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: 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: 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: 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: 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: 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?

"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: > 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?

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: Prototypes

"Bryan C. Warnock" wrote: > { > my $a = sub ($$) { code }; > gork($a); > } > > sub gork { > my ($a) = shift; > $a->(@some_list); # <- Here > } > > The reason prototypes aren't checked at "Here" is because there really > isn't a way to know what the prototype was. Um, that's not

What's up with %MY?

I haven't seen details in an Apocalypse, but Damian's Perl 6 overview has a bit about it. The Apocalypse specifically mentions *compile-time* scope management, but Damian is, uh, Damian. (DWIMery obviously. ;) Is stuff like: %MY::{'$lexical_var'} = \$other_var; supposed to be a compile-time o

Re: What's up with %MY?

Damian Conway wrote: > It would seem *very* odd to allow every symbol table *except* > %MY:: to be accessed at run-time. Well, yeah, that's true. How about we make it really simple and don't allow any modifications at run-time to any symbol table? Somehow I get the feeling that "*very* odd" can'

Re: What's up with %MY?

Damian wrote: > Dan wept: >> I knew there was something bugging me about this. >> >> Allowing lexically scoped subs to spring into existence (and >> variables, for that matter) will probably slow down sub and >> variable access, since we can't safely resolve at compile time wh

Re: What's up with %MY?

Damian wrote: > In other words, everything that Exporter does, only with lexical > referents not package referents. This in turn gives us the ability to > easily write proper lexically-scoped modules. Great! Then we don't need run-time lexical symbol table frobbing. A BEGIN block can muck with it

Re: What's up with %MY?

[EMAIL PROTECTED] wrote: > Clearly caller() isn't what we want here, but I'm not > quite sure what would be the correct incantation. I've always assumed that a BEGIN block's caller() will be the compiler. This makes it easy for the compiler to lie about %MY:: and use the lexical scope being compi

Re: What's up with %MY?

Dan Sugalski wrote: > ... you have to take into account the possibility that a > variable outside your immediate scope (because it's been defined in an > outer level of scope) might get replaced by a variable in some intermediate > level, things get tricky. Other things get "tricky" too. How abou

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?

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: > 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: 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: 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: 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: 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: What's up with %MY?

Dan Sugalski wrote: > At 02:05 PM 9/6/2001 -0400, Ken Fox wrote: > >You wrote on perl6-internals: > > > >get_lex P1, $x # Find $x > >get_type I0, P1 # Get $x's type > > > >[ loop using P1 and I0 ] > > > >That cod

Re: What's up with %MY?

Dan Sugalski wrote: > On the other hand, if we put the address of the lexical's PMC into a > register, it doesn't matter if someone messes with it, since they'll be > messing with the same PMC, and thus every time we fetch its value we'll Do > The Right Thing. Hmm. Shouldn't re-binding affect onl

Re: What's up with %MY?

Dan Sugalski wrote: > I think you're also overestimating the freakout factor. Probably. I'm not really worried about surprising programmers when they debug their code. Most of the time they've requested the surprise and will at least have a tiny clue about what happened. I'm worried a little abo

Re: what lexicals do?

Dave Mitchell wrote: > Can anyone think of anything else? You omitted the most important property of lexical variables: [From perlsub.pod] Unlike dynamic variables created by the C operator, lexical variables declared with C are totally hidden from the outside world, including any calle

Re: What's up with %MY?

Damian Conway wrote: > Bzzzt! The line: > > %MY::{'$x'} = \$z; > > assigns a reference to $z to the *symbol table entry* for $x, not to $x itself. So I should have said: %MY::{'$x'} = $z; That's pretty magical stuff isn't it? Sorry I used the wrong syntax. I'm just taking it from yo

Re: What's up with %MY?

"Bryan C. Warnock" wrote: > Generically speaking, modules aren't going to be running amok and making a > mess of your current lexical scope - they'll be introducing, possibily > repointing, and then possibly deleting specific symbols How much do you want to pay for this feature? 10% slower code?

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: 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

"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

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

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: 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

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: 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: 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: >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: 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: 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: > 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: Light ideas

Dave Storrs wrote: > why didn't you have to write: > > rule ugly_c_comment { > / > \/ \* [ .*? ? ]*? \* \/ > { let $0 := " " } > / > } Think of the curly braces as the regex quotes. If "{" is the quote then there's nothing spe

Re: Light ideas

Uri Guttman wrote: > but remember that whitespace is ignored as the /x mode is on > all the time. Whoops, yeah. For some reason I kept literal mode on when reading the spaces between two literals. The rules {foo bar} and {foobar} are the same, but some very low level part of my brain is resisti

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

backtracking into { code }

A question: Do rules matched in a { code } block set backtrack points for the outer rule? For example, are these rules equivalent? rule expr1 { { /@operators/ or fail } } rule expr2 { @operators } And a comment: It would be nice to have procedural control over back- tracking

Re: backtracking into { code }

Aaron Sherman wrote: > rule { { /@operators/.commit(1) or fail } } > > The hypothetical commit() method being one that would take a number and That would only be useful if the outer rule can backtrack into the inner /@operators/ rule. Can it? I agree with you that a commit method woul

Re: backtracking into { code }

Damian Conway wrote: > rule expr1 { > { m:cont/@operators/ or fail } > } > > Backtracking would just step back over the rule as if it were atomic > (or followed by a colon). Ok, thanks. (The "followed by a colon" is just to explain the behavior, right? It's illegal to follow a

Re: backtracking into { code }

Larry Wall wrote: > On Fri, 30 Aug 2002, Ken Fox wrote: > : Ok, thanks. (The "followed by a colon" is just to explain the behavior, > : right? It's illegal to follow a code block with a colon, isn't it?) > > I don't see why it should be illegal--it cou

Re: backtracking into { code }

Larry Wall wrote: > There's a famous book called "Golf is Not a Game of Perfect". Well now I'm *totally* confused. I looked that up on Amazon and it has something to do with clubs and grass and stuff. That's completely different than what I thought golfing was. ;) Seriously, though. I have a pos

Re: Regex stuff...

Piers Cawley wrote: > Unless I'm very much mistaken, the order of execution will > look like: > > $2:=$1; $1:=$2; You're not binding $2:=$1. You're binding $2 to the first capture. By default $1 is also bound to the first capture. Assuming that numbered variables aren't special, the orde

Re: @array = %hash

Simon Cozens wrote: > [EMAIL PROTECTED] (Damian Conway) writes: > >>> %hash4 = ("Something", "mixing", pairs => and, "scalars"); >> >>That's perfectly okay (except you forgot the quotes around the >>and you have an odd number of elements initializing the hash). > > Urgh, no. Either a pair is a

  1   2   >