Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!mordor!sri-spam!sri-unix!quintus!pds
From: pds@quintus.UUCP (Peter Schachte)
Newsgroups: comp.sys.amiga
Subject: Re: Feeping Creaturism
Message-ID: <688@sandino.quintus.UUCP>
Date: 24 Feb 88 22:30:07 GMT
References: <8802230741.AA29070@cory.Berkeley.EDU>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 43
Summary: I agree with your goals, but still think an IFF form would be better

In article <8802230741.AA29070@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
> >...I proposed a new IFF form for source code....  This would allow for ...
> > incremental compilation).
> 
> ...The IFF should be a separate file in RAM: (or some
> other temporary place) that can be refered to by the incremental compiler.
> 
> 	The advantages of doing that is that the source is compatible with
>  any text editor and transferable to any machine.  I like to keep my
>  source disks compact ...
> 
> 	In fact, forget about the IFF entirely... the incremental compiler
> would keep its own copy of the source in RAM:... or memory.
> 
> 				-Matt


I agree that it is desirable to keep the file small, and to make it easily
transferable to another machine, or a printer, or whatever.  But suppose
it were easy to move it into and out of IFF.  And further suppose that the
IFF file were maintained in a compressed form.  Knowing that the file is
source code makes it easy to do something like maintain it
pre-tokenized.  This would make the compile go (a little) faster, too.
And unless IFF added a lot of overhead, it should be pretty easy to
make the file SMALLER than the pure ascii file it stands for.

Adding memory of what has changed would be pretty easy, and pretty
small.  You could take the easy approach and just mark which procedures
have changed and which haven't.

Also, a smart program to put a source file into this IFF form could
check to see if there is an existing IFF file, and if so, do a quick
diff as it is updating the file, and at that point mark changed
procedures.  And an incremental compiler would wipe these "changed"
marks.  Then you could write a simple shell script to extract an ascii
file out of the IFF file, fire up DME, and then put it back into the
IFF file, marking the changes, when you're done editing.  Voila!  You
can still use DME unchanged.

Now all we need is an incremental compiler.
-- 
-Peter Schachte
pds@quintus.uucp
...!sun!quintus!pds