[vim/vim] Support contra-variant type check for object method arguments (similar to Dart) (PR #13221)

Yegappan Lakshmanan

unread,

Sep 29, 2023, 1:05:15 AM9/29/23

to vim/vim, Subscribed

Fixes #12965

You can view, comment on, or merge this pull request online at:

https://github.com/vim/vim/pull/13221

Commit Summary

af75efd Support contra-variant type check for object method arguments (similar to Dart). Fixes #12965

File Changes

(6 files)

Patch Links:

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.

codecov[bot]

unread,

Sep 29, 2023, 1:31:12 AM9/29/23

to vim/vim, Subscribed

Codecov Report

Merging #13221 (af75efd) into master (02902b5) will decrease coverage by 5.42%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master   #13221      +/-   ##
==========================================
- Coverage   82.13%   76.71%   -5.42%     
==========================================
  Files         160      150      -10     
  Lines      195393   152556   -42837     
  Branches    43844    39340    -4504     
==========================================
- Hits       160479   117035   -43444     
- Misses      22074    23499    +1425     
+ Partials    12840    12022     -818

Flag	Coverage Δ
huge-clang-Array	`?`
linux	`?`
mingw-x64-HUGE	`76.71% <100.00%> (-0.01%)`	⬇️
mingw-x86-HUGE	`?`
windows	`76.71% <100.00%> (-1.59%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
src/vim9class.c	`88.84% <100.00%> (-2.06%)`	⬇️
src/vim9type.c	`90.20% <100.00%> (-0.13%)`	⬇️

... and 154 files with indirect coverage changes

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Sep 29, 2023, 1:30:19 PM9/29/23

to vim/vim, Subscribed

what is contr-variant?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Restorer

unread,

Sep 29, 2023, 2:42:40 PM9/29/23

to vim/vim, Subscribed

I was curious about that too, as I didn't understand what it was about at all.
Here's what wikipedia says:
Covariance and contravariance (computer science)
And this is what I was able to find on Dart
Dart and covariant
But if you, @yegappan , could explain it in your own words, it would be much better.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Yegappan Lakshmanan

unread,

Sep 29, 2023, 3:50:41 PM9/29/23

to vim...@googlegroups.com, reply+ACY5DGGALMH4XHG2UX...@reply.github.com, vim/vim, Subscribed

Hi Christian,

On Fri, Sep 29, 2023 at 10:30 AM Christian Brabandt <vim-dev...@256bit.org> wrote:

what is contr-variant?

Consider the following example (from #12965):

class A

endclass

class B extends A
endclass

class C extends B
endclass

In this example, type "C" is a covariant of type "B" and "A" is contra-variant of type "B".

This matters when overruling methods in an extended class. The method return value

type in an extended class can use a covariant type of return value in the parent class.

The type of method arguments in an extended class can use a contra-variant type.

For example (continuing the above example):

class Foo
def Doit(p: B): B
return B.new()
enddef
endclass

class Baz extends Foo
def Doit(p: A): C
return C.new()
enddef
endclass

The Doit() method in class Foo uses "B" as the argument type and "B" as the return type.

The Doit() method in class Baz uses "A" as the argument type and "C" as the return type.

"A" is a contra-variant of "B" and "C" is a co-variant of "B".

A detailed explanation about this is in https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science).

I wanted to follow the model used in the Dart language (https://medium.com/dartlang/dart-declaration-site-variance-5c0e9c5f18a5).

Regards,

Yegappan

vim-dev ML

unread,

Sep 29, 2023, 3:50:55 PM9/29/23

to vim/vim, vim-dev ML, Your activity

..

I wanted to follow the model used in the Dart language (
https://medium.com/dartlang/dart-declaration-site-variance-5c0e9c5f18a5).

Regards,
Yegappan

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

Yegappan Lakshmanan

unread,

Sep 29, 2023, 3:51:48 PM9/29/23

to vim/vim, vim-dev ML, Push

@yegappan pushed 1 commit.

bd9b8f4 Support contra-variant type check for object method arguments (similar to Dart). Fixes #12965

—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.

Yegappan Lakshmanan

unread,

Sep 29, 2023, 4:19:22 PM9/29/23

to vim...@googlegroups.com, reply+ACY5DGAQ3YPTM2RCWD...@reply.github.com, vim/vim, vim-dev ML, Your activity

Currently the type of the method arguments and return value can be a covariant type

of the ones in the parent class method.

- Yegappan

vim-dev ML

unread,

Sep 29, 2023, 4:19:39 PM9/29/23

to vim/vim, vim-dev ML, Your activity

On Fri, Sep 29, 2023 at 12:50 PM vim-dev ML ***@***.***>

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Sep 29, 2023, 4:52:28 PM9/29/23

to vim/vim, vim-dev ML, Comment

Closed #13221 via f3b68d4.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

errael

unread,

Sep 29, 2023, 5:51:30 PM9/29/23

to vim/vim, vim-dev ML, Comment

Shades of Java's PECS.

There were two ways to deal with #12965.

Adjust the parser to meet the spec.
Change the spec and various implementation things.

Doing 1. is backwards compatible with future implementation of the requested features.
Doing 2. seems rushed.

My first look, not running any code, this change seems to add little, at the expense of conceptual complexity. I was in the process of manually working through some things related to this, so I could make a comment, when it got checked in (seemed pretty quick for a change that wasn't understood).

What's to rush to add new features that have not been debated?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Yegappan Lakshmanan

unread,

Sep 29, 2023, 9:29:59 PM9/29/23

to vim...@googlegroups.com, reply+ACY5DGA7ULSQWMQ7K6...@reply.github.com, vim/vim, vim-dev ML, Comment

Hi,

On Fri, Sep 29, 2023 at 2:51 PM errael <vim-dev...@256bit.org> wrote:

Shades of Java's PECS.

There were two ways to deal with #12965.

Adjust the parser to meet the spec.

The spec currently states that:

Object methods of the base class can be overruled. The signature (arguments,
argument types and return type) must be exactly the same.

The current implementation doesn't match with this spec. If we follow this spec,
then the type in an overruled method cannot be a covariant or contra-variant.
I think that will be limiting, as the method in an extended class may want to return
a covariant type.

Change the spec and various implementation things.

Doing 1. is backwards compatible with future implementation of the requested features.
Doing 2. seems rushed.

My first look, not running any code, this change seems to add little, at the expense of conceptual complexity. I was in the process of manually working through some things related to this, so I could make a comment, when it got checked in (seemed pretty quick for a change that wasn't understood).

Let me know if you see any cases that will break with the latest changs.

What's to rush to add new features that have not been debated?

No rush. I didn't see any objection to the proposal in https://github.com/vim/vim/issues/12965

and this is closer to the Dart spec.

As the changes are minimal to support this, if needed, we can make adjustments.

Regards,

Yegappan

vim-dev ML

unread,

Sep 29, 2023, 9:30:21 PM9/29/23

to vim/vim, vim-dev ML, Your activity

Hi,

On Fri, Sep 29, 2023 at 2:51 PM errael ***@***.***> wrote:

> Shades of Java's PECS.
>
> There were two ways to deal with #12965

> <https://github.com/vim/vim/issues/12965>.
>
> 1. Adjust the parser to meet the spec.

>
>
The spec currently states that:

Object methods of the base class can be overruled. The signature (arguments,
argument types and return type) must be exactly the same.

The current implementation doesn't match with this spec. If we follow
this spec,
then the type in an overruled method cannot be a covariant or
contra-variant.
I think that will be limiting, as the method in an extended class may want
to return
a covariant type.

>

> 1. Change the spec and various implementation things.

>
> Doing 1. is backwards compatible with future implementation of the
> requested features.
> Doing 2. seems rushed.
>
> My first look, not running any code, this change seems to add little, at

> the expense of *conceptual complexity*. I was in the process of manually

> working through some things related to this, so I could make a comment,
> when it got checked in (seemed pretty quick for a change that wasn't
> understood).
>

Let me know if you see any cases that will break with the latest changs.

> What's to rush to add new features that have not been debated?
>
>
>
No rush. I didn't see any objection to the proposal in
https://github.com/vim/vim/issues/12965
and this is closer to the Dart spec.

As the changes are minimal to support this, if needed, we can make
adjustments.

Regards,
Yegappan

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

errael

unread,

Sep 29, 2023, 10:47:18 PM9/29/23

to vim/vim, vim-dev ML, Comment

Shades of Java's PECS.

There were two ways to deal with #12965

1. Adjust the parser to meet the spec.

The spec currently states that:

Object methods of the base class can be overruled. The signature (arguments,
argument types and return type) must be exactly the same.

The current implementation doesn't match with this spec.

Right, I mentioned that and one option was to meet the spec. With this change,
even with the rewording of the spec, it can be argued (but not definitively)
that the changed spec is violated. Note the original spec says

Object methods of the base class can be overruled.  The signature (arguments,
argument types and return type) must be exactly the same.  The method of the
base class can be called by prefixing "super.".

The new spec still has the prefixing "super." phrase.

When I read base class can be called by prefixing "super.", in the context
of The signature ... must be exactly the same, it`s easy to interpret this
as meaning, using the current example, that

class Bar extends Foo
  def Doit(p: B): B
    return super.Doit(p)
  enddef
endclass

will compile and run OK. But if covariant and/or contravariant types are used
you'll easily get compile or runtime error, if super. is used in this fashion.

If we follow this spec,
then the type in an overruled method cannot be a covariant or
contra-variant.
I think that will be limiting, as the method in an extended class may want
to return
a covariant type.

I strongly agree that a method may want to return a covariant type.
Nothing in the previous spec (before this change) prevents returning a
covariant type. In fact, in the following example notice the output

object<C>
object<C>

Both Foo.Doit and Bar.Doit return the covariant type C.

vim9script
    
class A
endclass

class B extends A
endclass

class C extends B
endclass
  
class Foo
  def Doit(p: B): B
    return C.new()
  enddef
endclass

class Bar extends Foo
  def Doit(p: B): B
    return C.new()
  enddef
endclass

echo typename(Foo.new().Doit(C.new()))
echo typename(Bar.new().Doit(C.new()))

2. Change the spec and various implementation things.

Doing 1. is backwards compatible with future implementation of the
requested features.
Doing 2. seems rushed.

My first look, not running any code, this change seems to add little, at

the expense of conceptual complexity. I was in the process of manually

working through some things related to this, so I could make a comment,
when it got checked in (seemed pretty quick for a change that wasn't
understood).

Let me know if you see any cases that will break with the latest changs.

What's to rush to add new features that have not been debated?

No rush. I didn't see any objection to the proposal in #12965

And there was no support either; it was not debated. My excuse, not a great one,
is that I was focused on getting 9.1 release to meet spec and uncover any
things that would violate backwards compatibility.

and this is closer to the Dart spec.

So what? The original intent was for simplicity, AFAICT. There was a recent
case, accessing statics, where Dart is simple and was chosen.

In this case, Dart is more complex and doesn't give an advantage, IMHO.
You can already return covariant types with out this change. And adding
contravariant parameter types is confusing and I don't see what it gets you.
I don't see any advantage to making this spec change now, and some disadvantage.
If there's a need, it can be added post 9.1, but not the other way around.

As the changes are minimal to support this, if needed, we can make
adjustments.

—

Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

Ernie Rael

unread,

Sep 30, 2023, 1:15:40 AM9/30/23

to vim...@googlegroups.com

On 23/09/29 6:29 PM, Yegappan Lakshmanan wrote:

I always freak out when I don't see a response I made show up in the
list. So just in case the it wasn't delivered for some reason, there's a
TL;DR response at

https://github.com/vim/vim/pull/13221#issuecomment-1741637630

(apologies for the noise if it was delivered)

-ernie

Christian Brabandt

unread,

Sep 30, 2023, 6:55:59 AM9/30/23

to vim...@googlegroups.com

Well, make sure your reply includes the github mailing address, it
should look like this:
reply+XXXXXXXXX...@reply.github.com

and then the reply should go through

Best,
Christian
--
If the girl you love moves in with another guy once, it's more than enough.
Twice, it's much too much. Three times, it's the story of your life.

Ernie Rael

unread,

Sep 30, 2023, 11:25:15 AM9/30/23

to vim...@googlegroups.com

On 23/09/30 3:55 AM, Christian Brabandt wrote:
> On Fr, 29 Sep 2023, Ernie Rael wrote:
>
>>
>> I always freak out when I don't see a response I made show up in the list.
>> So just in case the it wasn't delivered for some reason, there's a TL;DR
>> response at
>>
>> https://github.com/vim/vim/pull/13221#issuecomment-1741637630
>>
>> (apologies for the noise if it was delivered)
> Well, make sure your reply includes the github mailing address, it
> should look like this:
> reply+XXXXXXXXX...@reply.github.com
>
> and then the reply should go through
>
> Best,
> Christian

I wasn't clear, sorry. I posted something at github, and didn't see it
show up in vim_dev; so the other direction. Once and a while stuff I
post on github doesn't make it to vimdev; I haven't noticed a pattern.

-ernie

Christian Brabandt

unread,

Sep 30, 2023, 12:30:36 PM9/30/23

to vim...@googlegroups.com

I have noticed that sometime mails get lost. I don't know why. It might
be google throttleing or github queuing up the mails somehow. At some
time in the past, github delivered a lot of old notifications that
seemed to get lost....

Thanks,
Christian
--
Beauty, n.:
The power by which a woman charms a lover and terrifies a husband.
-- Ambrose Bierce

shane qian

unread,

Oct 1, 2023, 1:12:08 AM10/1/23

to vim...@googlegroups.com

1. to duplicate mails I have said/mail to chrisbra before, perhaps not worthy to forward every github issues/PR/discussion to vim_dev, users may setup `watch` for vim repo in gitgub, then he/she may get lots dup mails and perhaps leading to dead loop if someone reply it I guess.

2. as for this topic itself, have no idea or have not looked into this contra-variant what is for now, but seems you've made OOP of vim9script too much full feature, to me, again I think most users just treat vim9 script is a scripting lang I cannot image how many people would really use it to write lots plugins, most of them just a general user vs not experienced programmers.

--

shane.xb.qian

shane qian

unread,

Oct 1, 2023, 7:43:35 AM10/1/23

to vim...@googlegroups.com

I meant it's a bit not good situation if user setup `watch` for vim repo in github, meanwhile he's in vim_dev group too, then there would forward Pr/issues/discussion from two sources, and that maybe get loop into dead loop if someone replied one of the mail and got confused the source.

one workaround maybe was keeping vim_dev for dev purpose, and github issues/pr/discussion was there stayed just in github.

better solution maybe if there was a way to detect dup mail and not **re-forward** again, but not sure if it was possible?

--

shane.xb.qian

shane qian

unread,

Oct 1, 2023, 8:17:10 AM10/1/23

to vim...@googlegroups.com

and I meant vim9script so far I felt it's good for type-checking and performance, but vim9 class to me I felt a bit burdened, not sure if still a chance to make it be simple to use (use for scripting), still wish that's the goal. @errael @yegappan

--

shane.xb.qian

Yegappan Lakshmanan

unread,

Oct 1, 2023, 9:45:05 AM10/1/23

to vim...@googlegroups.com

Hi,

On Sun, Oct 1, 2023 at 5:17 AM shane qian <shane...@live.com> wrote:

and I meant vim9script so far I felt it's good for type-checking and performance, but vim9 class to me I felt a bit burdened, not sure if still a chance to make it be simple to use (use for scripting), still wish that's the goal. @errael @yegappan

I haven't introduced any fancy OOP features so far. These are the features

that Bram has partially implemented or planned for and were already in

the todo list. These features are basic to any OOP language. Most of the

changes are about fixing bugs, following the specification, making the behavior

similar to the behavior in languages like Dart, Java and TypeScript and making

the type checking strict.

I think using a formal type checking term like "covariance" and "contra-variance"

confuses people to think that we are introducing fancy features. But these are

just terms for describing the type check and not new features. I could have

used "implement appropriate type check for method arguments and return

types in extended classes".

Regards,

Yegappan

shane qian

unread,

Oct 1, 2023, 10:20:26 AM10/1/23

to vim...@googlegroups.com

hi yegappan,

1. first of all, to me the `simple` meant `class` is class like `struct`, I was not like the OOP in vim9script actually, but well that probably would not be accepted by you all now.

2. about the implementation, we've discussed to make class var be default public and only one static keyword. that's another meant `simple`.

3. about the implementation still, now another ticket your proposal class douder methods, that's really something like mixture, if you preferred keyword then how about keyword `new C` for initiation? if you preferred underscore then how about add length()/empty() as another private method? etc.

4. about the `term`, I believe easy way or pre-agreed term before impl and documented it may be better.

--

shane.xb.qian

Yegappan Lakshmanan

unread,

Oct 1, 2023, 10:31:28 AM10/1/23

to vim...@googlegroups.com

On Sun, Oct 1, 2023 at 7:20 AM shane qian <shane...@live.com> wrote:

hi yegappan,

1. first of all, to me the `simple` meant `class` is class like `struct`, I was not like the OOP in vim9script actually, but well that probably would not be accepted by you all now.

Bram didn't intend the Vim9 classes to be simple structus. Please do read the Vim9 class

documentation and the items in the todo.txt file before the recent changes (early august).

2. about the implementation, we've discussed to make class var be default public and only one static keyword. that's another meant `simple`.

You do need to provide access control for object variables. Without that you cannot support

user-defined types. A user-defined type should be able to support private variables and

methods.

3. about the implementation still, now another ticket your proposal class douder methods, that's really something like mixture, if you preferred keyword then how about keyword `new C` for initiation? if you preferred underscore then how about add length()/empty() as another private method? etc.

The difference is that these methods are intended to be called internally by the Vim builtin functions

and not directly by the user and other methods. The goal is to support operations like a built-in

type (e.g. List, Dict, Blob, etc.) for objects. The underscores are used to make it explicit that

these functions are not intended to be directly used.

Regards,

Yegappan

Yegappan Lakshmanan

unread,

Oct 1, 2023, 10:38:24 AM10/1/23

to vim...@googlegroups.com

On Sun, Oct 1, 2023 at 7:20 AM shane qian <shane...@live.com> wrote:

hi yegappan,

4. about the `term`, I believe easy way or pre-agreed term before impl and documented it may be better.

Please look at the list of outstanding Vim9 class items in the todo.txt file:

https://github.com/vim/vim/blob/master/runtime/doc/todo.txt#L124

Look at the outstanding Vim9 class bugs:

https://github.com/vim/vim/issues?q=is%3Aopen+is%3Aissue+label%3Avim9class

Look at the following discussions:

https://github.com/vim/vim/discussions/13041

https://github.com/vim/vim/discussions/13195

https://github.com/vim/vim/discussions/13085

https://github.com/vim/vim/discussions/13069

https://github.com/vim/vim/discussions/13197

What would be more helpful is to test the current implementation and report bugs (if any) and

provide suggestions or patches for implementing the outstanding items.

Regards,

Yegappan

shane qian

unread,

Oct 1, 2023, 11:02:48 AM10/1/23

to vim...@googlegroups.com

1. we may ask core members to vote, if class is just a struct then no all of those arguments. these were all gone. :smile:

2. it was just saying **default** was to be `public`, didn't mean no `private`.

3. if `new()` is accessed only by `new C`, empty()/length() perhaps can be limited to only internal use too.

anyway, let's listen someone else if there were, or I am worried what's the end this OOP of vim9 how it would be easy to use.

// and sorry I am actually not sure why I was joining to argue this too, aha... maybe there no job to bother me. :lol:

--

shane.xb.qian

Ernie Rael

unread,

Oct 1, 2023, 2:06:36 PM10/1/23

to vim...@googlegroups.com

On 23/10/01 6:44 AM, Yegappan Lakshmanan wrote:

Hi,

On Sun, Oct 1, 2023 at 5:17 AM shane qian <shane...@live.com> wrote:

and I meant vim9script so far I felt it's good for type-checking and performance, but vim9 class to me I felt a bit burdened, not sure if still a chance to make it be simple to use (use for scripting), still wish that's the goal. @errael @yegappan

I haven't introduced any fancy OOP features so far. These are the features

that Bram has partially implemented or planned for and were already in

the todo list.

The spec clearly says (said)

Object methods of the base class can be overruled. The signature (arguments,

argument types and return type) must be exactly the same. The method of the

base class can be called by prefixing "super.".

I can't find where Bram partially implemented or planned to allow contravariant parameters. In fact it looks the other way around. See comments https://github.com/vim/vim/pull/13221#issuecomment-1741637630 .

After we've all worked hard to resolve incomplete spec issues (thinking statics) and to get the implementation to meet the spec. This last minute spec change, which doesn't seem to offer any useful functionality and hasn't been discussed or tested, feels ill-conceived.

While this may be something for the future, I see no reason to change the spec now.

These features are basic to any OOP language.

Can you point to a language that doesn't have overloaded methods that allows contravariant parameters? I'm not saying there aren't any (I'm just a country language-lawyer).

