It doesn’t compile for me — did it compile in 2008?

Yes. We had this general, useful, consistent notation and lost it for the convenience of using “+” and “*” for type-level natural numbers.

    newtype StreamArrow (~>) b c = Str (Stream b ~> Stream c)

It doesn’t compile for me — did it compile in 2008?

I bet a lovely repackaging of your work would be as a reinterpretation of Haskell programs via Compiling to categories.

An excellent reference is Sphere Tracing by John C. Hart: https://github.com/curv3d/curv/blob/master/docs/papers/sphere_tracing.pdf

Here’s a paper I wrote on the math behind Curv’s shape representation. It says some things that Hart does not, which are relevant to Curv: https://github.com/curv3d/curv/blob/master/docs/Theory.rst

My library of shape combinators is documented here: https://github.com/curv3d/curv/tree/master/docs/shapes

This doc explains that a shape has a distance field, and it classifies distance fields as exact, mitred, approximate, bad and discontinuous. You need to know this because shape combinators are sensitive to the class of distance field they receive as input, and they may return a worse class of distance than what they received as input. https://github.com/curv3d/curv/blob/master/docs/shapes/Shapes.rst

The documentation for each shape combinator describes its limitations with respect to the classes of distance field that it accepts as input and produces as output.

Other people have addressed this problem (of users needing to worry about distance field properties) by restricting expressiveness, limiting the set of shapes and shape combinators you can define or use. All of the related projects listed below restrict expressiveness and thereby make the abstraction less leaky.

Related projects:

ImplicitCAD is written in Haskell, and uses the same signed distance representation. No GPU compilation, and there is a fixed set of distance field operations hard coded into the library, which you have to hack to define new primitives. It’s not extensible like Curv is. No colour or animation. https://github.com/colah/ImplicitCAD

libfive uses Scheme as its extension language. It has some restrictions relative to Curv: distance functions must be closed form expressions (no conditionals, no recursion), so many Curv primitives cannot be ported. But, there is no Lipshitz continuity restriction on distance functions, so this restriction removes a burden from users. Shapes are converted to a triangle mesh before being displayed, so no fine detail, no infinite shapes. Also no colour or animation. The author, Matt Keeter, has a paper in this year’s SigGraph on compiling his closed-form distance functions to GPU shader code without using sphere tracing. This is a new algorithm: the paper and the source code are not yet available at time of writing.

The video game “Dreams” on Playstation by Media Molecule uses signed distance fields to represent all geometric shapes in the game. You can create your own content using an editor, by unioning, differencing and blending a small fixed set of geometric primitives. The set of geometric primitives and shape operators is sharply limited to make everything well behaved. The GPU implementation is quite interesting and impressive; I’m studying it with an eye to duplicating their best tricks in Curv some day. https://www.mediamolecule.com/blog/article/siggraph_2015

Since you seem to still update this paper occasionally, here’s a typo I noticed: In the end of section 5.2 on page 5, in the equation [[fmap f m]] = fmap f [[m]], I’m pretty sure fmap f [[m]] should be the composition fmap f ◦ [[m]] – so the expression can type check and be consistent with the following line.

As someone who has plumbed the depths of bigint optimization across multiple ISAs for elliptic curve cryptography, yes, it is indeed very awkward.

But in the context of your analysis, wouldn’t decoupling arithmetic from machine word size–entirely–be the purest ADT?