I am sorry, maybe I even don't understand how it would all work together in the end, but just from what I can see and understand now I don't think this should be solved with spreadsheets. It is good that spreadsheet (or python) can tap in, to read and even edit the values, but it should not be the central "on-compute" driver behind all of it. IMO the formula functionality has to be in the core of sketcher (and other modules that can make use of it) so the user has to be able to set such formulas directly there and it has to stay synchronized between the different inputs (task, properties, spreadsheet, python,...).
Ok, so you kindda agree with the direction of my second thought.
All the values we set are properties (or stored within properties). I think that the task is not doable, or at least not in an elegant way, by directly limiting it to the sketcher. IMHO, the change should be made in the properties. So that a Quantity, for example does not embed just a double, but a double and an expression (new type). Quantity is used overall, including the PropertyUnitItem, that is also overall. This PropertyUnitItem then should be upgraded to handle this new type (to allow the edition of the expression), while representing the double.
A word on expressions: I was thinking that solving changes like this can become a nightmare. For example, updating an expression can mean subsequently changing a plurality of values of other depending expressions. This shall be done in order (and optimized when possible) to avoid breaking not-that-simple designs. A solution I have been thinking of is that this new type, adds itself to a "newtype managing system" (another class, like a container of this new type). This "managing system" could have a tree structure, the nodes set into different levels depending on their dependence on the values of other types, something like:
Variable, Function of, expression/value
L, , 32 mm
...K, L, L/2
....N, K, K^2
......Z, M L, M/L
M, , 20 mm
....Z, M L, M/L
note that Z is in both branches. This should allow to see how the sketch are to be applied.
I would set initial limitations to the system: expressions can not be recursive, depend on themselves (not even circularly).
I would really like to use an existing proven engine for symbolic math (like GAP), both none seems to be under LGPL (GAP is GPL), and I think we can not afford another licensing nightmare.
Ok, those are my 2 cents. No intention to insert more noise, as I have not read yet the other tasks tanderson provided, and probably I am either presenting similar problems or similar non-working solutions...
