- Glasgow-haskell-users

RE: problems with FFI including h files
by Simon Marlow 03 Jun '02

03 Jun '02

> Sad, but very true! And GHC's headers are not very nice in > this respect: > > panne@jeanluc:~> grep '#define [^ \t][^ \t] ' > /usr/lib/ghc-5.03/include/* > /usr/lib/ghc-5.03/include/PrimOps.h:#define C 0 > /usr/lib/ghc-5.03/include/PrimOps.h:#define R 1 > /usr/lib/ghc-5.03/include/PrimOps.h:#define C 1 > /usr/lib/ghc-5.03/include/PrimOps.h:#define R 0 Yikes! Fixed, thanks. > panne@jeanluc:~> grep '#define [^ \t][^ \t] ' > /usr/lib/ghc-5.03/include/* > /usr/lib/ghc-5.03/include/Regs.h:#define R1 (BaseReg->rR1) > /usr/lib/ghc-5.03/include/Regs.h:#define R2 (BaseReg->rR2) > /usr/lib/ghc-5.03/include/Regs.h:#define F1 (BaseReg->rF1) > /usr/lib/ghc-5.03/include/Regs.h:#define F2 (BaseReg->rF2) > /usr/lib/ghc-5.03/include/Regs.h:#define F3 (BaseReg->rF3) > /usr/lib/ghc-5.03/include/Regs.h:#define F4 (BaseReg->rF4) > /usr/lib/ghc-5.03/include/Regs.h:#define D1 (BaseReg->rD1) > /usr/lib/ghc-5.03/include/Regs.h:#define D2 (BaseReg->rD2) > /usr/lib/ghc-5.03/include/Regs.h:#define L1 (BaseReg->rL1) > /usr/lib/ghc-5.03/include/Regs.h:#define Sp (BaseReg->rSp) > /usr/lib/ghc-5.03/include/Regs.h:#define Su (BaseReg->rSu) > /usr/lib/ghc-5.03/include/Regs.h:#define Hp (BaseReg->rHp) > > And so on... > > SimonM: What about a "poor man's" namespace, i.e. prefixing > every macro, > type, etc. with "GHC"/"ghc"? OpenGL, GLUT, GTK, etc. do a > similar thing, > and although it's a primitive measure, it's very effective. We really *should* do this, I know. The problem is that it isn't free by a long shot: it'll make .hc files significantly larger, and obfuscate a lot of code. Anyone have any ideas that don't have such a big impact? Cheers, Simon

3 2

RE: monomorphism/hugs98/ghc-5.02.3
by Simon Marlow 03 Jun '02

03 Jun '02

> However, in ghc-5.02.3 for Haskell 98 (without glasgow extensions) it > seems that is not the case. I _guessed_ that I need to use the flag > -fno-monomorphism-restriction > but I don't know whether I've failed to turn it on or if the > problem is to be found somewhere else. A related problem I've found > is that if I try to specify that flag in a pragma, I get an error > message stating that static flags may not be specified in pragmas, > and yet the flag is supposed to be dynamic. -fno-monomorphism-restriction was a static flag by mistake. The bugfix will be in 5.04. Cheers, Simon

1 0

Efficient UArray dot-product?
by Mike Gunter 03 Jun '02

03 Jun '02

Is it possible to write an dot-product function that GHC will compile to efficient code without using unsafeAt? I've tried and can't. I'm looking at generic IArray functions pragma-specialized to UArray Int Double. With unsafeAt the -ddump-simpl output looks optimal to me (aside from not unrolling or pipelining**): loop i s | i > ubSI = s | otherwise = let s' = s + (small `unsafeAt` i) * (big `unsafeAt` (off + i)) in seq s' $ loop (i + 1) s' compiles to $wloop = \ ww12 L :: PrelGHC.Int# ww13 L :: PrelGHC.Double# -> case PrelGHC.># ww12 ww9 of wild3 L { PrelBase.True -> PrelFloat.$wD# ww13; PrelBase.False -> $wloop (PrelGHC.+# ww12 1) (PrelGHC.+## ww13 (PrelGHC.*## (PrelGHC.indexDoubleArray# ww2 ww12) (PrelGHC.indexDoubleArray# ww6 (PrelGHC.+# a2 ww12)))) }; } in Without it (i.e. with (!)) the compiler will only use primitive arithmetic for addressing one of the arrays. Why? Is there a way to write dot-product that produces good code without resorting to unsafeAt? thanks, mike ** Pipelining probably isn't going to be worth your time in so far as you're targeting processors with dynamic scheduling. They'll pipeline things for you.

