Re: [Maxima-discuss] (MEMBER ...) with literal symbol(s)

--000000000000cff4fd063428cf10
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, May 1, 2025 at 10:21=E2=80=AFPM David Scherfgen via Maxima-discuss =
<
[email protected]> wrote:

> Hello,
>
> I noticed that GCL 2.7.1 compiles these functions differently:
>
> (defun f (x) (member x '(a b c)))
> (defun g (x) (member x '(a b c) :test #'eq))
>
> I suppose that's because F uses the default EQL as the test. I tried to
> understand the C code it generated, but it was incomprehensible to me.
> Anyways, I saw that the second function, G, had inlined the MEMBER call
> into (OR (EQ X 'A) (EQ X 'B) (EQ Y 'C)), which is reasonable. But why doe=
s
> F get compiled differently?
>
> Shouldn't the compiler notice that the second argument to MEMBER is a
> literal list of symbols and automatically use EQ instead of the default E=
QL
> test? That would be an easy and safe optimization.
>
> The same goes for the case where the first argument to MEMBER is a litera=
l
> symbol.
>
> Maxima is full of such instances where MEMBER is used as a shorter way to
> write (OR (EQ ...) (EQ ...) ...), and ":test #'eq" has mostly been remove=
d
> because it was believed that any modern Lisp compiler would apply this
> optimization automatically. At least SBCL does. (CCL doesn't, I have file=
d
> a report already.)
>
Does it really matter that this conversion isn't done?

Another reason why we should have left memq around.  Then we could have
written a compiler macro to do the optimization we want.  Assuming it
really makes a difference.

--000000000000cff4fd063428cf10
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small"><br></div></div><br><d=
iv class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gm=
ail_attr">On Thu, May 1, 2025 at 10:21=E2=80=AFPM David Scherfgen via Maxim=
a-discuss &lt;<a href=3D"mailto:[email protected]">maxim=
[email protected]</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"auto">Hello,<div dir=3D"auto">=
<br></div><div dir=3D"auto">I noticed that GCL 2.7.1 compiles these functio=
ns differently:</div><div dir=3D"auto"><br></div><div dir=3D"auto">(defun f=
 (x) (member x &#39;(a b c)))</div><div dir=3D"auto">(defun g (x) (member x=
 &#39;(a b c) :test #&#39;eq))</div><div dir=3D"auto"><br></div><div dir=3D=
"auto">I suppose that&#39;s because F uses the default EQL as the test. I t=
ried to understand the C code it generated, but it was incomprehensible to =
me. Anyways, I saw that the second function, G, had inlined the MEMBER call=
 into (OR (EQ X &#39;A) (EQ X &#39;B) (EQ Y &#39;C)), which is reasonable. =
But why does F get compiled differently?</div><div dir=3D"auto"><br></div><=
div dir=3D"auto">Shouldn&#39;t the compiler notice that the second argument=
 to MEMBER is a literal list of symbols and automatically use EQ instead of=
 the default EQL test? That would be an easy and safe optimization.</div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">The same goes for the case wher=
e the first argument to MEMBER is a literal symbol.</div><div dir=3D"auto">=
<br></div><div dir=3D"auto">Maxima is full of such instances where MEMBER i=
s used as a shorter way to write (OR (EQ ...) (EQ ...) ...), and &quot;:tes=
t #&#39;eq&quot; has mostly been removed because it was believed that any m=
odern Lisp compiler would apply this optimization automatically. At least S=
BCL does. (CCL doesn&#39;t, I have filed a report already.)</div></div></bl=
ockquote><div><span class=3D"gmail_default" style=3D"font-family:arial,helv=
etica,sans-serif;font-size:small">Does it really matter that this conversio=
n isn&#39;t done?</span></div><div><span class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small"><br></span></div><di=
v><span class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small">Another reason why we should have left memq around.=
=C2=A0 Then we could have written a compiler macro to do the optimization w=
e want.=C2=A0 Assuming it really makes a difference.</span> </div><br></div=
></div>

--000000000000cff4fd063428cf10--