- Glasgow-haskell-users

RE: unterminated {-
by Simon Marlow 26 Sep '01

26 Sep '01

> Seems to me it would make more sense for the message > XXXX.hs:214: unterminated `{-' > message to tell me where the {- is, rather than where the EOF is. Thanks, I've fixed the error message. Cheers, Simon

1 0

Cash Prize Win!
by Darren Middleton 25 Sep '01

25 Sep '01

To all our fans!! Welsh Fantasy Football has paid your entrance fee to the WELSH FANTASY FOOTBALL GAME 2001. Go to www.welshfantasyfootball.com to register a free team! You have to be in it to WIN it!!

1 0

Re: 5.02: windows installation glitches
by Marcin 'Qrczak' Kowalczyk 24 Sep '01

24 Sep '01

Mon, 24 Sep 2001 13:10:59 +0100, Reuben Thomas <rrt(a)dcs.gla.ac.uk> pisze: >> 1. Manual suggests installing ghc in directory without spaces in the >> name; yet the default one is named "Glasgow Haskell Compiler". > > The manual is wrong. AFAIK it's simply outdated; this used to be a problem. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

5.02: windows installation glitches
by Roman Belenov 24 Sep '01

24 Sep '01

1. Manual suggests installing ghc in directory without spaces in the name; yet the default one is named "Glasgow Haskell Compiler". 2. Table of contents in the manual contains ?? instead of page numbers as though TeX was not run enough times during build. -- With regards, Roman.

2 2

Re: Ptr and ForeignPtr Questions
by Ashley Yakeley 24 Sep '01

24 Sep '01

At 2001-09-23 23:12, Manuel M. T. Chakravarty wrote: >> I was just hoping for GHC to be able to spit out headers for 'foreign >> import' functions that the user could then define. This merely means a >> map from some restricted set of Haskell function types to C types. > >Functionality like that is not part of the FFI. However, it >would surely be possible to write an extra tool that >accomplishes just what you want. (It was a general design >rule to avoid in the basic FFI features that would be >complicated to define/implement and can as easily be >implemented by a tool.) Right. This would be very similar to the 'javah' tool used in the Java world. That works on compiled .class files, I suppose the equivalent would be a module that "plugged in" to the GHC "motherboard". >Moreover, the case where you bind to existing C functions is >much more common than where you bind to C functions that you >have written yourself. Right, but it's a more ambitious goal for the FFI designer, at least if they want to do it completely. As you point out, there are restrictions on just what existing C functions you can bind to. If your function looks like this: const char* foo (struct SomeLinkedList*); ...you have no choice but to write 'impedance-matching' code for that function. >structs are not allowed as arguments to foreign imported >functions. Exactly! And neither are const pointers. But argument const-ness, at least, can be safely ignored. -- Ashley Yakeley, Seattle WA

1 0

Re: Ptr and ForeignPtr Questions
by Ashley Yakeley 24 Sep '01

24 Sep '01

At 2001-09-23 19:14, Manuel M. T. Chakravarty wrote: >Hmm, we must be misunderstanding each other. Given that you >have > > foreign import strcat :: Ptr CChar -> Ptr CChar -> IO (Ptr CChar) > >How do you want to know whether the C prototype is > > char *strcat(char *dest, const char *src); > >or > > char *strcat(char *dest, char *src); I was just hoping for GHC to be able to spit out headers for 'foreign import' functions that the user could then define. This merely means a map from some restricted set of Haskell function types to C types. But it looks like you want to be able to arbitrarily import any C library function. Of course this means a map from C functions to Haskell functions. In the case you gave Haskell could get away with calling strcat using this: char* strcat(char*,char*); ...even if the function had actually been defined like this: char* strcat(char*,const char*); This is quite safe from a 'const' point of view. More difficult is this: const char* foo() { return "hello"; } ...since the best the FFI can do is this: foreign import foo :: IO (Ptr CChar) ...which is certainly _not_ const-safe. Perhaps one could have ConstPtrs, which didn't allow writes, and allow those in FFI. At 2001-09-23 19:21, Manuel M. T. Chakravarty wrote: >If you are writing a Haskell binding to a large C library >that has hundreds of functions, it is extremely unattractive >to write "impedance matchers" like `MyModule__StringCopy' >manually. I'm taking an approach similar to JNI, in which the user defines in C what has been declared in Haskell. But what you want to do is to allow the user to declare in Haskell what has been defined in C, obviously a more ambitious goal. Const pointers are not your only worry; how would you deal with structs? -- Ashley Yakeley, Seattle WA

2 1

Re: Ptr and ForeignPtr Questions
by Ashley Yakeley 24 Sep '01

24 Sep '01

At 2001-09-23 04:04, Marcin 'Qrczak' Kowalczyk wrote: >It would be impossible then to directly call a C function with a >parameter declared as a const pointer. It's illegal in C to have >mismatching prototypes of the same function. You can always do this: module MyModule where { foreign import StringCopy :: Ptr Int8 -> Ptr Int8 -> IO (); } which autogenerates this header: extern "C" { void MyModule__StringCopy(signed char* a,signed char* b); } which the user can implement like this: char* strcat(char* dest, const char* src); void MyModule__StringCopy(char* dest,char* src) { strcat(dest,src); } (assuming char and signed char are identical). -- Ashley Yakeley, Seattle WA

2 1

Re: Ptr and ForeignPtr Questions
by Ashley Yakeley 24 Sep '01

24 Sep '01

At 2001-09-23 04:02, Manuel M. T. Chakravarty wrote: >> I would assume that Ptr types would always be mapped to non-const >> pointers. Do you have an example of a Haskell type for a foreign import >> function, for which the corresponding C function type would be ambiguous? > >Take, for example, the following excerpt of the Linux man >pages But do you have an example of a Haskell type for a foreign import function, for which the corresponding C function type would be ambiguous? At 2001-09-21 02:20, Manuel M. T. Chakravarty wrote: >One could attempt to generate C prototypes from the Haskell >type declarations or similar things, btu it doesn't work >out. Surely one can still do this? This was what we were discussing, was it not? A C type for any given Haskell function type, not necessarily the other way around... -- Ashley Yakeley, Seattle WA

2 1

Re: Ptr and ForeignPtr Questions
by Ashley Yakeley 23 Sep '01

23 Sep '01

At 2001-09-23 15:56, Marcin 'Qrczak' Kowalczyk wrote: >> But do you have an example of a Haskell type for a foreign import >> function, for which the corresponding C function type would be ambiguous? > >Ptr CChar (as an argument). It could be either char * or const char *. It's always char*. A Haskell function passed a Ptr CChar is not prevented from modifying the contents of the pointer simply due to its type-declaration. In C, a char* can be implicitly converted to a const char* where necessary (but not the other way around). -- Ashley Yakeley, Seattle WA

1 0

Re: Ptr and ForeignPtr Questions
by Marcin 'Qrczak' Kowalczyk 23 Sep '01

23 Sep '01

Sun, 23 Sep 2001 15:41:41 -0700, Ashley Yakeley <ashley(a)semantic.org> pisze: > But do you have an example of a Haskell type for a foreign import > function, for which the corresponding C function type would be ambiguous? Ptr CChar (as an argument). It could be either char * or const char *. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0