# feedback on "C-style for"

10 messages
Open this post in threaded view
|

## feedback on "C-style for"

 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
Open this post in threaded view
|

## Re: feedback on "C-style for"

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

## Re: feedback on "C-style for"

 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 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
Open this post in threaded view
|

## Re: feedback on "C-style for"

Open this post in threaded view
|

## Re: feedback on "C-style for"

Open this post in threaded view
|

## Re: feedback on "C-style for"

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

## Re: feedback on "C-style for"

Open this post in threaded view
|