OpenSCAD2 design docs

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

OpenSCAD2 design docs

doug.moen
OpenSCAD2 is a backwards compatible redesign of OpenSCAD. Some highlights:
  • everything is a first class value, including functions, modules, shapes, groups and scripts
  • single unified namespace, instead of 3 namespaces for variables, functions and modules
  • modules are unified with functions
  • the 'module composability bug' is fixed: 'intersection' now composes with 'for'
  • generic sequence operations and generalized list comprehensions
  • objects: external script files are referenced as object values; {script} is an object literal; 'object.name' looks up a named field in an object
  • groups are replaced by object values; the CSG tree is a tree of objects
  • the 'use' command is fixed: it can be used to reference any library


At this point, I'm looking for feedback and new collaborators. There may ways to improve parts of the design to make it easier to use, or more powerful, or less complex, or whatever. I expect that there are still bugs in the backward compatibility provisions that may trigger design changes.

Since it's all on github, you may open issues if you like.

I don't have any working code yet. This has turned into a big project, so that's going to take a while, and will be implemented in multiple stages. I expect further design changes as a result of insights developed while implementing all of this.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD2 design docs

jdawgaz
In looking over the README, it all pretty much makes good sense.

However, may I make a suggestion on the one part I have read so far.

In the README, the new syntax:

elongate(n)(children) = {
  for (c = children)
    scale([n, 1, 1]) c;
};
It seems it might be a little bit clearer if it were IN instead of =
elongate(n)(children) = {
  for (c in children)
    scale([n, 1, 1]) c;
};
Jerry


Jerry

--
Extra Ham Operator: K7AZJ
Registered Linux User: 275424
Raspberry Pi and Arduino developer

The most exciting phrase to hear in science - the one that heralds new discoveries - is not "Eureka!" but "That's funny...".
- Isaac. Asimov

If you give someone a program, you will frustrate them for a day; if you teach them how to program, you will frustrate them for a lifetime. 
- Anonymous

If writing good code requires very little comments, then writing really excellent code requires no comments at all!
- Ken Thompson


On Fri, Jul 3, 2015 at 6:07 PM, doug moen <[hidden email]> wrote:
OpenSCAD2 is a backwards compatible redesign of OpenSCAD. Some highlights:
  • everything is a first class value, including functions, modules, shapes, groups and scripts
  • single unified namespace, instead of 3 namespaces for variables, functions and modules
  • modules are unified with functions
  • the 'module composability bug' is fixed: 'intersection' now composes with 'for'
  • generic sequence operations and generalized list comprehensions
  • objects: external script files are referenced as object values; {script} is an object literal; 'object.name' looks up a named field in an object
  • groups are replaced by object values; the CSG tree is a tree of objects
  • the 'use' command is fixed: it can be used to reference any library


At this point, I'm looking for feedback and new collaborators. There may ways to improve parts of the design to make it easier to use, or more powerful, or less complex, or whatever. I expect that there are still bugs in the backward compatibility provisions that may trigger design changes.

Since it's all on github, you may open issues if you like.

I don't have any working code yet. This has turned into a big project, so that's going to take a while, and will be implemented in multiple stages. I expect further design changes as a result of insights developed while implementing all of this.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD2 design docs

BenZ
In reply to this post by doug.moen
Re: [OpenSCAD] OpenSCAD2 design docs At
you write :
"In short, although it wasn't a design goal, OpenSCAD2 appears to have all of the necessary language mechanisms required to support object oriented programming. This may turn out to be useful in the future for structuring complex models or for writing new libraries of geometric objects."

==> It seems to me, taking an exising OO langugage and making a library for it would free you of all the hassle with parsing? Plus you have all the good parts of the language.  
Please don't mimic a professor/CEO which thinks he needs a new language.


OpenSCAD2 is a backwards compatible redesign of OpenSCAD. Some highlights:
  • everything is a first class value, including functions, modules, shapes, groups and scripts
  • single unified namespace, instead of 3 namespaces for variables, functions and modules
  • modules are unified with functions
  • the 'module composability bug' is fixed: 'intersection' now composes with 'for'
  • generic sequence operations and generalized list comprehensions
  • objects: external script files are referenced as object values; {script} is an object literal; 'object.name' looks up a named field in an object
  • groups are replaced by object values; the CSG tree is a tree of objects
  • the 'use' command is fixed: it can be used to reference any library
Design spec: https://github.com/doug-moen/openscad2

At this point, I'm looking for feedback and new collaborators. There may ways to improve parts of the design to make it easier to use, or more powerful, or less complex, or whatever. I expect that there are still bugs in the backward compatibility provisions that may trigger design changes.

Since it's all on github, you may open issues if you like.

I don't have any working code yet. This has turned into a big project, so that's going to take a while, and will be implemented in multiple stages. I expect further design changes as a result of insights developed while implementing all of this.



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD2 design docs

Neon22
Luckily its not a programming language at all.
Its a description of an object.
It is evaluated only once and it constructs an object as the result.
The description of the object uses sophisticated language-like expressions that
 allow for efficient, useful parametrisation of the object.

Most of the problem users face when trying to use this declarative description is in confusing it with a language.
E.g. the assignment operator.


On 7/4/2015 3:26 PM, Ben Simons wrote:
Re: [OpenSCAD] OpenSCAD2 design docs At
you write :
"In short, although it wasn't a design goal, OpenSCAD2 appears to have all of the necessary language mechanisms required to support object oriented programming. This may turn out to be useful in the future for structuring complex models or for writing new libraries of geometric objects."

==> It seems to me, taking an exising OO langugage and making a library for it would free you of all the hassle with parsing? Plus you have all the good parts of the language.  
Please don't mimic a professor/CEO which thinks he needs a new language.


OpenSCAD2 is a backwards compatible redesign of OpenSCAD. Some highlights:
  • everything is a first class value, including functions, modules, shapes, groups and scripts
  • single unified namespace, instead of 3 namespaces for variables, functions and modules
  • modules are unified with functions
  • the 'module composability bug' is fixed: 'intersection' now composes with 'for'
  • generic sequence operations and generalized list comprehensions
  • objects: external script files are referenced as object values; {script} is an object literal; 'object.name' looks up a named field in an object
  • groups are replaced by object values; the CSG tree is a tree of objects
  • the 'use' command is fixed: it can be used to reference any library
Design spec: https://github.com/doug-moen/openscad2

At this point, I'm looking for feedback and new collaborators. There may ways to improve parts of the design to make it easier to use, or more powerful, or less complex, or whatever. I expect that there are still bugs in the backward compatibility provisions that may trigger design changes.

Since it's all on github, you may open issues if you like.

I don't have any working code yet. This has turned into a big project, so that's going to take a while, and will be implemented in multiple stages. I expect further design changes as a result of insights developed while implementing all of this.




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6081 / Virus Database: 4365/10154 - Release Date: 07/03/15



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD2 design docs

MichaelAtOz
Administrator
In reply to this post by doug.moen
doug.moen wrote
OpenSCAD2 is a backwards compatible redesign of OpenSCAD.
   - single unified namespace, instead of 3 namespaces for variables,
   functions and modules
Aren't those two mutually exclusive. I have used, and seen in many other scripts, functions/modules/variables with the same name.
   - modules are unified with functions
What do you mean by that?

Admin - email* me if you need anything,
or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

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!
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD2 design docs

BenZ
In reply to this post by Neon22
Re: [OpenSCAD] OpenSCAD2 design docs Well, in exact theory you may be right for the current state. But he analyzed the future(!) as "appears to have all of the necessary language mechanisms".
I as a user have the feeling, maybe I'm wrong, but I have a real strong feeling (sarc), that I have to learn a new Syntax/method to create the objects in OpenScad.

I have the impression some people here want the brainfuxx. Well you can. You are free.
The next cheap laptop which supports OpenGL 4.3 will be on my shopping cart to test IceSL. They use, tataaaa....LUA. Not a language, eh?
Why LUA I don't know. Perhaps they want hinder all the millions of existing C/C# programmers by giving them a hard time. Or give their software a "professional/sophisticated" look. Well...


Luckily its not a programming language at all.
Its a description of an object.
It is evaluated only once and it constructs an object as the result.
The description of the object uses sophisticated language-like expressions that
allow for efficient, useful parametrisation of the object.

Most of the problem users face when trying to use this declarative description is in confusing it with a language.
E.g. the assignment operator.


