Re: Map and filter without intermediate tables

[joao lobato <btnfdp.lobato@...>]

On 6/7/12, steve donovan <steve.j.donovan@gmail.com> wrote:
> On Thu, Jun 7, 2012 at 1:06 PM, Geoff Leyland <geoff_leyland@fastmail.fm>
> wrote:
>> Yes, but if you have a function generating a sequence and a series of
>> sequence processors that might do things like map or filter that sequence,
>> then you might consider avoiding intermediate tables, since there was
>> never a table in the first place.
>
> That was the idea behind pl.seq
>
> https://github.com/stevedonovan/Penlight/blob/master/lua/pl/seq.lua
>
> E.g,
>
>> f = stringio.open 'one\n\ntwo\nthree'
>> seq(f:lines()):filter('~','^t'):upper():printall()
> TWO THREE
>
> But I've never bothered to check the speed - I suppose the thing about
> iterators is that they are 'lazy lists', potentially infinite.
>
>> seq(function() return math.random(1,10) end):take(5):printall()
> 4 9 9 8 2
>
> Personally, I prefer method chaining to functional application, since
> my brain tends to work best left-to-right.
>
> steve d.
>
>

Yes, I can see why method chaining seems easier to follow when reading
code, but it is in contravention of [1] and I don't want to be stopped
by the police :-) .

Things like list comprehensions, pattern matching as it exists in
Haskell or Erlang, unification and backtracking in Prolog, deal with
"white boxes". By using them one is foregoing most encapsulation. When
programming in the large, encapsulation is everything. Of course they
are useful tools, but sometmes they feel like a very particular and
proprietary Phillips screwdriver. You keep those in the toolbox, the
hammer (the for loop in Lua or the recursion in a functional language)
should be in your belt.

[1] http://en.wikipedia.org/wiki/Law_of_Demeter