From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.org!.POSTED!not-for-mail
From: Paul Eggert <eggert@cs.ucla.edu>
Newsgroups: gmane.emacs.devel
Subject: Re: RFC: String interpolation
Date: Mon, 12 Dec 2016 12:41:38 -0800
Organization: UCLA Computer Science Department
Message-ID: <3ff9e7e4-aee7-191e-5e3b-4d4ac0006a1f@cs.ucla.edu>
References: <51825111-ace4-f750-4077-026a3b648d27@gmail.com>
	<8737hwnc52.fsf@lifelogs.com> <m34m2bj2m2.fsf@gnus.org>
	<8c117f5c-209a-97d8-79ce-a78f707f0545@gmail.com>
	<m3wpf7hjzf.fsf@gnus.org>
	<76c9c475-0180-aa49-3d4a-006d4e3f943c@gmail.com>
	<m3oa0ifgvd.fsf@gnus.org>
	<m2k2b6rxaj.fsf@gmail.com> <m38trmdun6.fsf@gnus.org>
	<jwvr35dub31.fsf-monnier+gmane.emacs.devel@gnu.org>
	<m3r35dcwht.fsf@gnus.org>
	<89a6a20d-e135-caad-6b31-760ab7ac90fc@cs.ucla.edu>
	<87fultkjte.fsf@lifelogs.com>
NNTP-Posting-Host: blaine.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: blaine.gmane.org 1481575317 10255 195.159.176.226 (12 Dec 2016 20:41:57 GMT)
X-Complaints-To: usenet@blaine.gmane.org
NNTP-Posting-Date: Mon, 12 Dec 2016 20:41:57 +0000 (UTC)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
	Thunderbird/45.5.1
Cc: Lars Ingebrigtsen <larsi@gnus.org>
To: emacs-devel@gnu.org
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 12 21:41:50 2016
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>
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 <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	id 1cGXPy-0001nB-0N
	for ged-emacs-devel@m.gmane.org; Mon, 12 Dec 2016 21:41:50 +0100
Original-Received: from localhost ([::1]:33530 helo=lists.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	id 1cGXQ2-0006Gd-6w
	for ged-emacs-devel@m.gmane.org; Mon, 12 Dec 2016 15:41:54 -0500
Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47469)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <eggert@cs.ucla.edu>) id 1cGXPs-0006FE-0Q
	for emacs-devel@gnu.org; Mon, 12 Dec 2016 15:41:44 -0500
Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <eggert@cs.ucla.edu>) id 1cGXPo-0002So-O3
	for emacs-devel@gnu.org; Mon, 12 Dec 2016 15:41:43 -0500
Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:51314)
	by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	(Exim 4.71) (envelope-from <eggert@cs.ucla.edu>) id 1cGXPo-0002SN-IC
	for emacs-devel@gnu.org; Mon, 12 Dec 2016 15:41:40 -0500
Original-Received: from localhost (localhost [127.0.0.1])
	by zimbra.cs.ucla.edu (Postfix) with ESMTP id 54D5B160203;
	Mon, 12 Dec 2016 12:41:39 -0800 (PST)
Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1])
	by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032)
	with ESMTP id nInk9PfZcwIU; Mon, 12 Dec 2016 12:41:38 -0800 (PST)
Original-Received: from localhost (localhost [127.0.0.1])
	by zimbra.cs.ucla.edu (Postfix) with ESMTP id 872281601FE;
	Mon, 12 Dec 2016 12:41:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu
Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1])
	by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id t00o1V5p-L4g; Mon, 12 Dec 2016 12:41:38 -0800 (PST)
Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200])
	by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 6E1501601FD;
	Mon, 12 Dec 2016 12:41:38 -0800 (PST)
In-Reply-To: <87fultkjte.fsf@lifelogs.com>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy]
X-Received-From: 131.179.128.68
X-BeenThere: emacs-devel@gnu.org
X-Mailman-Version: 2.1.21
Precedence: list
List-Id: "Emacs development discussions." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-devel/>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=subscribe>
Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org
Original-Sender: "Emacs-devel" <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>
Xref: news.gmane.org gmane.emacs.devel:210372
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/210372>

On 12/12/2016 11:51 AM, Ted Zlatanov wrote:
> I like how this separates expressions from strings. It might be more
> readable if the % begins the next string:
>
>      (format "Altitude= " alt "%.2f, direction = " dir "%.2f.")

Unfortunately although this syntax is clean it would not be upward 
compatible, as 'format' currently silently discards excess trailing 
arguments. In contrast, Lars's suggestion:

> (format "Altitude= %.2f%" alt ", direction = %.2f%" dir ".")

is upward compatible. Also, I suspect that Lars's suggestion will be 
less error-prone than mine, as it would be more likely to diagnose stray 
occurrences of "%" at the end of a format.

> It has some downsides: it only works in one function; `(apply 'format ...)`
> can become surprising; and repeating a parameter requires duplicating
> the code.

True for repeating a nontrivial parameter. However, that is not common 
and 'let' should be good enough for that, e.g., (let ((dup (complicated 
expression))) (format "appearance1 = %f%" dup ", appearance2 = %g%." dup)).

I'm not sure what is meant mean by 'only works in one function'. 
format-message should behave like 'format', and any function that calls 
'format' or 'format-message' will get the extended behavior for free. 
For example, (message ...) would get the extended behavior.

(apply 'format FMT ...) would not get the extended behavior unless FMT 
itself uses the extension, and this should be good enough to avoid most 
surprises.

Ah, perhaps you're thinking about mixed forms like (format "x = %1d, y = 
%2d%" EX WYE ", z = %3d" ZEE)? To avoid confusion, the extension could 
work only if the format string has just one conversion specifier, at the 
end (just before the "%" at end of string). The idea would be to 
encourage people to write either the extended (format "x = %1d%" EX ", y 
= %2d%" WYE ", z = %3d%" ZEE) or the traditional (format "x = %1d, y = 
%2d, z = %3d" EX WYE ZEE) instead of trying to write a confusing mixture 
of the two.