Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.lisp > #33009
| 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> |
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
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