[OpenSCAD] Openscad Indirect Functions

doug moen doug at moens.org
Sat Oct 22 19:20:21 EDT 2016


Concerning the OpenSCAD2 proposal, otto wrote:

> I have some reservations about the following:
>
> 3.  Single unified namespace (instead of separate namespaces for
> variables, functions and modules).
> ---This would break some older programs.
>

OpenSCAD2 is backwards compatible with OpenSCAD, *and* it optionally allows
you to write scripts that use a single unified namespace. But the original
three-namespace dialect still works and is still supported. Those are
primary design goals.

If we discover backward compatibility problems during implementation, we'll
just treat those as bugs, and fix the bugs by tweaking the design.

The way OpenSCAD2 achieves these goals is by supporting two dialects: a
single-namespace dialect, and a 3-namespace dialect. The compiler
determines which dialect is used by a script by looking at the syntax of
function and module definitions. If the original function and module
definition syntax is used, it's the 3 namespace dialect. If the new syntax
is used, it's the one-namespace dialect. In the one-namespace dialect, a
function definition looks like this:
```
f(x) = x + 1;
```
Just like the 3-namespace syntax except that the word `function` is omitted.

There's no reason why the 3-namespace dialect can't be extended to support
namespace qualifiers that are appended to identifiers. There might be
technical reasons why this extension might be necessary, relating to
backward compatibility with old code. Also, there seem to be people who
would prefer this style of programming to using a single namespace. That's
cool too. We can support both styles in the same language.

On 20 October 2016 at 21:21, otto <otto at 123phase.com> wrote:

