There should be a hyperlink banner at the top of the docs of a library for which there's a more recent version. Especially with lens, whose highest Google page rank version happens to be 1.2, I find myself doing this every time:
Google "control.lens hackage" -> click "contents" in top right -> pick latest versubmitted by MitchellSalad
[link] [14 comments]
Philip Wadler recently gave a very interesting presentation on research he and his colleagues have been doing re: LINQ a la Haskell.
As yet there is, AFAIK, no production ready full blown LINQ-esque library in Haskell. I have checked out HaskellDB, Persistent, and Esqueleto, which leave much to be desired in terms of LINQ syntactic elegance and in some cases, what's even possible (e.g. lack of joins in Persistent).
Coming from Scala where type safe SQL DSLs abound, when can one expect a production ready LINQ in Haskell land?
I'm exploring moving from Scala + Play + ScalaQuery (superior to Slick, IMO) to Haskell + Yesod or Snap + unknown type safe SQL DSL, but am blocked by the database end of things, have no interest in going back to string based SQL.
Thanks for directing me to the missing linq.submitted by expatcoder
[link] [72 comments]
I am fairly new to Haskell, and i want to solve a math problem : 3 sqrt 5 like the third sqrt out of 5. Is there a way to implement this ? Please help me, thank you!submitted by 13utters
[link] [4 comments]
My GHC is working fine now. But there seem to be some changes in either GHC 7.8.2 or Cabal-22.214.171.124 that have broken some of the older packages in Hackage.
TL;DR I discovered the "Crypto-126.96.36.199 package is broken, and trying to install "terminfo-0.4.0.0" breaks GHC by over-writing the terminfo library that came with the GHC tarball because isn't in the GHC package registry.
I downloaded the binary distribution from here:
and then immediately began re-building all of the packages in my .cabal/packages/hackage.haskell.org/ direcotry.
I admit, all of my problems may be due to my Cabal config, but I haven't had any problems with it before this, as far as I know it is the default setup the option to build profiling libraries set to True.
The first problem I had was that Crypto-188.8.131.52 was not building files correctly. Some of shared object files "*.dyn_o" were being built without their accompanying "*.dyn_hi" files, although some of the "*.dyn_hi" files did exist). When cabal tried to copy these "*.dyn_hi" files to the global package registry during installation it would fail with something about (for example) "could not find RSA.dyn_hi". To solve this, I rebuilt every "*.dyn_o" file that did not have an accompanying "*.dyn_hi" by hand using the commandghc -dynamic --make Codec.Binary.RSA
The resulting "Codec/Binary/RSA.hi" file was actually a dynamic interface file but it's file extension was just ".hi" for some reason, (I double checked by using ghc --show-iface) so I just copied it it the "dist/build/Codec/Binary/" directory. I did this for every "*.hi" file that was supposed to be named "*.dyn_hi". This included about 10 files. Again, some "*.dyn_o" did build correctly with an accompanying "*.dyn_hi", about 10 of the modules were built incorrectly, all the rest were OK.
The second problem I had was with installing "Yi" which relies on the "terminfo-0.4.0.0" package. The "terminfo" library that came with the GHC 7.8.2 binary distribution does not show up in the output of "ghc-pkg list", so Cabal tries to build it thinking it doesn't exist, and it overwrites the existing "terminfo-0.4.0.0" package with a library that contains missing symbols. This causes GHC to completely stop working. The "ghc" program immediately fails with an error:symbol lookup error: /usr/local/lib/ghc-7.8.2/bin/../haskeline-0.7.1.2/libHShaskeline-0.7.1.2-ghc7.8.2.so: \ undefined symbol: terminfozm0zi4zi0zi0_SystemziConsoleziTerminfoziCursor_moveDown5_info
I was able to solve this problem by simply copying the contents of:ghc-7.8.2/libraries/terminfo/dist-install/build/*
from the source distribution tarball to the GHC installation directory:/usr/local/lib/ghc-7.8.2/terminfo-0.4.0.0/
and that solved the problem. But any program depending on "terminfo" simply will not install properly. The terminfo-0.4.0.0 package does not show up in the output of ghc-pkg list, even though it comes with the GHC 7.8.2 tarball and GHC relies on it. Attempting to install Terminfo will build a ".so" file that GHC cannot use. So don't install terminfo-0.4.0.0 from Hackage.
Fortunately, Yi is not something that is absolutely necessary. I was able to install every other package I needed (lens, diagrams, yesod, xmonad, gtk) without incident.
But whatever changes have been made in ghc-7.8.2 and the accompanying Cabal-184.108.40.206 seem to have broken some of the older Hackage packages.
Let the users beware.submitted by Ramin_HAL9001
[link] [1 comment]
Heartbleed aftermath: should Haskell web frameworks allow using a pure Haskell SSL library instead of OpenSSL?
I just fixed the infamous "heart bleed" OpenSSL bug in a couple of Snap web applications in my faculty. In light of the recourring nature of these buffer overun/overread vulnurabilties, why not use a Haskell-only implementation? It turns that one already exists.submitted by pbvas
[link] [52 comments]
I'm pretty new to Haskell concurrency and having some trouble figuring out the best way to implement the following behavior.
There are an arbitrary number of read threads and an arbitrary number of write threads with a single shared value between all of them. A read thread blocks if and only if it has read out the most recently written value. It should read a written value, at most, one time.
An example with three read threads and two write threads:Write1 writes 0 Read1 reads 0 Read3 reads 0 Read2 reads 0 ... Write1 writes 1 Read2 reads 1 Read3 reads 1 Write2 writes 2 Read1 reads 2 Read2 reads 2 Read3 reads 2 ...
Does something like this already exist on Hackage and I'm just not seeing it? Is there a good way to do this?submitted by pseudonom-
[link] [5 comments]
... and I've got to stop falling asleep mid-stream-of-consciousness/brain-dump (not 'bran'-dump! as that's something else entirely: 'brain'-dump!)
I'm going to entitle this article JILL after a lovely lady I knew, Ernimagilda Mucciaroni. 'Ernimagilda,' it turns out, is a nickname for Maria Theresa.
Santa Theresa, pray for us.
So, all combinators, and, by extension, a set of functional logics can be expressed by two combinators, the S:
S = \ x y z -> xz(yz)
and the K
K = \ x y -> x
combinators. Given those two combinators, and only those two combinators, you can rewrite any of the other combinators, like, for example, the I combinator:
I = \ x -> x
Or the B combinator:
B = \ x y z -> x(yz)
is simply SI, which I being defined above is S(SKK), or SII, I'll look that up. xxx
Great, we've got it all.
Problem. The K combinator, the constifier, drops a combinator from the discussion. So, if we're proving something, and we come across an inconvenient true, we simply apply the K combinator, and just drop it.
What if that instance of truth, that we just dropped, was the only instance in out universe of discourse?
Well, you could apply the continuation function and, going back in time, get it back. Or, without the continuation function, you could simply invent another universe, or reconstruct the one you were working with that truth back in there, and you're good to go, you can carry on from there.
Some philosophers have a problem with this, understandably, the 'oh, you can just go back and redo if you get it wrong the first time or if you find you needed it later'-excuse smacks of sloppiness, and in mathematics you have to be rigorous; you can't be sloppy. Imagine, for example, if they were blasé in constructing the Hilbert spaces? How much buy-in would there be if the disclaimer were added: "Oh, if something goes awry, just start over from the beginning and hope for the best. That should work"?
So, some site the dropping operator as the foundational problem, if there exists a truth in your space, why would you want to drop it? You'll only have to reconstruct it later on, anyway.
So, from that concern there arose the discussion around the 'noble' basis, or, how can we do what we need to do without discarding things that appear inconvenient or seem expedient to do so. After all, the Hilbert space is ... pretty big. There is room in this mathematics to carry around truths, regardless of their current utility. So, what combinators are necessary but also not destructive? Can this even be done.
It could. Four combinators showed to be of high utility in that they could construct the other combinators, except K, and they were S, M, B, and I or S, M, C, and I, depending on the preference of the proponent. Either set worked tolerably well.
But four combinators? Couldn't there be a reduced set that allowed one to use the noble set? After all, the SK-basis was originally the SKI-basis until someone brilliant realized that simply using S's and K's the I could be independently reproduced and therefore was unnecessary to form that basis.
It turns out in the noble SCMI-basis (or also in the SBMI-basis), there was. The J. The J combinator is defined as follows:
J = \ x y z w -> xy(xwz) xxx
The J in combination with another combinator would be able to reproduce the S (obviously), the C or the B (both, actually) and the M. Do you see which combinator?
Well, the T combinator:
T = \ x y -> yx
JII = \ I I z w -> II(Iwz) -I-> wx = T -- simplest realization
The R combinator:
R = \ x y z -> yzx
is JT or J(JII):
JT = \ T y z w -subst-> Ty(Twz) -T-> (Twz)y -T-> (zw)y = R
So, C from J, T, and R:
C = \ x y z -> xzy
RRR ... HA!
because RRRabc = RaRbc = Rbac = acb !
I = I -- simplest, simplest realization
M = \ x -> xx
But to get M, B would really help, so B is:
B = \ x y z -> x(yz)
B = C(JIC)(JI)xyz = (JIC)x(JI)yz = JICx(JI)yz = IC(I(JI)x)yz = C((JI)x)yz = JIxzy = Ix(Iyz) = B
So, M from J, I, B, C, R, T:
J(Ra)III = (Ra)I((Ra)II) = I((Ra)IIa = IIaa = aa = M, which, in combinators is:
RI(RI(RI(BJR))) ... RI moves the desired system down the chain ... for the 'J' anyway.
which is RI(RI(BJR))aI = RI(BJR)aII = BJRaIII = J(Ra)IIISo, now S:
S = \ x y z = xy(xz)
So, the strategy here is to move the 'W' to before the x and then 'I' it out, or:
JabcI ... no because that gets us:
ab(aIc) and that is NOT what we want. we want: