Wednesday, June 12, 2013

Re: breaking with history ?

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)

> * 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)

> * 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.

> * 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 ... ?

> 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.

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

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.

Marc Weber

--
--
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.

No comments: