discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

Function references

KM
Kuba Marek
Wed, Apr 13, 2016 8:22 PM

Hi,
I've been playing with OpenSCAD for a few days now and I found two
things that I really miss.

First is inability to pass functions as function parameters, the second
is inability to get vertex/faces data from children() call.

I'd like to try implementing these, starting with function references.

What I want to ask is how realistic this one seems to someone more
experienced with OpenSCAD internals and what's the workflow here for
changes like this? (Pull request to git once I'm done? Or pull request
without changes to discuss it first?).
With the function pointers I see a problem of it being a backwards
incompatible change; code like this:

function foo() = "bar";
foo = "baz";
echo(foo());
echo(foo);

would change meaning. How careful is OpenSCAD about breaking
changes like this? I didn't see anything similar to python's "from
future import something", did I just miss it or is there really no
such thing?

Thanks.

Hi, I've been playing with OpenSCAD for a few days now and I found two things that I really miss. First is inability to pass functions as function parameters, the second is inability to get vertex/faces data from children() call. I'd like to try implementing these, starting with function references. What I want to ask is how realistic this one seems to someone more experienced with OpenSCAD internals and what's the workflow here for changes like this? (Pull request to git once I'm done? Or pull request without changes to discuss it first?). With the function pointers I see a problem of it being a backwards incompatible change; code like this: function foo() = "bar"; foo = "baz"; echo(foo()); echo(foo); would change meaning. How careful is OpenSCAD about breaking changes like this? I didn't see anything similar to python's "from __future__ import something", did I just miss it or is there really no such thing? Thanks.
MK
Marius Kintel
Wed, Apr 13, 2016 9:01 PM

Hi,

On Apr 13, 2016, at 16:22 PM, Kuba Marek blue.cube@seznam.cz wrote:

I'd like to try implementing these, starting with function references.

There already exists a proposal for how this would fit into OpenSCAD.
Take a look here (warning: it’s quite a long document): https://github.com/doug-moen/openscad2

So far, we’ve approached this topic by trying to implement one feature at a time from this proposal. Some of the features do require deep refactoring.
I think Doug would be better able than me to evaluate the realism of implementing function references and how deep that rabbit hole goes.

-Marius

Hi, > On Apr 13, 2016, at 16:22 PM, Kuba Marek <blue.cube@seznam.cz> wrote: > > I'd like to try implementing these, starting with function references. > There already exists a proposal for how this would fit into OpenSCAD. Take a look here (warning: it’s quite a long document): https://github.com/doug-moen/openscad2 So far, we’ve approached this topic by trying to implement one feature at a time from this proposal. Some of the features do require deep refactoring. I think Doug would be better able than me to evaluate the realism of implementing function references and how deep that rabbit hole goes. -Marius
DM
doug moen
Thu, Apr 14, 2016 2:20 AM

Kuba said "How careful is OpenSCAD about breaking
changes like this? I didn't see anything similar to python's "from
future import something", did I just miss it or is there really no
such thing?"

There is no such thing in the language right now. What we sometimes do is
put configuration switches into the Preferences for enabling experimental
new language features. This preferences are typically used in developer
releases, and removed in major releases. I don't think that's adequate for
a change as big as unifying the function, module and variable namespaces
into a single namespace.

If we wanted to use the Python strategy, then we could introduce a new
syntax like
use single_namespace;
to specify that the current script uses a single namespace for variables,
functions and modules. Of course, this means that if we introduce a
built-in sort() function with an optional comparison function argument, or
if somebody creates a library module with a function argument, then you'll
need to write 'use single_namespace;' in order to use those new APIs.

The other part of the Python strategy is that, in some future release, the
single namespace becomes default behaviour, and you get a single namespace
even without using that syntax. The down side of this is that old scripts
on Thingiverse, github, and elsewhere will bit decay and eventually stop
working.

The OpenSCAD2 document proposes a different backwards compatibility
strategy, one that doesn't require 'use single_namespace;' in order to use
new built-in or library modules that use function arguments, and one that
preserves backwards compatibility for old scripts indefinitely, but
frankly, it's kind of a one-shot deal, and is a lot more difficult to
implement.

Kuba said "How careful is OpenSCAD about breaking changes like this? I didn't see anything similar to python's "from __future__ import something", did I just miss it or is there really no such thing?" There is no such thing in the language right now. What we sometimes do is put configuration switches into the Preferences for enabling experimental new language features. This preferences are typically used in developer releases, and removed in major releases. I don't think that's adequate for a change as big as unifying the function, module and variable namespaces into a single namespace. If we wanted to use the Python strategy, then we could introduce a new syntax like use single_namespace; to specify that the current script uses a single namespace for variables, functions and modules. Of course, this means that if we introduce a built-in sort() function with an optional comparison function argument, or if somebody creates a library module with a function argument, then you'll need to write 'use single_namespace;' in order to use those new APIs. The other part of the Python strategy is that, in some future release, the single namespace becomes default behaviour, and you get a single namespace even without using that syntax. The down side of this is that old scripts on Thingiverse, github, and elsewhere will bit decay and eventually stop working. The OpenSCAD2 document proposes a different backwards compatibility strategy, one that doesn't require 'use single_namespace;' in order to use new built-in or library modules that use function arguments, and one that preserves backwards compatibility for old scripts indefinitely, but frankly, it's kind of a one-shot deal, and is a lot more difficult to implement.