Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
+1, better cabal support for UHC's JS backend would be a big win. Daniel 2012/3/11 Jurriën Stutterheim j.stutterh...@me.com: While I might be a bit biased (I spent a good deal of time working on improving the UHC JS backend), I think there are a lot of opportunities to get Haskell as a client-side language via the UHC, as Heinrich suggested. Alessandro Vermeulen recently wrote an entire front-end application using the UHC JS backend, so we know that it's capable of producing working front-end applications. See also[1]. Currently, however, it is still a bit of a pain to compile larger UHC JS projects, since Cabal support for UHC's different backends is limited. This could be one potential goal for your GSoC project: make it possible to type `cabal configure cabal build` and find a complete JS application in your dist folder. This would go a long way to make the UHC JS backend more usable and as a result, make Haskell a practical language to use for client-side programming. In solving this problem, you will have to think about how to deal with external Haskell libraries (UHC compiles JS from its internal core representation, so storing pre-compiled object files won't work in this case) and perhaps external JS libraries as well. You would also need to modify Cabal so that it becomes possible to select a specific UHC backend in your cabal files. Ideally, you will only need one cabal file for an entire web application; for both the front-end and backend. I think this would make a nice GSoC project. The scope of the above should be about right, but if you would be done way ahead of time, there are plenty of relevant related things you could work on (e.g., a UHC JS-specific Haskell Platform-like package). If this sounds interesting to you, let me know and I can send you some more detailed information about the UHC JS backend. As for mentoring, I might be able to help out there, but since the above project would revolve more around Cabal and not so much around the UHC internals, there might be more suitable mentors out there. Jurriën [1] http://uu-computerscience.github.com/uhc-js/ On 8 Mar 2012, at 14:58, Heinrich Apfelmus wrote: Chris Smith wrote: My first impression on this is that it seems a little vague, but possibly promising. My impression is also that this project proposal is rather vague. The general goal Haskell as client-side language for websites is clear and worthwhile, but I can't tell from the proposal whether the project will succeed or not, or, more importantly, *what* it will succeed at. The way I see it is that a successful GSoC proposal has to embody four key points: 1. One specific goal - I want to compile Haskell to JS via UHC's backend 2. in a larger context - as a step towards Haskell as a client-side language for websites. 3. that is accompanied by a successful example - To demonstrate that this works, I will write a small Asteroids game with HTML5 and Haskell 4. and that others can build upon - Moreover, I want to make it really easy for others to use the Haskell-JS compilation from cabal. The last point is extremely important: you don't want to build a hobbled prototype that languishes in a dark corner of github, you want to build a great software that changes the world by solving an important problem and making this solution really easy to use! Alejandro, your proposal mentions several different specific goals, each of which can be the basis for a successful GSoC project: * Make UHC's Haskell-JS compilation easy to use. * Design combinators for DOM manipulation in functional style, f.i. zippers. Note that this goal does *not* involve running Haskell on the client-side, the focus is solely on the design of combinators. This means that you'd have to use another example, for instance XML parsing. Of course, the idea is that this can be reused when someone else manages to run Haskell on the client. * Design combinators for remote procedure calling via HTTP/AJAX. Again, there is no Haskell running in the browser, the showcase would be two Haskell processes that communicate with each other via HTTP/AJAX. Each of these goals is a tangible improvement on the status quo and specific enough to be completed in a single GSoC project. Of course, the one specific goal is not supposed to be a limit, it is meant to be a foundation. If there is time remaining, the student is free to work on whatever he dreams of. By all means, don't hesitate to reach for the sky, but help us climb to the tree top first. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.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
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
Jurriën Stutterheim wrote: Currently, however, it is still a bit of a pain to compile larger UHC JS projects, since Cabal support for UHC's different backends is limited. This could be one potential goal for your GSoC project: make it possible to type `cabal configure cabal build` and find a complete JS application in your dist folder. [..] I think this would make a nice GSoC project. The scope of the above should be about right, but if you would be done way ahead of time, there are plenty of relevant related things you could work on (e.g., a UHC JS-specific Haskell Platform-like package). If this sounds interesting to you, let me know and I can send you some more detailed information about the UHC JS backend.. As for mentoring, I might be able to help out there, but since the above project would revolve more around Cabal and not so much around the UHC internals, there might be more suitable mentors out there. This sounds like a great GSoC project to me. Maybe you can add it to the list of project suggestions, Jurriën? http://hackage.haskell.org/trac/summer-of-code/report/1 Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
That sound like a really cool project. Where could I get more information about what could I do? You mention about contacting but I think it's better to keep the discussion open for everybody. Alejandro 2012/3/11 Jurriën Stutterheim j.stutterh...@me.com While I might be a bit biased (I spent a good deal of time working on improving the UHC JS backend), I think there are a lot of opportunities to get Haskell as a client-side language via the UHC, as Heinrich suggested. Alessandro Vermeulen recently wrote an entire front-end application using the UHC JS backend, so we know that it's capable of producing working front-end applications. See also[1]. Currently, however, it is still a bit of a pain to compile larger UHC JS projects, since Cabal support for UHC's different backends is limited. This could be one potential goal for your GSoC project: make it possible to type `cabal configure cabal build` and find a complete JS application in your dist folder. This would go a long way to make the UHC JS backend more usable and as a result, make Haskell a practical language to use for client-side programming. In solving this problem, you will have to think about how to deal with external Haskell libraries (UHC compiles JS from its internal core representation, so storing pre-compiled object files won't work in this case) and perhaps external JS libraries as well. You would also need to modify Cabal so that it becomes possible to select a specific UHC backend in your cabal files. Ideally, you will only need one cabal file for an entire web application; for both the front-end and backend. I think this would make a nice GSoC project. The scope of the above should be about right, but if you would be done way ahead of time, there are plenty of relevant related things you could work on (e.g., a UHC JS-specific Haskell Platform-like package). If this sounds interesting to you, let me know and I can send you some more detailed information about the UHC JS backend. As for mentoring, I might be able to help out there, but since the above project would revolve more around Cabal and not so much around the UHC internals, there might be more suitable mentors out there. Jurriën [1] http://uu-computerscience.github.com/uhc-js/ On 8 Mar 2012, at 14:58, Heinrich Apfelmus wrote: Chris Smith wrote: My first impression on this is that it seems a little vague, but possibly promising. My impression is also that this project proposal is rather vague. The general goal Haskell as client-side language for websites is clear and worthwhile, but I can't tell from the proposal whether the project will succeed or not, or, more importantly, *what* it will succeed at. The way I see it is that a successful GSoC proposal has to embody four key points: 1. One specific goal - I want to compile Haskell to JS via UHC's backend 2. in a larger context - as a step towards Haskell as a client-side language for websites. 3. that is accompanied by a successful example - To demonstrate that this works, I will write a small Asteroids game with HTML5 and Haskell 4. and that others can build upon - Moreover, I want to make it really easy for others to use the Haskell-JS compilation from cabal. The last point is extremely important: you don't want to build a hobbled prototype that languishes in a dark corner of github, you want to build a great software that changes the world by solving an important problem and making this solution really easy to use! Alejandro, your proposal mentions several different specific goals, each of which can be the basis for a successful GSoC project: * Make UHC's Haskell-JS compilation easy to use. * Design combinators for DOM manipulation in functional style, f.i. zippers. Note that this goal does *not* involve running Haskell on the client-side, the focus is solely on the design of combinators. This means that you'd have to use another example, for instance XML parsing. Of course, the idea is that this can be reused when someone else manages to run Haskell on the client. * Design combinators for remote procedure calling via HTTP/AJAX. Again, there is no Haskell running in the browser, the showcase would be two Haskell processes that communicate with each other via HTTP/AJAX. Each of these goals is a tangible improvement on the status quo and specific enough to be completed in a single GSoC project. Of course, the one specific goal is not supposed to be a limit, it is meant to be a foundation. If there is time remaining, the student is free to work on whatever he dreams of. By all means, don't hesitate to reach for the sky, but help us climb to the tree top first. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell platform - mac lion - installation error
Once the Mac Haskell Platform installer is updated, it should no longer be needed to install Xcode. Then it should be enough to install the Command Line Tools package from https://developer.apple.com/downloads/ which is just a 171Mb download instead of the 1.85Gb for the whole Xcode toolset. On Mar 11, 2012, at 4:49 AM, Brandon Allbery wrote: On Sat, Mar 10, 2012 at 06:57, S D Swierstra doai...@uu.nl wrote: 1) Check whether you have a /Developer directory, and if not 2) look in your Applications folder to see whether you have program called Install XCode and if so run that Xcode 4.3.x does not use /Developer. The new path is /Applications/Xcode.app/Resources/Developer, but it has been rearranged (in particular, the SDKs have been moved, but there are other rearrangements as well) such that simply making a symlink will not work. (Xcode 4.3 also no longer has Install Xcode.app.) The Mac Haskell Platform installer may need to be updated to support Xcode 4.3. Note also that there still is an optional component that is generally needed for third party developer tools to work: you need to download the command line tools from within Xcode 4.3. -- 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 -- Sjoerd Visscher https://github.com/sjoerdvisscher/blog ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summer of Code idea: Haskell Web Toolkit
The link I mentioned in my previous email contains pretty much all of the currently available public information about the UHC JS backend (the Improving the UHC JavaScript Backend report is already slightly outdated, due to an API change, though). My report also contains some ideas for future work where this idea is also briefly mentioned. In addition to that, I have a yet unpublished paper that is very relevant to the UHC JS backend, but I don't think I can make that public yet, hence the contact me part :) Also, I have added it to the project list: http://hackage.haskell.org/trac/summer-of-code/ticket/1610 Jurriën On 11 Mar 2012, at 11:55, Alejandro Serrano Mena wrote: That sound like a really cool project. Where could I get more information about what could I do? You mention about contacting but I think it's better to keep the discussion open for everybody. Alejandro 2012/3/11 Jurriën Stutterheim j.stutterh...@me.com While I might be a bit biased (I spent a good deal of time working on improving the UHC JS backend), I think there are a lot of opportunities to get Haskell as a client-side language via the UHC, as Heinrich suggested. Alessandro Vermeulen recently wrote an entire front-end application using the UHC JS backend, so we know that it's capable of producing working front-end applications. See also[1]. Currently, however, it is still a bit of a pain to compile larger UHC JS projects, since Cabal support for UHC's different backends is limited. This could be one potential goal for your GSoC project: make it possible to type `cabal configure cabal build` and find a complete JS application in your dist folder. This would go a long way to make the UHC JS backend more usable and as a result, make Haskell a practical language to use for client-side programming. In solving this problem, you will have to think about how to deal with external Haskell libraries (UHC compiles JS from its internal core representation, so storing pre-compiled object files won't work in this case) and perhaps external JS libraries as well. You would also need to modify Cabal so that it becomes possible to select a specific UHC backend in your cabal files. Ideally, you will only need one cabal file for an entire web application; for both the front-end and backend. I think this would make a nice GSoC project. The scope of the above should be about right, but if you would be done way ahead of time, there are plenty of relevant related things you could work on (e.g., a UHC JS-specific Haskell Platform-like package). If this sounds interesting to you, let me know and I can send you some more detailed information about the UHC JS backend. As for mentoring, I might be able to help out there, but since the above project would revolve more around Cabal and not so much around the UHC internals, there might be more suitable mentors out there. Jurriën [1] http://uu-computerscience.github.com/uhc-js/ On 8 Mar 2012, at 14:58, Heinrich Apfelmus wrote: Chris Smith wrote: My first impression on this is that it seems a little vague, but possibly promising. My impression is also that this project proposal is rather vague. The general goal Haskell as client-side language for websites is clear and worthwhile, but I can't tell from the proposal whether the project will succeed or not, or, more importantly, *what* it will succeed at. The way I see it is that a successful GSoC proposal has to embody four key points: 1. One specific goal - I want to compile Haskell to JS via UHC's backend 2. in a larger context - as a step towards Haskell as a client-side language for websites. 3. that is accompanied by a successful example - To demonstrate that this works, I will write a small Asteroids game with HTML5 and Haskell 4. and that others can build upon - Moreover, I want to make it really easy for others to use the Haskell-JS compilation from cabal. The last point is extremely important: you don't want to build a hobbled prototype that languishes in a dark corner of github, you want to build a great software that changes the world by solving an important problem and making this solution really easy to use! Alejandro, your proposal mentions several different specific goals, each of which can be the basis for a successful GSoC project: * Make UHC's Haskell-JS compilation easy to use. * Design combinators for DOM manipulation in functional style, f.i. zippers. Note that this goal does *not* involve running Haskell on the client-side, the focus is solely on the design of combinators. This means that you'd have to use another example, for instance XML parsing. Of course, the idea is that this can be reused when someone else manages to run Haskell on the client. * Design combinators for remote procedure calling via HTTP/AJAX. Again, there is no Haskell running in the browser,
Re: [Haskell-cafe] ANNOUNCE: pipes-core 0.0.1
The Category law would be broken, though: unawait x id == yield x !== unawait x How did you get this equation? It's not even well-typed: unawait :: a - Pipe a b m () yield :: b - Pipe a b m () Someone actually implemented a variation of Pipes with unawait: https://github.com/duairc/pipes/blob/master/src/Control/Pipe/Common.hs (it's called 'unuse' there). I actually agree that it might break associativity or identity, but I don't have a counterexample in mind yet. BR, Paolo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pipes-core 0.0.1
On 2012-03-11 14:09, Paolo Capriotti wrote: The Category law would be broken, though: unawait x id == yield x !== unawait x How did you get this equation? It's not even well-typed: unawait :: a - Pipe a b m () yield :: b - Pipe a b m () I would expect that (id unawait x) await !== unawait x await === return x because in the general case of (p unawait x) if is impossible to transform the unawaited value out of the composition. To do that you would need the inverse of p. You can get around this by having a special constructor for the identity. But then id !== arr id IMO, neither of these failed laws would be a big problem in practice, since no one will actually use identity pipes in combination with unawait. Or perhaps we should be satisfied when Pipe is a Semigroupoid? Twan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pipes-core 0.0.1
On Sun, Mar 11, 2012 at 1:25 PM, Twan van Laarhoven twa...@gmail.com wrote: On 2012-03-11 14:09, Paolo Capriotti wrote: The Category law would be broken, though: unawait x id == yield x !== unawait x How did you get this equation? It's not even well-typed: unawait :: a - Pipe a b m () yield :: b - Pipe a b m () I would expect that (id unawait x) await !== unawait x await === return x There are several type errors in this equation, so I'm not exactly sure what you mean. If you intended to write something like: (id (unawait x return y)) await !== (unawait x return y) await then I disagree, because both sides should evaluate to 'return y'. I'm not sure why you would expect x to be returned, since there is no 'await' after 'unawait' in the middle pipe. because in the general case of (p unawait x) if is impossible to transform the unawaited value out of the composition. Why? The natual definition would be: p + (unawait x p') == (yield x p) + p' To do that you would need the inverse of p. You can get around this by having a special constructor for the identity. But then id !== arr id IMO, neither of these failed laws would be a big problem in practice, since no one will actually use identity pipes in combination with unawait. I'm extremely wary of this sort of reasoning, because failure of invariants in simple situations are a symptom of something being conceptually wrong in the abstraction. Or perhaps we should be satisfied when Pipe is a Semigroupoid? I don't think so, since we can always add formal identities. Usually, though, failure of the identity law implies failure of associativity, by just putting the failing identity in the middle of a composition. BR, Paolo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pipes-core 0.0.1
On Sun, Mar 11, 2012 at 7:09 AM, Paolo Capriotti p.caprio...@gmail.com wrote: Someone actually implemented a variation of Pipes with unawait: https://github.com/duairc/pipes/blob/master/src/Control/Pipe/Common.hs (it's called 'unuse' there). I actually agree that it might break associativity or identity, but I don't have a counterexample in mind yet. Indeed, on further thought, it looks like you'd run into problems here: unawait x await == return x (idP + unawait x) await == ??? The monadic operation is crucial there: without it, there's no way to observe which side of idP knows about the unawait, so you can keep it local and everything is fine... but throw in the Monad instance, and those pipes are no longer equivalent because they act differently in vertical composition. There is no easy way to fix this with (idP == pipe id). You could kludge the identity pipes and make that law hold, and I *think* you'd even keep associativity in the process so you would technically have a category again. But this hints to me that there is some *other* law you should expect to hold with regard to the interaction of Category and Monad, and now that is being broken. -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pipes-core 0.0.1
On 12-03-11 09:09 AM, Paolo Capriotti wrote: The Category law would be broken, though: unawait x id == yield x !== unawait x How did you get this equation? It's not even well-typed: unawait :: a - Pipe a b m () yield :: b - Pipe a b m () You're right, it's completely wrong. I was confused last night. Someone actually implemented a variation of Pipes with unawait: https://github.com/duairc/pipes/blob/master/src/Control/Pipe/Common.hs (it's called 'unuse' there). I actually agree that it might break associativity or identity, but I don't have a counterexample in mind yet. It's difficult to say without having the implementation of both unawait and all the combinators in one package. I'll assume the following equations hold: unawait x await = return x unawait x yield y = yield y unawait x (p1 unawait x) p2 = (p1 p2) * unawait x -- this one tripped me up first (unawait (x, y)) = unawait x The first two equations would let us move all the unawaits that are not immediately re-awaited to the end of their monadic pipeline stage: the unawait can always be performed as the last operation in bulk. The third equation let allows us to move these unawaits to the end of the pipeline. If these equations hold, unawait now appears to be law-abiding to me. I apologize for my unsubstantiated smears. The 'unuse' implementation you linked to drops the unmatched Unuse suspensions, so it doesn't follow the third equation. go i True u (Free (Unuse a d)) = go i True u d go True o (Free (Unuse a u)) d@(Free (Await _)) = go True o u d I think this implemanteation does break the Category law, but I'm having trouble testing it in GHCi. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pipes-core 0.0.1
On Sun, Mar 11, 2012 at 10:30 AM, Mario Blažević blama...@acanac.net wrote: It's difficult to say without having the implementation of both unawait and all the combinators in one package. I'll assume the following equations hold: (p1 unawait x) p2 = (p1 p2) * unawait x -- this one tripped me up I don't think this could reasonably hold. For example, you'd expect that for any p, idP p == idP since idP never terminates at all. But then let p1 == idP, and you get something silly. The issue is with early termination: if p2 terminates first in the left hand side, you don't want the unawait to occur. -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] network-conduit proxy
Thanks for explaining the problem. I guess I have to ditch my preconceived notions (based on using Java/.Net) that killing a thread is dangerous. Thanks again, Grant ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pipes-core 0.0.1
On 12-03-11 12:39 PM, Chris Smith wrote: On Sun, Mar 11, 2012 at 10:30 AM, Mario Blaževićblama...@acanac.net wrote: (p1 unawait x) p2 = (p1 p2)* unawait x -- this one tripped me up I don't think this could reasonably hold. For example, you'd expect that for any p, idP p == idP since idP never terminates at all. But then let p1 == idP, and you get something silly. The issue is with early termination: if p2 terminates first in the left hand side, you don't want the unawait to occur. No, idP does terminate once it consumes its input. Your idP p first reproduces the complete input, and then runs p with empty input. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE : Leksah 0.12
Source is in Hackage and https://github.com/leksah OS X Binary Installers http://leksah.org/packages/leksah-0.12.0.3-ghc-7.0.4.dmg http://leksah.org/packages/leksah-0.12.0.3-ghc-7.4.1.dmg Windows Binary Installers http://leksah.org/packages/leksah-0.12.0.3-ghc-6.12.3.exe http://leksah.org/packages/leksah-0.12.0.3-ghc-7.0.3.exe http://leksah.org/packages/leksah-0.12.0.3-ghc-7.0.4.exe http://leksah.org/packages/leksah-0.12.0.3-ghc-7.4.1.exe Changes to the last release include: * Support for GHC 7.2 and 7.4 * Better handling of navigation from text panes * Addition of a Files pane * Support for cabal test * Better printer for cabal files (when Leksah is built with Cabal 1.10) * Better candy support for literal Haskell * Syntax highlighting for quasi-quoted hamlet, julius and cassius (DSLs used in Yesod) * Several bug fixes and optimizations Thanks to Sanny Sanoff for improving some of the keyboard navigation and symbol searching among other things. Thanks to Harald Jagenteufel and Stephan Fortelny we have basic source control integration (git,svn) in a repo branch, but it is not part of this release. We hope to merge this in soon. Work has been progressing on a major restructuring of Leksah to make it a modular plugin based system from the ground up. It is a big task and there is still more to do. Unfortunately this has meant we have spent less time adding features. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pipes-core 0.0.1
On Sun, Mar 11, 2012 at 11:22 AM, Mario Blažević blama...@acanac.net wrote: No, idP does terminate once it consumes its input. Your idP p first reproduces the complete input, and then runs p with empty input. This is just not true. idP consumes input forever, and (idP p) = idP, for all pipes p. If it is composed with another pipe that terminates, then yes, the *composite* pipe can terminate, so for example ((q + idP) p) may actually do something with p. But to get that effect, you need to compose before the monadic bind... so for example (q + (idP p)) = (q + idP) = q. Yes, q can be exhausted, but when it is, idP will await input, which will immediately terminate the (idP p) pipe, producing the result from q, and ignoring p entirely. -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] network-conduit proxy
Sun, Mar 11, 2012 at 05:16:06PM +, grant wrote Thanks for explaining the problem. I guess I have to ditch my preconceived notions (based on using Java/.Net) that killing a thread is dangerous. Thanks again, Grant Don't know if it's a good way, but if you are afraid of killing thread you can use thread communication like you can use asynchronous exceptions or channels. So you can do smth like: (sourceClient $= CL.map Left) = (sourceTMChan communicationChannel $= CL.map Right) And have all data in Left and all commands in Right. This is really overkill for such a task but it can be usefull for more complicated ones, where there are communication between threads. -- Alexander V Vershilov signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why so many strings in Network.URI, System.Posix and similar libraries?
2012/3/11 Jeremy Shaw jer...@n-heptane.com: Also, URIs are not defined in terms of octets.. but in terms of characters. If you write a URI down on a piece of paper -- what octets are you using? None.. it's some scribbles on a paper. It is the characters that are important, not the bit representation. Well, to quote one example from RFC 3986: 2.1. Percent-Encoding A percent-encoding mechanism is used to represent a data octet in a component when that octet's corresponding character is outside the allowed set or is being used as a delimiter of, or within, the component. The syntax of URIs is a mechanism for describing data octets, not Unicode code points. It is at variance to describe URIs in terms of Unicode code points. If you render a URI in a utf-8 encoded document versus a utf-16 encoded document.. the octets will be different, but the meaning will be the same. Because it is the characters that are important. For a URI Text would be a more compact representation than String.. but ByteString is a bit dodgy since it is not well defined what those bytes represent. (though if you use a newtype wrapper around ByteString to declare that it is Ascii, then that would be fine). This is all fine well and good for what a URI is parsed from and what it is serialized too; but once parsed, the major components of a URI are all octets, pure and simple. Like the host part of the authority: host= IP-literal / IPv4address / reg-name ... reg-name= *( unreserved / pct-encoded / sub-delims ) The reg-name production is enough to show that, once the host portion is parsed, it could contain any bytes whatever. ByteString is the only correct representations for a parsed host and userinfo, as well as a parsed path, query or fragment. -- Jason Dusek pgp /// solidsnack 1FD4C6C1 FED18A2B ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] network-conduit proxy
So you can do smth like: (sourceClient $= CL.map Left) = (sourceTMChan communicationChannel $= CL.map Right) Alexander V Vershilov That's a great idea, I'll give that a try. I was having an odd problem with killThread on windows where the first character would be lost in the next session straight after the killThread, so your idea looks more appealing. Thanks again, Grant ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why so many strings in Network.URI, System.Posix and similar libraries?
On Sun, Mar 11, 2012 at 14:33, Jason Dusek jason.du...@gmail.com wrote: The syntax of URIs is a mechanism for describing data octets, not Unicode code points. It is at variance to describe URIs in terms of Unicode code points. You might want to take a glance at RFC 3492, though. -- 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
Re: [Haskell-cafe] ANNOUNCE: pipes-core 0.0.1
On 2012-03-11 14:46, Paolo Capriotti wrote:
On Sun, Mar 11, 2012 at 1:25 PM, Twan van Laarhoventwa...@gmail.com wrote:
I would expect that
(id unawait x) await !== unawait x await === return x
There are several type errors in this equation, so I'm not exactly
sure what you mean. If you intended to write something like:
(id (unawait x return y)) await
!==
(unawait x return y) await
then I disagree, because both sides should evaluate to 'return y'. I'm
not sure why you would expect x to be returned, since there is no
'await' after 'unawait' in the middle pipe.
Oops, I got confused by () and (). The intended semantics of unawait is
unawait x await === return x
So what I was trying to write is
(id + unawait x) await
=== {by identity law}
unawait x await
=== {by behavior of unawait}
return x
But that this is impossible to implement, and instead what you get is
(id + unawait x) await === return () await === await
because in the general case of
(p unawait x)
if is impossible to transform the unawaited value out of the composition.
Why? The natual definition would be:
p + (unawait x p') == (yield x p) + p'
Right, but then take p==id, which gives
(id + (unawait x return ())) p'
===
((yield x id) + return ()) p'
===
return () p'
===
p'
So the unawait is not seen by p', whereas the identity law would give
(id + (unawait x return ())) p'
===
(unawait x return ()) p'
===
unawait x p'
I would like to get this latter semantics, and if the left side is id, it is
fine. However, in
(p :: Pipe a b r) + (unawait x q :: Pipe b c r) :: Pipe a c r
x has type b. You can not write this in a form like
unawait x' q :: Pipe a c r
because here x' would have type a. But if p == id, this is exactly what you
would like to get.
I'm extremely wary of this sort of reasoning, because failure of
invariants in simple situations are a symptom of something being
conceptually wrong in the abstraction.
Or perhaps we should be satisfied when Pipe is a Semigroupoid?
I don't think so, since we can always add formal identities. Usually,
though, failure of the identity law implies failure of associativity,
by just putting the failing identity in the middle of a composition.
A simple way to implement unawait that fails the identity law is by discarding
left-over unawaits inside a vertical composition. I.e.
unawait x + p === return () + p
q + unawait y === q + return ()
As long as you do this consistently for *all* vertical compositions, I don't see
how associativity is broken.
In the first case, with unawait on the left, you don't need to discard the
await. But I think it is probably more consistent if you do.
Anway, 'purePipe id' is now a failing identity, in the sense that composing with
it discards trailing awaits from the other thing composed with.
Twan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pipes-core 0.0.1
On 2012-03-11 17:30, Mario Blažević wrote: It's difficult to say without having the implementation of both unawait and all the combinators in one package. I'll assume the following equations hold: unawait x await = return x unawait x yield y = yield y unawait x (p1 unawait x) p2 = (p1 p2) * unawait x -- this one tripped me up first (unawait (x, y)) = unawait x I think you should instead move unwaits in and out of the composition on the left side: unawait x (p1 + p2) === (unawait x p1) + p2 This makes idP a left-identity for (+), but not a right-identity, since you can't move unawaits in and out of p2. Twan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell-platform and ghc 7.4
Am new to haskell, but one thing I wanted to try out was the performance of an app in haskel. Having issues getting it to compile under ghc 7.0.4. The owner recommend trying to upgrade to 7.2/7.4 I see a warning that the haskell-platform isn't compatible with with 7.4.1, or so my homebrew install says. Can it be made to compile ?? Can I remove the haskell-platform and then install the dev tools from the haskell-platform via cabal etc once I have moved to 7.4.x etc ? Thanks ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell-platform and ghc 7.4
Hi. What has worked for me is to install a binary package for 7.4.1: http://www.haskell.org/ghc/download_ghc_7_4_1#binaries You can install it someplace special by giving --prefix=/someplace/special to the configure script. Then, adjust your path to hit /someplace/special/bin before it hits the location of your GHC 7.2. Maybe there's a preferred way, but this works for me (juggling 6.12.3, 7.0.4 and 7.4.1). -Andrew On Sun, Mar 11, 2012 at 4:58 PM, G gra...@fatlazycat.com wrote: Am new to haskell, but one thing I wanted to try out was the performance of an app in haskel. Having issues getting it to compile under ghc 7.0.4. The owner recommend trying to upgrade to 7.2/7.4 I see a warning that the haskell-platform isn't compatible with with 7.4.1, or so my homebrew install says. Can it be made to compile ?? Can I remove the haskell-platform and then install the dev tools from the haskell-platform via cabal etc once I have moved to 7.4.x etc ? Thanks ___ 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] Why so many strings in Network.URI, System.Posix and similar libraries?
2012/3/11 Brandon Allbery allber...@gmail.com: On Sun, Mar 11, 2012 at 14:33, Jason Dusek jason.du...@gmail.com wrote: The syntax of URIs is a mechanism for describing data octets, not Unicode code points. It is at variance to describe URIs in terms of Unicode code points. You might want to take a glance at RFC 3492, though. RFC 3492 covers Punycode, an approach to internationalized domain names. The relationship of RFC 3986 to the restrictions on the syntax of host names, as given by the DNS, is not simple. On the one hand, we have: This specification does not mandate a particular registered name lookup technology and therefore does not restrict the syntax of reg-name beyond what is necessary for interoperability. The production for reg-name is very liberal about allowable octets: reg-name= *( unreserved / pct-encoded / sub-delims ) However, we also have: The reg-name syntax allows percent-encoded octets in order to represent non-ASCII registered names in a uniform way that is independent of the underlying name resolution technology. Non-ASCII characters must first be encoded according to UTF-8... The argument for representing reg-names as Text is pretty strong since the only representable data under these rules is, indeed, Unicode code points. -- Jason Dusek pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell-platform and ghc 7.4
Ah, sounds a good idea. Thanks___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE : Leksah 0.12
Sounds good - but my build fails on ubuntu-11.10: Building gtksourceview2-0.12.3... Preprocessing library gtksourceview2-0.12.3... ./gtksourceview2.h:10:48: fatal error: gtksourceview/gtksourceundomanager.h: No such file or directory compilation terminated. gtk2hsC2hs: Error during preprocessing on ubuntu-11.04: Building gtksourceview2-0.12.3... Preprocessing library gtksourceview2-0.12.3... dist/build/Graphics/UI/Gtk/SourceView/Types.h:1:28: fatal error: gtksourceview2.h: No such file or directory compilation terminated. gtk2hsC2hs: Error during preprocessing custom header file - J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE : Leksah 0.12
Hi, I can confirm the issue with gtksourceview2.h Also I have the next error with leksah-server: src/IDE/Core/CTypes.hs:548:10: Duplicate instance declarations: instance NFData Version -- Defined at src/IDE/Core/CTypes.hs:548:10-23 instance NFData Version -- Defined in Control.DeepSeq ghc-7.0.4 deepseq-1.3.0.0 arch-x86_64 libgtksourceview2.0-dev is installed Thanks, Yuras ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE : Leksah 0.12
cabal install --extra-include-dirs=. gtksourceview2 Should get you up and running, but I think the correct fix might be to add include-dirs:. to the .cabal file. On 12 Mar 2012, at 11:01, Johannes Waldmann wrote: Sounds good - but my build fails on ubuntu-11.10: Building gtksourceview2-0.12.3... Preprocessing library gtksourceview2-0.12.3... ./gtksourceview2.h:10:48: fatal error: gtksourceview/gtksourceundomanager.h: No such file or directory compilation terminated. gtk2hsC2hs: Error during preprocessing on ubuntu-11.04: Building gtksourceview2-0.12.3... Preprocessing library gtksourceview2-0.12.3... dist/build/Graphics/UI/Gtk/SourceView/Types.h:1:28: fatal error: gtksourceview2.h: No such file or directory compilation terminated. gtk2hsC2hs: Error during preprocessing custom header file - J.W. ___ 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] ANNOUNCE : Leksah 0.12
cabal install --extra-include-dirs=. gtksourceview2 yes this works. thanks! - J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pipes-core 0.0.1
On Sun, Mar 11, 2012 at 2:33 PM, Twan van Laarhoven twa...@gmail.com wrote: I think you should instead move unwaits in and out of the composition on the left side: unawait x (p1 + p2) === (unawait x p1) + p2 This makes idP a left-identity for (+), but not a right-identity, since you can't move unawaits in and out of p2. Not sure how we got to the point of debating which of the category laws pipes should break... messy business there. I'm going to be in favor of not breaking the laws at all. The problem here is that composition of chunked pipes requires agreement on the chunk type, which gives the type-level guarantees you need that all chunked pipes in a horizontal composition (by which I mean composition in the category... I think you were calling that vertical? no matter...) share the same chunk type. Paolo's pipes-extra does this by inventing a newtype for chunked pipes, in which the input type appears in the result as well. There are probably some details to quibble with, but I think the idea there is correct. I don't like this idea of implicitly just throwing away perfectly good data because the types are wrong. It shows up in the category-theoretic properties of the package as a result, but it also shows up in the fact that you're *throwing* *away* perfectly good data just because the type system doesn't give you a place to put it! What's become obvious from this is that a (ChunkedPipe a b m r) can NOT be modelled correctly as a (Pipe a b m r). -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE : Leksah 0.12
Not a combination of deepseq and ghc we had tested. Thanks for the heads up. I have uploaded leksah-server-0.12.0.4 to Hackage to fix this. Please do a cabal update and try again. On 12 Mar 2012, at 11:15, Yuras Shumovich wrote: Hi, I can confirm the issue with gtksourceview2.h Also I have the next error with leksah-server: src/IDE/Core/CTypes.hs:548:10: Duplicate instance declarations: instance NFData Version -- Defined at src/IDE/Core/CTypes.hs:548:10-23 instance NFData Version -- Defined in Control.DeepSeq ghc-7.0.4 deepseq-1.3.0.0 arch-x86_64 libgtksourceview2.0-dev is installed Thanks, Yuras ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: freesect-0.0.5
Hi, I'm pleased to announce my first package, freesect, which is a Haskell syntax extension to generalise sections. Please visit the homepage http://www.fremissant.net/freesect for more information. The package is also available on Hackage. Some previous discussion occurred on the haskell-cafe thread http://www.mail-archive.com/haskell-cafe@haskell.org/msg97643.html It's been an exhilarating experience! Kind Regards, Andrew Seniuk (rasfar on #haskell) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pipes-core 0.0.1
On 12-03-11 01:36 PM, Chris Smith wrote:
On Sun, Mar 11, 2012 at 11:22 AM, Mario Blaževićblama...@acanac.net wrote:
No, idP does terminate once it consumes its input. Your idP p first
reproduces the complete input, and then runs p with empty input.
This is just not true. idP consumes input forever, and (idP p) =
idP, for all pipes p.
If it is composed with another pipe that terminates, then yes, the
*composite* pipe can terminate, so for example ((q+ idP) p) may
actually do something with p. But to get that effect, you need to
compose before the monadic bind... so for example (q+ (idP p)) =
(q+ idP) = q. Yes, q can be exhausted, but when it is, idP will
await input, which will immediately terminate the (idP p) pipe,
producing the result from q, and ignoring p entirely.
Sorry. I was describing the way it's done in SCC, and I assumed
that pipes and pipes-core behaved the same. But GHCi says you're right:
:{
| runPipe ((fromList [1, 2, 3] return [])
| + (idP fromList [4, 5] return [])
| + consume)
| :}
[1,2,3]
May I enquire what was the reason for the non-termination of idP?
Why was it not defined as 'forP yield' instead? The following command
runs the way I expected.
:{
| runPipe ((fromList [1, 2, 3] return [])
| + (forP yield fromList [4, 5] return [])
| + consume)
| :}
[1,2,3,4,5]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why so many strings in Network.URI, System.Posix and similar libraries?
2012/3/11 Thedward Blevins thedw...@barsoom.net: On Sun, Mar 11, 2012 at 13:33, Jason Dusek jason.du...@gmail.com wrote: The syntax of URIs is a mechanism for describing data octets, not Unicode code points. It is at variance to describe URIs in terms of Unicode code points. This claim is at odds with the RFC you quoted: 2. Characters The URI syntax provides a method of encoding data, presumably for the sake of identifying a resource, as a sequence of characters. The URI characters are, in turn, frequently encoded as octets for transport or presentation. This specification does not mandate any particular character encoding for mapping between URI characters and the octets used to store or transmit those characters. (Emphasis is mine) The RFC is specifically agnostic about serialization. I generally agree that there are a lot of places where ByteString should be used, but I'm not convinced this is one of them. Hi Thedward, I am CC'ing the list since you raise a good point that, I think, reflects on the discussion broadly. It is true that intent of the spec is to allow encoding of characters and not of bytes: I misread its intent, attending only to the productions. But due to the way URIs interact with character encoding, a general URI parser is constrained to work with ByteStrings, just the same. The RFC ...does not mandate any particular character encoding for mapping between URI characters and the octets used to store or transmit those characters... and in Section 1.2.1 it is allowed that the encoding of may depend on the scheme: In local or regional contexts and with improving technology, users might benefit from being able to use a wider range of characters; such use is not defined by this specification. Percent-encoded octets (Section 2.1) may be used within a URI to represent characters outside the range of the US-ASCII coded character set if this representation is allowed by the scheme or by the protocol element in which the URI is referenced. It seems possible for any octet, 0x00..0xFF, to show up in a URI, and it is only after parsing the scheme that we can say whether the octet belongs there are not. Thus a general URI parser can only go as far as splitting into components and percent decoding before handing off to scheme specific validation rules (but that's a big help already!). I've implemented a parser under these principles that handles specifically URLs: http://hackage.haskell.org/package/URLb Although the intent of the spec is to represent characters, I contend it does not succeed in doing so. Is it wise to assume more semantics than are actually there? The Internet and UNIX are full of broken junk; but faithful representation would seem to be better than idealization for those occasions where we must deal with them. I'm not sure the assumption of textiness really helps much in practice since the Universal Character Set contains control codes and bidi characters -- data that isn't really text. -- Jason Dusek pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pipes-core 0.0.1
On Sun, Mar 11, 2012 at 8:53 PM, Mario Blažević blama...@acanac.net wrote: May I enquire what was the reason for the non-termination of idP? Why was it not defined as 'forP yield' instead? The following command runs the way I expected. With pipes-core (which, recall, is known to be unsound... just felt this is a good time for a reminder of that, even though I believe the subset that adds tryAwait and forP to be sound), you do get both (pipe id) and (forP yield). So discover which is the true identity, we can try: idP + forP yield == forP yield forP yield + idP == forP yield Yep, looks like idP is still the identity. Of course, the real reason (aside from the fact that you can check and see) is that forP isn't definable at all in Gabriel's pipes package. -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Helper classes for Generics
Hi all, I've been playing with GHC's new generics features (see http://www.haskell.org/ghc/docs/latest/html/users_guide/generic-programming.html). All the documentation I've seen suggests creating a helper class -- for instance, the GSerialize class in the above link -- on which one defines generic instances. It seems to me that this isn't necessary. For example, here's the the example from the GHC docs, but without a helper class: -- set the phantom type of Rep to (), to avoid ambiguity from0 :: Generic a = a - Rep a () from0 = from data Bit = O | I class Serialize a where put :: a - [Bit] default put :: (Generic a, Serialize (Rep a ())) = a - [Bit] put = put . from0 instance Serialize (U1 x) where put U1 = [] instance (Serialize (a x), Serialize (b x)) = Serialize ((a :*: b) x) where put (x :*: y) = put x ++ put y instance (Serialize (a x), Serialize (b x)) = Serialize ((a :+: b) x) where put (L1 x) = O : put x put (R1 x) = I : put x instance (Serialize (a x)) = Serialize (M1 i c a x) where put (M1 x) = put x instance (Serialize a) = Serialize (K1 i a x) where put (K1 x) = put x Is there a reason to prefer using helper classes? Or perhaps we should update the wiki page (http://www.haskell.org/haskellwiki/Generics) to avoid using helper classes? Regards, Reiner___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] using mutable data structures in pure functions
Consider the following idea for implementing pure functions: A pure function can allocate and modify memory as long as a) it never returns a reference to the memory or b) it never again modifies the memory once it returns (i.e. it returns an immutable object). This is based on the idea of value objects in object-oriented languages - the only mutation of a value object occurs in the constructor. Once the constructor is finished initializing the object it becomes immutable. My first question is whether or not this is accurate or does it need some qualifications / fixing up. Secondly, where does this idea fit into the Haskell philosophy? For example, consider the definition of Data.List.nub: nub l = nub' l [] where nub' [] _ = [] nub' (x:xs) ls | x `elem` ls = nub' xs ls | otherwise = x : nub' xs (x:ls) Clearly the memory allocated to ls never escapes nub', so it seems that ls could be replaced with a mutable data structure (with an eye towards improving performance in special cases). For another example, consider Data.Map.fromList. I kind of expected fromList to build up the map using a mutable data structure and then seal it up before returning it, but it seems to call the same insert that one would call to add to the map after it has been constructed. So, again, what is the Haskell philosophy towards using mutable data structures in pure functions? Is it: 1. leave it to the compiler to find these kinds of opportunities 2. just use the immutable data structures - after all they are just as good (at least asymptotically) 3. you don't want to use mutable data structures because of _ 4. it does happen, and some examples are __ Thanks, ER ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] using mutable data structures in pure functions
I'm sure others will want to chime in here, but I'll offer my two cents. On Sun, 11 Mar 2012 22:38:56 -0500, E R pc88m...@gmail.com wrote: snip So, again, what is the Haskell philosophy towards using mutable data structures in pure functions? Is it: 1. leave it to the compiler to find these kinds of opportunities 2. just use the immutable data structures - after all they are just as good (at least asymptotically) 3. you don't want to use mutable data structures because of _ 4. it does happen, and some examples are __ You will find that a surprising amount of the time this will be sufficient. After all, programmer time is frequently more expensive than processor time. That being said, there are some cases where you really do want to be able to utilize a mutable data structure inside of an otherwise pure algorithm. This is precisely the use of the ST monad. ST serves to allow the use of mutable state inside of a function while hiding the fact from the outside world. Cheers, - Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why so many strings in Network.URI, System.Posix and similar libraries?
On Sun, Mar 11, 2012 at 23:05, Jason Dusek jason.du...@gmail.com wrote: Although the intent of the spec is to represent characters, I contend it does not succeed in doing so. Is it wise to assume more semantics than are actually there? It is not; one of the reasons that many experts protested the acceptance of this RFC is because of its incomplete specification (and as a result there are a lot of implementations currently which *do* assume more semantics, not always compatibly with each other). Punycode is out there now, but it's a mess and a minefield. -- 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
Re: [Haskell-cafe] Why so many strings in Network.URI, System.Posix and similar libraries?
Argh. Email fail. Hopefully this time I have managed to reply-all to the list *and* keep the unicode properly intact. Sorry about any duplicates you may have received. On Sun, Mar 11, 2012 at 1:33 PM, Jason Dusek jason.du...@gmail.com wrote: 2012/3/11 Jeremy Shaw jer...@n-heptane.com: Also, URIs are not defined in terms of octets.. but in terms of characters. If you write a URI down on a piece of paper -- what octets are you using? None.. it's some scribbles on a paper. It is the characters that are important, not the bit representation. To quote RFC1738: URLs are sequences of characters, i.e., letters, digits, and special characters. A URLs may be represented in a variety of ways: e.g., ink on paper, or a sequence of octets in a coded character set. The interpretation of a URL depends only on the identity of the characters used. Well, to quote one example from RFC 3986: 2.1. Percent-Encoding A percent-encoding mechanism is used to represent a data octet in a component when that octet's corresponding character is outside the allowed set or is being used as a delimiter of, or within, the component. Right. This describes how to convert an octet into a sequence of characters, since the only thing that can appear in a URI is sequences of characters. The syntax of URIs is a mechanism for describing data octets, not Unicode code points. It is at variance to describe URIs in terms of Unicode code points. Not sure what you mean by this. As the RFC says, a URI is defined entirely by the identity of the characters that are used. There is definitely no single, correct byte sequence for representing a URI. If I give you a sequence of bytes and tell you it is a URI, the only way to decode it is to first know what encoding the byte sequence represents.. ascii, utf-16, etc. Once you have decoded the byte sequence into a sequence of characters, only then can you parse the URI. If you render a URI in a utf-8 encoded document versus a utf-16 encoded document.. the octets will be diffiFor example, let's say that we have a unicode string and we want to use it in the URI path. the meaning will be the same. Because it is the characters that are important. For a URI Text would be a more compact representation than String.. but ByteString is a bit dodgy since it is not well defined what those bytes represent. (though if you use a newtype wrapper around ByteString to declare that it is Ascii, then that would be fine). This is all fine well and good for what a URI is parsed from and what it is serialized too; but once parsed, the major components of a URI are all octets, pure and simple. Not quite. We can not, for example, change uriPath to be a ByteString and decode any percent encoded characters for the user, because that would change the meaning of the path and break applications. For example, let's say we have the path segments [foo, bar/baz] and we wish to use them in the path info of a URI. Because / is a special character it must be percent encoded as %2F. So, the path info for the url would be: foo/bar%2Fbaz If we had the path segments, [foo,bar,baz], however that would be encoded as: foo/bar/baz Now let's look at decoding the path. If we simple decode the percent encoded characters and give the user a ByteString then both urls will decode to: pack foo/bar/baz Which is incorrect. [foo, bar/baz] and [foo,bar,baz] represent different paths. The percent encoding there is required to distinguish between to two unique paths. Let's look at another example, Let's say we want to encode the path segments: [I❤λ] How do we do that? Well.. the RFCs do not mandate a specific way. While a URL is a sequence of characters -- the set of allow characters in pretty restricted. So, we must use some application specific way to transform that string into something that is allowed in a uri path. We could do it by converting all characters to their unicode character numbers like: u73u2764u03BB Since the string now only contains acceptable characters, we can easily convert it to a valid uri path. Later when someone requests that url, our application can convert it back to a unicode character sequence. Of course, no one actually uses that method. The commonly used (and I believe, officially endorsed, but not required) method is a bit more complicated. 1. first we take the string I❤λ and utf-8 encoded it to get a octet sequence: 49 e2 9d a4 ce bb 2. next we percent encode the bytes to get *back* to a character sequence (such as a String, Text, or Ascii) I%E2%9D%A4%CE%BB So, that is character sequence that would appear in the URI. *But* we do not yet have octets that we can transmit over the internet. We only have a sequence of characters. We must now convert those characters into octets. For example, let's say we put the url as an 'href' in an a tag in a web page that is UTF-16 encoded. 3. Now we must convert the character
Re: [Haskell-cafe] using mutable data structures in pure functions
On Sun, Mar 11, 2012 at 8:38 PM, E R pc88m...@gmail.com wrote: 1. leave it to the compiler to find these kinds of opportunities 2. just use the immutable data structures - after all they are just as good (at least asymptotically) 3. you don't want to use mutable data structures because of _ 4. it does happen, and some examples are __ 5. There's no substitute for thinking and understanding the trade-offs that you are making. :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why so many strings in Network.URI, System.Posix and similar libraries?
2012/3/12 Jeremy Shaw jer...@n-heptane.com: The syntax of URIs is a mechanism for describing data octets, not Unicode code points. It is at variance to describe URIs in terms of Unicode code points. Not sure what you mean by this. As the RFC says, a URI is defined entirely by the identity of the characters that are used. There is definitely no single, correct byte sequence for representing a URI. If I give you a sequence of bytes and tell you it is a URI, the only way to decode it is to first know what encoding the byte sequence represents.. ascii, utf-16, etc. Once you have decoded the byte sequence into a sequence of characters, only then can you parse the URI. Hmm. Well, I have been reading the spec the other way around: first you parse the URI to get the bytes, then you use encoding information to interpret the bytes. I think this curious passage from Section 2.5 is interesting to consider here: For most systems, an unreserved character appearing within a URI component is interpreted as representing the data octet corresponding to that character's encoding in US-ASCII. Consumers of URIs assume that the letter X corresponds to the octet 01011000, and even when that assumption is incorrect, there is no harm in making it. A system that internally provides identifiers in the form of a different character encoding, such as EBCDIC, will generally perform character translation of textual identifiers to UTF-8 [STD63] (or some other superset of the US-ASCII character encoding) at an internal interface, thereby providing more meaningful identifiers than those resulting from simply percent-encoding the original octets. I am really not sure how to interpret this. I have been reading '%' in productions as '0b00100101' and I have written my parser this way; but that is probably backwards thinking. ...let's say we have the path segments [foo, bar/baz] and we wish to use them in the path info of a URI. Because / is a special character it must be percent encoded as %2F. So, the path info for the url would be: foo/bar%2Fbaz If we had the path segments, [foo,bar,baz], however that would be encoded as: foo/bar/baz Now let's look at decoding the path. If we simple decode the percent encoded characters and give the user a ByteString then both urls will decode to: pack foo/bar/baz Which is incorrect. [foo, bar/baz] and [foo,bar,baz] represent different paths. The percent encoding there is required to distinguish between to two unique paths. I read the section on paths differently: a path is sequence of bytes, wherein slash runs are not permitted, among other rules. However, re-reading the section, a big todo is made about hierarchical data and path normalization; it really seems your interpretation is the correct one. I tried it out in cURL, for example: http://www.ietf.org/rfc%2Frfc3986.txt # 404 Not Found http://www.ietf.org/rfc/rfc3986.txt # 200 OK My recently released released URL parser/pretty-printer is actually wrong in its handling of paths and, when corrected, will only amount to a parser of URLs that are encoded in US-ASCII and supersets thereof. -- Jason Dusek pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
