all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions
@ 2019-02-15  2:09 Michael Heerdegen
  2019-02-19  0:22 ` Michael Heerdegen
                   ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: Michael Heerdegen @ 2019-02-15  2:09 UTC (permalink / raw)
  To: 34481


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.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions
  2019-02-15  2:09 bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions Michael Heerdegen
@ 2019-02-19  0:22 ` Michael Heerdegen
  2019-02-19  1:03 ` Michael Heerdegen
  2019-10-03 22:28 ` Stefan Kangas
  2 siblings, 0 replies; 19+ messages in thread
From: Michael Heerdegen @ 2019-02-19  0:22 UTC (permalink / raw)
  To: 34481

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

^ permalink raw reply related	[flat|nested] 19+ messages in thread

* bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions
  2019-02-15  2:09 bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions Michael Heerdegen
  2019-02-19  0:22 ` Michael Heerdegen
@ 2019-02-19  1:03 ` Michael Heerdegen
  2019-02-19  2:36   ` Michael Heerdegen
  2019-10-03 22:28 ` Stefan Kangas
  2 siblings, 1 reply; 19+ messages in thread
From: Michael Heerdegen @ 2019-02-19  1:03 UTC (permalink / raw)
  To: 34481

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.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions
  2019-02-19  1:03 ` Michael Heerdegen
@ 2019-02-19  2:36   ` Michael Heerdegen
  0 siblings, 0 replies; 19+ messages in thread
From: Michael Heerdegen @ 2019-02-19  2:36 UTC (permalink / raw)
  To: 34481

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.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions
  2019-02-15  2:09 bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions Michael Heerdegen
  2019-02-19  0:22 ` Michael Heerdegen
  2019-02-19  1:03 ` Michael Heerdegen
@ 2019-10-03 22:28 ` Stefan Kangas
  2019-10-17 10:36   ` Michael Heerdegen
  2 siblings, 1 reply; 19+ messages in thread
From: Stefan Kangas @ 2019-10-03 22:28 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: 34481

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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions
  2019-10-03 22:28 ` Stefan Kangas
@ 2019-10-17 10:36   ` Michael Heerdegen
  2019-10-17 10:45     ` Stefan Kangas
  0 siblings, 1 reply; 19+ messages in thread
From: Michael Heerdegen @ 2019-10-17 10:36 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 34481

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.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions
  2019-10-17 10:36   ` Michael Heerdegen
@ 2019-10-17 10:45     ` Stefan Kangas
  2019-10-17 12:31       ` Michael Heerdegen
  0 siblings, 1 reply; 19+ messages in thread
From: Stefan Kangas @ 2019-10-17 10:45 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: 34481

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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions
  2019-10-17 10:45     ` Stefan Kangas
@ 2019-10-17 12:31       ` Michael Heerdegen
  2019-10-17 18:20         ` Michael Heerdegen
                           ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: Michael Heerdegen @ 2019-10-17 12:31 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 34481

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.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions
  2019-10-17 12:31       ` Michael Heerdegen
@ 2019-10-17 18:20         ` Michael Heerdegen
  2019-11-07 13:44         ` Stefan Kangas
  2021-03-01 15:53         ` Lars Ingebrigtsen
  2 siblings, 0 replies; 19+ messages in thread
From: Michael Heerdegen @ 2019-10-17 18:20 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 34481

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.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions
  2019-10-17 12:31       ` Michael Heerdegen
  2019-10-17 18:20         ` Michael Heerdegen
@ 2019-11-07 13:44         ` Stefan Kangas
  2021-03-01 15:53         ` Lars Ingebrigtsen
  2 siblings, 0 replies; 19+ messages in thread
From: Stefan Kangas @ 2019-11-07 13:44 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: 34481

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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions
  2019-10-17 12:31       ` Michael Heerdegen
  2019-10-17 18:20         ` Michael Heerdegen
  2019-11-07 13:44         ` Stefan Kangas
@ 2021-03-01 15:53         ` Lars Ingebrigtsen
  2021-03-01 16:23           ` Stefan Monnier
  2021-03-01 23:18           ` Michael Heerdegen
  2 siblings, 2 replies; 19+ messages in thread
From: Lars Ingebrigtsen @ 2021-03-01 15:53 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: Stefan Kangas, 34481, Stefan Monnier

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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions
  2021-03-01 15:53         ` Lars Ingebrigtsen
@ 2021-03-01 16:23           ` Stefan Monnier
  2021-03-01 23:15             ` Michael Heerdegen
  2021-03-01 23:18           ` Michael Heerdegen
  1 sibling, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2021-03-01 16:23 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Michael Heerdegen, Stefan Kangas, 34481

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






^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions
  2021-03-01 16:23           ` Stefan Monnier
@ 2021-03-01 23:15             ` Michael Heerdegen
  0 siblings, 0 replies; 19+ messages in thread
From: Michael Heerdegen @ 2021-03-01 23:15 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Lars Ingebrigtsen, Stefan Kangas, 34481

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.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions
  2021-03-01 15:53         ` Lars Ingebrigtsen
  2021-03-01 16:23           ` Stefan Monnier
@ 2021-03-01 23:18           ` Michael Heerdegen
  2021-03-01 23:29             ` Lars Ingebrigtsen
  1 sibling, 1 reply; 19+ messages in thread
From: Michael Heerdegen @ 2021-03-01 23:18 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Stefan Kangas, 34481, Stefan Monnier

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.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions
  2021-03-01 23:18           ` Michael Heerdegen
@ 2021-03-01 23:29             ` Lars Ingebrigtsen
  2021-03-01 23:49               ` Michael Heerdegen
  0 siblings, 1 reply; 19+ messages in thread
From: Lars Ingebrigtsen @ 2021-03-01 23:29 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: Stefan Kangas, 34481, Stefan Monnier

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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions
  2021-03-01 23:29             ` Lars Ingebrigtsen
@ 2021-03-01 23:49               ` Michael Heerdegen
  2021-03-02  1:11                 ` Michael Heerdegen
  2021-03-02  2:41                 ` Stefan Monnier
  0 siblings, 2 replies; 19+ messages in thread
From: Michael Heerdegen @ 2021-03-01 23:49 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Stefan Kangas, 34481, Stefan Monnier

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.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions
  2021-03-01 23:49               ` Michael Heerdegen
@ 2021-03-02  1:11                 ` Michael Heerdegen
  2021-03-02  6:53                   ` Lars Ingebrigtsen
  2021-03-02  2:41                 ` Stefan Monnier
  1 sibling, 1 reply; 19+ messages in thread
From: Michael Heerdegen @ 2021-03-02  1:11 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Stefan Kangas, 34481, Stefan Monnier

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.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions
  2021-03-01 23:49               ` Michael Heerdegen
  2021-03-02  1:11                 ` Michael Heerdegen
@ 2021-03-02  2:41                 ` Stefan Monnier
  1 sibling, 0 replies; 19+ messages in thread
From: Stefan Monnier @ 2021-03-02  2:41 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: Lars Ingebrigtsen, Stefan Kangas, 34481

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






^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions
  2021-03-02  1:11                 ` Michael Heerdegen
@ 2021-03-02  6:53                   ` Lars Ingebrigtsen
  0 siblings, 0 replies; 19+ messages in thread
From: Lars Ingebrigtsen @ 2021-03-02  6:53 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: Stefan Kangas, 34481, Stefan Monnier

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





^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2021-03-02  6:53 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-02-15  2:09 bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions Michael Heerdegen
2019-02-19  0:22 ` Michael Heerdegen
2019-02-19  1:03 ` Michael Heerdegen
2019-02-19  2:36   ` Michael Heerdegen
2019-10-03 22:28 ` Stefan Kangas
2019-10-17 10:36   ` Michael Heerdegen
2019-10-17 10:45     ` Stefan Kangas
2019-10-17 12:31       ` Michael Heerdegen
2019-10-17 18:20         ` Michael Heerdegen
2019-11-07 13:44         ` Stefan Kangas
2021-03-01 15:53         ` Lars Ingebrigtsen
2021-03-01 16:23           ` Stefan Monnier
2021-03-01 23:15             ` Michael Heerdegen
2021-03-01 23:18           ` Michael Heerdegen
2021-03-01 23:29             ` Lars Ingebrigtsen
2021-03-01 23:49               ` Michael Heerdegen
2021-03-02  1:11                 ` Michael Heerdegen
2021-03-02  6:53                   ` Lars Ingebrigtsen
2021-03-02  2:41                 ` Stefan Monnier

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.