tp3 wrote

Would it be worth adding a simpler mechanism for passing existing functions?
It seems like the existing scheme creates two independent namespaces for
functions and it's sort of clumsy to get between them.  In MATLAB, for
example, you can pass an existing function by writing "@sin".  I can
imagine having to write code where I generate a table of function
redefinitions to make it easy to pass pre-existing functions without the
need for all the verbosity of a function declaration embedded in the code
for every call.

What would be the disadvantage of writing all of my functions using the new
syntax.  Would there be any problems with this?  So  always write

funcname = function(...) definition....;

This seems like it could be desirable since you can do something with a
function literal defined this way that you can't do with a regular function.
And there is no apparent advantage to defining functions the "normal" way.
I mean, the one obvious limitation is that I no longer have a different
namespace for functions if I do this.

--
Sent from: http://forum.openscad.org/

The issue is the old format functions have their own namespace,
separate from variables and modules so you can have the same name it all
three namespaces and there is no ambiguity. However new style function
literals are anonymous until you assign them to a variable and then that
variable is in the variable namespace, not the function namespace.

On Sat, 9 Nov 2019 at 15:03, adrianv avm4@cornell.edu wrote:

Yeah, I was aware of that.  But I don't think I'd really miss this.  In most
languages, functions don't get a separate namespace from variables, so it's
actually kind of an odd quirk of OpenSCAD.  I wonder if there are any other
issues I have overlooked, or relating to performance.

nophead wrote

--
Sent from: http://forum.openscad.org/

On 09.11.19 16:15, adrianv wrote:

Yes, that certainly is open for discussion. It might even be
possible to bind the built-in functions to the respective
names in the variable namespace.

As that is one layer up from the top layer available to the
user, it would still be possible to just overwrite those names
in existing code.

I believe the only non-compatible change is that you can
still observe this by "if (is_undef(sin))" on top level.

The other way around. Those separate namespaces already exist
and cause the issues now. The problem is that first class
functions obviously need to be in the variable namespace as
they are really just values.

Right now, the only disadvantage I'm aware of is that use<>
will not import them as they are variables, and use<> only
imports (old style) functions and modules.

That's something which needs to be changed of cause.

ciao,
Torsten.

Maybe but people like me would as I have made extensive use of it so
changing it would break a lot of code.

On Sat, 9 Nov 2019 at 15:47, Torsten Paul Torsten.Paul@gmx.de wrote:

I wasn't suggesting that the old syntax be removed.  Rather, I was pondering
how to write code in the future.  It appears like with the new function
syntax that it might make sense to always use the new one.  In other words,
to treat the old syntax like a sort of old-style method and abandon it.

Out of curiosity, is there some particular use case for using variables with
the same name as functions, or you just find it convenient to make variables
named "square" and "cube" and so on?

nophead wrote

--
Sent from: http://forum.openscad.org/

I often have code like this:

screw = iec_screw(type);

...

screw(screw, screw_length);

screw is both a local variable and a global module. Because it is local it
isn't really appropriate to give it a longer name, like the_screw or
iec_screw. If it was iec_screw then again it is the same name as a
function. In other languages I would have to think up a different name.

On Sat, 9 Nov 2019 at 17:49, adrianv avm4@cornell.edu wrote:

f = function(a)  a;
echo(f==f); // ECHO: false

???

OpenSCAD version 2019.10.25.ci3851 (git feee8f02)

Torsten Paul Torsten.Paul@gmx.de wrote: