cse-machine-version py-slang independent from js-slang #48
Conversation
|
Can you please let me know which parts specifically you need my review for? For example, I know the entire Additionally, I can't review the conductor parts, as I'm not familiar with those. So I'll trust you implemented them correctly. |
|
Another question. Out of curiosity:
why not run the original Python AST without translation in the cse machine? Is there a specific design choice being made here? |
src/translator.ts
Outdated
| // 你可以复用 "Literal"，也可以用别的 type 标记 | ||
| // 这里保持和 BigInt 的风格一致 | ||
| type: 'Literal', | ||
|
|
||
| // 和 visitBigIntLiteralExpr 类似，这里用一个字段来保存复数内容 | ||
| // 比如把它叫做 "complex" | ||
| // expr.value 是一个 PyComplexNumber, 你可以用 toString(), 或者直接存 real/imag | ||
| complex: { | ||
| real: expr.value.real, | ||
| imag: expr.value.imag | ||
| }, | ||
|
|
||
| // 和其它 literal 一样，加上位置信息 | ||
| loc: this.toEstreeLocation(expr), |
There was a problem hiding this comment.
While I understand this, can the comments be translated to English please? For future students who might not understand Mandarin.
There was a problem hiding this comment.
Apologies for the oversight — I forgot to translate that part into English. Thanks for pointing it out! I’ll update the comments right away.
|
The PR as it currently stands is not possible to be reviewed (it's too big). Can I request that you split it up into smaller PRs by functionality? The |
I think it's because when I first took over the project, there was already an existing pipeline that translated Python code into JavaScript ESTree. To avoid modifying the original structure too much, I discussed with Prof Henz, and decided to build the new features on top of it. Also, I had learned about cse-machine implementation from js-slang, so I thought it would be a good idea to follow a similar approach and implement a Python version of the cse-machine based on the generated ESTree, while preserving Python syntax and semantics. |
Sure. I will split up in modules. I'll start by separating the core cse-machine implementation, then follow up with the built-in functions, followed by the tests and documentation. The dist folder will be committed at the very end, after all reviewable modules are in place. |
and also I think it's not we call "translation in the cse machine". I think what the current cse-machine does is not to translate, but to execute the result of the existing parsePythonToEstreeAst function. The previous logic for converting Python code to ESTree was already quite robust (I later added some enhancements for handling strings and complex numbers), so building an executor on top of the already-translated ESTree made the development process much smoother. |
The original logic of py-slang (main branch) was to convert Python code into JavaScript code and then pass it to js-slang for execution. In the implementation of cse-machine-version branch, I retained the original functionality of generating the ESTree, and based on that, I developed a cse-machine to execute the translated Python program. This pull request represents a significant update — all code related to the cse-machine is newly introduced and did not exist in the original py-slang. In addition, part of the documentation has also ready.
The cse-machine-version branch of py-slang is independent of js-slang. It follows the cse-machine architecture of js-slang and adheres to Source Academy’s Conductor framework (https://github.com/source-academy/conductor), allowing it to run directly on the frontend at sourceacademy.org. The program implements the frontend API through Conductor and, via layered calls with runInContext, eventually passes the user’s input code segment to the evaluator in the interpreter for execution. If the user’s code produces an error, an error message is returned; if the code executes successfully, the evaluator ultimately returns the result produced by the user’s print statements.
This version of py-slang implements built-in functions, including math library functions that conform to Source Chapter 1 and other Python built-in functions. Note that the logic for input, nextafter, and ulp has not yet been implemented. The remaining functions essentially behave like native Python functions, except for some precision differences due to underlying discrepancies between JavaScript and Python implementations. For an introduction to the Python Chapter 1 syntax, please refer to py-slang/docs/python/specs/source_1.pdf; for details on the syntax of the built-in functions, see py-slang/docs/python/python_1/global.html.