Comments for Less Sugar/More Meat http://netsuperbrain.com/blog Sankel Software, FRP, Haskell, Reactive Sat, 19 May 2012 09:26:21 +0000 http://wordpress.org/?v=2.6.2 Comment on freeglut + Windows + HOpenGL + HGLUT by Haskell '.hs' file compile problems... http://netsuperbrain.com/blog/posts/freeglut-windows-hopengl-hglut/#comment-34444 Haskell '.hs' file compile problems... Wed, 29 Feb 2012 15:00:30 +0000 http://netsuperbrain.com/blog/?p=136#comment-34444 <p><</p> <p>p>[...] Might need to install the haskell glut binding. It seems like you're using windows? I don't know how to do it on windows on linux I just use cabal but I found this from hackage Less Sugar/More Meat</p> <

p>[...] Might need to install the haskell glut binding. It seems like you’re using windows? I don’t know how to do it on windows on linux I just use cabal but I found this from hackage Less Sugar/More Meat

]]> Comment on Haskell’s evaluation isn’t magic by Mike B http://netsuperbrain.com/blog/posts/haskells-evaluation-isnt-magic/#comment-34168 Mike B Fri, 24 Feb 2012 15:55:31 +0000 http://netsuperbrain.com/blog/?p=371#comment-34168 <p>Note that the "next Haskell will be strict" comment was made 9 years ago, at a talk in 2003 and Haskell is now 50% older, with no strict variation/derivative/counterpoint to Haskell in sight (or is there)?</p> <p>https://research.microsoft.com/en-us/um/people/simonpj/papers/haskell-retrospective/</p> Note that the “next Haskell will be strict” comment was made 9 years ago, at a talk in 2003 and Haskell is now 50% older, with no strict variation/derivative/counterpoint to Haskell in sight (or is there)?

https://research.microsoft.com/en-us/um/people/simonpj/papers/haskell-retrospective/

]]> Comment on Haskell’s evaluation isn’t magic by Alexander Batischev http://netsuperbrain.com/blog/posts/haskells-evaluation-isnt-magic/#comment-26255 Alexander Batischev Thu, 28 Jul 2011 16:20:02 +0000 http://netsuperbrain.com/blog/?p=371#comment-26255 <blockquote> <p>Based off of those logs, it is reasonable to expect that the first expression will run faster.</p> </blockquote> <p>You probably meant "the second expression".</p> <p>Thank you for a great article!</p>

Based off of those logs, it is reasonable to expect that the first expression will run faster.

You probably meant “the second expression”.

Thank you for a great article!

]]> Comment on Haskell’s evaluation isn’t magic by Alessandro Stamatto http://netsuperbrain.com/blog/posts/haskells-evaluation-isnt-magic/#comment-24676 Alessandro Stamatto Tue, 21 Jun 2011 15:42:08 +0000 http://netsuperbrain.com/blog/?p=371#comment-24676 <p>In the presentation I remember him saying something along the lines “laziness is not essential, and all the exciting features offered by it can be done with strictness, as such the next haskell will be strict ”</p> <p>*Corrected a typo</p> In the presentation I remember him saying something along the lines “laziness is not essential, and all the exciting features offered by it can be done with strictness, as such the next haskell will be strict ”

*Corrected a typo

]]> Comment on Haskell’s evaluation isn’t magic by Alessandro Stamatto http://netsuperbrain.com/blog/posts/haskells-evaluation-isnt-magic/#comment-24675 Alessandro Stamatto Tue, 21 Jun 2011 15:39:46 +0000 http://netsuperbrain.com/blog/?p=371#comment-24675 <p>In the presentation I remember him saying something along the lines "laziness is not essential, and all the exciting features offered by it can be done with strictness then the next will be strict haskell"</p> In the presentation I remember him saying something along the lines “laziness is not essential, and all the exciting features offered by it can be done with strictness then the next will be strict haskell”

]]> Comment on Haskell’s evaluation isn’t magic by v http://netsuperbrain.com/blog/posts/haskells-evaluation-isnt-magic/#comment-24658 v Tue, 21 Jun 2011 04:59:36 +0000 http://netsuperbrain.com/blog/?p=371#comment-24658 <p>http://www.cs.nott.ac.uk/~gmh/appsem-slides/peytonjones.ppt</p> <p>There's the quote.</p> http://www.cs.nott.ac.uk/~gmh/appsem-slides/peytonjones.ppt

There’s the quote.

]]> Comment on Haskell’s evaluation isn’t magic by C. McCann http://netsuperbrain.com/blog/posts/haskells-evaluation-isnt-magic/#comment-24655 C. McCann Tue, 21 Jun 2011 02:21:24 +0000 http://netsuperbrain.com/blog/?p=371#comment-24655 <p>That quote is from "Wearing the hair shirt: a retrospective on Haskell". See here: http://research.microsoft.com/en-us/um/people/simonpj/papers/haskell-retrospective/</p> <p>I doubt he meant it in a completely literal sense, since it came after a section talking about the benefits vs. drawbacks to laziness without clearly favoring either, but it's hard to tell what a single line from a powerpoint slide means without the context of the full presentation.</p> That quote is from “Wearing the hair shirt: a retrospective on Haskell”. See here: http://research.microsoft.com/en-us/um/people/simonpj/papers/haskell-retrospective/

I doubt he meant it in a completely literal sense, since it came after a section talking about the benefits vs. drawbacks to laziness without clearly favoring either, but it’s hard to tell what a single line from a powerpoint slide means without the context of the full presentation.

]]> Comment on Haskell’s evaluation isn’t magic by Eric http://netsuperbrain.com/blog/posts/haskells-evaluation-isnt-magic/#comment-24652 Eric Mon, 20 Jun 2011 23:41:10 +0000 http://netsuperbrain.com/blog/?p=371#comment-24652 <p>@Anonymous.</p> <blockquote> <p>“The next Haskell will be strict” Simon Peyton Jones</p> </blockquote> <p>Do you have the reference for that quote. Last time I heard SPJ in a presentation, he said that he'd certainly like sometimes Haskell to be strict, but he's pretty sure that, by then, he would regret that and would like to come back again to "by-need", so he will never be able to definitely set-up his mind on this question.</p> <p>Eric.</p> @Anonymous.

“The next Haskell will be strict” Simon Peyton Jones

Do you have the reference for that quote. Last time I heard SPJ in a presentation, he said that he’d certainly like sometimes Haskell to be strict, but he’s pretty sure that, by then, he would regret that and would like to come back again to “by-need”, so he will never be able to definitely set-up his mind on this question.

Eric.

]]> Comment on Haskell’s evaluation isn’t magic by ceii http://netsuperbrain.com/blog/posts/haskells-evaluation-isnt-magic/#comment-24651 ceii Mon, 20 Jun 2011 21:53:33 +0000 http://netsuperbrain.com/blog/?p=371#comment-24651 <p>Anonymous: I'm curious about the origin of that quote. As far as I'm aware, SPJ has never done something so rash as to take a definite position on this question.</p> <p>The only consensus about strict by default vs. lazy by default seems to be that you lose important and desirable properties no matter which side of the fence your language stands on.</p> Anonymous: I’m curious about the origin of that quote. As far as I’m aware, SPJ has never done something so rash as to take a definite position on this question.

The only consensus about strict by default vs. lazy by default seems to be that you lose important and desirable properties no matter which side of the fence your language stands on.

]]> Comment on Haskell’s evaluation isn’t magic by pipoca http://netsuperbrain.com/blog/posts/haskells-evaluation-isnt-magic/#comment-24647 pipoca Mon, 20 Jun 2011 20:19:03 +0000 http://netsuperbrain.com/blog/?p=371#comment-24647 <p>The performance characteristics of a sub-expression will be the same (modulo variables already having been evaluated on the heap) if you evaluate it in the context of the larger expression or if you just evaluate the sub-expression itself.</p> <p>Programs are built out of small blocks, and if you understand the behavior of the blocks themselves, you can predict some of the characteristics of the structures you make out of them. Sure, you'll get some interesting emergent behavior out of them in the larger structure, but knowing the basic behavior of the blocks will get you reasonably far.</p> The performance characteristics of a sub-expression will be the same (modulo variables already having been evaluated on the heap) if you evaluate it in the context of the larger expression or if you just evaluate the sub-expression itself.

Programs are built out of small blocks, and if you understand the behavior of the blocks themselves, you can predict some of the characteristics of the structures you make out of them. Sure, you’ll get some interesting emergent behavior out of them in the larger structure, but knowing the basic behavior of the blocks will get you reasonably far.

]]>