[OpenSCAD] Openscad Indirect Functions

nop head nop.head at gmail.com
Sat Oct 15 13:06:17 EDT 2016


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20161015/da199aad/attachment-0002.html>


More information about the Discuss mailing list