Re: Lexicals, continuations, and register allocation

Matt Fowles <[EMAIL PROTECTED]> wrote: > Leo~ > On Wed, 24 Nov 2004 04:55:24 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote: >> I've clearly stated that lexicals aka non-volatiles have distinct >> registers. > Thus for these large subs, won't this be a large overhead? Why? It's actually less

Namespace-sub invocation syntax?

Since there is a syntax for invoking subs: .sub foo # ... .end .sub bar foo() .end Should there be one for invoking a sub out of a namespace, say: .namespace [ "Foo" ] .sub bar # ... .end .namespace [ "Baz" ] .sub quux [ "Foo", "bar

Re: Reserved Word Heartburn

Luke Palmer <[EMAIL PROTECTED]> wrote: > IMCC yells at me when I say: > .namespace [ "Foo" ] > .sub new > ... > .end > While it's tolerable for local symbols, subs really have to be > named according to the interface. Is it possible to allow: > .sub "new" > ... > .end Should be rather

Re: Lexicals, continuations, and register allocation

Matt Fowles <[EMAIL PROTECTED]> wrote: > On Wed, 24 Nov 2004 17:25:05 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote: >> a = b + c + foo() > I am not sure that they are as rare as you think. Does it matter? They are no lexicals, you can't refetch them. So they get a distinct storage. When f

Re: Lexicals, continuations, and register allocation

Chromatic <[EMAIL PROTECTED]> wrote: > On Wed, 2004-11-24 at 15:04 +, Nicholas Clark wrote: >> Quite a lot of us would just like parrot COMPLETE and CORRECT before >> starting to put a lot of effort into how fast it is. > I'd settle for it compiling (#32514). Well, having just a short look a

Re: Lexicals, continuations, and register allocation

Bill Coffman <[EMAIL PROTECTED]> wrote: >> two possible interferences of different kinds, with additional coding >> overhead ... > ... What makes it a > little complicated is how do these "ubiquetous" symbols interact with > the non-ubuiquitous? Those arcs are needed for this. Yes that's what

Re: Too many opcodes

On Wed, Nov 24, 2004 at 09:20:42AM +0100, Leopold Toetsch wrote: > 2) Opcode variants with mixed arguments > > Honestly > >acos Nx, Iy > > and tons of other such opcodes are just overkill. If I want a numeric > result, I just pass in a numeric argument. If people really want > that, imcc ha

Re: [off topic] an amusing side note

On Wed, Nov 24, 2004 at 04:25:14PM -0500, John Siracusa wrote: > On 11/24/04 3:42 PM, Felix Gallo wrote: > > Well, it's the first time *I've* seen it. > > > > http://otierney.net/images/perl6.gif > > > > I find it difficult to disagree, at the perl6 language level. > > I don't :) Judging by the

Re: [off topic] an amusing side note

On Wed, Nov 24, 2004 at 06:30:29PM -0500, Felix Gallo wrote: > > 2. "perl 6 is a lot cleaner than perl 5". It's also much, much > larger than an already very large language. I've been programming > and evangelizing Perl in organizations small and gigantic since > 4.03x, and my eyes just glaze o

