Continuing the conversation from the GitHub issue… lexer.l and parser.y will get you the syntax, but not the semantics.

As a trivial example, you mention cylinder(10,100,100).  What do those numbers mean? That information is in primitives.cc, in built in_cylinder().  But how many sides will the cylinder have? That’s in src/utils/calc.cc, in Calc:: get_fragments_from_r(). And which way do the vertexes point? That’s back in primitives.cc, in generate_circle().

OK, so you have to have an adequate library.  But surely the language is easy enough, right?

Consider the following.  What will it print?

a = “a1”;
$b = “b1”;
module foo() echo(a=a, $b=$b);
if (true) {
a = “a2”;
$b = “b2”;
foo();
}

Prints
a=“a1”, $b=“b2”
“a” is lexically scoped, scoped based on the textual structure of the program.  “$b”, on the other hand, is dynamically scoped, scoped by the call structure.

Or:

i = 1;
if (true) {
echo(i);
i = i + 1;
}
echo(i);

First, it will print a 2.  In a particular scope, OpenSCAD will execute all assignments and then all module invocations, and echo() is a module invocation. Then it will print a 1, because the “if” creates a new scope. In that scope the original “i” is visible until the 2 is assigned to a new “i”. At the end of the scope that new “i” disappears, revealing the original “i”.  Some of those semantics are in parser.y, in the actions, while other parts are not.

And there’s a lot more where those came from.

Do real OpenSCAD programs do this sort of thing? Depend on the orientation of a cylinder’s vertexes? Sure. Do tricks with $ variables? More than you can believe.  Do strange things with scoping and execution order? Mostly no.  But sometimes?

Implementing the lexical analysis and the parser, or extracting the AST from OpenSCAD somehow, plus obvious implementations of primitives, will get you a modest fraction of OpenSCAD programs.  Driving that fraction up will take a lot more.

—-

Marius suggests working from a CSG export. That will indeed get you past most of the semantics, since it avoids annoying stuff like variables, expressions, conditionals, modules, and so on.  However, it will lose all semantic information about how the model is constructed.

for(i = [1:10]) translate([i*10,0,0]) cube(i);

will generate ten cubes with particular size and position relationships to one another. The CSG export will have those ten cubes and their positions, of course, but will have nothing about why they are at those sizes and positions - just the positions and sizes.  Want spheres instead of cubes? A one-word change to the OpenSCAD; a ten-word change to the CSG. Want them spaced 20 apart instead of 10? Trivial in the original, less so in the CSG.

If all you want is an export of the resulting model, CSG is good.  (Give or take stuff about vertex orientation.) But if you want a program with the same inputs, algorithms, and outputs, it’s not helpful.

There are OpenSCAD models where the two are nearly the same, but my guess is very few, and rarely if ever complex ones.

Dear Jordan,

Thank you very much for your comprehensive response.

Overall, the task of converting OpenSCAD scripts to CadQuery scripts seems quite formidable. However, considering the countless engineers who have successfully converted various languages to JavaScript or wasm, it appears that those were non-trivial tasks as well. I believe we can manually explore this further to understand the complexities involved, and then determine the best approach.

I have quoted the most relevant content below.
> Implementing the lexical analysis and the parser, or extracting the AST from OpenSCAD somehow, plus obvious implementations of primitives, > will get you a modest fraction of OpenSCAD programs.  Driving that fraction up will take a lot more.
> If all you want is an export of the resulting model, CSG is good.  (Give or take stuff about vertex orientation.) But if you want a >program with the same inputs, algorithms, and outputs, it’s not helpful.

Best regards,
Youbao

> -----Original Messages-----
> From: "Jordan Brown via Discuss" discuss@lists.openscad.org
> Sent Time: 2025-02-09 10:19:15 (Sunday)
> To: discuss@lists.openscad.org
> Cc: 张友宝 zhangyoubao@siom.ac.cn, discuss@lists.openscad.org, "Jordan Brown" openscad@jordan.maileater.net
> Subject: [OpenSCAD] Re: About Automatically Translating OpenSCAD Scripting Code into CadQuery Scripting Code (Python Code)
>
> Continuing the conversation from the GitHub issue… lexer.l and parser.y will get you the syntax, but not the semantics.
>
> As a trivial example, you mention cylinder(10,100,100).  What do those numbers mean? That information is in primitives.cc, in built in_cylinder().  But how many sides will the cylinder have? That’s in src/utils/calc.cc, in Calc:: get_fragments_from_r(). And which way do the vertexes point? That’s back in primitives.cc, in generate_circle().
>
> OK, so you have to have an adequate library.  But surely the language is easy enough, right?
>
> Consider the following.  What will it print?
>
> a = “a1”;
> $b = “b1”;
> module foo() echo(a=a, $b=$b);
> if (true) {
>    a = “a2”;
>    $b = “b2”;
>    foo();
> }
>
> Prints
>    a=“a1”, $b=“b2”
> “a” is lexically scoped, scoped based on the textual structure of the program.  “$b”, on the other hand, is dynamically scoped, scoped by the call structure.
>
> Or:
>
> i = 1;
> if (true) {
>    echo(i);
>    i = i + 1;
> }
> echo(i);
>
> First, it will print a 2.  In a particular scope, OpenSCAD will execute all assignments and then all module invocations, and echo() is a module invocation. Then it will print a 1, because the “if” creates a new scope. In that scope the original “i” is visible until the 2 is assigned to a new “i”. At the end of the scope that new “i” disappears, revealing the original “i”.  Some of those semantics are in parser.y, in the actions, while other parts are not.
>
> And there’s a lot more where those came from.
>
> Do real OpenSCAD programs do this sort of thing? Depend on the orientation of a cylinder’s vertexes? Sure. Do tricks with $ variables? More than you can believe.  Do strange things with scoping and execution order? Mostly no.  But sometimes?
>
> Implementing the lexical analysis and the parser, or extracting the AST from OpenSCAD somehow, plus obvious implementations of primitives, will get you a modest fraction of OpenSCAD programs.  Driving that fraction up will take a lot more.
>
> —-
>
> Marius suggests working from a CSG export. That will indeed get you past most of the semantics, since it avoids annoying stuff like variables, expressions, conditionals, modules, and so on.  However, it will lose all semantic information about how the model is constructed.
>
> for(i = [1:10]) translate([i*10,0,0]) cube(i);
>
> will generate ten cubes with particular size and position relationships to one another. The CSG export will have those ten cubes and their positions, of course, but will have nothing about why they are at those sizes and positions - just the positions and sizes.  Want spheres instead of cubes? A one-word change to the OpenSCAD; a ten-word change to the CSG. Want them spaced 20 apart instead of 10? Trivial in the original, less so in the CSG.
>
> If all you want is an export of the resulting model, CSG is good.  (Give or take stuff about vertex orientation.) But if you want a program with the same inputs, algorithms, and outputs, it’s not helpful.
>
> There are OpenSCAD models where the two are nearly the same, but my guess is very few, and rarely if ever complex ones.
>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
/openscad@jordan.maileater.net/zhangyoubao@siom.ac.cn/discuss@lists.openscad.org