Re: Schwartzian Transform
On Mon, Mar 26, 2001 at 04:34:22PM -0600, Jarkko Hietaniemi wrote: Of course. So how is the ST justified when you simply want to sort by length? I.e., why is this not sufficient: Those of the School of Maniacal Optimization may prefer calling length() only O(N) times, instead of O(N log N) times. Yeah, a weak argument, but then again, I didn't claim length() as such being the prime user of ST. Oops. Maybe it wasn't the best example. Ah, I think I can weasel my way out of this: now we have UTF8 strings, it's possible that calling length() on a string is an O(N) process instead of a simple lookup in the SV. (Hmm. Perhaps xpv should have had an xpv_utf8len field.) -- It's 106 miles from Birmingham, we've got an eighth of a tank of gas, half a pack of Dorritos, it's dusk, and we're wearing contacts. - Malcolm Ray
pitching names for the attribute for a function with no memory or side effects
James Mastros wrote: Ahh, bingo. That's what a number of people (inculding me) are suggesting -- a :functional / :pure / :stateless / :somthingelseIdontrecall attribute attachable to a sub. :memoizable :clean :nosideeffects
Re: What can we optimize (was Re: Schwartzian transforms)
Dan Sugalski wrote:
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.
I'm hoping to have this stage of optimization in perl.
Dan
define non-MY to mean, dynamic or lexical from outside of the function,
so, non-my relative to the function.
obviously_clean(\subX){ # could be defined as:
not (any appearance of known-unclean functions)
and
not (non-MY appears at all)
}
subs and functions can get flagged clean/unclean fairly quickly then.
known-unclean are things like "rand" and any functions that have not
been marked "clean" already.
The attribute would force a non-obviously clean subroutine to be treated
as clean, and memoized, unless use-less-memory is in effect. It would allow
for some pretty subtle abuses.
Re: pitching names for the attribute for a function with no memory or side effects
At 08:17 PM 3/30/2001 +, David L. Nicol wrote: James Mastros wrote: Ahh, bingo. That's what a number of people (inculding me) are suggesting -- a :functional / :pure / :stateless / :somthingelseIdontrecall attribute attachable to a sub. :memoizable :clean :nosideeffects :contained. Or possibly :irrelevant, since generally speaking most people won't use it and the optimizer will have to infer whether it's safe to not execute the function every time... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: pitching names for the attribute for a function with no memory or side effects
From: John Porter [mailto:[EMAIL PROTECTED]] Dan Sugalski wrote: :contained. Or possibly :irrelevant, since generally speaking most people won't use it and the optimizer will have to infer whether it's safe to not execute the function every time... It shouldn't necessarily have to. If I *tell* it it's safe, that should be the end of the story. It don't get much more optimal than that. I think he's talking about the 90% of the time that no one explicitly declares it, but the optimizer infers that it is "contained" anyway. Speaking of which... how about: "immutable" immutable adj : not subject or susceptible to change or variation in form or quality or nature; "the view of that time was that all species were immutable, created by God" [syn: changeless] [ant: mutable] --Source: WordNet 1.6, 1997 Princeton University
RE: pitching names for the attribute for a function with no memor y or side effects
At 03:30 PM 3/30/2001 -0600, Garrett Goebel wrote: From: John Porter [mailto:[EMAIL PROTECTED]] Dan Sugalski wrote: :contained. Or possibly :irrelevant, since generally speaking most people won't use it and the optimizer will have to infer whether it's safe to not execute the function every time... It shouldn't necessarily have to. If I *tell* it it's safe, that should be the end of the story. It don't get much more optimal than that. I think he's talking about the 90% of the time that no one explicitly declares it, but the optimizer infers that it is "contained" anyway. John's right, though. Regardless of how a sub looks, if it's marked as something we can call only when we really need we should respect that. (I can see it for subs that do reach outside themselves for the info needed to provide data to sort) Speaking of which... how about: "immutable" Doesn't have the right ring to it, unfortunately. It's not really immutable, it just has no side-effects. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: pitching names for the attribute for a function with no memor y or side effects
Dan Sugalski [EMAIL PROTECTED] writes: Doesn't have the right ring to it, unfortunately. It's not really immutable, it just has no side-effects. gcc and the literature both use "pure"; I'd recommend that. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: pitching names for the attribute for a function with no memor y or side effects
Russ Allbery wrote: gcc and the literature both use "pure"; I'd recommend that. Excellent! So I wasn't pulling it out of... thin air. :-) I like pure too, but I'm afraid the nuance of it will be completely lost on non-Functional programmers. -- John Porter Like music? Then you're gonna love this. I was into these dudes before anybody. Asked me to be the manager.
