develooper Front page | perl.perl5.porters | Postings from March 2000

Re: [ID 20000330.052] Use of uninitialized value in concatenation (.)

From:
Joseph N. Hall
Date:
March 31, 2000 12:01
Subject:
Re: [ID 20000330.052] Use of uninitialized value in concatenation (.)
Message ID:
MailDrop1.2d7j-PPC.1000331130108@perlfaq.com
On Fri, 31 Mar 2000 14:42:52 -0500 dan@sidhe.org (Dan Sugalski) wrote:

* At 12:26 PM 3/31/00 -0700, Joseph N. Hall wrote:
* >I'm not completely convinced that adding markers to the bytecode
* >stream to indicate when run-time interpolation is in effect is such
* >a bad idea.  It might allow finer-grained control over interpolation
* >(with overload?  or?) as well as more accurate Deparse, both of which
* >might turn out to be quite valuable.  Just to resolve the problem
* >with the warning message, though, it's way too much work.
*
* An added field could be thrown into the opcodes, but the problem with that
* is the opcodes take even more memory than they used to. They keep getting
* bigger, and I think we're seeing slowdowns as it is from larger opcodes.
* (The bigger they are the fewer fit in a page or the processor cache, though
* we're pretty profligate with D-space as it is)

I doubt that is really a problem for the ages, though.  In the near
future, if not now, caches will be large and/or capable enough that
cache busting really isn't something to design against.  Nevermind
that there is one Perl and a zillion different cache architectures.

* It might be worth doing to opcodes what we do to SVs and make the opcode
* itself smaller with the 'extras' hanging off a secondary structure, but I
* don't know that it'd be a win overall.

What is going on at runtime is already so complex that I wonder how much
more indirection and complexity would be worthwhile.  My biggest objection
to adding more stuff to the guts of Perl isn't that it makes Perl bigger
or slower, but that it brings the guts closer to "write-only" as far
as current and possible future developers/patchers are concerned.  Bigger
and slower are problems that 6 months of progress in the CPU wars will
solve.  Incomprehensible is a problem that is almost impossible to solve.

I'm certainly impressed at all the indirection that has crept into
the guts.  My look at sprintf the other day and this message issue today
have made it clear to me that C/C++ acumen and smarts and good programming
skills are not enough qualification to work on even relatively simple
Perl patches.  Which brings up the notion that "patches welcome" might
at times be more a vacuous retort than a real offer, but I shouldn't 
go there. 

  -joseph




nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About