[vim/vim] Proposal: the string interpolation (the template string) (#4491)

[aiya000]

Instructions: Replace the template text and remove irrelevant text (including this line)

---

Hi, Bram.
I'm a you and Vim's fan!

Is your feature request related something that is currently hard to do? Please describe.

I want to introduce the string interpolation (the template string) into Vim script.

Now it is introduced onto

• JavaScript
  • and TypeScript
• Kotlin
• Scala
• Ruby
• C#
• Swift

Describe the solution you'd like

A clear and concise description of what you want to happen.

'The string interpolation' ('The template string') embeds any expressions ${x} into a string via Vim function string().

For example.

" Embed literals using back quotations (the template string) and "${" "}"

call assert_equal(`I have ${10}`, 'I have 10')

call assert_equal(`I'm a ${'vim'}`, "I'm a vim")



" Variables

let x = 10

call assert_equal(`I have ${x}`, 'I have 10')



" Others

let x = ch_open('localhost:25252')  " dummy

call assert_equal(`${x}`, string(x))

I'm refering to the JavaScript's format of ${x} for the Vim script's template string.
(${x} ${dict.a} ${10} ${function('function')})

These expressions must be surrounded by "${" and "}".

---

I'm implementing it now.
The test can be shown at here :D

Please see this 👇 if you can!

• vim/test_string_interpolation.vim at ec933cee9d9cb2b1bd5b3f3fa69f8dc214989c2a - aiya000/vim - GitHub

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

I'm planning a template string form $"I'm ${name}" (surrounded by $" and ")
if Bram doesn't like a back quoted form I'm ${name}.

Additional context

After it introduced, expression embedding is to be more easier, and I think it is very cool!

---

Thanks!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[aiya000]

I'm implementing this at here :D

[Bram Moolenaar]

Backticks are hard to use on some keyboards, and also they are hard to distinguish from single quotes.
On top of that, Vim has two types of strings: single quoted and double quoted. Both are useful.
Therefore the $"template" and $'template' syntax seems a better solution.
Since we only used $ for environment variables, I don't think there is a conflict with existing syntax.

For $"foo ${var} bar" I assume that "var" is taken literally, thus backslashes are kept as-is.

[aiya000]

Thank you, Bram!

That solution seems very good!
I'll implement $'' and $"" 👍

[aiya000]

I force-pushed the newer test here :)

[Houl]

What about instead adding a function similar to eval() or map() to perform the interpolation? Eg interpol().

Or what about instead adding a function to create an intermediate representation (ie a Vim expression) which can then be eval()uated?

And for the syntax:
We already have statusline syntax: abc%{expr}def, how about reusing that?

[Bram Moolenaar]

> I force-pushed the newer test [here](https://github.com/aiya000/vim/blob/cde8426446d6d4c53c2614999195af4f70130b72/src/testdir/test_string_interpolation.vim) :)

Thanks. I would think this works fine.

I have some minor problem with using $"" and $'', since it results in a
lot of dollars, e.g.:

$'${[10, 20]}'

Is there any other syntax that would work better?

t'${[10, 20]}'
_'${[10, 20]}'

Opinions?

Should we also allow using $var instead of ${var}, like Python does?
It does require escaping every literal $ with $$.

--
hundred-and-one symptoms of being an internet addict:
218. Your spouse hands you a gift wrapped magnet with your PC's name
on it and you accuse him or her of genocide.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Bram Moolenaar]

> What about _instead_ adding a function similar to `eval()` or `map()`
> to perform the interpolation? Eg `interpol()`.
>
> Or what about _instead_ adding a function to create an intermediate
> representation (ie a Vim expression) which can then be `eval()`uated?

Python has the Template() constructor for this. It's a more heavy
mechanism.

> And for the syntax: We already have statusline syntax:

> `abc%{expr}def`, how about reusing that?

That makes sense. Javascript, Typescript and Python use ${expr} though.
Also, printf() templates use %. Not sure what weighs more.

--
hundred-and-one symptoms of being an internet addict:

219. Your spouse has his or her lawyer deliver the divorce papers...
via e-mail.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—

[aiya000]

I have some minor problem with using $"" and $'', since it results in a
lot of dollars, e.g.:

Is there any other syntax that would work better?
Opinions?

I like $"" and $'' the best, but I think it is good to add 't'' and t""' or '_'' and _""' as that synonym 👍

Should we also allow using $var instead of ${var}, like Python does?

I thought it, and took a questionnaire to

What do you like any support?



1. only ${var}

