[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jose E. Marchesi
Subject: Re: [RFC] More powerful string literals, instead of new format function
Date: Fri, 12 Mar 2021 23:46:23 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]