Lisp Macros, Delayed Evaluation and the Evolution of Smalltalk

Post by lispm » Wed, Mar 20, 2019, 8:00 AM UTC

_qbjt wrote: post #24

Macros work much better in homoiconic languages like Lisp than they do in other languages. Most of the code I write these days is in Elixir and I avoid macros unless absolutely necessary. The benefits generally don't outweigh the (long-term) costs.

  (postfix 2 3 + 3 *)

Post by mpweiher » Wed, Mar 20, 2019, 8:51 AM UTC

lispm wrote: post #28

mpweiher wrote: post #20

Earlier quoted context omitted.

> misconception that Lisp macros are mostly used to 'delay' evaluation. It was in the examples. No generalization to all of LISP was made or intended, though it would be interesting to make a survey study of actual macro usage by developers. It is also clear that you actually need the delay-evaluation mechanism in order to get something like "if" out of the language and into the library. > what Smalltalk calls 'block…

> It is also clear that you actually need the delay-evaluation mechanism in order to get something like "if" out of the language and into the library. In a functional programming language one can just use functions. (defun l-true (a b) a) (defun l-false (a b) b) (defun l-if (f a b) (funcall f a b)) True is a function, false is a function and if is a function. Now we can do conditional execution: CL-USER 57 > (l-if #'…

   #include 

   void a() { printf("true\n"); }
   void b() { printf("false\n"); }

   typedef void (*fnfn) ();

   void fnif(int cond, fnfn trueCase, fnfn falseCase )
   {
        fnfn switcher[2]={ falseCase, trueCase };
        switcher[cond](); 
   }

   int main(int argc, char *argv[] ) {
       fnif( 0, a,b ); 
   }

Post by mpweiher » Wed, Mar 20, 2019, 9:04 AM UTC

lispm wrote: post #31

_qbjt wrote: post #24

Macros work much better in homoiconic languages like Lisp than they do in other languages. Most of the code I write these days is in Elixir and I avoid macros unless absolutely necessary. The benefits generally don't outweigh the (long-term) costs.

One of the differences between macros in Lisp and some other languages which provide macros is that the expressions themselves don't need to be valid code in some programming language -> they don't get parsed by a language parser upfront. Thus I can write a postfix macro and then write code like this: (postfix 2 3 + 3 *) even though Lisp requires code to be nested prefix expressions. Some other languages won't allow…

Post by mpweiher » Wed, Mar 20, 2019, 10:25 AM UTC

User23 wrote: post #26

Algol 60 is wildly underappreciated, and pass by name[1] is a great example. [1] http://www.cs.sfu.ca/~cameron/Teaching/383/PassByName.html Edit: An elementary error is to assume that call by name is equivalent to pass by reference. It's not.

Post by lispm » Wed, Mar 20, 2019, 10:33 AM UTC

hibbelig wrote: post #32

lispm wrote: post #16

Earlier quoted context omitted.

That's why I wrote 'more like'. Given that you haven't defined any semantics of your operators, it's more like a guess. Not sure if this helps you. But let's define a macro A: CL-USER 32 > (defmacro a (b c) (print (list :macro-expansion b c)) (list 'print (list 'quote (list :runtime :b b :c c)))) A This macro does two things: it prints something at macro expansion time and then generates some code it returns as a val…

A normal function call evaluates the arguments and then calls the function. Because macro expansion does something before evaluating the arguments, you can say that evaluating the arguments has been delayed. I feel this is just looking at the same thing from two different directions. Of course, macro expansion does _more_ than just delaying the evaluation of the arguments, and if people say that macros delay evaluati…