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
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
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.
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
--- 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
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,
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
--- 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
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
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
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.
___
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-
12 matches
Mail list logo