- Haskell-Cafe - Haskell.org

First Call for Papers -- GPCE'08
by Emir Pasalic 20 Feb '08

20 Feb '08

Call for Papers Seventh International Conference on Generative Programming and Component Engineering (GPCE 2008) October 19-23, 2008 Nashville, Tennessee (co-located with OOPSLA 2008) http://www.gpce.org Important Dates: * Submission of abstracts: May 12, 2008 * Submission: May 19, 2008 * Notification: June 30, 2008 * Tutorial and workshop proposals: March 30, 2008 * Tutorial and workshop notification: April 5, 2008 Scope Generative and component approaches are revolutionizing software development similar to how automation and components revolutionized manufacturing. Generative Programming (developing programs that synthesize other programs), Component Engineering (raising the level of modularization and analysis in application design), and Domain-Specific Languages (DSLs) (elevating program specifications to compact domain-specific notations that are easier to write, maintain, and analyze) are key technologies for automating program development. The International Conference on Generative Programming and Component Engineering provides a venue for researchers and practitioners interested in techniques for enhancing the productivity, quality, and time-to-market in software development that stems from deploying components and automating program generation. In addition to exploring cutting-edge techniques for developing generative and component-based software, our goal is to foster further cross-fertilization between the software engineering research community and the programming languages community. Submissions Research papers: 10 pages in SIGPLAN proceedings style (sigplanconf.cls) reporting original research results that contribute to scientific knowledge in the areas listed below (the PC chair can advise on appropriateness). Experience reports: 2 to 4 pages in length in SIGPLAN proceedings style (sigplanconf.cls). We encourage experience reports that provide concrete evidence with regards to the efficacy of generative technologies in industrial applications. Topics GPCE seeks contributions in software engineering and in programming languages related (but not limited) to: * Generative programming o Reuse, meta-programming, partial evaluation, multi-stage and multi-level languages, step-wise refinement, and generic programming o Semantics, type systems, symbolic computation, linking and explicit substitution, in-lining and macros, templates, and program transformation o Runtime code generation, compilation, active libraries, synthesis from specifications, development methods, generation of non-code artifacts, formal methods, and reflection * Generative techniques for o Product-line architectures o Distributed, real-time and embedded systems o Model-driven development and architecture o Resource bounded/safety critical systems. * Component-based software engineering o Reuse, distributed platforms and middleware, distributed systems, evolution, patterns, development methods, deployment and configuration techniques, and formal methods * Integration of generative and component-based approaches * Domain engineering and domain analysis o Domain-specific languages including visual and UML-based DSLs * Separation of concerns o Aspect-oriented and feature-oriented programming, o Intentional programming and multi-dimensional separation of concerns * Industrial applications of the above Experience reports on applications of these techniques to real-world problems are especially encouraged, as are research papers that relate ideas and concepts from several of these topics, or bridge the gap between theory and practice. The program chair is happy to advise on the appropriateness of a particular subject. Submissions must adhere to SIGPLAN's republication policy. Please contact the program chair if you have any questions about how this policy applies to your paper (gpce2008 at gpce.org) Organizers General Chair: Yannis Smaragdakis (University of Oregon) Program Chair: Jeremy Siek (University of Colorado at Boulder) Satellite Chair: Ralf Lammel (Univ. Koblenz-Landau) Publicity Chair: Emir Pasalic (LogicBlox, Inc.) Program Committee David Abrahams (Boost Consulting) Uwe Assmann (Technische Universitat, Dresden) Ira Baxter (Semantic Designs, USA) Martin Bravenboer (Delft Univ. of Tech., The Netherlands) Jacques Carette (McMaster University, Canada) Shigeru Chiba (Tokyo Institute of Technology, Japan) William R. Cook (University of Texas at Austin, USA) Lidia Fuentes (University of Malaga, Spain) Yossi Gil (The Technion, Israel) Aniruddha Gokhale (Vanderbilt University, USA) Mark Grechanik (Accenture Technology Labs, USA) Stanislaw Jarzabek (National University of Singapore) Jaakko Jarvi (Texas A&M Unviersity, USA) Julie Lawall (DIKU, University of Copenhagen, Denmark) Christian Lengauer (University of Passau, Germany) Matthew Marcus (Adobe Systems Inc., USA) Anne-Francoise Le Meur (University of Lille 1, France) Sibylle Schupp (Chalmers University of Technology, Sweden) Peter Sestoft (IT University of Copenhagen, Denmark) Chung-chieh Shan (Rutgers University, USA) Eric Van Wyk (University of Minnesota, USA)

