- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Solved but strange error in type inference
by oleg＠okmij.org 04 Jan '12

04 Jan '12

One should keep in mind the distinction between schematic variables (which participate in unification) and universally quantified variables. Let's look at the forall-elimination rule G |- e : forall a. A -------------------- E G |- e : A[a := t] If the term e has the type forall a. A, we can use the term at some specific type t. Often the type checker doesn't know which specific type t to choose. Therefore, the type checker inserts a schematic type variable X (think of Prolog logic variable), to defer the decision. Further down the type-checking road, more information becomes available and it will become clear what concrete type t to use. Like in Prolog, a logic variable denotes a guess, or a promise, to be forced later (there is a deep connection between laziness and logic variables). So, the forall-elimination rule becomes G |- e : forall a. A -------------------- E G |- e : A[a := X] Let's look at the forall-introduction rule G |- e : A [a := aeigen] -------------------- I where aeigen \not\in G G |- e : forall a. A To type-check that a term e has a polymorphic type (which happens when the user gave a type signatures which contains type variables, implicitly quantified), the type-checker generates a fresh, unique _constant_ (called eigenvariable) and type-checks the term with the constant substituted for the type variable. If the term type-checks, it does have the polymorphic type. (One may ask why this fresh constant is called eigen_variable_ if it doesn't actually vary. That is a very good question, answered in http://okmij.org/ftp/formalizations/inductive-definitions.html#eigenvariabl… ). GHC calls these eigenvariable rigid variables. The upshot: eigenvariabes are constants and can't be changed by unification. Schematic variables are variables and can be substituted by unification. Quantified type variables are replaced by schematic variables when _using_ a polymorphic term. Quantified type variables are replaced by constants (or, rigid variables) when _type-checking_ a term. The earlier example: f :: a -> a f x = x :: a can be alpha-converted [recall, ScopedTypeVariable extension is off] as f :: a -> a f x = x :: b First the type-checker generates beigen. To check if 'f' can indeed be given the type signature a -> a, GHC generates the eigenvariable aeigen and type-checks (\x::aeigen -> x :: beigen) :: aeigen The problem becomes obvious. The error message is very precise, describing the precise location where type variables are bound. Couldn't match type `a' with `b' `a' is a rigid type variable bound by the type signature for f :: a -> a at /tmp/e.hs:2:1 `b' is a rigid type variable bound by an expression type signature: b at /tmp/e.hs:2:7 In the expression: x :: b In an equation for `f': f x = x :: b Again, read `rigid type variable' as eigen-variable. In OCaml, type variables are schematic variables (in many contexts). For example: # let f1 (x:'a) = (x:'b);; val f1 : 'a -> 'a = <fun> # let f2 (x:'a) = x + 1;; val f2 : int -> int = <fun> The function f2 is not polymorphic at all, although it may appear so from the use of the type variable 'a. But in other contexts OCaml does work like GHC: # module F : sig val f5 : 'a -> 'a end = struct let f5 x = x + 1 end;; Error: Signature mismatch: Modules do not match: sig val f5 : int -> int end is not included in sig val f5 : 'a -> 'a end Values do not match: val f5 : int -> int is not included in val f5 : 'a -> 'a Further, OCaml has now a specific construct to introduce rigid type variables (which appear as type constants). # let f4 (type a) (x:a) = (x:a) + 1;; Characters 25-26: let f4 (type a) (x:a) = (x:a) + 1;; ^ Error: This expression has type a but an expression was expected of type int

1 0

GHC compilation issue: Working around bug #4374?
by Sanket Agrawal 04 Jan '12

04 Jan '12

