Question about UIOP: Any reason GET-TEMPORARY-FILE couldn't be exported?

[Robert Goldman]

On 8/22/16 Aug 22 -5:16 PM, Faré wrote:
> On Mon, Aug 22, 2016 at 5:48 PM, Robert Goldman <rpgoldman at 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