[vim/vim] Language Specification: vim9.1 vim9script freeze (Discussion #13454)
errael
Around the end of August, in the thread "Updates on the Vim project", it was suggested that vim9script needed "one more week and then stop". The primary goal was "make sure that all the Vim9 class changes that may break backward compatibility go in before the Vim 9.1 release". It turned out that vim9script was not as well specified or fully implemented as people thought; of necessity, the time frame got pushed out. In addition a lot of the TODO list was completed.
Can the spec be frozen for vim9.1?
This discussion is for comments and consideration on whether or not vim9.1's vim9script is ready for release.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
errael
I think the vim9script spec for vim9.1 can now support backwards compatibility.
Large projects, using OOP features, can be written to the current vim9.1 spec and continue to work in future releases. And by limiting vim9.1 features, there's maximum flexibility for future language development.
I think there's agreement on the current spec; but, without changing the spec, the document could use some additional info, clarifications, and/or fixes. And the implementation requires some targeted work, for example error checking to insure a type can not be used as a class (a TODO item, see below).
Spec and doc updates and examples
The most recent spec changes/additions would benefit from improved documentation.
:type
Needs doc: atypealiascan be used anywhere the associated type can be used.- Value vs Type - This distinction seems to have general agreement
Is documentation needed to clarify this distinction? Where?
A type, including builtin type,class(user defined type), ortypealiascannot be assigned to a variable or otherwise used as a value. - Any other doc additions/changes/examples that are needed and/or particularly useful?
Implementation
Now with :type fully implemented for user defined types. This TODO item
When "Meta" is a class, is "const MetaAlias = Meta" allowed? It should
either work or given an error. Possibly give an error now and implement it
later (using a typedef). #12006
can be completed by giving an error, also obviates #12961. See reference [1].
Conundrums
There are difficulties created because some language features are actually implemented as builtin functions. In particular, instanceof(), typename(), type() and call() handle types (there may be others). Since types are not values, there must be special considerations for passing a class/typealias to a builtin function as a function parameter. [1] passes type items to builtin functions.
Builtin functions tend to be careful about checking types; but then you get a myriad of function specific error messages when passing a type. The Uniform builtin function argument checking experimental commit, in [1], checks if the called function can handle types and so there's a common error which helps avoid confusion about type vs value (hopefully).
An additional problem is that some builtins (instanceof() and call()) take a list which might include a class/typealias, and a list should only hold values. There are two approaches to dealing with this
- Allow a
class/typealiasas a list item, with extra code to protected that such items do not leak into the program as a value. - Extended, or additional, API for
instanceof()andcall()so that types can be passed as function parameters instead of in a list.
The commit "Modify instanceof() to handle varargs of classes instead of list", in [1], is an example of dealing with (2). For call(), could modify it such that if the 2nd argument is not a list, then the call has varargs and no dictionary (vim9 only). Neither of these hacks is particularly satisfying.
[1] "Prevent class name assign" yegappan#2
—
Reply to this email directly, view it on GitHub,.
You are receiving this because you are subscribed to this thread.
dkearns
Can the spec be frozen for vim9.1?
I sincerely hope not. There's lots of open questions in discussion, issue, and PR comment threads.
—
Reply to this email directly, view it on GitHub,.
You are receiving this because you are subscribed to this thread.
errael
Can the spec be frozen for vim9.1?
I sincerely hope not. There's lots of open questions in discussion, issue, and PR comment threads.
I think I've seen most of the recent comments about issues. I neglected to copy links to them from this issue. Oops.
There's stuff that is not liked by some or that could be done differently,
but I'm not aware of anything that is so egregious that it must be fixed
to avoid backwards compatibility problems; or, just as important (if not more so),
features that should be left out because they hinder future language development.
I've been guided by the last "official" statement on the vim9script requirements for vim9.1.
all the Vim9 class changes that may break backward
compatibility go in before the Vim 9.1 release.
with the caveat about leaving stuff out that might hinder future development.
—
Reply to this email directly, view it on GitHub,.
You are receiving this because you are subscribed to this thread.
errael
Addendum-1 to #13454 (comment)
The following additional possibilities for dealing with the Conundrums have come up recently.
- Use strings to specify classes by name, #13421 (comment).
- In vim9script treat builtin functions that are really part of the language as part of the language.
(2) is probably the best assuming call() doesn't need class in it's arugment list. (1) is OK; but source compatibility isn't important for instanceof() and the list is a hassle; it's minor language weirdness and a hack but with suitable error messages seems not too bad. (3) is OK for instanceof() (other than general dislike), it doesn't work with call(), typename(), type(). Doing (4) is pretty clean, but relatively high development cost (I'm guessing, so maybe not), and there's issues if hardcoded class list is not sufficient.
One of the features of the current scheme is that a list of classes can be built prgrammatically; but is this important. Is it OK to require that the classes to be hardcoded as shown in the following
instanceof(obj, [C1, C2, C3])
It might be more of an issue with call(). But does call() need to work with any builtin when a constructed list has a class in it? I'm beginning to think that there's no requirement for building a list that contains classes in pieces.
—
Reply to this email directly, view it on GitHub,.
You are receiving this because you are subscribed to this thread.
errael
Closed #13454 as outdated.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
errael
I think the time has come...
—
Reply to this email directly, view it on GitHub,.
You are receiving this because you are subscribed to this thread.