Re: [nongnu] elpa/geiser bb9d5cb200: geiser-impl--normalize-method: quick fix for previous change

Re: [nongnu] elpa/geiser bb9d5cb200: geiser-impl--normalize-method: quick fix for previous change

[Stefan Monnier]

>      (let ((v (cadr m)))
> -      (if (functionp v) m
> -        `(,(car m)
> -          ,(lambda (&rest _) v))))))
> +      (if (functionp v) m `(,(car m) (lambda (&rest _) ,v))))))

But this reintroduces the use of a list-that-looks-like-a-function
instead of a true function.

BTW, one difference I can see is that the new code will basically pass
`v` to `eval` whereas the code I had sent considers `v` to be
a value already.

So maybe the code I should have sent is along the lines of the
patch below?


        Stefan


diff --git a/elisp/geiser-impl.el b/elisp/geiser-impl.el
index 53a7a824c3..3bc5af5e55 100644
--- a/elisp/geiser-impl.el
+++ b/elisp/geiser-impl.el
@@ -158,7 +158,7 @@ in order to determine its scheme flavour."
              (= 2 (length m))
              (symbolp (car m)))
     (let ((v (cadr m)))
-      (if (functionp v) m `(,(car m) (lambda (&rest _) ,v))))))
+      (if (functionp v) m `(,(car m) ,(lambda (&rest _) (eval v t)))))))
 
 (defun geiser-impl--define (file name parent methods)
   (let* ((methods (mapcar #'geiser-impl--normalize-method methods))

Re: [nongnu] elpa/geiser bb9d5cb200: geiser-impl--normalize-method: quick fix for previous change

[Jose A Ortega Ruiz]

On Fri, Jan 28 2022, Stefan Monnier wrote:

>>      (let ((v (cadr m)))
>> -      (if (functionp v) m
>> -        `(,(car m)
>> -          ,(lambda (&rest _) v))))))
>> +      (if (functionp v) m `(,(car m) (lambda (&rest _) ,v))))))
>
> But this reintroduces the use of a list-that-looks-like-a-function
> instead of a true function.

yes... i just wanted to push quickly a fix for users of the unstable
version, and then think about it.

>
> BTW, one difference I can see is that the new code will basically pass
> `v` to `eval` whereas the code I had sent considers `v` to be
> a value already.

yes, that's the problem: v is the name of a variable, and we want to
evaluate its value when the function being defined is called, not when
the function is defined.

> So maybe the code I should have sent is along the lines of the
> patch below?

yes, that works, but i find it ugly to use eval explictly for the sake
of not using "a list-that-looks-like-a-function": what are the downsides
of the latter?  i understand that i'd be just hiding an implicit eval,
but is that all, or am i missing other drawbacks? (isn't, loosely
speaking, hiding evals one of things macros buy us?... the
version without eval looks more readable to me).

thanks,
jao
-- 
God is real, unless declared integer.

Re: [nongnu] elpa/geiser bb9d5cb200: geiser-impl--normalize-method: quick fix for previous change

[Stefan Monnier]

> yes, that works, but i find it ugly to use eval explictly for the sake
> of not using "a list-that-looks-like-a-function":

To me, it's being more honest: we have a variable that holds an ELisp
expression, so we need `eval` somwehere.

> what are the downsides of the latter?  i understand that i'd be just
> hiding an implicit eval, but is that all, or am i missing
> other drawbacks?

There's no serious drawback, no.  Here are some minor drawbacks:
- In Common-Lisp and Scheme '(lambda () 5) does not evaluate to
  something recognized as a function.  Currently ELisp does, but I think
  it's something better avoided.  I hope in some distant future we can
  make the types `function` and `cons` be a mutually-exclusive.
- the function value `(lambda () ,v) returns a function that will
  evaluate v using the old dynamically-scoped dialect which we're trying
  to phase out.

> (isn't, loosely speaking, hiding evals one of things macros
> buy us?

`eval` is used sometimes in macros, but most macros neither use nor hide
`eval`, AFAIK, no.

> ... the version without eval looks more readable to me).

My own taste is reflects in the fact that my local Emacs rejects
(lambda ...) as a valid function value ;-)


        Stefan

Re: [nongnu] elpa/geiser bb9d5cb200: geiser-impl--normalize-method: quick fix for previous change

[Jose A Ortega Ruiz]

On Fri, Jan 28 2022, Stefan Monnier wrote:

>> yes, that works, but i find it ugly to use eval explictly for the sake
>> of not using "a list-that-looks-like-a-function":
>
> To me, it's being more honest: we have a variable that holds an ELisp
> expression, so we need `eval` somwehere.
>
>> what are the downsides of the latter?  i understand that i'd be just
>> hiding an implicit eval, but is that all, or am i missing
>> other drawbacks?
>
> There's no serious drawback, no.  Here are some minor drawbacks:
> - In Common-Lisp and Scheme '(lambda () 5) does not evaluate to
>   something recognized as a function.  Currently ELisp does, but I think
>   it's something better avoided.  I hope in some distant future we can
>   make the types `function` and `cons` be a mutually-exclusive.
> - the function value `(lambda () ,v) returns a function that will
>   evaluate v using the old dynamically-scoped dialect which we're trying
>   to phase out.

ok, that sounds mildly persuasive, and it's always good to plan for the
next 50 years...

>> (isn't, loosely speaking, hiding evals one of things macros
>> buy us?
>
> `eval` is used sometimes in macros, but most macros neither use nor hide
> `eval`, AFAIK, no.

i was thinking of the fact that a (non-hygienic) macro essentially
produces a list that is then evaluated for me implicitly.  but anyway,
it was just a loose association.

>> ... the version without eval looks more readable to me).
>
> My own taste is reflects in the fact that my local Emacs rejects
> (lambda ...) as a valid function value ;-)

i've pushed a patch using eval... why, it'd be a shame if you couldn't
use geiser! ;)

thanks,
jao
-- 
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."
  -Terry Pratchett, Reaper Man