Hi Sebastian Sylvan, Thank you very much! I thick the last column return a string because of the Haskell "Show" function, for when I made test, I got such an error message: Show ([SqlValue] -> IO [[SqlValue]]). Any way, thank you very much!
Deng Chao 在 2008-03-22六的 13:55 [EMAIL PROTECTED] > Send Haskell-Cafe mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.haskell.org/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > > > Today's Topics: > > 1. compile error with FFI code (Galchin Vasili) > 2. "doctest" for haskell -- a good project? (Shaun Cutts) > 3. Re: [GSoC] Plugins for GHC (Bulat Ziganshin) > 4. Re: "doctest" for haskell -- a good project? (Roman Cheplyaka) > 5. Re: "doctest" for haskell -- a good project? (Don Stewart) > 6. Re: [GSoC] Plugins for GHC (Neil Mitchell) > 7. Re: "doctest" for haskell -- a good project? (Neil Mitchell) > 8. Re: An ugly zip3 problem.. (Michael Feathers) > 9. Re: An ugly zip3 problem.. (Michael Feathers) > 10. How to program with sqlite? (Deng Chao) > 11. Re: "doctest" for haskell -- a good project? (Thomas Schilling) > 12. Re: How to program with sqlite? (Sebastian Sylvan) > 13. Re: "doctest" for haskell -- a good project? (Sebastian Sylvan) > 14. HXT and types in Control.Arrow.ArrowTree (Robert Vollmert) > 15. Opening Windows .lnk Files (Dominic Steinitz) > 16. RE: "doctest" for haskell -- a good project? (Shaun Cutts) > 17. Re: An ugly zip3 problem.. (Bryan O'Sullivan) > 18. Re: "doctest" for haskell -- a good project? (Paul Johnson) > 19. Re: AMQP framing layer: design help requested. (Paul Johnson) > 20. Re: Problem with OpenAL (Antoine Latter) > 21. Re: AMQP framing layer: design help requested. (Derek Elkins) > 22. Re: Opening Windows .lnk Files (Neil Mitchell) > 23. Re: "doctest" for haskell -- a good project? (Neil Mitchell) > 24. Re: Opening Windows .lnk Files (Dominic Steinitz) > 25. RE: "doctest" for haskell -- a good project? (Shaun Cutts) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 21 Mar 2008 23:21:26 -0500 > From: "Galchin Vasili" <[EMAIL PROTECTED]> > Subject: [Haskell-cafe] compile error with FFI code > To: Haskell-cafe <[email protected]> > Cc: Galchin Vasili <[EMAIL PROTECTED]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > Hello, > > In my blah.hsc, I have "allocbytes (#const (struct bozo)) .. where > > struct bozo is a bunch of "long int" ,,, In the "runhaskell Setup.hs build" > step I get a nasty error message about an "incomplete type". I have look at > many times but this error doesn't make sense to me. ?? > > Kind regards, Vasili > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://www.haskell.org/pipermail/haskell-cafe/attachments/20080321/273d5ca0/attachment-0001.htm > > ------------------------------ > > Message: 2 > Date: Sat, 22 Mar 2008 02:20:38 -0400 > From: "Shaun Cutts" <[EMAIL PROTECTED]> > Subject: [Haskell-cafe] "doctest" for haskell -- a good project? > To: <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > Hello, > > I am an experienced programmer, currently learning Haskell. Currently I > write many things in python. I use both the "doctest" and "unittest" modules > extensively. As I write code, I simultaneously write doctest code in the doc > strings to explain/set out the "typical narrative" of how the code is used. > Then finishing off a module I write unittests for boundary conditions, more > complex test cases, and generally code that would be annoying to write & > read in doctests. > > I note that there is a unit testing framework for Haskell, but I don't see > any doctest module. Might this be a good project? > > If so, suggestions as to resources would be greatly appreciated. I believe I > can't just "introspect" Haskell modules to get at documentation/comments, > like I can in python? (Why not? :)) I notice that there are a few > "documentation generators". Should I try to write an extension of one of > these? Haddock, for instance? Are there any Haddock developers hanging out > on this list, to encourage or dissuade me? :) (And where is the Haddock doc > for Haddock?) > > In any case, thanks in advance for any comments & advice. > > - Shaun Cutts > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://www.haskell.org/pipermail/haskell-cafe/attachments/20080322/185fb821/attachment-0001.htm > > ------------------------------ > > Message: 3 > Date: Sat, 22 Mar 2008 10:08:50 +0300 > From: Bulat Ziganshin <[EMAIL PROTECTED]> > Subject: Re: [Haskell-cafe] [GSoC] Plugins for GHC > To: "Max Bolingbroke" <[EMAIL PROTECTED]> > Cc: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > Hello Max, > > Saturday, March 22, 2008, 1:23:37 AM, you wrote: > > > around with modifying GHC itself. Potential use cases are: > > * And whatever clever ideas the community comes up with! > > i'm interested in syntax macros feature like metalua > > > -- > Best regards, > Bulat mailto:[EMAIL PROTECTED] > > > > ------------------------------ > > Message: 4 > Date: Sat, 22 Mar 2008 10:29:33 +0200 > From: Roman Cheplyaka <[EMAIL PROTECTED]> > Subject: Re: [Haskell-cafe] "doctest" for haskell -- a good project? > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > * Shaun Cutts <[EMAIL PROTECTED]> [2008-03-22 02:20:38-0400] > > Hello, > > > > I am an experienced programmer, currently learning Haskell. Currently I > > write many things in python. I use both the "doctest" and "unittest" modules > > extensively. As I write code, I simultaneously write doctest code in the doc > > strings to explain/set out the "typical narrative" of how the code is used. > > Then finishing off a module I write unittests for boundary conditions, more > > complex test cases, and generally code that would be annoying to write & > > read in doctests. > > > > I note that there is a unit testing framework for Haskell, but I don't see > > any doctest module. Might this be a good project? > > > > If so, suggestions as to resources would be greatly appreciated. I believe I > > can't just "introspect" Haskell modules to get at documentation/comments, > > like I can in python? (Why not? :)) I notice that there are a few > > "documentation generators". Should I try to write an extension of one of > > these? Haddock, for instance? Are there any Haddock developers hanging out > > on this list, to encourage or dissuade me? :) (And where is the Haddock doc > > for Haddock?) > > > > In any case, thanks in advance for any comments & advice. > > > > - Shaun Cutts > > > Did you try haddock? > > -- > Roman I. Cheplyaka :: http://ro-che.info/ > ...being in love is totally punk rock... > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 307 bytes > Desc: Digital signature > Url : > http://www.haskell.org/pipermail/haskell-cafe/attachments/20080322/0a310583/attachment-0001.bin > > ------------------------------ > > Message: 5 > Date: Sat, 22 Mar 2008 01:39:44 -0700 > From: Don Stewart <[EMAIL PROTECTED]> > Subject: Re: [Haskell-cafe] "doctest" for haskell -- a good project? > To: Shaun Cutts <[EMAIL PROTECTED]> > Cc: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > shaun: > > Hello, > > > > I am an experienced programmer, currently learning Haskell. Currently I > > write many things in python. I use both the "doctest" and "unittest" > > modules extensively. As I write code, I simultaneously write doctest code > > in the doc strings to explain/set out the "typical narrative" of how the > > code is used. Then finishing off a module I write unittests for boundary > > conditions, more complex test cases, and generally code that would be > > annoying to write & read in doctests. > > > > I note that there is a unit testing framework for Haskell, but I don't > > see > > There's a couple, QuickCheck is the best, it generalises unit testing to > property testing with random, or not so random, data. > > > any doctest module. Might this be a good project? > > If so, suggestions as to resources would be greatly appreciated. I > > believe > > I can't just "introspect" Haskell modules to get at > > documentation/comments, like I can in python? (Why not? :)) I notice that > > there are a few "documentation generators". Should I try to write an > > extension of one of these? Haddock, for instance? Are there any Haddock > > developers hanging out on this list, to encourage or dissuade me? :) (And > > where is the Haddock doc for Haddock?) > > > > In any case, thanks in advance for any comments & advice. > > I'm not sure how doctest works, or how it would work in a Haskell > setting, could you elaborate? > > One idea that does strike me is that it would be super useful to have > the ability in ghci to extract the haddocks associated with a function. > > > :doc map > > would result in: > > -- | 'map' @f xs@ is the list obtained by applying @f@ to each element > -- of @xs@, i.e., > -- > -- > map f [x1, x2, ..., xn] == [f x1, f x2, .. > -- > map f [x1, x2, ...] == [f x1, f x2, ...] > > marked up in ascii. > > I'm not sure if that's related to doctest, but it sure would be useful! > > -- Don > > > ------------------------------ > > Message: 6 > Date: Sat, 22 Mar 2008 12:15:26 +0000 > From: "Neil Mitchell" <[EMAIL PROTECTED]> > Subject: Re: [Haskell-cafe] [GSoC] Plugins for GHC > To: "Max Bolingbroke" <[EMAIL PROTECTED]> > Cc: [email protected] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Max, > > This sounds fantastic! > > My only question would be how this relates to the external Core work > that Tim has been doing. If we have this, can external core become a > plugin? If we have this, do we no longer need external Core? It seems > to say that we don't want external Core as the interface, as it won't > be stable in any way - does that mean we don't want external Core at > all? > > Thanks > > Neil > > > We certainly need a mechanism for doing > > On 3/21/08, Max Bolingbroke <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I'm interested in working on a plugins system for the Glasgow Haskell > > Compiler. The idea here is to allow third parties to add more > > capabilities to the compiler in a way that doesn't involve messing > > around with modifying GHC itself. Potential use cases are: > > * Allow Haskell code to be selectively run on GPUs > > * Idiosyncratic application-specific optimization passes > > * And whatever clever ideas the community comes up with! > > > > This project has previously been proposed as an Microsoft Research > > internship project > > (http://hackage.haskell.org/trac/ghc/wiki/Internships).I have a > > preliminary wiki page with details at > > http://hackage.haskell.org/trac/ghc/wiki/Plugins > > > > I'd particularly like to get feedback from the list on: > > * Other design goals people would like to see > > * Improvements to the proposed (very half-baked!) user interface > > * Other hooks people think they might like to have into the compiler > > * Interested mentors. Simon PJ has indicated he would be interested in > > mentoring this, but there might be other projects that need him more? > > > > This project would satisfy a dependency that Manuel mentioned in > > http://groups.google.com/group/fa.haskell/msg/3ca260fb075a901e to > > implement an "array DSL" for GPUs in Haskell. It would mean GHC taking > > a dependency on hs-plugins > > (http://www.cse.unsw.edu.au/~dons/hs-plugins/), as that's our current > > strategy to allow GHC to dynamically link with the plugins. > > > > A little about my experience with GHC: this year I worked on > > implementing comprehensive comprehensions > > (http://research.microsoft.com/~simonpj/papers/list-comp/index.htm) as > > my final year undergraduate project, supervised by Simon PJ. I have > > subsequently implemented a few other patches, adding some core-level > > optimizations / bug fixes (some of which are pending review). > > > > Thanks in advance for your comments! > > Max > > _______________________________________________ > > Haskell-Cafe mailing list > > [email protected] > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > ------------------------------ > > Message: 7 > Date: Sat, 22 Mar 2008 12:17:48 +0000 > From: "Neil Mitchell" <[EMAIL PROTECTED]> > Subject: Re: [Haskell-cafe] "doctest" for haskell -- a good project? > To: "Don Stewart" <[EMAIL PROTECTED]> > Cc: Shaun Cutts <[EMAIL PROTECTED]>, [email protected] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi > > > One idea that does strike me is that it would be super useful to have > > the ability in ghci to extract the haddocks associated with a function. > > > > > :doc map > > > > would result in: > > > > -- | 'map' @f xs@ is the list obtained by applying @f@ to each element > > -- of @xs@, i.e., > > -- > > -- > map f [x1, x2, ..., xn] == [f x1, f x2, .. > > -- > map f [x1, x2, ...] == [f x1, f x2, ...] > > That will be in Hoogle 4, as it does already directly relate to what > Hoogle has to do. > > As for doctest, i think that could be implemented as a --warn flag to > Haddock, and might be a useful thing to have. For example "90% of the > base library has documentation, please go add documentation to > 'sinh'", as a warning message. > > Thanks > > Neil > > > ------------------------------ > > Message: 8 > Date: Sat, 22 Mar 2008 08:45:01 -0400 > From: Michael Feathers <[EMAIL PROTECTED]> > Subject: Re: [Haskell-cafe] An ugly zip3 problem.. > To: Tillmann Rendel <[EMAIL PROTECTED]> > Cc: Haskell Cafe <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > Thanks! I learned a lot from that. > > > Michael > > Tillmann Rendel wrote: > > Michael Feathers wrote: > > > I'm working on something and it's looking rather ugly. essentially, > > > it's an application of a low pass filer to a dataset. > > > > I would not consider your code ugly. it can be made shorter, though. > > > > > type Dataset = [Double] > > > type FilterWindow3 = (Double,Double,Double) > > > > > > internalList :: [a] -> [a] > > > internalList = tail . init > > > > > > lowPass3 :: FilterWindow3 -> Double > > > lowPass3 (i, j, k) = (i + 2 * j + k) / 4.0 > > > > > > filter3 :: (FilterWindow3 -> Double) -> Dataset -> Dataset > > > filter3 f3 ds = [(f3 x) | x <- formWindows ds] > > > > I would prefer this version to the list comprehension: > > > > filter3 f3 = map f3 . formWindows > > > > I tend to assume list comprehensions are doing something magical I have > > to figure out while reading a program, so a comprehension for a simple > > map looks wrong to me. read ahead for more magical list comprehensions. > > > > > iterFilter :: (Dataset -> Dataset) -> Int -> Dataset -> Dataset > > > iterFilter f n ds > > > | n > 0 = iterFilter f (n - 1) (f ds) > > > | otherwise = ds > > > > You can use iterate and list indexing to iterate a function a specified > > number of times. > > > > iterFilter f n = (!! n) . iterate f > > > > Probably > > > > iterateN :: (a -> a) -> Int -> a > > > > is a better type and name for this function. > > > > > formWindows :: Dataset -> [FilterWindow3] > > > formWindows ds = > > > internalList $ zip3 x y z > > > where c0 = [head ds] > > > cn = [last ds] > > > x = ds ++ cn ++ cn > > > y = c0 ++ ds ++ cn > > > z = c0 ++ c0 ++ ds > > > > internalList will delete the first and last element, so why create it at > > all? there is no problem with different list lengths, the result will be > > as long as the shortest list. > > > > formWindows ds = zip3 x y z where > > x = tail ds ++ [last ds] > > y = ds > > z = head ds : ds > > > > if you want to make clear what elements of the lists are used, you can use > > > > z = head ds : init ds > > > > instead. Note that definition for y clearly states that the middle > > element is the original list. I would consider swapping x and z to help > > me imagine a window moving over the dataset. as it is now, i have to > > imagine a window with an integrated mirror to make it fit. > > > > I don't like the definition of x, because I fear that the (last ds) > > thunk will hang around and hold the whole list ds in memory, which is > > unecessary because it's value only depends on the last element of said > > list. I would therefore consider a different implementation using tails. > > > > formWindows ds = [(f y z, y, x) | (x : y : z) <- tails (head ds : ds)] > > where f x [] = x > > f _ (x : _) = x > > > > the head corner case is taken care of by duplicating the head of ds. the > > last corner case is taken care of by the call to f, which uses y as > > default value if z doesn't contain another one. the list comprehension > > is used here to do three different things: > > > > * convert lists to tuples > > * apply f > > * throw away the last element of tails' result (pattern match > > failure means "ignore this element" in list comprehensions) > > > > Maybe > > > > headDefault :: a -> [a] -> a > > > > is a sensible name for f. > > > > > smooth :: Int -> Dataset -> Dataset > > > smooth = iterFilter $ filter3 lowPass3 > > > > by inlining the definition above, this can be given as a four-liner now: > > > > smooth n = (!! n) . iterate f where > > f ds = [(g y z + 2 * y + x) / 4.0 | x:y:z <- tails (head ds : ds)] > > g x [] = x > > g _ (x:_) = x > > > > :-) > > > > Tillmann > > > > > -- > Now Playing: http://www.youtube.com/watch?v=SsnDdq4V8zg > > > > ------------------------------ > > Message: 9 > Date: Sat, 22 Mar 2008 08:53:58 -0400 > From: Michael Feathers <[EMAIL PROTECTED]> > Subject: Re: [Haskell-cafe] An ugly zip3 problem.. > To: Tillmann Rendel <[EMAIL PROTECTED]> > Cc: Haskell Cafe <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > One thing that gets me about this solution.. as I was structuring mine I > noticed that I was ending up with types like FilterWindow3 and functions > like lowPass3. Inlining does eliminate them, but I wonder whether there > is a good way to structure the computation generically so that it can be > performed with windows of 5 as well as 3. The cons pattern matching > here would get in the way, and in my original solution, the fact that I > was using tuples got in the way also. > > Would Haskell's type system allow you to pass a function of arbitrary > arity, discern its arity, use that information to construct the > appropriate structure for iteration, and then apply it? > > > Michael > > Tillmann Rendel wrote: > > > > > by inlining the definition above, this can be given as a four-liner now: > > > > smooth n = (!! n) . iterate f where > > f ds = [(g y z + 2 * y + x) / 4.0 | x:y:z <- tails (head ds : ds)] > > g x [] = x > > g _ (x:_) = x > > > > :-) > > > > Tillmann > > > > > -- > Now Playing: http://www.youtube.com/watch?v=SsnDdq4V8zg > > > > ------------------------------ > > Message: 10 > Date: Sat, 22 Mar 2008 21:40:01 +0800 > From: Deng Chao <[EMAIL PROTECTED]> > Subject: [Haskell-cafe] How to program with sqlite? > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain > > Hi all, > I'm learning sqlite, and as I know haskell has some libraries like > HDBC or HSQL can access sqlite DB. Can anybody give me a small example > to show how to use it? It will be very appreciate? Thanks! > > Best Regards, > Deng Chao > > > > ------------------------------ > > Message: 11 > Date: Sat, 22 Mar 2008 14:53:31 +0100 > From: Thomas Schilling <[EMAIL PROTECTED]> > Subject: Re: [Haskell-cafe] "doctest" for haskell -- a good project? > To: "Neil Mitchell" <[EMAIL PROTECTED]> > Cc: Shaun Cutts <[EMAIL PROTECTED]>, [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > On 22 mar 2008, at 13.17, Neil Mitchell wrote: > > > Hi > > > >> One idea that does strike me is that it would be super useful to > >> have > >> the ability in ghci to extract the haddocks associated with a > >> function. > >> > >>> :doc map > >> > >> would result in: > >> > >> -- | 'map' @f xs@ is the list obtained by applying @f@ to > >> each element > >> -- of @xs@, i.e., > >> -- > >> -- > map f [x1, x2, ..., xn] == [f x1, f x2, .. > >> -- > map f [x1, x2, ...] == [f x1, f x2, ...] > > > > That will be in Hoogle 4, as it does already directly relate to what > > Hoogle has to do. > > > > As for doctest, i think that could be implemented as a --warn flag to > > Haddock, and might be a useful thing to have. For example "90% of the > > base library has documentation, please go add documentation to > > 'sinh'", as a warning message. > > > > > Though that would be a nice feature, too, I think you misunderstood > what a doctest is. > > A doctest is a unit test in the documentation. This way it serves as > a usage example as well as a formal specification of the semantics. > I think we already have some way to run quickchecks inside > documentation, but I can't remember what it was that could do that. > > / Thomas > > > ------------------------------ > > Message: 12 > Date: Sat, 22 Mar 2008 14:15:02 +0000 > From: "Sebastian Sylvan" <[EMAIL PROTECTED]> > Subject: Re: [Haskell-cafe] How to program with sqlite? > To: [EMAIL PROTECTED] > Cc: [email protected] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > On Sat, Mar 22, 2008 at 1:40 PM, Deng Chao <[EMAIL PROTECTED]> wrote: > > > Hi all, > > I'm learning sqlite, and as I know haskell has some libraries like > > HDBC or HSQL can access sqlite DB. Can anybody give me a small example > > to show how to use it? It will be very appreciate? Thanks! > > > > Best Regards, > > Deng Chao > > > > _______________________________________________ > > Haskell-Cafe mailing list > > [email protected] > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > Here's a quick GHCi session with HDBC. > > Prelude> :m +Database.HDBC > Prelude Database.HDBC> :m +Database.HDBC.Sqlite3 > Prelude Database.HDBC Database.HDBC.Sqlite3> conn <- connectSqlite3 "mydb" > Prelude Database.HDBC Database.HDBC.Sqlite3> quickQuery conn "CREATE TABLE > mytable (FirstName varchar, LastName varchar, Age int )" [] > [] > Prelude Database.HDBC Database.HDBC.Sqlite3> quickQuery conn "INSERT INTO > mytable VALUES ('Sebastian','Sylvan',26)" [] > [] > Prelude Database.HDBC Database.HDBC.Sqlite3> commit conn > Prelude Database.HDBC Database.HDBC.Sqlite3> quickQuery conn "SELECT * FROM > mytable" [] > [[SqlString "Sebastian",SqlString "Sylvan",SqlString "26"]] > Prelude Database.HDBC Database.HDBC.Sqlite3> disconnect conn > > > Not sure why that Age field came back as a string though :-) > > > -- > Sebastian Sylvan > +44(0)7857-300802 > UIN: 44640862 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://www.haskell.org/pipermail/haskell-cafe/attachments/20080322/37aaabaf/attachment-0001.htm > > ------------------------------ > > Message: 13 > Date: Sat, 22 Mar 2008 14:20:10 +0000 > From: "Sebastian Sylvan" <[EMAIL PROTECTED]> > Subject: Re: [Haskell-cafe] "doctest" for haskell -- a good project? > To: "Don Stewart" <[EMAIL PROTECTED]> > Cc: Shaun Cutts <[EMAIL PROTECTED]>, [email protected] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > On Sat, Mar 22, 2008 at 8:39 AM, Don Stewart <[EMAIL PROTECTED]> wrote: > > > shaun: > > > Hello, > > > > > > I am an experienced programmer, currently learning Haskell. Currently > > I > > > write many things in python. I use both the "doctest" and "unittest" > > > modules extensively. As I write code, I simultaneously write doctest > > code > > > in the doc strings to explain/set out the "typical narrative" of how > > the > > > code is used. Then finishing off a module I write unittests for > > boundary > > > conditions, more complex test cases, and generally code that would be > > > annoying to write & read in doctests. > > > > > > I note that there is a unit testing framework for Haskell, but I > > don't see > > > > There's a couple, QuickCheck is the best, it generalises unit testing to > > property testing with random, or not so random, data. > > > > > any doctest module. Might this be a good project? > > > If so, suggestions as to resources would be greatly appreciated. I > > believe > > > I can't just "introspect" Haskell modules to get at > > > documentation/comments, like I can in python? (Why not? :)) I notice > > that > > > there are a few "documentation generators". Should I try to write an > > > extension of one of these? Haddock, for instance? Are there any > > Haddock > > > developers hanging out on this list, to encourage or dissuade me? :) > > (And > > > where is the Haddock doc for Haddock?) > > > > > > In any case, thanks in advance for any comments & advice. > > > > I'm not sure how doctest works, or how it would work in a Haskell > > setting, could you elaborate? > > > > One idea that does strike me is that it would be super useful to have > > the ability in ghci to extract the haddocks associated with a function. > > > > > :doc map > > > > would result in: > > > > -- | 'map' @f xs@ is the list obtained by applying @f@ to each element > > -- of @xs@, i.e., > > -- > > -- > map f [x1, x2, ..., xn] == [f x1, f x2, .. > > -- > map f [x1, x2, ...] == [f x1, f x2, ...] > > > > marked up in ascii. > > > > I'm not sure if that's related to doctest, but it sure would be useful! > > > > To be honest, I think this is what we should see when we type ":info map". > Preferably we'd get a proper GUI version of GHCi which prints it out into a > HTML box or something with proper hyperlinks and formatting. > > > > -- > Sebastian Sylvan > +44(0)7857-300802 > UIN: 44640862 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://www.haskell.org/pipermail/haskell-cafe/attachments/20080322/cee14b21/attachment-0001.htm > > ------------------------------ > > Message: 14 > Date: Sat, 22 Mar 2008 15:29:28 +0100 > From: Robert Vollmert <[EMAIL PROTECTED]> > Subject: [Haskell-cafe] HXT and types in Control.Arrow.ArrowTree > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > Hello, > > I'm having some trouble with HXT, the types of some functions in > particular. This may well be caused by a lack of understanding for > arrow programming -- I'd appreciate any hints. > > In short, I'm constantly running into what appear to be artificial > type restrictions in Control.Arrow.ArrowTree. For example, the > signature of "deep" is > > deep :: (Tree t, ArrowTree a) => a (t b) (t b) -> a (t b) (t b) > > instead of the more general > > deep :: (Tree t, ArrowTree a) => a (t b) c -> a (t b) c > > Say I have an arrow > > getLink :: (ArrowXml a) => a XmlTree Link > > that converts an HTML link (<a href="url">text</a>) into some > appropriate data type (code below). To collect all links in a > document, I'd like to use > > deep getLink > > instead of > > deep (hasName "a") >>> getLink > > Is this the wrong approach to converting XML into Haskell data types? > > Cheers > Robert > > > module Links where > > import Text.XML.HXT.Arrow > > data Link = Link { url, text :: String } > deriving Show > > getLink :: (ArrowXml a) => a XmlTree Link > getLink = isElem >>> hasName "a" > >>> (getAttrValue0 "href" &&& getAllText) > >>> arr (uncurry Link) > > getAllText :: (ArrowXml a) => a XmlTree String > getAllText = listA (deep isText >>> getText) >>> arr concat > > > > ------------------------------ > > Message: 15 > Date: Sat, 22 Mar 2008 15:00:44 +0000 > From: Dominic Steinitz <[EMAIL PROTECTED]> > Subject: [Haskell-cafe] Opening Windows .lnk Files > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Does anyone know how to do this? If I open a file on Windows e.g. > "asn_application.h.lnk" then I get the link data rather than the data in > the linked file. > > Thanks, Dominic. > > > > ------------------------------ > > Message: 16 > Date: Sat, 22 Mar 2008 11:19:30 -0400 > From: "Shaun Cutts" <[EMAIL PROTECTED]> > Subject: RE: [Haskell-cafe] "doctest" for haskell -- a good project? > To: "'Thomas Schilling'" <[EMAIL PROTECTED]> > Cc: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > Thanks for the quick responses. To elaborate on how doctests work in python: > > (Background: in python functions, classes & modules are all "objects" -- > having attributes as well as (for functions) the ability to run them. They > all have, in particular a documentation string associated with them. To get > at these doctest module just loads the module, then examines its contents, > looking for doc strings of contained functions & classes... so the language > itself provides introspection capabilities: a strong point of python. Maybe > Haskell should also have this :).) > > Doctests in python are bits of code in documentation strings specially > annotated. In the docstring for a function "f", we might have (with > apologies for python function call syntax :)): > > >>> f( foo ) > bar > > This means: run f( foo ) and check that (the string representation of ) the > output is "bar". > > You can put any code in docstring. In effect, the doctest module turns what > you have written into a little module, together with imports, etc. > > For continuation lines on blocks of code the convention is: > > >>> f( > ... foo ) > > A blank line after a ">>>" line means that no output is expected (you > defined a function, for example). > If a blank line is part of the string representation of output, then it is > represented, e.g.: > > >>> f( foo ) > <BLANKLINE> > bar > > If result has lots of text, you can use > > >>> f( foo ) > <ELLIPSIS> > bar > > This is helpful, e.g. if f is a helper function that catches an exception > then prints it out; you don't want to check the resulting stack-trace -- > just the part at the end about what exception was caught. > > There are lots of other switches & options, but no need to copy all of the > details. (Anyway, by the time I get to worrying about them, I'll have my own > opinions. :)) > > --------------------------------------- > > So Paul Johnson writes: > > > You need to support QuickCheck and Hunit > > In fact, at least in python, doctests are even more generic... They support > "anything" -- though > QuickCheck tests are also allowed. Does this approach seem ok/desirable here > too? > > A bit worrisome info from Paul: > > > Haddock does not contain a full Haskell parser, which makes it difficult > to extend in a principled way (or maybe I'm just not a good enough > programmer). > > > I also looked at using the Haskell parser in the libraries, but that > doesn't capture comments. > > Associating a comment with a particular construct is not that simple > either. > > Hmm... this makes me think that the first thing would be for me to put in an > option to capture comments in the parse tree in the parser. Then Paul and > crew would hack the parser's use into Haddock. Then I'd extend Haddock to > support doctests! > > How about that? > > Or actually I think its overkill. If I can hook into the processing of the > comment (presumably only extended comments), I can piece together a fake > "module". The "..." convention means I should know how to stitch together > expressions without having to understand them. One problem is checking the > "output" of an expression. If an expression has output, it would seem I > should throw in a test (using QuickCheck?). Hmmm. > > - Shaun > > > > -----Original Message----- > > From: Thomas Schilling [mailto:[EMAIL PROTECTED] > > Sent: Saturday, March 22, 2008 9:54 AM > > To: Neil Mitchell > > Cc: Don Stewart; Shaun Cutts; [email protected] > > Subject: Re: [Haskell-cafe] "doctest" for haskell -- a good project? > > > > > > On 22 mar 2008, at 13.17, Neil Mitchell wrote: > > > > > Hi > > > > > >> One idea that does strike me is that it would be super useful to > > >> have the ability in ghci to extract the haddocks > > associated with a > > >> function. > > >> > > >>> :doc map > > >> > > >> would result in: > > >> > > >> -- | 'map' @f xs@ is the list obtained by applying > > @f@ to each > > >> element > > >> -- of @xs@, i.e., > > >> -- > > >> -- > map f [x1, x2, ..., xn] == [f x1, f x2, .. > > >> -- > map f [x1, x2, ...] == [f x1, f x2, ...] > > > > > > That will be in Hoogle 4, as it does already directly > > relate to what > > > Hoogle has to do. > > > > > > As for doctest, i think that could be implemented as a > > --warn flag to > > > Haddock, and might be a useful thing to have. For example > > "90% of the > > > base library has documentation, please go add documentation to > > > 'sinh'", as a warning message. > > > > > > > > > Though that would be a nice feature, too, I think you > > misunderstood what a doctest is. > > > > A doctest is a unit test in the documentation. This way it > > serves as > > a usage example as well as a formal specification of the semantics. > > I think we already have some way to run quickchecks inside > > documentation, but I can't remember what it was that could do that. > > > > / Thomas > > > > > > ------------------------------ > > Message: 17 > Date: Sat, 22 Mar 2008 08:42:47 -0700 > From: Bryan O'Sullivan <[EMAIL PROTECTED]> > Subject: Re: [Haskell-cafe] An ugly zip3 problem.. > To: Michael Feathers <[EMAIL PROTECTED]> > Cc: Haskell Cafe <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=UTF-8 > > Michael Feathers wrote: > > > Would Haskell's type system allow you to pass a function of arbitrary > > arity, discern its arity, use that information to construct the > > appropriate structure for iteration, and then apply it? > > The answer is probably "yes", because almost every time I've thought > that a type system related question had an answer of "no", someone has > been able to point me at a paper by Oleg Kiselyov. > > But if you're convolving a one-dimensional vector, and it's structured > as a list, a simpler approach is to use a variant of a zipper data > structure. Basically, as you traverse the list, you build a new list of > the elements that you've already consumed. > > Let's say your list looks like this: > > [1,2,3,4,5,6,7,8] > > You start off with an empty list of items you've consumed, and for each > item you pull off the list you're consuming, you push it onto the list > you've consumed. > > [] 1 [2,3,4,5,6,7,8] > [1] 2 [3,4,5,6,7,8] > ... > [4,3,2,1] 5 [6,7,8] > ... > > Your consumption function can then use pattern matching to pick out an > appropriate number of neighbouring elements from the fronts of the list > you're about to consume and the list you've just consumed. To change > the number of elements you're looking at, you just modify the two > patterns, not the types or data structures you're using. > > This technique, though cute, has several drawbacks. > > 1. Lists won't exactly make your performance fly. You're also > constructing an entire list of already seen values when you only need a > handful from near the front. This capability makes sense when you need > to be able to switch the direction of iteration for some reason, but > that doesn't apply here. > 2. Because you can't pattern match on elements in an array, you can't > pick this approach up and transplant it to a different underlying data > structure. > 3. I don't know how to construct a useful zipper over lists of higher > order (e.g. lists of lists), so at least with my limited brain power and > attention span, the approach falls apart if you want to convolve a 2D or > higher vector. > > <b > > > ------------------------------ > > Message: 18 > Date: Sat, 22 Mar 2008 16:08:03 +0000 > From: Paul Johnson <[EMAIL PROTECTED]> > Subject: Re: [Haskell-cafe] "doctest" for haskell -- a good project? > To: Shaun Cutts <[EMAIL PROTECTED]>, Haskell-cafe Cafe > <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Shaun Cutts wrote: > > I note that there is a unit testing framework for Haskell, but I don't > > see any doctest module. Might this be a good project? > I once looked at doing this, but I didn't get very far. > > Haddock is important here because you want to include the tests as part > of the documentation. QuickCheck properties in particular closely > resemble a formal specification. For a couple of examples, see my > RangedSet package and Neil Mitchel's FilePath package. I manually > copied the RangedSet tests into the Haddock documentation, while Neil > wrote a small Haskell script to extract his tests from his documentation > automatically. Unfortunately his script is tied to specific aspects of > his FilePath package. > > Haddock does not contain a full Haskell parser, which makes it difficult > to extend in a principled way (or maybe I'm just not a good enough > programmer). The problem is you need to have several different new > kinds of mark-up, and its not always clear what to do. > > You need to support QuickCheck and HUnit. Also possibly SmallCheck and > some other similar unit testing cum specification frameworks. For > QuickCheck you need to have type information for the tests. For > instance the classic specification / test of "reverse" is: > > > prop_reverse xs xy = (reverse xs ++ reverse ys) == reverse (ys ++ xs) > > Somewhere you need to flag that "xs" and "ys" are lists of integers. In > the case of my RangedSets I needed to run the tests with both Integers > and Doubles. > > I also looked at using the Haskell parser in the libraries, but that > doesn't capture comments. Associating a comment with a particular > construct is not that simple either. > > If you can manage this then it would be great. > > Paul. > > > > ------------------------------ > > Message: 19 > Date: Sat, 22 Mar 2008 16:08:23 +0000 > From: Paul Johnson <[EMAIL PROTECTED]> > Subject: Re: [Haskell-cafe] AMQP framing layer: design help requested. > To: Haskell-cafe Cafe <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Dean Herington wrote: > > At 6:41 PM -0700 3/21/08, Adam Langley wrote: > >> > >> Also > >>> getter <- fmap (amqpGetTable !) getWord8 > >>> getter > >> > >> is just > >> > >> > fmap (amqpGetTable !) getWord8 > > > > I don't think so. Aren't there two "gettings": the first to get the > > "type" byte and the second to get the item? > > > Yes. I didn't use it because it seemed obfuscated, but in fact the > point-free version is > > > fmap (amqpGetTable !) getWord8 >>= id > > And I've also got an AmqpWire class similar to Dean's AmqpValue class. > But both of these miss the point (which is why I didn't clutter up my > simplified explanation with them). > > I'm looking for an alternative to the honking big AmqpVariant and > AmqpArray types. I think I want something along the lines of: > > > class (Binary v) => VariantClass v where > > typeCode :: v -> Word8 > > fromVariant :: AmqpVariant -> Maybe v > > > > newtype AmqpVariant = forall a . (VariantClass a) => Variant a > > > > newtype AmqpArray = forall a . (VariantClass a) => AmqpArray [a] > > But I can't see how to write "fromVariant". I'm also unsure what the > "amqpGet" and "amqpPut" methods might look like. > > Or maybe these two types are actually the best design. They do let you > pattern-match on the contents. Extracting the contents of a variant > from the design above would be something like: > > > processVariant (Variant v) = > > case typeCode v of > > 0x01 -> processWord8 $ fromJust $ fromVariant v > > 0x02 -> ... and so on. > > Compare this with: > > > processVariant (VariantWord8 v) = processWord8 v > > processVariant (VariantWord16 v) = processWord16 v > > ... and so on. > > What do you think? > > Paul. > > > > > ------------------------------ > > Message: 20 > Date: Sat, 22 Mar 2008 11:13:54 -0500 > From: "Antoine Latter" <[EMAIL PROTECTED]> > Subject: Re: [Haskell-cafe] Problem with OpenAL > To: "George Giorgidze" <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], [email protected] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > For those of you following along, you'll need: > > > import qualified Sound.OpenAL as AL > > import Data.Maybe > > import Foreign.C.Types > > import Control.Monad > > import Control.Concurrent > > import Foreign.Storable > > import Foreign.Marshal.Alloc > > when I run "playOpenAL 440" I get no sound, and the following is > repeatedly printed on the console: > > waiting > 0 > 1 > waiting > 0 > 1 > waiting > 0 > 1 > waiting > 0 > 1 > > What do you think should be happening? > > -Antoine > > 2008/3/21 George Giorgidze <[EMAIL PROTECTED]>: > > I tried OpenAL binding (the one which is on the Hackage), but with no luck. > > > > I can not hear anything from speakers and also according to generated output > > on console it seems that "AL.play" never completes playback of a buffer as > > buffer remains registered as "unprocessed" in OpenAL context. > > Here is the piece of code. I am not getting any error messages from OpenAL > > library functions. > > > > playOpenAL :: Int -> IO () > > playOpenAL sr = do > > mDevice <- AL.openDevice Nothing > > when (isNothing mDevice) $ error "opening OpenAL device" > > let device = fromJust mDevice > > > > mContext <- AL.createContext device [ > > AL.Frequency (fromIntegral sr) > > , AL.Refresh (fromIntegral sr) > > ] > > when (isNothing mContext) $ error "creating OpenAL context" > > let context = fromJust mContext > > AL.currentContext AL.$= (Just context) > > > > > > let sampleNumber = 256 > > bufSize = sampleNumber * (sizeOf (undefined :: CShort)) > > buf2 <- mallocBytes bufSize > > > > -- here I am filling buf2 with noise .... > > > > [source] <- AL.genObjectNames 1 > > [buffer] <- AL.genObjectNames 1 > > > > let region = AL.MemoryRegion buf2 (fromIntegral bufSize) > > AL.bufferData buffer AL.$= (AL.BufferData region AL.Mono16 (fromIntegral > > sr)) > > > > > > AL.queueBuffers source [buffer] > > AL.loopingMode source AL.$= AL.OneShot > > > > let waitForSource = do > > putStrLn "waiting" > > s <- AL.get (AL.buffersProcessed source) > > putStrLn $ show s > > s <- AL.get (AL.buffersQueued source) > > putStrLn $ show s > > state <- AL.get (AL.sourceState source) > > case state of > > AL.Playing -> do > > threadDelay 1024 > > waitForSource > > _ -> return () > > > > putStrLn "Start Playing ... " > > AL.play [source] > > waitForSource > > > > > > AL.currentContext AL.$= Nothing > > AL.destroyContext context > > b <- AL.closeDevice device > > when (not b) $ error "closing device" > > > > > > Is this library still maintained? > > > > Best, George > > > > _______________________________________________ > > Haskell-Cafe mailing list > > [email protected] > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > > ------------------------------ > > Message: 21 > Date: Sat, 22 Mar 2008 11:50:49 -0500 > From: Derek Elkins <[EMAIL PROTECTED]> > Subject: Re: [Haskell-cafe] AMQP framing layer: design help requested. > To: Paul Johnson <[EMAIL PROTECTED]> > Cc: Haskell-cafe Cafe <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain > > On Sat, 2008-03-22 at 16:08 +0000, Paul Johnson wrote: > > Dean Herington wrote: > > > At 6:41 PM -0700 3/21/08, Adam Langley wrote: > > >> > > >> Also > > >>> getter <- fmap (amqpGetTable !) getWord8 > > >>> getter > > >> > > >> is just > > >> > > >> > fmap (amqpGetTable !) getWord8 > > > > > > I don't think so. Aren't there two "gettings": the first to get the > > > "type" byte and the second to get the item? > > > > > Yes. I didn't use it because it seemed obfuscated, but in fact the > > point-free version is > > > > > fmap (amqpGetTable !) getWord8 >>= id > > > Nah, the point-free version wouldn't be this. First, > join = x >>= id so > fmap (ampqGetTable !) getWord8 >>= id > === join (fmap (ampqGetTable !) getWord8) > Next, m >>= f = join (fmap f m) so > join (fmap (ampqGetTable !) getWord8) > === getWord8 >>= (ampqGetTable !) > This would be the point-free version > > So the original code was a round-about way of saying: > do word <- getWord8; ampqGetTable ! word > > > > > ------------------------------ > > Message: 22 > Date: Sat, 22 Mar 2008 17:11:06 +0000 > From: "Neil Mitchell" <[EMAIL PROTECTED]> > Subject: Re: [Haskell-cafe] Opening Windows .lnk Files > To: "Dominic Steinitz" <[EMAIL PROTECTED]> > Cc: [email protected] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi > > Drop into the command line, rename the file from foo.lnk to foo.txt, > using "ren foo.lnk foo.txt", then open "foo.txt". It's a chunk of > binary goop, so will likely not be much use. > > There is a COM class for editing shortcut files (IShellLink), which > I've used before from C code. See > http://darcs.haskell.org/hugs98/src/winhugs/installer/ShellCode.cpp, > in particular the CreateShortcut function. > > Thanks > > Neil > > > ------------------------------ > > Message: 23 > Date: Sat, 22 Mar 2008 17:16:55 +0000 > From: "Neil Mitchell" <[EMAIL PROTECTED]> > Subject: Re: [Haskell-cafe] "doctest" for haskell -- a good project? > To: "Paul Johnson" <[EMAIL PROTECTED]> > Cc: Shaun Cutts <[EMAIL PROTECTED]>, Haskell-cafe Cafe > <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi > > > I once looked at doing this, but I didn't get very far. > > Me too, and I managed to get some way: > > > resemble a formal specification. For a couple of examples, see my > > RangedSet package and Neil Mitchel's FilePath package. I manually > > copied the RangedSet tests into the Haddock documentation, while Neil > > wrote a small Haskell script to extract his tests from his documentation > > automatically. Unfortunately his script is tied to specific aspects of > > his FilePath package. > > Yes, the problem was that FilePath wants to execute half the tests > twice with different modules, and half with just one namespace. As far > as tests go, this is a very wacky requirement. I wanted to generalise > it into a tool, but couldn't find a sensible generalisation that still > worked with filepath - and hence didn't bother. I think the solution > is to not permit the quirkyness of filepath, and write a general > solution for everything else. > > As someone who has frequently considered writing this, even going as > far as brainstorming on a whiteboard, I would be an enthusiastic user > of this. I think the lack of this tool in Haskell is a big hole which > someone needs to fill. I particularly like the facility in FilePath: > > -- > x == reverse (reverse x) > -- > reverse "neil" = "lien" > > i.e. I can write both quickcheck properties (quantified over all > single letter variables), or I can write an instance (like doctest in > Python) > > Thanks, and good luck! > > Neil > > > ------------------------------ > > Message: 24 > Date: Sat, 22 Mar 2008 17:32:38 +0000 > From: Dominic Steinitz <[EMAIL PROTECTED]> > Subject: Re: [Haskell-cafe] Opening Windows .lnk Files > To: Neil Mitchell <[EMAIL PROTECTED]> > Cc: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Neil Mitchell wrote: > > Hi > > > > Drop into the command line, rename the file from foo.lnk to foo.txt, > > using "ren foo.lnk foo.txt", then open "foo.txt". It's a chunk of > > binary goop, so will likely not be much use. > > > > There is a COM class for editing shortcut files (IShellLink), which > > I've used before from C code. See > > http://darcs.haskell.org/hugs98/src/winhugs/installer/ShellCode.cpp, > > in particular the CreateShortcut function. > > > > Thanks > > > > Neil > > > > > > > Neil, > > Thanks but following a discussion on #haskell, it's all beginning to > sound a bit hard. Somehow I thought it would be easy. I know where the > real files are so I'll just set a directory as a parameter, strip off > the .lnk from the name and use that + the directory to manipulate them. > > Dominic. > > > > ------------------------------ > > Message: 25 > Date: Sat, 22 Mar 2008 14:02:16 -0400 > From: "Shaun Cutts" <[EMAIL PROTECTED]> > Subject: RE: [Haskell-cafe] "doctest" for haskell -- a good project? > To: "'Neil Mitchell'" <[EMAIL PROTECTED]>, "'Paul Johnson'" > <[EMAIL PROTECTED]> > Cc: 'Haskell-cafe Cafe' <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > > > > resemble a formal specification. For a couple of > > examples, see my > > > RangedSet package and Neil Mitchel's FilePath package. I manually > > > copied the RangedSet tests into the Haddock documentation, > > while Neil > > > wrote a small Haskell script to extract his tests from his > > > documentation automatically. Unfortunately his script is tied to > > > specific aspects of his FilePath package. > > > > Yes, the problem was that FilePath wants to execute half the > > tests twice with different modules, and half with just one > > namespace. As far as tests go, this is a very wacky > > requirement. I wanted to generalise it into a tool, but > > couldn't find a sensible generalisation that still worked > > with filepath - and hence didn't bother. I think the solution > > is to not permit the quirkyness of filepath, and write a > > general solution for everything else. > > Niel -- I understand your script is part of FilePath... might it be a good > starting point for abstraction? Can you point me to it? > > > As someone who has frequently considered writing this, even > > going as far as brainstorming on a whiteboard, I would be an > > enthusiastic user of this. I think the lack of this tool in > > Haskell is a big hole which someone needs to fill. I > > particularly like the facility in FilePath: > > > > -- > x == reverse (reverse x) > > -- > reverse "neil" = "lien" > > > > i.e. I can write both quickcheck properties (quantified over > > all single letter variables), or I can write an instance > > (like doctest in > > Python) > > > > Thanks, and good luck! > > > > Neil > > > Thank you for the support... This might take me a while, I must warn, as > this is an "after work" project, and I am a consultant, so "after work" > often doesn't come :). But its certainly motivating to work on something > right away that could be useful (to myself as well). > > - Shaun > > > > ------------------------------ > > _______________________________________________ > Haskell-Cafe mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > End of Haskell-Cafe Digest, Vol 55, Issue 30 > ******************************************** _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
