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

2003-01-23 Thread Fisher Mark
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

RE: purge: opposite of grep

2002-12-05 Thread Fisher Mark
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 separate, which IIRC is

RE: RFC - Hashing PMC's albie@halfarrabio.di.uminho.pt

2002-07-24 Thread Fisher Mark
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

RE: RFC - Hashing PMC's albie@halfarrabio.di.uminho.pt

2002-07-24 Thread Fisher Mark
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: Mutable vs immutable strings

2002-04-25 Thread Fisher Mark
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

RE: Subroutines...

2002-04-25 Thread Fisher Mark
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: quote for the day

2001-02-28 Thread Fisher Mark
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:

RE: Perl recommended reading list

2000-10-10 Thread Fisher Mark
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

RE: A tentative list of vtable functions

2000-10-04 Thread Fisher Mark
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

2000-10-02 Thread Fisher Mark
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

RE: PERL6STORM - tchrist's brainstorm list for perl6

2000-09-21 Thread Fisher Mark
=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++

RE: An attempt to be constructive

2000-09-13 Thread Fisher Mark
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 by

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

2000-08-30 Thread Fisher Mark
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!"

Optional Separate Programs for Interpreter Passes

2000-08-29 Thread Fisher Mark
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

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

2000-08-28 Thread Fisher Mark
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 146 (v1) Remove socket functions from core

2000-08-28 Thread Fisher Mark
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 my

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

2000-08-25 Thread Fisher Mark
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