In your second example (module example_module), you create a mutable
object and modify its state, in these lines:

But we want OpenSCAD to be purely declarative, without state mutation semantics.

Hello Doug,

Interesting discussion! Please understand that if you find I present
alternative viewpoints I very much respect the work being done. I
just want to add my perspective.

On 2015-05-17 01:35, doug moen wrote:

I have followed the posts for only a few months, so I do not have the
full picture. I apologise if I repeat important discussions you may
have had already. I have noted the stated goal of "functional
language", but I have yet to see a truly convincing explanation of
why that is a good thing as seen from the user point of view. More on
that below.

On the top of the front page of http://www.openscad.org/ it says "The
Programmers Solid 3D CAD Modeller". Programmers are the stated
primary target for OpenSCAD. There are many CAD packages around, most
target non-programmers first and foremost. OpenSCAD targets
programmers and that should influence the way capabilities are
improved. This is not in conflict with accommodating also users with
a different background, in my opinion.

The unique thing about OpenSCAD is its capability to express
unambiguous models in a programming language, a very powerful
capability. I believe the challenge is to make the language
sufficiently expressive: As simple as possible, but no simpler.

See above. If I had no experience in programming, I would use a
different modelling tool than OpenSCAD, there are many. I disagree if
the idea is to discard universally accepted programming idioms in
order to accommodate people with no programming background. Note I
explicitly do not mean to suggest making OpenSCAD a large language
like e.g. C++. On the contrary, I think you might be running the risk
of creating a large language precisely because the most common and
most expressive idioms are left out.