On 7/4/2015 3:26 PM, Ben Simons wrote:
Re: [OpenSCAD] OpenSCAD2 design docs At
you write :
"In short, although it wasn't a design goal, OpenSCAD2 appears to have all of the necessary language mechanisms required to support object oriented programming. This may turn out to be useful in the future for structuring complex models or for writing new libraries of geometric objects."

==> It seems to me, taking an exising OO langugage and making a library for it would free you of all the hassle with parsing? Plus you have all the good parts of the language.  
Please don't mimic a professor/CEO which thinks he needs a new language.


OpenSCAD2 is a backwards compatible redesign of OpenSCAD. Some highlights:
  • everything is a first class value, including functions, modules, shapes, groups and scripts
  • single unified namespace, instead of 3 namespaces for variables, functions and modules
  • modules are unified with functions
  • the 'module composability bug' is fixed: 'intersection' now composes with 'for'
  • generic sequence operations and generalized list comprehensions
  • objects: external script files are referenced as object values; {script} is an object literal; 'object.name' looks up a named field in an object
  • groups are replaced by object values; the CSG tree is a tree of objects
  • the 'use' command is fixed: it can be used to reference any library


Design spec: https://github.com/doug-moen/openscad2

At this point, I'm looking for feedback and new collaborators. There may ways to improve parts of the design to make it easier to use, or more powerful, or less complex, or whatever. I expect that there are still bugs in the backward compatibility provisions that may trigger design changes.

Since it's all on github, you may open issues if you like.

I don't have any working code yet. This has turned into a big project, so that's going to take a while, and will be implemented in multiple stages. I expect further design changes as a result of insights developed while implementing all of this.





_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


No virus found in this message.
Checked by AVG -
www.avg.com
Version: 2015.0.6081 / Virus Database: 4365/10154 - Release Date: 07/03/15
Luckily its not a programming language at all.
Its a description of an object.
It is evaluated only once and it constructs an object as the result.
The description of the object uses sophisticated language-like expressions that
allow for efficient, useful parametrisation of the object.

Most of the problem users face when trying to use this declarative description is in confusing it with a language.
E.g. the assignment operator.


On 7/4/2015 3:26 PM, Ben Simons wrote:
At
you write :
"In short, although it wasn't a design goal, OpenSCAD2 appears to have all of the necessary language mechanisms required to support object oriented programming. This may turn out to be useful in the future for structuring complex models or for writing new libraries of geometric objects."

==> It seems to me, taking an exising OO langugage and making a library for it would free you of all the hassle with parsing? Plus you have all the good parts of the language.  
Please don't mimic a professor/CEO which thinks he needs a new language.


OpenSCAD2 is a backwards compatible redesign of OpenSCAD. Some highlights:
  • everything is a first class value, including functions, modules, shapes, groups and scripts
  • single unified namespace, instead of 3 namespaces for variables, functions and modules
  • modules are unified with functions
  • the 'module composability bug' is fixed: 'intersection' now composes with 'for'
  • generic sequence operations and generalized list comprehensions
  • objects: external script files are referenced as object values; {script} is an object literal; 'object.name' looks up a named field in an object
  • groups are replaced by object values; the CSG tree is a tree of objects
  • the 'use' command is fixed: it can be used to reference any library


Design spec: https://github.com/doug-moen/openscad2

At this point, I'm looking for feedback and new collaborators. There may ways to improve parts of the design to make it easier to use, or more powerful, or less complex, or whatever. I expect that there are still bugs in the backward compatibility provisions that may trigger design changes.

Since it's all on github, you may open issues if you like.

I don't have any working code yet. This has turned into a big project, so that's going to take a while, and will be implemented in multiple stages. I expect further design changes as a result of insights developed while implementing all of this.





_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


No virus found in this message.
Checked by AVG -
www.avg.com
Version: 2015.0.6081 / Virus Database: 4365/10154 - Release Date: 07/03/15


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
rk
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD2 design docs

rk
In reply to this post by doug.moen
Hi,

On Fri, Jul 03, 2015 at 07:07:45PM -0400, doug moen wrote:
>    - single unified namespace, instead of 3 namespaces for variables,
>    functions and modules
I would recommend namespaces, so that names of included/used libraries
cannot clash. I don't know how functional languages usually do this,
but I like the way Python does; for OpenSCAD it could look like:

use <mylib.scad>;
use <myotherlib.scad> as a;
from <somelib.scad> use *;
from <lib4.scad> use mod1, mod2;

mylib.myobject1();
a.myotherobject2();
mod1();

On Sat, Jul 04, 2015 at 04:35:05PM +1200, Mark Schafer wrote:
> Luckily its not a programming language at all.
> Its a description of an object.
> It is evaluated only once and it constructs an object as the result.
The OpenSCAD-language *is* a (functional) programming language.

And I'm absolutely sure that the OpenSCAD2-language will also be a
programming language -- simply because it's necessary.

Of course, you can start with a reduced description-language without
variables, assignments, conditionals or loops; but then, I'm sure
these features would be added later, because they are necessary.
And then, you'll have a programming language...
(By the way, the same happened already to some template-engine-languages,
where the authors first thought that they don't need a programming-
language...)

From the README:
> In short, although it wasn't a design goal, OpenSCAD2 appears to have
> all of the necessary language mechanisms required to support object
> oriented programming
I really like that OpenSCAD uses a functional programmming language,
although it's a bit unusual at the beginning, but as soon as you
understand the concept, it's fine.

And yes, it's unusual for beginners, which mostly think like procedural
languages and not like functional languages. ;) But this can be solved
by adding a procedural (or OO) language on top, which then creates
OpenSCAD-code.

If you want an OO-language for OpenSCAD2, how about Python? (Or better: Python3)
Python has a very readable syntax, is beginner-friendly, and has all
features you could need. The Python-program could then create OpenSCAD-code.
This way, you don't have to invent and implement a new language, you can
start step-by-step and directly test every feature, and test different
designs with minimal effort. When the design is fixed and tested, you
could still use a restricted Python-subset or even implement your own
parser, if you want to.


best regards
Roland

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD2 design docs

Neon22
In reply to this post by BenZ
I don't understand you - you do know that OpenSCAD uses CSG (Constructive Solid Geometry) ? You do know what that means right ?
Its a tree structure of boolean operations between primitives with transforms applied to them.
The tree structure can be evaluated in real-time (which is how Raytracers might use it (like POVray)),
or it can be evaluated to create a boundary rep (brep) describing the shape and this further sampled to create a triangular mesh shell (stl in this case).

So this tree structure could just be typed out as a tree but its hard for people to grasp the shape of the final object when described like this. History shows us its hard to author shapes using just that tree.
All the earlier reps of CSG trees are just that. CSG trees are also hard to animate which is why there are IIRC no CSG animation system since those originally developed at the Univ of Otago (Wyvill) in the early 90's.

OpenSCAD attempted to make it easier to describe the CSG tree by having local variables and things like loop constructs and if-then expressions to allow more shapes to be built from a smaller number of parameters.

Lua, Python, C variants are all programming languages. These ones are general purpose programming languages. A general purpose programming languages does not guarantee resolving to a tree structure. There could be loops in it (for example).

So using ANY such language would be a mistake unless its used to create a tree structure as a side effect of it running. IceSL does appear to do exactly this using an emit() function. I haven't looked further to see how they traverse the tree. We will all follow IceSL to see what their solution is I am sure. Their solution does not obviate this one which uses language like constructs to create the CSG Tree.

There's just no positive reason for you to attack this project because you have some weird idea that C programmers should all be catered to. You do know that there's a reason there is more than one programming language - I hope...
Why you think people would choose LUA to give the impression of "professional" I have no idea.
On the other hand its small, simple, lightweight, and easily embeddable. It has lexical scoping and GC. But it has no classes and no integers, and no error handling. I am sure the IceSL people took that into account when they made their decision.


On 7/4/2015 6:13 PM, Ben Simons wrote:
Re: [OpenSCAD] OpenSCAD2 design docs Well, in exact theory you may be right for the current state. But he analyzed the future(!) as "appears to have all of the necessary language mechanisms".
I as a user have the feeling, maybe I'm wrong, but I have a real strong feeling (sarc), that I have to learn a new Syntax/method to create the objects in OpenScad.

I have the impression some people here want the brainfuxx. Well you can. You are free.
The next cheap laptop which supports OpenGL 4.3 will be on my shopping cart to test IceSL. They use, tataaaa....LUA. Not a language, eh?
Why LUA I don't know. Perhaps they want hinder all the millions of existing C/C# programmers by giving them a hard time. Or give their software a "professional/sophisticated" look. Well...


