Storing non-storable types about feldspar-language

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