[OpenSCAD] Openscad Indirect Functions

nop head nop.head at gmail.com
Sun Oct 16 10:35:27 EDT 2016


@ 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 at 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 at 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 at 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 at lists.openscad.org
>> > > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>> > >
>>
>> _______________________________________________
>> 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/20161016/2d608631/attachment-0002.html>


More information about the Discuss mailing list