Simon Peyton-Jones wrote:
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.
Thanks for your anal
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
Ralf Laemmel wrote:
I still have to see a good reason to use "-fallow-incoherent-instances".
The motivation came from SPJ for the following example:
type Inte a = (Integer,a)
instance Show a => Show [Inte a]
data Bar b = Bar [b]
instance Show b => Show (Bar b) where
show (Bar x1) = show x1
This
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.
___
Glas
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 constrain
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
--- 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 wo
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 `addGeneralFal
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
--- 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,
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 A
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
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 castCharToCWcha
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
14 matches
Mail list logo
