Strict mode makes several changes to normal JavaScript semantics:
- Eliminates some JavaScript silent errors by changing them to throw errors.
- Fixes mistakes that make it difficult for JavaScript engines to perform optimizations: strict mode code can sometimes be made to run faster than identical code that's not strict mode.
- Prohibits some syntax likely to be defined in future versions of ECMAScript.
Yasuhiro Matsumoto wrote:
> Why you don't use { ?
I know this will trigger a discussion. Nearly all languages use blocks
ending with "}". It's much easier to see where a block ends that way
than using "endif", "endwhile", etc., it stands out.
Since we already have the start of the block without extra punctuation,
there is no need to add a "{" there. It would be pointless to add it.
The only place where "{" will appear is a block by itself, used to
declare a variable:
{
let tmp = 0
...
}
" tmp not available here
If you don't like using "}" you can use "endif", "endfor", etc. as before.
Second comment there says about syntax highlighting. So making vimscript faster here won't help much because [tree-sitter](https://tree-sitter.github.io/tree-sitter/) will be lot faster than vimscript, which means syntax highlighting in neovim will also be more accurate and faster then vim.
Instead of picking up non real world examples to demonstrate perf gains can we pick some proper goals.
Here are some of the examples I can think of:
* Faster fuzzy finder. Currently there is 0 plugins that is fast in pure vimscript. I would like to see an example of FuzzyFinder in vim9 that is fast as https://github.com/liuchengxu/vim-clap and https://github.com/junegunn/fzf.vim. Few requirements here: Searching large number of nested directories and files, highlighting matches. Some of these I elaborated in this comment https://github.com/vim/vim/issues/3573#issuecomment-433730939.
* vim9 syntax highlighting vs neovim tree-sitter syntax highlighting. We should count speed as well as accuracy.
* Fuzzy search for auto complete popup menu.
I still think WASM is the way to go and not vimscript 9. This way I can code in what ever language suits me and just ship the bytecode.
For example: will vimscript 9 support generics/async,await/pattern matching/threading or greenthreads/immutability? This list will keep going on. Making it fast is just one issue it solves. A language gets attractive not just for perf but many other features that come around it.
Here is a new WASM runtime since I last mentioned which claims to be 15x faster then other c wasm runtimes. https://github.com/wasm3/wasm3.
As a plugin author I can then code in any languages I want that suits the needed. For example a python dev might write in python, a JS dev might right in Javascript or Typescript if they need typing. And they can still write in go/rust/zig or even c if they need performance. And most languages these days already support compiling to WASM.
> * provide a interface to a debug adapter to allow debugging of vimscript
> executing in a Vim instance (i.e. Vim Debug Adapter)
Sure.
* 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 don't think WASM helps at all with syntax highlighting. The good old
Vim syntax highlighting depends on regexp patterns. I have already
optimized the speed of that, I don't think it can be improved much more.
The main alternative now is to use an external parser or language server
and communicate with it. Such as the govim plugin does. You an now use
text properties to highlight the text.
FUNCTIONS SORTED ON SELF TIME
count total (s) self (s) function
10004 2.192760 lsp#utils#base64_decode()
10004 2.202340 1.375972 <SNR>87_add_highlight()
10004 3.162274 0.504508 <SNR>87_tokens_to_hl_info()
30024 0.465006 <SNR>87_octets_to_number()
10005 0.351520 0.286610 lsp#capabilities#has_semantic_highlight()
100053 0.251802 <SNR>87_get_textprop_name()
1 5.561511 0.196170 lsp#ui#vim#semantic#handle_semantic()
10005 0.574658 0.169267 lsp#ui#vim#semantic#get_scopes()
20011 0.118792 lsp#get_server_capabilities()
> Basically in strict mode it would still use a:name as the variable name but
> it is no longer a dictionary. This way all new vimscript is 100% compatible
> with old vimscript < 9
I don't see that. If a: is no longer available as a dictionary it won't
be 100% compatible. There are other subtle assumptions, e.g. about how
error messages are handled. It will work like "abort" was present.