What is an unsafe function in Haskell?

Question

I believe that an unsafe function is a function that says that it will return a value of some type, but can actually throw an exception and stop execution, therefore it does not return any value at all, but I'm not sure.

Or maybe an unsafe function is a function that can return a value of a different type than the one declared in the signature? Wouldn't that be a weakly typed function?

Or are these weakly typed and insecure synonyms in Haskell?

This may be a stupid question, but I could not find a direct answer.

I checked the readLn documentation hoping to see a link to unsafe functions, but there was none.

This article, Unsafe Functions , says something about a violation of the type system, but it does not indicate how; through exceptions ?, by returning values ​​of the wrong type?

So what is an unsafe function in Haskell?

Answer 1

Haskell has several concepts that are unsafe.

• The calculation of the value leads to input / output. The main suspect here is unsafePerformIO . It is a bit inconsistent whether it should be considered that these lazy I / O and unsafeInterleaveIO are considered unsafe by this definition.

• Something is violating the type system. The main suspect is unsafeCoerce , but unsafePerformIO can do this too.

• Something violates memory security without violating the type system (thanks Karl to remind me). The main suspects are unsafe array or vector indexing operations and misuse of an external function interface.

• The result of the calculation depends on the evaluation order. The main suspect is unsafePerformIO , but unsafeInterleaveST can do this too.

• Evaluation can lead to an exception or an infinite loop. This is a relatively mild form of insecurity ... unless it is not.

• Something violates the agreement ("laws"). Haskell programmers rely on reasoning about their code. Whether this should be considered an “unsafe" topic of discussion. Examples: applying seq to a function, using coerce in such a way as to change the arity of the function relative to its reference implementation and cause a problem if someone applies seq to what was previously a partial application, and now there may be a bottom (in some cases there is good reasons for performance) by writing instances of classes that violate functor laws, applicative ones, monads, workarounds, etc. Waiting for arguments to satisfy the prerequisites, but not checking what they are doing (for example, functions that quickly turn ascending lists into sets or maps).

Safe Haskell

To help programmers manage some of these forms of insecurity, the Safe Haskell system classifies modules as safe or insecure, depending on the import and language extensions they use. I have not studied the details, but GarethR indicates that

I think your concept 1 through 3 would be considered unsafe Safe Haskell. It may be worth reading it because the authors of Safe Haskell clearly understood security.

and Ørjan Johansen indicates that

Safe Haskell also prohibits some things that are appropriate at point 6, for example, extensions that can go beyond the export boundaries of modules (Template Haskell, getting a generic newtype) or change the behavior of imported code (rules, overlapping instances).

The programmer can mark the Safe module to indicate that they want the GHC to verify that it is safe, unsafe to indicate that it is insecure, or Trustworthy to indicate that the author claims that its API is safe to use, despite that its implementation uses unsafe functions.