On 15. okt. 2016 00:58, Parkinbot wrote: > nice: : > >> a = 10; >> a(); >> module a(){ >> a = a; >> echo(a); >> echo(a()); >> a(); >> function a() = 20; >> >> module a(){ >> a = a; >> echo(a); >> echo(a()); >> function a() = 20; >> } >> } > Very good! Everything is obvious from the context, right? The problem is implicit, but separate namespaces for variables, functions and modules. It is confusing to the human reader, such code will lead to unexpected results. It doesn't matter if the compiler is 'right' if the user expects something else. This kind of confusion is best avoided (IMHO), and in several other languages it is an error (example below). My first idea would be to use an existing front end language with such issues already handled instead of inventing a new one for OpenSCAD, but since that is too late perhaps one may at least consider what other languages do to resolve such issues. Perhaps in OpenSCAD one could make explicit that 3 namespaces always exist, for example: variables : where variable names exist functions : where function names exist modules : where module names exist As long as all symbols used in the OpenSCAD user code are unique across namespaces, there are no issues and all is working as before. However, once the same symbol names appear in different namespaces, a warning could be issued. To remove the warning, the user would use other names or alternatively use explicit namespace prefixing to make the interpretation clear, for example: a = 10; modules::a(); module a(){ a = a; echo(a); echo(functions::a()); modules::a(); function a() = 20; module a(){ a = a; echo(a); echo(functions::a()); function a() = 30; } } The fact that modules can be nested, makes it even more confusing to a reader, the prefixes are supposed to be local in this example. To compare, I just did a small test. The following code (some irrelevant code not shown) causes errors in C++ and AngelScript because of name resolution issues as in your OpenSCAD example. First code line is line 4: double a = 10; double a() { return 20; } void language_test() { print(a()); print(' '); print(a); } Tryng it with 2 C++ compilers and the AngelScript interpreter gave consistent errors: MSVC2013 C++ (windows): main.cpp(5) : error C2365: 'a' : redefinition; previous definition was 'data variable' main.cpp(8) : error C2064: term does not evaluate to a function taking 0 arguments GNU g++ (linux): main.cpp:5:10: error: ‘double a()’ redeclared as different kind of symbol main.cpp:8:12: error: ‘a’ cannot be used as a function Angescript: asERR : (line 5, col 1) : Name conflict. 'a' is a global property. However, when introducing an explicit namespace, all are ok: double a = 10; namespace functions { double a() { return 20; } } void language_test() { print(functions::a()); print(' '); print(a); } the output is : 20 10 As always, this is just food for thought. Regards Carsten Arnholm

