function f()=a;  should persistently point to outer value.  The
  fact that function f()=a; created a local variable named with
  token_id "a" is an artifact.

  In my opinion
  a = 1;
  a = 2;  //should at least produce a warning if not an error.

  Whereas:

  a=1;
  module m()
  {
    a=2;
  }

   should be legal and provides for a different value of a in the
   two different scopes as it does now.

   a = 1;
   function f() = a;

   Sets the value of "a" as a local variable.  The function then
   always points to the local variable. We should provide a

 a = 0;
 module m()
 {
     a = 1;
     function f() = a;
     x = f();
     y = f();
     echo(x,y);
  }
m();

On 18 November 2016 at 15:15, doug moen <doug@moens.org> wrote: > nophead said: "Although I have to say interpreted languages are always > more powerful but slower and while the geometry evaluation dominates there > isn't much advantage to compiling." > > Interpreted languages *can* be more powerful, but it depends on the > language. OpenSCAD is not a powerful language. Javascript, which is > lexically scoped and compiled, is far more powerful, and the lack of > function values in OpenSCAD is a problem for me. > > Suppose we were to extend OpenSCAD so that you can define new geometric > primitives directly in the language. I mean that user defined OpenSCAD > functions would be executed during preview and rendering. And suppose we > make that fast by compiling OpenSCAD code into parallelized GPU code. Then > we would need lexical scoping and a compiler. The functional/declarative > nature of OpenSCAD really helps with this, but the dynamic scoping gets in > the way. Anyway, I think this is worth trying, you could do some really > cool things with this kind of system. > Do I understand this right? You are proposing making OpenScad powerful enough to replace GCAL so things like union can be written at the user level, and have it run on a GPU? > > On 18 November 2016 at 09:11, nop head <nop.head@gmail.com> wrote: > >> I just remembered the truly bizarre rule where putting a variable >> assignment in a module call that is not named in the module definition can >> override the same name in another module. E.g. >> >> b = 2; >> module x(a) echo(a,b); >> >> x(1); >> x(1, b = 3); >> >> ECHO: 1, 2 >> >> ECHO: 1, 3 >> >> >> >> That would make compilation difficult! Although I have to say interpreted >> languages are always more powerful but slower and while the geometry >> evaluation dominates there isn't much advantage to compiling. >> >> >> >> On 18 November 2016 at 14:03, nop head <nop.head@gmail.com> wrote: >> >>> So is it just a bug in the implementation of nested functions (and >>> presumably nested modules) or are there other exceptions to lexical scope? >>> >>> I would be surprised if much or any code relies on this so it could be >>> bug fixed. >>> >>> On 18 November 2016 at 13:51, doug moen <doug@moens.org> wrote: >>> >>>> nop head said: I thought scope was supposed to be lexical apart from >>>> the $ variables? >>>> >>>> That's what I thought too, for years. I think it's *intended* to be >>>> lexically scoped, but the code doesn't actually work that way. >>>> >>>> If you were to try and write a compiler for OpenSCAD, one that >>>> generates efficient code, then you'd have to know what the lexical scoping >>>> rules actually are, and implement those rules. It has been frustrating for >>>> me to come up with a clear statement of what the scoping rules are, so that >>>> I could try to implement them in my compiler. >>>> >>>> For now, I've given up on reverse engineering the scoping rules, >>>> because I want to work on my VM and geometry engine. Instead, I just >>>> implemented the simplest lexical scoping rule that I could, which is that >>>> at the top level of a script, there is only 1 namespace, and the scope of >>>> every variable and function definition is the entire file (recursive >>>> scoping). It's simple and consistent: it allows recursive definitions, and >>>> all you need to know as a user is that the order of definitions doesn't >>>> matter. Plus, it is well known how to implement this. If I consistently >>>> used "sequential scoping" for everything, then recursive function >>>> definitions would be impossible. The actual scoping rules for OpenSCAD are >>>> apparently very complicated, and I don't know how to implement them using >>>> conventional compiler technology. >>>> >>>> I think it would be beneficial if OpenSCAD were changed so that it >>>> actually is lexically scoped, except for $ variables. And I'd like to see >>>> the OpenSCAD team document the lexical scoping rules. In particular, what >>>> is the scope of a variable definition? Then maybe at a later date I could >>>> revisit this and try to write a compiler that obeys these rules. >>>> >>>> Well defined lexical scoping rules are important for implementing first >>>> class function values. An anonymous function literal "captures" the values >>>> of nonlocal lexically scoped variables from surrounding scopes, at the time >>>> the function literal is evaluated. This results in a data structure called >>>> a closure. When the function value is subsequently called, it uses the >>>> captured values. Function definitions work exactly the same way: nonlocal >>>> variables are captured when the function definition is evaluated. The >>>> variables that are captured are the ones visible at the point where the >>>> function is defined, not at the point where the function is called. >>>> >>>> On 18 November 2016 at 05:38, nop head <nop.head@gmail.com> wrote: >>>> >>>>> If you replace the calls of f() with a then you get the same result >>>>> and it makes sense since the first a refers to the outer scope and the >>>>> second one to the inner scope. So the function behaves more like a macro >>>>> text substitution. But if you move the definition of f outside the module >>>>> it always accesses the outer a. >>>>> >>>>> So yes it is a strange mixture of lexical and dynamic. I thought scope >>>>> was supposed to be lexical apart from the $ variables? >>>>> >>>>> On 18 November 2016 at 06:12, otto <otto@123phase.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> > doug.moen wrote >>>>>> > > 1 a = 0; >>>>>> > > 2 module m() >>>>>> > > 3 { >>>>>> > > 4 function f() = a; >>>>>> > > 5 x = f(); >>>>>> > > 6 a = 1; >>>>>> > > 7 y = f(); >>>>>> > > 8 echo(x,y); >>>>>> > > 9 } >>>>>> > > 10 m(); >>>>>> > > >>>>>> > > So the output is: >>>>>> > > ECHO: 0,1 >>>>>> > > >>>>>> > > Fun question: is any of this behaviour a bug? >>>>>> >>>>>> I think it is. Heres why. >>>>>> function f() = a; //refers to the outer scope value of a. >>>>>> x = f(); //sets local x to the outer scope value of a. >>>>>> a=1; //This should have no effect on the outer >>>>>> scope. >>>>>> >>>>>> function f()=a; should persistently point to outer value. The >>>>>> fact that function f()=a; created a local variable named with >>>>>> token_id "a" is an artifact. >>>>>> >>>>>> In my opinion >>>>>> a = 1; >>>>>> a = 2; //should at least produce a warning if not an error. >>>>>> >>>>>> Whereas: >>>>>> >>>>>> a=1; >>>>>> module m() >>>>>> { >>>>>> a=2; >>>>>> } >>>>>> >>>>>> should be legal and provides for a different value of a in the >>>>>> two different scopes as it does now. >>>>>> >>>>>> a = 1; >>>>>> function f() = a; >>>>>> >>>>>> Sets the value of "a" as a local variable. The function then >>>>>> always points to the local variable. We should provide a >>>>>> warning if it >>>>>> is redefined. >>>>>> >>>>>> Of course, since this is the behavior and it works, it isn't really a >>>>>> bug, it is an artifact. But it falls into the category of a gotchya, >>>>>> I can think of no case where there isn't a clearer method of writing >>>>>> this code. Everywhere this artifact is used, it tends to obfuscate. >>>>>> >>>>>> Regards >>>>>> Otto >>>>>> >>>>>> > >>>>>> > That makes perfect sense, if you want it the other way you do >>>>>> > >>>>>> > >>>>>> > > a = 0; >>>>>> > > module m() >>>>>> > > { >>>>>> > > a = 1; >>>>>> > > function f() = a; >>>>>> > > x = f(); >>>>>> > > y = f(); >>>>>> > > echo(x,y); >>>>>> > > } >>>>>> > > m(); >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > ----- >>>>>> > Admin - PM me if you need anything, or if I've done something >>>>>> > stupid... >>>>>> > >>>>>> > Unless specifically shown otherwise above, my contribution is in the >>>>>> > Public Domain; to the extent possible under law, I have waived all >>>>>> > copyright and related or neighbouring rights to this work. Obviously >>>>>> > inclusion of works of previous authors is not included in the above. >>>>>> > >>>>>> > The TPP is no simple “trade agreement.” Fight it! >>>>>> > http://www.ourfairdeal.org/ time is running out! -- >>>>>> > View this message in context: >>>>>> > http://forum.openscad.org/feedback-let-echo-and-assert-in-ex >>>>>> pressions-tp19111p19205.html >>>>>> > Sent from the OpenSCAD mailing list archive at Nabble.com. >>>>>> > >>>>>> > _______________________________________________ >>>>>> > OpenSCAD mailing list >>>>>> > Discuss@lists.openscad.org >>>>>> > http://lists.openscad.org/mailman/listinfo/discuss_lists.ope >>>>>> nscad.org >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >

  function f()=a;  should persistently point to outer value.  The
  fact that function f()=a; created a local variable named with
  token_id "a" is an artifact.

  In my opinion
  a = 1;
  a = 2;  //should at least produce a warning if not an error.

  Whereas:

  a=1;
  module m()
  {
    a=2;
  }

   should be legal and provides for a different value of a in the
   two different scopes as it does now.

   a = 1;
   function f() = a;

   Sets the value of "a" as a local variable.  The function then
   always points to the local variable. We should provide a

 a = 0;
 module m()
 {
     a = 1;
     function f() = a;
     x = f();
     y = f();
     echo(x,y);
  }