>
> There are several symbols commonly used to express a mapping, see:
>
> http://mathinsight.org/function_notation
>
> and
>
> http://mathworld.wolfram.com/Function.html
>
> The simple arrow is a statement about a range and a domain, it does
> not define the function.  It looks something like this -->   In TeX
> (or LaTeX) use the symbol \rightarrow.
> In order to define a function sometimes the arrow symbol has a vertical
> mark at the beginning, something like this |-->   In TeX use the symbol
> \mapsto.
>
> The \rightarrow alone should not be used to define a function in a math
> textbook, even at high school level, since it is not common usage.  If
> one wants to define a function using an arrow, the \mapsto is the
> correct symbol.  A much more common way to define a function is the
> f(x)=x*x type usage both in languages and math books.
>
> The statement:
> > > The arrow is used pointing to a SET that contains all possible
> > > answers for the function, but does not specify what is the answer
> > > for a partigular input.
> is correct.
>
> We are not writing mathematics with openscad.  We are programming, and
> any new syntax should follow rules established in older programming
> languages and that are in common usage in order to make our new language
> more learnable and easier to maintain.  From my point of view defining a
> function is best done with a syntax ... f(x)=x*x .... type
> expression.
>
> Python:
>         def f(x):
>             return x*x
>
> C/C++:
> <return type> f(x){ return x*x; }
>
> scheme:
>   (define f (lambda (x)  (* x x)))
>
> ruby:
> def f(x)
>    return x*x
> end
>
> My takeaway from this is that most programmers and users just
> learning this language, will expect a function definition, even in a new
> language, to contain a part naming the function followed by
> parenthesis, followed by an argument list. This
> is true of all of the languages mentioned, so unless there is some
> really compelling reason to use a different form of syntax, that is
> that provides a dramatic increase in either the power of the language or
> its ease of use, I think we should stick to the current
> notation. All of the above are easy and similar to openscads current
> technique:
>
> openscad:
>
> function f(x)=x*x;
>
> If openscad is a first programming language, as it will be for
> some, learning a traditional style syntax will allow skills to be more
> easily applied in future systems.  I particularly dislike the arrow
> syntax because of its easy confusion with the C dereferencing operator
> "->".
>
> Doug Moens proposal at:
> https://github.com/doug-moen/openscad2
> Contains a number of excellent ideas and represents the only document
> that I could find at this point that presents a clear vision of one
> direction in which OpenScad can grow.
>
> In particular I agree with the following:
>
> 1. OpenSCAD2 is a backwards compatible redesign of OpenSCAD. The main
> goals are expressive power and ease of use.
>
> 2. Everything is a first class value (including functions, modules,
> shapes, and objects).
>
> I have some reservations about the following:
>
> 3.  Single unified namespace (instead of separate namespaces for
> variables, functions and modules).
> ---This would break some older
> programs.  I think that we can begin to unify the name spaces and
> simply depreciate the older syntax.  Doug proposes anonymous functions
> be written function(<arglist>) expr
>
> Given a function call such as x(z), we could check the old name space
> for a function with the name "z"; if it is found we execute the
> function "z".  If it is not found we check the variable namespace for
> a variable with the name "z", if it is not found, it is an error.  If
> it is found we check the contents of the "z" variable in the function
> namespace.  The values assigned to anonymous functions cannot be
> created with the old function type definition in our new system.  This
> is how the system using the "@" syntax I wrote works. The issue is that
> a new, anonymous function that has been assigned a new name that
> conflicts with an old name will never be executed.  That is one reason
> why I prefer to explicitly dereference variables in function calls.  I
> guess we could allow both explicit and implicit dereferencing and
> attempt to depreciate the old function definition technique, but I am
> afraid that that would lead to confusion and difficulty finding errors
> in new code.  Old code would work as expected.
>
> 4. Simple, consistent scoping rules eliminate a source of confusion.
> ---Agree
>
> 5. OpenSCAD reports errors in more situations where something goes
> wrong.  This makes bugs easier to diagnose.
> ---Agree  Openscad should also issue more warnings.  "x=3; ... x=4;"
> should generate a warning.  Would break
> anything already out there if we made the construct illegal?
>
> 6. Backwards compatibility mode for old scripts that rely on 3
> namespaces and old scoping rules.
> ---Old rules should be the default mode.  Any other modes need massive
> justification in my opinion.
>
> 7.  New syntax for function & module definitions, use and include,
> required to support new semantics while preserving backwards
> compatibility.
> ---Old syntax must continue to work.
>
> Objects result from treating scripts as first class values, and add a
> lot of new expressive power.
> ---Openscad should be extended to support objects explicitly and allow
> them to be passed back and forth in the main name space.  We do not
> have to abandon the multiple name spaces in order to achieve this.
>
> I see a major need for the following:
>
> 1. The adoption and implementation of anonymous function syntax.  The
> major issue here is adoption and syntax.  We know this can be
> implemented in hours, not days.
>
> 2. Making an anonymous module in which we can explicitly assign the
> module to a variable and dereference the module when we wish to have it
> rendered.  (working on it when I have time).
>
> 3. The ability to render a module to a polygon/polyhedron set
> consisting of its points and faces as is used in the call to
> polyhedron.  The rendering would not be part of the top level geometry
> but would simply return the list of points and faces.
> (working on it when I have time).
>
> I see a minor need for the following:
>
> 1. Native affine functions:  I use a list of a (3X3) matrix and a 3
> vector to represent an affine transform.  In CGAL they provide some
> nice affine functions and routines.  I have implemented the inverse
> affine and some others in my affine.scad library, but making these a
> native type would allow the use of the * binary operator to combine
> transforms and transform vectors and would make the operations faster.
>
> 2. Extension of the hull function to accept a set of points instead of
> requiring objects containing both points and faces.
> (working on it when I have time.)
>
> A long term goal:
>
> A better integration between opescad and cgal that would allow for
> some of the more exotic cgal libraries to be compiled from CGAL and
> imported into openscad.  How to implement this is not clear.  A general
> technique of including or using compiled code with new functionality
> would be great.  One of the great things about python is that this is
> an implemented feature.
>
> All of the above should be achievable.
>
>
>
> Regards
> Otto
>
>
>
>
>
>
>
>
>
> On Thu, 20 Oct 2016 12:08:53 -0400
> doug moen <doug at moens.org> wrote:
>
> > In my high school algebra text book, the → is used exactly as I have
> > described. Here's a quote from an exercise:
> >
> > In f : x → x², x ∈ R, what is the image of 2?
> >
> > Citation:
> > http://www.mathhelp.com/how_to/functions/function_and_arrow_notation/
> >
> > The → is *also* used when describing the domain and range of a
> > function, eg f : R→R.
> >
> > Citation: http://mathworld.wolfram.com/Function.html
> >
> > So I think → notation for functions is common and well understood in
> > high school classrooms.
> >
> > On 19 October 2016 at 09:44, Lucas Vinicius Hartmann <
> > lucas.hartmann at gmail.com> wrote:
> >
> > > 2016-10-18 17:51 GMT-03:00 doug moen <doug at moens.org>:
> > >
> > >> The → symbol is what's used in mathematics to describe functions,
> > >> eg f : x → x².
> > >>
> > >
> > > I am not really sure, but If I remember correctly the usage of the
> > > arrow in math is not exactly that. It describes a property of the
> > > function, not the function itself.
> > >
> > > The arrow is used pointing to a SET that contains all possible
> > > answers for the function, but does not specify what is the answer
> > > for a partigular input. Basically it is equivalent to the return
> > > type of a function prototype in C/C++.
> > >
> > > If, for instance, we have a cubic function given by
> > >
> > > f(x) = x*x*x
> > >
> > > Then f(x) may return any real number, so the result set is all real
> > > numbers.
> > >
> > > f(x) -> R     (Imagine the stylish R for real numbers here)
> > >
> > > If f2(x) was a square function, then only positive real numbers
> > > could be returned, so...
> > >
> > > f2(x) -> R+
> > >
> > > That said, the usage of arrows in openscad or programming languages
> > > is up to the developers. :-)
> > >
> > > _______________________________________________
> > > OpenSCAD mailing list
> > > Discuss at lists.openscad.org
> > > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
> > >
> > >
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20161022/a33c3b57/attachment-0002.html>


More information about the Discuss mailing list