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,99ab4bb580fc34cd X-Google-Attributes: gid103376,public From: fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) Subject: Re: Q: access to subprogram Date: 1996/07/26 Message-ID: <4tb4ii$5fc@mulga.cs.mu.OZ.AU>#1/1 X-Deja-AN: 170583368 references: <4rb9dp$qe6@news1.delphi.com> <4t4siv$bh2@goanna.cs.rmit.edu.au> <4t7dvt$cbo@mulga.cs.mu.OZ.AU> organization: Comp Sci, University of Melbourne newsgroups: comp.lang.ada Date: 1996-07-26T00:00:00+00:00 List-Id: bobduff@world.std.com (Robert A Duff) writes: >If you *always* represent access-to-subprogram values with extra data >telling where the generic instance data is, then it can work, but that's >distributed overhead for the case where you didn't use generics. > >Make sense? After much thought -- nope, I'm still confused ;-) Mercury's shared-generics implementation doesn't have any distributed overhead when compared to "Mercury minus generics". I don't think it has any distributed overhead when compared to Pascal either (i.e. I think Pascal could be extended with Mercury-style generics without imposing any distributed overhead.) But there is distributed overhead compared to C, if you're not willing to adopt the GNU C trampoline approach or something along those lines. I'm still confused about whether there is distributed overhead compared to Ada. You can't represent higher-order types (Mercury's equivalent to access-to-subprogram types) using a single code address, you need a data address as well -- presuming you don't use trampolines. But I thought Ada already imposed that requirement, since you can take the address of nested procedures in Ada? (can't you?) The way the Mercury implementation handles taking the address of a generic instance in a shared generic is to package up the generic instance data in basically the same way that the stack frame data in an enclosing procedure is packed up when you take the address of a nested procedure. So as long as you are already committed to being able to take the address of nested procedures, there is no distributed overhead -- I think. -- Fergus Henderson | "I have always known that the pursuit WWW: | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.