[OpenSCAD] eval( ) ???

doug moen doug at moens.org
Sat May 16 19:35:33 EDT 2015


Hi Carsten.

One of my top goals for "OpenSCAD 2" is to stay true to the goals and
philosophy of OpenSCAD. I've tried to figure out what these are by
talking to Marius and reading forum posts for the last few years.

Some OpenSCAD users are computer programmers like you and me, but many
are not. If OpenSCAD is your first experience with computer
programming, then how many new concepts do you need to learn before
you can be productive? OpenSCAD seems to have a low barrier to entry,
and we want to keep it this way.

One philosophical principle I've learned from the community is that
OpenSCAD is intended to be a purely declarative or 'functional'
language, except that it should also be much easier to learn than
serious functional languages such as Haskell. This means that there is
no state. You can't increment a variable or modify a data structure
in-place.

Traditional OOP languages are based on the idea of objects with state,
and there is a lot of additional heavy weight machinery that you need
to learn before you can be productive. But we don't want this: we'll
end up with a language that is easy to use once you have learned
object oriented programming, but it with a higher barrier to entry for
beginners.

In your first example (class lollipop), you defined a class, you
defined a constructor inside the class, you declared data members then
separately assigned them initial values within the constructor, and
you have an assignment to the special variable 'this'. You used a lot
of machinery to accomplish something very simple.

In your second example (module example_module), you create a mutable
object and modify its state, in these lines:
>     table_plate = cube(size=[100,100,5],center=true);
>
>     // union the lollipops with the table plate and return it
>     table_plate.union(lolA);
>     table_plate.union(lolB);
>
>     // be explicit about what the module returns
>     return table_plate;
But we want OpenSCAD to be purely declarative, without state mutation semantics.

When I have more time, maybe I'll try and rewrite your code in
OpenSCAD 2, to demonstrate that the same things can be accomplished in
a simpler way, without all the heavy machinery of OOP.

Doug Moen.

On 16/05/2015, Carsten Arnholm <arnholm at arnholm.org> wrote:
> On 2015-05-16 19:33, G. Wade Johnson wrote:
>> Is there a {beta,alpha,prototype} version of OpenSCAD2 somewhere for
>> people to play with? Is there a spec to read?
>>
>> I, for one, would like to see anything you are willing to share on this.
>
> That was my reaction as well.
>
> In my opinion, classes are not there to complicate things. On the
> contrary, it is an important tool for simplification. Being able to name
> a type, encapsulate its data members and provide member functions would
> go a long way towards the goal of being more expressive without
> complicating things.
>
> In my line of thinking, which may be different from OpenSCAD2 (as I have
> not grasped the full idea of it), the main ideas would be:
>
> classes would be used for constructing named parametric objects
> (instantiation) and being able to union, intersect and difference the
> result with other named or unnamed objects (union(), intersect() and
> difference() would be member functions on any class. unlike a module, a
> class may contain data members unique to each instance created.
>
> Below is just a silly example to illustrate: 2 lollipops on a table.
> The difference between a module and a class here is that a class may be
> instantiated and may remember its construction parameters so they can be
> re-used later. It also owns its CSG object.
>
> // classes are new
> class lollipop {
>
>     // a constructor is a member function with the same name as the class
>     lollipop(rad, diam, hei)
>     {
>        // keep data members
>        radius   = rad;
>        diameter = diam;
>        height   = hei;
>
>        // "this CSG object"
>        this = union() {
>           translate([0,0,height]) sphere(r=radius);
>           cylinder(d=diameter,h=height);
>        };
>     }
>
>     // data members of the class
>     radius;
>     diameter;
>     height;
> };
>
>
> // modules exist as before
> module example_model()
> {
>     // create 2 lollipops of different sizes
>     // the second is dependent on the first
>
>     lolA = lollipop(rad=10,diam=2,hei=50);
>     lolB = lollipop(lolA.radius*2,lolA.diameter*3,lolA.height);
>
>     // create a cube representing the table plate. Here,
>     // the construction parameters cannot be accessed later
>     // since the cube is a primitive only
>     table_plate = cube(size=[100,100,5],center=true);
>
>     // union the lollipops with the table plate and return it
>     table_plate.union(lolA);
>     table_plate.union(lolB);
>
>     // be explicit about what the module returns
>     return table_plate;
> }
>
> // construct the exmple model and export it as STL
> example_model().render().export("STL","lollipops_on_table.stl");
>
>
> You could go on, classes could have data members being instantiations of
> other classes, or even containers containing such.
>
> The above is just meant as a supplement to what I wrote before,
> illustrating the idea that the OpenSCAD language could be extended in a
> direction which would be immediately recognisable to programmers, while
> still being backwards compatible with existing OpenSCAD code. If you
> want to express things as it is currently being done, you can, but you
> also have other possibilities.
>
> Again, just my thoughts. I don't know if it would be easy to implement.
>
>
> Carsten
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss at lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>




More information about the Discuss mailing list