[vim/vim] Add support for generic class, interfaces, etc. (PR #18910)
Yegappan Lakshmanan
This is a work in progress. Extending a generic class or interface is not yet supported.
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/18910
Commit Summary
- 2a4f394 Add support for generic class, interfaces, etc.
File Changes
(21 files)
- M src/errors.h (20)
- M src/eval.c (71)
- M src/evalvars.c (23)
- M src/proto/userfunc.pro (2)
- M src/proto/vim9class.pro (5)
- M src/proto/vim9expr.pro (2)
- M src/proto/vim9generics.pro (12)
- M src/proto/vim9type.pro (2)
- M src/structs.h (9)
- M src/testdir/Make_all.mak (2)
- A src/testdir/test_vim9_generic_class.vim (1041)
- M src/testdir/test_vim9_generics.vim (121)
- M src/userfunc.c (43)
- M src/vim9class.c (1055)
- M src/vim9cmds.c (2)
- M src/vim9compile.c (9)
- M src/vim9execute.c (3)
- M src/vim9expr.c (62)
- M src/vim9generics.c (84)
- M src/vim9script.c (2)
- M src/vim9type.c (62)
Patch Links:
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
@yegappan pushed 1 commit.
- 4b7d38f Use a different viarable name for gfatab
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
Aliaksei Budavei
zzzyxwvut left a comment (vim/vim#18910)Thank you.
This is a much-desired language feature and a much-welcome
complement to generic functions, as it offers a much greater
degree of expressiveness for type abstraction.
I have been toying with builds from this PR for some time.
A couple things don't yet work (#4d7545):
- Many-parameter parameterised types cannot be currently
used in LHS of variable declarations and as type
arguments.
example_a.vim
vim9script class Single<T> final X: T def new(this.X) enddef def ToTuple(): tuple<T, ...list<any>> return (this.X, ) enddef endclass class Pair<T, U> extends Single<T> final Y: U def new(this.X, this.Y) enddef def ToTuple(): tuple<T, U, ...list<any>> return (this.X, this.Y) enddef endclass def OneTuple<T>(X: T): tuple<T> return (X, ) enddef def TwoTuple<T, U>(X: T, Y: U): tuple<T, U> return (X, Y) enddef var s1: Single<number> = Single<number>.new(1) echo 1 == s1.X const s2: tuple<Single<Single<number>>> = OneTuple<Single<Single<number>>>( Single<Single<number>>.new( Single<number>.new(1))) echo 1 == s2[0].X.X type NumberNumberPair = Pair<number, number> #### FIXME: E488 try var p: Pair<number, number> = Pair<number, number>.new(1, 2) echo 3 == p.X + p.Y catch /\<E488:/ echo v:exception var p: NumberNumberPair = Pair<number, number>.new(1, 2) echo 3 == p.X + p.Y endtry #### FIXME: E15 try echo Pair<Pair<number, number>, Pair<number, number>>.new( Pair<number, number>.new(1, 2), Pair<number, number>.new(1, 2)).X catch /\<E15:/ echo v:exception echo (1, 2) == Pair<NumberNumberPair, NumberNumberPair>.new( Pair<number, number>.new(1, 2), Pair<number, number>.new(1, 2)).X.ToTuple() endtry try echo TwoTuple<Pair<number, number>, Pair<number, number>>( Pair<number, number>.new(1, 2), Pair<number, number>.new(1, 2)).X catch /\<E15:/ echo v:exception echo (1, 2) == TwoTuple<NumberNumberPair, NumberNumberPair>( Pair<number, number>.new(1, 2), Pair<number, number>.new(1, 2))[0].ToTuple() endtry
- Type variables are allowed in signatures of builtin object
methods (akaempty,len, andstring):
example_b.vim
vim9script class String final _value: string def new(this._value) enddef def string(): string return this._value enddef endclass class Box<T> final _value: T def new(this._value) enddef # FIXME: Wrong signature! def string(): T return this._value enddef # FIXME: Wrong signature! def len(): T return this._value enddef # FIXME: Wrong signature! def empty(): T return this._value enddef endclass echo Box<String>.new(String.new('hello')).len() echo Box<String>.new(String.new('hello')).empty() echo Box<String>.new(String.new('hello')).string() # FIXME: Possibly see garbage and (possibly delayed) SEGV. echo Box<String>.new(String.new('hello'))
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
yegappan left a comment (vim/vim#18910)Thank you.
This is a much-desired language feature and a much-welcome complement to generic functions, as it offers a much greater degree of expressiveness for type abstraction.
I have been toying with builds from this PR for some time. A couple things don't yet work (#4d7545):
Thanks for trying out the PR and reporting the problems. This helps a lot.
- Type variables are allowed in signatures of builtin object
methods (akaempty,len, andstring):
I have fixed this issue in the latest updated PR. I will look into the first issue.
Thanks,
Yegappan
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
yegappan left a comment (vim/vim#18910)Thank you.
This is a much-desired language feature and a much-welcome complement to generic functions, as it offers a much greater degree of expressiveness for type abstraction.
I have been toying with builds from this PR for some time. A couple things don't yet work (#4d7545):Thanks for trying out the PR and reporting the problems. This helps a lot.
- Type variables are allowed in signatures of builtin object
methods (akaempty,len, andstring):I have fixed this issue in the latest updated PR. I will look into the first issue.
@zzzyxwvut: The latest updated PR addresses the issue seen with the code in example_a.vim.
Can you try the latest PR?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Aliaksei Budavei
zzzyxwvut left a comment (vim/vim#18910)Thank you for addressing the reported shortcomings.
Recursive generic type declarations are currently rejected:
example_c.vim
vim9script interface Copiable<T> var value: T #### FIXME: E1010 def Copy(): Copiable<T> endinterface class NumRef implements Copiable<number> const value: number def new(this.value) enddef # Assume return value covariance. def Copy(): NumRef return NumRef.new(this.value) enddef endclass class StrRef implements Copiable<string> const value: string def new(this.value) enddef def Copy(): Copiable<string> return StrRef.new(this.value) enddef endclass echo 0 == NumRef.new(0).Copy().value echo "" == StrRef.new("").Copy().value
I understand that type variance is still being researched;
I can't find any related test cases.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Aliaksei Budavei
zzzyxwvut left a comment (vim/vim#18910)There is a general limitation in not permitting the use of
type variables with parameterised return types and object
variable types (cf. the previously reported issue about
recursive generic types.)
example_d.vim
vim9script class Ref<T> var x: T
endclass class Pair<T, U>
# FIXME: E1010
static def Make<A, B>(X: A, Y: B): Pair<A, B>
return Pair<A, B>.new(X, Y)
enddef
# FIXME: E1010
def Copy(): Pair<T, U>
return Pair<T, U>.new(this.X, this.Y)
enddef
def new(this.X, this.Y)
enddef
public const X: T
public const Y: U
endclass
# FIXME: E1012
var p: Pair<bool, bool> = Pair<bool, bool>.Make<bool, bool>(true, false)
# FIXME: E1570
echo Pair<bool, bool>.Make<bool, bool>(false, true).Copy()
interface RefRef<T>
# FIXME: E1010
var x: Ref<T>
endinterface
# FIXME: E1010
def MakeRef<T>(): Ref<T>
return Ref<T>.new()
enddef—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