m();

nophead said: "Do I understand this right? You are proposing making OpenScad powerful enough to replace GCAL so things like union can be written at the user level, and have it run on a GPU?" Yes, that is what I am working towards. I have the implementation worked out, and hopefully next year I'll have something to demo. Initially, it won't be OpenSCAD (or OpenSCAD2), it will instead be a simplified OpenSCAD-like language with lexical scoping and other accommodations for GPU compilation. And it won't "replace CGAL", since I'm using different data structures and algorithms, so the behaviour of union, etc will be different. I'm hoping it will be faster, but I can't make claims until I have working code. On 18 November 2016 at 10:47, nop head <nop.head@gmail.com> wrote: > > > On 18 November 2016 at 15:15, doug moen <doug@moens.org> wrote: > >> nophead said: "Although I have to say interpreted languages are always >> more powerful but slower and while the geometry evaluation dominates there >> isn't much advantage to compiling." >> >> Interpreted languages *can* be more powerful, but it depends on the >> language. OpenSCAD is not a powerful language. Javascript, which is >> lexically scoped and compiled, is far more powerful, and the lack of >> function values in OpenSCAD is a problem for me. >> >> Suppose we were to extend OpenSCAD so that you can define new geometric >> primitives directly in the language. I mean that user defined OpenSCAD >> functions would be executed during preview and rendering. And suppose we >> make that fast by compiling OpenSCAD code into parallelized GPU code. Then >> we would need lexical scoping and a compiler. The functional/declarative >> nature of OpenSCAD really helps with this, but the dynamic scoping gets in >> the way. Anyway, I think this is worth trying, you could do some really >> cool things with this kind of system. >> > > Do I understand this right? You are proposing making OpenScad powerful > enough to replace GCAL so things like union can be written at the user > level, and have it run on a GPU? > > >> >> On 18 November 2016 at 09:11, nop head <nop.head@gmail.com> wrote: >> >>> I just remembered the truly bizarre rule where putting a variable >>> assignment in a module call that is not named in the module definition can >>> override the same name in another module. E.g. >>> >>> b = 2; >>> module x(a) echo(a,b); >>> >>> x(1); >>> x(1, b = 3); >>> >>> ECHO: 1, 2 >>> >>> ECHO: 1, 3 >>> >>> >>> >>> That would make compilation difficult! Although I have to say >>> interpreted languages are always more powerful but slower and while the >>> geometry evaluation dominates there isn't much advantage to compiling. >>> >>> >>> >>> On 18 November 2016 at 14:03, nop head <nop.head@gmail.com> wrote: >>> >>>> So is it just a bug in the implementation of nested functions (and >>>> presumably nested modules) or are there other exceptions to lexical scope? >>>> >>>> I would be surprised if much or any code relies on this so it could be >>>> bug fixed. >>>> >>>> On 18 November 2016 at 13:51, doug moen <doug@moens.org> wrote: >>>> >>>>> nop head said: I thought scope was supposed to be lexical apart from >>>>> the $ variables? >>>>> >>>>> That's what I thought too, for years. I think it's *intended* to be >>>>> lexically scoped, but the code doesn't actually work that way. >>>>> >>>>> If you were to try and write a compiler for OpenSCAD, one that >>>>> generates efficient code, then you'd have to know what the lexical scoping >>>>> rules actually are, and implement those rules. It has been frustrating for >>>>> me to come up with a clear statement of what the scoping rules are, so that >>>>> I could try to implement them in my compiler. >>>>> >>>>> For now, I've given up on reverse engineering the scoping rules, >>>>> because I want to work on my VM and geometry engine. Instead, I just >>>>> implemented the simplest lexical scoping rule that I could, which is that >>>>> at the top level of a script, there is only 1 namespace, and the scope of >>>>> every variable and function definition is the entire file (recursive >>>>> scoping). It's simple and consistent: it allows recursive definitions, and >>>>> all you need to know as a user is that the order of definitions doesn't >>>>> matter. Plus, it is well known how to implement this. If I consistently >>>>> used "sequential scoping" for everything, then recursive function >>>>> definitions would be impossible. The actual scoping rules for OpenSCAD are >>>>> apparently very complicated, and I don't know how to implement them using >>>>> conventional compiler technology. >>>>> >>>>> I think it would be beneficial if OpenSCAD were changed so that it >>>>> actually is lexically scoped, except for $ variables. And I'd like to see >>>>> the OpenSCAD team document the lexical scoping rules. In particular, what >>>>> is the scope of a variable definition? Then maybe at a later date I could >>>>> revisit this and try to write a compiler that obeys these rules. >>>>> >>>>> Well defined lexical scoping rules are important for implementing >>>>> first class function values. An anonymous function literal "captures" the >>>>> values of nonlocal lexically scoped variables from surrounding scopes, at >>>>> the time the function literal is evaluated. This results in a data >>>>> structure called a closure. When the function value is subsequently called, >>>>> it uses the captured values. Function definitions work exactly the same >>>>> way: nonlocal variables are captured when the function definition is >>>>> evaluated. The variables that are captured are the ones visible at the >>>>> point where the function is defined, not at the point where the function is >>>>> called. >>>>> >>>>> On 18 November 2016 at 05:38, nop head <nop.head@gmail.com> wrote: >>>>> >>>>>> If you replace the calls of f() with a then you get the same result >>>>>> and it makes sense since the first a refers to the outer scope and the >>>>>> second one to the inner scope. So the function behaves more like a macro >>>>>> text substitution. But if you move the definition of f outside the module >>>>>> it always accesses the outer a. >>>>>> >>>>>> So yes it is a strange mixture of lexical and dynamic. I thought >>>>>> scope was supposed to be lexical apart from the $ variables? >>>>>> >>>>>> On 18 November 2016 at 06:12, otto <otto@123phase.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> > doug.moen wrote >>>>>>> > > 1 a = 0; >>>>>>> > > 2 module m() >>>>>>> > > 3 { >>>>>>> > > 4 function f() = a; >>>>>>> > > 5 x = f(); >>>>>>> > > 6 a = 1; >>>>>>> > > 7 y = f(); >>>>>>> > > 8 echo(x,y); >>>>>>> > > 9 } >>>>>>> > > 10 m(); >>>>>>> > > >>>>>>> > > So the output is: >>>>>>> > > ECHO: 0,1 >>>>>>> > > >>>>>>> > > Fun question: is any of this behaviour a bug? >>>>>>> >>>>>>> I think it is. Heres why. >>>>>>> function f() = a; //refers to the outer scope value of a. >>>>>>> x = f(); //sets local x to the outer scope value of a. >>>>>>> a=1; //This should have no effect on the outer >>>>>>> scope. >>>>>>> >>>>>>> function f()=a; should persistently point to outer value. The >>>>>>> fact that function f()=a; created a local variable named with >>>>>>> token_id "a" is an artifact. >>>>>>> >>>>>>> In my opinion >>>>>>> a = 1; >>>>>>> a = 2; //should at least produce a warning if not an error. >>>>>>> >>>>>>> Whereas: >>>>>>> >>>>>>> a=1; >>>>>>> module m() >>>>>>> { >>>>>>> a=2; >>>>>>> } >>>>>>> >>>>>>> should be legal and provides for a different value of a in the >>>>>>> two different scopes as it does now. >>>>>>> >>>>>>> a = 1; >>>>>>> function f() = a; >>>>>>> >>>>>>> Sets the value of "a" as a local variable. The function then >>>>>>> always points to the local variable. We should provide a >>>>>>> warning if it >>>>>>> is redefined. >>>>>>> >>>>>>> Of course, since this is the behavior and it works, it isn't really a >>>>>>> bug, it is an artifact. But it falls into the category of a gotchya, >>>>>>> I can think of no case where there isn't a clearer method of writing >>>>>>> this code. Everywhere this artifact is used, it tends to obfuscate. >>>>>>> >>>>>>> Regards >>>>>>> Otto >>>>>>> >>>>>>> > >>>>>>> > That makes perfect sense, if you want it the other way you do >>>>>>> > >>>>>>> > >>>>>>> > > a = 0; >>>>>>> > > module m() >>>>>>> > > { >>>>>>> > > a = 1; >>>>>>> > > function f() = a; >>>>>>> > > x = f(); >>>>>>> > > y = f(); >>>>>>> > > echo(x,y); >>>>>>> > > } >>>>>>> > > m(); >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > ----- >>>>>>> > Admin - PM me if you need anything, or if I've done something >>>>>>> > stupid... >>>>>>> > >>>>>>> > Unless specifically shown otherwise above, my contribution is in >>>>>>> the >>>>>>> > Public Domain; to the extent possible under law, I have waived all >>>>>>> > copyright and related or neighbouring rights to this work. >>>>>>> Obviously >>>>>>> > inclusion of works of previous authors is not included in the >>>>>>> above. >>>>>>> > >>>>>>> > The TPP is no simple “trade agreement.” Fight it! >>>>>>> > http://www.ourfairdeal.org/ time is running out! -- >>>>>>> > View this message in context: >>>>>>> > http://forum.openscad.org/feedback-let-echo-and-assert-in-ex >>>>>>> pressions-tp19111p19205.html >>>>>>> > Sent from the OpenSCAD mailing list archive at Nabble.com. >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > OpenSCAD mailing list >>>>>>> > Discuss@lists.openscad.org >>>>>>> > http://lists.openscad.org/mailman/listinfo/discuss_lists.ope >>>>>>> nscad.org >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OpenSCAD mailing list >>>>>>> Discuss@lists.openscad.org >>>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.ope >>>>>>> nscad.org >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> 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 >> >> > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >

