Reply to message «Re: Vim Script grammer», sent 13:17:46 12 July 2011, Tuesday by Marc Weber:
I think the solution is a modal editor with plugin architecture and a VimL
interpreter as one of the plugins so that you can move VimL scripts there. I am
choosing LLVM for it because it is the only program that enables me to write
JIT
and normal compiler (though with such wide use of eval (:exe) it won't do much)
in one turn and also has a number of already written optimization paths.
> Moreover for JS etc there exist many more libraries such as parser
> generators etc. You're right: For VimL there exist XML parsing libraries
> as well (-> webapi-vim on github). But it took 30 years until someone
> stepped up to write it. And still then it was buggy and had to be fixed.
When I was writing YAML parser in VimL I just took pyyaml, rewritten it in VimL
and also copied their tests (+ a number of yaml.vim specific ones after
everything was written). With this approach you can easily write an XML parser
and also gain a bit of code reusage :)
> Moreover for JS etc there exist many more libraries such as parser
> generators etc. You're right: For VimL there exist XML parsing libraries
> as well (-> webapi-vim on github). But it took 30 years until someone
> stepped up to write it. And still then it was buggy and had to be fixed.
For C/C++ there are even more libraries. And there is C/C++->JS compiler, but
do
you have the opposite? I don't think writing editor in JS is a good idea. I
would rather like to see some generic bytecode support in browser then JS.
> If ZyX manages to optimize VimL I'd be happy cause I had to stop two
> projects due to speed reasons. (One was about completion for Delphi. It
> partially works. But its much too slow even when using as much caching
> as you can - the other was about tagging as3 sources on the fly -
> because I don't like to retag sources always. I want things to work
> without me taking action - EAch time it partially worked - but I spend
> hours on getting response time to less than a second - and I was still
> not satisfied.)
I am going to write a replacement for Vim that is mostly backwards-compatible
and has a VimL interpreter (JIT compiler) as one of its plugins. But do not
expect something more then core in a year. I also have some other project to
finish before starting to write something that time-consuming.
So, if I succeed, it will be bad idea to write these projects in VimL and not
in, for example, python.
> Yes, have close look at the python "support". The python module does
> not even have a "escape_for_vim" function !
One of the reasons why I have wrote yaml.vim is that there is no way to easily
pass recursive structures to vim. Neither from python (or any other language
that is "supported") nor using built-in functionality. Having eval as the only
way to pass data back to vim is weird. Perl and ruby "support" is even worse:
there is no Vim::Eval function that can return a hash or a list.
> Yes - you can get your job done. But a clean interface would allow you
> to map python callbacks to <cr> or the like directly.. The problem is
> that the time of each individual is limited. And you don't have time to
> learn 50 languages and implement things in those. Thus if JS would be
> used only you could script your browser and Vim
JS support may be implemented by one of the plugins, but I strongly object to
having it as the only scripting language.
Unless you want to move editor to browser you will forced to have two different
implementations of the core. To just script textareas writing an extension to
browser is enough and it is much more simple then having two cores.
> we both agree that in this case its easy to see what's going wrong.
> But now use more complicated code .. good luck.
>
> Maybe there is even a way to iterate over all objects VimL knows about
> to find out what func 77 is. But why should people learn about all this
> stuff?
Use :function {77}. But when you write something like (you may have seen
similar
syntax in code that uses jQuery)
call self.dosomething().dosomethingelse()
and self.dosomething() has
return self.dosmth().dosmth2()
and self.dosmth() fails... You will have split first :call into two as well as
second :return to even get the point where something failed. Error message in
this case is very strange and cryptic, I had to spend about twenty minutes to
guess that I should do the split.
> We all love that "English" is an universal language and that we can
> understand each other.
I like that there is an universal language, but I never liked English itself.
Esperanto would fit here better.
> It would be equally nice if browsers and Vim had
> the same scripting language.
I would stay on old Vim in this case.
Original message:
> Excerpts from Ingo Karkat's message of Tue Jul 12 09:36:52 +0200 2011:
> > IMO most of the complexity is due to the Vim API, not VimL itself. So,
> > unless you completely redesign the API (and that probably means changing
> > much of the core Vim implementation as well), you won't gain that much.
>
> From your homepage it looks like you've spend some time with various
> programming languages. I read "Java, C++, Unix Shell scripts, Perl, ..".
>
> So probably you love error messages like something has gone wrong in
> 10..27..34 as much as I do. [1]
>
> This happens if you use the "advanced features" of VimL: dict functions.
>
> If you compare this to nice stack traces of python, ruby, HaXe, JS you
> see the difference.
>
> And the amount of plugins available for Opera, Firefox which have been
> written in JS at least proof that JS is a language many devs can pick up
> and to turn their browser into what they want as well.
>
> Moreover for JS etc there exist many more libraries such as parser
> generators etc. You're right: For VimL there exist XML parsing libraries
> as well (-> webapi-vim on github). But it took 30 years until someone
> stepped up to write it. And still then it was buggy and had to be fixed.
>
> Resources are wasted here. Keep that in mind. Those resources could be
> spend on writing a web aware vim implementation or on Uganda or on
> installing energy saving items in your house.
>
> Or on writing what many people ask on irc:
> Writing howtos about how to apply Vim to user specific problems such as
> - setting up Vim with python development
> - setting up Vim for web development
> - ...
> - People *do* join #vim and ask those questions. So we don't have
> documentation satisfying that. We should work on that rather than
> writing yet another library which already exists in 10 other languages
> (and just works) in VimL (my 2 cents).
>
> Historical VimL was perfect. 30 years ago there was neither JS, PHP,
> perl, ruby, ... So VimL was a huge step. Today
>
> > So, for me, I'd like to keep VimL (and the many extension languages that
> > are / can be supported by Vim).
>
> Yes, have close look at the python "support". The python module does
> not even have a "escape_for_vim" function !
>
> Yes - you can get your job done. But a clean interface would allow you
> to map python callbacks to <cr> or the like directly.. The problem is
> that the time of each individual is limited. And you don't have time to
> learn 50 languages and implement things in those. Thus if JS would be
> used only you could script your browser and Vim
>
> We all love that "English" is an universal language and that we can
> understand each other. It would be equally nice if browsers and Vim had
> the same scripting language. eventually you should translate Vim
> documentation into Esperento because its easy to pick up..
> The end result is you still have to learn English because most
> interesting documentation has been written in English.
>
> If ZyX manages to optimize VimL I'd be happy cause I had to stop two
> projects due to speed reasons. (One was about completion for Delphi. It
> partially works. But its much too slow even when using as much caching
> as you can - the other was about tagging as3 sources on the fly -
> because I don't like to retag sources always. I want things to work
> without me taking action - EAch time it partially worked - but I spend
> hours on getting response time to less than a second - and I was still
> not satisfied.) - Yes you're right: I should not have used VimL in the
> first place. Which value does VimL provide then if you have to learn
> VimL, then you have to learn that VimL doesn't satisfy you, then you
> have to rewrite your stuff?
>
> Anyway I would have been much happier if it worked out of the box.
>
> Today you can't do everything on your own:
> - maintain a language for an editor
> - support editors
> - write editor tools to support other languages
> - ...
>
> Maybe its only me who wants this all.
>
> If was using Vim to write emails only I'd be happy.
>
> Marc Weber
>
>
>
> [1] Example triggering those kind of messages:
>
> let a = {}
>
> fun a.a()
> call self.b()
> endf
>
> fun a.b()
> call self.a()
> endf
>
> call a.a()
>
> we both agree that in this case its easy to see what's going wrong.
> But now use more complicated code .. good luck.
>
> Maybe there is even a way to iterate over all objects VimL knows about
> to find out what func 77 is. But why should people learn about all this
> stuff?
signature.asc
Description: This is a digitally signed message part.
