Re: [Haskell-cafe] An issue with EDSLs in the ``finally tagless'' tradition
On Wed, Sep 23, 2009 at 10:24 PM, Brad Larsen brad.lar...@gmail.com wrote: On Wed, Sep 23, 2009 at 11:12 PM, Luke Palmer lrpal...@gmail.com wrote: I would like to see an example of this unmodularity, making use of the polymorphism, so I can understand what you're asking better. Luke [...] A simple test case, combining boolean expressions and arithmetic expressions: test1 = cond (true * false) (pae_constant 0) (pae_add (pae_constant 22) (pae_constant 20)) -- unE test1 === 42 Looks great! So, where is the modularity problem? Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Beginning of a meta-Haskell [was: An issue with the ``finally tagless'' tradition]
Thanks Oleg! Brad: On 24/09/2009, at 3:54 PM, o...@okmij.org wrote: and interpret it several times, as an integer -- testpw :: Int testpw = (unR power) (unR 2) ((unR 7)::Int) -- 128 My type function allows one to remove the '::Int' annotation, which is especially useful in situations where you cannot give an annotation due to 'show . read'-style ambiguity. Conversely one gives up some useful polymorphism (in my case, sometimes it would be nice to have multiple boolean types). Another nit with Oleg's code is that you can only interpret Bool with Bool, in the interpreter: class QBool repr where true, false :: repr Bool if_ :: repr Bool - repr w - repr w - repr w If 'repr' is merely a Haskell98-style type constructor, it cannot analyse its argument. Hence there are two choices: use the argument (Bool) or don't (see the pretty printer). I doubt you could implement a very pleasant interpreter using the latter option, but see http://web.cecs.pdx.edu/~brianh/talks/talk20081010.pdf if you want to try. Again, using a type function here allows you to choose an arbitrary type to represent Bool (and so forth). Trying to do this with fundeps is possible but syntactically heavy. cheers peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parallel graphics
This is seriously cool stuff!!! Maybe it's time to start a Haskell Demo Scene :-) (what's a demo scene? See http://en.wikipedia.org/wiki/Demoscene ) PS: Note that Conal Elliott also was generating GPU code using Haskell with Vertigo back in 2004: http://conal.net/papers/Vertigo/ On Thu, Sep 24, 2009 at 5:32 AM, Claude Heiland-Allen claudiusmaxi...@goto10.org wrote: Andrew Coppin wrote: (OK, well the *best* way is to use the GPU. But AFAIK that's still a theoretical research project, so we'll leave that for now.) Works for me :-) http://claudiusmaximus.goto10.org/cm/2009-09-24_fl4m6e_in_haskell.html There doesn't need to be a sound theoretical foundation for everything, sometimes sufficient ugly hackery will make pretty pretty pictures... Claude -- http://claudiusmaximus.goto10.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Ctrl-C handling in Haskell with curl on Linux
Hi, Yesterday I tried to implement simple tool to download pages, and wanted catch Ctrl-C (and other 'killing' messages) from haskell to handle state saving. Without curl (when I perform some long operation) haskell throws UserInterrupt exception immediately, but if I put long operation, which downloads page from the WEB (from the far-far-away server :) ) than I noticed following issues: - to break my program I have to press Ctrl-C twice - haskell doesn't throw an exception - when I rewrite this code to use signals, haskell, after I press Ctrl-C several times exits with error too many pending signals I put the test code in the end of the letter. Shortly the longTask doesn't handle Ctrl-C and longTask' handles it. I couldn't find any solutions to this problem, I am afraid that this problem could occur in other non-native haskell modules (bindings to C libraries) Many thanks in advance, Vasyl pasternak -- Test code: module Main where import Prelude hiding (catch) import Network.Curl import Control.Exception import Control.Monad import System.IO errorHandler defVal e = do putStrLn $ Error: ++ (show (e :: ErrorCall)) return defVal link = far-far-away-site.com.net getSite curl l = do r - do_curl_ curl l method_GET :: IO (CurlResponse) if respCurlCode r /= CurlOK then error get page failed else return $ respBody r -- this long task doesn't throw user interrupts longTask = do putStrLn Long task started curl - initialize setopts curl [CurlCookieJar cookies] handle (errorHandler ()) $ mapM_ (\_ - getSite curl link return ()) [0..100] return () -- this trows longTask' = do putStrLn long task started let fib n = foldr (*) 1 [1..n] h - openFile /dev/null WriteMode -- never ends mapM_ (hPutStr h . show . fib) [1..] return () onAbort e = do let x = show (e :: AsyncException) putStrLn $ Aborted: ++ x return () main :: IO () main = do handle onAbort longTask putStrLn Exiting ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [uvector] derive UA instance for newtype
On Wed, Sep 23, 2009 at 11:19 PM, Daniel Peebles pumpkin...@gmail.com wrote: I believe this is a bug that was introduced in 6.10.2 (it definitely worked in 6.10.1) that has since been fixed in HEAD. This newtype deriving issue also prevents the uvector testsuite from running at the moment. Yes. It works in 6.10.1 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ctrl-C handling in Haskell with curl on Linux
Hello Vasyl, Thursday, September 24, 2009, 1:30:46 PM, you wrote: I couldn't find any solutions to this problem, I am afraid that this problem could occur in other non-native haskell modules (bindings to C libraries) look at GHC.ConsoleHandler module -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ctrl-C handling in Haskell with curl on Linux
On Sep 24, 2009, at 05:30 , Vasyl Pasternak wrote: Yesterday I tried to implement simple tool to download pages, and wanted catch Ctrl-C (and other 'killing' messages) from haskell to handle state saving. Without curl (when I perform some long operation) haskell throws UserInterrupt exception immediately, but if I put long operation, which downloads page from the WEB (from the far-far-away server :) ) than I noticed following issues: You're going to have problems any time a C library installs its own signal handler, which I would expect libcurl to do so it can clean up after itself. This is true even in C-to-C calling; you need a way to hook the signal handler, which some libraries provide in their API and others you just lose. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ctrl-C handling in Haskell with curl on Linux
On Sep 24, 2009, at 06:20 , Brandon S. Allbery KF8NH wrote: On Sep 24, 2009, at 05:30 , Vasyl Pasternak wrote: Yesterday I tried to implement simple tool to download pages, and wanted catch Ctrl-C (and other 'killing' messages) from haskell to handle state saving. Without curl (when I perform some long operation) haskell throws UserInterrupt exception immediately, but if I put long operation, which downloads page from the WEB (from the far-far-away server :) ) than I noticed following issues: You're going to have problems any time a C library installs its own signal handler, which I would expect libcurl to do so it can clean up after itself. This is true even in C-to-C calling; you need a way to hook the signal handler, which some libraries provide in their API and others you just lose. Just occurred to me I should clarify: while most exception handling mechanisms support the concept of re-throwing exceptions to outer exception handlers, POSIX signals do not. The best you could hope for in a library routine which handles signals itself is an API hook into the signal handler; next best is the API returning a signal-occurred error/exception value. Note that I have no idea how the equivalent signaling mechanism works on Win32. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: graphviz-2999.5.1.1
I'm pleased to announce version 2999.5.1.1 [1] of the graphviz library, which provides bindings to the GraphViz [2] suite of tools for drawing graphs. [1] http://hackage.haskell.org/package/graphviz-2999.5.1.1 [2] http://www.graphviz.org/ This is yet another bugfix release, fixing the problem spotted by Kathleen Fisher where Dot keywords need to be explicitly quoted if used as labels, etc. Once again, this is done automagically with no change to the API. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parallel graphics
Awesome! On Thu, Sep 24, 2009 at 7:47 AM, Peter Verswyvelen bugf...@gmail.comwrote: This is seriously cool stuff!!! Maybe it's time to start a Haskell Demo Scene :-) (what's a demo scene? See http://en.wikipedia.org/wiki/Demoscene ) PS: Note that Conal Elliott also was generating GPU code using Haskell with Vertigo back in 2004: http://conal.net/papers/Vertigo/ On Thu, Sep 24, 2009 at 5:32 AM, Claude Heiland-Allen claudiusmaxi...@goto10.org wrote: Andrew Coppin wrote: (OK, well the *best* way is to use the GPU. But AFAIK that's still a theoretical research project, so we'll leave that for now.) Works for me :-) http://claudiusmaximus.goto10.org/cm/2009-09-24_fl4m6e_in_haskell.html There doesn't need to be a sound theoretical foundation for everything, sometimes sufficient ugly hackery will make pretty pretty pictures... Claude -- http://claudiusmaximus.goto10.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parallel graphics
This is just awesome indeed. You should create a haskell wiki page about that, so that beginners could see Haskell can do that (TM) (yeah, some beginners doubt of it). On Thu, Sep 24, 2009 at 1:02 PM, Olex P hoknam...@gmail.com wrote: Awesome! On Thu, Sep 24, 2009 at 7:47 AM, Peter Verswyvelen bugf...@gmail.comwrote: This is seriously cool stuff!!! Maybe it's time to start a Haskell Demo Scene :-) (what's a demo scene? See http://en.wikipedia.org/wiki/Demoscene ) PS: Note that Conal Elliott also was generating GPU code using Haskell with Vertigo back in 2004: http://conal.net/papers/Vertigo/ On Thu, Sep 24, 2009 at 5:32 AM, Claude Heiland-Allen claudiusmaxi...@goto10.org wrote: Andrew Coppin wrote: (OK, well the *best* way is to use the GPU. But AFAIK that's still a theoretical research project, so we'll leave that for now.) Works for me :-) http://claudiusmaximus.goto10.org/cm/2009-09-24_fl4m6e_in_haskell.html There doesn't need to be a sound theoretical foundation for everything, sometimes sufficient ugly hackery will make pretty pretty pictures... Claude -- http://claudiusmaximus.goto10.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Alp Mestan http://blog.mestan.fr/ http://alp.developpez.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bug in writeArray?
2009/9/23 Bulat Ziganshin bulat.zigans...@gmail.com: Hello Grzegorz, Wednesday, September 23, 2009, 7:19:59 PM, you wrote: This seems like a bug in the implementation of writeArray: when passed let (l,u) = ((0,10),(20,20)) writeArray computes raw index (from 0 to total number of array elements) and check that this index is correct. with multi-dimensional arrays this approach may lead to wrong results, as you mentioned. it's known problem that isn't fixed for a long time probably due to efficiency cautions. Hmm, I understand that efficiency is an issue, but in that case shouldn't unsafe writing be provided by and unsafeWriteArray function, while writeArray does proper range checking? Or at least this problem with writeArray should be clearly indicated in the documentation. I for one spent several hours debugging before finding out about this lack of proper range checks so it's not an imaginary problem. -- Grzegorz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ctrl-C handling in Haskell with curl on Linux
Thank you, You give me and idea, and I fixed this annoying bug - we should only wrap all curl code into withCurlDo function, so the longTask function should be following: longTask = do putStrLn Long task started (curl) withCurlDo $ do curl - initialize setopts curl [CurlCookieJar cookies] handle (errorHandler ()) $ mapM_ (\_ - getSite curl link return ()) [0..100] return () Now it works fine and handles interrupts correctly. Best regards, Vasyl Pasternak 2009/9/24 Brandon S. Allbery KF8NH allb...@ece.cmu.edu On Sep 24, 2009, at 06:20 , Brandon S. Allbery KF8NH wrote: On Sep 24, 2009, at 05:30 , Vasyl Pasternak wrote: Yesterday I tried to implement simple tool to download pages, and wanted catch Ctrl-C (and other 'killing' messages) from haskell to handle state saving. Without curl (when I perform some long operation) haskell throws UserInterrupt exception immediately, but if I put long operation, which downloads page from the WEB (from the far-far-away server :) ) than I noticed following issues: You're going to have problems any time a C library installs its own signal handler, which I would expect libcurl to do so it can clean up after itself. This is true even in C-to-C calling; you need a way to hook the signal handler, which some libraries provide in their API and others you just lose. Just occurred to me I should clarify: while most exception handling mechanisms support the concept of re-throwing exceptions to outer exception handlers, POSIX signals do not. The best you could hope for in a library routine which handles signals itself is an API hook into the signal handler; next best is the API returning a signal-occurred error/exception value. Note that I have no idea how the equivalent signaling mechanism works on Win32. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of GHC as a Cross Compiler
On Wed, 2009-09-23 at 14:50 -0400, John Van Enk wrote: Hi, This may be more appropriate for a different list, but I'm having a hard time figuring out whether or not we're getting a cross compiler in 6.12 or not. Can some one point me to the correct place in Traq to find this information? We're getting slightly closer but it's not even nearly there yet. You might have read about the changes in the native code generator towards building all backends on each platform. However there are a lot of other changes needed especially in the build system to make a full cross-compiler. I know some people have worked on this for ARM but there's nothing integrated yet. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] gtk2hs and runghc
On Thu, 2009-09-24 at 00:10 +0200, Günther Schmidt wrote: Hi Duncan, so ... I have a green light to call gtk from within a forkIO thread for as long as I make sure that the rts is single threaded? Yes and that works very nicely (with the cooperative scheduling trick described in the gtk2hs FAQ). BTW: I was already strongly put off using unsafeInitGUIwForThreadedRTS but thanks for the warning. Thus my back to my original question: Can I start either ghci or runghc with a single-threaded rts so I don't have to compile the app every time I want to check my really trick GUI code? No. The ghc binary itself (ghc, runghc, ghci) is linked using the threaded runtime system. That's a link-time choice, there's no way to turn it on/off at the command line (that might change in future with shared libs). Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of GHC as a Cross Compiler
Thanks. I'd heard rumors about a year ago that 6.12 might have a cross compiler. I just wanted to check. :) On Wed, Sep 23, 2009 at 4:41 PM, Duncan Coutts duncan.cou...@worc.ox.ac.ukwrote: On Wed, 2009-09-23 at 14:50 -0400, John Van Enk wrote: Hi, This may be more appropriate for a different list, but I'm having a hard time figuring out whether or not we're getting a cross compiler in 6.12 or not. Can some one point me to the correct place in Traq to find this information? We're getting slightly closer but it's not even nearly there yet. You might have read about the changes in the native code generator towards building all backends on each platform. However there are a lot of other changes needed especially in the build system to make a full cross-compiler. I know some people have worked on this for ARM but there's nothing integrated yet. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] An issue with EDSLs in the ``finally tagless'' tradition
The modularity problem I speak of is that to add a new interpretation of the DSL, I will likely have to modify the EDSL definition to add additional constraints. Ideally, I would like to be able to define the EDSL once, in a module, and be able to write arbitrary interpretations of it in other modules, without having to go back and change the EDSL definition. Regards, Bradford Larsen On Sep 24, 2009 2:15 AM, Luke Palmer lrpal...@gmail.com wrote: On Wed, Sep 23, 2009 at 10:24 PM, Brad Larsen brad.lar...@gmail.com wrote: On Wed, Sep 23, 2009 ... I would like to see an example of this unmodularity, making use of the polymorphism, so I can ... [...] A simple test case, combining boolean expressions and arithmetic expressions: test1 = con... Looks great! So, where is the modularity problem? Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bug in writeArray?
I agree with Grzegorz. Perhaps we should file a bug-report, if there isn't one already? -Iavor 2009/9/24 Grzegorz Chrupała pite...@gmail.com: 2009/9/23 Bulat Ziganshin bulat.zigans...@gmail.com: Hello Grzegorz, Wednesday, September 23, 2009, 7:19:59 PM, you wrote: This seems like a bug in the implementation of writeArray: when passed let (l,u) = ((0,10),(20,20)) writeArray computes raw index (from 0 to total number of array elements) and check that this index is correct. with multi-dimensional arrays this approach may lead to wrong results, as you mentioned. it's known problem that isn't fixed for a long time probably due to efficiency cautions. Hmm, I understand that efficiency is an issue, but in that case shouldn't unsafe writing be provided by and unsafeWriteArray function, while writeArray does proper range checking? Or at least this problem with writeArray should be clearly indicated in the documentation. I for one spent several hours debugging before finding out about this lack of proper range checks so it's not an imaginary problem. -- Grzegorz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haddock and literate Haskell: annotations must be marked as source?
Hi all, I've developed a bit of a taste for literate Haskell lately, being a verbose sort of guy. Unfortunately, it doesn't seem to interact with Haddock in the way I'd like/expect. I just wanted to check that my understanding of the situation is correct before I (regretfully) give up on LHS. It seems to me that Haddock only picks up annotation comments (ie those that should be included in the produced documentation) from literate Haskell source when those annotations are themselves marked up as source - it seems not to recognise them in the general text. For example, I was expecting/hoping that from the point of view of Haddock, the following literate Haskell code with an annotation-marked paragraph (starts with a vertical bar) in the non-source text. | Turn a foo into a bar. foo :: Foo - Bar foo b = ... ought to be equivalent to the following illiterate Haskell: -- | Turn a foo into a bar. foo :: Foo - Bar foo b = ... ie, it should produce Haddock docs where the definition of foo is annotated with that comment. Sadly, that appears not to be the case. It appears the literate version needs to look like this: -- | Turn a foo into a bar foo :: Foo - Bar foo b = ... which to my mind rather defeats the purpose of being literate. So: am I right that this is the intended/expected behaviour? If not, how does one get round it? If so, could someone perhaps comment on the prospects/complexity of implementing this - or the reasons why it is in fact a bad idea? Many thanks! -Andy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Haddock and literate Haskell: annotations must bemarked as source?
From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Andy Gimblett It seems to me that Haddock only picks up annotation comments (ie those that should be included in the produced documentation) from literate Haskell source when those annotations are themselves marked up as source - it seems not to recognise them in the general text. It appears the literate version needs to look like this: -- | Turn a foo into a bar foo :: Foo - Bar foo b = ... which to my mind rather defeats the purpose of being literate. So: am I right that this is the intended/expected behaviour? Haddock currently uses ghc's parser, and I believe the literate preprocessor discards comments. I think there is an item on the haddock wishlist to preserve the literate comments, but I'm not certain... This problem has been solved in cabal, BTW. Cabal preprocesses .lhs itself, rather than trust the compiler to do it, and it preserves the comments. If you generate you haddocks with cabal, then you should be able to use the markup the way you expected. The Takusen source files are written in this style. For example, see: http://darcs.haskell.org/takusen/Database/Enumerator.lhs Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Coq-Club] An encoding of parametricity in Agda
Hi Taral, Eugene, [Taral] Perhaps I don't understand Agda very well, but I don't see parametricity here. For one, there's no attempt to prove that: forall (P Q : forall a, a - a), P = Q. [Eugene] Under parametricity, I mean the Reynolds Abstraction Theorem, from which free theorems follow. Would it help to say that the Abstraction Theorem states that every *definable* function is parametric, whereas Taral's formula states that *every* function of that type is parametric? (Both concepts are useful; Agda presumably has models where Taral's formula does not hold (if it's consistent, i.e. has models at all), so that formula presumably isn't provable in Agda without additional axioms.) All the best, - Benja ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bug in writeArray?
2009/9/24 Iavor Diatchki iavor.diatc...@gmail.com: I agree with Grzegorz. Perhaps we should file a bug-report, if there isn't one already? http://hackage.haskell.org/trac/ghc/ticket/2120 Apparently, it's fixed in GHC 6.12. -- Dave Menendez d...@zednenem.com http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bug in writeArray?
On Thu, 2009-09-24 at 13:53 +0200, Grzegorz Chrupała wrote: 2009/9/23 Bulat Ziganshin bulat.zigans...@gmail.com: Hello Grzegorz, Wednesday, September 23, 2009, 7:19:59 PM, you wrote: This seems like a bug in the implementation of writeArray: when passed let (l,u) = ((0,10),(20,20)) writeArray computes raw index (from 0 to total number of array elements) and check that this index is correct. with multi-dimensional arrays this approach may lead to wrong results, as you mentioned. it's known problem that isn't fixed for a long time probably due to efficiency cautions. Hmm, I understand that efficiency is an issue, but in that case shouldn't unsafe writing be provided by and unsafeWriteArray function, while writeArray does proper range checking? Or at least this problem with writeArray should be clearly indicated in the documentation. I for one spent several hours debugging before finding out about this lack of proper range checks so it's not an imaginary problem. It's now fixed: http://hackage.haskell.org/trac/ghc/ticket/2120#comment:13 Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock and literate Haskell: annotations must be marked as source?
On Thu, 2009-09-24 at 17:49 +0100, Andy Gimblett wrote: So: am I right that this is the intended/expected behaviour? If not, how does one get round it? If so, could someone perhaps comment on the prospects/complexity of implementing this - or the reasons why it is in fact a bad idea? As Brad says, we implemented this in Cabal by doing a non-standard unlit operation. So cabal haddock will do the right thing for your examples. Running haddock directly and letting it do the unlitting will get different results. If the consensus is that the style of unliting that Cabal is doing is generally the right thing then perhaps we can standardise it and have ghc/haddock do it directly. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: Workflow-0.5.5, TCache-0.6.4 RefSerialize-0.2.4
Hi I'm proud to announce Workflow 0.5.5. Workflow has a monad transformer that encapsulates any monad in a state monad that bring automatic state logging and recovery. A workflow can be viewed as a thread that persist across planeed or unplanned application shutdowns. When recovering the excution is resumed at the last action that was logged. The process continues at the same state as if not interruption took place. Any feedback will be appreciated. Besides state logging and recovery, there are a number of communication primitives that are aware of persistence across reinitiations such are persistent queues, persistent timeouts, or wait for events in the STM monad. These primitives permits inter-woikflow communications and communications with external threads. I hope that this package would be useful for very long computations, either the programs that are CPU intensive and produce valuable intermediate data or programs that wait for actions from users and others processes during days or weeks. That is typical in web applications. Such programs can be defined in a single monadic procedure transparently, without regards of saving intermediate results or reinitiations at the correct point. This new version is not restricted to handle a single type. Every intermediate data must be an instance of Read and Show. For complex data types, other persistence mechanisms can be used (see documentation). The package is at: http://hackage.haskell.org/package/Workflow http://hackage.haskell.org/packages/archive/Workflow/0.5.5/Workflow-0.5.5.tar.gz The tar archive has the documentation and some examples. Among them, a simulation of workflow for the creation and approval of documents, with two levels of approval and approval timeouts, It uses most of the features of the package. NOTE: cabal install reports Tar checksum errors when installed, however, such errors do not appear by downloading the tar.gz archive and decompressing it with the unix or windows tools. I do not know why cabal install behaves as such. Here is a simple example: This is a counter that shows a sequence of numbers, one a second: *module Main where import Control.Concurrent(threadDelay) import System.IO (hFlush,stdout) count n= do putStr (show n ++ ) hFlush stdout threadDelay 100 count (n+1) main= count 0 * This is the same program, with the added feature of remembering the last count after interruption (sequence.hs): *module Main where import Control.Workflow import Control.Concurrent(threadDelay) import System.IO (hFlush,stdout) mcount n= do step $ putStr (show n ++ ) hFlush stdout threadDelay 100 mcount (n+1) main= do registerType :: IO () registerType :: IO Int let start= 0 :: Int startWF count start [(count, mcount)] :: IO () * This is the execution log: *Worflow-0.5.5demosrunghc sequence.hs 0 1 2 3 4 5 6 7 sequence.hs: win32ConsoleHandler sequence.hs: sequence.hs: interrupted Worflow-0.5.5demos Worflow-0.5.5demosrunghc sequence.hs 7 8 9 10 11 * This package uses TCache and RefSerialize. I also uploaded new versions of these packages with extensive documentation and examplles included in the tar.gz archives ( cabal install also repor checksum errors, but are OK when downloading and installing by hand): http://hackage.haskell.org/package/TCache http://hackage.haskell.org/package/TCache http://hackage.haskell.org/packages/archive/TCache/0.6.4/TCache-0.6.4.tar.gz http://hackage.haskell.org/package/RefSerialize http://hackage.haskell.org/package/RefSerialize http://hackage.haskell.org/packages/archive/RefSerialize/0.2.4/RefSerialize-0.2.4.tar.gz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock and literate Haskell: annotations must be marked as source?
On 24 Sep 2009, at 18:28, Duncan Coutts wrote: On Thu, 2009-09-24 at 17:49 +0100, Andy Gimblett wrote: So: am I right that this is the intended/expected behaviour? If not, how does one get round it? If so, could someone perhaps comment on the prospects/complexity of implementing this - or the reasons why it is in fact a bad idea? As Brad says, we implemented this in Cabal by doing a non-standard unlit operation. So cabal haddock will do the right thing for your examples. Running haddock directly and letting it do the unlitting will get different results. That's great news for me, except: that's what I tried first, and I've just tried it again and it still doesn't seem to work for me. Perhaps I am doing something wrong...? Here's a toy example LHS file: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=9802 and here's the corresponding .cabal file: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=9803 and here's a screenshot of the resultant HTML: http://is.gd/3DzmT (produced via runghc Setup configure runghc Setup haddock ) Any idea what I'm doing wrong? One thing I did try was removing the blank line between the annotation and the code. Of course, that breaks the LHS rules, so it doesn't build. (I wondered if it was special cased for this purpose.) Thanks again, -Andy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] best practices for monad transformers and exceptions?
On Thu, Sep 24, 2009 at 8:11 AM, pepe pepeibo...@gmail.com wrote: Exceptions in the ErrorT monad are not compositional. It's the first time I see the approach of stacking several ErrorT monads. It seems slightly better than having a 'global' exception type, although the explicit lifting looks quite painful. I really don't know whether there is a way to write catch_abort, sorry! Even if there is, I don't think you want to use it. A much better option is to use an extensible exception type. Yeah, I had forgotten about Tyeable implementations, which is silly since that's how the IO exceptions now work. Your extensible error framework looks pretty nice! I just made the exceptions global (i.e. put them all in the lowest level type) since I only have two at this point, but if I had more I would definitely check out Control.Monad.Exception. Ideally I would like to be able to package up a set of services as a transformer and plug it in compositionally without worrying about its implementation, but it seems monad transformers are only part of the way there. You can get some hiding with a newtype, and then you can get unlifted access with classes as mtl does (but then you need a bunch of instance boilerplate), but then if the one of the services the transformer needs is early return, then you have to pull the ErrorT out and put it into the final monad, and handle all the exceptions in the final monad's run. It would be nice someday to have more satisfactory way of combining effects. I dream of a way to effortlessly create encapsulated transformers that easily compose with other transformers... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock and literate Haskell: annotations must be marked as source?
On Thu, 2009-09-24 at 19:48 +0100, Andy Gimblett wrote: That's great news for me, except: that's what I tried first, and I've just tried it again and it still doesn't seem to work for me. Perhaps I am doing something wrong...? You're quite right, it got broken with the move to haddock2. The code in Cabal-1.6 skips the pre-processing when using haddock2, assuming haddock will handle it. In the current Cabal development version it works properly and I get the right output for your example. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock and literate Haskell: annotations must be marked as source?
On 24 Sep 2009, at 20:10, Duncan Coutts wrote: On Thu, 2009-09-24 at 19:48 +0100, Andy Gimblett wrote: That's great news for me, except: that's what I tried first, and I've just tried it again and it still doesn't seem to work for me. Perhaps I am doing something wrong...? You're quite right, it got broken with the move to haddock2. The code in Cabal-1.6 skips the pre-processing when using haddock2, assuming haddock will handle it. In the current Cabal development version it works properly and I get the right output for your example. Ah, righto. In that case, I won't shy away from LHS, and I'll be patient for the next Cabal release, or maybe even check out the development version. :-) Many thanks for your reassurance! Cheers, -Andy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: diagrams 0.2.1, and planned major improvements
Hi all, I'm pleased to announce version 0.2.1 of the diagrams library, available now on Hackage [1]. This is a minor release which fixes a few bugs and adds a few new combinators, most notably a grid layout combinator contributed by Ganesh Sittampalam. For a full list of the features new to 0.2.1, see the CHANGES file [2]. The real reason for the release is to get existing new features out the door before gearing up for a planned major rewrite of the backend to use a constraint-solving layout engine. This will allow for much greater elegance and flexibility, as well as a number of features (such as arrows connecting different parts of the diagram) which would be difficult or impossible to implement in the current framework. My ultimate vision is for the diagrams library to become a viable alternative to declarative drawing systems such as MetaPost [3] and Asymptote [4], with the distinct advantages that it will be (1) *purely* declarative, and (2) an *embedded* DSL, providing the full power of Haskell and its ecosystem, as opposed to the ad-hoc specialized languages used by MetaPost and Asymptote. If this sounds exciting to you, I hope you'll join me, either by trying out diagrams for your projects and providing feedback, or by contributing some code. If you're interested in helping with the rewrite itself, let me know; I also plan to set up a core/contrib model like that of xmonad, so there should also be plenty of opportunities for contributing independent add-on modules which enhance the core functionality. -Brent [1] http://hackage.haskell.org/package/diagrams [2] http://code.haskell.org/diagrams/CHANGES [3] http://www.tug.org/metapost.html [4] http://asymptote.sourceforge.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] source locations (was: best practices for monad transformers and exceptions?)
I forgot to mention this, but control-monad-exception reminded me:
Is there any interest in a way for ghc to report source locations? I
have a preprocessor that basically works and is really useful but also
awkward and not scalable. control-monad-exception has TH which is
more scalable but requires manual annotation at every call site. The
loch package also requires annotation at call sites.
I searched on trac, but it's hard to know what to search for and I
only found a feature request to make 'undefined' report line numbers.
Some way to have the callee get the caller's location would be quite
handy. Perhaps something like:
-- | (calling_function, calling_filename, line_number)
type SrcPos = Maybe (String, String, Int)
{-# SRCPOS_ANNOTATE foo, foo_srcpos #-}
foo :: Arg - Result
foo = foo_srcpos Nothing
foo_srcpos :: SrcPos - Arg - Result
foo_srcpos srcpos arg = do
State.modify $ \st - st { state_stack = srcpos : state_stack st }
-- or whatever
Then ghc will rewrite calls to 'foo' as calls to 'foo_srcpos' and add
a SrcPos arg. If the extension isn't present, plain 'foo' will be
called which will pass Nothing. This is basically what my
preprocessor does, only it doesn't understand modules and importing,
so it relies on me having a consistent import convention.
I suppose the preprocessor could be extended with the ability to
understand import lines... but ghc could put the annotation in .hi and
wouldn't have to scan all the source files. My preprocessor wouldn't
work with libraries.
Getting a complete call stack would be even nicer, and I remember
seeing something a while ago about how it would require keeping track
of the calls separately from the real (possibly heavily inlined or
tail recursive) call stack but would be technically possible
especially with some more detailed source code information which I
suppose may be in by now...
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parallel graphics
On Thu, 24 Sep 2009, Alp Mestan wrote: This is just awesome indeed. I'm impressed, too! You should create a haskell wiki page about that, so that beginners could see Haskell can do that (TM) (yeah, some beginners doubt of it). Don't miss to add it to http://www.haskell.org/haskellwiki/Category:Graphics or so. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: source locations (was: best practices for monad transformers and exceptions?)
Sorry! Never mind all that. I just stumbled across http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack *sigh* ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: diagrams 0.2.1, and planned major improvements
simply beautiful 2009/9/24 Brent Yorgey byor...@seas.upenn.edu Hi all, I'm pleased to announce version 0.2.1 of the diagrams library, available now on Hackage [1]. This is a minor release which fixes a few bugs and adds a few new combinators, most notably a grid layout combinator contributed by Ganesh Sittampalam. For a full list of the features new to 0.2.1, see the CHANGES file [2]. The real reason for the release is to get existing new features out the door before gearing up for a planned major rewrite of the backend to use a constraint-solving layout engine. This will allow for much greater elegance and flexibility, as well as a number of features (such as arrows connecting different parts of the diagram) which would be difficult or impossible to implement in the current framework. My ultimate vision is for the diagrams library to become a viable alternative to declarative drawing systems such as MetaPost [3] and Asymptote [4], with the distinct advantages that it will be (1) *purely* declarative, and (2) an *embedded* DSL, providing the full power of Haskell and its ecosystem, as opposed to the ad-hoc specialized languages used by MetaPost and Asymptote. If this sounds exciting to you, I hope you'll join me, either by trying out diagrams for your projects and providing feedback, or by contributing some code. If you're interested in helping with the rewrite itself, let me know; I also plan to set up a core/contrib model like that of xmonad, so there should also be plenty of opportunities for contributing independent add-on modules which enhance the core functionality. -Brent [1] http://hackage.haskell.org/package/diagrams [2] http://code.haskell.org/diagrams/CHANGES [3] http://www.tug.org/metapost.html [4] http://asymptote.sourceforge.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] An issue with EDSLs in the ``finally tagless'' tradition
Brad Larsen wrote: The modularity problem I speak of is that to add a new interpretation of the DSL, I will likely have to modify the EDSL definition to add additional constraints. Ideally, I would like to be able to define the EDSL once, in a module, and be able to write arbitrary interpretations of it in other modules, without having to go back and change the EDSL definition. The canonical, if theoretically unsatisfying, way to do this is to lift all type variables into the class specification. Thus, instead of class Foo f where foo :: forall a. a - f a we would instead have class Foo f a where foo :: a - f a According to the intention of the design, variables thus lifted should remain polymorphic in instances however they can have contexts applied to them: instance (Num a) = Foo F a where foo = ... The reason this is unsatisfying is that there's no way to enforce that instances don't ground these variables, which can interfere with the validity of applying certain laws/transformations. Also, if you need to lift more than one variable in the same class then it can be tricky to do the encoding right. For instance, when converting Monad into this form (e.g. so we can define an instance for Set) it is prudent to separate it into one class for return and another for join/(=)/(). But it does solve the problem at hand. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Referring to Prelude.(++)
I'd like to redefine (++) so that it works on a more general class of lists (ListOf a). To do this, I found that I can import the Prelude hiding the definition of (++). Then I want to make [] an instance of ListOf, and have the (++) function call the built-in Prelude.(++). My problem is that I can't figure out how to call the built-in function. Just using Prelude.(++) doesn't seem to work in the way that Prelude.foldl would (for example). Any ideas? Terry___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Referring to Prelude.(++)
Did you try (Prelude.++)? I think that's the way it needs to be done. Dan On Thu, Sep 24, 2009 at 8:59 PM, Terry Hayes tdcha...@pacbell.net wrote: I'd like to redefine (++) so that it works on a more general class of lists (ListOf a). To do this, I found that I can import the Prelude hiding the definition of (++). Then I want to make [] an instance of ListOf, and have the (++) function call the built-in Prelude.(++). My problem is that I can't figure out how to call the built-in function. Just using Prelude.(++) doesn't seem to work in the way that Prelude.foldl would (for example). Any ideas? Terry ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Referring to Prelude.(++)
Thanks, you got me to head in the correct direction. I need to import Prelude twice, once without (++) and once qualified only for the (++) function. import Prelude hiding ( (++) ) import qualified Prelude ( (++) ) Terry From: Daniel Peebles pumpkin...@gmail.com To: Terry Hayes tdcha...@pacbell.net Cc: haskell-cafe@haskell.org Sent: Thursday, September 24, 2009 6:02:18 PM Subject: Re: [Haskell-cafe] Referring to Prelude.(++) Did you try (Prelude.++)? I think that's the way it needs to be done. Dan On Thu, Sep 24, 2009 at 8:59 PM, Terry Hayes tdcha...@pacbell.net wrote: I'd like to redefine (++) so that it works on a more general class of lists (ListOf a). To do this, I found that I can import the Prelude hiding the definition of (++). Then I want to make [] an instance of ListOf, and have the (++) function call the built-in Prelude.(++). My problem is that I can't figure out how to call the built-in function. Just using Prelude.(++) doesn't seem to work in the way that Prelude.foldl would (for example). Any ideas? Terry ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Monad Tutorial in C++
Just wrote yet another of the above if anybody wants one: http://nuerd.blogspot.com/2009/09/monad-tutorial-in-c.html Adrian. -- View this message in context: http://www.nabble.com/Monad-Tutorial-in-C%2B%2B-tp25606090p25606090.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monad Tutorial in C++
Sorry for the double post - the machine said it had rejected the first one. -- View this message in context: http://www.nabble.com/Monad-Tutorial-in-C%2B%2B-tp25606090p25606162.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] An issue with EDSLs in the ``finally tagless'' tradition
Bruno, On Thu, Sep 24, 2009 at 1:20 AM, Bruno Oliveira br...@ropas.snu.ac.kr wrote: Hello Brad, I believe that the problem you encountered is not quite the expression problem (which is about adding new constructors and functions modularly), but rather about refining *existing* constructs with more specific types. One could argue that they are related though but, for your own sake, you may want to use a term that more directly points to the problem in question. [...] Indeed, for finding existing approaches to this problem, it is prudent to know what others refer to it as. If you squint a little, this looks like an instance of the expression problem: type classes are (families of) constructors, and instances of those type classes (i.e., interpretations) are functions on those constructors. Sincerely, Brad ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] An issue with EDSLs in the ``finally tagless'' tradition
Wren, On Thu, Sep 24, 2009 at 8:36 PM, wren ng thornton w...@freegeek.org wrote: Brad Larsen wrote: The modularity problem I speak of is that to add a new interpretation of the DSL, I will likely have to modify the EDSL definition to add additional constraints. Ideally, I would like to be able to define the EDSL once, in a module, and be able to write arbitrary interpretations of it in other modules, without having to go back and change the EDSL definition. The canonical, if theoretically unsatisfying, way to do this is to lift all type variables into the class specification. Thus, instead of class Foo f where foo :: forall a. a - f a we would instead have class Foo f a where foo :: a - f a According to the intention of the design, variables thus lifted should remain polymorphic in instances however they can have contexts applied to them: instance (Num a) = Foo F a where foo = ... The reason this is unsatisfying is that there's no way to enforce that instances don't ground these variables, which can interfere with the validity of applying certain laws/transformations. Also, if you need to lift more than one variable in the same class then it can be tricky to do the encoding right. For instance, when converting Monad into this form (e.g. so we can define an instance for Set) it is prudent to separate it into one class for return and another for join/(=)/(). But it does solve the problem at hand. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe I have experimented some in the past day with this canonical technique of lifting type variables into the class specification. This is somewhat successful; however, one problem is that when multiple variables are lifted into the specification, ambiguity creeps in (and over-generality?), in the absence of superclass constraints or functional dependencies. So, for example, Foo seems to work well, but Bar does not: class Foo a where ... class Bar a b where ... One can alleviate the ambiguity of Bar by splitting it into two classes, similarly to splitting up Monad: class PreBar a where ... class (PreBar a) = Bar a b where ... It's not clear to me that such a decomposition is always possible. I'll keep experimenting with modular, tagless EDSLs... Sincerely, Brad ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
