From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Noam Postavsky Newsgroups: gmane.emacs.devel Subject: Re: (:named nil) in cl-defstruct (was: new `obarray` type) Date: Wed, 15 Mar 2017 15:39:31 -0400 Message-ID: References: <20170313220335.GA5098@acm> <20170314201414.GA4562@acm> <8660jaz9lr.fsf@molnjunk.nocrew.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: blaine.gmane.org 1489606811 20941 195.159.176.226 (15 Mar 2017 19:40:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 15 Mar 2017 19:40:11 +0000 (UTC) Cc: Emacs developers To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 15 20:40:04 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1coEmB-0004nH-KN for ged-emacs-devel@m.gmane.org; Wed, 15 Mar 2017 20:40:03 +0100 Original-Received: from localhost ([::1]:39231 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1coEmH-00047q-Gy for ged-emacs-devel@m.gmane.org; Wed, 15 Mar 2017 15:40:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52055) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1coElh-00046f-A5 for emacs-devel@gnu.org; Wed, 15 Mar 2017 15:39:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1coElg-0005t4-Ei for emacs-devel@gnu.org; Wed, 15 Mar 2017 15:39:33 -0400 Original-Received: from mail-ot0-x22d.google.com ([2607:f8b0:4003:c0f::22d]:36834) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1coElg-0005sz-9t for emacs-devel@gnu.org; Wed, 15 Mar 2017 15:39:32 -0400 Original-Received: by mail-ot0-x22d.google.com with SMTP id i1so31131495ota.3 for ; Wed, 15 Mar 2017 12:39:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=x4aeBwkrM+11x20c+pbZ3LNfjHuJsV864OVFuf52Pvo=; b=fOxCQcPXa9H+tTXrXR9tmhVSDsYya/EdZFci1Ns1xEJelo91s4IZURKzzUptqIJ8F5 +AhS7L/lRi1hToIwg+UzjK9+AXHvtEYIfdJ/PEsgDZXaZmTUPvnNbmMMtLjs1Ii9UH03 o84zEJzlnowIfAvECNi7Ry2AY00TKMlQmylAICBDHbhVnlddXcLEoS7CdbnThi78+AFl BkbTuGLsxTjPssETZo9k87/GIXbVxuGMh3b/G+LH5YMs0X/V6IXMv+hdrXFGsIEW4l3T 1fG2aNw0BE3oUE5RvUaKvAXlJj9YpnQttVQqqry/BwhjSW9mb1NBVkdcbNQK7Pv1q40v NDPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=x4aeBwkrM+11x20c+pbZ3LNfjHuJsV864OVFuf52Pvo=; b=CUOo1kuqGFVNnn2hg62Hhk0CozrqjyoojuBjyi18NhDTlqxuuYB9OM4dQT/YBjHPsL CxCvHuDGfQv6IIWi8//vJN7fSf10D+ACZN0SUzIgweSZYNkWEgHHNDQfs79CXEnBgR2C m8+q6UdauNBWNF6OdgxrLnhrO4e4Y5MxXvvNr4AHI1Oh+3vYEpDoSAlHJWr08a0LBK23 n2b6BaDqOmC5G6ZiP+Jek8avlQ800EczLuYws+yjsflpaSGHwVXHN/kT2oQuncxDSD6D 9NYrW8T/7d+x6vZAgxeAJBee+Z6P8iCqf2g2Xgx+mY4n1lxwIqg0iOg9cKNthkNpgQfb Yk/A== X-Gm-Message-State: AFeK/H3ExhBx5X7ekIoK0AcFg7o71AHURBhF4AOnissRxz8ziR/uknGZVxX8smvHJqwjiI0FtJ3jlj+DJir1ug== X-Received: by 10.157.15.161 with SMTP id d30mr2513352otd.221.1489606771535; Wed, 15 Mar 2017 12:39:31 -0700 (PDT) Original-Received: by 10.157.80.172 with HTTP; Wed, 15 Mar 2017 12:39:31 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: Du4tsRZaGtJJUBfWef_-_bgYbO8 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4003:c0f::22d X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:213052 Archived-At: On Wed, Mar 15, 2017 at 3:24 PM, Stefan Monnier wrote: > Common-Lisp doesn't allow (:named ...), but cl-macs.el treats it > as :named hence the confusion. I think we should change this to either > disallow (:named ...) or to treat (:named nil) as a way to say "*not* > named". The patch below does latter. Any objection? > - (setq named t)) > + (setq named (if args (car args) t))) Hmm, if I read the code below correctly, this would allow (:named something-else), but the struct wouldn't be named 'something-else'. Which still seems potentially confusing for users.