Vim9 design choice: comments

[Bram Moolenaar]

I'm trying to make the Vim9 script syntax consistent and easy to use.
But I'm now running into something that would be a drastic change.

I already added support for comments starting with #. These are nice,
we know them from shell scripts, Python and a few other syntaxes.

Double quoted comments can currently still be used, but not everywhere.
E.g. when an expression might continue in the next line:
function("arg one",
"arg two")

This also shows the inconsistency:
myList->add(123) " works
g:myList->add(123) " works
[1, 2, 3]->Process() " works
#{a: 1, b: 2}->Process() " works
{'a': 1, 'b': 2}->Process() " works
"foobar"->Process() " does NOT work
("foobar")->Process() " works
'foobar'->Process() " does NOT work
('foobar')->Process() " works

I just made the last-but-one work, since we added the rule that a range
must start with a colon, and using a mark in a range would thus be :'t.

To make this work with a double quoted string, we don't have much choice
but to disallow double quoted comments. Since there really is no way to
tell the difference, both a string and a comment may contain anything.

Vim has always supported double quoted comments, disallowing them would
be a big divergence. But as the above shows, it does make it consistent
and easy to use. It's just not at all backwards compatible.

Opinions?

--
How To Keep A Healthy Level Of Insanity:
18. When leaving the zoo, start running towards the parking lot,
yelling "run for your lives, they're loose!!"

/// 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 ///

[James McCoy]

On Wed, Jul 15, 2020 at 02:25:40PM +0200, Bram Moolenaar wrote:
> To make this work with a double quoted string, we don't have much choice
> but to disallow double quoted comments.

Just where vim9script is being used or everywhere?

> Vim has always supported double quoted comments, disallowing them would
> be a big divergence. But as the above shows, it does make it consistent
> and easy to use. It's just not at all backwards compatible.

vim9script itself isn't backwards compatible, so if you're only
disallowing double quoted comments in that context, I don't see why it
matters.

Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB

[Gary Johnson]

On 2020-07-15, James McCoy wrote:
> On Wed, Jul 15, 2020 at 02:25:40PM +0200, Bram Moolenaar wrote:
> > To make this work with a double quoted string, we don't have much choice
> > but to disallow double quoted comments.
>
> Just where vim9script is being used or everywhere?

That's my question, too.

I don't think I really care what Vimscript9 does, but I use a lot of
plugins whose authors are not even around anymore. Having to update
all of those would be a huge inconvenience. Plus, I would have to
keep two sets of plugins around to support the various versions of
Vim I use on different systems.

Regards,
Gary

[Dominique Pellé]

I've always found it strange that in vim script, double
quotes are used for strings as well as comments.

It seems cleaner/clearer to not use double quotes
for comments anymore. Vim9 script is not 100% compatible
anyway, so it seems OK. Vim9 script aims maybe to look
somewhat familiar to those who know vim script, but not
entirely. Since it's a new language, it's a good opportunity
to simplify oddities. I wonder whether such simplification
also helps to parse faster (speed being the main goal of vim9).

Ah, I just see that # (used for comments when there is a
space after #) is also used for things that are not comments
as in #{a: 1, b: 2}->Process(). So comments in vim9
still look a bit odd.

Regards
Dominique

[Bram Moolenaar]

James McCoy wrote:

> On Wed, Jul 15, 2020 at 02:25:40PM +0200, Bram Moolenaar wrote:
> > To make this work with a double quoted string, we don't have much choice
> > but to disallow double quoted comments.
>
> Just where vim9script is being used or everywhere?

In case this wasn't clear: legacy Vim script will remain 100% backwards
compatible.

> > Vim has always supported double quoted comments, disallowing them would
> > be a big divergence. But as the above shows, it does make it consistent
> > and easy to use. It's just not at all backwards compatible.
>
> vim9script itself isn't backwards compatible, so if you're only
> disallowing double quoted comments in that context, I don't see why it
> matters.

It would matter for people switching between legacy Vim script and Vim9
script. But perhaps it's actually good to quickly see that all the
comments are different, so you know what kind of script you are dealing
with? The "vim9script" command would only be at the very top of the
file.

--
I'm not familiar with this proof, but I'm aware of a significant
following of toddlers who believe that peanut butter is the solution
to all of life's problems... -- Tim Hammerquist

[Ben Jackson]

My opinion is that it's ok to drop double-quote comments in vim9 script. I think it's good to only have 1 way to do things right, so having both double-quote and hash comments feels off.

Vim is a somewhat of an outlier in using double-quote for comments, so it would seem and feel natural to me to keep hash comments on vim9script and respectfully wave goodbye to double-quote comments. As you say, this is another way that can signal that the syntax and semantics of the code differ between legacy vimscript and vim9script.

