Re: [Haskell-cafe] decoupling type classes
Yin, 2012/1/14 Yin Wang yinwa...@gmail.com: On Sat, Jan 14, 2012 at 2:38 PM, Dominique Devriese dominique.devri...@cs.kuleuven.be wrote: I may or may not have thought about it. Maybe you can give an example of parametric instances where there could be problems, so that I can figure out whether my system works on the example or not. The typical example would be instance Eq a = Eq [a] where [] == [] = True (a : as) == (b : bs) = a == b as == bs _ == _ = False It can handle this case, although it doesn't handle it as a parametric instance. I suspect that we don't need the concept of parameter instances at all. We just searches for instances recursively at the call site: That seems like it could work, but typically, one would like termination guarantees for this search, to avoid the type-checker getting stuck... foo x = let overload bar (x:Int) = x + 1 in \() - bar x baz = in foo (1::Int) Even if we have only one definition of bar in the program, we should not resolve it to the definition of bar inside foo. Because that bar is not visible at the call site foo (1::int). We should report an error in this case. Think of bar as a typed dynamically scoped variable helps to justify this decision. So you're saying that any function that calls an overloaded function should always allow its own callers to provide this, even if a correct instance is in scope. Would that mean all instances have to be resolved from main? This also strikes me as strange, since I gather you would get something like length :: Monoid Int = [a] - Int, which would break if you happen to have a multiplicative monoid in scope at the call site? Dominique ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] named pipe interface
Hi, On 14.01.2012, at 12:11, Serge D. Mechveliani wrote: On Fri, Jan 13, 2012 at 12:19:34PM -0800, Donn Cave wrote: Quoth Serge D. Mechveliani mech...@botik.ru, ... Initially, I did the example by the Foreign Function Interface for C. But then, I thought But this is unnatural! Use plainly the standard Haskell IO, it has everything. So, your advice is return to FFI ? Well, it turns out that the I/O system functions in System.Posix.IO may work for your purposes. I was able to get your example to work with these functions, which correspond to open(2), read(2), write(2). I would also use these functions in C, as you did in your C program. Haskell I/O functions like hGetLine are analogous to C library I/O like fgets(3) - in particular, they're buffered, and I would guess that's why they don't work for you here. Specifically, openFile toA WriteOnly Nothing defaultFileFlags openFile fromA ReadOnly Nothing defaultFileFlags fdWrite toA str (str, len) - fdRead fromA 64 return str Great! Thank you very much. As I find, Posix.IO is not of the standard, but it is of GHC. Anyway, it fits my purpose. By openFile you, probably, mean openFd. Another point is the number of open files, for a long loop. I put toA_IO = openFd toA WriteOnly Nothing defaultFileFlags fromA_IO = openFd fromA ReadOnly Nothing defaultFileFlags axiomIO :: String - IO String axiomIO str = do toA - toA_IO fromA - fromA_IO fdWrite toA str (str, _len) - fdRead fromA 64 return str When applying axiomIO in a loop of 9000 strings, it breaks: too many open files. I do not understand why it is so, because toA_IO and fromA_IO are global constants (I have not any experience with `do'). Anyway, I have changed this to toA = unsafePerformIO toA_IO fromA = unsafePerformIO fromA_IO axiomIO :: String - IO String axiomIO str = do fdWrite toA str (str, _len) - fdRead fromA 64 return str And now, it works in loong loops too (I need to understand further whether my usage of unsafePerformIO really damages the project). I'd say this use of unsafePerformIO is *not* safe. E.g. a Haskell compiler is allowed to evaluate the right hand side of toA and fromA multiple times. If you aren't 100% sure that it is ok to use unsafePerformIO, don't use it! Try something like the following: initIO = do to - toA_IO from - fromA_IO return (to, from) axiomIO (to,from) str = do fdWrite to str (str, _len) - fdRead from 64 return str main = do fds - initIO … res - axiomIO fds … Obviously I didn't compile and test this code. Its performance is 9/10 of the C - C performance (ghc -O, gcc -O, Linux Debian). It is still slow: 12 small strings/second on a 2 GHz machine. But this is something to start with. I was able to get your example to work with these functions, which correspond to open(2), read(2), write(2). I would also use these functions in C, as you did in your C program. Haskell I/O functions like hGetLine are analogous to C library I/O like fgets(3) - in particular, they're buffered, and I would guess that's why they don't work for you here. Indeed. Initially, I tried C - C, and used fgets, fputs, fflush. And it did not work, it required to open/close files inside a loop; I failed with attempts. Again, do not understand, why (do they wait till the buffer is full?). Then, I tried read/write, as it is in fifoFromA.c which I posted. And it works. Now, Haskell - C gives a hope. Nice. Thanks, -- Sergei mech...@botik.ru ___ Glasgow-haskell-users mailing list glasgow-haskell-us...@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] bindings for libvirt
The author of libvirt, Richard Jones, is an OCaml hacker. G -- -Original Message- From: Michael Litchard mich...@schmong.org Sender: haskell-cafe-boun...@haskell.org Date: Sun, 15 Jan 2012 14:05:56 To: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] bindings for libvirt That's encouraging! On Sun, Jan 15, 2012 at 1:41 PM, Erik de Castro Lopo mle...@mega-nerd.com wrote: Michael Litchard wrote: Due to the direction things are going at work, I have become interested in Haskell bindings for libvirt. Noticed that this hasn't been done yet. Interesting! I was wondering if this was due to lack of motivation, or if there were some difficult hurdles with libvirt that make the project cost-prohibitive. Well there are already Ocaml bindings for libvirt http://libvirt.org/ocaml/ so its most likely the former. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] bindings for libvirt
Gaius Hammond wrote: The author of libvirt, Richard Jones, is an OCaml hacker. libvirt has many authors. See the git repo commit history: http://libvirt.org/git/?p=libvirt.git;a=summary Richard Jones is however the the main author of the Ocaml bindings: http://libvirt.org/ocaml/ChangeLog.txt Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] named pipe interface
To my question about safety of
toA_IO = openFd toA WriteOnly Nothing defaultFileFlags
fromA_IO = openFd fromA ReadOnly Nothing defaultFileFlags
toA = unsafePerformIO toA_IO
fromA = unsafePerformIO fromA_IO
axiomIO :: String - IO String
axiomIO str = do
fdWrite toA str
(str, _) - fdRead fromA 64
return str
Jean-Marie Gaillourdet wrote on Jan 16, 2012
[..]
I'd say this use of unsafePerformIO is *not* safe. E.g. a Haskell
compiler is allowed to evaluate the right hand side of toA and fromA
multiple times. If you aren't 100% sure that it is ok to use
unsafePerformIO, don't use it!
[..]
For example, consider in the above context the program
main = do
(str1, _) - fdRead fromA 64
(str2, _) - fdRead fromA 64
putStr (str1 ++ str2)
Is this possible that str1 and str2 are input from different file
descriptors?
Does this effect depend on in-lining of fromA_IO by the compiler ?
Will {-# NOTINLINE fromA_IO #-} make it safe?
Please, copy the respond to mech...@botik.ru
Regards,
--
Sergei
mech...@botik.ru
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Patch combinators
Hi all! Based on ideas by Koen Claessen, I have made a small module for what might be called patch combinators: http://hpaste.org/56501 Examples are found as comments. Before I push this to Hackage, I just wanted to check if there is any package that already provides this sort of functionality. (We're planning to use this module for expressing compile-time constraints on Feldspar functions.) Thanks for any feedback! / Emil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monad-control rant
On 01/16/2012 02:15 PM, Edward Z. Yang wrote: Hello Mikhail, Hi. Sorry, long email. tl;dr I think it makes more sense for throw/catch/mask to be bundled together, and it is the case that splitting these up doesn't address the original issue monad-control was designed to solve. ~ * ~ Anders and I thought a little more about your example, and we first wanted to clarify which instance you thought was impossible to write. For example, we think it should be possible to write: instance MonadBaseControl AIO AIO Notice that the base monad is AIO: this lets you lift arbitrary AIO operations to a transformed AIO monad (e.g. ReaderT r AIO), but no more. If this is the instance you claimed was impossible, we'd like to try implementing it. Can you publish the full example code somewhere? However, we don't think it will be possible to write: instance MonadBaseControl IO AIO Because this lets you leak arbitrary IO control flow into AIO (e.g. forkIO, with both threads having the ability to run the current AIO context), and as you stated, you only want to allow a limited subset of control flow in. (I think this was the intent of the original message.) I was talking about the latter instance. And I don't want to lift IO control to AIO, I want an API that works with both IO and AIO. The real problem with `MonadBaseControl IO AIO` is that the interpreter cuts actions into smaller pieces (at blocking operations) and then reschedules them in some order. For example, consider the following piece of code: (`catch` \e → HANDLER) $ do FOO -- wait until the state satisfies the condition aioCond STATE_CONDITION BAR The interpreter installs HANDLER and executes FOO. Then it restores exception handlers of some other program and executes a piece of it. Eventually, when the state satisfies STATE_CONDITION, the interpreter restores HANDLER and executes BAR. It's impossible to implement `catch` by some sort of straightforward delegation to `Control.Exception.catch`, you can't inject you logic into IO (at least without some bizarre inversion of control). I don't see why functions like `throwIO`, `catch`, `finally`, `bracket`, etc should be tied to IO or monads that allow lifting of IO actions. The functions make perfect sense in `ErrorT SomeException Identity` and in many other monads that have nothing to do with IO, why restrict ourselves? It's like exporting custom named `|` and friends for each parser combinator library and then reimplementing common Alternative idioms again and again. Maybe client code doesn't want to be attached to AIO base monads, though; that's too restrictive for them. So they'd like to generalize a bit. So let's move on to the issue of your typeclass decomposition. ~ * ~ I don't think it makes too much sense have thing pick off a menu of Abort/Recover/Finally from a semantics perspective: It's easy to imagine monads that have an instance of one of the classes but not of the others I'd like to see some examples. I hypothesize that most of such monads are incoherent, semantically speaking. For example, what does it mean to have a monad that can recover exceptions, but for which you can't throw exceptions? Imagine a monad that disallows lifting of arbitrary IO actions, but can receive asynchronous events (which would probably be /implemented/ on top of asynchronous exceptions, but that's not important here) that behave like runtime-inserted left zeros. COMPUTATIONALLY_HEAVY_CODE `recover` \level → GIVE_AN_APPROXIMATION_INSTEAD(level) There only a few options: - You have special primitives which throw exceptions, distinct from Haskell's IO exceptions. In that case, you've implemented your own homebrew exception system, and all you get is a 'Catch MyException' which is too specific for a client who is expecting to be able to catch SomeExceptions. - You execute arbitrary IO and allow those exceptions to be caught. But then I can implement Throw: I just embed an IO action that is throwing an exception. - You only execute a limited subset of IO, but when they throw exceptions they throw ordinary IO exceptions. In this case, the client doesn't have access to any scarce resources except the ones you provided, so there's no reason for him to even need this functionality, unless he's specifically coding against your monad. As I said, you think of IO too much. The purpose of monad-abort-fd is to provide a generic API for handling errors that have values attached to them and for guarding actions with finalizers (as the notion of failure can include more things besides the errors). What does it mean to not have a Finally instance, but a Recover and Throw instance? Well, I can manually reimplement finally in this case (with or without support for asynchronous exceptions, depending
Re: [Haskell-cafe] Monad-control rant
On Mon, Jan 16, 2012 at 08:17, Mikhail Vorozhtsov mikhail.vorozht...@gmail.com wrote: As I said, you think of IO too much. I think you two are talking about two related but different things; monad-control is solving a *specific* problem with IO, but you want something more general. I think you'll find your more general solution will involve monad-control, but will not satisfy all the use cases for monad-control (because IO is a sewer, and sometimes you need to deal with the sewer as such). -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ICFP 2012 Call for papers
= ICFP 2012: International Conference on Functional Programming Copenhagen, Denmark, September 9 - 15, 2012 http://www.icfpconference.org/icfp2012 = Important Dates ~~~ Submissions due: Monday Mar 12, 2012 14:00 UTC Author response: Monday May 07, 2012 14:00 UTC - May 9 14:00 UTC Notification: Monday May 28, 2012 Final copy due: Monday Jul 02, 2012 Scope ~ ICFP 2012 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, and from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects, concurrency, or parallelism. Topics of interest include (but are not limited to): * Language Design: concurrency and distribution; modules; components and composition; metaprogramming; interoperability; type systems; relations to imperative, object-oriented, or logic programming * Implementation: abstract machines; virtual machines; interpretation; compilation; compile-time and run-time optimization; memory management; multi-threading; exploiting parallel hardware; interfaces to foreign functions, services, components, or low-level machine resources * Software-Development Techniques: algorithms and data structures; design patterns; specification; verification; validation; proof assistants; debugging; testing; tracing; profiling * Foundations: formal semantics; lambda calculus; rewriting; type theory; monads; continuations; control; state; effects; program verification; dependent types * Analysis and Transformation: control-flow; data-flow; abstract interpretation; partial evaluation; program calculation * Applications and Domain-Specific Languages: symbolic computing; formal-methods tools; artificial intelligence; systems programming; distributed-systems and web programming; hardware design; databases; XML processing; scientific and numerical computing; graphical user interfaces; multimedia programming; scripting; system administration; security * Education: teaching introductory programming; parallel programming; mathematical proof; algebra * Functional Pearls: elegant, instructive, and fun essays on functional programming * Experience Reports: short papers that provide evidence that functional programming really works or describe obstacles that have kept it from working If you are concerned about the appropriateness of some topic, do not hesitate to contact the program chair. Abbreviated instructions for authors * By March 12 2012, 14:00 UTC, submit a full paper of at most 12 pages (6 pages for an Experience Report), including bibliography and figures. The deadlines will be strictly enforced and papers exceeding the page limits will be summarily rejected. * Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. * Each submission must adhere to SIGPLAN's republication policy, as explained on the web at http://www.acm.org/sigplan/republicationpolicy.htm * Authors of resubmitted (but previously rejected) papers have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the program chair will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews. Overall, a submission will be evaluated according to its relevance, correctness, significance, originality, and clarity. It should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. The technical content should be accessible to a broad audience. Functional Pearls and Experience Reports are separate categories of papers that need not report original research results and must be marked as such at the time of submission. Detailed guidelines on both categories are on the conference web site. Proceedings will be published by ACM Press. Authors of accepted submissions are expected to transfer the copyright to the ACM. Presentations will be videotaped and released online if the presenter consents. Formatting: Submissions must be in PDF format printable in black and white on US Letter sized paper and interpretable by Ghostscript. If this requirement is a hardship, make
Re: [Haskell-cafe] How to make asynchronous I/O composable and safe?
I favor a wait-free concurrency model based on the `vat` from E language. Vats can be modeled very easily in Haskell, and in many other languages. I currently use such a vat model for my Haskell projects. I describe aspects of it at a few places: * http://lambda-the-ultimate.org/node/4289#comment-65886 (vats and methods) * http://lambda-the-ultimate.org/node/4325#comment-66645 (pipeline method calls) * http://awelonblue.wordpress.com/2011/10/06/vat-model-for-rdp/ Unfortunately, my code isn't generic. The vats I've implemented are specialized (i.e. via extra stages and queues) primarily for efficient processing of concurrent reactive dataflows. Advantages of Vats: * wait-free asynchronous IO, hence deadlock and starvation free * first-class methods that help in many ways: ** distribute the dispatch burden (no need for a `main` switch statement) ** extensible (easy to add new methods without adjusting central code) ** transparent parallelization (calls may transparently invoke local or remote methods) ** securable (control distribution and parameter-types of methods) ** easily model code distribution (e.g. create a method with monad action parameters) * simple state - variables local to each vat may be shared between methods * coarse-grained `islands of consistency` are easy to reason about * implicit batching between vats improves consistency AND efficiency * easy to express incremental computation (as sequence of method calls) * clean coarse-grained interaction with data-parallelism (e.g. spark parameters) Technically, the vat consistency model is not `composable`. Instead, it works well based on coarse granularity and the natural limits of local reasoning - i.e. actual use-cases only interact with one or two other vats before they extend far enough that developers simply design assuming arbitrary ordering and potential interference. Developers can build ad-hoc consistency models atop vats easily enough. I use a temporal consistency model atop vats, which is composable, but is feasible for my reactive dataflow model primarily due to its updates being commutative. That said, one should be careful about asserting transactions are composable. Transactions don't scale well as they compose, having greater opportunity for conflict, rework, starvation, priority inversion. Transactions also don't interact well with the real-world IO, such as continuous sensor streams or actuators. Despite the non-composability of vat semantics, they at least scale better than transactions. cf. http://awelonblue.wordpress.com/2011/07/05/transaction-tribulation/ The recent work on Cloud Haskell takes a similar inspiration from E's vats. However, the focus of cloud haskell is different and consequently there are a lot of subtle but important differences between cloud haskell processes and my use of vats, e.g. regarding process identifiers, serializability requirements, etc. * http://research.microsoft.com/~simonpj/papers/parallel/remote.pdf (cloud haskell) Regards, Dave On Fri, Jan 13, 2012 at 9:24 PM, Joey Adams joeyadams3.14...@gmail.comwrote: In Haskell, sound logic and a great type system lead to elegant, composable code in a variety of domains, such as: * Expression evaluation * Parsing * Concurrent programming (thanks to STM) Asynchronous I/O is tricky. However, Haskell currently does little to alleviate the complexity (at least for me). How can we structure network protocol APIs so that they stack well (e.g. only lock once, rather than locking each layer's connection state)? How can we deal with I/O errors without having to think about them at every turn? For now, how can I structure my application's communication API so it's less messy to use? Thanks, - Joey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] strict, lazy, non-strict, eager
Full beta-reduction is certainly not strict but also doesn't guarantee terminate even where it is possible (i.e. it might indefinitely unfold a value without making progress). I don't think there is much you can say about non-strictness and termination. Regards, Dave On Mon, Jan 9, 2012 at 3:01 AM, Jon Fairbairn jon.fairba...@cl.cam.ac.ukwrote: Perhaps what I should have said to be almost as succinct but this time accurate is “non-strict semantics requires that the evaluation strategy terminate if there is any evaluation strategy that terminates”? -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monad-control rant
Hello Mikhail, Thanks for continuing to be willing to participate in a lively discussion. :-) Excerpts from Mikhail Vorozhtsov's message of Mon Jan 16 08:17:57 -0500 2012: On 01/16/2012 02:15 PM, Edward Z. Yang wrote: Anders and I thought a little more about your example, and we first wanted to clarify which instance you thought was impossible to write. [snip] I was talking about the latter instance. Great, that's what I thought. And I don't want to lift IO control to AIO, I want an API that works with both IO and AIO. Yup! But we're going to have to define what me mean by API that works with both IO and AIO. The real problem with `MonadBaseControl IO AIO` is that the interpreter cuts actions into smaller pieces (at blocking operations) and then reschedules them in some order. [snip] I don't what you've said here is inconsistent with me claiming that AIO needs to limit IO control flow, but I must admit we've been working with an approximation of AIO because the full code hasn't been publishing anywhere. I don't see why functions like `throwIO`, `catch`, `finally`, `bracket`, etc should be tied to IO or monads that allow lifting of IO actions. The functions make perfect sense in `ErrorT SomeException Identity` and in many other monads that have nothing to do with IO, why restrict ourselves? I agree. (Later in the message I'll propose a new MonadCatchIO instance that drops the MonadIO superclass.) The first section was intended to make sure I understood what you were talking about. Based on your response, I *think* I interpreted your problem correctly. I don't think it makes too much sense have thing pick off a menu of Abort/Recover/Finally from a semantics perspective: It's easy to imagine monads that have an instance of one of the classes but not of the others I'd like to see some examples. I hypothesize that most of such monads are incoherent, semantically speaking. For example, what does it mean to have a monad that can recover exceptions, but for which you can't throw exceptions? Imagine a monad that disallows lifting of arbitrary IO actions, but can receive asynchronous events (which would probably be /implemented/ on top of asynchronous exceptions, but that's not important here) that behave like runtime-inserted left zeros. COMPUTATIONALLY_HEAVY_CODE `recover` \level → GIVE_AN_APPROXIMATION_INSTEAD(level) The vehicle of implementation here is kind of important. If they are implemented as asynchronous exceptions, I can in fact still throw in this universe: I just attempt to execute the equivalent of 'undefined :: m a'. Since asynchronous exceptions can always be thrown from pure code, I can /always/ do this, no matter how you lock down the types. Indeed, I think implementing this functionality on asynchronous exceptions is a good idea, because it lets you handle nonterminating pure code nicely, and allows you to bail out even when you're not doing monadic execution. But, for the sake of argument, so let's suppose that they're not done as asynchronous exceptions; essentially, you define some 'safe points' which have the possibility to raise exceptions. In this case, I claim there will never be a *technical* difficulty against implementing manually thrown exceptions; the concern here is you don't want the user to do that. With some sets of operations, this isn't a very strong injunction; if there is a deterministic set of operations that results in an error, the user can make a gadget which is semantically equivalent to a thrown exception. I don't think I can argue anything stronger here, so I concede the rest of the point. So, to summarize, such an interface (has recovery but not masking or throwing) always has a trivial throw instance unless you are not implementing it on top of asynchronous exceptions. Your example reminds me of what happens in pure code. In this context, we have the ability to throw errors and map over errors (although I'm not sure how people feel about that, semantically), but not to catch them or mask them. But I don't think we need another typeclass for that. There only a few options: - You have special primitives which throw exceptions, distinct from Haskell's IO exceptions. In that case, you've implemented your own homebrew exception system, and all you get is a 'Catch MyException' which is too specific for a client who is expecting to be able to catch SomeExceptions. - You execute arbitrary IO and allow those exceptions to be caught. But then I can implement Throw: I just embed an IO action that is throwing an exception. - You only execute a limited subset of IO, but when they throw exceptions they throw ordinary IO exceptions. In this case, the client doesn't have access to any scarce resources except the ones you provided, so there's no reason for him to even need this
[Haskell-cafe] Network.Browser and Network.TLS
Hello! I am interested in extending the Network.HTTP code in the HTTP package to support HTTPS via TLS. A clear candidate is to use the Network.TLS module in the TLS library (because its TLS logic is written in pure Haskell, rather than any of the FFI libraries like Network.Curl or the OpenSSL package). It's simple enough to provide an implementation of the Network.Stream.Stream typeclass around a TLSCtx, and this works for the Network.HTTP.Stream functions. However, I am interested in using the functionality in the Network.Browser module. This module uses the Network.HTTP.HandleStream interface, which is implemented directly on top of the Handle datatype and the Network.BufferType.BufferOp functions. HandleStreams seem to be for allowing the user to pull out an arbitrary data type out of an HTTP stream, not for doing any stream processing the way TLS does. As far as I can tell, the current typeclass system does not allow a TLSCtx to piggypack off of a HandleStream. My assumption is that this interface is used for speed so the user doesn't have to convert some canonical type into the type that he/she desires in client code. TLS, however, must use a specific type to decode the bytes that it pulls out of the stream. I don't think it's reasonable to try to modify the TLS library to decode bytes from an arbitrary type. Decoding necessarily needs byte-level access to its input (and therefore output) streams in a manner extremely similar to the functions that ByteString provides. Perhaps I'm wrong about this, but the conclusion I've reached is that it doesn't make sense for TLS to use an arbitrary typeclass because the interface it requires is so similar to the existing ByteString datatype. If an application wants a specific type out of a TLS stream, it must necessarily convert the type in software. Any speed that might be gained by pulling your native type out of a network connection will be dwarfed anyway by the cost of decryption. The Network.Stream functions allow this by using String type for all data transfers (which is counterintuitive for binary data transfers). An implementation of Network.Stream.Stream using TLS would convert TLS's output ByteString into a String (possibly by doing something like ((map (toEnum . fromIntegral)) . unpack) which doesn't make a whole lot of sense and is fairly wasteful). A client program might even convert it back to a ByteString, so the client program must have knowledge about how the bytes are packed into the String. Network.Browser only seems to have one function which isn't simply a state accessor/mutator: 'request'. This function gives the connection a type of HStream ty = HandleStream ty. As stated before, the HandleStream directly uses the Handle type. This means that, as far as I can tell, there is no way to fit TLS into the Network.Browser module as it stands because the types don't allow for it. Supporting TLS in Network.Browser would have to change the type of 'request' and therefore break every program out there which uses the Network.Browser module. It would be possible to create something like a 'requestHTTPS' function which returns a different type, but this is quite inelegant - there should be one function that inspects the scheme of the URI it is handed. I am left with the conclusion that it is impossible to support TLS in Network.Browser without breaking many Haskell programs. It is obviously possible to fork the HTTP library, but I'd like to improve the state of the existing libraries. Likewise, it is possible to create a new module that supports HTTPS but has different typed functions and lots of code duplication with Network.Browser, but that is quite inelegant. I suppose this is mostly directed at the maintainers of the HTTP and TLS libraries, Sigbjorn Finne and Vincent Hanquez, but I'd be greatful for your input on what I can do to contribute to the Haskell community regarding Network.Browser and Network.TLS. Perhaps I should just use the Network.HTTP.Enumerator module and not deal with Network.Browser? Maybe I'm going about this in entirely the wrong way. Thanks, Myles C. Maxfield ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] decoupling type classes
The typical example would be instance Eq a = Eq [a] where [] == [] = True (a : as) == (b : bs) = a == b as == bs _ == _ = False It can handle this case, although it doesn't handle it as a parametric instance. I suspect that we don't need the concept of parameter instances at all. We just searches for instances recursively at the call site: That seems like it could work, but typically, one would like termination guarantees for this search, to avoid the type-checker getting stuck... Good point. Currently I'm guessing that we need to keep a stack of the traced calls. If a recursive call needs an implicit parameter X which is matched by one of the functions in the stack, we back up from the stack and resolve X to the function found on stack. foo x = let overload bar (x:Int) = x + 1 in \() - bar x baz = in foo (1::Int) Even if we have only one definition of bar in the program, we should not resolve it to the definition of bar inside foo. Because that bar is not visible at the call site foo (1::int). We should report an error in this case. Think of bar as a typed dynamically scoped variable helps to justify this decision. So you're saying that any function that calls an overloaded function should always allow its own callers to provide this, even if a correct instance is in scope. Would that mean all instances have to be resolved from main? This also strikes me as strange, since I gather you would get something like length :: Monoid Int = [a] - Int, which would break if you happen to have a multiplicative monoid in scope at the call site? If you already have a correct instance in scope, then you should have no way defining another instance with the same name and type in the scope as the existing one. This is the case for Haskell. But it may be useful to allow nested definitions (using let) to shadow the existing instances in the outer scope of the overloaded call. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Network.Browser and Network.TLS
On Mon, Jan 16, 2012 at 6:28 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: I am interested in extending the Network.HTTP code in the HTTP package to support HTTPS via TLS. [snip] I am left with the conclusion that it is impossible to support TLS in Network.Browser without breaking many Haskell programs. It is obviously possible to fork the HTTP library, but I'd like to improve the state of the existing libraries. Likewise, it is possible to create a new module that supports HTTPS but has different typed functions and lots of code duplication with Network.Browser, but that is quite inelegant. If you need Network.Browser's functionality, it would be great if it could be ported to work with http-conduit. I wouldn't consider using HTTP on any production code. Perhaps I should just use the Network.HTTP.Enumerator module and not deal with Network.Browser? Maybe I'm going about this in entirely the wrong way. What are you trying to do? On most cases http-conduit has everything you need. Cheers! -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Summers of Code retrospective (updated for 2011)
On Sat, Dec 10, 2011 at 6:57 PM, Gwern Branwen gwe...@gmail.com wrote: The Wheel turns, and months come and pass, leaving blog posts that fade into 404s; a wind rose in Mountain View, whispering of the coming Winter... Tonight I sat down and finally looked into the 2011 SoCs to see how they turned out and judge them according to my whimsically arbitrary and subjective standards: http://www.gwern.net/Haskell%20Summer%20of%20Code#results-1 They turned out pretty much as I predicted - but then I *would* say that, wouldn't I? As I've said before. You clearly have a strong opinion about GSoC and care about the projects that are accepted. You should sign up as a mentor next year, even if it's only to review proposals and provide feedback. Especially if you think half of the projects are doomed each year. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to get Cabal to spit out a .a library suitable for linking into C/Objective-C
Did you figure out what you need to know? If not, I would suggest asking this same question but on StackOverflow (assuming you haven't already asked there). Jason On Mon, Dec 19, 2011 at 2:35 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Howdy, I'm trying to figure out how to get Cabal configured to compile and link my Haskell code such that the code can be part of C and/or Objective-C code such that all the Haskell dependencies are rolled into a .a file and can be linked by a normal C linker (e.g., ld). I've been through http://haskell.org/ghc/docs/6.12.2/html/users_guide/ffi-ghc.html#using-own-main and the associated linked, but I'm unable to find out the Cabal incantation to output a library that's linkable into my other code. Any pointers or examples would be greatly appreciated. Thanks, David -- Visi.Pro, Cloud Computing for the Rest of Us http://visi.pro Lift, the simply functional web framework http://liftweb.net Follow me: http://twitter.com/dpp Blog: http://goodstuff.im ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Network.Browser and Network.TLS
Felipe Almeida Lessa wrote: On Mon, Jan 16, 2012 at 6:28 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: I am interested in extending the Network.HTTP code in the HTTP package to support HTTPS via TLS. [snip] I am left with the conclusion that it is impossible to support TLS in Network.Browser without breaking many Haskell programs. It is obviously possible to fork the HTTP library, but I'd like to improve the state of the existing libraries. Likewise, it is possible to create a new module that supports HTTPS but has different typed functions and lots of code duplication with Network.Browser, but that is quite inelegant. If you need Network.Browser's functionality, it would be great if it could be ported to work with http-conduit. I wouldn't consider using HTTP on any production code. +1 Perhaps I should just use the Network.HTTP.Enumerator module and not deal with Network.Browser? Maybe I'm going about this in entirely the wrong way. What are you trying to do? On most cases http-conduit has everything you need. Specifically: http://hackage.haskell.org/packages/archive/http-conduit/latest/doc/html/Network-HTTP-Conduit.html Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Network.Browser and Network.TLS
On 01/16/2012 08:28 PM, Myles C. Maxfield wrote: Hello! [snip] Hi Myles, I'm going to echo Felipe and Erik's comments, and think you'ld have a better time porting Network.Browser on top of http-enumerator (now called http-conduit). Looking at it quickly, it doesn't seems too difficult to do, and could be a worthwhile things to have. http-conduit is more useful in general for real world applications than HTTP. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] fixity declaration in GHCi
Hello everyone, while I'm playing with fixity declaration in GHCi, I found a strange behavior. Can anyone explain this? Is this actually an expected behavior, or is it a glitch? $ ghci GHCi, version 7.0.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Prelude minus--(1) interactive:1:1: Not in scope: `minus' Prelude let minus x y = x-y; infixl 6 `minus`--(2) Prelude 10^5 `minus` 2--(3) 1000 Prelude let infixl 6 `minus`--(4) interactive:1:14: The fixity declaration for `minus' lacks an accompanying binding Prelude let subtract x y = x-y--(5) Prelude 10^5 `subtract` 2--(6) 1000 Prelude let f x y = x-y; infixl 6 `f` in 10^5 `f` 2--(7) 8 Prelude (1) suggests that `minus` is not defined here. in (2), I try to define `minus` with precedence level 6. However, (3) suggests that precedence level of `minus` is stronger than ^ . (4) suggests that you cannot redefine fixity here. (5)(6) is consistent with Haskell 98 report section 4.4.2; Any operator lacking a fixity declaration is assumed to be infixl 9. in (7), precedence level is set as expected. So, what is happening in (3)? Where did the fixity declaration in (2) went? Best, -- MURANUSHI Takayuki The Hakubi Center, Kyoto University : http://www.hakubi.kyoto-u.ac.jp/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
