Extending OpenSCAD from assembler to C or Perlish language and adding standard library
On 29.09.19 09:45, Robin2 wrote:
On the specific point of linking with other languages it
seems to me it would make sense to turn that on its head
and use another language (such as Python) to generate
Openscad code as it could then draw on all the wide-ranging
capabilities available to Python (or whatever language you
prefer) without needing to make any changes to Openscad.
I think there's probably a number of use cases where
using a separate driver based on a different language like
python makes sense. I can image creating models based
on data from a database.
However I'm not sure generating the full OpenSCAD source
code is the best way to go. Both from effort in the other
language and also from architecture view. In most cases
it might be better to generate the core data from the
external tool and use that in the model. This also gives
a nice separation of concerns which is a good strategy
even with just a single language.
ciao,
Torsten.
And it doesn't break referential transparency.
Please explain how? I have seen other languages like rust explicitly say
that data should be immutable to allow it to be shared between threads.
On Sun, 29 Sep 2019 at 18:01, Doug Moen doug@moens.org wrote:
Revar: Everything on your list is possible, given sufficient development
resources,
and given the willingness to make language language changes (there's a
tradeoff:
new features add complexity while making the language more powerful).
I want to mention that mutable variables are not "nearly impossible to
implement
with the current design". I proposed a design for adding mutable variables
while
retaining backward compatibility, years ago:
https://github.com/openscad/openscad/wiki/Mutable-Variables
The key idea is: You can't redefine the = operator as an assignment
operator for mutable variables without breaking backward compatibility, so
I introduced := as the assignment operator.
The reaction was mixed.
- One person, who has written complex algorithms using data structures in
OpenSCAD, was enthusiastic (but hated the syntax). - Another person claimed that this would destroy referential transparency
and make it impossible to use data parallelism to make OpenSCAD run
much faster. This isn't actually true, though. - Other people pointed out that the syntax is ugly and that grafting
imperative features into OpenSCAD adds too much complexity.
I implemented a simpler and more refined version of that old proposal
in Curv, which is my personal OpenSCAD successor. The syntax I use for
mutable variables could be added to OpenSCAD without breaking
backward compatibility. And it doesn't break referential transparency.
Curv is required to be referentially transparent, because I compile Curv
into data parallel code that renders quickly.
I think that the people who want mutable variables in OpenSCAD
would prefer a more Pythonic syntax: a=b is used both to define
a new variable, and to reassign an existing variable. That would make
variables easier to understand and use, but it would break backward
compatibility.
RapCAD is a fork of OpenSCAD that works this way. It has mutable variable
and various other improvements. https://github.com/GilesBathgate/RapCAD
RapCAD doesn't have most things in Revar's wishlist, and to get that, I
think
you realistically need to look at doing OpenSCAD things from within a
general purpose language. I'm skeptical that OpenSCAD will ever be
extended into a GP language, and some people in this thread have already
spoken against the idea.
AngelCAD is an embedding of OpenSCAD-like features in a GP language
called AngelScript. Carsten mentions AngelCAD regularly on this forum.
https://github.com/arnholm/angelcad
If you want to use a more mainstream language, like Javascript or Python,
then you should consider using OpenJSCAD or SolidPython.
Both projects have been around for many years and are still being updated.
OpenJSCAD supports both OpenSCAD and Javascript syntax,
and it runs in a web browser. https://openjscad.org/
SolidPython lets you define models using Python, then it generates
OpenSCAD code to render the model.
https://github.com/SolidCode/SolidPython
Doug Moen.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 29.09.19 04:38, Revar Desmera wrote:
- Mutable variables. I know that this is nearly impossible
to implement with the current design, and I understand the
reasoning, even if I don't necessarily agree with the design
decisions.
No, as long as it's about variable assignment, there's
nothing in the current implementation that would prevent
that. It's maybe not even complicated. I biggest concern
is probably the compatibility.
Doug mentioned there are ways to do that in a backward
compatible way so that's worth having a look at.
That does not mean mutable values (e.g. vectors) though. I
suspect that's something that might not happen.
It's not something very high at my personal wish-list at
this point. But having the discussion of how to integrate
it without breaking existing scripts might get someone
interested in jumping at the topic.
- Better data structures. Classes would be beautiful.
I'm not sure if that fits the bill, but what I want to
look at next, after the function literals are the object
literals from
https://github.com/doug-moen/openscad2/blob/master/rfc/Objects.md
I tried before but the existing parser did not allow the
needed nested member lookup. I believe the changes from
the function literal branch will solve that issue so it
should be trivial to add at least parts of the proposal.
For example exposing additional information about imported
files or even representing a JSON file as object tree.
- The work I've seen on passing functions as a first
class object has been excellent. Good job there!
Thanks, still some open topics to solve, but it's moving
at least :-). Also, just to highlight that again, big
thanks to Doug for his work on the OpenSCAD2 proposal.
- The ability to rename built-in and existing modules/
functions would allow for extending functionality on
things likelinear_extrude(),polygon(), andpolyhedron().
I think the feature for that would be namespaces.
Actually renaming the internal name seems like a recipe
for disaster when using multiple libraries.
I'm thinking there might be a simple solution for
just one special case. Allowing access to the internal
version instead of whatever is shadowing it might not
be the most general solution, but might already catch
some of the most needed use cases.
e.g. something like:
module cube() ::cube(center = true);
I would assume that is not even very hard to do.
It would be nice to get some input from language design
perspective. I don't know anyone except Doug who has
experience in that topic.
- Access to the bounds of 2D/3D geometry, if not access
to the vertex list. Again, I know this is very difficult,
and why it is difficult, but the ability to get geometry
bounds would enable various functionality that I have
been wanting to do, but can't.
What functionality is that? There might be other ways to
get there in some cases.
- Ways to call external C/C++ libraries like ClipperLib.
While possible this seems to make everything dependent on
a specific setup and existing libraries.
- Ability to read a file from disk, and better string/
binary processing functions.
I don't see a problem with that. It would needs some more
specific definition as anything which goes into the language
is difficult to change later.
ciao,
Torsten.
tp3 wrote
However I'm not sure generating the full OpenSCAD source
code is the best way to go. Both from effort in the other
language and also from architecture view. In most cases
it might be better to generate the core data from the
external tool and use that in the model. This also gives
a nice separation of concerns which is a good strategy
even with just a single language.
I would appreciate it if you could expand on this.
I am working on a Python program that allows a user to select things (such
as Cube or Translate or Difference) by clicking a mouse and providing the
numbers (such as the dimensions of the cube). The Python program then writes
the text for the necessary scad file and Openscad interprets it and creates
the model. I don't have to do all the tedious Openscad typing when I want to
create a design. The Python program is not complex and it knows nothing
about 3D design - it is just a text generator.
I'm not clear from your comments whether you are thinking of that sort of
tool, or a very different usage of (e.g.) Python.
...R
--
Sent from: http://forum.openscad.org/
On 29.09.19 21:01, Robin2 wrote:
I would appreciate it if you could expand on this.
Most of the "Py*SCAD.py" projects are mirroring the
model generation in python itself. Again there might
be use case that actually need that. But in general
I find actual model description in OpenSCAD much more
concise in the OpenSCAD DSL due to some of the
behavior is implied (like modules returning the
geometry).
The architecture comment is something about how to
structure code. I'm seeing lots of code like (not
related to OpenSCAD at all...):
- read database and loop over rows
- call function with data of one row
- read/compute additional data for row
- act on that data, e.g. call external system
- forget about everything calculated in that call
That is hard to optimize, difficult to debug and also
very complicated to extend (even more so if that is
all based on deep object hierarchies but that's another
can of worms).
In my experience it's much better to do all the
calculation possible in the beginning and start acting
on the data only at the point all the information is
already gathered.
I am working on a Python program that allows a user
to select things (such as Cube or Translate or Difference)
by clicking a mouse and providing the numbers (such
as the dimensions of the cube).
Right, so something like BlocksCAD or similar tools?
Well, that's a special use case, more like a frontend
to the existing language. I guess the general comments
do not apply as much to that.
I'm still dreaming of having something like that
directly as feature in OpenSCAD, but I suspect that will
always remain a dream.
ciao,
Torsten.
On Sun, Sep 29, 2019, at 6:46 PM, nop head wrote:
And it doesn't break referential transparency.
Please explain how? I have seen other languages like rust explicitly say that data should be immutable to allow it to be shared between threads.
Curv supports mutable local variables, but not mutable global variables. This provides just enough support for imperative style programming to allow me to port imperative algorithms from other languages into Curv, without forcing me to convert while loops into tail recursion. But Curv is not a fully imperative language. Functions are pure (the result of a function depends only on its arguments). There is a referentially transparent expression language and an imperative statement language, and they are sufficiently segregated that the statements don't break referential transparency of expressions. Side effects (like assignment) are restricted to the statement language. Within the expression language, you cannot observe the order of side effects, so A + B will always be the same as B + A.
Curv does not have mutable objects, as seen in Python. In Python,
A = [1,2,3]
B = A
A[0] = 17
Now both A and B are set to [17,2,3], because lists are mutable objects. I think this is unintuitive and surprising the first time you encounter it, and it's a source of bugs. In Curv, values are immutable, and only local variables are mutable. Mutating one variable has no effect on other variables. So after executing the following statement list,
local A = [1,2,3];
local B = A;
A[0] := 17;
then A is set to [17,2,3] and B is set to [1,2,3]. Curv has much simpler semantics than Python.
tp3 wrote
Right, so something like BlocksCAD or similar tools?
Well, that's a special use case, more like a frontend
to the existing language. I guess the general comments
do not apply as much to that.
Yes, a front-end.
Until I read your Post I didn't even know BlocksCAD existed. Needless to say
my project does not have (and won't have) such a sexy GUI, but it works in
much the same way.
...R
--
Sent from: http://forum.openscad.org/
Robin2 wrote
I am working on a Python program that allows a user to select things (such
as Cube or Translate or Difference) by clicking a mouse and providing the
numbers (such as the dimensions of the cube). The Python program then
writes
the text for the necessary scad file and Openscad interprets it and
creates
the model. I don't have to do all the tedious Openscad typing when I want
to
create a design. The Python program is not complex and it knows nothing
about 3D design - it is just a text generator.
Robin, if typing is a concern, the new snapshot has autocomplete, you still
need to do the parameters etc, but you can type 'tr(' and it changes to
'translate(' along with a hint for the syntax.
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!
Sent from: http://forum.openscad.org/
MichaelAtOz wrote
Robin, if typing is a concern, the new snapshot has autocomplete, you
still
need to do the parameters etc, but you can type 'tr(' and it changes to
'translate(' along with a hint for the syntax.
Thanks Michael.
I've got to the stage where I am really looking for a completely different
style of working. My Geany text editor does a degree of autocomplete with
Python (and I think it can with Openscad).
But having seen the possibility of completely eliminating the typing of code
it is hard to be satisfied with autocomplete :)
I see a big conceptual difference between Openscad and (for example) Python.
Python is a general purpose language with no preconceived goal. Openscad has
a very specfic goal. It is a means to manipulate shapes for the purpose of
creating a 3D model. So it seems to me natural that there should be an
optional front end that allows the user to select and define the shapes
without writing code.
...R
--
Sent from: http://forum.openscad.org/
I see OpenSCAD as a live coding system for making 3D shapes. There are two aspects to this: how quick, efficient and productive is the system to use, and how powerful is it (what is the range of 3D shapes that you can generate).
Live coding is part of productivity. You make small changes to your code and then immediately view the resulting shape in the preview pane. The previewer is an important part of this experience: you can tweak a parameter by moving a slider, and interactively view the effects of the parameter change in the preview pane. The syntax also contributes to productivity: OpenSCAD programs have far less boilerplate, are more convenient to write, than equivalent programs written in general purpose languages. Look at the code you write in OpenJSCAD or SolidPython to see the contrast.
The other issue is expressive power. What shapes can you make. OpenSCAD has some built-in primitives, such as the CSG operations (union, intersection, difference) that are implemented internally using heavy duty data structures and algorithms. But there's also a lot missing. To a limited extent, it is possible to implement new operations, like splines and sweeps, by writing OpenSCAD code. There are libraries (created by experts) for doing this. Many people use these libraries. But it is a lot more difficult to write code involving data structures and algorithms in OpenSCAD than it is in even simple programming languages that are designed for beginners or non-experts. For example, Snap (a block-based visual language designed for kids) and Processing (designed for artists) have much more powerful programming facilities than OpenSCAD. I don't think it is necessary for OpenSCAD to be so weak, and this makes it difficult for experts to create libraries of interesting new primitives by writing OpenSCAD code.
Some people say: don't extend OpenSCAD, you can just use Python to generate OpenSCAD code. Fine, but that doesn't give me a convenient live coding environment for designing shapes, and that doesn't let experts design new geometric primitives and then share them over the internet so that other people can use them. The only way this suggestion helps is if you build an OpenSCAD-like live programming environment for building shapes using Python, and then build a community and library ecosystem around this tool.