Newsgroups: comp.object,comp.lang.c++,comp.lang.ada,comp.lang.cobol,comp.lang.clos
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!pipex!harlqn.co.uk!harlequin.co.uk!jason
From: jason@harlequin.co.uk (Jason Trenouth)
Subject: Re: C+@ Litter
In-Reply-To: carroll@quadriga.cis.udel.edu's message of 19 May 1995 15:48:33 GMT
Message-ID: <JASON.95May24134348@wratting.harlqn.co.uk>
X-Attribution: Jason
Sender: usenet@harlequin.co.uk (Usenet Maintainer)
Organization: Harlequin Ltd, Barrington Hall, Cambridge UK
References: <dewar.797512974@gnat> <3mbmd5$s06@icebox.mfltd.co.uk>
	<3n8jdv$jer@watnews1.watson.ibm.com> <3n8rjd$90a@disunms.epfl.ch>
	<19950421T230840Z.enag@naggum.no>
	<rshapiro-1305951849430001@ipa.bbn.com>
	<GIROD.95May15105836@dshp01.trs.ntc.nokia.com>
	<rshapiro-1605952054040001@ipa.bbn.com>
	<1995May17.175411.9737@rcmcon.com> <3pg1om$kmg@News1.mcs.com>
	<CARROLL.95May19114833@quadriga.cis.udel.edu>
Date: Wed, 24 May 1995 12:43:48 GMT
Lines: 67
Xref: glinda.oz.cs.cmu.edu comp.object:31447 comp.lang.c++:129970 comp.lang.ada:30339 comp.lang.cobol:3495 comp.lang.clos:3016


In article <CARROLL.95May19114833@quadriga.cis.udel.edu> carroll@quadriga.cis.udel.edu (unknown) writes:

Mark> Not only are you wrong about C++, but you're blazingly wrong in
Mark> general. Incremental compilation is possible for *all* static
Mark> languages, C++ included.
Mark> 
Mark> There is absolutely *nothing* about C++, or any static language
Mark> in general, that prohibits incremental compilation. There isn't
Mark> even anything about C++ that makes incremental compilation
Mark> especially *difficult*. (Templates are a nuiscance to compile,
Mark> but they're no worse in an incremental setting than they are in
Mark> general. In fact, incremental compilation of the system *might*
Mark> even make them easier, because you have the full system
Mark> available.)
Mark> 
Mark> Incremental compilation is, at its core, a compilation
Mark> technology that does the following:
Mark> 
Mark> - divide a program into very small, seperately compilable,
Mark> compilation units.
Mark> 
Mark> - establish a dependency relationship between the compilation
Mark> units, where unit A being dependent on unit B means that unit A
Mark> must be recompiled in response to a change in unit B.

In general you don't need to do the previous step with dynamic
languages.

Mark> - seperately compile units
Mark> 
Mark> - determine which units need recompilation in response to a
Mark> source change

Ditto.

Mark> - link seperately compiled units into an executable on demand.

You also omitted discussion of maintaining execution state. You need
to be able to link into an _executing_ executable.

Mark> None of this is impossible in C++. You can subdivide a C++
Mark> program into small compilation units in a variety of ways. Each
Mark> function can be compiled seperately, or each scope unit, or each
Mark> basic block. Compilation dependencies are statically computable.
Mark> Minimum necessary recompilations can't be computed perfectly,
Mark> but then it's impossible to do it perfectly in general, and a
Mark> respectable conservative estimate isn't difficult.

I think that the point that Jim was trying to make was that dynamic
languages make incremental compilation much easier than static
languages.

In general, they pay the cost of an indirection so that, for example,
when you incrementally redefine a function you don't have to recompile
all the call sites.

Dynamic languages also let you redefine a function in an executing
program so that you don't have to start afresh in order to test its
effects.

__Jason
--
| Jason Trenouth       	       	       	 | WWW:   http://www.harlequin.com  |
| Harlequin Ltd,                         | EMAIL: jason@harlequin.co.uk     |
| Barrington Hall,                       | TEL:   +44 (0)1223 872522        |
| Barrington, Cambridge CB2 5RG, UK      | FAX:   +44 (0)1223 872519        |
