This ticket is for tracking ideas for the next full release of Kuroko.
1.0 was essentially a demo, the first version of Kuroko as a viable language built from the core of Crafting Interpreters. 1.1 is intended to be a "real" release - one with a production-ready release process, "complete" standard library, and stable ABI/API for extension developers and embedders.
[ ] Standard library improvements:
[ ] subprocess module, etc. (can we do this in managed code around the os module?)
[x] Complete os coverage (what's still missing that we need? We have the exec family, fork, ...)
[x] Add class decorators (bim syntax files would really like to have this)
[x] Threading? Or maybe that's best left way on the backlog for "2.0".I actually sat down and did this, though it's still missing locks in a lot of places and is only known to work on Linux...
[x] Persist module bytecode with a marshaling format. Bytecode itself can be directly saved; function constants tables are a bit trickier. Format stability is not important, but we should be able to write once and then read from future runs of the same interpreter version like Python does with 'pyc' files. This is experimental, but a functional demonstration is provided in 1.1
[x] Add docstring bindings for everything in the standard library. (__builtins__ still needs full coverage of types)
[x] Build tools for turning docstring docs into usable HTML documentation, like Sphinx does.
[x] Complete C API documentation, follow a standard like Doxygen, add build tools for it.
[ ] Prose docs for embedding and extending, building from source, something like the Python Tutorial.
[ ] Rewrite/reorganize headers:
[ ] C library users should only need to include <kuroko/kuroko.h> and not separate headers.
[x] Library sources should also be including things like <kuroko/kuroko.h> instead of "kuroko.h"
Need a "config.h" to hold build-time settings like whether threads are enabled, as they affect struct definitions. This is still a problem, but not as much as it was...
[ ] Add an autotools-like configure script so we can stop worrying about weirdness when building for win32? Maybe also integrate some of the WASM build scripts into that...
[x] Make class fields work like in Python / eliminate the "fields"/"methods" split?
[x] Implement multiple inheritance, runtime attribute lookup ordering? Not doing multiple inheritance now or ever, but maybe mixins will show up at some point.
[x] Type hinting annotations
[x] On module-level let declarations
[x] In function signatures
[x] On class attributes
Deferred to 1.2
Rewrite the compiler to build an AST so we can reasonably implement things like multiple assignment, real tuple syntax, etc.
Clean up cruft from Crafting Interpreters that no longer makes sense in modern Kuroko:
Merge "chunks" and "functions" as there is a 1:1 relationship between the two.
Call the result "code objects" like Python does?Done!
"Functions" vs "Closures" makes little sense in the C API.Partially done
Fix all those IS_TYPE / AS_TYPE macros to use the format from util.h with actual type names.
Eliminate object.c and move things into their obj_ sources (and all the common stuff into memory.c? which should probably be renamed gc.c?)
Cancelled
Write an ARCHITECTURE.md with a prose description of how everything meshes together. We have a website, with extensive documentation, it describes the architecture of the compiler.
Make the compiler fully re-entrant. There were speed concerns with making the VM re-entrant as means of supporting threading, but this is not the case with the compiler, so we can definitely have a top-level state we chain down to everything... A complete compiler rewrite with an AST is planned for 1.2, so I'm not going to waste my time with this right now.
Consider whether basic value types should be nixed and moved to objects. Even Python has its integers and such as objects, and it would allow us to reduce stack references to just pointers, halving (or more) their size. Having a single path for type checking might also improve performance.Followup: This was tried and it improved some cases and destroyed some others. Not really sure if it's worthwhile unless we want everything to have fields, like in Python.
This ticket is for tracking ideas for the next full release of Kuroko.
1.0 was essentially a demo, the first version of Kuroko as a viable language built from the core of Crafting Interpreters. 1.1 is intended to be a "real" release - one with a production-ready release process, "complete" standard library, and stable ABI/API for extension developers and embedders.
subprocessmodule, etc. (can we do this in managed code around theosmodule?)oscoverage (what's still missing that we need? We have the exec family, fork, ...)socketmodulehttp.server;requestsimplementation?)codecsimplementationvm.cand use macros from bim development branch.strmethods:replace,startswith,endswith,find/indexisalpha(etc.); support other sequences injoinindex,count,clear,copy,remove,reversedelon slicesclear,copy,get,setdefault,updatesetinto C coreOr maybe that's best left way on the backlog for "2.0".I actually sat down and did this, though it's still missing locks in a lot of places and is only known to work on Linux...__builtins__still needs full coverage of types)<kuroko/kuroko.h>and not separate headers.<kuroko/kuroko.h>instead of"kuroko.h"Need a "config.h" to hold build-time settings like whether threads are enabled, as they affect struct definitions.This is still a problem, but not as much as it was...configurescript so we can stop worrying about weirdness when building for win32? Maybe also integrate some of the WASM build scripts into that...multiple inheritance, runtime attribute lookup ordering? Not doing multiple inheritance now or ever, but maybe mixins will show up at some point.letdeclarationsDeferred to 1.2
multiple assignment, real tuple syntax, etc.Call the result "code objects" like Python does?Done!"Functions" vs "Closures" makes little sense in the C API.Partially doneIS_TYPE/AS_TYPEmacros to use the format fromutil.hwith actual type names.object.cand move things into theirobj_sources (and all the common stuff intomemory.c? which should probably be renamedgc.c?)Cancelled
Write anWe have a website, with extensive documentation, it describes the architecture of the compiler.ARCHITECTURE.mdwith a prose description of how everything meshes together.Make the compiler fully re-entrant. There were speed concerns with making the VM re-entrant as means of supporting threading, but this is not the case with the compiler, so we can definitely have a top-level state we chain down to everything...A complete compiler rewrite with an AST is planned for 1.2, so I'm not going to waste my time with this right now.Consider whether basic value types should be nixed and moved to objects. Even Python has its integers and such as objects, and it would allow us to reduce stack references to just pointers, halving (or more) their size. Having a single path for type checking might also improve performance.Followup: This was tried and it improved some cases and destroyed some others. Not really sure if it's worthwhile unless we want everything to have fields, like in Python.