Marius wrote: "I’m not sure anyone wants to document these rules as they’re mostly artifacts of poorly written/tested code" I didn't mean document the current behaviour. I mean document the lexical scoping rules that you would like OpenSCAD to have, so that deviations from these rules can be reported as bugs, and so that users understand what behaviour to expect in the future, based on the document. On 18 November 2016 at 10:39, Marius Kintel <marius@kintel.net> wrote: > > On Nov 18, 2016, at 08:51, doug moen <doug@moens.org> wrote: > > > > I think it would be beneficial if OpenSCAD were changed so that it > actually is lexically scoped, except for $ variables. > > I agree. I’d like to see a way of providing very clear messages to people > exploiting this behavior that it’s deprecated, ideally with a way of > upgrading code to follow the new rules. > > > And I'd like to see the OpenSCAD team document the lexical scoping > rules. In particular, what is the scope of a variable definition? Then > maybe at a later date I could revisit this and try to write a compiler that > obeys these rules. > > > I’m not sure anyone wants to document these rules as they’re mostly > artifacts of poorly written/tested code in the past. Extracting docs from > code is not always easy.. > Most of this is implicitly available as tests. Any new compiler could > reuse these test cases. > Rather than documenting it, we could always identify usage of such with > tests, and write rules on the AST level to detect usage of said features, > and potentially provide an upgrade path. > > -Marius > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

