Lambdas and "typedefs" in Vim9

[Lifepillar]

I have not followed the development of Vim9 script closely, but
yesterday I have started to play with it. I was pleasantly surprised to
see how far it's got already: I could convert some scripts of mine
without much effort and make them run just fine!

I have two questions/curiosities:

1. I was not able to pass lambdas to defs, only funcrefs. Can/will this
be supported?

2. Has a type aliasing or "typedef" mechanism been considered or,
perhaps, already planned? My use case is defining a library of opaque
types, which I can change without the need to modify client code.

Thanks,
Life.

[Bram Moolenaar]

> I have not followed the development of Vim9 script closely, but
> yesterday I have started to play with it. I was pleasantly surprised to
> see how far it's got already: I could convert some scripts of mine
> without much effort and make them run just fine!

Glad to hear. Note that some things still change.

> I have two questions/curiosities:
>
> 1. I was not able to pass lambdas to defs, only funcrefs. Can/will this
> be supported?

Can you give an example of what does not work?

> 2. Has a type aliasing or "typedef" mechanism been considered or,
> perhaps, already planned? My use case is defining a library of opaque
> types, which I can change without the need to modify client code.

Yes, typedefs are planned to be added at some point. We can make
everything work without it, so it's for later.

--
The average life of an organization chart is six months. You can safely
ignore any order from your boss that would take six months to complete.
(Scott Adams - The Dilbert principle)

/// Bram Moolenaar -- Br...@Moolenaar.net -- 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 ///

[Lifepillar]

On 2020-09-27, Bram Moolenaar <Br...@moolenaar.net> wrote:

>> I have two questions/curiosities:
>>
>> 1. I was not able to pass lambdas to defs, only funcrefs. Can/will this
>> be supported?
>
> Can you give an example of what does not work?

This is what I have tried:

vim9script

def Filter(l: list<string>, Cond: func(string): bool): list<string>
let res = []
for item in l
if Cond(item)
add(res, item)
endif
endfor
return res
enddef

def Filter2(l: list<string>, Cond: func(string): bool): list<string>
return filter(copy(l), Cond)
enddef

def MyCond(v: string): bool
return v =~ '^a'
enddef

let x = ['a', 'b', 'c']

Filter(x, MyCond)
# OK

Filter(x, funcref(MyCond))
# OK

Filter(x, { v -> v =~ '^b' })
# E1013

Filter2(x, { v -> v =~ '^b' })
# Ditto

I have tried other variations of the signatures, such as 'func', but
without luck. Also tried to add types to the lambda, as in:

{ v: string -> ... }

but that gives E720 (not that I expected it to work).

>> 2. Has a type aliasing or "typedef" mechanism been considered or,
>> perhaps, already planned? My use case is defining a library of opaque
>> types, which I can change without the need to modify client code.
>
> Yes, typedefs are planned to be added at some point. We can make
> everything work without it, so it's for later.

That's great!

Life.

[Bram Moolenaar]

> This is what I have tried:
>
> vim9script
>
> def Filter(l: list<string>, Cond: func(string): bool): list<string>
> let res = []
> for item in l
> if Cond(item)
> add(res, item)
> endif
> endfor
> return res
> enddef
>
> def Filter2(l: list<string>, Cond: func(string): bool): list<string>
> return filter(copy(l), Cond)
> enddef
>
> def MyCond(v: string): bool
> return v =~ '^a'
> enddef
>
> let x = ['a', 'b', 'c']
>
> Filter(x, MyCond)
> # OK
>
> Filter(x, funcref(MyCond))
> # OK
>
> Filter(x, { v -> v =~ '^b' })
> # E1013

Well, in a sense that is correct. The Filter() functions accepts a
function reference with a specific type, and what is passed in is a
function reference without any known type. Using that function
reference might fail, thus requires a runtime check, which is what we
want to avoid in a compiled function.

This works:

def Func()

Filter(x, { v -> v =~ '^b' })

enddef
Func()

Because the lambda is compiled.

I suppose what we could do is that when an argument is a lambda, first
compile it, so that we have the type. This would also make execution
faster. It gets a bit more complicated if it's a nested structure, e.g.
dict with a lambda.

--
A)bort, R)etry, B)ang it with a large hammer

[Lifepillar]

On 2020-09-27, Bram Moolenaar <Br...@moolenaar.net> wrote:
>

>> Filter(x, { v -> v =~ '^b' })
>> # E1013
>
> Well, in a sense that is correct. The Filter() functions accepts a
> function reference with a specific type, and what is passed in is a
> function reference without any known type.

Ok, that might be expected, but the above call fails also when
Filter()'s argument is defined simply as `func`, which, according to the
documentation, is the type for arguments that are "any kind of function
reference, no type checking for arguments or return value".

But I'd rather have strict type checking anyway, so what you propose
below would be perfect. Unfortunately, I am not into the implementation
details enough to be helpful. Looking forward to seeing progress in this
area as well!

Life.

> This works:
>
> def Func()
> Filter(x, { v -> v =~ '^b' })
> enddef
> Func()
>
> Because the lambda is compiled.
>
> I suppose what we could do is that when an argument is a lambda, first
> compile it, so that we have the type. This would also make execution
> faster. It gets a bit more complicated if it's a nested structure, e.g.
> dict with a lambda.
>
> --
> A)bort, R)etry, B)ang it with a large hammer
>
> /// Bram Moolenaar -- Br...@Moolenaar.net -- 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 ///
>

> --