Re: [Haskell-cafe] [Haskell] ANNOUNCE: system-filepath 0.4.5 and system-fileio 0.3.4
On Thu, Feb 09, 2012 at 11:40:28AM -0800, John Meacham wrote:
On Thu, Feb 9, 2012 at 11:23 AM, Ian Lynagh ig...@earth.li wrote:
On Thu, Feb 09, 2012 at 04:52:16AM -0800, John Meacham wrote:
Since CSigSet has sigset_t associated with it, 'Ptr CSigSet' ends up
turning
into 'sigset_t *' in the generated code. (Ptr (Ptr CChar)) turns into
char**
and so forth.
What does the syntax for associating sigset_t with CSigSet look like?
There currently isn't a user accessable once,
My current syntax idea is.
data CFile = foreign stdio.h FILE
but it doesn't extend easily to 'newtype's
or maybe a {-# CTYPE FILE #-} pragma...
I've now implemented this in GHC. For now, the syntax is:
type{-# CTYPE some C type #-} Foo = ...
newtype {-# CTYPE some C type #-} Foo = ...
data{-# CTYPE some C type #-} Foo = ...
The magic for (Ptr a) is built in to the compiler.
Thanks
Ian
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: system-filepath 0.4.5 and system-fileio 0.3.4
On Thu, Feb 16, 2012 at 1:20 PM, Ian Lynagh ig...@earth.li wrote:
I've now implemented this in GHC. For now, the syntax is:
type {-# CTYPE some C type #-} Foo = ...
newtype {-# CTYPE some C type #-} Foo = ...
data {-# CTYPE some C type #-} Foo = ...
The magic for (Ptr a) is built in to the compiler.
Heh. I just added it for jhc too with the exact same syntax. :)
the difference is that I do not allow them for 'type' declarations, as
dusugaring of types happens very early in compilation, and it feels sort
of wrong to give type synonyms meaning. like I'm breaking referential
transparency or something..
I also allow foreign header declarations just like with ccall.
data {-# CTYPE stdio.h FILE #-} CFile
will mean that 'stdio.h' needs to be included for FILE to be declared.
John
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: system-filepath 0.4.5 and system-fileio 0.3.4
On Wed, Feb 8, 2012 at 10:56 AM, Ian Lynagh ig...@earth.li wrote: That sounds right. It basically means you don't have to write the C stubs yourself, which is nice because (a) doing so is a pain, and (b) when the foreign import is inside 2 or 3 CPP conditionals it's even more of a pain to replicate them correctly in the C stub. Unfortunately, there are cases where C doesn't get all the type information it needs, e.g.: http://hackage.haskell.org/trac/ghc/ticket/2979#comment:14 but I'm not sure what the best fix is. I believe jhc's algorithm works in this case. Certain type constructors have C types associated with them, in particular, many newtypes have c types that are different than their contents. So my routine that finds out whether an argument is suitable for FFIing returns both a c type, and the underlying raw type (Int# etc..) that the type maps to. So the algorithm checks if the current type constructor has an associated C type, if it doesn't then it expands the newtype one layer and trys again, however if it does have a c type, it still recurses to get at the underlying raw type, but then replaces the c type with whatever was attached to the newtype. In the case of 'Ptr a' it recursively runs the algorithm on the argument to 'Ptr', then takes that c type and appends a '*' to it. If the argument to 'Ptr' is not an FFIable type, then it just returns HsPtr as the C type. Since CSigSet has sigset_t associated with it, 'Ptr CSigSet' ends up turning into 'sigset_t *' in the generated code. (Ptr (Ptr CChar)) turns into char** and so forth. An interesting quirk of this scheme is that it faithfully translates the perhaps unfortunate idiom of newtype Foo_t = Foo_t (Ptr Foo_t) into foo_t (an infinite chain of pointers) which is actually what the user specified. :) I added a check for recursive newtypes that chops the recursion to catch this as people seem to utilize it. I ask because jhc needs such a feature (very hacky method used now, the rts knows some problematic functions and includes hacky wrappers and #defines.) and I'll make it behave just like the ghc one when possible. Great! It has now been implemented, shall be in jhc 0.8.1. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: system-filepath 0.4.5 and system-fileio 0.3.4
On Thu, Feb 09, 2012 at 04:52:16AM -0800, John Meacham wrote: Since CSigSet has sigset_t associated with it, 'Ptr CSigSet' ends up turning into 'sigset_t *' in the generated code. (Ptr (Ptr CChar)) turns into char** and so forth. What does the syntax for associating sigset_t with CSigSet look like? Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: system-filepath 0.4.5 and system-fileio 0.3.4
On Thu, Feb 9, 2012 at 11:23 AM, Ian Lynagh ig...@earth.li wrote:
On Thu, Feb 09, 2012 at 04:52:16AM -0800, John Meacham wrote:
Since CSigSet has sigset_t associated with it, 'Ptr CSigSet' ends up
turning
into 'sigset_t *' in the generated code. (Ptr (Ptr CChar)) turns into char**
and so forth.
What does the syntax for associating sigset_t with CSigSet look like?
There currently isn't a user accessable once, but CSigSet is included in the
FFI spec so having the complier know about it isn't that bad. In fact, it is
how I interpreted the standard. Otherwise, why would CFile be specified if it
didn't expand 'Ptr CFile' properly. I just have a single list of associations
that is easy to update at the moment, but a user defineable way is something i
want in the future. My current syntax idea is.
data CFile = foreign stdio.h FILE
but it doesn't extend easily to 'newtype's
or maybe a {-# CTYPE FILE #-} pragma...
The 'Ptr' trick is useful for more than just pointers, I use the same thing to
support native complex numbers. I have
data Complex_ :: # - # -- type function of unboxed types to unboxed types.
then can do things like 'Complex_ Float64_' to get hardware supported complex
doubles. The expansion happens just like 'Ptr' except instead of postpending
'*' when it encounters _Complex, it prepends '_Complex ' (a C99 standard
keyword).
You can then import primitives like normal (for jhc)
foreign import primitive Add complexPlus ::
Complex_ Float64_ - Complex_ Float64_ - Complex_ Float64_
and lift it into a data type and add instances for the standard numeric classes
if you wish. (I have macros that automate the somewhat repetitive instance
creation in lib/jhc/Jhc/Num.m4)
John
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: system-filepath 0.4.5 and system-fileio 0.3.4
On 08/02/2012 02:26, John Meacham wrote: On Tue, Feb 7, 2012 at 4:24 AM, Simon Marlowmarlo...@gmail.com wrote: Separately the unix package added support for undecoded FilePaths (RawFilePath), but unfortunately at the same time we started using a new extension in GHC 7.4.1 (CApiFFI), which we decided not to document because it was still experimental: Hi, from my reading, it looks like 'capi' means from a logical perspective, Don't assume the object is addressible, but rather that the standard c syntax for calling this routine will expand into correct code when compiled with the stated headers So, it may be implemented by say creating a stub .c file that includes the headers and creates a wrapper around each one or when compiling via C, actually including the given headers and the function calls in the code. Yes, that's exactly it. In GHC we create a stub (even when compiling via C, for simplicity of implementation). Cheers, Simon I ask because jhc needs such a feature (very hacky method used now, the rts knows some problematic functions and includes hacky wrappers and #defines.) and I'll make it behave just like the ghc one when possible. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: system-filepath 0.4.5 and system-fileio 0.3.4
On Tue, Feb 07, 2012 at 06:26:48PM -0800, John Meacham wrote: Hi, from my reading, it looks like 'capi' means from a logical perspective, Don't assume the object is addressible, but rather that the standard c syntax for calling this routine will expand into correct code when compiled with the stated headers So, it may be implemented by say creating a stub .c file that includes the headers and creates a wrapper around each one or when compiling via C, actually including the given headers and the function calls in the code. That sounds right. It basically means you don't have to write the C stubs yourself, which is nice because (a) doing so is a pain, and (b) when the foreign import is inside 2 or 3 CPP conditionals it's even more of a pain to replicate them correctly in the C stub. Unfortunately, there are cases where C doesn't get all the type information it needs, e.g.: http://hackage.haskell.org/trac/ghc/ticket/2979#comment:14 but I'm not sure what the best fix is. I ask because jhc needs such a feature (very hacky method used now, the rts knows some problematic functions and includes hacky wrappers and #defines.) and I'll make it behave just like the ghc one when possible. Great! Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: system-filepath 0.4.5 and system-fileio 0.3.4
On 06/02/2012 20:32, Ian Lynagh wrote: On Sun, Feb 05, 2012 at 07:17:32PM -0800, John Millikin wrote: That was my understanding also, then QuickCheck found a counter-example. It turns out that there are cases where a valid path cannot be roundtripped in the GHC 7.2 encoding. This is fixed in GHC 7.4.1. I think we forgot to mention it in the release notes. Rountripping of FilePath is now fully supported. The commit in question is this: commit 7e59b6d50ec4a4400e8730bfd8cfc471c1873702 Author: Max Bolingbroke batterseapo...@hotmail.com Date: Fri Nov 18 17:45:34 2011 + Go back to using private-use characters in roundtripping Which was the result of a long discussion on the glasgow-haskell-users mailing list: http://www.haskell.org/pipermail/glasgow-haskell-users/2011-November/021115.html Separately the unix package added support for undecoded FilePaths (RawFilePath), but unfortunately at the same time we started using a new extension in GHC 7.4.1 (CApiFFI), which we decided not to document because it was still experimental: http://hackage.haskell.org/trac/ghc/ticket/2979 In retrospect we should have documented this. It's not like we don't normally dump a load of experimental features on our users and then change them later :-) Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: system-filepath 0.4.5 and system-fileio 0.3.4
On Tue, Feb 7, 2012 at 4:24 AM, Simon Marlow marlo...@gmail.com wrote: Separately the unix package added support for undecoded FilePaths (RawFilePath), but unfortunately at the same time we started using a new extension in GHC 7.4.1 (CApiFFI), which we decided not to document because it was still experimental: Hi, from my reading, it looks like 'capi' means from a logical perspective, Don't assume the object is addressible, but rather that the standard c syntax for calling this routine will expand into correct code when compiled with the stated headers So, it may be implemented by say creating a stub .c file that includes the headers and creates a wrapper around each one or when compiling via C, actually including the given headers and the function calls in the code. I ask because jhc needs such a feature (very hacky method used now, the rts knows some problematic functions and includes hacky wrappers and #defines.) and I'll make it behave just like the ghc one when possible. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: system-filepath 0.4.5 and system-fileio 0.3.4
On Sun, Feb 05, 2012 at 07:17:32PM -0800, John Millikin wrote: That was my understanding also, then QuickCheck found a counter-example. It turns out that there are cases where a valid path cannot be roundtripped in the GHC 7.2 encoding. This is fixed in GHC 7.4.1. Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