I don't feel it's any more jarring than being able to call an expression without `call`, or requiring typing. Legacy vimscript and vim9script are essentially 2 completely different dialects, which means picking one way to do comments is probably a good idea.

[Bram Moolenaar]

Ben Jackson wrote:

> My opinion is that it's ok to drop double-quote comments in vim9 script. I
> think it's good to only have 1 way to do things right, so having both
> double-quote and hash comments feels off.
>
> Vim is a somewhat of an outlier in using double-quote for comments, so it
> would seem and feel natural to me to keep hash comments on vim9script and
> respectfully wave goodbye to double-quote comments. As you say, this is
> another way that can signal that the syntax and semantics of the code
> differ between legacy vimscript and vim9script.
>
> I don't feel it's any more jarring than being able to call an expression
> without `call`, or requiring typing. Legacy vimscript and vim9script are
> essentially 2 completely different dialects, which means picking one way to
> do comments is probably a good idea.

Thanks, these are good points.

--
"You know, it's at times like this when I'm trapped in a Vogon airlock with
a man from Betelgeuse and about to die of asphyxiation in deep space that I
really wish I'd listened to what my mother told me when I was young!"
"Why, what did she tell you?"
"I don't know, I didn't listen!"
-- Arthur Dent and Ford Prefect in Douglas Adams'
"The Hitchhiker's Guide to the Galaxy"

[Andy Massimino]

They are different languages, but why make it harder than necessary for people to migrate their scripts (and most probably maintain two dialects of their scripts due to non-adoption by neovim)?  My finger still reaches for double quote when I want a comment.

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/202007162017.06GKHn6g3674699%40masaka.moolenaar.net.

[Bram Moolenaar]

Andy Massimino wrote:

> They are different languages, but why make it harder than necessary for
> people to migrate their scripts (and most probably maintain two dialects of
> their scripts due to non-adoption by neovim)? My finger still reaches for
> double quote when I want a comment.

Yes, that is why I started the discussion.

An alternative would be to not allow a double quoted string at the start
of any line. You would have to use a single quoted string or put the
string inside parens: ("string"). This leads to complications when
adding line breaks. This would work:

MyFunc("arg one\r\n", "arg\ttwo", "arg three\n")

But when inserting line breaks you would have to change it:

MyFunc("arg one\r\n",
("arg\ttwo"),
("arg three\n"))

Or you would need the old style line continuation:

MyFunc("arg one\r\n",
\ "arg\ttwo",
\ "arg three\n")

Both of these are not like any language I know. Thus it violates the
plan to get closer to what people are used to.

The current Vim9 script is a mix of both: Allow a double quoted string
in a place where an expression is expected, but disallow it (use as a
comment) in other places. It's hard to keep this predictable and
consistent. E.g., this works:

'text'->setline(1)

But this won't:

"text"->setline(1)


I'm not 100% sure what argument counts more, but I do tend to think that
the difference with legacy Vim script is good, it is easy to spot a Vim9
script by the comments. Having to spot a missing "call" or types being
specified is less obvious.

--
Due knot trussed yore spell chequer two fined awl miss steaks.

[Andy Massimino]

Thanks, I did not fully appreciate the thorniness of the problem until
you pointed it out again.

On 7/16/20 5:05 PM, Bram Moolenaar wrote:
> This leads to complications when adding line breaks.

vim script has never properly supported continuation line comments,
except for a recent patch with a different syntax inside dicts/lists, so
I think it is totally OK to just ban double quote comments inside
continuations.

If the example of "hello"->func() is the only other case of syntax
ambiguity, disallowing that particular kind of bare expression (with a
warning) would be a reasonable compromise in my opinion. It is not an
expression you encounter very frequently.

On 7/16/20 5:05 PM, Bram Moolenaar wrote:
> but I do tend to think that
> the difference with legacy Vim script is good

I think, I always assumed (possibly wrongly) that migrating to
vim9script was intended to be a gradual approach. A developer would
take an existing vim script and put vim9script at the top, and then as
they see fit, little-by-little use the vim9 script features, like
typing, fast def functions, and bare expressions. This is similar in
spirit to python's typing system. Barring double-quote comments seems
like a departure, since it is no longer true that a 'reasonable' vim
script is a valid vim9script which is just missing a vim9script marker.

If vim9script has long ago passed the point where this is a viable
model, or never was, then my argument isn't really valid. I suppose it
is not extremely clear to me what the high-level goal of vim9script is.
Especially inside the continuum of two extremes of a performant
byte-compiled restricted form of vim script vs merely blessing an
existing language (js,py,lua) as first-class.

Regards,
Andy

[Bram Moolenaar]

Andy Massimino wrote:

