(SIP 11) Alternative string interpolation proposal
martin odersky
Daniel Sobral
> I just augmented my string interpolation proposal with an alternative syntax
> and mechanism. I like the alternative better because it is far more general
> than the first proposal.
On the document, it tells me I cannot comment on it. Wasn't the
ability to comment on the proposals one of the goals? Also, I can only
see the document embedded (maybe I'm missing something?), which is
rather uncomfortable.
I do have some comments. I'll wait to see if I should make them here,
or if I should do them on the document.
--
Daniel C. Sobral
I travel to the future all the time.
martin odersky
Martin Odersky
Prof., EPFL and Chairman, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967
Daniel Sobral
> Hi Daniel, I now opened comments on the Google doc. I am not sure why
> embedded Google Docs in a SIP mean that the normal comment function on the
> SIP is disabled, but that seems to be the case.
> Looking forward to your comments.
Thanks. I'm afraid I got carried away with the comments... :-) This
new proposal is vastly superior to the first one.
Rex Kerr
If implicit conversions are in-scope for the string identifier, that would be even better (one could write extensions without having to change StringContext).
And if there were a way to pass formatting information, that would be even better--maybe something with automatic deconstruction of tuples? I haven't had time to come up with something elegant and general.
--Rex
Seth Tisue
> This is great! I had many reservations about the first version; this one
> seems splendidly general.
Agree, my reaction exactly. This is marvelous. (And as an old Lisp
hand, I love the macro/quasiquote example.)
{ is of course nicer than \{ nearly all the time, but the JSON use
case gives me pause. See Benjamin Jackman's comment. I wish I had an
idea on this, but I don't.
--
Seth Tisue | Northwestern University | http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/
Daniel Sobral
> This is great! I had many reservations about the first version; this one
> seems splendidly general.
>
> If implicit conversions are in-scope for the string identifier, that would
> be even better (one could write extensions without having to change
> StringContext).
Implicits are in scope. See, this works just like for-comprehension
expansion: you rewrite the code as indicated, then process using
standard Scala rules.
That's why it is extensible. You can add methods to StringContext
implicitly. You can add show implicitly. You can add formatted
implicitly.
And note that "id" does *not* need to receive parameters. Pay close
attention to the XML example, and how it works. That's the example
that really brought to me the full impact of the proposal.
> And if there were a way to pass formatting information, that would be even
> better--maybe something with automatic deconstruction of tuples? I haven't
> had time to come up with something elegant and general.
Err? Beyond { expr ; fmt } expanding to expr.formatted("fmt")? What
else would you need?
>
> --Rex
>
> On Thu, Oct 27, 2011 at 9:28 AM, martin odersky <martin....@epfl.ch>
> wrote:
>>
>> I just augmented my string interpolation proposal with an alternative
>> syntax and mechanism. I like the alternative better because it is far more
>> general than the first proposal.
>> Comments welcome!
>> -- Martin
>>
>
>
--
Rex Kerr
> And if there were a way to pass formatting information, that would be evenErr? Beyond { expr ; fmt } expanding to expr.formatted("fmt")? What
> better--maybe something with automatic deconstruction of tuples? I haven't
> had time to come up with something elegant and general.
else would you need?
def col(i: Int, n: Int) = s"{i;{n}d}"
The latter is okay or not? If yes, awesome, but that's not exactly what "arbitrary string of characters" brings to mind. And this is only with the same sort of processing embedded; if you want to switch, it's not clear how one could accomplish that. If you can't parameterize your formatting, you're missing half the point of parameterizing.
--Rex
Daniel Sobral
Oh, God, you're right! Sure, { x; 2.2f } looks nicer than { x; "2.2f"
}, but, in practice, you're quite likely to need a formatting computed
at run-time! Please, do comment this on the SIP.
Rex Kerr
<xml>{val a = 7; a*a+a}</xml>
produces <xml>56</xml>. This is very useful, since it lets you embed complex expressions easily.
But with the current format proposal, this wouldn't work:
s"{val a = 7; a*a+a}"
would send " a*a+a" as the format string with the empty string as content. Well, fair enough, use more braces:
s"{{val a = 7; a*a+a}}"
but, no, {{ and }} are interpreted as escapes, so this gives "{val a = 7; a*a+a}". So you'd have to
s"{ {val a = 7; a*a+a} }"
in order to actually get a block, which is sort of weird-looking and possibly fragile, especially if you wanted to combine it with formatting:
s"{ {val a = 7; a*a+a}; 5d}" // doesn't do what you think
s"{ {val a = 7; a*a+a};5d}" // imbalanced, ugly
s"{ {val a = 7; a*a+a} ;5d}" // works, but maybe error-prone?
So maybe we can change the rule for escaping braces to be that in normal strings you use \{ and \}, and in raw strings you are out of luck (where out of luck means you use string interpolation: {'{'} and {'}'}).
Then at least you could write blocks with double braces.
But this makes me wonder whether the default shouldn't be a block, with formatting set off by an empty statement:
s"{val a = 7; a*a+a; ;5d}" // Previous example
s"{4;;5d}" // Just want to print 4 with spaces
Here I'm not sure; this favors complex usage over simple usage, which arguably is the wrong way to go.
--Rex
Eugene Burmako
semicolon. In that case, rare occasional semicolons at the end of the
expression can be easily negated by wrapping a relevant part of the
expression in paretheses.
>
>
>
> > Hi Daniel, I now opened comments on the Google doc. I am not sure why
> > embedded Google Docs in a SIP mean that the normal comment function on the
> > SIP is disabled, but that seems to be the case.
>
> > Looking forward to your comments.
>
> > -- Martin
>
>
> >> On Thu, Oct 27, 2011 at 11:28, martin odersky <martin.oder...@epfl.ch>
> >> > I just augmented my string interpolation proposal with an alternative
> >> syntax
> >> > and mechanism. I like the alternative better because it is far more
> >> general
> >> > than the first proposal.
>
> >> On the document, it tells me I cannot comment on it. Wasn't the
> >> ability to comment on the proposals one of the goals? Also, I can only
> >> see the document embedded (maybe I'm missing something?), which is
> >> rather uncomfortable.
>
> >> I do have some comments. I'll wait to see if I should make them here,
> >> or if I should do them on the document.
>
> >> --
> >> Daniel C. Sobral
>
> >> I travel to the future all the time.
>
> > --
> > Martin Odersky
Eugene Burmako
Arioch
<ich...@gmail.com> сообщал:
> And if there were a way to pass formatting information, that would be
> even better--maybe something with automatic deconstruction of tuples? I
> haven't had time to come up with something elegant and general.
Maybe sub-expression ? Some standard library ?
Implicit cast to one of formatter classes, which result in string
expression instead of integer?
From s"I ate {n} apples" to like s"I ate {n.format.base(16)} apples"
One more thing is parameters reordering. Natural words order is different
in languages.
Say, in English it is adjective-noun but in Latin/French/Spanish/Italian
it is noun-adjective.
"Living water" or "aqua vita"
If translating any long enough text from English to Russian you found that
either you end with some Frankenstein of language, or you need to reorder
even subclauses in complex sentences.
One more example would be address, should it be ordered from {apartment
No} to {street} to {city} up to {country} ? Or from {country} down to ...
{apartment No} ?
While C sprintf-like specification - template string with placeholders,
followed by array of values - is harder to type and read, it allows
reordering on localisation, without changing program sources.
To integrate GetText-like functionality with StringContext(strings
list).method(valus list) it seems like intermediate layer like
StringContext(strings
list).localizer-and-reoderer(locale-info).method(values list) is required,
but injecting it after JARs are made is not so nice, as to have it in
place already.
--
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
Benjamin Jackman
Benjamin Jackman
Arioch
<benjamin...@gmail.com> сообщал:
> location in an expression anyhow? Just brainstorming.
If just brainstorming... function(Unit) aka call-by-name
{expression; yet expression; still expression; => now format}
Arioch
<benjamin...@gmail.com> сообщал:
> Maybe something other than ; there, perhaps just a normal ','
if to treat it like normal infix method AnyVal => string
{{val a = 7; a*a+a} infix-format 000d }
What are possible symbols not yet taken for one or another operator ? :-)
That would made typing longer, but then format specifiers no more are
special case