Bram Moolenaar | b17893a | 2020-03-14 08:19:51 +0100 | [diff] [blame] | 1 | *vim9.txt* For Vim version 8.2. Last change: 2020 Mar 01 |
Bram Moolenaar | 8a7d654 | 2020-01-26 15:56:19 +0100 | [diff] [blame] | 2 | |
| 3 | |
| 4 | VIM REFERENCE MANUAL by Bram Moolenaar |
| 5 | |
| 6 | |
| 7 | THIS IS STILL UNDER DEVELOPMENT - ANYTHING CAN BREAK - ANYTHING CAN CHANGE |
| 8 | |
| 9 | Vim9 script commands and expressions. |
| 10 | |
| 11 | Most expression help is in |eval.txt|. This file is about the new syntax and |
| 12 | features in Vim9 script. |
| 13 | |
| 14 | THIS IS STILL UNDER DEVELOPMENT - ANYTHING CAN BREAK - ANYTHING CAN CHANGE |
| 15 | |
| 16 | |
| 17 | 1 What is Vim9 script? |vim9-script| |
| 18 | 2. Differences |vim9-differences| |
| 19 | 3. New style functions |fast-functions| |
| 20 | 4. Types |vim9-types| |
| 21 | 5. Namespace, Import and Export |vim9script| |
| 22 | |
| 23 | 9. Rationale |vim9-rationale| |
| 24 | |
| 25 | ============================================================================== |
| 26 | |
| 27 | 1. What is Vim9 script? *vim9-script* |
| 28 | |
| 29 | THIS IS STILL UNDER DEVELOPMENT - ANYTHING CAN BREAK - ANYTHING CAN CHANGE |
| 30 | |
| 31 | Vim script has been growing over time, while keeping backwards compatibility. |
| 32 | That means bad choices from the past often can't be changed. Execution is |
| 33 | quite slow, every line is parsed every time it is executed. |
| 34 | |
| 35 | The main goal of Vim9 script is to drastically improve performance. An |
| 36 | increase in execution speed of 10 to 100 times can be expected. A secondary |
| 37 | goal is to avoid Vim-specific constructs and get closer to commonly used |
| 38 | programming languages, such as JavaScript, TypeScript and Java. |
| 39 | |
| 40 | The performance improvements can only be achieved by not being 100% backwards |
| 41 | compatible. For example, in a function the arguments are not available in the |
| 42 | "a:" dictionary, as creating that dictionary adds quite a lot of overhead. |
| 43 | Other differences are more subtle, such as how errors are handled. |
| 44 | |
| 45 | The Vim9 script syntax and semantics are used in: |
| 46 | - a function defined with the `:def` command |
| 47 | - a script file where the first command is `vim9script` |
| 48 | |
| 49 | When using `:function` in a Vim9 script file the legacy syntax is used. |
| 50 | However, this is discouraged. |
| 51 | |
| 52 | Vim9 script and legacy Vim script can be mixed. There is no need to rewrite |
| 53 | old scripts, they keep working as before. |
| 54 | |
| 55 | ============================================================================== |
| 56 | |
| 57 | 2. Differences from legacy Vim script *vim9-differences* |
| 58 | |
| 59 | THIS IS STILL UNDER DEVELOPMENT - ANYTHING CAN BREAK - ANYTHING CAN CHANGE |
| 60 | |
| 61 | Vim9 functions ~ |
| 62 | |
| 63 | `:def` has no extra arguments like `:function` does: "range", "abort", "dict" |
| 64 | or "closure". A `:def` function always aborts on an error, does not get a |
| 65 | range passed and cannot be a "dict" function. |
| 66 | |
| 67 | In the function body: |
| 68 | - Arguments are accessed by name, without "a:". |
| 69 | - There is no "a:" dictionary or "a:000" list. Variable arguments are defined |
| 70 | with a name and have a list type: > |
| 71 | def MyFunc(...itemlist: list<type>) |
| 72 | for item in itemlist |
| 73 | ... |
| 74 | |
| 75 | |
| 76 | Variable declarations with :let and :const ~ |
| 77 | |
| 78 | Local variables need to be declared with `:let`. Local constants need to be |
| 79 | declared with `:const`. We refer to both as "variables". |
| 80 | |
| 81 | Variables can be local to a script, function or code block: > |
| 82 | vim9script |
| 83 | let script_var = 123 |
| 84 | def SomeFunc() |
| 85 | let func_var = script_var |
| 86 | if cond |
| 87 | let block_var = func_var |
| 88 | ... |
| 89 | |
| 90 | The variables are only visible in the block where they are defined and nested |
| 91 | blocks. Once the block ends the variable is no longer accessible: > |
| 92 | if cond |
| 93 | let inner = 5 |
| 94 | else |
| 95 | let inner = 0 |
| 96 | endif |
| 97 | echo inner " Error! |
| 98 | |
| 99 | The declaration must be done earlier: > |
| 100 | let inner: number |
| 101 | if cond |
| 102 | inner = 5 |
| 103 | else |
| 104 | inner = 0 |
| 105 | endif |
| 106 | echo inner |
| 107 | |
| 108 | To intentionally use a variable that won't be available later, a block can be |
| 109 | used: > |
| 110 | { |
| 111 | let temp = 'temp' |
| 112 | ... |
| 113 | } |
| 114 | echo temp " Error! |
| 115 | |
Bram Moolenaar | 560979e | 2020-02-04 22:53:05 +0100 | [diff] [blame] | 116 | An existing variable cannot be assigned to with `:let`, since that implies a |
Bram Moolenaar | 8a7d654 | 2020-01-26 15:56:19 +0100 | [diff] [blame] | 117 | declaration. An exception is global variables: these can be both used with |
| 118 | and without `:let`, because there is no rule about where they are declared. |
| 119 | |
| 120 | Variables cannot shadow previously defined variables. |
| 121 | Variables may shadow Ex commands, rename the variable if needed. |
| 122 | |
| 123 | Since "&opt = value" is now assigning a value to option "opt", ":&" cannot be |
| 124 | used to repeat a `:substitute` command. |
| 125 | |
| 126 | |
| 127 | Omitting :call and :eval ~ |
| 128 | |
| 129 | Functions can be called without `:call`: > |
| 130 | writefile(lines, 'file') |
Bram Moolenaar | 560979e | 2020-02-04 22:53:05 +0100 | [diff] [blame] | 131 | Using `:call` is still possible, but this is discouraged. |
Bram Moolenaar | 8a7d654 | 2020-01-26 15:56:19 +0100 | [diff] [blame] | 132 | |
| 133 | A method call without `eval` is possible, so long as the start is an |
Bram Moolenaar | 0c6ceaf | 2020-02-22 18:36:32 +0100 | [diff] [blame] | 134 | identifier or can't be an Ex command. It does NOT work for string constants: > |
Bram Moolenaar | 8a7d654 | 2020-01-26 15:56:19 +0100 | [diff] [blame] | 135 | myList->add(123) " works |
| 136 | g:myList->add(123) " works |
| 137 | [1, 2, 3]->Process() " works |
| 138 | #{a: 1, b: 2}->Process() " works |
| 139 | {'a': 1, 'b': 2}->Process() " works |
| 140 | "foobar"->Process() " does NOT work |
Bram Moolenaar | 0c6ceaf | 2020-02-22 18:36:32 +0100 | [diff] [blame] | 141 | ("foobar")->Process() " works |
| 142 | 'foobar'->Process() " does NOT work |
| 143 | ('foobar')->Process() " works |
Bram Moolenaar | 8a7d654 | 2020-01-26 15:56:19 +0100 | [diff] [blame] | 144 | |
Bram Moolenaar | 5b1c8fe | 2020-02-21 18:42:43 +0100 | [diff] [blame] | 145 | In case there is ambiguity between a function name and an Ex command, use ":" |
| 146 | to make clear you want to use the Ex command. For example, there is both the |
| 147 | `:substitute` command and the `substitute()` function. When the line starts |
| 148 | with `substitute(` this will use the function, prepend a colon to use the |
| 149 | command instead: > |
Bram Moolenaar | 0c6ceaf | 2020-02-22 18:36:32 +0100 | [diff] [blame] | 150 | :substitute(pattern (replacement ( |
Bram Moolenaar | 5b1c8fe | 2020-02-21 18:42:43 +0100 | [diff] [blame] | 151 | |
Bram Moolenaar | cc390ff | 2020-02-29 22:06:30 +0100 | [diff] [blame] | 152 | Note that while variables need to be defined before they can be used, |
| 153 | functions can be called before being defined. This is required to be able |
| 154 | have cyclic dependencies between functions. It is slightly less efficient, |
| 155 | since the function has to be looked up by name. And a typo in the function |
| 156 | name will only be found when the call is executed. |
| 157 | |
Bram Moolenaar | 8a7d654 | 2020-01-26 15:56:19 +0100 | [diff] [blame] | 158 | |
| 159 | No curly braces expansion ~ |
| 160 | |
| 161 | |curly-braces-names| cannot be used. |
| 162 | |
| 163 | |
Bram Moolenaar | 560979e | 2020-02-04 22:53:05 +0100 | [diff] [blame] | 164 | No :append, :change or :insert ~ |
Bram Moolenaar | 8a7d654 | 2020-01-26 15:56:19 +0100 | [diff] [blame] | 165 | |
Bram Moolenaar | 560979e | 2020-02-04 22:53:05 +0100 | [diff] [blame] | 166 | These commands are too quickly confused with local variable names. |
| 167 | |
| 168 | |
| 169 | Comparators ~ |
| 170 | |
| 171 | The 'ignorecase' option is not used for comparators that use strings. |
Bram Moolenaar | 8a7d654 | 2020-01-26 15:56:19 +0100 | [diff] [blame] | 172 | |
| 173 | |
| 174 | White space ~ |
| 175 | |
| 176 | Vim9 script enforces proper use of white space. This is no longer allowed: > |
| 177 | let var=234 " Error! |
| 178 | let var= 234 " Error! |
| 179 | let var =234 " Error! |
| 180 | There must be white space before and after the "=": > |
| 181 | let var = 234 " OK |
| 182 | |
| 183 | White space is required around most operators. |
| 184 | |
| 185 | White space is not allowed: |
| 186 | - Between a function name and the "(": > |
| 187 | call Func (arg) " Error! |
| 188 | call Func |
| 189 | \ (arg) " Error! |
| 190 | call Func(arg) " OK |
| 191 | call Func( |
| 192 | \ arg) " OK |
Bram Moolenaar | 5b1c8fe | 2020-02-21 18:42:43 +0100 | [diff] [blame] | 193 | call Func( |
| 194 | \ arg " OK |
| 195 | \ ) |
Bram Moolenaar | 8a7d654 | 2020-01-26 15:56:19 +0100 | [diff] [blame] | 196 | |
| 197 | |
| 198 | Conditions and expressions ~ |
| 199 | |
| 200 | Conditions and expression are mostly working like they do in JavaScript. A |
| 201 | difference is made where JavaScript does not work like most people expect. |
| 202 | Specifically, an empty list is falsey. |
| 203 | |
| 204 | Any type of variable can be used as a condition, there is no error, not even |
| 205 | for using a list or job. This is very much like JavaScript, but there are a |
| 206 | few exceptions. |
| 207 | |
| 208 | type TRUE when ~ |
| 209 | bool v:true |
| 210 | number non-zero |
| 211 | float non-zero |
| 212 | string non-empty |
| 213 | blob non-empty |
| 214 | list non-empty (different from JavaScript) |
| 215 | dictionary non-empty (different from JavaScript) |
Bram Moolenaar | b17893a | 2020-03-14 08:19:51 +0100 | [diff] [blame] | 216 | func when not NULL |
Bram Moolenaar | 8a7d654 | 2020-01-26 15:56:19 +0100 | [diff] [blame] | 217 | partial when not NULL |
| 218 | special v:true |
| 219 | job when not NULL |
| 220 | channel when not NULL |
| 221 | class when not NULL |
| 222 | object when not NULL (TODO: when isTrue() returns v:true) |
| 223 | |
| 224 | The boolean operators "||" and "&&" do not change the value: > |
| 225 | 8 || 2 == 8 |
| 226 | 0 || 2 == 2 |
| 227 | 0 || '' == '' |
| 228 | 8 && 2 == 2 |
| 229 | 0 && 2 == 0 |
| 230 | [] && 2 == [] |
| 231 | |
| 232 | When using `..` for string concatenation the arguments are always converted to |
| 233 | string. > |
| 234 | 'hello ' .. 123 == 'hello 123' |
| 235 | 'hello ' .. v:true == 'hello true' |
| 236 | |
| 237 | In Vim9 script one can use "true" for v:true and "false" for v:false. |
| 238 | |
| 239 | |
| 240 | ============================================================================== |
| 241 | |
| 242 | 3. New style functions *fast-functions* |
| 243 | |
| 244 | THIS IS STILL UNDER DEVELOPMENT - ANYTHING CAN BREAK - ANYTHING CAN CHANGE |
| 245 | |
| 246 | *:def* |
| 247 | :def[!] {name}([arguments])[: {return-type} |
| 248 | Define a new function by the name {name}. The body of |
| 249 | the function follows in the next lines, until the |
| 250 | matching `:enddef`. |
| 251 | |
Bram Moolenaar | ebdf3c9 | 2020-02-15 21:41:42 +0100 | [diff] [blame] | 252 | When {return-type} is omitted the function is not |
| 253 | expected to return anything. |
Bram Moolenaar | 8a7d654 | 2020-01-26 15:56:19 +0100 | [diff] [blame] | 254 | |
| 255 | {arguments} is a sequence of zero or more argument |
| 256 | declarations. There are three forms: |
| 257 | {name}: {type} |
| 258 | {name} = {value} |
| 259 | {name}: {type} = {value} |
| 260 | The first form is a mandatory argument, the caller |
| 261 | must always provide them. |
| 262 | The second and third form are optional arguments. |
| 263 | When the caller omits an argument the {value} is used. |
| 264 | |
Bram Moolenaar | 560979e | 2020-02-04 22:53:05 +0100 | [diff] [blame] | 265 | NOTE: It is possible to nest `:def` inside another |
| 266 | `:def`, but it is not possible to nest `:def` inside |
| 267 | `:function`, for backwards compatibility. |
| 268 | |
Bram Moolenaar | 8a7d654 | 2020-01-26 15:56:19 +0100 | [diff] [blame] | 269 | [!] is used as with `:function`. |
| 270 | |
| 271 | *:enddef* |
| 272 | :enddef End of a function defined with `:def`. |
| 273 | |
| 274 | |
Bram Moolenaar | 5b1c8fe | 2020-02-21 18:42:43 +0100 | [diff] [blame] | 275 | If the script the function is defined in is Vim9 script, then script-local |
| 276 | variables can be accessed without the "s:" prefix. They must be defined |
| 277 | before the function. If the script the function is defined in is legacy |
| 278 | script, then script-local variables must be accessed with the "s:" prefix. |
| 279 | |
| 280 | |
Bram Moolenaar | ebdf3c9 | 2020-02-15 21:41:42 +0100 | [diff] [blame] | 281 | *:disa* *:disassemble* |
| 282 | :disa[ssemble] {func} Show the instructions generated for {func}. |
| 283 | This is for debugging and testing. |
Bram Moolenaar | cc390ff | 2020-02-29 22:06:30 +0100 | [diff] [blame] | 284 | Note that for command line completion of {func} you |
| 285 | can prepend "s:" to find script-local functions. |
Bram Moolenaar | ebdf3c9 | 2020-02-15 21:41:42 +0100 | [diff] [blame] | 286 | |
Bram Moolenaar | 8a7d654 | 2020-01-26 15:56:19 +0100 | [diff] [blame] | 287 | ============================================================================== |
| 288 | |
| 289 | 4. Types *vim9-types* |
| 290 | |
| 291 | THIS IS STILL UNDER DEVELOPMENT - ANYTHING CAN BREAK - ANYTHING CAN CHANGE |
| 292 | |
| 293 | The following builtin types are supported: |
| 294 | bool |
| 295 | number |
| 296 | float |
| 297 | string |
| 298 | blob |
| 299 | list<type> |
| 300 | dict<type> |
| 301 | (a: type, b: type): type |
| 302 | job |
| 303 | channel |
Bram Moolenaar | b17893a | 2020-03-14 08:19:51 +0100 | [diff] [blame] | 304 | func |
| 305 | partial |
Bram Moolenaar | 8a7d654 | 2020-01-26 15:56:19 +0100 | [diff] [blame] | 306 | |
| 307 | Not supported yet: |
| 308 | tuple<a: type, b: type, ...> |
| 309 | |
| 310 | These types can be used in declarations, but no variable will have this type: |
| 311 | type|type |
| 312 | void |
| 313 | any |
| 314 | |
| 315 | There is no array type, use list<type> instead. For a list constant an |
| 316 | efficient implementation is used that avoids allocating lot of small pieces of |
| 317 | memory. |
| 318 | |
| 319 | A function defined with `:def` must declare the return type. If there is no |
| 320 | type then the function doesn't return anything. "void" is used in type |
| 321 | declarations. |
| 322 | |
| 323 | Custom types can be defined with `:type`: > |
| 324 | :type MyList list<string> |
| 325 | {not implemented yet} |
| 326 | |
| 327 | And classes and interfaces can be used as types: > |
| 328 | :class MyClass |
| 329 | :let mine: MyClass |
| 330 | |
| 331 | :interface MyInterface |
| 332 | :let mine: MyInterface |
| 333 | |
| 334 | :class MyTemplate<Targ> |
| 335 | :let mine: MyTemplate<number> |
| 336 | :let mine: MyTemplate<string> |
| 337 | |
| 338 | :class MyInterface<Targ> |
| 339 | :let mine: MyInterface<number> |
| 340 | :let mine: MyInterface<string> |
| 341 | {not implemented yet} |
| 342 | |
| 343 | |
| 344 | Type inference *type-inference* |
| 345 | |
| 346 | In general: Whenever the type is clear it can be omitted. For example, when |
| 347 | declaring a variable and giving it a value: > |
| 348 | let var = 0 " infers number type |
| 349 | let var = 'hello' " infers string type |
| 350 | |
| 351 | |
| 352 | ============================================================================== |
| 353 | |
| 354 | 5. Namespace, Import and Export |
| 355 | *vim9script* *vim9-export* *vim9-import* |
| 356 | |
| 357 | THIS IS STILL UNDER DEVELOPMENT - ANYTHING CAN BREAK - ANYTHING CAN CHANGE |
| 358 | |
| 359 | A Vim9 script can be written to be imported. This means that everything in |
| 360 | the script is local, unless exported. Those exported items, and only those |
| 361 | items, can then be imported in another script. |
| 362 | |
| 363 | |
| 364 | Namespace ~ |
| 365 | *:vim9script* *:vim9* |
Bram Moolenaar | 560979e | 2020-02-04 22:53:05 +0100 | [diff] [blame] | 366 | To recognize a file that can be imported the `vim9script` statement must |
Bram Moolenaar | 8a7d654 | 2020-01-26 15:56:19 +0100 | [diff] [blame] | 367 | appear as the first statement in the file. It tells Vim to interpret the |
| 368 | script in its own namespace, instead of the global namespace. If a file |
| 369 | starts with: > |
| 370 | vim9script |
| 371 | let myvar = 'yes' |
| 372 | Then "myvar" will only exist in this file. While without `vim9script` it would |
| 373 | be available as `g:myvar` from any other script and function. |
| 374 | |
| 375 | The variables at the file level are very much like the script-local "s:" |
| 376 | variables in legacy Vim script, but the "s:" is omitted. |
| 377 | |
| 378 | In Vim9 script the global "g:" namespace can still be used as before. |
| 379 | |
| 380 | A side effect of `:vim9script` is that the 'cpoptions' option is set to the |
| 381 | Vim default value, like with: > |
| 382 | :set cpo&vim |
| 383 | One of the effects is that |line-continuation| is always enabled. |
| 384 | The original value of 'cpoptions' is restored at the end of the script. |
| 385 | |
| 386 | |
| 387 | Export ~ |
| 388 | *:export* *:exp* |
| 389 | Exporting one item can be written as: > |
| 390 | export const EXPORTED_CONST = 1234 |
| 391 | export let someValue = ... |
| 392 | export def MyFunc() ... |
| 393 | export class MyClass ... |
| 394 | |
| 395 | As this suggests, only constants, variables, `:def` functions and classes can |
| 396 | be exported. |
| 397 | |
| 398 | Alternatively, an export statement can be used to export several already |
| 399 | defined (otherwise script-local) items: > |
| 400 | export {EXPORTED_CONST, someValue, MyFunc, MyClass} |
| 401 | |
| 402 | |
| 403 | Import ~ |
| 404 | *:import* *:imp* |
| 405 | The exported items can be imported individually in another Vim9 script: > |
| 406 | import EXPORTED_CONST from "thatscript.vim" |
| 407 | import MyClass from "myclass.vim" |
| 408 | |
| 409 | To import multiple items at the same time: > |
| 410 | import {someValue, MyClass} from "thatscript.vim" |
| 411 | |
Bram Moolenaar | 560979e | 2020-02-04 22:53:05 +0100 | [diff] [blame] | 412 | In case the name is ambiguous, another name can be specified: > |
Bram Moolenaar | 8a7d654 | 2020-01-26 15:56:19 +0100 | [diff] [blame] | 413 | import MyClass as ThatClass from "myclass.vim" |
| 414 | import {someValue, MyClass as ThatClass} from "myclass.vim" |
| 415 | |
| 416 | To import all exported items under a specific identifier: > |
| 417 | import * as That from 'thatscript.vim' |
| 418 | |
| 419 | Then you can use "That.EXPORTED_CONST", "That.someValue", etc. You are free |
| 420 | to choose the name "That", but it is highly recommended to use the name of the |
| 421 | script file to avoid confusion. |
| 422 | |
| 423 | The script name after `import` can be: |
| 424 | - A relative path, starting "." or "..". This finds a file relative to the |
| 425 | location of the script file itself. This is useful to split up a large |
| 426 | plugin into several files. |
| 427 | - An absolute path, starting with "/" on Unix or "D:/" on MS-Windows. This |
| 428 | will be rarely used. |
| 429 | - A path not being relative or absolute. This will be found in the |
| 430 | "import" subdirectories of 'runtimepath' entries. The name will usually be |
| 431 | longer and unique, to avoid loading the wrong file. |
| 432 | |
| 433 | Once a vim9 script file has been imported, the result is cached and used the |
| 434 | next time the same script is imported. It will not be read again. |
| 435 | *:import-cycle* |
| 436 | The `import` commands are executed when encountered. If that script (directly |
| 437 | or indirectly) imports the current script, then items defined after the |
| 438 | `import` won't be processed yet. Therefore cyclic imports can exist, but may |
| 439 | result in undefined items. |
| 440 | |
| 441 | |
| 442 | Import in an autoload script ~ |
| 443 | |
| 444 | For optimal startup speed, loading scripts should be postponed until they are |
Bram Moolenaar | 560979e | 2020-02-04 22:53:05 +0100 | [diff] [blame] | 445 | actually needed. A recommended mechanism: |
Bram Moolenaar | 8a7d654 | 2020-01-26 15:56:19 +0100 | [diff] [blame] | 446 | |
| 447 | 1. In the plugin define user commands, functions and/or mappings that refer to |
| 448 | an autoload script. > |
| 449 | command -nargs=1 SearchForStuff call searchfor#Stuff(<f-args>) |
| 450 | |
| 451 | < This goes in .../plugin/anyname.vim. "anyname.vim" can be freely chosen. |
| 452 | |
| 453 | 2. In the autocommand script do the actual work. You can import items from |
| 454 | other files to split up functionality in appropriate pieces. > |
| 455 | vim9script |
| 456 | import FilterFunc from "../import/someother.vim" |
| 457 | def searchfor#Stuff(arg: string) |
| 458 | let filtered = FilterFunc(arg) |
| 459 | ... |
| 460 | < This goes in .../autoload/searchfor.vim. "searchfor" in the file name |
| 461 | must be exactly the same as the prefix for the function name, that is how |
| 462 | Vim finds the file. |
| 463 | |
| 464 | 3. Other functionality, possibly shared between plugins, contains the exported |
| 465 | items and any private items. > |
| 466 | vim9script |
| 467 | let localVar = 'local' |
| 468 | export def FilterFunc(arg: string): string |
| 469 | ... |
| 470 | < This goes in .../import/someother.vim. |
| 471 | |
| 472 | |
| 473 | Import in legacy Vim script ~ |
| 474 | |
| 475 | If an `import` statement is used in legacy Vim script, for identifier the |
| 476 | script-local "s:" namespace will be used, even when "s:" is not specified. |
| 477 | |
| 478 | |
| 479 | ============================================================================== |
| 480 | |
| 481 | 9. Rationale *vim9-rationale* |
| 482 | |
| 483 | The :def command ~ |
| 484 | |
| 485 | Plugin writers have asked for a much faster Vim script. Investigation have |
Bram Moolenaar | 560979e | 2020-02-04 22:53:05 +0100 | [diff] [blame] | 486 | shown that keeping the existing semantics of function calls make this close to |
Bram Moolenaar | 8a7d654 | 2020-01-26 15:56:19 +0100 | [diff] [blame] | 487 | impossible, because of the overhead involved with calling a function, setting |
| 488 | up the local function scope and executing lines. There are many details that |
| 489 | need to be handled, such as error messages and exceptions. The need to create |
| 490 | a dictionary for a: and l: scopes, the a:000 list and several others add too |
| 491 | much overhead that cannot be avoided. |
| 492 | |
| 493 | Therefore the `:def` method to define a new-style function had to be added, |
| 494 | which allows for a function with different semantics. Most things still work |
| 495 | as before, but some parts do not. A new way to define a function was |
| 496 | considered the best way to separate the old-style code from Vim9 script code. |
| 497 | |
| 498 | Using "def" to define a function comes from Python. Other languages use |
| 499 | "function" which clashes with legacy Vim script. |
| 500 | |
| 501 | |
| 502 | Type checking ~ |
| 503 | |
| 504 | When compiling lines of Vim commands into instructions as much as possible |
| 505 | should be done at compile time. Postponing it to runtime makes the execution |
| 506 | slower and means mistakes are found only later. For example, when |
| 507 | encountering the "+" character and compiling this into a generic add |
| 508 | instruction, at execution time the instruction would have to inspect the type |
| 509 | of the arguments and decide what kind of addition to do. And when the |
| 510 | type is dictionary throw an error. If the types are known to be numbers then |
| 511 | an "add number" instruction can be used, which is faster. The error can be |
| 512 | given at compile time, no error handling is needed at runtime. |
| 513 | |
| 514 | The syntax for types is similar to Java, since it is easy to understand and |
| 515 | widely used. The type names are what was used in Vim before, with some |
| 516 | additions such as "void" and "bool". |
| 517 | |
| 518 | |
| 519 | JavaScript/TypeScript syntax and semantics ~ |
| 520 | |
| 521 | Script writers have complained that the Vim script syntax is unexpectedly |
| 522 | different from what they are used to. To reduce this complaint popular |
| 523 | languages will be used as an example. At the same time, we do not want to |
Bram Moolenaar | 560979e | 2020-02-04 22:53:05 +0100 | [diff] [blame] | 524 | abandon the well-known parts of legacy Vim script. |
Bram Moolenaar | 8a7d654 | 2020-01-26 15:56:19 +0100 | [diff] [blame] | 525 | |
| 526 | Since Vim already uses `:let` and `:const` and optional type checking is |
| 527 | desirable, the JavaScript/TypeScript syntax fits best for variable |
| 528 | declarations. > |
| 529 | const greeting = 'hello' " string type is inferred |
| 530 | let name: string |
| 531 | ... |
| 532 | name = 'John' |
| 533 | |
| 534 | Expression evaluation was already close to what JavaScript and other languages |
| 535 | are doing. Some details are unexpected and can be fixed. For example how the |
| 536 | || and && operators work. Legacy Vim script: > |
| 537 | let result = 44 |
| 538 | ... |
| 539 | return result || 0 " returns 1 |
| 540 | |
| 541 | Vim9 script works like JavaScript, keep the value: > |
| 542 | let result = 44 |
| 543 | ... |
| 544 | return result || 0 " returns 44 |
| 545 | |
| 546 | On the other hand, overloading "+" to use both for addition and string |
| 547 | concatenation goes against legacy Vim script and often leads to mistakes. |
| 548 | For that reason we will keep using ".." for string concatenation. Lua also |
| 549 | uses ".." this way. |
| 550 | |
| 551 | |
| 552 | Import and Export ~ |
| 553 | |
| 554 | A problem of legacy Vim script is that by default all functions and variables |
| 555 | are global. It is possible to make them script-local, but then they are not |
| 556 | available in other scripts. |
| 557 | |
| 558 | In Vim9 script a mechanism very similar to the Javascript import and export |
| 559 | mechanism is supported. It is a variant to the existing `:source` command |
| 560 | that works like one would expect: |
| 561 | - Instead of making everything global by default, everything is script-local, |
| 562 | unless exported. |
| 563 | - When importing a script the symbols that are imported are listed, avoiding |
| 564 | name conflicts and failures if later functionality is added. |
| 565 | - The mechanism allows for writing a big, long script with a very clear API: |
| 566 | the exported function(s) and class(es). |
| 567 | - By using relative paths loading can be much faster for an import inside of a |
| 568 | package, no need to search many directories. |
| 569 | - Once an import has been used, it can be cached and loading it again can be |
| 570 | avoided. |
| 571 | - The Vim-specific use of "s:" to make things script-local can be dropped. |
| 572 | |
| 573 | |
| 574 | Classes ~ |
| 575 | |
| 576 | Vim supports interfaces to Perl, Python, Lua, Tcl and a few others. But |
| 577 | these have never become widespread. When Vim 9 was designed a decision was |
| 578 | made to phase out these interfaces and concentrate on Vim script, while |
| 579 | encouraging plugin authors to write code in any language and run it as an |
| 580 | external tool, using jobs and channels. |
| 581 | |
| 582 | Still, using an external tool has disadvantages. An alternative is to convert |
| 583 | the tool into Vim script. For that to be possible without too much |
| 584 | translation, and keeping the code fast at the same time, the constructs of the |
| 585 | tool need to be supported. Since most languages support classes the lack of |
| 586 | class support in Vim is then a problem. |
| 587 | |
| 588 | Previously Vim supported a kind-of object oriented programming by adding |
| 589 | methods to a dictionary. With some care this could be made to work, but it |
| 590 | does not look like real classes. On top of that, it's very slow, because of |
| 591 | the use of dictionaries. |
| 592 | |
| 593 | The support of classes in Vim9 script is a "minimal common functionality" of |
| 594 | class support in most languages. It works mostly like Java, which is the most |
| 595 | popular programming language. |
| 596 | |
| 597 | |
| 598 | |
| 599 | vim:tw=78:ts=8:noet:ft=help:norl: |