There's a need to tag entities in the language to refer to them later, currently, that's done with strings so

const part001 = startSketchAt([-1.2, 4.83])
|> line([2.8, 0], %)
|> angledLine([45, 3.09], %)

might become

const part001 = startSketchAt([-1.2, 4.83])
|> line({ to: [2.8, 0], tag: 'seg01' }, %)
|> angledLine([45, segLen('seg01', %)], %)

There are a number of problems with this

• It's just an arbitrary sequence of characters, it can't really be part of static analysis, miss-spelling would cause segLen('sEg01', %) to fail.
• Someone could put the string in a variable, but it would be outside the pipe and so very ugly with multiple tags and still nothing stopping two tags from conflicting (same string without the user realising)
• Maybe we make some easy way of accessing the tag off the pipe object segLen(%$seg01, %). $ is arbitrary but also a bit weird, maybe .. might be a better convention? %..seg01, maybe also weird that seg01 starts its life as what looks like a string and then changes to something that behaves more like a key.
• Also with the transformation from line([2.8, 0], %) -> line({ to: [2.8, 0], tag: 'seg01' }, %) you can see that I'm trying to keep the line function to always taking two params, and adding in more optional params by changing the first param to a key-value pair, which in itself is kind of ugly.

With all of that said maybe attributes could work as a way of adding tags that's still compatible with pipeExpressions or not

const part001 = startSketchAt([-1.2, 4.83])
#[tag=seg01]
|> line([2.8, 0], %)
|> angledLine([45, segLen(%..seg01, %)], %)

And maybe there's a possibility of this having this part of the typing system i.e.

const part001 = startSketchAt([-1.2, 4.83])
|> line([2.8, 0], %)
|> angledLine([45, segLen(%..seg01, %)], %) // <- error trying to access a non-existant tag

It would know that the tag seg01 doesn't exist ahead of execution/calls to the engine?

This goes against something I said in #2, that attributes can be used for metadata not associated with modelling, but I think I can live with that.

Fillets are critical and we have to make sure KCL can express them easily.

I'm going to talk to the more CAD-experienced KC employees about how fillets actually work in practice and get some user stories.

Incomplete list of ideas:

• Support rounding edges of 2D solids, and extruding them into 3D with rounded edges
• Operations on 3D shapes (e.g. union/intersection/difference) should take a Fillet parameter to describe how to round the edges

We're gonna need examples of how to practically use KCL. I think a gear is a good first step. It's a nontrivial 3D solid, and it's also very common in real CAD. Here's what I've got so far.

@jgomez720 says the way real engineers draw gears is:

1. Create a cylinder with a cylinder missing in its center
2. Draw a gap (which, when removed, forms a tooth) on the top of the cylinder
3. Extrude it down, subtracting it from the cylinder

It'll be something like this (remember, type annotations will be optional, they're included here for clarity)

// Create cylinder with a cylinder missing in center

cylinder = (height: Distance, radius: Distance) =>
	circle(radius) 
	|> extrude(height)

gearWithoutTeeth = (height: Distance) =>
	let
		radius = Distance::cm(30)
	in subtract(
		cylinder(height, radius/10), // outer cylinder
		cylinder(height, radius)     // inner cylinder to subtract
	)

// Draw the negative space which defines the gear tooth.

toothToRemove2D = ... // TODO: define the tooth via lines/path segments

// Extrude the removal tooth into 3D

toothToRemove = (height: Distance) =>
	extrude(toothToRemove2D, height)

// Subtract that tooth from the main gear part via circular pattern

teethToRemove = (teeth: Number, height: Distance) =>
	circularPattern(toothToRemove, teeth, gearWithoutTeeth(height))

// Voila: a parameterized gear function.

gear = (teeth: Number, height: Distance) =>
	subtract(gearWithoutTeeth(height), teethToRemove)

// Which lets you make various individual gears.
gear1 = gear(40, Distance::cm(3))
gear2 = gear(33, Distance::cm(20))

Just walking through this example with Josh was really helpful for bridging the gap between my software and his hardware background.

Open questions:

• The signature for circularPattern is still hazy
• How do we draw the toothToRemove2D on the cylinder

All KCL objects (lines, paths, points, corners, solids, etc) should support metadata. This way users can:

• Add notes for other humans (annotations)
• Add structured data for APIs to read (e.g. physical properties like mass, which feed into KittyCAD's API for checking the total weight of your assemblies)
• Add custom properties which get carried through to the GLTF export (for manufacturing devices)

These metadata need to support both statically-typed metadata (which we typecheck), and flexible data (for external devices or clients, whose schema we won't understand).

Right now the fantasy docs describe a Material type, which all 3D objects take as a parameter when they're constructed. In my opinion this could be a special case of the more general and powerful metadata system I described above.