[OpenSCAD] The OpenSCAD Language

Carsten Arnholm arnholm at arnholm.org
Mon May 6 13:21:12 EDT 2019

On 06.05.2019 16:59, Doug Moen wrote:
 > 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.

Whatever you call it is not important, I was simply loosely referring to 
what has been said at various times when e.g. explaining why variables 
are constant in OpenSCAD. 

The main point as I see it is being able to do things like assign and 
re-assign variables and use them for anything, including holding shapes. 
Also, I prefer not to be limited to recursion when iteration is natural. 
It is all about choice.  Being able to declare user defined datatypes 
(classes) in the script language is another thing I want to have, so I 
enabled it. The list goes on.

 > 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)."

The main point is you can't do that in OpenSCAD, not which paradigm you 
classify the language to.

 > 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.

That is indeed a good principle to work from, given the large user base. 
However, to have alternatives is also a good thing, so I am offering one.

 > However, AngelCAD is just CSG embedded in a general purpose
 > imperative language.

You could say a Ford is just a car :-)

 > There is a lot of verbosity and boilerplate,

This is not a competition in writing a trivial example using the least 
amount of bytes, at least not the way I see it. I am more interested in 
the examples that are somewhat more complex.  The cases you list don't 
do the same things either. If you want a minimal,complete example that 
generates and exports a cube it can be written as

void main() { cube(45).write_xcsg(GetInputFullPath()); }

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

You can write the above in various ways,  all below are valid and doing 
the same thing

// 1
shape@ main_shape()
    return cube(45);

// 2
shape@ main_shape()
    cube cu(45);
    return cu;

// 3
shape@ main_shape()
    auto cu = cube(45);
    return cu;

But, this is not a competition in writing trivial code with the least 
amount of bytes. With support for different programming styles in the 
same language, one can select the most natural approach in each case. I 
am more interested in readability and performance than sheer compactness 
of trivial cases.

The motivation behind AngelCAD is to offer flexibility, expressiveness 
and speed. It is also about offering a choice, if you like it you can 
use it.

Carsten Arnholm

More information about the Discuss mailing list