[...]

I think using a formal type checking term like "covariance" and "contra-variance"

confuses people to think that we are introducing fancy features. But these are

just terms for describing the type check and not new features.

I don't believe that is accurate regarding contra-variant parameters; that is new. And for returning a covariant type that could already be done without removing the requirement that "the signature ... must be exactly the same".

I could have

used "implement appropriate type check for method arguments and return

types in extended classes".

Regards,

Yegappan

--
--
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 vim_dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAAW7x7%3DEMWHk1FmdAfyuZesgyon8BFeB06GUqxsVMULOpasS_A%40mail.gmail.com.

Ernie Rael

unread,

Oct 1, 2023, 2:24:16 PM10/1/23

to vim...@googlegroups.com

On 23/10/01 8:02 AM, shane qian wrote:

1. we may ask core members to vote, if class is just a struct then no all of those arguments. these were all gone. :smile:

2. it was just saying **default** was to be `public`, didn't mean no `private`.

3. if `new()` is accessed only by `new C`, empty()/length() perhaps can be limited to only internal use too.

I haven't yet looked at the empty()/len() addition; this was in the todo list. I'm guessing this allows the programmer to do

class C...
len(obj_of_type_C)

and get a value defined by the class, could be very handy for a class that is used as a container. Not sure what happens if class didn't define a __len function; guess I'll find out.