> Thanks, I did not fully appreciate the thorniness of the problem until
> you pointed it out again.
>
> On 7/16/20 5:05 PM, Bram Moolenaar wrote:
> > This leads to complications when adding line breaks.
>
> vim script has never properly supported continuation line comments,
> except for a recent patch with a different syntax inside dicts/lists, so
> I think it is totally OK to just ban double quote comments inside
> continuations.
>
> If the example of "hello"->func() is the only other case of syntax
> ambiguity, disallowing that particular kind of bare expression (with a
> warning) would be a reasonable compromise in my opinion. It is not an
> expression you encounter very frequently.

Yes, this specific example seems to be an exception. But there might be
a few more like this.

> On 7/16/20 5:05 PM, Bram Moolenaar wrote:
> > but I do tend to think that
> > the difference with legacy Vim script is good
>
> I think, I always assumed (possibly wrongly) that migrating to
> vim9script was intended to be a gradual approach. A developer would
> take an existing vim script and put vim9script at the top, and then as
> they see fit, little-by-little use the vim9 script features, like
> typing, fast def functions, and bare expressions. This is similar in
> spirit to python's typing system. Barring double-quote comments seems
> like a departure, since it is no longer true that a 'reasonable' vim
> script is a valid vim9script which is just missing a vim9script marker.

Well, if you are lucky then putting "vim9script" at the top of an
existing script will work. But there are several subtle changes in
semantics that might break it. The most obvious one is that "let" is
used for declarations, but not assignments. Most scripts will need to
be adjusted for that.

Finding and replacing double quotes at the start of the line with # is
simple enough. And as soon as you remove "call" before function calls
and "let" before assignments that are not declarations, it's already
different enough.

It's a habit to start comments with a double quote. Syntax highlighting
will soon show the mistake to help avoiding using the wrong comment
character.

> If vim9script has long ago passed the point where this is a viable
> model, or never was, then my argument isn't really valid. I suppose it
> is not extremely clear to me what the high-level goal of vim9script is.
> Especially inside the continuum of two extremes of a performant
> byte-compiled restricted form of vim script vs merely blessing an
> existing language (js,py,lua) as first-class.

We only really have one chance to define a new syntax. Once Vim9 has
launched, it has to be backwards compatible. I tend to give the long
term goals a higher priority than the short-term goal of making Vim9
script more-or-less similar to legacy Vim script.

The main long-term goals are:
- Similarity with existing programming languages, less to learn
- Consistency and preditability - no surprises
- Still similar to legacy Vim script, with Ex commands, builtin
functions, etc.
- Minimal use of punctuation, e.g. no ";" at the end of a statement.

--
The users that I support would double-click on a landmine to find out
what happens. -- A system administrator

[FUJIWARA Takuya]

2020年7月15日(水) 21:25 Bram Moolenaar <Br...@moolenaar.net>:

>
>
> I'm trying to make the Vim9 script syntax consistent and easy to use.
> But I'm now running into something that would be a drastic change.
>
> I already added support for comments starting with #. These are nice,
> we know them from shell scripts, Python and a few other syntaxes.
>
> Double quoted comments can currently still be used, but not everywhere.
> E.g. when an expression might continue in the next line:
> function("arg one",
> "arg two")
>
> This also shows the inconsistency:
> myList->add(123) " works
> g:myList->add(123) " works
> [1, 2, 3]->Process() " works
> #{a: 1, b: 2}->Process() " works
> {'a': 1, 'b': 2}->Process() " works
> "foobar"->Process() " does NOT work
> ("foobar")->Process() " works
> 'foobar'->Process() " does NOT work
> ('foobar')->Process() " works
>
> I just made the last-but-one work, since we added the rule that a range
> must start with a colon, and using a mark in a range would thus be :'t.
>
> To make this work with a double quoted string, we don't have much choice
> but to disallow double quoted comments. Since there really is no way to
> tell the difference, both a string and a comment may contain anything.

+1 to disallow double quoted comments.
Using double quote character as both comments and strings are really ambiguous.
It's a bad habit since old vim script.
vim9script does not need to support it.

If vim9script becomes faster, powerful as well as other script
languages, and worth migrating, everyone would do that :)
even if syntax is different.

>
> Vim has always supported double quoted comments, disallowing them would
> be a big divergence. But as the above shows, it does make it consistent
> and easy to use. It's just not at all backwards compatible.
>
> Opinions?
>
> --
> How To Keep A Healthy Level Of Insanity:
> 18. When leaving the zoo, start running towards the parking lot,
> yelling "run for your lives, they're loose!!"
>
> /// 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 ///
>

> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/202007151225.06FCPeBd3317933%40masaka.moolenaar.net.



--
FUJIWARA Takuya