| Andre 2005-11-07, 10:03 pm |
| Dirk Thierbach wrote:
> If you keep it purely functional, then I don't think so. I'd say
> there's is really just one canonical way to do an until-loop. The
> only thing that changes is presentation and syntax.
Let's be purely functional and take Clean, for example. There it
might be most natural to use uniqueness types. I could change the
implementation - perhaps making it easier to port to Haskell - by
wrapping things up in a monad, in which case the do-until interface
would be different, even though there may be a canonical underlying
isomorphism. A macro would allow me to make this change of implementation
without needing to change all the use sites throughout
my code base.
By the way, why indeed does Haskell have
the "do" notation? Isn't "do" a macro, after all?
Wouldn't it have been nice not to have had to wait for a new version
of each of the compilers to have access to the "do" notation when
it was initially introduced? Is "do" going to be the only such
notation that will ever be useful? What if you come up with
a wonderful new DSL analogous to "do" for, say, arrows, that made
thinking about them so much easier, and wanted to use it in writing
and portably sharing programs?
> Maybe there's a misunderstanding here. It's the *idea* of an
> until-loop which implies the use of side effects. HOFs and
> side-effects are orthogonal concepts, they don't imply each other.
My statement was that the thunk implementation required side
effects. I am aware that a monadic implementation does not.
> I chose the Haskell example with monads because if you want
> side-effects, then in Haskell you have no other choice but to use
> monads. So, in Haskell, there is *no* other way, even with macros,
> to implement an until-loop with side effects, but to use monads.
That seems wrong. You could explicitly pass a store as an extra
argument, to give just one alternative.
> And in the end, as other people have observed, I'd argue it is actually
> *better* to use one universal way to parametrize abstractions.
So which universal way is it going to be? The monadic one, the store-
passing one, the CPS one ... ;-)
> One thing that I really hate about many macros I have seen is the
> unsystematical, ad-hoc way in which they treat they arguments.
This would indeed be bad if it were true. However, macros do not have
arguments. Asserting that they do is like asserting that the phrase
"i <- readIORef v" is an argument of "do" in the following:
(do { i <- readIORef v; return (i == 5) })
However, I do not think many Haskellers would agree with such an assertion.
> (If it's not obvious to you why monads imply an ordering on
> side effects, someone in this NG has written a nice introduction of
> monads for Lispers some time ago. Google should be able to find it.)
No need. I wrote one of those introductions ;-)
>
> Yes, one of the things that macros give you is *control* over
> run-time vs. compile-time evaluation. Sometimes that is important.
My point was not that the macro gave you that control. It was that
the HOF explicitly committed you to extra, unnecessary steps in the
evaluation model that might indeed be optimized away, but also
might not. The macro does not commit you to this.
The fact that the idea of inlining optimizations even occurs to
us at the use site comprises a conceptual barrier, however slight,
that has nothing to do with the actual semantics of the loop we
are trying to write.
> Macros are
> sometimes nice to have, but you can go a long way without them. And
> while there's a number of reasons why it's more conveninient to use
> macros in Lisp, I have the impression that this tends to make
> people a bit unnecessarily "preachy" about them, while at the same
> side blinding them to alternatives. But maybe that's just my
> impression :-)
I agree that macros can be, and are, abused, as are HOFs and everything
else. But stating, as some on this thread have done, that syntactic
abstraction is useless, when such a statement is made from lack of
understanding and actual experience with syntactic abstraction, is
as ignorant as the oft-repeated claims in some circles that HOF-based
abstraction is useless.
Cheers
Andre
|