220 20519 <55FE8717.4080707@gmail.com> article Path: news.gmane.org!not-for-mail From: Miro Knejp Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Rough Draft Proposal of Interpolated String Literals Date: Sun, 20 Sep 2015 12:14:47 +0200 Lines: 440 Approved: news@gmane.org Message-ID: <55FE8717.4080707@gmail.com> References: <55FDC8F9.9050909@wanadoo.fr> <34e8c580-c03c-47d9-ace1-39dd5b1bb41a@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------060101050508030604030904" X-Trace: ger.gmane.org 1442744088 7927 80.91.229.3 (20 Sep 2015 10:14:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 20 Sep 2015 10:14:48 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC6ONSXJ54LBBEMO7KXQKGQEKNFIFTY@isocpp.org Sun Sep 20 12:14:43 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lb0-f197.google.com ([209.85.217.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zdbdq-0006I9-Rt for gclcip-std-proposals@m.gmane.org; Sun, 20 Sep 2015 12:14:42 +0200 Original-Received: by lbot4 with SMTP id t4sf30027089lbo.0 for ; Sun, 20 Sep 2015 03:14:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=+VwAusJWMjpy/ojqqalwixUCIP3fLhVOcaiAeHFby0k=; b=PrpKcTfqaTWSqz5zVau0/b8bucTYp0lzlbtZRjGpjI4uM7RKBLHKetya/F0AynnIne ZENEKxPQqqIUftVuS0+nXjznpnLLF8tbKHHcTaNsZyrwVLTcVICcTVz8ikqxUYcBQpCM iuVYxRTIKvvUm6AYfiUhTd6YE45aoSqLigpSUWC8pE3wzsF4u7wzHz0rTVUmCet6Jrlt W2RSAl3RhNcekAnpV3BAkS//90JMn+cutxQH0xLQe/uWal9YR0AbZMt/rzYcGMPeO+/Q RM0Tzyb6cjl51FhP0R2B2TbWXJg7KtwDbd0gTwnIjpjvjGzwL8BjGOIBTZ48humcr0sG EsSA= X-Gm-Message-State: ALoCoQll6oXkWjwYEGNfnxBvtS63w+6KV9z1iIOYPyWMCD6I9yacU2aKb7rKi8uIKzeNjPonm/AN X-Received: by 10.152.22.101 with SMTP id c5mr2343881laf.0.1442744082390; Sun, 20 Sep 2015 03:14:42 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.96.134 with SMTP id ds6ls474738wib.27.canary; Sun, 20 Sep 2015 03:14:41 -0700 (PDT) X-Received: by 10.180.103.199 with SMTP id fy7mr7385512wib.85.1442744081371; Sun, 20 Sep 2015 03:14:41 -0700 (PDT) Original-Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com. [2a00:1450:400c:c05::236]) by mx.google.com with ESMTPS id yv9si23870745wjc.67.2015.09.20.03.14.41 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Sep 2015 03:14:41 -0700 (PDT) Received-SPF: pass (google.com: domain of miro.knejp@gmail.com designates 2a00:1450:400c:c05::236 as permitted sender) client-ip=2a00:1450:400c:c05::236; Original-Received: by wiclk2 with SMTP id lk2so111336155wic.0 for ; Sun, 20 Sep 2015 03:14:41 -0700 (PDT) X-Received: by 10.180.8.9 with SMTP id n9mr7356855wia.40.1442744080925; Sun, 20 Sep 2015 03:14:40 -0700 (PDT) Original-Received: from [192.168.42.33] (ppp-93-104-178-86.dynamic.mnet-online.de. [93.104.178.86]) by smtp.gmail.com with ESMTPSA id xw2sm18270097wjc.12.2015.09.20.03.14.39 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 20 Sep 2015 03:14:40 -0700 (PDT) User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 In-Reply-To: <34e8c580-c03c-47d9-ace1-39dd5b1bb41a@isocpp.org> X-Original-Sender: miro.knejp@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of miro.knejp@gmail.com designates 2a00:1450:400c:c05::236 as permitted sender) smtp.mailfrom=miro.knejp@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:20519 Archived-At: This is a multi-part message in MIME format. --------------060101050508030604030904 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable More reasons not to darg translation into this topic. There are use cases for string interpolation and there are use cases for=20 runtime formatting. If you want a runtime-provided translation you=20 probably also worry about runtime-provided formatting options, like=20 left/right alignment based on writing direction, plurality forms,=20 gender-based declination, date-time specifiers and whatnot. Stuff like=20 "blah blah {0:select(his, her, condition)} blah blah". These options=20 have to be written by translators who don't ever see the source code, so=20 it is far more than just changing the sequence of a sentence. How is the=20 compiler supposed to create these? Furthermore a tool that extracts strings from source code is IMHO bad=20 practice. It makes *programmers* write user-visible strings in source=20 code, which is just plain bad and should be done by=20 *translators/designers*, even if it is their native language, and not in=20 the source code. Imagine you have dedicated people (non-coders, possibly=20 external) who provide the English texts and make sure they are=20 consistent and error-free and conform to all kinds of marketing=20 nonsense. This is not a burden for programmers and something that should=20 not be done at source-code level. If you want to encourage good=20 practice, don't encourage people to write *any* localizable or evn=20 user-visible strings in source code (I could turn a blind eye on log=20 files and internal exceptions). User-visible strings should be treated=20 equally as data to your application just as images or sounds. Please, if you want formatting, create a formatting proposal. If you=20 want translation, create a translation proposal. Both are needed. But=20 there's no point in trying to shoehorn everything into string=20 interpolation, which is simply a tool to break up a string into a=20 sequence of expressions. Am 20.09.2015 um 11:29 schrieb Bengt Gustafsson: > Vicente: I like your idea of transforming the string to a "classic"=20 > format string + a list of parameters. This enables translation.=20 > However, I don't think that a proposal which directly translates the > result to something containing specific function names like format and=20 > translate has much chance with the committe. My synergetic suggestion=20 > would then be this transformation: > > int i; > string s; > > F"This is $i and this is $s." > > translates to: > > "This is $1$ and this is $2$.", i, s > > which must be complemented at the call site into something like: > > translated_format(cout, F"This is $i and this is $s."); > > Note that a drawback with this scheme, in conjunction with=20 > translation, is that gettext or whatever tool is used to extract the=20 > strings from the source code has to mimic the transformation of the=20 > literal that the compiler does. This should be doable as long as it=20 > can be done in a context free way, i.e. without having access to the=20 > symbol table. I'm unsure if the problematic > parsing passes this test. > > An alternative syntax for the original string solves this: > > F"This is $i+3$ and this is $s$ ." > > but this opens another can of worms, as now you have to be able to=20 > parse this: > > F"This is $i+3$ and this is $s + "extra"$ ." > > without stumbling on the nested quotation marks... > > I don't know if even this can be prevented: > > F"This is $i+3$ and this is $s + F" extra $i*2$"$ ." > > This is no problem for a recursive decent parser, but maybe it is=20 > overdoing it. Any system allowing an expression inside the literal=20 > must however define rules for nexting of string literals and=20 > F-literals inside those expressions. > > A side note: The nested literal F" extra $i*2$" in the example above=20 > specifies a leading space before the word extra. I think this speaks=20 > against the idea of defining the insert prefix at the start of the=20 > string. It is not so easy to see the difference between one and two=20 > spaces, and with tabs in the mix it gets worse... > > > Den l=C3=B6rdag 19 september 2015 kl. 22:43:40 UTC+2 skrev Vicente J. Bot= et=20 > Escriba: > > Le 18/09/15 22:21, Andrew Tomazos a =C3=A9crit : > > Please find attached a very very rough draft of a proposal entitled > > "Interpolated String Literals". > > > > Mainly after encouragement or discouragement, and any high-level > thoughts > > you might have about it. > > > I like the idea. IIUC the interpolated string > > F"$ This is $i and this is $s." > > you are proposing is syntactic sugar for > > << "This is " << i << " and this is " << s << "." > > The transformation has the advantage that the result is already > parsed. > > However, if we want to manage with internationalization I believe > that > the whole interpolated string should be translated to something like > > format(translate("This is {1} and this is {2}."), i, u); > > Where translate takes care of the internationalization, it would > lookup > for the translation "This is %1% and this is %2%." in its dictionary. > format is a variadic variant of Boost.Format, which could be more > efficient than the use of % as in , > > format(translate("This is {1} and this is {2}.")) % i % u; > > This is the schema used by Boost.Locale. IMO any internationalization > solution must pay at run time for the look-up and the parsing. > > Why not have both using two different prefixes for two different > translation schemes? > > I"$ This is $i and this is $s." > > I recognize that a internationalization solution is more complex than > what you proposes and need much more than that. Your proposal has > enough > value by itself, and could be adapted later if one day we have an > internationalization proposal. > > Vicente > > P.S. As others, I don't think it is correct to have the fist << > in the > translation, the translation should result in one expression. > > --=20 > > --- > You received this message because you are subscribed to the Google=20 > Groups "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this group and stop receiving emails from it, send=20 > an email to std-proposals+unsubscribe@isocpp.org=20 > . > To post to this group, send email to std-proposals@isocpp.org=20 > . > Visit this group at=20 > http://groups.google.com/a/isocpp.org/group/std-proposals/. --=20 ---=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. --------------060101050508030604030904 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable More reasons not to darg translation into this topic.
There are use cases for string interpolation and there are use cases for runtime formatting. If you want a runtime-provided translation you probably also worry about runtime-provided formatting options, like left/right alignment based on writing direction, plurality forms, gender-based declination, date-time specifiers and whatnot. Stuff like "blah blah {0:select(his, her, condition)} blah blah". These options have to be written by translators who don't ever see the source code, so it is far more than just changing the sequence of a sentence. How is the compiler supposed to create these?