I am getting the compilation error below when building GHC 7.0.4 on RHEL5 (x86_64) – I configured make to point to ncurses and libgmp. I will appreciated pointers on how to work around the issue below. I don’t have root privileges. My apologies if this has already been discussed in this forum. I searched for the issue but could find only the GHC bug ticket below. GHC bug ticket: http://hackage.haskell.org/trac/ghc/ticket/4374 - it doesn’t have description on how to work around the bug. Compilation error: ----------------------- $ C_INCLUDE_PATH=/efs/dist/fsf/ncurses/5.6/common/include/ncurses:/home/saagrawa/scripts/misc/libgmp/include LIBRARY_PATH=/efs/dist/fsf/ncurses/5.6/exec/lib:/home/saagrawa/scripts/misc/libgmp/lib make ===--- updating makefiles phase 0 make -r --no-print-directory -f ghc.mk phase=0 just-makefiles ===--- updating makefiles phase 1 make -r --no-print-directory -f ghc.mk phase=1 just-makefiles ===--- updating makefiles phase 2 make -r --no-print-directory -f ghc.mk phase=2 just-makefiles ===--- updating makefiles phase 3 make -r --no-print-directory -f ghc.mk phase=3 just-makefiles ===--- finished updating makefiles make -r --no-print-directory -f ghc.mk all "inplace/bin/ghc-stage1" libraries/integer-gmp/dist-install/build/GHC/Integer.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/GMP/Internals.dyn_o libraries/integer-gmp/dist-install/build/GHC/Integer/Type.dyn_o libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.dyn_o libraries/integer-gmp/dist-install/build/cbits/cbits.dyn_o libraries/integer-gmp/gmp/objs/*.o `/usr/bin/find libraries/integer-gmp/dist-install/build -name "*_stub.dyn_o" -print` -shared -dynamic -dynload deploy -dylib-install-name /home/saagrawa/scripts/misc/ghc/7.0.4/lib/ghc-7.0.4/`basename "libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.3-ghc7.0.4.so" | sed 's/^libHS//;s/[-]ghc.*//'`/`basename "libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.3-ghc7.0.4.so"` -no-auto-link-packages -package ghc-prim-0.2.0.0 -o libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.3-ghc7.0.4.so /efs/dist/fsf/gcc/4.4.3-build004/.exec/x86-64.rhel.5/libexec/gcc/x86_64-unknown-linux-gnu/4.4.3/ld: libraries/integer-gmp/gmp/objs/aors.o: relocation R_X86_64_32 against `__gmpz_sub' can not be used when making a shared object; recompile with -fPIC libraries/integer-gmp/gmp/objs/aors.o: could not read symbols: Bad value collect2: ld returned 1 exit status make[1]: *** [libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.3-ghc7.0.4.so] Error 1 make: *** [all] Error 2 $ ll /home/saagrawa/scripts/misc/libgmp/lib|awk '{print $9,$10,$11}' ### the libgmp lib folder has dynamic libraries libgmp.so.3.5.2* libgmp.so.3 -> libgmp.so.3.5.2* libgmp.so -> libgmp.so.3.5.2* libgmp.la* libgmp.a

1 1

Re: [Haskell-cafe] Experiments in Haskell Packaging
by Chris Dornan 04 Jan '12

04 Jan '12

Hi Ryan, Ryan Grant [mailto:rgrant@rgrant.org] said: > Are packages cabal-installed using --global? The packages that come with a compiler or Haskell Platform are installed --global. Every other package is installed with cabal, by default into the user's space. > Is it mostly reliant on cabal or cabal-dev? It works with cabal. I have not tested interworking with cabal-dev yet. (There is a big overlap in the functionality of course.) > How easily can I upgrade cabal? > http://stackoverflow.com/questions/5380888/cabal-install-and-debian The stackoverflow discussion seems a little confused in that 'cabal update' just updates the local cache of package headers from the server, not any of the installed packages. But I am using the latest version of cabal-install (0.10.2), compiled with cabal-1.10.1.0 library (from March rather than June's cabal-1.10.2.0). Users should never have to build their own cabal-install, but just keep up to date with the distro. If users should need to use their own private Cabal builds for whatever reason we will provide a wiki page showing them how to do it. > Can the idea be extended to OSX, as well? I see no reason why not. The idea behind my post was really to say that we should be doing this with all distros. I will be making the hub sources available through hackage/github when beta testing is complete (but sooner if demand dictates). Folks can install it on their own systems and hook in their own GHC and HP builds. Best of all folks can make it available in other Haskell distros. The interesting question is whether anyone else decides to structure their distros in the same way as the justhub distro. That is the real challenge! > How does this strategy relate to the Nix package manager? > http://nixos.org/nix/ In a sense the philosophy is similar because I am arguing that we shouldn't be updating distributions, just adding to them. In that sense it is a functional philosophy. But after that 30,000 foot observation the comparison diverges as far as I can see. Great questions! Thanks, Chris