1 0

Re: [Haskell-cafe] Haskell maximum stack depth
by Neil Mitchell 19 Feb '08

19 Feb '08

Hi > ghc uses a pretty conventional stack AFAIK, and it is arbitrarily > limited, but you can change the limit with +RTS options. GHC uses a conventional stack (in that you put stuff at the top, and take it off from the top), but it is not a conventional stack in the way imperative programs work. In an imperative program if you make a function call, a frame gets pushed on the stack. When the function call returns, the frame gets popped off the stack. In Haskell, lazy evaluation makes it massively more confusing. > Also, stack "overflows" are a pretty common cause of program failure > IME, not at all rare. At least, far more common than whatever error > message you get from heap exhaustion (can't even remember the last > time I saw one of those). Yes, I agree. However, in imperative programming stack overflow nearly always means you've exceeded some recursion depth in the program, and should think about refactoring it to use explicit loops. In Haskell, stack overflow is usually a laziness bug. Same error message, completely different causes. In Haskell, the solution to stack overflow is almost never "increase the stack depth", but "fix your laziness leak". To answer the question if Haskell has a "stack depth restriction ... like Java" the answer is no. It has a stack depth restriction, but its absolutely nothing like Java in the way it uses the stack, so you can't compare them. My guess is that Istarex's inner thought might have been along the lines of "in Java if I do too much recursion I get a stack overflow, but Haskell only has recursion, does that mean I get into stack overflows all the time?". I could of course be entirely wrong ;-) Thanks Neil

14 47

build-depends contraints in a .cabal file
by Antoine Latter 19 Feb '08

19 Feb '08