I would challenge anyone to define what "low barrier to entry" really
means. What I indicated explicitly accommodated current idioms ("If
you want to express things as it is currently being done, you can,
but you also have other possibilities.").

If you can't express what you think, or only with difficulty because
of limitations in the language, the barrier is high, not low.

I think an important goal of OpenSCAD is to provide a language giving
the average programmer an efficient way to express 3d models. Such a
goal does not, in my opinion, automatically imply that common idioms
known from other languages should be discarded.

As you say, in OpenSCAD you are not allowed to modify the value of
variable. As seen from a user point of view, this is not a
simplification, it is a constraint that makes things harder for the
user. It is as if you tell a C++ programmer to use ONLY template
code, where everything must be defined at compile time. Of course,
this constraint makes life easer for the implementer, no doubt about
that, but I don't think that is the argument presented.

I do not agree with that, see my previous simple example.

See above notes on target audience.

Yes, I did use an over-simplified example that could be solved using
other techniques. However, the idea was to convey the idea of a very
simple object model that could be used for much more complicated
examples that would be difficult to express with the current language
features.

As noted above, I have come across this statement several times, I am
fully aware it exists. I just have not seen arguments that have
convinced me it is consistent with how I perceive OpenSCADs overall
goals.

I think it would be useful to see alternative code, indeed. It makes
it easier to get a factual impression of what it is.

I will consider also some alternatives to what we have discussed. I
need to understand a few more things in OpenSCAD as it currently
stands, I am still learning here.

I would like to thank you for a thought provoking debate and for the
work done!

Carsten Arnholm

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

doug moen mailto:doug@moens.org
May 16, 2015 at 19:27
Hi Yona. I find parts of your post confusing (the term "module" is
overloaded), but we are thinking along the same lines.

A quick way to summarize my thinking is that you don't need classes to
do object oriented programming. The prototype/delegation paradigm used
by Javascript is just as powerful. But if all objects are immutable,
then you don't need delegation, and things get really simple. You just
need:

1. object literals
2. a way to make a new object by specifying the differences from an
   old object. Or: a way to customize an object, overriding some
   fields, resulting in a new object.
3. functions

And that's it, you have a functional OOP system. It's simple, more
powerful than it looks, and good enough for our purposes.

OpenSCAD already has the above 3 concepts:

1. an OpenSCAD script corresponds to an object
2. you can customize a script, overriding some definitions, by
   writing 'include <scriptname>' and then writing new definitions
   that override some of the bindings inherited from <scriptname>.
   Or, you can override definitions within a script from the command
   line using the -D flag.
3. OpenSCAD has functions. Also, 'module' definitions are really just
   functions by another name.

OpenSCAD 2 just generalizes these already-existing concepts. It adds
object literals and first class object values. It adds a better syntax
for customizing an object. It unifies "functions" and "modules", using
the word "function" to describe both.

Now I'll copy and paste part of Yona's post, with terminology and
syntax changed to correspond to my current OpenSCAD 2 design:

Doug Moen.

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Yona Appletree mailto:hypher@gmail.com
May 16, 2015 at 17:52
Doug,

This is a fascinating discussion, and I wanted to chime in about
objects and mutability (full disclosure, experienced programmer). I
have an interest in functional, immutable programming styles, but have
not personally used lisp or Haskell. Most of my experience is with Scala.

I think you can preserve much of the usefulness of objects while
keeping a simple syntax and immutability. In fact, we don't even
really need a new keyword. Modules are fine as is, with a few minor
extensions. The main features that seem useful are:

1. Combining data, geometry and functions into one variable space
2. Module mix-ins
3. Access to module parameters and variables as "fields"
4. A module "copy" method. I will use the name "with", where you can
   specify overrides to the parameters and variables in the modules.
   This would return a copy of the module with the new values,
   keeping immutability.

Carsten's example would look something like this:
module Lollipop(
radius,
diameter,
height
) extends Geometry /* This could be the default, and not needed to be
stated explicitly */ {
translate([0,0,height]) sphere(r=radius);
cylinder(d=diameter,h=height
}

// modules exist as before
module example_model()
{
// create 2 lollipops of different sizes, the second dependent on the
first

lolA = Lollipop(radius = 10, diameter = 2, height = 50);
lolB = lolA.with(radius = lolA.radius2, diameter = lolA.diameter2);
// height is omitted -- it stays the same

// create a cube representing the table plate.
// cube is a module just like everything else (albeit a native one),
// and it's parameters ARE accessible, and has a .with() if needed.
table_plate = cube(size=[100,100,5], center=true);

// union, a member of the base geometry module, returns an immutable
copy of itself
// unioned with the arguments to union. Since we are a module, any
geometry declared is
// implicitly unioned as before.
table_plate.union(lolA, lolB);
}

// construct the exmple model and export it as STL
example_model()
.render() // Produces rendered geometry... more on this later
.exportStl("lollipops_on_table.stl"); // magic strings are ugly. Use
an actual method name for STL

But these extensions would allow far more, but remain mostly, if not
completely backwards compatible. We can actually implement the
"geometry" base module using the existing functionality of OpenSCAD:
module GeometryBase {
unionOf = (args* /*vararg syntax tdb, of course /) -> { / Anonymous
function syntax TDB */
union() {
this
args
}
}

rendered = (x = 1) -> render(x) { this }
}

If we consider { ... } to be an "inline module", you get associative
arrays for free:

data = {
a = 10;
b = 20;
}
echo(data.a); // Valid because variables of modules are exposed

// You can create a copy with new values as well
data2 = data.with(b=30, c=100);

Just my two cents, but it would be a simple way to keep backwards
compatibility and all the desirable current features while giving the
programmers many of the features that feel natural to us.

• Yona
  doug moen mailto:doug@moens.org
  May 16, 2015 at 16:35
  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:

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 Arnholmarnholm@arnholm.org  wrote:

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Carsten Arnholm mailto:arnholm@arnholm.org
May 16, 2015 at 15:08

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@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
G. Wade Johnson mailto:gwadej@anomaly.org
May 16, 2015 at 10:33
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.

G. Wade

On Sat, 16 May 2015 12:44:38 -0400

Now I'll copy and paste part of Yona's post, with terminology and syntax
changed to correspond to my current OpenSCAD 2 design:

// If we consider { ... } to be an "inline object", you get associative

doug.moen wrote

I like this idea. For the on-the-fly local var assignment in data(b=30,
c=100), openscad seems to already have this capacity:

echo( b=30, c=100 );

b,c are local variables created at the run time.

Also would be great if, other than data.a, we can do x=data["a"],
x=data("a") (in case it needs to contain space) or even x=data(a).

One more thing, variable name like 3a, 4b are allowed in openscad. Will
data.3a also be allowed ?

And, on top of that, we also need:

keys(data) ==> ["a","b"]
values(data) ==> [10,20]

or data.keys, data.values, such that they can be iterated over.

This brings up: if we do [ for(x=data) ...], what would x stands for.

$  Runsun Pan, PhD

$ -- OpenScad_DocTest: doc and unit test ( Github , Thingiverse  )

$ -- hash parameter model: here , here

$ -- Linux Mint 17.1 Rebecca x64  + OpenSCAD 2015.03.15/2015.04.01.nightly

--
View this message in context:
http://forum.openscad.org/eval-tp12627p12700.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

Runsun said:

I would vote for data["a"] or data.("a")

Of course.

I'll grant the need for keys(data). But values is just
[for (k=keys(data)) data[k]]
and I don't know that it would be needed often enough to justify as a
builtin.

This brings up: if we do [ for(x=data) ...], what would x stands for.

OpenSCAD scripts are the model for what objects are. An object is a set of
named fields, and a sequence of shapes. Consider:

lollypop = {
radius = 3;
diameter = 1;
height = 10;

translate([0,0,height]) sphere(r=radius);
cylinder(d=diameter,h=height);
};

You can use 'lollypop' in any context expecting a shape.
Or you can customize lollypop, eg with a longer stick:

lollypop(height=20)

You can accomplish something similar with a module definition, but objects
are easier to understand and use.

So lollypop contains two shapes, and behaves like a list of those shapes.

len(lollypop) == 2
lollypop[0] == translate([0,0,10]) sphere(r=3)
lollypop[1] == cylinder(d=1,h=10)

and this answers what "for (x=lollypop) ..." means.

Doug.