GNU bug report logs - #52063
28.0.60; Confusing presentation of lambda

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Philipp Stephani <p.stephani2 <at> gmail.com>,
 Filipp Gunbin <fgunbin <at> fastmail.fm>, 52063 <at> debbugs.gnu.org
Subject: Re: bug#52063: 28.0.60; Confusing presentation of lambda
Date: Mon, 29 Nov 2021 12:58:35 -0500

> My point is that if we're extending the `lambda' syntax, we might as
> well do it in a way that allows further easy expansions in the future.

And my point is that we're not discussing the syntax of `lambda` but the
representation of function values.
[ I agree with the above, BTW.  I just don't think it is relevant to the
  problem at hand.  ]

>> Also, I think it's good if the source syntax is a bit different from the
>> function value syntax: we want the two to be *similar* so the function
>> value feels familiar and can intuitively be understood, but we also want
>> to make it clear that we're looking at something
>> fundamentally different.
>> That's why I'd favor a representation of the form #[...] or #<...> or ...
> Hm, right...  I think I'm in favour of demystifying, not further
> mystifying things for the users.

Currently the vast majority of functions in Emacs's heap (i.e. function
*values*) get printed either as a symbol or as #[...] or as #<subr...>.
The (lambda ...) and (closure ...) cases are in the minority and I think
it would be good to try and eliminate these cases as much as possible
(we'll probably have to keep supporting it for backward compatibility,
but we can stop generating them ourselves).


        Stefan

Previous Next

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