Can I specify an equality constraint in the build-depends field of a .cabal file? This would say that I want one specific version (because all the rest of my packages are compiled against that version and I'm getting type-checking errors trying to install the new package). neither > build-depends: foobar = 3.0.1 or > build-depends: foobar-3.0.1 seem to work. Do I have any choices other than re-compiling everything? Thanks, Antoine

3 2

Arrow combinator names
by Tom Davies 19 Feb '08

19 Feb '08

Are there generally accepted English language names for the arrow combinators? >>> compose? &&& pair? etc...

4 3

Doubting Haskell
by Alan Carter 19 Feb '08

19 Feb '08

Greetings Haskellers, I'm a Haskell newbie, and this post began as a scream for help. Having slept on it I find myself thinking of Simon Peyton-Jones' recent request for good use cases. Perhaps a frustrated - and doubting - newbie can also provide a data point. If my worries are unfounded (and I hope they are), I think it's significant that to me, today, they seem real enough. Please understand that I'm not being negative for the sake of it - rather I'm describing what Haskell looks like from the outside. Let me put it this way. Imagine that two weeks ago my forward-thinking and risk-embracing boss asked me to evaluate Haskell for the upcoming Project X. Further imagine that she ensured I was able to sit in the corner emitting curses for the whole two weeks, and on Monday I have to provide my report. At this point, two weeks in, I would be forced to say that I have no reason to believe that Haskell is useful for real world tasks. ghc is an industrial strength compiler for a toy language. While remarkable claims are made for it, in practice even the experts are often unable to implement the most basic behaviours, and where they are able to implement, they find that their program has become so complex that they are unable to describe or discuss the result. Likely this is a deep problem, not a shallow one. The Haskell community is in denial over this, leading to phenomenal time wasting as one goes round and round in circles playing word games with documentation. This risks a return of the chronic embuggerance that we thought we'd escaped when Vista appeared and the set of people who would have to write Windows device drivers reduced to Hewlett Packard employees, Joanna Rutkowska and criminals. When people enthuse about Haskell, we should run a program called Cat.hs from the haskell.org website, throw fruit at them and laugh. Strong words, but in all honesty I *want* to believe, and if I would make such a report I imagine hundreds if not thousands would say the same thing. I'm hoping I'm wrong about this, and what's actually needed is some work on communication (perhaps from a production programming point of view, which I'd be keen to help with). What got me started with Haskell was the video of an Intel employee holding a Teraflops in his hand. I still remember the very silly September 1991 edition of Scientific American, which asked if a Teraflops would *ever* be built. What a stupid question! Stack up enough VIC20s and eventually you'll get a Teraflops. The question should have been "when". Now it's the size of a CD, and only 80 cores are needed. Unfortunately keeping 80 cores running is tricky. I know this from writing some heavy parallel stuff in the mid-90s. It was all quite clever in it's day. Chuck bloated and unguessable CORBA, do something light with TCP/IP (Beuwolf took that to extremes). Neat linkage like rpcgen gave C, so that I could run fast on an SMP Sequent with 30 cores or on a floorfull of about 70 Sun pizza boxen at night. Unfortunately despite having a nice framework, tracing rays is still hard (the rays and medium were... interesting). Making a problem parallel required a sneaky and dedicated person's sincere skull-sweat. Worse, the solutions so produced had a horrible structural instability about them. Just a small change to the requirement could require a computed value where it wasn't needed before, so that it resulted in big changes to the implementation. The skull-sweating would be needed all over again. (Remember that the big point about objects, which e.g. Booch always emphasized, was that a well chosen set of classes maps well to the domain and so reduces such structural instability.) Even then, it was devilish hard to keep 70 "cores" busy. So watching the Intel guy got my klaxons going. We now need to be able to do parallel with ease. Functional programming just got really important. It's years since I last played with Scheme, but I quickly moved on because I could see the "which Scheme" problem becoming a millstone round everyone's necks outside of research contexts. Ditto Lisp. So Haskell. Grown-up compiler, one standard and (apparently) a decent corpus of example code and tutorials. I might be an imperative programmer, but I do lapse - for example I find it very easy to generate swathes of cross referenced documentation using m4. My head goes kind of weird after a few hours, such that m4 seems sane and it's the rest of the world that's ungainly, so maybe it should be banned like DMT, but I like it. I felt able to enter the functional world. I'll omit the first week of suffering, which I see is a well documented rite of passage. (Although most evaluators will have left the building by the end of week one so it's not helping popularity. Perhaps there could be Squires of the Lambda Calculus who haven't done the vigil, mortification of flesh and so on?) Eventually a 3 page introduction on the O'Reilly website together with a good document called "Haskell for C Programmers" got me to the point where I could access "Yet Another Haskell Tutorial", and I was away... for a bit. After a while I'd written some malformed horrors as answers to exercises, and was telling myself that it's probably just an edge effect - deep within a real Haskell program the ugliness would be invisible, tucked away in Ugly.hs. Then I discovered wxHaskell and got very excited. I really like wxWidgets, and I know it well. If I could play with some Haskell which manipulates wxWidgets I'd progress very quickly! I even have a recent C++ wxWidgets program which was annoying me as I wrote it because of the boilerplate. Great! I can play with type inference and mutter "about bloody time" with a smile on my face. Eventually I got a mix of wxWidgets 2.6.3, wxHaskell from darcs, ghc 6.6 running on my Mac, almost exactly as that permutation was described on the website, and I was off. Within a few hours I had a nice frame, with 10 text controls and legends populating it. It already took less lines than C++, and then I discovered how to bundle all the text controls into a tuple to pass them around, and define some "getters" to access the tuple. My line count shrunk to what it "should" be - that is, something Kolmogorov wouldn't laugh at but is unattainable in C++. I had an onOpen which popped up a dialog and got a filename from the user, with all the properties filled in right. I proved that I could update the values in the text controls from the onOpen. Great. Next, translate the bit that says (pseudocode): if(attempt_file_open) if(attempt_file_read) process That's it. No fancy, complex error messages. Just check the error returns and only proceed if I have something to proceed with. Like grown-ups do. I *will* check my error returns. I have tormented too many newbies to *ever* consider doing anything else. If I cannot check my error returns I will not write the program. This is production programming 101, and I suspect that there's a real issue with priorities between the traditional Haskell community and production programmers. So the time of madness began. I could find examples which did: if(attempt_file_open) attempt_file_read process Which is useless. Other examples did: attempt_file_open if(attempt_file_read) process Which is also useless. So I'm looking through the wxHaskell examples. They're all contrived, using very high level functions to (for example) read a complete image structure from a named file, which as one function had one possible source of errors. I go back to scanning and Googling like crazy. Eventually I notice a bit in "Yet Another Haskell Tutorial" - page 65 - which introduces "bracket", immediately explains that it is useless for my (very common) need, and refers the reader to Section 10 - "Advanced Techniques". The author of this excellent document hasn't yet written Section 10. I wonder why. I pause to examine bracket some more. I really can't tell if the "always" clause gets called if the initialization fails. From the use with file opening it looks like it isn't (or the handle to be closed would be invalid) but that wouldn't help if the initializer had two steps, e.g. called socket(2) and bind(2). This is the kind of thing good production programmers get really het up about. I'm still grovelling through reams of stuff, trying to find out how to open *and* read a file in a grown up way, and I find various programs on haskell.org. There's an implementation of cat(1)! That's the thing! A file concatenator must be able to open *and* read it's file. Eagerly I download it. Curiously there doesn't seem to be any error handling. I compile it and point it at a non-existent file. The program crashes. Horribly. So much for Cat.hs. I feel glad I hadn't been able to cope with the video of Simon Peyton-Jones OSCON talk, because the camera operator kept filming his face while he's gesturing at the specific line of code he's talking about with a pointer! After seeing Cat.hs do essence of FAIL just opening a file, claims that Haskell could serve as a scripting language suitable for the crew of the Black Pearl in yonder corner to use would pain me. Now I'm getting cross and turned off the whole business. I've been here before, grovelling through reams of stuff, trying to find something out while each example is contrived to side-step the problem, half-baked and useless, evasive or referencing non-existent documentation. All I need to make the experience complete is a certain firm's trademarks gratuitously embedded in the text at least once on every line. Then I'd be nauseous by now too. Finally I found an uncommented example with no discussion called Hedi. This seems to be doing exception handling, but what it is doing, how, why, what can raise them, so on and so forth would presumably be covered in the "too complex to describe" bit of "Yet Another Haskell Tutorial". I tried to understand it from first principles, looking at the Type theology for the exceptions and various calls, but while I have the cup of tea I lack the necessary Total Perspective Vortex. I felt no confidence trying to even cut and paste it. So question number one: Please - how do I do this? Somehow I doubt that wrapping the complexity of opening a file *and* reading it in a grown up way and then documenting idioms that use the wrapper would help. If it would, the wrapper and doco would already exist. That implies that the complexity doesn't stack. If I get to the point where I can open a file *and* read it in a grown up way, and then I need to (say) verify a version number from the file: if(attempt_file_open) if(attempt_file_read) if(version_ok) process Would I need to completely restructure my program? I suspect so. But it's worth bringing it up. Question number two: Might wrapping the indescribable complexity of the most basic operations make it possible to publish and discuss some idioms which accomplish them? I'd be quite happy with a voodoo idiom for now. I know someone who (20 years on) still doesn't understand pointers to functions. She still uses qsort(3) by rote, and it works for her. That will do for beginners. My biggest worry is that there's a really bad trade-off going on here. Sure, the structural instability of imperative parallel algorithms can be reduced, but at the cost of adding structural instability to everything else! TANSTAAFL and the lump in the carpet always goes somewhere. I read one chap who complained that in order to add one single line of debug he had to completely restructure his entire program, and then the line count was as big as an imperative language would be. Plus a world more complex I bet. It's this TANSTAAFL that's making me a non-believer. So question number three (rhetorical): What would have happened if Codd and Date had tried to make SQL a general purpose programming language? Sequential file handling would have been impossible for all practical purposes, so no-one would have got the benefits of set theory (oh sorry relational calculus) and our most successful intentional language would have been stillborn. We'd still be using CODASYL. Which leads to question number four: Why not do one job well? Limit parallelism to a single SMP machine where there are no comms to fail and failures which do occur will justify the OS chucking the whole process. Make an interface so that Haskell can be called from C++ or Java, with a simple IDL that can marshall nested structs, list<>s, map<>s and vector<>s in and out. Then we can get on with writing ambitious pure computations with names like sortOutRawCatScanData, tersely and in easily parallelizable ways, like we embed SQL to get certain specialist jobs done. Then when all this was going on, question number five appeared: What the hell are these "lightweight Haskell threads"? Are they some kind of green threads running non-preemptively inside a single OS thread? Are they OS threads that could run concurrently on multi-core hardware? If they are green threads (and it sounds like they are) then this is all an academic exercise which has no production application yet. I'm still hoping that this is solvable. That the instinctive priorities of production programmers are just different to those of researchers, and in fact it *is* possible to open a file *and* read it, checking *both* error returns, without being driven insane. If so, I sincerely suggest an example or two, like the small but well formed programs in K&R, Stroustrup or Gosling saying things like: if((fp = fopen(...)) != NULL) { if(fgets(...) != NULL) { printf(...); } fclose(...) } Best wishes - and still hoping I'm wrong after all Alan Carter -- ... the PA system was moaning unctuously, like a lady hippopotamus reading A. E. Housman ..." -- James Blish, "They Shall Have Stars"

