[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Simplifying SRFI 109, part 2: interpolation vs. i18n

This page is part of the web mail archives of SRFI 109 from before July 7th, 2015. The new archives for SRFI 109 contain all messages, not just those from before July 7th, 2015.

On 02/10/2013 12:20 AM, John Cowan wrote:
Unfortunately, [interpolation (enclosed expressions and template
processing) and internationalization]
are provided in such a way that they can't be
used jointly.  Interpolation uses the direct scheme of embedding
the expressions at fixed points in the string, which is poison for
i18n, because expressions need to be placed in at different points in
internationalized versions of the string due to differing word orders.

Obviously, I don't think interpolation internationalization "are
are provided in such a way that they can't be used jointly".
I specifically, discuss how they *can* be used jointly, by using
format specifiers that reposition the argument cursor.  The
write-up not concrete enough for a standard, which is I'm inclined
to follow your [earlier] suggestion to defer this functionality to
a follow-on SRFI.  But I'm fairly confident the concept can work,
and is reasonably friendly (given whatever reservations one might
have about format strings), and in fact we implemented this idea
in JavaFX Script.

Furthermore, even if we don't support internationalization, it
doesn't follow that interpolation isn't useful.  True, if you
leave out the format specifiers it becomes syntactic sugar
for string concatenation combined with implicit coercion from
arbitrary values to strings, using display-style formatting.
But that is a fairly nice syntactic sugar, as you can see
from it's prevalence in most command shells, and other languages,
including the Nashorn dialect of JavaScript:

If all my arguments are accepted, the $string$ syntax becomes unnecessary,
and it is possible to use SRFI 109 string literals in any context where
strings may be used, in particular including data files, without further
modification to the user's program.  Since the value to be returned
will always be a string object, there is no reason for the flexibility
of allowing $string$ to do anything other than coerce its arguments to
be strings and then concatenate them, so allowing it to be redefined
is profitless.  In general, I am all for flexible handling, but there
are times when too much flexibility is as annoying as too little, and
I believe SRFI 109 as currently specified exceeds that threshold.

I agree there is little or no use in redefining $string$.  However,
I still think we need a library function or macro to "coerce its
arguments to be strings and then concatenate them".  I don't see
how we can avoid $string$ (or the equivalent by another name),
unless we drop interpolation - which I don't want to do.  We
could have the reader "optimize" $string$ to a string literal
when all the arguments are literals - but not in the general case.
	--Per Bothner
per@xxxxxxxxxxx   http://per.bothner.com/