Mon Apr 22 07:58:21 EDT 2019
Start by creating a new kind of binding: a loop.
A loop has two main parts:
- Output array
- Output accumulator
To simplify, these are always there, and there is just one of them for
now. Extend to multiple arrays or accumulators once the basic
structure is ready.
So it is clear now where Term needs to be extended.
The question now is where to add the concept of collection. Should
"node" be extended to mean a combination of accumulators and arrays?
Maybe the first change to make is the ability to have multiple outputs
from a primitive, because loops will likely have multiple outputs.
It seems safest to extend Term into something that can express this
structure. Maybe TermLoop.hs?
It might be possible to extend Term.hs in-place, but I worry about
breaking things, so let's just decouple it for now and create an
Or, just go for it. I believe the only necessary change is in
Note that node type is abstract in Term.hs. Let's first find out the
concrete type of C.compile
compile :: Show n => String -> CompileResult n -> String
So it doesn't care about the node type.
Let's add another constraint on n that embeds the looping.
class Loop n
instance Loop NodeNum
compile :: (Loop n, Show n) => String -> CompileResult n -> String
This class then could expose the required nesting.
( This is the first time I think about using type classes to express
folds to extend data types. Is this the right way to go? This is
always possible, I just never realized it was an option.. )
So current approach is to just stick to Term, and extend it
recursively using a type class.