CWString API

2004-11-30 Thread Krasimir Angelov
Hello guys, I am working on updated version of HDirect and now I am going to use CWString API to marshal (wchar_t *) type to String. I found some inconsistencies in the API. - castCWcharToChar and castCharToCWchar functions are defined only for Posix systems and they aren't exported. In the

Re: CWString API

2004-11-30 Thread John Meacham
On Tue, Nov 30, 2004 at 12:41:04AM -0800, Krasimir Angelov wrote: Hello guys, I am working on updated version of HDirect and now I am going to use CWString API to marshal (wchar_t *) type to String. I found some inconsistencies in the API. - castCWcharToChar and castCharToCWchar

RE: CWString API

2004-11-30 Thread Simon Marlow
On 30 November 2004 09:35, John Meacham wrote: On Tue, Nov 30, 2004 at 12:41:04AM -0800, Krasimir Angelov wrote: Hello guys, I am working on updated version of HDirect and now I am going to use CWString API to marshal (wchar_t *) type to String. I found some inconsistencies in the API.

Re: CWString API

2004-11-30 Thread John Meacham
On Tue, Nov 30, 2004 at 10:17:13AM -, Simon Marlow wrote: On 30 November 2004 09:35, John Meacham wrote: On Tue, Nov 30, 2004 at 12:41:04AM -0800, Krasimir Angelov wrote: Hello guys, I am working on updated version of HDirect and now I am going to use CWString API to marshal

Re: CWString API

2004-11-30 Thread Krasimir Angelov
--- John Meacham [EMAIL PROTECTED] wrote: The problem is that these operations are very unsafe, there is no guarenteed isomorphism or even injection between wchar_ts and Chars. If people really know what they are doing, they can do the conversion themselves via fromIntegral/ord/chr, but I

Re: CWString API

2004-11-30 Thread John Meacham
On Tue, Nov 30, 2004 at 02:40:20AM -0800, Krasimir Angelov wrote: --- John Meacham [EMAIL PROTECTED] wrote: The problem is that these operations are very unsafe, there is no guarenteed isomorphism or even injection between wchar_ts and Chars. If people really know what they are doing,

-fallow-incoherent-instances

2004-11-30 Thread Christian Maeder
The attached module does not compile and yields the following error: InCoherentInst.hs:17: Could not deduce (Confuse a) from the context (Typeable a) arising from use of `breakFn' at InCoherentInst.hs:17 Probable fix: Add (Confuse a) to the type signature(s) for

Re: CWString API

2004-11-30 Thread Krasimir Angelov
--- John Meacham [EMAIL PROTECTED] wrote: Note that in general, there will not ever be a guarenteed one-to-one mapping between chars,wchar_ts and haskell Chars, so higher level routines must work on strings rather than individual chars. With other words the case for wchar_t isn't worse

Re: -fallow-incoherent-instances

2004-11-30 Thread Christian Maeder
I wrote: If, furthermore, the confusing instance is commented out, the source even compiles without extensions. Correction: -fglasgow-exts is still required for the type GeneralBreakFn, but -fallow-overlapping-instances can be omitted. {-# OPTIONS -fglasgow-exts -fallow-overlapping-instances

Re: -fallow-incoherent-instances

2004-11-30 Thread Ralf Laemmel
Hi, you do realise that -fallow-incoherent-instances is enabling a hell. What mostly happens is that the most general instance is chosen. Which explains the error here: Say the confusing instance is chosen (because it is generic) and hence the type checker tries to establish the Confuse

Re: -fallow-incoherent-instances

2004-11-30 Thread Keean Schupke
Ralf Laemmel wrote: General conclusion: I still have to see a good reason to use -fallow-incoherent-instances. It's mostly good to shot yourself in the head. Maybe one day we will get -fallow-backtracking? now that would be useful... Keean. ___

RE: -fno-monomorphism-restriction

2004-11-30 Thread Simon Peyton-Jones
Christian This isn't a bug. See Section 4.5.5 of the Haskell Report, http://haskell.org/onlinereport/decls.html in the second bullet under the sub-heading Motivation. Your (bi, las) binding is essentially the same as the (n,s) binding in that bullet. Simon | -Original Message-