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

Previous Next

Full log

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
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 14:54:25 +0100

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

> I'm OK with making the printed representation similar to the
> source code.  But when that is in turn used to motivate changes to the
> source code, I think it's gone too far.
> It's hard enough to design good source syntax without such constraints.

I'm not sure I follow you -- I don't think this would mean changing any
source code?

But, yes, it would mean that people might be tempted to write actual
code like

(lambda ()
  (declare (lexical-binding (foo . 1)))
  ...)

but people might be tempted to do the same with `closure' forms, and
that doesn't seem to be happening.

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.

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

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

Previous Next

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