[Haskell-cafe] Figuring out if an algebraic type is enumerated
through Data.Generics?
Alfonso Acosta
alfonso.acosta at gmail.com
Tue May 6 12:34:36 EDT 2008
Hi all,
<probably_unnnecesary_background>
I'm writing a Hardware-oriented DSL deep-embedded in Haskell (similar
to Lava, for those familiar with it).
One of the goals of the language is to support polymorphic signals
(i.e. we would like to allow signals to carry values of any type,
including user-defined types)
The embedded compiler has different backends: simulation, VHDL,
graphical representation in GraphML ...
The simulation backend manages to support polymorphic signals by
forcing them to be Typeable. In that way, circuit functions, no matter
what signals they process, can be transformed to Dynamic and included
in the AST for later simulation.
The situation is more complicated for the VHDL backend. The Typeable
trick works just fine for translating a limited set of predefined
types (e.g. tuples) but not for user-defined types, since the
embedded-compiler doesn't have access to the user-defined type
declarations.
One possible solution to access the type-definition of signal values
would be constraining them to instances of Data. Then, we could use
dataTypeOf to get access to the type representation. (Another option
would be using template Haskell's reify, but I would like to avoid
that by now)
It would certainly be difficult map any Haskell type to VHDL, so, by
now we would be content to map enumerate algebraic types (i.e.
algebraic types whose all data constructors have arity zero, e.g.
data Colors = Green | Blue | Red)
</probably_unnnecesary_background>
So, the question is. Is there a way to figure out the arity of data
constructors using Data.Generics ?
I'm totally new to generics, but (tell me if I'm wrong) it seems that
Constr doesn't hold any information about the data-constructor
arguments. Why is it so?
Do you think there is a workoaround for this problem? (maybe using
some other function from Data.Generics different to dataTypeOf?)
Thanks in advance,
Alfonso Acosta
More information about the Haskell-Cafe
mailing list