- Haskell-Cafe - Haskell.org

Functional programming and William Lawvere's notion of "variable sets"(vs topos of "static sets") in a Topos ...
by Vasili I. Galchin 04 Aug '14

04 Aug '14

Hello Haskellers, I have been re-reading William Lawvere's description of "variable sets" (a functor category) in "a elementary topoi" on a discrete poset/preset vs a "abstract sets" in the topos of abstract sets . In Haskell( and other FPLs .. ) aren't "pure" computations just over the topos of abstract sets and "mutable" /"time-varying/stateful" computations aren't just "variable sets" (i.e. a functor over a discrete preset-poset)?? Please forgive my bad English :-( If uncertain aboyt my Englsih, please say so. Kind regards, Vasya P.S. Yes I am familiar with Eugenio Moggi's papers on using monads for stateful computations ..

2 1

Re: [Haskell-cafe] Fwd: Default stdout buffering of child process of createProcess
by Doug McIlroy 04 Aug '14

04 Aug '14

>> I still think haskell is using screwy defaults for stdout buffering. > Line buffered would be an inefficient default. Stdout is fully buffered in > c99 if it can be determined that it is not attached to a terminal. Putting efficiency before efficacy is un-Haskellian. How can the required determination be implemented? Stdout may be attached to a terminal indirectly through a pipeline. It may be "attached" through a file that another process is watching. It may be attached to some other real-time device or system. Buffering can cause unbounded delays in systems with sporadic input. And it can cause deadlock in systems that employ feedback, as most systems do. Terminals, for example, are unbuffered not merely because users are impatient, but more critically because users are feedback agents. Because the effects of buffering are not transparent, it would be wise to make it an optional optimization, not a default.

5 6

"Standardising" Haskell AST for tooling
by Alan & Kim Zimmerman 03 Aug '14

03 Aug '14

Hi all I am looking at updating HaRe for GHC 7.8.3, and I am fighting my way through the AST changes. One of the things I have had at the back of my mind for a while is to use something like Kure universes or more generally lens to provide a set of isomorphisms from the various flavours of AST into some kind of standardised internal representation, allowing easier tool manipulation. This could potentially decouple the tools from the specific compiler/analyzer, so they could work across GHC 7.6.x, GHC 7.8.x, haskell-src-exts, haste, etc.. Obviously there would be limitations to this where an advance in the language brings in new features, but a lot of useful tool work can be done that does not touch the new stuff. I don't know if anything similar is planned in either ghc-server or another toolchain. My haskell-token-utils is a first limited attempt to bring source code round tripping to a variety of backends, but a more general solution to the AST phase would help tooling in general So, is this worth doing? Is it being done already, or planned? Regards Alan

1 0

Bad interaction of inlinePerformIO and mutable vectors
by Michael Snoyman 03 Aug '14

03 Aug '14

I'm trying to understand why some code isn't behaving as I'd expect, and to determine whether it's a bug or not (and where that bug might be). Here's the simplest version of the code: import Data.ByteString.Internal (inlinePerformIO) import qualified Data.Vector as V import qualified Data.Vector.Mutable as VM main :: IO () main = do vm <- VM.new 1 VM.write vm 0 'A' let x = inlinePerformIO $ VM.write vm 0 'B' x `seq` (V.freeze vm >>= print) A more complete example is available on lpaste[1]. The problem is that I would expect the output to be "B", but in fact "A" is still printed. From the longer paste that I linked to, you can see that: * When using unsafePerformIO and unsafeDupablePerformIO, the semantics work as I would have expected: "B" is printed after forcing evaluation of the result. * If I add a `VM.read vm 0` call after the write, it also works. * Using IORef, the behavior is also as I would have expected: as soon as the result is evaluated, the reference is updated. I'm testing on GHC 7.8.3, Ubuntu 64-bit, and compiling with -O2. I'm curious if anyone has an idea as to why there is this difference in behavior. Michael [1] http://lpaste.net/108483

6 10

http://www.downforeveryoneorjustme.com/haskell.org
by Tim C. Schroeder 03 Aug '14

03 Aug '14

Thinks always break on the weekend, don’t they! Apologies if this is a scheduled outtake. In the meantime, there’s fortunately a Haddock mirror on http://haddocks.fpcomplete.com/fp/7.7/20131212-1/ ;-) Cheers, Tim

1 0

Haskell Platform 2014.2.0.0 Release Candidate 4 (Windows only)
by Mark Lentczner 03 Aug '14

03 Aug '14

