Implement translation from concepts to FSMs.

[jrbeaumont]

Add functionality for a concept specification to FSM translation.

There is a .sg representation which works with tools and Workcraft. This can be used as the intermediary, as with the STG translation.

[jrbeaumont]

@snowleopard: I have done some refactoring and adding in the FSM translation today.

I have hit upon a problem with trying to keep the FSM and STG libraries separate.

When translating, a lot of work can be done on a concept specification of any type (FSM/STG) without needing to separate these, but then a problem arises in that a CircuitConcept is produced, and this is then passed into the relevant translation algorithm. The problem with this however is that both Tuura.Concept.STG and Tuura.Concept.FSM have a CircuitConcept type, which currently are exactly the same, but each translation algorithm needs the specific CircuitConcept, either STG or FSM.

It may be necessary after all to have a unified concept library. From these, an STG specific library can then inherit from these and build on top of them.

What do you think?

[snowleopard]

I think we should have common code for CircuitConcept and then essentially two functions:

• toSTG :: CircuitConcept -> STG, or if STG datatype is too difficult to define, just a simpler writer function writeSTG :: CircuitConcept -> String
• toFSM :: CircuitConcept -> FSM, or writeFSM :: CircuitConcept -> String

Can we have this?

[jrbeaumont]

I may have found a way for separate libraries, I'll keep going with this for now, and we can review it then.

I think in the long run, your ideas may be more valid, but we can work on this from my current in progress implementation.