2 1

Dynamic types: GHCI works, GHC doesn't?
by Andre Pang 02 Jun '02

02 Jun '02

Hi all, I'm trying to get a grip on the Dynamic types stuff supplied with GHC, and I'm not sure if I'm doing something wrong, or whether I've found a bug. It seems that the fromDynamic and fromDyn functions seem to work if you load your module into GHCI, but they don't work when you compile it into a stand-alone executable with GHC. Here's an example of what the output is meant to be like: 22:51(0) .../project/dynamic_types-bug% ghci -package lang DynamicTypesBug.hs [ GHCI header deleted ] Loading package std ... linking ... done. Loading package lang ... linking ... done. Compiling Main ( DynamicTypesBug.hs, interpreted ) Ok, modules loaded: Main. Main> main Static type: FootnoteData [Char] Int Coerced (dynamic) type: FootnoteData [Char] Int Does dynamic type == static type? True Attempting to run fromDynamic on the dynamic type ... 5. This be the footnote Main> So, that all works fine. Compile it through GHC, however, and this happens: 22:57(0) .../project/dynamic_types-bug% ghc --make -package lang DynamicTypesBug.hs ghc-5.02.2: chasing modules from: DynamicTypesBug.hs Compiling Main ( DynamicTypesBug.hs, ./DynamicTypesBug.o ) ghc: linking ... 22:57(0) .../project/dynamic_types-bug% ./a.out Static type: FootnoteData [Char] Int Coerced (dynamic) type: FootnoteData [Char] Int Does dynamic type == static type? False Attempting to run fromDynamic on the dynamic type ... Fail: Maybe.fromJust: Nothing Furthermore, if you compile it with GHC, then run GHCI afterward, GHCI will use the Main.o object file rather than try to compile it again, and will fail: 22:58(1) .../project/dynamic_types-bug% ghci -package lang DynamicTypesBug.hs [ GHCI header deleted ] Loading package std ... linking ... done. Loading package lang ... linking ... done. Skipping Main ( DynamicTypesBug.hs, ./DynamicTypesBug.o ) Ok, modules loaded: Main. Main> main Static type: FootnoteData [Char] Int Coerced (dynamic) type: FootnoteData [Char] Int Does dynamic type == static type? False Attempting to run fromDynamic on the dynamic type ... *** Exception: Maybe.fromJust: Nothing Main> I've seen this behaviour with: * ghc-5.02.2 from the Debian ghc5 package * ghc-5.02.1 on another Linux machine (compiled from source) * ghc-5.03.20020204 snapshot on Windows (Sigbjorne's MSI package) It's possible that I'm not using the Dynamic module functions properly, since I don't think I understand them that well. In particular, I'm a bit confused as to how to construct a TypeRep with the mkAppTy function. See my code to see how I'm (mis)using it :). The code which exhibits this behaviour is attached to this message (DynamicTypesBug.hs). Hopefully I'm just doing something silly ... -- #ozone/algorithm <ozone(a)algorithm.com.au> - trust.in.love.to.save

4 4

Re: Dynamic types: GHCI works, GHC doesn't?
by Andre Pang 01 Jun '02

01 Jun '02

On Sat, Jun 01, 2002 at 11:01:57PM +1000, Andre Pang wrote: > It seems that the fromDynamic and fromDyn functions seem to work > if you load your module into GHCI, but they don't work when you > compile it into a stand-alone executable with GHC. .. unless you compile it with -O2: 23:18(0) .../project/dynamic_types-bug% ghc --make -package lang -O2 DynamicTypesBug.hs ghc-5.02.2: chasing modules from: DynamicTypesBug.hs Compiling Main ( DynamicTypesBug.hs, ./DynamicTypesBug.o ) ghc: linking ... 23:18(0) .../project/dynamic_types-bug% ./a.out Static type: FootnoteData [Char] Int Coerced (dynamic) type: FootnoteData [Char] Int Does dynamic type == static type? True Attempting to run fromDynamic on the dynamic type ... 5. This be the footnote Weird. It also seems to work with -O1. I should note that I observed the buggy GHC behaviour with -fvia-c as well, regardless of whether gcc-2.95 or gcc-3.1 was used. Putting -O0 on the GHC commandline, or omitting the -O option altogether, appears to trigger the bug. This doesn't happen with GHCI (i.e. 'ghci -O0' seems to work). -- #ozone/algorithm <andrep(a)cse.unsw.EDU.AU> - b.sc (comp. sci+psych)

