Constraints - Githubissues

nrc commented 4 hours ago

Constraints seem like a big rough edge in KCL at the moment. This is a tracking issue to collect related issues, document problems, and discuss solutions.

Currently constraints are initiated and manipulated by the UI. They are not explicit in KCL: they are represented by different functions, e.g., xLineTois a more constrained version oflineTo`, and by factored-out variables. These patterns are then recognised by the UI for further manipulation of the constraints.

This is unsatisfactory because it is fragile - the user could change a constraint in code such that the UI can no longer treat it like a constraint. It is sub-optimal for users because of the implictness of the constraint. It also doesn't scale well: we end up with a lot of closely related but different std lib functions.

We would also like a bunch more constraints than we currently support.

nrc commented 4 hours ago

@jtran has proposed a change to the language making constraints first-class: #13

nrc commented 4 hours ago

I have a rough idea which might help (would need other improvements too): rather than have multiple different line functions with different levels of constrainedness, we have a single line function who's argument defines how the line is drawn, including constraints. So line(pt(0, 0, 0)) would replace lineTo, line(vec(0, 1, 0)) would replace line, and for more advanced cases, something like line(parallel(X) & length(4)) (& here is a strawman syntax) would replace xLine(4), or line(angle(90) & length(4)) would replace angledLine, etc. Similarly for arc and other drawing functions which might be constrained. This puts the constraint in one place and makes it more explicit. It also makes the std lib smaller and better organised. However, it doesn't extend to constraints across multiple items, e.g., we might want to constrain two lines to be parallel, but not give one a specific angle and the other follow the first.

KittyCAD / kcl-experiments

Constraints #16