> On Nov 18, 2016, at 12:16, doug moen <doug@moens.org> wrote: > > I didn't mean document the current behaviour. I mean document the lexical scoping rules that you would like OpenSCAD to have, so that deviations from these rules can be reported as bugs, and so that users understand what behaviour to expect in the future, based on the document. > That would be a good step. There are two types of current behaviors though, the ones we could deprecate to force people to use a better alternative and the one we’d need to change as there is no better alternative. Leaking of parameter list into module scope is an example of the former. Reassignment rules for variables is an example of the latter. -Marius

nophead wrote > I just remembered the truly bizarre rule where putting a variable > assignment in a module call that is not named in the module definition can > override the same name in another module. E.g. > > b = 2; > module x(a) echo(a,b); > > x(1); > x(1, b = 3); > > ECHO: 1, 2 > > ECHO: 1, 3 That is very useful, particularly with library code. Have a look at Write.scad, for example. Also when designing variants, being able to override specific values in a module. I previously mentioned that ~hundred lines of variables. If had to declare them all in all modules, just so I can override them then it would be a nightmare. Where I can just: some_module(...,thingID=thingID-0.1); for any of the many variables. I have for example a variable number of widgets in a row on a mounting plate, some face one direction some others, some are on the bottom of the plate. I can control any specific behaviour of the specific widget in the calling module by adjusting any variable/'parameter' on the specific module call. Anyway, my 2c worth. Or I just put '$' in all variables... ----- Admin - PM me if you need anything, or if I've done something stupid... Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above. The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out! -- View this message in context: http://forum.openscad.org/feedback-let-echo-and-assert-in-expressions-tp19111p19233.html Sent from the OpenSCAD mailing list archive at Nabble.com.

