- FFI - Haskell.org

FFI Report, CVS Id 1.14
by Manuel M. T. Chakravarty 31 Aug '01

31 Aug '01

I have updated http://www.cse.unsw.edu.au/~chak/haskell/ffi.ps.gz to reflect the recent discussion. It seems so far that the best time to meet at ICFP to discuss the FFI is Tuesday evening. Moreover, Ralf gave us a 10 minute slot at the Haskell Workshop for the FFI. My plan would be to briefly outline where we are to get a discussion going with a wider audience. Cheers, Manuel

1 0

RE: FFI Report, CVS Id 1.11
by Simon Peyton-Jones 31 Aug '01

31 Aug '01

Manuel Excellent stuff. Truly excellent. Simon * I have many small wording suggestions, but I'll just perform them directly. * Still uncontroversial, I found 3.2 to be in a funny order. I'll re-organise it slightly. * I found 4.1 pretty confusing, and I'm an unusually well-informed reader. a) It was some while before I realised that the first entity production is only for foreign *import*. The foreign *export* entity production and its accompanying text is embedded in the middle of a vast swathe of foreign import stuff (both before and after!). Let's have sub-sections! b) Presumably an & import places constraints on the type? Ah! That's what you mean by "static address", and later "imported address". Easy to be confused here. Strong suggestion: give one example of each form in the description-list. c) Explain that if there is no static/dynamic/wrapper, then static is assumed. Mention why "static" exists at all. (To allow entities called wrapper.) * 5.4.2 Talks of "foreign export dynamic". Out of date! * 5.5 I think foreignPtrToPtr had better have an IO type, else you don't quite know when it'll be called,. relative to the touchForeignPtr... Oh-ho! It doesn't matter! If it hasn't been called then the supended call keeps the foreign ptr alive. If it has been called, the touch will keep the foreign ptr alive long enough. Cunning. But worth explaining! * 5.5 description of withForeignPtr. Similarly, should explain a bit about this "not safe" stuff. What we mean is that the foreign ptr may be finalised afer withForeignPtr is done, so the Ptr may be unusable after that -- unless you touch the ForeignPtr afterwards, in which case it's ok.... Careful explanation needed. | > PtrDiff | > ~~~~~~~ ... | Haskell already uses Int for these kinds of lengths: array | indices are mapped to Int, default implementations of list | functions use Int for measuring lengths. | | On 64-bit processors Int is 64-bit (or 63-bit when targeting | OCaml etc.), so the need of handling objects larger than a | gigabyte in 32-bit architectures is temporary, if at all. ... | What about peekArray etc.? It's not clear where to stop. I must say that I rather agree with Marcin here. Let's just use Int (but not Int32!). On machines with big address spaces, Ints will be big. Keep it simple. Oh, and efficient! | ForeignPtr | ~~~~~~~~~~ | | Why do we still allow ForeignPtr as an argument to a foreign | imported function, now that we have withForeignPtr? Is it | just for convenience? If that's the case, it would be | enlightening for the spec to say so (perhaps in a footnote). I agree with this. C Calls ~~~~~ | suggest that the entity string must always be present, but | could be "". I was wondering if there is any real difficulty | in permitting an empty entity string to be omitted | altogether? Makes sense to me, guv. Makes the common case easy for Joe Programmer. | Int and Word | ~~~~~~~~~~~~ | You want to drop the assertion that "arithmetic is performed | modulo 2^n" for sized Int and Word types, on the grounds that | this doesn't hold for Int. But Int is not of fixed size, so | how could it require modulo arithmetic! I happen to think | the fact that Int is of unspecified size >30 bits, with | undefined behaviour on overflow, was something of a mistake | in Haskell. Now that we have the opportunity to define a | sensible overflow behaviour for fixed size types, I think we | should take it. I agree with this.

3 3

RE: FFI Report, CVS Id 1.11
by Simon Marlow 30 Aug '01

30 Aug '01

