Path: utzoo!mnetor!uunet!husc6!mit-eddie!bbn!uwmcsd1!ig!agate!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: Feeping Creaturism
Message-ID: <8802230741.AA29070@cory.Berkeley.EDU>
Date: 23 Feb 88 07:41:51 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 32


>down in comp.lang.lisp.)  That is why I proposed a new IFF form for
>source code.  This would allow for separate tools from different
>suppliers to behave in useful ways as if they were integrated (e.g.,
>incremental compilation).
>-- 
>-Peter Schachte
>pds@quintus.uucp
>....!sun!quintus!pds

	Sounds like the proper approach, but how about a slightly different
approach to the IFF... Specifically, the 'changes since last compile' 
should be a strictly temporary item, and thus would not be contained in
the actual source file.  The IFF should be a separate file in RAM: (or some
other temporary place) that can be refered to by the incremental compiler.
A crash simply means the compiler must recompile everything... no biggie.

	The advantages of doing that is that the source is simply standard
ascii... compatible with any text editor and transferable to any machine
(and readable on that machine).  I like to keep my source disks clean and
compact ... and virtually 100% full, and I don't want a lot of extranious
information in all those 'text' files when I'm not working on them.

	In fact, forget about the IFF entirely... the incremental compiler
would keep its own copy of the source in RAM:... or memory.  When you tell it 
to compile, it simply figures out what changed between the master and its 
personal copy and recompiles just those parts.  The comparisons required
are essentially a diff, which takes virtually no time.  Only those files
that were modified are actually diff'd (you can figure it out simply by
looking at the time stamps).

				-Matt