Closed jrbeaumont closed 7 years ago
@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?
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?
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.
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.