Debate if we should add mutation to KCL #22
Conversation
|
|
||
| - Mechanical engineers (MEs) will be coming from Python or JS. They will be used to imperative programming with loops and variables. The functional programming patterns (e.g. map and reduce) they'll need to engage with will be unfamiliar. | ||
| - Given that we're already asking MEs to go outside their comfort zone (by coding rather than using the GUI), we should make the language as intuitive as possible. This probably means for loops. | ||
| - To keep KCL performant will require implementing persistant data structures. For example, to keep KCL immutable, Array.push currently clones the array into a new variable, and appends to the cloned array. It'd be much faster to just mutate the array in-place, but that'd require mutation. There are alternative high-performance immutable data structures but we'd need to understand and implement them. Certainly doable, but less immediately simple than reusing Rust's mutable datatypes. |
There was a problem hiding this comment.
Once KittyCAD/modeling-app#1130 is fixed, I don't think adopting persistent data structures would be hard at all. There are only a few things that interact with arrays. Literals, map, reduce, push, and get index [].
There was a problem hiding this comment.
I think that in practice this shouldn't be a problem if we encourage using constructs like patterns rather than arrays. For performance, most variables would only require reference counting, not full persistent data structures. The latter could be layered on top of Rust data structures fairly easy (note that you don't really want a persistent data structure, which is emulating mutability in an immutable world, you want the opposite which is emulating immutability in a mutable but monotonic world. This is pretty easy - just use a Rust array and a variable which points to an earlier version of the array is a copy-on-write slice reference of the correct length, similarly for other data structures).
| - Encourages users to use higher-level constructs like patterns, that can be optimized in both KCL and the engine much more easily than a for loop. | ||
| - Easy to map a specific geometric feature (e.g. a 2D polygon) to its definition in the IDE because a geometric feature is created once and then never changed, so it's fully defined at its source range. If geometry could be updated, we'd need the IDE to show where it was defined AND where the relevant change was made. | ||
| - KCL is about defining geometry, not about modeling a changing system. Mutation doesn't seem necessary. | ||
|
|
There was a problem hiding this comment.
I'll add that it makes a lot of analyses (e.g., for the IDE), optimisations, and other reasoning about the code, much, much easier. In particular, partial execution (for sketch mode) and code mods will be much harder to get right in the presence of mutation
| ## Why mutation | ||
|
|
||
| - Mechanical engineers (MEs) will be coming from Python or JS. They will be used to imperative programming with loops and variables. The functional programming patterns (e.g. map and reduce) they'll need to engage with will be unfamiliar. | ||
| - Given that we're already asking MEs to go outside their comfort zone (by coding rather than using the GUI), we should make the language as intuitive as possible. This probably means for loops. |
There was a problem hiding this comment.
See #15 for a proposal for a 'for loop' construct which subsumes for_each, map, and reduce (in most cases) and works with immutability, and I believe is easy to teach to programmers coming from Python/JS (though the actual details of how it works are somewhat complex).
| - Mechanical engineers (MEs) will be coming from Python or JS. They will be used to imperative programming with loops and variables. The functional programming patterns (e.g. map and reduce) they'll need to engage with will be unfamiliar. | ||
| - Given that we're already asking MEs to go outside their comfort zone (by coding rather than using the GUI), we should make the language as intuitive as possible. This probably means for loops. | ||
| - To keep KCL performant will require implementing persistant data structures. For example, to keep KCL immutable, Array.push currently clones the array into a new variable, and appends to the cloned array. It'd be much faster to just mutate the array in-place, but that'd require mutation. There are alternative high-performance immutable data structures but we'd need to understand and implement them. Certainly doable, but less immediately simple than reusing Rust's mutable datatypes. | ||
| - Currently the engine is mutable and KCL is not. This leads to mismatches like <https://github.com/kittycad/modeling-app/issues/2728> which will be complicated to solve if we keep the language immutable, and trivial if we allow mutation. |
There was a problem hiding this comment.
I commented here, I don't think it is that hard to fix (though certainly non-trivial to fix properly)
| - Currently the engine is mutable and KCL is not. This leads to mismatches like <https://github.com/kittycad/modeling-app/issues/2728> which will be complicated to solve if we keep the language immutable, and trivial if we allow mutation. | ||
| - Many math formulae that MEs will try to implement are easier as imperative algorithms (citation needed) | ||
|
|
||
| ## Implementation problems |
There was a problem hiding this comment.
I fear that there would be a large knock-on effect of such a large change to the character of the language which would mean a lot of changes to existing and planned constructs, and std lib functions.
No description provided.