Re: [Haskell-cafe] Are constructors strict?
On 20.01.2011, at 22:18, Daryoush Mehrtash wrote: I am having hard time understanding the following paragraph in Purely functional Lazy non-deterministic programing paper http://www.cs.rutgers.edu/~ccshan/rational/lazy-nondet.pdf The problem with the naive monadic encoding of non-determinism is that the arguments to a constructor must be deterministic. If these arguments are themselves results of non-deterministic computations, these computations must be performed completely before we can apply the constructor to build a non-deterministic result. Why does the argument to constructors must be deterministic?WHy is it that thunks are not used in this case? If you use a monadic model for non-determinism in Haskell you use the standard constructors provided by Haskell and the bind operator to apply it to a non-deterministic (monadic) value. For example, consider the non-deterministic value coin defined as follows. coin :: MonadPlus m = m Bool coin = False `mplus` True To apply the constructor Just to this value you use the bind operator as follows. test :: MonadPlus m = m (Maybe Bool) test = coin = return . Just If you now consider the following definition. loop = MonadPlus m = m Bool loop = loop If we apply Just to loop as follows test2 :: MonadPlus m = m (Maybe Bool) test2 = loop = return . Just the evaluation of test2 does not terminate because = has to evaluate loop. But this does not correctly reflect the behaviour in a functional logic language like Curry. For example, if you have a function that checks whether the outermost constructor of test2 is Just, the test is supposed to be successful. In the naive model for non-determinism this is not the case. Cheers, Jan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] windows network programming
Just starting out here so I don't know what I'm doing yet, but this one doesn't compile for me. ping.hs:19:13: parse error on input `-' So am I doing something stupid here or is there something wrong with the code? -Tako On Fri, Jan 21, 2011 at 04:48, Michael Litchard mich...@schmong.org wrote: freenode figured this out. Pasting here for future reference. import Control.Concurrent import Network import System.IO main :: IO () main = withSocketsDo $ do m - newEmptyMVar forkIO (waitAndPong m) ping m -- The basic server waitAndPong :: MVar () - IO () waitAndPong m = do socket - listenOn (PortNumber 8000) putMVar m () (handle,_,_) - accept socket hSetBuffering handle LineBuffering incoming - hGetLine handle putStrLn ( ++ incoming) hPutStrLn handle pong -- The basic client ping :: MVar () - IO () ping m = do _ - takeMVar m handle - connectTo localhost (PortNumber 8000) hSetBuffering handle LineBuffering hPutStrLn handle ping incoming - hGetLine handle putStrLn ( ++ incoming) On Thu, Jan 20, 2011 at 6:17 PM, Michael Litchard mich...@schmong.orgwrote: I tried this as an example and got the following error when running. net.exe: connect: failed (Connection refused (WSAECONNREFUSED)) Firewall is off, running as administrator Windows is Windows 7 Enterprise. Advice on what to do next is appreciated On Tue, Nov 2, 2010 at 1:24 PM, Nils Schweinsberg m...@n-sch.de wrote: Am 02.11.2010 19:57, schrieb Michael Litchard: got any urls with examples? Sure, see this short server-client-ping-pong application. By the way, I noticed that you don't need withSocketsDo on windows 7, but I guess it's there for a reason for older windows versions. :) import Control.Concurrent import Network import System.IO main :: IO () main = withSocketsDo $ do forkIO waitAndPong ping -- The basic server waitAndPong :: IO () waitAndPong = do socket - listenOn (PortNumber 1234) (handle,_,_) - accept socket hSetBuffering handle LineBuffering incoming - hGetLine handle putStrLn ( ++ incoming) hPutStrLn handle pong -- The basic client ping :: IO () ping = do handle - connectTo localhost (PortNumber 1234) hSetBuffering handle LineBuffering hPutStrLn handle ping incoming - hGetLine handle putStrLn ( ++ incoming) ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Are constructors strict?
sorry, forgot to cc cafe. On Fri, Jan 21, 2011 at 7:12 PM, Sebastian Fischer fisc...@nii.ac.jpwrote: Hi Daryoush, On Fri, Jan 21, 2011 at 6:18 AM, Daryoush Mehrtash dmehrt...@gmail.comwrote: I am having hard time understanding the following paragraph in Purely functional Lazy non-deterministic programing paper http://www.cs.rutgers.edu/~ccshan/rational/lazy-nondet.pdf The problem with the naive monadic encoding of non-determinism is that the arguments to a constructor must be deterministic. If these arguments are themselves results of non-deterministic computations, these computations must be performed completely before we can apply the constructor to build a non-deterministic result. Why does the argument to constructors must be deterministic? Because of the type of the constructor. Say you want to compute a list of Ints nondeterministically (like in the paper). Than the first argument of the (:) constructurs in the result must be an Int. A nondeterministic computation that yields an Int has type (m Int) for some nondeterminism monad (for example, it has type [Int] in the list monad). That the (:) constructur is polymorphic and would allow to make a value of type [m Int], is a coincidence and does not help to make a value of type (m [Int]). WHy is it that thunks are not used in this case? Thunks do not model nondeterminism, only laziness. Did that help you understand? Regards, Sebastian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Where is the CABAL file for haskell-platform 2010.2.0.0?
On Thu, Jan 20, 2011 at 4:38 PM, Magnus Therning mag...@therning.org wrote: % curl -s http://code.haskell.org/haskell-platform/haskell-platform.cabal | head ... Where can I find the cabal file for 2010.2.0.0 until 2011.1.0.0 is formally released (or will it be 2011.2.0.0 as the release plan says)? Will the CABAL file for 2010.2.0.0 not be available *at all* after 2011.x.0.0 is released? http://code.haskell.org/haskell-platform/ is a darcs repository. Why don't you look in the history? G -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Where is the CABAL file for haskell-platform 2010.2.0.0?
On Fri, Jan 21, 2011 at 10:30, Gregory Collins g...@gregorycollins.net wrote: On Thu, Jan 20, 2011 at 4:38 PM, Magnus Therning mag...@therning.org wrote: % curl -s http://code.haskell.org/haskell-platform/haskell-platform.cabal | head ... Where can I find the cabal file for 2010.2.0.0 until 2011.1.0.0 is formally released (or will it be 2011.2.0.0 as the release plan says)? Will the CABAL file for 2010.2.0.0 not be available *at all* after 2011.x.0.0 is released? http://code.haskell.org/haskell-platform/ is a darcs repository. Why don't you look in the history? I did, but gave up after realising that there are no tags in that repository. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hledget: mtv vs transformers
On Fri, Jan 21, 2011 at 3:37 AM, Simon Michael si...@joyful.com wrote: You mean mtl 2.*, right ? Yes that is a problem. I'm nervous about requiring mtl 2 because when I bumped hledger 0.13's process dependency to 0.14 for similar reasons it made all kinds of trouble for folks who just want to install the hledger core in standard/older haskell environments. Well, chalk me up as the person with standard/old haskell environment :) I have many versions of GHC installed, plus I have a Haskell Platform from .debs as provided by Debian/unstable. That version of HP still carries GHC 6.12.1 and mtl 1.* Using that, it is impossible to make install hledger for the reasons outlined below - you either have to exclude hledger-chart, or build fails. On Jan 20, 2011, at 5:11 PM, Dmitry Astapov wrote: Since hledger-chart depends on Chart, which in turn depends on transformers 0.2.*, it will make a sense to bump all mtl dependencies in hledger to 2.2 When one does make install with older GHC (like 6.12.1, for example), and mtl 1.x is available, it would be happily used for hledger-lib and hledger, but compilation of hledger-chart will pull in transformers 0.2 (but not the newer mtl) and will fail due to conflicting instances. -- Dmitry Astapov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hledget: mtv vs transformers
On Fri, Jan 21, 2011 at 8:02 AM, Michael Snoyman mich...@snoyman.comwrote: Couldn't you depend on either version of mtl? Point is that in this particular case two different versions of mtl are being pulled in the compilation by different dependencies. Plus, transformers 0.2.* is selected as well. Cabal reasons along the following lines: one dependency is hledger 0.13, which is built against the mtl 1.x. Selecting both another dependency is Chart, which is built against transformers 0.2.x Now instances from transformers conflict with those from mtl 1.x, when you are building hledger-chart Plus, when you are rebuilding hledger-0.13 from scratch, they start to conflict as well. Add in the mix deficiency of 6.12.1 which is sometimes picks up wrong version of packages (or so I remember), and all the hell breaks loose. The only solution for me was to bump mtl to 2.x, rebuild everything depending on mtl, and something pulled in newer process in the process, which caused another wave of rebuilds. With 6.12.3 or 7.0.1 everything is way easier (as expected) :) On Fri, Jan 21, 2011 at 3:37 AM, Simon Michael si...@joyful.com wrote: You mean mtl 2.*, right ? Yes that is a problem. I'm nervous about requiring mtl 2 because when I bumped hledger 0.13's process dependency to 0.14 for similar reasons it made all kinds of trouble for folks who just want to install the hledger core in standard/older haskell environments. On Jan 20, 2011, at 5:11 PM, Dmitry Astapov wrote: Since hledger-chart depends on Chart, which in turn depends on transformers 0.2.*, it will make a sense to bump all mtl dependencies in hledger to 2.2 When one does make install with older GHC (like 6.12.1, for example), and mtl 1.x is available, it would be happily used for hledger-lib and hledger, but compilation of hledger-chart will pull in transformers 0.2 (but not the newer mtl) and will fail due to conflicting instances. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Dmitry Astapov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Are constructors strict?
loop = MonadPlus m = m Bool loop = loop If we apply Just to loop as follows test2 :: MonadPlus m = m (Maybe Bool) test2 = loop = return . Just the evaluation of test2 does not terminate because = has to evaluate loop. But this does not correctly reflect the behaviour in a functional logic language like Curry. For example, if you have a function that checks whether the outermost constructor of test2 is Just, the test is supposed to be successful. In the naive model for non-determinism this is not the case. Do I have to have MonadPlus m or would any other Monad class work the same way? -- Daryoush Weblog: http://perlustration.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hledget: mtv vs transformers
On Fri, Jan 21, 2011 at 12:50 PM, Dmitry Astapov dasta...@gmail.com wrote: On Fri, Jan 21, 2011 at 8:02 AM, Michael Snoyman mich...@snoyman.com wrote: Couldn't you depend on either version of mtl? Point is that in this particular case two different versions of mtl are being pulled in the compilation by different dependencies. Plus, transformers 0.2.* is selected as well. Cabal reasons along the following lines: one dependency is hledger 0.13, which is built against the mtl 1.x. Selecting both another dependency is Chart, which is built against transformers 0.2.x Now instances from transformers conflict with those from mtl 1.x, when you are building hledger-chart Plus, when you are rebuilding hledger-0.13 from scratch, they start to conflict as well. Add in the mix deficiency of 6.12.1 which is sometimes picks up wrong version of packages (or so I remember), and all the hell breaks loose. The only solution for me was to bump mtl to 2.x, rebuild everything depending on mtl, and something pulled in newer process in the process, which caused another wave of rebuilds. With 6.12.3 or 7.0.1 everything is way easier (as expected) :) What I mean is that if his code isn't using any features particular to a specific version of mtl, he can relax the version bounds to allow *either* version, which should at least sidestep the issue. If the underlying libraries depend on both mtl 1 and 2, though, there really isn't much to be done. On Fri, Jan 21, 2011 at 3:37 AM, Simon Michael si...@joyful.com wrote: You mean mtl 2.*, right ? Yes that is a problem. I'm nervous about requiring mtl 2 because when I bumped hledger 0.13's process dependency to 0.14 for similar reasons it made all kinds of trouble for folks who just want to install the hledger core in standard/older haskell environments. On Jan 20, 2011, at 5:11 PM, Dmitry Astapov wrote: Since hledger-chart depends on Chart, which in turn depends on transformers 0.2.*, it will make a sense to bump all mtl dependencies in hledger to 2.2 When one does make install with older GHC (like 6.12.1, for example), and mtl 1.x is available, it would be happily used for hledger-lib and hledger, but compilation of hledger-chart will pull in transformers 0.2 (but not the newer mtl) and will fail due to conflicting instances. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Dmitry Astapov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hledger: mtl vs transformers
On 1/20/11 10:02 PM, Michael Snoyman wrote: Couldn't you depend on either version of mtl? I currently depend on mtl, no version.. am I missing your point ? On 1/21/11 2:50 AM, Dmitry Astapov wrote: something pulled in newer process in the process, which caused another wave of rebuilds. hledger! As I said. Due to just the kind of dependency bump you're suggesting. (I've since reverted that higher process dependency.) On 1/21/11 2:44 AM, Dmitry Astapov wrote: I have many versions of GHC installed, plus I have a Haskell Platform from .debs as provided by Debian/unstable. That version of HP still carries GHC 6.12.1 and mtl 1.* So I think you're saying: I know I won't be able to install hledger with my standard platform install, but I'm willing to upgrade my whole system to mtl 2 for hledger, because at least I know hledger-chart will install in the end. And I'm saying: I now think it's a better trade-off for now to leave hledger core installable without this pain, and let hledger-chart users - who are less numerous, since gtk is relatively difficult, and hledger-chart is for now quite limited - deal with the problem (by installing hledger-chart before hledger, or by using --constraint 'mtl=2'). And, though I know few read them, document it as best we can at http://hledger.org/MANUAL.html#installing and http://hledger.org/MANUAL.html#installation-issues . Also I seem to remember 6.12.1 had at least one specific problem, as you suggest, so supporting it might be out of scope... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Looking for criticism and comments on web-mongrel2.
After sufficient hand-wringing I finally uploaded web-mongrel2 up to hackage and I'm interested in criticism of my approach. The module itself is terribly simple as it's meant to provide a lightweight layer between an application or framework and Mongrel2, but if nothing else, it's a start. Anyway, the hackage page is at http://hackage.haskell.org/package/web-mongrel2-0.0.2.2 with a link to the github repo. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [web-devel] Looking for criticism and comments on web-mongrel2.
On Fri, Jan 21, 2011 at 2:30 PM, Clint Moore cmo...@wamboli.com wrote: After sufficient hand-wringing I finally uploaded web-mongrel2 up to hackage and I'm interested in criticism of my approach. The module itself is terribly simple as it's meant to provide a lightweight layer between an application or framework and Mongrel2, but if nothing else, it's a start. Anyway, the hackage page is at http://hackage.haskell.org/package/web-mongrel2-0.0.2.2 with a link to the github repo. Looks like you've done a good job so far, and have even put in a fair amount of docs. Impressive! Just some minor thoughts: * I think you should consider using ByteStrings instead of Strings in a lot of places (eg, headers). * In m2_parse, it looks to me like usage of Parsec is overkill, since a simple break would work. As a plus, if you also switch to ByteString, you could use breakByte which will give you a highly optimized parsing function. * For response_body, I'd **really** avoid usage of String. In fact, some form of enumerator would be very good there. But at the very least, please switch to a lazy ByteString. I can't really say too much more without knowing more of the internals of zeromq and mongrel2, but I think this is a good project to have going for the Haskell community. Thank you. Obviously I'm biased here, but I'd love to see a WAI wrapper for mongrel2. Would you be interested in either having this package provide a WAI interface, or writing a separate package that wraps this package and provides one? I'd be happy to offer some help if you're interested. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for criticism and comments on web-mongrel2.
2011/1/21 Clint Moore cmo...@wamboli.com: After sufficient hand-wringing I finally uploaded web-mongrel2 up to hackage and I'm interested in criticism of my approach. The module itself is terribly simple as it's meant to provide a lightweight layer between an application or framework and Mongrel2, but if nothing else, it's a start. Anyway, the hackage page is at http://hackage.haskell.org/package/web-mongrel2-0.0.2.2 with a link to the github repo. Hi, The link given on hackage to git is broken, it seems to be web-mongrel2 instead of haskell-mongrel2. Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for criticism and comments on web-mongrel2.
On Fri, Jan 21, 2011 at 3:30 PM, Vo Minh Thu not...@gmail.com wrote: 2011/1/21 Clint Moore cmo...@wamboli.com: After sufficient hand-wringing I finally uploaded web-mongrel2 up to hackage and I'm interested in criticism of my approach. The module itself is terribly simple as it's meant to provide a lightweight layer between an application or framework and Mongrel2, but if nothing else, it's a start. Anyway, the hackage page is at http://hackage.haskell.org/package/web-mongrel2-0.0.2.2 with a link to the github repo. Hi, The link given on hackage to git is broken, it seems to be web-mongrel2 instead of haskell-mongrel2. It worked fine for me... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [web-devel] Looking for criticism and comments on web-mongrel2.
On Fri, Jan 21, 2011 at 5:28 AM, Michael Snoyman mich...@snoyman.com wrote: On Fri, Jan 21, 2011 at 2:30 PM, Clint Moore cmo...@wamboli.com wrote: Looks like you've done a good job so far, and have even put in a fair amount of docs. Impressive! Just some minor thoughts: Well thanks for the encouragement! * I think you should consider using ByteStrings instead of Strings in a lot of places (eg, headers). Ugh! I forgot to include in my email that that was the first thing I am going to do. I'm actually working on that now. * In m2_parse, it looks to me like usage of Parsec is overkill, since a simple break would work. As a plus, if you also switch to ByteString, you could use breakByte which will give you a highly optimized parsing function. Now this I wouldn't have thought of. I'll go back into m2_parse and look it over again. * For response_body, I'd **really** avoid usage of String. In fact, some form of enumerator would be very good there. But at the very least, please switch to a lazy ByteString. Yep, definitely bytestrings everywhere. I guess I was overly excited to get it in front of someone and kinda jumped the gun on releasing it. There'll be a new version tomorrow. I can't really say too much more without knowing more of the internals of zeromq and mongrel2, but I think this is a good project to have going for the Haskell community. Thank you. Again, I appreciate the complement! Obviously I'm biased here, but I'd love to see a WAI wrapper for mongrel2. Would you be interested in either having this package provide a WAI interface, or writing a separate package that wraps this package and provides one? I'd be happy to offer some help if you're interested. One of the reasons the handler is so simply implemented is so that, at least I hope, is that it makes it very simple to implement handlers. Incidentally, WAI was the first library I was going to start with for implementing some handlers myself. I figure the more handlers I write the more bugs I'll catch. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for criticism and comments on web-mongrel2.
On Fri, Jan 21, 2011 at 5:30 AM, Vo Minh Thu not...@gmail.com wrote: The link given on hackage to git is broken, it seems to be web-mongrel2 instead of haskell-mongrel2. If you click on the latest version the link should be correct. And yes, it's web-mongrel2 - I caught that SECONDS after uploading it to hackage. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [web-devel] Looking for criticism and comments on web-mongrel2.
On Fri, Jan 21, 2011 at 3:40 PM, Clint Moore cmo...@wamboli.com wrote: On Fri, Jan 21, 2011 at 5:28 AM, Michael Snoyman mich...@snoyman.com wrote: On Fri, Jan 21, 2011 at 2:30 PM, Clint Moore cmo...@wamboli.com wrote: Looks like you've done a good job so far, and have even put in a fair amount of docs. Impressive! Just some minor thoughts: Well thanks for the encouragement! * I think you should consider using ByteStrings instead of Strings in a lot of places (eg, headers). Ugh! I forgot to include in my email that that was the first thing I am going to do. I'm actually working on that now. * In m2_parse, it looks to me like usage of Parsec is overkill, since a simple break would work. As a plus, if you also switch to ByteString, you could use breakByte which will give you a highly optimized parsing function. Now this I wouldn't have thought of. I'll go back into m2_parse and look it over again. * For response_body, I'd **really** avoid usage of String. In fact, some form of enumerator would be very good there. But at the very least, please switch to a lazy ByteString. Yep, definitely bytestrings everywhere. I guess I was overly excited to get it in front of someone and kinda jumped the gun on releasing it. There'll be a new version tomorrow. I can't really say too much more without knowing more of the internals of zeromq and mongrel2, but I think this is a good project to have going for the Haskell community. Thank you. Again, I appreciate the complement! Obviously I'm biased here, but I'd love to see a WAI wrapper for mongrel2. Would you be interested in either having this package provide a WAI interface, or writing a separate package that wraps this package and provides one? I'd be happy to offer some help if you're interested. One of the reasons the handler is so simply implemented is so that, at least I hope, is that it makes it very simple to implement handlers. Incidentally, WAI was the first library I was going to start with for implementing some handlers myself. I figure the more handlers I write the more bugs I'll catch. Glad to hear you were already working on the bytestring switch, I hope I didn't focus on that too much ;). If you *are* planning on writing a WAI handler for this, you will need to provide something more powerful for the response body than lazy bytestrings. Well, either that, or use some ugly forkIO/unsafeInterleaveIO tricks that I don't mention in polite company. Out of curiosity, does mongrel2 provide any kind of optimization for serving files via a sendfile system call? I would be surprised if it didn't. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [web-devel] Looking for criticism and comments on web-mongrel2.
On Fri, Jan 21, 2011 at 5:44 AM, Michael Snoyman mich...@snoyman.com wrote: Glad to hear you were already working on the bytestring switch, I hope I didn't focus on that too much ;). If you *are* planning on writing a Naw, you didn't. Using bytestrings as much as possible especially when dealing with network services are a definite best practice. WAI handler for this, you will need to provide something more powerful for the response body than lazy bytestrings. Well, either that, or use some ugly forkIO/unsafeInterleaveIO tricks that I don't mention in polite company. Well, then I'll have to figure something out. I'm morally opposed to unsafe* No, forkIO I love. But haven't yet had to resort to using anything unsafe, though I haven't done any FFI or other things that apparently make it necessary. Out of curiosity, does mongrel2 provide any kind of optimization for serving files via a sendfile system call? I would be surprised if it didn't. I don't know. I'll check that out and report back. As far as handling files, one thing that I really like about M2 is the way it handles file uploads. From the manual: Mongrel2 uses an asynchronous method of doing uploads that helps you avoid receiving files you either can't accept or shouldn't accept. It does this by sending your handler an initial message with just the headers, streaming the file to disk, and then a final message so you can read the resulting file. If you don't want the upload, then you can send a kill message (a 0 length message) and the connection closes, and the file never lands. I'm going to write a couple of simple examples later today, one of them being a file upload handler to illustrate how to use it from the application side. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [web-devel] Looking for criticism and comments on web-mongrel2.
On Fri, Jan 21, 2011 at 3:55 PM, Clint Moore cmo...@wamboli.com wrote: On Fri, Jan 21, 2011 at 5:44 AM, Michael Snoyman mich...@snoyman.com wrote: Glad to hear you were already working on the bytestring switch, I hope I didn't focus on that too much ;). If you *are* planning on writing a Naw, you didn't. Using bytestrings as much as possible especially when dealing with network services are a definite best practice. WAI handler for this, you will need to provide something more powerful for the response body than lazy bytestrings. Well, either that, or use some ugly forkIO/unsafeInterleaveIO tricks that I don't mention in polite company. Well, then I'll have to figure something out. I'm morally opposed to unsafe* No, forkIO I love. But haven't yet had to resort to using anything unsafe, though I haven't done any FFI or other things that apparently make it necessary. The most powerful interface (powerful meaning user can do whatever they want) is a simple ByteString - IO () function that can be called multiple times to keep sending data to the client. Since you need to send the headers first, you could consider some kind of interface similar to: Application :: Request - (Status - Headers - IO (ByteString - IO ()) - IO () This would basically mean that an application is given a request and function to call. That function, after taking the status code and headers (however you encode them) would return a *new* function that would allow you to send chunks of data to the client. You could also completely skip the status/headers part and make it the user's responsibility to add them. Another option is using blaze-builder Builders instead of ByteStrings. Now that I looked more closely at the response_template, a few questions: * Why are you sending Connection: close? * I'm not sure if it can ever cause a problem, but it's probably a bad idea to give a message of OK for every status code. * Not every content type will have a charset associated with it (eg, image/png). Out of curiosity, does mongrel2 provide any kind of optimization for serving files via a sendfile system call? I would be surprised if it didn't. I don't know. I'll check that out and report back. As far as handling files, one thing that I really like about M2 is the way it handles file uploads. From the manual: Mongrel2 uses an asynchronous method of doing uploads that helps you avoid receiving files you either can't accept or shouldn't accept. It does this by sending your handler an initial message with just the headers, streaming the file to disk, and then a final message so you can read the resulting file. If you don't want the upload, then you can send a kill message (a 0 length message) and the connection closes, and the file never lands. I'm going to write a couple of simple examples later today, one of them being a file upload handler to illustrate how to use it from the application side. That sounds like a nice interface if you're just targeting mongrel directly. However: * How does it handle request which are neither url-encoded or multipart form data? * To provide a proper WAI backend, it would need to provide the raw request body. Does mongrel2 support that in any way? Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Are constructors strict?
On 21.01.2011, at 11:52, Daryoush Mehrtash wrote: Do I have to have MonadPlus m or would any other Monad class work the same way? Not all monad instances satisfy undefined = return . Just = undefined if that's what you are asking for. For example, consider the identity monad. instance Monad Identity where return = Identity m = k = k (runIdentity m) Then we have undefined = return . Just = undefined = Identity . Just = Identity (Just undefined) /= undefined If = performs pattern matching on its first argument like most instances do then you get undefined = return . Just = undefined. I think that the monadplus laws mplus m n = f = mplus (m = f) (n = f) called (Ldistr) in the paper and mzero = f = mzero called (Lzero) in the paper imply undefined = return . Just = undefined At least if you have mzero /= mplus m n which is quite desirable. I don't think that this holds for continuation based monads. But Sebastian will most certainly know better as he is one of the authors of the paper. Cheers, Jan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for criticism and comments on web-mongrel2.
On Fri, 21 Jan 2011 13:30:07 +0100, Clint Moore cmo...@wamboli.com wrote: After sufficient hand-wringing I finally uploaded web-mongrel2 up to hackage and I'm interested in criticism of my approach. The module itself is terribly simple as it's meant to provide a lightweight layer between an application or framework and Mongrel2, but if nothing else, it's a start. Anyway, the hackage page is at http://hackage.haskell.org/package/web-mongrel2-0.0.2.2 with a link to the github repo. It's a pity it's not installable on Windows, since it depends (via zeromq-haskell) on the package unix. Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] CfP: The 9th International Conference on SOFTWARE ENGINEERING AND FORMAL METHODS (SEFM'11)
CALL FOR PAPERS - SEFM 2011 The 9th International Conference on SOFTWARE ENGINEERING AND FORMAL METHODS (SEFM) 14-18 November 2011 Montevideo, Uruguay URL: http://www.fing.edu.uy/inco/eventos/SEFM2011 ++ IMPORTANT DATES * Title and abstract submission deadline: 23 April 2011 * Paper submission deadline: 30 April 2011 * Acceptance/rejection notification: 15 June 2011 * Camera-ready version due: 15 July 2011 +++ BACKGROUND AND OBJECTIVES The aim of the conference is to bring together practitioners and researchers from academia, industry and government to advance the state of the art in formal methods, to facilitate their uptake in the software industry and to encourage their integration with practical engineering methods. Papers that combine formal methods and software engineering are especially welcome. Authors are invited to submit original research or tool papers on any relevant topic. These can either be normal or short papers. Short papers can discuss new ideas which are at an early stage of development and which have not yet been thoroughly evaluated. TOPICS Topics of interest include, but are not limited to: * formal requirement analysis, specification and design * programming languages, program analysis and type theory * formal methods for service-oriented and cloud computing * formal aspects of security and mobility * model checking, theorem proving and decision procedures * formal methods for real-time, hybrid and embedded systems * formal methods for safety-critical, fault-tolerant and secure systems * software architecture and coordination languages * component, object and multi-agent systems * formal aspects of software evolution and maintenance * formal methods for testing, re-engineering and reuse * light-weight and scalable formal methods * tool integration * applications of formal methods, industrial case studies and technology transfer KEYNOTE SPEAKERS * Daniel Le Métayer - INRIA, France * More to be announced... SPECIAL TRACK The conference programme will include a special track on Modelling for Sustainable Development. A separate Call for Papers is available for the special track. All queries on submissions to the special track should be sent to: sefm2011-...@iist.unu.edu. LOCATION The conference will be held at the NH Columbia Hotel located close to the financial center of Montevideo and enjoying excellent views of the Plata river (Río de la Plata) - http://www.nh-hotels.com/nh/en/hotels/uruguay/montevideo/nh-columbia.html. SUBMISSION AND PUBLICATION Submissions to the conference must not have been published or be concurrently considered for publication elsewhere. All submissions will be peer-reviewed and judged on the basis of originality, contribution to the field, technical and presentation quality, and relevance to the conference. All papers must be written in English. Research and tool papers must not exceed 16 pages in the LNCS format while short papers must not exceed 8 pages in the LNCS format (see http://www.springer.de/comp/lncs/authors.html for details). All queries on the submissions should be sent to: sefm2...@fing.edu.uy. Papers must be submitted electronically via the Easychair System: http://www.easychair.org/conferences/?conf=sefm11 The proceedings will be published in the Springer Lecture Notes in Computer Science series (LNCS). After the conference, authors of selected papers will be invited to submit an extended version of their work to be considered for publication in a special issue of the SoSyM journal (Software and Systems Modeling, Springer), following the standard reviewing process of the journal. COMMITTEES Conference Chair * Alberto Pardo, Universidad de la República, Uruguay Program Co-chairs * Gilles Barthe, IMDEA Software, Spain * Gerardo Schneider, Chalmers | Univ. of Gothenburg, Sweden Program Committee * Bernhard K. Aichering (Graz University of Technology, Austria) * Luis Barbosa (University of Minho, Portugal) * Gilles Barthe (IMDEA Software, Spain) * Thomas Anung Basuki (UNU-IIST, China) * Alexandre Bergel (University of Chile, Chile) * Gustavo Betarte (Universidad de la República, Uruguay) * Ana Cavalcanti (University of York, UK) * Pedro R. D'Argenio (Univ. Nacional de Córdoba, Argentina) * Van Hung Dang (UNU-IIST, China) * George Eleftherakis (SEERC, Greece) * José Luiz Fiadeiro (University of Leicester, UK) * Martin Fränzle (Oldenburg University, Germany) * Stefania Gnesi (ISTI-CNR, Italy) * Rob Hierons (Brunel University, UK) * Paola Inverardi (University of L'Aquila, UK) * Jean-Marie Jacquet (University of Namur, Belgium) * Tomasz Janowski (UNU-IIST, China) * Jean-Marc Jezequel (IRISA, France) * Joseph Kiniry (IT University of Copenhagen, Denmark) * Paddy Krishnan (Bond University, Australia) * Martin Leucker (TU Munich, Germany) * Xuandong Li (Nanjing University, China) * Peter Lindsay (The University of Queensland,
Re: [Haskell-cafe] Proposal: Applicative = Monad: Call for consensus
On January 19, 2011 15:28:33 Conor McBride wrote: In each case, the former has (++) acting on lists of strings as pure values, while the latter has (++) acting on strings as values given in []-computations. The type [String] determines a domain, it does not decompose uniquely to a notion of computation and a notion of value. We currently resolve this ambiguity by using one syntax for pure computations with [String] values and a different syntax for [] computations with String values. Just as we use newtypes to put a different spin on types which are denotationally the same, it might be worth considering a clearer (but renegotiable) separation of the computation and value aspects of types, in order to allow a syntax in which functions are typed as if they act on *values*, but lifted to whatever notion of computation is ambient. Yes. That makes sense. Thank you both for the clarification. The idea of explicitly separating the two aspects of types is an interesting one. The automated approach I had been thinking of was to always take the simplest context possible. (i.e., for the above, list of strings as pure values). To this end I've been working on a measure for the complexity of the application operator. I've got a draft at http://www.sharcnet.ca/~tyson/haskell/papers/TypeShape.pdf I'm still working on my thinking on polymorphic types though, so everything from section 2.2 onwards is subject to change (especially 2.3 and the conclusion). Cheers! -Tyson signature.asc Description: This is a digitally signed message part. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Applicative = Monad: Call for consensus
Interesting little paper, Tyson.
You bring up other programming languages and 'ad-hoc systems for
resolving ambiguities'; I agree with you that these systems generally
have no strong theoretical basis, but I'm not sure that's a terribly
bad thing.
I think what a programmer actually wants from ambiguity resolution is
something *predictable*; C++'s system is definitely stretching the
boundaries of predictability, but any case where I have to break out a
calculator to decide whether the compiler is going to choose
specification A or specification B for my program seems like a
failure. I'd much rather the solution wasn't always 'the most
probable' but at least was easy for me to figure out without thinking
too hard.
The goal is to easily know when I have to manually specify ambiguity
resolution and when I can trust the compiler to do it for me. I
didn't completely follow the math in your paper, so maybe it turns out
simply if it was implemented, but it wasn't clear to me. At the
least, I think you should add examples of the types of ambiguity
resolution you'd like the compiler to figure out and what your
probability measure chooses as the correct answer in each case.
Anyways, thanks for the interesting read. I'm excited to see work on
making a better type *inference* system, since much of the work lately
seems to be on making a better *type* system at the cost of more often
manually specifying types.
I work in a traditional programming industry, and most of the people
from work that I talk to about Haskell are frustrated that they can't
just write putStrLn (readLn + (5 :: Int)) and have the compiler figure
out where the lifts and joins go. After all, that just works in C[1]!
What's the point of having the most powerful type system in the
universe if the compiler can't use it to make your life easier?
-- ryan
[1] sample program:
int readLn(); // reads a line from stdin and converts string to int
void putStrLn(int x); // prints an int to stdout
void main() { putStrLn(readLn() + 5); }
On Fri, Jan 21, 2011 at 8:43 AM, Tyson Whitehead twhiteh...@gmail.com wrote:
On January 19, 2011 15:28:33 Conor McBride wrote:
In each case, the former has (++) acting on lists of strings as pure
values,
while the latter has (++) acting on strings as values given in
[]-computations.
The type [String] determines a domain, it does not decompose uniquely
to a
notion of computation and a notion of value. We currently resolve this
ambiguity by using one syntax for pure computations with [String] values
and a different syntax for [] computations with String values.
Just as we use newtypes to put a different spin on types which are
denotationally the same, it might be worth considering a clearer (but
renegotiable) separation of the computation and value aspects of types,
in order to allow a syntax in which functions are typed as if they act
on
*values*, but lifted to whatever notion of computation is ambient.
Yes. That makes sense. Thank you both for the clarification. The idea of
explicitly separating the two aspects of types is an interesting one.
The automated approach I had been thinking of was to always take the simplest
context possible. (i.e., for the above, list of strings as pure values).
To this end I've been working on a measure for the complexity of the
application operator. I've got a draft at
http://www.sharcnet.ca/~tyson/haskell/papers/TypeShape.pdf
I'm still working on my thinking on polymorphic types though, so everything
from section 2.2 onwards is subject to change (especially 2.3 and the
conclusion).
Cheers! -Tyson
___
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] web-routes and forms
Hello Jeremy,
I'm still trying to integrate web routes, but there is one thing I don't
understand:
how to deal with multiple forms?
In my former application, each forms used to redirect to a subdirectory of
the web site, and an appropriate handler was waiting there.
But now with web routes I don't see how to do that.
I've tried to push down the decision over subdirectories (with the guard
dir) inside the RouteT monad:
type NomicServer = ServerPartT IO
type RoutedNomicServer = RouteT PlayerCommand NomicServer
nomicSite :: ServerHandle - Site PlayerCommand (NomicServer Html)
nomicSite sh = setDefault (Noop 0) Site {
handleSite = \f url - unRouteT (routedNomicHandle sh url) f
, formatPathSegments = \u - (toPathSegments u, [])
, parsePathSegments = parseSegments fromPathSegments
}
routedNomicHandle :: ServerHandle - PlayerCommand - RoutedNomicServer Html
routedNomicHandle sh pc = do
d - liftRouteT $ liftIO getDataDir
msum [dir Login $ loginPage,
dir postLogin $ postLogin,
--nullDir fileServe [] d,
dir NewRule $ newRule sh,
dir NewGame $ newGameWeb sh,
dir Nomic $ routedNomicCommands sh pc]
routedNomicCommands :: ServerHandle - PlayerCommand - RoutedNomicServer
Html
routedNomicCommands sh (Noop pn) = nomicPageComm pn sh
(return ())
routedNomicCommands sh (JoinGame pn game) = nomicPageComm pn sh
(joinGame game pn)
routedNomicCommands sh (LeaveGame pn) = nomicPageComm pn sh
(leaveGame pn)
routedNomicCommands sh (SubscribeGame pn game) = nomicPageComm pn sh
(subscribeGame game pn)
routedNomicCommands sh (UnsubscribeGame pn game) = nomicPageComm pn sh
(unsubscribeGame game pn)
routedNomicCommands sh (Amend pn) = nomicPageComm pn sh
(amendConstitution pn)
routedNomicCommands sh (DoAction pn an ar) = nomicPageComm pn sh
(doAction' an ar pn)
routedNomicCommands sh (NewRule pn name text code) = nomicPageComm pn sh
(submitRule name text code pn)
routedNomicCommands sh (NewGame pn game) = nomicPageComm pn sh
(newGame game pn)
loginPage :: RoutedNomicServer Html
loginPage = do
l - loginForm
ok $ H.html $ do
H.head $ do
H.title (H.string Login to Nomic)
H.link ! rel stylesheet ! type_ text/css ! href
/static/css/nomic.css
H.meta ! A.httpEquiv Content-Type ! content
text/html;charset=utf-8
H.meta ! A.name keywords ! A.content Nomic, game, rules, Haskell,
auto-reference
H.body $ do
H.div ! A.id container $ do
H.div ! A.id header $ Login to Nomic
H.div ! A.id login $ l
H.div ! A.id footer $ footer
loginForm :: RoutedNomicServer Html
loginForm = do
ok $ H.form ! A.method POST ! A.action /postLogin ! enctype
multipart/form-data;charset=UTF-8 $ do
H.label ! for login $ Login
input ! type_ text ! name login ! A.id login ! tabindex 1 !
accesskey L
H.label ! for password $ Password
input ! type_ text ! name password ! A.id password ! tabindex
2 ! accesskey P
input ! type_ submit ! tabindex 3 ! accesskey S ! value Enter
Nomic!
postLogin :: RoutedNomicServer Html
postLogin = do
methodM POST -- only accept a post method
mbEntry - getData -- get the data
case mbEntry of
Nothing - error $ error: postLogin
Just (LoginPass login password) - do
mpn - liftRouteT $ liftIO $ newPlayerWeb login password
case mpn of
Just pn - do
link - showURL $ Noop pn
seeOther link $ string Redirecting...
Nothing - seeOther (/Login?status=fail :: String) $ string
Redirecting...
launchWebServer :: ServerHandle - IO ()
launchWebServer sh = do
putStrLn Starting web server...\nTo connect, drive your browser to \
http://localhost:8000/Login\;
simpleHTTP nullConf $ implSite http://localhost:8000/; (nomicSite sh)
But when I drive my browser to http://localhost:8000/Login/;, happstack
tell me there is nothing here.
Am I doing it right? If yes, I must have made a mistake.
(as you can see I'm still far from putting in disgestive functors ;)
If you need, the complete application can be found here (see file Web.hs):
https://github.com/cdupont/Nomic
Thanks,
Corentin
On Wed, Jan 19, 2011 at 5:12 PM, Corentin Dupont
corentin.dup...@gmail.comwrote:
Thanks Jeremy.
I had it to work now ;)
Corentin
On Tue, Jan 18, 2011 at 6:01 PM, Jeremy Shaw jer...@n-heptane.com wrote:
Hello,
trhsx will be installed in ~/.cabal/bin, so you will need to add that
to your PATH.
In order to use the demo code I provided you would need the latest
happstack from darcs because it contains a few differences in the API.
The code can be made to work with what is on hackage though.
The submit issue is actually a bug in digestive-functors-blaze. The
return type should be, Form m i e BlazeFormHtml (). jaspervdj is going
to patch it and upload a new version.
- jeremy
On Thu, Jan 13, 2011 at 2:40 PM, Corentin
Re: [Haskell-cafe] Problems installing the haskell platform
On 11-01-19 08:52 AM, Henry Laxen wrote: Greetings. I've been using haskell for about a year now, though I will readily admit I still don't really know what I am doing when I get error messages. Today I decided to reset my haskell environment from scratch, avoiding the debian packages and going straight to the source. 1. Install ghc from http://www.haskell.org/ghc/download_ghc_6_12_3 Success!! ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.3 cabal update Downloading the latest package list from hackage.haskell.org I wonder where you got your cabal from. Certainly not by installing ghc. Looks like an old version you failed to reset when you said reset. Here is why it matters. With ghc 6.12.3 and cabal-install version 0.8.0 using version 1.8.0.2 of the Cabal library, stm-2.1.2.1 does not build. The error is: [4 of 7] Compiling Control.Concurrent.STM.TVar ( Control/Concurrent/STM/TVar.hs, dist/build/Control/Concurrent/STM/TVar.o ) Control/Concurrent/STM/TVar.hs:22:8: Ambiguous occurrence `readTVarIO' It could refer to either `Control.Concurrent.STM.TVar.readTVarIO', defined at Control/Concurrent/STM/TVar.hs:35:0 or `GHC.Conc.readTVarIO', imported from GHC.Conc at Control/Concurrent/STM/TVar.hs:29:0-14 With the same ghc 6.12.3 but cabal-install version 0.8.2 using version 1.8.0.6 of the Cabal library, stm-2.1.2.1 builds fine. If you use Setup.hs, it calls up whichever Cabal library your ghc comes with, which is 1.8.0.6, so stm-2.1.2.1 builds fine too. Why Cabal library 1.8.0.2 caused the error: by generating inferior CPP macros. In dist/build/autogen/cabal_macros.h it scripts: /* package base-4.2.0.2 */ #define MIN_VERSION_base(major1,major2,minor) \ (major1) 4 || \ (major1) == 4 (major2) 2 || \ (major1) == 4 (major2) == 2 (minor) = 0 It wants to provide a macro for testing version numbers of base, but it forgets a pair of defensive parentheses, so some usages will go wrong. Indeed, in TVar.hs: #ifdef __GLASGOW_HASKELL__ import GHC.Conc #else -- doesn't matter to us today #endif #if ! MIN_VERSION_base(4,2,0) readTVarIO = atomically . readTVar #endif If base version is 4.2.0, then GHC.Conc does not provide readTVarIO, and we want to define one ourselves. If base version is =4.2.0 (for example ghc 6.12.3), then GHC.Conc provides readTVarIO, and we want to go with that. But the macro test goes wrong, and we do both. Cabal library 1.8.0.6 generates the macro correctly: /* package base-4.2.0.2 */ #define MIN_VERSION_base(major1,major2,minor) (\ (major1) 4 || \ (major1) == 4 (major2) 2 || \ (major1) == 4 (major2) == 2 (minor) = 0) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Splittable random numbers
Hi cafe, I want to add the ability to use AES-NI instructions on Intel architectures to GHC. Mainly I'd like to do splittable random number generators based on AES as was suggested at the outset of this email. (I met Burton Smith last week and this topic came up.) I was just reading the below thread about the plugin architecture which got me thinking about what the right way to add AES-NI is. (Disregarding for a moment portability and the issue of where to test cpuid...) http://www.haskell.org/pipermail/glasgow-haskell-users/2011-January/019874.html The FFI is always an option. But after reading the first N pages I could come across from google I'm still not totally clear on whether unsafe foreign calls can happen simultaneously from separate Haskell threads (and with sufficiently low overhead for this purpose). I also ran across the phrase compiler primitive somewhere wrt GHC: http://hackage.haskell.org/trac/ghc/wiki/AddingNewPrimitiveOperations Is that the right way to go? Or would the compiler plugin mechanism possibly allowing doing this without modifying mainline GHC? Thanks, -Ryan On Fri, Nov 12, 2010 at 6:26 PM, wren ng thornton w...@freegeek.org wrote: On 11/12/10 5:33 AM, Richard Senington wrote: It does not give the results you would want. This may have something to do with picking good parameters for the mkLehmerTree function. For example, using a random setup, I just got these results result expected range 16.814 expected = 16.0 (1,31) 16.191 expected = 16.5 (1,32) 16.576 expected = 17.0 (1,33) 17.081 expected = 17.5 (1,34) 17.543 expected = 18.0 (1,35) Have you run any significance tests? I wouldn't be surprised to see +/-0.5 as within the bounds of expected randomness. I'm more worried about it seeming to be consistently on the -0.5 end of things, than I am about it not matching expectation (how many samples did you take again?). For small ranges like this, a consistent -0.5 (or +0.5) tends to indicate off-by-one errors in the generator. -- Live well, ~wren ___ 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] windows network programming
On 11-01-21 03:13 AM, Tako Schotanus wrote: Just starting out here so I don't know what I'm doing yet, but this one doesn't compile for me. ping.hs:19:13: parse error on input `-' The original code contains no parse error. When you tranfer it to your editor, you may accidentally change indentation, which causes such parse errors. Some editors add tabs behind your back to confound indentation further. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Splittable random numbers
On Wed, Nov 10, 2010 at 11:33 AM, Lauri Alanko l...@iki.fi wrote: So a naive implementation of split would be: split g = (mkGen seed, g') where (seed, g') = random g (Where mkGen creates a new state from some sufficiently big seed data.) So what is the problem here? What kinds of observable interdependencies between split streams would come up with the above definition using common PRNGs? Are my assumptions about the security of cryptographic PRNGs incorrect, or is the issue simply that they are too expensive for ordinary random number generation? Yeah, I was thinking for any good PRNG this should be fine. We probably want to pull as much internal state as we can from one generator to the other so we may want to use a specialized seed routine that is optimized for a specific PRNG rather than using an Int or something. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Data.Ranges show error
I am getting the following error when trying to do a show on a Ranges object
:-
C:\Languages\Haskellghci rangeTest.hs
GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
[1 of 1] Compiling Main ( rangeTest.hs, interpreted )
Ok, modules loaded: Main.
*Main main
Loading package array-0.3.0.1 ... linking ... done.
Loading package containers-0.3.0.0 ... linking ... done.
Loading package ranges-0.2.3 ... linking ... done.
Ranges [(37*** Exception: stdout: hPutChar: invalid argument (character is
not
in the code page)
*Main
I have attached the test source also :-
import Data.Ranges
test = (ranges [
range 32 33,
range 34 35,
range 37 39
])
main :: IO ()
main = do {
putStrLn (show test)
}
I am probably doing something fundermentaly wrong.
Many thanks in advance,
Aaron
rangeTest.hs
Description: Binary data
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] source line annotations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/19/11 17:43 , Evan Laforge wrote: My preprocessor works well, but occasionally I do have to go in and fix yet another odd corner that came up. Initially I thought I would only simplistically replace tokens and avoid using a full syntax parser, but to really do it correctly a full parser is needed. And of course this is specific to my style (qualified imports) and project. To do this in full generality really requires the compiler's help. Had you looked at the haskell-src-exts package? - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk06TJYACgkQIn7hlCsL25VmugCfVxD0o078PwJx7da1Axnqg2ep TzMAnR4oEkA7S1oOdYWtNiS3WBWgb88i =FbHc -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Applicative = Monad: Call for consensus
uj supplied this:
About the discussion
putStrLn (readLn + (5 :: Int))..
I'll write it as the following line,
importing Control.Applicative
main = (+) readLn (return 3)
They look almost exactly same in my eyes..
On Fri, 21 Jan 2011 11:01:36 -0800, you wrote:
Interesting little paper, Tyson.
You bring up other programming languages and 'ad-hoc systems for
resolving ambiguities'; I agree with you that these systems generally
have no strong theoretical basis, but I'm not sure that's a terribly
bad thing.
I think what a programmer actually wants from ambiguity resolution is
something *predictable*; C++'s system is definitely stretching the
boundaries of predictability, but any case where I have to break out a
calculator to decide whether the compiler is going to choose
specification A or specification B for my program seems like a
failure. I'd much rather the solution wasn't always 'the most
probable' but at least was easy for me to figure out without thinking
too hard.
The goal is to easily know when I have to manually specify ambiguity
resolution and when I can trust the compiler to do it for me. I
didn't completely follow the math in your paper, so maybe it turns out
simply if it was implemented, but it wasn't clear to me. At the
least, I think you should add examples of the types of ambiguity
resolution you'd like the compiler to figure out and what your
probability measure chooses as the correct answer in each case.
Anyways, thanks for the interesting read. I'm excited to see work on
making a better type *inference* system, since much of the work lately
seems to be on making a better *type* system at the cost of more often
manually specifying types.
I work in a traditional programming industry, and most of the people
from work that I talk to about Haskell are frustrated that they can't
just write putStrLn (readLn + (5 :: Int)) and have the compiler figure
out where the lifts and joins go. After all, that just works in C[1]!
What's the point of having the most powerful type system in the
universe if the compiler can't use it to make your life easier?
-- ryan
[1] sample program:
int readLn(); // reads a line from stdin and converts string to int
void putStrLn(int x); // prints an int to stdout
void main() { putStrLn(readLn() + 5); }
On Fri, Jan 21, 2011 at 8:43 AM, Tyson Whitehead twhiteh...@gmail.com wrote:
On January 19, 2011 15:28:33 Conor McBride wrote:
In each case, the former has (++) acting on lists of strings as pure
values,
while the latter has (++) acting on strings as values given in
[]-computations.
The type [String] determines a domain, it does not decompose uniquely
to a
notion of computation and a notion of value. We currently resolve this
ambiguity by using one syntax for pure computations with [String] values
and a different syntax for [] computations with String values.
Just as we use newtypes to put a different spin on types which are
denotationally the same, it might be worth considering a clearer (but
renegotiable) separation of the computation and value aspects of types,
in order to allow a syntax in which functions are typed as if they act
on
*values*, but lifted to whatever notion of computation is ambient.
Yes. ?That makes sense. ?Thank you both for the clarification. ?The idea of
explicitly separating the two aspects of types is an interesting one.
The automated approach I had been thinking of was to always take the simplest
context possible. ?(i.e., for the above, list of strings as pure values).
To this end I've been working on a measure for the complexity of the
application operator. ?I've got a draft at
http://www.sharcnet.ca/~tyson/haskell/papers/TypeShape.pdf
I'm still working on my thinking on polymorphic types though, so everything
from section 2.2 onwards is subject to change (especially 2.3 and the
conclusion).
Cheers! ?-Tyson
___
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
--
Regards,
Casey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Splittable random numbers
I'm not too familiar with all the Haskell API's for RNGs. This is the first time I've looked at CryptoRandomGen, but I can see the benefit of having a bytestring interface rather than the System.Random Int based one. Is there a reason that the AES implementation in the AES or crypto packages can't be ripped out and repackage in the way you would like? Cheers, -Ryan On Fri, Jan 21, 2011 at 6:11 PM, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: Ryan, If you make an AES based RNG then consider making an instance for CryptoRandomGen (see DRBG [1] for example instances). Such an instance means you can use splitGen [2], which can split generators in the manner described in this thread. If you make the RNG match NIST SP 800-90 then feel free to send it to me for inclusion in the DRBG package, I've been meaning to make the block cipher based DRBG for a while now. Finally, any implementation of AES (using NI or not) could probably go in its own package or a cipher-specific package like CryptoCipher[3]. Its a shame we don't have an AES implementation on Hackage that 1) exposes the fundamental block interface instead of some higher-level wrapping and 2) isn't tied to a large library. Cheers, Thomas [1] http://hackage.haskell.org/package/DRBG and http://hackage.haskell.org/packages/archive/DRBG/0.1.2/doc/html/src/Crypto-Random-DRBG.html#HmacDRBG [2] http://hackage.haskell.org/packages/archive/crypto-api/0.3.1/doc/html/Crypto-Random.html#v:splitGen [3] http://hackage.haskell.org/package/cryptocipher On Fri, Jan 21, 2011 at 2:19 PM, Ryan Newton rrnew...@gmail.com wrote: Hi cafe, I want to add the ability to use AES-NI instructions on Intel architectures to GHC. Mainly I'd like to do splittable random number generators based on AES as was suggested at the outset of this email. (I met Burton Smith last week and this topic came up.) I was just reading the below thread about the plugin architecture which got me thinking about what the right way to add AES-NI is. (Disregarding for a moment portability and the issue of where to test cpuid...) http://www.haskell.org/pipermail/glasgow-haskell-users/2011-January/019874.html The FFI is always an option. But after reading the first N pages I could come across from google I'm still not totally clear on whether unsafe foreign calls can happen simultaneously from separate Haskell threads (and with sufficiently low overhead for this purpose). I also ran across the phrase compiler primitive somewhere wrt GHC: http://hackage.haskell.org/trac/ghc/wiki/AddingNewPrimitiveOperations Is that the right way to go? Or would the compiler plugin mechanism possibly allowing doing this without modifying mainline GHC? Thanks, -Ryan On Fri, Nov 12, 2010 at 6:26 PM, wren ng thornton w...@freegeek.org wrote: On 11/12/10 5:33 AM, Richard Senington wrote: It does not give the results you would want. This may have something to do with picking good parameters for the mkLehmerTree function. For example, using a random setup, I just got these results result expected range 16.814 expected = 16.0 (1,31) 16.191 expected = 16.5 (1,32) 16.576 expected = 17.0 (1,33) 17.081 expected = 17.5 (1,34) 17.543 expected = 18.0 (1,35) Have you run any significance tests? I wouldn't be surprised to see +/-0.5 as within the bounds of expected randomness. I'm more worried about it seeming to be consistently on the -0.5 end of things, than I am about it not matching expectation (how many samples did you take again?). For small ranges like this, a consistent -0.5 (or +0.5) tends to indicate off-by-one errors in the generator. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Glasgow-haskell-users mailing list glasgow-haskell-us...@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Splittable random numbers
On Wed, Nov 10, 2010 at 11:33 AM, Lauri Alanko l...@iki.fi wrote: So a naive implementation of split would be: split g = (mkGen seed, g') where (seed, g') = random g Just to be clear, that is the same as Burton Smith's original proposal that Simon mentioned at the outset, right? Specifically, Smith's proposal is yours instantiated with a crypto based PRNG? So, except for the silliness of generating 128 random bits to make an Int, the following would implement the strategy using the crypto package on Hackage, correct? -- import Codec.Encryption.AES import Data.LargeWord import System.Random data RNG = RNG Word128 Word128 deriving Show next128 (RNG k c) = (encrypt k c, RNG k (c+1)) instance RandomGen RNG where next g = (fromIntegral n, g') where (n,g') = next128 g split g@(RNG k c) = (g', RNG n 0) where (n,g') = next128 g -- The reason I brought up AES-NI was that doing AES in hardware would allow about an 8X improvement over the best software implementation (~2 cycles per byte encrypted). Comparison would be warranted, but perhaps it could make the crypto based PRNG efficient enough for day-to-day use. Best, -Ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