Yes but I choose to use OpenScad to design my 3D objects, not C++ (which I know) or Angel script (which I don't). I like it as it is now. There is never ambiguity because if it doesn't have parenthesis after it it is a variable, if it does it is a function if it is in an expression and a module otherwise. I don't see how that is confusing. On 15 October 2016 at 11:30, Carsten Arnholm <arnholm@arnholm.org> wrote: > On 15. okt. 2016 00:58, Parkinbot wrote: > >> nice: : >> >> a = 10; >>> a(); >>> module a(){ >>> a = a; >>> echo(a); >>> echo(a()); >>> a(); >>> function a() = 20; >>> >>> module a(){ >>> a = a; >>> echo(a); >>> echo(a()); >>> function a() = 20; >>> } >>> } >>> >> >> > Very good! Everything is obvious from the context, right? > > The problem is implicit, but separate namespaces for variables, functions > and modules. It is confusing to the human reader, such code will lead to > unexpected results. It doesn't matter if the compiler is 'right' if the > user expects something else. This kind of confusion is best avoided (IMHO), > and in several other languages it is an error (example below). > > > My first idea would be to use an existing front end language with such > issues already handled instead of inventing a new one for OpenSCAD, but > since that is too late perhaps one may at least consider what other > languages do to resolve such issues. > > Perhaps in OpenSCAD one could make explicit that 3 namespaces always > exist, for example: > > variables : where variable names exist > functions : where function names exist > modules : where module names exist > > As long as all symbols used in the OpenSCAD user code are unique across > namespaces, there are no issues and all is working as before. However, once > the same symbol names appear in different namespaces, a warning could be > issued. To remove the warning, the user would use other names or > alternatively use explicit namespace prefixing to make the interpretation > clear, for example: > > a = 10; > modules::a(); > module a(){ > a = a; > echo(a); > echo(functions::a()); > modules::a(); > function a() = 20; > > module a(){ > a = a; > echo(a); > echo(functions::a()); > function a() = 30; > } > } > > The fact that modules can be nested, makes it even more confusing to a > reader, the prefixes are supposed to be local in this example. > > > > To compare, I just did a small test. The following code (some irrelevant > code not shown) causes errors in C++ and AngelScript because of name > resolution issues as in your OpenSCAD example. First code line is line 4: > > > double a = 10; > double a() { return 20; } > void language_test() > { > print(a()); > print(' '); > print(a); > } > > > Tryng it with 2 C++ compilers and the AngelScript interpreter gave > consistent errors: > > MSVC2013 C++ (windows): > main.cpp(5) : error C2365: 'a' : redefinition; previous definition was > 'data variable' > main.cpp(8) : error C2064: term does not evaluate to a function taking 0 > arguments > > GNU g++ (linux): > main.cpp:5:10: error: ‘double a()’ redeclared as different kind of symbol > main.cpp:8:12: error: ‘a’ cannot be used as a function > > Angescript: > asERR : (line 5, col 1) : Name conflict. 'a' is a global property. > > > > However, when introducing an explicit namespace, all are ok: > > double a = 10; > namespace functions { double a() { return 20; } } > void language_test() > { > print(functions::a()); > print(' '); > print(a); > } > > the output is : 20 10 > > As always, this is just food for thought. > > Regards > Carsten Arnholm > > > > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

The whole idea of having separate namespaces for functions and variables is slightly confusing for me. I understand how it works, but I still find the "a" example incomprehensible. OpenSCAD calls itself functional language and having functions just be variable with function value is fairly standard in these. When I started with OpenSCAD, separate namespaces were the biggest hassle I encountered. If keeping the backwards compatibility was too important, then I would vote for "@" dereferencing a string expression to a function call (so that `@"f"()` behaves exactly like `f()`. Kuba > Yes but I choose to use OpenScad to design my 3D objects, not C++ > (which I know) or Angel script (which I don't). I like it as it is > now. There is never ambiguity because if it doesn't have parenthesis > after it it is a variable, if it does it is a function if it is in an > expression and a module otherwise. I don't see how that is confusing. > > On 15 October 2016 at 11:30, Carsten Arnholm <arnholm@arnholm.org> > wrote: > > > On 15. okt. 2016 00:58, Parkinbot wrote: > > > >> nice: : > >> > >> a = 10; > >>> a(); > >>> module a(){ > >>> a = a; > >>> echo(a); > >>> echo(a()); > >>> a(); > >>> function a() = 20; > >>> > >>> module a(){ > >>> a = a; > >>> echo(a); > >>> echo(a()); > >>> function a() = 20; > >>> } > >>> } > >>> > >> > >> > > Very good! Everything is obvious from the context, right? > > > > The problem is implicit, but separate namespaces for variables, > > functions and modules. It is confusing to the human reader, such > > code will lead to unexpected results. It doesn't matter if the > > compiler is 'right' if the user expects something else. This kind > > of confusion is best avoided (IMHO), and in several other languages > > it is an error (example below). > > > > > > My first idea would be to use an existing front end language with > > such issues already handled instead of inventing a new one for > > OpenSCAD, but since that is too late perhaps one may at least > > consider what other languages do to resolve such issues. > > > > Perhaps in OpenSCAD one could make explicit that 3 namespaces always > > exist, for example: > > > > variables : where variable names exist > > functions : where function names exist > > modules : where module names exist > > > > As long as all symbols used in the OpenSCAD user code are unique > > across namespaces, there are no issues and all is working as > > before. However, once the same symbol names appear in different > > namespaces, a warning could be issued. To remove the warning, the > > user would use other names or alternatively use explicit namespace > > prefixing to make the interpretation clear, for example: > > > > a = 10; > > modules::a(); > > module a(){ > > a = a; > > echo(a); > > echo(functions::a()); > > modules::a(); > > function a() = 20; > > > > module a(){ > > a = a; > > echo(a); > > echo(functions::a()); > > function a() = 30; > > } > > } > > > > The fact that modules can be nested, makes it even more confusing > > to a reader, the prefixes are supposed to be local in this example. > > > > > > > > To compare, I just did a small test. The following code (some > > irrelevant code not shown) causes errors in C++ and AngelScript > > because of name resolution issues as in your OpenSCAD example. > > First code line is line 4: > > > > > > double a = 10; > > double a() { return 20; } > > void language_test() > > { > > print(a()); > > print(' '); > > print(a); > > } > > > > > > Tryng it with 2 C++ compilers and the AngelScript interpreter gave > > consistent errors: > > > > MSVC2013 C++ (windows): > > main.cpp(5) : error C2365: 'a' : redefinition; previous definition > > was 'data variable' > > main.cpp(8) : error C2064: term does not evaluate to a function > > taking 0 arguments > > > > GNU g++ (linux): > > main.cpp:5:10: error: ‘double a()’ redeclared as different kind of > > symbol main.cpp:8:12: error: ‘a’ cannot be used as a function > > > > Angescript: > > asERR : (line 5, col 1) : Name conflict. 'a' is a global property. > > > > > > > > However, when introducing an explicit namespace, all are ok: > > > > double a = 10; > > namespace functions { double a() { return 20; } } > > void language_test() > > { > > print(functions::a()); > > print(' '); > > print(a); > > } > > > > the output is : 20 10 > > > > As always, this is just food for thought. > > > > Regards > > Carsten Arnholm > > > > > > > > > > > > _______________________________________________ > > OpenSCAD mailing list > > Discuss@lists.openscad.org > > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >

Yes that would get my vote. Very simple and powerful while totally backwards compatible. The "a" example is confusing only because of the nested definitions causing hiding. Nothing to do with the separate namespaces. It is always obvious which of the three namespaces is referenced. On 15 October 2016 at 20:40, Kuba Marek <blue.cube@seznam.cz> wrote: > The whole idea of having separate namespaces for functions and > variables is slightly confusing for me. I understand how it works, but > I still find the "a" example incomprehensible. > > OpenSCAD calls itself functional language and having functions just be > variable with function value is fairly standard in these. When I > started with OpenSCAD, separate namespaces were the biggest hassle I > encountered. > > If keeping the backwards compatibility was too important, then I would > vote for "@" dereferencing a string expression to a function call (so > that `@"f"()` behaves exactly like `f()`. > > Kuba > > > Yes but I choose to use OpenScad to design my 3D objects, not C++ > > (which I know) or Angel script (which I don't). I like it as it is > > now. There is never ambiguity because if it doesn't have parenthesis > > after it it is a variable, if it does it is a function if it is in an > > expression and a module otherwise. I don't see how that is confusing. > > > > On 15 October 2016 at 11:30, Carsten Arnholm <arnholm@arnholm.org> > > wrote: > > > > > On 15. okt. 2016 00:58, Parkinbot wrote: > > > > > >> nice: : > > >> > > >> a = 10; > > >>> a(); > > >>> module a(){ > > >>> a = a; > > >>> echo(a); > > >>> echo(a()); > > >>> a(); > > >>> function a() = 20; > > >>> > > >>> module a(){ > > >>> a = a; > > >>> echo(a); > > >>> echo(a()); > > >>> function a() = 20; > > >>> } > > >>> } > > >>> > > >> > > >> > > > Very good! Everything is obvious from the context, right? > > > > > > The problem is implicit, but separate namespaces for variables, > > > functions and modules. It is confusing to the human reader, such > > > code will lead to unexpected results. It doesn't matter if the > > > compiler is 'right' if the user expects something else. This kind > > > of confusion is best avoided (IMHO), and in several other languages > > > it is an error (example below). > > > > > > > > > My first idea would be to use an existing front end language with > > > such issues already handled instead of inventing a new one for > > > OpenSCAD, but since that is too late perhaps one may at least > > > consider what other languages do to resolve such issues. > > > > > > Perhaps in OpenSCAD one could make explicit that 3 namespaces always > > > exist, for example: > > > > > > variables : where variable names exist > > > functions : where function names exist > > > modules : where module names exist > > > > > > As long as all symbols used in the OpenSCAD user code are unique > > > across namespaces, there are no issues and all is working as > > > before. However, once the same symbol names appear in different > > > namespaces, a warning could be issued. To remove the warning, the > > > user would use other names or alternatively use explicit namespace > > > prefixing to make the interpretation clear, for example: > > > > > > a = 10; > > > modules::a(); > > > module a(){ > > > a = a; > > > echo(a); > > > echo(functions::a()); > > > modules::a(); > > > function a() = 20; > > > > > > module a(){ > > > a = a; > > > echo(a); > > > echo(functions::a()); > > > function a() = 30; > > > } > > > } > > > > > > The fact that modules can be nested, makes it even more confusing > > > to a reader, the prefixes are supposed to be local in this example. > > > > > > > > > > > > To compare, I just did a small test. The following code (some > > > irrelevant code not shown) causes errors in C++ and AngelScript > > > because of name resolution issues as in your OpenSCAD example. > > > First code line is line 4: > > > > > > > > > double a = 10; > > > double a() { return 20; } > > > void language_test() > > > { > > > print(a()); > > > print(' '); > > > print(a); > > > } > > > > > > > > > Tryng it with 2 C++ compilers and the AngelScript interpreter gave > > > consistent errors: > > > > > > MSVC2013 C++ (windows): > > > main.cpp(5) : error C2365: 'a' : redefinition; previous definition > > > was 'data variable' > > > main.cpp(8) : error C2064: term does not evaluate to a function > > > taking 0 arguments > > > > > > GNU g++ (linux): > > > main.cpp:5:10: error: ‘double a()’ redeclared as different kind of > > > symbol main.cpp:8:12: error: ‘a’ cannot be used as a function > > > > > > Angescript: > > > asERR : (line 5, col 1) : Name conflict. 'a' is a global property. > > > > > > > > > > > > However, when introducing an explicit namespace, all are ok: > > > > > > double a = 10; > > > namespace functions { double a() { return 20; } } > > > void language_test() > > > { > > > print(functions::a()); > > > print(' '); > > > print(a); > > > } > > > > > > the output is : 20 10 > > > > > > As always, this is just food for thought. > > > > > > Regards > > > Carsten Arnholm > > > > > > > > > > > > > > > > > > _______________________________________________ > > > OpenSCAD mailing list > > > Discuss@lists.openscad.org > > > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > > > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

@ could also be used in a statement to have indirect modules as well. It would be more powerful than children() because you would be able to pass parameters as you are invoking it in the parent instead of outside it. On 15 October 2016 at 20:48, nop head <nop.head@gmail.com> wrote: > Yes that would get my vote. Very simple and powerful while totally > backwards compatible. > > The "a" example is confusing only because of the nested definitions > causing hiding. Nothing to do with the separate namespaces. It is always > obvious which of the three namespaces is referenced. > > On 15 October 2016 at 20:40, Kuba Marek <blue.cube@seznam.cz> wrote: > >> The whole idea of having separate namespaces for functions and >> variables is slightly confusing for me. I understand how it works, but >> I still find the "a" example incomprehensible. >> >> OpenSCAD calls itself functional language and having functions just be >> variable with function value is fairly standard in these. When I >> started with OpenSCAD, separate namespaces were the biggest hassle I >> encountered. >> >> If keeping the backwards compatibility was too important, then I would >> vote for "@" dereferencing a string expression to a function call (so >> that `@"f"()` behaves exactly like `f()`. >> >> Kuba >> >> > Yes but I choose to use OpenScad to design my 3D objects, not C++ >> > (which I know) or Angel script (which I don't). I like it as it is >> > now. There is never ambiguity because if it doesn't have parenthesis >> > after it it is a variable, if it does it is a function if it is in an >> > expression and a module otherwise. I don't see how that is confusing. >> > >> > On 15 October 2016 at 11:30, Carsten Arnholm <arnholm@arnholm.org> >> > wrote: >> > >> > > On 15. okt. 2016 00:58, Parkinbot wrote: >> > > >> > >> nice: : >> > >> >> > >> a = 10; >> > >>> a(); >> > >>> module a(){ >> > >>> a = a; >> > >>> echo(a); >> > >>> echo(a()); >> > >>> a(); >> > >>> function a() = 20; >> > >>> >> > >>> module a(){ >> > >>> a = a; >> > >>> echo(a); >> > >>> echo(a()); >> > >>> function a() = 20; >> > >>> } >> > >>> } >> > >>> >> > >> >> > >> >> > > Very good! Everything is obvious from the context, right? >> > > >> > > The problem is implicit, but separate namespaces for variables, >> > > functions and modules. It is confusing to the human reader, such >> > > code will lead to unexpected results. It doesn't matter if the >> > > compiler is 'right' if the user expects something else. This kind >> > > of confusion is best avoided (IMHO), and in several other languages >> > > it is an error (example below). >> > > >> > > >> > > My first idea would be to use an existing front end language with >> > > such issues already handled instead of inventing a new one for >> > > OpenSCAD, but since that is too late perhaps one may at least >> > > consider what other languages do to resolve such issues. >> > > >> > > Perhaps in OpenSCAD one could make explicit that 3 namespaces always >> > > exist, for example: >> > > >> > > variables : where variable names exist >> > > functions : where function names exist >> > > modules : where module names exist >> > > >> > > As long as all symbols used in the OpenSCAD user code are unique >> > > across namespaces, there are no issues and all is working as >> > > before. However, once the same symbol names appear in different >> > > namespaces, a warning could be issued. To remove the warning, the >> > > user would use other names or alternatively use explicit namespace >> > > prefixing to make the interpretation clear, for example: >> > > >> > > a = 10; >> > > modules::a(); >> > > module a(){ >> > > a = a; >> > > echo(a); >> > > echo(functions::a()); >> > > modules::a(); >> > > function a() = 20; >> > > >> > > module a(){ >> > > a = a; >> > > echo(a); >> > > echo(functions::a()); >> > > function a() = 30; >> > > } >> > > } >> > > >> > > The fact that modules can be nested, makes it even more confusing >> > > to a reader, the prefixes are supposed to be local in this example. >> > > >> > > >> > > >> > > To compare, I just did a small test. The following code (some >> > > irrelevant code not shown) causes errors in C++ and AngelScript >> > > because of name resolution issues as in your OpenSCAD example. >> > > First code line is line 4: >> > > >> > > >> > > double a = 10; >> > > double a() { return 20; } >> > > void language_test() >> > > { >> > > print(a()); >> > > print(' '); >> > > print(a); >> > > } >> > > >> > > >> > > Tryng it with 2 C++ compilers and the AngelScript interpreter gave >> > > consistent errors: >> > > >> > > MSVC2013 C++ (windows): >> > > main.cpp(5) : error C2365: 'a' : redefinition; previous definition >> > > was 'data variable' >> > > main.cpp(8) : error C2064: term does not evaluate to a function >> > > taking 0 arguments >> > > >> > > GNU g++ (linux): >> > > main.cpp:5:10: error: ‘double a()’ redeclared as different kind of >> > > symbol main.cpp:8:12: error: ‘a’ cannot be used as a function >> > > >> > > Angescript: >> > > asERR : (line 5, col 1) : Name conflict. 'a' is a global property. >> > > >> > > >> > > >> > > However, when introducing an explicit namespace, all are ok: >> > > >> > > double a = 10; >> > > namespace functions { double a() { return 20; } } >> > > void language_test() >> > > { >> > > print(functions::a()); >> > > print(' '); >> > > print(a); >> > > } >> > > >> > > the output is : 20 10 >> > > >> > > As always, this is just food for thought. >> > > >> > > Regards >> > > Carsten Arnholm >> > > >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > OpenSCAD mailing list >> > > Discuss@lists.openscad.org >> > > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> > > >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> > >

nophead wrote > @ could also be used in a statement to have indirect modules as well. It > would be more powerful than children() because you would be able to pass > parameters as you are invoking it in the parent instead of outside it. Very useful, but you could do that without @ as well: module whatsit (...) {...} module doit(m) .... ...transforms... m(parameters); doit(whatsit); -- View this message in context: http://forum.openscad.org/Convert-from-object-to-polygon-polyhedron-tp18522p18728.html Sent from the OpenSCAD mailing list archive at Nabble.com.

> nophead wrote > > ...... but you could do that without @ as well: > > > module whatsit (...) {...} > > module doit(m) > .... > ...transforms... m(parameters); > > > doit(whatsit); What if you also had a variable called whatsit? That is where the @ comes in. It disambiguates the namespace like () does with a function.

Exactly. Rather than break everything by unifying the namespaces all it needs is an @ sign that converts a string to a module or function depending on the context. It is also more readable than languages that use the type of the variable instead. When you see an @ you know there is an indirection. Without it you need to look at the name and find its type is a function pointer and not a function to realise that. On 16 October 2016 at 16:28, Greg Frost <gregorybartonfrost@gmail.com> wrote: > > > nophead wrote > > > > ...... but you could do that without @ as well: > > > > > > module whatsit (...) {...} > > > > module doit(m) > > .... > > ...transforms... m(parameters); > > > > > > doit(whatsit); > > What if you also had a variable called whatsit? > That is where the @ comes in. It disambiguates the namespace like () does > with a function. > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

nophead wrote > Yes that would get my vote. Very simple and powerful while totally > backwards compatible. > > The "a" example is confusing only because of the nested definitions > causing > hiding. Nothing to do with the separate namespaces. It is always obvious > which of the three namespaces is referenced. As nested definitions are possible then using a @"" syntax is not advisable as this would not work in particular contexts: Or worse, the wrong function could called. Being able to reference any of the namespaces is only necessary when storing a reference to it in a definition. (As does doug.moen, I prefer the use of 'definition' over 'variable' as it's value is not mutable.) So, it is only necessary to use a decorator when referencing from one of the other namespaces. Doug's suggestion is to use *m$* and *f$* prefixes to explicitly reference them. He also stated using *v$* for the variable/definition namespace, but, IMHO that wouldn't be useful, as this namespace is used by default when assigning to a definition or passing as a parameter. So the above example becomes like this: -- View this message in context: http://forum.openscad.org/Convert-from-object-to-polygon-polyhedron-tp18522p18733.html Sent from the OpenSCAD mailing list archive at Nabble.com.

FYI, the prefixes are something that Doug is stating he'd use for the backward compatibility mode and would want the main mode to have a unified namespace. Personally, I would like to keep the namespaces separate and have this in the main mode. Maintaining two modes is not something that is optimal. Another alternative would be to EXPLICITLY state if the code uses a unified namespace, which would be marginally better as it would allow simpler backward compatibility and allow more advanced features to be use in older code. -- View this message in context: http://forum.openscad.org/Convert-from-object-to-polygon-polyhedron-tp18522p18734.html Sent from the OpenSCAD mailing list archive at Nabble.com.