1 0

problems with FFI including h files
by Hal Daume III 01 Jun '02

01 Jun '02

Hi all! I'm hoping someone with more FFI experience than me (pretty much anyone who's done anything with FFI) can help me out. Basically, I'm trying to include an h file and gcc is telling me that there are parse errors in it. However, when I write a c program that includes that h file, it don't get such errors. Here is an example C program: 12:52pm moussor:ATLAS/ cat TestAtlas.c #include "cblas.h" int main() { double x = cblas_ddot(0,0,0,0,0); } And, I can compile it: 1:39pm moussor:ATLAS/ /nfs/isd/hdaume/bin/gcc TestAtlas.c -B/nfs/isd/hdaume/download/ATLAS -L/nfs/isd/hdaume/download/ATLAS/lib/SunOS_SunUS2 -llapack -lcblas -lf77blas -latlas 1:39pm moussor:ATLAS/ ./a.out 1:39pm moussor:ATLAS/ The h file I'm including, "cblas.h" is located in /nfs/isd/hdaume/download/ATLAS/include and all the libraries are the the specified lib directory (though those aren't really relevant at this point). Moving on to the haskell side of things, I have a module: 1:37pm moussor:~/projects/ cat HBlas/Level1GC2.hs {-# OPTIONS -#include "cblas.h" #-} -- run with: module HBlas.Level1GC2 where 1:41pm moussor:~/projects/ that contains no definitions (obviously my real one has definitions, but it makes no difference at this point). so, i try to compile with ghc using: ghco HBlas/Level1GC2.hs -cpp -L/nfs/isd/hdaume/download/ATLAS/lib/SunOS_SunUS2 -llapack -lcblas -lf77blas -latlas -iHBlas -pgmc/nfs/isd/hdaume/bin/gcc -optc-B/nfs/isd/hdaume/download/ATLAS so, basically, i'm including the same -L and -B directives to gcc, using the same version of gcc (3.1), same libraries and everything but now it complains and says: Compiling HBlas.Level1GC2 ( HBlas/Level1GC2.hs, HBlas/Level1GC2.sun4.o ) In file included from /tmp/ghc3741.hc:7: /nfs/isd/hdaume/download/ATLAS/include/cblas.h:444: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:449: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:453: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:458: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:474: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:479: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:483: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:488: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:504: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:509: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:513: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:518: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:534: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:539: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:543: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:548: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:568: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:572: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:577: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:582: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:586: parse error before numeric constant /nfs/isd/hdaume/download/ATLAS/include/cblas.h:591: parse error before numeric constant if I look at cblas.h, line 444 is the last line of this definition: void cblas_sgemm(const enum CBLAS_ORDER Order, const enum CBLAS_TRANSPOSE TransA, const enum CBLAS_TRANSPOSE TransB, const int M, const int N, const int K, const float alpha, const float *A, const int lda, const float *B, const int ldb, const float beta, float *C, const int ldc); i really have *no* idea what's going on. if i compile the c and the haskell with -v, the lines leading up to the errors on the haskell side read: *** C Compiler /nfs/isd/hdaume/bin/gcc -x c /tmp/ghc3749.hc -o /tmp/ghc3749.raw_s -w -v -S -Wimplicit -O -D__GLASGOW_HASKELL__=502 -B/nfs/isd/hdaume/download/ATLAS -ffloat-store -I . -I /nfs/isd/hdaume/lib/ghc-5.02.3/include Reading specs from /nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1/specs Configured with: /nfs/isd/hdaume/download/gcc-3.1/configure --prefix=/nfs/isd/hdaume --with-cpu=ultrasparc --enable-languages=c,c++,f77,java Thread model: posix gcc version 3.1 /nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1/cc1 -lang-c -v -I . -I /nfs/isd/hdaume/lib/ghc-5.02.3/include -isystem /nfs/isd/hdaume/download/ATLAS/include -D__GNUC__=3 -D__GNUC_MINOR__=1 -D__GNUC_PATCHLEVEL__=0 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc -D__sun -D__unix -Asystem=unix -Asystem=svr4 -D__OPTIMIZE__ -D__STDC_HOSTED__=1 -D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int -D__WCHAR_TYPE__=long int -D__WINT_TYPE__=long int -D__GCC_NEW_VARARGS__ -Acpu=sparc -Amachine=sparc -D__GLASGOW_HASKELL__=502 /tmp/ghc3749.hc -quiet -dumpbase ghc3749.hc -O -Wimplicit -w -version -ffloat-store -o /tmp/ghc3749.raw_s GNU CPP version 3.1 (cpplib) (sparc ELF) GNU C version 3.1 (sparc-sun-solaris2.8) compiled by GNU C version 2.95.2 19991024 (release). ignoring nonexistent directory "/nfs/isd/hdaume/sparc-sun-solaris2.8/include" #include "..." search starts here: #include <...> search starts here: . /nfs/isd/hdaume/lib/ghc-5.02.3/include /nfs/isd/hdaume/download/ATLAS/include /usr/local/include /nfs/isd/hdaume/include /nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1/include /usr/include End of search list. In file included from /tmp/ghc3749.hc:7: /nfs/isd/hdaume/download/ATLAS/include/cblas.h:444: parse error before numeric constant and the entire transcript of just compiling the c program with gcc is: 1:41pm moussor:ATLAS/ /nfs/isd/hdaume/bin/gcc TestAtlas.c -B/nfs/isd/hdaume/download/ATLAS -L/nfs/isd/hdaume/download/ATLAS/lib/SunOS_SunUS2 -llapack -lcblas -lf77blas -latlas -v Reading specs from /nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1/specs Configured with: /nfs/isd/hdaume/download/gcc-3.1/configure --prefix=/nfs/isd/hdaume --with-cpu=ultrasparc --enable-languages=c,c++,f77,java Thread model: posix gcc version 3.1 /nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1/cc1 -lang-c -v -isystem /nfs/isd/hdaume/download/ATLAS/include -D__GNUC__=3 -D__GNUC_MINOR__=1 -D__GNUC_PATCHLEVEL__=0 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc -D__sun -D__unix -Asystem=unix -Asystem=svr4 -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int -D__WCHAR_TYPE__=long int -D__WINT_TYPE__=long int -D__GCC_NEW_VARARGS__ -Acpu=sparc -Amachine=sparc TestAtlas.c -quiet -dumpbase TestAtlas.c -version -o /var/tmp//cc1I7kU6.s GNU CPP version 3.1 (cpplib) (sparc ELF) GNU C version 3.1 (sparc-sun-solaris2.8) compiled by GNU C version 2.95.2 19991024 (release). ignoring nonexistent directory "/nfs/isd/hdaume/sparc-sun-solaris2.8/include" #include "..." search starts here: #include <...> search starts here: /nfs/isd/hdaume/download/ATLAS/include /usr/local/include /nfs/isd/hdaume/include /nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1/include /usr/include End of search list. /usr/ccs/bin/as -V -Qy -s -xarch=v8plusa -o /var/tmp//cc1wEdD7.o /var/tmp//cc1I7kU6.s /usr/ccs/bin/as: Sun WorkShop 6 99/08/18 /nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1/collect2 -V -Y P,/usr/ccs/lib:/usr/lib -Qy /nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1/crt1.o /nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1/crti.o /usr/ccs/lib/values-Xa.o /nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1/crtbegin.o -L/nfs/isd/hdaume/download/ATLAS/lib/SunOS_SunUS2 -L/nfs/isd/hdaume/download/ATLAS -L/nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1 -L/usr/ccs/bin -L/usr/ccs/lib -L/nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1/../../.. /var/tmp//cc1wEdD7.o -llapack -lcblas -lf77blas -latlas -lgcc -lgcc_eh -lc -lgcc -lgcc_eh -lc /nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1/crtend.o /nfs/isd/hdaume/lib/gcc-lib/sparc-sun-solaris2.8/3.1/crtn.o ld: Software Generation Utilities - Solaris-ELF (4.0) so yeah, i'm completely at a loss here. i really don't know very much about gcc and why it would be doing this; i notice there are a few command line options passed to cc1 in the haskell version that don't exist on the c side. to make sure it wasn't a problem with the .hc extension, i renamed TestAtlas.c to TestAtlas.hc and compiled with "gcc -x c TestAtlas.hc ..." and the rest the same and it still works fine. please please please help :) thanks! - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

