Re: Microlight
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Microlight
- From: Philipp Janda <siffiejoe@...>
- Date: 2012年12月18日 14:48:36 +0100
Hi!
Am 18.12.2012 13:29, schrieb Peter Aronoff:
On Tue Dec 18 2012 @ 12:42, Dirk Laurie wrote:
I've analyzed to myself why I felt much more enthusiastic
about Microlight in February than I do now. It's simple: I've
been off Python for ten months longer. I don't feel a need
for e.g. `class`, `callable`, `map` and `filter` any more. I find it
more readable to write the equivalent in plain Lua. The jury
is still out on `range`.
I'm curious about the end: "I find it more readable to write the equivalent
in plain Lua." I've been using Lua more and more lately (instead of Ruby or
Bash or previously Perl), and I already have my own general-purpose utility
module that includes `map`, `filter`, `partition`, etc. I understand the
idea that they are simple to write in plain Lua, but why would you ever
want to write them *twice* in plain Lua? (Just curious, not trolling.)
Everything IMHO, of course:
map and filter are good examples. Every possible map- or filter-function
(I can imagine) is not as flexible (and not as clear) as using Lua's
built-in language features. For example, does your map function take an
array (w/o holes?), a general table, or an iterator as input? Does it
return an array, a general table, an iterator, or nothing at all
(typically called each instead of map)? What if I need one of the other
possibilities? Does the modification function only influence the values
or the keys too (or in case of the iterator version: How many values can
be modified by the function)? Named modification or predicate functions
are not as general as you would like, because they might have to handle
that extra useless parameter passed by map/filter. And you can't break
(you could throw and catch an error for that, though).
Then there are performance reasons: You always need a modification
function -- possibly a closure -- for map, even if the modification is
trivial. If you combine map and filter, you will get temporary tables
(or closures in the iterator case).
And last but not least you add a dependency to your utility module to
your code although it would be trivial to avoid it.
And everything because you want to write:
map( filter( t, is_odd ), function( _, v ) print( v ) end )
instead of:
for i,v in ipairs( t ) do
if is_odd( i ) then
print( v )
end
end
(And of course I could write it on one line, but try to wrap/indent the
line above in a meaningful way ...)
Can't say anything about partition, though, since I don't know what it's
supposed to do.
P
Philipp