I took a partial, initial attempt at adding string formatting in scripts

[jamesblacklock]

Here is my branch: https://github.com/jamesblacklock/sixtyfps/tree/str-format

This is not complete for a few reasons:

1. no cpp codegen at the moment
2. no way to validate format strings during code generation, so invalid format strings will be a rust compile error rather than a .60 compile error
3. not all error messages have been added in the right places
4. no test cases have been created yet

However, it seems to me this is a really important feature to have, so I'm curious what feedback the project maintainers have on this idea or how I should improve it.

Thanks!

[ogoffart]

I'm really happy to see contributions to SixtyFPS, thank you.

I think we need some discussion about the use case for the format feature. And what kind of format string we accept.
We already have a string interpolation with the \{} syntax:

text: "hello \{root.name}!";

But is format string still a preferred feature to string interpolation?

One usecase i am aware of is for the translations, which we want to support soon. And i have some notes in the issue #33 already.
But this need a runtime format. The tr crate has its own runtime formating functions which we could extract into another crate. https://github.com/woboq/tr/blob/master/tr/src/lib.rs#L74 (or find another crate)

[ogoffart]

the Dart programming language uses toStringAsFixed, toStringAsPrecision and toStringAsExponential. I kind of like the explicit names choosen by dart.

But either way, i think a method like to-fixed(2) is what we want. We can still bikeshed on the name later :-)

[jamesblacklock]

But there are other considerations, such as zero padding, sign, etc.

[ogoffart]

If we follow the javascript way, ToFixed and toPrecision always add 0 padding.
Not sure what you mean with the sign, it can always be removed with abs(...) (which perhaps we should also allow .abs()?)

[jamesblacklock]

What I mean is padding at the beginning: 00.20
Most number formatters also have an "always show sign" option: +2, -4, etc.

[tronical]

so maybe blance.to-str({ precision: 2 })

Yes, exactly. I think conceptually this is similar to Intl.NumberFormat.

Javascript has different function: toFixed(2) , toPrecision(2) and also toExponentioal and toLocaleString. Perhaps good to take as a source of inspiration as well.

Yes, for convenience I think toFixed(2) etc. make sense to offer, aside a more general function to convert float to string.

Regarding naming: I favour to-string over to-str - just like the array length is also length instead of len.

[ogoffart]

Regarding the implementation, i'm not sure why you added the Type::VariadicFunction, but we already have kind of variadic function like the debug() function or the min and max functions.
These are internally first considered as BuiltinMacroFunction and are lowered to actual typed function call in builtin_macros.rs, I believe the format-str function should be very similar to the debug function because in the end, all its arguments need to be converted to strings.

[jamesblacklock]

I don't think I had a good reason haha. Still learning the codebase.

[DaMilyutin]

I was going to ask about format.

Keep in mind C++20 format approaches:
https://en.cppreference.com/w/cpp/utility/format
https://en.cppreference.com/w/cpp/utility/format/formatter#Standard_format_specification
https://en.cppreference.com/w/cpp/utility/format/formatter

Sorry throwing that many links at you. :-)

[ogoffart]

I think "\{slider.value.to-fixed(2)}" is more readable and explicit than "\{slider.value : 0.2f}"
(although in this example one would just write slider.value.to-fixed(2) )

So I believe it would be better to have simple function like to-fixed or have something like slider.value.format({ minimum-fraction-digits: 2 })

[DaMilyutin]

This looks closer to pipeline approach. Like you may want to add some other format-traits:
\{slider.value.precision(2).width(10).align_left().fill(0)} // I've taken some names from C++ <iomanip>

I'll give you something to think about format language design. :-)
As you know С had formats like printf("%10.4f", value);
Then C++ added iostreams std::cout<< std::setw(10) << std::setfill('*') << std::setprecision(2) << value;
But then C++ turned to python-like std::format I mentioned above.
And this history of format language design shows (in area of C++) that we returned almost to where we started.
iostream approach was way too verbse and it had to much syntax noise:
you don't see your final string after those format manipulators.

Why C++ turned to iostream? Because it is type-safe.
Why C++ turned to format? Because it is both type-safe (in compile time, AFAIK) and compact/short-spoken.

