[ghc-hetmet.git] / ghc / docs / users_guide / glasgow_exts.lit

%************************************************************************
%*                                                                      *
\section[glasgow-exts]{Glasgow extensions to Haskell}
\index{Haskell, Glasgow extensions}
\index{extensions, Glasgow Haskell}
%*                                                                      *
%************************************************************************

As with all known Haskell systems, GHC implements some extensions to
the language.
To use them, you'll need to give
a \tr{-fglasgow-exts}%
\index{-fglasgow-exts option} option.

Virtually all of the Glasgow extensions serve to give you access to the
underlying facilities with which we implement Haskell.  Thus, you can
get at the Raw Iron, if you are willing to write some non-standard
code at a more primitive level.  You need not be ``stuck'' on
performance because of the implementation costs of Haskell's
``high-level'' features---you can always code ``under'' them.  In an
extreme case, you can write all your time-critical code in C, and then
just glue it together with Haskell!

Executive summary of our extensions:
\begin{description}
\item[Unboxed types and primitive operations:] You can get right down
to the raw machine types and operations; included in this are
``primitive arrays'' (direct access to Big Wads of Bytes).
Please see \Sectionref{glasgow-unboxed} and following.

\item[Calling out to C:] Just what it sounds like.  We provide {\em
lots} of rope that you can dangle around your neck.
Please see \Sectionref{glasgow-ccalls}.

\item[``HBC-ish'' extensions:] Extensions implemented because people said,
``HBC does Y.  Could you teach GHC to do the same?''  Please see
\Sectionref{glasgow-hbc-exts} for a quick list.
\end{description}