What I don't understand is why these spec changes are needed at the last minute. Seems better to add them after 9.1 is released.

Unless the idea is to wait several months to shake out these new additions. Something being in the todo list does not always imply it gets into a release. Unless it's a simple change, I'd think that stuff would go in at the beginning of the release cycle and not the end.

-ernie

anyway, let's listen someone else if there were, or I am worried what's the end this OOP of vim9 how it would be easy to use.

// and sorry I am actually not sure why I was joining to argue this too, aha... maybe there no job to bother me. :lol:

--

shane.xb.qian

--
--
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 vim_dev+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/OS3P286MB0913D94F71C3B843152D4D72EBC6A%40OS3P286MB0913.JPNP286.PROD.OUTLOOK.COM.

Yegappan Lakshmanan

unread,

Oct 1, 2023, 5:56:59 PM10/1/23

to vim...@googlegroups.com

On Sun, Oct 1, 2023 at 11:06 AM Ernie Rael <err...@raelity.com> wrote:

On 23/10/01 6:44 AM, Yegappan Lakshmanan wrote:

Hi,

On Sun, Oct 1, 2023 at 5:17 AM shane qian <shane...@live.com> wrote:

and I meant vim9script so far I felt it's good for type-checking and performance, but vim9 class to me I felt a bit burdened, not sure if still a chance to make it be simple to use (use for scripting), still wish that's the goal. @errael @yegappan

