Merging Vim9 script changes

[Bram Moolenaar]

I have been experimenting with ideas for Vim9 script in a separate
repository for a while. I'm quite happy with how this turns out, and I
haven't heard objections.

Since keeping this separate from the main Vim code requires extra
maintenance, especially when refactoring code, I think it's time to
merge the changes for Vim9 script into the main code.

Note that Vim9 script will remain experimental! It will take several
months of exploring before we can decide it is good and settle down on
the syntax and semantics. Feel free to write Vim9 script, but be
prepared that it might break.

I am going to include it without a new "#ifdef": if the +eval feature is
supported then the Vim9 script support will also be included. For me it
means I have to make sure it builds without problems. The advantage is
that improvements also apply to legacy Vim script, such as using an
efficient range-list implementation.

So long as you don't use ":def" to define a function and don't use
"vim9script" in a script file, then everything works as before. Well,
it might get a bit faster.

--
For large projects, Team Leaders use sophisticated project management software
to keep track of who's doing what. The software collects the lies and guesses
of the project team and organizes them in to instantly outdated charts that
are too boring to look at closely. This is called "planning".
(Scott Adams - The Dilbert principle)

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

[Paul Jolly]

Hi Bram - interested to try things out.

A couple of stupid questions:

* if Vim9 script remains experimental, presumably I have to explicitly
enable it within a script it somehow/somewhere? Or is this the
vim9script reference above?
* you allude to this point above, but will the speed improvements be
limited to Vim9 script?
* I'm assuming that channel support will remain the same? Is there any
speed improvements we can investigate here?

Thanks

> --
> --
> 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/202001251631.00PGVo0I028317%40masaka.moolenaar.net.

[Bram Moolenaar]

Paul Jolly wrote:

> A couple of stupid questions:
>
> * if Vim9 script remains experimental, presumably I have to explicitly
> enable it within a script it somehow/somewhere? Or is this the
> vim9script reference above?

The Vim9 script syntax is only used for functions defined with ":def"
and for scripts that start with "vim9script".

> * you allude to this point above, but will the speed improvements be
> limited to Vim9 script?

Most speed improvements are in functions defined with ":def". They are
compiled into instructions which execute very fast.

> * I'm assuming that channel support will remain the same? Is there any
> speed improvements we can investigate here?

Nothing changes for channel support. Except that when you use a ":def"
function to build a request or unpack a response that should be a lot
faster.

--
At some point in the project somebody will start whining about the need to
determine the project "requirements". This involves interviewing people who
don't know what they want but, curiously, know exactly when they need it.

[Paul Jolly]

Thanks very much.

> > * if Vim9 script remains experimental, presumably I have to explicitly
> > enable it within a script it somehow/somewhere? Or is this the
> > vim9script reference above?
>
> The Vim9 script syntax is only used for functions defined with ":def"
> and for scripts that start with "vim9script".

I seem to recall from the other threads on Vim9 that the reason for
using :def is that the changes for Vim9 script will not be backwards
compatible.

What about the other way around? Is there a mode in which we can run
Vim such that :function declared functions run as if declared via
:def? And similarly for scripts, running in this mode would obviate
the need for "vim9script"?

If not, do you have a script rewriter planned, to help people with the
migration?

Apologies if I missed these points from the other Vim9 threads.

<snip>

> > * I'm assuming that channel support will remain the same? Is there any
> > speed improvements we can investigate here?
>
> Nothing changes for channel support. Except that when you use a ":def"
> function to build a request or unpack a response that should be a lot
> faster.

Thanks. The rationale behind this question and the questions above is
me trying to work out how best we experiment with these changes with
govim. I, and I'm sure many other people, would like to avoid having
to rewrite existing VimScript where possible, especially whilst things
are experimental. But at the same time it would seem to make sense to
exercise the proposed changes as much as possible as early as
possible.

Best,


Paul

[Bram Moolenaar]

Paul Jolly wrote:

> > > * if Vim9 script remains experimental, presumably I have to explicitly
> > > enable it within a script it somehow/somewhere? Or is this the
> > > vim9script reference above?
> >
> > The Vim9 script syntax is only used for functions defined with ":def"
> > and for scripts that start with "vim9script".
>
> I seem to recall from the other threads on Vim9 that the reason for
> using :def is that the changes for Vim9 script will not be backwards
> compatible.
>
> What about the other way around? Is there a mode in which we can run
> Vim such that :function declared functions run as if declared via
> :def? And similarly for scripts, running in this mode would obviate
> the need for "vim9script"?

I do not think that is possible in general. There will be too many
subtle differences. And there will be a long time that the two will
exist side by side (probably forever).

I have wondered if there is a way the Vim9 syntax could be detected
automatically, but that would require scanning the whole file before
interpreting it. It's good to state it upfront anyway.

> If not, do you have a script rewriter planned, to help people with the
> migration?

