[OpenSCAD] Openscad Indirect Functions

otto otto at 123phase.com
Mon Oct 17 16:26:03 EDT 2016

I have no problem with a "function" syntax, or a "lambda" syntax for
that matter:


Which has the advantage that a casual reader may catch on to the syntax
quicker, since the meaning of "lambda" and lambda functions have a
long history. 

I am willing to change the syntax in my test code to whatever if folks
are willing to commit to download install and try.  If
someone wants to use this capability now, then I am willing to
implement it in a way they like, so it can be tested in practice.   I am somewhat
concerned that my syntax will be passed by on the next newer and better
version of OpenScad and will be obsolete.  It seems that there is
very little work going on at the moment to expand the syntax.  That
speaks loads about the excellent quality of the current syntax and
code, since it is clearly being used widely. There are only a few
improvements that seem obvious to me, one being anonymous and indirect
functions.  This improvement is recommended do to actual need as
opposed to theoretical reasons.

I have forked/cloned the openscad system to a new repository at:


This is only for the sake of making it easy to download an compile
reliably. I am unfamiliar with github and the ethics of cooperation on
the open source site, so forgive me and inform me if this is the wrong
approach to getting new code into the world and tested.

Re namespaces:

I like the non-unified name spaces, although unconventional it works
for me. 

Torsten wrote:

> I don't think we have a problem at definition time,
> the trouble is where the data is passed to another
> function (or module).

He is absolutely right on this.

The "@" dereference operator is needed in order to
move a reference to a function from the non-function
namespace to an actual function in the function namespace.  Explicit
dereferencing is not necessarily bad and used extensively in other
languages. Unifying the namespaces discourages certain operations, and
encourages others, but in reality there are no common operations such as
"+" that have any meaning between objects in the seperate namespaces
of openscad. Objects in one namespace, do not move easily into the
others without some form of explicit conversion.

Note that: the meaning of:

>reduce = function(func,vec:
>    len(vec)==2 
          ? @func(vec[0],vec[1]) 
>         : @func(vec[0], at reduce(func,[for (i=[1:len(vec)-1]) vec[i]]))
>                  );
> echo(@reduce(function(x,y:x*y),[1,2,3,4,5]));

Is clear, and in my opinion even clearer if we use "@" both to declare
the anonymous function and to dereference since it impies our
intentions and directs us to to expect "reduce" to be used with the
dereference "@" when it is used.  I also like the compactness of "@"
over either "lambda" or "function".

>reduce = @(func,vec:
>    len(vec)==2 
          ? @func(vec[0],vec[1]) 
>         : @func(vec[0], at reduce(func,[for (i=[1:len(vec)-1]) vec[i]]))
>                  );
> echo(@reduce(@(x,y:x*y),[1,2,3,4,5]));

Personally, I see little advantage in merging the namespaces since the
current design works, is simple and easy to maintain and in addition
adding indirection is trivial.  Unifying the namespaces raises a
plethora of other issues. The only remaining issue is one of what the
syntax looks like, not what it does. 

Who else is working on the OpenScad C++/parser code here and what are
they doing?  I note that there are many places in the code marked with 

		// FIXME: <comment>

I hope to deal with a few of these as well.  Is anyone else working on

Current Test Code for:
reduce = @(func,vec:
     len(vec)==2 ? @func(vec[0],vec[1]) :
@func(vec[0], at reduce(func,[for (i=[1:len(vec)-1]) vec[i]]))

ECHO: 15
ECHO: 120
ECHO: -0.982406     


On Mon, 17 Oct 2016 04:58:38 -0700 (MST)
Richard Urwin <soronlin+openscad at googlemail.com> wrote:

> ottojas wrote
> > Here is an example of openScad code using the new syntax.
> > 
> > function reduce(func,vec) =
> >      len(vec)==2 ? @func(vec[0],vec[1]) :
> > @func(vec[0],reduce(func,[for (i=[1:len(vec)-1]) vec[i]])); 
> > 
> > echo(reduce(@(x,y:x+y),[1,2,3,4,5]));
> > echo(reduce(@(x,y:x*y),[1,2,3,4,5]));
> >      
> > cossin=@(x,y:sin(x)-cos(y));
> > echo(reduce(cossin,[1,2,3,4,5]));     
> >       
> > /**************************
> >      RESULT
> > ECHO: 15
> > ECHO: 120
> > ECHO: -0.982406     
> > **************************/  
> The @ in the indirect call is required for backwards compatibility
> but every other use of @ could be replaced by "function", making your
> code:
> function reduce(func,vec) =
>      len(vec)==2 ? @func(vec[0],vec[1]) :
> @func(vec[0],reduce(@func,[for (i=[1:len(vec)-1]) vec[i]])); 
> echo(reduce(function(x,y:x+y),[1,2,3,4,5]));
> echo(reduce(function(x,y:x*y),[1,2,3,4,5]));
> cossin=function(x,y:sin(x)-cos(y));
> echo(reduce(cossin,[1,2,3,4,5]));     
> To my mind, that is more readable.
> Then, if eventually the namespaces are merged, the @ could be
> deprecated and phased out.
> --
> View this message in context:
> http://forum.openscad.org/Convert-from-object-to-polygon-polyhedron-tp18522p18752.html
> Sent from the OpenSCAD mailing list archive at Nabble.com.
> _______________________________________________
> OpenSCAD mailing list
> Discuss at lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

More information about the Discuss mailing list