Well other languages don't allow bizarre overrides like that and I have never had any problem programming anything with them. I can also make complex machines like Mendel90 without "hundred lines of variables". The trick is to use an object oriented style where objects are represented by lists of properties and passed as a single argument. Anything else is passed as named parameters apart from a few global variables like layer height and filament width. On 19 November 2016 at 00:31, MichaelAtOz <oz.at.michael@gmail.com> wrote: > nophead wrote > > I just remembered the truly bizarre rule where putting a variable > > assignment in a module call that is not named in the module definition > can > > override the same name in another module. E.g. > > > > b = 2; > > module x(a) echo(a,b); > > > > x(1); > > x(1, b = 3); > > > > ECHO: 1, 2 > > > > ECHO: 1, 3 > > That is very useful, particularly with library code. Have a look at > Write.scad, for example. > > Also when designing variants, being able to override specific values in a > module. > > I previously mentioned that ~hundred lines of variables. If had to declare > them all in all modules, just so I can override them then it would be a > nightmare. Where I can just: > > some_module(...,thingID=thingID-0.1); > > for any of the many variables. > > I have for example a variable number of widgets in a row on a mounting > plate, some face one direction some others, some are on the bottom of the > plate. > I can control any specific behaviour of the specific widget in the calling > module by adjusting any variable/'parameter' on the specific module call. > > Anyway, my 2c worth. > > Or I just put '$' in all variables... > > > > > > > ----- > Admin - PM me if you need anything, or if I've done something stupid... > > Unless specifically shown otherwise above, my contribution is in the > Public Domain; to the extent possible under law, I have waived all > copyright and related or neighbouring rights to this work. Obviously > inclusion of works of previous authors is not included in the above. > > The TPP is no simple “trade agreement.” Fight it! > http://www.ourfairdeal.org/ time is running out! > -- > View this message in context: http://forum.openscad.org/ > feedback-let-echo-and-assert-in-expressions-tp19111p19233.html > Sent from the OpenSCAD mailing list archive at Nabble.com. > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

