[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sbcl-devel
Subject:    Re: [Sbcl-devel] [Sbcl-commits] master: Remove a duplicated defconstant
From:       Douglas Katzman via Sbcl-devel <sbcl-devel () lists ! sourceforge ! net>
Date:       2019-03-09 0:41:55
Message-ID: CAOrNaszBrG1OUPUS9XUNwTag=HBZwy9DzK58LaUCkhUv7Z1-Gw () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


I think I will fix this once and for all by storing macros in the lexenv as
 (name macro lambda-expression-of-the-expander #<expander-function>)
rather than
 (name macro . #<expander-function>)
which relies on (function-lambda-expression F) to return the right thing.
It's more more cons cell, hardly worth worrying about.
This would also mean removing the change that you made in
https://sourceforge.net/p/sbcl/sbcl/ci/d4666477303b1def which was an
unportable version of that.

Another thing I'd like to see us do is stop storing the macrolet when the
sole purpose of the macrolet was to define the inline function.
In:
(declaim (inline foo))
(macrolet ((define-foo () '(defun foo () (blah))))
 (define-foo))
there is no need to capture DEFINE-FOO as part of the syntactic closure
environment of FOO.
I'm not of the best way to go about computing the "physical
environment"-like thing that FOO really needs, which is nothing.

[Attachment #5 (text/html)]

<div dir="ltr"><div dir="ltr">I think I will fix this once and for all by storing \
macros in the lexenv as<div>  (name macro lambda-expression-of-the-expander \
#&lt;expander-function&gt;)</div><div>rather than</div><div>  (name macro . \
#&lt;expander-function&gt;)</div><div>which relies on (function-lambda-expression F) \
to return the right thing.</div><div>It&#39;s more more cons cell, hardly worth \
worrying about.</div><div>This would also mean removing the change that you made in  \
<a href="https://sourceforge.net/p/sbcl/sbcl/ci/d4666477303b1def">https://sourceforge.net/p/sbcl/sbcl/ci/d4666477303b1def</a> \
which was an unportable version of that.</div><div><br></div><div>Another thing \
I&#39;d like to see us do is stop storing the macrolet when the sole purpose of the \
macrolet was to define the inline function.</div><div>In:</div><div>(declaim (inline \
foo))</div><div>(macrolet ((define-foo () &#39;(defun foo () (blah))))  </div><div>  \
(define-foo))</div><div>there is no need to capture DEFINE-FOO as part of the \
syntactic closure environment of FOO.</div><div>I&#39;m not of the best way to go \
about computing the &quot;physical environment&quot;-like thing that FOO really \
needs, which is nothing.</div><div><br></div></div></div>





_______________________________________________
Sbcl-devel mailing list
Sbcl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel


[prev in list] [next in list] [prev in thread] [next in thread]