No abstract

No abstract

Managing resources-file handles, database connections, etc.-is a hard problem. Debugging resource leaks and runtime errors due to resource mis-management are difficult in evolving production code. Programming languages with static type systems are great tools to ensure erroneous code is detected at compile time. However, modern static type systems do li le in the aspect of resource management as resources are treated as normal values. We propose a type system, b, based on the logic of bunched implications (BI)(O'Hearn and Pym 1999) which models resources as first class citizens. We distinguish two kinds of program objects-restricted and unrestricted-and two kinds of functions-sharing and separating. Our approach guarantees resource correctness without compromising existing functional abstractions.For a concrete example, we consider the case of file handling. In Haskell, a file being closed twice or a file not being closed at all may cause run-time errors but it not flagged as a type error. We represent separating functions, i.e. functions that do not share resources with their arguments using − * , and sharing functions i.e. functions that share resources with their arguments using ↠. In b, the type signatures of the file handling API explicitly states that they are separating in nature. is accounts for closing the file handle more than once. Each program object needs to be explicitly dropped if it has to be treated as a resource, as in linear type systems (Ahmed et al. 2007;Bernardy et al. 2017;Mazurak et al. 2010). is accounts for failing to close the file handles.Exception handling in Haskell can be done using MonadError (Liang et al. 1995). However, it does not give a systematic way of cleaning up resources in case of run-time exceptions. We consider the case where a critical section of the code throws an exception as shown in Fig. 1.e IOF describes the fact that the computation can throw exceptions, while IO does not. e catch function has a sharing argument, hence it can access the file handle fh declared in the part of the code that can throw exceptions and close it before exiting to prevent a memory leak.