1. output-translations is for output-files, not for input-files—except of course that input-files often will in turn call output-files on a previous operation that it depends on.
2. as to output-files, it is the outermost method that applies the output translations—when the second value is NIL; the translations are assumed to already have been applied or subsumed when the second value is T. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Foolishness is rarely a matter of lack of intelligence or even lack of information. — John McCarthy On Fri, Jan 24, 2020 at 3:56 PM Robert Goldman <rpgold...@sift.info> wrote: > > I'm looking at the documentation for INPUT-FILES and OUTPUT-FILES and I see > this: > > (defgeneric output-files (operation component) > (:documentation "Methods for this function return two values: a list of > output files > corresponding to this action, and a boolean indicating if they have already > been subjected > to relevant output translations and should not be further translated. > > Methods on PERFORM *must* call this function to determine where their outputs > are to be located. > They may rely on the order of the files to discriminate between outputs. > ")) > (defgeneric input-files (operation component) > (:documentation "A list of input files corresponding to this action. > > Methods on PERFORM *must* call this function to determine where their inputs > are located. > They may rely on the order of the files to discriminate between inputs. > ")) > > Missing in the above is an explanation of how to tell INPUT-FILES whether to > apply output translations or not. > > Is this left to the author of the relevant PERFORM method? Or is there > something one should do when writing a PERFORM method or an operator > definition?