1 0

Is the haddock generator on Hackage down?
by Bardur Arantsson 04 Jan '12

04 Jan '12

Hi all, No Haddock documentation seems to have been generated on Hackage in the past few days. See e.g. http://hackage.haskell.org/package/copilot-2.0.3 or http://hackage.haskell.org/package/derive-2.5.5 Does anyone know if the cron job (or whatever) isn't running for some reason? Cheers,

2 1

space-efficient, composable list transformers [was: Re: Reifying case expressions [was: Re: On stream processing, and a new release of timeplot coming]]
by Sebastian Fischer 04 Jan '12

04 Jan '12

Hello Heinrich, On Tue, Dec 27, 2011 at 1:09 PM, Heinrich Apfelmus < apfelmus(a)quantentunnel.de> wrote: > Sebastian Fischer wrote: > >> all functions defined in terms of `ListTo` and `interpret` >> are spine strict - they return a result only after consuming all input >> list >> constructors. > > Indeed, the trouble is that my original formulation cannot return a result > before it has evaluated all the case expressions. To include laziness, we > need a way to return results early. > > Sebastian's ListTransformer type does precisely that for the special > case of lists as results, Hmm, I think it does more than that.. (see below) but it turns out that there is also a completely generic way of returning > results early. In particular, we can leverage lazy evaluation for the > result type. > This is nice! It would be cool if we could get the benefits of ListConsumer and ListTransformer in a single data type. I know that you chose these names to avoid confusion, but I would like to > advertise again the idea of choosing the *same* names for the constructors > as the combinators they represent [...] This technique for designing data > structures has the huge advantage that it's immediately clear how to > interpret it and which laws are supposed to hold. I also like your names better, although they suggest that there is a single possible interpretation function. Even at the expense of blinding eyes to the possibility of other interpretation functions, I agree that it makes things clearer to use names from a *motivating* interpretation. In hindsight, my names for the constructors of ListTransformer seem to be inspired by operations on handles. So, `Cut` should have been named `Close` instead.. > Especially in the case of lists, I think that this approach clears up a > lot of confusion about seemingly new concepts like Iteratees and so on. A share the discomfort with seemingly alien concepts and agree that clarity of exposition is crucial, both for the meaning of defined combinators and their implementation. We should aim at combinators that people are already familiar with, either because they are commonplace (like id, (.), or fmap) or because they are used by many other libraries (like the Applicative combinators). A good way to explain the meaning of the combinators is via the meaning of the same combinators on a familiar type. Your interpretation function is a type-class morphism from `ListTo a b` to `[a] -> b`. For Functor we have: interpret (fmap f a) = fmap f (interpret a) On the left side, we use `fmap` for `ListTo a` on the right side for `((->) l)`. Similarly, we have the following properties for the coresponding Applicative instances: interpret (pure x) = pure x interpret (a <*> b) = interpret a <*> interpret b Such morphism properties simplify how to think about programs a lot, because one can think about programs as if they were written in the *meaning* type without knowing anything about the *implementation* type. The computed results are the same but they are computed more efficiently. Your `ListTo` type achieves space efficiency for Applicative composition of list functions by executing them in lock-step. Because of the additional laziness provided by the `Fmap` constructor, compositions like interpret a . interpret b can also be executed in constant space. However, we cannot use the space efficient Applicative combinators again to form parallel compositions of sequential ones because we are already in the meaning type. We could implement composition for the `ListTo` type as follows (<.) :: ListTo b c -> ListTo a [b] -> ListTo a c a <. b = interpret a <$> b But if we use a result of this function as argument of <*>, then the advantage of using `ListTo` is lost. While interpret ((,) <$> andL <*> andL) runs in constant space, interpret ((,) <$> (andL <. idL) <*> (andL <. idL)) does not. The ListTransformer type supports composition in lock-step via a category instance. The meaning of `ListTransformer a b` is `[a] -> [b]` with the additional restriction that all functions `f` in the image of the interpretation function are incremental: xs `isPrefixOf` ys ==> f xs `isPrefixOf` f ys Composition as implemented in the ListTransformer type satisfies morphism properties for the category instance: transformList id = id transformList (a . b) = transformList a . transformList b As it is implemented on the ListTransformer type directly (without using the interpretation function), it can be combined with the Applicative instance for parallel composition without losing space efficiency. The Applicative instance for `ListTransformer` is different from the Applicative instance for `ListTo` (or `ListConsumer`). While interpret ((,) <$> idL <*> idL) is of type `[a] -> ([a],[a])` transformList ((,) <$> idL <*> idL) is of type `[a] -> [(a,a)]`. We could achieve the latter behaviour with the former instance by using an additional fmap. But uncurry zip <$> ((,) <$> idL <*> idL) has the same disadvantages regarding space efficiency as referred to above because the computation of `zip` cannot occur in lock-step with another computation. The meaning of the Applicative instance of `ListTransformer` can again be described using morphism properties on Applicative structures. The corresponding structure on the meaning type `[a] -> [b]` is the following combination of the Applicative instances for functions and for ZipLists. fmap f a = liftA (fmap f) a pure x = pure (getZipList (pure x)) a <*> b = getZipList <$> liftA2 (<*>) (ZipList <$> a) (ZipList <$> b) I have a gut feeling that the laziness provided by the `Fmap` constructor is too implicit to be useful for the kind of lock-step composition provided by ListTransformer. So I don't have high hopes that we can unify `ListConsumer` and `ListTransformer` into a single type. Do you have an idea? Sebastian

