So now I think I can state the big problem with compact linear types
as implemented "by magic". Consider:

        fun f[A,B] (x:A * B) {
                var y: B * A;
                var pya : &A = &y.1;
                var pyb : &B = &y.0;
                pya <- x.0;
                pyb <- x.1;
                return y;
        }

Of course this is a very stupid implementation of a function to swap
the order of a pair of values around. But you would expect it to work!

Unfortunately it will work with A=int and B=string. But it will NOT work
with A=bool and B=bool because 

        A* B = bool * bool

is a compact linear type and the components of such a type are not
addressable. Of course there exist pointers to type bool, just not
when a bool is embedded in a compact linear value.

The actual problem here is that the projection:

        prj0: &(A*B) -> &A

is not universal. Of course a universal "locator" type can be encoded:
you need an ordinary pointer and a bit more info (a pair of integers
will do for a projection: one to divide by (shift right) and one to modulo
by (mask hit stuff out). But then we need 3 words for all pointers,
since the type of the pointer does not determine whether we need
the extra pair or integers or not (it depends on whether the type
is compact linear or not, and whether it is embedded in another
compact linear value as a subcomponent or not).

There is a proper solution to this introduce ANOTHER tuple
forming combinator:

        2 * 3 * 4 // PACKED TUPLE
        2 &* 3 &* 4 // UNPACKED TUPLE


Now, all components of an unpacked tuple are addressable.
For a packed tuple, they're not. Note a packed tuple is what
we have right now in Felix. 

Note that for non-compact linear types, packed and unpacked
tuples have the same representation. The difference is that
you can address the components of an unpacked tuple always.
With packed tuples you can only do it if you know the types
are not compact linear. In particular in a parametrically polymorphic
function a packed tuples components cannot be addressed.
[But you can still assign to them!!!!]

Not sure what to do here. But the current type system isn't sound,
so something has to be done :)

Note that it is a bit tricky to ban pointers to tuple components ..
because remember an array is just a tuple. Still FORTRAN
got away with arrays without pointers ...


--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org




------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language

Reply via email to