[perl #32605] [TODO] Website examples, no PIR.

# New Ticket Created by Herbert Snorrason # Please include the string: [perl #32605] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=32605 > The parrotcode.org website has an 'Examples' section, which (currently) contains

eof opcode

I noticed a hole in the io.ops where the PIO stuff wasn't covered. This patch creates an eof opcode which checks for end of file. Brian Wheeler [EMAIL PROTECTED] cvs diff: Diffing . cvs diff: Diffing ops Index: ops/io.ops === RCS f

Re: [off topic] an amusing side note

On 11/24/04 7:27 PM, Tim Bunce wrote: > I predict a burst of wild creativity from authors enjoying the > exploration of all the wonderful tools in the perl6 toolbox. > > Then, after a year or three of fun, sawn off limbs, and bloodied > fingers (and after a few good books get published) most of us

Will _anything_ be able to truly parse and understand perl?

Hi folks I thought it was about time I brought some concerns I've been having lately to the list. Not so much on any particular problem with perl6, but on problems with perl5 we would seem to have the opportunity to fix but aren't. (So far as I can tell). One of the biggest problems I have had

[perl #32607] The preprocessor changes "pmc" to an identifier

# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #32607] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=32607 > The preprocessor changes "pmc" to a previously used identifier: $ ./parrot -E -

Re: Will _anything_ be able to truly parse and understand perl?

Adam Kennedy writes: > Getting (finally) to perl6, I could have sworn I saw an RFC early on > which said "Make perl6 easier to parse". > > But it would appear the opposite is occurring. Source filters have > become grammars and will now be officially approved and acceptable > (yes?) while so far

Re: Test::Simple 0.51 prerelease

On Tue, Nov 23, 2004 at 10:51:26PM +0100, Tels wrote: > On Tuesday 23 November 2004 10:57, Michael G Schwern wrote: > > http://www.pobox.com/~schwern/Test-Simple-0.51.tar.gz > > Just wanted to send you a big thank you for your work on Test::*. I am slwly > converting my testsuites to Test::More a

Re: Will _anything_ be able to truly parse and understand perl?

Luke has answered this better than I would have. In particular, he wrote: > Perl's contextual sensitivity is part of the language. So the best you > can do is to track everything like you mentioned. It's going to be > impossible to parse Perl without having perl around to do it for you. That firs

[ANNOUNCE] Test::Simple/More/Builder 0.51

http://www.pobox.com/~schwern/src/Test-Simple-0.51.tar.gz or http://mugnus.schwern.org/svn/CPAN/Test-Simple/tags/VERSION=0.51 or svn://mungus.schwern.org/CPAN/Test-Simple/tags/VERSION=0.51 (I'm having fun with Subversion) A small bug fix release mostly to fix a pesky test mistake on Windows that

old parrot question?

hi,everyone. I am learning parrot0.0.1 source code. But i don't know "padding" in assemble.pl? "$size += length($_) % $sizeof_packi; # Padding" ??? why need to pad? who help ? bloves [EMAIL PROTECTED] 　　2004-11-25

Re: [perl #32607] The preprocessor changes "pmc" to an identifier

Fglock @ Pucrs . Br <[EMAIL PROTECTED]> wrote: > The preprocessor changes "pmc" to a previously > used identifier: > $ ./parrot -E -# invoke preprocessor Ouch, the preprocessor is far behind the current syntax. It needs either updating or disabling. Thanks for reporting, leo

Re: [perl #32514] Cannot Build Parrot on Linux PPC (nonvolatile registers)

Chromatic <[EMAIL PROTECTED]> wrote: > Ah, I've made Parrot build again on Linux PPC (and make testj only has > the expected t/library/streams.t failure present with make test too). He he, great. > The attached file works as the eventual src/platform_asm.s file, at > least on my architecture. I

Re: Too many opcodes

Nicholas Clark <[EMAIL PROTECTED]> wrote: > On Wed, Nov 24, 2004 at 09:20:42AM +0100, Leopold Toetsch wrote: >> 2) Opcode variants with mixed arguments >> >> Honestly >> >>acos Nx, Iy >> >> and tons of other such opcodes are just overkill. > Heck, why do we even have transcendental maths ops

Re: eof opcode

Brian Wheeler <[EMAIL PROTECTED]> wrote: > I noticed a hole in the io.ops where the PIO stuff wasn't covered. This > patch creates an eof opcode which checks for end of file. Please just use the "eof" method of the PIO object: $I0 = $P0."eof"() leo

Re: Will _anything_ be able to truly parse and understand perl?

Adam Kennedy writes: > perl itself would also appear unable to understand perl source, > instead doing what I would call RIBRIB parsing, "Read a bit, run a > bit". RIBRIB? RABRAB, surely! Smylers