[<<][meta][>>][..]
Tue Dec 6 21:59:56 EST 2011
Next: fix Sys.hs
It seems that with a little work this could be quite nice to have. As
long as this existential type gets filled in properly
data Sys p m i o =
forall s. () -- FIXME: Add interface to existential type
=> Sys ((s, i) -> m (s, o)) s
it should be little more than generalization and stub fill in of this:
compileLoop update init =
_letrec
(\loop -> _lambda (\s -> do
i <- undefined -- FIXME: read input
(s', o) <- update (s, i)
-- FIXME: write output
-- FIXME: terminate condition
_app loop s))
(\loop -> _app loop init)
I was intuiting about this and I wonder why such a tree can't just be
exposed as a thing over which you can map. The current Struct
interface seems unnecessarily clumsy, especially with that r as ras
stuff.
It seems that translation between representation of structuring and
structuring of representations is only needed for _app and _lambda.
When we stay in the domain of structuring of representations (which I
think is where Sys actually lives), these operations are not
necessary.
So sys doesn't need to support pack/unpack, just structSize,
structVariables, structCompile. Maybe it's best to separate those out
anyway?
[Reply][About]
[<<][meta][>>][..]