Luckily its not a programming language at all.
Its a description of an object.
It is evaluated only once and it constructs an object as the result.
The description of the object uses sophisticated language-like expressions that
allow for efficient, useful parametrisation of the object.

Most of the problem users face when trying to use this declarative description is in confusing it with a language.
E.g. the assignment operator.


On 7/4/2015 3:26 PM, Ben Simons wrote:
Re: [OpenSCAD] OpenSCAD2 design docs At
you write :
"In short, although it wasn't a design goal, OpenSCAD2 appears to have all of the necessary language mechanisms required to support object oriented programming. This may turn out to be useful in the future for structuring complex models or for writing new libraries of geometric objects."

==> It seems to me, taking an exising OO langugage and making a library for it would free you of all the hassle with parsing? Plus you have all the good parts of the language.  
Please don't mimic a professor/CEO which thinks he needs a new language.


OpenSCAD2 is a backwards compatible redesign of OpenSCAD. Some highlights:
  • everything is a first class value, including functions, modules, shapes, groups and scripts
  • single unified namespace, instead of 3 namespaces for variables, functions and modules
  • modules are unified with functions
  • the 'module composability bug' is fixed: 'intersection' now composes with 'for'
  • generic sequence operations and generalized list comprehensions
  • objects: external script files are referenced as object values; {script} is an object literal; 'object.name' looks up a named field in an object
  • groups are replaced by object values; the CSG tree is a tree of objects
  • the 'use' command is fixed: it can be used to reference any library


Design spec: https://github.com/doug-moen/openscad2

At this point, I'm looking for feedback and new collaborators. There may ways to improve parts of the design to make it easier to use, or more powerful, or less complex, or whatever. I expect that there are still bugs in the backward compatibility provisions that may trigger design changes.

Since it's all on github, you may open issues if you like.

I don't have any working code yet. This has turned into a big project, so that's going to take a while, and will be implemented in multiple stages. I expect further design changes as a result of insights developed while implementing all of this.





_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


No virus found in this message.
Checked by AVG -
www.avg.com
Version: 2015.0.6081 / Virus Database: 4365/10154 - Release Date: 07/03/15
Luckily its not a programming language at all.
Its a description of an object.
It is evaluated only once and it constructs an object as the result.
The description of the object uses sophisticated language-like expressions that
allow for efficient, useful parametrisation of the object.

Most of the problem users face when trying to use this declarative description is in confusing it with a language.
E.g. the assignment operator.


On 7/4/2015 3:26 PM, Ben Simons wrote:
At
you write :
"In short, although it wasn't a design goal, OpenSCAD2 appears to have all of the necessary language mechanisms required to support object oriented programming. This may turn out to be useful in the future for structuring complex models or for writing new libraries of geometric objects."

==> It seems to me, taking an exising OO langugage and making a library for it would free you of all the hassle with parsing? Plus you have all the good parts of the language.  
Please don't mimic a professor/CEO which thinks he needs a new language.


OpenSCAD2 is a backwards compatible redesign of OpenSCAD. Some highlights:
  • everything is a first class value, including functions, modules, shapes, groups and scripts
  • single unified namespace, instead of 3 namespaces for variables, functions and modules
  • modules are unified with functions
  • the 'module composability bug' is fixed: 'intersection' now composes with 'for'
  • generic sequence operations and generalized list comprehensions
  • objects: external script files are referenced as object values; {script} is an object literal; 'object.name' looks up a named field in an object
  • groups are replaced by object values; the CSG tree is a tree of objects
  • the 'use' command is fixed: it can be used to reference any library


Design spec: https://github.com/doug-moen/openscad2

At this point, I'm looking for feedback and new collaborators. There may ways to improve parts of the design to make it easier to use, or more powerful, or less complex, or whatever. I expect that there are still bugs in the backward compatibility provisions that may trigger design changes.

Since it's all on github, you may open issues if you like.

I don't have any working code yet. This has turned into a big project, so that's going to take a while, and will be implemented in multiple stages. I expect further design changes as a result of insights developed while implementing all of this.





_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


No virus found in this message.
Checked by AVG -
www.avg.com
Version: 2015.0.6081 / Virus Database: 4365/10154 - Release Date: 07/03/15



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6081 / Virus Database: 4365/10154 - Release Date: 07/03/15



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD2 design docs

BenZ
Re: [OpenSCAD] OpenSCAD2 design docs Thanks for the explanation. Honestly, I did not knew all of it. I'm a user and so far wrote only one script on github which is faster than all the rest of the same type and some home appliances repair parts.
Special thanks also you described it in English and not in Swahili.
LUA is for most people Swahili. I don't know a single programmer who is fluent Lua speaker. I know a ton of C-variant speakers.
Also there are not many right-left languages or top down. Very hard for us to grasp. Luckily, in programming, they don't use different chars. But I'm sure the Chinese get stronger and since you can have some electronics data sheets only in Chinese this will change soon too.

But in programming all is different. Every now and then someone invents a new language, say...Spanish.
He has perfect reasoning why Spanish is needed (very good to express feelings/romance) and suddenly finds a community talking Spanish to each other (because they write romance books).
After that follows Italian(good foods), then German (to describe "Kraut" and worlds most advanced fusion reactors(really cool)) and then Russian(drinking and world class aviation).
And your argument is, that I'm too lazy to learn something new! If it makes sense then I would. But it doesn't. My understanding is that persons who invent a new programming language are:
- young (which is good) and inexperienced (not so good), jumping on every bandwagon
- psychopath (wants that we suffer)
- small dicked, err, I mean low self esteem
- professors in need to create papers
- CEO's protecting their revenue (apple / MS / Google wars)
- too lazy to implement it into another language (Ok, it might be easier with limited resources to create a new one)
- good people like the reader of this rant who ....

Instead, my idea is we should extend the existing stuff. Why not extend English with romance words/constructs? But of course, one does not earn a wikipedia entry as a person who allowed to type C++ without braces.
So all the rage is python. Or you could extend C# so it can describe tree structures better. No no no, we need a complete new syntax (sigh).
Furthermore, for each language we programmers create libraries/frameworks of everything again and again, ahhhhh and then the interoperability, fun!
It is good for our business, but not for humanity. And users of OpenScad are humans.

I do not attack the project, damn! I'm a bit spontaneous, excuse me for that.
My typing is here because I see that you have limited resources. Why invent a language if you have limited resources????
Why torture the persons with the biggest potential using OpenScad (the programmers) with an exotic syntax? I can do it yes. Of course I'm cool..hahahhoho...(walking around with stiff back). I can put it on my resumé!
For example it would be far more valuable to create a good object/shape framework. By far!!! We humans are simple and want often the same thing. Put it in the library. Thingiverse as library!!!
It would be 100 hundred percent more user friendly if one can type "bolt" and OpenScad's intellisense presents all bolts it knows...Or type NEMA and it presents 17,23,etc

It was an attempt to help. But my mouth messed all up, sigh...sorry.




I don't understand you - you do know that OpenSCAD uses CSG (Constructive Solid Geometry) ? You do know what that means right ?
Its a tree structure of boolean operations between primitives with transforms applied to them.
The tree structure can be evaluated in real-time (which is how Raytracers might use it (like POVray)),
or it can be evaluated to create a boundary rep (brep) describing the shape and this further sampled to create a triangular mesh shell (stl in this case).

So this tree structure could just be typed out as a tree but its hard for people to grasp the shape of the final object when described like this. History shows us its hard to author shapes using just that tree.
All the earlier reps of CSG trees are just that. CSG trees are also hard to animate which is why there are IIRC no CSG animation system since those originally developed at the Univ of Otago (Wyvill) in the early 90's.

OpenSCAD attempted to make it easier to describe the CSG tree by having local variables and things like loop constructs and if-then expressions to allow more shapes to be built from a smaller number of parameters.

Lua, Python, C variants are all programming languages. These ones are general purpose programming languages. A general purpose programming languages does not guarantee resolving to a tree structure. There could be loops in it (for example).

So using ANY such language would be a mistake unless its used to create a tree structure as a side effect of it running. IceSL does appear to do exactly this using an emit() function. I haven't looked further to see how they traverse the tree. We will all follow IceSL to see what their solution is I am sure. Their solution does not obviate this one which uses language like constructs to create the CSG Tree.

There's just no positive reason for you to attack this project because you have some weird idea that C programmers should all be catered to. You do know that there's a reason there is more than one programming language - I hope...
Why you think people would choose LUA to give the impression of "professional" I have no idea.
On the other hand its small, simple, lightweight, and easily embeddable. It has lexical scoping and GC. But it has no classes and no integers, and no error handling. I am sure the IceSL people took that into account when they made their decision.


