Hi Bram, thanks for sharing. Looks really promising.
Regarding https://github.com/brammool/vim9#3-better-vim-script, I have a
few ideas for your consideration:
* Execution often relies on user configuration (ignorecase, magic, etc.)
and there is common boilerplate required in many scripts to set/restore
cpo. Could we say that when `scriptversion` is `vim9`, we always execute as
if `set cpo&vim` ?
* Line continuation. I know this is probably hard to change, but could we
look at a line-continuation scheme that's more familiar ? As we don't have
line termination, Perhaps something more like python's e.g. if a line ends
with an unbalanced parenthesis (or a `<backslash><newline>`), then assume
the next line is a continuation? I think the `<newline><backslash>` syntax
is unfamiliar to a lot of people.
* Scoped functions or lambdas containing ex-commands (or better, def
function bodies). When combined with try/finally, this would allow
constructs that take a "block" of code, such as "WithCurrentBuffer( buf, {
=> block of code/commands, maybe split across lines } )" or something like
this when working with external tools `SendMessageToTool( message, then = {
=> some block of ex commands } ). This can currently be done with Funcref,
but I think that you have to do 'function ...' and then 'delfiunc' as all
functions are currently global. Maybe the new scoping rules could be
extended to allow this.
I already mentioned elsewhere that the other barrier to entry for vim
scripting is tooling and debugging. Hopefully with a these changes we can
consider how to:
* extract the parser so that an external tool can parse and do code
comprehension, go-to, refactor, etc., think Vim Language Server (there is
one, but it's not canonical)
* provide a interface to a debug adapter to allow debugging of vimscript
executing in a Vim instance (i.e. Vim Debug Adapter)
* provide better source/line information for stack traces (so that we can
reliably jump to location of assertions e.g. test failures using cnext). I
saw a recent patch which improves sourcing_lineno and uses a proper stack.
I was planning to work on a patch to store source/line info when debugging
is enabled, but might hold off while vim 9 shakes down, as this is likely
required for the above debugger interface (assuming that's a goal).
Just a few ideas to throw in to the mix!
Thanks again,
Ben
On Thursday, January 2, 2020 at 7:44:10 PM UTC, Bram Moolenaar wrote:
>
>
> I have created a repository for the Vim9 script experiments:
> https://github.com/brammool/vim9
>
> I did another measurement for a more realistic example, re-indenting a
> large number of lines. In old Vim script it would be:
>
> let totallen = 0
> for i in range(1, 100000)
> call setline(i, ' ' .. getline(i))
> let totallen += len(getline(i))
> endfor
>
> The timing differences are much smaller than for the computational
> example, but Vim9 script is clearly the fastest:
>
> Vim old: 0.853752
> Python: 0.304584
> Lua: 0.286573
> Vim new: 0.190276
>
> Compared to legacy Vim script it is a 4 times faster.
>
> If you want to look at the instructions that are used internally, the
> ":disassemble" command shows what's the compilation result. For
> example, this function:
>
> def VimNew(): number
> let totallen = 0
> for i in range(1, 100000)
> setline(i, ' ' .. getline(i))
> totallen += len(getline(i))
> }
> return totallen
> enddef
>
> Results in this:
>
> let totallen = 0
> 0 STORE 0 in $0
>
> for i in range(1, 100000)
> 1 STORE -1 in $1
> 2 PUSHNR 1
> 3 PUSHNR 100000
> 4 BCALL range(argc 2)
> 5 FOR $1 -> 21
> 6 STORE $2
>
> setline(i, ' ' .. getline(i))
> 7 LOAD $2
> 8 PUSHS " "
> 9 LOAD $2
> 10 BCALL getline(argc 1)
> 11 CONCAT
> 12 BCALL setline(argc 2)
> 13 DROP
>
> totallen += len(getline(i))
> 14 LOAD $0
> 15 LOAD $2
> 16 BCALL getline(argc 1)
> 17 BCALL len(argc 1)
> 18 ADDNR
> 19 STORE $0
>
> }
> 20 JUMP -> 5
> 21 DROP
>
> return totallen
> 22 LOAD $0
> 23 RETURN
>
>
> Obviously there is still an awful lot of work to be done. Fortunately,
> the numbers show it's worth it.
>
> --
> The Law of VIM:
> For each member b of the possible behaviour space B of program P, there
> exists
> a finite time t before which at least one user u in the total user space U
> of
> program P will request b becomes a member of the allowed behaviour space
> B'
> (B' <= B).
> In other words: Sooner or later everyone wants everything as an option.
> -- Vince Negri
>
> /// Bram Moolenaar -- b...@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/0538bce3-cc96-4e69-8899-9f5f958de7fb%40googlegroups.com.
