Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.lisp > #33006
| From | Kaz Kylheku <847-115-0292@kylheku.com> |
|---|---|
| Newsgroups | comp.lang.lisp |
| Subject | Re: symbol-macros -vs- symbol setf-expander |
| Date | 2019-06-01 02:51 +0000 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <20190531193523.418@kylheku.com> (permalink) |
| References | (3 earlier) <jwv1s0fd9ej.fsf-monnier+comp.lang.lisp@gnu.org> <20190530214258.24@kylheku.com> <m2r28e1yg8.fsf@despina.home> <20190531112949.658@kylheku.com> <jwvy32mjn3p.fsf-monnier+comp.lang.lisp@gnu.org> |
On 2019-05-31, Stefan Monnier <monnier@iro.umontreal.ca> wrote: >> Why I would consider the approach is that it's very simple and >> doesn't rely on any non-portable features. > > I see the simplicity advantage, but not the portability advantage. > The way we'd implement it in Elisp, `placelet` would take the PLACE, > and extract from it a GETTER and a SETTER, and then do > > (symbol-macrolet ((X (synthetic-place GETTER SETTER))) ...) > > where `synthetic-place` is a globally defined generalized variable (as > well as a macro that just returns its first arg). This is the thing that fails in CL, which makes my code incorrect, as commented. Because if it's defined both as a macro that returns its first arg (alias for the getter) and as a generalized place then that macro always gets expanded, even if X is used as a place. 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 > In Elisp's `gv.el` this is very straightforward and portable and doesn't > require an assumption about the ability to re-construct the GETTER from > the SETTER. 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? 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. 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. 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. -- TXR Programming Lanuage: http://nongnu.org/txr Music DIY Mailing List: http://www.kylheku.com/diy ADA MP-1 Mailing List: http://www.kylheku.com/mp1
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