Re: [Haskell-cafe] Contributing to http-conduit
Here is a patch regarding getRedirectedRequest. Comments are very welcome. --Myles C. Maxfield On Wed, Jan 25, 2012 at 10:21 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: I was planning on making the caller deal with keeping track of cookies between requests. My cookie idea only solves the problem of cookies persisting through a redirect chain - not between subsequent request chains. Do you think that Network.HTTP.Conduit should have a persistent cookie jar between caller's requests? I don't really think so. --Myles On Wed, Jan 25, 2012 at 9:28 PM, Michael Snoyman mich...@snoyman.comwrote: On Wed, Jan 25, 2012 at 8:18 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Alright, that's fine. I just wanted to be explicit about the interface we'd be providing. Taking the Request construction code out of 'http' and putting it into its own function should be a quick change - I'll have it to you soon. One possible wrench - The existing code copies some fields (like the proxy) from the original request. In order to keep this functionality, the signature would have to be: checkRedirect :: Request m - Response - Maybe (Request m) Is that okay with you? I think I'd also like to call the function something different, perhaps 'getRedirectedRequest'. Is that okay? I'll also add an example to the documentation about how a caller would get the redirection chain by re-implementing redirection (by using the example in your previous email). Sounds great. As for cookie handling - I think Network.Browser has a pretty elegant solution to this. They allow a CookieFilter which has type of URI - Cookie - IO Bool. Cookies are only put in the cookie jar if the function returns True. There is a default CookieFilter, which behaves as we would expect, but the user can override this function. That way, if you don't want to support cookies, you can just pass in (\ _ _ - return False). Also sounds good. If we're already expecting people that want specific functionality to re-implement the redirect-following code, this solution might be unnecessary. Do you think that such a concept would be beneficial for Network.HTTP.Conduit to implement? Yes, I can imagine that some people would want more fine-grained control of which cookies are accepted. Either way, I'll probably end up making a solution similar to your checkRedirect function that will just allow people to take SetCookies out of a Response and put Cookies into a Request. I'll probably also provide a default function which converts a SetCookie into a cookie by looking up the current time, inspecting the Request, etc. This will allow me to not have to change the type of Request or Response - the functions I'll be writing can deal with the raw Headers that are already in Requests and Responses. Modifying 'http' to use these functions will be straightforward. How does this sound to you? Sounds like a good plan to me. I'm not entirely certain how you're planning on implementing the cookie jar itself. In other words, if I make a request, have a cookie set, and then make another request later, where will the cookie be stored in the interim, and how will the second request know to use it? Michael getRedirectedRequest.patch Description: Binary data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Contributing to http-conduit
I'm a little worried about the use of `fromJust`, it will give users a very confusing error message, and the error might be trigged at the wrong point in the computation. I'd feel better if checkRedirect lived in either some Failure, an Either, or maybe even in IO itself. IO might make sense if we want to implement some cookie jar functionality in the future via mutable references. Michael On Thu, Jan 26, 2012 at 10:29 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Here is a patch regarding getRedirectedRequest. Comments are very welcome. --Myles C. Maxfield On Wed, Jan 25, 2012 at 10:21 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: I was planning on making the caller deal with keeping track of cookies between requests. My cookie idea only solves the problem of cookies persisting through a redirect chain - not between subsequent request chains. Do you think that Network.HTTP.Conduit should have a persistent cookie jar between caller's requests? I don't really think so. --Myles On Wed, Jan 25, 2012 at 9:28 PM, Michael Snoyman mich...@snoyman.com wrote: On Wed, Jan 25, 2012 at 8:18 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Alright, that's fine. I just wanted to be explicit about the interface we'd be providing. Taking the Request construction code out of 'http' and putting it into its own function should be a quick change - I'll have it to you soon. One possible wrench - The existing code copies some fields (like the proxy) from the original request. In order to keep this functionality, the signature would have to be: checkRedirect :: Request m - Response - Maybe (Request m) Is that okay with you? I think I'd also like to call the function something different, perhaps 'getRedirectedRequest'. Is that okay? I'll also add an example to the documentation about how a caller would get the redirection chain by re-implementing redirection (by using the example in your previous email). Sounds great. As for cookie handling - I think Network.Browser has a pretty elegant solution to this. They allow a CookieFilter which has type of URI - Cookie - IO Bool. Cookies are only put in the cookie jar if the function returns True. There is a default CookieFilter, which behaves as we would expect, but the user can override this function. That way, if you don't want to support cookies, you can just pass in (\ _ _ - return False). Also sounds good. If we're already expecting people that want specific functionality to re-implement the redirect-following code, this solution might be unnecessary. Do you think that such a concept would be beneficial for Network.HTTP.Conduit to implement? Yes, I can imagine that some people would want more fine-grained control of which cookies are accepted. Either way, I'll probably end up making a solution similar to your checkRedirect function that will just allow people to take SetCookies out of a Response and put Cookies into a Request. I'll probably also provide a default function which converts a SetCookie into a cookie by looking up the current time, inspecting the Request, etc. This will allow me to not have to change the type of Request or Response - the functions I'll be writing can deal with the raw Headers that are already in Requests and Responses. Modifying 'http' to use these functions will be straightforward. How does this sound to you? Sounds like a good plan to me. I'm not entirely certain how you're planning on implementing the cookie jar itself. In other words, if I make a request, have a cookie set, and then make another request later, where will the cookie be stored in the interim, and how will the second request know to use it? Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hierarchical tracing for debugging laziness
One day, I _really_ should learn all GHCI commands...
Thanks, Felipe ^^
2012/1/25 Felipe Almeida Lessa felipe.le...@gmail.com
On Wed, Jan 25, 2012 at 7:38 PM, Yves Parès yves.pa...@gmail.com wrote:
But I haven't found a way to tell GHCI to fully evaluate 'x' but _not_
print
its value.
Use the :force, Yves!
let {a = htrace a 12; b = htrace b 29; c = htrace c 10; d = htrace
d 90; x = htrace , (htrace + (a+b), htrace * (c*d)) }
:force x
,
+
a
b
*
c
d
x = (41,900)
Cheers! =)
--
Felipe.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghc-api Static Semantics?
Hi Thomas, By static semantics I mean use and bind locations for every name in the AST. For example: f x = let x = x + 1 in x Should parse as something like HsMatch (f (HsPat x (1,2) (1,2)) (HsBody (HsExp (HsLet (HsMatch (x (8,1) (8,1)) (HsExp (HsInfix (+) (1) (x) (12,1) (8,1)) (x (16,1) (8,1 I'm steering towards haskell-src-exts right now as the sheer complexity of the ghc-api is putting me off. I need something simple, as I can't be spending all my time learning the ghc-api and hacking it together to do what I want. It does look a bit of a mess. Just trying to do simple things like parsing a file and showing its output proved to be much more complicated than it really needed to be. Let me know if you decide to take on this project. We have decided to take it on. :) Chris. On 24 January 2012 10:35, Christopher Brown cm...@st-andrews.ac.uk wrote: Have you looked at ghc-syb-utils, which gives a neat way to print an AST? http://hackage.haskell.org/packages/archive/ghc-syb-utils/0.2.1.0/doc/html/GHC-SYB-Utils.html Yes I found that yesterday! Chris. -- JP Moresmau http://jpmoresmau.blogspot.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 -- Push the envelope. Watch it bend. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] LDTA 2012: call for participation
*** LDTA 2012 Call for Participation 12th International Workshop on Language Descriptions, Tools, and Applications http://ldta.info Tallinn, Estonia March 31 April 1, 2012 an ETAPS workshop *** You are cordially invited to LDTA'12. LDTA is an application and tool-oriented workshop focused on grammarware - software based on grammars in some form. Grammarware applications are typically language processing applications and traditional examples include parsers, program analyzers, optimizers and translators. -- REGISTRATION-- To register for LDTA'12, please follow the instructions at: http://www.etaps.org/2012/registration The early registration deadline is January 29, 2012. --HOTEL INFORMATION-- LDTA will be co-located with ETAPS. Please visit ETAPS's web site to get more information for the accomodation (http://www.etaps.org/2012/accommodation). Special rates and/or block bookings for ETAPS 2012 participants at a number of central hotels also expire Sunday, 29 January 2012. --PROGRAM-- The workshop will include an invited talk by Janis Voigtländer (University of Bonn, Germany) and the presentation of the following technical papers: - Sebastian Erdweg, Paolo G. Giarrusso and Tillmann Rendel. Language Composition Untangled - Johnni Winther. Improving Precision of Generated ASTs - Tobi Vollebregt, Lennart C. L. Kats and Eelco Visser. Declarative Specification of Template-Based Textual Editors - Marcos Viera, Doaitse Swierstra and Atze Dijkstra. Grammar Fragments Fly First-Class - Marcos Viera, Doaitse Swierstra and Arie Middelkoop. UUAG Meets AspectAG: How to make Attribute Grammars First-Class - Daniel Lincke and Sibylle Schupp. From HOT to COOL - Transforming Higher-Order Typed Languages to Concept-Constrained Object-Oriented Languages - Maartje De Jonge and Eelco Visser. A Language Generic Solution for Name Binding Preservation in Refactorings - Vadim Zaytsev. Notation-Parametric Grammar Recovery - Jean-Christophe Bach, Pierre-Etienne Moreau, Marc Pantel and Xavier Crégut. Models Transformations with Tom The workshop will also feature presentations devoted to a de-brief of the 2011 tool challenge, based on the paper currently being prepared by the challenge participants. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why were unfailable patterns removed and fail added to Monad?
On 2012-01-24 05:32, Michael Snoyman wrote: On Fri, Jan 20, 2012 at 6:52 AM, Michael Snoymanmich...@snoyman.com wrote: provide an extra warning flag (turned on by -Wall) that will warn when you match on a failable pattern. I've filed a feature request for this warning: http://hackage.haskell.org/trac/ghc/ticket/5813 Thanks! I wish the compiler could tell the difference between monads that handle failure nicely (e.g. List) and those that throw a runtime error (e.g. IO). Something's wrong -- I'm feeling nostalgic for MonadZero. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need advice: Haskell in Web Client
On Thu, Jan 19, 2012 at 1:37 AM, Dag Odenhall dag.odenh...@gmail.comwrote: On Tue, 2012-01-17 at 22:05 +0300, dokondr wrote: I prefer using Turing complete PL to program web client, like the one used in GWT (Java) or Cappuccino (Objective-J). http://cappuccino.org/learn/ In this case you /almost/ don't need to know HTML, CSS, DOM, Ajax, etc. to develop WebUI and good PL lets you concentrate on problem domain instead of bothering about browser support. It is a real pity that Haskell still has no such tools to generate Web GUI in Javascript. ((( Have you seen Chris Done's posts on the subject? http://chrisdone.com/tags/javascript.html Thanks for the link! (Never seen this before) Ideally, I would be happy to be able to write in Haskell a complete front-end / GUI, so it could be compiled to different back-ends: Javascript to run in the Browser and also a standalone app. In Python world this is already done with Pyjamas (http://pyjs.org/) - a Rich Internet Application (RIA) Development Platform for both Web and Desktop. Also from Pyjamas site: Pyjamas ... contains a Python-to-Javascript compiler, an AJAX framework and a Widget Set API. Pyjamas Desktop is the Desktop version of Pyjamas Pyjamas Desktop allows the exact same python web application source code to be executed as a standalone desktop application (running under Python) instead of being stuck in a Web browser. Architecture diagram http://pyjs.org/wiki/pyjamasandpyjamasdesktop/ I wonder if somebody works on similar Haskell Rich Internet Application (RIA) Development Platform ? Any ideas, comments on implementation of such system in Haskell? What existing Haskell GUI libraries can be used for a desktop GUI, etc.? Thanks! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghc-api Static Semantics?
On 26 January 2012 09:24, Christopher Brown cm...@st-andrews.ac.uk wrote: Hi Thomas, By static semantics I mean use and bind locations for every name in the AST. Right, that's what the renamer does in GHC. The GHC AST is parameterised over the type of identifiers used. The three different identifier types are: - RdrName: is the name as it occurred in source code. This is the output of the parser. - Name: is basically RdrName + unique ID, so you can distinguish two xs bound at different locations (this is what you want). This is the output of the renamer. - Id: is Name + Type information and consequently is the output of the type checker. Diagram: String --parser-- HsModule RdrName --renamer-- HsModule Name --type-checker-- HsBinds Id Since you can't hook in-between renamer and type checker, it's perhaps more accurately depicted as: String --parser-- HsModule RdrName --renamer+type-checker-- (HsModule Name, HsBinds Id) The main reasons why it's tricky to use the GHC API are: 1. You need to setup the environment of packages etc. E.g., the renamer needs to look up imported modules to correctly resolve imported names (or give a error). 2. The second is that the current API is not designed for external use. As I mentioned, you cannot run renamer and typechecker independently, there are dozens of invariants, there are environments being updated by the various phases, etc. For example, if you want to generate code it's probably best to either generate HsModure RdrName or perhaps the Template Haskell API (never tried that path). I'm steering towards haskell-src-exts right now as the sheer complexity of the ghc-api is putting me off. I need something simple, as I can't be spending all my time learning the ghc-api and hacking it together to do what I want. It does look a bit of a mess. Just trying to do simple things like parsing a file and showing its output proved to be much more complicated than it really needed to be We have decided to take it on. :) Could you clarify that? Are you doing everything in haskell-src-exts or are you using the GHC API and translate the result into haskell-src-exts? The former might be easier to implement, the latter could later be extended to give you type info as well (without the need to implement a whole type checker that most likely will bit rot compared to GHC sooner or later). / Thomas -- Push the envelope. Watch it bend. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghc-api Static Semantics?
Thomas, thank you for that explanation about the different type of identifiers in the different phases of analysis. I've never seen that information so clearly laid out before, can it be added to the wikis (in http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/API or http://www.haskell.org/haskellwiki/GHC/As_a_library maybe)? I think it would be helpful to all people that want to dive into the GHC API. On a side note, I'm going to do something very similar in my BuildWrapper project (which is now the backend of the EclipseFP IDE plugins): instead of going back to the API every time the user requests to know the type of something in the AST, I'm thinking of sending the whole typed AST to the Java code. Maybe that's something Christopher could use. Both the BuildWrapper code and Thomas's scion code are available on GitHub, as they provide examples on how to use the GHC API. JP On Thu, Jan 26, 2012 at 2:31 PM, Thomas Schilling nomin...@googlemail.com wrote: On 26 January 2012 09:24, Christopher Brown cm...@st-andrews.ac.uk wrote: Hi Thomas, By static semantics I mean use and bind locations for every name in the AST. Right, that's what the renamer does in GHC. The GHC AST is parameterised over the type of identifiers used. The three different identifier types are: RdrName: is the name as it occurred in source code. This is the output of the parser. Name: is basically RdrName + unique ID, so you can distinguish two xs bound at different locations (this is what you want). This is the output of the renamer. Id: is Name + Type information and consequently is the output of the type checker. Diagram: String --parser-- HsModule RdrName --renamer-- HsModule Name --type-checker-- HsBinds Id Since you can't hook in-between renamer and type checker, it's perhaps more accurately depicted as: String --parser-- HsModule RdrName --renamer+type-checker-- (HsModule Name, HsBinds Id) The main reasons why it's tricky to use the GHC API are: You need to setup the environment of packages etc. E.g., the renamer needs to look up imported modules to correctly resolve imported names (or give a error). The second is that the current API is not designed for external use. As I mentioned, you cannot run renamer and typechecker independently, there are dozens of invariants, there are environments being updated by the various phases, etc. For example, if you want to generate code it's probably best to either generate HsModure RdrName or perhaps the Template Haskell API (never tried that path). / Thomas -- Push the envelope. Watch it bend. -- JP Moresmau http://jpmoresmau.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need advice: Haskell in Web Client
On 01/26/2012 11:16 AM, dokondr wrote: On Thu, Jan 19, 2012 at 1:37 AM, Dag Odenhalldag.odenh...@gmail.comwrote: On Tue, 2012-01-17 at 22:05 +0300, dokondr wrote: I prefer using Turing complete PL to program web client, like the one used in GWT (Java) or Cappuccino (Objective-J). http://cappuccino.org/learn/ In this case you /almost/ don't need to know HTML, CSS, DOM, Ajax, etc. to develop WebUI and good PL lets you concentrate on problem domain instead of bothering about browser support. It is a real pity that Haskell still has no such tools to generate Web GUI in Javascript. ((( Have you seen Chris Done's posts on the subject? http://chrisdone.com/tags/javascript.html Thanks for the link! (Never seen this before) Ideally, I would be happy to be able to write in Haskell a complete front-end / GUI, so it could be compiled to different back-ends: Javascript to run in the Browser and also a standalone app. In Python world this is already done with Pyjamas (http://pyjs.org/) - a Rich Internet Application (RIA) Development Platform for both Web and Desktop. Also from Pyjamas site: Pyjamas ... contains a Python-to-Javascript compiler, an AJAX framework and a Widget Set API. Pyjamas Desktop is the Desktop version of Pyjamas Pyjamas Desktop allows the exact same python web application source code to be executed as a standalone desktop application (running under Python) instead of being stuck in a Web browser. Architecture diagram http://pyjs.org/wiki/pyjamasandpyjamasdesktop/ I wonder if somebody works on similar Haskell Rich Internet Application (RIA) Development Platform ? Any ideas, comments on implementation of such system in Haskell? What existing Haskell GUI libraries can be used for a desktop GUI, etc.? Well, it's basically just proof-of-concept at the moment, and it's not really usable for real applications at the moment, but there is http://hackage.haskell.org/package/dingo-core-0.1.0 http://hackage.haskell.org/package/dingo-widgets-0.1.0 http://hackage.haskell.org/package/dingo-example-0.1.0 The basic client-server communication, server-side state handling, etc. is there, but it's missing a couple of things before it could be used for real apps: There's no real security, and there are *very* few widgets. The few widgets that exist at the moment are also probably lacking a few operations. On the plus side, it's should be pretty easy to create new widgets. You can get a feel for how the thing looks from an application programmer's perspective by looking at the source for the example. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghc-api Static Semantics?
On 26 January 2012 16:33, JP Moresmau jpmores...@gmail.com wrote: Thomas, thank you for that explanation about the different type of identifiers in the different phases of analysis. I've never seen that information so clearly laid out before, can it be added to the wikis (in http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/API or http://www.haskell.org/haskellwiki/GHC/As_a_library maybe)? I think it would be helpful to all people that want to dive into the GHC API. Will do. On a side note, I'm going to do something very similar in my BuildWrapper project (which is now the backend of the EclipseFP IDE plugins): instead of going back to the API every time the user requests to know the type of something in the AST, I'm thinking of sending the whole typed AST to the Java code. Maybe that's something Christopher could use. Both the BuildWrapper code and Thomas's scion code are available on GitHub, as they provide examples on how to use the GHC API. I really don't think you want to do much work on the front-end as that will just need to be duplicated for each front-end. That was the whole point of building Scion in the first place. I understand, of course, that Scion is not useful enough at this time. Well, I currently don't have much time to work on Scion, but the plan is as follows: - Scion becomes a multi-process architecture. It has to be since it's not safe to run multiple GHC sessions inside the same process. Even if that were possible, you wouldn't be able to, say, have a profiling compiler and a release compiler in the same process due to how static flags work. Separate processes have the additional advantage that you can kill them if they use too much memory (e.g., because you can't unload loaded interfaces). - Scion will be based on Shake and GHC will mostly be used in one-shot mode (i.e., not --make). This makes it easier to handle preprocessed files. It also allows us to generate and update meta-information on demand. I.e., instead of parsing and typechecking a file and then caching the result for the current file, Scion will simply generate meta information whenever it (re-)compiles a source file and writes that meta information to a file. Querying or caching that meta information then is completely orthogonal to generating it. The most basic meta information would be a type-annotated version of the compiled AST (possibly + warnings and errors from the last time it was compiled). Any other meta information can then be generated from that. - The GHCi debugger probably needs to be treated specially. There also should be automatic detection of files that aren't supported by the bytecode compiler (e.g., those using UnboxedTuples) and force compilation to machine code for those. - The front-end protocol should be specified somewhere. I'm thinking about using protobuf specifications and then use ways to generate custom formats from that (e.g., JSON, Lisp S-Expressions, XML?). And if the frontend supports protocol buffers, then it can use that and be fast. That also means that all serialisation code can be auto-generated. I won't have time to work on this before the ICFP deadline (and only very little afterwards), but Scion is not dead (just hibernating). JP On Thu, Jan 26, 2012 at 2:31 PM, Thomas Schilling nomin...@googlemail.com wrote: On 26 January 2012 09:24, Christopher Brown cm...@st-andrews.ac.uk wrote: Hi Thomas, By static semantics I mean use and bind locations for every name in the AST. Right, that's what the renamer does in GHC. The GHC AST is parameterised over the type of identifiers used. The three different identifier types are: RdrName: is the name as it occurred in source code. This is the output of the parser. Name: is basically RdrName + unique ID, so you can distinguish two xs bound at different locations (this is what you want). This is the output of the renamer. Id: is Name + Type information and consequently is the output of the type checker. Diagram: String --parser-- HsModule RdrName --renamer-- HsModule Name --type-checker-- HsBinds Id Since you can't hook in-between renamer and type checker, it's perhaps more accurately depicted as: String --parser-- HsModule RdrName --renamer+type-checker-- (HsModule Name, HsBinds Id) The main reasons why it's tricky to use the GHC API are: You need to setup the environment of packages etc. E.g., the renamer needs to look up imported modules to correctly resolve imported names (or give a error). The second is that the current API is not designed for external use. As I mentioned, you cannot run renamer and typechecker independently, there are dozens of invariants, there are environments being updated by the various phases, etc. For example, if you want to generate code it's probably best to either generate HsModure RdrName or perhaps the Template Haskell API (never
Re: [Haskell-cafe] Natural Transformations and fmap
I tried the free theorem generator ( http://www-ps.iai.uni-bonn.de/cgi-bin/free-theorems-webui.cgi) and it wouldn't let me use generic functors, but playing with [] and Maybe leads me to believe that the free theorem for :- is forall f :: m :- n, forall g :: a - b, g strict and total fmap g . f = f . fmap g This implies that the monad laws don't necessarily hold in situations like \m - m = const Nothing, which seems wrong to me. The counterexamples ( http://www-ps.iai.uni-bonn.de/cgi-bin/exfind.cgi), however, all rely on odd natural transformations like (\_ - Just undefined). My guess is that there is a side condition we can put on f that is implied by the monoid laws which doesn't require g to be strict or total. -- ryan On Mon, Jan 23, 2012 at 10:23 PM, Brent Yorgey byor...@seas.upenn.eduwrote: On Mon, Jan 23, 2012 at 09:06:52PM -0800, Ryan Ingram wrote: On Mon, Jan 23, 2012 at 8:05 PM, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: On Tuesday 24 January 2012, 04:39:03, Ryan Ingram wrote: At the end of that paste, I prove the three Haskell monad laws from the functor laws and monoid-ish versions of the monad laws, but my proofs all rely on a property of natural transformations that I'm not sure how to prove; given type m :- n = (forall x. m x - n x) class Functor f where fmap :: forall a b. (a - b) - f a - f b -- Functor identity law: fmap id = id -- Functor composition law fmap (f . g) = fmap f . fmap g Given Functors m and n, natural transformation f :: m :- n, and g :: a - b, how can I prove (f . fmap_m g) = (fmap_n g . f)? Unless I'm utterly confused, that's (part of) the definition of a natural transformation (for non-category-theorists). Alright, let's pretend I know nothing about natural transformations and just have the type declaration type m :- n = (forall x. m x - n x) And I have f :: M :- N g :: A - B instance Functor M -- with proofs of functor laws instance Functor N -- with proofs of functor laws How can I prove fmap g. f :: M A - N B = f . fmap g :: M A - N B I assume I need to make some sort of appeal to the parametricity of M :- N. This is in fact precisely the free theorem you get from the parametricity of f. Parametricity means that f must act uniformly for all x -- which is an intuitive way of saying that f really is a natural transformation. -Brent ___ 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
[Haskell-cafe] [ANNOUNCE] biostockholm 0.2
Hello! I'm pleased to announce the second major release of the biostockholm library! This library allows you to parse and render files in the Stockholm 1.0 format, which is used by Pfam, Rfam, Infernal and others for holding information about families of proteins or non-coding RNAs. http://hackage.haskell.org/package/biostockholm Despite this low increase in number from 0.1 to 0.2, this is actually a big rewrite of the library. Now we have: - An streaming interface similar to what SAX parsers provide. This allows you to consume Stockholm files using constant memory (80k in a simple case). - More test cases. It's able to consume its own pretty printed version of Rfam through the document interface, and is also capable of reading the full Rfam stockholm file (which has some huge families) through the streaming interface. - QuickCheck properties. Now we have three different QuickCheck properties covering almost everything. These have helped uncover some tricky bugs that were never found before. However, two of these three properties still don't pass, but I consider the failing examples that I've investigated just corner cases. Unfortunately, Stockholm lacks a formal specification. - Conduit interface. Besides a lazy I/O version, now there's a conduit interface. - Code much easier to read and reason about. - Fast enough: the streaming interface achieves 12 MiB/s for parsing, which is pretty nice considering that there are some known overheads on its implementation. For the tasks that biostockholm 0.1 already handled, biostockholm 0.2 tends to be slightly slower. However, biostockholm 0.2 is able to handle some previously impossible cases where an streaming solution is required. Cheers! -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Wow you have to check this out Haskell
Can we please have something done about this spam that's been happening semi-regularly here? On 26 January 2012 03:13, R J rj248...@hotmail.com wrote: hello Haskell the holidays are coming up soon and I think this can help http://www.news13open.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Weekly News: Issue 212
Welcome to issue 212 of the HWN, a newsletter covering developments in the Haskell community. This issue covers top Haskell stories from around the web found between January 11 to 21, 2012. You can find the HTML version at: http://contemplatecode.blogspot.com/2012/01/haskell-weekly-news-issue-212.html Quotes of the Week * shachaf: Haskell's type system is the perfect mix of useless and stupid. * roconnor: gez, you write one paper explaining how a lens is really a higher order monoidal natural transformation, and suddenly everyone thinks you are an expert on lenses. * roconnor: a lens is a monoidal natural transformation between higher-order coalgebra functors, what's the problem? * Enigmagic: we use the 'rsync' deploy model * cmccann: someone should implement a dependently-typed unsafeCoerce in Agda, you'd have to provide a proof that the coercion is invalid * ghc: Couldn't match type `No' with `Yes' Top Reddit Stories * Idris - A language with dependent types Domain: idris-lang.org, Score: 43, Comments: 30 On Reddit: [1] http://goo.gl/pZdKX Original: [2] http://goo.gl/MxXKx * Purely Functional, Declarative Game Logic Using Reactive Programming Domain: github.com, Score: 38, Comments: 17 On Reddit: [3] http://goo.gl/ByPJj Original: [4] http://goo.gl/1PYa4 * A guided tour through the bytestring library Domain: meiersi.github.com, Score: 32, Comments: 10 On Reddit: [5] http://goo.gl/0YUQ2 Original: [6] http://goo.gl/A2u2S * Comprehensions Domain: patternsinfp.wordpress.com, Score: 26, Comments: 7 On Reddit: [7] http://goo.gl/9Zv3F Original: [8] http://goo.gl/SNA14 * Thinking of writing a tutorial series on FP and Haskell. Here's a demo. Domain: codingtales.com, Score: 24, Comments: 9 On Reddit: [9] http://goo.gl/eU99Y Original: [10] http://goo.gl/1efUI * UHC compiles Haskell to JavaScript. Web game using Haskell for Ludum Dare? Domain: chrisdone.com, Score: 23, Comments: 4 On Reddit: [11] http://goo.gl/og088 Original: [12] http://goo.gl/8Op3M * Warp Conduits Released! Domain: yesodweb.com, Score: 22, Comments: 3 On Reddit: [13] http://goo.gl/zpHnZ Original: [14] http://goo.gl/5Vl3w * Why are guards in the list comprehension faster than in the do-notation? Domain: self.haskell, Score: 19, Comments: 22 On Reddit: [15] http://goo.gl/1T8Kk Original: [16] http://goo.gl/1T8Kk * Hac Boston Domain: self.haskell, Score: 19, Comments: 7 On Reddit: [17] http://goo.gl/xWWZF Original: [18] http://goo.gl/xWWZF * Easy steps to install gtk and use all its features on OS X lion Domain: gist.github.com, Score: 16, Comments: 10 On Reddit: [19] http://goo.gl/Teh6P Original: [20] http://goo.gl/Su6Y1 Top StackOverflow Questions * What is this haskell syntax? votes: 19, answers: 1 Read on SO: [21] http://goo.gl/JCYg0 * Why is the type of this function (a - a) - a? votes: 18, answers: 4 Read on SO: [22] http://goo.gl/BTr8e * `Integer` vs `Int64` vs `Word64` votes: 13, answers: 1 Read on SO: [23] http://goo.gl/Pc2CX * Did I just write a continuation? votes: 12, answers: 1 Read on SO: [24] http://goo.gl/aXnTw * How lazy is Haskell's `++`? votes: 12, answers: 3 Read on SO: [25] http://goo.gl/GxPxC * Can Haskell be used to write shell scripts? votes: 12, answers: 4 Read on SO: [26] http://goo.gl/u3Qke * Why does this Haskell code compile? votes: 12, answers: 2 Read on SO: [27] http://goo.gl/yz6VB * Any nice tools for untying knots in Haskell? votes: 11, answers: 4 Read on SO: [28] http://goo.gl/YGNeq * Two-dimensional zipper votes: 10, answers: 2 Read on SO: [29] http://goo.gl/37E9J * the way merge-sort faster than insertion-sort puzzles me votes: 10, answers: 2 Read on SO: [30] http://goo.gl/mkmdc * Haskell function that takes a type and a value and checks if value has that type votes: 10, answers: 1 Read on SO: [31] http://goo.gl/tJO81 Until next time, Daniel Santa Cruz References 1. http://idris-lang.org/ 2. http://www.reddit.com/r/haskell/comments/ol90m/idris_a_language_with_dependent_types/ 3. https://github.com/leonidas/codeblog/blob/master/2012/2012-01-17-declarative-game-logic-afrp.md 4. http://www.reddit.com/r/haskell/comments/ol7vm/purely_functional_declarative_game_logic_using/ 5. http://meiersi.github.com/HaskellerZ/meetups/2012%2001%2019%20-%20The%20bytestring%20library/slides.html 6. http://www.reddit.com/r/haskell/comments/oqjhy/a_guided_tour_through_the_bytestring_library/ 7. http://patternsinfp.wordpress.com/2012/01/19/comprehensions/ 8. http://www.reddit.com/r/haskell/comments/on8a6/comprehensions/ 9. http://codingtales.com/2012/01/16/understanding-foldl-using-foldr-from-real-world-haskell/ 10.
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
Steve Horne sh006d3592 at blueyonder.co.uk writes: There's a proposal at the moment to add support for TDNR to Haskell - to leverage the power of the dot (e.g. for intellisense).http://hackage.haskell.org/trac/haskell- prime/wiki/TypeDirectedNameResolution I approve of the goal, ... Steve, I think that proposal has been rather superseeded by http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields, which draws on TDNR. But SORF is best seen as an evolving design space, with precise details yet to be clarified/agreed. I've put my own variation into the ring: http://www.haskell.org/pipermail/glasgow-haskell-users/2011- December/021298.html -- which seems to have fallen into a black hole :-( One of the aspects of TDNR that wasn't so popular was that its type-directed resolution was very similar to instance resolution, but subtly and confusingly different. I guess we have to be very careful about the dot. It seems to be in a very 'crowded' syntax space, so if we implement the wrong way, we could end up shutting the door with the keys left inside. SPJ's observations about how the dot works in other languages are all good points. He's arguing that the dot should behave in a familiar way. I'm most used to it in SQL as table.column, but I guess for most programmers it's object.method. Haskell is already encumbered by Module.name, and g . f (function composition with spaces round the dot). I like the part in OverloadedRecordFields (and TDNR) re user-defined 'virtual' fields. (fullName being a concatenation of the datatype fields firstName and lastName, area being a calculation over a Shape datatype.) But the point about those being virtual is that they're not first-class fields: you can't update through them. SPJ got 'stuck' at that point. My proposal was that restricting the dot to field selection wasted too much of the design space. Instead dot should be merely syntactic sugar for reverse function application. That is: whatever.funcmethod == (funcmethod whatever) (Note no spaces around the dot. This is syntactically distinct from qualified names because the name to the left of the dot begins lower-case.) Then funcmethod can be a 'real' field selector, or a virtual field or a class method or some other function completely. So to get to name resolution: since dot is (reverse) function application, we can use all the usual Haskell type inference/instance selection 'for free'. Either/both `whatever' and `funcmethod' could be arguments passed through from a distant call, which turned out to be a record type and field selector (not recognisable as such from its name). So we'd get polymorphic record and field selection 'for free'. I'd also like to be able to mix the dot with qualified names: A.b.(C.D.e.f).G.h == (G.h ((f C.D.e) A.b)) The syntax rule is: an upper-case name to the left of the dot means this is a qualified name, and binds most tightly. lower-case to the left means reverse- function applic. Of course you can use parentheses to group differently. (Re a one-sided dot I have no intuitions. TDNR includes some options for partial application/sections, SORF some more. They seem to me what Wirth would call 'rococo'. If dot is to be merely function application, it hardly seems worth worrying about.) How do we get field names to be suitable funcmethods for dot applying to records? And how do we support field update? == Subjects for a different post. There's also an elephant in the room I haven't talked about: TDNR started with what happens inside an IDE when you type `x.' and all the possible methods (or fields) for x pop up. This follows the philosophy in OO of focus on the object - look for the action. (Same thinking as right-click in GUI's. Contrast old-style 'green screen' applications where you went down a menu tree first (action), then looked for your object.) If the dot is merely function application, then what follows the dot could be 'anything' (including very generic functions like show or return). I plain don't know if IDE's can be smart enough to spot that what's to the left of the dot is a datatype and offer its fields, or get from its type to its instances to their methods. (Actually, under my proposal, datatype to fields is exactly datatype to Has instance.) (How) could it tell what are more-specific or more- generic methods? My basic idea is stolen from Bertrand Meyer (Object-Oriented Software Construction, second edition). Basically, a class *is* both a module and a type. ... 1) Are you sure that C++ classes/instances/methods are comparable enough to Haskell's? This is a very confusing area of terminology for object-oriented cp. functional languages. 2) Have you looked at GHC 7.4.1 innovations around classes-as-types and Constraint kinds? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org
Re: [Haskell-cafe] Natural Transformations and fmap
On 1/23/12 10:39 PM, Ryan Ingram wrote:
type m :- n = (forall x. m x - n x)
class Functor f where fmap :: forall a b. (a - b) - f a - f b
-- Functor identity law: fmap id = id
-- Functor composition law fmap (f . g) = fmap f . fmap g
Given Functors m and n, natural transformation f :: m :- n, and g :: a -
b, how can I prove (f . fmap_m g) = (fmap_n g . f)?
That is the defining property of natural transformations. To prove it
for polymorphic functions in Haskell you'll probably want to leverage
parametricity.
I assume you don't know category theory, based on other emails in this
thread. But the definition of a natural transformation is that it is a
family of morphisms/functions { f_X :: M X - N X | X an object/type }
such that for all g :: a - b we have that f_b . fmap_m g == fmap_n g . f_a
Thus, you can in principle define plenty of natural transformations
which do not have the type f :: forall X. M X - N X. The only
requirement is that the family of morphisms obeys that equation. It's
nice however that if a function has that type, then it is guaranteed to
satisfy the equation (so long as it doesn't break the rules by playing
with strictness or other things that make it so Hask isn't actually a
category).
--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
