A common pattern:def foo(): x = some value # but do we need this? (short answer: no) if something: # ... do stuff ... x = 'bla' else: x = 'blo'
The variable x is being initialized before the if/else, but the intention of the programmer is that its value will actually be determined by the if/else itself. If somebody later comes around and mistakenly removes one of the assignments (inside ‘if’ or ‘else’), no runtime error will occur and x will remain initialized to a probably wrong value.
Leaving out the initialization is better – in that case, forgetting to set x in one of the branches will cause an UnboundLocalError:>>> def foo(): ... if False: ... x = 0 ... return x ... >>> foo() Traceback (most recent call last): File "", line 1, in File "", line 4, in foo UnboundLocalError: local variable 'x' referenced before assignment
Errors are good! (when they flag buggy code)
Now, what if we also have an x declared in the global scope? Because of how Python handles variable scope, the error will still happen (which is good).>>> x = 1 >>> def foo(): ... if False: ... x = 0 ... return x ... >>> foo() Traceback (most recent call last): .. UnboundLocalError: local variable 'x' referenced before assignment
Summary: In Python, don’t initialize variables until you know what value to assign to them.
Ok so I figure I might as well release this to the world. It works decently enough for my purposes the past week or so.
So voila, ghc 7.10.1 alpine packages. I'm pestering the Alpine developers to get this into the testing repository proper but in the interim, have fun. Note this is compiled with -O2, when you recompile ghc a lot binary size starts to seem a minor problem.
The readme should cover things I found/know about. The examples directory has everything you'd need to use these packages in a Dockerfile. The stage1/2/3 directories have a mostly working setup on how I got to native packages within alpine linux.
Consider it alpha grade though. I can compile things like idris with it and they work. But I haven't validated its correct. Only that things compile and don't segfault straight away.
Also not entirely sure if having a ghc/ghc-dev package split makes sense to be honest.
Next up on my list is automating rebuilds for cabal-install and ghc itself so that when 7.10.2/next cabal version is out I'm set to update this jazz.
Also many thanks to everyone in #ghc that helped me with this as well as anyone I may be missing/forgetting about. Have to go help debug a problem.
Enjoy!submitted by saudade
[link] [5 comments]
A few weeks ago, we announced the first public beta of stack, a new build tool for Haskell. Since then we've seen a huge amount of work on stack: code contributions, feature requests, bug reports, and design discussions. In other words, the response we've had from the community has been amazing. Thank you for helping us push forward with improved Haskell tooling.
Today we're announcing a new milestone: we believe that stack is now stable enough to be the standard build tool for most Haskell development. We're taking the beta label off of stack, and recommending people dive in. Please keep in mind that stack is still young software, and there are likely corner cases that haven't been worked out fully. However, the feedback we've received from other users has indicated that stack is ready. The stack team itself (both inside and outside of FP Complete) has been using stack for months now as its primary tool. And at FP Complete, we've already moved our biggest projects over to it.
One question which I've personally held off on addressing until now is a direct comparison between stack and other build tools, cabal being the most obvious comparison. Expect a blog post on the subject in the near future. For now, my recommendation is: try out stack, and see if you like it.Bringing Haskell to the masses
While stack started with the needs of existing Commercial Haskell users, the goal we've always had in mind for it is a tool that lowers the barrier to entry for non-Haskellers. As we've discussed before, FP Complete has done quite a bit of research on this topic, and the data shows that build tool issues have been an obstacle to adoption. We want stack to solve that, and we want your help.
Firstly: keep doing what you've been doing! Using stack, testing it, providing feedback, reporting bugs; all of these make stack better for both our existing community and for newcomers. But the next step is marketing Haskell outside of our community. All of us Haskellers already know how wonderful a language Haskell is. Let's send a clear message to the rest of the world that it's time they try Haskell. stack's aim is to remove those initial barriers. But now we need to tell people what Haskell has to offer.
If you're interested in getting involved in this kind of a push, please join and discuss on the Commercial Haskell mailing list. There's no preexisting formula for how this should be done. But the basic idea I have right now is:
- Give users a clear message on how to get up and running with Haskell based on stack
- Give a good example of a strength Haskell has
- Make it easy for people to play around with the concept with some sample code
I'm sure others will have better ideas than I on how to accomplish this. If you want to see Haskell take off as not only a successful, powerful language (which it is now), but as a more popular language too, come get involved!
I stumbled on Haskell's Generics and it kind of reminds me of Java's Reflection mechanism. Not exactly the same mechanics in play, but both are trying to "solve" the same problem. Did I get it right?submitted by evohunz
[link] [6 comments]
In general, does what Functional Programming and Haskell teach result in safer code in other imperative or procedural programming languages? (less bugs etc)submitted by pragm
[link] [19 comments]
Im doing some cold-golf challenges (program should be as short as possible) and im stuck now. I have 3 powerset implementations :powerset  = [] powerset (x:xs) = xss ++ map (x:) xss where xss = powerset xs main = print $ powerset([1,2]) import Control.Monad(filterM) p = filterM(const[True,False]) main = p[1,2] import Data.List; main = (readLn :: IO [Integer] ) >> = print . subsequences
For now it takes an input in this form : [1,2,3]. Any advice how to change it so it takes every number in list in this form :
IO system of haskell is super hard for me, so can someone show me how to make input possible in first and second function ?
Extra question IS it possible to change those function so they compute power set when as one parameter I will pass [1,2] ?submitted by Cosaquee
[link] [5 comments]
Also, I am aware about LiquidHaskell and Dana Xu's work.
However, how much of that can be used in Haskell today (with 7.10)? Anything planned for the future?
Are Haskell's typeclasses one implementation of refinement types?
EDIT: A quote about using intersections and unions for overloading: "In its present form, this idiom is less powerful than type classes (Wadler and Blott 1989)".
Indeed, adding multiple class constraints creates an intersection (Eq a, Show a) => ... means having both Eq and Show.submitted by mallai
[link] [17 comments]