I haven't introduced any fancy OOP features so far. These are the features

that Bram has partially implemented or planned for and were already in

the todo list.

The spec clearly says (said)

Object methods of the base class can be overruled. The signature (arguments,
argument types and return type) must be exactly the same. The method of the
base class can be called by prefixing "super.".

I can't find where Bram partially implemented or planned to allow contravariant parameters. In fact it looks the other way around. See comments https://github.com/vim/vim/pull/13221#issuecomment-1741637630 .

After we've all worked hard to resolve incomplete spec issues (thinking statics) and to get the implementation to meet the spec. This last minute spec change, which doesn't seem to offer any useful functionality and hasn't been discussed or tested, feels ill-conceived.

We have two options for the method parameter types. We can either follow the Typescript/Java

specification, which supports covariance for the method parameters or follow the Dart specification

which supports contra-variance for the method parameters. As we are already following the Dart

specification for interfaces, I choose the Dart specification.

While this may be something for the future, I see no reason to change the spec now.

These features are basic to any OOP language.

Can you point to a language that doesn't have overloaded methods that allows contravariant parameters? I'm not saying there aren't any (I'm just a country language-lawyer).

Are you referring to covariant parameters here? If you are, then Dart allows only contravariant parameters

for overloaded methods.

Regards,

Yegappan

