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

Groups > comp.lang.lisp > #33005

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

Show all headers | View raw

On 2019-05-31, Pascal J. Bourguignon <pjb@informatimago.com> wrote:
> Kaz Kylheku <847-115-0292@kylheku.com> writes:
>
>> On 2019-05-31, Pascal J. Bourguignon <pjb@informatimago.com> wrote:
>>> Kaz Kylheku <847-115-0292@kylheku.com> writes:
>>>>
>>>> The define-setf-expander call in placelet1 is useless and can be
>>>> removed. …
>>>>
>>>> Lucky for as, …
>>>>
>>>> The approach will fail …
>>>
>>> Why would you consider an approach that will fail???
>>
>> It might fail to expand due to a form having no setf expansion being
>> used as a place. The placelet1 macro could be easily refined to detect
>> the situation, and provide an accurate diagnostic.
>>
>> Why I would consider the approach is that it's very simple and
>> doesn't rely on any non-portable features.
>>
>> At least it's worth noting/documenting: "if we are able to take a
>> certain requirement off the table, such and such highly simplified trick
>> is possible which handles the remaining requirements".
>
> Furthermore, even if one call to get-setf-expansion gives you a result
> such as (cdr #:foo), it doesn't mean that another call (notably with a
> different &environment, but possibly for any reason (eg. different

Since CL doesn't have lexical setf-expansions, I think the enviornment
is only used (and necessary) for expanding macros. So that is to say, if
we want to obtain the setf expansion for some (foo) form, that form
could be a macrolet in the given context. get-setf-expansion has to
have the environment to resolve that.

> optimization level, different run-time (OS where the same executable
> runs), etc could have given a different expression for the getter, one
> one hand, and on the other hand, there's also no guaranteed that the
> expression given by the getter be actually a place.  Eg. you could get a
> (kdr #:foo) instead, with no (setf kdr).

Yes. I constructed "artificial" places exactly like this when testing
exploratory code in this area. This kind of place reliably produces
an error when the code is doing it wrong.

> So basically, you need to perform the test, visually, which is worse
> than automatically, but you can also do it automatically, but it all
> comes down to perusing the section 5.1.2.2.
> http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/sec_5-1-2-2.html
> Ie. you must make the decision when you write the code.

That doesn't really help.

The solution is conceptually very simple: we create a temporary place
like (#:G0025) which defers to the original place, using its access
and store forms (my code shows this). We bind the desired alias symbol S
to this (#:G0025) form and fully expand the code.  All S's get converted
to (#:G0025) and further, the expansion expand all (#:G0025) occurrences
that are used as places. The these expansions will use the correct
access and store form.  Occurrences of (#:G0025) that are not used as
places will stay unexpanded as (#:G0025); that symbol has no binding in
the function/operator space.  We then set up macrolet which binds
(#:G0025) to the access form, and inject that expanded code into that
macrolet; that code is our result.  Thus the remaining occurrences which
are pure accesses use the correct form also.

We can't do this in one phase, because if we simultaneously have a S
symbol macro expanding to (#:G0025) and a macrolet expanding (#:G0025)
to the access form, these expansions both happen first; every single S,
whether used as a place or not, is first reduced through (#:G0025) down
to the the access form and we are back to square one: uses of S as a
place are using the access form to deduce the store.

This is the very situation exemplified in the code: the (macrolet ...
(symbol-macrolet ...)) are combined into one piece of code with a single
expansion phase, and that is the reason why the define-setf-expander
form makes no difference, as the comment says. When the symbol-macrolet
and macrolet expand, nothing is left in the code that interacts with the
"proxy-place"; the code just contains references to the access form
of the original place.

Also, if we do fully expand the body code, then the proxy place
(#:G0025) is no longer needed. We would like to delete it to reduce
polution; alas, however, CL doesn't give us a portable way to undo the
effect of define-setf-expander. In some systems it's keyed to a property
of the symbol and whatnot.

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