[0x00cl]

Hey, I took a look at your project, I'm not someone who deals with schematics or KiCad but I'm still interested in these kind of things. I read the motivations in the docs and understood why would someone try to create a new language after looking at SKiDL, but still feels like it could've been simply a python library/package instead of having to do the work of creating a new language and having to deal with the language and interpreter/compiler. I'm sure a more object oriented approach would have made it a better experience to script schematics, specially with all the tooling Python has (such as `uv` to manage project, `ruff` to lint and format, etc). Regarding your language, just wondering why does led and supply need quotation marks but resistors and capacitors that some not only include numbers such as (10k) don't need to. It feels unnecessary to make that difference, specially for a script that tried to be simpler

[liu3hao]

Hi! Thank you for taking a look at circuitscript! Before creating circuitscript, I did consider using the SKiDL package as a circuit design tool, however even though I am familiar with python, the syntax for things like connecting pins was very strange (using the += operator). Moreover many of the existing code to schematics, including SKiDL, forces the designer to give up the actual layout of the schematic itself. As a electronics designer in my day job, a well organized schematic is very important to understand the overall design. It does not only show connections, but is also a map of the system. A poorly drawn map complicates system understanding and troubleshooting.

I'm not sure how an object oriented approach would make things easier for schematic generation. The objects (components) themselves do not undergo much data interactions/manipulations. Maybe if you have some examples, this would be helpful for me to understand. As much as possible I am leaning towards a more functional approach, where inputs, data transformations and outputs are more defined.

With a new language, I could decide features that I wanted and more importantly, include more circuit specific features (branch/join/parallel statements). Of course, a python library would be able to produce the same data representation that circuitscript ultimately generates, but one aim of circuitscript is to make it much easier to do so.

The standard lib provides led, supply, res and cap as component functions (basically normal functions that return a component). For LED and supply, they take strings as parameters, this defines the led color and the name of the supply net respectively. Res and cap take a number parameter like 1k, 1u, 100n, etc. Such number expressions are very common in schematics and CAD packages, so this is a important feature to support (python equivalent of using 1e3, 1e-6, etc.).