Haskell API/EDSL

[Christopher Olah]

> The more interesting conversation, I think, is crafting an
exceptionally nice Haskell API.

Well, it is.

I see two big questions.

(1) To monad or not to monad.

Presently, we take a very first class approach to building ImplicitCAD
objects in Haskell. We work with objects and lists of objects. For
example:

union [
sphere 10,
cube 10
]

But we could move to a Writer-style monad approach.

union $ do
sphere 10
cube 10

There's advantages and disadvantages to both. The non-monadic approach
is a lot simpler, the monadic one means that we could return
information to help place later objects (eg. significant points to
attach things to). And if we ever get geometric constraints, it could
a monad transformer over a monad for them.

(2) Can we avoid argument soup?

In the extopenscad interface, it is fine or even pleasant for things
to have lots of optional arguments and to be polymorphic. This works
less well in Haskell. In Haskell, we typically prefer smaller
combinators...

Thoughts?

Chris

[Reinoud Zandijk]

Hi folks,

i would take another road and regretfully you haven't replied on it yet Chris,
but here i'll try to express myself more clearly.

First of all, you state yourself that ImplicitCAD is a mathematical inspired
SolidCAD program. Haskell is also a mathematical inspired language, so yes, it
would be logical to combine elements of both of them.

> Presently, we take a very first class approach to building ImplicitCAD
> objects in Haskell. We work with objects and lists of objects. For example:
>
> union [ sphere 10, cube 10 ]
>
> But we could move to a Writer-style monad approach.
>
> union $ do sphere 10 cube 10

As you state, there are advantages and disadvantages to both, therefore my
argument to create a new specification language inspired on math but tailored
to operations that are logical for the domain.

Does anyone know what are/were the considerations for OpenSCAD to not use a
subset of the PovRay language? At times it looks like its `pythonized' some
PovRay language and at other times it completely different.

> (2) Can we avoid argument soup?
>
> In the extopenscad interface, it is fine or even pleasant for things to have
> lots of optional arguments and to be polymorphic. This works less well in
> Haskell. In Haskell, we typically prefer smaller combinators...

I think we need to analyse orthogonal primitives like :

UnionR R obj = rounded R . union obj
vec3d x y z = (x,y,z)

in stead of having a UnionR etc; this saves heaps of argument soup since
internally this can be converted into primitives with complete arguments.

Thoughts?
Reinoud

[Christopher Olah]

> i would take another road and regretfully you haven't replied on it yet Chris,
> but here i'll try to express myself more clearly.

Sorry, there were a bunch of things in the other thread and this must
have slipped by.

>> (Direct vs Monad approach)

> As you state, there are advantages and disadvantages to both, therefore my
> argument to create a new specification language inspired on math but tailored
> to operations that are logical for the domain.

This isn't really an issue of language, though. It's an issue of
semantics. Any language we create will essentially do one of these two
approaches.

> Does anyone know what are/were the considerations for OpenSCAD to not use a
> subset of the PovRay language? At times it looks like its `pythonized' some
> PovRay language and at other times it completely different.

I don't. However, PovRay is optimized for rather different purposes
(describing detailed optical properties, textures, etc, of objects)
than OpenSCAD.

> in stead of having a UnionR etc; this saves heaps of argument soup since
> internally this can be converted into primitives with complete arguments.

Yep, rounded is one example of how we might break things into smaller
combinators.

Chris

[Reinoud Zandijk]

Hi Chris, hi folks,

On Tue, Dec 18, 2012 at 01:27:47PM -0500, Christopher Olah wrote:
> > i would take another road and regretfully you haven't replied on it yet Chris,
> > but here i'll try to express myself more clearly.
>
> Sorry, there were a bunch of things in the other thread and this must
> have slipped by.

Pity, it was a lot more elaborate :-/

> >> (Direct vs Monad approach)
> > As you state, there are advantages and disadvantages to both, therefore my
> > argument to create a new specification language inspired on math but tailored
> > to operations that are logical for the domain.
>
> This isn't really an issue of language, though. It's an issue of
> semantics. Any language we create will essentially do one of these two
> approaches.

To be honest i still don't get Monads that good :-S I'll try to read in on it.

> > Does anyone know what are/were the considerations for OpenSCAD to not use a
> > subset of the PovRay language? At times it looks like its `pythonized' some
> > PovRay language and at other times it completely different.
>
> I don't. However, PovRay is optimized for rather different purposes
> (describing detailed optical properties, textures, etc, of objects)
> than OpenSCAD.

If you look at the syntax and expression of PovRay its quite interesting too
since it has both CSG and implicit functionality including rounding unions
etc.

> > in stead of having a UnionR etc; this saves heaps of argument soup since
> > internally this can be converted into primitives with complete arguments.
>
> Yep, rounded is one example of how we might break things into smaller
> combinators.

If we express the underlaying datastructure as having slots for say colour or
material or other properties then a union of a coloured object is possible
too. Say express `colour (r,g,b) obj' as an operation on a tuple `obj'
creating something analog to (first(obj), Colour (rgb):second(obj)) and like
`union [..]' creating a tuple ([..], []).

Is this effectively what a Monad does? Thoughts?

Reinoud

[Will Knop]

(1) To monad or not to monad.

Presently, we take a very first class approach to building ImplicitCAD
objects in Haskell. We work with objects and lists of objects. For
example:

union [
   sphere 10,
   cube 10
]

But we could move to a Writer-style monad approach.

union $ do
   sphere 10
   cube 10

There's advantages and disadvantages to both. The non-monadic approach
is a lot simpler, the monadic one means that we could return
information to help place later objects (eg. significant points to
attach things to). And if we ever get geometric constraints, it could
a monad transformer over a monad for them.

I'm not a monad guru, but I certainly see them being useful in ImplicidCAD. However, remember that the purpose of a monad is to carry extra computation around with the pure calculation-- I'm under the impression that implicit objects and their transforms can be considered pure and thus using a writer-style approach is unnecessary or even harmful. Yet, monads would be great for export/rendering and who knows what else.

Will