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: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public From: piercarl@sabi.demon.co.uk (Piercarlo Grandi) Subject: Re: What is wrong with OO ? Date: 1997/01/14 Message-ID: #1/1 X-Deja-AN: 209797719 x-nntp-posting-host: sabi.demon.co.uk x-disclaimer: Contents reflect my personal views only references: <5acjtn$5uj@news3.digex.net> <32D11FD3.41C6@wi.leidenuniv.nl> <5b56u0$fsc@news.eng.octel.com> <32D84C44.1C72@mpce.mq.edu.au> content-type: text/plain; charset=US-ASCII organization: Home's where my rucksack's mime-version: 1.0 (generated by tm-edit 7.94) newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng Date: 1997-01-14T00:00:00+00:00 List-Id: >>> "martin" == Martin ELLISON writes: martin> Why can't the compiler optimise the whole program? (Assuming martin> that it is all written in the same language). Who says that you martin> have to compile and generate code for each module and then link martin> them together? Doing so may be quicker for a development martin> version, but surely a production compile can be optimised across martin> the whole system. This is more or less what Ole Agesen has done for type inference in Self for the production of shrink wrapped applications... The problem with type inference and OO is that OO modules are supposedly designed to be as resuable as possible, that is as generic as possible. Thus type inference returns wide sets of types for constraints; consider for example a stack class: you can infer that all variables in it will have a type constraint like 'Object', that is anything. Unfortunately such tyep inference is next to useless, for type ifnerence results in significant safety advantages when type constraints are narrower, and in optimization when type constrains are narrowest, that is about a single type. Since supposedly an OO program is composed mostly of reusable modules, which are written to be as generic as possible, the situation seems hopeless. What Oleg Agesen has done for Self is a kind of type-based ``tree shaker''; it is base don the idea that if one infers type on reusable modules *in the context of each application in which they are reused* then type inference can become significantly stronger (the price of course one payus to take advantage of it is then code duplication). So for example a matrix package which is otherwise totally generic can in the context of a numerical application to be about matrixes of floats, and in the context of a graphics application to be about matrixes of integers/pixels. What then happens is that the whole source of the application is examined at the same time, and the type constraints of the application, which are usually quite specific, are propagates across call sites back to the generic reuable modules that i t references, and these are specialized for those type constraints. The specialized modules are then optimized mercilessly as a whole. This technique naturally has some severe limitations; in practice it is only useful to develop shrink wrapped, standalone applications, for it involves a stark tradeoff between code replication and slowness. Very vaguely similar techniques are used in recent versions of some ``C++'' implementations where template instantion/inlining is in effect done by the linker in a somewhat clumsy iterative way; or the programmer does inference by hand listing which templates instances are neded, like in ``Ada''. I may be wrong, but the Sather compiler does much the same automatic process (less clumsily) of global inference and instantiation; in this is is significantly helped by the rather regrettable limitation which still exists AFAIK that Sather does not allow separate compilation, so all modules are merged as _sources_, and (possibly slow) compilation then on the full source (application plus reusable modules).