On 16. okt. 2016 20:56, adrian wrote:

Double colon is precisely what some other languages use. It makes sense.

Carsten Arnholm

Or another option (fairly usable):
What about keeping separate function namespace for backwards
compatibility and introducing JavaScript-ish lambdas that exist in
variable namespace?

Usage example:

f = function(a, b) a + b;

instead of

function f(a, b) = a + b;

This should be easy to parse, make functions behave in a familiar way
for people coming from other languages and add lambdas as a bonus.

Kuba

Python likes:

lambda x: x+2

For anonymous syntax.

Lisp likes

(lambda (x) (+ arg 2))

For same operation.  I don't particularly like either construct but
either could be implemented.

I have now implemented

@(x:x+2)

in my prototype system.  It works just as well as the

function @<tok_id>(<arglist>)=<expr>

I tried earlier.

It is completely compatible with mixed name spaces and breaks no
earlier code.

If you wish to assign the function to a variable in the main name space
it can be done.  Dereferencing is done with the "@" symbol as well.

Any (almost) of the suggested syntaxes is easy to add to openScad.  The
(bison) parser works nearly flawlessly and was neatly programmed.  I
have had no trouble hacking the code.

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
**************************/

For me, Openscad1.1 is much more interesting than openScad 2.0..
That is, I do not believe that any changes should break previous code.
I have not yet posted the new code to github, but this time I will do so
as a complete clone of the current system in order to make it easier to
test.

For me, to make my work possible, I wanted a system that implemented
some new functionality but in which I could have confidence that code
written by others continues to work.

I think the explicit dereferencing is better than a check during
compilation or execution and easier to implement and maintain.  I am
also considering the same kind of syntax for an anonymous module, where
an address can be passed around in a normal variable and dereferenced
when needed.  I considered @f() for functions and @m() for modules but
choose in my current prototype to use "@" unmodified.  Hacking the code
to support modules is more difficult and currently I have not started
trying, so I have no idea just how much I would be biting off.  Any
syntax for indirect functions is fairly easy for me at this point with
my current understanding of the code.

I have no intention of breaking any current code which means of course,
maintaining the separation of the name spaces.  When I get a clone of
the system set up for prototyping, I will add this kind of functionality
as I develop it and if people want it added to the base system they can
lobby for that or simply use the cloned/modified version.

Regards
Otto

On Sun, 16 Oct 2016 13:34:00 -0700 (MST)
Richard Urwin soronlin+openscad@googlemail.com wrote:

Von: "Kuba Marek" blue.cube@seznam.cz

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

E.g (ignoring modules completely for now).

f = 6;
function f(x) = 1;
function call_indirect(func, x) = func(x);

call_indirect(f); // is that the variable or function?

As we don't have types, we can't easily infer which
of the 'f' thingies is supposed to be passed to the
call_indirect() function.

To clarify which one is meant, we either have to use a
unified namespace, or have the user declare explicitely
which of the namespaces too choose from.

ciao,
Torsten.

In my proposal this code would behave exactly as it does now and pass
the value 6.
If you wanted to pass the function, the example would have to look like
this:

// f = 6; // With this line the next one would cause an error
f = function f(x) 1;
call_indirect(f);

This is exactly what would be happening -- by using the lambda syntax
instead of the existing syntax you would be saying "this is a
variable with function as a value" instead of "this is a function"

Kuba

ottojas wrote

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.