> Further additions to the FFI > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > IMHO, the FFI should really be self-contained and not rely > on other non-standardised extensions/libraries. Therefore, > I propose some additions. This makes me slightly uneasy because the FFI specification will conflict with the new library specification that is currently evolving. For example, the names of all the modules are different (eg. CForeign -> Foreign.C). Now, the FFI spec is clearly much further along than the library spec, so I don't want to hold it up, but I think it would be useful if we could agree on what direction we want to go. My suggestion is that, since the new library spec will hopefully be adopted by NHC, Hugs and GHC, that the FFI and library proposals may co-exist and agree on the specification of the FFI modules. That means changing the FFI spec at a later date to accomodate the changes made as a result of the library reorganisation. > * I think, we should include the `Bits' module (or something > similar). It is needed, eg, to handle bindings to C > functions that expect bit vectors as arguments. > > * To implement marshalling for foreign imported pure > functions, `unsafePerformIO' is essential. We could add > it to the module `Foreign' or `MarshalUtils'. This raises > the question of whether `unsafeInterleaveIO' falls in the > same category. I think, we should add `unsafePerformIO' > and leave `unsafeInterleaveIO' our as it is less important > for the FFI. ok, but note that there will be some overlap with the library spec. > * I am also not really convinced about > `MarshalUtils.withMany'. There may be situations, where > such a function is handy, but should it really be in the > standard libraries? Moreover, it isn't really marshalling > specific - it is JAFL (Just Another Function on Lists). We can move it to Data.List.withMany in the new library hierarchy. > Names > ~~~~~ > * I don't think `CTypesISO' is a good name. Maybe > `CTypesLib' as it contains the types from the C library > (as opposed to the normal builtin types)? Or put it all > into `CTypes' after all - that doesn't mean GHC (or any > other compiler) has to put it into a single module, just > for the definition. I tend to having one module only. One module is fine with me. I have a couple of other points: ForeignPtr ~~~~~~~~~~ Why do we still allow ForeignPtr as an argument to a foreign imported function, now that we have withForeignPtr? Is it just for convenience? If that's the case, it would be enlightening for the spec to say so (perhaps in a footnote). IOError ~~~~~~~ One thing that bugs me about writing FFI code at the moment is that there isn't a portable way to generate an IOError except through CError.throwErrno and friends. There's also no way to change the info (location, filename, handle) in an existing IOError. This is the single cause of non-portability in a lot of the FFI code I've written recently. Also, we currently can't provide a portable version of CError.hs. I'd like to see something like this: --------- data IOErrorType -- abstract mkIOError :: IOErrorType -> String -> Maybe FilePath -> Maybe Handle -> IOError alreadyExistsError :: IOErrorType alreadyInUseError :: IOErrorType ... addIOErrorLoc :: String -> IO a -> IO a addIOErrorLocAndPath :: String -> FilePath -> IO a -> IO a --------- This doesn't require any more functionality than is already required by Haskell 98 (although perhaps the range of IOErrorType could be expanded somewhat), and it should sit just as well on top of Nhc's implementation of IOErrors as GHC's. Furthermore it would let us provide a portable implementation of CError.hs. The addIOError functions are very useful. Quite often an error is generated by throwErrno in a function which is a long way from the one which the consumer of a library initially called; for example when I get an error from Directory.renameFile I want the error message to say "Directory.renameFile" and contain the filename that I passed to renameFile. So you'd implement renameFile as renameFile file1 file2 = addIOErrorLocAndPath "Directoy.renameFile" file1 $ do ... Cheers, Simon

2 1

FFI Report, CVS Id 1.11
by Manuel M. T. Chakravarty 30 Aug '01

30 Aug '01

Folks, After another teaching-enforced pause, I have continued working at the FFI Report: http://www.cse.unsw.edu.au/~chak/haskell/ffi.ps.gz For C, the report should now be essentially complete (I have included all the libraries). There are, however, still some outstanding issues (see the report and below for the gory details). For all calling conventions other than ccall and stdcall, most is still missing. My plan for driving this further is as follows: * Get all but the most controversial outstanding issues for the language-independent and the C binding fixed until ICFP. * Have a meeting at ICFP to nail any remaining issues in the language-independent and C binding as well as discuss how much we exactly want to do for other calling conventions and how we go about doing it. Could everybody who is coming to ICFP and would like to attend the meeting drop me a note please? Just so that we can fix when to meet. I will be in Florence from Saturday around noon until the following Friday (maybe even Saturday) noon. Cheers, Manuel PS: The source of the document is in cvs.haskell.org and at <http://www.cse.unsw.edu.au/~chak/haskell/ffi.tex>. -=- The Gory Details(TM) -=- I went through all messages on this list that I hadn't responded to yet and either included the suggestions or they are discussed below. "static" keyword ~~~~~~~~~~~~~~~~ Marcin wrote re removing the "static" keyword in C extents, > What the lack of static takes away is the ability to import a function > called "dynamic" or "wrapper". I don't think that it's a big limitation > considering hundreds of names which are taken away by a Haskell's > runtime system. IHMO, it is one thing for an implementation to do that and another for a language definition. > Anyway, we could call them "_dynamic" and "_wrapper" to indicate > that they are magical in some sense - using such names for external > function names would be a violation of ISO/ANSI C rules (they are > reserved for the C implementation). *urgh* I think, that's uglier than having "static". So, I'll stick with static unless there are serious counter arguments. Backward compatibility ~~~~~~~~~~~~~~~~~~~~~~ Malcolm raised the issue of backward compatibility. As I understand it we aren't concerned about the definition actually encompassing the syntax and semantics currently implemented in GHC and NHC, but there is an understanding that those system will allow the "old" syntax for a while after they adopt the standard. NHC's current implementation of "foreign export" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >From the discussion, it seems that NHC simply allows the phrase "foreign export" in front of the normal type signature of a function (as opposed to in addition to that type signature). I never had this in mind and it has always been different in GHC and in Sigbjorn's FFI spec. In fact, being able to have foo :: Num a => a -> a foo = ... foreign export foo :: Int -> Int was always sold as a feature of the system. Further additions to the FFI ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ IMHO, the FFI should really be self-contained and not rely on other non-standardised extensions/libraries. Therefore, I propose some additions. * I think, we should include the `Bits' module (or something similar). It is needed, eg, to handle bindings to C functions that expect bit vectors as arguments. * To implement marshalling for foreign imported pure functions, `unsafePerformIO' is essential. We could add it to the module `Foreign' or `MarshalUtils'. This raises the question of whether `unsafeInterleaveIO' falls in the same category. I think, we should add `unsafePerformIO' and leave `unsafeInterleaveIO' our as it is less important for the FFI. * Why do we only have `Eq' on ForeignPtr, but also `Ord' and `Show' on Ptr? I'll add `Ord' and `Show' to `ForeignPtr' unless their are objections. * Should HsFFI.h include a function like GHC's startupHaskell()? For linking Haskell libraries into foreign code that seems to be necessary. So, I vote for inclusion. Superflous stuff ~~~~~~~~~~~~~~~~ * I am still not convinced that we need `Storable.destruct'. For deallocating special purpose structures that need a deep traversal, shouldn't we just use a custom function? * I am also not really convinced about `MarshalUtils.withMany'. There may be situations, where such a function is handy, but should it really be in the standard libraries? Moreover, it isn't really marshalling specific - it is JAFL (Just Another Function on Lists). Names ~~~~~ * I don't think `CTypesISO' is a good name. Maybe `CTypesLib' as it contains the types from the C library (as opposed to the normal builtin types)? Or put it all into `CTypes' after all - that doesn't mean GHC (or any other compiler) has to put it into a single module, just for the definition. I tend to having one module only. PtrDiff ~~~~~~~ Maybe after all, `PtrDiff' wasn't that bad an idea. To assume that a pointer difference fits into an `Int' (what we do at the moment) is pretty dodgy. Remember that all that H98 requires of an `Int' is that it has >=30 bits. IMHO, this is pretty weak for a general representation of a pointer difference. The annoying thing about our old use of `PtrDiff' was that it made `plusPtr' a pain to use (as we had to cast the offset to a `PtrDiff' first). A simple solution would be plusPtr :: Integral i => Ptr a -> i -> Ptr b I am actually pretty convinced that this is the right way to go. Argument types for foreign functions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ As you can see, I have removed my construction for using `Storable' to specify the types that can be used as arguments to foreign functions. However, I don't agree with the posts claiming that this route would be unworkable. Whenever a type `T' is `Storable', it can be passed to a foreign function in one of two ways: (1) The compiler has special knowledge about the type and just generates the normal (possibly type-dependent) argument passing code. (2) If the compiler has no special knowledge about the type, it `alloca's temporary storage for the type and `poke's the argument into that location. Then, it generates a stub routine in the foreign language that gets a pointer to the temorary storage instead of the actual argument. The stub routine extracts the argument and calls the actual foreign routine. The idea is of course that the compiler (at least if it aspires to generate decent code) has special knowlegde about all the standard types. So, (2) is only the fallback for weird user-defined instances of `Storable'. (+) I like this approach, because it makes the FFI definition nicer. (-) Unfortunately, it is more fuss for the implementation and probably doesn't make a big difference in practice. I have removed it from the report, because "worse is better"[1] (at least that's what some people claim; although it is somewhat against the spirit of Haskell, which tends to put elegance over simplicity of implementation). [1] http://www.jwz.org/doc/worse-is-better.html

3 6

Re: Two questions
by D. Tweed 30 Aug '01

30 Aug '01

META: If one of the main Haskell lists is a better place for than ffi for this discussion, please let me know. Many thanks for the help Alastair. I'll study the Greencard and this code this weekend and see if it looks like a good way to acheive what I'd like to do. In the mean time, a couple of immediate points/questions. On 28 Aug 2001, Alastair David Reid wrote: > You might look at Greencard. Greencard was specifically designed to > let you easily map a C function interface into the corresponding > idiomatic Haskell type. I believe this was _not_ such an important > goal for hdirect. [Other tools (which are being more actively > developed) have the same goal - but I haven't used them so I can't > comment on them.] ATM I'm more interested in the opposite direction: getting informatoin out of a Haskell function which returns a non-abstract, non-primitive data type. > Although Greencard is targetted at C, we (the Yale group) used it with > a C++ visual tracking library. I'm attaching some code to show you > what it looks like because although 'extern "C"' does play a role, > I think it's different from what you're thinking of. > > > Other than being inelegant, is there anything to > > prevent me trying to hack on a stage in the foreign code interface > > stuff that compares the output of `nm' and `nm --demangle' to do > > automatic conversion into mangled-names when there is no overloading > > going on. (I ask this because it would minimise the changes needed > > to the C++ source code to call C++ functions.) > > I don't see a fundamental problem - but it does sound like one of > those projects that is always 90% complete because the last 10% is too > painful to do properly. I'm a bit puzzled here: I've got an object file which, amongst other things contains one function called blockMatchScore16x16Simple. It's the only function of that name (no overloading). If I do the output nm --demangle on the file the only occurrence of that string is in the context of this line: 00000000 T blockMatchScore16x16Simple(int *, int, int, int, unsigned char *, unsigned char *) Equally the only occurence in the straight nm output is 00000000 T blockMatchScore16x16Simple__FPiiiiPUcT4 Doesn't this mean that to make the function calling mechanism work in one of the Haskell ffi's `as is' all that has to be done is change the string blockMatchScore16x16Simple into blockMatchScore16x16Simple__FPiiiiPUcT4. (I suppose a C++ compiler might theoretically be allowed to have a completely different calling convention to the corresponding C one, but I can't imagine it actually happening in practice.) Note that I'm not proposing to do anything for either overloaded or `optional argument' functions, it'd just be nice to be able to avoid a ripple effect when, after changing a function to be extern "C" so that it can be called from Haskell any object file containing a call to that function has to be recompiled. And then recompiled again when I finish the prototyping and take away the extern "C" (Cf. my .signature :-) ). [snip] > 5) The system this was used in was described in our ICSE'99 paper: > > http://www.cs.utah.edu/~reid/icse99.ps.gz Yes it was reading this paper recently which prompted me to think again about trying to integrate Haskell prototyping with the C++ code. However, that paper seems to tackle the problem of building applications (more especially the control logic) from well understood and implemented low-level, compute-intensive primitives in C++. I'm thinking more about the situation where you're actively researching new low-level primitives and it'd be nice to be able to try out ideas for new low-level stuff quickly in haskell. A good example which has happened recently is formulating an objective function over a long vector which the plan is to minimise by `annealing' using the partial derivatives; many times the definition may have multiple local minima which prevent convergence to the `correct' answer, and this property is often quite sensitive to the exact form of the objective function. It'd be nice to be able to experiment with this in a language with garbage collection, local lambda functions, list comprehensions, etc. However, if the algorithm looks promising it'll be translated into the C++ part of the program for quickest execution. By contrast, the control-logic parts of my programs are relatively simple. To be more concrete what I'd like to be able to do without too much work setting up each new case is C++ ----------> Haskell | C++ function <------ (The re-entrant call into C++ is for simple calls to simple numerical functions, say gaussian_err(float *mean,float **covar,float *x) which could be defined in Haskell without any problems but I'd just like to minimise the duplication because each duplication allows the possibilities of typos.) Whilst the C++ side does have all the weird (and wonderful aspects) of C++ like objects, overloading, etc, I don't see that it'd be particularly useful for what I want to get done to move them to across the language border; i.e., I'm basically thinking about interfacing to C functions, except compiled with a C++ compiler. Many thanks for any illumination anyone can shed on this, ___cheers,_dave________________________________________________________ www.cs.bris.ac.uk/~tweed/pi.htm |tweed's law: however many computers email: tweed(a)cs.bris.ac.uk | you have, half your time is spent work tel: (0117) 954-5250 | waiting for compilations to finish.

2 1

Two questions
by D. Tweed 28 Aug '01

28 Aug '01

Hi, could anyone help me with some answers and/or some recommendations about what to read (hopefully at a higher level than the source code :-) ) to get the answers to the following questions (I've read the current ffi & hdirect documentation & examples and ffi-list archives but couldn't find anything to answer these questions): (1) The hdirect documentation appears to say that anything other than a primitive type can only be returned as an abstract datatype. If this is correct, is there any common way people have come up with to tackle returns of datatypes (primarily lists) to some sort of datastructure that can be examined directly in C (well, C++)? (2) Regarding calling C++ from Haskell, is it correct that all functions being called have to be `extern C' because of C++-name-mangling? Other than being inelegant, is there anything to prevent me trying to hack on a stage in the foreign code interface stuff that compares the output of `nm' and `nm --demangle' to do automatic conversion into mangled-names when there is no overloading going on. (I ask this because it would minimise the changes needed to the C++ source code to call C++ functions.) To explain these questions, I'm interested in being able to use Haskell more aggressively in developing prototype code (for visual analysis). At present I write small independent Haskell scripts that test an algorithm using synthetic test data; I'm looking at being able to call Haskell prototype code directly from the main C++ application. (This would have the advantage of being able to run the prototype code on real data generated by the preceding C++ code.) Thus, unlike most of the FFI stuff I see talked about in the documentation (which describes situations where one of the sets of source code is essentially stable), the source code in _both_ languages is extremely changeable. My interest in `low programmer-overhead interfacing' is that my job is currently `image processing' and nothing else; consequently if it takes more time working with the interfacing tools than is saved by easier prototyping in haskell I can't justify doing it. Many thanks of any assistance anyone is able to provide, ___cheers,_dave________________________________________________________ www.cs.bris.ac.uk/~tweed/pi.htm |tweed's law: however many computers email: tweed(a)cs.bris.ac.uk | you have, half your time is spent work tel: (0117) 954-5250 | waiting for compilations to finish.

1 0

Re: FFI Report, CVS Id 1.11
by Marcin 'Qrczak' Kowalczyk 25 Aug '01

25 Aug '01

24 Aug 2001 12:20:41 -0600, Alastair David Reid <reid(a)cs.utah.edu> pisze: > Let's add some asserts to the affected code so that we'll get warnings > when we try to compile the code on a system that breaks these assumptions. > Something like this: > > #if SIZEOF_INT != SIZEOF_PTR > #error "Pointer difference operation could overflow - please fix" > #endif In ghc Int always has the same size as the pointer. Or did you mean something other? -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Re: FFI Report, CVS Id 1.11
by cwitty＠newtonlabs.com 24 Aug '01

24 Aug '01

"Manuel M. T. Chakravarty" <chak(a)cse.unsw.edu.au> writes: > Array and list indicies are quite different beats from > pointer differences. To get into a problem with array > indicies, we would need an array (and thus, heap) that is > big enough to requires such an index. In contrast, pointers > are not constrained be point into the heap. For, example > with mmap(), I can easily get two pointers that are much > further apart than what would fit into the real (even the > virtual) memory of the concrete hardware. In other words, > in x86 Linux, your address space is already 3GB. We don't > need any new fancy hardware for 30 bit pointer differences > to have the potential to get us into trouble. Why would you want to take the difference of two pointers that point into different objects? Carl Witty

2 1

Re: FFI Report, CVS Id 1.11
by Marcin 'Qrczak' Kowalczyk 23 Aug '01

23 Aug '01

Sun, 19 Aug 2001 23:14:59 +1000, Manuel M. T. Chakravarty <chak(a)cse.unsw.edu.au> pisze: > * I am still not convinced that we need > `Storable.destruct'. For deallocating special purpose > structures that need a deep traversal, shouldn't we just > use a custom function? Without destruct code like with haskellValue $ \ptr -> do just use ptr, no allocation nor deallocation would be correct in 99% of cases, except that for some types it leaks memory (when the only reasonable implementation of poke is not idempotent wrt. allocated memory). These cases include char* inside a struct, assumed to point to a memory private to this struct. Yes, it can be called by hand, just as C++ destructors could be called by hand. But places where it should be called are automatically predictable, as long as it is well defined which memory is initialized and which is not. Since with* functions automatically call poke, they should automatically call something which undoes side effects of poke. You might avoid Storable instances for such types and only use opaque ForeignPtrs to heap-allocated objects. In this case, if all the allocation and deallocation is handled by foreign code, destruct is not needed. It makes sense however for more complex types which are made instances of Storable, i.e. where memory allocation is done by Haskell. I imagine that allocation in Haskell will be especially good idea now when Simon Marlow made alloca faster than malloc. A Haskell-C++ interfacing tool would hook destructors to destruct. > * I am also not really convinced about > `MarshalUtils.withMany'. There may be situations, where > such a function is handy, but should it really be in the > standard libraries? It's not so easily written by hand. Explicit recursion is needed, AFAIK it can't be simply written in terms of foldr, mapM etc. So it requires a variable definition, and thus would be written in this very form where needed, instead of "inlined". It's the mapM of the continuation monad, where the monad is /\a. (a -> res) -> res and thus can't be made instance of class Monad without wrapping in a newtype. FFI uses the "(a -> IO b) -> IO b" type pattern much. > Moreover, it isn't really marshalling specific - it is JAFL > (Just Another Function on Lists). Yes, but it's not available elsewhere. > PtrDiff > ~~~~~~~ > Maybe after all, `PtrDiff' wasn't that bad an idea. To > assume that a pointer difference fits into an `Int' (what we > do at the moment) is pretty dodgy. Remember that all that > H98 requires of an `Int' is that it has >=30 bits. IMHO, > this is pretty weak for a general representation of a > pointer difference. Haskell already uses Int for these kinds of lengths: array indices are mapped to Int, default implementations of list functions use Int for measuring lengths. On 64-bit processors Int is 64-bit (or 63-bit when targeting OCaml etc.), so the need of handling objects larger than a gigabyte in 32-bit architectures is temporary, if at all. Haskell has the advantage over C that there is no temptation to express all sized integer types as {char,short,int,long}, so there is no reason for Int to be too small. On 32-bit processors C implementations generally don't allow objects larger than 32 bits anyway. > The annoying thing about our old use of `PtrDiff' was that > it made `plusPtr' a pain to use (as we had to cast the > offset to a `PtrDiff' first). A simple solution would be > > plusPtr :: Integral i => Ptr a -> i -> Ptr b It would make "ptr `plusPtr` 1" use Integer by default (with a warning with -Wall). What about peekArray etc.? It's not clear where to stop. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

2 1

UnsafeCString
by Simon Marlow 10 Aug '01

10 Aug '01

As of yesterday, GHC's implementation of MarshalAlloc.allocaBytes is now based on ByteArrays, and is much faster. Since this effectively removes the reason for having UnsafeCString, and since there was some objection to it in the first place, I propose to remove it. Any objections? Cheers, Simon

2 1