OpenSCAD2 design docs
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.
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
I
*f 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 doug@moens.org 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
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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Re: [OpenSCAD] OpenSCAD2 design docsAt
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.
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.
<pre wrap="">_______________________________________________ OpenSCAD mailing list <a class="moz-txt-link-abbreviated" href="mailto:Discuss@lists.openscad.org">Discuss@lists.openscad.org</a> <a class="moz-txt-link-freetext" href="http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org">http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org</a>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
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?
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-tp13019p13023.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Re: [OpenSCAD] OpenSCAD2 design docsWell, 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
Discuss@lists.openscad.org
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/15Luckily 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
Discuss@lists.openscad.org
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
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
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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.orgNo 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.orgNo virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6081 / Virus Database: 4365/10154 - Release Date: 07/03/15<pre wrap="">_______________________________________________ OpenSCAD mailing list <a class="moz-txt-link-abbreviated" href="mailto:Discuss@lists.openscad.org">Discuss@lists.openscad.org</a> <a class="moz-txt-link-freetext" href="http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org">http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org</a>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
Re: [OpenSCAD] OpenSCAD2 design docsThanks 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
Discuss@lists.openscad.org
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/15Luckily 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
Discuss@lists.openscad.org
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
Discuss@lists.openscad.org
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/15I 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
Discuss@lists.openscad.org
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/15Luckily 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
Discuss@lists.openscad.org
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
Discuss@lists.openscad.org
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
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 zuiopl@hotmail.com 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
Discuss@lists.openscad.org
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
Discuss@lists.openscad.org
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
Discuss@lists.openscad.org
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
Discuss@lists.openscad.org
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
Discuss@lists.openscad.org
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
Discuss@lists.openscad.org
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