- Haskell-Cafe - Haskell.org

Problem type checking class-method implementation
by Stefan Holdermans 03 Aug '05

03 Aug '05

Dear Haskellers, Yesterday I stumbled upon a problem type checking a program involving multi-parameter type classes. GHC rejected the program; still, I was not immediately convinced it contained a type error. Having given it some more thoughts, I start to suspect that the type checker is in err and that the program is well-typed after all. But, well, I might be overlooking something obvious... I have reduced my code to a small but hopelessly contrived example program exposing the problem. Please hang on. Because we employ multi-parameter type classes, we need the Glasgow extensions: {-# OPTIONS -fglasgow-exts #-} Let's start easy and define the identity monad: newtype Identity a = Identity {runIdentity :: a} instance Monad Identity where return = Identity Identity a >>= f = f a Then, let's introduce the foundations for the (contrived) example: class (Monad m) => IsItem m i where processItem :: i -> m () class (Monad m) => IsProcessor p m | m -> p where process :: (IsItem m i) => i -> m () -- ...some more methods, possibly involving p... So, an item is something that can be processed within the context of a certain monad, and a processor is something that can process an item of an appropriate type. Note the functional dependency from m to p: a processor type m uniquely determines the type of the processing context p. Before we move on, consider this canonical item type, which is just a one-field record representing an implementation of the IsItem class: newtype Item m = Item {processItemImpl :: m ()} The corresponding instance declaration is obvious: instance (Monad m) => IsItem m (Item m) where processItem = processItemImpl Furthermore values of every type that is an instance of IsItem can be converted to corresponding Item values: toItem :: (IsItem m i) => i -> Item m toItem = Item . processItem Please stick with me, for we are now going to implement a monad transformer for processors (which, for this example, is really just the identity monad transformer): newtype ProcessorT p m a = ProcessorT {runProcessorT :: m a} instance (Monad m) => Monad (ProcessorT p m) where return = ProcessorT . return ProcessorT m >>= f = ProcessorT (m >>= runProcessorT . f) instance (Monad m) => IsProcessor p (ProcessorT p m) where process = processItem Then, finally, we use this transformer to derive a processor monad: newtype Processor p a = Processor {unwrap :: ProcessorT p Identity a} runProcessor :: Processor p a -> a runProcessor = runIdentity . runProcessorT . unwrap So, we just make sure that Processor is a monad: instance Monad (Processor p) where return = Processor . return Processor m >>= f = Processor (m >>= unwrap . f) Now all what is left to do is declare Processor an instance of IsProcessor. To this end, we need to be able to cast items for Processor p to items for ProcessorT p Identity (for all p). The following function takes care of that: castItem :: (IsItem (Processor p) i) => i -> Item (ProcessorT p Identity) castItem = Item . unwrap . processItem Note that up 'til now everything is fine: GHC is happy, I am happy. But then, when all the hard work is done, and we just only have to connect things properly, it just breaks: instance IsProcessor p (Processor p) where process = Processor . process . castItem After adding this last instance declaration, GHC happily reports: Processor.hs:56:24: Could not deduce (IsItem (ProcessorT p Identity) (Item (ProcessorT p1 Identity))) from the context (IsProcessor p (Processor p), Monad (Processor p), IsItem (Processor p) i) arising from use of `process' at Processor.hs:56:24-30 Probable fix: add (IsItem (ProcessorT p Identity) (Item (ProcessorT p1 Identity))) to the class or instance method `process' or add an instance declaration for (IsItem (ProcessorT p Identity) (Item (ProcessorT p1 Identity))) In the first argument of `(.)', namely `process' In the second argument of `(.)', namely `process . castItem' In the definition of `process': process = Processor . (process . castItem) Processor.hs:56:34: Could not deduce (IsItem (Processor p1) i) from the context (IsProcessor p (Processor p), Monad (Processor p), IsItem (Processor p) i) arising from use of `castItem' at Processor.hs:56:34-41 Probable fix: add (IsItem (Processor p1) i) to the class or instance method `process' or add an instance declaration for (IsItem (Processor p1) i) In the second argument of `(.)', namely `castItem' In the second argument of `(.)', namely `process . castItem' In the definition of `process': process = Processor . (process . castItem) It seems to me that the type checker fails to unify p and p1 where it really should. But once again: I may be wrong here. So, could you either explain to me what I'm missing here and why this program is indeed ill-typed, or confirm that it's really just GHC that should be accepting this program. I have attached a file Processor.hs containing the example program. Please note that I've only tested this with GHC 6.4. I did not try it (yet) with the version in HEAD. Neither did I investigate how Hugs acts on this code. I'm aware that there are some workarounds to get past this problem. The most obvious approach to circumventing this issue is to alter the signature of process so that it takes an explicit Item value and put the need for casting (using toItem) to the caller side. But that's just not the point, of course. I'm sorry for this far too long post, but this issue is quite essential for the code I'm currently working. Reactions, therefore, are much appreciated. TIA, Stefan http://www.cs.uu.nl/~stefan/

1 0

Announce: HSFFIG 1.0 Stable Release
by Dimitry Golubovsky 01 Aug '05

01 Aug '05

Dear List Subscribers, I am pleased to announce the first stable release of HSFFIG, yet another tool for autogeneration of FFI bindings from C include files. The project is now hosted at Sourceforge: http://hsffig.sourceforge.net Downloads page: http://www.sourceforge.net/projects/hsffig Darcs repo: darcs get http://hsffig.sourceforge.net/repos/hsffig-1.0 Tutorial: http://www.haskell.org/hawiki/HsffigTutorial The wiki page "HsffigExamples" has been separated from the Tutorial. If anybody has an interesting example of using HSFFIG please update the page with code samples. Brief summary of changes: - The distribution is now cabalized. Please read the INSTALL file. - The multiparameter class and combinators to access members of structures/unions are moved to separate library. It is necessary to specify -package HSFFIG when compiling applications. Thanks to everybody who participated in discussions related to HSFFIG on this list, and privately. This helped me with implelentation of some features and gave some ideas for future improvement. Debian, RPM, and other packagers: if you create a HSFFIG package please let me know the package URL so I can update the Freshmeat project information page, and the project homepage. For any problems related to this project feel free to contact me. -- Dimitry Golubovsky

1 0

Call for participation: CUFP 2005
by Andy Moran 01 Aug '05

01 Aug '05

IMPORTANT NOTE: Registration is now available at: http://www.cs.ioc.ee/tfp-icfp-gpce05/ CUFP 2005 THE SECOND ACM SIGPLAN COMMERCIAL USERS OF FUNCTIONAL PROGRAMMING WORKSHOP http://www.galois.com/cufp/ Talinn, Estonia September 24th 2005 Co-located with ICFP http://www.brics.dk/~danvy/icfp05/ ---------------------------------------------------------------------- Important dates Early registration deadline July 29, 2005 Late registration deadline September 2, 2005 Workshop September 24, 2005 Registration is available at: http://www.cs.ioc.ee/tfp-icfp-gpce05 ---------------------------------------------------------------------- The goal of CUFP is to build a community for users of functional programming languages and technology, be they using functional languages in their professional lives, in an open source project (other than implementation of functional languages), as a hobby, or any combination thereof. In short: anyone who uses functional programming as a /means/, but not an /end/. ---------------------------------------------------------------------- Schedule The meeting will last a full day, with a mix of invited presentations and discussion sessions. This year, we have the following confirmed speakers: * Atrijus Tang; talking about PUGS, a Perl6 implementation, written in Haskell; * Fabrice Le Fessant; talking about MLDonkey, a popular multi-platform, multi-network P2P client written in OCaml. * Michael Sperber; talking about uses of Scheme in the banking industry. * David Roundy; talking about darcs, a popular and flexible revision control system well-suited to highly distributed development, written in Haskell. * Jim Grundy; talking his experiences with functional programming at Intel's Strategic CAD Labs. * Robert Boone; talking about his experiences at FreeScale. * Jonathan Soebel; talking about lessons the FP community can learn from the OMG's Model Driven Architecture (MDA) and its related marketing efforts. We will also be having two working sessions, where lively debate and brainstorming will be the order of the day: * FP, Education, and Industry: industry folks complain that there aren't enough FP folks being produced by schools, and educators complain that students don't see any point in studying FP if there are no jobs to be had. How can we break this stalemate? Simon Thompson of Functional and Declarative Programming in Education (FDPE05) will be joining us, and we'll be debriefing at FDPE05. * Stimulating a CUFP Community: we'd like the buzz and excitement surrounding CUFP to persist beyond the workshops. What would such a community look like? How do we make it happen? The session will kick off with two separate but complimentary starting points: a proposed "Users of FP" community web site and a proposed "Haskell Consortium" web site. There will be no published proceedings, as the meeting is intended to be more a discussion forum than a technical interchange. A full report of last year's workshop appeared in the Functional Programming column of the December 2004 issue of SIGPLAN Notices, and we plan to do the same this year. -- Andy Moran Phone: 503.626.6616, x113 Galois Connections Inc. Fax: 503.350.0833 12725 SW Millikan Way, Suite #290 http://www.galois.com Beaverton, OR 97005 moran(a)galois.com

5 6

STM and MonadFix?
by Jonathan Cast 29 Jul '05

29 Jul '05

Why is there no MonadFix STM instance? Jon Cast

1 0

RE: [Haskell-cafe] hssfig: Unresolved symbols when importing a foreignlibrary: what is the preferred way of handling?
by Simon Marlow 28 Jul '05

28 Jul '05

On 27 July 2005 15:32, Dimitry Golubovsky wrote: > - instead of generation of a single object file referencing all the > functions, create one per funciton import and place them all in an > archive (.a). Then, when linking, only actually used functions will be > picked from the archive. This is what ghc -split-objs does. It's something of a hack, but I just thought I'd mention it. I believe it would fix your problem. Cheers, Simon

1 0

Suggestions for #defines with FFI
by John Goerzen 28 Jul '05

28 Jul '05

Hi, I'm writing a Haskell interface to a library that #defines about 100 constants corresponding to numeric exit codes. It also defines hundreds of contants, over the same numbering ranges, for other purposes. The exit codes are non-contiguous as well. So my question is: is there a nice way I can represent this in Haskell, preferably without having to key in all 100 constants? Or will I just have to list all the options and give up type checking to differentiate one purpose of a constant from another? Thanks, -- John

3 3

RE: [Haskell-cafe] Suggestions for #defines with FFI
by Dimitry Golubovsky 28 Jul '05

28 Jul '05

John, Could you please give an example of such constant definitions? Is it possible to look at the include file? -- Dimitry Golubovsky Anywhere on the Web

4 5

hssfig: Unresolved symbols when importing a foreign library: what is the preferred way of handling?
by Dimitry Golubovsky 27 Jul '05

27 Jul '05

I would like to collect opinions from interested people on this matter. Background: Hsffig parses include files (.h) and generates FFI import declarations for every function/external variable it encounters a prototype declaration for. The result is a .hsc file which is converted into a Haskell source and compiled into an object file and linked into an executable along with other application source files using ghc as frontend (so far, hsffig is targeted to ghc users only). This object file will contain references to all foreign functions to be imported. Problem: In some cases, a include file may contain prototypes of functions not existing in the library it corresponds to. In my case, <unistd.h> (Linux, glibc2) contains prototypes for __ftruncate and pthread_atfork which come up unresolved when linking the executable without additional libraries specified. pthread_atfork is resolved when linking with -lpthread. Where is __ftruncate defined, I don't know, and I do not really want ot know unless I need to use this function. Possible solutions, sorted by expected amount of work necessary to implement (please pick one you would prefer, or suggest yours): - leave everything as is: the executable will not be linked until the developer finds all the libraries to resolve all the missing symbols. That's how it works (or doesn't work) now. - tell ld only to warn about unresolved symbols: the executable will be built anyway, but if the unresolved function is called from under the hood it most likely results in segfault hard to explain (which function caused it). Only special linker option is required. - for each foreign function imported, generate a stub which, when called, complains loudly and aborts the program. These stubs are placed in a separate object file and linked after all possible libraries, so library-defined symbols always take precedence. The disadvantage is: the developer would not know which symbols remained unresolved when the executable was linked, only will he know when the application crashes. I am trying to implement this now, using the hsc2hs' #def macro to define those stub functions. - analyze the linker output and make auto-correction in the generated .hsc file just by excluding FFI declarations for unresolved functions. Non-elegant, requires second pass and highly platform and tool dependent. - instead of generation of a single object file referencing all the functions, create one per funciton import and place them all in an archive (.a). Then, when linking, only actually used functions will be picked from the archive. I am not sure how would this interact with ghc --make: I got an impression that a .hi file is necessary for all modules (.hs/.hi/.o triple) imported unless they are gotten from a package. If I have in my program: import FOO_H and there is no FOO_H.hi nor FOO_H.hs, only libFOO_H.a: how ghc would live with this? The latter approach does not take much to implement in hsffig itself (I already have a splitter which splits into one object file per a structure/union). I am more concerned how to make ghc live with this. Creation of a package for each imported include file seems like overkill. PS I believe that hsffig will be an useful utility. I noticed several people downloaded nightly tarballs or checked out from the DARCS repo. If these persons have found this program useful, would they please suggest something on the matter I described. -- Dimitry Golubovsky Anywhere on the Web

1 0

RE: [Haskell-cafe] ForeignPtrs with liveness dependencies
by Simon Marlow 27 Jul '05

27 Jul '05

On 26 July 2005 16:49, Einar Karttunen wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: >> No, unfortunately not. You have foo's finalizer which refers to bar >> via a touchForeignPtr. If both foo and bar are unreachable >> (references from finalizers don't count), then both foo and bar's >> finalizers will be started together, and may run in any order. > > I didn't realize the "references from finalizers don't count" rule. It does make sense. If references from finalizers *did* keep objects alive, then if you had two objects that referreed to each other by their finalizers, neither would ever be finalized. This paper has all the rationale, you might find it interesting: http://www.haskell.org/~simonmar/papers/weak.pdf Expressing ordering relationships between finalizers is known to be hard - for instance, if you have a chain of N dependent finalizers that are all unreachable, you don't want to take N major GCs to discover the fact. The canonical paper on this is Hans Boehm's "Destructors, finalizers, and synchronization": http://portal.acm.org/citation.cfm?id=604153 > What would happen if the finalizer of foo would resurrect bar after > bar's finalizer has been run? That can happen. Nothing goes wrong on the Haskell side, but if this is a problem for your C objects then you need to be aware of it. >> So touchForeignPtr does only one thing: it expresses the precise >> relationship "bar is alive if foo is alive". If both are not alive, >> then both finalizers can run, in any order. > > So reference counting the objects is the solution? Perhaps. It seems robust, anyway. >> I realise this is very subtle. By all means suggest improvements to >> the docs. > > Mentioning that references from finalizers don't count could help > someone not to repeat my mistakes. Ok, will do. Cheers, Simon

1 0

Newbie question about Read strings in a line of File
by Huong Nguyen 26 Jul '05

26 Jul '05

Hello everybody, Now I am writing a module to handles messages of a system. The messages are stored in a file. The content of each line of the file likes this: 1 001 001 Error message 1 1 001 002 Error message 2 1 002 001 Warning message 1 in which: The first word is the language Code (e.g: 1 is English, 2 is French), the second is type of messages (e.g: 001 is error message, 002 is warning message,etc), the third is the index number of messages, and the last is the message. I need to read 3 first words of each line and assign them to 3 variables. After that, I need to show the error message based on the tuple of those 3 first variable, e.g: errMsg("1","001","001") = "Error message 1" At first, I tried to read only one first line of the file as follows: import Prelude import List import Char import IO main = do hdl <- openFile "message.txt" ReadMode msgLine <-hGetLine hdl --stdMsg: cut space at the begining of the line. let stdMsg = dropWhile(not.isSpace) msgLine -Assign langCode with the first word of the line. let langCode = takeWhile(not.isSpace) stdMsg However, after that, I do not know how to read second element, third element of the line. And how to read continuous next line after first? Please help me. Thanks a lot.

2 1