Future of ImplicitCAD
Christopher Olah
ImplicitCAD has been around for a bit over a year now. We've made a
ton of progress. Huge progress has been made on performance. There are
all sorts of cool new features. We have a lovely website
(www.implicitcad.org) to teach people about ImplicitCAD. We have use
in the wild for serious projects
(https://github.com/nathan7/nateplate/). And there are other
contributors! It's been very exciting to watch ImplicitCAD grow.
I wanted to use this thread as an opportunity to brain storm about the
future of ImplicitCAD. If there's a crazy idea bouncing around in your
head or something that is irking you, please mention it.
================
**Parametric Functions / Polygon / Triangle Mesh**: Better support for
polygons and support for triangle meshes. These have the added benefit
of making it easy to inject parametric function approximations, which
are the natural way to describe many things (eg. gears). If we added
resolution as an argument to get_implicit, we could emulate support
for parametric functions described objects by always sampling much
lower than the resolution of rendering.
**Import Format Support**: In particular, a DXF and SVG importer would
be really nice.
**Geometric Constraints**: In a programmatic CAD tool these would
essentially be logic programming. You'd describe a geometric situation
and get back values solving it, to save you the trouble of calculating
them yourself. It would also be less bug prone. Unfortunately, open
source implementations seem to be limited and not in C (which we could
FFI to). If we want this, we will probably have to write our own in C
or Haskell.
**Integrating module calls and expressions in extopenscad**: The
motivating example here is `rotate_extrude(shape = square(10, 20))
{...}` which we have the math implemented for, but lack a way to
describe in extopenscad.
**Extopenscad interfaces**: Objects can describe positions to attach
things at. Possibly using normal vectors to do alignment and snapping.
**GPU acceleration (for raytracing?)**: The GPU acceleration part is
probably self explanatory, but it would be a great way to speed things
up, since everything is ludicrously parallel. In particular, if we
could get real time raytracing, it would make a very compelling
interface for native use.
**Google Native Client?**: Google Native Client is a way to run
programs natively for web applications. It seems likely LLVM will
support it at some point in the future, which would be really
interesting for us...
**Other Languages?** Presently, you can only really design ImplicitCAD
objects in Haskell and extopenscad. But there are interpreters for
lots of other languages written in Haskell --
http://www.haskell.org/haskellwiki/Applications_and_libraries/Compilers_and_interpreters.
I wonder how many we could inject the ImplicitCAD API into the
execution environment with? ImplicitCAD objects being possible to
design in Python/Ruby/Javascript/Perl/etc would be really cool.
Especially if we could still import between them.
**CLI Variable Setting**: "<nathan7> Passing variables to extopenscad.
like I can do extopenscad -Dbuild=production and stuff" -- Sounds like
a great idea to me!
**Optional Dependencies**: As we require more and more elaborate
dependencies, ImplicitCAD becomes harder to build. Thoughts on ways we
could make features/dependencies optional without increasing
maintenance work are appreciated.
**Packaging / Binaries**: I think it is important for us to provide
packages / compiled binaries to help with adoption. I'm working on a
Fedora package. Anyone interested in taking on a platform?
=====
So, what else? The website is also fair game.
Chris
Sebastien Zany
--
Christopher Olah
Also, LaTeX support.
Chris
Reinoud Zandijk
i've seen some Haskell examples you made for ImplicitCAD
like
out = union [ | rectR 0 (-40,-40) (40,40), |
| translate (40,40) (circle 30) ] |
Ben Gamari
> OK, from me here,
>
> i've seen some Haskell examples you made for ImplicitCAD like
>
> out = union [
>
> rectR 0 (-40,-40) (40,40),
>
> translate (40,40) (circle 30) ]
>
> could we extract some form of alternate file format from this? say with
> limited haskell syntax like (thinking out loud here, don't keep me to it! :)
>
much of the time. No matter how much work you put into a dedicated DSL,
you'll never beat a full programming language. Personally I'm not
convinced that it's worth the effort to develop OpenSCAD into a
fully-fledged language. That being said, I of course can't complain if
someone else takes on this task.
Cheers,
- Ben
Christopher Olah
> much of the time. No matter how much work you put into a dedicated DSL,
> you'll never beat a full programming language. Personally I'm not
> convinced that it's worth the effort to develop OpenSCAD into a
> fully-fledged language. That being said, I of course can't complain if
> someone else takes on this task.
added because people were terrified of Haskell and there is a ton of
existing OpenSCAD code.
The Haskell API is kind of crude, but I certainly think it could be a
very nice way to design objects. And if we make it easy to integrate
Haskell/extopenscad code, perhaps some people will switch to Haskell.
Frameworks are known to drive adoption.
But I think extopenscad is essential for us to get initial adoption.
Reinound, you've done a great job capturing some of the ways designing
an object in Haskell could be very elegant. But why use a Haskell
inspired markup language and not just Haskell? The motivation between
extopenscad is the existing OpenSCAD users, what would the motivation
behind this be?
Chris
Sebastien Zany
"But I think extopenscad is essential for us to get initial adoption."
Sent from my iPhone
>
>
Ben Gamari
On Dec 10, 2012 11:34 PM, "Christopher Olah" <christoph...@gmail.com> wrote:
>
> Originally, ImplicitCAD was just a Haskell library. ExtOpenScad was
> added because people were terrified of Haskell and there is a ton of
> existing OpenSCAD code.
>
Sure, and I think this was the right thing to do both from the standpoint of adoption and practicality: even for someone with a working knowledge of Haskell it is infinitesimally easier to start a design with OpenSCAD syntax than it is with the Haskell interface.
> The Haskell API is kind of crude, but I certainly think it could be a
> very nice way to design objects. And if we make it easy to integrate
> Haskell/extopenscad code, perhaps some people will switch to Haskell.
> Frameworks are known to drive adoption.
>
> But I think extopenscad is essential for us to get initial adoption.
>
Definitely. I think as long as we can provide support for a proper superset of the openscad syntax we've done what is necessary. Any further features exposed through the OpenSCAD frontend are gravy.
Beyond my work on mirror support what other features remain outstanding towards full OpenSCAD support?
Cheers,
- Ben
Matthew Sorensen
Minkowski sum - all of the literature I looked at indicates this is non-trivial to express implicitly.
--
Gordon Wrigley
--
Reinoud Zandijk
On Tuesday, December 11, 2012 5:34:36 AM UTC+1, Christopher Olah wrote:
Originally, ImplicitCAD was just a Haskell library. ExtOpenScad was
added because people were terrified of Haskell and there is a ton of
existing OpenSCAD code.
True, though i don't know if i would call it `a ton of code', its there for sure as thingiverse alone reports 4314 things.
But I think extopenscad is essential for us to get initial adoption.
Reinoud, you've done a great job capturing some of the ways designing
an object in Haskell could be very elegant. But why use a Haskell
inspired markup language and not just Haskell? The motivation between
extopenscad is the existing OpenSCAD users, what would the motivation
behind this be?
The motivation behind this proposed interface Haskell inspired language is to isolate the specification from the implementation without dictating a language. It will also permit to use variables and/or constructors that may or might become part of the Haskell language.
The big problem in this whole idea is as expected: where to draw a line? what to allow in this language without making its implementation a PITA? only strict math insprired Haskell like features? like assignments, generators, multiple case logic and function definition and such? But then in what form? Haskell allows some things to be written down in more than one way. And what form would be acceptable and not confusing/conflicting with most functional languages? Would such a language be easier to learn and integrate than raw Haskell that is far too feature rich?
As for extra properties in my example it may be better to specify say
---
arm = union [cube ..., ....];
leg = union [....];
vol1 = volume [material ABS, density "1-x+y/2", color RGB (0.1, 0.2, 0.3)] arm;
vol2 = volume [material PLA, density 1, color ... ] leg;
out = [vol1, vol2];
---
? and thus won't allow volumes to be unioned with a cube later on due to the type?
In short, what i'd like to see it being able to specify enough for the full support of the See the wikipedia page (http://en.wikipedia.org/wiki/Additive_Manufacturing_File_Format) on it, also known as STL2.
Any ideas?
With regards,
Reinoud
cfh...@gmail.com
1. I am uncomfortable with the fact that all IC outputs, 2D and 3D, seem to be limited-resolution "renders". Other tools later in the chain could sometimes benefit from machine-precision geometry information. For this purpose I envision adding a "point" data type whose position is computed according to the geometric model and is output directly without a rendering approximation step.
2. I would like to see identifiers which can be attached to geometric features. They need not have semantic content; as a bare minimum UUIDs would suffice if other tools in the toolchain are doing the interpretation. For example, I might want to label a hole diameter with a tolerance, an object with a material type, or a feature with a label or note. The most obvious applications don't require us to think hard about composition rules: the hole remains distinct in the rendering, its annotation "ream to 0.375 +/- 0.0002 inch dia" remains attached to the surface or path rendered, and all is fine. However I do think it is useful to consider rules for composing identifiers, to support user-defined composition rules based on identifier classes, and to provide some default rules for common use, e.g. if a 2D output path contains elements generated from three underlying objects with distinct identifiers, the path could bear all, none, or a single priority-based identifier in each class.
My 2c
Chuck
Gordon Wrigley
--
cfh...@gmail.com
> How would your point data type represent curved surfaces?
>
I think you misunderstand my intent. There is nothing wrong with the existing ImplicitCAD mechanisms for representing 3-manifolds (solids), 2-manifolds (surfaces), or 1-manifolds (curves). What is missing is a representation for 0-manifolds.
Perhaps a concrete example is in order. Remember, I want to make concrete objects with real-world fabrication processes. Suppose I want to make something with a number of round holes -- perhaps a circuit board or even an engine block. The best way to make these holes is with a drill, and a drilling machine needs (x,y) positioning coordinates.
At present I can define the holes in a circuit board, for example with the extopenSCAD "circle" primitive, and I can render an svg file which makes a pretty picture of the board. The picture is a useful and necessary artifact, but it does not directly give me the (x,y) coordinates for the drilling machine. I would have to post-process the svg file, identify the circles (actually the approximating polygons), estimate their center coordinates, and produce my CNC drill file from that. I would prefer to have a more direct route from "part program" (in extopenSCAD) to CAM file (x,y drill coordinates in g-code).
Bottom line, we have a "sphere" primitive. We have a "circle" primitive. Let's have a "point" primitive, too.
While I have been focusing first on the simplest manufacturing processes (e.g. drilling holes), it is probably useful to consider that even the most sophisticated manufacturing processes rarely use *surface* representations directly. When "the rubber meets the road", it is almost always a 2-manifold ("tool path" in 3-space, or in higher dimensions for 4- or 5-axis machine tools) that cuts the metal or adds the plastic.
Cheers,
Chuck
cfh...@gmail.com
On Sunday, December 16, 2012 9:30:09 AM UTC-8, cfh...@gmail.com wrote:
> On Sunday, December 16, 2012 4:08:05 AM UTC-8, Gordon Wrigley wrote:
> > How would your point data type represent curved surfaces?
> >
>
> I think you misunderstand my intent. There is nothing wrong with the existing ImplicitCAD mechanisms for representing 3-manifolds (solids), 2-manifolds (surfaces), or 1-manifolds (curves). What is missing is a representation for 0-manifolds.
>
[...]
> While I have been focusing first on the simplest manufacturing processes (e.g. drilling holes), it is probably useful to consider that even the most sophisticated manufacturing processes rarely use *surface* representations directly. When "the rubber meets the road", it is almost always a 2-manifold ("tool path" in 3-space, or in higher dimensions for 4- or 5-axis machine tools) that cuts the metal or adds the plastic.
Woopsie! That tool path curve would be a 1-manifold, of course, not a 2-manifold!
C
Christopher Olah
ImplicitCAD, without extopenscad, at NYC Maker Faire. The reaction
ranged from unenthusiastic to negative; several people, unprompted,
told me I needed to interpret OpenSCAD.
It has been observed that frameworks often drive adoption of
languages. Perhaps ImplicitCAD can help with Haskell. But low barrier
to entry and backwards compatibility are an important starting point.
The more interesting conversation, I think, is crafting an
exceptionally nice Haskell API. I'll raise this in another thread.
> Beyond my work on mirror support what other features remain outstanding towards full OpenSCAD support?
>> 1. I am uncomfortable with the fact that all IC outputs, 2D and 3D, seem to be limited-resolution "renders".
a format where we don't do this, certain ImplicitCAD objects can be
compiled into OpenSCAD ones and, for exmple, circles will come through
as precise circles.
>> Other tools later in the chain could sometimes benefit from machine-precision geometry information.
aware of any other formats being able to describe precisely.
This is why we are interested in also handling gcode generation -- it
really isn't possible to pass on all the information we have about the
object.
>> For this purpose I envision adding a "point" data type whose position is computed according to the geometric model and is output directly without a rendering approximation step.
necessary. It would be trivial to extract circles being cut away and
handle them specially.
>> 2. I would like to see identifiers which can be attached to geometric features.
work on for a while. Meta data for materials, colors, feature labels
for diagrams, and so forth are things we really need to add. (I'll
start a thread about revamping SymbolicObj{2,3}.)
An example of a particularly challenging type of object to support
would be metal folding, where we may need to attach information about
tapping to holes, and also lines to fold on.
Chris
cfh...@gmail.com
> CH>> 1. I am uncomfortable with the fact that all IC outputs, 2D and 3D, seem to be limited-resolution "renders".
>
> This is an issue of output formats, not ImplicitCAD. As an example of
> a format where we don't do this, certain ImplicitCAD objects can be
> compiled into OpenSCAD ones and, for exmple, circles will come through
> as precise circles.
As an element of a toolchain, it is very helpful if the output is in a format that is already used in the field. It may be sad, but autocad dxf is probably the most widely readable format for 2D/3D point/line/arc geometry. I would recommend putting more emphasis on this than on gcode (see below).
> CH>> Other tools later in the chain could sometimes benefit from machine-precision geometry information.
>
> The problem is that ImplicitCAD allows describing objects that I'm not
> aware of any other formats being able to describe precisely.
>
> This is why we are interested in also handling gcode generation -- it
> really isn't possible to pass on all the information we have about the
> object.
This sounds good in the abstract, but I would caution against investing a large effort here at this time. G-code generation is about modeling a manufacturing process, above and beyond modeling an object. You need expertise in the intended manufacturing process to write a good CAM postprocessor. This subject gets very deep, and we will need a lot more Haskell programmers involved before we are touching commercial-strength applications like http://www.mastercam.com . In the mean time, let's prioritize the task of getting the *part geometry* information out of ImplicitCAD accurately, over the task of turning ImplicitCAD into ImplicitCAD/CAM.
> CH>> For this purpose I envision adding a "point" data type whose position is computed according to the geometric model and is output directly without a rendering approximation step.
>
> CH>> Perhaps a concrete example is in order. Remember, I want to make concrete objects with real-world fabrication processes. Suppose I want to make something with a number of round holes -- perhaps a circuit board or even an engine block. The best way to make these holes is with a drill, and a drilling machine needs (x,y) positioning coordinates.
>
> At least in this case, I don't think any sort of point input format is
> necessary. It would be trivial to extract circles being cut away and
> handle them specially.
I'm surprised you prefer the special-case "hack" over a general solution, but I'm a pragmatist; I'll take whatever method gives me the data I need to make accurate parts!
> >> 2. I would like to see identifiers which can be attached to geometric features.
>
> This is an extremely good point, and something I've been meaning to
> work on for a while. Meta data for materials, colors, feature labels
> for diagrams, and so forth are things we really need to add. (I'll
> start a thread about revamping SymbolicObj{2,3}.)
>
http://amf.wikispaces.com/ metadata may be a good starting point.
> An example of a particularly challenging type of object to support
> would be metal folding, where we may need to attach information about
> tapping to holes, and also lines to fold on.
+1 on sheet metal folding, I could use it right away!! (I'm in a laser-cutter/plasma table world these days, can you tell? ;) ) This seems like a natural ("bend 45 degrees around axis A" analogous to "extrude 50mm along axis A"). There may be some difficult corner cases but for most situations this may not be all that hard to implement.
>
>
>
> Chris
Nils McCarthy
On Saturday, December 8, 2012 3:29:03 PM UTC-8, Christopher Olah wrote:
**Parametric Functions / Polygon / Triangle Mesh**: Better support for
polygons and support for triangle meshes. These have the added benefit
of making it easy to inject parametric function approximations, which
are the natural way to describe many things (eg. gears). If we added
resolution as an argument to get_implicit, we could emulate support
for parametric functions described objects by always sampling much
lower than the resolution of rendering.
Allowing for non-algebraic structures would also allow computation of things that aren't easy to calculate implicitly, like minkowski sums. If minkowski(a,b) is requested, and both a and b are already defined by meshes, it could use an existing minkowski polyhedron algorithm to produce an exact sum. If not, it could generate a mesh approximation at the requested resolution.
**Import Format Support**: In particular, a DXF and SVG importer would
be really nice.
STL import would be useful too.
**Geometric Constraints**: In a programmatic CAD tool these would
+1, but this seems like a longer term goal
So, what else? The website is also fair game.
Here's my wish list:
* Faster STL export: I have a not-very-involved model that I'm trying to export to STL with reasonable resolution (I'm targeting 3d printing), and it's taking a really long time and runs out of memory. I have some ideas on some optimizations that could be done:
** Optimize the generated expression for speedier evaluation. Maybe some common subexpression elimination? Perhaps use some symbolic algebra package to do some simplifications? This might require getImplicit to be structured a bit differently, but I think it could be a big win to, say, not multiply a whole bunch of things by sin(0) or cos(90) and add them together for every single point when doing a rotation transformation. Also, pulling out matrices and premultiplying them together when doing something like translate(...) rotate(...) translate(...) union { ... } might help also.
** Faster meshing algorithm. I thought I remember reading something about a faster O(surface area) algorithm for generating meshes than the O(volume) algorithm that it looks like it's using now. What happened to that?
* Voxel output. I'm not sure if there's a popular standard format for voxel data yet, but I have a friend who works at a 3d printing shop says they're planning to start accepting voxel data files sometime within the next year. This sounds like the ideal geometrization for 3d printing; it gives detail more efficiently than a polyhedron, but is not nearly as equipment specific as gcode.
* More versatile metadata facitlity for describing objects. It seems like there's a lot of additional information about structures that we might like to include. Here are some ideas:
** Material
** Color
** Transparency (even if we're not targetting to become a full-featured raytracer, it would still be useful for debugging purposes to be able to emulate e.g. the "%" operator in openscad)
** Whether the object is better defined by a mesh or implicitly
** Maybe the bounding box could use this metadata facility too? I don't know if that makes sense or not.
That's all I have for now. :)
-nils
willia...@gmail.com
• Geometric Constraints: This would be fantastic, though I'm under the impression that it would be a lot of work.
• GPU Acceleration: I'm very interested in using OpenCL/GL, particularly because one may be able to efficiently render implicit objects without converting to / approximating with polygonal geometry.
• Haskell API: This is my main use, and I think Haskell is an ideal platform for CAD. I'm not dissatisfied by the current API at all, but I look forward to improvements.
• Metadata: This is crucial to so many applications. Since it's not all that difficult to add, it should probably be at the top of my list (if my list was actually in some kind of order).
• Complete Set of Modeling Operations: I miss some common operations such as fillet/chamfer, loft/sweep, revolve, etc. It would be nice to have those.
• Symbolic Simplification: This is more of an optimization, but it would be interesting to use symbolic algebra to simplify implicit objects.
• Simulation/FEA: Physical simulation (gears, joints, bearings, etc.) would be really cool, let alone some of the more advanced finite element analysis stuff. Most other software out there is either really simplistic, cumbersome/buggy, or insanely complex. I think programmatic objects would make for a great medium.
• File Import: This was the first thing I noticed was missing when I was checking ImplicitCAD out. It didn't put me off, but it will some people.
Whew, that's all I've got for now!
'Till next time,
Will
Will Knop
Christopher Olah
hard to support some sort of simple modelling for waves, diffusion,
etc. And this would be a really neat feature.
For creating engineering diagrams, does anyone have a good reference
for what they should look like?
Chris
Matthew Sorensen
>Simulation/FEA
>PDEs simulation
>Gcode
Will Knop
>Material properties metadata
>Simulation/FEA
>PDEs simulation>Voxel output.
>Gcode>metal folding, engineering diagrams, gcode, etcWhile all of this would be awesome, sane software engineering/generally practicality predicts that if we try to support everything we'll get distracted, write a lot of half-assed implementations of sweet features, while not making much progress on improving ImplicitCAD's core. This seems especially true given that all of these tasks are non-trivial and ImplictCAD's core focus is also non-trivially difficult. Perhaps this suggests that building a nice API that exposes enough of the internals to implement such features is the way to go.
Reinoud Zandijk
On Thu, Dec 20, 2012 at 12:34:11AM -0800, Matthew Sorensen wrote:
> I'm also interested in AMF support - so much so that I have a working
> implementation (https://github.com/matthewSorensen/ImplicitCAD/tree/amf)
> and an accompanying library (https://github.com/matthewSorensen/blaze-amf).
> I even own a real copy of the AMF standard! However, it just
> exports triangles and meshes at the moment, as ImplictCAD has no other
> metadata to think about.
it allways specifies vertex normals regardless if they exist or not. 2) It
doesn't specify the edge tangents where needed...
My solution would be to calculate all three edge tangents for each triangle
and then if all the edge tangents for a point indicate a vertex normal use
that normal and if the two edge tangents over an edge are flat, remove the
edge tangents too.
It might not trivial to do that in ImplicitCAD since it uses global operations
on the end result of the triangulations though (memory wise).
With regards,
Reinoud
Gordon Wrigley
Here's another:• Blending Operations: It seems like ImplicitCAD has some blending functionality already, but this paper generalizes and expounds on the idea.
--
Reinoud Zandijk
(thinking aloud here)
On Thu, Dec 20, 2012 at 07:30:27AM +0000, Gordon Wrigley wrote:
> If geometric constraints means what I think it does then that's the feature
> whose absence hurts me the most in openscad. Bolting parts together to form
> whole machines and in turn controlling the shape of those parts so they fit
> their space in the machine. These things are manual, tedious and hard in
> openscad.
is a heavy 3d CAD user (Catia V, SolidWorks) and this is one of his main
objections against using it. He said it might be good for parts creation but
it sucked on assembly since that all has to be done manually.
There are some `tricks' to do assembly in OpenSCAD but it mostly comes down to
having one static object and bolting the others to it by coordinate
calculation, not ideal.
Looking at other specification languages solutions like BRLcad and PLaSM, i
notice that their hardly if any got support for assembly. The BRLcad webpage
has the most compresensive tutorial on it and somewhat adresses it. They
suggest, logically, to keep assembly in mind when designing objects by having
a good origin and orientation for reuse, duh!
What could help is an named attachment primitive, either of both of a surface
for plane specification and an attachment point for positioning. Having a
surface to attach to reduces the attachment to only have 3 degrees of freedom
(place+rotation), having a point too reduces it to 1 degree of freedom
(rotation). This final freedom then needs to be fixed using a 2nd mounting
point.
Self adjusting objects that change on their placement just mean that some
objects need modification after placement by allowing them to be say drilled
out by a connecting rod. Or do you envision say only specifying an attachment
point without orientation and let the orientation be determined by the
solution of the placement?
Programs like SolidWorks have 2d constraint solving where you can use the
resulting values/lengths/angles etc. to build your 3d object. Later on, when
assembling 3d objects one can say specify the drill-holes in a sheet by
linking it to the bolt placements in another.
Lots of parameter passing can be linked if we allow 1) angle and position
query 2) refer to placement/rotation by refering to named values calculated
when assembling and most importantly: good design with construction is mind :)
Thoughts?
Reinoud
Gordon Wrigley
Reinoud
--
Reinoud Zandijk
> FYI There is some interesting work around doing this sort of stuff in scad
> libraries, like this:
> http://www.iearobotics.com/blog/2012/09/10/enhancing-openscad-with-the-attach-library/
Ok, now we need to implement that attach module together with the vector
module either so that it works in ImplicitCAD or as a build-in :)
Ideas?
Cheers,
Reinoud
Will Knop
Ben Gamari
convinced that a monadic interface necessary or desireable
here. Especially if we are going to discuss doing transformations to
other computational frameworks (e.g. OpenCL), I think the power of a
monadic interface is strongly undesireable. If I'm not mistaken, all we
want to do here is build a static object graph.
Cheers,
- Ben
Will Knop
Will Knop
Chuck Harrison
On Monday, December 10, 2012 8:34:36 PM UTC-8, Christopher Olah wrote:
> Frankly, I envision myself simply using implicitcad as a Haskell library
> much of the time. No matter how much work you put into a dedicated DSL,
> you'll never beat a full programming language. Personally I'm not
> convinced that it's worth the effort to develop OpenSCAD into a
> fully-fledged language. That being said, I of course can't complain if
> someone else takes on this task.
Originally, ImplicitCAD was just a Haskell library. ExtOpenScad was
added because people were terrified of Haskell and there is a ton of
existing OpenSCAD code.
The Haskell API is kind of crude, but I certainly think it could be a
very nice way to design objects. And if we make it easy to integrate
Haskell/extopenscad code, perhaps some people will switch to Haskell.
Frameworks are known to drive adoption.
But I think extopenscad is essential for us to get initial adoption.
Reinound, you've done a great job capturing some of the ways designing
an object in Haskell could be very elegant. But why use a Haskell
inspired markup language and not just Haskell? The motivation between
extopenscad is the existing OpenSCAD users, what would the motivation
behind this be?
Chris