[OpenSCAD] Proposal for extensions to the OpenSCAD syntax

Hugo Jackson hugo at apres.net
Sun Oct 27 19:09:18 EDT 2019


I've been working with OpenSCAD for a couple of years now, and while frustrating I appreciate problematic nature of the inherent
limitations, like being unable to interrogate values.

I have been playing around with ways in which the basic syntax might be extended that would provide more
flexibility and power in creating 3D models. I'm no computer language expert, but I think the extensions
I propose would ease a lot of frustrations with some of the inherent limitations of the language without
breaking any of the rules.

To start, I would propose an extension of the "dot" notation, that would allow one to refer to a value declaration and/or
function or module component of another module with a dot. 

e.g.

module foo() {
	valueA = 7;
	valueB = 3;
	
	function myFunc(num) = valueA + num;
	
	cube([valueA, valueB, valueB]);
}

module bar() {
	valueB = 8;

	valueC = foo.valueA + foo.myFunc(valueB); // use the myFunc function of foo to calculate valueC
	
	cube([valueA, valueB, valueC])
	foo();

}

Scoping rules would remain as they are, in that value declarations would be at the scope of the called module or module part. i.e. for the
above example the cube created in module bar, valueB would = 8 but it would be 3 in foo.


The second extension would be the election of three operations as 'reserved' functions, union, difference and intersection such that one
could explicitly call that part of a module without calling the others:

module foo() {
	valueA = 7;
	
	intersection : {
		cylinder(d = 7, h = 4);
	}

	difference : {
		cube([8,3,2]);
	}

	union : {
		translate([9,3,3])
			cube([3,1,1]);
	}
}

module bar() {
	valueG = foo.valueA;
	
	
	foo.union(); // would only execute foo.union;
	foo(); // would execute intersection(){difference(){union(){<union code>}<difference code>}<intersection code>}
	
}

One could select the execution of nested module definitions in another module as well… not just the ‘reserved’ functions.

This would allow for a tighter coupling of a module's attributes to it's basic geometry. Simplistically, say one wants a walled cylinder but it will 
this part would have differing bases depending on where the cylinder was used in a design. As it stands, one would need to either create
cumbersome code for the cylinder base to avoid the base cylinder definition to avoid 'filling' up the cylinder where the base was, or decouple
the difference operation from the declaration of the cylinder so it will clear out any of the base geometry that is placed in the
way of the shaft.

These two extensions of the syntax would also allow for comparatively effortless calculation of boundary regions where desired without
creating a performance penalty where it is not needed and provide for pseudo polling of an objects characteristics without actually
requiring access to unreachable object values.

I hope that what I see as a manifold increase in the expressive power and abstraction in creating openSCAD programs with these
suggestions for an extended syntax or self-evident... and I'd be interested in what the rest of you might think. If what I’m suggesting is unclear
Please let me know… I didn’t want to bog this proposal down with details if it’s obvious, but in doing that I have taken the risk that the improvement
And benefits of such extensions may not be evident.




More information about the Discuss mailing list