MIME-Version: 1.0 (generated by SEMI MIME-Edit 0.92 - "Oyanagi")
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Message-ID:  <199710200612.CAA28440@aleph.swift.xxx>
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE>
In-Reply-To:  Your message of "Tue, 07 Oct 1997 20:22:32 BST." 
              <199710071922.UAA00483@frank.zdv.uni-mainz.de>
Date:         Mon, 20 Oct 1997 02:12:44 -0400
From: Matthew Swift <swift@ALUM.MIT.EDU>
Sender: Mailing list for the LaTeX3 project
              <LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE>
To: Multiple recipients of list LATEX-L
              <LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE>
Subject:      Re: Extended include
Status: R

>>>>> "F" == Frank Mittelbach <Frank.Mittelbach@UNI-MAINZ.DE> writes:

    F> in fact for some prototype kernel (long time ago) i implemented
    F> a scheme that always used two aux files: one to read from and
    F> one to write to. the advantage was that a) less files and b)
    F> much better control in error situations, ie in case your run
    F> ended in the middle LaTeX would not use the file that was only
    F> partly written but the one that was fully written last time.

Frank, would you describe the basic flowchart of this idea?  I would
like to implement it in my experimental include system.

If your two aux filenames are A and B, during the first run you read
From A and write to B.  Presuming no errors, during your next run
however you need to read from B and write to A.  How do you keep
track?  I'm sure I could arrive at a solution, but if you did this
before and had it working, you maybe solved some other problems I
would have to re-solve.