[<<][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][>>][..]