GNU bug report logs - #34481
27.0.50; cl-flet, cl-labels and lambda expressions

Previous Next

Full log

Message #56 received at 34481 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Stefan Kangas <stefan <at> marxist.se>,
 34481 <at> debbugs.gnu.org
Subject: Re: bug#34481: 27.0.50; cl-flet, cl-labels and lambda expressions
Date: Mon, 01 Mar 2021 21:41:18 -0500

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.