{"id":832,"date":"2024-12-18T11:07:55","date_gmt":"2024-12-18T11:07:55","guid":{"rendered":"https:\/\/blog.67bricks.com\/?p=832"},"modified":"2024-12-18T11:07:55","modified_gmt":"2024-12-18T11:07:55","slug":"wishing-upon-a-star","status":"publish","type":"post","link":"https:\/\/blog.67bricks.com\/?p=832","title":{"rendered":"Wishing upon a star"},"content":{"rendered":"\n

When I was a boy, many years ago…<\/h2>\n\n\n\n

…I used to like building polyhedron models out of card. Here is a photo of me, probably around 1987ish, spray-painting a compound of ten tetrahedra<\/a>. Evidently the photographer had partially obscured the aperture with their finger, but there were no digital cameras back in those days, you only found out your mistakes when you had the picture developed!<\/p>\n\n\n\n

\"The
The artist at work<\/figcaption><\/figure><\/div>\n\n\n\n

Making a model out of card was a long and laborious process. First, armed with a protractor and ruler, one had to draw the net<\/a> on card, making sure there were tabs in the right place to glue the thing together. Then it had to be cut out, and the intended folds scored very carefully with a craft knife (you need them to fold cleanly, but if you cut through the card you’ll have to start again). Finally, it had to be glued together to give it three-dimensional form, a process which got increasingly fiddly as access to the interior became harder.<\/p>\n\n\n\n\n\n\n\n

This being the season of goodwill and all that…<\/h2>\n\n\n\n

…I thought I’d make a Christmas star decoration out of card. My plan was to make what was essentially an icosahedron<\/a> but with pointy triangular pyramids on each face (a bit like a stellated icosahedron). I figured that I could save time on the net construction by creating them in SVG and laser-printing them onto card. I scribbled onto a convenient piece of paper my plan for the net:<\/p>\n\n\n\n

\"Pencil
One fifth of the net for the star<\/figcaption><\/figure><\/div>\n\n\n\n

One of those, I figured, would fold to make a chain of four pyramids, and five such chains could be joined together to make the final shape. The big question was – how pointy should I make the pyramids? Too pointy, and they’d be really tricky to glue together. Not pointy enough and the star would look a bit rubbish. Also, I needed to make each net as big as possible while still being printable onto an A4-sized piece of card. I could obviously prototype this by drawing something in Inkscape<\/a>, but I didn’t fancy the faff of having to edit it and make sure all of the angles came out right. So, naturally, I started to wonder how I could write something to generate the SVG for me, allowing me to tweak angles and regenerate at will (it didn’t have to solve the problem completely; I could always scale and rotate in Inkscape to make best use of the card).<\/p>\n\n\n\n

Cometh the hour…<\/h2>\n\n\n\n

…cometh the libraries. Two of them, in fact. To handle the geometry, I remembered that years and years ago I’d written a silly math library in Java<\/a>, and happily I’d written something similar in Scala<\/a> (neither of these is to be taken seriously as a proper library – do not use them!). That handles points, vectors, lines and so on. But then I wanted a way to describe the net in terms of “this is how you make a triangle with a base angle of x degrees, so draw one, rotate a bit, draw another one, now do another of these shapes but flipped…” and so on.<\/p>\n\n\n\n

Basically, this would be something a bit like Logo<\/a>, where there’s a notional “turtle” that exists on the plane somewhere, and can be told to go forward, or turn through some angle, with a pen that’s either down or up so it may or may not draw a line when it moves. So at any moment, there’s some “state” in the system (the set of lines drawn so far on the canvas, the location and orientation of the turtle) and I want to be able to issue commands that update the state or rather, since this is Scala, we want the state to be immutable and commands will return an updated copy of it.<\/p>\n\n\n\n

So a first stab (in pseudocode) at something to draw an isoceles triangle with a particular base length and opposite angle might look something like this:<\/p>\n\n\n\n

def triangle(currentState: State, baseLength: Double, oppositeAngle: Rad): (State, Point) {\n  val equalAngle: Rad = (Rad.PI - oppositeAngle) \/ 2.0\n  val equalSide = baseLength \/ (2 * Math.cos(equalAngle))\n  val currentlyFacing = getCurrentDirectionFromState(currentState) \/\/ because we'll want to use this later\n  val (stateAfterDrawingBaseLine, endPointOfBaseLine) = drawLineAndMove(currentState, baseLength)\n  val stateAfterRotatingTheFirstTime = rotateBy(getCurrentDirectionFromState, Rad.PI - equalAngle)\n  val stateAfterDrawingTheFirstEqualSide = drawLineAndMove(stateAfterRotatingTheFirstTime, equalSide)\n  \/\/ ... you get the idea\n} yield endOfBase\n\n<\/code><\/pre>\n\n\n\n
There are at least three problems with this approach:<\/p>\n\n\n\n
  1. We keep having to return an updated state, which needs to be passed on to the next instruction for it to operate on, which means we have to get creative with variable names. I could have used state1<\/code>, state2<\/code>, state3<\/code> and so on, but it’s still a bit ugly, and easy to use the wrong state somewhere leading to mysterious bugs.<\/li>
  2. Sometimes we want to return something additional to the new state (e.g. the end point of the line we’ve just drawn). We can either invent a bunch of case classes for this, or return a Tuple(State, something else)<\/code>, but the lack of uniformity of return types seems a bit inelegant.<\/li>
  3. We’re not handling errors anywhere.<\/li><\/ol>\n\n\n\n
    We can do something about “3” easily, at least – if we define methods to return Try[(State, other, things)]<\/code> then we can use a for-comprehension and potentially deal with errors using the usual .recover<\/code>, .recoverWith<\/code> combinators. But the first two issues still rankle.<\/p>\n\n\n\n
    The second library…<\/h2>\n\n\n\n
    …and the subject of this blogpost after an extended scene-setting introduction, is a library for sequencing computations (internal to 67 Bricks, I’m afraid, so no link!) which I wrote a few years inspired by exercises in the book Functional Programming in Scala<\/a> (looking around my office, I can’t see it anywhere, which makes me wonder if I lent it to someone).<\/p>\n\n\n\n
    Let us cut to the chase, and see what the triangle<\/code> method looks like, and then try to understand it.<\/p>\n\n\n\n
    def triangle(baseLength: Double,\n             oppositeAngle: Rad): Computation[Canvas, Point, DrawFailure] = {\n  val equalAngle: Rad = (Rad.PI - oppositeAngle) \/ 2.0\n  val equalSide = baseLength \/ (2 * Math.cos(equalAngle))\n  for {\n    facing <- getFacing\n    endOfBase <- drawLineAndMove(baseLength)\n    _ <- rotateBy(Rad.PI - equalAngle)\n    _ <- drawLineAndMove(equalSide)\n    _ <- rotateBy(Rad.PI - oppositeAngle)\n    _ <- drawLineAndMove(equalSide)\n    _ <- moveTo(endOfBase)\n    _ <- rotateTo(facing)\n  } yield endOfBase\n}\n<\/code><\/pre>\n\n\n\n
    So, it is a for-comprehension, and it’s all quite easy to follow, but where on earth has the state gone? There’s no state being passed into the method, and we appear to be ignoring the return values from many of the methods (assigning to _<\/code>). And what is that Computation[Canvas, Point, DrawFailure]<\/code>?<\/p>\n\n\n\n
    Computations, and their outcomes<\/h2>\n\n\n\n
    The computation library has a trait Computation[S, +A, +F]<\/code>, and a sealed trait ComputationResult[S, +A, +F]<\/code> defined as follows:<\/p>\n\n\n\n
    trait Computation[S, +A, +F] {\n\n  def run: S => ComputationResult[S, A, F]\n\n  def map[B](fn: A => B): Computation[S, B, F] = ... \/\/ details omitted\n\n  def flatMap[B, G :> F](fn: A => Computation[S, B, G]): Computation[S, B, G} = ...\n\n}\n\nobject Computation {\n\n  private class ComputationImpl[S, +A, +F](override val run: S => ComputationResult[S, A, F]) extends Computation[S, A, F]\n\n  \/\/ Constructor for Computations, transforming a suitable function into a Computation\n  def apply[S, A, F](run: S => ComputationResult[S, A, F]): Computation[S, A, F] = new ComputationImpl(run)\n\n}\n\nsealed trait ComputationResult[S, +A, +F]\n\ncase class Ongoing[S, +A, +F](state: S, result: A) extends ComputationResult[S, A, F]\n\ncase class Failed[S, +A, +F](error: F) extends ComputationResult[S, A, F]\n<\/code><\/pre>\n\n\n\n
    A Computation[S, A, F]<\/code> is basically a function, which takes some kind of “state” (represented by the type S<\/code>), and must return a ComputationResult<\/code> of which there is a choice of two; either an Ongoing<\/code> encapsulating an updated state S<\/code> and possibly some kind of observable result of type A<\/code>, or a Failed<\/code> which holds an error of type F<\/code>. In the triangle<\/code> example above, we have the following:<\/p>\n\n\n\n