Re: [Haskell-cafe] foldlWhile
On Saturday 20 November 2004 10:47, Serge D. Mechveliani wrote: Is such a function familia to the Haskell users? foldlWhile :: (a - b - a) - (a - Bool) - a - [b] - a Maybe this link is of interest to you: http://okmij.org/ftp/Haskell/#fold-stream Ben -- Top level things with identity are evil.-- Lennart Augustsson ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Problem with overlapping class instances
Once again, the Haskell class system is proving rather subtle for me. On this occasion, I'm getting an overlapping class instance error which I think should be fully disambiguated by the supplied class context. The code below (end of message) is a .lhs file that reproduces the problem in Hugs, with external dependencies from my working codebase stripped out. It should be possible to simply load it (or this whole email) to get the same error: [[ Reading file D:\Cvs\DEV\HaskellDL\spike-overlap-conceptexpr.lhs: ERROR D:\Cvs\DEV\HaskellDL\spike-overlap-conceptexpr.lhs:30 - Overlapping inst ances for class ConceptExpr *** This instance : ConceptExpr (a b) *** Overlaps with : ConceptExpr AtomicConcept *** Common instance : ConceptExpr [Char] ]] The line referred to as this instance is: instance (ConceptWrapper cw c, ConceptExpr c) = ConceptExpr (cw c) where The reported overlapping instance is [Char], which I take to be derived from the type constructor [] applied to type Char, this yielding a form that matches (cw c). But the instance ConceptExpr (cw c) is declared to be dependent on the context ConceptWrapper cw c, which has *not* been declared for the type constructor []. GHCi with -fglasgow-exts is no more informative. What am I missing here? #g -- [Source code follows] spike-overlap-ConceptExpr.lhs - type AtomicConcepts a = [(AtomicConcept,[a])] type AtomicRoles a = [(AtomicRole ,[(a,a)])] type TInterpretation a = ([a],AtomicConcepts a,AtomicRoles a) class (Eq c, Show c) = ConceptExpr c where iConcept :: Ord a = TInterpretation a - c - [a] ... type AtomicConcept = String -- named atomic concept Declare AtomicConcept and AtomicRole as instances of ConceptExpr and RoleExpr (AtomicRole is used by AL, and including AtomicConcept here for completeness). instance ConceptExpr AtomicConcept where iConcept = undefined ... To allow a common expression to support multiple description logics, we first define a wrapper class for DLConcept and DLRole: class ConceptExpr c = ConceptWrapper cw c | cw - c where wrapConcept :: c - cw c - cw c getConcept :: cw c - c Using this, a ConceptWrapper can be defined to be an instance of ConceptExpr: This is line 30: instance (ConceptWrapper cw c, ConceptExpr c) = ConceptExpr (cw c) where iConcept = iConcept . getConcept Error message: Reading file D:\Cvs\DEV\HaskellDL\spike-overlap-conceptexpr.lhs: ERROR D:\Cvs\DEV\HaskellDL\spike-overlap-conceptexpr.lhs:30 - Overlapping inst ances for class ConceptExpr *** This instance : ConceptExpr (a b) *** Overlaps with : ConceptExpr AtomicConcept *** Common instance : ConceptExpr [Char] Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem with overlapping class instances
Instance selection and thereby overlapping resolution is *independent* of constraints. It is defined to be purely syntactical in terms of instance heads. See the HList paper for some weird examples. Ralf Graham Klyne wrote: The reported overlapping instance is [Char], which I take to be derived from the type constructor [] applied to type Char, this yielding a form that matches (cw c). But the instance ConceptExpr (cw c) is declared to be dependent on the context ConceptWrapper cw c, which has *not* been declared for the type constructor []. GHCi with -fglasgow-exts is no more informative. What am I missing here? ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Top Level TWI's again was Re: [Haskell] Re: Parameterized Show
[Switching to Haskell-cafe] At 11:26 22/11/04 +, you wrote: I would ask an alternative question - is it possible to live without unsafePerformIO? I have never needed to use it! I have used it once, with reservations, but at the time I didn't have the time/energy to find a better solution. (The occasion of its use was accessing external entities within an XML parser; by making the assumption that the external entities do not change within any context in which results from a program are compared, I was able to satisfy the proof obligation of not causing or being sensitive to side effects.) The reason this was important to me is that I wanted to be able to use the parser from code that was not visibly in the IO monad. For me, treating Web data transformations as pure functions is one of the attractions of using Haskell. (Since doing that, I had an idea that I might be able to parameterize the entity processing code on some Monad, and use either an Identity monad or IO depending on the actual requirements. This way, I could keep pure XML processing out of the IO monad, but use IO when IO was needed.) In short: I think it's usually possible to avoid using unsafePerformIO, but I'd be reluctant to cede it altogether, if only for sometimes quick-and-dirty pragmatic reasons. #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Top Level TWI's again was Re: [Haskell] Re: Parameterized Show
Obviously without knowing the details I am speculating, but would it not be possible to do a first pass of the XML and build a list of files to read (a pure function) this returns its result to the IO monad where the files are read and concatenated together, and passed to a second (pure functional) processing function. If written well this can take advantage of lazy execution, so both functions end up running concurrently. It seems to me that as unsafePerformIO is not in the standard and only implemented on some compilers/interpreters, that you limit the portability of code by using it, and that it is best avoided. Also as any safe use of unsafePerformIO can be refactored to not use it I could certainly live without it. Keean. Graham Klyne wrote: [Switching to Haskell-cafe] I have used it once, with reservations, but at the time I didn't have the time/energy to find a better solution. (The occasion of its use was accessing external entities within an XML parser; by making the assumption that the external entities do not change within any context in which results from a program are compared, I was able to satisfy the proof obligation of not causing or being sensitive to side effects.) The reason this was important to me is that I wanted to be able to use the parser from code that was not visibly in the IO monad. For me, treating Web data transformations as pure functions is one of the attractions of using Haskell. (Since doing that, I had an idea that I might be able to parameterize the entity processing code on some Monad, and use either an Identity monad or IO depending on the actual requirements. This way, I could keep pure XML processing out of the IO monad, but use IO when IO was needed.) In short: I think it's usually possible to avoid using unsafePerformIO, but I'd be reluctant to cede it altogether, if only for sometimes quick-and-dirty pragmatic reasons. #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Top Level TWI's again was Re: [Haskell] Re: Parameterized Show
On Monday 22 November 2004 23:22, Keean Schupke wrote: It seems to me that as unsafePerformIO is not in the standard and only implemented on some compilers/interpreters, that you limit the portability of code by using it, and that it is best avoided. Also as any safe use of unsafePerformIO can be refactored to not use it I could certainly live without it. With one exception: If a foreign function (e.g. from a C library) is really pure, then I see no way to tell that to the compiler other than using unsafePerformIO. IIRC, unsafePerformIO is in the standard FFI libraries. Ben -- Top level things with identity are evil.-- Lennart Augustsson ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Top Level TWI's again
Benjamin Franksen writes: If a foreign function (e.g. from a C library) is really pure, then I see no way to tell that to the compiler other than using unsafePerformIO. What's the problem with importing it with a pure signature? Like this: foreign import ccall unsafe sin :: CDouble - CDouble Peter ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
