Convert from object to polygon/polyhedron.
Concerning the OpenSCAD2 proposal, otto wrote:
I have some reservations about the following:
- 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@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:
-
OpenSCAD2 is a backwards compatible redesign of OpenSCAD. The main
goals are expressive power and ease of use. -
Everything is a first class value (including functions, modules,
shapes, and objects).
I have some reservations about the following:
- 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.
-
Simple, consistent scoping rules eliminate a source of confusion.
---Agree -
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? -
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. -
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:
-
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. -
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). -
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:
-
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. -
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:
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:
2016-10-18 17:51 GMT-03:00 doug moen doug@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) = 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. :-)
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Otto wrote:
I see a major need for the following:
- The adoption and implementation of anonymous function syntax.
...
Doug proposes anonymous functions be written function(<arglist>) expr
The OpenSCAD2 proposal was written during May-July 2015. I've had a lot of
new ideas since then, but I mostly haven't updated the document, because it
was exhausting to write, and time considerations. Now I'm actually coding,
and trying to prototype some of the ideas. I'll write new documentation
once my design stabilizes.
My original 'function(arglist)expr' syntax was based on the old Javascript
syntax for anonymous functions. It turns out that when you try to use this
syntax for writing code, it sucks. That's probably why Javascript has
replaced this syntax with arrow notation. I'm using arrow notation now as
well. My syntax is actually identical to the new Java syntax for anonymous
functions, which uses -> (Javascript is the same except it uses =>).
My original proposed syntax is too verbose for short anonymous functions
like 'x->x+1', and if you want a long anonymous function, it might be
clearer to write a named function definition, as nop head suggested.
The other problem with my original syntax is that it sucks for curried
functions. The OpenSCAD2 proposal explains why curried functions are
important.
In arrow notation, you can write x->y->x+y, and that's a curried
function. In the originally proposed syntax, that would be
function(x)(function(y)x+y) which is a lot more verbose, and requires
nested parentheses. And you can't write a curried function at all using
Otto's @ notation (I've tried, the code doesn't work).
And you can't write a curried function
at all using Otto's @ notation (I've tried, the code doesn't work).
Doug is right. I tried it too and there is a bug in my code. I will
have to work on that.
f = @(x:@(y:x+y)); //Should work and doesn't.
Otto
On Sun, 23 Oct 2016 07:46:01 -0400
doug moen doug@moens.org wrote:
Otto wrote:
I see a major need for the following:
- The adoption and implementation of anonymous function syntax.
...
Doug proposes anonymous functions be written function(<arglist>)
expr
The OpenSCAD2 proposal was written during May-July 2015. I've had a
lot of new ideas since then, but I mostly haven't updated the
document, because it was exhausting to write, and time
considerations. Now I'm actually coding, and trying to prototype some
of the ideas. I'll write new documentation once my design stabilizes.
My original 'function(arglist)expr' syntax was based on the old
Javascript syntax for anonymous functions. It turns out that when you
try to use this syntax for writing code, it sucks. That's probably
why Javascript has replaced this syntax with arrow notation. I'm
using arrow notation now as well. My syntax is actually identical to
the new Java syntax for anonymous functions, which uses ->
(Javascript is the same except it uses =>).
My original proposed syntax is too verbose for short anonymous
functions like 'x->x+1', and if you want a long anonymous function,
it might be clearer to write a named function definition, as nop head
suggested.
The other problem with my original syntax is that it sucks for curried
functions. The OpenSCAD2 proposal explains why curried functions are
important.
In arrow notation, you can write x->y->x+y, and that's a curried
function. In the originally proposed syntax, that would be
function(x)(function(y)x+y) which is a lot more verbose, and
requires nested parentheses. And you can't write a curried function
at all using Otto's @ notation (I've tried, the code doesn't work).