My goal is not to remove VimScript. It should remain there. But instead of adding if_my_favorite_langauge. We should add if_wasm and call stop adding any other languages.
"Web" in WASM is misleading, it has nothing to do with "Web" as in internet or browser similar to Java in Javacsript has nothing to Java programming. While you can write in WASM assembly. You will most likely never write it. You write in a higher language such as c, rust, javascript which then compiles to WASM binaries or WASM assemblies.I'm more interested in WASM binaries as they can be compact and are portable across various machine architecture and OS. You can try here: https://mbebenita.github.io/WasmExplorer/ Here is a simple example: You write in your favorite language that can compile to WASM. I'm using C here: int add(int a, int b) { return a+b; } int main() { int result = add(1,2); } Then it converts to WASM assembly or WASM binary which is portable: WASM assembly looks like this. WASM binaries are portable and lot more efficient at running then manually parsing this ASM and executing. (module (table 0 anyfunc) (memory $0 1) (export "memory" (memory $0)) (export "_Z3addii" (func $_Z3addii)) (export "main" (func $main)) (func $_Z3addii (; 0 ;) (param $0 i32) (param $1 i32) (result i32) (i32.add (get_local $1) (get_local $0) ) ) (func $main (; 1 ;) (result i32) (i32.const 0) ) ) Based on the WASM VM you choose it can do other optimizations. And here is the WASM generating x86 ASM code: wasm-function[0]: sub rsp, 8 ; 0x000000 48 83 ec 08 mov ecx, esi ; 0x000004 8b ce mov eax, ecx ; 0x000006 8b c1 add eax, edi ; 0x000008 03 c7 nop ; 0x00000a 66 90 add rsp, 8 ; 0x00000c 48 83 c4 08 ret ; 0x000010 c3 wasm-function[1]: sub rsp, 8 ; 0x000000 48 83 ec 08 xor eax, eax ; 0x000004 33 c0 nop ; 0x000006 66 90 add rsp, 8 ; 0x000008 48 83 c4 08 ret ; 0x00000c c3 As you can see there is nothing about internet or browser in this code. As you can see, WASM has first class notion of types (i32) allowing WASM VMs to optimize natively. We don't need vimscript to implement a type. This mean I can use the entire ecosystem of that particular language which includes libraries that the language uses as well as others have written. So my thought here is let us first get a WASM VM running natively in vim as first class citizen and then we can worry about writing a better VM optimizing it to be faster. WASM also have other extensions point some of which are official spec and some which can be own. * WASI - WebAssembly System Interface, think of this like the C stdlib. This allows WASM to make system calls similar to read/write in c. * WASM threads - Allows to use threading, locks. * and many more On Saturday, January 4, 2020 at 5:10:39 PM UTC-8, Tony Mechelynck wrote: > > On Sun, Jan 5, 2020 at 1:22 AM Prabir Shrestha <[email protected] > <javascript:>> wrote: > >> -1 for }. That is the most absurd syntax I have seen in any language that >> only uses it for closing. >> >> So I went and re-read the poll https://github.com/vim/vim/issues/3573. >> And here is what I can think of reading it again in Jan 2020. >> >> Can we get more info on what does make vim-script faster mean? >> >> [image: Screen Shot 2020-01-04 at 3.53.13 PM.png] >> >> [image: Screen Shot 2020-01-04 at 4.04.27 PM.png] >> >> [image: Screen Shot 2020-01-04 at 4.05.36 PM.png] >> >> >> >> 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. >> >> >> On Saturday, January 4, 2020 at 7:18:01 AM UTC-8, mattn wrote: >>> >>> Simply poor readability for me. >>> >>> And it will be difficult to support Vim script syntax highlighting in >>> other text editors or viewer (like GitHub). >>> >>> On Saturday, January 4, 2020 at 10:05:53 PM UTC+9, Andy Massimino wrote: >>>> >>>> On 1/3/20 8:17 AM, Bram Moolenaar wrote: >>>> > Ken Takata wrote: >>>> > >>>> >> 2020/1/3 Fri 19:02:13 UTC+9 Bram Moolenaar wrote: >>>> >>> >>>> >>> 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. >>>> >>> >>>> >> Text objects like "a{" or "i{" don't work well without the starting >>>> "{". >>>> > That never worked for "for" / "endfor", right? >>>> > >>>> >> Also "%" may not work well. >>>> > With some adjustments to b:match_words it works. >>>> >>>> b:match_words sequences between if/else/endif and >>>> function/return/endfunction tuples not just if/endif >>>> function/endfunction pairs. Adjusting b:match_words to handle '}' ends >>>> breaks this. There is no way to handle this with b:match_words (do you >>>> know of one?) >>>> >>>> Consider: >>>> >>>> function A() | if x | return | endif | endfunction >>>> >>>> vs: >>>> >>>> function A() | if x | return | } | } >>>> >>>> One of the nicer things about vimscript (with respect to %) is 'return' >>>> can only match with 'endfunction', 'break' with 'endwhile'/'endfor', >>>> 'else' with 'endif', etc. >>>> >>>> > >>>> > And when "%" works you can select a block from "if"/"while"/"for" >>>> until >>>> > the matching "}" with "v%". >>>> > >>>> >>>> >> Hm. > - Vim must keep support of Vim script for compatibility reasons > - WASM means "web assembly", right? Well, Vim must go on working even when > no web connection is available, and I'm not going to code my vimrc in > assembly language, which is the least compatible source language there is. > (x86 even has two of them, MASM and AT&T assembler). > > Just my 0.02 €. > > Best regards, > Tony. > -- -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/32387a3c-ca8b-4475-8b2c-473ff8d2ea17%40googlegroups.com.
