Difference between revisions of "Monomorphism by annotation of type variables"

From HaskellWiki
Jump to: navigation, search
m
Line 19: Line 19:
   
 
...would cause a type error - the type of <code>undefined</code> is also made monomorphic by the annotated type of <code>newIORef</code>, resulting in the
 
...would cause a type error - the type of <code>undefined</code> is also made monomorphic by the annotated type of <code>newIORef</code>, resulting in the
type <code>monomo a . IO (IORef a)</code> for <code>v</code>, preventing its dual specialisation to <code>IORef [Char]</code> and <code>IORef Int</code>.
+
type <code>monomo a . IORef a</code> for <code>v</code>, preventing its dual specialisation to <code>IORef [Char]</code> and <code>IORef Int</code>.
   
 
Definitions relying on the old behaviour would be modified to use, or replaced by new primitives.
 
Definitions relying on the old behaviour would be modified to use, or replaced by new primitives.

Revision as of 20:59, 20 February 2019


Introduce the reserved word monomo for rendering type variables monomorphic:

         primitive newIORef :: monomo a . a -> IO (IORef a)

Its use in the type signatures for such primitives would prevent the definition of polymorphic references in all contexts - the (abbreviated) canonical example of abuse:

         let v = ... $ newIORef undefined in
         do writeIORef v ("0" :: [Char])
            n <- readIORef v
            return (n + 1 :: Int)


...would cause a type error - the type of undefined is also made monomorphic by the annotated type of newIORef, resulting in the type monomo a . IORef a for v, preventing its dual specialisation to IORef [Char] and IORef Int.

Definitions relying on the old behaviour would be modified to use, or replaced by new primitives.

Atravers 00:21, 7 January 2019 (UTC)