3 3

Avoiding parametric function binding
by Kevin Quick 03 Jan '12

03 Jan '12

I'm having some difficulty avoiding a tight parametric binding of function parameters, which is limiting the (de)composability of my expressions. I'm curious as to whether there is an option or method I haven't tried to achieve this. Here's an example test case: > data Var = V1 (Maybe Int) > | V2 (Maybe String) > > test = V1 (Just 1) Given this structure, I can do something like this: > elemStr :: (Show a) => Maybe a -> String > elemStr = show > > varStr (V1 x) = elemStr $ id x > varStr (V2 x) = elemStr $ id x > > main = putStrLn . varStr $ test This operation extracted the internal value from the Var container, and then passes it to a parametric function (id) and that result to another parametric function with a class restriction on the input. This is fine so-far. However, what I'd like to do is decompose this to allow more flexibility (using id is pretty boring) without having to repeat the extraction boilerplate each time. My first attempt: > varElem :: forall x . (Show x) => Var -> x > varElem (V1 x) = x > varElem (V2 x) = x > > main = putStrLn . elemStr . varElem $ test This fails because even though I've specified the same class constraint for the output type of varElem that elemStr requires on its input element, the compiler binds the parametric type of x when it processes the first (V1) definition and fails with an error on the second definition because it asserts that x must be an Int and it found a String. I realized that the parametric output type was awkward, so I tried inverting the design (somewhat similar to fmap): > onVarElem :: forall a . (Show a) => (Maybe a -> String) -> Var -> String > onVarElem f (V1 x) = f x > onVarElem f (V2 x) = f x > > main = putStrLn . onVarElem elemStr $ test This is probably a better design, but still fails for the same reason: Couldn't match expected type `Int' with actual type `[Char]' Expected type: Maybe Int Actual type: Maybe String In the first argument of `f', namely `x' In the expression: f x Even changing onVarElem so the second parameter was a simple variable and performing the pattern match in an internal where or let binding failed because the first application of f bind its parametric values. Is there a way to delay this parametric binding to allow composable function specifications? Thanks, Kevin -- -KQ

4 5

More cabal install problems
by Victor Miller 03 Jan '12

03 Jan '12

