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


Groups > comp.lang.lisp > #33009

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

From Kaz Kylheku <847-115-0292@kylheku.com>
Newsgroups comp.lang.lisp
Subject Re: symbol-macros -vs- symbol setf-expander
Date 2019-06-03 01:13 +0000
Organization Aioe.org NNTP Server
Message-ID <20190602174604.220@kylheku.com> (permalink)
References (5 earlier) <m2r28e1yg8.fsf@despina.home> <20190531112949.658@kylheku.com> <jwvy32mjn3p.fsf-monnier+comp.lang.lisp@gnu.org> <20190531193523.418@kylheku.com> <jwvmuj0j7z6.fsf-monnier+comp.lang.lisp@gnu.org>

Show all headers | View raw


On 2019-06-02, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> 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?

Well, (incf <whatever>) knows that <whatever> is a place. It asks
for the expansion with get-setf-expansion. But note that
get-setf-expansion takes an &environment parameter: it expands the place
first: first X goes to (synthetic-place...) and then to G. THen
get-setf-expansion will get the expansion of G and return that.
incf then works with that expansion.

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

Ah, but what if the access form of this global (bar ...j) place is simply
the (bar ...) function call? (The overwhelmingly common case).

That call will go to the local function. (incf (bar ...)) will call
the local funtion to get the value, but use the store form from the the
global setf expansion, like (bar-set ... new-value) or whatever.

The situation is half-baked between global and local.

However, with a macrolet, the user expects to hijack the (bar ...)
form completely, in all its uses. If we macrolet (bar ...) to (car ...),
we want (setf (bar ...) x) to do (setf (car ..) x) and forget the global
(bar ...) place.

This is why the CL approach is justifiable.

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