Hi nop head. OpenSCAD bis would be compatible with your code, because your definitions of the function versions of rotate, translate, etc, would hide the built in definitions. If I was implementing this, I would test the changes against your code to ensure that there were no additional warnings or errors and no changes of behaviour. Any incompatibilities would be considered a bug. Also, if I was implementing this today, I would ignore the part of the design that tries to make shapes and modules into first class values, because that part is too big and scary. I would only implement the function part of OpenSCAD bis. The function part can be summarized as: * New style function definitions define the function in both the variable and the function namespaces. * Within a new style function definition, parameter names and let-bound local variables are defined in both the variable and the function namespaces. * Most built in functions are also defined in the variable namespace. But those definitions are hidden by user defined variables. Doug Moen. On Fri, Aug 23, 2019, at 3:21 AM, nop head wrote: > I think OpenSCAD bis would still have compatibility issues if you put built in modules into the function and variable namespaces. Keeping the namespaces separate for compatibility is pointless if you put built in things in more than one namespace. > > For example I have function versions of rotate, translate, etc, that work on matrices. > > On Thu, 22 Aug 2019 at 23:25, Doug Moen <doug@moens.org> wrote: >> Okay, I justed updated the OpenSCAD2 project to show the current status. >> >> The original OpenSCAD2 proposal was not popular with some members of the community, and it had some problems with backward compatibility. >> >> Back in 2017, I starting writing an updated proposal, "OpenSCAD bis", which is simpler, and has a lower risk of breaking backwards compatibility. For the record, the document is here: https://github.com/doug-moen/openscad2/blob/master/OpenSCADbis.md >> >> Doug Moen. >> >> On Thu, Aug 22, 2019, at 5:28 PM, Torsten Paul wrote: >> > A probably better base for the discussion is that one >> > >> > https://github.com/doug-moen/openscad2/blob/master/rfc/Functions.md >> > >> > as it's considering the existing OpenSCAD syntax. >> > >> > ciao, >> > Torsten. >> > >> > >> > _______________________________________________ >> > 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 >

OK that makes sense. I does open the door to more complexity and I like OpenSCAD because it is simple. With function pointers I can put them in lists and make vtables for my objects adding polymorphism and inheritance as I did with C before C++ was invented and I knew what OO was. On Fri, 23 Aug 2019 at 14:46, Doug Moen <doug@moens.org> wrote: > Hi nop head. > > OpenSCAD bis would be compatible with your code, because your definitions > of the function versions of rotate, translate, etc, would hide the built in > definitions. > > If I was implementing this, I would test the changes against your code to > ensure that there were no additional warnings or errors and no changes of > behaviour. Any incompatibilities would be considered a bug. > > Also, if I was implementing this today, I would ignore the part of the > design that tries to make shapes and modules into first class values, > because that part is too big and scary. I would only implement the function > part of OpenSCAD bis. The function part can be summarized as: > * New style function definitions define the function in both the variable > and the function namespaces. > * Within a new style function definition, parameter names and let-bound > local variables are defined in both the variable and the function > namespaces. > * Most built in functions are also defined in the variable namespace. But > those definitions are hidden by user defined variables. > > Doug Moen. > > On Fri, Aug 23, 2019, at 3:21 AM, nop head wrote: > > I think OpenSCAD bis would still have compatibility issues if you put > built in modules into the function and variable namespaces. Keeping the > namespaces separate for compatibility is pointless if you put built in > things in more than one namespace. > > For example I have function versions of rotate, translate, etc, that work > on matrices. > > On Thu, 22 Aug 2019 at 23:25, Doug Moen <doug@moens.org> wrote: > > Okay, I justed updated the OpenSCAD2 project to show the current status. > > The original OpenSCAD2 proposal was not popular with some members of the > community, and it had some problems with backward compatibility. > > Back in 2017, I starting writing an updated proposal, "OpenSCAD bis", > which is simpler, and has a lower risk of breaking backwards compatibility. > For the record, the document is here: > https://github.com/doug-moen/openscad2/blob/master/OpenSCADbis.md > > Doug Moen. > > On Thu, Aug 22, 2019, at 5:28 PM, Torsten Paul wrote: > > A probably better base for the discussion is that one > > > > https://github.com/doug-moen/openscad2/blob/master/rfc/Functions.md > > > > as it's considering the existing OpenSCAD syntax. > > > > ciao, > > Torsten. > > > > > > _______________________________________________ > > 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 >

On 23.08.19 15:42, Doug Moen wrote: > ... I would ignore the part of the design that tries to make > shapes and modules into first class values, because that > part is too big and scary. I would only implement the function > part of OpenSCAD bis. Yes, that what I'm thinking too. This is also pretty much what we were doing (slowly) in past. Taking small steps implementing parts of your proposal. The functions would be a bigger step but I think it's worth it as there's a lot of use cases that could greatly benefit from this feature. Just to highlight that again: Thanks for all the work you did writing those proposals, they are a big help in showing a road to a future OpenSCAD without breaking too much of the past. ciao, Torsten.