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: RFC: String interpolation Date: Thu, 08 Dec 2016 16:31:50 -0500 Message-ID: References: <51825111-ace4-f750-4077-026a3b648d27@gmail.com> <9f4dbc5a-7978-8cdb-d8f5-05d853ff4a99@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1481232735 21132 195.159.176.226 (8 Dec 2016 21:32:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 8 Dec 2016 21:32:15 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 08 22:32:10 2016 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 1cF6IT-0004Lh-Fc for ged-emacs-devel@m.gmane.org; Thu, 08 Dec 2016 22:32:09 +0100 Original-Received: from localhost ([::1]:49116 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cF6IX-0001Dq-Gp for ged-emacs-devel@m.gmane.org; Thu, 08 Dec 2016 16:32:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43703) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cF6IQ-00017R-7m for emacs-devel@gnu.org; Thu, 08 Dec 2016 16:32:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cF6IM-0000p6-SM for emacs-devel@gnu.org; Thu, 08 Dec 2016 16:32:06 -0500 Original-Received: from [195.159.176.226] (port=58265 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cF6IM-0000ot-Ku for emacs-devel@gnu.org; Thu, 08 Dec 2016 16:32:02 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cF6IC-00023S-8D for emacs-devel@gnu.org; Thu, 08 Dec 2016 22:31:52 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 30 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:KtC2sP+fDw4/t46vGPuIbU0RQ+A= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:210160 Archived-At: > Neat, it looks like they do almost exactly the same, right? Except % vs. $. Pretty much, yes. > The nice part about not constructing a top-level call to format is that the > full format string doesn't need to be reparsed every time. Indeed. But the Elisp interpreter is slow compared to the `format` parser, so I'd expect the use of a single `format` call to be more efficient (both in code size and execution time). That's just a gut feeling, tho, I have no hard data to back it up (my implementation uses a single `format` call partly because of that gut feeling but also because it seemed easier). > You could even imagine getting rid of format entirely, and parsing > even the format sequences at compile time. My gut says that the resulting Elisp code would probably be even larger and slower. > Sounds reasonable. I'm happy to drop the extended format codes with "|" in > them. Since ELisp variable names routinely include slashes and colons, > I think having {} is useful (looks like your implementation supported that > too?). Being able to specify a format string is nice too. I added supported for {..} not so much because of slashes and such, but simply to resolve the ambiguity between "%{a}b" and "%{ab}". Stefan