feedback on "C-style for"

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

feedback on "C-style for"

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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: feedback on "C-style for"

Ronaldo
I agree this allows to more concise code. But, why would only mutable variable assignment have such a distinct privilege?
Reply | Threaded
Open this post in threaded view
|

Re: feedback on "C-style for"

doug.moen
Pattern matching assignment is useful everywhere. (But my post was about "C style for", and I didn't want to digress.)

The other place I would find it particularly useful (in my code, at least) is for functions that take [x,y,z] points as arguments. Eg,

function f([x,y,z]) = ...;

f([0, 10, 10])



On 1 June 2016 at 16:27, Ronaldo <[hidden email]> wrote:
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.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: feedback on "C-style for"

wolf
"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.
Reply | Threaded
Open this post in threaded view
|

Re: feedback on "C-style for"

MichaelAtOz
Administrator
wolf wrote
"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."
Well said.
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.
I disagree here.
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.
+1
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.
Worth considering. Really need to solve the overriding of 'identifiers' (currently called variables) set in an include<> tho. Also fix command line '-D var'.
2. introduce genuine variables (==mutable constants), as pointed out in <https://github.com/openscad/openscad/wiki/Mutable-Variables>
Still not for Frankenstein... also IMO "parallel, pattern matching assignment statement" is just another head bolted on. I'm sure we all have "gee, it would be nice to" have's, then suddenly the language explodes like a multi-tool with everything open...

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.
Yes, keep OpenSCAD easy for beginners; while I'm an experienced coder and can read most languages, I found the transition to OpenSCAD very easy and hope it stays relatively uncomplicated for future newcomers.
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.
50/50
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.
+1
Introduce genuine (==mutable) variables.
-1
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.
Admin - email* me if you need anything, or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.
Reply | Threaded
Open this post in threaded view
|

Re: feedback on "C-style for"

Jamie_K
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.
Reply | Threaded
Open this post in threaded view
|

Re: feedback on "C-style for"

Ronaldo
@ 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.
Reply | Threaded
Open this post in threaded view
|

Re: feedback on "C-style for"

cacb
In reply to this post by Jamie_K
On 2016-06-02 06:04, Jamie_K wrote:

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

Agreed. This is common sense.

I don't understand how the argument for a "functional" language follows
from the objective of ease of use for beginners, except for trivial code
which is really equally trivial in any language, "functional" 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.

This is true, it can defeat the noble objective of OpenSCAD being
accessible to non-specialists.

About a year ago on this list, I stated that I thought the focus of
OpenSCAD was too much on language definition compared to other
functionality, and that this follows from the fact that OpenSCAD defines
it own language syntax. To me, it seems this is still the case.

Carsten Arnholm

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: feedback on "C-style for"

tp3
On 06/02/2016 01:50 PM, [hidden email] wrote:
> This is true, it can defeat the noble objective of OpenSCAD
> being accessible to non-specialists.
>
It *is* used by non-specialists, looking at the various post
all over the internet. I believe it certainly should stay that
way. I don't think that means it's impossible to add some more
advanced features.

> About a year ago on this list, I stated that I thought the
> focus of OpenSCAD was too much on language definition
> compared to other functionality, and that this follows from
> the fact that OpenSCAD defines it own language syntax. To me,
> it seems this is still the case.
>
Based on what? There's quite some discussion on the list here,
and that's good. It's a big topic, so seeing different viewpoints
is nice. The work Doug does in writing down the ideas and
driving the discussion is just awesome.

As far as development goes, looking at the github history,
there's only a very very tiny effort to already include some
of the ideas that fit nicely into the existing code.

So I see only one "problem", the wishlist is very long compared
to the available development power. But that's just how things
tend to go with open source projects. There's a number of nice
things waiting to be finished, it's just taking time...

ciao,
  Torsten.



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: feedback on "C-style for"

Jamie_K
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