PROPOSAL: Add openFileTemplate, openBinaryFileTemplate to System.IO

Simon Marlow marlowsd at
Mon Aug 3 11:45:30 EDT 2009

On 25/07/2009 13:35, Ian Lynagh wrote:
> On Fri, Jul 24, 2009 at 11:11:40PM -0700, Evan Laforge wrote:
>> On Fri, Jul 24, 2009 at 11:02 PM, minh thu<noteed at>  wrote:
>>> 2009/7/25 Evan Laforge<qdunkan at>:
>>>> I've never heard this usage of the word "template" before, so I
>>>> guessed it was meant to open some kind of template file.
>>>> openWithMode?  openWithPermissions?
>>> man mktemp
>> Ohhh, it's for the filename, sorry, all the talk about permissions got
>> me on the wrong track.
> Right. Just to clarify for anyone else reading, we currently have:
>      openTempFile           :: FilePath ->  String ->  IO (FilePath, Handle)
>      openBinaryTempFile     :: FilePath ->  String ->  IO (FilePath, Handle)
> which mask the mode, and we would add
>      openFileTemplate       :: FilePath ->  String ->  IO (FilePath, Handle)
>      openBinaryFileTemplate :: FilePath ->  String ->  IO (FilePath, Handle)
> which do not.
> Theese functions are used like this:
>      openFileTemplate "/foo/bar" "bazXXX.ext"
> and open a file called "baz143.ext". "bazXXX.ext" is the template.

I'm not too keen on the naming.  openFileTemplate differs from 
openTempFile only in that it uses the default permissions, and yet its 
name suggests that it does something quite different.

The fact that you don't know what the file is going to be called means 
that the API is only really useful for temporary files, so I have no 
problem with that being part of the name.  Perhaps 

Or perhaps we deprecate openTempFile, and make a new openTemporaryFile 
that takes a Bool argument to say whether to make the file private or not?


More information about the Libraries mailing list