| Joachim Durchholz 2005-11-03, 7:01 pm |
| Andre schrieb:
> - Modularity: being able to change the implementation
> from e.g., thunks to monads without having to change all the use sites.
Ah, that's the "exposes internal implementation" criticism - it meant
"exposing the internal implementation of the 'until' construct".
Well, I'm not sure that this is a serious issue in an FPL context. If
all you have are closures, then there isn't much variation here. I think
the variation that we have observed is more because "until" is an
inherently imperative construct, something that isn't needed in
side-effect-free FPL programming. You don't then need two cooperating
closures.
A better example would be "iterate over a list and return some condensed
information". For historical reasons, this is commonly called a "fold"
and looks like this:
fold op zero list
E.g. to get the sum of all elements of integer_list, you write
fold (+) 0 integer_list
One could do that using macros, but it's not necessary: fold is a simple
higher-order function (a three-liner including the type signature IIRC).
There exists a multitude of such operators. They can slice and dice
lists in about any way imaginable. There are operations to split and
merge lists, to transform them.
I don't need "until" if I put everything into lists and have these
operators work on these :-)
OK, lists aren't suitable for every task in computation. They suck if
you need to operate on many elements at once, or need to select a few
items in them at random. There are other data structures that can do
this, of course, and these also come with the appropriate HOFs for
slicing and dicing.
Do I need macros? Not really: I have all the data structures I want, and
the operations to transform them as needed.
> - Optimization: The macro might construct thunks behind the
> scenes, but does not have to. A syntax that is agnostic with
> respect to this detail is arguably better than a HOF that isn't,
> for a looping construct where performance might be important.
FPL compilers are usually quite good at optimising this kind of closure
("thunk" in your terminology) away.
Regards,
Jo
|