2. only $var

3. both ${var} and $var

the 1. is gotten most votes!

I think $var can be appended later if $var is needed later.
But I wish to will start off of with only ${var} now 😂
(I don't hate $var :D)

It does require escaping every literal $ with $$.

Good!
I'll implement the escaping as it!

[Nick Jensen]

The 3 types of string interpolation I'm used to seeing and using are:

1. javascript/typescript:

   `Value is: ${val}`

2. python:

   f'Value is {val}'
   f'Literal braces: {{}}'

3. C#:

   $"Value is {val}"
   $"Literal braces: {{}}"

Keeping similar to at least one of these seems sensible - since javascript is so popular these days my preference would be to use that syntax. The other nice thing about the javascript/typescript syntax is that you don't have to escape literal characters - $, { and } can all be used alone, the interpolation only captures the full ${} pattern.

[chdiza]

I don't see the point of any of this, as opposed to just using existing concatenation. Doing let foo = "one $[bar} baz" saves only one measly character when compared with let foo = "one ".bar." baz"

[aiya000]

@chdiza Maybe it is a question for general 😂
Please find the purpose of other languages :)

[Bram Moolenaar]

> The 3 types of string interpolation I'm used to seeing and using are:
>

> 1. javascript/typescript:
> ```javascript
> `Value is: ${val}`
> ```
> 2. python:
> ```python

> f'Value is {val}'
> f'Literal braces: {{}}'

> ```
> 3. C#:
> ```cs

> $"Value is {val}"
> $"Literal braces: {{}}"
> ```
>
> Keeping similar to at least one of these seems sensible - since
> javascript is so popular these days my preference would be to use that
> syntax. The other nice thing about the javascript/typescript syntax is

> that you don't have to escape literal characters - `$`, `{` and `}`

> can all be used alone, the interpolation only captures the full `${}`
> pattern.

I also use Javascript/Typescript regularly, which is why I know the
backtick is hard to recognize. It depends on the font, but it looks
very much like the backtick. This may lead to mistakes.

I agree that using just $val or {val} has the problem of much more
escaping. "${" is pretty rare to encounter.

I actually like how _"template" and _'template' look, but I don't think
any other language does that, thus it's a bit weird.

--
hundred-and-one symptoms of being an internet addict:

234. You started college as a chemistry major, and walk out four years
later as an Internet provider.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—

[aiya000]

After all, I like $var too :D

I want to implement

• $"" and _""
• $'' and _''
• $var ${var} ${literals}
  • var doesn't need the surround {}, literals must be surrounded by {}. e.g. $10 and $string(30) is illformed. $var and ${var} is well-formed.

Can I make this? 😃

[aiya000]

(I like a form $'' and $"" 😂 I want to this.)

[K.Takata]

Isn't $var confusing with environment variables?

[Nick Jensen]

I also use Javascript/Typescript regularly, which is why I know the
backtick is hard to recognize. It depends on the font, but it looks
very much like the backtick. This may lead to mistakes.

OK, that's fair enough Bram (although I don't personally find it confusing and, as noted, this is already used by javascript/typescript so clearly many people find it acceptable).

My one last statement in favour of the javascript/typescript syntax is that vim already uses the {} interpolation characters in :h curly_brace_names, where it is possible in vimscript to do this:

let my_{&filetype}_variable = 'something';

It would be nice and consistent to then be able to do this:

let my_{&filetype}_variable = `something {&filetype}-specific`;

[Nick Jensen]

Apologies, I'm clearly typing before thinking, the curly_brace_name syntax is similar to C# syntax, not javascript/typescript syntax, as there is no leading $ before the interpolation {} characters. So perhaps the C# syntax would be appropriate?

let my_{&filetype}_variable = $"something {&filetype}-specific (escaping with doubled characters for literal {{ and }})"

[Linda_pp]

Just idea, but from Swift langauge's string literal, I wonder \(...) with extending existing double quote strings might match to Vim script.

print("6 times 7 is \(6 * 7).")