Before you get too carried away working at the lowest level (e.g.,
sloshing \tr{MutableByteArray#}s around your program), you may wish to
check if there are system libraries that provide a ``Haskellised
veneer'' over the features you want.  See \Sectionref{syslibs}.

\Sectionref{ghc-prelude} is the definitive guide for many of the
low-level facilities in GHC.

%************************************************************************
%*                                                                      *
\subsection[glasgow-unboxed]{Unboxed types}
\index{Unboxed types (Glasgow extension)}
%*                                                                      *
%************************************************************************

These types correspond to the ``raw machine'' types you would use in
C: \tr{Int#} (long int), \tr{Double#} (double),
\tr{Addr#} (void *), etc.  The {\em primitive
operations} (PrimOps) on these types are what you might expect; e.g.,
\tr{(+#)} is addition on \tr{Int#}s, and is the machine-addition that
we all know and love---usually one instruction.

A numerically-intensive program using unboxed types can go a {\em lot}
faster than its ``standard'' counterpart---we saw a threefold speedup
on one example.

Please see \Sectionref{ghc-libs-ghc} for the details of
unboxed types and the operations on them.

%************************************************************************
%*                                                                      *
\subsection[glasgow-ST-monad]{Primitive state-transformer monad}
\index{state transformers (Glasgow extensions)}
\index{ST monad (Glasgow extension)}
%*                                                                      *
%************************************************************************

This monad underlies our implementation of arrays, mutable and immutable,
and our implementation of I/O, including ``C calls''.

You probably won't use the monad directly, but you might use all those
other things!

More information on the state-related types can be found in the
elsewhere, \Sectionref{ghc-prelude}.

%************************************************************************
%*                                                                      *
\subsection[glasgow-prim-arrays]{Primitive arrays, mutable and otherwise}
\index{primitive arrays (Glasgow extension)}
\index{arrays, primitive (Glasgow extension)}
%*                                                                      *
%************************************************************************

GHC knows about quite a few flavours of Large Swathes of Bytes.

First, GHC distinguishes between primitive arrays of (boxed) Haskell
objects (type \tr{Array# obj}) and primitive arrays of bytes (type
\tr{ByteArray#}).

Second, it distinguishes between...
\begin{description}
\item[Immutable:]
Arrays that do not change (as with ``standard'' Haskell arrays); you
can only read from them.  Obviously, they do not need the care and
attention of the state-transformer monad.

\item[Mutable:]
Arrays that may be changed or ``mutated.''  All the operations on them
live within the state-transformer monad and the updates happen {\em
in-place}.

\item[``Static'' (in C land):]
A C~routine may pass an \tr{Addr#} pointer back into Haskell land.
There are then primitive operations with which you may merrily grab
values over in C land, by indexing off the ``static'' pointer.

\item[``Stable'' pointers:]
If, for some reason, you wish to hand a Haskell pointer (i.e., {\em
not} an unboxed value) to a C~routine, you first make the pointer
``stable,'' so that the garbage collector won't forget that it exists.
That is, GHC provides a safe way to pass Haskell pointers to C.

Please see \Sectionref{glasgow-stablePtrs} for more details.

\item[``Foreign objects'':]
A ``foreign object'' is a safe way to pass an external object (a
C~allocated pointer, say) to Haskell and have Haskell do the Right
Thing when it no longer references the object.  So, for example, C
could pass a large bitmap over to Haskell and say ``please free this
memory when you're done with it.'' 

Please see \Sectionref{glasgow-foreignObjs} for more details.
\end{description}

The libraries section give more details on all these 
``primitive array'' types and the operations on them,
\Sectionref{ghc-prelude}.


%************************************************************************
%*                                                                      *
\subsection[own-mainIO]{Using your own @mainIO@}
\index{mainIO, rolling your own}
\index{GHCmain, module containing mainIO}
%*                                                                      *
%************************************************************************

Normally, the GHC runtime system begins things by called an internal
function @mainIO :: IO ()@ which, in turn, fires up your @Main.main@.
The standard definition of @mainIO@ looks like this:

\begin{verbatim}
mainIO = catch Main.main 
           (\err -> error ("I/O error: " ++ showsPrec 0 err "\n"))
\end{verbatim}

\noindent that is, all it does is to run @Main.main@, catching any I/O
errors that occur and displaying them on standard error before exiting
the program.

To subvert the above process, you need only provide a @mainIO :: IO
()@ of your own (in a module named \tr{GHCmain}).

Here's a little example, stolen from Alastair Reid:

\begin{verbatim}
module GHCmain ( mainIO ) where

import GlaExts

mainIO :: IO ()
mainIO = do
         sleep 5
         _ccall_ printf "%d\n" (14::Int)

sleep :: Int -> IO ()
sleep t = _ccall_ sleep t
\end{verbatim}

%************************************************************************
%*                                                                      *
\subsection[glasgow-ccalls]{Calling~C directly from Haskell}
\index{C calls (Glasgow extension)}
\index{_ccall_ (Glasgow extension)}
\index{_casm_ (Glasgow extension)}
%*                                                                      *
%************************************************************************

GOOD ADVICE: Because this stuff is not Entirely Stable as far as names
and things go, you would be well-advised to keep your C-callery
corraled in a few modules, rather than sprinkled all over your code.
It will then be quite easy to update later on.

WARNING AS OF 2.03: Yes, the \tr{_ccall_} stuff probably {\em will
change}, to something better, of course!  One step in that direction
is Green Card, a foreign function interface pre-processor for Haskell
(``Glasgow'' Haskell in particular) --- check out 
\begin{verbatim}
ftp://ftp.dcs.gla.ac.uk/pub/haskell/glasgow/green-card.ANNOUNCE
ftp://ftp.dcs.gla.ac.uk/pub/haskell/glasgow/green-card-src.tar.gz
\end{verbatim}

%************************************************************************
%*                                                                      *
\subsubsection[ccall-intro]{\tr{_ccall_} and \tr{_casm_}: an introduction}
%*                                                                      *
%************************************************************************

The simplest way to use a simple C function
\begin{verbatim}
double fooC( FILE *in, char c, int i, double d, unsigned int u )
\end{verbatim}
is to provide a Haskell wrapper:
\begin{verbatim}
fooH :: Char -> Int -> Double -> Word -> IO Double
fooH c i d w = _ccall_ fooC (``stdin''::Addr) c i d w
\end{verbatim}
The function @fooH@ will unbox all of its arguments, call the C
function \tr{fooC} and box the corresponding arguments.

One of the annoyances about \tr{_ccall_}s is when the C types don't quite
match the Haskell compiler's ideas.  For this, the \tr{_casm_} variant
may be just the ticket (NB: {\em no chance} of such code going through
a native-code generator):
\begin{verbatim}
oldGetEnv name
  = _casm_ ``%r = getenv((char *) %0);'' name >>= \ litstring@(A# str#) ->
    return (
        if (litstring == ``NULL'') then
            Left ("Fail:oldGetEnv:"++name)
        else
            Right (unpackCString# str#)
    )
\end{verbatim}

The first literal-literal argument to a \tr{_casm_} is like a
\tr{printf} format: \tr{%r} is replaced with the ``result,''
\tr{%0}--\tr{%n-1} are replaced with the 1st--nth arguments.  As you
can see above, it is an easy way to do simple C~casting.  Everything
said about \tr{_ccall_} goes for \tr{_casm_} as well.

%************************************************************************
%*                                                                      *
\subsubsection[glasgow-foreign-headers]{Using function headers}
\index{C calls---function headers}
%*                                                                      *
%************************************************************************

When generating C (using the \tr{-fvia-C} directive), one can assist
the C compiler in detecting type errors by using the \tr{-#include}
directive to provide \tr{.h} files containing function headers.

For example,
\begin{verbatim}
typedef unsigned long *StgForeignObj;
typedef long StgInt;

void          initialiseEFS (StgInt size);
StgInt        terminateEFS (void);
StgForeignObj emptyEFS(void);
StgForeignObj updateEFS (StgForeignObj a, StgInt i, StgInt x);
StgInt        lookupEFS (StgForeignObj a, StgInt i);
\end{verbatim}

You can find appropriate definitions for \tr{StgInt},
\tr{StgForeignObj}, etc using \tr{gcc} on your architecture by
consulting \tr{ghc/includes/StgTypes.lh}.  The following table
summarises the relationship between Haskell types and C types.

\begin{tabular}{ll}
C type name      & Haskell Type \\ \hline
%-----           & ---------------     
\tr{StgChar}          & \tr{Char#}\\               
\tr{StgInt}           & \tr{Int#}\\                
\tr{StgWord}          & \tr{Word#}\\               
\tr{StgAddr}          & \tr{Addr#}\\               
\tr{StgFloat}         & \tr{Float#}\\              
\tr{StgDouble}        & \tr{Double#}\\             
                            
\tr{StgArray}         & \tr{Array#}\\              
\tr{StgByteArray}     & \tr{ByteArray#}\\          
\tr{StgArray}         & \tr{MutableArray#}\\       
\tr{StgByteArray}     & \tr{MutableByteArray#}\\   
                                    
\tr{StgStablePtr}     & \tr{StablePtr#}\\          
\tr{StgForeignObj}    & \tr{ForeignObj#}
\end{tabular}

Note that this approach is only {\em essential\/} for returning
\tr{float}s (or if \tr{sizeof(int) != sizeof(int *)} on your
architecture) but is a Good Thing for anyone who cares about writing
solid code.  You're crazy not to do it.

%************************************************************************
%*                                                                      *
\subsubsection[glasgow-stablePtrs]{Subverting automatic unboxing with ``stable pointers''}
\index{stable pointers (Glasgow extension)}
%*                                                                      *
%************************************************************************

The arguments of a \tr{_ccall_} are automatically unboxed before the
call.  There are two reasons why this is usually the Right Thing to do:
\begin{itemize}
\item
C is a strict language: it would be excessively tedious to pass
unevaluated arguments and require the C programmer to force their
evaluation before using them.

\item Boxed values are stored on the Haskell heap and may be moved
within the heap if a garbage collection occurs---that is, pointers
to boxed objects are not {\em stable\/}.
\end{itemize}

It is possible to subvert the unboxing process by creating a ``stable
pointer'' to a value and passing the stable pointer instead.  For example, to
pass/return an integer lazily to C functions \tr{storeC} and
\tr{fetchC}, one might write:
\begin{verbatim}
storeH :: Int -> IO ()
storeH x = makeStablePtr x              >>= \ stable_x ->
           _ccall_ storeC stable_x

fetchH :: IO Int
fetchH x = _ccall_ fetchC               >>= \ stable_x ->
           deRefStablePtr stable_x      >>= \ x ->
           freeStablePtr stable_x       >>
           return x
\end{verbatim}

The garbage collector will refrain from throwing a stable pointer away
until you explicitly call one of the following from C or Haskell.
\begin{verbatim}
void freeStablePointer( StgStablePtr stablePtrToToss )
freeStablePtr :: StablePtr a -> IO ()
\end{verbatim}

As with the use of \tr{free} in C programs, GREAT CARE SHOULD BE
EXERCISED to ensure these functions are called at the right time: too
early and you get dangling references (and, if you're lucky, an error
message from the runtime system); too late and you get space leaks.

And to force evaluation of the argument within \tr{fooC}, one would
call one of the following C functions (according to type of argument).

\begin{verbatim}
void     performIO  ( StgStablePtr stableIndex /* StablePtr s (IO ()) */ );
StgInt   enterInt   ( StgStablePtr stableIndex /* StablePtr s Int */ );
StgFloat enterFloat ( StgStablePtr stableIndex /* StablePtr s Float */ );
\end{verbatim}

\index{performIO, call a haskell IO computation from C}
\index{enterInt, call a haskell function from C}
\index{enterFloat, call a haskell function from C}

% ToDo ADR: test these functions!

Note Bene: \tr{_ccall_GC_} must be used if any of these functions are used.


%************************************************************************
%*                                                                      *
\subsubsection[glasgow-foreignObjs]{Pointing outside the Haskell heap}
\index{foreign objects (Glasgow extension)}
%*                                                                      *
%************************************************************************

There are two types that \tr{ghc} programs can use to reference
(heap-allocated) objects outside the Haskell world: \tr{Addr} and
\tr{ForeignObj}.

If you use \tr{Addr}, it is up to you to the programmer to arrange
allocation and deallocation of the objects.

If you use \tr{ForeignObj}, \tr{ghc}'s garbage collector will
call upon the user-supplied {\em finaliser} function to free
the object when the Haskell world no longer can access the object.
(An object is associated with a finaliser function when the abstract
 Haskell type @ForeignObj@ is created). The finaliser function is
expressed in C, and is passed as argument the object:

\begin{verbatim}
void foreignFinaliser ( StgForeignObj fo )
\end{verbatim}
when the Haskell world can no longer access the object.  Since
\tr{ForeignObj}s only get released when a garbage collection occurs,
we provide ways of triggering a garbage collection from within C and
from within Haskell.
\begin{verbatim}
void StgPerformGarbageCollection()
performGC :: IO ()
\end{verbatim}

%************************************************************************
%*                                                                      *
\subsubsection[glasgow-avoiding-monads]{Avoiding monads}
\index{C calls to `pure C'}
\index{unsafePerformIO (GlaExts)}
%*                                                                      *
%************************************************************************

The \tr{_ccall_} construct is part of the \tr{IO} monad because 9 out
of 10 uses will be to call imperative functions with side effects such
as \tr{printf}.  Use of the monad ensures that these operations happen
in a predictable order in spite of laziness and compiler
optimisations.

To avoid having to be in the monad to call a C function, it is
possible to use @unsafePerformIO@, which is available from the
@IOExts@ module.  There are three situations where one might like to
call a C function from outside the IO world:

\begin{itemize}
\item
Calling a function with no side-effects:
\begin{verbatim}
atan2d :: Double -> Double -> Double
atan2d y x = unsafePerformIO (_ccall_ atan2d y x)

sincosd :: Double -> (Double, Double)
sincosd x = unsafePerformIO $ do
        da <- newDoubleArray (0, 1)
        _casm_ ``sincosd( %0, &((double *)%1[0]), &((double *)%1[1]) );'' x da
        s <- readDoubleArray da 0
        c <- readDoubleArray da 1
        return (s, c)
\end{verbatim}

\item Calling a set of functions which have side-effects but which can
be used in a purely functional manner.

For example, an imperative implementation of a purely functional
lookup-table might be accessed using the following functions.

\begin{verbatim}
empty  :: EFS x
update :: EFS x -> Int -> x -> EFS x
lookup :: EFS a -> Int -> a

empty = unsafePerformIO (_ccall_ emptyEFS)

update a i x = unsafePerformIO $
        makeStablePtr x         >>= \ stable_x ->
        _ccall_ updateEFS a i stable_x

lookup a i = unsafePerformIO $
        _ccall_ lookupEFS a i   >>= \ stable_x ->
        deRefStablePtr stable_x
\end{verbatim}

You will almost always want to use \tr{ForeignObj}s with this.

\item Calling a side-effecting function even though the results will
be unpredictable.  For example the \tr{trace} function is defined by:

\begin{verbatim}
trace :: String -> a -> a
trace string expr
  = unsafePerformIO (
        ((_ccall_ PreTraceHook sTDERR{-msg-}):: IO ())  >>
        fputs sTDERR string                             >>
        ((_ccall_ PostTraceHook sTDERR{-msg-}):: IO ()) >>
        return expr )
  where
    sTDERR = (``stderr'' :: Addr)
\end{verbatim}

(This kind of use is not highly recommended --- it is only really
useful in debugging code.)
\end{itemize}

%************************************************************************
%*                                                                      *
\subsubsection[ccall-gotchas]{C-calling ``gotchas'' checklist}
\index{C call dangers}
%*                                                                      *
%************************************************************************

And some advice, too.

\begin{itemize}
\item
\tr{_ccall_} is part of the \tr{IO} monad --- not the \tr{ST} monad.
Use the functions
\begin{verbatim}
ioToST :: IO a -> ST RealWorld a
stToIO :: ST RealWorld a -> IO a
\end{verbatim}
\index{ioToST function}
\index{stToIO function}
to coerce computations back and forth between the two monads.

\item For modules that use \tr{_ccall_}s, etc., compile with
\tr{-fvia-C}.\index{-fvia-C option} You don't have to, but you should.

Also, use the \tr{-#include "prototypes.h"} flag (hack) to inform the
C compiler of the fully-prototyped types of all the C functions you
call.  (\Sectionref{glasgow-foreign-headers} says more about this...)

This scheme is the {\em only} way that you will get {\em any}
typechecking of your \tr{_ccall_}s.  (It shouldn't be that way,
but...)

\item
Try to avoid \tr{_ccall_}s to C~functions that take \tr{float}
arguments or return \tr{float} results.  Reason: if you do, you will
become entangled in (ANSI?) C's rules for when arguments/results are
promoted to \tr{doubles}.  It's a nightmare and just not worth it.
Use \tr{doubles} if possible.

If you do use \tr{floats}, check and re-check that the right thing is
happening.  Perhaps compile with \tr{-keep-hc-file-too} and look at
the intermediate C (\tr{.hc} file).

\item
The compiler uses two non-standard type-classes when
type-checking the arguments and results of \tr{_ccall_}: the arguments
(respectively result) of \tr{_ccall_} must be instances of the class
\tr{CCallable} (respectively \tr{CReturnable}).  (Neither class
defines any methods --- their only function is to keep the
type-checker happy.)

The type checker must be able to figure out just which of the
C-callable/returnable types is being used.  If it can't, you have to
add type signatures. For example,
\begin{verbatim}
f x = _ccall_ foo x
\end{verbatim}
is not good enough, because the compiler can't work out what type @x@ is, nor 
what type the @_ccall_@ returns.  You have to write, say:
\begin{verbatim}
f :: Int -> IO Double
f x = _ccall_ foo x
\end{verbatim}

This table summarises the standard instances of these classes.

% ToDo: check this table against implementation!

\begin{tabular}{llll}
Type                &CCallable&CReturnable & Which is probably... \\ \hline
%------            ----------  ------------    -------------
\tr{Char}              & Yes  & Yes   & \tr{unsigned char} \\
\tr{Int}               & Yes  & Yes   & \tr{long int} \\
\tr{Word}              & Yes  & Yes   & \tr{unsigned long int} \\
\tr{Addr}              & Yes  & Yes   & \tr{char *} \\
\tr{Float}             & Yes  & Yes   & \tr{float} \\
\tr{Double}            & Yes  & Yes   & \tr{double} \\
\tr{()}                & No   & Yes   & \tr{void} \\
\tr{[Char]}            & Yes  & No    & \tr{char *} (null-terminated) \\
                                      
\tr{Array}             & Yes  & No    & \tr{unsigned long *}\\
\tr{ByteArray}         & Yes  & No    & \tr{unsigned long *}\\
\tr{MutableArray}      & Yes  & No    & \tr{unsigned long *}\\
\tr{MutableByteArray}  & Yes  & No    & \tr{unsigned long *}\\
                                       
\tr{State}             & Yes  & Yes   & nothing!\\
                                       
\tr{StablePtr}         & Yes  & Yes   & \tr{unsigned long *}\\
\tr{ForeignObjs}       & Yes  & Yes   & see later\\
\end{tabular}

The brave and careful programmer can add their own instances of these
classes for the following types:
\begin{itemize}
\item
A {\em boxed-primitive} type may be made an instance of both
\tr{CCallable} and \tr{CReturnable}.  

A boxed primitive type is any data type with a
single unary constructor with a single primitive argument.  For
example, the following are all boxed primitive types:

\begin{verbatim}
Int
Double
data XDisplay = XDisplay Addr#
data EFS a = EFS# ForeignObj#
\end{verbatim}

\begin{verbatim}
instance CCallable   (EFS a)
instance CReturnable (EFS a)
\end{verbatim}

\item Any datatype with a single nullary constructor may be made an
instance of \tr{CReturnable}.  For example:

\begin{verbatim}
data MyVoid = MyVoid
instance CReturnable MyVoid
\end{verbatim}

\item As at version 2.09, \tr{String} (i.e., \tr{[Char]}) is still
not a \tr{CReturnable} type.

Also, the now-builtin type \tr{PackedString} is neither
\tr{CCallable} nor \tr{CReturnable}.  (But there are functions in
the PackedString interface to let you get at the necessary bits...)
\end{itemize}

\item
The code-generator will complain if you attempt to use \tr{%r}
in a \tr{_casm_} whose result type is \tr{IO ()}; or if you don't
use \tr{%r} {\em precisely\/} once for any other result type.  These
messages are supposed to be helpful and catch bugs---please tell us
if they wreck your life.

\item If you call out to C code which may trigger the Haskell garbage
collector (examples of this later...), then you must use the
\tr{_ccall_GC_}\index{_ccall_GC_ primitive} or
\tr{_casm_GC_}\index{_casm_GC_ primitive} variant of C-calls.  (This
does not work with the native code generator - use \tr{\fvia-C}.) This
stuff is hairy with a capital H!  \end{itemize}

%************************************************************************
%*                                                                      *
\subsection[glasgow-hbc-exts]{``HBC-ish'' extensions implemented by GHC}
\index{HBC-like Glasgow extensions}
\index{extensions, HBC-like}
%*                                                                      *
%************************************************************************

\begin{description}
%-------------------------------------------------------------------
\item[@fromInt@ method in class @Num@:]
It's there.  Converts from an \tr{Int} to the type.

%-------------------------------------------------------------------
\item[@toInt@ method in class @Integral@:]
Converts from type type to an \tr{Int}.

%-------------------------------------------------------------------
\item[Overlapping instance declarations:]
\index{overlapping instances}
\index{instances, overlapping}

In \tr{instance <context> => Class (T x1 ... xn)}, the \tr{xi}s can be
{\em types}, rather than just {\em type variables}.

Thus, you can have an instance \tr{instance Foo [Char]}, as well as
the more general \tr{instance Foo [a]}; the former will be used in
preference to the latter, where applicable.

As Lennart says, ``This is a dubious feature and should not be used
carelessly.''

See also: \tr{SPECIALIZE instance} pragmas, in \Sectionref{faster}.
\end{description}