I've been trying to install threadscope on my macbook pro runing OSX 10.7 (Lion). This hasn't been easy. Thanks to help here, I finally got glib installed, but now one of the hangups is in installing the package gio. The following happens: Building gio-0.12.2... Building library... creating dist/build /usr/bin/ghc --make -package-name gio-0.12.2 -hide-all-packages -fbuilding-cabal-package -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -Idist/build/autogen -Idist/build -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build -hidir dist/build -stubdir dist/build -package-id array-0.3.0.2-143060371bda4ff52c270d1067551fe8 -package-id base-4.3.1.0-239d76b73f466dc120129098b3472858 -package-id bytestring-0.9.1.10-5bb17614aed376ea31b721a9272770b1 -package-id containers-0.4.0.0-b4885363abca642443ccd842502a3b7e -package-id glib-0.12.2-185c12da89238d25c489c0b80fc015c5 -package-id mtl-2.0.1.0-5b7a9cce5565d8cc8721ba4f95becf1b -O -XHaskell98 -XForeignFunctionInterface System.GIO System.GIO.Enums System.GIO.Types System.GIO.Async.AsyncResult System.GIO.Signals System.GIO.Async.Cancellable System.GIO.File.AppInfo System.GIO.File.ContentType System.GIO.File.FileAttribute System.GIO.File.File System.GIO.File.FileEnumerator System.GIO.File.FileInfo System.GIO.File.FileMonitor System.GIO.File.IOError System.GIO.File.MountOperation System.GIO.Icons.Emblem System.GIO.Icons.EmblemedIcon System.GIO.Icons.FileIcon System.GIO.Icons.Icon System.GIO.Icons.ThemedIcon System.GIO.Volumes.Drive System.GIO.Volumes.Mount System.GIO.Volumes.Volume System.GIO.Volumes.VolumeMonitor <command line>: cannot satisfy -package-id mtl-2.0.1.0-5b7a9cce5565d8cc8721ba4f95becf1b (use -v for more information) World file is already up to date. cabal: Error: some packages failed to install: gio-0.12.2 failed during the building phase. The exception was: ExitFailure 1 ------- However, cabal list tells me: * mtl Synopsis: Monad classes, using functional dependencies Default available version: 2.0.1.0 Installed versions: 2.0.1.0 License: BSD3 which tells me that the version of mtl that's desired is already installed. Any suggestions? Victor

2 2

On the purity of Haskell
by Steve Horne 03 Jan '12

03 Jan '12

This is just my view on whether Haskell is pure, being offered up for criticism. I haven't seen this view explicitly articulated anywhere before, but it does seem to be implicit in a lot of explanations - in particular the description of Monads in SBCs "Tackling the Awkward Squad". I'm entirely focused on the IO monad here, but aware that it's just one concrete case of an abstraction. Warning - it may look like trolling at various points. Please keep going to the end before making a judgement. To make the context explicit, there are two apparently conflicting viewpoints on Haskell... 1. The whole point of the IO monad is to support programming with side-effecting actions - ie impurity. 2. The IO monad is just a monad - a generic type (IO actions), a couple of operators (primarily return and bind) and some rules - within a pure functional language. You can't create impurity by taking a subset of a pure language. My view is that both of these are correct, each from a particular point of view. Furthermore, by essentially the same arguments, C is also both an impure language and a pure one. See what I mean about the trolling thing? I'm actually quite serious about this, though - and by the end I think Haskell advocates will generally approve. First assertion... Haskell is a pure functional language, but only from the compile-time point of view. The compiler manipulates and composes IO actions (among other things). The final resulting IO actions are finally swallowed by unsafePerformIO or returned from main. However, Haskell is an impure side-effecting language from the run-time point of view - when the composed actions are executed. Impurity doesn't magically spring from the ether - it results from the translation by the compiler of IO actions to executable code and the execution of that code. In this sense, IO actions are directly equivalent to the AST nodes in a C compiler. A C compiler can be written in a purely functional way - in principle it's just a pure function that accepts a string (source code) and returns another string (executable code). I'm fudging issues like separate compilation and #include, but all of these can be resolved in principle in a pure functional way. Everything a C compiler does at compile time is therefore, in principle, purely functional. In fact, in the implementation of Haskell compilers, IO actions almost certainly *are* ASTs. Obviously there's some interesting aspects to that such as all the partially evaluated and unevaluated functions. But even a partially evaluated function has a representation within a compiler that can be considered an AST node, and even AST nodes within a C compiler may represent partially evaluated functions. Even the return and bind operators are there within the C compiler in a sense, similar to the do notation in Haskell. Values are converted into actions. Actions are sequenced. Though the more primitive form isn't directly available to the programmer, it could easily be explicitly present within the compiler. What about variables? What about referential transparency? Well, to a compiler writer (and equally for this argument) an identifier is not the same thing as the variable it references. One way to model the situation is that for every function in a C program, all explicit parameters are implicitly within the IO monad. There is one implicit parameter too - a kind of IORef to the whole system memory. Identifiers have values which identify where the variable is within the big implicit IORef. So all the manipulation of identifiers and their reference-like values is purely functional. Actual handling of variables stored within the big implicit IORef is deferred until run-time. So once you accept that there's an implicit big IORef parameter to every function, by the usual definition of referential transparency, C is as transparent as Haskell. The compile-time result of each function is completely determined by its (implicit and explicit) parameters - it's just that that result is typically a way to look up the run-time result within the big IORef later. What's different about Haskell relative to C therefore... 1. The style of the "AST" is different. It still amounts to the same thing in this argument, but the fact that most AST nodes are simply partially-evaluated functions has significant practical consequences, especially with laziness mixed in too. There's a deep connection between the compile-time and run-time models (contrast C++ templates). 2. The IO monad is explicit in Haskell - side-effects are only permitted (even at run-time) where the programmer has explicitly opted to allow them. 3. IORefs are explicit in Haskell - instead of always having one you can have none, one or many. This is relevant to an alternative definition of referential transparency. Politicians aren't considered transparent when they bury the relevant in a mass of the irrelevant, and even pure functions can be considered to lack transparency in that sense. Haskell allows (and encourages) you to focus in on the relevant - to reference an IORef Bool or an IORef Int rather than dealing with an IORef Everything. That last sentence of the third point is my most recent eureka - not so long ago I posted a "Haskell is just using misleading definitions - it's no more transparent than C" rant, possibly on Stack Overflow. Wrong again :-( So - what do you think?

