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.
This is the second of two posts proposing simplifications (reductions in
scope) for SRFI 109. The idea is that by removing variable elements,
this SRFI (unlike SRFIs 107 and 108) becomes purely lexical in scope:
the output of the a SRFI-109-capable reader returns the same thing for
a SRFI-109 string literal and a regular string, viz. an immutable Scheme
string object.
Since calls on format are optional, if redefinable entity names are
removed as I proposed in part 1, the only remaining reason *not* to
expand a SRFI-109 string literal into a pure Scheme string literal are
the twin facilities of interpolation (enclosed expressions and template
processing) and internationalization.
Unfortunately, these 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.
(As a simple example, localizing something as simple as numeric dates
requires the ability to specify not only what delimiters divide the
day, month, and year portions, but what order they must appear in.
This cannot be done with mere interpolation.)
Per contra, the i18n facility provided only maps literal, untemplated
strings to other literal, untemplated strings. That does not work
when, as is often the case, there are variable parts in the string to
be internationalized.
I therefore suggest that these facilities be moved out of SRFI 109
and into a different facility that can provide them more thoroughly
and uniformly, either as part of a formatting library or (preferably,
in my view) stand-alone.
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.
--
John Cowan http://www.ccil.org/~cowan <cowan@xxxxxxxx>
"Any legal document draws most of its meaning from context. A telegram
that says 'SELL HUNDRED THOUSAND SHARES IBM SHORT' (only 190 bits in
5-bit Baudot code plus appropriate headers) is as good a legal document
as any, even sans digital signature." --me