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


Groups > comp.lang.lisp > #33006

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

Show all headers | View raw


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


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