Re: [RFC] More powerful string literals, instead of new format function

[Jose E. Marchesi]

Hi Mohammad.

> === Proposal for Poke
>
> I propose a Python-like string literal: f-strings.

I am not convinced at all about this.

I think that the "inline" nature of these f-strings is more suitable for
dynamically typed languages like Python or sh, or for homoiconic
languages like Lisp or Tcl, than for a statically typed language like
Poke.

In dynamically typed languages the slots, or tags, in the formatted
strings are simple: an expression.  Like "Age is {age}" or "Age is
$(($age + 8))" or "Age is [expr $age + 8]".

But Poke is statically typed and the %-tags can be non-trivial.  Besides
%v, which works for any value and uses the poke default value printer,
we have %i, %s, and so on, and the compiler performs type-checking on
them.  The %-constructs also admit flags and arguments, like %5Tv.  And
some others are required to be nested and/or paired like %<CLASS: and
%>.

It seems to me that expressing all that in inline tags, which require
the value/expression to be denoted also inline, would require a fairly
complex mini-language.

Also, if we have both "normal" string literals and f-string literals,
what will happen to printf?  Will we keep it?  Will we remove it?

Finally, the f-strings would also be not that familiar for our main
target audience: C and C++ programmers.

I would really base `format' in the same form that `printf' has:

  printf (FMT, [ARGS...])
  format (FMT, [ARGS...])

> - I think `==` for strings should remain as it is, and should not consider
>   the metadata.

Yes, definitely.