25 119

Experiments in Haskell Packaging
by Chris Dornan 03 Jan '12

03 Jan '12

[I am sorry for if get two copies of this -- no sign of the first copy.] The justhub.org Haskell distribution for Enterprise Linux (RHEL/CentOS 5 & 6) is now live. The distribution deviates from current practice. When you upgrade to a new Haskell Platform you add the new platform to your Haskell infrastructure rather than replacing the old platform with a new one. Why? • Stability: Enterprise Linux places a strong emphasis on stability and updating packages should not break things. (This has provided some challenges for us as RHEL 5 is still using GCC 4.1.2 and Binutils 2.17.50.) • Flexibility: Different projects will in general need to work with different versions of the platform and toolkits and upgrade according to their own schedules. I believe Haskell’s strong-typing sharpens the need for this. Production projects will need to upgrade according to their own schedules while other projects will want to stay up-to-date. In general when you check out a source tree you want to build with the tools and libraries that it has been tested with and move on according to the project’s timetable. • Sandboxes: The same mechanism for managing the multiple toolkits and platforms can be adapted to provide an integrated sandbox utility. The logic that dictates that projects have different tool-chain requirements applies to the user packages too. (‘Handbox’ doesn’t really work so we use Hubs instead.) • Package Deletion: The infrastructure can also be expanded to complete the package management tools with package removal and garbage collection of library code. • The Catalogue: All of the GHC releases can be added as they become available. In general the distribution works just like any other – after an upgrade invoking ‘ghc’ without any other configuration will invoke the compiler for that latest platform, which should behave as it would on any other (working) distribution. But after an upgrade: • any projects configured to work with specific tool chains and libraries will continue undisturbed; • you can create a new hub based on the new platform and experiment with it on newly-checked-out source tree without disturbing an existing working tree (or just swap the hub into an existing work tree and back out again if things don’t work out); • even on release of a new version of a package (or if you want to experiment with your existing packages) you can easily duplicate an existing hub and delete, upgrade and add packages on a topic branch. Of course ‘serious developers’ have been doing this with home-brew infrastructure for ever. Nevertheless I have found doing it with well-integrated tools to be quite liberating. It might also help new users to make the transition to serious developers more quickly. Thoughts anyone? Chris

1 0

proxy settings with simpleHttp
by hanjoosten 03 Jan '12

03 Jan '12

Hi, I am fiddling around with the package http-enumerator to download web pages. I was used to `simpleHttp` do do that. However, I would like to infuence the proxy settings, because sometimes I am behind a firewall. Is there a simple way to do this? Thanks! Han. -- View this message in context: http://haskell.1045720.n5.nabble.com/proxy-settings-with-simpleHttp-tp51149… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

2 1