[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