Though it does not fully maintain backward compatibility, \( simply represents( in "..." literal so it should not appear in current Vim script codebases.

• Pros: we don't need a new type of string literal
• Cons: backward compatibility is not fully maintained

[aiya000]

Just idea, but from Swift langauge's string literal, I wonder (...) with extending existing double quote strings might match to Vim script.
print("6 times 7 is (6 * 7).")

Oh, I didn't bethink "(xxx)"..., but this is the best choice in my opinion!
I'll re-implementing all to this if Bram is OK :)

(
Does this mean that doesn't support string-interpolations in string literals?

echo "\(10)"
" ==> 10

echo '\(10)'
" ==> \(10)

I think this is very good.
)

[Linda_pp]

Thank you for the quick and positive response.

Does this mean that doesn't support string-interpolations in string literals?

Yes, I meant that. Since single quote string is something like raw string literals in other languages, no interpolation sounds natural for me.

But it's just an idea. There may be some mismatch to Vim script. So let's carefully consider grammar. After some thoughts, I came up with possible confusion. \(...) in double quote is similar to \(...\) in single quote string (grouping of regex).

[Bram Moolenaar]

> > I also use Javascript/Typescript regularly, which is why I know the
> > backtick is hard to recognize. It depends on the font, but it looks
> > very much like the backtick. This may lead to mistakes.

I of course meant that a backtick looks very much like a single quote.

> OK, that's fair enough Bram (although I don't personally find it

> confusing and, as noted, this _is_ already used by

> javascript/typescript so clearly many people find it acceptable).

These decisions are often made by a committee, it doesn't mean it's
always a good idea. Perhaps they used a font where it is not a problem.
For Vim it's nice if we can use a syntax that script writers recognize,
but we also want to avoid things that have turned out to be a
not-so-great choice.

There are other languages where a prefix to a string changes the meaning
of that string, we can at least follow that pattern.

> My one last statement in favour of the javascript/typescript syntax is
> that vim already uses the `{}` interpolation characters in `:h

> curly_brace_names`, where it is possible in vimscript to do this:
>
> ```vim

> let my_{&filetype}_variable = 'something';
> ```
>
> It would be nice and consistent to then be able to do this:
>

> ```vim
> let my_{&filetype}_variable = `something {&filetype}-specific`;
> ```

The use of {} like that has been deprecated, there are too many subtle
corner cases with it. I also don't see it used much.

--
"The amigos also appear to be guilty of not citing the work of others who had
gone before them. Even worse, they have a chapter about modeling time and
space without making a single reference to Star Trek!"
(Scott Ambler, reviewing the UML User Guide)

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—

[Bram Moolenaar]

> Just idea, but from [Swift langauge's string literal](https://docs.swift.org/swift-book/LanguageGuide/StringsAndCharacters.html), I wonder `\(...)` with extending existing double quote strings might match to Vim script.
>
> ```swift

> print("6 times 7 is \(6 * 7).")

> ```
>
> Though it does not fully maintain backward compatibility, `\(` simply represents`(` in `"..."` literal so it should not appear in current Vim script codebases.
>
> - Pros: we don't need a new type of string literal
> - Cons: backward compatibility is not fully maintained

I do not see a good reason to break backwards compatibility.
Also, for single quotes a backclash is not a special character.
I would not want to limit this to double quoted strings.

--
hundred-and-one symptoms of being an internet addict:

239. You think "surfing" is something you do on dry land.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—

[aiya000]

I would not want to limit this to double quoted strings.

I see 👍
I'll proceed with $'' $"" and _'' _"".

[Yegappan Lakshmanan]

Hi,

The taglist plugin (which was developed back in 2002 and widely used)
heavily uses the curly brace syntax in variables. This was implemented
before Lists/Dicts were added to Vim.

https://www.vim.org/scripts/script.php?script_id=273
http://vim-taglist.sourceforge.net/index.html

- Yegappan

[vim-dev ML]

[aiya000]

Now implement state!

• Maybe, most implementation is done
• A little of parsing is rest
• Currently using back quotations. $'' $"" and _'' _"" will be used

—
You are receiving this because you commented.

[aiya000]

The taglist plugin (which was developed back in 2002 and widely used)
heavily uses the curly brace syntax in variables. This was implemented
before Lists/Dicts were added to Vim.

In my opinion, it has no problem 👍
Because string interpolations is available only under the $'' $"" _'' _""!

Please see above comments for back compatibilities if you want :D

—
You are receiving this because you commented.

[aiya000]

I'm working on this about everyday, please wait! :D

[aiya000]

My all tests passed!
This is checked on this revision!!

Remain tasks

• Add help
• Make syntax highlighting

[K.Takata]

• Make syntax highlighting

Syntax highlighting is maintained differently.
It is maintained by Dr. Chip, so you should sent a patch to him.

[mattn]

_"foo" breaks compatibility. Current behavior is:

:let _ = 1
:echo _"foo"
1 foo

[aiya000]

@brammool
Hi, I opened #4634 !
That is '' omitted version. because #4491 (comment) X)
Please take this patch if you ok to agree '' unsupport 🙏

Or let's discuss again about '_' support if you really wan to it 👍

—
You are receiving this because you commented.

[Bram Moolenaar]

> @brammool
> Hi, I opened #4634 !

> That is '_' omitted version. because https://github.com/vim/vim/issues/4491#issuecomment-509065896 X)
> Please take this patch if you ok to agree '_' unsupport :pray:
>
> Or let's discuss again about '_' support if you really wan to it :+1:

Thanks!

I do like how _"some ${var} here" looks, but it is an unusual syntax.
If you use gettext in Vim you wonder if the parens are missing:
_("some text here");

Although $"some ${var} here" doesn't look as nice, I haven't seen a
better syntax. Thus I think we should go with that.

--
ARTHUR: Bloody peasant!
DENNIS: Oh, what a give away. Did you hear that, did you hear that, eh?
That's what I'm on about -- did you see him repressing me, you saw it
didn't you?
The Quest for the Holy Grail (Monty Python)

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—

[FUJIWARA Takuya]

I wonder why two syntaxes of same feature are supported (_"some ${var} here", $"some ${var} here").
I don't disagree strongly that adding two syntaxes, but as my simple feeling, I think one syntax is enough.

IMHO, I recommend Python 3's f-strings syntax (because Vim script syntax is similar to Python):
https://docs.python.org/ja/3.6/reference/lexical_analysis.html#f-strings

$ python3.7
Python 3.7.3 (default, Mar 27 2019, 09:23:15) 
[Clang 10.0.1 (clang-1001.0.46.3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> var = 42
>>> print(f'some {var} here')
some 42 here
>>> print(f'some {{var}} here')
some {var} here

But f-strings has many many features (below example is from above link).
I think it's not necessary (inside {...} is just Vim expression).

>>> name = "Fred"
>>> f"He said his name is {name!r}."
"He said his name is 'Fred'."
>>> f"He said his name is {repr(name)}."  # repr() is equivalent to !r
"He said his name is 'Fred'."
>>> width = 10
>>> precision = 4
>>> value = decimal.Decimal("12.34567")
>>> f"result: {value:{width}.{precision}}"  # nested fields
'result:      12.35'
>>> today = datetime(year=2017, month=1, day=27)
>>> f"{today:%B %d, %Y}"  # using date format specifier
'January 27, 2017'
>>> number = 1024
>>> f"{number:#0x}"  # using integer format specifier
'0x400'

[FUJIWARA Takuya]

As @mattn said, f-strings syntax has also compatibility issue #4491 (comment)
But I think this is very minor edge case (specific to :echo and its familiar commands).

[aiya000]

I want $'' $"" if only one is supported :D

[aiya000]

@brammool Thanks for agreeing!
I'll fix PR reviewed terms momently 👍️

—
You are receiving this because you commented.

[aiya000]

I fixed reviews!

[Bram Moolenaar]

> I wonder why two syntaxes of same feature are supported (`_"some ${var} here"`, `$"some ${var} here"`).

> I don't disagree strongly that adding two syntaxes, but as my simple
> feeling, I think one syntax is enough.

The current plan is to only support $'string' and $"string".

> IMHO, I recommend Python 3's f-strings syntax (because Vim script
> syntax is similar to Python):
> https://docs.python.org/ja/3.6/reference/lexical_analysis.html#f-strings

There are other languages with other solutions. I don't think any of
them really stands out, it mostly depends on what you are used to.

I use Javascript/Typescript myself, and the backtick way is nicely
short, but I also have the experience that distinguising a single quote
from a backtick is quite hard, it's very easy to do wrong. It depends
on the font too.

--
-rwxr-xr-x 1 root 24 Oct 29 1929 /bin/ed
-rwxr-xr-t 4 root 131720 Jan 1 1970 /usr/ucb/vi
-rwxr-xr-x 1 root 5.89824e37 Oct 22 1990 /usr/bin/emacs

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—

[aiya000]

#4639 finished!
I'll wait to be taken the patch :D
Thanks!

[FUJIWARA Takuya]

@aiya000 maybe the pull request should be #4634.

I also want this feature.
because it improves readability a lot.

[aiya000]

@tyru Oh, that's right ><
Thanks! lol

[Bram Moolenaar]

Shouldn't this be closed now that there is #4634 ?

[aiya000]

Sure👍️

—
You are receiving this because you commented.

[aiya000]

Closed #4491.