in reply to Doing "it" only once

Your code looks overly complicated, it could be as simple as: 

#! perl -sw
use strict;

sub doit {
    local $^W;
    *doit = sub{ print } if m[^foo];
}

doit() while $_ = <DATA>;

=output
P:\test>junk4
fum
fiddlesticks
=cut

__DATA__
fee
fi
foo
fum
fiddlesticks

[download]

It's this kind of self-modifying code that horrified the CS types in the late 60's (early COBOL compilers used this extensively), and is what lead to 'structured programming' and eventually object orientation.

The funny thing is it is exactly this kind of technique that allows FP language compilers to produce efficient code from what appears horribly inefficient at the source code level. Goggle for a paper on the "The spineless tagless G-machine" for further reading.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.

Replies are listed 'Best First'.
Re^2: Doing "it" only once
by Limbic~Region (Chancellor) on Sep 21, 2005 at 16:33 UTC
    BrowserUk,
    I am sure there are many ways to improve the specific example and thanks for providing one of them. I didn't spend a lot of time thinking about it as I was just trying to provide a proof-of-concept so people would get an idea of how it might work.

    Additionally, thanks for the history lesson. In a nutshell, this type of functionality has been intentionally removed from some languages so these types of optimizations wouldn't happen - interesting.

    Cheers - L~R

[reply]
      ...this type of functionality has been intentionally removed from some languages so these types of optimizations wouldn't happen...

      Yes, but as I said, FP language compilers are now making a virtue of it :)

      The very thing that makes porting FP techniques into Perl such a waste of time, is that Perl cannot hope to come close to performing anything like the depth of analysis (at runtime) that (say) the GHC can perform at compile time. For example, memoization may seem like an 'advanced technique' in Perl's terms, but when you consider that every single function in Haskell is automatically memoized by the compiler, and moreover, every parameter of every function (currying) also. And this is done such that once a function is called with a given (set of) parameter(s), the code to call the function is actually overwritten with the resultant value, you begin to see how the efficiency is achieved.

      The mechanism of overwriting the function invocation with the value means that once the function has been called, every single subsequent call of the function (with the same parameter(s)) throughout the program, now simply retrieves the value of the result. And this is done such that there is not even a conditional test, never mind additional function calls to implement the memoization as is required by some Perl implementations.

      It is the referential integrity built in to the Haskell language that allows GHC to analyse the entire program structure and perform extensive graph reduction with value substitution.

      The dynamic nature of Perl, the need for introspection and the need to support mutable data, make many of the optimisations possible in FP languages, impossible in Perl.

      It would be nice to think that P6 would be able to detect the (referentially pure) conditions that would allow it to substitute value for function calls after the first invocation, but it will require some extremely clever code in the compiler/interpreter to perform that trick.

      In terms of Perl 5, it actually make more sense to model the function invocations in terms of a tied hash. The code just uses the appropriate value of the hash $fp{ parameter }, and the tie mechanism fills in the value if it isn't already present. Subsequent calls for the same value are very efficient (pro rata the inefficiency of tied hashs).

      You end up with a lazy (never calculated if never called for), strict (only calculated once), and very perlish mechanism that is a much better fit with the language that some others that attempt to emulate the source code semantics of FP languages without recognising that the absence of the optimising compiler renders them horribly inefficient.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.
[reply]
[d/l]
        For example, memoization may seem like an 'advanced technique' in Perl's terms, but when you consider that every single function in Haskell is automatically memoized by the compiler, and moreover, every parameter of every function (currying) also.
        Well, technically this is incorrect. Functions in Haskell are not memoized. You can see this is trivially true by considering the '+' function defined for the integers. Memoizing a measly 1 billion different arguments would easily exahust the memory of a 32 bit machine. 
        main = print (add_up 1000000000 0)

add_up 0 acc = acc
add_up n acc = add_up (n - 1) (acc + n)

        [download]
        ...(be sure to turn on optimizations!). You're probably thinking of the fact that data stuctures (like lists) are memoized by nature of the lazy graph rewriting semantics. See also, MemoisingCafs and Functional Programming and Parallel Graph Rewriting.
[reply]
[d/l]

In Section Meditations