HasSize, IsPointer, HasGC typeclasses. about sixten HOT 9 CLOSED

Hey Josef!

I didn't word that very clearly. What I meant was that the Pair a b is passed in registers or on the stack when used in a function. Sizes are only passed to polymorphic functions. When dealing with known types the compiler uses that information to generate better code and doesn't pass around sizes.

It seems to me that this scheme gets the same benefit as one based on typeclasses would, but I'd be interested to hear your elaborated thoughts on the matter if you still think it's a good idea. :)

I've updated the README to hopefully be clearer.

from sixten.

from sixten.

The types (sizes) are used and passed around like any other values, so if you pass them as implicit arguments (using the forall construct, which I think will be the most common for types) then you already have beta and eta.

To clarify, in the type forall a b. (a -> b) -> List a -> List b, the forall a b part stands for two implicit arguments of type Type. Types are compiled to type representations (i.e. sizes), so at runtime, a and b are type representations being implicitly passed.

from sixten.

Then type representation and type classes are identical. Or I would be very surprised if they were not. If you find any such case be sure to notify me ( I am talking about efficiency / functionality difference, not syntactic one ).

On a different note. I have heard you have problems with using the same code for both boxed and unboxed data (polymorphism over memory location). Why don't you just add the boxiness information into type representation as you did with size?

from sixten.

Where did you hear that? Polymorphism works fine over both boxed and unboxed data.

from sixten.

I mean how do you know whether those 8 bytes you pass to increment : Int64 -> Int64 represent an actual stack allocated Int64 or pointer to boxed one stored on heap instead?

from sixten.

increment isn't polymorphic so we know statically that its argument is not boxed (note that everything is unboxed unless it has a Ptr around it), so it's not a good example to use for this question, but let's ask the same question for:

id : forall a. a -> a
id x = x

Now, since id doesn't statically know the size of its argument it'll be passed on the stack (as opposed to in a register), i.e. as a pointer to a stack location. Since id doesn't statically know the size of its return value, it'll be returned by out param, i.e. at runtime id takes an extra argument consisting of a pointer to where it should write its return value.

It doesn't matter if id's argument is an Int or a Ptr Int or a Vector 10 Int or a Ptr (Vector 10 Int), it still works the same way: it copies the size of the input type (a which (on a 64-bit system) is 8 for Int, 8 for Ptr Int, 80 for Vector 10 Int, and 8 for Ptr (Vector 10 Int)) number of bytes from the argument pointer to the out param pointer, i.e. it's a memcpy. If it's passed a Ptr Int, that means that the pointer will be passed on the stack, and the pointer is copied to the out param pointer. Note that it doesn't care what the pointer points to, just what the value of the pointer itself is.

from sixten.

This is somewhat beside the point, but I forgot to mention an optimisation that the compiler implements which makes what I said above not quite true about certain functions. id is an example of a function whose return value is derived from the input only. What I mean by that is that the return value is guaranteed to already be on the caller's stack frame (and not created on id's stack frame), and that it's thus safe to just return that stack pointer directly. So the optimised form of id is not memcpy, but to return the stack pointer it was given. Another example of such a function is the list head function.

Polymorphic functions that don't fall into this category work like what I described above, however.

from sixten.

Considering this solved now.

from sixten.