Named parameters to format?

Named parameters to format?

[Christopher Allan Webber]

Hello all,

I've been thinking about what I'm going to do once I hit the need for
gettext support.  I'm not really sure for things that have multiple
variables in their string.  In python land, I'd do something like:

  gettext("foo %(bar) %(baz)") % {"bar": "bleh",
                                  "baz": "wonk"}

This would give translators an opportunity to move the right parameters
to the right place in the string.  However, this appears to not be
possible in our current format system, because there's no place to put
keyword based substitutable arguments.  Syntactic word ordering varies
from natural language to natural language, so...

Surely someone's run into this before?  What's the right solution?

 - Chris

Re: Named parameters to format?

[Nala Ginrut]

I don't know if someone wrote this one for format string. But there's
Python3-like string template in Artanis, say:
((make-string-template "foo ${bar} ${baz}") #:bar "bleh" #:baz "wonk")
I think it does the similar thing.

If you're interested in it, you may easily port it from Artanis. But you
need irregex as well.
https://github.com/NalaGinrut/artanis/blob/master/artanis/utils.scm#L411



On Mon, 2015-12-14 at 22:52 -0600, Christopher Allan Webber wrote:
> Hello all,
> 
> I've been thinking about what I'm going to do once I hit the need for
> gettext support.  I'm not really sure for things that have multiple
> variables in their string.  In python land, I'd do something like:
> 
>   gettext("foo %(bar) %(baz)") % {"bar": "bleh",
>                                   "baz": "wonk"}
> 
> This would give translators an opportunity to move the right parameters
> to the right place in the string.  However, this appears to not be
> possible in our current format system, because there's no place to put
> keyword based substitutable arguments.  Syntactic word ordering varies
> from natural language to natural language, so...
> 
> Surely someone's run into this before?  What's the right solution?
> 
>  - Chris
> 

Re: Named parameters to format?

[Christopher Allan Webber]

Thanks, Nala! :)

Nala Ginrut writes:

> I don't know if someone wrote this one for format string. But there's
> Python3-like string template in Artanis, say:
> ((make-string-template "foo ${bar} ${baz}") #:bar "bleh" #:baz "wonk")
> I think it does the similar thing.
>
> If you're interested in it, you may easily port it from Artanis. But you
> need irregex as well.
> https://github.com/NalaGinrut/artanis/blob/master/artanis/utils.scm#L411
>
>
>
> On Mon, 2015-12-14 at 22:52 -0600, Christopher Allan Webber wrote:
>> Hello all,
>> 
>> I've been thinking about what I'm going to do once I hit the need for
>> gettext support.  I'm not really sure for things that have multiple
>> variables in their string.  In python land, I'd do something like:
>> 
>>   gettext("foo %(bar) %(baz)") % {"bar": "bleh",
>>                                   "baz": "wonk"}
>> 
>> This would give translators an opportunity to move the right parameters
>> to the right place in the string.  However, this appears to not be
>> possible in our current format system, because there's no place to put
>> keyword based substitutable arguments.  Syntactic word ordering varies
>> from natural language to natural language, so...
>> 
>> Surely someone's run into this before?  What's the right solution?
>> 
>>  - Chris
>> 

Re: Named parameters to format?

[Mark H Weaver]

Christopher Allan Webber <cwebber@dustycloud.org> writes:

> I've been thinking about what I'm going to do once I hit the need for
> gettext support.  I'm not really sure for things that have multiple
> variables in their string.  In python land, I'd do something like:
>
>   gettext("foo %(bar) %(baz)") % {"bar": "bleh",
>                                   "baz": "wonk"}
>
> This would give translators an opportunity to move the right parameters
> to the right place in the string.  However, this appears to not be
> possible in our current format system, because there's no place to put
> keyword based substitutable arguments.  Syntactic word ordering varies
> from natural language to natural language, so...

It's true that (ice-9 format) doesn't provide a way to specify
substitutable arguments by keyword, but it _does_ provide a way to
specify arguments by index.  Search for "Argument jumping" in section
7.10 (Formatted Output) of the Guile manual.  In particular, "~0@*" sets
the argument "pointer" to the first argument (index 0), and more
generally "~N@*" jumps to argument N.  So, for example:

  scheme@(guile-user)> (format #f "~0@*~d and ~1@*~d" 1 2)
  $1 = "1 and 2"
  scheme@(guile-user)> (format #f "~1@*~d and ~0@*~d" 1 2)
  $2 = "2 and 1"

I agree that this is not very nice, and that we should find a better
solution.

      Mark

Re: Named parameters to format?

[Ludovic Courtès]

Hi!

‘format’ is an implementation of the historical Common Lisp (I think?)
thing.

The Better Approach™ is probably <http://synthcode.com/scheme/fmt>.  An
entirely different but IMO nicer approach (again, real EDSL instead of
stringy DSL.)

Ludo’.

Re: Named parameters to format?

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> ‘format’ is an implementation of the historical Common Lisp (I think?)
> thing.
>
> The Better Approach™ is probably <http://synthcode.com/scheme/fmt>.  An
> entirely different but IMO nicer approach (again, real EDSL instead of
> stringy DSL.)

For some time now, I've been thinking that we should consider adopting
<http://synthcode.com/scheme/fmt> as a replacement for 'format', but it
seems to lack any reasonable way to accomplish what Chris is asking for.

Thoughts?

      Mark

Re: Named parameters to format?

[Christopher Allan Webber]

Ludovic Courtès writes:

> Hi!
>
> ‘format’ is an implementation of the historical Common Lisp (I think?)
> thing.
>
> The Better Approach™ is probably <http://synthcode.com/scheme/fmt>.  An
> entirely different but IMO nicer approach (again, real EDSL instead of
> stringy DSL.)
>
> Ludo’.

I've been interested in fmt.  Though, I wonder if a stringly typed
system is needed for gettext compatibility?

Re: Named parameters to format?

[Ludovic Courtès]

Christopher Allan Webber <cwebber@dustycloud.org> skribis:

> Ludovic Courtès writes:
>
>> Hi!
>>
>> ‘format’ is an implementation of the historical Common Lisp (I think?)
>> thing.
>>
>> The Better Approach™ is probably <http://synthcode.com/scheme/fmt>.  An
>> entirely different but IMO nicer approach (again, real EDSL instead of
>> stringy DSL.)
>>
>> Ludo’.
>
> I've been interested in fmt.  Though, I wonder if a stringly typed
> system is needed for gettext compatibility?

Right, that’s a very good point.  I don’t think ‘fmt’ lends itself well
to i18n, which is a bummer.

Ludo’.

Re: Named parameters to format?

[Christopher Allan Webber]

Mark H Weaver writes:

> Christopher Allan Webber <cwebber@dustycloud.org> writes:
>
>> I've been thinking about what I'm going to do once I hit the need for
>> gettext support.  I'm not really sure for things that have multiple
>> variables in their string.  In python land, I'd do something like:
>>
>>   gettext("foo %(bar) %(baz)") % {"bar": "bleh",
>>                                   "baz": "wonk"}
>>
>> This would give translators an opportunity to move the right parameters
>> to the right place in the string.  However, this appears to not be
>> possible in our current format system, because there's no place to put
>> keyword based substitutable arguments.  Syntactic word ordering varies
>> from natural language to natural language, so...
>
> It's true that (ice-9 format) doesn't provide a way to specify
> substitutable arguments by keyword, but it _does_ provide a way to
> specify arguments by index.  Search for "Argument jumping" in section
> 7.10 (Formatted Output) of the Guile manual.  In particular, "~0@*" sets
> the argument "pointer" to the first argument (index 0), and more
> generally "~N@*" jumps to argument N.  So, for example:
>
>   scheme@(guile-user)> (format #f "~0@*~d and ~1@*~d" 1 2)
>   $1 = "1 and 2"
>   scheme@(guile-user)> (format #f "~1@*~d and ~0@*~d" 1 2)
>   $2 = "2 and 1"
>
> I agree that this is not very nice, and that we should find a better
> solution.
>
>       Mark

Aha, it's very helpful though!  That does solve my need.