From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Elisp printer Date: Sun, 05 Mar 2017 21:50:18 -0500 Message-ID: References: <87pokampa4.fsf@ericabrahamsen.net> <8760m2mmlq.fsf@ericabrahamsen.net> <87lguq5r87.fsf@ericabrahamsen.net> <878tp0i74g.fsf@users.sourceforge.net> <87efyg6y0i.fsf_-_@drachen> <87o9xjm7ij.fsf@drachen> <871sufm1io.fsf@drachen> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1488768658 5173 195.159.176.226 (6 Mar 2017 02:50:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 6 Mar 2017 02:50:58 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Michael Heerdegen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 06 03:50:55 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 1ckija-0000SL-VM for ged-emacs-devel@m.gmane.org; Mon, 06 Mar 2017 03:50:51 +0100 Original-Received: from localhost ([::1]:41340 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ckijg-0001Tc-US for ged-emacs-devel@m.gmane.org; Sun, 05 Mar 2017 21:50:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36759) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ckijA-0001TK-I0 for emacs-devel@gnu.org; Sun, 05 Mar 2017 21:50:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ckij7-0008D8-Ef for emacs-devel@gnu.org; Sun, 05 Mar 2017 21:50:24 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:58004) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ckij7-0008Cv-9N for emacs-devel@gnu.org; Sun, 05 Mar 2017 21:50:21 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DICgC3zbxY/zPujBheGwEBAQMBAQEJAQEBg1FBhDuFVoV4kFEpAZcahhwEAgKCZUQUAQIBAQEBAQEBayiFFgEEAVYjBQsLNBIUGA0kigcIsUOKeQEBAQcCASWLPYo5BY9Wf4tXnHKGYJM7NiGBAyIVCCyHMSKKSAEBAQ X-IPAS-Result: A0DICgC3zbxY/zPujBheGwEBAQMBAQEJAQEBg1FBhDuFVoV4kFEpAZcahhwEAgKCZUQUAQIBAQEBAQEBayiFFgEEAVYjBQsLNBIUGA0kigcIsUOKeQEBAQcCASWLPYo5BY9Wf4tXnHKGYJM7NiGBAyIVCCyHMSKKSAEBAQ X-IronPort-AV: E=Sophos;i="5.35,251,1484024400"; d="scan'208";a="294522075" Original-Received: from 24-140-238-51.cpe.teksavvy.com (HELO pastel.home) ([24.140.238.51]) by smtp.teksavvy.com with ESMTP; 05 Mar 2017 21:50:18 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 74E6364F69; Sun, 5 Mar 2017 21:50:18 -0500 (EST) In-Reply-To: <871sufm1io.fsf@drachen> (Michael Heerdegen's message of "Fri, 03 Mar 2017 05:23:43 +0100") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:212783 Archived-At: > I tried with (symbol-function 'byte-compile-arglist-warn), where I have > advised that function, and got > #+begin_src emacs-lisp > # (name arglist macrop) > # > my-byte-compile-arglist-warn--around-ad> > #+end_src I see, yes, that's ugly. >> We could use a syntax more like that of structs, i.e. something of the >> form #s(...). For those objects which really aren't structs at all, we >> could use a similar notation with another letter (e.g. #f(...) for >> function objects such as advice thingies)? > Is just one letter enough? Of course: the "#s(..)" is really "#s( ...)" so the above example could look like #f(advice-wrapper :around #f(compiled-function (name arglist macrop) #) my-byte-compile-arglist-warn--around-ad) > How would thunks and streams look like with > this scheme? You'd get to choose when you implement their corresponding methods but they could look like #f(thunk ...) and #f(stream ...) -- Stefan