[<<][meta][>>][..]
Thu Dec 29 08:38:03 EST 2011

SArray and inference

I wonder if it isn't simpler to solve the problem:

   (L (a t1)), L (a t2))   <->   a (L t1, L t2)

which is a more direct description of the isomorphism that is the core
of this problem, instead of trying to fuse this type constructor
commutation with _get / _set as is currently done in SArray.

What does this operation look like in lowlevel code?  Problem there is
that it doesn't exist: it's entirely virtual.

So what's the real problem with current factoring?  There is some
ambiguity left:

    No instances for (SArray
                        (StateCont.SC Code.CompState Term) Code sa0 (L Tfloat),
                      SArray (StateCont.SC Code.CompState Term) Code sa1 (L Tfloat),
                      Struct Term Code as0 (Code sa0),
                      Struct Term Code bs0 (Code sa1))
      arising from a use of `compile3'
    Possible fix:
      add instance declarations for
      (SArray (StateCont.SC Code.CompState Term) Code sa0 (L Tfloat),
       SArray (StateCont.SC Code.CompState Term) Code sa1 (L Tfloat),
       Struct Term Code as0 (Code sa0),
       Struct Term Code bs0 (Code sa1))

Need to think about this...  I'm missing something simple.  The fact
that this isomorphism isn't expressed directly somehow bothers me..

More concretely, what is it that actually happens?  A single _get' /
_set' is replaced with a _get / _set for each array member of the
struct.

Why is this so hard?

Should something be said about properties of t?  It is known that both
sa ant t are part of struct instances.  With the former a struct of
array of type and the latter a struct of type.


  class TML m r => SArray m r sa t where
    _get' :: r sa -> r Tint -> m (r t)
    _set' :: r sa -> r Tint -> r t -> m (r ())


Giving up.  Guess: Something isn't factored properly such that
information that's necessary for inference is lost, but I can't put my
finger on it..




[Reply][About]
[<<][meta][>>][..]