Luke Palmer <[EMAIL PROTECTED]> wrote: > Leopold Toetsch writes: >> This term came up in a recent discussion[1]. But I'd like to give this >> term a second meaning.
> Except what you're talking about here is premature *optimzation*. No. I don't think so. >> During design considerations we (including me of course too) tend to >> discard or pessimize ideas early, because they look inefficient And I've summarized a bunch of examples. Maybe it wasn't too clear, but the conclusion is of course: spilling, lexical refetching, using method calls, ... (expensive looking operations) should not be discarded early. They can be optimized *later*. > ... Inline caching is > just another optimization. We need to be feature complete. That's exactly what I've written. I've described this idea as a possible later optimization. > And if you really feel like you need to optimize something, look into > the lexicals-as-registers idea you had to fix continuation semantics. > Then you can work under the guise of fixing something broken. Yeah. Have a look at chromatic's 4 c-words: compiles -> correct -> complete -> competitive "compiles" isn't really given, when there are compilers that either can't compile an -O3 build of the switched core or take ages to complete (if memory usage even permits that) choking the CG* cores. "correct". I've discovered and analysed the problem with continuations. I've made a proposal to fix that. No one has said that it's technically wrong or couldn't work. It seems you are liking the idea, but Dan doesn't. Now what? "complete" - read e.g. my recent postings WRT MMD (and perl.cvs.parrot:) "competitive" well, I like a speedy Parrot, that's obvious. It's a nice to have. But not only. Folks on conferences get interested in Parrot because it can proof that programs will run faster. > Luke leo