This is an update to the Windows RC2 candidates. These candidates fix three problems with the installation scripts. The binary build of the packages has not changed. *Fixes:* - Fix the PATH to add the location where binaries are installed with "cabal install --global" - Fix the url shortcut that is installed, to point to the platform+ghc master indices, rather than just the ghc indices - Fix where a 32-bit HP installed on a 64-bit system was going *Installers can be found here:* - HaskellPlatform-2014.2.0.0-i386-RC4-setup.exe <http://www.ozonehouse.com/mark/platform/HaskellPlatform-2014.2.0.0-i386-RC4…> - HaskellPlatform-2014.2.0.0-x86_64-RC4-setup.exe <http://www.ozonehouse.com/mark/platform/HaskellPlatform-2014.2.0.0-x86_64-R…> - Mark P.S.: You might have noticed that the server that hosted the RC files was down intermittently yesterday and today. It suffered a double (!) disk failure. It is back up with shiny new disks. P.P.S: As always, for the reasonably wary: shasum -a 256: 975e014d53cfdb84036889923d6e9598e4623baa9c69d53dc4d9372fe100cf95 HaskellPlatform-2014.2.0.0-i386-RC4-setup.exe 05b39901cdc43de335583c461bcd77c0d8dd5765ab195ad387a0dc774a43bee2 HaskellPlatform-2014.2.0.0-x86_64-RC4-setup.exe

1 0

unfoldr with a little extra
by David Feuer 03 Aug '14

03 Aug '14

Edward Kmett's NonEmpty module has a version of unfoldr (there just called unfoldr) for non-empty lists that seems also to be useful when applied to regular lists: unfoldr1::(b -> (a, Maybe b)) -> b -> [a] unfoldr1 f b= go b where go q = case f q of (a,may_b) -> a : maybe [] go may_b My question is whether it is possible to write this function using the usual unfoldr. I have the feeling there might be some way, but I just can't see it. David

2 1

typed tagless-final interpretation examples broken with recent ghc
by Mathijs Kwik 02 Aug '14

02 Aug '14

Hi all, I've been reading up on typed tagless-final interpretations [1] and the accompanying examples. It seems the stuff about CPS transformations does no longer compile, probably because of stricter typing rules. I tried both ghc 7.6 and ghc 7.8, which both give a different kind of error message. It's a bit much and long to paste here though. I would really like to get the example working, but couldn't manage by only supplying type signatures. Perhaps there is some language pragma I can turn on or off to get the old behaviour back? The 2 files needed (no further libraries needed) are: - http://okmij.org/ftp/tagless-final/course/TTF.hs (working) - http://okmij.org/ftp/tagless-final/course/CPS.hs (problem) All help would be greatly appreciated. Regards, Mathijs [1] http://okmij.org/ftp/tagless-final/course/index.html

2 1

re-reading a Samson Abramsky paper ..
by Vasili I. Galchin 02 Aug '14

02 Aug '14

http://staff.science.uva.nl/~ssimon/indjournal/pdf/abramsky.pdf .. no words .. I will let Samson speak for himself .. :-) Hopefully my audience cam keep up with Abramsky's terseness .. he is very "cheeky" ...

1 0

Re: [Haskell-cafe] Tor project
by Adam Wick 02 Aug '14

02 Aug '14

Hi - Yes, we (Galois) are. The end goal is to have a Tor implementation running on a HaLVM. Right now the project is internal, but the plan is to push a basic relay node implementation out to our GitHub site sometime in the next few weeks. As for TLS, it is possible that timing attacks based on a functional language implementation could be more likely than those for a traditional C implementation. On the other hand, functional language implementations protect you from a wide variety of attacks that occur in C implementations. I don’t believe the balance has been studied, but it’d be interesting. I do know the OCaml/Mirage folks have been having good luck with their TLS implementation. I believe they’ve at least started doing some red team analysis of it, as well, with good results. See their various blog posts, starting with http://openmirage.org/blog/introducing-ocaml-tls. I’m not sure if Vincent’s library has been subject to similar evaluation, and I know the partial library in our Tor implementation has not been. - Adam Quoth: > I’ll make a question out of it: > > Is anyone working on a Haskell project compatible with Tor? Library, Server, Browser, etc. > Is anyone interested in such a project? > Would the Haskell Runtime and TLS modules have any time dependent behavior that would make encryption harder/easier to break than C implementations? Basically, is the TLS attach surface smaller or larger than openssl and is there any data to support claims of such?

14 34