Re: breaking with history ?

Marc Weber <marco-oweber@gmx.de> a écrit:
> I guess the perfect thing for VimL would be moving it into its own
> library (like python).
>
> Then other projects could use VimL, too. And it would allow some future
> optimizations.
>
> Then it would be an optional dependency (which most users are very very
> likely to use)

Then this raises the question: can VimL stand on its own, i.e. even if
it were enhanced as far as functionality is concerned, why would
somebody use it rather than any other language? If you compare Python,
Ruby and Lua, there are strong reasons why you could favor one or the
other; what could VimL bring? (You more or less answer the question
below when you ask "Why not use Python or ... then?")

> > * Organize functions in libraries – just dictionaries, really. So, for
> > instance, "stridx()", "strlen()", "strpart() would be
> > "string.index()", "string.length()", "string.part()", whereas
> > functions dealing with buffers would be in a "buffer" dictionary, etc.
> > That would make the entire language much clearer (and easier to
> > extend).
>
> You can al ready do so:
>
> let string = {}
> for n in ['stridx','length','part']
> exec 'fun string.'.n.'(...) | return call('.n.', a:000) | endf'
> endfor
>
> or such (untested)

Of course I can do that but it'd just be so much simpler if it were
already done (not to mention sharing code that use such a convention).

> > * Remove the one-command-per-line restriction, so you can write things
> > like:
> > while foo if bar TRUE else break endif endwhile
>
> See example above - often you already can use |
> eg while foo | if | bar | TRUE | else | break| endif| endwhile
> or such.

I forgot to mention: allow multiple commands on the same line without
the bar :) But thinking about it, perhaps that's even simpler than
"then", "do", and/or ";" (albeit more dangerous because it *often*
works, not always).

> > * Get rid of ":call" for functions. Shouldn't it be possible for Vim
> > to distinguish ":foo" (a command) from ":bar()" (a function) thanks to
> > the parentheses?
> If we start that, then we can work on a viml2 version adding proper
> object support, closures - but then, why not just use python or ruby or
> perl, or ... ?

Would it really be such a major change that you'd need an entirely new
version of the language?

> > Now perhaps the best solution is to replace VimL with Lua or Ruby or,
> You got it - improving VimL would lead to something other have already
> invented.
>
> We cannot replace VimL, but we can make python, ruby work as nice as viml.
> Then this switch may naturally happen without breaking existing code.

Yes, of course; but, as you put it, it "may naturally happen", which
implies it might never happen too and perhaps ten years from now we'll
still have an "official" yet limited scripting language and countless
extensions relying on "unofficial" languages (mostly Python) that
won't work for everybody. So, in my opinion, it should rather be
decided now what we want to script Vim with in the future: either
VimL, and then it should be improved, or Python/Ruby/Lua/YouNameIt,
and then development should go in that direction now; the latter
solution would be quite a change.

> There are cool languages such as urweb, disciple which deserve love and
> have unique new features.

Oh, googling those, I see that both are Haskell-like languages
(Disciple is actually a dialect of Haskell). A few weeks ago, I
started trying to learn Haskell for fun; that *was* fun, but I
definitely wouldn't want that to script my editor and I'm afraid it
would repel new users (one of the reasons why I chose Vim over Emacs
myself was that I just couldn't get my head around Lisp and I wanted to
be able to customize the editor at once).

> The next big thing is: Do I have enough to time to contribute to help
> making this all happen - and if so - which is the best way.
>
> Eg if somebody could investigate whether Vim could benefit from all the
> work which is but into gobjectIntrospection this would be great.
>
> I don't know yet - all I know is that they have similar goals: make C
> apps scriptable by scripting languages.

Unfortunately I'm illiterate in C (I'm not a programmer, and I use Vim
mostly for TeX files), so I'm useless here – in case I wasn't elsewhere :).

Best,
Paul

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.