4 6

Re: monomorphism/hugs98/ghc-5.02.3
by Matt Fairtlough 31 May '02

31 May '02

Thanks a lot for the solution! And of course the ghci behaviour is much more sensible than the hugs one. And for pointing me to the mail archive. It encourages me to submit my next problem: stack overflow with simple Show instances...more later I wonder if there is a list of Hugs to GHCI "gotchas"? Matt. --------------------------------------------------------------------------- Matt Fairtlough m.fairtlough(a)dcs.shef.ac.uk Verification and Testing Group Room 115 Department of Computer Science University of Sheffield Regent Court, 211 Portobello Street Sheffield S1 4DP Tel: (0)114-22-21826 UK Fax: (0)114-22-21810 WWW: http://www.dcs.shef.ac.uk/~matt/ ----------------------------------------------------------------------------

3 2

Re: monomorphism/hugs98/ghc-5.02.3
by Matt Fairtlough 31 May '02

31 May '02

Hmm. It might be related but I somehow doubt it. The buggy program is ------------------------------------------ module Bug2 where data Bug2 = Bug2 instance Show Bug2 where showsPrec _ Bug2 str = showChar '?' str ------------------------------------------ (stack overflow on Bug2> Bug2) and the fix is ------------------------------------------ module Bug2 where data Bug2 = Bug2 instance Show Bug2 where showsPrec _ Bug2 str = showChar '?' str ------------------------------------------ -- an indentation problem. Quite why globally redefining showsPrec produces a stack overflow when showing Bug2 values I'll have to leave to the experts. --------------------------------------------------------------------------- Matt Fairtlough m.fairtlough(a)dcs.shef.ac.uk Verification and Testing Group Room 115 Department of Computer Science University of Sheffield Regent Court, 211 Portobello Street Sheffield S1 4DP Tel: (0)114-22-21826 UK Fax: (0)114-22-21810 WWW: http://www.dcs.shef.ac.uk/~matt/ ----------------------------------------------------------------------------

