> On 5 Jan 2020, at 18:55, Bram Moolenaar <[email protected]> wrote:
>
>
> Ben Jackson wrote:
>
>> Hi Bram, thanks for sharing. Looks really promising.
>>
>> Regarding https://github.com/brammool/vim9#3-better-vim-script, I have a
>> few ideas for your consideration:
>>
>> * Execution often relies on user configuration (ignorecase, magic, etc.)
>> and there is common boilerplate required in many scripts to set/restore
>> cpo. Could we say that when `scriptversion` is `vim9`, we always execute as
>> if `set cpo&vim` ?
>
> For :def functions those will be parsed as if 'nocompatible' is set.
>
> For 'ignorecase' and 'magic' we can ignore those for the =~ and !~
> operators. What else?
The “usual" expression operators behave differently (when not suffixed with #
or ?) depending on `ignorecase`, right. As in: if x == “CaseSensitiveMatch?”
Depends on ignorecase.
Examples from :help expr4:
"abc" ==# "Abc" evaluates to 0
"abc" ==? "Abc" evaluates to 1
"abc" == "Abc" evaluates to 1 if 'ignorecase' is set, 0 otherwise
I think this is one of those things you just have to know (like using === in
javascirpt). Would be fewer accidental bugs if `==` worked consistently I guess.
>
> Not sure yet what will happen at the script level. No changes are
> needed for speed. If needed the file can be put inside :def/:enddef
> and then calling that function. Not ideal, but at least it's possible.
I guess the javascript idiom here is to have an anonymous function that’s
immediately called:
( def ( args ) : return type
Code
enddef )()
But that’s hardly art.
>
>
>> * Line continuation. I know this is probably hard to change, but could we
>> look at a line-continuation scheme that's more familiar ? As we don't have
>> line termination, Perhaps something more like python's e.g. if a line ends
>> with an unbalanced parenthesis (or a `<backslash><newline>`), then assume
>> the next line is a continuation? I think the `<newline><backslash>` syntax
>> is unfamiliar to a lot of people.
>
> It will be difficult to implement, and we'll still need the old way of
> line continuation in some places. Putting the backslash at the end of
> the line isn't nice anyway, too easy to make mistakes, we should
> probably not add it. Mixing the two is probably worse.
> If we can have some statements continue on the next line without a
> backslash remains to be seen.
Sure. I figured this would be difficult.
>
>> * Scoped functions or lambdas containing ex-commands (or better, def
>> function bodies). When combined with try/finally, this would allow
>> constructs that take a "block" of code, such as "WithCurrentBuffer( buf, {
>> => block of code/commands, maybe split across lines } )" or something like
>> this when working with external tools `SendMessageToTool( message, then = {
>> => some block of ex commands } ). This can currently be done with Funcref,
>> but I think that you have to do 'function ...' and then 'delfiunc' as all
>> functions are currently global. Maybe the new scoping rules could be
>> extended to allow this.
>
> That a function declared locally in a function becomes a global function
> is indeed unexpected. We can at least make them local inside a :def
> function, unless prefixed with g:, just like with variables.
>
> Defining a function and creating a funcref in one step would also be
> useful. Not sure about the syntax. TypeScript does something like
> this:
> let ref = function(arg: type): rettype { ... body };
>
> Perhaps we can do:
> let ref = def(arg: type): rettype
> ... body
> enddef
>
I personally like the python approach: a def inside a function is a local
variable of function type. As in:
let myFunc = function( … ) { … body }
Would be written simply as
def myFunc( … ):
… body
In vimscript we could do the same, having a nested ‘def’ always declare a local
Funcref by name, but have a ‘real’ name that’s hidden from the user (like a
lambda). In the above example, that would create a local variable ‘myFunc’
which is a Funcref to an (unnamed?) function with ( … ) args and … body.
Again, not sure how practical that is, but it _feels_ smiler to how lambdas
currently work.
>> I already mentioned elsewhere that the other barrier to entry for vim
>> scripting is tooling and debugging. Hopefully with a these changes we can
>> consider how to:
>>
>> * extract the parser so that an external tool can parse and do code
>> comprehension, go-to, refactor, etc., think Vim Language Server (there is
>> one, but it's not canonical)
>
> It's a lot easier to make an independent parser. Trying to share a
> parser will make things very complicated.
Fair enough.
>
>> * provide a interface to a debug adapter to allow debugging of vimscript
>> executing in a Vim instance (i.e. Vim Debug Adapter)
>
> Sure.
Woo \o/. Debugging vimscript with vimspector would be very kickass. I’m more
than willing to put in hard graft to make this happen.
>
>> * provide better source/line information for stack traces (so that we can
>> reliably jump to location of assertions e.g. test failures using cnext). I
>> saw a recent patch which improves sourcing_lineno and uses a proper stack.
>> I was planning to work on a patch to store source/line info when debugging
>> is enabled, but might hold off while vim 9 shakes down, as this is likely
>> required for the above debugger interface (assuming that's a goal).
>
> Yes, I started improving the execution stack. Currently it only tracks a
> sequence of function calls, it does not continue with a :source command
> or executing autocommands, and it's a string without file/line info.
> This can be greatly improved.
I’ll keep researching. I have some ideas about how to do it, so I’ll maybe put
a prototype together over the next few months.
>
> --
> ROBIN: (warily) And if you get a question wrong?
> ARTHUR: You are cast into the Gorge of Eternal Peril.
> ROBIN: Oh ... wacho!
> "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
>
> /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
> /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\ an exciting new programming language -- http://www.Zimbu.org ///
> \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
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/1D11EF06-2DB2-48BF-BD43-C1187099C781%40gmail.com.
