I've been working on a few libraries that I'm starting to feel ready to upload to Hackage, and I'm running into the same problem again and again: I need to embed a C or C++ project with its own build system into the package, and baking all those files into extra-source-filesin the cabal file seems impractical. In one case there are hundreds of files!
What I'd really like to do is programmatically add files to extra-source-files in Setup.hs, but so far I haven't been able to figure out how to do this. The cabal hooks that look like they might do the job, such as readDesc, don't even seem to get run, at least on cabal 1.20.
I took a look at other packages and I found that Christopher Rodrigues' Omega package deals with this by including its C sources as a tar ball. This seems like a workable solution, but I still feel like there must be a cleaner approach.
Is there a best practice for handling this problem? Am I just fundamentally approaching this the wrong way? I'd appreciate any guidance reddit can offer!submitted by swift1337
[link] [2 comments]
What is your view on using the Haskell-Platform installer versus just installing GHC and Cabal and managing it as you go?submitted by sigzero
[link] [23 comments]
I woke up feeling terrible last monday, and by midnight I was on a bed in the ER. Spent the next few days in the hospital: had surgery on wednesday, got released on thursday. Since then I've been resting about the house, and have been recovering quickly. It was my first "real" surgery. (I've had other surgical procedures, but they aren't the sort that doctors mean when they ask if you've "had any surgeries".) Before saying what I had done, I'd like to make a point about social awareness.
Do you recognize these symptoms?
- sharp shooting pain in the chest, possibly extending to shoulders and neck/throat, lightheadedness/dizziness, shortness of breath.
- dark urine, yellowing skin/eyes, nausea/vomiting, difficulty concentrating, sleepiness.
- urinating often, increased thirst/hunger, blurry vision, abrasions heal slowly, tingling/pain/numbness in hands/feet.
- dull pain in the pit of your stomach, possibly extending to back or right shoulder, possibly increasing after eating fatty foots, doesn't abate in different positions, fever and chills.
This day and age I'd expect any moderately educated person to recognize the first three immediately: heart disease, liver disease, and diabetes (type 2). Both heart disease and diabetes have had powerful ad campaigns to increase awareness. Liver disease hasn't had that advantage, but the symptoms of jaundice are mentioned in the side-effect reports of most medications, and they're pretty memorable to boot. The last one I never would have recognized until it happened to me. And, frankly, the ER doctors had a hell of a time figuring out what it might be based only on my symptoms. I felt feverish at the time, though my temperature was normal. This was the first out-and-out attack, so I couldn't talk about how often it happened nor say whether it got worse after eating fatty foods. Knowing all the symptoms now, I can look back and see that this has been a long time coming; but at the moment all I could tell the docs was: intense dull pain in the pit of my stomach, doesn't get better or worse when changing position.
These are the symptoms of gallbladder disease. Women are more than twice as likely as men to get it. Women on hormone replacement therapy are more likely to get it. Many women are hit with it during the end of pregnancy— so many so that nurses remark on the number of cholecystectomy patients with one-week old babies. There's something about estrogen (or fluctuations thereof) that doesn't play nicely with the gallbladder. So I mention this for all the women, especially trans women, in the audience. Of course, none of this is to say that there aren't plenty of men who suffer from the same. Prior to going to the ER I'd heard almost nothing about gallbladder disease, other than knowing that gallstones were a thing. But in the scarce week since then I've lost track of how many women have told me about their cholecystectomies. With how common it is, I think this is one of those diseases that we as a society should be able to recognize— like diabetes, heart attacks, and jaundice.
So yeah, I'm down an organ now. There aren't too many side effects of having your gallbladder removed (compared to removing other organs), though it does mean I'll have to watch my diet. I've been doing that anyways, now it's just different things to look for. I'll have to put the high-protein low-carb diet on hold for a couple months, since I need to reduce fat intake until my body gets used to the new me. Also worth noting: apparently losing weight quickly (as with the 30-pounds I dropped last fall) can increase the risk of gallstones. So if you're dropping weight, you should be sure to monitor things and try to flush/cleanse your gallbladder.
That's it for now. Goodnight and good health.
Edward Kmett writes:
Ironically if I had to say anything from the traffic in my inbox and on #haskell about it, it is mostly the old guard who gets disgruntled by lens.
So let me try and explain why that is. I’ll go ahead and say this: lens is unidiomatic Haskell.
By which I mean that lens isn’t like any other library that we normally use. It doesn’t follow the conventions of Haskell APIs, on which I elaborate below.
Now let me clarify that this doesn’t necessarily mean that lens is a bad library. It’s an unusual library. It’s almost a separate language, with its own idioms, embedded in Haskell.
It is as unusual as, say, Yesod is. But unlike Yesod, which follows Haskell’s spirit, not letter (syntax), lens, I argue, follows Haskell’s letter, but not its spirit.
So here’s why I think lens violates the spirit of Haskell:
In Haskell, types provide a pretty good explanation of what a function does. Good luck deciphering lens types.
Here’s a random function signature I picked from lens:below :: Traversable f => APrism' s a -> Prism' (f s) (f a)
Despite having some (fairly basic) understanding of what prisms are, this signature tells me nothing at all, even despite the usage of type synonyms.
So you have to rely on documentation much more than on types. Yeah, just like in Ruby.
Usually, types in Haskell are rigid. This leads to a distinctive style of composing programs: look at the types and see what fits where. This is impossible with lens, which takes overloading to the level mainstream Haskell probably hasn’t seen before.
We have to learn the new language of the lens combinators and how to compose them, instead of enjoying our knowledge of how to compose Haskell functions. Formally, lens types are Haskell function types, but while with ordinary Haskell functions you immediately see from types whether they can be composed, with lens functions this is very hard in practice.
The size of the lens API is comparable to the size of what I’d call «core Haskell» (i.e. more or less the base library). It is also similar in spirit to base: it has a big number of trivial combinations of basic functions, in order to create a base vocabulary in which bigger programs are expressed.
Ordinary libraries, instead, give only basic functions/combinators, and rely on the vocabulary provided by base (or lens) to compose them together.
This is why I regard lens as a language in its own. And this demonstrates why learning lens is hard: surely learning a new language is harder than learning a new library.
Dependencies. A library as basic in its purpose as lens ideally should have almost no dependencies at all. Instead, other libraries should depend on it and implement its interface. (Or even do it without depending on it, as is possible with lens.)
A package implementing lenses that depends on a JSON parsing library and a gzip compression library sounds almost like a joke to me.
OTOH, it kind of makes sense if you think about lens as a language. It just ships with a “rich standard library”. Nice!
Backward composition of lenses. It’s a minor issue, and I wouldn’t mention it if it wasn’t a great demonstration of how lens goes against the conventions of Haskell.
Note that I’m not trying to make a judgment here (although my tone probably does give away my attitude towards lens). I’m simply explaining why people may dislike and resist it.
Nor am I trying to argue against any particular design decision of lens. I’m sure they all have valid rationale behind them.
I just hope that someone will write an idiomatic Haskell library as powerful as (or close to) lens, with perhaps a different set of compromises made. Otherwise, I’m afraid we all will have to learn this new language sooner or later.
It seems like an obvious optimization. Take the following function (and imagine it as a pure function that is significantly more expensive to compute, such as a hash function):square :: Int -> Int square x = x * x
If the platform could recognize that the result of square 16 is always 256, because it's a pure, deterministic function, then it could keep the previously calculated results in a hashtable keyed by the argument.
There are obvious performance gains to be had if the hashtable lookup is significantly faster and cheaper than computing the result every time.
I understand it's not too difficult to implement in the language, but I'm wondering if it has ever been discussed as a potential feature for GHC itself, as an automatic (or optional) optimization for non-monadic functions.submitted by DroidLogician
[link] [20 comments]
I was recently investigating macro tree transducers as a model of computation due to their great computing characteristics. Specifically, every MTT can be composed, so, for example, coding your program with MTTs would mean you get things like Stream Fusion on arbitrary recursive functions for free.
Now I'm wondering what you can't do with macro tree transducers? What are practical algorithms that are necessary to daily programming that can't be done with those?submitted by SrPeixinho
[link] [7 comments]
In exploring the lens library, I recently discovered the general purpose combinators. I find using (&) (flip ($)) addictive. Below is an example of summing all the odd numbers from 1 to 100 and printing the result.
right-to-leftprint . foldr (+) 0 . filter odd $ [1..10]
left-to-right[1..10] & filter odd & Prelude.foldr (+) 0 & print
My brain works from the raw materials at hand to the final objective. Get a list from 1 to 100, filter the odd numbers, sum them, and then print the result. For me, writing right-to-left code involves a lot of left-arrowing as I go through these steps.
What I really like about left-to-right is when you need to move from pure code to a monad. Assume that the list you are odding and summing is coming from an IO effect:
right-to-leftprint =<< (liftM $ foldr (+) 0 . filter odd) (return [1..10] :: IO [Int])
left-to-right (<&> is flip fmap)(return [1..10] :: IO [Int]) <&> (filter odd) <&> foldr (+) 0 >>= print
It took a lot longer for me to work out the liftM,=<<,. combo required to keep it a one-liner compared with the rather snazzy <&> with a natural >>= to deal with print.
Do other people code like this, and would it be considered to be idiomatic (enough that it doesn't annoy others sharing my code)? And are there major problems with adoption of a left-to-right coding style?submitted by tonyday567
[link] [30 comments]
I've just been reviewing some basic functional programming ideas and playing with functions as values-with-holes. One thing I came up with was...class Cut a b where cut :: a -> (b, b -> a) -- snd (cut x) $ fst (cut x) = x
The cut function breaks a piece out of a value, returning the pair of the piece and a reconstruct-the-value function. The law states that if I use the reconstruct function with the same piece I cut out I get back the original value.
This looks like it might be a useful idea, so is something like it already in a library somewhere? Are there any papers I should read that use a similar class in an interesting way?
I feel like I'm missing something obvious, so sorry if this is dumb.submitted by ninereeds314
[link] [15 comments]
Notice this program:even_fibs = take 200000 $ filter even $ map fst $ iterate (\(a,b) -> (b,a+b)) (0,1) solve x = sum_digits $ sum $ take x even_fibs solutions = map solve [0..200000] sum_digits = sum . map (read . return) . show main = readLn >>= (\x -> print $ solutions !! x)
Now mind this compilation/execution:$ ghc -O2 programa.hs -o programa $ echo 100000 | time ./programa 282042 3.13 real 2.11 user 0.90 sys
There is a problem with that: solutions is a constant, static list. It has 200000 elements and none of them depend on any variable. It can be calculated in compile time, and in fact is what I want, or else I wouldn't have coded it like that. Yet GHC does not do this. As a result, a program that is supposed to be instantaneous needs 3 seconds to run. How can I force GHC to do so?submitted by SrPeixinho
[link] [8 comments]