My question falls right into this theme.  A few days ago I set out to write a
little function to compute the average of a vector. Thought everything would
be straightforward.

// average a vector
function avg(vec) {
sum = 0;
for (n=vec) sum = sum + n;
return sum / len(vec);
}

Surprise! This language doesn't have functions with curly braces, it has
functions with equal signs. Given that it has modules with curly braces,
this took me greatly by surprise. Now, as I read this thread, I see that the
issue goes much deeper than I realized.

So, please suggest to me how to write the avg function. PLEASE don't tell me
that recursion is the best approach; this feels about as pretty as using
pliers to do a screwdriver's job.

Suggestion on the side: I was surprised not to find sum() and avg() on the
list of built-in functions operating on vectors. I recommend adding them.
Surely they are trivial to implement!

Cheers,
Ken

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

Hi all,

OK, it’s this time of year again. I’ll be short and try to reiterate from earlier discussions:

First of all, the question “why” we have these “limitations” will become more clear once we start better exploiting the opportunities, as Alan hinted towards.

I admit:
o We need a “reduce” function to help collecting information depending on a list of input. Recursion is fine, but people tend to struggle with it and we could offer some help.
o We should probable disallow any attempt of reassignment, to make it more clear what’s going on. The only real reason we partially allow it is to allow cmd-line variable overrides.

To help think about things:
o Imagine every expression in OpenCAD being executed in parallel. Any dependency of existing expressions must be made explicit by hierarchical grouping. This will kill the idea of iterating in order to accumulate information.
o In terms of functions: Imagine a function expression being something you’d type into a spreadsheet cell. Not totally mappable, but it might help framing it.

Now, we could add all kinds of sugar to help people apply their existing programming problem solving skills. Question is more if it really helps us, secondary who will spearhead the design of such language extensions, as we currently don’t really have attachment for these ideas on the dev team.

If you think about the OpenSCAD language as something similar to HTML, but for 3D modeling, you’d still have a need for various programs generating code in this language (similar to the plethora of HTML generators out there). There exist a number of tools for helping with OpenSCAD code generation from existing programming languages (python, ruby, C++, haskell, clojure off the top of my head) and there are tools offering Javascript interfaces for similar purposes (OpenJSCAD, CoffeeSCAD). Until we have a really good reason to do so in OpenSCAD proper, and a really good candidate for which language to support, I think it’s better to keep these things separate.

Cheers,

-Marius