Open nrc opened 4 weeks ago
@jtran has proposed a change to the language making constraints first-class: #13
Some related issues: https://github.com/KittyCAD/modeling-app/issues/1626, https://github.com/KittyCAD/modeling-app/issues/1498, https://github.com/KittyCAD/modeling-app/issues/111
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.
The currently supported constraints are:
angleLine
angleLine
, used for making lines parallelangledLineThatIntersects
lineTo
angleLine
xLine
or yLine
Note that another key way for defining constraints is to use values which are defined using a value of another object, e.g., using segAng(seg02)
where seg2
is the tag of a segment.
Some notes and start of a design: https://gist.github.com/nrc/efdec535bd961a0f7b470480676fa9eb
See also this list of sketch features, including constraints: https://github.com/KittyCAD/notes/blob/main/docs/personal/Boone-Nick/Advanced-Sketch-Features.md
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.,
xLineTo
is 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.