Furthermore a tool that extracts strings from source code is IMHO bad practice. It makes *programmers* write user-visible strings in source code, which is just plain bad and should be done by *translators/designers*, even if it is their native language, and not in the source code. Imagine you have dedicated people (non-coders, possibly external) who provide the English texts and make sure they are consistent and error-free and conform to all kinds of marketing nonsense. This is not a burden for programmers and something that should not be done at source-code level. If you want to encourage good practice, don't encourage people to write *any* localizable or evn user-visible strings in source code (I could turn a blind eye on log files and internal exceptions). User-visible strings should be treated equally as data to your application just as images or sounds.

Please, if you want formatting, create a formatting proposal. If you want translation, create a translation proposal. Both are needed. But there's no point in trying to shoehorn everything into string interpolation, which is simply a tool to break up a string into a sequence of expressions.

Am 20.09.2015 um 11:29 schrieb Bengt Gustafsson:
Vicente: I like your idea of transforming the string to a "classic" format string + a list of parameters. This enables translation. However, I don't think that a proposal which directly translates the
result to something containing specific function names like format and translate has much chance with the committe. My synergetic suggestion would then be this transformation:

int i;
string s;

=C2=A0F"This is $i and this is $s."

translates to:

"This is $1$ and this is $2$.", i, s

