[Haskell-cafe] Re: Haskell-Cafe Digest, Vol 55, Issue 30

Deng Chao knifewolf at gmail.com
Sun Mar 23 07:48:34 EDT 2008


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 -0400,haskell-cafe-request at haskell.org写道:
> Send Haskell-Cafe mailing list submissions to
> 	haskell-cafe at haskell.org
> 
> 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
> 	haskell-cafe-request at haskell.org
> 
> You can reach the person managing the list at
> 	haskell-cafe-owner at haskell.org
> 
> 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" <vigalchin at gmail.com>
> Subject: [Haskell-cafe] compile error with FFI code
> To: Haskell-cafe <haskell-cafe at haskell.org>
> Cc: Galchin Vasili <vigalchin at gmail.com>
> Message-ID:
> 	<5ae4f2ba0803212121w17fe482ek105c13cf6999e603 at mail.gmail.com>
> 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" <shaun at cuttshome.net>
> Subject: [Haskell-cafe] "doctest" for haskell -- a good project?
> To: <haskell-cafe at haskell.org>
> Message-ID: <04bd01c88be4$d998c010$7000a8c0 at INTERLINK>
> 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 <bulat.ziganshin at gmail.com>
> Subject: Re: [Haskell-cafe] [GSoC] Plugins for GHC
> To: "Max Bolingbroke" <batterseapower at hotmail.com>
> Cc: haskell-cafe at haskell.org
> Message-ID: <19110011979.20080322100850 at gmail.com>
> 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:Bulat.Ziganshin at gmail.com
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Sat, 22 Mar 2008 10:29:33 +0200
> From: Roman Cheplyaka <roma at ro-che.info>
> Subject: Re: [Haskell-cafe] "doctest" for haskell -- a good project?
> To: haskell-cafe at haskell.org
> Message-ID: <20080322082932.GA3361 at home.ro-che.info>
> Content-Type: text/plain; charset="us-ascii"
> 
> * Shaun Cutts <shaun at cuttshome.net> [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 <dons at galois.com>
> Subject: Re: [Haskell-cafe] "doctest" for haskell -- a good project?
> To: Shaun Cutts <shaun at cuttshome.net>
> Cc: haskell-cafe at haskell.org
> Message-ID: <20080322083944.GA30413 at scytale.galois.com>
> 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" <ndmitchell at gmail.com>
> Subject: Re: [Haskell-cafe] [GSoC] Plugins for GHC
> To: "Max Bolingbroke" <batterseapower at hotmail.com>
> Cc: haskell-cafe at haskell.org
> Message-ID:
> 	<404396ef0803220515n52dc7cfbg5b565ba2e481c27b at mail.gmail.com>
> 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 <batterseapower at hotmail.com> 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
> >  Haskell-Cafe at haskell.org
> >  http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Sat, 22 Mar 2008 12:17:48 +0000
> From: "Neil Mitchell" <ndmitchell at gmail.com>
> Subject: Re: [Haskell-cafe] "doctest" for haskell -- a good project?
> To: "Don Stewart" <dons at galois.com>
> Cc: Shaun Cutts <shaun at cuttshome.net>, haskell-cafe at haskell.org
> Message-ID:
> 	<404396ef0803220517w35ac8e81u41026c85bd9ebe1d at mail.gmail.com>
> 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 <mfeathers at mindspring.com>
> Subject: Re: [Haskell-cafe] An ugly zip3 problem..
> To: Tillmann Rendel <rendel at rbg.informatik.tu-darmstadt.de>
> Cc: Haskell Cafe <haskell-cafe at haskell.org>
> Message-ID: <47E4FF4D.5000000 at mindspring.com>
> 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 <mfeathers at mindspring.com>
> Subject: Re: [Haskell-cafe] An ugly zip3 problem..
> To: Tillmann Rendel <rendel at rbg.informatik.tu-darmstadt.de>
> Cc: Haskell Cafe <haskell-cafe at haskell.org>
> Message-ID: <47E50166.8070302 at mindspring.com>
> 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 <knifewolf at gmail.com>
> Subject: [Haskell-cafe] How to program with sqlite?
> To: haskell-cafe at haskell.org
> Message-ID: <1206193201.9417.4.camel at knifewolfUBUNTU>
> 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 <nominolo at googlemail.com>
> Subject: Re: [Haskell-cafe] "doctest" for haskell -- a good project?
> To: "Neil Mitchell" <ndmitchell at gmail.com>
> Cc: Shaun Cutts <shaun at cuttshome.net>, haskell-cafe at haskell.org
> Message-ID: <1413441C-C2FE-4451-837E-19908C607843 at googlemail.com>
> 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" <sebastian.sylvan at gmail.com>
> Subject: Re: [Haskell-cafe] How to program with sqlite?
> To: knifewolf at gmail.com
> Cc: haskell-cafe at haskell.org
> Message-ID:
> 	<3d96ac180803220715q50c2f0c8gbbd538c3deb26c3e at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> On Sat, Mar 22, 2008 at 1:40 PM, Deng Chao <knifewolf at gmail.com> 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
> > Haskell-Cafe at haskell.org
> > 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" <sebastian.sylvan at gmail.com>
> Subject: Re: [Haskell-cafe] "doctest" for haskell -- a good project?
> To: "Don Stewart" <dons at galois.com>
> Cc: Shaun Cutts <shaun at cuttshome.net>, haskell-cafe at haskell.org
> Message-ID:
> 	<3d96ac180803220720v49847f9fq9f6930cb372f5c6f at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> On Sat, Mar 22, 2008 at 8:39 AM, Don Stewart <dons at galois.com> 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 <rvollmert-lists at gmx.net>
> Subject: [Haskell-cafe] HXT and types in Control.Arrow.ArrowTree
> To: haskell-cafe at haskell.org
> Message-ID: <ED32B4CE-2475-44C9-AE6A-77A919E8C87C at gmx.net>
> 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 <dominic.steinitz at blueyonder.co.uk>
> Subject: [Haskell-cafe] Opening Windows .lnk Files
> To: haskell-cafe at haskell.org
> Message-ID: <47E51F1C.7090808 at blueyonder.co.uk>
> 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" <shaun at cuttshome.net>
> Subject: RE: [Haskell-cafe] "doctest" for haskell -- a good project?
> To: "'Thomas Schilling'" <nominolo at googlemail.com>
> Cc: haskell-cafe at haskell.org
> Message-ID: <052801c88c30$211e93b0$7000a8c0 at INTERLINK>
> 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:nominolo at googlemail.com] 
> > Sent: Saturday, March 22, 2008 9:54 AM
> > To: Neil Mitchell
> > Cc: Don Stewart; Shaun Cutts; haskell-cafe at haskell.org
> > 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 <bos at serpentine.com>
> Subject: Re: [Haskell-cafe] An ugly zip3 problem..
> To: Michael Feathers <mfeathers at mindspring.com>
> Cc: Haskell Cafe <haskell-cafe at haskell.org>
> Message-ID: <47E528F7.8060204 at serpentine.com>
> 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 <paul at cogito.org.uk>
> Subject: Re: [Haskell-cafe] "doctest" for haskell -- a good project?
> To: Shaun Cutts <shaun at cuttshome.net>,	Haskell-cafe Cafe
> 	<haskell-cafe at haskell.org>
> Message-ID: <47E52EE3.3040808 at cogito.org.uk>
> 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 <paul at cogito.org.uk>
> Subject: Re: [Haskell-cafe] AMQP framing layer: design help requested.
> To: Haskell-cafe Cafe <haskell-cafe at haskell.org>
> Message-ID: <47E52EF7.9000209 at cogito.org.uk>
> 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" <aslatter at gmail.com>
> Subject: Re: [Haskell-cafe] Problem with OpenAL
> To: "George Giorgidze" <ggg at cs.nott.ac.uk>
> Cc: sven.panne at aedion.de, haskell-cafe at haskell.org
> Message-ID:
> 	<694519c50803220913l4e42d4c9s5b66265a3721c6a6 at mail.gmail.com>
> 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 <ggg at cs.nott.ac.uk>:
> > 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
> >  Haskell-Cafe at haskell.org
> >  http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >
> 
> 
> ------------------------------
> 
> Message: 21
> Date: Sat, 22 Mar 2008 11:50:49 -0500
> From: Derek Elkins <derek.a.elkins at gmail.com>
> Subject: Re: [Haskell-cafe] AMQP framing layer: design help requested.
> To: Paul Johnson <paul at cogito.org.uk>
> Cc: Haskell-cafe Cafe <haskell-cafe at haskell.org>
> Message-ID: <1206204649.5533.23.camel at derek-laptop>
> 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" <ndmitchell at gmail.com>
> Subject: Re: [Haskell-cafe] Opening Windows .lnk Files
> To: "Dominic Steinitz" <dominic.steinitz at blueyonder.co.uk>
> Cc: haskell-cafe at haskell.org
> Message-ID:
> 	<404396ef0803221011j35c44a90i1924ed6fce92774f at mail.gmail.com>
> 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" <ndmitchell at gmail.com>
> Subject: Re: [Haskell-cafe] "doctest" for haskell -- a good project?
> To: "Paul Johnson" <paul at cogito.org.uk>
> Cc: Shaun Cutts <shaun at cuttshome.net>,	Haskell-cafe Cafe
> 	<haskell-cafe at haskell.org>
> Message-ID:
> 	<404396ef0803221016u4919a2eaud9b916a4f32fa82b at mail.gmail.com>
> 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 <dominic.steinitz at blueyonder.co.uk>
> Subject: Re: [Haskell-cafe] Opening Windows .lnk Files
> To: Neil Mitchell <ndmitchell at gmail.com>
> Cc: haskell-cafe at haskell.org
> Message-ID: <47E542B6.6030000 at blueyonder.co.uk>
> 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" <shaun at cuttshome.net>
> Subject: RE: [Haskell-cafe] "doctest" for haskell -- a good project?
> To: "'Neil Mitchell'" <ndmitchell at gmail.com>,	"'Paul Johnson'"
> 	<paul at cogito.org.uk>
> Cc: 'Haskell-cafe Cafe' <haskell-cafe at haskell.org>
> Message-ID: <05d301c88c46$de0d92d0$7000a8c0 at INTERLINK>
> 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
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
> 
> End of Haskell-Cafe Digest, Vol 55, Issue 30
> ********************************************



More information about the Haskell-Cafe mailing list