On 7/4/2015 6:13 PM, Ben Simons wrote:
Re: [OpenSCAD] OpenSCAD2 design docs Well, in exact theory you may be right for the current state. But he analyzed the future(!) as "appears to have all of the necessary language mechanisms".
I as a user have the feeling, maybe I'm wrong, but I have a real strong feeling (sarc), that I have to learn a new Syntax/method to create the objects in OpenScad.

I have the impression some people here want the brainfuxx. Well you can. You are free.
The next cheap laptop which supports OpenGL 4.3 will be on my shopping cart to test IceSL. They use, tataaaa....LUA. Not a language, eh?
Why LUA I don't know. Perhaps they want hinder all the millions of existing C/C# programmers by giving them a hard time. Or give their software a "professional/sophisticated" look. Well...


Luckily its not a programming language at all.
Its a description of an object.
It is evaluated only once and it constructs an object as the result.
The description of the object uses sophisticated language-like expressions that
allow for efficient, useful parametrisation of the object.

Most of the problem users face when trying to use this declarative description is in confusing it with a language.
E.g. the assignment operator.


On 7/4/2015 3:26 PM, Ben Simons wrote:
Re: [OpenSCAD] OpenSCAD2 design docs At
you write :
"In short, although it wasn't a design goal, OpenSCAD2 appears to have all of the necessary language mechanisms required to support object oriented programming. This may turn out to be useful in the future for structuring complex models or for writing new libraries of geometric objects."

==> It seems to me, taking an exising OO langugage and making a library for it would free you of all the hassle with parsing? Plus you have all the good parts of the language.  
Please don't mimic a professor/CEO which thinks he needs a new language.


OpenSCAD2 is a backwards compatible redesign of OpenSCAD. Some highlights:
  • everything is a first class value, including functions, modules, shapes, groups and scripts
  • single unified namespace, instead of 3 namespaces for variables, functions and modules
  • modules are unified with functions
  • the 'module composability bug' is fixed: 'intersection' now composes with 'for'
  • generic sequence operations and generalized list comprehensions
  • objects: external script files are referenced as object values; {script} is an object literal; 'object.name' looks up a named field in an object
  • groups are replaced by object values; the CSG tree is a tree of objects
  • the 'use' command is fixed: it can be used to reference any library



Design spec: https://github.com/doug-moen/openscad2

At this point, I'm looking for feedback and new collaborators. There may ways to improve parts of the design to make it easier to use, or more powerful, or less complex, or whatever. I expect that there are still bugs in the backward compatibility provisions that may trigger design changes.

Since it's all on github, you may open issues if you like.

I don't have any working code yet. This has turned into a big project, so that's going to take a while, and will be implemented in multiple stages. I expect further design changes as a result of insights developed while implementing all of this.






_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


No virus found in this message.
Checked by AVG -
www.avg.com
Version: 2015.0.6081 / Virus Database: 4365/10154 - Release Date: 07/03/15
Luckily its not a programming language at all.
Its a description of an object.
It is evaluated only once and it constructs an object as the result.
The description of the object uses sophisticated language-like expressions that
allow for efficient, useful parametrisation of the object.

Most of the problem users face when trying to use this declarative description is in confusing it with a language.
E.g. the assignment operator.


On 7/4/2015 3:26 PM, Ben Simons wrote:
At
you write :
"In short, although it wasn't a design goal, OpenSCAD2 appears to have all of the necessary language mechanisms required to support object oriented programming. This may turn out to be useful in the future for structuring complex models or for writing new libraries of geometric objects."

==> It seems to me, taking an exising OO langugage and making a library for it would free you of all the hassle with parsing? Plus you have all the good parts of the language.  
Please don't mimic a professor/CEO which thinks he needs a new language.


OpenSCAD2 is a backwards compatible redesign of OpenSCAD. Some highlights:
  • everything is a first class value, including functions, modules, shapes, groups and scripts
  • single unified namespace, instead of 3 namespaces for variables, functions and modules
  • modules are unified with functions
  • the 'module composability bug' is fixed: 'intersection' now composes with 'for'
  • generic sequence operations and generalized list comprehensions
  • objects: external script files are referenced as object values; {script} is an object literal; 'object.name' looks up a named field in an object
  • groups are replaced by object values; the CSG tree is a tree of objects
  • the 'use' command is fixed: it can be used to reference any library



Design spec: https://github.com/doug-moen/openscad2

At this point, I'm looking for feedback and new collaborators. There may ways to improve parts of the design to make it easier to use, or more powerful, or less complex, or whatever. I expect that there are still bugs in the backward compatibility provisions that may trigger design changes.

Since it's all on github, you may open issues if you like.

I don't have any working code yet. This has turned into a big project, so that's going to take a while, and will be implemented in multiple stages. I expect further design changes as a result of insights developed while implementing all of this.






_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


No virus found in this message.
Checked by AVG -
www.avg.com
Version: 2015.0.6081 / Virus Database: 4365/10154 - Release Date: 07/03/15



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


No virus found in this message.
Checked by AVG -
www.avg.com
Version: 2015.0.6081 / Virus Database: 4365/10154 - Release Date: 07/03/15
I don't understand you - you do know that OpenSCAD uses CSG (Constructive Solid Geometry) ? You do know what that means right ?
Its a tree structure of boolean operations between primitives with transforms applied to them.
The tree structure can be evaluated in real-time (which is how Raytracers might use it (like POVray)),
or it can be evaluated to create a boundary rep (brep) describing the shape and this further sampled to create a triangular mesh shell (stl in this case).

So this tree structure could just be typed out as a tree but its hard for people to grasp the shape of the final object when described like this. History shows us its hard to author shapes using just that tree.
All the earlier reps of CSG trees are just that. CSG trees are also hard to animate which is why there are IIRC no CSG animation system since those originally developed at the Univ of Otago (Wyvill) in the early 90's.

OpenSCAD attempted to make it easier to describe the CSG tree by having local variables and things like loop constructs and if-then expressions to allow more shapes to be built from a smaller number of parameters.

Lua, Python, C variants are all programming languages. These ones are general purpose programming languages. A general purpose programming languages does not guarantee resolving to a tree structure. There could be loops in it (for example).

So using ANY such language would be a mistake unless its used to create a tree structure as a side effect of it running. IceSL does appear to do exactly this using an emit() function. I haven't looked further to see how they traverse the tree. We will all follow IceSL to see what their solution is I am sure. Their solution does not obviate this one which uses language like constructs to create the CSG Tree.

There's just no positive reason for you to attack this project because you have some weird idea that C programmers should all be catered to. You do know that there's a reason there is more than one programming language - I hope...
Why you think people would choose LUA to give the impression of "professional" I have no idea.
On the other hand its small, simple, lightweight, and easily embeddable. It has lexical scoping and GC. But it has no classes and no integers, and no error handling. I am sure the IceSL people took that into account when they made their decision.


On 7/4/2015 6:13 PM, Ben Simons wrote:
Well, in exact theory you may be right for the current state. But he analyzed the future(!) as "appears to have all of the necessary language mechanisms".
I as a user have the feeling, maybe I'm wrong, but I have a real strong feeling (sarc), that I have to learn a new Syntax/method to create the objects in OpenScad.

I have the impression some people here want the brainfuxx. Well you can. You are free.
The next cheap laptop which supports OpenGL 4.3 will be on my shopping cart to test IceSL. They use, tataaaa....LUA. Not a language, eh?
Why LUA I don't know. Perhaps they want hinder all the millions of existing C/C# programmers by giving them a hard time. Or give their software a "professional/sophisticated" look. Well...


Luckily its not a programming language at all.
Its a description of an object.
It is evaluated only once and it constructs an object as the result.
The description of the object uses sophisticated language-like expressions that
allow for efficient, useful parametrisation of the object.

Most of the problem users face when trying to use this declarative description is in confusing it with a language.
E.g. the assignment operator.


On 7/4/2015 3:26 PM, Ben Simons wrote:
Re: [OpenSCAD] OpenSCAD2 design docs At
you write :
"In short, although it wasn't a design goal, OpenSCAD2 appears to have all of the necessary language mechanisms required to support object oriented programming. This may turn out to be useful in the future for structuring complex models or for writing new libraries of geometric objects."

==> It seems to me, taking an exising OO langugage and making a library for it would free you of all the hassle with parsing? Plus you have all the good parts of the language.  
Please don't mimic a professor/CEO which thinks he needs a new language.


