Re: Q: unboxed values and polymorphism

[jsa@organon.com (Jon S Anthony)]

In article <uvv7mt7ubgd.fsf@chaq.informatik.uni-tuebingen.de> Hannes Haug <Hannes.Haug@Student.Uni-Tuebingen.de> writes:

> >>>>> "Jon" == Jon S Anthony <jsa@organon.com> writes:
> 
>     Jon> In article <uvvyblp84l7.fsf@chaq.informatik.uni-tuebingen.de>
>     Jon> Hannes Haug <Hannes.Haug@Student.Uni-Tuebingen.de> writes:
>     >> I'm new to Ada and have a questions on polymorphism. The
>     >> standard way to have polymorphism in Ada are tagged
>     >> records. But for my needs
> 
>     Jon> If it helps, it also works this way in C++, Eiffel, Sather,
>     Jon> and any other "statically" typed OO language.
> 
>     >> this requires too much space.
> 
>     Jon> Then you are in trouble no matter what.
> 
> But the trouble is not that big.

OK, I had two strikes against me, this one looks like I managed a
"foul ball".


>     >> require too much time and space. I'd like to convert access
>     >> values to integers and do my own tagging. I could simply
>     >> translate my C code.
> 
>     Jon> This sounds like a _really_ _really_ bad idea.  In your C,
>     Jon> are you using "meta" bits (ala' Lisp impls) or what?
> 
> Sort of. Fixnums are integers in the range -2^30 ... 2^30-1. Other
> integers are interpreted as pointers to (or indices in arrays of)
> bignums or list cells. And it is not a bad idea.

Aha.  Yes, this is not so bad an idea.  I thought you meant "tagging"
in the Ada sense of "tagged types" and you were going to do your own
"subclassing" and dispatching stuff, but thought just maybe you had
the "meta bit" stuff in mind.  Well, I'm not completely dead yet.

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


>     Jon> I'm not sure what it is you are trying to do.  Make a list?
>     Jon> Make a generic list?  Make a typed polymorphic list?  Make an
>     Jon> untyped uncheckd programmer beware list?  What?
> 
> I need it for my computer algebra nucleus. I need lisp-like dynamic
> typing. I cannot use tagged records. This would make a list cell 50%
> bigger. This would mean 33% less list cells. And this would mean 50%

Yes, I've been here before.  This is not an easy nut to crack in
order to have something really satisfactory.  I did not use tagged
types for the cells either.


> more garbage collections. I also need the type information on the stack
> for my garbage collector. I cannot use records for fixnums either. This
> would mean a "new" for every operation. My nagation takes ca. 20 nsec
> for fixnums on a 90MHz hyperSPARC. With a "new" this would be a not so
> little bit slower. Perhaps the usage of records for fixnums would even
> make some functions too big for inlining.

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

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

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


Well, I'm not sure if I managed to get out of this or not!  Strike
three?

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com