Re: Macros (Was: Interesting: "Lisp as a competitive advantage")

Jerzy Karczmarczuk
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. --KW 8-)

Keith Wansbrough quotes :
Jerzy Karczmarczuk
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) ) translated into (if cond1 seq1 (if cond2 (begin seq2 etc) (if ... ))) In the same way the LET* constructs are developed. And a multifunction DEFINE. 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. Jerzy Karczmarczuk Caen, France

"Keith" == Keith Wansbrough
writes:
Keith> Jerzy Karczmarczuk
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.
Keith> Isn't this exactly the reason that macros are less necessary in Keith> lazy languages? Keith> In Haskell you can write Keith> myIf True x y = x Keith> myIf False x y = y Sure, but you're relying on pattern matching to implement the semantics of myIf, which already is a generalized conditional. In Scheme, where pattern matching is not primitive, you can get it through a macro. The same holds for things like DO notation or list comprehensions, where apparently lazy evaluation by itself doesn't help implementing convenient syntax atop a more primitive underlying notion. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla
participants (3)
-
Jerzy Karczmarczuk
-
Keith Wansbrough
-
sperber@informatik.uni-tuebingen.de