Re^6: Better mousetrap (getting top N values from list X)

[BrowserUk]

Okay. I see what you are saying now. The slice across the return from sort generates a lazy list.

So the code:

my @data = getdata( 100000 );

my @topN = ( sort( @data ) )[ 1 .. 10 ];

undef( @data );

for my $top ( @topN ) { ## << COrrect per 427878
    ## do something with $top
}

Passes the whole list of data to sort, (which takes a copy of it in case we modify or discard it) and returns an iterator which gets bound to @top, so that each time we access the next element of @top in the for loop, the iterator is called via the magic of tieing, and the copy of the 100,000 elements that we passed to sort gets scanned to produce the next of our 5 return values.

Lazy huh?!

[sleepingsquirrel]

Essentially. Although I think you probably meant...

for my $top ( @topN ) {
    ## do something with $top
}

[BrowserUk]

Corrected. Thanks.

You do see the contradiction though?

For an algorithm that produces a subset m of a set N, duplicating N so that you can produce the subset lazily always consumes more storage--not to mention the overhead of tieing the iterator, retaining it's state etc.

<soapbox>

That's one of my bug bears with FP. They claim it produces proveably correct code by avoiding side effects, or putting things into variables and so forth, but what they gloss over is that you still retain state, you just put it all on the either the program stack or continuation stack or some other internal stack where the programmer cannot see it, or test it or verify it. Or control it.

Until they find a way to prove that the FP interpreter or compiler (usually written in C!) cannot corrupt it's own stack, every other claim of proveability is built on sand.

</soapbox>

[sleepingsquirrel]

Until they find a way to prove that the FP interpreter or compiler (usually written in C!) cannot corrupt it's own stack, every other claim of proveability is built on sand.

Sure, if the compiler has a bug, you're screwed. But how is that any different than the non FP case? It would be heaven-on-earth if we only had to worry about compiler bugs. Just compare how many bugs you find in you're own code, versus bugs in perl. There's a good reason why there are fewer bugs in a compiler than other code written in that language. Because more people use the compiler in more different ways. And most FP compilers (common lisps, haskell, ocaml, etc.) are self-hosted if for no other reason then it shows the compilier writers are willing to eat their own dog food.