| Dirk Thierbach 2005-11-07, 10:03 pm |
| Andre <andre@het.brown.edu> wrote:
> Dirk Thierbach wrote:
[color=darkred]
> 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.
I still don't think that could be done. Can you give an example
how a macro would translate the same expression either to a
uniqueness-type or a monadic implementation? Without changing the
call sites, and without having the monadic information at the
call sites in the first place?
(Interpreting a monad in terms of uniqueness types is trivial, of
course, and you don't need macros for that -- an appropriate typeclass
works fine).
> By the way, why indeed does Haskell have the "do" notation?
As I said, the argument seemed to have been that it makes it easier
for imperative programmers to understand the notation (in the same way
list comprehension makes it easier for mathematicians to write some
stuff).
Maybe someone who actually was involved when that was decided can
comment.
> Isn't "do" a macro, after all?
It's thin syntactic sugar, and AFAIK it was debated if it was really
necessary.
> 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?
The point is not that syntactic sugar, or a complete macro system, is
not nice to have. The point is that macro advocats frequently claim
that macros are so insanely powerful that nothing can compete with
them. For many cases, that's just not true. For some cases, macros are
indeed great, and the only option -- but it really depends on your
application if you are going to hit such a case. So far, I have felt
the need to use macros only once, and that was with the object part of
OCaml, where HOFs cannot be used.
> 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?
You can implement Arrows just fine with the available languages
constructs (that's what the library does). If you think syntactic
sugar is important, then you (surprise!) just use a simple preprocessor.
Again, the point is that these kinds of usage are very superficial,
and don't contain a lot of "power". They are nice to have, but
are really only icing on the cake. The substance is elsewhere.
> My statement was that the thunk implementation required side
> effects.
Then maybe I don't understand the statement. Assuming that by
"thunk implementation", you mean the wrapping of some expression
inside a lambda, why does that *require* side effects? I'd rather
say that it "enables" side-effects by postponing the evaluation,
converting the strict evaluation order into a lazy one.
But maybe this point is not very important for this discussion.
> I am aware that a monadic implementation does not.
The monadic implementation basically uses the same trick: You wrap
everything into a function that is executed at the appropriate time.
Hence, monads also work under strict evaluation.
[color=darkred]
> That seems wrong. You could explicitly pass a store as an extra
> argument, to give just one alternative.
Assuming that by store you mean a state expression, then you wouldn't
have real side effects, but just pass around the state in a purely
functional way, as in the until-function from the Prelude.
Maybe an example to clarify? In Haskell, it's just not possible to use
side effects to assign to "variables" (i.e. references) outside a
monad.
[color=darkred]
> This would indeed be bad if it were true. However, macros do not have
> arguments.
I really don't mind what you call them. If you don't like the word,
suggest another one. But it's clear what I meant, isn't it?
> 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.
Yes, and I think I already agreed with 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.
Huh? Optimization and correctness should be completely unrelated.
There's no "conceptual barrier" I can see here.
[color=darkred]
> I agree that macros can be, and are, abused, as are HOFs and everything
> else.
The point is not that macros can be abused (as you say, everything can
be abused). The point is their evangelization above everything else by
some people.
> 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.
No kind of abstraction is "useless".
- Dirk
|