Storing non-storable types

[emilaxelsson]

It is currently possible to e.g. make an array of references, but this doesn't do the right thing when generating code. The array will contain the values of the references, not the references themselves.

Example:

import qualified Prelude

import Feldspar
import Feldspar.Mutable
import Feldspar.Compiler
import Feldspar.SimpleVector

test x = runMutable $ do
    r1 <- newRef 1
    r2 <- newRef 2
    let arr :: Vector (Ref (Data Int32))
        arr = save $ indexed x $ \i -> (i<1) ? r1 $ r2
    setRef (arr ! 0) 33
    getRef $ arr ! 0

Generated code:

void test(uint32_t v0, int32_t * out)
{
  int32_t v1;
  int32_t v2;
  int32_t v7;
  struct array * e8 = NULL;

  v1 = 1;
  v2 = 2;
  e8 = initArray(e8, sizeof(int32_t), v0);
  for (uint32_t v3 = 0; v3 < v0; v3 += 1)
  {
    if ((v3 < 1))
    {
      at(int32_t,e8,v3) = v1;
    }
    else
    {
      at(int32_t,e8,v3) = v2;
    }
  }
  v7 = at(int32_t,e8,0);
  v7 = 33;
  *out = v7;
  freeArray(e8);
}

The assignment v7 = 33 doesn't update the original reference v1.

Possible solutions:

1. Exclude Ref (and maybe other types) from Type
   • Alternatively, make a sub-class of Type that excludes Ref (and maybe other types), and use that to constrain functions like parallel
2. Fix the problem in the back end. In the above case, this would mean making an array of addresses. However, this seems like begging for problems (e.g. on a NUMA architecture where addresses are context-dependent).

[emilaxelsson]

Just realized that a much simpler test case would be a Ref (Ref a), which should exhibit the same problem.

[emilaxelsson]

Maybe the second solution is not so bad after all. We already have arrays which are in some sense generalizations of references.

[josefs]

For the sake of argument, what would be the difference between the new sub-class and Type? What intuition should I use to know which one of them to use in a particular piece of code?

[pjonsson]

This is a bug that should be fixed in the code generator somewhere; I assume it relates to Program somehow.

How urgent/important is this for you? I don't think it's a minor local fix.

[emilaxelsson]

For the sake of argument, what would be the difference between the new sub-class and Type? What intuition should I use to know which one of them to use in a particular piece of code?

I'm not sure actually. The simplest thing would be to just exclude Ref from Type. But I don't know if that maybe rules out too much (I don't remeber exactly what Type is used for), so I thought a sub-class might be needed.

But it would of course be nice if this could be fixed in the back end. Arrays of references can be useful.

[emilaxelsson]

How urgent/important is this for you? I don't think it's a minor local fix.

Not urgent at all. I just started to think about this for a different reason.

[emilaxelsson]

I will move this issue to feldspar-compiler.