Yegappan Lakshmanan

unread,

Oct 1, 2023, 6:01:00 PM10/1/23

to vim...@googlegroups.com

On Sun, Oct 1, 2023 at 11:24 AM Ernie Rael <err...@raelity.com> wrote:

On 23/10/01 8:02 AM, shane qian wrote:

1. we may ask core members to vote, if class is just a struct then no all of those arguments. these were all gone. :smile:

2. it was just saying **default** was to be `public`, didn't mean no `private`.

3. if `new()` is accessed only by `new C`, empty()/length() perhaps can be limited to only internal use too.

I haven't yet looked at the empty()/len() addition; this was in the todo list. I'm guessing this allows the programmer to do

class C...
len(obj_of_type_C)

and get a value defined by the class, could be very handy for a class that is used as a container. Not sure what happens if class didn't define a __len function; guess I'll find out.

What I don't understand is why these spec changes are needed at the last minute. Seems better to add them after 9.1 is released.

If we decide to use "__" for these methods in a future release, then we need to reserve them now.

As the changes are small, instead of just reserving the "__" prefix for now, I went ahead with the

implementation.

- Yegappan

Ernie Rael

unread,

Oct 1, 2023, 7:16:16 PM10/1/23

to vim...@googlegroups.com

On 23/10/01 2:56 PM, Yegappan Lakshmanan wrote:

On Sun, Oct 1, 2023 at 11:06 AM Ernie Rael <err...@raelity.com> wrote:

On 23/10/01 6:44 AM, Yegappan Lakshmanan wrote:

Hi,

On Sun, Oct 1, 2023 at 5:17 AM shane qian <shane...@live.com> wrote:

and I meant vim9script so far I felt it's good for type-checking and performance, but vim9 class to me I felt a bit burdened, not sure if still a chance to make it be simple to use (use for scripting), still wish that's the goal. @errael @yegappan

I haven't introduced any fancy OOP features so far. These are the features

that Bram has partially implemented or planned for and were already in

the todo list.

The spec clearly says (said)

Object methods of the base class can be overruled. The signature (arguments,
argument types and return type) must be exactly the same. The method of the
base class can be called by prefixing "super.".

I can't find where Bram partially implemented or planned to allow contravariant parameters. In fact it looks the other way around. See comments https://github.com/vim/vim/pull/13221#issuecomment-1741637630 .

After we've all worked hard to resolve incomplete spec issues (thinking statics) and to get the implementation to meet the spec. This last minute spec change, which doesn't seem to offer any useful functionality and hasn't been discussed or tested, feels ill-conceived.

We have two options for the method parameter types.

Actually, we have three options. We could follow the original spec which is invariant parameters: The signature [...] must be exactly the same.

I've been repeating myself. But I still have not seen any answer as to why the spec, invariant parameters, should be changed rather than simply enforcing the spec for vim9.1, and revisiting
the issue at some future point. I'd be interested in seeing a real world example that makes this
change worthwhile.

To be clear, if a method signature says "def Foo(): return A", that doesn't mean that a subclass of A can't be returned from Foo().

We can either follow the Typescript/Java

specification, which supports covariance for the method parameters or follow the Dart specification

which supports contra-variance for the method parameters. As we are already following the Dart

specification for interfaces, I choose the Dart specification.

So what if we chose Dart for one thing. There are some cases where other languages are followed, the idea is to pick something consistent with the vim9script design philosophy. I do not understand why change the spec for a confusing concept. I've only seen contravariant parameters in relationship to generics, for example

In the common case of a generic data structure ilist, covariant parameters are used for methods getting data out of the structure, and contravariant parameters for methods putting data into the structure. the mnemonic for Producer Extends, Consumer Super (PECS), from the book Effective Java by Joshua Bloch gives an easy way to remember when to use covariance and contravariance.

But in our case we are not talking about a generic data structures. And no matter what words you use to describe it, it is not a simple concept. I still review PECS when I design a Java generic class/method. IIRC, generics are on the vim9class todo list; that's probably the proper time to consider contravariant parameters.

-ernie

While this may be something for the future, I see no reason to change the spec now.

These features are basic to any OOP language.