OpenSCAD2 is a backwards compatible redesign of OpenSCAD. Some highlights:
  • everything is a first class value, including functions, modules, shapes, groups and scripts
  • single unified namespace, instead of 3 namespaces for variables, functions and modules
  • modules are unified with functions
  • the 'module composability bug' is fixed: 'intersection' now composes with 'for'
  • generic sequence operations and generalized list comprehensions
  • objects: external script files are referenced as object values; {script} is an object literal; 'object.name' looks up a named field in an object
  • groups are replaced by object values; the CSG tree is a tree of objects
  • the 'use' command is fixed: it can be used to reference any library



Design spec: https://github.com/doug-moen/openscad2

At this point, I'm looking for feedback and new collaborators. There may ways to improve parts of the design to make it easier to use, or more powerful, or less complex, or whatever. I expect that there are still bugs in the backward compatibility provisions that may trigger design changes.

Since it's all on github, you may open issues if you like.

I don't have any working code yet. This has turned into a big project, so that's going to take a while, and will be implemented in multiple stages. I expect further design changes as a result of insights developed while implementing all of this.






_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


No virus found in this message.
Checked by AVG -
www.avg.com
Version: 2015.0.6081 / Virus Database: 4365/10154 - Release Date: 07/03/15
Luckily its not a programming language at all.
Its a description of an object.
It is evaluated only once and it constructs an object as the result.
The description of the object uses sophisticated language-like expressions that
allow for efficient, useful parametrisation of the object.

Most of the problem users face when trying to use this declarative description is in confusing it with a language.
E.g. the assignment operator.


On 7/4/2015 3:26 PM, Ben Simons wrote:
At
you write :
"In short, although it wasn't a design goal, OpenSCAD2 appears to have all of the necessary language mechanisms required to support object oriented programming. This may turn out to be useful in the future for structuring complex models or for writing new libraries of geometric objects."

==> It seems to me, taking an exising OO langugage and making a library for it would free you of all the hassle with parsing? Plus you have all the good parts of the language.  
Please don't mimic a professor/CEO which thinks he needs a new language.


OpenSCAD2 is a backwards compatible redesign of OpenSCAD. Some highlights:
  • everything is a first class value, including functions, modules, shapes, groups and scripts
  • single unified namespace, instead of 3 namespaces for variables, functions and modules
  • modules are unified with functions
  • the 'module composability bug' is fixed: 'intersection' now composes with 'for'
  • generic sequence operations and generalized list comprehensions
  • objects: external script files are referenced as object values; {script} is an object literal; 'object.name' looks up a named field in an object
  • groups are replaced by object values; the CSG tree is a tree of objects
  • the 'use' command is fixed: it can be used to reference any library



Design spec: https://github.com/doug-moen/openscad2

At this point, I'm looking for feedback and new collaborators. There may ways to improve parts of the design to make it easier to use, or more powerful, or less complex, or whatever. I expect that there are still bugs in the backward compatibility provisions that may trigger design changes.

Since it's all on github, you may open issues if you like.

I don't have any working code yet. This has turned into a big project, so that's going to take a while, and will be implemented in multiple stages. I expect further design changes as a result of insights developed while implementing all of this.






_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


No virus found in this message.
Checked by AVG -
www.avg.com
Version: 2015.0.6081 / Virus Database: 4365/10154 - Release Date: 07/03/15



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


No virus found in this message.
Checked by AVG -
www.avg.com
Version: 2015.0.6081 / Virus Database: 4365/10154 - Release Date: 07/03/15


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD2 design docs

G. Wade Johnson
You actually left out a really good reason to invent a language:
notation. Most programming languages are designed to make a particular
approach or solution easier than in other languages. One way to make
things easier to solve and understand is notation.

In ancient Rome, large number multiplication was considered advanced
math. Roman numerals do not make multiplication easy. Changing to the
positional notation we now use, makes multiplication of arbitrary
numbers so easy we teach it in elementary school.

OpenSCAD is a notation for describing objects, it is not a general
purpose programming language.

Although it may not be your intent, several of your examples come
across as condescending or insulting. I might humbly suggest that you
first understand the reasons why the designers of OpernSCAD are doing
what they do before assuming that you know a better solution.

G. Wade

On Sat, 4 Jul 2015 22:51:10 +0200
Ben Simons <[hidden email]> wrote:

