Jarrett Billingsley wrote:
[...]
> Now look at a language like Japanese, where you'd probably put the database name first; it'd be arranged something like "in personnel database {}, employee {} does not exist".  Now you have to change the order of the arguments after the format string.  But with indexing, you can say {0} always is the employee name, and {1} always is the database name, so that you can format them in the correct order for other languages, without having to change the actual format code.  Just change the format string.

May I suggest to use an identifier instead of a numeric index?
I have several years of experience with multi-language code and I can say that for a translator is better.

For example:

"{0} has {1} pieces in {2}"

Could be:

"{supplier} has {stock} pieces in {city}"

and make the translator happy.

Ciao

Roberto Mariottini wrote:
> Jarrett Billingsley wrote:
> [...]
>> Now look at a language like Japanese, where you'd probably put the database name first; it'd be arranged something like "in personnel database {}, employee {} does not exist".  Now you have to change the order of the arguments after the format string.  But with indexing, you can say {0} always is the employee name, and {1} always is the database name, so that you can format them in the correct order for other languages, without having to change the actual format code.  Just change the format string.
> 
> May I suggest to use an identifier instead of a numeric index?
> I have several years of experience with multi-language code and I can say that for a translator is better.
> 
> For example:
> 
> "{0} has {1} pieces in {2}"
> 
> Could be:
> 
> "{supplier} has {stock} pieces in {city}"
> 
> and make the translator happy.

How would such identifiers be matched up with variadic arguments?


Sean

Sean Kelly wrote:
> Roberto Mariottini wrote:
>> Jarrett Billingsley wrote:
>> [...]
>>> Now look at a language like Japanese, where you'd probably put the database name first; it'd be arranged something like "in personnel database {}, employee {} does not exist".  Now you have to change the order of the arguments after the format string.  But with indexing, you can say {0} always is the employee name, and {1} always is the database name, so that you can format them in the correct order for other languages, without having to change the actual format code.  Just change the format string.
>>
>> May I suggest to use an identifier instead of a numeric index?
>> I have several years of experience with multi-language code and I can say that for a translator is better.
>>
>> For example:
>>
>> "{0} has {1} pieces in {2}"
>>
>> Could be:
>>
>> "{supplier} has {stock} pieces in {city}"
>>
>> and make the translator happy.
> 
> How would such identifiers be matched up with variadic arguments?

hmm.. Could it match the variable names with the inserts?

string supplier = "Bob";
string city = "Someplace far far away";
int stock = 5;

format("{supplier} has {stock} pieces in {city}",
  supplier, city, stock);

Maybe with some more reflection features it could be possible.

Regan

Regan Heath Wrote:

> >> For example:
> >>
> >> "{0} has {1} pieces in {2}"
> >>
> >> Could be:
> >>
> >> "{supplier} has {stock} pieces in {city}"
> >>
> >> and make the translator happy.
> > 
> > How would such identifiers be matched up with variadic arguments?
> 
> hmm.. Could it match the variable names with the inserts?
> 
> string supplier = "Bob";
> string city = "Someplace far far away";
> int stock = 5;
> 
> format("{supplier} has {stock} pieces in {city}",
>    supplier, city, stock);
> 
> Maybe with some more reflection features it could be possible.
> 
> Regan
> 
>

