Macros (Was: Interesting: "Lisp as a competitive advantage")
Mon, 07 May 2001 12:38:31 +0200
Keith Wansbrough quotes :
> Jerzy Karczmarczuk <firstname.lastname@example.org> writes:
> > Macros in Scheme are used to unfold n-ary control structures such as COND
> > into a hierarchy of IFs, etc. Nothing (in principle) to do with laziness
> > or HO functions.
> Isn't this exactly the reason that macros are less necessary in lazy languages?
> In Haskell you can write
> myIf True x y = x
> myIf False x y = y
> and then a function like
> recip x = myIf (abs x < eps) 0 (1 / x)
> works as expected. In Scheme,
> (define myIf
> (lambda (b x y)
> (if b x y)))
> does *not* have the desired behaviour! One can only write myIf using
> macros, or by explicitly delaying the arguments.
Well, my point was very different *here*. Lazy functions *may* play the role
of control structures (as your myIf in Haskell). In Scheme, with macros or
without macros you CANNOT implement "if". But you can write
(cond (cond1 seq1)
(cond2 seq2 etc)
(condN und so weiter) )
(if cond1 seq1
(if cond2 (begin seq2 etc)
(if ... )))
In the same way the LET* constructs are developed. And a multifunction
So, here it is not the question of laziness, but of syntactic extensions.
(Of course, one can "cheat" implementing a user-defined IF as you proposed
above, delaying the last two arguments of this ternary operator, but the
decision which one will be evaluated, will pass through the "real" IF anyway.)
However, if you have already your primitive control structures (i.e. your
underlying machine), you can play with macros to implement lazy continuations,
backtracking, etc.Usually this is awkward, and less efficient than if done
at a more primitive level, where you can use easily unboxed data stored on
true stacks, execute real, fast branching, etc.
I am not sure about this vise-grip analogy. For me macros are fašades, a way
to present a surface of the programm. The real work, where you need wrenches,
pipes, dynamite and Bible, all that is hidden behind.