Lambdas and "typedefs" in Vim9

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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.

--
--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/rkplkd%24o98%241%40ciao.gmane.io.
Reply | Threaded
Open this post in threaded view
|

Re: Lambdas and "typedefs" in Vim9

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 -- [hidden email] -- 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_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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/202009271151.08RBpfkI137035%40masaka.moolenaar.net.
Reply | Threaded
Open this post in threaded view
|

Re: Lambdas and "typedefs" in Vim9

Lifepillar
On 2020-09-27, Bram Moolenaar <[hidden email]> 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.

--
--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/rkq4el%24p4m%241%40ciao.gmane.io.
Reply | Threaded
Open this post in threaded view
|

Re: Lambdas and "typedefs" in Vim9

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

 /// Bram Moolenaar -- [hidden email] -- 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_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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/202009271545.08RFjj4L186795%40masaka.moolenaar.net.
Reply | Threaded
Open this post in threaded view
|

Re: Lambdas and "typedefs" in Vim9

Lifepillar
On 2020-09-27, Bram Moolenaar <[hidden email]> 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 -- [hidden email] -- 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_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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/rkqgue%241385%241%40ciao.gmane.io.