I've been playing with "C-style for" (which is an experimental feature in
the dev build).

It gets a bit cumbersome for complex examples with multiple loop variables,
so I'd like to suggest an improvement.

What I'd like is a parallel, pattern matching assignment statement. For
example,

[x,y,z] = point;

requires 'point' to be a list with exactly 3 elements (otherwise an error
is reported). The 3 elements are assigned to x, y and z. This would be
really handy for updating multiple loop variables in the update step.

First example is the fibonacci sequence.

function fibonacci(n) =
[
for (a=0, b=1; b <= n; t=a, a=b, b=a+t) b
];
echo(fibonacci(10)); // [1, 1, 2, 3, 5, 8]

I'd like to get rid of the temporary variable 't', which I need because I
can't do a parallel assignment of a and b in the update step.

function fibonacci2(n) =
[
for (a=0, b=1; b <= n; [a,b]=[b, b=a+b]) b
];

Second example is prime factors.

function prime_factors(n) =
[
for (n=n, f=2;
n>1;
n1 = n%f==0 ? n/f : n,
f = n%f==0 ? f : f+1,
n = n1)
if (n%f==0) f
];
echo(prime_factors(20)); // [2,2,5]

There are two things I'd like to fix here: the extra variable n1, and the
need to duplicate the 'n%f==0 ? ... : ...' logic for updating n and f.

function prime_factors2(n) =
[
for (n=n, f=2;
n>1;
[n,f] = n%f==0 ? [n/f,f] : [n,f+1])
if (n%f==0) f
];

As you can see, with this change the code becomes a lot shorter.

I agree this allows to more concise code. But, why would only mutable
variable assignment have such a distinct privilege?

--
View this message in context: http://forum.openscad.org/feedback-on-C-style-for-tp17512p17514.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