Well, not even scripting languages keep names of local variables in memory at runtime, so I assume you mean compile-time. That means that the localized properties would have to be known at compile time (via file imports, etc.), which, assuming you store every language in the executable, might lead to some code bloat and a not-so-nimble architecture. But if that's what you're going for, someone demonstrated a while back that this is already possible, via mixins, and will get a lot easier with macros. Search for PHP-style print or something like that (I'm too lazy & limited by BlackBerry bandwidth to  get you the exact link).

Robert Fraser wrote:
> Well, not even scripting languages keep names of local variables in
> memory at runtime...

Hmm?

>>> a = 12
>>> b = 'waffles'
>>> locals()
{'__builtins__': <module '__builtin__' (built-in)>, '__name__': '__main__', 'b': 'waffles', '__doc__': None, 'a': 12}
>>> "%(a)s %(b)s" % locals()
'12 waffles'

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org

Roberto Mariottini wrote:
> May I suggest to use an identifier instead of a numeric index?
> I have several years of experience with multi-language code and I can say that for a translator is better.
> 
> For example:
> 
> "{0} has {1} pieces in {2}"
> 
> Could be:
> 
> "{supplier} has {stock} pieces in {city}"
> 
> and make the translator happy.


It's an interesting idea, but the trick is knowing how to go from the identifier into the literal numerical index of the arguments.  Something like "{0,supplier} has {1,stock} pieces in {2,city}" could work.

Of course, if you're really going to support internationalization, it'd be nice to not need to translate one copy of the program into another and simply embed the text for multiple languages in the command line. Another candidate would be to put it through some kind of behind the scenes translator.  Maybe the two could be combined...  where the program could be run for a specific language and text would be translated first by a manual translation if available and then either dump the original (english) or attempt an automatic translation.

Kirk McDonald wrote:
> Robert Fraser wrote:
>> Well, not even scripting languages keep names of local variables in
>> memory at runtime...
> 
> Hmm?
> 
>  >>> a = 12
>  >>> b = 'waffles'
>  >>> locals()
> {'__builtins__': <module '__builtin__' (built-in)>, '__name__': '__main__', 'b': 'waffles', '__doc__': None, 'a': 12}
>  >>> "%(a)s %(b)s" % locals()
> '12 waffles'
> 

And if I may add:

<?php

$a = 5;
$b = 'a';
$$b = 'Hello, world!';
echo $a;

?>

Robert Fraser wrote:
> Regan Heath Wrote:
> 
>>>> For example:
>>>>
>>>> "{0} has {1} pieces in {2}"
>>>>
>>>> Could be:
>>>>
>>>> "{supplier} has {stock} pieces in {city}"
>>>>
>>>> and make the translator happy.
>>> How would such identifiers be matched up with variadic arguments?
>> hmm.. Could it match the variable names with the inserts?
>>
>> string supplier = "Bob";
>> string city = "Someplace far far away";
>> int stock = 5;
>>
>> format("{supplier} has {stock} pieces in {city}",
>>    supplier, city, stock);
>>
>> Maybe with some more reflection features it could be possible.
>>
>> Regan
>>
>>
>  Well, not even scripting languages keep names of local variables in memory at runtime, so I assume you mean compile-time. That means that the localized properties would have to be known at compile time (via file imports, etc.), which, assuming you store every language in the executable, might lead to some code bloat and a not-so-nimble architecture. But if that's what you're going for, someone demonstrated a while back that this is already possible, via mixins, and will get a lot easier with macros. Search for PHP-style print or something like that (I'm too lazy & limited by BlackBerry bandwidth to  get you the exact link).

That was me. It's true, no new reflection features are required. The difficulty is in deciding how it should work, rather than implementing it.
Specifically, what do you do if some of the variables are calculations?
Eg, if stock is (palettesize*numberofpalettes*15) ?
You could do
format("{supplier} has {stock = (palettesize*numberofpalettes*15)} pieces in {city}");
But I don't think that's what was intended -- you don't want the translator seeing the calculations!

You could have a separate string converting names to indices, but it's starting to look clumsy.

Don Clugston wrote:
> Robert Fraser wrote:
>> Regan Heath Wrote:
>>
>>>>> For example:
>>>>>
>>>>> "{0} has {1} pieces in {2}"
>>>>>
>>>>> Could be:
>>>>>
>>>>> "{supplier} has {stock} pieces in {city}"
>>>>>
>>>>> and make the translator happy.
>>>> How would such identifiers be matched up with variadic arguments?
>>> hmm.. Could it match the variable names with the inserts?
>>>
>>> string supplier = "Bob";
>>> string city = "Someplace far far away";
>>> int stock = 5;
>>>
>>> format("{supplier} has {stock} pieces in {city}",
>>>    supplier, city, stock);
>>>
>>> Maybe with some more reflection features it could be possible.
>>>
>>> Regan
>>>
>>>
>>  Well, not even scripting languages keep names of local variables in memory at runtime, so I assume you mean compile-time. That means that the localized properties would have to be known at compile time (via file imports, etc.), which, assuming you store every language in the executable, might lead to some code bloat and a not-so-nimble architecture. But if that's what you're going for, someone demonstrated a while back that this is already possible, via mixins, and will get a lot easier with macros. Search for PHP-style print or something like that (I'm too lazy & limited by BlackBerry bandwidth to  get you the exact link).
> 
> That was me. It's true, no new reflection features are required. The difficulty is in deciding how it should work, rather than implementing it.
> Specifically, what do you do if some of the variables are calculations?
> Eg, if stock is (palettesize*numberofpalettes*15) ?
> You could do
> format("{supplier} has {stock = (palettesize*numberofpalettes*15)} pieces in {city}");
> But I don't think that's what was intended -- you don't want the translator seeing the calculations!
> 
> You could have a separate string converting names to indices, but it's starting to look clumsy.

Alternatively, you could generate a name-to-varargs-index AA at compile-time, and use this in your runtime string formatter. Something like:

int stock = ... ;
string supplier = ... ;
City city = ... ;
string formatstring = getLocalizedFormatString(); // runtime
mixin(DoRuntimeFormat!(formatstring, stock, supplier, city));

...

template DoRuntimeFormat(alias formatString, Names...)
{
    const char[] DoRuntimeFormat = "format(" + formatString.stringof
       + ", " + ConvertToAA!(Names) + ");";
}


  -- Reiner

Julio César Carrascal Urquijo wrote:
> Kirk McDonald wrote:
>> Robert Fraser wrote:
>>> Well, not even scripting languages keep names of local variables in
>>> memory at runtime...
>>
>> Hmm?
>>
>>  >>> a = 12
>>  >>> b = 'waffles'
>>  >>> locals()
>> {'__builtins__': <module '__builtin__' (built-in)>, '__name__': '__main__', 'b': 'waffles', '__doc__': None, 'a': 12}
>>  >>> "%(a)s %(b)s" % locals()
>> '12 waffles'
>>
> 
> And if I may add:
> 
> <?php
> 
> $a = 5;
> $b = 'a';
> $$b = 'Hello, world!';
> echo $a;
> 
> ?>

And also Ruby.

# names.rb
puts Symbol.all_symbols.inspect


This will print for you an array of a few thousand symbols from the runtime, among them the names of many variables.  Changing the source to:
myVar = 42
puts Symbol.all_symbols.index(:myVar)

Gave me '1117'.  At least in Ruby each such symbol is retained exactly once, no matter how many things have that name.  (Otherwise... could you imagine the memory consumption...)

-- Chris Nicholson-Sauls