RE: Transferring control between code segments, eval, and suchlik e things

> Design Edict #3: All destinations *must* be marked as such in the > bytecode metadata segment. (I am officially nervous about this, as I > can see a number of ways to subvert this for evil) [...] > Design Edict #4: Dan is officially iffy on jumps, but can see them as > useful for lower-level s

RE: purge: opposite of grep

> FWIW, I came up with "purge" because my first inclination was to spell > "grep" backwards: "perg". :-) I like "purge", although "except", "exclude", and "omit" all have their charms. For partition function, I like "divvy", "carve", "segment" (in that order) and almost anything other than "sepa

RE: RFC - Hashing PMC's

> But then sometimes you'd *want* hashing to be based on the > content. OK, I'll bite -- when would you want this behavior? This behavior means that once you change the contents, the hash value would become irretrievable unless you restored the contents of the key. (Is this useful in functional

RE: RFC - Hashing PMC's

As the last person to change the key hash algorithm, I'd like to chime in here with a request that each PMC provide a string that the key hashing algorithm can operate on. To some degree this is just selfish on my part -- I've got plans for upgrading the key hash algorithm in Perl 5 and Perl 6 wh

RE: Selective exporting of properties/methods

Miko O'Sullivan writes: >What I've often wanted would be standard method that is called before every >subroutine call. If that method returns false then the method that was >called is not called. What you're describing is Aspect-Oriented Programming (I think). Take a look around CPAN for Aspect.

RE: Subroutines...

> I've no strong opinions on how it's done, but I do believe that > it's *very* important that subroutine calls be as fast as possible > (and significantly faster than perl5). This must be a priority. > > To my mind that means that a subroutine should be responsible for > setting up whatever _it_

RE: Mutable vs immutable strings

> Should strings in parrot be mutable or immutable? Right now we've a > mix, and that's untenable. I've improved (read: got working) 2 C++ string libraries in the past, both with mutable strings. As performance was a primary consideration on both systems that used these libraries, I chose to co

RE: quote for the day

> >What is this talk of software 'releases'? Klingons do not > 'release' software; > >our software ESCAPES, leaving a bloody trail of designers and quality > >assurance people in its wake! One good source of all the Klingon programmer sayings: http://public.logica.com/~stepneys/joke/kli

RE: Perl recommended reading list

If it's not too late, I'd like to also add: Code Complete : A Practical Handbook of Software Construction Steve C. McConnell No matter what else we do, we know we're going to be writing code for this puppy. IMHO I was writing pretty solid code already, but I'm seeing ways to impro

RE: A tentative list of vtable functions

> 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. It can't be done by the default new operator, but you can do it

RE: RFC 349 (v1) Perl modules should be built with a Perl make program

These references should have made it into the RFC: cons http://www.dsmit.com/cons/ pmake http://www.cpan.org/modules/by-authors/id/N/NI/NI-S/Make-1.00.tar.gz Mark Leighton FisherThomson Consumer Electronics [EMAIL PROTECTE

RE: RFC 329 (v1) C

>I briefly considered > >{ >use syntax "python"; >} > >and nearly lost my lunch. And if you want to lose your breakfast too, consider: use "lisp"; use "apl"; (Although if the array-processing and currying RFCs are accepted, Perl will finally have powers beyond tho

RE: PERL6STORM - tchrist's brainstorm list for perl6

> =item perl6storm #0064 > > Do something about microsoft's CRLF abomination. I think for the case of Microsoft C++ used for the Win32 port, everyone would be happy if Perl's sysopen, sysread, etc. did not require binmode. Unfortunately, Microsoft made the decision very early on in its C/C++ dev

RE: An attempt to be constructive

Russ Allbery writes: >The entire point and *purpose* of a lawyer specializing in contract law is >to write clearly. They're not writing clearly for the average reader, >necessarily; that requires a whole different type of phrasing. They're >writing clearly for the interpretation of the contract

RE: RFC 176 (v1) subroutine / generic entity documentation

> #File: Foo.pm > sub foo : doc( In:scalar - int - foo identifier >Out:array - decomposed foo >Effects: Queries Foo DB >Exceptions: DBI, "bad foo id" > EOS > { This is an interesting and powerful idea, but I can't help thinking that it needs to be

RE: Do we really need eq?

Al Lipscomb writes: >I was wondering about maybe being able to store these > attributes as > optional parts of the scalar. Something like this (please > don't get hung up > on the details, I am not much of a designer): > >my($amt,$hours,$total); >$amt->{TYPE} = "DOLLARS"; >$total->{

RE: RFC 168 (v1) Built-in functions should be functions

John Porter writes: > Ah, the old "If you want Tcl, you know where to find it" non-argument. > > "Closures?""No! This is Perl, not Lisp!" > "Objects?" "No! This is Perl, not Smalltalk!" > "Patterns?""No! This is Perl, not Snobol!" > "Subroutines?" "No! This is Perl, not Basic!" >

RE: Optional Separate Programs for Interpreter Passes

Bradley M. Kuhn wrote: > For the world of the JVM port, it's imperative that hooks be > provided so > that the front-end can be run independently, and a different > back-end can be > run (to emit bytecode of some sort). All this also dovetails nicely with the mass-market world of embedded devic

Optional Separate Programs for Interpreter Passes

Although Perl interpretation is divided into several passes (parser/lexer, optimizer, tree/bytecode runner), all these passes are grouped together in one binary. Under some memory-constrained conditions, it could be better if each pass ran as its own program, passing the transformed data onto the

RE: RFC 146 (v1) Remove socket functions from core

>>BTW, I have access to Rational Software's Quantify (and PureCoverage and >>Purify) on WinNT and HP-UX 10.20 which I'd be glad to use for such tests. > >If you want to get "in the mood" it would be good to fire it up on >(say) perl5.6.0 and see where the hot-spots are. Planning on it as part of

RE: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.

>By the way, for all you thesis writers and thesis advisors out there -- I >suspect that a separate implementation of the Perl6 lexer and/or Perl6 >parser might make a dandy thesis topic... By the way, this message makes more sense if you s/a separate/an independent/... :( > =

RE: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.

> > Do we have an RFC yet that proposes Perl to be easier parsable? > > Damian? > >Working on it. By the way, for all you thesis writers and thesis advisors out there -- I suspect that a separate implementation of the Perl6 lexer and/or Perl6 parser might make a dandy thesis topic... ===

RE: RFC 146 (v1) Remove socket functions from core

>Leaping to conculusions based on no tests at all is even worse... > >Will anyone bite the bullet and write the "Internals Decisions should >be based on actual tests on multiple platforms" RFC ? BTW, I have access to Rational Software's Quantify (and PureCoverage and Purify) on WinNT and HP-UX 10

RE: RFC 146 (v1) Remove socket functions from core

> For instance, if I'm running Perl on my Palm, I'd just as soon that > index() were implemented in Perl using repeated substr() comparisons. How small do we really need to go? Are we looking at implementing Perl for microcontrollers, or are we only worrying about Perl for PDAs? The difference