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

[Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>]

Drew Adams wrote:

>>>> 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.

Hm ... interesting. Yeah, maybe we should start do that more?

But I'm unsure even what is the entry point...

What kind of things or problems could or should you solve
with macros?

-- 
underground experts united
https://dataswamp.org/~incal