ASR: add string formatting nodes

[certik]

One way to handle string formatting and printing in a language independent approach is to decouple string formatting form printing. The Print ASR node would just do printing and printing related flags. I think it's pretty much there.

Then we need an expr node like StringFormat, which will handle all string formatting. The string formatting is inherently runtime operation, so the StringFormat would accept the format string (in various styles) and the variables to format, and it would produce formatted string. It is not clear if a single StringFormat can handle all formatting styles. If not, we will introduce StringFormatFortran, StringFormatC, StringFormatPython1 (%s style), StringFormatPython2 (the {} style) etc. (there are also f-strings in Python, it would be nice to generate the original f-string from ASR if possible).

Then in Fortran print "(i0, i0)", a, b will become Print(StringFormatFortran("(i0, i0)", a, b)), and Python's print("%d %d", a, b) would become Print(StringFormatPython1("%d %d", a, b)).

[certik]

There is also Python's "%r" % some_object (and also %s), it seems it should be part of StringFormatPython1, to handle the %r and %s correctly. Then print(l) becomes Print(StringFormatPython1("%s", l)) and repr(l) becomes StringFormatPython1("%r", l) and str(l) becomes StringFormatPython1("%s", l).

[czgdp1807]

Just a note.
While implementing, we should test this approach with the following types (mixed types of container data structures).

1. list[dict[i32, tuple[i32, f64]]]
2. tuple[list[i32], dict[i32, f64]]
3. dict[tuple[i32, str], list[dict[i32, i64]]]
4. .
5. .
6. .
7. Any combination of aggregate data types like list, tuple, dict and so on.

[ubaidsk]

One of the concerns that I have with this approach is that

• As per the ASR Specification here, it seems ASR is self-contained and complete
• If we have nodes like StringFormatC or StringFormatPython3 in the ASR, it seems that the ASR in a way might not look complete, since there could always be a language for which we did not yet define an ASR node.
• Or whenever we add/define/develop a new language frontend, we would need to add a new node to the ASR for print formatting of this specific language, thus the ASR does not look self-contained (since it is being needed to be extended/modified for every new langauge frontend).

[ubaidsk]

Would it be possible/feasible to define a StringFormatC or StringFormatPython3 function in every front-ends builtin runtime library?

[ubaidsk]

Please, could someone possibly share about #1129 (comment) and #1129 (comment)?