> Re: [OpenSCAD] OpenSCAD2 design docs Thanks for the explanation.
> Honestly, I did not knew all of it. I'm a user and so far wrote only
> one script on github which is faster than all the rest of the same
> type and some home appliances repair parts. Special thanks also you
> described it in English and not in Swahili. LUA is for most people
> Swahili. I don't know a single programmer who is fluent Lua speaker.
> I know a ton of C-variant speakers. Also there are not many
> right-left languages or top down. Very hard for us to grasp. Luckily,
> in programming, they don't use different chars. But I'm sure the
> Chinese get stronger and since you can have some electronics data
> sheets only in Chinese this will change soon too.
>
> But in programming all is different. Every now and then someone
> invents a new language, say...Spanish. He has perfect reasoning why
> Spanish is needed (very good to express feelings/romance) and
> suddenly finds a community talking Spanish to each other (because
> they write romance books). After that follows Italian(good foods),
> then German (to describe "Kraut" and worlds most advanced fusion
> reactors(really cool)) and then Russian(drinking and world class
> aviation). And your argument is, that I'm too lazy to learn something
> new! If it makes sense then I would. But it doesn't. My understanding
> is that persons who invent a new programming language are:
> - young (which is good) and inexperienced (not so good), jumping on
> every bandwagon
> - psychopath (wants that we suffer)
> - small dicked, err, I mean low self esteem
> - professors in need to create papers
> - CEO's protecting their revenue (apple / MS / Google wars)
> - too lazy to implement it into another language (Ok, it might be
> easier with limited resources to create a new one)
> - good people like the reader of this rant who ....
>
> Instead, my idea is we should extend the existing stuff. Why not
> extend English with romance words/constructs? But of course, one does
> not earn a wikipedia entry as a person who allowed to type C++
> without braces. So all the rage is python. Or you could extend C# so
> it can describe tree structures better. No no no, we need a complete
> new syntax (sigh). Furthermore, for each language we programmers
> create libraries/frameworks of everything again and again, ahhhhh and
> then the interoperability, fun! It is good for our business, but not
> for humanity. And users of OpenScad are humans.
>
> I do not attack the project, damn! I'm a bit spontaneous, excuse me
> for that. My typing is here because I see that you have limited
> resources. Why invent a language if you have limited resources????
> Why torture the persons with the biggest potential using OpenScad
> (the programmers) with an exotic syntax? I can do it yes. Of course
> I'm cool..hahahhoho...(walking around with stiff back). I can put it
> on my resumé! For example it would be far more valuable to create a
> good object/shape framework. By far!!! We humans are simple and want
> often the same thing. Put it in the library. Thingiverse as
> library!!! It would be 100 hundred percent more user friendly if one
> can type "bolt" and OpenScad's intellisense presents all bolts it
> knows...Or type NEMA and it presents 17,23,etc
>
> It was an attempt to help. But my mouth messed all up, sigh...sorry.
>
>
>
>
> I don't understand you - you do know that OpenSCAD uses CSG
> (Constructive Solid Geometry) ? You do know what that means right ?
> Its a tree structure of boolean operations between primitives with
> transforms applied to them. The tree structure can be evaluated in
> real-time (which is how Raytracers might use it (like POVray)), or it
> can be evaluated to create a boundary rep (brep) describing the shape
> and this further sampled to create a triangular mesh shell (stl in
> this case).
>
> So this tree structure could just be typed out as a tree but its hard
> for people to grasp the shape of the final object when described like
> this. History shows us its hard to author shapes using just that
> tree. All the earlier reps of CSG trees are just that. CSG trees are
> also hard to animate which is why there are IIRC no CSG animation
> system since those originally developed at the Univ of Otago (Wyvill)
> in the early 90's.
>
> OpenSCAD attempted to make it easier to describe the CSG tree by
> having local variables and things like loop constructs and if-then
> expressions to allow more shapes to be built from a smaller number of
> parameters.
>
> Lua, Python, C variants are all programming languages. These ones are
> general purpose programming languages. A general purpose programming
> languages does not guarantee resolving to a tree structure. There
> could be loops in it (for example).
>
> So using ANY such language would be a mistake unless its used to
> create a tree structure as a side effect of it running. IceSL does
> appear to do exactly this using an emit() function. I haven't looked
> further to see how they traverse the tree. We will all follow IceSL
> to see what their solution is I am sure. Their solution does not
> obviate this one which uses language like constructs to create the
> CSG Tree.
>
> There's just no positive reason for you to attack this project
> because you have some weird idea that C programmers should all be
> catered to. You do know that there's a reason there is more than one
> programming language - I hope... Why you think people would choose
> LUA to give the impression of "professional" I have no idea. On the
> other hand its small, simple, lightweight, and easily embeddable. It
> has lexical scoping and GC. But it has no classes and no integers,
> and no error handling. I am sure the IceSL people took that into
> account when they made their decision.
>
>
> On 7/4/2015 6:13 PM, Ben Simons wrote:
> Re: [OpenSCAD] OpenSCAD2 design docs Well, in exact theory you may be
> right for the current state. But he analyzed the future(!) as
> "appears to have all of the necessary language mechanisms". I as a
> user have the feeling, maybe I'm wrong, but I have a real strong
> feeling (sarc), that I have to learn a new Syntax/method to create
> the objects in OpenScad.
>
> I have the impression some people here want the brainfuxx. Well you
> can. You are free. The next cheap laptop which supports OpenGL 4.3
> will be on my shopping cart to test IceSL. They use, tataaaa....LUA.
> Not a language, eh? Why LUA I don't know. Perhaps they want hinder
> all the millions of existing C/C# programmers by giving them a hard
> time. Or give their software a "professional/sophisticated" look.
> Well...
>
>
> Luckily its not a programming language at all.
> Its a description of an object.
> It is evaluated only once and it constructs an object as the result.
> The description of the object uses sophisticated language-like
> expressions that allow for efficient, useful parametrisation of the
> object.
>
> Most of the problem users face when trying to use this declarative
> description is in confusing it with a language. E.g. the assignment
> operator.
>
>
> On 7/4/2015 3:26 PM, Ben Simons wrote:
> Re: [OpenSCAD] OpenSCAD2 design docs At
> you write :
> "In short, although it wasn't a design goal, OpenSCAD2 appears to
> have all of the necessary language mechanisms required to support
> object oriented programming. This may turn out to be useful in the
> future for structuring complex models or for writing new libraries of
> geometric objects."
>
> ==> It seems to me, taking an exising OO langugage and making a
> library for it would free you of all the hassle with parsing? Plus
> you have all the good parts of the language. Please don't mimic a
> professor/CEO which thinks he needs a new language.
>
>
> OpenSCAD2 is a backwards compatible redesign of OpenSCAD. Some
> highlights: everything is a first class value, including functions,
> modules, shapes, groups and scripts single unified namespace, instead
> of 3 namespaces for variables, functions and modules modules are
> unified with functions the 'module composability bug' is fixed:
> 'intersection' now composes with 'for' generic sequence operations
> and generalized list comprehensions objects: external script files
> are referenced as object values; {script} is an object literal;
> 'object.name' looks up a named field in an object groups are replaced
> by object values; the CSG tree is a tree of objects the 'use' command
> is fixed: it can be used to reference any library
>
>
>
> Design spec: https://github.com/doug-moen/openscad2
>
> At this point, I'm looking for feedback and new collaborators. There
> may ways to improve parts of the design to make it easier to use, or
> more powerful, or less complex, or whatever. I expect that there are
> still bugs in the backward compatibility provisions that may trigger
> design changes.
>
> Since it's all on github, you may open issues if you like.
>
> I don't have any working code yet. This has turned into a big
> project, so that's going to take a while, and will be implemented in
> multiple stages. I expect further design changes as a result of
> insights developed while implementing all of this.
>
>
>
>
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2015.0.6081 / Virus Database: 4365/10154 - Release Date:
> 07/03/15
>
> Luckily its not a programming language at all.
> Its a description of an object.
> It is evaluated only once and it constructs an object as the result.
> The description of the object uses sophisticated language-like
> expressions that allow for efficient, useful parametrisation of the
> object.
>
> Most of the problem users face when trying to use this declarative
> description is in confusing it with a language. E.g. the assignment
> operator.
>
>
> On 7/4/2015 3:26 PM, Ben Simons wrote:
> At
> you write :
> "In short, although it wasn't a design goal, OpenSCAD2 appears to
> have all of the necessary language mechanisms required to support
> object oriented programming. This may turn out to be useful in the
> future for structuring complex models or for writing new libraries of
> geometric objects."
>
> ==> It seems to me, taking an exising OO langugage and making a
> library for it would free you of all the hassle with parsing? Plus
> you have all the good parts of the language. Please don't mimic a
> professor/CEO which thinks he needs a new language.
>
>
> OpenSCAD2 is a backwards compatible redesign of OpenSCAD. Some
> highlights: everything is a first class value, including functions,
> modules, shapes, groups and scripts single unified namespace, instead
> of 3 namespaces for variables, functions and modules modules are
> unified with functions the 'module composability bug' is fixed:
> 'intersection' now composes with 'for' generic sequence operations
> and generalized list comprehensions objects: external script files
> are referenced as object values; {script} is an object literal;
> 'object.name' looks up a named field in an object groups are replaced
> by object values; the CSG tree is a tree of objects the 'use' command
> is fixed: it can be used to reference any library
>
>
>
> Design spec: https://github.com/doug-moen/openscad2
>
> At this point, I'm looking for feedback and new collaborators. There
> may ways to improve parts of the design to make it easier to use, or
> more powerful, or less complex, or whatever. I expect that there are
> still bugs in the backward compatibility provisions that may trigger
> design changes.
>
> Since it's all on github, you may open issues if you like.
>
> I don't have any working code yet. This has turned into a big
> project, so that's going to take a while, and will be implemented in
> multiple stages. I expect further design changes as a result of
> insights developed while implementing all of this.
>
>
>
>
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2015.0.6081 / Virus Database: 4365/10154 - Release Date:
> 07/03/15
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2015.0.6081 / Virus Database: 4365/10154 - Release Date:
> 07/03/15
>
> I don't understand you - you do know that OpenSCAD uses CSG
> (Constructive Solid Geometry) ? You do know what that means right ?
> Its a tree structure of boolean operations between primitives with
> transforms applied to them. The tree structure can be evaluated in
> real-time (which is how Raytracers might use it (like POVray)), or it
> can be evaluated to create a boundary rep (brep) describing the shape
> and this further sampled to create a triangular mesh shell (stl in
> this case).
>
> So this tree structure could just be typed out as a tree but its hard
> for people to grasp the shape of the final object when described like
> this. History shows us its hard to author shapes using just that
> tree. All the earlier reps of CSG trees are just that. CSG trees are
> also hard to animate which is why there are IIRC no CSG animation
> system since those originally developed at the Univ of Otago (Wyvill)
> in the early 90's.
>
> OpenSCAD attempted to make it easier to describe the CSG tree by
> having local variables and things like loop constructs and if-then
> expressions to allow more shapes to be built from a smaller number of
> parameters.
>
> Lua, Python, C variants are all programming languages. These ones are
> general purpose programming languages. A general purpose programming
> languages does not guarantee resolving to a tree structure. There
> could be loops in it (for example).
>
> So using ANY such language would be a mistake unless its used to
> create a tree structure as a side effect of it running. IceSL does
> appear to do exactly this using an emit() function. I haven't looked
> further to see how they traverse the tree. We will all follow IceSL
> to see what their solution is I am sure. Their solution does not
> obviate this one which uses language like constructs to create the
> CSG Tree.
>
> There's just no positive reason for you to attack this project
> because you have some weird idea that C programmers should all be
> catered to. You do know that there's a reason there is more than one
> programming language - I hope... Why you think people would choose
> LUA to give the impression of "professional" I have no idea. On the
> other hand its small, simple, lightweight, and easily embeddable. It
> has lexical scoping and GC. But it has no classes and no integers,
> and no error handling. I am sure the IceSL people took that into
> account when they made their decision.
>
>
> On 7/4/2015 6:13 PM, Ben Simons wrote:
> Well, in exact theory you may be right for the current state. But he
> analyzed the future(!) as "appears to have all of the necessary
> language mechanisms". I as a user have the feeling, maybe I'm wrong,
> but I have a real strong feeling (sarc), that I have to learn a new
> Syntax/method to create the objects in OpenScad.
>
> I have the impression some people here want the brainfuxx. Well you
> can. You are free. The next cheap laptop which supports OpenGL 4.3
> will be on my shopping cart to test IceSL. They use, tataaaa....LUA.
> Not a language, eh? Why LUA I don't know. Perhaps they want hinder
> all the millions of existing C/C# programmers by giving them a hard
> time. Or give their software a "professional/sophisticated" look.
> Well...
>
>
> Luckily its not a programming language at all.
> Its a description of an object.
> It is evaluated only once and it constructs an object as the result.
> The description of the object uses sophisticated language-like
> expressions that allow for efficient, useful parametrisation of the
> object.
>
> Most of the problem users face when trying to use this declarative
> description is in confusing it with a language. E.g. the assignment
> operator.
>
>
> On 7/4/2015 3:26 PM, Ben Simons wrote:
> Re: [OpenSCAD] OpenSCAD2 design docs At
> you write :
> "In short, although it wasn't a design goal, OpenSCAD2 appears to
> have all of the necessary language mechanisms required to support
> object oriented programming. This may turn out to be useful in the
> future for structuring complex models or for writing new libraries of
> geometric objects."
>
> ==> It seems to me, taking an exising OO langugage and making a
> library for it would free you of all the hassle with parsing? Plus
> you have all the good parts of the language. Please don't mimic a
> professor/CEO which thinks he needs a new language.
>
>
> OpenSCAD2 is a backwards compatible redesign of OpenSCAD. Some
> highlights: everything is a first class value, including functions,
> modules, shapes, groups and scripts single unified namespace, instead
> of 3 namespaces for variables, functions and modules modules are
> unified with functions the 'module composability bug' is fixed:
> 'intersection' now composes with 'for' generic sequence operations
> and generalized list comprehensions objects: external script files
> are referenced as object values; {script} is an object literal;
> 'object.name' looks up a named field in an object groups are replaced
> by object values; the CSG tree is a tree of objects the 'use' command
> is fixed: it can be used to reference any library
>
>
>
> Design spec: https://github.com/doug-moen/openscad2
>
> At this point, I'm looking for feedback and new collaborators. There
> may ways to improve parts of the design to make it easier to use, or
> more powerful, or less complex, or whatever. I expect that there are
> still bugs in the backward compatibility provisions that may trigger
> design changes.
>
> Since it's all on github, you may open issues if you like.
>
> I don't have any working code yet. This has turned into a big
> project, so that's going to take a while, and will be implemented in
> multiple stages. I expect further design changes as a result of
> insights developed while implementing all of this.
>
>
>
>
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2015.0.6081 / Virus Database: 4365/10154 - Release Date:
> 07/03/15
>
> Luckily its not a programming language at all.
> Its a description of an object.
> It is evaluated only once and it constructs an object as the result.
> The description of the object uses sophisticated language-like
> expressions that allow for efficient, useful parametrisation of the
> object.
>
> Most of the problem users face when trying to use this declarative
> description is in confusing it with a language. E.g. the assignment
> operator.
>
>
> On 7/4/2015 3:26 PM, Ben Simons wrote:
> At
> you write :
> "In short, although it wasn't a design goal, OpenSCAD2 appears to
> have all of the necessary language mechanisms required to support
> object oriented programming. This may turn out to be useful in the
> future for structuring complex models or for writing new libraries of
> geometric objects."
>
> ==> It seems to me, taking an exising OO langugage and making a
> library for it would free you of all the hassle with parsing? Plus
> you have all the good parts of the language. Please don't mimic a
> professor/CEO which thinks he needs a new language.
>
>
> OpenSCAD2 is a backwards compatible redesign of OpenSCAD. Some
> highlights: everything is a first class value, including functions,
> modules, shapes, groups and scripts single unified namespace, instead
> of 3 namespaces for variables, functions and modules modules are
> unified with functions the 'module composability bug' is fixed:
> 'intersection' now composes with 'for' generic sequence operations
> and generalized list comprehensions objects: external script files
> are referenced as object values; {script} is an object literal;
> 'object.name' looks up a named field in an object groups are replaced
> by object values; the CSG tree is a tree of objects the 'use' command
> is fixed: it can be used to reference any library
>
>
>
> Design spec: https://github.com/doug-moen/openscad2
>
> At this point, I'm looking for feedback and new collaborators. There
> may ways to improve parts of the design to make it easier to use, or
> more powerful, or less complex, or whatever. I expect that there are
> still bugs in the backward compatibility provisions that may trigger
> design changes.
>
> Since it's all on github, you may open issues if you like.
>
> I don't have any working code yet. This has turned into a big
> project, so that's going to take a while, and will be implemented in
> multiple stages. I expect further design changes as a result of
> insights developed while implementing all of this.
>
>
>
>
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2015.0.6081 / Virus Database: 4365/10154 - Release Date:
> 07/03/15
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2015.0.6081 / Virus Database: 4365/10154 - Release Date:
> 07/03/15
>