which must be complemented at the call site into something like:

translated_format(cout,=C2=A0=C2=A0F"This is $i and this is $s= ..");

Note that a drawback with this scheme, in conjunction with translation, is that gettext or whatever tool is used to extract the strings from the source code has to mimic the transformation of the literal that the compiler does. This should be doable as long as it can be done in a context free way, i.e. without having access to the symbol table. I'm unsure if the problematic > parsing passes this test.

An alternative syntax for the original string solves this:

=C2=A0F"This is $i+3$ and this is $s$ ."

but this opens another can of worms, as now you have to be able to parse this:

=C2=A0F"This is $i+3$ and this is $s + "extra"$ ."

without stumbling on the nested quotation marks...

I don't know if even this can be prevented:

=C2=A0F"This is $i+3$ and this is $s + F" extra $i*2$"$ ."

This is no problem for a recursive decent parser, but maybe it is overdoing it. Any system allowing an expression inside the literal must however define rules for nexting of string literals and F-literals inside those expressions.

A side note: The nested literal =C2=A0F" extra $i*2$" in the example above specifies a leading space before the word extra. I think this speaks against the idea of defining the insert prefix at the start of the string. It is not so easy to see the difference between one and two spaces, and with tabs in the mix it gets worse...


Den l=C3=B6rdag 19 september 2015 kl. 22:43:40 UTC+2 skrev Vicente J. Botet Escriba:
Le 18/09/15 22:21, Andrew Tomazos a =C3=A9crit :
> Please find attached a very very rough draft of a proposal entitled
> "Interpolated String Literals".
>
> Mainly after encouragement or discouragement, and any high-level thoughts
> you might have about it.
>
I like the idea. IIUC the interpolated string

=C2=A0 =C2=A0 =C2=A0F"$ This is $i and this is $s."

you are proposing is syntactic sugar for

=C2=A0 =C2=A0 =C2=A0<< "This is " << i << " a= nd this is " << s << "."

The transformation has the advantage that the result is already parsed.

However, if we want to manage with internationalization I believe that
the whole interpolated string should be translated to something like

=C2=A0 =C2=A0 =C2=A0format(translate("This is {1} and this is {= 2}."), i, u);

Where translate takes care of the internationalization, it would lookup
for the translation "This is %1% and this is %2%." in its dictionary.
format is a variadic variant of Boost.Format, which could be more
efficient than the use of % as in ,

=C2=A0 =C2=A0 =C2=A0format(translate("This is {1} and this is {= 2}.")) % i % u;

This is the schema used by Boost.Locale. IMO any internationalization
solution must pay at run time for the look-up and the parsing.

Why not have both using two different prefixes for two different
translation schemes?

=C2=A0 =C2=A0 =C2=A0I"$ This is $i and this is $s."

I recognize that a internationalization solution is more complex than
what you proposes and need much more than that. Your proposal has enough
value by itself, and could be adapted later if one day we have an
internationalization proposal.

Vicente

P.S. As others, I don't think it is correct =C2=A0to have the fist << in the
translation, the translation should result in one expression.
--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+= unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--------------060101050508030604030904-- .