Graham Barr writes:
| Not at all. foldr would have to enquire the array size the iterate backwards.
| reduce can do the same.
Ah, well here's where the implementation counts for all. foldr probably
(but not definately) would need to know the list size, but neither foldl
nor foldr need to flatten the list to work. This is important to me, as
that allows for arbitrarily long lists without absorbing all RAM known
to man, and allows list members to be 'generated' on the fly. Use the
fibonnaci numbers as an example.
If we can find a way to let an iterator to exit early from a folding
function, e.g., having found a fixed point or, more likely, throwing an
exception, then we may be able to avoid calculating the whole list;
which could have a positive impact in intensive calculations, and ties
like xDBM, DB_File, etc.
To me, the majority of these functions should be library functions ---
as they are in List::Util --- working with minimalist language support.
We can pretty much do all these things now (as List::Util amply
demonstrates); what I would like to discuss adding to the language is
1) a means to signal an early exit to the iterator,
2) a means to tell we're at the end of a list without having to
evaluate the list length as we start
3) a much more lightweight, and language built-in, mechanism for
currying these functions.
(3) may require more explanation, for those unfamiliar with functional
languages. I want to define sum, e.g., as
foldl 0 +, which is reduce { $a + $b } (0, @x) in current terms.
Now, I can build my own subr to do this,
$sum = sub { @_ ? shift + @_ : 0 }
or
$sum = sub { unshift 0, @_ unless @_; reduce { $a + $b } @_ }
(roughly) but that seems rather heavy; I would rather more like to just
define in terms of syntax not dissimilar to the above C<foldl 0 +>.
This might avoid specifying a new coderef every time I want to change
the sentinel value. The subr syntax is very off-putting if you want to
curry multiple functions together.
Now, I feel obliged, rightly or wrongly, to add a disclaimer:
I'm not trying to subvert Perl.
I'm not trying to reinvent the functional wheel.
I'm not going to start suggesting we remove assignment from the
language.
I am suggesting that this is a feature that Perl lacks, that I miss,
that it could have, that would significantly increase its expressive
power without negatively impacting its wondrous way.
And I feel that by being able to iterate over lists with map, grep,
fold[rl]/reduce{,_r}, whatever, _without pre-flattening the list_, we
could drastically increase the applicability of these constructs.
There, I'm done. 8*)
| Yes we steel the ideas, but we need to implement them in a perl-ish
| way.
Absolutely. I love the Perlish way, and don't wish to leave it. I'm
merely pointing out that the research has been done into functions
handling funtions & lists , and in particular, reduce is only one side
of a two-sided coin, so lets consider the other side now, rather than
discovering the need for it later and having to retrofit it.
| Please keep your comments on the list. If you don't make them public
| others won't know you have concerns.
Oops, that wasn't intentional --- I must have hit the wrong button.
Mx.
--
See, the stars are shining bright
Everything's all right tonight
-- (Martin L. Gore, Never Let Me Down Again)