Can you point to a language that doesn't have overloaded methods that allows contravariant parameters? I'm not saying there aren't any (I'm just a country language-lawyer).

Are you referring to covariant parameters here? If you are, then Dart allows only contravariant parameters

for overloaded methods.

Regards,

Yegappan

[...]

I think using a formal type checking term like "covariance" and "contra-variance"

confuses people to think that we are introducing fancy features. But these are

just terms for describing the type check and not new features.

I don't believe that is accurate regarding contra-variant parameters; that is new. And for returning a covariant type that could already be done without removing the requirement that "the signature ... must be exactly the same".

I could have

used "implement appropriate type check for method arguments and return

types in extended classes".

--

--
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 vim_dev+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAAW7x7mPtLqJsD0w8a%3DODLj5V%3Dj4-OZ__TPbkC90AXz%3D5byNrw%40mail.gmail.com.

Yegappan Lakshmanan

unread,

Oct 1, 2023, 8:23:34 PM10/1/23

to vim...@googlegroups.com

On Sun, Oct 1, 2023 at 4:16 PM Ernie Rael <err...@raelity.com> wrote:

On 23/10/01 2:56 PM, Yegappan Lakshmanan wrote:

On Sun, Oct 1, 2023 at 11:06 AM Ernie Rael <err...@raelity.com> wrote:

On 23/10/01 6:44 AM, Yegappan Lakshmanan wrote:

Hi,

On Sun, Oct 1, 2023 at 5:17 AM shane qian <shane...@live.com> wrote:

and I meant vim9script so far I felt it's good for type-checking and performance, but vim9 class to me I felt a bit burdened, not sure if still a chance to make it be simple to use (use for scripting), still wish that's the goal. @errael @yegappan

I haven't introduced any fancy OOP features so far. These are the features

that Bram has partially implemented or planned for and were already in

the todo list.

The spec clearly says (said)

Object methods of the base class can be overruled. The signature (arguments,
argument types and return type) must be exactly the same. The method of the
base class can be called by prefixing "super.".

I can't find where Bram partially implemented or planned to allow contravariant parameters. In fact it looks the other way around. See comments https://github.com/vim/vim/pull/13221#issuecomment-1741637630 .

After we've all worked hard to resolve incomplete spec issues (thinking statics) and to get the implementation to meet the spec. This last minute spec change, which doesn't seem to offer any useful functionality and hasn't been discussed or tested, feels ill-conceived.

We have two options for the method parameter types.

Actually, we have three options. We could follow the original spec which is invariant parameters: The signature [...] must be exactly the same.

I've been repeating myself. But I still have not seen any answer as to why the spec, invariant parameters, should be changed rather than simply enforcing the spec for vim9.1, and revisiting
the issue at some future point. I'd be interested in seeing a real world example that makes this
change worthwhile.

I have created PR https://github.com/vim/vim/pull/13248 to use invariant type check instead

of contra-variant type check for the derived method argument type checks. We can revisit

this type check later.

- Yegappan

dkearns

unread,

Oct 3, 2023, 11:57:53 AM10/3/23

to vim/vim, vim-dev ML, Comment

Is that really three variations of variance in about as many days? I can't keep up.

This is a foundational principle of OOP. If we can't start from a common understanding of reality these threads aren't very useful.

Referencing other languages is becoming counter-productive. I've also done this in past discussions because Bram had done so in the documentation and as a short-hand but it's becoming distracting. Dart, in isolation, is not relevant here; it's not a pioneer of contravariance.

However, for general reference, TypeScript supports bivariance with a compiler flag for strict contravariance and Dart supports contravariance with a keyword for covariance. The following languages, OTTOMH, all support contravariance - Python, PHP, Kotlin, Scala, Swift, Flow and others. Java doesn't support it, presumably because it doesn't play nicely with their overloading implementation.

I'm not sure what parallel there is with the static members implementation and discussion. The initial implementation was "weird" and it was made sane. The functionality wasn't hobbled in some nebulous pursuit of simplicity. This latest change makes the type system less expressive. Given the state of play has existed for forty years I'm not sure what is going to be illuminated by deferring a decision.

Anyway, my initial report was primarily interested in having the unsound covariance resolved which it has been, thanks.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

errael

unread,

Oct 3, 2023, 2:19:48 PM10/3/23

to vim/vim, vim-dev ML, Comment

Is that really three variations of variance in about as many days? I can't keep up.

This is a foundational principle of OOP. If we can't start from a common understanding of reality these threads aren't very useful.

Yes and Yes. Hopefully we're just talking about implementation issues.

Referencing other languages is becoming counter-productive. I've also done this in past discussions because Bram had done so in the documentation and as a short-hand but it's becoming distracting. Dart, in isolation, is not relevant here; it's not a pioneer of contravariance.

However, for general reference, TypeScript supports bivariance with a compiler flag for strict contravariance and Dart supports contravariance with a keyword for covariance. The following languages, OTTOMH, all support contravariance - Python, PHP, Kotlin, Scala, Swift, Flow and others. Java doesn't support it, presumably because it doesn't play nicely with their overloading implementation.

