Re: Perl culture, perl readabillity
On Thu, 29 Mar 2001 06:53:49 +0200, Otto Wyss [EMAIL PROTECTED] wrote: - Make readability your main objective. Readability is possibly the weakest part of Perl. - Keep your eyes on modularity. Modularity is by far the best concept where complexity could be hidden. - Don't forget usability. This is after all the point why people use Perl in the first place. It seems you are not interested in critics, so lets end this thread. Au contraire. The Perl community is *very* much interested in critiques. Seen the amount of response to you starting mail, this is overwhelming. One thing you probably `missed' in this discussion, is the way /you/ look at the language. Writing to the perl community, you're writing to people that got used to the syntax and now see the logic and usability of the 'line noise' you call unreadable. Every language has got it's pros and cons. Perl's first usage for most of us is probably it's glue function and versability. When you program/script in perl for a few weeks/month/years, you'll get used to it, and you're going to like it and probably even appreciate it. I started using perl in my company after reading an article in Unix-Info (a dutch magazine) that stated that perl would do well as an awk, grep and sed replacement, and that rose my curiosity. All those utils on unix have their own syntax, and you don't tell me that sed, awk and grep based scripts are readable/maintainable, esp. if there's a lot of programmers involved in setting up the lot. Perl being a fine replacement for it, has now 'conquered' this company. We almost never ever use shell scripts anymore, and there's not many left that know how to write awk and sed scripts. One syntax will do. In the beginning we wrote Perl scripts that called external SQL scripts, which now are converted to DBI/DBD. Perl's glue function saves time. A reason to postpone using DBD was that our database was not (yet) implemented by someone, so I had to write it myself. Now the world has access to yet another Database interface for perl through CPAN, yat another *BIG* advantage of the perl community: they /share/ the knowledge. If you want code that is readable by *all* your (even unexperienced) programmers and want to keep it maintainable, feel free to use python, but if you want to grow the program into more flexible use, extend it later to use yet another database, interface or character encoding, I think you should hop over the initial line noise and just *USE* perl. If you do, I'd like to hear your experience half a year from now. Have the appropriate amount of fun (in whatever language)! -- H.Merijn Brand Amsterdam Perl Mongers (http://www.amsterdam.pm.org/) using perl-5.005.03, 5.6.0, 5.6.1, 5.7.1 623 on HP-UX 10.20 11.00, AIX 4.2 AIX 4.3, WinNT 4, Win2K pro WinCE 2.11 often with Tk800.022 /| DBD-Unify ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
Re: Schwartzian transforms
On Wed, 28 Mar 2001 11:11:20 -0500, Dan Sugalski wrote: "Can perl automatically optimize away function and tie calls inside a sort function, and under what circumstances?" It doesn't really matter if the functions inside the sort function are idempotent--what matters is whether it's OK for us to go and memoize the things (or whatever else we might choose to do) Exactly. This whole discussion borders on the edge of the ridiculous. Any sort algorithm ALWAYS assumes that comparisons are constant, i.e. return consequent results on subsequent calls. They always infer sorting information out of what they got yet. That's why they hardly ever need to compare every item with every other item. The fewser comparisons, the better the algorithm. As MJD very recently wrote: An optimal sort function will not call the comparator if it already knows what the result should be! So true. That implies that side effects and otherwise unmemoizability of sort functions may *always* safely be ignored. If not, the programmer has a personal problem, i.e. a bad starting point. Otherwise, the results of sort would largely depend upon which sort algorithm was used internally! -- Bart.
Re: Perl culture, perl readabillity
Nicely put, Merijn. Stomping into (any) programming language camp and telling loudly that what you are doing is wrong is a bit like stomping into a Mongol camp and asking what's up with the funny fur hats. Or, in the of case Perl, accusing us of too much line noise and being too hard to read, is like complaining to the Chinese/mathematicians that can't you just using Latin letters / plain English instead of Greek and symbols so that the rest of us could understand you. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Perl culture, perl readabillity
Quoting [EMAIL PROTECTED]:
:I'm choosing a new language only if is suitable for most of my tasks and
:these range from the 10 line script up to several million line project.
:Currently Perl is rather capable for any small scripting task but it's
:out of questions if there are more than 2 person involved or the line
:count goes above several hundreds (maybe thousands). And this is only
:because to much time is lost in understanding what all the other code is doing.
The current project I'm leading at work is a 18000 line of perl application.
Yes, 18_000, and that's only pure lines of code, with comments and blank
lines not counted.
It's very maintainable, but then, it's using strict OO programming, which
tends to encapsulate things well, and I have imposed the "programming by
contract" methodology to make things scalable in the large.
When I say strict OO programming, I mean:
* Use explicit plain perl -- not "use base", "use fields" or things that tend
to hide extra processing under the hood that rises the overall complexity
instead.
* Have explicit access routines for every attribute, and never dereference
attributes explicitely. That is, say:
$o-attr
and NOT:
$o-{attr};
There are also explicit -set_attr() routines for all attributes that
can be set.
* Most methods specify a contract with explicit REQUIRE and ENSURE clauses.
The code also uses ASSERTs in places.
* Use modules like Getargs::Long to have long argument names for routines that
take more than, say, 3 args, especially for creation routines. This also
allows type checking.
So no, your argument does not stand as it is!
I've seen people do horrible C-like things in "clean" languages like Eiffel,
and people do *very neat* things in C, or, more often, Perl.
Raphael
Re: What can we optimize (was Re: Schwartzian transforms)
On Wed, Mar 28, 2001 at 03:41:42PM -0800, Hong Zhang wrote: Are we over-optimizing? The Perl is just an interpreter language. Who really needs this kind of optimization for Perl? Even C does not provide this feature. Umm, art thou sure? C can optimize better then we currently do many times, because it doesn't have to worry about side-efects as often because it doesn't have the concept of ties/overriden operators. (It does, and we do, have to worry about aliasing, but that is somthing of a smaller problem.) Just because C doesn't memonize, doesn't mean we shouldn't have that optimization available to us. So many other optimizations that are doable in C aren't in perl. Though Pascal/Ada have distinctions like function/procedure, it does not make them any faster than C. Umm, I don't know Ada, but in Pascal, the only difference is that one returns a value and the other does not (IE like void vs. nonvoid functions in C, or sub vs. function in VB). Just given its ugly name, I hate to see it in the core language. If people really want to optimize Perl, they can write a native compiler for Perl with advanced garbage collector, just like Scheme or Strongtalk compiler? We want to make it as fast as reasonably possible. Writing a native compiler might not be _reasonably_ possible. And an advanced GC will almost certianly be part of perl6; they're orthogonal issues. -=- James Mastros -- The most beautiful thing we can experience is the mysterious. It is the source of all true art and science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand wrapt in awe, is as good as dead. -=- Albert Einstein AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: What can we optimize (was Re: Schwartzian transforms)
On Thu, Mar 29, 2001 at 10:25:06AM -0500, James Mastros wrote: On Wed, Mar 28, 2001 at 03:41:42PM -0800, Hong Zhang wrote: Are we over-optimizing? The Perl is just an interpreter language. Who really needs this kind of optimization for Perl? Even C does not provide this feature. Umm, art thou sure? C can optimize better then we currently do many times, Somewhat tangentially: this reminds me of a message a week ago or so (can't find it anymore in my inbox) which proposed writing C (or C++) code for Perl 6 so that "modern CPU architectures are happy" (no pipeline stalls because of "if"-s, etc.) Hello? This is a very high-level language we are writing, not a DSP core. Optimizing by choosing good algorithms and data structures, yes, microoptimizing, maybe, only after the code works first, and even then we would be following the mirage since CPU architectures do evolve, and in general, for large codebases, the C compilers are much, much, better in optimizing than humans. Yes, a human can sit down and read the databooks and optimize a simple algorithm to hell and back. But megabytes of source code? Get real. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: What can we optimize (was Re: Schwartzian transforms)
Jarkko Hietaniemi wrote: ... proposed writing C (or C++) code for Perl 6 so that "modern CPU architectures are happy" (no pipeline stalls because of "if"-s, etc.) ... in general, for large codebases, the C compilers are much, much, better in optimizing than humans. I totally agree. That would just be absurd. We need to keep our priorities straight. We have to live with the fact that perl might scream a little more on one platform than on another. Far better for us to write code that is maintainable for the long haul. Shoot, by the time perl7 comes out, the C compilers will just be that much better (and the hardware that much faster). -- John Porter
Re: What can we optimize (was Re: Schwartzian transforms)
Jarkko Hietaniemi [EMAIL PROTECTED] wrote: Somewhat tangentially: this reminds me of a message a week ago or so (can't find it anymore in my inbox) which proposed writing C (or C++) code for Perl 6 so that "modern CPU architectures are happy" (no pipeline stalls because of "if"-s, etc.) Hello? This is a very high-level language we are writing, not a DSP core. Optimizing by choosing good algorithms and data structures, yes, microoptimizing, maybe, only after the code works first, and even then we would be following the mirage since CPU architectures do evolve, and in general, for large codebases, the C compilers are much, much, better in optimizing than humans. Yes, a human can sit down and read the databooks and optimize a simple algorithm to hell and back. But megabytes of source code? Get real. That may have been me: http://archive.develooper.com/perl6-internals%40perl.org/msg02685.html (PDD for coding conventions) The main thrust of that was whether a PDD on coding conventions should have sections on: * Coding style * Naming conventions * Commenting conventions * Portability guidelines * Performance guidelines Based on your comments above (which I hearily agree with), I guess we can safely dispense with that last entry. Dave M.
Re: What can we optimize (was Re: Schwartzian transforms)
Dave Mitchell wrote: The main thrust of that was whether a PDD on coding conventions should have sections on: ... * Performance guidelines ...I guess we can safely dispense with that last entry. No, performance guidelines are probably still appropriate; but doing hand-coded peephole optimizations is not the Right Thing. As Jarkko, said: Optimizing by choosing good algorithms and data structures, yes -- John Porter
Re: What can we optimize (was Re: Schwartzian transforms)
At 10:25 AM 3/29/2001 -0500, James Mastros wrote: On Wed, Mar 28, 2001 at 03:41:42PM -0800, Hong Zhang wrote: Are we over-optimizing? The Perl is just an interpreter language. Who really needs this kind of optimization for Perl? Even C does not provide this feature. Umm, art thou sure? C can optimize better then we currently do many times, because it doesn't have to worry about side-efects as often because it doesn't have the concept of ties/overriden operators. (It does, and we do, have to worry about aliasing, but that is somthing of a smaller problem.) Aliasing is actually one of the bigger problems with C, or so I'm lead to believe. It gets in the way of a number of optimizations rather badly. (So say some of Compaq's C and Fortran compiler folks, and I have no reason to doubt them. The Fortran compiler often generates faster code than the C compiler for this reason apparently) Just because C doesn't memonize, doesn't mean we shouldn't have that optimization available to us. So many other optimizations that are doable in C aren't in perl. That's not true. Perl's probably more optimizable than C for many things. Though Pascal/Ada have distinctions like function/procedure, it does not make them any faster than C. Umm, I don't know Ada, but in Pascal, the only difference is that one returns a value and the other does not (IE like void vs. nonvoid functions in C, or sub vs. function in VB). Well, functions without return values are mildly faster than functions with return values. No stack and/or register manipulation needed for the return. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: What can we optimize (was Re: Schwartzian transforms)
At 03:41 PM 3/28/2001 -0800, Hong Zhang wrote: Are we over-optimizing? The Perl is just an interpreter language. Perl's not just an interpreter language, and hasn't been for a while. (Granted the bytecode compiler's not fully functional, but it does work in some cases) Who really needs this kind of optimization for Perl? I do. Lots of people with web apps do. Pretty much anyone with a large or long-running perl program does. Even C does not provide this feature. C doesn't have the sort of sort function that makes this possible in the first place, nor does it have the sort of data that makes it a reasonable thing to do. Perl does, so some optimization is reasonable. Whether it's a good first spot to optimize is an open question, but it will be a big win for quite a few people. Though Pascal/Ada have distinctions like function/procedure, it does not make them any faster than C. Depends on how the function's written in C. A function that has no meaningful return yet still returns one which gets inevitably thrown away will cost more than one that never returns anything, and there is a tendency to return *something* since you can. Just given its ugly name, I hate to see it in the core language. What, the ST? Why on earth would you think that we'd make much of a big deal over it in the docs? I'd just soon not mention it and just put it in as an optimization and have it be a pleasant performance win. If people really want to optimize Perl, they can write a native compiler for Perl with advanced garbage collector, just like Scheme or Strongtalk compiler? What, as opposed to the interpreter with advanced garbage collector? :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl culture, perl readabillity
At 06:53 AM 3/29/2001 +0200, Otto Wyss wrote: It seems you are not interested in critics, so lets end this thread. More to the point, I said let it rest, so the thread should end. Now. And this means *everyone*. Thank you. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: What can we optimize (was Re: Schwartzian transforms)
On Thu, Mar 29, 2001 at 11:29:16AM -0500, Dan Sugalski wrote:
At 05:19 PM 3/29/2001 +0100, Dave Mitchell wrote:
Jarkko Hietaniemi [EMAIL PROTECTED] wrote:
Somewhat tangentially: this reminds me of a message a week ago or so
(can't find it anymore in my inbox) which proposed writing C (or C++)
code for Perl 6 so that "modern CPU architectures are happy" (no
pipeline stalls because of "if"-s, etc.) Hello? This is a very
high-level language we are writing, not a DSP core. Optimizing by
choosing good algorithms and data structures, yes, microoptimizing,
maybe, only after the code works first, and even then we would be
following the mirage since CPU architectures do evolve, and in
general, for large codebases, the C compilers are much, much, better
in optimizing than humans. Yes, a human can sit down and read
the databooks and optimize a simple algorithm to hell and back.
But megabytes of source code? Get real.
That may have been me:
(Sorry if I sounded too blunt, the other stuff in the PDD was fine.)
http://archive.develooper.com/perl6-internals%40perl.org/msg02685.html
(PDD for coding conventions)
The main thrust of that was whether a PDD on coding conventions
should have sections on:
* Coding style
* Naming conventions
* Commenting conventions
* Portability guidelines
* Performance guidelines
Based on your comments above (which I hearily agree with), I guess
we can safely dispense with that last entry.
Don't. Hand-optimizing the C code's pretty silly generally, but there are
some reasonable rules of thumb that can gain enough of a performance boost
[snip]
Yes. Rules of thumb are good, sort of like common lore of how
CPUs in general work. I would like to add the overall principle of
optimizing for speed first (that is, at the expense of space, e.g.
by using wide integer types) (worry about space later, if needed),
and avoiding division/modulus. Perhaps the rule #0 would be:
measure before you optimize. Concentrate on the hotspots, instead
of wasting your time honing some obscure rarely executed code.
An additional coding guideline could be:
* Extensibility guidelines
(This is not the same as 'portability.')
One particular detail I've noticed cropping up would be to avoid using
char* (or {char*,length}) if it is feasible to later use a SV*
(perl5-speak) at the same spot. An example: UTF-8 hash keys in Perl5.
The same goes for flag fields: only if you can be fairly certain
that the number of flags never exceeds 32, should you use an int.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Re: What can we optimize (was Re: Schwartzian transforms)
Who really needs this kind of optimization for Perl? I do. Lots of people with web apps do. Pretty much anyone with a large or long-running perl program does. I have to say that I agree to disagree. Since it has been so controversal, I just don't think this optimization is a good one. C doesn't have the sort of sort function that makes this possible in the first place, nor does it have the sort of data that makes it a reasonable thing to do. Perl does, so some optimization is reasonable. Whether it's a good first spot to optimize is an open question, but it will be a big win for quite a few people. C has qsort() and bsearch(). Anyway, I will not put it on my optimization list. Though Pascal/Ada have distinctions like function/procedure, it does not make them any faster than C. Depends on how the function's written in C. A function that has no meaningful return yet still returns one which gets inevitably thrown away will cost more than one that never returns anything, and there is a tendency to return *something* since you can. The function in Ada can not have any side effect, i.e. no change to globals. The procedure can have side effect. It gives compilers some more chances for optimizations. For example (pseudo code), function comp(int n, int m) : int; the compiler can safely remember the result of comparison for the same arguments. Hong
Re: What can we optimize (was Re: Schwartzian transforms)
On Thu, Mar 29, 2001 at 10:36:48AM -0800, Hong Zhang wrote: I have to say that I agree to disagree. Since it has been so controversal, I just don't think this optimization is a good one. Hmm, we aren't talking sort() specificly anymore. Look at the subject line. G The function in Ada can not have any side effect, i.e. no change to globals. The procedure can have side effect. It gives compilers some more chances for optimizations. For example (pseudo code), function comp(int n, int m) : int; the compiler can safely remember the result of comparison for the same arguments. Ahh, bingo. That's what a number of people (inculding me) are suggesting -- a :functional / :pure / :stateless / :somthingelseIdontrecall attribute attachable to a sub. -=- James Mastros -- The most beautiful thing we can experience is the mysterious. It is the source of all true art and science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand wrapt in awe, is as good as dead. -=- Albert Einstein AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
Re: What can we optimize (was Re: Schwartzian transforms)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 29 Mar 2001 10:36:48 -0800, "Hong Zhang" [EMAIL PROTECTED] wrote: The function in Ada can not have any side effect, i.e. no change to globals. Unless my reading of the Ada 95 standard is wrong, there's nothing that precludes functions having side effects. The only thing an Ada function cannot do is having "out" or "in out" parameters, so it cannot modify its arguments, and even that can be circumvented (as you can pass "in" access parameters). /L/e/k/t/u -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.5.8 for non-commercial use http://www.pgp.com iQA/AwUBOsOiu/4C0a0jUw5YEQKjQwCeP2Aeu6aJsdpP3asvcQDS+dyk2aoAoKS5 2gJ1o0xX1lfa0hXrVff1tPvx =t4je -END PGP SIGNATURE-
Re: What can we optimize (was Re: Schwartzian transforms)
Dan Sugalski [EMAIL PROTECTED] writes:
True enough. This is a small subset of general optimizations. For example,
this:
$i = 0;
foreach (1..1000) {
$i++;
}
can be easily optimized to:
$i = 1000;
and most language implementations with any sort of optimizer will do this. If
$i isn't actually used after that point without another assignment it might
well be completely optimized away. With perl, though, this does potentially
unexpected things if $i is tied. Do we still optimize it away? Do we only do
it if we can tell that $i's not tied? Do we force the programmer to explicitly
note which variables are potentially tied with the "my Dog $spot" syntax and
assume that everything else is fair game? Can we even do that in the face of
runtime requires, dos, or evals? (Or does that force a complete reevaluation
of the optimized bytecode)
How painful would an 'potential' optimization that marked that area in
the bytecode/optree/whatever, with something along the lines of the
following be?
If you get to this point and $i is not tied, and '=' is not
overridden for $i's class
then $i = 1000
otherwise, do the loop.
Of course, it means that the static runtime size is going to increase,
but presumably these potential optimizations wouldn't get done in the
presence of 'use less qw/space/'
--
Piers
Re: What can we optimize (was Re: Schwartzian transforms)
At 10:57 PM 3/29/2001 +0100, Piers Cawley wrote: How painful would an 'potential' optimization that marked that area in the bytecode/optree/whatever, with something along the lines of the following be? If you get to this point and $i is not tied, and '=' is not overridden for $i's class then $i = 1000 otherwise, do the loop. I've considered an "iftied" opcode that would essentially do this. The downside is the extra size of the bytecode as you've mentioned. I'm not sure if the speed boost would be worth it, but it's on my list of things to try. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: What can we optimize (was Re: Schwartzian transforms)
Dan Sugalski [EMAIL PROTECTED] writes: Aliasing is actually one of the bigger problems with C, or so I'm lead to believe. It gets in the way of a number of optimizations rather badly. (So say some of Compaq's C and Fortran compiler folks, and I have no reason to doubt them. The Fortran compiler often generates faster code than the C compiler for this reason apparently) Hence the introduction of the restrict keyword in C99 and several of gcc's attribute extensions for marking pure functions to try to get a handle on the problem. *wry grin* Yeah, that's the main thing that gets in the way of optimizing C. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: What can we optimize (was Re: Schwartzian transforms)
James Mastros [EMAIL PROTECTED] writes: Ahh, bingo. That's what a number of people (inculding me) are suggesting -- a :functional / :pure / :stateless / :somthingelseIdontrecall attribute attachable to a sub. The experience from gcc, which has a similar attribute, is that such an attribute will be fairly rarely used and that most of your gains will come from managing to teach the compiler to figure out that information for itself. This will probably be harder in Perl than in C because C can afford to take more time to do global optimization passes. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: What can we optimize (was Re: Schwartzian transforms)
At 02:52 PM 3/29/2001 -0800, Russ Allbery wrote: James Mastros [EMAIL PROTECTED] writes: Ahh, bingo. That's what a number of people (inculding me) are suggesting -- a :functional / :pure / :stateless / :somthingelseIdontrecall attribute attachable to a sub. The experience from gcc, which has a similar attribute, is that such an attribute will be fairly rarely used and that most of your gains will come from managing to teach the compiler to figure out that information for itself. This will probably be harder in Perl than in C because C can afford to take more time to do global optimization passes. I'm hoping to have this stage of optimization in perl. Off by default with a normal parse-and-go run (though certainly enableable if you want), on by default with the bytecode compiler. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: What can we optimize (was Re: Schwartzian transforms)
"DS" == Dan Sugalski [EMAIL PROTECTED] writes: This will probably be harder in Perl than in C because C can afford to take more time to do global optimization passes. DS I'm hoping to have this stage of optimization in perl. Off by DS default with a normal parse-and-go run (though certainly DS enableable if you want), on by default with the bytecode compiler. for long running daemon type programs, any extra optimization overhead at startup will be well worth it. this would be a great win if it wrings out a decent amount of speedup. or you could make it only doable for bytecode and then you run that. this shouldn't be an issue with many systems who want that optimization pass. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: What can we optimize (was Re: Schwartzian transforms)
At 06:22 PM 3/29/2001 -0500, Uri Guttman wrote: "DS" == Dan Sugalski [EMAIL PROTECTED] writes: This will probably be harder in Perl than in C because C can afford to take more time to do global optimization passes. DS I'm hoping to have this stage of optimization in perl. Off by DS default with a normal parse-and-go run (though certainly DS enableable if you want), on by default with the bytecode compiler. for long running daemon type programs, any extra optimization overhead at startup will be well worth it. this would be a great win if it wrings out a decent amount of speedup. or you could make it only doable for bytecode and then you run that. this shouldn't be an issue with many systems who want that optimization pass. There's not much point in making it doable for bytecode but not normal perl runs, as the same engine will be there for both. (Though I suppose the main perl interpreter would be smaller if there wasn't an optimizer in it, but I wouldn't bet it would take up much space) Since I'm going to tend to fire off long-running stuff in perl, I expect it'll be there for the asking. :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: What can we optimize (was Re: Schwartzian transforms)
From: Dan Sugalski [mailto:[EMAIL PROTECTED]] I'm hoping to have this stage of optimization in perl. Off by default with a normal parse-and-go run (though certainly enableable if you want), on by default with the bytecode compiler. Don't forget about run-time information: You could mark candidates for optimisation at compile time then, at run time, if the size of the array is "big" then spend the time to see if you can optimise. I'm not sure how to define "big", but I'm sure that's solvable. Dave.
