On 8/22/16 Aug 22 -5:16 PM, Faré wrote: > On Mon, Aug 22, 2016 at 5:48 PM, Robert Goldman <rpgold...@sift.net> wrote: >> I am translating some existing code that does something like the following: >> >> concatenate f1 and f2 > temp file 1 >> concatenate f2 and f1 (i.e., reverse concat) > temp file 2 >> compute function of temp file 1 >> compute function of temp file 2 >> return minimum of f(temp file1), f(temp file2) >> >> I did this using "cat" for which it is more convenient to have the name >> of the file than the stream. >> >> In general, when invoking the shell, the shell "speaks" names, not CL >> streams. >> >> Now, as you said, I could simply replicate the logic of >> GET-TEMPORARY-FILE, but since GET-TEMPORARY-FILE pretty much replicates >> the interface of mktemp, which the shell wizards consider to be >> valuable, I think there's precedent for something like >> GET-TEMPORARY-FILE being supplied. Although, perhaps calling it >> GET-TEMPORARY-FILENAME would be better. >> >> Is there some reason it would be inappropriate to export this? >> > It's an unintentional omission indeed that > UIOP/STREAM::GET-TEMPORARY-FILE wasn't exported. I thought I had > exported it, but I failed to. The function has existed since 3.1.2 > (i.e. the first stable 3.1 release).
Since it has never been exported, I believe we can safely rename it. I note, actually, that my proposed renaming is also wrong. It should be GET-TEMPORARY-PATHNAME not FILENAME, right? Since we get back a CL pathname and not a namestring. At the expense of a slightly fatter interface, I'm tempted to add both: GET-TEMPORARY-PATHNAME returning a pathname and GET-TEMPORARY-FILENAME returning a filename (string) The former is more natural for CL, but the latter is more useful when interacting with anything that is not CL. > > Note that in most cases, you'll have cleaner code using > WITH-TEMPORARY-FILE, though (also to be considered debugged since > 3.1.2). Yes, I agree. For interop with the shell, though, this API may be handier. Best, r
