otto said:

I just finished implementing this functionality myself. Here are some
things I would include in a thorough set of unit tests:

• builtin functions like sin can be referenced as function values
• "closures" work correctly. If a function references a non-local variable
  X, then X retains its value within the body of the function, even if the
  function value outlives the scope of X.
• recursively defined functions don't cause a storage leak. This is a
  problem when you are using reference counting, and you implement closures
  in "the obvious way": recursive functions lead to a reference cycle, which
  causes a storage leak. It took me a while to figure out how to fix this.

Doug.

On 18 October 2016 at 01:37, otto otto@123phase.com wrote:

nophead wrote

I disagree. There are places where a lambda is better fitted. For
example, a temporary, quick handler like that in array.map( x=> x+2 ).
The need of making a named function for this purpose actually makes
the code more complicated and harder to write.

Personally, I don't mind what syntax to use. As long as the feature is
there, I'll just adopt to it. Besides, nothing can please everybody.
The important thing is to have it available for people who want it. For
those who don't, then simply don't use it. I don't think it's gonna hurt.

$  Runsun Pan, PhD $ libs: doctest , faces ( git ), offline doc ( git ), runscad.py ( 2 , git ), synwrite ( 2 );   $ tips: hash ( 2 ), matrix ( 2 , 3 ), sweep ( 2 , 3 ), var ( 2 ), lerp , animation ( gif , prodVid , animlib ), precision ( 2 ), xl-control , type , rounded polygon , chfont , tailRecur ( 2, 3 ), isosphere ( 2 ), area , vol/center , RGB , CurvedImg , tests ( 2 ); $ Apps: rollApp , blockscad , openjscad , on AWS ( pdf )

View this message in context: http://forum.openscad.org/Convert-from-object-to-polygon-polyhedron-tp18522p18769.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

doug.moen wrote

Good points.

$  Runsun Pan, PhD $ libs: doctest , faces ( git ), offline doc ( git ), runscad.py ( 2 , git ), synwrite ( 2 );   $ tips: hash ( 2 ), matrix ( 2 , 3 ), sweep ( 2 , 3 ), var ( 2 ), lerp , animation ( gif , prodVid , animlib ), precision ( 2 ), xl-control , type , rounded polygon , chfont , tailRecur ( 2, 3 ), isosphere ( 2 ), area , vol/center , RGB , CurvedImg , tests ( 2 ); $ Apps: rollApp , blockscad , openjscad , on AWS ( pdf )

View this message in context: http://forum.openscad.org/Convert-from-object-to-polygon-polyhedron-tp18522p18770.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

On 18 October 2016 at 22:35, runsun runsun@gmail.com wrote:

How is it hard or complicated to write a named function add2(x) = x + 2; ?

Anybody that knows how to write an OpenScad function can do it and the
result is more readable, it is just a bit more verbose, but not much.

It means OpenSCAD code becomes a little harder to read for people that have
not come across lambda before. Its syntax becomes more complex but there
isn't anything new that can be done with it. It becomes a slightly bigger
language to learn.

It also means OpenSCAD needs more maintenance as its code gets a bit bigger
and there needs to be a more test cases. Fine for indirect functions
because they add power but lambda doesn't. It is just a slight shortcut
that saves you thinking up a name. Unless some optimisation is done it
leads to code duplication because once a named function is written it can
be used multiple times.

On Tue, 18 Oct 2016 23:52:33 +0100
nop head nop.head@gmail.com wrote:

No harder than it would be to require that arithmetic expressions can
only be written in functions.

Just like it can be handy to have an arithmetic expression in-line,
sometimes having a function in-line is clearer than the alternative.

G. Wade

--
You write code as if the person who will maintain your code is a violent
psychopath who knows where you live.              -- John F. Woods

nophead wrote

Well, when you write the code up to the point of "arr.map(...", you have
to leave the code and move to another place to write "function add2(x) = x +
2;",
then move back to complete it.

With lambda, you finish the code right there, don't have to switch places.

This is the same for code reader. When a reader reads the code to that
point, he/she has to first search and locate that function, then switch to
there to understand it, then switch back to continue. That's a lot of
distractions for such a simple task.

This is what I call brain twists, an unnecessary detour or distraction
to your coding focus. IMO, a good language should reduce these sorts of
"brain twists" as much as possible.

Taking python/javascript as example. To get the last item in an array,
you do 'arr[-1]' in python. It is straight forward and, as the "-" indicates
a "count from reversed direction", it feels natural. But in javascript,
you have to use other approaches, like 'arr[arr.length-1]', or
'arr.slice(-1)[0]'.
Yes, it's "just a little bit verbose", but it is an unnecessary "brain
twist"
that can be avoided.

Besides, if a language is designed with this "just a little bit verbose"
mentality,
then all the little bits finally adds up and results in a verbosity that's
never be
"just a little".

Python is designed with less brain twist that's why it's considered more
natural
and one of the easiest to learn for beginners.

The above statements you made here applies to ANY new feature, thus are
not valid arguments when discussing a specific feature.

$  Runsun Pan, PhD $ libs: doctest , faces ( git ), offline doc ( git ), runscad.py ( 2 , git ), synwrite ( 2 );   $ tips: hash ( 2 ), matrix ( 2 , 3 ), sweep ( 2 , 3 ), var ( 2 ), lerp , animation ( gif , prodVid , animlib ), precision ( 2 ), xl-control , type , rounded polygon , chfont , tailRecur ( 2, 3 ), isosphere ( 2 ), area , vol/center , RGB , CurvedImg , tests ( 2 ); $ Apps: rollApp , blockscad , openjscad , on AWS ( pdf )

View this message in context: http://forum.openscad.org/Convert-from-object-to-polygon-polyhedron-tp18522p18773.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

On Tue, Oct 18, 2016 at 04:51:04PM -0400, doug moen wrote:

Most importantly, I WOULD confuse => and >= . (i.e. I might write =>
where >= was intended, less likely the other way around).

Roger. 

--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
-- BitWizard writes Linux device drivers for any device you may have! --
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

2016-10-18 17:51 GMT-03:00 doug moen doug@moens.org:

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) = xxx

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

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@gmail.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:

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@moens.org wrote: