Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!spool.mu.edu!agate!ucbvax!DMAFHT1.BITNET!X903 From: X903@DMAFHT1.BITNET (Marc Wachowitz) Newsgroups: comp.lang.modula2 Subject: RE: Make the language Perfect/SOS Message-ID: Date: 28 Jun 91 08:58:50 GMT Article-I.D.: UCF1VM.INFO-M2%91062803250032 References: Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: Modula2 List Organization: The Internet Lines: 30 On Thu, 27 Jun 91 15:07:00 -0300 said: > >=> Sorry, but I think this argument is rather nonsensical. When talking >=> about overhead (i.e. complexity or runtime cost), "compiler" is any- >=> thing you have to run to obtain the object file (or whatever you have >=> instead) from your source. It doesn't matter if this is separated into >=> several programs, or if one of them is called preprocessor. > >A preprocessor NEVER adds runtime overhead. It is a COMPILEtime overhead. Of course :-) I'm talking of the runtime of the translation process. Sorry that I haven't made that clear enough the first time. ... >I don't think that's true because the proposed scheme *IS* used in Prolog with >success. I know that it is done in Prolog. Note that I never tried to say it were impossible to implement or anything like that. What constitutes a success here is not proven by giving an existing implementation; one cannot derive what is desired from what exists (though one should take current practice into account). This would be as saying in ethics that it's quite okay to kill other people, since it is not so uncommon - I guess you would hardly follow this kind of argumentation. If one views something as desirable depends largely on personal taste and experience (not more vs. less but the particular kind of experience one has). Btw, prolog has - in my personal and limited view, of course - major problems exactly in this area: large projects with hundreds of modules written by many people over a long period of time and designed to be reusable for different problems. Marc Wachowitz X903@DMAFHT1.BITNET