in reply to RFC: Tool::Box
First, this is a mighty fine idea. It reduces the cost of certain
common operations, even if hand-coding them is already inexpensive.
More importantly, it solidifies common idioms behind descriptive
names that the community can incorporate into its collective
vocabulary.
Second, the all-caps are a bit much. (They burn my eyes.)
Third, I like the pre-loading refinement. (Personally, I wouldn't
use them like this:
my $min = MIN(1..10)->();
because I find this more pleasing:
my $min = MIN->(1..10);
)
But the refinement does have value for finding min-maxes and max-mins:
my $max_of_at_least_zero = MAX(0);
$max_of_at_least_zero->($_) while <>;
# ...
Fourth, let's load the tool-box up! How about some new additions?
- read_all – slurp filehandle
- read_all_from_path – open, slurp, close
- zip – merge parallel arrays
- zip_with – merge parallel arrays with a given "zipper" function
- foldl, foldl1, foldr, foldr1, scanl, scanl1, scanr, scanr1 – more friends from functional programming
- curry – everybody loves curry
Thanks for getting the ball rolling.
Cheers, Tom
Re^2: RFC: Tool::Box
by Limbic~Region (Chancellor) on Nov 16, 2004 at 14:07 UTC
|
tmoertel,
- First, this is a mighty fine idea...
Thank you. I think it might be, but I would have preferred to hear from some relative newcomers.
- Second, the all-caps are a bit much...
I have changed them. I am not sure why I used all caps as I don't normally.
- Third, I like the pre-loading refinement...
This was a hard decision with regards to DWIM. I would have preferred to have the ability in calling syntax to determine if they just want to run one time and get an answer versus returning a function. This seemed like an acceptable comprimise.
- Fourth, let's load the tool-box up! How about some new additions?...
I am more than happy to be a co-author. We would decide when/if we release it who is responsible for maintenance.
| [reply] [d/l] |
|
You can tell CPAN that you are co-maintainers so that both of you can upload new versions.
| [reply] |
Re^2: RFC: Tool::Box
by Limbic~Region (Chancellor) on Nov 20, 2004 at 21:22 UTC
|
tmoertel,
I decided to get rid of max/min even if it is more functional than what List::Util provides. I think the only List::Util function worth making a closure out of is reduce.
Additionally, I changed the calling syntax a bit. If you call a function with an argument list it will return the result of that list instead of a function. The trouble, as pointed out by diotalevi, is what to do if it is called with an empty list/array. Perhaps using different function names?
Update:Slight modification (removing a function) after diotalevi pointed out it was equivalent to another List::Util function | [reply] [d/l] |
|
Why do you define the anonymous subroutine every time you call the function? Your anonymous subs aren't closures - they're just anon subs. They don't close over anything, let alone anything in @_. Your functions would be much faster if you define the subrefs ahead of time. Your functions would also be simpler because they just dispatch to the subref or return it, as needed.
Another item - you make the same mistake nearly every unique'ing function makes: what if I want to find unique objects or hashrefs? Much better is @uniq{@_} = @_; values %uniq. That way, you also respect any overloaded stringification I might use. Your uniq_ordered() function doesn't have this mistake.
Being right, does not endow the right to be rude; politeness costs nothing. Being unknowing, is not the same as being stupid. Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence. Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.
| [reply] [d/l] |
|
dragonchild,
I think the fact that the code morphed from being nothing but closures to being either/or depending on if called with an argument list made the code confusing. The commentary and the POD did explain this however. You say that none of the anonymous subs close over anything.
sub ave {
my $tot;
my $cnt;
my $find_ave = sub {
$cnt += @_;
$tot += $_ for @_;
return $cnt ? $tot / $cnt : undef;
};
return @_ ? $find_ave->( @_ ) : $find_ave;
}
This is true if ave is called like print ave(5, 10, -1, 7.3); as the anonymous sub is executed and the value 5.325 is returned - that's the way it was designed. If on the other hand, the code is called like my $ave = ave();, there most certainly is a closure returned - it closes over both $cnt and $tot. I am guessing the ternary use of @_ made you think I was trying to close over something in @_? Perhaps it would have been more clear (and better) if I had not modified the original code and re-written it as:
sub ave {
my ($cnt , $tot);
if ( @_ ) {
$cnt += @_;
$tot += $_ for @_;
return $cnt ? $tot / $cnt : undef;
}
else {
return sub {
$cnt += @_;
$tot += $_ for @_;
return $cnt ? $tot / $cnt : undef;
};
}
}
Another item - you make the same mistake nearly every unique'ing function makes...
Thanks. While the POD doesn't make any promises like that, I think it would be better off that way.
Updated: I was grumpy when I first replied as I had just woken up. Modified tone slightly to be less combative.
| [reply] [d/l] [select] |
|
|
|
|
In order for a library to be useful, programmers must understand it. A
chimera-like interface that shifts depending on the number of arguments
passed to a function or upon magic use-time flags only places hurdles
on the track to understanding. I'm squarely with diotalevi: The
interface should be clear and unchanging.
I recommend having separate functions for each behavior. For
example, we could use the _acc suffix to denote accumulating
functions that can be used to accumulate results iteratively. As long
as we are clear and consistent in our usage, we can deliver both
accumulating and non-accumulating functionality without making the
library harder to understand.
One possible implementation:
# factor out accumulating behavior:
sub make_acc_fn(&@) {
my $f = shift;
$f->(@_);
$f;
}
# mean
sub mean { mean_acc(@_)->() } # all-at-once version
sub mean_acc { # accumulating-function version
my ($tot, $cnt);
make_acc_fn {
$cnt += @_;
$tot += $_ for @_;
$cnt ? $tot / $cnt : undef;
} @_ ;
}
# uniq
sub uniq { uniq_acc(@_)->() }
sub uniq_acc {
my %uniq;
make_acc_fn {
@uniq{ @_ } = ();
wantarray ? keys %uniq : scalar keys %uniq;
} @_ ;
}
# examples
print mean(1,2,3,5), $/;
# 2.5
my $m = mean_acc();
print "$_ => ", $m->($_), $/ for 1..5;
# 1 => 1
# 2 => 1.5
# 3 => 2
# 4 => 2.5
# 5 => 3
print uniq(1,2,3,1..5), $/;
# 41325
my $u = uniq_acc(1,2,3);
print "$_ => ", $u->($_), $/ for 1..5;
# 1 => 132
# 2 => 132
# 3 => 132
# 4 => 4132
# 5 => 41325
Cheers, Tom
| [reply] [d/l] |
Re^2: RFC: Tool::Box
by ihb (Deacon) on Nov 17, 2004 at 10:03 UTC
|
For a read_all_from_path subroutine see File::Slurp (one of my must-have modules). An efficient read_all could probably be added there.
For zip, fold*, and scan* see Language::Functional. If you want a zip_with, patching Language::Functional would perhaps be a good idea.
For spices see Sub::Curry.
ihb
See perltoc if you don't know which perldoc to read!
Read argumentation in its context!
| [reply] |
|
|