1 0

instance Show (Ptr a)
by Hal Daume III 31 May '02

31 May '02

The GHC docs claim Ptr a is an instance of Eq, Ord and Show, but it doesn't actually seem to have a Show instance. At least the docs should reflect the fact that there is not instance; preferably, could someone actually make an instance? It would be nice (primarily for debugging purposes) to be able to see where the allocations from malloc, newArray, etc took place. - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

2 1

monomorphism/hugs98/ghc-5.02.3
by Matt Fairtlough 31 May '02

31 May '02

Hello Haskellers, I've just joined this email group because I am teaching Haskell to our 2nd year students. I'm not a Haskell expert but I do enjoy functional programming. I don't know if anyone can help with this; I've checked the FAQs and the bug-reports on SourceForge and found nothing but I'd have thought it might be a common problem for folks migrating from hugs to ghci. I'm used to using hugs in haskell 98 mode but it seems that functions need not be monomorphic in where clauses in that case (is this a departure from the standard?). However, in ghc-5.02.3 for Haskell 98 (without glasgow extensions) it seems that is not the case. I _guessed_ that I need to use the flag -fno-monomorphism-restriction but I don't know whether I've failed to turn it on or if the problem is to be found somewhere else. A related problem I've found is that if I try to specify that flag in a pragma, I get an error message stating that static flags may not be specified in pragmas, and yet the flag is supposed to be dynamic. Here is a simple instance of a program that runs under Hugs but not ghc(i)-5.02.3 : module Test where class Bounded a => Testit a where test1 :: a data Test a = Test {f1::[a], f2::[Char]} class Super a where sup1 :: a -> Maybe a instance (Eq a, Testit a) => Super (Test a) where sup1 (Test{f1=x, f2=y}) = Just Test{f1=x, f2=y} where y' = top y x' = top x top :: [a] -> a top (s:st) = s is it possible to compile this program in ghc-5.02.3? Any advice much appreciated, Matt. --------------------------------------------------------------------------- Matt Fairtlough m.fairtlough(a)dcs.shef.ac.uk Verification and Testing Group Room 115 Department of Computer Science University of Sheffield Regent Court, 211 Portobello Street Sheffield S1 4DP Tel: (0)114-22-21826 UK Fax: (0)114-22-21810 WWW: http://www.dcs.shef.ac.uk/~matt/ ----------------------------------------------------------------------------

2 1