Feat/luakittens #7
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Removed require calls to iter (which referenced the same exact file) and replaced them with `M.`.
The partitioning function takes a range and splits it to one satisfying a predicate and one not satisfying a predicate.
This file defines settings for the lua language server. Namely: - Instructs luals to find busted test functions - Instructs luals to find luassert monkey patched assert - Ignores variables starting with _
By marking the `M.__test` files with `---@package` they're not displayed in completion from outside.
The luaKITTENS library is an attempt to redefine a type system in lua. It consists of a parser for parsing luaKITTEN type expressions and a validator which can then take a type and check if it complies with a given kitten. Currently only the parsing part is done and it requires some more polishing as well. The parser is implemented in lpeg, but I will rewrite it to a more sophisticated solution later, which will allow for much better error diagnostics.
Optional nils - `nil?` don't make sense, as `?` is already a shorthand of `T|nil`, which would make it `nil|nil`. I prefer to disallow that in grammar, than sanitize later.
Previously the `parse()` function only returned a single match, but the grammar is defined to return several matches if the alternative grammar is used.
The grammar allows for alternative types, e.g. `string|number|(fn, bool)`. This syntax, however, allows for specifying the same type twice. I haven't found a way to disable that in the syntax itself, so the resulting parse is postprocessed in the end to not carry additional, unnecessary types around.
For now two transformations are being done:
- If `any` is listed as an alternative type, the entire type is turned
into `any`
- If `nil` is listed as one of only two types, we turn the other type
into `T?`, the difference here is that now instead of having
`{ { kind = '...', ... }, { kind = 'fundamental', type = 'nil } }`
we have
`{ { kind = '...', opt = '?' ... } }`
(if you're confused about why `opt` is `?` here instead of `true` -
it's because the AST comes out formed already out of
`vim.lpeg.Pattern.match`. The grammar doesn't allowed to specify a
boolean type there and it doesn't really make sense to rewrite the
grammar
In lua setting a table key to `nil` means deleting it, which means that
having a type like `{ [T]: nil }` or `{ foo: nil }` doesn't make sense
as per lua semantics.
It's hard to model the resulting AST type using luaCATS annotations as they are very much incomplete, still. The syntax is also rapidly changing, so there's no reason to keep around the constantly invalidated annotations around, for now.
`nil`s as keys for tables are also prohibited, so we disable them in the syntax as well :)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The luakittens library is an attempt to redefine the type system and type validation methods in lua.
For now the plans is for it to consist of several parts:
kittyfor shortCurrently only the language and parser are done and tested, mostly. Several things are lacking for now.
There's no specification yet, to discover the language and it's capabilities one would have to look at the
only_parsefunction and__test()->describe('only_parse())This implementation is incomplete and I will be rewriting it to a handwritten parser, which will allow for more fine-grained syntax control and better diagnostics.