The cool thing is that it uses the same code as the reader and writer.In essence, you write one function, taking two arguments: tar(dstTarFile, srcFiles)

The cool thing is that it uses the same code as the reader and writer.In essence, you write one function, taking two arguments: tar(dstTarFile, srcFiles) Next you provide one of the two arguments and query Prolog to find the other: you pass in a tar file as the first argument, and it tells you what `srcFiles` would need to be to create that archive, effectively extracting it. Alternately, you pass in `srcFiles` and it tells you what the corresponding dstTarFile should be, creating an archive. Another way to think about it is that the Prolog code is not directly telling you how to read/write tar files. Instead, imagine it as a cost function that tells you how well this tar file corresponds to the uncompressed representation of those files, which you're minimizing. If you were to write it in C, the code would imperative: do this, then that, then this other thing. Consequently, the reader and writer code are totally different. For example, to process the file size, you would write functions two functions: char* uIntToOctalASCII(unsigned int sz)` and octalASCIIToUInt(char* szstr). Semantically, these are inverses[0]: octalASCIIToUInt(uIntToOctalASCII(x)) == x but the implementations have very little in common. At best, you can use one to test the other. [0] And leaks memory, but whatever....