--
Java is a DSL for taking large XML files and converting them to stack
traces                                        -- Bulat Shakirzyanov

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD2 design docs

doug.moen
In reply to this post by BenZ
Hi Ben. Congratulations, you have managed to use my own words to completely mischaracterize what my project is all about. Somehow, you managed to ignore almost everything I wrote, quoted one sentence out of context, and used it against me.

Also, I have to say that your vicious personal attacks against me go far beyond anything I would have expected to read on the OpenSCAD forum. No, I am not a psychopath. No, this project is not compensation for my small dick.

For everybody else, yes of course I understand that OpenSCAD is a stateless, "functional" language, and that it is much easier to use than a general purpose programming language. My design document actually states both of these things as design goals.

On 3 July 2015 at 23:26, Ben Simons <[hidden email]> wrote:
At
you write :
"In short, although it wasn't a design goal, OpenSCAD2 appears to have all of the necessary language mechanisms required to support object oriented programming. This may turn out to be useful in the future for structuring complex models or for writing new libraries of geometric objects."

==> It seems to me, taking an exising OO langugage and making a library for it would free you of all the hassle with parsing? Plus you have all the good parts of the language.  
Please don't mimic a professor/CEO which thinks he needs a new language.


OpenSCAD2 is a backwards compatible redesign of OpenSCAD. Some highlights:
  • everything is a first class value, including functions, modules, shapes, groups and scripts
  • single unified namespace, instead of 3 namespaces for variables, functions and modules
  • modules are unified with functions
  • the 'module composability bug' is fixed: 'intersection' now composes with 'for'
  • generic sequence operations and generalized list comprehensions
  • objects: external script files are referenced as object values; {script} is an object literal; 'object.name' looks up a named field in an object
  • groups are replaced by object values; the CSG tree is a tree of objects
  • the 'use' command is fixed: it can be used to reference any library
Design spec: https://github.com/doug-moen/openscad2

At this point, I'm looking for feedback and new collaborators. There may ways to improve parts of the design to make it easier to use, or more powerful, or less complex, or whatever. I expect that there are still bugs in the backward compatibility provisions that may trigger design changes.

Since it's all on github, you may open issues if you like.

I don't have any working code yet. This has turned into a big project, so that's going to take a while, and will be implemented in multiple stages. I expect further design changes as a result of insights developed while implementing all of this.



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD2 design docs

BenZ
Re: [OpenSCAD] OpenSCAD2 design docs Well, actually, I thought you are clever because you wanted to change it in the correct direction.
The three dots in the last option were for you and others here.
Ok, I don't say anything anymore.
My wording is bad...


Hi Ben. Congratulations, you have managed to use my own words to completely mischaracterize what my project is all about. Somehow, you managed to ignore almost everything I wrote, quoted one sentence out of context, and used it against me.

Also, I have to say that your vicious personal attacks against me go far beyond anything I would have expected to read on the OpenSCAD forum. No, I am not a psychopath. No, this project is not compensation for my small dick.

For everybody else, yes of course I understand that OpenSCAD is a stateless, "functional" language, and that it is much easier to use than a general purpose programming language. My design document actually states both of these things as design goals.

On 3 July 2015 at 23:26, Ben Simons <
[hidden email]> wrote:
At
you write :
"In short, although it wasn't a design goal, OpenSCAD2 appears to have all of the necessary language mechanisms required to support object oriented programming. This may turn out to be useful in the future for structuring complex models or for writing new libraries of geometric objects."

==> It seems to me, taking an exising OO langugage and making a library for it would free you of all the hassle with parsing? Plus you have all the good parts of the language.  
Please don't mimic a professor/CEO which thinks he needs a new language.