20 30

naming a data structure for weighted random selection without replacement
by Stuart Cook 19 Feb '08

19 Feb '08

A while ago I wrote a little data structure that allows weighted random selection-without-replacement from a collection of values in O(log n) time.[1] I'm now in the process of packaging it up for Hackage, but I'm looking for good names for both the type and its operations. The name I have at the moment is "Pool", which I'm reasonably happy with, but I wanted to see if I could find anything better. Asking on #haskell got me a few responses: * Hat (cute, but conflicts with the program tracer) * Bag (already way too overloaded) * Bucket (not as suggestive as Pool) I have three main operations: * "pull" selects a random element, returning it and the remainder, but fails if the pool is empty * "pullN" selects /n/ distinct elements, returning them and the remainder, but fails if the pool has too few elements * "takeN" selects up to /n/ distinct elements, returning them and the remainder, but returns no more elements than could be found in the pool (analogous to Data.List.take) Any suggestions? Stuart [1] Actually I delegated most of the work to the data-structure-in-a-can that is Data.FingerTree, but that's another story.

6 6

Working with multiple time zones
by Dave Hinton 18 Feb '08

18 Feb '08

(This is a toy program to demonstrate only the part of my real program that I'm having trouble with.) Suppose I'm writing a program to print the current time in various time zones. The time zones are to be given symbolically on the command line in the form "Europe/London" or "America/New_York". The idea is that either the operating system or the runtime library keeps track of what time zones different places are in, and when they are on summer time, so that my code doesn't have to worry about it. Haskell has a TimeZone type in Data.Time.LocalTime, but it only represents constant offsets from UTC — doesn't encode rules for when the clocks change. And there doesn't seem to be any way of looking up the time zone for a locality. Data.Time.LocalTime has the getTimeZone function, which returns the time zone for a given UTC time on the local machine — this takes care of summer time, but by itself only works for the local machine's locality. If I was writing this program in C, I'd get round this by setting the TZ environment variable to the locality I was interested in before doing time conversions. $ cat cnow.c #include <stdio.h> #include <stdlib.h> #include <string.h> #include <time.h> void outTime (time_t utc, char *tzName) { char env[100] = "TZ="; strcat (env, tzName); putenv (env); printf ("%s\t%s", tzName, asctime (localtime (&utc))); } int main (int argc, char **argv) { int i; time_t utc = time (NULL); for (i = 1; i < argc; ++i) outTime (utc, argv[i]); return 0; } $ gcc cnow.c -o cnow $ ./cnow Europe/Paris Europe/Moscow Europe/London Europe/Paris Sat Feb 16 23:57:22 2008 Europe/Moscow Sun Feb 17 01:57:22 2008 Europe/London Sat Feb 16 22:57:22 2008 So far, so good. Here's the equivalent in Haskell: $ cat hsnow.hs import Data.Time import Data.Time.LocalTime import System.Environment import System.Posix.Env outTime utc env = do putEnv ("TZ=" ++ env) tz <- getTimeZone utc putStrLn (env ++ "\t" ++ show (utcToLocalTime tz utc)) main = do utc <- getCurrentTime mapM_ (outTime utc) =<< getArgs $ ghc --make hsnow.hs -o hsnow [1 of 1] Compiling Main ( hsnow.hs, hsnow.o ) Linking hsnow ... $ ./hsnow Europe/Paris Europe/Moscow Europe/London Europe/Paris 2008-02-16 23:59:11.776151 Europe/Moscow 2008-02-16 23:59:11.776151 Europe/London 2008-02-16 23:59:11.776151 $ ./hsnow Europe/Moscow Europe/London Europe/Paris Europe/Moscow 2008-02-17 01:59:28.617711 Europe/London 2008-02-17 01:59:28.617711 Europe/Paris 2008-02-17 01:59:28.617711 Not good. GHC's runtime library seems to be taking the value of TZ the first time it is called as gospel, and ignoring subsequent changes to TZ. So: 1. Is this a bug in GHC's Data.Time.LocalTime.getTimeZone? 2. If GHC's implementation is working as designed, how do I translate the C program above into Haskell? I'm running on Debian stable, with GHC 6.6. Thanks.

8 9

Haskell Thrift bindings
by Dave Tapley 18 Feb '08

18 Feb '08

Hi everyone, This is regarding Thrift, "a software framework for scalable cross-language services development"(1) Present in the release tarball there is some source for Haskell but no sign of a tutorial or any sample code. I'm just picking through but as a long shot does anyone have examples they could send me? I'm also looking to put together a page on haskellwiki once I'm up and running. The project seems like a fine way to sneak Haskell into existing project ;) Cheers, Dave (1) http://developers.facebook.com/thrift/

1 0

More powerful error handling
by Philippa Cowderoy 18 Feb '08

18 Feb '08

For a while I've been meaning to propose something along the lines of this class: class (MonadError m e, MonadError m' e') => MonadErrorRelated m e m' e' | m -> e, m' -> e', m e' -> m' where catch' :: m a -> (e -> m' a) -> m' a rethrow :: m a -> (e -> e') -> m' a with an example instance being: instance (Error e, Error e') => MonadErrorRelated (Either e) e (Either e') e' where catch' (Right v) _ = Right v catch' (Left e) h = h e rethrow c ef = catch' c (throw . ef) (yep, that definition of rethrow would make a sensible default and there's a default catch' in terms of rethrow too) The nicest use would be for converting between a more specific error type and a more general one that handles a wider range of errors - enabling us to keep tighter track of which errors are possible in a given piece of code. Bonus points for using it together with polymorphic variants where rethrow becomes rather trivial. The following two functions or close variants might also be useful: catchMaybe :: (MonadError m ()) => Maybe a -> m a catchMaybe Nothing = throwError () catchMaybe (Just a) = return a catchEither :: (MonadError m e) => Either e a -> m a catchEither (Left err) = throwError err catchEither (Right a) = return a No doubt there are some names that could use tweaking. As far as I'm concerned you can count me in the camp of people that resent the existing MonadError instances all requiring an Error instance too, it makes things messier when you have access to something like this. But I guess that's because fail is begging for the following definition: fail = fail -- fail is made of fail -- flippa(a)flippac.org There is no magic bullet. There are, however, plenty of bullets that magically home in on feet when not used in exactly the right circumstances.

2 1

problem with collection (container) class
by Leandro Demarco Vedelago 18 Feb '08

18 Feb '08

Hi! I'm pretty (not to say very) new to haskell and i've to create a new class named container that includes types that hold other values, more specific, i have "created" this two types: data Abb a b = Branch a b (Abb a b) (Abb a b) | Leaf and data ListAssoc a b = Node a b (ListAssoc a b) | Empty and implemented some common functions (add, search, delete, empty,etc). So when I was asked to create this new class I crashed against a big problem, or at least for me. My first attempt was: class Container c where empty :: c but when I had to implement "add" I tried add :: c -> a -> b -> c although I was almost sure that it wouldn't work, so I realized that I had to give Container not one but three parameters, the container and the types of values that the container saved so I started searching and I found similar cases, but the difference iis that in this cases the class was defined as follows: class Container c e | c->e where empty :: c insert :: c -> e -> c member :: c -> e -> Bool but my particular problem here is that the types I designed hold two values of different type and these holds just one value. Besides I knew nothing about functional dependency used in here and I keep knowing almost nothing about them, but I tried something like this: class Container c a b |c -> a, c -> b where empty :: c add :: c -> a -> c search :: c -> a -> Maybe b del :: c -> a -> c toListPair :: c -> [(a,b)] instance Container Abb a b where empty = Leaf add Leaf x y = Branch x y Leaf Leaf add arb@(Branch ni nd ri rd) x y |x == ni = arb |x > ni = Branch ni nd ri (add rd x y) |otherwise = Branch ni nd (add ri x y) rd search Leaf x = Nothing search (Branch ni nd ri rd) x |x == ni = Just nd |x > ni = search rd x |x < ni = search ri x but when I try to load it in WinHugs I get the following error message: - Instance is more general than a dependency allows *** Instance : Container Abb a b *** For class : Container a b c *** Under dependency : a -> b and as I have stated above my knowledge about dependencies is almost null, not to say null, so I don´t even have an idea where the error is. A suggestion that I've received was to change the type of Abb for data Abb (a,b) = Branch a b (Abb (a,b)) (Abb (a,b)) | Leaf and declare container class with just two parameters like I found in all pages I visited. I have not tried this yet, as I still have hope that what I intend to do is possible. Well if you have any suggestions I'd appreciate you send it to me and sorry for bothering you and my english, but i'm "spanish-speaker".

4 4