help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [External] : Re: Why is defun not executed during load-file?


From: Drew Adams
Subject: RE: [External] : Re: Why is defun not executed during load-file?
Date: Mon, 31 May 2021 05:05:57 +0000

> >> Also, writing macros compared to writing functions
> >> typically involves more bugs...
> >
> > Why do you think so? [...]
> 
> Maybe because it involves an extra layer, writing something
> that will write something that will do something instead of
> writing something that will do something...
> 
> Just keep on adding layers. Write something to write something
> to write something ... etc. It gets more difficult for each
> level added, is what we think.

Fair enough; reasonable argument.

But I still think the perceived difficulty comes
from relative lack of practice.  There are only 2
levels/layers involved.  And they're completely
separate: (1) macro-expansion of a sexp to a sexp,
and (2) evaluation of the sexp resulting from #1.

You write lots of Lisp functions.  And you no
doubt think nothing of adding "layers" by having
a function that calls a function that calls a
function...  Even inhibiting evaluation with
`quote' here and there doesn't seem weird, once
a novice practices a bit and gets used to it.
But all of that is (can be) really quite complex.

It's just that you do that all the time - you're
used to it.  You don't write Lisp macros all the
time.
___

The macro-expansion step is the only part that's
a bit unusual - it's different from most of the
Lisp code you write.

Think of that step as just replacing one sexp by
another.  The input sexp has the form of a Lisp
function call: a non-empty list whose car is a
symbol.

The output is normally a sexp of the same form,
but it need not be - it can be any Lisp value
(any list, vector, string, symbol, number,
buffer, frame, syntax table, keymap,...).  As
far as step #1 is concerned, its result need
not even be something that can be evaluated
- or even read - without error.

And you have Lisp completely at your disposal,
for creating the output sexp, given the input
sexp.
___

Once you have the macro-expansion step defined,
the job's typically done.  What's left is to
verify that the output sexp _evaluates_ to the
result you want - and that, for every possible
input.

That is, because the result of macro-expansion
(#1) is typically evaluated, you do have to
worry about that evaluation step (#2), yes.

But if you only ever used `macroexpand' of sexp
to sexp to sexp to sexp,... then you wouldn't
need to bother with that worry.  You'd just be
transforming one list with a symbol car to
another, to another, to another,...

Macro-expansion isn't evaluation; it's reduction.
Lisp evaluation rules don't apply to producing
the output sexp from the input sexp.  What rules
do apply?  Whatever rules you like.  The only
rule underlying it all is that the input needs
to be a list with a symbol car.

For those used to purely functional programming,
that's all macro-expansion is: just reduction -
term rewriting.  You can look at it as a rewrite
rule from input patterns to output patterns. But
the rule can be implemented any way you like,
using any Lisp code.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]