OpenSCAD2 is a backwards compatible redesign of OpenSCAD. Some highlights:
  • everything is a first class value, including functions, modules, shapes, groups and scripts
  • single unified namespace, instead of 3 namespaces for variables, functions and modules
  • modules are unified with functions
  • the 'module composability bug' is fixed: 'intersection' now composes with 'for'
  • generic sequence operations and generalized list comprehensions
  • objects: external script files are referenced as object values; {script} is an object literal; 'object.name' looks up a named field in an object
  • groups are replaced by object values; the CSG tree is a tree of objects
  • the 'use' command is fixed: it can be used to reference any library


Design spec: https://github.com/doug-moen/openscad2

At this point, I'm looking for feedback and new collaborators. There may ways to improve parts of the design to make it easier to use, or more powerful, or less complex, or whatever. I expect that there are still bugs in the backward compatibility provisions that may trigger design changes.

Since it's all on github, you may open issues if you like.

I don't have any working code yet. This has turned into a big project, so that's going to take a while, and will be implemented in multiple stages. I expect further design changes as a result of insights developed while implementing all of this.




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD2 design docs

L Boyd
In reply to this post by doug.moen
Using a general purpose language is great in the academic world, but not the efficient way to address a specific problem. I have spent some 50 years creating specific solutions where the general purpose solution was much slower, sometime by a factor of 100.

Keep up your good work and don't let the C/C+ freaks distract you.
Larry
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD2 design docs

MichaelAtOz
Administrator
L Boyd wrote
some 50 years creating specific solutions
...if you count Tandy TRS-80 fiddling in the store, with BASIC and cassettes, then I can count 40 odd years...I wrote a pretty good shoot-em-up game...

Not as good as my DEC VT100 based space game I did at Uni...Shame you never get credits for that stuff back then...

So I'm assuming I'm a bit wiser than I feel older... ;)
Admin - email* me if you need anything,
or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

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!
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD2 design docs

L Boyd
I know what you mean about not getting credit for what you did way back then. No one remembers that I was the first one outside of Dartmouth to write a BASIC compiler. It was a one pass compiler for the SDS 940 which fit in 2K (24 bit) words of read only memory. When IBM later wrote their version, it used over 100K words.
Larry
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD2 design docs

jdawgaz
I was wondering. I do that occasionally :-)

if a use("v2") statement was at the top of the file. Could a lot of the extra functions be the same name as the old ones, but with the different args needed? Or is that too much work?

jerry


Jerry

--
Extra Ham Operator: K7AZJ
Registered Linux User: 275424
Raspberry Pi and Arduino developer

The most exciting phrase to hear in science - the one that heralds new discoveries - is not "Eureka!" but "That's funny...".
- Isaac. Asimov

If you give someone a program, you will frustrate them for a day; if you teach them how to program, you will frustrate them for a lifetime. 
- Anonymous

If writing good code requires very little comments, then writing really excellent code requires no comments at all!
- Ken Thompson


On Mon, Jul 6, 2015 at 7:02 AM, L Boyd <[hidden email]> wrote:
I know what you mean about not getting credit for what you did way back then.
No one remembers that I was the first one outside of Dartmouth to write a
BASIC compiler. It was a one pass compiler for the SDS 940 which fit in 2K
(24 bit) words of read only memory. When IBM later wrote their version, it
used over 100K words.



--
View this message in context: http://forum.openscad.org/OpenSCAD2-design-docs-tp13019p13067.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD2 design docs

MichaelAtOz
Administrator
In reply to this post by MichaelAtOz
Re scope rules for v2.

I have used this layout


{ // rECESS - the hollow holder where accessories are inserted
rTolerance=0.0; // adjust - originally the ID of the print was marginally tight 2.05 2.75
rOD=40;
rID=35.5;
rThick=2-rTolerance;
rDeep=38; // was 45
}

{ // rECESS Ridge - the raised ridges running down inside the holder
rRidgeHigh=0.75-rTolerance;
rRidgeWide=3;
rRidgeWide0=6.2; // at mid-line parallel with slot at top
rRidgeNum=6; // spacing, includes the one cut away by wide slot
}

To group the definitions but mainly to allow me to collapse them in the editor.

I think I have seen other code in the wild doing so too.

Is that going to be problematic in v2 scoping?
Admin - email* me if you need anything,
or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

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!
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD2 design docs

MichaelAtOz
Administrator
Note in the email the line breaks were removed.
Admin - email* me if you need anything,
or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

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!
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD2 design docs

runsun
In reply to this post by doug.moen
Doug (in other thread) wrote
 
In OpenSCAD2, the syntax {...} is an expression that returns a geometric
object.
For example, { size=10; cube(size); } is an expression.

You can give this expression a name:

   mycube = {
      size=10;
      cube(size);
   };

Now 'mycube' is the name of a geometric object.

   echo(mycube.size); // ECHO: 10

   rotate(45) mycube;

Doug.
1) I'd prefer that this geometric object has some built-in parameters, for example, like points:

   echo( mycube.points );

   So we can do these:

      1.1) translate( mycube.points[3]) yourcube;

      1.2) for( p= mycube.points ) translate( p ) sphere(...);

      1.3)  for( i= mycube.points[4:] )         // pick up the second half
                 mycube.points[i]= somefunc(i); // re-assign points to change shape

      1.4) Assuming we have a Line() module, draw a line to connect two objects (at specified points):

            Line( mycube.points[0], yourcube.points[2] )

      1.5) distance( mycube.points[0], yourcube.points[2] )

2) I'd prefer all those actions, like translate, rotate, union, etc, can be functions, too:

       yourcube = rotate( mycube, 45 );
       hiscube = translate( yourcube.points[2] );

All the ideas have one thing in mind: keeping track of coordinates for further operations.        
$ Runsun Pan, PhD
$ libs: scadx, doctest, faces(git), offline doc(git), runscad.py(2,git), editor of choice: CudaText ( OpenSCAD lexer); $ Tips; $ Snippets
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD2 design docs

doug.moen
In reply to this post by MichaelAtOz
MichaelAtOz notes that a top level compound statement, {...}, is interpreted by OpenSCAD as if the braces aren't there. Michael uses this to group sets of related definitions within a large script, so that they can be collapsed by the folding tree editor.

This is new information for me: I didn't know that people are using this design pattern "in the wild", as Michael says.

Right now, the idiomatic way to write this code in OpenSCAD2 is:

include { // rECESS - the hollow holder where accessories are inserted
rTolerance=0.0; // adjust - originally the ID of the print was marginally
tight 2.05 2.75
rOD=40;
rID=35.5;
rThick=2-rTolerance;
rDeep=38;               // was 45
};

include { // rECESS Ridge - the raised ridges running down inside the holder
rRidgeHigh=0.75-rTolerance;
rRidgeWide=3;
rRidgeWide0=6.2;        // at mid-line parallel with slot at top
rRidgeNum=6;    // spacing, includes the one cut away by wide slot
};

Explanation: the OpenSCAD2 'include' operator takes an object expression as an argument, and {...} is an object literal.

Also, in OpenSCAD2, objects are the replacement for groups in the CSG tree. Each non-leaf node in the CSG tree is an object. As a result, "top level compound statements" could appear naturally in code as a representation of nested objects in a CSG tree. And that conflicts with the current use of that syntax that Michael reports.

At present, this is an incompatibility between the existing language and OpenSCAD2 that I wasn't aware of.

The new OpenSCAD implementation will use heuristics to detect OpenSCAD1 code and run in backward compatibility mode. It should be capable of detecting Michael's code and evaluating it correctly without breaking. There will also be an upgrade tool that converts existing code to use the new syntax, and we could convert top level {...} statements to 'include {...};' as part of the upgrade.

Michael, do you think this is an acceptable solution to the problem that you uncovered?

Doug.

On 18 July 2015 at 01:10, MichaelAtOz <[hidden email]> wrote:
Re scope rules for v2.

I have used this layout


{ // rECESS - the hollow holder where accessories are inserted
rTolerance=0.0; // adjust - originally the ID of the print was marginally
tight 2.05 2.75
rOD=40;
rID=35.5;
rThick=2-rTolerance;
rDeep=38;               // was 45
}

{ // rECESS Ridge - the raised ridges running down inside the holder
rRidgeHigh=0.75-rTolerance;
rRidgeWide=3;
rRidgeWide0=6.2;        // at mid-line parallel with slot at top
rRidgeNum=6;    // spacing, includes the one cut away by wide slot
}

To group the definitions but mainly to allow me to collapse them in the
editor.

I think I have seen other code in the wild doing so too.

Is that going to be problematic in v2 scoping?




-----
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. This work is published globally via the internet. :) 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/
--
View this message in context: http://forum.openscad.org/OpenSCAD2-design-docs-tp13019p13225.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
12