"Bei dem ist 'ne Schraube locker" (literally "He has a loose screw", more
idiomatic "NUTS") and "Daar lê 'n slang in die gras" (literally" "There
hides a snake in the grass", more idiomatic "that's very buggy code") were
my first impressions when I read doug.moen's proposal.

But let me quote someone else: <github.com/doug-moen/openscad2>

"OpenSCAD2 is a backward compatible redesign of the OpenSCAD language. The
goals are:

to make OpenSCAD easier to use;
to make OpenSCAD more expressive and powerful, not by adding complexity

and piling on features, but by making the core language simpler and more
uniform, and by removing restrictions on how language elements can be
composed together to create larger components."

I am not going to dig up here what OpenSCAD developers have written on this
forum about "C-style programming". Simply put, for non-C programmers,
C-style programming is very difficult to read. "barely readable" it was
called in the tutorial I used to learn OpenSCAD. Rather consider how many
new users have problems with conditionals, or with polygon(), or are
actually using list comprehension.
On the latter, from what I can gather from this forum, only its creator
actually uses it, for everyone else it's too complicated. Or why would we
hear complaints about long render times? Look at the code samples provided,
and it soon becomes obvious that long render times arise from people
stuffing the renderer with work that is not truly needed for the creation of
the shape they are after. If they had but understood list comprehension, and
how lists can eliminate unused corners and faces before CGAL gets hold of
them, they could have saved themselves a lot of frustration . . .

If you live in a country where only a single language is spoken, your
thinking gets limited by the capabilities of that language. That's why
translating the initial quotes is so unsatisfactory and why they inevitably
loose their wittiness in translation. As doug.moen has pointed out in
another thread
(http://forum.openscad.org/Polygon-using-relative-points-rather-than-absolute-td17414.html
and https://github.com/openscad/openscad/wiki/Mutable-Variables), functional
programming is actually a dead end road, imperative-type programming had to
be introduced to achieve universality.

And that's why I object to "C-style for". Proper coding style should be
modelled as close to English language semantics as is possible. Conciseness
should not be an objective - easy learning should. And that means

1. rewrite all manuals and replace the word "variable" with "constant". Have
   that courage, and admit to yourself that when values are assigned at compile
   time they become constants - calling them variables is fudging/evading the
   issue.
2. introduce genuine variables (==mutable constants), as pointed out in
   https://github.com/openscad/openscad/wiki/Mutable-Variables
3. forget about "C-style programming" as its use implies the OpenSCAD user
   is already familiar with C, before he/she can consider learning OpenSCAD.
   "C-style" constructs are admittedly easy for C-programmers, but mostly are
   "barely readable" for people not familiar with C.
4. The for loop should take the form
   for i:=1 to </endval/> step </stepval/>
   because that is English, and thus accessible to everyone capable of reading
   the OpenSCAD manual.

Consider that functional languages came about as a response to the ease with
which the (mis)use of pointers in C can generate buggy code. List
Comprehension (array or *struct in C) is just one way to get around the
potential trouble lurking here. Resist the objections raised by functional
language zealots, and keep the OpenSCAD language simple and readable,
without requiring a background in C. Introduce genuine (==mutable)
variables.

OpenSCAD2 is the way forward, not "C-style". Treat a function as a pointer
to a value, or a list of values. Whether these values were obtained at
compile time or at run time is important only the the developer, it is
immaterial to the user.

--
View this message in context: http://forum.openscad.org/feedback-on-C-style-for-tp17512p17516.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

When it comes to mutable variables, it comes down to the deep question of
pure functional or not.  I disagree that pure functional is a dead-end road,
but the choice is a fork in the road where you need to decisively pick one
or the other.

If the answer is pure functional, then do{} introduces internal
inconsistency, and the "proper" (meaning internally coherent) way to support
mutation is via first-class functions, closures, and monads.  If OpenSCAD
does grow in this direction, then in a functional future looking /back/ at
do{}, it's going to be even more clumsy to retain coherence and work around
all the implications of backward compatibility and funky interactions.

I won't argue about whether functional or imperative is "better" or more
elegant, but I will argue that pure functional thinking is much more
/specialized/ than sequential style thinking.  I have heard it said that
functional programming is more like mathematics and less like programming,
and I would agree.  Yet I still believe that this mathematical style of
thinking is less common and less accessible to non-specialists, beginner or
not!  Anybody can bang out a bit of procedural code, but not everyone can
wrap their heads around closures, continuations, tail-recursion, or monads.

If the choice is to loosen the pure-functional requirement and forgo strict
referential transparency then I would /still/ suggest that do{} blocks are
not as good as if mutation were adopted as part of a more coherent
imperative language.

--
View this message in context: http://forum.openscad.org/feedback-on-C-style-for-tp17512p17519.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

@ Jamie K
I can't agree more.
Before OpenSCAD, I worked with Sketchup for almost two years. I think the
success of Sketchup relies on the elementary set of operators it provides.
Everybody is able to select an edge, extend a line, close a face, extrude a
rectangle. You don't need more than elementary geometry for that except... a
lot of manual work.

After using OpenSCAD for a little more than an year, my Sketchup
installation is outdated and unused. If you intend to do more than basic
cube and cylinder assembly in Sketchup without a enormous effort you will
have to find a plugin or write one yourself. But that means to write Ruby
code, deal with a enormous and confusing API and event oriented programming.
In short, you will have to divert a lot from your modelling focus.

What I found in OpenSCAD was the opposite. I am all the time concentrated in
my problem. And since geometric modelling is geometry, it is mathematics. In
the OpenSCAD world, again, if you only intend to assemble a few cubes and
cylinders, extrude a DXF, generate its stl file, you have support to do it.
But for me the main strength of OpenSCAD is to play with mathematical
objects. And in a mathematical framework.

I had not any previous experience with functional programming before. My
programming background was structured programming (anybody out there knows
what is that? :) ). I am still a Pascal programmer that tried reluctantly to
code in C and Ruby. But neither one fulfill my expectations. I would not
like to see the OpenSCAD language follow that roads. Now that I am about to
master list comprehension I don't want to step back.

I agree that OpenSCAD should be easy to learn but I think its main target
should be the more mathematical minded people. I have been writing a lot of
OpenSCAD code oriented to modelling with Bezier surfaces. I started a
experiment with f-rep, a modelling system based on implicity surface. Those
are examples of very powerful modelling framework but they require a good
mathematical background to be useful.

I feel some constraint in the OpenSCAD language possibly due to my limited
programming experience. What I would expect is a richer set of operators for
lists, first class functions and more efficiency both in the programming
interpretation and preview and render. I can live without mutable variables.

--
View this message in context: http://forum.openscad.org/feedback-on-C-style-for-tp17512p17521.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

A minor point I'd like to clarify, is when I speak of accessibility to
non-specialists, I'm talking about the more advanced programming aspects,
such as defining and using functions or list comprehensions.  There is no
question that ordinary geometry and modules are tremendously useful and
easily accessible.

When it comes to offset a polygon, or convert relative points to absolute,
what should be easy becomes a test of whether you understand tail recursion.

Opening up the programming aspects to non-specialists could expand creation
and sharing of operators (dilate, generate-mold, slice,
cleanup-non-manifold, voronoi-subdivide, or whatever).  As it is now, almost
all creation and sharing is of models, not operators.  With a proliferation
of operators, the designer who can't (or doesn't want to) write code could
see a lot of benefit too.

-Jamie

--
View this message in context: http://forum.openscad.org/feedback-on-C-style-for-tp17512p17540.html
Sent from the OpenSCAD mailing list archive at Nabble.com.