[Haskell-cafe] Re: Status of TypeDirectedNameResolution proposal?
On Nov 18, 9:49 pm, Robert Greayer robgrea...@gmail.com wrote:
On Wed, Nov 18, 2009 at 3:10 PM, levi greenspan.l...@googlemail.com wrote:
On Nov 18, 8:18 pm, Luke Palmer lrpal...@gmail.com wrote:
You know, another solution to the records problem, which is not quite
as convenient but much simpler (and has other applications) is to
allow local modules.
module Foo where
module Bar where
data Bar = Bar { x :: Int, y :: Int }
module Baz where
data Baz = Baz { x :: Int, y :: Int }
f a b = Bar.x a + Baz.y b
+1
Independent of TDNR I would welcome this. Maybe Ticket 2551 (Allow
multiple modules per source file) [1] should be reconsidered.
Although ticket 2551 is not exactly what Luke is suggesting (which would be
an extension to the language, whereas, if I'm not mistaken, 2551 is just a
change to where GHC can find modules, not nesting of modules).
Right. Given the mixed replies to TDNR here so far I wonder if there
is any chance of at least getting some support for this ticket or
maybe even for the nested modules proposal? The current situation
w.r.t. records is really no fun.
Cheers,
Levi
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
|* General Type Directed Name Resolution (GTDNR): |For every function application f x in the program where f is a |name, f is resolved based on the type of the argument x. | ... | You suggest that GTDNR might not be a good idea, well why not? One | reason is that it can potentially lead to a whole lot of guessing, | slowing the compiler down dramatically and maybe even so much guessing | that there are multiple whole-program resolutions (oh noes!). So how can | we control that combinatorial exploration of alternatives? One way would | be to restrict the places where we allow guessing. There's still | potential room for combinatorial explosions but they're greatly reduced, | both because we reduce the number of variables in the problem (so the | combinatorics are smaller), and because we (generally) will have a good | deal of non-variable context to anchor the disambiguation process and | hopefully resolve the variables easily. Yes. I'm confident that GTDNR is not viable. The TDNR proposal is carefully constrained to give a uni-directional information flow from the record field to select the function. I don't think that the vastly more general idea you propose is going to work when combined with ordinary HM type inference, type classes, type functions, etc etc. Of course, I could be wrong. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: gnome-keyring 0.1 (bindings to libgnome-keyring)
jmillikin wrote: The GNOME Keyring is a service for securely storing per-user secret information, such as passwords and encryption keys, on the GNOME desktop. This library is a binding to the libgnome-keyring C library. The API is still a bit too slave-ish to the original for my taste, some modules will be changing/merging in the next version. The innards are an absolute horror -- don't look too close if you're one of those people who faint at rampant unsafe casting. That said, it works surprisingly well for a first-release FFI binding -- mostly due to the excellent design of libgnome-keyring and c2hs. So if any Linux/BSD/OpenSolaris/etc users have needed secure password storage in Haskell, please try it out and let me know if you encounter any problems. Download: http://hackage.haskell.org/package/gnome-keyring/ API docs (copy of original library docs): https://dl.dropbox.com/u/1947532/gnome-keyring_0.1/index.html Thank you so much, John! Just yesterday I started learning c2hs and even succeeded in importing is_available and result_to_message from libgnome-keyring %) I will use your bindings now, they look much better than what I would come up with! I opened a ticket [1] at gtk2hs a month ago, I guess it can be closed now unless you are interested in integrating with gtk2hs. Despite the name, they have a bunch of GNOME bindings: gstreamer, gio, vfs, gconf, etc. Cheers, Alex [1] http://hackage.haskell.org/trac/gtk2hs/ticket/1176 -- View this message in context: http://old.nabble.com/ANNOUNCE%3A-gnome-keyring-0.1-%28bindings-to-libgnome-keyring%29-tp26383498p26438749.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: Haskell Communities and Activities Report (17th ed., November 2009)
On behalf of the many, many contributors, I am pleased to announce that the Haskell Communities and Activities Report (17th edition, November 2009) http://www.haskell.org/communities/ is now available from the Haskell Communities home page in PDF and HTML formats. Many thanks go to all the people that contributed to this report, both directly, by sending in descriptions, and indirectly, by doing all the interesting things that are reported. I hope you will find it as interesting a read as I did. If you have not encountered the Haskell Communities and Activities Reports before, you may like to know that the first of these reports was published in November 2001. Their goal is to improve the communication between the increasingly diverse groups, projects, and individuals working on, with, or inspired by Haskell. The idea behind these reports is simple: Every six months, a call goes out to all of you enjoying Haskell to contribute brief summaries of your own area of work. Many of you respond (eagerly, unprompted, and sometimes in time for the actual deadline ;-) to the call. The editor collects all the contributions into a single report and feeds that back to the community. When I try for the next update, six months from now, you might want to report on your own work, project, research area or group as well. So, please put the following into your diaries now: End of April 2010: target deadline for contributions to the May 2010 edition of the HCA Report Unfortunately, many Haskellers working on interesting projects are so busy with their work that they seem to have lost the time to follow the Haskell related mailing lists and newsgroups, and have trouble even finding time to report on their work. If you are a member, user or friend of a project so burdened, please find someone willing to make time to report and ask them to register with the editor for a simple e-mail reminder in October (you could point me to them as well, and I can then politely ask if they want to contribute, but it might work better if you do the initial asking). Of course, they will still have to find the ten to fifteen minutes to draw up their report, but maybe we can increase our coverage of all that is going on in the community. Feel free to circulate this announcement further in order to reach people who might otherwise not see it. Enjoy! Janis Voigtlaender hcar at haskell.org -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:j...@iai.uni-bonn.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Graph drawing library for Haskell
Hi, Anyone knows a good library for graph diagram drawing? Or a haskell binding for one? Something like jgraph. http://www.jgraph.com/jgraph.html []s' Victor -- GNU/Linux user #446397 - http://counter.li.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graph drawing library for Haskell
I have had some luck with the graphviz (dotter) bindings for drawing node/ark graphs. It's not an ideal solution, and will require some wrappers to bind to your data structures, but it does work. Matthew 2009/11/20 Victor Mateus Oliveira rhapso...@gmail.com Hi, Anyone knows a good library for graph diagram drawing? Or a haskell binding for one? Something like jgraph. http://www.jgraph.com/jgraph.html []s' Victor -- GNU/Linux user #446397 - http://counter.li.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graph drawing library for Haskell
On Fri, Nov 20, 2009 at 1:57 PM, Victor Mateus Oliveira rhapso...@gmail.com wrote: Hi, Anyone knows a good library for graph diagram drawing? Or a haskell binding for one? Something like jgraph. http://www.jgraph.com/jgraph.html I usually turn to graphviz for my Haskell graphing needs. /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
GTDNR is what I really want anyway... whether or not it's possible. :-) At any given time, importing everything unqualified from every module used by a typical hs leads only to a handful of ambiguities. While the general case might be intractable, real-world cases might be trivial. Regards, John On Nov 19, 2009, at 11:13 PM, wren ng thornton wrote: Twan van Laarhoven wrote: My point is that desugaring x.f to (f x) and treating some instances of (f x) as (ModuleToGuess.f x) are two separate things. In the current proposal these two are combined, but I see no reason to do so. To be a bit more concrete, I would propose: * General Type Directed Name Resolution (GTDNR): For every function application f x in the program where f is a name, f is resolved based on the type of the argument x. Note that I am not saying that this is necessarily a good idea, it is just a possible alternative to the current TDNR proposal. I'm not a big fan of any of the TDNR proposals I've seen (I think we still haven't found the right way to do it without it being just a hack), but I can give one good reason for why these two parts of the proposal are grouped together. You suggest that GTDNR might not be a good idea, well why not? One reason is that it can potentially lead to a whole lot of guessing, slowing the compiler down dramatically and maybe even so much guessing that there are multiple whole-program resolutions (oh noes!). So how can we control that combinatorial exploration of alternatives? One way would be to restrict the places where we allow guessing. There's still potential room for combinatorial explosions but they're greatly reduced, both because we reduce the number of variables in the problem (so the combinatorics are smaller), and because we (generally) will have a good deal of non-variable context to anchor the disambiguation process and hopefully resolve the variables easily. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: bindings-SDL 1.0.2, the domain specific language for FFI description
Maurício CA wrote: I believe I forgot to write a section with that information, as well as others one would like to know from start. I wrote a new section trying to fix that in 'how to use it' topic. http://bitbucket.org/mauricio/bindings-dsl/wiki/HowToUseIt Very nice. I think that is clear enough. I'm not sure I have already got to a point where documentation is clear and complete enough but not too long and boring. If you also thing some parts of documentation were not helpful, or if more is missing, please let me know. Quite the contrary, with that one exception, I found the documentation to be among some of the best I have used. I especially like the numerous examples you included. - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Status of TypeDirectedNameResolution proposal?
You know, another solution to the records problem, which is not quite
as convenient but much simpler (and has other applications) is to
allow local modules.
module Foo where
module Bar where
data Bar = Bar { x :: Int, y :: Int }
module Baz where
data Baz = Baz { x :: Int, y :: Int }
f a b = Bar.x a + Baz.y b
For someone coming from an SML background, that makes a lot of sense.
You could also add an automatic lightweight module, like Agda does,
where
data Baz = Node { x :: Int, y :: Int }
implicitly defines a local module Baz with record selection functions
Baz.x and Baz.y and even a Baz.Node constructor.
Stefan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Iteratee question
I am writing a binary data parser and use `iteratee' package. The following pattern appears quite often in my code: results - map someConversion `liftM` replicateM nbytes Iter.head The meaning is: take `nbytes' from stream, apply `someConversion' to every byte and return the list of `results'. But there's more than one way to do it[1]: i1, i2, i3 :: Monad m = Int - IterateeG [] Word8 m [String] i1 n = map conv `liftM` replicateM n Iter.head i2 n = map conv `liftM` joinI (Iter.take n stream2list) i3 n = joinI $ Iter.take n $ joinI $ mapStream conv stream2list [1] http://en.wikipedia.org/wiki/There's_more_than_one_way_to_do_it If you try the program[2] I've hpasted, you will see that these three iteratees have equal results. [2] http://hpaste.org/fastcgi/hpaste.fcgi/view?id=12464#a12464 Of those i1, i2, i3 which one is better and why? Or is there another - preferable - way of applying iteratees to this task? My naïve guess is that i1 will have worse performance with big n's. It looks like `i1' is reading bytes one by one, while `i2' takes whole chunks of data... I'm not sure though. I would appreciate it a lot if you improve my understanding. -- vvv ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graph drawing library for Haskell
I've written a simple incomplete binding to graphviz-as-a-library to do in-process graphviz layouts, though I would say it's hardly complete so I haven't released it. If it's useful to someone and they want to put in some additional elbow grease to make the particular features they want work, I can throw it up somewhere. -Ross On Nov 20, 2009, at 9:00 AM, Magnus Therning wrote: On Fri, Nov 20, 2009 at 1:57 PM, Victor Mateus Oliveira rhapso...@gmail.com wrote: Hi, Anyone knows a good library for graph diagram drawing? Or a haskell binding for one? Something like jgraph. http://www.jgraph.com/jgraph.html I usually turn to graphviz for my Haskell graphing needs. /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graph drawing library for Haskell
I'm looking for something more integrated with a gui library. The jgraph integrates with swing, so you can move, create, delete, have popup menus, select nodes, and so on. I haven't found yet.. If there isn't, I thinking in create one lib with wxHaskell using wxDC... But by now, I really prefer to use one existing library. []s Victor On Fri, Nov 20, 2009 at 12:00 PM, Magnus Therning mag...@therning.org wrote: On Fri, Nov 20, 2009 at 1:57 PM, Victor Mateus Oliveira rhapso...@gmail.com wrote: Hi, Anyone knows a good library for graph diagram drawing? Or a haskell binding for one? Something like jgraph. http://www.jgraph.com/jgraph.html I usually turn to graphviz for my Haskell graphing needs. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe -- GNU/Linux user #446397 - http://counter.li.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: gnome-keyring 0.1 (bindings to libgnome-keyring)
I'm not keen on gtk2hs in general -- it's quite monolithic, which makes it difficult to 1) install (via Cabal) and 2) develop. Ideally, GTK+ bindings would be available on Hackage in separate packages (like gtk, gnome-vfs, gconf, etc), and would be developed in separate repositories to avoid lockstep. Luckily, libgnome-keyring doesn't have many glib-isms in its API, so I could treat it as a mostly standalone library. On Fri, Nov 20, 2009 at 03:12, Alexander Kojevnikov alexan...@kojevnikov.com wrote: jmillikin wrote: The GNOME Keyring is a service for securely storing per-user secret information, such as passwords and encryption keys, on the GNOME desktop. This library is a binding to the libgnome-keyring C library. The API is still a bit too slave-ish to the original for my taste, some modules will be changing/merging in the next version. The innards are an absolute horror -- don't look too close if you're one of those people who faint at rampant unsafe casting. That said, it works surprisingly well for a first-release FFI binding -- mostly due to the excellent design of libgnome-keyring and c2hs. So if any Linux/BSD/OpenSolaris/etc users have needed secure password storage in Haskell, please try it out and let me know if you encounter any problems. Download: http://hackage.haskell.org/package/gnome-keyring/ API docs (copy of original library docs): https://dl.dropbox.com/u/1947532/gnome-keyring_0.1/index.html Thank you so much, John! Just yesterday I started learning c2hs and even succeeded in importing is_available and result_to_message from libgnome-keyring %) I will use your bindings now, they look much better than what I would come up with! I opened a ticket [1] at gtk2hs a month ago, I guess it can be closed now unless you are interested in integrating with gtk2hs. Despite the name, they have a bunch of GNOME bindings: gstreamer, gio, vfs, gconf, etc. Cheers, Alex [1] http://hackage.haskell.org/trac/gtk2hs/ticket/1176 -- View this message in context: http://old.nabble.com/ANNOUNCE%3A-gnome-keyring-0.1-%28bindings-to-libgnome-keyring%29-tp26383498p26438749.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Applicative Functor or Idiom?
After reading several recent papers I came to the understanding that there isn't consensus on the name of Applicative Functors. Several prefer to call them idioms: 'Idiom' was the name McBride originally chose, but he and Paterson now favour the less evocative term `applicative functor'. We have a slight preference for the former, not least because it lends itself nicely to adjectival uses, as in `idiomatic traversal'[1] I also noticed use of the term Idiom in [2], [3], and [4]. I'm writing a set of classes that includes AF's and I'm trying to decide whether to call the class Idiom. Anyone have more information on this question? David [1] Gibbons, J. and Oliveira, B. c. 2009. The essence of the iterator pattern. J. Funct. Program. 19, 3-4 (Jul. 2009), 377-402. DOI= http://dx.doi.org/10.1017/S0956796809007291 [2] RALF HINZE (2009). The Bird Tree. Journal of Functional Programming, 19 , pp 491-508 doi:10.1017/S0956796809990116 [3] S. Lindley, P. Wadler, and J. Yallop. Idioms are oblivious, arrows are meticulous, monads are promiscuous. In Proc. of MSFP, 2008. [4] The Arrow Calculus, Sam Lindley, Philip Wadler, and Jeremy Yallop. Tech report, 2008. -- David Sankel Sankel Software www.sankelsoftware.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Applicative Functor or Idiom?
David Sankel wrote: After reading several recent papers I came to the understanding that there isn't consensus on the name of Applicative Functors. Several prefer to call them idioms: 'Idiom' was the name McBride originally chose, but he and Paterson now favour the less evocative term `applicative functor'. We have a slight preference for the former, not least because it lends itself nicely to adjectival uses, as in `idiomatic traversal'[1] I also noticed use of the term Idiom in [2], [3], and [4]. I much prefer the name Applicative Functor, because 'idiom' and especially 'idiomatic' can mean lots of other things (just look up the word in a dictionary!). While an applicative functor is always a functor with 'pure' and 'ap' operations. I'm writing a set of classes that includes AF's and I'm trying to decide whether to call the class Idiom. Anyone have more information on this question? Why are you writing your own? How do your classes differ from the standard Control.Applicative? Twan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Applicative Functor or Idiom?
On Fri, Nov 20, 2009 at 2:58 PM, Twan van Laarhoven twa...@gmail.com wrote: David Sankel wrote: I'm writing a set of classes that includes AF's and I'm trying to decide whether to call the class Idiom. Anyone have more information on this question? Why are you writing your own? How do your classes differ from the standard Control.Applicative? I'm writing them for a different language. Same meanings though. David -- David Sankel Sankel Software www.sankelsoftware.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graph drawing library for Haskell
Victor Mateus Oliveira wrote: I'm looking for something more integrated with a gui library. The jgraph integrates with swing, so you can move, create, delete, have popup menus, select nodes, and so on. I haven't found yet.. If there isn't, I thinking in create one lib with wxHaskell using wxDC... But by now, I really prefer to use one existing library. How about Tom Docker's Chart library: http://hackage.haskell.org/package/Chart Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fwd: [BostonHaskell] Next meeting: November 24th at MIT (32-G882)
-- Forwarded message -- From: Ravi Nanavati rav...@alum.mit.edu Date: Fri, Nov 20, 2009 at 4:00 PM Subject: Next meeting: November 24th at MIT (32-G882) To: bostonhask...@googlegroups.com I'm pleased to announce the November meeting of the Boston Area Haskell Users' Group. Based on the available days remaining in November, the meeting has been scheduled for Tuesday, November 24th from 6:30pm to 8:30pm. Like recent meetings, it will be held in the MIT CSAIL Reading Room (32-G882, i.e. a room on the 8th floor of the Gates Tower of the MIT's Stata Center at 32 Vassar St in Cambridge, MA). Based on the response to my previous message, I'm developing a QuickCheck-focused joint programming exercise. If anyone wants to help with that, I'd appreciate it (since I'm trying to pull this together at the last minute). My plan is to introduce QuickCheck and start with a couple of warm-up exercises before our traditional break. After the break I'd like to use QuickCheck to find a subtle bug or two in some interesting, nontrivial (but not too large or complicated) Haskell program. I've found some introductory material to use as a starting point, but I don't have the right sort of Haskell program handy. If anyone has an interesting Haskell program they can share that is a good fit for this exercise, please let me know (the sooner the better). Since the meeting is going to be focused on a programming exercise, I don't think we'll have room for any larger presentations (at least based on our experience at the September meeting), but I'm there will be room for lightning talks or other advertisements if anyone has an interest in doing that. The November attendance poll is at: http://doodle.com/hyv5a76ib6untwtp As always, responding to this poll will help with two things: 1. Getting an idea of what fraction of the Boston-area Haskell community can and can't attend this meeting (to help with future scheduling). 2. Giving me an estimated count of attendees, since I have talked my wife into baking some more goodies and bringing drinks again. Helping with BostonHaskell (besides volunteering to speak at future meetings): 1. Sponsorship of refreshments is still being eagerly solicited (especially as, for personal reasons, the Cupcake Fund is running low). 2. Please let me know if you're willing to arrive early (6pm) to stand by the door and let people into the 8th floor. I'm guessing 1 or 2 volunteers is enough here. 3. If someone is willing to edit the HaskellWiki page, post to reddit or otherwise publicize the meeting please just go ahead and do that (especially as I'm sending this out a bit later than intended). If you have any questions about the meeting please send them to them BostonHaskell mailing list: bostonhask...@googlegroups.com or contact me directly. I look forward to seeing many Boston-area Haskellers at the November meeting! Thank you, - Ravi Nanavati ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: inversion lists
On Thu, 19 Nov 2009 04:54:13 +0100 Daniel Fischer daniel.is.fisc...@web.de wrote: DF h :: Num a = a - [a] - [a] DF h x (y:ys) DF | x+1 == y = x:ys DF h x zs = x:(x+1):zs DF invlist = foldr h [] ghci invlist [2,3,4,5,8,9,10] DF [2,6,8,11] ghci invlist [4] DF [4,5] ghci invlist [1,2,3,4,7,8,9,13,14,15,20,22] DF [1,5,7,10,13,16,20,21,22,23] That's nice, thanks for the elegant code. I was hoping to make it work lazily with foldl, if you have the interest in implementing it that way. I tried but failed (no, you can't see my attempt :) A nice property of inversion lists is that inverting them simply requires removing or adding the minimum possible value at the beginning of the list. A membership test requires traversal but since the list is sorted we know when to stop if it doesn't exist. Set union and difference are pretty tricky but at least can stop early if one of two sets is finite. As I learn more Haskell I'll try implementing these step by step. Is there any interest in making this an actual module or is it not very useful in the context of Haskell? Thanks Ted ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
