[OpenSCAD] The OpenSCAD Language

Doug Moen doug at moens.org
Mon May 6 10:59:04 EDT 2019


The OpenSCAD language has the following limitations:
* You can't store a shape in a variable.
* You can't query the attributes of a shape (eg, get the bounding box, or the list of faces and vertices).
* Functions are not values. They can't be stored in variables, passed as parameters, or returned as results.
* The only data structure is the list. There are no records (or maps).
* There is no assignment statement, and no mutable variables.

When I first got involved with OpenSCAD, I hoped to pitch in and fix these limitations. I wrote a number of design proposals, and created "OpenSCAD2" as a design proposal for fixing these limitations.

Once it became clear that I wouldn't be able to make these changes within the OpenSCAD project, I renamed OpenSCAD2 to Curv, and evolved the project in a different direction from OpenSCAD. The Curv language fixes all of the limitations that I listed above, and I changed the representation of shapes from triangle meshes to signed distance fields, which I believe is a more powerful representation. It can represent curved shapes and deeply iterated fractals using a mathematically exact representation, and there is a larger set of shape operations available. This representation also supports full colour 3D printing.

Carsten wrote:

> In OpenSCAD, a design choice was at one stage taken to use what is called
> a "functional language" which by definition disallows the types of operations
> you mention.

OpenSCAD is not a functional language. Functional programming is all about programming with functions. But functions are not values in OpenSCAD.

It would be fair to call OpenSCAD a domain-specific, declarative language.

It is untrue that functional languages "by definition" disallow the feature that Troberg wants: "I can't assign an object to a variable and then ask that variable about the object (location, size, rotation et cetera)."

Curv is a pure functional language (the strictest type of functional language), and it nevertheless supports all of the features I mentioned in the first paragraph, including assignment statements and mutable variables. Curv also supports the usual functional programming idioms: curried functions, pattern matching, full tail recursion optimization.

It would be possible, in principle, to extend OpenSCAD to support the same features. But it would be a big, disruptive change to the language, and that conflicts with OpenSCAD's conservative approach to change. OpenSCAD is almost 10 years old and the project has emphasized stability, incremental change and backwards compatibility.

AngelCAD certainly represents one approach to overcoming OpenSCAD's limitations.

However, AngelCAD is just CSG embedded in a general purpose imperative language. There is a lot of verbosity and boilerplate, compared to a domain-specific declarative language such as OpenSCAD or Curv. The lack of boilerplate is something that I really value about OpenSCAD.

AngelCAD:
shape@ main_shape()
{
    cube@ cu = cube(size:45, center:true);
    return cu;
}

void main()
{
   shape@ obj = main_shape();
   obj.write_xcsg(GetInputFullPath(),secant_tolerance:0.01);
}

OpenJSCAD:
function main ()
{
   return cube({size: 45, center: true});
}

OpenSCAD:
cube(45, center=true);

Curv:
cube 45

 Doug Moen.



More information about the Discuss mailing list