I'm not sure what parallel there is with the static members implementation and discussion. The initial implementation was "weird" and it was made sane.

Exactly, the spec was never finished regarding statics, and a sane implementation was required. The point of mentioning that, is that the spec was unfinished and most agreed the implementation was broken.

This discussion, Xvariant behavior, is very different; it's about a spec change. I don't think Bram accidentally wrote, back in February

The signature (arguments, argument types and return type) must be exactly the same.

That sentence now appears twice in the spec. Implementing that in no way constrains future development, AFAICT. In fact, I think it provides maximum flexibility going forward. Less is more.

The functionality wasn't hobbled in some nebulous pursuit of simplicity.

I'm not sure to what this is referring. In general I agree with the implied goal.

This latest change makes the type system less expressive.

True. But, from what I've read, the type system isn't finished. I hope the type system is extended in a well thought out and coordinated fashion, rather than piecemeal (like Java?).

Given the state of play has existed for forty years I'm not sure what is going to be illuminated by deferring a decision.

Syntax. You've pointed out that there are several ways the concept can be expressed in a language. And, at least in Java, it's not supported in method signatures at all; but the concept is intimate with Java generics (PECS). The type system needs time and effort, and I would think Xvariance needs to be part of that.

Anyway, my initial report was primarily interested in having the unsound covariance resolved which it has been, thanks.

Agree. When I saw the initial report, I figured another spec violation to fix (and with suggestions for the future); not a new feature at this late date. Personally, I think every spec change requires discussion and burn in time; there are sometimes unintended consequences or implications.

Every time the spec is changed, the release date must be pushed out to insure reliability.

I'd like to see vim9.1 release soon, maybe that's a point of disagreement.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

dkearns

unread,

Oct 9, 2023, 1:25:02 PM10/9/23

to vim/vim, vim-dev ML, Comment

Sorry, I don't think I was notified of this reply but noticed it when checking the history of this general issue. A day late and a dollar short...my usual style.

This discussion, Xvariant behavior, is very different; it's about a spec change. I don't think Bram accidentally wrote, back in February
The signature (arguments, argument types and return type) must be exactly the same.
That sentence now appears twice in the spec. Implementing that in no way constrains future development, AFAICT. In fact, I think it provides maximum flexibility going forward. Less is more.

In my opinion it's a pre-alpha design/help document covering a first pass partial implementation. We can't divine how this would otherwise have turned out and I think we should just attempt to develop the best language possible. Bram was actually pretty flexible and, for example, reworked closures after the 9.0 release.

The first line of the "spec" states: "NOTE - This is not finished yet, anything can still change! - NOTE"

It's leveraged and ignored at will, and as has come to pass again, it's been changed with the resolution to this issue.

Given the state of play has existed for forty years I'm not sure what is going to be illuminated by deferring a decision.

Syntax. You've pointed out that there are several ways the concept can be expressed in a language. And, at least in Java, it's not supported in method signatures at all; but the concept is intimate with Java generics (PECS). The type system needs time and effort, and I would think Xvariance needs to be part of that.

I wasn't proposing any syntax changes. This is a simple type-checking.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you commented.

errael

unread,

Oct 9, 2023, 3:27:02 PM10/9/23

to vim/vim, vim-dev ML, Comment

In my opinion [the spec is] a pre-alpha

I'm not sure I'd go that far, I could see alpha, if you think of the eventual vim9.1 release as a beta, then anything implemented in the release should be beta. Haven't heard much about release targets lately (maybe some implicit hints). But I've also hear that vim9.1 class code is supposed to be compatible with the releases after that; I don't see how that's reconciled with an alpha or beta spec (for what's implemented).

we should just attempt to develop the best language possible

I agree. I guess the basic question/issue is whether or not we can release something that is compatible with future releases.

Given the state of play has existed for forty years I'm not sure what is going to be illuminated by deferring a decision.

Syntax. You've pointed out that there are several ways the concept can be expressed in a language. And, at least in Java, it's not supported in method signatures at all; but the concept is intimate with Java generics (PECS). The type system needs time and effort, and I would think Xvariance needs to be part of that.

I wasn't proposing any syntax changes. This is a simple type-checking.

What I meant by that, assuming there's evolution in the type system, is that for specifying contra-variant parameters it may be desirable to have some syntax. I think some language uses in:/out: for example (reminds me of Java's extends/super).

Saying that parameters can be contra-variant feels like a big change that could cause problems. And it would be good to know how the type system works with future stuff, there's generics in the todo list. Unless someone can say with confidence that "there's no problems and it all work" with suggestions on how it fits in with future development... If a vim9.1 release can be delayed, I'm not sure for how long, then these questions could probably be resolved before it's released.

I'm not saying contra-variant parameters shouldn't be handled. I'm asking if they need to be handled right now? What's the downside if they are not?