|
| Dirk Thierbach wrote:
>
> Andre <andre@het.brown.edu> wrote:
>
> I don't follow that. In what why does the HOF approach expose the
> internal implementation? By abusing side-effects? Or what idea is
> behind this? Example?
I just meant that there are many ways of implementing a
do-until construct, many of which do not require the thunks needed
by the one HOF example (which imply the use of side effects, as you
observe), or the monadic types used in the other HOF example.
A macro can be used to hide this detail, and can be justified by the
same arguments used for any other kind of abstraction.
These include:
- Modularity: being able to change the implementation
from e.g., thunks to monads without having to change all the use sites.
- 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.
Cheers
Andre
|
|