Plan and priorities for KCL 1.0

[nrc]

No description provided.

[jtran]

a more principled way to do it is export of variables

It's true that $foo binds foo locally, like an output parameter. But the .tags field is a whole separate use for tags.

A common use case is having a function that builds a sketch and returns it. If it were a matter of binding variables in a weird way that were accessible in the calling scope, you couldn't call the function multiple times.

Here's an example of this pattern that works today that's quite useful:

fn buildShape = (plane, offset) => {
  return startSketchOn(plane)
    |> ...
    |> line([1, 2], %, $important)
    |> ...
    |> close(%)
}

one = buildShape('XZ', 0)
two = buildShape('XY', 22)

extrude(10, one)
extrude(10, two)

// Sketch on each face.
buildMore(one.tags.important)
buildMore(two.tags.important)

When I first joined, I thought we wanted to hide the information. That may be true for assemblies. But for a single part, the user needs to be able to access everything in the scene that they could possibly click on.

As it is today, I don't see how it could work with static typing. The tags available in .tags would need to be part of the return type of buildShape().

On the other hand, if it were reified at runtime, it could look like this and be a runtime error if it's not defined:

buildMore(one.tags['important'])
buildMore(two.tags['important'])

A complication, which I think you're calling "dynamic tagging", is that even though Kurt et al have pushed for named tags for stability, others have brought up that if we have loops, then it doesn't really make sense to name a segment inside a loop. It needs an index corresponding to the loop index. So how does that work?

We used to declare the tags with strings, so people would actually do string concatenation between a name and a numeric index to declare them. This is all very dynamic.

Unless you have an idea for a completely different way of doing this, I think it needs to be dynamic.

[nrc]

So, I actually think there is a lot that is weird about this way of doing things, the dynamic-ness is the least bad bit. The fact that the name important is significant at runtime is weird because it makes variables significant which limits optimisation (or at least forces optimisation to maintain this info), it breaks encapsulation (because if the author changes the name of important, it break users of the sketch, which can't be caught statically in all cases because of indexing fields by non-literal strings), furthermore, if the structure of the final solid changes, then the meaning of important can change. The fact that important tags a line but is used to refer to a surface means that tags are ambiguous and I think this will be hard for users to understand in some cases.

I think there isn't a single solution, but multiple: naming and explicitly making some tags public is part of the solution, and I think these should become fields on the created sketch (so the equivalent of simply one.important, though not the extruded solid, IMO). It should also be possible to navigate to each component (or at least collection of components), so one.extrudedFaces would give you the set of faces extruded from the sketch. Finally, I think we should have a query system for finding geometry which is the general solution for finding any component which can be clicked, in this case, something like select(partOf = one, extrudedFrom = one.extrusionSketch.important). Obviously, this isn't a 1.0 thing though

[jtran]

The plan looks good to me overall.

[jessfraz]

As mentioned on the thread in slack I don’t think we should remove int

[nrc]

Sorry, I forgot to respond on Slack. My thinking is that although it is a pretty small thing, it is one of many small things that all together make KCL feel a bit rough, and while not needing int alone isn't much, if we can polish all or most of these rough edges, then KCL will feel a lot nicer, especially for new users.

There was also a lot of discussion about other numeric stuff (all of which I think we should postpone to after 1.0). To be clear, I think not requiring int is a really small amount of work and that it doesn't make things any harder for the other numeric stuff, so IMO the cost/benefit here is good.

[jessfraz]

okay i just want to make sure we aren't creating magic, do other programming languages do this automatic conversion of floats to ints. MEs aren't so dense as to not know the difference and I think giving them the control to change the type is better than not, BUT i guess if we are only talking about changing 10.0000000000000000000... to a int then its fine, but if we are talking about changing 10.000000000000000001 i say no

[nrc]

Could you say why you don't like the 10.000000000000000001 thing? We could definitely do just the former and it would get us most of the way there, but using a tiny epsilon would avoid some minor irritation for users.

It's not so much that it's a hard concept, just not one which fits with the rest of the language - we just have a number type, we don't ever expose the int vs not-int distinction explicitly, and it leads to really awkward behaviour like foo(5) working but x = 5; foo(5) being an error which requires x = 5; foo(int(5)).

[nrc]

Other languages do have an equivalence, e.g., Javascript has the position that all numbers are f64, but lets you use those in for loops, etc. (although their approach is to just accept floats everywhere rather than having an implicit conversion, I believe the conversion is better since for i in [0..(0.1 + 0.2) * 10] should either be an error or treat the upper bound as 3, whereas in JS the upper bound is equivalent to being treated like 4).

Example for why we might want a tiny epsilon is (0.1 + 0.2) * 10 comes out at 3.0000000000000004 and I would love to treat that like 3.

[jessfraz]

I think with the precision we need for CAD I do not feel comfortable converting anything that is not 00000000 all zeroes without the user explicity saying to do so. Because for like a engine or a rocket they might actually want that.

[jessfraz]

I’d argue adding caching of objects for assemblies etc is a nice priority and making it fast which is more important than a few things on the list here

[nrc]

I'll add it in. I'll need to think a bit about how it can work, etc. My initial impression is that it will be a pretty large amount of work.

Are we aiming to get assemblies into 1.0? That was one thing I was unsure about for the feature work

[jessfraz]

yes assemblies are required for v1, honestly i think we are like 50% of the way there for cache, we already have the hashes, we would need to only re-execute the objects that changed, there is already an api for object delete.

[nrc]

I added work items for assemblies and caching to the doc, needs elaboration though