bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions

bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions

[Michael Heerdegen]

Hi,

two related little issues:

1.  `cl-flet's edebug spec only works with one allowed syntax, when all
bindings look like (FUNC ARGLIST BODY...).  The second possible syntax
(FUNC EXP) makes edebug barf, no edebugging possible :-(

2.  `cl-labels' doesn't allow expressions evaluating to functions.  But
I think we could allow lambda expressions.  Seems this would not even be
hard to do: the macro constructs a lambda expression anyway (if we do
this, we should take care of the edebug spec as well).  Oh - why I want
this?  Just a matter of taste, I just prefer a lambda expression to the
(FUNC ARGLIST BODY...) syntax.  And I think a (FUNC (lambda ...))
syntax would still be in line with the semantics.

What do you think?


Regards,

Michael.

bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions

[Michael Heerdegen]

[-- Attachment #1: Type: text/plain, Size: 331 bytes --]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Hi,
>
> two related little issues:
>
> 1.  `cl-flet's edebug spec only works with one allowed syntax, when all
> bindings look like (FUNC ARGLIST BODY...).  The second possible syntax
> (FUNC EXP) makes edebug barf, no edebugging possible :-(

Who knows if this is correct?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Extend-debug-spec-of-cl-flet.patch --]
[-- Type: text/x-diff, Size: 1100 bytes --]

From 3859414d19bc9de1593af7276decafe9b34ee628 Mon Sep 17 00:00:00 2001
From: Michael Heerdegen <michael_heerdegen@web.de>
Date: Tue, 19 Feb 2019 01:12:07 +0100
Subject: [PATCH] Extend debug spec of cl-flet

* lisp/emacs-lisp/cl-macs.el (cl-flet): Extend debug spec to cover
definitions of the form (FUNC EXP).
---
 lisp/emacs-lisp/cl-macs.el | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lisp/emacs-lisp/cl-macs.el b/lisp/emacs-lisp/cl-macs.el
index 5faa055f99..9f79b1a7cf 100644
--- a/lisp/emacs-lisp/cl-macs.el
+++ b/lisp/emacs-lisp/cl-macs.el
@@ -2044,7 +2044,9 @@ cl-flet
 info node `(cl) Function Bindings' for details.

 \(fn ((FUNC ARGLIST BODY...) ...) FORM...)"
-  (declare (indent 1) (debug ((&rest (cl-defun)) cl-declarations body)))
+  (declare (indent 1)
+           (debug ((&rest [&or (&define name form) (cl-defun)])
+                   cl-declarations body)))
   (let ((binds ()) (newenv macroexpand-all-environment))
     (dolist (binding bindings)
       (let ((var (make-symbol (format "--cl-%s--" (car binding))))
--
2.20.1


[-- Attachment #3: Type: text/plain, Size: 221 bytes --]


I wasn't sure if I need to use "def-form" instead of "form" (I guess
not) or if some "nil" or "gate" magic is needed in addition.

And to which branch should I install it if it happens to be correct?


Thanks,

Michael.

bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> 2.  `cl-labels' doesn't allow expressions evaluating to functions.  But
> I think we could allow lambda expressions.  Seems this would not even be
> hard to do: the macro constructs a lambda expression anyway (if we do
> this, we should take care of the edebug spec as well).  Oh - why I want
> this?  Just a matter of taste, I just prefer a lambda expression to the
> (FUNC ARGLIST BODY...) syntax.

Another reason why I got used to prefer lambda expressions, also for
cl-flet, is because elisp-mode indents the (FUNC ARGLIST BODY...) case
so badly:

(cl-labels ((f (x y z)
               (* x y z))))
vs.

(cl-labels ((f (lambda (x y z)
                 (* x y z)))))


Michael.

bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Another reason why I got used to prefer lambda expressions, also for
> cl-flet, is because elisp-mode indents the (FUNC ARGLIST BODY...) case
> so badly:
>
> (cl-labels ((f (x y z)
>                (* x y z))))

I wonder if (function-get 'cl-labels 'lisp-indent-function) should
better be bound to a suitable method function (which is allowed, but
seems not yet used anywhere).

Michael.

bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions

[Stefan Kangas]

Michael Heerdegen <michael_heerdegen@web.de> writes:

>> 1.  `cl-flet's edebug spec only works with one allowed syntax, when all
>> bindings look like (FUNC ARGLIST BODY...).  The second possible syntax
>> (FUNC EXP) makes edebug barf, no edebugging possible :-(

I also ran into this today.

> Who knows if this is correct?

The below patch fixes the problem for me at least.  If no one objects,
perhaps we could install it?  Or could it make matters worse?

> From 3859414d19bc9de1593af7276decafe9b34ee628 Mon Sep 17 00:00:00 2001
> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Tue, 19 Feb 2019 01:12:07 +0100
> Subject: [PATCH] Extend debug spec of cl-flet
>
> * lisp/emacs-lisp/cl-macs.el (cl-flet): Extend debug spec to cover
> definitions of the form (FUNC EXP).
> ---
>  lisp/emacs-lisp/cl-macs.el | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/lisp/emacs-lisp/cl-macs.el b/lisp/emacs-lisp/cl-macs.el
> index 5faa055f99..9f79b1a7cf 100644
> --- a/lisp/emacs-lisp/cl-macs.el
> +++ b/lisp/emacs-lisp/cl-macs.el
> @@ -2044,7 +2044,9 @@ cl-flet
>  info node `(cl) Function Bindings' for details.
>
>  \(fn ((FUNC ARGLIST BODY...) ...) FORM...)"
> -  (declare (indent 1) (debug ((&rest (cl-defun)) cl-declarations body)))
> +  (declare (indent 1)
> +           (debug ((&rest [&or (&define name form) (cl-defun)])
> +                   cl-declarations body)))
>    (let ((binds ()) (newenv macroexpand-all-environment))
>      (dolist (binding bindings)
>        (let ((var (make-symbol (format "--cl-%s--" (car binding))))
> --
> 2.20.1
>
>
> I wasn't sure if I need to use "def-form" instead of "form" (I guess
> not) or if some "nil" or "gate" magic is needed in addition.

I don't know either, unfortunately.  I have only tested and verified
it fixed the problem for me.

Best regards,
Stefan Kangas

bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions

[Michael Heerdegen]

Stefan Kangas <stefan@marxist.se> writes:

> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
> >> 1.  `cl-flet's edebug spec only works with one allowed syntax, when all
> >> bindings look like (FUNC ARGLIST BODY...).  The second possible syntax
> >> (FUNC EXP) makes edebug barf, no edebugging possible :-(

> The below patch fixes the problem for me at least.  If no one objects,
> perhaps we could install it?  Or could it make matters worse?

I don't think it could make it worse.  I also think now that it should
be correct.  AFAIU `def-form' doesn't need to be used but I think I
should use `function-form' instead of `form' so that quoted lambdas are
supported as well.


Michael.

bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions

[Stefan Kangas]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> I don't think it could make it worse.  I also think now that it should
> be correct.  AFAIU `def-form' doesn't need to be used but I think I
> should use `function-form' instead of `form' so that quoted lambdas are
> supported as well.

Sounds good to me.  No one seems to object, so I'd suggest you go
ahead and push it to master.

Best regards,
Stefan Kangas

bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions

[Michael Heerdegen]

Stefan Kangas <stefan@marxist.se> writes:

> > I don't think it could make it worse.  I also think now that it should
> > be correct.  AFAIU `def-form' doesn't need to be used but I think I
> > should use `function-form' instead of `form' so that quoted lambdas are
> > supported as well.
>
> Sounds good to me.  No one seems to object, so I'd suggest you go
> ahead and push it to master.

Ok, will do tonight.

BTW, do you have an opinion about allowing (SYMBOL LAMBDA-EXPR) binding
syntax for cl-labels and cl-macrolet?  The reason why I want this is (1)
I often try to use this syntax and it doesn't work, and (2) it indents
more nicely.  Or do you even have a nice idea of how to fix the
indentation problem?

Michael.

bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> > Sounds good to me.  No one seems to object, so I'd suggest you go
> > ahead and push it to master.
>
> Ok, will do tonight.

That part is done now.

Michael.

bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions

[Stefan Kangas]

Michael Heerdegen <michael_heerdegen@web.de> writes:

>> Sounds good to me.  No one seems to object, so I'd suggest you go
>> ahead and push it to master.
>
> Ok, will do tonight.

Thank you for doing that.

> BTW, do you have an opinion about allowing (SYMBOL LAMBDA-EXPR) binding
> syntax for cl-labels and cl-macrolet?  The reason why I want this is (1)
> I often try to use this syntax and it doesn't work, and (2) it indents
> more nicely.  Or do you even have a nice idea of how to fix the
> indentation problem?

I don't think I can give an informed opinion about that, sorry.
Perhaps you could ask Stefan Monnier.

Best regards,
Stefan Kangas

bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> BTW, do you have an opinion about allowing (SYMBOL LAMBDA-EXPR) binding
> syntax for cl-labels and cl-macrolet?  The reason why I want this is (1)
> I often try to use this syntax and it doesn't work, and (2) it indents
> more nicely.  Or do you even have a nice idea of how to fix the
> indentation problem?

If I skim this bug report correctly, the reported problem was fixed, but
it was left open due to this question?

Which is to allow (cl-labels ((foo (lambda () ...)))) as an alternative
syntax, if I understood the proposal correctly?

I know we're not beholden to Common Lisp for our versions of the macros,
but this seems kinda confusing to me, so my preference would be not to
extend the syntax in this way.

But I don't really use `cl-labels', so I don't really have much of an
opinion here.

Perhaps Stefan M has?  (Added to the CCs.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions

[Stefan Monnier]

>> BTW, do you have an opinion about allowing (SYMBOL LAMBDA-EXPR) binding
>> syntax for cl-labels and cl-macrolet?  The reason why I want this is (1)
>> I often try to use this syntax and it doesn't work, and (2) it indents
>> more nicely.

I made this syntax work for `cl-flet`, so I'm not opposed to allowing it
for `cl-macrolet` and `cl-labels`.

> Which is to allow (cl-labels ((foo (lambda () ...)))) as an alternative
> syntax, if I understood the proposal correctly?

BTW, when I added it to `cl-flet` the main purpose wasn't to
write `(cl-flet ((f (lambda ...))) ...)` but rather to write
`(cl-flet ((f x)) ...)` or more generally to compute at runtime which
function to bind to `f`, without having to introduce an η-redex.

As for indentation, I consider the way we currently indent `cl-labels`
and friends as a bug.


        Stefan

bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> As for indentation, I consider the way we currently indent `cl-labels`
> and friends as a bug.

Yep.  I think fixing this is more important than allowing lambda
expressions in the binding list, but it's also the harder task.

Michael.

bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> [...]
> Which is to allow (cl-labels ((foo (lambda () ...)))) as an alternative
> syntax, if I understood the proposal correctly?

Yes.  And, I think, to allow arbitrary expressions evaluating to a
function for `cl-macrolet'.

> I know we're not beholden to Common Lisp for our versions of the macros,
> but this seems kinda confusing to me [...]

Why?


Regards,

Michael.

bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

>> I know we're not beholden to Common Lisp for our versions of the macros,
>> but this seems kinda confusing to me [...]
>
> Why?

Just because it's not a part of Common Lisp -- I think people expect the
cl-* functions to be a subset of CL syntax, not a superset.

But we're free to do what we want here, of course, and I don't oppose
extending the syntax here.  But it's just something to keep in mind.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Just because it's not a part of Common Lisp -- I think people expect
> the cl-* functions to be a subset of CL syntax, not a superset.

Ok.

For cl-flet, we already have it, and it's a useful extension.  For
cl-labels, I don't care that much, and allowing arbitrary
function-valued expressions does not even make sense for it.  But for
macrolet I guess it could make sense (does CL have macrolet?).

Michael.

bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> But for macrolet I guess it could make sense.

No, AFAIU macro expanders of `cl-macrolet' can't make use of runtime
values (the expansion can, of course), so I think, similar to
`cl-labels', encouraging the impression that a function is referenced or
created at runtime (by evaluating a lambda) might be no good idea in
these cases.

Michael.

bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
>> But for macrolet I guess it could make sense.
>
> No, AFAIU macro expanders of `cl-macrolet' can't make use of runtime
> values (the expansion can, of course), so I think, similar to
> `cl-labels', encouraging the impression that a function is referenced or
> created at runtime (by evaluating a lambda) might be no good idea in
> these cases.

Right.  So I think the conclusion here is that we're not going to add
this form (at this time, at least), and since the other bits talked
about here have been fixed, I'm closing this bug report.

Fixing indentation was also mentioned (and the indentation here is
indeed very bad), but there's a separate bug report for that: bug#9622.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions

[Stefan Monnier]

>> Just because it's not a part of Common Lisp -- I think people expect
>> the cl-* functions to be a subset of CL syntax, not a superset.
> For cl-flet, we already have it, and it's a useful extension.  For
> cl-labels, I don't care that much, and allowing arbitrary
> function-valued expressions does not even make sense for it.

`letrec` does allow function-valued expressions, so `cl-labels` could
just as well.  But it's rarely useful, indeed.

> But for macrolet I guess it could make sense (does CL have macrolet?).

It can be useful, but it can only depend on values that exist at
macro-expansion time.  In practice, all the use cases I know are for use
where `cl-macrolet` would be used in the output of a macro, so it's just
as easy (if not easier) to call `macroexpand-all` directly, passing it
the environment you want.

Hence the difference between `cl-flet` and the other two: I have come up
with an actual case where it's useful to have `cl-flet` bind the
function name to a "computed function" (IIRC this came up while coding
`cl-generic.el`), whereas I haven't come across such a need for
`cl-labels` or `cl-macrolet` yet.


        Stefan