[Haskell-cafe] Robert Harper on monads and laziness
I'm following Harper's blog, Existential Type¹, which I find to be an enjoyable and entertainingly written tirade about the advantages of teaching functional programming - specifically ML - to students. Of course, he tends to be critical of Haskell, but it's nice to get some thought provoking opinion from somebody who knows a bit about the business. Recently, he had a piece on monads, and how to do them in ML, and one statement puzzled me: There is a particular reason why monads had to arise in Haskell, though, which is to defeat the scourge of laziness. My own view is/was that monads were so successful in Haskell since it allowed writing flexible programs with imperative features, without sacrificing referential transparency. Although people are quick (and rightly so) to point out that this flexibility goes way beyond IO, I think IO was in many ways the killer application for monads. Before IO, we had very limited functionality (like 'interact' taking a 'String - String' function and converting it into an exectuable program) to build real programs from. Laziness does require referential transparency (or at least, it is easier to get away with the lack of RT in a strict language), so I can see that he is indirectly correct, but RT is a goal in itself. Thus, I wonder if there are any other rationale for a statement like that? -k ¹ http://existentialtype.wordpress.com/ -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Robert Harper on monads and laziness
Yes, I'm following it too, and it seems to me that Harper just allows his dislike for Haskell to take advantage of his judgement. Monads as a way to deal with laziness are a very common misconception. Отправлено с iPhone May 2, 2011, в 11:54, Ketil Malde ke...@malde.org написал(а): I'm following Harper's blog, Existential Type¹, which I find to be an enjoyable and entertainingly written tirade about the advantages of teaching functional programming - specifically ML - to students. Of course, he tends to be critical of Haskell, but it's nice to get some thought provoking opinion from somebody who knows a bit about the business. Recently, he had a piece on monads, and how to do them in ML, and one statement puzzled me: There is a particular reason why monads had to arise in Haskell, though, which is to defeat the scourge of laziness. My own view is/was that monads were so successful in Haskell since it allowed writing flexible programs with imperative features, without sacrificing referential transparency. Although people are quick (and rightly so) to point out that this flexibility goes way beyond IO, I think IO was in many ways the killer application for monads. Before IO, we had very limited functionality (like 'interact' taking a 'String - String' function and converting it into an exectuable program) to build real programs from. Laziness does require referential transparency (or at least, it is easier to get away with the lack of RT in a strict language), so I can see that he is indirectly correct, but RT is a goal in itself. Thus, I wonder if there are any other rationale for a statement like that? -k ¹ http://existentialtype.wordpress.com/ -- If I haven't seen further, it is by standing in the footprints of giants ___ 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] Robert Harper on monads and laziness
On 2011-05-02 03:54, Ketil Malde wrote: There is a particular reason why monads had to arise in Haskell, though, which is to defeat the scourge of laziness. I wonder if there are any other rationale for a statement like that? He spends one paragraph dismissing the usefulness of referential transparency You cannot easily convert between functional and monadic style without a radical restructuring of code. ... you are deprived of the useful concept of a benign effect I imagine that he considered how he prefers ML the way it is, without base libraries thoroughly rewritten to support purity. If purity and RT aren't the reason why Haskell uses monads, what's left? Laziness does have disadvantages. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Links into list
Hello all, I have rather strange question. I wonder whether there is an obvious solution or not in Haskell. I tried but without defining quite ugly tree-like structures and incorporating IORefs it seems to me like impossible. Note: I use ASCII art to explain. let l be a Haskell list +-+-+-+ l = | | | | +-+-+-+ let li be another Haskell list +-+-+-+ li = |a|b|c| +-+-+-+ let hi be a hook/pointer list such, that it links some/all members of the list li +--+--+--+ hi = |pa|pb|pc| +--+--+--+ | | | V V V +--+--+--+ li = |a |b |c | +--+--+--+ When I insert li into l, I would like to get something like: +--+--+--+ hi =|pa|pb|pc| +--+--+--+ | | | V V V +-+-+--+--+--+--+---+ l' = | | | |a |b |c | | +-+-+--+--+--+--+---+ where l' is still a Haskell list. Now, I would like to modify, directly via pb the list l' to have: +--+--+--+ hi =|pa|pb|pc| +--+--+--+ | | +---+ V V V +-+-+--+--+--+-+-+-+-+--+---+ le = | | | |a |b |q|w|e|r|c | | +-+-+--+--+--+-+-+-+-+--+---+ where le is a Haskell list, but, in fact accessible through the same ID/reference all the time. Simply: I would like to have direct access into several places in a very long list. Moreover, the efficiency and features of Haskell list and all the functions around it are to be used as well (not all, but many, nevertheless, I could make them new, if I can achieve good performance, not a big trouble). Is it possible, or not? Could you possibly point me to some resource I can get more information about such tricks. Thanks John -- John Sneer johnsn...@operamail.com -- http://www.fastmail.fm - A no graphics, no pop-ups email service ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Links into list
On 2 May 2011 11:10, John Sneer johnsn...@operamail.com wrote: Hello all, I have rather strange question. I wonder whether there is an obvious solution or not in Haskell. I tried but without defining quite ugly tree-like structures and incorporating IORefs it seems to me like impossible. What you want seems more applicable to a Sequence rather than a list. -- 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] How to make ghc 7 with llvm?
Sorry to reply after so long time. When you say there is no proble, I understand it as: Even if some libraries were compiled with gcc, they are still linkable with object files generated with llvm. So this remembered me a problem I met long ago with no answer. I compiled ghc 7 with ghc 6 and gcc. Everything was fine. Then I added -fllvm to ghc to install some hackages. This was when I noticed that, the new hackage reported some dependencies were lost, which were actually in the system (and same version). Then I recompile the missing dependencies, and noticed from ghc-pkg that, the old ones and the new ones were having different sign, the thing that looks like a hash code after the name of package. Now I dropped -fllvm, everything now seems really fine. On Fri, Apr 29, 2011 at 9:58 AM, Erik de Castro Lopo mle...@mega-nerd.com wrote: Magicloud Magiclouds wrote: As I recalled, ghc started to support llvm from version 7. Yes. But there is a problem: there is no option to make ghc with llvm. Its not an option, its a feature that is compiled in by default and enabled by using -fllvm on the ghc command line. So Library within ghc source will be in gcc's binary format. It is my understanding that libraries compiled via the native code generator (NCG) are fully compatible with libraries compiled with -fllvm. Then when I install other packages, they may complain that the binary format is not llvm, so they install some libraries again. You seem to think there is a problem where this is no problem :-). Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- 竹密岂妨流水过 山高哪阻野云飞 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Links into list
On Mon, May 2, 2011 at 8:16 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 2 May 2011 11:10, John Sneer johnsn...@operamail.com wrote: Hello all, I have rather strange question. I wonder whether there is an obvious solution or not in Haskell. I tried but without defining quite ugly tree-like structures and incorporating IORefs it seems to me like impossible. What you want seems more applicable to a Sequence rather than a list. Or a mutable list, something like data MList s a = Nil | Cons (STRef s a) (STRef s (MList s a)) Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Links into list
Well, I have more or less similar solution, but its efficiency for map/foldr etc. is quite low :-( Nevertheless, probably no other solution. BR and thanks John -- John Sneer johnsn...@operamail.com On Mon, 02 May 2011 08:32 -0300, Felipe Almeida Lessa felipe.le...@gmail.com wrote: On Mon, May 2, 2011 at 8:16 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 2 May 2011 11:10, John Sneer johnsn...@operamail.com wrote: Hello all, I have rather strange question. I wonder whether there is an obvious solution or not in Haskell. I tried but without defining quite ugly tree-like structures and incorporating IORefs it seems to me like impossible. What you want seems more applicable to a Sequence rather than a list. Or a mutable list, something like data MList s a = Nil | Cons (STRef s a) (STRef s (MList s a)) Cheers, -- Felipe. -- http://www.fastmail.fm - Email service worth paying for. Try it for free ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Links into list
Re-CCing the list. On 2 May 2011 11:33, John Sneer johnsn...@operamail.com wrote: I took a look at http://cvs.haskell.org/Hugs/pages/libraries/base/Data-Sequence.html but it doesn't seem to be helpful - cannot insert sequence into the sequence, just modification of a single element is supported. Moreover, indexing via Ints would require extra recalculation when something is somewhere inserted. So, either it is not the solution or I have not understood the Sequence well. :-( Well, you can split the list (probably using splitAt) and then insert another one in between (using ). -- 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] Links into list
On 02/05/11 13:10, John Sneer wrote: Simply: I would like to have direct access into several places in a very long list. Maybe you could use a zipper. Or just maintain the list split into chunks. So l' = [stuffBefore,hi,stuffAfter]. Or if you want to be able to use each element of hi as a kind of pointer, then l'=[stuffBefore] ++ map (:[]) hi ++ [stuffAfter] Now modification becomes just a matter of replacing the appropriate chunk. Twan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Robert Harper on monads and laziness
2011/5/2 Ketil Malde ke...@malde.org: There is a particular reason why monads had to arise in Haskell, though, which is to defeat the scourge of laziness. My own view is/was that monads were so successful in Haskell since it allowed writing flexible programs with imperative features, without sacrificing referential transparency. [...] Laziness does require referential transparency (or at least, it is easier to get away with the lack of RT in a strict language), so I can see that he is indirectly correct, but RT is a goal in itself. Thus, I wonder if there are any other rationale for a statement like that? I agree with your analysis. Throughout his different articles, I think Harper partly has a point when he says that laziness brings certain disadvantages (like e.g. complex memory and CPU behaviour) to Haskell (although I disagree with some of his other arguments here). However, like you say, he misses the ball by amalgamating laziness with referential transparency, where the first probably requires the second but not vice versa. This allows him to simply dismiss both, which is convenient for his apparent conclusion that ML is strictly better than Haskell, since referential transparency and purity are (in my view) one of the things ML lacks most when compared to Haskell. His only other argument against referential transparency and purity seems to be his mentioning of benign effects, which is weak for two reasons: first, benign effects are clearly not what typical ML programs use non-purity for and second, benign effects can be supported much more conservatively using Haskell's unsafePerformIO. Dominique ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [web-devel] Odd Ambiguous type variable `a0' in the constraint: error (with Yesod)
Ok I have found the source issue, in my case it was an issue that ended up turning into how the modules for my Webserver is organized, and that compiler error (about an ambiguous type) occurred because my main webserver datatype was not instantiated yet in that module (using where aproot). In essence there were 2 issues The original problem (with the ambigous type error) was fixed by just simply providing a type (in this case RepHtml) to the function definition Once this was done, the second problem occured due to using splicing with Template Haskell (from mkYesod). What I was attempting to do is to seperate the handlers (of the form get/postR) from the routes created with mkYesod. This wasn't originally an issue until I tried to create widgets, and it was due to the use of defaultLayout. Handlers using defaultLayout needs to be placed *after* the instantiation of yesod (where you do instance yesod *** where aproot *) however, the mkYesod requires the handlers (of the form get/postR) to be placed before the routes. Handlers without a defaultLayout do not require the Yesod instantiation to compile (which is why the error never came up before, I never used defaultLayout prior to attempting to use widgets). This created some horrific cyclic module dependably, where I was forced to use hs-boot files along with creating a dummy module which just contains the instance Yesod ** where ** by itself. Splitting off that instantiation into a separate module was required since hs-boot files don't work with functions that do splicing due to template haskell Of course if GHC supported cyclic module dependencies out of the box (and support for function splices with template haskell in those hs-boot files are added) then this would have been much less painful, is there any plan to support automatic creating of hs-boot files to GHC anytime soon? On Sun, May 1, 2011 at 11:00 PM, Michael Snoyman mich...@snoyman.comwrote: Without seeing the actual code that's causing the breakage, there's not much I can tell you. (If you'd like me to take a look off-list, feel free to send me a private email.) My best recommendation is to try putting a type signature on getRootR. As a general issue: polymorphic Hamlet is a very convenient feature, but I think it leads to too much complexity in the type system. I've added some code for non-polymorphic Hamlet to the Github repo and will be releasing it as its own module (Text.Hamlet.NonPoly) in the next release. Assuming all goes well, it will be replacing the current Hamlet. That essentially means that you'll need to replace your code with something like: getRootR = defaultLayout $ do setTitle Polymorphic Hamlet addHtml [$html|pI was added with addHtml|] addHamlet [$hamlet|pI was added with addHamlet|] addWidget [$whamlet|pI was added with addWidget|] And just to make everyone curious: I've also added i18n support to non-poly Hamlet. I've got a long train ride on Tuesday, and I'm planning on documenting it then. Michael On Sun, May 1, 2011 at 6:50 AM, Mathew de Detrich dete...@gmail.com wrote: Ok so I have a problem that was described here (http://permalink.gmane.org/gmane.comp.lang.haskell.web/1431) in regards to returning a Ambiguous type variable `a0' in the constraint error when compiling. Originally I thought it was due to the way I was coding that part of the code (or to be more accurate the code specifically for creating the so called widgets with addHTML/addWidget,addHamlet). So I copied the example code given here exactly (http://www.yesodweb.com/book/example-widgets). Compiling this worked fine, so at the next point I changed the definition of getRootR to getRootR = defaultLayout $ wrapper $ do setTitle Polymorphic Hamlet addHtml [$hamlet|pI was added with addHtml|] addHamlet [$hamlet|pI was added with addHamlet|] addWidget [$hamlet|pI was added with addWidget|] and then to getRootR = defaultLayout $ do setTitle Polymorphic Hamlet addHtml [$hamlet|pI was added with addHtml|] addHamlet [$hamlet|pI was added with addHamlet|] addWidget [$hamlet|pI was added with addWidget|] Both times compiled fine, so the issue wasn't what I originally thought that it was (as described in http://permalink.gmane.org/gmane.comp.lang.haskell.web/1431). The problem is, that when I use the above example code in my WebServer, I get this Ambigious type error when compiling (even though I have set up the route the exact same way). Unfortunatley I can't provide the code for my webserver, since its commercially owned (and it would be pointless because its just renamed variables, but otherwise its the same), so does anyone have any ideas what could possibly cause such an error (such as a missing/extra import or some package or something), or possibly some missing instances? Also sorry for creating another mailing list, but its a different issue then
Re: [Haskell-cafe] [web-devel] Odd Ambiguous type variable `a0' in the constraint: error (with Yesod)
Actually, there's a much simpler solution already implemented in the scaffolded site: instead of using mkYesod, use mkYesodData and mkYesodDispatch. mkYesod is really just a combination of the two. The former defines your route datatype, and the latter creates the YesodDispatch instance. This allows you to create your route in one module, put your handlers in their own modules, and then import those handlers in the final module that calls mkYesodDispatch. HTH, Michael On Mon, May 2, 2011 at 4:14 PM, Mathew de Detrich dete...@gmail.com wrote: Ok I have found the source issue, in my case it was an issue that ended up turning into how the modules for my Webserver is organized, and that compiler error (about an ambiguous type) occurred because my main webserver datatype was not instantiated yet in that module (using where aproot). In essence there were 2 issues The original problem (with the ambigous type error) was fixed by just simply providing a type (in this case RepHtml) to the function definition Once this was done, the second problem occured due to using splicing with Template Haskell (from mkYesod). What I was attempting to do is to seperate the handlers (of the form get/postR) from the routes created with mkYesod. This wasn't originally an issue until I tried to create widgets, and it was due to the use of defaultLayout. Handlers using defaultLayout needs to be placed *after* the instantiation of yesod (where you do instance yesod *** where aproot *) however, the mkYesod requires the handlers (of the form get/postR) to be placed before the routes. Handlers without a defaultLayout do not require the Yesod instantiation to compile (which is why the error never came up before, I never used defaultLayout prior to attempting to use widgets). This created some horrific cyclic module dependably, where I was forced to use hs-boot files along with creating a dummy module which just contains the instance Yesod ** where ** by itself. Splitting off that instantiation into a separate module was required since hs-boot files don't work with functions that do splicing due to template haskell Of course if GHC supported cyclic module dependencies out of the box (and support for function splices with template haskell in those hs-boot files are added) then this would have been much less painful, is there any plan to support automatic creating of hs-boot files to GHC anytime soon? On Sun, May 1, 2011 at 11:00 PM, Michael Snoyman mich...@snoyman.com wrote: Without seeing the actual code that's causing the breakage, there's not much I can tell you. (If you'd like me to take a look off-list, feel free to send me a private email.) My best recommendation is to try putting a type signature on getRootR. As a general issue: polymorphic Hamlet is a very convenient feature, but I think it leads to too much complexity in the type system. I've added some code for non-polymorphic Hamlet to the Github repo and will be releasing it as its own module (Text.Hamlet.NonPoly) in the next release. Assuming all goes well, it will be replacing the current Hamlet. That essentially means that you'll need to replace your code with something like: getRootR = defaultLayout $ do setTitle Polymorphic Hamlet addHtml [$html|pI was added with addHtml|] addHamlet [$hamlet|pI was added with addHamlet|] addWidget [$whamlet|pI was added with addWidget|] And just to make everyone curious: I've also added i18n support to non-poly Hamlet. I've got a long train ride on Tuesday, and I'm planning on documenting it then. Michael On Sun, May 1, 2011 at 6:50 AM, Mathew de Detrich dete...@gmail.com wrote: Ok so I have a problem that was described here (http://permalink.gmane.org/gmane.comp.lang.haskell.web/1431) in regards to returning a Ambiguous type variable `a0' in the constraint error when compiling. Originally I thought it was due to the way I was coding that part of the code (or to be more accurate the code specifically for creating the so called widgets with addHTML/addWidget,addHamlet). So I copied the example code given here exactly (http://www.yesodweb.com/book/example-widgets). Compiling this worked fine, so at the next point I changed the definition of getRootR to getRootR = defaultLayout $ wrapper $ do setTitle Polymorphic Hamlet addHtml [$hamlet|pI was added with addHtml|] addHamlet [$hamlet|pI was added with addHamlet|] addWidget [$hamlet|pI was added with addWidget|] and then to getRootR = defaultLayout $ do setTitle Polymorphic Hamlet addHtml [$hamlet|pI was added with addHtml|] addHamlet [$hamlet|pI was added with addHamlet|] addWidget [$hamlet|pI was added with addWidget|] Both times compiled fine, so the issue wasn't what I originally thought that it was (as described in http://permalink.gmane.org/gmane.comp.lang.haskell.web/1431). The problem is, that when I use the
Re: [Haskell-cafe] Robert Harper on monads and laziness
On Mon, May 2, 2011 at 9:29 AM, Dominique Devriese dominique.devri...@cs.kuleuven.be wrote: I agree with your analysis. Throughout his different articles, I think Harper partly has a point when he says that laziness brings certain disadvantages (like e.g. complex memory and CPU behaviour) to Haskell (although I disagree with some of his other arguments here). However, like you say, he misses the ball by amalgamating laziness with referential transparency, where the first probably requires the second but not vice versa. This allows him to simply dismiss both, which is convenient for his apparent conclusion that ML is strictly better than Haskell, since referential transparency and purity are (in my view) one of the things ML lacks most when compared to Haskell. His only other argument against referential transparency and purity seems to be his mentioning of benign effects, which is weak for two reasons: first, benign effects are clearly not what typical ML programs use non-purity for and second, benign effects can be supported much more conservatively using Haskell's unsafePerformIO. Or, instead of unsafePerformIO, runST. Saying that we should allow effects everywhere because there are benign effects is like saying that we should allow GOTOs everywhere because there are some benign GOTOs. By allowing these benign things we also open a can of worms of malign things. Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GLUT error while using Gloss
Hi Cafe! When I'm running examles from Gloss graphics library, all examples except gloss-hello are crashing with the following error: GLUT: Warning in gloss-easy: GL error: gloss-easy: stderr: hPutChar: invalid argument (character is not in the code page). A window with produced picture is showed for one second and then it crashes. gloss-hello, strangely, is working perfectly. I'm using Windows 7 (but on XP there is same behaviour), Haskell Platform 2011.2, OpenGL 2.4.0.1, GLUT 2.2.2.0, Gloss 1.3.1.2. At the first time, exampes didn't want to run at all, but I placed glut32.dll from http://www.xmission.com/~nate/glut.html in my .dlls folder. I tried another glut32.dll (from the Raincat game), but it didn't change anything. How can it be fixed? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [web-devel] Odd Ambiguous type variable `a0' in the constraint: error (with Yesod)
.. You tell me this now ;) I was actually wanting to look at scaffolding, but the section for it in the Yesod book is not completed yet (http://www.yesodweb.com/book/scaffold) Well that was like 4 hours wasted Do you have a quick example of how scaffolding is done with mkYesodData and mkYesodDispatch (I only need something trivial)? On Mon, May 2, 2011 at 11:18 PM, Michael Snoyman mich...@snoyman.comwrote: Actually, there's a much simpler solution already implemented in the scaffolded site: instead of using mkYesod, use mkYesodData and mkYesodDispatch. mkYesod is really just a combination of the two. The former defines your route datatype, and the latter creates the YesodDispatch instance. This allows you to create your route in one module, put your handlers in their own modules, and then import those handlers in the final module that calls mkYesodDispatch. HTH, Michael On Mon, May 2, 2011 at 4:14 PM, Mathew de Detrich dete...@gmail.com wrote: Ok I have found the source issue, in my case it was an issue that ended up turning into how the modules for my Webserver is organized, and that compiler error (about an ambiguous type) occurred because my main webserver datatype was not instantiated yet in that module (using where aproot). In essence there were 2 issues The original problem (with the ambigous type error) was fixed by just simply providing a type (in this case RepHtml) to the function definition Once this was done, the second problem occured due to using splicing with Template Haskell (from mkYesod). What I was attempting to do is to seperate the handlers (of the form get/postR) from the routes created with mkYesod. This wasn't originally an issue until I tried to create widgets, and it was due to the use of defaultLayout. Handlers using defaultLayout needs to be placed *after* the instantiation of yesod (where you do instance yesod *** where aproot *) however, the mkYesod requires the handlers (of the form get/postR) to be placed before the routes. Handlers without a defaultLayout do not require the Yesod instantiation to compile (which is why the error never came up before, I never used defaultLayout prior to attempting to use widgets). This created some horrific cyclic module dependably, where I was forced to use hs-boot files along with creating a dummy module which just contains the instance Yesod ** where ** by itself. Splitting off that instantiation into a separate module was required since hs-boot files don't work with functions that do splicing due to template haskell Of course if GHC supported cyclic module dependencies out of the box (and support for function splices with template haskell in those hs-boot files are added) then this would have been much less painful, is there any plan to support automatic creating of hs-boot files to GHC anytime soon? On Sun, May 1, 2011 at 11:00 PM, Michael Snoyman mich...@snoyman.com wrote: Without seeing the actual code that's causing the breakage, there's not much I can tell you. (If you'd like me to take a look off-list, feel free to send me a private email.) My best recommendation is to try putting a type signature on getRootR. As a general issue: polymorphic Hamlet is a very convenient feature, but I think it leads to too much complexity in the type system. I've added some code for non-polymorphic Hamlet to the Github repo and will be releasing it as its own module (Text.Hamlet.NonPoly) in the next release. Assuming all goes well, it will be replacing the current Hamlet. That essentially means that you'll need to replace your code with something like: getRootR = defaultLayout $ do setTitle Polymorphic Hamlet addHtml [$html|pI was added with addHtml|] addHamlet [$hamlet|pI was added with addHamlet|] addWidget [$whamlet|pI was added with addWidget|] And just to make everyone curious: I've also added i18n support to non-poly Hamlet. I've got a long train ride on Tuesday, and I'm planning on documenting it then. Michael On Sun, May 1, 2011 at 6:50 AM, Mathew de Detrich dete...@gmail.com wrote: Ok so I have a problem that was described here (http://permalink.gmane.org/gmane.comp.lang.haskell.web/1431) in regards to returning a Ambiguous type variable `a0' in the constraint error when compiling. Originally I thought it was due to the way I was coding that part of the code (or to be more accurate the code specifically for creating the so called widgets with addHTML/addWidget,addHamlet). So I copied the example code given here exactly (http://www.yesodweb.com/book/example-widgets ). Compiling this worked fine, so at the next point I changed the definition of getRootR to getRootR = defaultLayout $ wrapper $ do setTitle Polymorphic Hamlet addHtml [$hamlet|pI was added with addHtml|] addHamlet [$hamlet|pI was added with
Re: [Haskell-cafe] [web-devel] Odd Ambiguous type variable `a0' in the constraint: error (with Yesod)
My best advice is to just run the scaffolder. Any other examples I can point you to (like the Haskellers source code) will contain a lot of extra information that won't necessarily apply to your case. Michael On Mon, May 2, 2011 at 4:28 PM, Mathew de Detrich dete...@gmail.com wrote: .. You tell me this now ;) I was actually wanting to look at scaffolding, but the section for it in the Yesod book is not completed yet (http://www.yesodweb.com/book/scaffold) Well that was like 4 hours wasted Do you have a quick example of how scaffolding is done with mkYesodData and mkYesodDispatch (I only need something trivial)? On Mon, May 2, 2011 at 11:18 PM, Michael Snoyman mich...@snoyman.com wrote: Actually, there's a much simpler solution already implemented in the scaffolded site: instead of using mkYesod, use mkYesodData and mkYesodDispatch. mkYesod is really just a combination of the two. The former defines your route datatype, and the latter creates the YesodDispatch instance. This allows you to create your route in one module, put your handlers in their own modules, and then import those handlers in the final module that calls mkYesodDispatch. HTH, Michael On Mon, May 2, 2011 at 4:14 PM, Mathew de Detrich dete...@gmail.com wrote: Ok I have found the source issue, in my case it was an issue that ended up turning into how the modules for my Webserver is organized, and that compiler error (about an ambiguous type) occurred because my main webserver datatype was not instantiated yet in that module (using where aproot). In essence there were 2 issues The original problem (with the ambigous type error) was fixed by just simply providing a type (in this case RepHtml) to the function definition Once this was done, the second problem occured due to using splicing with Template Haskell (from mkYesod). What I was attempting to do is to seperate the handlers (of the form get/postR) from the routes created with mkYesod. This wasn't originally an issue until I tried to create widgets, and it was due to the use of defaultLayout. Handlers using defaultLayout needs to be placed *after* the instantiation of yesod (where you do instance yesod *** where aproot *) however, the mkYesod requires the handlers (of the form get/postR) to be placed before the routes. Handlers without a defaultLayout do not require the Yesod instantiation to compile (which is why the error never came up before, I never used defaultLayout prior to attempting to use widgets). This created some horrific cyclic module dependably, where I was forced to use hs-boot files along with creating a dummy module which just contains the instance Yesod ** where ** by itself. Splitting off that instantiation into a separate module was required since hs-boot files don't work with functions that do splicing due to template haskell Of course if GHC supported cyclic module dependencies out of the box (and support for function splices with template haskell in those hs-boot files are added) then this would have been much less painful, is there any plan to support automatic creating of hs-boot files to GHC anytime soon? On Sun, May 1, 2011 at 11:00 PM, Michael Snoyman mich...@snoyman.com wrote: Without seeing the actual code that's causing the breakage, there's not much I can tell you. (If you'd like me to take a look off-list, feel free to send me a private email.) My best recommendation is to try putting a type signature on getRootR. As a general issue: polymorphic Hamlet is a very convenient feature, but I think it leads to too much complexity in the type system. I've added some code for non-polymorphic Hamlet to the Github repo and will be releasing it as its own module (Text.Hamlet.NonPoly) in the next release. Assuming all goes well, it will be replacing the current Hamlet. That essentially means that you'll need to replace your code with something like: getRootR = defaultLayout $ do setTitle Polymorphic Hamlet addHtml [$html|pI was added with addHtml|] addHamlet [$hamlet|pI was added with addHamlet|] addWidget [$whamlet|pI was added with addWidget|] And just to make everyone curious: I've also added i18n support to non-poly Hamlet. I've got a long train ride on Tuesday, and I'm planning on documenting it then. Michael On Sun, May 1, 2011 at 6:50 AM, Mathew de Detrich dete...@gmail.com wrote: Ok so I have a problem that was described here (http://permalink.gmane.org/gmane.comp.lang.haskell.web/1431) in regards to returning a Ambiguous type variable `a0' in the constraint error when compiling. Originally I thought it was due to the way I was coding that part of the code (or to be more accurate the code specifically for creating the so called widgets with addHTML/addWidget,addHamlet). So I copied the example code given here exactly
Re: [Haskell-cafe] [web-devel] Odd Ambiguous type variable `a0' in the constraint: error (with Yesod)
Im not sure what you mean exactly by run the scaffolder, (just to be clear, I am not exactly sure what technically scaffolding is apart from it being referenced once or twice in your documentation) I assume you are talking about setting up the handlers for a specific route, and then creating that single route on its own (instead of all at once with mkYesod)? On Mon, May 2, 2011 at 11:30 PM, Michael Snoyman mich...@snoyman.comwrote: My best advice is to just run the scaffolder. Any other examples I can point you to (like the Haskellers source code) will contain a lot of extra information that won't necessarily apply to your case. Michael On Mon, May 2, 2011 at 4:28 PM, Mathew de Detrich dete...@gmail.com wrote: .. You tell me this now ;) I was actually wanting to look at scaffolding, but the section for it in the Yesod book is not completed yet (http://www.yesodweb.com/book/scaffold) Well that was like 4 hours wasted Do you have a quick example of how scaffolding is done with mkYesodData and mkYesodDispatch (I only need something trivial)? On Mon, May 2, 2011 at 11:18 PM, Michael Snoyman mich...@snoyman.com wrote: Actually, there's a much simpler solution already implemented in the scaffolded site: instead of using mkYesod, use mkYesodData and mkYesodDispatch. mkYesod is really just a combination of the two. The former defines your route datatype, and the latter creates the YesodDispatch instance. This allows you to create your route in one module, put your handlers in their own modules, and then import those handlers in the final module that calls mkYesodDispatch. HTH, Michael On Mon, May 2, 2011 at 4:14 PM, Mathew de Detrich dete...@gmail.com wrote: Ok I have found the source issue, in my case it was an issue that ended up turning into how the modules for my Webserver is organized, and that compiler error (about an ambiguous type) occurred because my main webserver datatype was not instantiated yet in that module (using where aproot). In essence there were 2 issues The original problem (with the ambigous type error) was fixed by just simply providing a type (in this case RepHtml) to the function definition Once this was done, the second problem occured due to using splicing with Template Haskell (from mkYesod). What I was attempting to do is to seperate the handlers (of the form get/postR) from the routes created with mkYesod. This wasn't originally an issue until I tried to create widgets, and it was due to the use of defaultLayout. Handlers using defaultLayout needs to be placed *after* the instantiation of yesod (where you do instance yesod *** where aproot *) however, the mkYesod requires the handlers (of the form get/postR) to be placed before the routes. Handlers without a defaultLayout do not require the Yesod instantiation to compile (which is why the error never came up before, I never used defaultLayout prior to attempting to use widgets). This created some horrific cyclic module dependably, where I was forced to use hs-boot files along with creating a dummy module which just contains the instance Yesod ** where ** by itself. Splitting off that instantiation into a separate module was required since hs-boot files don't work with functions that do splicing due to template haskell Of course if GHC supported cyclic module dependencies out of the box (and support for function splices with template haskell in those hs-boot files are added) then this would have been much less painful, is there any plan to support automatic creating of hs-boot files to GHC anytime soon? On Sun, May 1, 2011 at 11:00 PM, Michael Snoyman mich...@snoyman.com wrote: Without seeing the actual code that's causing the breakage, there's not much I can tell you. (If you'd like me to take a look off-list, feel free to send me a private email.) My best recommendation is to try putting a type signature on getRootR. As a general issue: polymorphic Hamlet is a very convenient feature, but I think it leads to too much complexity in the type system. I've added some code for non-polymorphic Hamlet to the Github repo and will be releasing it as its own module (Text.Hamlet.NonPoly) in the next release. Assuming all goes well, it will be replacing the current Hamlet. That essentially means that you'll need to replace your code with something like: getRootR = defaultLayout $ do setTitle Polymorphic Hamlet addHtml [$html|pI was added with addHtml|] addHamlet [$hamlet|pI was added with addHamlet|] addWidget [$whamlet|pI was added with addWidget|] And just to make everyone curious: I've also added i18n support to non-poly Hamlet. I've got a long train ride on Tuesday, and I'm planning on documenting it then. Michael On Sun, May 1, 2011 at
Re: [Haskell-cafe] [web-devel] Odd Ambiguous type variable `a0' in the constraint: error (with Yesod)
Type: yesod init It will ask you some questions and then generate a bootstrap site. Michael On Mon, May 2, 2011 at 4:40 PM, Mathew de Detrich dete...@gmail.com wrote: Im not sure what you mean exactly by run the scaffolder, (just to be clear, I am not exactly sure what technically scaffolding is apart from it being referenced once or twice in your documentation) I assume you are talking about setting up the handlers for a specific route, and then creating that single route on its own (instead of all at once with mkYesod)? On Mon, May 2, 2011 at 11:30 PM, Michael Snoyman mich...@snoyman.com wrote: My best advice is to just run the scaffolder. Any other examples I can point you to (like the Haskellers source code) will contain a lot of extra information that won't necessarily apply to your case. Michael On Mon, May 2, 2011 at 4:28 PM, Mathew de Detrich dete...@gmail.com wrote: .. You tell me this now ;) I was actually wanting to look at scaffolding, but the section for it in the Yesod book is not completed yet (http://www.yesodweb.com/book/scaffold) Well that was like 4 hours wasted Do you have a quick example of how scaffolding is done with mkYesodData and mkYesodDispatch (I only need something trivial)? On Mon, May 2, 2011 at 11:18 PM, Michael Snoyman mich...@snoyman.com wrote: Actually, there's a much simpler solution already implemented in the scaffolded site: instead of using mkYesod, use mkYesodData and mkYesodDispatch. mkYesod is really just a combination of the two. The former defines your route datatype, and the latter creates the YesodDispatch instance. This allows you to create your route in one module, put your handlers in their own modules, and then import those handlers in the final module that calls mkYesodDispatch. HTH, Michael On Mon, May 2, 2011 at 4:14 PM, Mathew de Detrich dete...@gmail.com wrote: Ok I have found the source issue, in my case it was an issue that ended up turning into how the modules for my Webserver is organized, and that compiler error (about an ambiguous type) occurred because my main webserver datatype was not instantiated yet in that module (using where aproot). In essence there were 2 issues The original problem (with the ambigous type error) was fixed by just simply providing a type (in this case RepHtml) to the function definition Once this was done, the second problem occured due to using splicing with Template Haskell (from mkYesod). What I was attempting to do is to seperate the handlers (of the form get/postR) from the routes created with mkYesod. This wasn't originally an issue until I tried to create widgets, and it was due to the use of defaultLayout. Handlers using defaultLayout needs to be placed *after* the instantiation of yesod (where you do instance yesod *** where aproot *) however, the mkYesod requires the handlers (of the form get/postR) to be placed before the routes. Handlers without a defaultLayout do not require the Yesod instantiation to compile (which is why the error never came up before, I never used defaultLayout prior to attempting to use widgets). This created some horrific cyclic module dependably, where I was forced to use hs-boot files along with creating a dummy module which just contains the instance Yesod ** where ** by itself. Splitting off that instantiation into a separate module was required since hs-boot files don't work with functions that do splicing due to template haskell Of course if GHC supported cyclic module dependencies out of the box (and support for function splices with template haskell in those hs-boot files are added) then this would have been much less painful, is there any plan to support automatic creating of hs-boot files to GHC anytime soon? On Sun, May 1, 2011 at 11:00 PM, Michael Snoyman mich...@snoyman.com wrote: Without seeing the actual code that's causing the breakage, there's not much I can tell you. (If you'd like me to take a look off-list, feel free to send me a private email.) My best recommendation is to try putting a type signature on getRootR. As a general issue: polymorphic Hamlet is a very convenient feature, but I think it leads to too much complexity in the type system. I've added some code for non-polymorphic Hamlet to the Github repo and will be releasing it as its own module (Text.Hamlet.NonPoly) in the next release. Assuming all goes well, it will be replacing the current Hamlet. That essentially means that you'll need to replace your code with something like: getRootR = defaultLayout $ do setTitle Polymorphic Hamlet addHtml [$html|pI was added with addHtml|] addHamlet [$hamlet|pI was added with addHamlet|] addWidget [$whamlet|pI was added with addWidget|] And
Re: [Haskell-cafe] [web-devel] Odd Ambiguous type variable `a0' in the constraint: error (with Yesod)
Ok thanks, that helped On Mon, May 2, 2011 at 11:53 PM, Michael Snoyman mich...@snoyman.comwrote: Type: yesod init It will ask you some questions and then generate a bootstrap site. Michael On Mon, May 2, 2011 at 4:40 PM, Mathew de Detrich dete...@gmail.com wrote: Im not sure what you mean exactly by run the scaffolder, (just to be clear, I am not exactly sure what technically scaffolding is apart from it being referenced once or twice in your documentation) I assume you are talking about setting up the handlers for a specific route, and then creating that single route on its own (instead of all at once with mkYesod)? On Mon, May 2, 2011 at 11:30 PM, Michael Snoyman mich...@snoyman.com wrote: My best advice is to just run the scaffolder. Any other examples I can point you to (like the Haskellers source code) will contain a lot of extra information that won't necessarily apply to your case. Michael On Mon, May 2, 2011 at 4:28 PM, Mathew de Detrich dete...@gmail.com wrote: .. You tell me this now ;) I was actually wanting to look at scaffolding, but the section for it in the Yesod book is not completed yet ( http://www.yesodweb.com/book/scaffold) Well that was like 4 hours wasted Do you have a quick example of how scaffolding is done with mkYesodData and mkYesodDispatch (I only need something trivial)? On Mon, May 2, 2011 at 11:18 PM, Michael Snoyman mich...@snoyman.com wrote: Actually, there's a much simpler solution already implemented in the scaffolded site: instead of using mkYesod, use mkYesodData and mkYesodDispatch. mkYesod is really just a combination of the two. The former defines your route datatype, and the latter creates the YesodDispatch instance. This allows you to create your route in one module, put your handlers in their own modules, and then import those handlers in the final module that calls mkYesodDispatch. HTH, Michael On Mon, May 2, 2011 at 4:14 PM, Mathew de Detrich dete...@gmail.com wrote: Ok I have found the source issue, in my case it was an issue that ended up turning into how the modules for my Webserver is organized, and that compiler error (about an ambiguous type) occurred because my main webserver datatype was not instantiated yet in that module (using where aproot). In essence there were 2 issues The original problem (with the ambigous type error) was fixed by just simply providing a type (in this case RepHtml) to the function definition Once this was done, the second problem occured due to using splicing with Template Haskell (from mkYesod). What I was attempting to do is to seperate the handlers (of the form get/postR) from the routes created with mkYesod. This wasn't originally an issue until I tried to create widgets, and it was due to the use of defaultLayout. Handlers using defaultLayout needs to be placed *after* the instantiation of yesod (where you do instance yesod *** where aproot *) however, the mkYesod requires the handlers (of the form get/postR) to be placed before the routes. Handlers without a defaultLayout do not require the Yesod instantiation to compile (which is why the error never came up before, I never used defaultLayout prior to attempting to use widgets). This created some horrific cyclic module dependably, where I was forced to use hs-boot files along with creating a dummy module which just contains the instance Yesod ** where ** by itself. Splitting off that instantiation into a separate module was required since hs-boot files don't work with functions that do splicing due to template haskell Of course if GHC supported cyclic module dependencies out of the box (and support for function splices with template haskell in those hs-boot files are added) then this would have been much less painful, is there any plan to support automatic creating of hs-boot files to GHC anytime soon? On Sun, May 1, 2011 at 11:00 PM, Michael Snoyman mich...@snoyman.com wrote: Without seeing the actual code that's causing the breakage, there's not much I can tell you. (If you'd like me to take a look off-list, feel free to send me a private email.) My best recommendation is to try putting a type signature on getRootR. As a general issue: polymorphic Hamlet is a very convenient feature, but I think it leads to too much complexity in the type system. I've added some code for non-polymorphic Hamlet to the Github repo and will be releasing it as its own module (Text.Hamlet.NonPoly) in the next release. Assuming all goes well, it will be replacing the current Hamlet. That essentially means that you'll need to replace your code with something like:
Re: [Haskell-cafe] ANN: Leksah 0.10.0
Hi Mathew, I was not the one working on Yi integration so far, but let me tell you what I think of the matter. Yi attempts to be a full blown editor, while Leksah needs Yi as a library for text editing with features typical of a source code editor component. What we have in Leksah is an abstract TextEditor interface. So if I would work on it (and I can't say if I will do) I would fork Yi, and factor out a simple TextEditor library, and then would try to convince the Yi people that it would make sense to refactor Yi this way. As it is now we have Yi in some way integrated, but it is not well defined, what part of functionality Leksah and Yi play, and I guess we will not reach something usable this way. Jürgen On 30 Apr., 11:25, Mathew de Detrich dete...@gmail.com wrote: Is there going to be any plans to integrate Yi into Leksah as you originally planned to, or is that idea for the short term out the window? On Fri, Apr 22, 2011 at 8:40 PM, Hamish Mackenzie hamish.k.macken...@googlemail.com wrote: Yesterday we uploaded our official 0.10.0 release (0.10.0.4) to Hackage and we have Windows and OS X installers athttp://leksah.org/download.html Anyone using an earlier version should upgrade. This release is mainly small improvements and bug fixes. Some of the improvements include: * Better messages for some common problems. * Improved grep (now searches all source directories in your workspace) * Updated build system for more reliable rebuilding of dependent packages in your workspace We have automated the building of the Leksah installers and this should allow us to do more frequent releases in the future. There is a lot more to do and we would love to hear from anyone who has time to help out. Worth mentioning because they can be hard to find: * Ctrl R adds missing imports * Ctrl Enter evaluates current line or selection in GHCi * Right click menu in the editor has other debug functions * Comment and uncomment are now Ctrl D and Ctrl Shift D To build Leksah yourself: * Install Gtk and GtkSourceView2 (C libraries and headers) * Install The Haskell Platform (or GHC = 6.12.3) * cabal update * cabal install gtk2hs-buildtools * cabal install leksah * leksah Making a Gtk application look nice on Windows and OS X is not easy so we recommend using one of these prebuilt binaries: Windows users using GHC 7.0.3 http://leksah.org/packages/leksah-0.10.0.4-ghc-7.0.3.exe Windows users using GHC 6.12.3 http://leksah.org/packages/leksah-0.10.0.4-ghc-6.12.3.exe OS X 10.6 users using GHC 7.0.3 http://leksah.org/packages/leksah-0.8.0.6.dmg (These installers do not install Gtk2Hs packages on your system) Please consulthttp://leksah.org/download.htmlfor more details about installation! Background information can be found in the Leksah manual http://leksah.org/leksah_manual.pdf. Known bugs and problems: * Leksah does not run with GHC 6.12.2 (http://http://hackage.haskell.org/trac/ghc/ticket/4038) Have fun Jürgen Hamish See you on #leksah IRC ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-C...@haskell.orghttp://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] GLUT error while using Gloss
On Mon, May 2, 2011 at 6:29 AM, Artyom Kazak artyom.ka...@gmail.com wrote: Hi Cafe! When I'm running examles from Gloss graphics library, all examples except gloss-hello are crashing with the following error: GLUT: Warning in gloss-easy: GL error: gloss-easy: stderr: hPutChar: invalid argument (character is not in the code page). A window with produced picture is showed for one second and then it crashes. This is fixed in the git repository for GLUT, but I didn't push the fix to hackage yet: https://github.com/haskell-opengl/GLUT/pull/1 Sorry for the inconvenience! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GLUT error while using Gloss
It's good to hear. Thanks! 2011/5/2 Jason Dagit dag...@gmail.com: This is fixed in the git repository for GLUT, but I didn't push the fix to hackage yet: https://github.com/haskell-opengl/GLUT/pull/1 Sorry for the inconvenience! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Interfacing C++ iterators does not work as expected
Hi,
I tried to access C++ iterators from Haskell via the FFI. There are two
example programs attached, in Haskell as well as in C++. Both utilise the
same iterator wrapper example.cpp, but when running the Haskell program it
prints an empty list, where it should print the contents of some vector. The
C++ program meanwhile runs fine though. What does not seem to work is this
part:
bool
finished (std::vectorint::iterator *begin, std::vectorint::iterator
*end)
{
return *begin == *end;
}
In Haskellland, finished :: Ptr Iterator - Ptr Iterator - IO Bool always
returns IO True. Is this a bug lurking in my program or is it a GHC issue?
Long
ffi_and_iterators.tar.gz
Description: GNU Zip compressed data
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Reformatter for Show
Hello everyone!
Haskell have nice automatically derivable Show type class. It's quite
useful for debugging with one exception. String representation of even
moderately large value is completely unreadable (example below).
My question is there any tool for reformatting result of show so it
could be read by human beings?
Real life example of world salad produced by show
Module (SrcLoc {srcFilename = rec.hs, srcLine = 1, srcColumn = 1})
(ModuleName Main) [OptionsPragma (SrcLoc {srcFilename = rec.hs,
srcLine = 1, srcColumn = 1}) (Just GHC) -F -pgmF ./preprocessor ]
Nothing (Just [EVar (UnQual (Ident main))]) [] [DataDecl (SrcLoc
{srcFilename = rec.hs, srcLine = 3, srcColumn = 1}) DataType []
(Ident Foo) [] [QualConDecl (SrcLoc {srcFilename = rec.hs,
srcLine = 3, srcColumn = 12}) [] [] (RecDecl (Ident Foo) [([Ident
asd],UnBangedTy (TyCon (UnQual (Ident Int,([Ident
fgh],UnBangedTy (TyCon (UnQual (Ident String])] [(UnQual
...
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reformatter for Show
Hi Alexey, On 2 May 2011 21:01, Alexey Khudyakov alexey.sklad...@gmail.com wrote: My question is there any tool for reformatting result of show so it could be read by human beings? http://hackage.haskell.org/package/pretty-show Just use ppShow, instead of show. Hope this helps, Ozgur ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reformatter for Show
On 2 May 2011 22:01, Alexey Khudyakov alexey.sklad...@gmail.com wrote: Hello everyone! Haskell have nice automatically derivable Show type class. It's quite useful for debugging with one exception. String representation of even moderately large value is completely unreadable (example below). My question is there any tool for reformatting result of show so it could be read by human beings? I'm working on an inspector for it in Emacs, similar to Firebug/Chrome developer bar expansion of objects. If you use Emacs I can let you know when I've done it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interfacing C++ iterators does not work as expected
It works if I replace the 'bool' return type of 'finished' with int
and CInt on the C++ and Haskell side, respectively, and test for (/=
0).
On Mon, May 2, 2011 at 9:35 PM, Huynh Huu Long
long.upc...@googlemail.com wrote:
Hi,
I tried to access C++ iterators from Haskell via the FFI. There are two
example programs attached, in Haskell as well as in C++. Both utilise the
same iterator wrapper example.cpp, but when running the Haskell program it
prints an empty list, where it should print the contents of some vector. The
C++ program meanwhile runs fine though. What does not seem to work is this
part:
bool
finished (std::vectorint::iterator *begin, std::vectorint::iterator
*end)
{
return *begin == *end;
}
In Haskellland, finished :: Ptr Iterator - Ptr Iterator - IO Bool always
returns IO True. Is this a bug lurking in my program or is it a GHC issue?
Long
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Work is punishment for failing to procrastinate effectively.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reformatter for Show
On Mon, May 2, 2011 at 3:01 PM, Alexey Khudyakov
alexey.sklad...@gmail.com wrote:
Hello everyone!
Haskell have nice automatically derivable Show type class. It's quite useful
for debugging with one exception. String representation of even moderately
large value is completely unreadable (example below).
My question is there any tool for reformatting result of show so it could be
read by human beings?
You could use the 'groom' package on Hackage:
http://hackage.haskell.org/package/groom
It works best for the derived show instances.
Antoine
Real life example of world salad produced by show
Module (SrcLoc {srcFilename = rec.hs, srcLine = 1, srcColumn = 1})
(ModuleName Main) [OptionsPragma (SrcLoc {srcFilename = rec.hs,
srcLine = 1, srcColumn = 1}) (Just GHC) -F -pgmF ./preprocessor ]
Nothing (Just [EVar (UnQual (Ident main))]) [] [DataDecl (SrcLoc
{srcFilename = rec.hs, srcLine = 3, srcColumn = 1}) DataType []
(Ident Foo) [] [QualConDecl (SrcLoc {srcFilename = rec.hs,
srcLine = 3, srcColumn = 12}) [] [] (RecDecl (Ident Foo) [([Ident
asd],UnBangedTy (TyCon (UnQual (Ident Int,([Ident
fgh],UnBangedTy (TyCon (UnQual (Ident String])] [(UnQual
...
___
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] versioning of Haskell packages
Rogan Creswick schrieb: We *do* still have some trouble maintaining / enforcing the PVP in general, and there are a few things that it doesn't cover (I don't believe exception behavior is covered, for example, although I'd argue that throwing more exceptions than a previous version introduces a substantial API change. Anyhow, that's a different rant. ;). If exceptions would be part of the type, then adding exceptions would change the API. I would like that very much. We can already have that behaviour with the existing exception handling packages. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interfacing C++ iterators does not work as expected
Big thanks, that works for me as well. Doesn't GHC check whether a type is allowed (like CInt,...) or not (like Bool,...)? 2011/5/2 Gábor Lehel illiss...@gmail.com: It works if I replace the 'bool' return type of 'finished' with int and CInt on the C++ and Haskell side, respectively, and test for (/= 0). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reformatter for Show
Ozgur Akgun wrote: Hi Alexey, On 2 May 2011 21:01, Alexey Khudyakov alexey.sklad...@gmail.com wrote: My question is there any tool for reformatting result of show so it could be read by human beings? http://hackage.haskell.org/package/pretty-show Just use ppShow, instead of show. ppShow also has a command line tool called ppsh. I run ppsh in an xterm, paste the Show output into the xterm and then hit Control-d to see the formatted output. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reformatter for Show
On 03.05.2011 00:43, Antoine Latter wrote: On Mon, May 2, 2011 at 3:01 PM, Alexey Khudyakov alexey.sklad...@gmail.com wrote: Hello everyone! Haskell have nice automatically derivable Show type class. It's quite useful for debugging with one exception. String representation of even moderately large value is completely unreadable (example below). My question is there any tool for reformatting result of show so it could be read by human beings? You could use the 'groom' package on Hackage: http://hackage.haskell.org/package/groom It works best for the derived show instances. Antoine http://hackage.haskell.org/package/pretty-show Just use ppShow, instead of show. Hope this helps, Ozgur Thanks a lot. It's exactly what I looked for. Both packages do they jobs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Leksah 0.10.0
I actually agree with you on that regard, I think the best thing you can get from Yi is just the basic editing commands (the same you would get from vim), such as visual/edit mode and whatnot The best thing that Leksah can turn into (and something that Haskell desperately needs) is a Haskell version of Eclipse, because as Java has a weakness of being incredibly verbose (which Eclipse gets around with very easily, try coding Java in vim!!!), Haskell being a statically typed language has a weakness that in non trivial code, types can become convoluted and 'piping' functions together becoming complicated, something that a very smart code completion along with very powerful refactoring techniques that Eclipse has would do wonders. The one thing that Haskell is missing is a proper editing environment, and at least in my opinion one of the major things that a language needs to become widely adopted (unless its a first like perl,C was) is a proper editing environment that is approachable for newer people but remains powerful for advanced users On Tue, May 3, 2011 at 1:43 AM, jutaro j...@arcor.de wrote: Hi Mathew, I was not the one working on Yi integration so far, but let me tell you what I think of the matter. Yi attempts to be a full blown editor, while Leksah needs Yi as a library for text editing with features typical of a source code editor component. What we have in Leksah is an abstract TextEditor interface. So if I would work on it (and I can't say if I will do) I would fork Yi, and factor out a simple TextEditor library, and then would try to convince the Yi people that it would make sense to refactor Yi this way. As it is now we have Yi in some way integrated, but it is not well defined, what part of functionality Leksah and Yi play, and I guess we will not reach something usable this way. Jürgen On 30 Apr., 11:25, Mathew de Detrich dete...@gmail.com wrote: Is there going to be any plans to integrate Yi into Leksah as you originally planned to, or is that idea for the short term out the window? On Fri, Apr 22, 2011 at 8:40 PM, Hamish Mackenzie hamish.k.macken...@googlemail.com wrote: Yesterday we uploaded our official 0.10.0 release (0.10.0.4) to Hackage and we have Windows and OS X installers athttp:// leksah.org/download.html Anyone using an earlier version should upgrade. This release is mainly small improvements and bug fixes. Some of the improvements include: * Better messages for some common problems. * Improved grep (now searches all source directories in your workspace) * Updated build system for more reliable rebuilding of dependent packages in your workspace We have automated the building of the Leksah installers and this should allow us to do more frequent releases in the future. There is a lot more to do and we would love to hear from anyone who has time to help out. Worth mentioning because they can be hard to find: * Ctrl R adds missing imports * Ctrl Enter evaluates current line or selection in GHCi * Right click menu in the editor has other debug functions * Comment and uncomment are now Ctrl D and Ctrl Shift D To build Leksah yourself: * Install Gtk and GtkSourceView2 (C libraries and headers) * Install The Haskell Platform (or GHC = 6.12.3) * cabal update * cabal install gtk2hs-buildtools * cabal install leksah * leksah Making a Gtk application look nice on Windows and OS X is not easy so we recommend using one of these prebuilt binaries: Windows users using GHC 7.0.3 http://leksah.org/packages/leksah-0.10.0.4-ghc-7.0.3.exe Windows users using GHC 6.12.3 http://leksah.org/packages/leksah-0.10.0.4-ghc-6.12.3.exe OS X 10.6 users using GHC 7.0.3 http://leksah.org/packages/leksah-0.8.0.6.dmg (These installers do not install Gtk2Hs packages on your system) Please consulthttp://leksah.org/download.htmlfor more details about installation! Background information can be found in the Leksah manual http://leksah.org/leksah_manual.pdf. Known bugs and problems: * Leksah does not run with GHC 6.12.2 (http://http://hackage.haskell.org/trac/ghc/ticket/4038) Have fun Jürgen Hamish See you on #leksah IRC ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-C...@haskell.orghttp:// 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] Robert Harper on monads and laziness
On 02/05/11 17:54, Ketil Malde wrote: I'm following Harper's blog, Existential Type¹, which I find to be an enjoyable and entertainingly written tirade about the advantages of teaching functional programming - specifically ML - to students. Of course, he tends to be critical of Haskell, but it's nice to get some thought provoking opinion from somebody who knows a bit about the business. Recently, he had a piece on monads, and how to do them in ML, and one statement puzzled me: There is a particular reason why monads had to arise in Haskell, though, which is to defeat the scourge of laziness. My own view is/was that monads were so successful in Haskell since it allowed writing flexible programs with imperative features, without sacrificing referential transparency. Although people are quick (and rightly so) to point out that this flexibility goes way beyond IO, I think IO was in many ways the killer application for monads. Before IO, we had very limited functionality (like 'interact' taking a 'String - String' function and converting it into an exectuable program) to build real programs from. Laziness does require referential transparency (or at least, it is easier to get away with the lack of RT in a strict language), so I can see that he is indirectly correct, but RT is a goal in itself. Thus, I wonder if there are any other rationale for a statement like that? -k ¹ http://existentialtype.wordpress.com/ Interesting how I have been authoring and subsequently using monads in scala for several years and it is strictness that gets in the way more than anything. http://github.com/scalaz/scalaz/ I have been teaching functional programming for quite a while, both in universities and outside of academia, and I am of the opinion that Haskell's suitability in first place has no close second place. I wonder why I am wrong, but this post (and previous) is hardly persuasive. -- Tony Morris http://tmorris.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interfacing C++ iterators does not work as expected
On 11-05-02 05:31 PM, Huynh Huu Long wrote: Big thanks, that works for me as well. Doesn't GHC check whether a type is allowed (like CInt,...) or not (like Bool,...)? No, it doesn't, since version 6.10.1: http://www.haskell.org/ghc/docs/6.10.1/html/users_guide/ffi-ghc.html#glasgow-foreign-headers As it happens, FFI requires translating Haskell Bool from C int (unlikely to be 1 byte), while GCC translates C++ bool to 1 byte. At a suitable moon phase and planet alignment (or data alignment), mixing up an int with a byte will be funny. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Binary and Serialize classes
I'm a bit skeptical of adding builders for different variable length encodings to the library, simply because there are so many possibilities. I think creating a binary-vle (for variable length encoding) package would be worthwhile. I have an implementation of the VLE used in protocol buffers. I didn't necessarily mean the general notion of variable length encodings, I just meant the encodings for the built-in types that are a little more complex than most. For example, export a putInteger that's documented to not change its encoding. Same for putString, and even trivial ones like putPair, putEtcEtc. Then you'd have to declare a bunch of boilerplate like 'instance MySerialize Integer where put = putInteger'. It would be annoying, but less annoying than copying the contents of putInteger everywhere, and you'd be guaranteed to be explicitly depending on all your implementations, so you could either use ones explicitly documented to be consistent, or write your own. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Is Harper right that Haskell cannot model the natural numbers?
In one of his blog posts, Robert Harper claims that the natural numbers are not definable in Haskell. SML datatype nat = ZERO | SUCC of nat Haskell data Nat = Zero | Succ Nat differ in that the SML version has strict constructors, and so only finite instances of nat can be constructed, whereas Haskell has lazy constructors, so inf = Succ inf is constructible, but that's not a natural number, and it isn't bottom either, so this is not a model of the natural numbers. Fair enough, but what about data Nat = Zero | Succ !Nat where the constructors *are* strict? It's perfectly good Haskell 98 as far as I can see. Now Nat itself isn't _quite_ a model of the naturals because it includes bottom, but then an SML function returning nat can also fail, so arguably SML's nat could or should be thought of as including bottom too. What am I missing? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is Harper right that Haskell cannot model the natural numbers?
On 11-05-02 11:25 PM, Richard O'Keefe wrote: Fair enough, but what about data Nat = Zero | Succ !Nat It works. I say, Harper forgot it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Leksah 0.10.0
I did most of the Yi integration work done so far, but I have not had time to
work on it lately. Yi already is a library (for dyre) and is designed to work
with different front ends. The approach I took was to add a new Pango
Control front end based on the existing Pango front end.
I think the Yi team are planning on making all the front ends into separate
packages so at that point the Pango Control front end would hopefully be in
yi-pango (or perhaps its own yi-pango-control). The main thing is that the
front end modules depend on the core Yi stuff, but not the other way around.
So in that sense the design you describe is already close to how Yi works now.
Most of what I imagine you mean when you say basic editing commands already
work in Leksah with Yi. There is a lot left to do though...
* Improve speed of rendering the text so it is usable (currently the
entire window is redrawn for each key press)
* Support for displaying minibuffers (vim : and / for instance do not work)
* Fire an event on text insertion for autocomplete
* Tagging of text to highlight search results and compiler errors
* Locate X Y coordinates of text so we can display the autocomplete window
in the right place
* Scroll to a text location (if the user selects error or grep result)
* When a new file is opened by Yi we should fire an event and open a window
in Leksah for it
* Likewise if a buffer is closed via a Yi command
* Work out how to make Yi more configurable in the Windows and OS X
binary installers
To get an idea of some of what is left to do search for TODO in
https://github.com/jutaro/leksah/blob/master/src/IDE/TextEditor.hs
The Pango Control front end is currently here
https://github.com/yi-editor/yi/blob/master/yi/src/library/Yi/UI/Pango/Control.hs
To build Yi support into Leksah get Yi from github and install it with
cabal configure --flags=pango -vte --constraint='parsec2.2'
(not sure if the -vte is needed, may just need that on OS X)
(also the parsec restraint is not needed if you get Leksah from github)
Then install Leksah with
cabal configure --flags=yi
(add -dyre to the flags if you want to use the Leksah default Yi config)
Once that is done you should edit your ~/.yi/yi.hs file so that DYRE will
not turn Leksah into Yi. Add this to the start...
{-# LANGUAGE CPP #-}
import Yi
#ifdef LEKSAH
import IDE.Leksah
#endif
And change the main function so it looks like this...
main :: IO ()
#ifdef LEKSAH
main = leksah $ myConfig
#else
main = yi $ myConfig
#endif
Finally run Leksah and check the box Edit Prefs - Editor - Use Yi. This
change comes into play when you open a new file (already opened buffers will
still be GtkSourceView).
mahrz expressed an interest in helping out on #leksah IRC a couple of weeks
back, but I have not heard how he is getting on. Other than that I am not
aware of anyone else working on it, so if anyone can help out that would be
great. Send any questions to Leksah and Yi lists or IRC #leksah.
On 3 May 2011, at 11:49, Mathew de Detrich wrote:
I actually agree with you on that regard, I think the best thing you can get
from Yi is just the basic editing commands (the same you would get from vim),
such as visual/edit mode and whatnot
The best thing that Leksah can turn into (and something that Haskell
desperately needs) is a Haskell version of Eclipse, because as Java has a
weakness of being incredibly verbose (which Eclipse gets around with very
easily, try coding Java in vim!!!), Haskell being a statically typed language
has a weakness that in non trivial code, types can become convoluted and
'piping' functions together becoming complicated, something that a very smart
code completion along with very powerful refactoring techniques that Eclipse
has would do wonders.
The one thing that Haskell is missing is a proper editing environment, and at
least in my opinion one of the major things that a language needs to become
widely adopted (unless its a first like perl,C was) is a proper editing
environment that is approachable for newer people but remains powerful for
advanced users
On Tue, May 3, 2011 at 1:43 AM, jutaro j...@arcor.de wrote:
Hi Mathew,
I was not the one working on Yi integration so far, but let me tell
you
what I think of the matter. Yi attempts to be a full blown editor,
while Leksah
needs Yi as a library for text editing with features typical of a
source code editor component.
What we have in Leksah is an abstract TextEditor interface.
So if I would work on it (and I can't say if I will do) I would fork
Yi, and
factor out a simple TextEditor library, and then would try to convince
the
Yi people that it would make sense to refactor Yi this way.
As it is now we have Yi in some way integrated, but it is not well
defined,
what part of functionality Leksah and Yi play, and I guess we will not
reach
something usable this way.
Jürgen
On 30 Apr., 11:25,
Re: [Haskell-cafe] Is Harper right that Haskell cannot model the natural numbers?
On 03/05/2011, at 1:25 PM, Richard O'Keefe wrote:
In one of his blog posts, Robert Harper claims that the natural numbers
are not definable in Haskell.
SML datatype nat = ZERO | SUCC of nat
Haskell data Nat = Zero | Succ Nat
differ in that the SML version has strict constructors, and so only
finite instances of nat can be constructed, whereas Haskell has
lazy constructors, so
inf = Succ inf
is constructible, but that's not a natural number, and it isn't
bottom either, so this is not a model of the natural numbers.
Fair enough, but what about
data Nat = Zero | Succ !Nat
where the constructors *are* strict? It's perfectly good Haskell 98
as far as I can see. Now Nat itself isn't _quite_ a model of the
naturals because it includes bottom, but then an SML function
returning nat can also fail, so arguably SML's nat could or should be
thought of as including bottom too.
What am I missing?
Do read the comments attached to the blog post (and also maybe at reddit).
I believe the traditional model for ML-like languages in denotational
semantics is to lift the type returned by a function. So ML's Nat type is
taken to be an inductively-defined set (with the discrete order) and your
divergent ML function really has type a - Nat_{lift} for whatever type a you
had in mind. I think Moggi's encoding into monads makes this clear - you use
the Maybe/Evaluation/Strict monad to handle divergent arguments.
cheers
peter
--
http://peteg.org/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Robert Harper on monads and laziness
Tony Morris: Interesting how I have been authoring and subsequently using monads in scala for several years and it is strictness that gets in the way more than anything. Just to make sure that I understand you correctly. You are saying that when you use monads in Scala, then strictness makes that more awkward than necessary. (I assume that you are *not* saying that strictness is the most awkward language feature of Scala.) Why is that? Manuel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Robert Harper on monads and laziness
For a historical perspective, I highly recommend The Definitive Account of the History of Haskell: http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/index.htm Section 7 clearly and directly cites the desire to have pure I/O as the motivation for adopting monads. As you are saying that doesn't directly contradict the statement of Bob that you cite. In fact, Section 3.2 of the above paper supports the opinion that purity is a consequence of choosing to be lazy, but it also claims that the combination of power and beauty of a pure language motivated the language designers. Interestingly, today (at least the academic fraction of) the Haskell community appears to hold the purity of the language in higher regard than its laziness. Manuel Ketil Malde: I'm following Harper's blog, Existential Type¹, which I find to be an enjoyable and entertainingly written tirade about the advantages of teaching functional programming - specifically ML - to students. Of course, he tends to be critical of Haskell, but it's nice to get some thought provoking opinion from somebody who knows a bit about the business. Recently, he had a piece on monads, and how to do them in ML, and one statement puzzled me: There is a particular reason why monads had to arise in Haskell, though, which is to defeat the scourge of laziness. My own view is/was that monads were so successful in Haskell since it allowed writing flexible programs with imperative features, without sacrificing referential transparency. Although people are quick (and rightly so) to point out that this flexibility goes way beyond IO, I think IO was in many ways the killer application for monads. Before IO, we had very limited functionality (like 'interact' taking a 'String - String' function and converting it into an exectuable program) to build real programs from. Laziness does require referential transparency (or at least, it is easier to get away with the lack of RT in a strict language), so I can see that he is indirectly correct, but RT is a goal in itself. Thus, I wonder if there are any other rationale for a statement like that? -k ¹ http://existentialtype.wordpress.com/ -- If I haven't seen further, it is by standing in the footprints of giants ___ 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
