Lambda the Ultimate

I've been sweating over a very similar problem myself lately. I've been trying to design a useful, flexible, reasonably abstract language for just describing complex physical things.

Formal verification of CNC programs to build things is a fine goal, but I think that before it can be useful we need to be able to fully and flexibly describe the things to be built. CNC is a type of assembly language very dependent on the local device; it should be emitted, not by humans, but by compilers.

What we want to do is build particular objects. But we want some flexibility (undefined behavior?) to allow for differences in locally available materials and processes. And, depending on the object, different qualities may be important to us.

Color, for example, may be an important material property for a toy bunny. For a bushing that holds an axle inside a sealed box, not so much. So we want to stop the build of the toy bunny if the right color isn't available, but go ahead and make the bushing green instead of white because we really don't care what color it is. Likewise, the exact measurements and tolerances of the bushing matter to us a lot, but the toy bunny, not so much. So we want to stop the build of the bushing if the local hardware can't produce tolerances within 0.01 mm, but let the toy bunny go ahead and get built.

It isn't enough to say what material you want to build it out of and what shape you want it. You also have to specify manufacturing tolerances, margins of error, dimensional constraints, acceptable substitutions if any and their effect on design, interfaces between volumes made from different materials (like conductors and insulators), and (this is important) which properties are the *salient* properties of the materials.

Consider the humble plastic interlocking brick, beloved of children worldwide. So, do you take your CNC file and build it out of whatever type of plastic you have available? Or whatever plastic your local fabber can handle? NO! If the plastic has the wrong degree of resilience and elasticity, you get bricks that take excessive force to snap together, bricks that break instead of snapping together, bricks that don't snap together tightly enough to build things out of, bricks that chip and break in normal use, etc.

You can adapt the design to work with most common kinds of plastic. It needs different wall thicknesses at crucial points in the sockets and/or pins where bending has to happen for the snap-together action to work. So how do we describe that to allow a local fabber can figure out what the "correct" pattern and manufacturing process for its particular grade of plastic might be? Not with CNC codes. CNC just tells the machine what shape to cut, and doesn't allow for any adaptation to locally-available materials or local capabilities.

Now consider the variety of manufacturing processes out there. There is everything from electrostatic machining to injection molding to CNC cutting to plasma welding to layered deposition to sand casting to vacuum forming to stamping to selective sintering. Most of these can be used to make an interlocking brick in a standard size. But the processes are so fundamentally different that there is not a single instruction in common in the controls for these devices. And even within each family of devices, different machines use fundamentally different control paradigms. Describing the manufacturing process in detail for such devices is like writing programs in machine code -- it is tightly tied to a specific hardware and incompatible with all other hardware. And that's because it's all about specifying process (do this, cut here, turn twenty degrees, cut that, etc) rather than result (I want a plastic brick that I can snap together with other plastic bricks made from the same pattern).

What I want is a language for describing objects, which I can use to make programs for producing those objects portable across different manufacturing devices and different kinds of manufacturing devices. I want to feed this program to a "compiler" that knows the local capabilities and how to control them, which determines whether it's locally buildable and if so develops a construction plan (which may entail emitting CNC or other "assembly-level" instructions) suited for the local devices.

The objects resulting from running the program would be slightly different depending on available materials, available manufacturing technologies, etc, but for practical purposes they should work "the same way" or be "the same kind of object."

This is exactly the same kind of abstraction over machine code that was provided by programming languages in the first place.

I thought about a more abstract language to describe analog computers (not limited to a mechanical (or hydraulic/pneumatic) realisation, but also with standard electronic circuits, be it ICs, discrete solid state devices or vacuum tubes) also for the fun of it and to try out different strategies of mapping the high level description to a given technology which in turn is described by a sub language. Apart from the hacking value of this undertaking it bears some similarities to analog modelling languages like Verilog-A, but with a slightly different scope. I bet such a language given that it provides a rich enough toolbox (translation to languages like SPICE for electronics, g-code for mechanical parts, etc.; as well as the possibility of simulating mechanical devices) could also make a fun toy for educational purposes for almost all levels (not only universities).

As for building something that would be accepted by the industry, I am doubtful. Engineers and designers dealing with building machines and circuits already have many tools and languages at their disposal and most often the deciding factor is being able to integrate a given tool into an existing or planned workflow. But I strongly agree that analog computers and mechanics could make for a very rich source of case studies for DSLs apart from the well known examples.

What I had in mind is much more modest. I just want to be able to compile a description of a function (say f(x)=1/(x+1) in range 1..10) to a cut path for producing an appropriate cam, for example, and be able to deduce which parts will be needed (assuming an appropriately restricted language for describing functions).