I'll add extra link which is almost cheat-sheet for C++ format
https://www.modernescpp.com/index.php/std-format-in-c-20

[jamesblacklock]

I don't know if this is the place to debate the merits of one approach over another, but I'd argue that the printf style of formatter is better simply because it is so concise. I've seen C++ code where people use printf just so that they don't need all that verbose iostream crap. More recent designs, such as Python or Rust, seem to agree that concise is better, even though it is admittedly less readable. Regexes are similar; imagine if you needed to spell out, in English, everything a regex is supposed to be doing.

[tronical]

Yes, the fact that it is harder to read is exactly the main issue I have with it. Code is read a lot more often than it is written. Especially with the UI markup this includes not only hardcore software developers :-). I'm strongly in favour of a more readable API, even if that means typing more characters.

The formatting we are discussing here is in the context of user interfaces, not debugging bytes received for a serial port. So I think verbosity is a fair thing to trade in exchange for readability.

[DaMilyutin]

I'd argue that
format("float={:10.2f} int={:06}\n", some_float, some_int);
is more readable than
'cout << "float="<< setw(10) << setprecision(2) << some_float << " int=" << setw(6) << setfill(0) << some_int;'
Latter has too much noise.

I agree that common code should use English and be readable as English.
Formatting strings has its specific grammar which learned once becomes simple and easy.

Imagining how I understand your vision, in sixtyfps it turns to
"float=\{some_float.width(10).precision(2)} int=\{some_int.width(6).fill(0)}"
Actually, it is quite coincise and readable.
Do you want it to look like this?

Total python-like will look like this: "float=\{some_float: 10.2f} int=\{some_int: 06}"

[ogoffart]

Regarding formatting, we really need something in SixtyFPS, but it has to be in combination with translation (i18n) and we can also have a function that do the formatting without the translation. So from the discussion I had with @tronical , we agree that

• We want the translation to use the English text in the source code (as opposed to id), and that is extracted by a tool for translations.
• The translations will also be used in the native code (Rust, C++, ...) and so the formatting should also work there, with the same syntax. I would not even be opposed to support different dialect of the formatting syntax that can be changed with a pragma or some options, so it can be the same as whatever translation format is used.
• We kind of like the way rust and other modern frameworks do it from simple thing with {} or {0} or {foo}, but anything more complex like specifying number formatting or plural handling we don't know what to do there, but we know it is important and complex
• We looked at ICU message format because it was mentioned before, but we couldn't really find a good spec. (We also don't like the way the '{' is escaped.

Remember there are different level to how translation work:

1. how it looks in the source code, e.g, using a @tr("...", foo = self.foo, bar = root.bar * 5) macro from which string can be extracted. The macro might need also some context useful for translation
2. The runtime lookup of the translation that needs to be delegated to a backend (e.g: gettext)
3. The formatting (what we're talking about here) which implies substituting the parameter, possibly with plural handling, numerical formatting, or more advanced cases.

2. and 3. should be delegated to other crates, that can also be exposed to C++ and other languages.

We would need a survey on how translation are done in other languages and what formatting they used for translation. I'm only familiar with the KDE k18n framework, but I'm sure lots of other people have thought about that.

I'm glad this is being discussed here so we can move forward on #33 too.

[DaMilyutin]

I still think that using Rust std.fmt or C++20 std::format is preferrable.
I insist that there may be intersection of both of those format syntaxes (there are some differences).
This will allow to pass those strings easily between both C++20 and Rust and use them in .60 files as well.

Repeating links
https://doc.rust-lang.org/std/fmt/ (probably well known to all Rust develpers)
There was repo named fmt whish merged into C++20 standard library:
https://fmt.dev/8.0.1/syntax.html (better description of fmt; may differ, insufficiently - I assume, from std::format)
It can be used to build in to C++ prior to C++20.

For language translation I'd translate only what goes outside formatting syntax {}.
I don't get right what you want, probably...
Maybe you mean locale (this may affect how format outputs)
https://en.cppreference.com/w/cpp/locale/locale

P.S. Sorry, if I've said something obvious... or noob.