doug.moen wrote > For example, > K = L `concat` M; > This is easy enough to implement. Would we really need anything more > complicated than this? Infix notation might be a good step forward to escape the bracket forest and to increase readability. I don't think a good parser will need backticks for disambiguation, but this is just the details. doug.moen wrote > Operator *overloading* is a huge leap in complexity from defining new > operators. That presupposes the ability to define new user defined data > types. Do we really need this? Aren't the user defined structs you propose a first step into this direction? As this introduces only implicit typing, a lot of the potential of having structs in a language will lie idle. And it is of course not too complicated to implement an explicit typing system on top of this and I promise that this will be the first thing users acquainted with OOP will do - in a wild fashion. How? Just introduce a common field to carry type information and provide "typed" operations to test for it (which sooner or later would bring up the demand for a user defined error or at least warning, but isn't this already a big miss?). > function myTypeOp(parameters) = if (parameters.type != "myType") > error("myTypeOp called with wrong parameter") else ... -- View this message in context: http://forum.openscad.org/feedback-let-echo-and-assert-in-expressions-tp19111p19243.html Sent from the OpenSCAD mailing list archive at Nabble.com.

nophead wrote > I can also make complex machines like Mendel90 without "hundred lines of > variables". Mine is not unlike your Mendel config.scad. And, yes mine was a design began many years ago on, and allowed to organically evolve in a time constrained delivery window...(it's not pretty). It used naming conventions to 'class'ify things. But it would help if the language had structure elements to assist, rather than having to invent ... anyway, I'm sure we all have our wish lists. But that 'feature' is really handy for prototyping... ----- Admin - PM me if you need anything, or if I've done something stupid... Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above. The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out! -- View this message in context: http://forum.openscad.org/feedback-let-echo-and-assert-in-expressions-tp19111p19258.html Sent from the OpenSCAD mailing list archive at Nabble.com.

nophead wrote > b = 2; > module x(a) echo(a,b); > > x(1); > x(1, b = 3); > > ECHO: 1, 2 > ECHO: 1, 3 I am shocked to see this is possible. The module x doesn't not define b as its argument, therefore it shouldn't be allowed to take it, let along change it. This violates all the programming language studies I had before. ----- $ Runsun Pan, PhD $ libs: doctest , faces ( git ), offline doc ( git ), runscad.py ( 2 , git ), synwrite ( 2 ); &nbsp; $ 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 ), text , triang ; $ Apps: rollApp , blockscad , openjscad , on AWS ( pdf ) -- View this message in context: http://forum.openscad.org/feedback-let-echo-and-assert-in-expressions-tp19111p19260.html Sent from the OpenSCAD mailing list archive at Nabble.com.

A further test rescues myself from the shock. The b in x(a, b=3) is a local, and only when missing will the global b is involved. Still a bit strange but not that weird after all. ----- $ Runsun Pan, PhD $ libs: doctest , faces ( git ), offline doc ( git ), runscad.py ( 2 , git ), synwrite ( 2 ); &nbsp; $ 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 ), text , triang ; $ Apps: rollApp , blockscad , openjscad , on AWS ( pdf ) -- View this message in context: http://forum.openscad.org/feedback-let-echo-and-assert-in-expressions-tp19111p19261.html Sent from the OpenSCAD mailing list archive at Nabble.com.