Ezno contains a way to represent types (and subsequent other internals) in a binary way. For example the literal type "hello" can be serialized (and stored on disk) as a array of bytes such as [0x01, 0x48, 0x65, 0x6c, 0x6c, 0x6f]. Here 0x01 might point the discriminant/tag of the Type enum and the rest are utf8 (or whatever Rust .as_bytes() representation is).
This is a substitute for .d.ts files and can have the benefits
Represent events and other Ezno specific things(that are more complicated to write in definition files)
Faster
Smaller, trivial parsing
Can be split apart, run in parallel without hoisting (not doing ATM tho)
.d.ts files are still useful and used for non-cached checking and as a way to write definitions (as the binary is not intuitive to write). These files do not have to be generated by library authors or added to package managers etc.
Handling the serialization and deserialization logic is done with the binary-serialize-derive crate (which is currently under this repo, although might be moved in the future if it isn't specific to ezno-checker). It is a procedural macro that generates the logic for Type <-> [u8]
This was implemented a while ago. But got disabled sometime around the release as type information was split between TypeStore and Environment.
This needs to be added back, but needs some thinking and big adjustments before
Function types can reference positions of parameters. If it is split from definition files then there needs to be be a way to reference positions in the existing definition files. Not sure how that works with the current SourceId and source_map::filesystem setup. Maybe need to also store information from the filesystem from checking
kaleidawave
commented
4 months ago
Ezno contains a way to represent types (and subsequent other internals) in a binary way. For example the literal type
"hello"can be serialized (and stored on disk) as a array of bytes such as[0x01, 0x48, 0x65, 0x6c, 0x6c, 0x6f]. Here0x01might point the discriminant/tag of theTypeenum and the rest are utf8 (or whatever Rust.as_bytes()representation is).This is a substitute for
.d.tsfiles and can have the benefits.d.tsfiles are still useful and used for non-cached checking and as a way to write definitions (as the binary is not intuitive to write). These files do not have to be generated by library authors or added to package managers etc.Handling the serialization and deserialization logic is done with the binary-serialize-derive crate (which is currently under this repo, although might be moved in the future if it isn't specific to
ezno-checker). It is a procedural macro that generates the logic forType <-> [u8]This was implemented a while ago. But got disabled sometime around the release as type information was split between
TypeStoreandEnvironment.This needs to be added back, but needs some thinking and big adjustments before
SourceIdandsource_map::filesystemsetup. Maybe need to also store information from the filesystem from checking