otto otto at 123phase.com
Thu Oct 20 21:21:43 EDT 2016

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:

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:
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:

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

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. :-)
> >
> > _______________________________________________