From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8de933d44255f226 X-Google-Attributes: gid103376,public From: jsa@organon.com (Jon S Anthony) Subject: Re: Q: unboxed values and polymorphism Date: 1996/06/18 Message-ID: X-Deja-AN: 160866099 sender: news@organon.com (news) references: organization: Organon Motives, Inc. newsgroups: comp.lang.ada Date: 1996-06-18T00:00:00+00:00 List-Id: In article Hannes Haug writes: > >>>>> "Jon" == Jon S Anthony writes: > > Jon> In article > Jon> Hannes Haug 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