1 %************************************************************************
3 \section[glasgow-exts]{Glasgow extensions to Haskell}
4 \index{Haskell, Glasgow extensions}
5 \index{extensions, Glasgow Haskell}
7 %************************************************************************
9 As with all known Haskell systems, GHC implements some extensions to
11 To use them, you'll need to give
12 a \tr{-fglasgow-exts}%
13 \index{-fglasgow-exts option} option.
15 Virtually all of the Glasgow extensions serve to give you access to the
16 underlying facilities with which we implement Haskell. Thus, you can
17 get at the Raw Iron, if you are willing to write some non-standard
18 code at a more primitive level. You need not be ``stuck'' on
19 performance because of the implementation costs of Haskell's
20 ``high-level'' features---you can always code ``under'' them. In an
21 extreme case, you can write all your time-critical code in C, and then
22 just glue it together with Haskell!
24 Executive summary of our extensions:
26 \item[Unboxed types and primitive operations:] You can get right down
27 to the raw machine types and operations; included in this are
28 ``primitive arrays'' (direct access to Big Wads of Bytes).
29 Please see \Sectionref{glasgow-unboxed} and following.
31 \item[Calling out to C:] Just what it sounds like. We provide {\em
32 lots} of rope that you can dangle around your neck.
33 Please see \Sectionref{glasgow-ccalls}.
35 \item[``HBC-ish'' extensions:] Extensions implemented because people said,
36 ``HBC does Y. Could you teach GHC to do the same?'' Please see
37 \Sectionref{glasgow-hbc-exts} for a quick list.
40 Before you get too carried away working at the lowest level (e.g.,
41 sloshing \tr{MutableByteArray#}s around your program), you may wish to
42 check if there are system libraries that provide a ``Haskellised
43 veneer'' over the features you want. See \Sectionref{syslibs}.
45 \Sectionref{ghc-prelude} is the definitive guide for many of the
46 low-level facilities in GHC.
48 %************************************************************************
50 \subsection[glasgow-unboxed]{Unboxed types}
51 \index{Unboxed types (Glasgow extension)}
53 %************************************************************************
55 These types correspond to the ``raw machine'' types you would use in
56 C: \tr{Int#} (long int), \tr{Double#} (double),
57 \tr{Addr#} (void *), etc. The {\em primitive
58 operations} (PrimOps) on these types are what you might expect; e.g.,
59 \tr{(+#)} is addition on \tr{Int#}s, and is the machine-addition that
60 we all know and love---usually one instruction.
62 A numerically-intensive program using unboxed types can go a {\em lot}
63 faster than its ``standard'' counterpart---we saw a threefold speedup
66 Please see \Sectionref{ghc-libs-ghc} for the details of
67 unboxed types and the operations on them.
69 %************************************************************************
71 \subsection[glasgow-ST-monad]{Primitive state-transformer monad}
72 \index{state transformers (Glasgow extensions)}
73 \index{ST monad (Glasgow extension)}
75 %************************************************************************
77 This monad underlies our implementation of arrays, mutable and immutable,
78 and our implementation of I/O, including ``C calls''.
80 You probably won't use the monad directly, but you might use all those
83 More information on the state-related types can be found in the
84 elsewhere, \Sectionref{ghc-prelude}.
86 %************************************************************************
88 \subsection[glasgow-prim-arrays]{Primitive arrays, mutable and otherwise}
89 \index{primitive arrays (Glasgow extension)}
90 \index{arrays, primitive (Glasgow extension)}
92 %************************************************************************
94 GHC knows about quite a few flavours of Large Swathes of Bytes.
96 First, GHC distinguishes between primitive arrays of (boxed) Haskell
97 objects (type \tr{Array# obj}) and primitive arrays of bytes (type
100 Second, it distinguishes between...
103 Arrays that do not change (as with ``standard'' Haskell arrays); you
104 can only read from them. Obviously, they do not need the care and
105 attention of the state-transformer monad.
108 Arrays that may be changed or ``mutated.'' All the operations on them
109 live within the state-transformer monad and the updates happen {\em
112 \item[``Static'' (in C land):]
113 A C~routine may pass an \tr{Addr#} pointer back into Haskell land.
114 There are then primitive operations with which you may merrily grab
115 values over in C land, by indexing off the ``static'' pointer.
117 \item[``Stable'' pointers:]
118 If, for some reason, you wish to hand a Haskell pointer (i.e., {\em
119 not} an unboxed value) to a C~routine, you first make the pointer
120 ``stable,'' so that the garbage collector won't forget that it exists.
121 That is, GHC provides a safe way to pass Haskell pointers to C.
123 Please see \Sectionref{glasgow-stablePtrs} for more details.
125 \item[``Foreign objects'':]
126 A ``foreign object'' is a safe way to pass an external object (a
127 C~allocated pointer, say) to Haskell and have Haskell do the Right
128 Thing when it no longer references the object. So, for example, C
129 could pass a large bitmap over to Haskell and say ``please free this
130 memory when you're done with it.''
132 Please see \Sectionref{glasgow-foreignObjs} for more details.
135 The libraries section give more details on all these
136 ``primitive array'' types and the operations on them,
137 \Sectionref{ghc-prelude}.
140 %************************************************************************
142 \subsection[own-mainIO]{Using your own @mainIO@}
143 \index{mainIO, rolling your own}
144 \index{GHCmain, module containing mainIO}
146 %************************************************************************
148 Normally, the GHC runtime system begins things by called an internal
155 \noindent which, in turn, fires up your @Main.main@. The standard
156 definition of @mainIO@ looks like this:
159 mainIO = catch Main.main
160 (\err -> error ("I/O error: " ++
161 showsPrec 0 err "\n"))
164 \noindent that is, all it does is run @Main.main@, catching any I/O
165 errors that occur and displaying them on standard error before exiting
168 To subvert the above process, you need only provide a @mainIO@ of your
169 own (in a module named \tr{GHCmain}).
171 Here's a little example, stolen from Alastair Reid:
174 module GHCmain ( mainIO ) where
181 _ccall_ printf "%d\n" (14::Int)
183 sleep :: Int -> IO ()
184 sleep t = _ccall_ sleep t
187 %************************************************************************
189 \subsection[glasgow-ccalls]{Calling~C directly from Haskell}
190 \index{C calls (Glasgow extension)}
191 \index{_ccall_ (Glasgow extension)}
192 \index{_casm_ (Glasgow extension)}
194 %************************************************************************
196 GOOD ADVICE: Because this stuff is not Entirely Stable as far as names
197 and things go, you would be well-advised to keep your C-callery
198 corraled in a few modules, rather than sprinkled all over your code.
199 It will then be quite easy to update later on.
201 WARNING AS OF 2.03: Yes, the \tr{_ccall_} stuff probably {\em will
202 change}, to something better, of course! One step in that direction
203 is Green Card, a foreign function interface pre-processor for Haskell
204 (``Glasgow'' Haskell in particular) --- check out
206 ftp://ftp.dcs.gla.ac.uk/pub/haskell/glasgow/green-card.ANNOUNCE
207 ftp://ftp.dcs.gla.ac.uk/pub/haskell/glasgow/green-card-src.tar.gz
210 %************************************************************************
212 \subsubsection[ccall-intro]{\tr{_ccall_} and \tr{_casm_}: an introduction}
214 %************************************************************************
216 The simplest way to use a simple C function
218 double fooC( FILE *in, char c, int i, double d, unsigned int u )
220 is to provide a Haskell wrapper:
222 fooH :: Char -> Int -> Double -> Word -> IO Double
223 fooH c i d w = _ccall_ fooC (``stdin''::Addr) c i d w
225 The function @fooH@ will unbox all of its arguments, call the C
226 function \tr{fooC} and box the corresponding arguments.
228 One of the annoyances about \tr{_ccall_}s is when the C types don't quite
229 match the Haskell compiler's ideas. For this, the \tr{_casm_} variant
230 may be just the ticket (NB: {\em no chance} of such code going through
231 a native-code generator):
234 = _casm_ ``%r = getenv((char *) %0);'' name >>= \ litstring@(A# str#) ->
236 if (litstring == ``NULL'') then
237 Left ("Fail:oldGetEnv:"++name)
239 Right (unpackCString# str#)
243 The first literal-literal argument to a \tr{_casm_} is like a
244 \tr{printf} format: \tr{%r} is replaced with the ``result,''
245 \tr{%0}--\tr{%n-1} are replaced with the 1st--nth arguments. As you
246 can see above, it is an easy way to do simple C~casting. Everything
247 said about \tr{_ccall_} goes for \tr{_casm_} as well.
249 %************************************************************************
251 \subsubsection[glasgow-foreign-headers]{Using function headers}
252 \index{C calls, function headers}
254 %************************************************************************
256 When generating C (using the \tr{-fvia-C} directive), one can assist
257 the C compiler in detecting type errors by using the \tr{-#include}
258 directive to provide \tr{.h} files containing function headers.
262 typedef unsigned long *StgForeignObj;
265 void initialiseEFS (StgInt size);
266 StgInt terminateEFS (void);
267 StgForeignObj emptyEFS(void);
268 StgForeignObj updateEFS (StgForeignObj a, StgInt i, StgInt x);
269 StgInt lookupEFS (StgForeignObj a, StgInt i);
272 You can find appropriate definitions for \tr{StgInt},
273 \tr{StgForeignObj}, etc using \tr{gcc} on your architecture by
274 consulting \tr{ghc/includes/StgTypes.lh}. The following table
275 summarises the relationship between Haskell types and C types.
278 C type name & Haskell Type \\ \hline
279 %----- & ---------------
280 \tr{StgChar} & \tr{Char#}\\
281 \tr{StgInt} & \tr{Int#}\\
282 \tr{StgWord} & \tr{Word#}\\
283 \tr{StgAddr} & \tr{Addr#}\\
284 \tr{StgFloat} & \tr{Float#}\\
285 \tr{StgDouble} & \tr{Double#}\\
287 \tr{StgArray} & \tr{Array#}\\
288 \tr{StgByteArray} & \tr{ByteArray#}\\
289 \tr{StgArray} & \tr{MutableArray#}\\
290 \tr{StgByteArray} & \tr{MutableByteArray#}\\
292 \tr{StgStablePtr} & \tr{StablePtr#}\\
293 \tr{StgForeignObj} & \tr{ForeignObj#}
296 Note that this approach is only {\em essential\/} for returning
297 \tr{float}s (or if \tr{sizeof(int) != sizeof(int *)} on your
298 architecture) but is a Good Thing for anyone who cares about writing
299 solid code. You're crazy not to do it.
301 %************************************************************************
303 \subsubsection[glasgow-stablePtrs]{Subverting automatic unboxing with ``stable pointers''}
304 \index{stable pointers (Glasgow extension)}
306 %************************************************************************
308 The arguments of a \tr{_ccall_} are automatically unboxed before the
309 call. There are two reasons why this is usually the Right Thing to do:
312 C is a strict language: it would be excessively tedious to pass
313 unevaluated arguments and require the C programmer to force their
314 evaluation before using them.
316 \item Boxed values are stored on the Haskell heap and may be moved
317 within the heap if a garbage collection occurs---that is, pointers
318 to boxed objects are not {\em stable\/}.
321 It is possible to subvert the unboxing process by creating a ``stable
322 pointer'' to a value and passing the stable pointer instead. For example, to
323 pass/return an integer lazily to C functions \tr{storeC} and
324 \tr{fetchC}, one might write:
326 storeH :: Int -> IO ()
327 storeH x = makeStablePtr x >>= \ stable_x ->
328 _ccall_ storeC stable_x
331 fetchH x = _ccall_ fetchC >>= \ stable_x ->
332 deRefStablePtr stable_x >>= \ x ->
333 freeStablePtr stable_x >>
337 The garbage collector will refrain from throwing a stable pointer away
338 until you explicitly call one of the following from C or Haskell.
340 void freeStablePointer( StgStablePtr stablePtrToToss )
341 freeStablePtr :: StablePtr a -> IO ()
344 As with the use of \tr{free} in C programs, GREAT CARE SHOULD BE
345 EXERCISED to ensure these functions are called at the right time: too
346 early and you get dangling references (and, if you're lucky, an error
347 message from the runtime system); too late and you get space leaks.
349 And to force evaluation of the argument within \tr{fooC}, one would
350 call one of the following C functions (according to type of argument).
353 void performIO ( StgStablePtr stableIndex /* StablePtr s (IO ()) */ );
354 StgInt enterInt ( StgStablePtr stableIndex /* StablePtr s Int */ );
355 StgFloat enterFloat ( StgStablePtr stableIndex /* StablePtr s Float */ );
358 \index{performIO, call a haskell IO computation from C}
359 \index{enterInt, call a haskell function from C}
360 \index{enterFloat, call a haskell function from C}
362 % ToDo ADR: test these functions!
364 Note Bene: \tr{_ccall_GC_} must be used if any of these functions are used.
367 %************************************************************************
369 \subsubsection[glasgow-foreignObjs]{Pointing outside the Haskell heap}
370 \index{foreign objects (Glasgow extension)}
372 %************************************************************************
374 There are two types that \tr{ghc} programs can use to reference
375 (heap-allocated) objects outside the Haskell world: \tr{Addr} and
378 If you use \tr{Addr}, it is up to you to the programmer to arrange
379 allocation and deallocation of the objects.
381 If you use \tr{ForeignObj}, \tr{ghc}'s garbage collector will
382 call upon the user-supplied {\em finaliser} function to free
383 the object when the Haskell world no longer can access the object.
384 (An object is associated with a finaliser function when the abstract
385 Haskell type @ForeignObj@ is created). The finaliser function is
386 expressed in C, and is passed as argument the object:
389 void foreignFinaliser ( StgForeignObj fo )
391 when the Haskell world can no longer access the object. Since
392 \tr{ForeignObj}s only get released when a garbage collection occurs,
393 we provide ways of triggering a garbage collection from within C and
396 void StgPerformGarbageCollection()
400 More information is provided on the programmers' interface to
401 @ForeignObj@ can be found in Section \ref{sec:foreign-obj}.
403 %************************************************************************
405 \subsubsection[glasgow-avoiding-monads]{Avoiding monads}
406 \index{C calls to `pure C'}
407 \index{unsafePerformIO}
409 %************************************************************************
411 The \tr{_ccall_} construct is part of the \tr{IO} monad because 9 out
412 of 10 uses will be to call imperative functions with side effects such
413 as \tr{printf}. Use of the monad ensures that these operations happen
414 in a predictable order in spite of laziness and compiler
417 To avoid having to be in the monad to call a C function, it is
418 possible to use @unsafePerformIO@, which is available from the
419 @IOExts@ module. There are three situations where one might like to
420 call a C function from outside the IO world:
424 Calling a function with no side-effects:
426 atan2d :: Double -> Double -> Double
427 atan2d y x = unsafePerformIO (_ccall_ atan2d y x)
429 sincosd :: Double -> (Double, Double)
430 sincosd x = unsafePerformIO $ do
431 da <- newDoubleArray (0, 1)
432 _casm_ ``sincosd( %0, &((double *)%1[0]), &((double *)%1[1]) );'' x da
433 s <- readDoubleArray da 0
434 c <- readDoubleArray da 1
438 \item Calling a set of functions which have side-effects but which can
439 be used in a purely functional manner.
441 For example, an imperative implementation of a purely functional
442 lookup-table might be accessed using the following functions.
446 update :: EFS x -> Int -> x -> EFS x
447 lookup :: EFS a -> Int -> a
449 empty = unsafePerformIO (_ccall_ emptyEFS)
451 update a i x = unsafePerformIO $
452 makeStablePtr x >>= \ stable_x ->
453 _ccall_ updateEFS a i stable_x
455 lookup a i = unsafePerformIO $
456 _ccall_ lookupEFS a i >>= \ stable_x ->
457 deRefStablePtr stable_x
460 You will almost always want to use \tr{ForeignObj}s with this.
462 \item Calling a side-effecting function even though the results will
463 be unpredictable. For example the \tr{trace} function is defined by:
466 trace :: String -> a -> a
469 ((_ccall_ PreTraceHook sTDERR{-msg-}):: IO ()) >>
470 fputs sTDERR string >>
471 ((_ccall_ PostTraceHook sTDERR{-msg-}):: IO ()) >>
474 sTDERR = (``stderr'' :: Addr)
477 (This kind of use is not highly recommended --- it is only really
478 useful in debugging code.)
481 %************************************************************************
483 \subsubsection[ccall-gotchas]{C-calling ``gotchas'' checklist}
484 \index{C call dangers}
486 %************************************************************************
488 And some advice, too.
491 \item For modules that use \tr{_ccall_}s, etc., compile with
492 \tr{-fvia-C}.\index{-fvia-C option} You don't have to, but you should.
494 Also, use the \tr{-#include "prototypes.h"} flag (hack) to inform the
495 C compiler of the fully-prototyped types of all the C functions you
496 call. (\Sectionref{glasgow-foreign-headers} says more about this...)
498 This scheme is the {\em only} way that you will get {\em any}
499 typechecking of your \tr{_ccall_}s. (It shouldn't be that way,
503 Try to avoid \tr{_ccall_}s to C~functions that take \tr{float}
504 arguments or return \tr{float} results. Reason: if you do, you will
505 become entangled in (ANSI?) C's rules for when arguments/results are
506 promoted to \tr{doubles}. It's a nightmare and just not worth it.
507 Use \tr{doubles} if possible.
509 If you do use \tr{floats}, check and re-check that the right thing is
510 happening. Perhaps compile with \tr{-keep-hc-file-too} and look at
511 the intermediate C (\tr{.hc} file).
513 \item The compiler uses two non-standard type-classes when
514 type-checking the arguments and results of \tr{_ccall_}: the arguments
515 (respectively result) of \tr{_ccall_} must be instances of the class
516 \tr{CCallable} (respectively \tr{CReturnable}). Both classes may be
517 imported from the module @CCall@, but this should only be necessary if
518 you want to define a new instance. (Neither class defines any methods
519 --- their only function is to keep the type-checker happy.)
521 The type checker must be able to figure out just which of the
522 C-callable/returnable types is being used. If it can't, you have to
523 add type signatures. For example,
527 is not good enough, because the compiler can't work out what type @x@ is, nor
528 what type the @_ccall_@ returns. You have to write, say:
530 f :: Int -> IO Double
534 This table summarises the standard instances of these classes.
536 % ToDo: check this table against implementation!
538 \begin{tabular}{llll}
539 Type &CCallable&CReturnable & Which is probably... \\ \hline
540 %------ ---------- ------------ -------------
541 \tr{Char} & Yes & Yes & \tr{unsigned char} \\
542 \tr{Int} & Yes & Yes & \tr{long int} \\
543 \tr{Word} & Yes & Yes & \tr{unsigned long int} \\
544 \tr{Addr} & Yes & Yes & \tr{char *} \\
545 \tr{Float} & Yes & Yes & \tr{float} \\
546 \tr{Double} & Yes & Yes & \tr{double} \\
547 \tr{()} & No & Yes & \tr{void} \\
548 \tr{[Char]} & Yes & No & \tr{char *} (null-terminated) \\
550 \tr{Array} & Yes & No & \tr{unsigned long *}\\
551 \tr{ByteArray} & Yes & No & \tr{unsigned long *}\\
552 \tr{MutableArray} & Yes & No & \tr{unsigned long *}\\
553 \tr{MutableByteArray} & Yes & No & \tr{unsigned long *}\\
555 \tr{State} & Yes & Yes & nothing!\\
557 \tr{StablePtr} & Yes & Yes & \tr{unsigned long *}\\
558 \tr{ForeignObjs} & Yes & Yes & see later\\
561 The brave and careful programmer can add their own instances of these
562 classes for the following types:
565 A {\em boxed-primitive} type may be made an instance of both
566 \tr{CCallable} and \tr{CReturnable}.
568 A boxed primitive type is any data type with a
569 single unary constructor with a single primitive argument. For
570 example, the following are all boxed primitive types:
575 data XDisplay = XDisplay Addr#
576 data EFS a = EFS# ForeignObj#
580 instance CCallable (EFS a)
581 instance CReturnable (EFS a)
584 \item Any datatype with a single nullary constructor may be made an
585 instance of \tr{CReturnable}. For example:
589 instance CReturnable MyVoid
592 \item As at version 2.09, \tr{String} (i.e., \tr{[Char]}) is still
593 not a \tr{CReturnable} type.
595 Also, the now-builtin type \tr{PackedString} is neither
596 \tr{CCallable} nor \tr{CReturnable}. (But there are functions in
597 the PackedString interface to let you get at the necessary bits...)
601 The code-generator will complain if you attempt to use \tr{%r}
602 in a \tr{_casm_} whose result type is \tr{IO ()}; or if you don't
603 use \tr{%r} {\em precisely\/} once for any other result type. These
604 messages are supposed to be helpful and catch bugs---please tell us
605 if they wreck your life.
607 \item If you call out to C code which may trigger the Haskell garbage
608 collector (examples of this later...), then you must use the
609 \tr{_ccall_GC_}\index{_ccall_GC_ primitive} or
610 \tr{_casm_GC_}\index{_casm_GC_ primitive} variant of C-calls. (This
611 does not work with the native code generator - use \tr{\fvia-C}.) This
612 stuff is hairy with a capital H! \end{itemize}
614 %************************************************************************
616 \subsection[glasgow-hbc-exts]{``HBC-ish'' extensions implemented by GHC}
617 \index{HBC-like Glasgow extensions}
618 \index{extensions, HBC-like}
620 %************************************************************************
623 %-------------------------------------------------------------------
624 \item[@fromInt@ method in class @Num@:]
625 It's there. Converts from an \tr{Int} to the type.
627 %-------------------------------------------------------------------
628 \item[@toInt@ method in class @Integral@:]
629 Converts from type type to an \tr{Int}.
631 %-------------------------------------------------------------------
632 \item[Overlapping instance declarations:]
633 \index{overlapping instances}
634 \index{instances, overlapping}
636 In \tr{instance <context> => Class (T x1 ... xn)}, the \tr{xi}s can be
637 {\em types}, rather than just {\em type variables}.
639 Thus, you can have an instance \tr{instance Foo [Char]}, as well as
640 the more general \tr{instance Foo [a]}; the former will be used in
641 preference to the latter, where applicable.
643 As Lennart says, ``This is a dubious feature and should not be used
646 See also: \tr{SPECIALIZE instance} pragmas, in \Sectionref{faster}.