Kuroko is essentially an incomplete implementation of Python with some quirks. This issue is intended to track what Kuroko is missing or unintentionally does differently.
[x] Tuples: Are these really any different from lists without mutation? Look into also implementing CPython's freelists for small tuples, which probably requires some GC integration. Syntax support should be fairly straightforward: Detect TOKEN_COMMA in a grouping after an expression and switch to tuple processing.
[x] if statements in comprehensions: Implement as an if branch that pops and decrements the iterator counter if expression is False?
[x] print as a function: OP_PRINT is just a loxism and there's really no reason this couldn't be moved to a native function, including support for the various keyword arguments (end is particularly useful). This can happen right now? (Even inclusive of the string coercion...)
[x] is: We only have == and there are semantic differences between is and ==. Also is not.
[x] Various special methods: __get__/__set__ should be renamed to their Python counterparts of __getitem__/__setitem__, we're missing all of the operator ones (__add__, __eq__, etc.)... Marked done: Some of these aren't the same as in Python, but we have good overall coverage for operators.
[x] Class fields: These are just generally useful for defining fixed members or defaults without an init, and also make nicely namespaced enums and whatnot.
[ ] Standard Library: Throwing this very large task in a single checkbox, but there's a lot of ground to cover even just for the basics.
[x] Line feeds in statements: Inside of parens or brackets, line feeds should be accepted.
[x] pass statement: We accept empty blocks, maybe we shouldn't? Still should have pass either way.
[x] with ... as ...: I think this fairly straightforward? It's a scoping block that introduces a local from an expression. Slap a let on the line before and the typical Python use case makes sense of opening and reading a file into a variable and then closing the file (still need to support files going out of scope correctly closing/freeing, but that's a different issue). Marked done: VM still needs better support for early exceptions.
[x] finally statement: Semantics for this are complicated.
[x] Multiple arbitrary assignments: We can assign to multiple members with special syntax (foo.(a,b,c) = ...) and we can assign multiple variables in a let expression, but assignment to multiple arbitrary assignment targets is tricky without an AST.
[x] async/await
Coroutines in CPython are implemented in essentially the same ways generators, combined with an event loop that handles scheduling them. We have generators, we have real threads to use with to_thread, we should be able to build a compatible implementation of async/await and start pumping out coroutines.
[ ] asyncio module
[x] yield from, yield expressions
[ ] Understand global/nonlocal in functions; global is probably a no-op, non-local may be useful as a static check that enforces resolution as an upvalue?
[ ] Recover the Python-compatible mode in the compiler.
Kuroko is essentially an incomplete implementation of Python with some quirks. This issue is intended to track what Kuroko is missing or unintentionally does differently.
TOKEN_COMMAin a grouping after an expression and switch to tuple processing.ifstatements in comprehensions: Implement as anifbranch that pops and decrements the iterator counter if expression is False?printas a function:OP_PRINTis just a loxism and there's really no reason this couldn't be moved to a native function, including support for the various keyword arguments (endis particularly useful). This can happen right now? (Even inclusive of the string coercion...)is: We only have==and there are semantic differences betweenisand==. Alsois not.__get__/__set__should be renamed to their Python counterparts of__getitem__/__setitem__, we're missing all of the operator ones (__add__,__eq__, etc.)... Marked done: Some of these aren't the same as in Python, but we have good overall coverage for operators.passstatement: We accept empty blocks, maybe we shouldn't? Still should havepasseither way.leton the line before and the typical Python use case makes sense of opening and reading a file into a variable and then closing the file (still need to support files going out of scope correctly closing/freeing, but that's a different issue). Marked done: VM still needs better support for early exceptions.finallystatement: Semantics for this are complicated.foo.(a,b,c) = ...) and we can assign multiple variables in aletexpression, but assignment to multiple arbitrary assignment targets is tricky without an AST.async/awaitCoroutines in CPython are implemented in essentially the same ways generators, combined with an event loop that handles scheduling them. We have generators, we have real threads to use withto_thread, we should be able to build a compatible implementation ofasync/awaitand start pumping out coroutines.asynciomoduleyield from,yieldexpressionsglobal/nonlocalin functions; global is probably a no-op, non-local may be useful as a static check that enforces resolution as an upvalue?