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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no 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: Hannes Haug Subject: Re: Q: unboxed values and polymorphism Date: 1996/06/17 Message-ID: #1/1 X-Deja-AN: 160613526 sender: haugha@chaq.informatik.uni-tuebingen.de references: organization: Uni Tuebingen newsgroups: comp.lang.ada Date: 1996-06-17T00:00:00+00:00 List-Id: Hi, >>>>> "TT" == Tucker Taft writes: TT> Rather than tagged records, which allow for "unbounded" TT> polymorphism, you might want to simply use a variant record. TT> By using an appropriate record representation clause, you TT> should be able to keep your list cells down to 2 words. You TT> might still find a use for unbounded polymorphism (i.e. tagged TT> records), when you point to larger objects which are not TT> simply composted of list cells. However, if you are TT> essentially implementing a variant of Lisp, then I doubt if TT> tagged records will do much for you. Tightly encoded variant TT> records seem more likely to be the answer. But will this give me unboxed integers and type information on the stack ? I'd try a private type that's actually an integer. I'd use half of this integers (-2**30 ... 2**30-1) for my fixnums. Values outside this range would be indices in arrays of bignums or list cells. So I'd have unboxed integers and type information on the stack. - hannes