Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.lisp > #33007

Re: symbol-macros -vs- symbol setf-expander

Show all headers | View raw

> I.e. given
>
>   (incf X)
>
> X gets replaced by (synthetic-place G S), nicely enough. But that is
> immediately recognized as a macro and taken to G. So we end up with
>
>   (incf G) ;; the access form; S ignored

That sounds positively wrong: expansion of `incf` should happen before
we can know that (synthetic-place G S) is a Lisp expression (as opposed
to some data used by the macro some other way) that can be
macro-expanded, right?

> Aha! Maybe in Elisp, the GV framework doesn't macro-expand a place if
> that place is registered as a GV, even if it exists as a macro also.
> I.e. it gives priority to the place?

Exactly: the equivalent of get-setf-expansion first looks for a place
definition and only if that fails it falls back to looking for
a macro definition.

That seems to be the only good choice.  I'm surprised, Common-Lisp is
not more careful with such ordering.  It seems "out of character"
(seeing how it was careful to specify ordering of macroexpansion of
top-level `progn` forms, for example).

> I think I may have experimented with that order in TXR Lisp, but
> for whatever reason, I ended up with the CL approach: always blindly
> expand all macros, and only consider the form as a place once it
> is fully expanded.

But that choice simply disallows macros that are also setf-expander.

> That could be the wrong approach: I will be certain to revisit that
> design decision. I do seem to recall I had a good reason.

It can be tricky to get it right, admittedly (e.g. you need to use
macroexpand-1 so as to be able to check for the presence of
a setf-expander after each step of macroexpansion).  We recently fixed
a bug in symbol-macrolet in this regard where it macroexpanded its args
before substituting them into the body.

> The opposite approach that I rejected does break macros in some ways.
> Say there is some global (foo) place. Now in my code, suppose I have a
> local macro (macrolet ((foo (...) ...))).  My code is not aware of the
> global foo. This local foo *is* used as a place in my code: (incf
> (foo)).  If this fails to expand my macro, but instead works with the
> global (foo) generalized place (giving it priority), that is surprising,
> and arguably breaks lexical scope: the macro should shadow everything.

I think this is a much more general problem: the place you define is
associated to the *symbol* foo and not to its macro definition.
The same holds for places defined on functions: if you define a global
function `bar`, then a place `bar` for it, and then use `flet` to
locally override this `bar` a `setf` will still use the global place you
defined, AFAIK.  Same if you globally redefine the global macro/function
without redefining the place.

For this reason, in Elisp I prefer writing:

    (defun FOO (ARGS)
      (declare (gv-expander ...))
      BODY)

over

    (defun FOO (ARGS) BODY)
    (gv-define-expander FOO ...)
    
even though currently, the implementation of the former just turns it
into the latter: at least the source code makes it clear that the
expander belongs to this particular function definition, and hopefully
in some future we will correctly associate the expander to the function
and not to its symbol.


        Stefan

Back to comp.lang.lisp | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

symbol-macros -vs- symbol setf-expander Stefan Monnier <monnier@iro.umontreal.ca> - 2019-05-21 15:46 -0400
  Re: symbol-macros -vs- symbol setf-expander Kaz Kylheku <847-115-0292@kylheku.com> - 2019-05-21 21:25 +0000
    Re: symbol-macros -vs- symbol setf-expander Kaz Kylheku <847-115-0292@kylheku.com> - 2019-05-22 20:07 +0000
      Re: symbol-macros -vs- symbol setf-expander Stefan Monnier <monnier@iro.umontreal.ca> - 2019-05-30 15:40 -0400
        Re: symbol-macros -vs- symbol setf-expander Kaz Kylheku <847-115-0292@kylheku.com> - 2019-05-31 04:51 +0000
          Re: symbol-macros -vs- symbol setf-expander "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-05-31 16:38 +0200
            Re: symbol-macros -vs- symbol setf-expander Kaz Kylheku <847-115-0292@kylheku.com> - 2019-05-31 18:42 +0000
              Re: symbol-macros -vs- symbol setf-expander "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-05-31 21:24 +0200
                Re: symbol-macros -vs- symbol setf-expander Kaz Kylheku <847-115-0292@kylheku.com> - 2019-06-01 02:34 +0000
              Re: symbol-macros -vs- symbol setf-expander Stefan Monnier <monnier@iro.umontreal.ca> - 2019-05-31 18:14 -0400
                Re: symbol-macros -vs- symbol setf-expander Kaz Kylheku <847-115-0292@kylheku.com> - 2019-06-01 02:51 +0000
                Re: symbol-macros -vs- symbol setf-expander Stefan Monnier <monnier@iro.umontreal.ca> - 2019-06-02 12:16 -0400
                Re: symbol-macros -vs- symbol setf-expander Kaz Kylheku <847-115-0292@kylheku.com> - 2019-06-03 01:13 +0000
        Re: symbol-macros -vs- symbol setf-expander Stefan Monnier <monnier@iro.umontreal.ca> - 2019-05-31 18:04 -0400
  Re: symbol-macros -vs- symbol setf-expander "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-05-22 22:00 +0200
    Re: symbol-macros -vs- symbol setf-expander a.daniel.eliason@gmail.com - 2019-05-23 08:10 -0700
      Re: symbol-macros -vs- symbol setf-expander Spiros Bousbouras <spibou@gmail.com> - 2019-05-23 15:22 +0000
        Re: symbol-macros -vs- symbol setf-expander Dimitri Fontaine <dim@tapoueh.org> - 2019-05-23 18:02 +0200
          Re: symbol-macros -vs- symbol setf-expander Spiros Bousbouras <spibou@gmail.com> - 2019-05-23 16:51 +0000
        Re: symbol-macros -vs- symbol setf-expander Kaz Kylheku <847-115-0292@kylheku.com> - 2019-05-23 17:05 +0000
          Re: symbol-macros -vs- symbol setf-expander "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-05-23 19:26 +0200
  Re: symbol-macros -vs- symbol setf-expander smh <shaflich@gmail.com> - 2019-05-22 18:47 -0700

csiph-web