Open snowleopard opened 8 years ago
This is a good point, and it would be useful for us to describe signals as input
, output
or internal
. For FSMs this doesn't make too much of a difference, but for STGs to be useful with tools such as petrify
it could do with these distinctions.
This could also be useful with #19 as this is somewhat holding us back with memory concepts. If it possible to define some internal signals for resolving CSC conflicts, for example, and define this, then it can be included when producing an STG, or even a logic implementation.
We have a meeting later this week, in which we can discuss this. But we can meet earlier if possible and discuss this alone, as it is an important point somewhat holding back the development of this concepts tool.
It's also holding me back for the dotG (STG) generation, so I was going to take a stab at this since I can't do anything else in concepts right now. I would say this is very specific to concepts and could get lengthy, so perhaps it's a good candidate for a quick meeting before Thursday. I'm free whenever. I'll let @snowleopard decide, since he's the busiest.
At the moment concepts are represented by a concrete datatype:
This is later used to define circuit concepts:
Although this works relatively well now, it is not very flexible. In particular, expressions that combine concepts together cannot be interpreted in different contexts. Consider the following example:
Given
data Signal = X | Y | Z
, we can only interpretcElement X Y Z
as an expression of typeCircuitConcept Signal
, which is basically a state graph represented by a collection of Boolean functions.This is not the only interpretation of interest. In particular, we might want to interpret
cElement X Y Z
as a compact description of an STG, which could be stored in a.g
file for processing by standard tools likepetrify
orworkcraft
.This brings up the following problem: how do we redesign concepts in such a way that
cElement
and other expressions become polymorphic and the following two interpretations become possible:The first one should be equivalent to the current interpretation, but the second one should produce an STG datatype instead. The implementation of both of these functions could in fact be as simple as
id
. Actual work will be done behind the scenes by magic Haskell type inference.