No plans, but it should not be too difficult to do the most obvious
changes, such as removing "a:" from before arguments. It will be very
difficult to do it completely automatic, e.g. if a function is using
"a:" as a dictionary.

> > > * I'm assuming that channel support will remain the same? Is there any
> > > speed improvements we can investigate here?
> >
> > Nothing changes for channel support. Except that when you use a ":def"
> > function to build a request or unpack a response that should be a lot
> > faster.
>
> Thanks. The rationale behind this question and the questions above is
> me trying to work out how best we experiment with these changes with
> govim. I, and I'm sure many other people, would like to avoid having
> to rewrite existing VimScript where possible, especially whilst things
> are experimental. But at the same time it would seem to make sense to
> exercise the proposed changes as much as possible as early as
> possible.

The advantage of how it's done is that you do not *have* to rewrite
anything, but if you have some place where performance matters, you can
put that in a :def function and profit.

I imagine that when Vim9 script is supported widely enough that plugin
writers can convert the files. Just like they would use a newly added
function.


--
A salesperson says: Translation:
"backward compatible" Old technology
"Premium" Overpriced
"Can't keep it on the shelf" Unavailable
"Stands alone" Piece of shit
"Proprietary" Incompatible

[Tony Mechelynck]

IIUC, the following is now a valid construct in newly-written or
updated non-"vim9script" script? (Let's say, a .vimrc which must also
support an older Vim version from my Linux distro)

if exists('vim9script') == 2
import MyFunc as myfunc from '~/.vim/myvim9.vim'
else
function s:myfunc()
...
endfunction
endif
command MyCommand -nargs=0 -bar call s:myfunc()

Best regards,
Tony.

[Tony Mechelynck]

On Sun, Jan 26, 2020 at 6:18 PM Tony Mechelynck
<antoine.m...@gmail.com> wrote:
>
> IIUC, the following is now a valid construct in newly-written or
> updated non-"vim9script" script? (Let's say, a .vimrc which must also
> support an older Vim version from my Linux distro)
>
> if exists('vim9script') == 2

oops: if exists(':vim9script') == 2

[Bram Moolenaar]

Tony wrote:

> IIUC, the following is now a valid construct in newly-written or
> updated non-"vim9script" script? (Let's say, a .vimrc which must also
> support an older Vim version from my Linux distro)
>
> if exists('vim9script') == 2

That should be:

if exists(':vim9script') == 2

> import MyFunc as myfunc from '~/.vim/myvim9.vim'

Import only works in a Vim9 script file. Not that it is impossible in
legacy Vim script, but I think it's a good idea not to mix a new command
in an old script file. e.g., do you need to use "s:myfunc" here?

> else
> function s:myfunc()
> ...
> endfunction
> endif
> command MyCommand -nargs=0 -bar call s:myfunc()

--
While it's true that many normal people whould prefer not to _date_ an
engineer, most normal people harbor an intense desire to _mate_ with them,
thus producing engineerlike children who will have high-paying jobs long
before losing their virginity.

[Tony Mechelynck]

On Sun, Jan 26, 2020 at 6:57 PM Bram Moolenaar <Br...@moolenaar.net> wrote:
>
>
> Tony wrote:
>
> > IIUC, the following is now a valid construct in newly-written or
> > updated non-"vim9script" script? (Let's say, a .vimrc which must also
> > support an older Vim version from my Linux distro)
> >
> > if exists('vim9script') == 2
>
> That should be:
> if exists(':vim9script') == 2

yes, I sent an erratum

>
> > import MyFunc as myfunc from '~/.vim/myvim9.vim'
>
> Import only works in a Vim9 script file. Not that it is impossible in
> legacy Vim script, but I think it's a good idea not to mix a new command
> in an old script file. e.g., do you need to use "s:myfunc" here?
>
> > else
> > function s:myfunc()
> > ...
> > endfunction
> > endif
> > command MyCommand -nargs=0 -bar call s:myfunc()

I wrote this based on my interpretation of doc/vim9.txt lines 435-438:

<quote>
Import in legacy Vim script ~

If an `import` statement is used in legacy Vim script, for identifier the
script-local "s:" namespace will be used, even when "s:" is not specified.
</quote>

and BTW I also assumed that, in the "true" branch of the ":if
exists(':vim9script') == 2" conditional block I could, instead of an
:import statement, use a :def ... enddef for the same local function,
but only with careful writing. Of course the s: namespace is needed in
the command definition, and therefore also in the "else" branch, to
make sure that the same function (which will be forced to script-local
if imported) is defined the fast way if possible, with fallback on the
traditional ":function" definition if necessary.

The idea of mixing old and new code in, for instance, a vimrc is that
I might want to use incompatible features elsewhere in the script, for
instance a :function with the range modifier, or a curly-braces-name.
Or a function with a variable number of arguments if the script might
conceivably be run in a Vim executable not yet supporting Dictionary
variables, but this latter hypothesis is of dwindling likelihood as
time goes on.

Best regards,
Tony.