Re: Q: unboxed values and polymorphism

[Hannes Haug <Hannes.Haug@Student.Uni-Tuebingen.de>]

>>>>> "Jon" == Jon S Anthony <jsa@organon.com> writes:
    
    Jon> In this case, you might get away with unchecked conversion.
    Jon> It will basically give you the same as you had in your C.
    Jon> The question, of course, is this safe?  If integers and
    Jon> access types are not "just 32 bit [or 64 bit] units" you will
    Jon> be in trouble.  This would be true even in the case where
    Jon> access values were "just addresses" and addresses did not
    Jon> have the same machine level representation as integers
    Jon> (basically n-bit "words")

But I can convert pointers to System.Storage_Elements.Integer_Address.
But this could be a modular integer type. :-( If Integer_Address is a
signed integer type I can just use this for my pointers and fixnums.

    [...]

    Jon> Yes, all of these are real issues and keep leading down
    Jon> various rat-holes.  The problem is that you really can't do a
    Jon> _nice_ job of what you want to do _in the language_.  It just
    Jon> doesn't have quite the support.  To get close, you will
    Jon> probably have to define your own storage pools and allocation
    Jon> and get this hooked into your GC.  But of course this means
    Jon> that at the _client_ level, some tagged types will likely be
    Jon> running around (for finalization of stack allocated stuff...)

    Jon> What I ended up doing was making the client level list "not
    Jon> just" carcdr cell.  The actual carcdr implementation was a
    Jon> hidden attribute which for all its cells always use my
    Jon> internal storage pool machinery.  The client level list type
    Jon> had enough brains to "do the right thing" at finalization
    Jon> (mostly for stack allocation reasons), had the overhead of a
    Jon> tagged type but removed this overhead from the carcdr cells
    Jon> and their allocation/deallocation (which used a scavenging GC
    Jon> algorithm)

    Jon> You'd probably have to extend this scenario some to
    Jon> accomodate the requirements of your fixnums.

You have certain controll over your pointers if you allocate the list cells
in a mmaped region. That's what I've done in C. So my pointers will never
be in the range of my fixnums. You can even make shure that this pointers
have a unique bit pattern. So I have real fixnums and real pointers. There
are no `explicit' tags. Most of the time I even don't have to do an exact
type check in my gc. That's only necessary while scanning the stack. When
I'm traversing a list the checks can be a little bit simpler and faster.
But I'm not shure if the whole thing is worth the trouble.

 - hannes