Re: [Haskell-cafe] Where is the pairing-with-monoid monad instance?
On Wed, Jan 11, 2012 at 03:23, Conal Elliott wrote: Is the standard pair-with-monoid monad instance in some standard place? I see the Applicative instance in Control.Applicative, and the pair-with-monoid Functor instance in Control.Monad.Instances, and the (-) e and Either e monad instances also in Control.Monad.Instances. I'm looking for something like instance Monoid o = Monad ((,) o) where return a= (mempty,a) (o,a) = f = (o `mappend` o', b) where (o',b) = f a Where is it hiding from me? http://hackage.haskell.org/packages/archive/transformers/0.2.2.0/doc/html/Control-Monad-Trans-Writer-Lazy.html#t:WriterT? Regards, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC exceeding command line length limit with split-objs - and a possible fix
I used https://github.com/kennethreitz/osx-gcc-installer/downloads to get a real gcc on Lion. Biggish download, but it worked. I've also seen reports of success by self-compiling gcc, or by installing XCode 4 on top of an existing XCode 3 installation. John L. From: Eugene Kirpichov ekirpic...@gmail.com Oh well... looks like building ghc won't be easy, as it doesn't build with llvm-gcc and it's not easy to get a real gcc on Lion. But I don't stop trying :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC exceeding command line length limit with split-objs - and a possible fix
On 11 Jan 2012, at 13:38, John Lato wrote: I used https://github.com/kennethreitz/osx-gcc-installer/downloads to get a real gcc on Lion. Biggish download, but it worked. I've also seen reports of success by self-compiling gcc, or by installing XCode 4 on top of an existing XCode 3 installation. GCC 4.6.2 builds on OS X 10.7 with Xcode 4.2. Build GMP 5.0.2 with clang, and then GCC with /usr/bin/gcc - llvm-gcc-4.2. I think I saw someone guild GCC 4.7, but this is highest stable. Hans From: Eugene Kirpichov ekirpic...@gmail.com Oh well... looks like building ghc won't be easy, as it doesn't build with llvm-gcc and it's not easy to get a real gcc on Lion. But I don't stop trying :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC exceeding command line length limit with split-objs - and a possible fix
Thanks, looks like I already succeeded by downloading xcode 3. Now my original question remains - is such a change a good idea? (I've already found the place in code where the fix has to be made; should take an hour of work at most) On Wed, Jan 11, 2012 at 6:07 PM, Hans Aberg haber...@telia.com wrote: On 11 Jan 2012, at 13:38, John Lato wrote: I used https://github.com/kennethreitz/osx-gcc-installer/downloads to get a real gcc on Lion. Biggish download, but it worked. I've also seen reports of success by self-compiling gcc, or by installing XCode 4 on top of an existing XCode 3 installation. GCC 4.6.2 builds on OS X 10.7 with Xcode 4.2. Build GMP 5.0.2 with clang, and then GCC with /usr/bin/gcc - llvm-gcc-4.2. I think I saw someone guild GCC 4.7, but this is highest stable. Hans From: Eugene Kirpichov ekirpic...@gmail.com Oh well... looks like building ghc won't be easy, as it doesn't build with llvm-gcc and it's not easy to get a real gcc on Lion. But I don't stop trying :) -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC exceeding command line length limit with split-objs - and a possible fix
Hi Eugene, I think I did run into this problem before, and had to turn of split-objs temporarily to work around it. I'd appreciate a fix. Best, Ozgur On 11 January 2012 14:14, Eugene Kirpichov ekirpic...@gmail.com wrote: Now my original question remains - is such a change a good idea? (I've already found the place in code where the fix has to be made; should take an hour of work at most) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Code generation and optimisation for compiling Haskell
Based on your stated background, the best start would be the (longer) paper on the Spineless Tagless G-machine [1]. It describes how graph reduction is actually implemented efficiently. Since then there have been two major changes to this basic implementation: Use of eval/apply (a different calling convention) [2] and constructor tagging [3] (which drastically reduces the number of indirect branches from the original STG approach). In addition to this fairly low-level stuff, there are very powerful optimisations performed at a higher level. For a taste see stream fusion [4]. If you're done with these, feel free to ask for more. :) [1]: http://research.microsoft.com/apps/pubs/default.aspx?id=67083 [2]: http://research.microsoft.com/en-us/um/people/simonpj/papers/eval-apply/ [3]: http://research.microsoft.com/en-us/um/people/simonpj/papers/ptr-tag/index.htm [4]: http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.104.7401 On 10 January 2012 17:25, Steve Horne sh006d3...@blueyonder.co.uk wrote: Although I'm far from being an expert Haskell programmer, I think I'm ready to look into some of the details of how it's compiled. I've a copy of Modern Compiler Design (Grune, Bal, Jacobs and Langendoen) - I first learned a lot of lexical and parsing stuff from it quite a few years ago. Today, I started looking through the functional languages section - I've read it before, but never absorbed much of it. Graph reduction, lambda lifing, etc - it seems pretty simple. Far too simple. It's hard to believe that decent performance is possible if all the work is done by a run-time graph reduction engine. Simon Peyton Jones has written a couple of books on implementing functional languages which are available for free download. At a glance, they seem to covers similar topics in much more detail. However, they're from 1987 and 1992. Considering SPJs period of despair when he couldn't get practical performance for monadic I/O, these seem very dated. Some time ago, I made a note to look up the book Functional Programming and Parallel Graph Rewriting (I forget why) but again that's from the early 90's. I've also got a note to look up Urban Boquists thesis. SPJ also has some papers on compilation - http://research.microsoft.com/en-us/um/people/simonpj/papers/papers.html#compiler - and the papers on optimisation by program transformation have caught my eye. Are there any current text-books that describe the techniques used by compilers like GHC to generate efficient code from functional languages? It's OK to assume some knowledge of basic compiler theory - the important stuff is code generation and optimisation techniques for lazy functional languages in particular. Also, what papers should I read? Am I on the right lines with the ones I've mentioned above? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Push the envelope. Watch it bend. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Unboxed Rationals?
I have a program which does a lot of computations with Array's of rationals. In order to get better performance I'd like to use unboxed arrays, but, since (Ratio Int) isn't a primitive type this doesn't work. It occured to me that I could rewrite this using -fglasgow-exts where I represent a rational by (# Int, Int #). It isn't too hard to do this, but I'd like to know it it's already in some library out there, so that I can use something already existing. This is a more general problem that I have (I'm pretty new to Haskell) of finding a library to do X. Victor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unboxed Rationals?
You can use Data.Vector.Unboxed. There isn't an instance for Ratio a, but it is easy to write one, since it would be very similar to Complex a. http://hackage.haskell.org/packages/archive/vector/0.9.1/doc/html/Data-Vector-Unboxed.html#t:Unbox ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unboxed Rationals?
Also, uvector already supports unboxed Ratios: http://hackage.haskell.org/package/uvector In fact, I am surprised that Data.Vector doesn't have a Ratio instance, but has a Complex instance. Any ideas, why? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC exceeding command line length limit with split-objs - and a possible fix
On Wed, Jan 11, 2012 at 02:12, Eugene Kirpichov ekirpic...@gmail.comwrote: I think a nice fix would be to employ gcc's ability to read options from a file - gcc @file - and write overly long option strings into temp files. What immediately occurs to me is, what if the problem (or another manifestation of same) occurs in the ld step? OS X's ld(1) doesn't have such an option /per se/, and binutils ld(1) does not reliably create valid Mach-O objects. I would consider batching split-objs files into static archives (see ar(1) and ranlib(1)). This also has the advantages of being portable (other platforms other have length limits; I believe it's the main reason split-objs is disabled by default on e.g. Solaris) and that with many linkers it's faster than individual objects because it can use the archive table of contents to speed up searching for files and symbols. -- 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] GHC exceeding command line length limit with split-objs - and a possible fix
Hi Brandon, Thanks - looks like this would be a modification of the linking stage, splitting it into two parts: batching objects and then actually linking them. Do you think that what I originally proposed is still a good thing to have before implementing your solution? (it definitely would be for myself, as it's easier to do and I'd then quicker become able to build my application with split-objs and shrink its executable size from 11 to 2Mb) On Wed, Jan 11, 2012 at 9:48 PM, Brandon Allbery allber...@gmail.comwrote: On Wed, Jan 11, 2012 at 02:12, Eugene Kirpichov ekirpic...@gmail.comwrote: I think a nice fix would be to employ gcc's ability to read options from a file - gcc @file - and write overly long option strings into temp files. What immediately occurs to me is, what if the problem (or another manifestation of same) occurs in the ld step? OS X's ld(1) doesn't have such an option /per se/, and binutils ld(1) does not reliably create valid Mach-O objects. I would consider batching split-objs files into static archives (see ar(1) and ranlib(1)). This also has the advantages of being portable (other platforms other have length limits; I believe it's the main reason split-objs is disabled by default on e.g. Solaris) and that with many linkers it's faster than individual objects because it can use the archive table of contents to speed up searching for files and symbols. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC exceeding command line length limit with split-objs - and a possible fix
On Wed, Jan 11, 2012 at 14:50, Eugene Kirpichov ekirpic...@gmail.comwrote: Do you think that what I originally proposed is still a good thing to have before implementing your solution? (it definitely would be for myself, as it's easier to do and I'd then quicker become able to build my application with split-objs and shrink its executable size from 11 to 2Mb) Only if it works; my expectation is that all you will accomplish is to move the failure point, as the command line for ld is usually larger than the one for gcc. It is possible that gcc will do something to deal with it itself, but I have a suspicion that only works (if it does) with binutils ld, which is not usable on OS X. BTW, I'm actually suggesting that split-objs create an archive, where non-split-objs creates an object; from there I suspect you wouldn't actually need to handle anything any differently between the two cases (aside from specifying the .a instead of the .o as needed). -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] A simple telnet client using Conduit
Hi all, I've written a simple telnet client using Michael Snoyman's Conduit library and was looking for comments as to whether I'm doing it right. In particular, is my usage of a ResourceT to track a thread a good idea, necessary or waste of time. The code is here: https://gist.github.com/1596792 Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How to terminate the process group of a process created with createProcess?
Hello, (on unix) creating a process A which spawns itself a subprocess B and terminating process A before it finishes leaves process B as a process on its own. This is because terminateProcess sends the sigterm signal to the process only and not to its process group. Is there a way to terminate the process group of process A? Or alternatively is there a way to get he Posix ProcessId of process A? The following is a minimal example. The process sleep 60 survives the termination of both sleep and of the main program. code module Main where import Control.Concurrent import System.Process main = do h@(_, _, _, hProc) - createProcess (proc time [sleep, 60]) threadDelay $ 5 * 100 terminateProcess hProc waitForProcess hProc /code Kind regards, André ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to terminate the process group of a process created with createProcess?
On Wed, Jan 11, 2012 at 16:26, André Scholz andre.sch...@uni-bremen.dewrote: (on unix) creating a process A which spawns itself a subprocess B and terminating process A before it finishes leaves process B as a process on its own. This is because terminateProcess sends the sigterm signal to the process only and not to its process group. terminateProcess passes on the semantics of kill(2); on SVID-compliant (and I think POSIX.1-compliant) systems, the negative of the process group leader's process ID is used to signal the process group. Note that you may need to arrange for your initial child process to invoke setpgrp() to insure that the parent program is not part of the process group. However I'm unclear as to the situation you are encountering, as your example does not appear to be spawning an intermediate process. -- 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] How to terminate the process group of a processcreated with createProcess?
Quoth Brandon Allbery allber...@gmail.com, ... terminateProcess passes on the semantics of kill(2); on SVID-compliant (and I think POSIX.1-compliant) systems, the negative of the process group leader's process ID is used to signal the process group. Note that you may need to arrange for your initial child process to invoke setpgrp() to insure that the parent program is not part of the process group. ... and that stuff can be found in System.Posix.Process. Support for POSIX killpg can be found in System.Posix.Signals, by the way in case you think that would make your intention more transparent. However I'm unclear as to the situation you are encountering, as your example does not appear to be spawning an intermediate process. I missed that at first myself -- he actually invokes time sleep 60. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unboxed Rationals?
On 11/01/2012, at 17:00, Artyom Kazak wrote: In fact, I am surprised that Data.Vector doesn't have a Ratio instance, but has a Complex instance. Any ideas, why? Nobody has asked for it so far. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A simple telnet client using Conduit
On line 29, instead of liftIO $ do mapM_ ... runResourceT $ do ... ... why not liftIO $ mapM_ ... ... ... ? Regarding threads, you should use resourceForkIO [1] which has a quite nicer interface. So you telnet would end like: telnet :: String - Int - IO () telnet host port = runResourceT $ do (releaseSock, hsock) - with (connectTo host $ PortNumber $ fromIntegral port) hClose liftIO $ mapM_ (\h - hSetBuffering h LineBuffering) [ stdin, stdout, hsock ] resourceForkIO $ sourceHandle stdin $$ sinkHandle hsock sourceHandle hsock $$ sinkHandle stdout release releaseSock Disclaimer: code not tested =). Cheers, [1] http://hackage.haskell.org/packages/archive/conduit/0.0.2/doc/html/Control-Monad-Trans-Resource.html#v:resourceForkIO -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A simple telnet client using Conduit
Thanks for the input Felipe. Felipe Almeida Lessa wrote: On line 29, instead of liftIO $ do mapM_ ... runResourceT $ do Well that was because that whole block needs to run in IO. Regarding threads, you should use resourceForkIO [1] which has a quite nicer interface. I did read about resourceForkIO and it says: Introduce a reference-counting scheme to allow a resource context to be shared by multiple threads. Once the last thread exits, all remaining resources will be released. In my case, I don't have any resources that are shared between threads. All I have is the actual ThreadId returned by forkIO. Since that ThreadId actually isn't used explicitly anywhere (but is implicitly passed to killThread when release releaseThread is called). The other thing about your solution is the question of what happens to the ThreadId returned by resourceForkIO. Rewriting your solution to explicity handle the ThreadId I get: telnet :: String - Int - IO () telnet host port = runResourceT $ do (releaseSock, hsock) - with (connectTo host $ PortNumber $ fromIntegral port) hClose liftIO $ mapM_ (\h - hSetBuffering h LineBuffering) [ stdin, stdout, hsock ] tid - resourceForkIO $ sourceHandle stdin $$ sinkHandle hsock sourceHandle hsock $$ sinkHandle stdout liftIO $ killThread tid release releaseSock The problem here is that I am not sure if the explicit killThread is actually needed and it is, I think my solution, where killThread happens automatically is actually better. If what happens within the outer call to resourceT is a long running process, your solution (in the absence of the explicit killThread) could leave threads lying around that would have been cleaned up much earlier in my soltuion. Thoughts? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A simple telnet client using Conduit
A new solution that drops two 'runResourceT' calls: telnet :: String - Int - IO () telnet host port = runResourceT $ do (releaseSock, hsock) - with (connectTo host $ PortNumber $ fromIntegral port) hClose liftIO $ mapM_ (\h - hSetBuffering h LineBuffering) [ stdin, stdout, hsock ] (releaseThread, _) - with (forkIO $ runResourceT $ sourceHandle stdin $$ sinkHandle hsock) killThread sourceHandle hsock $$ sinkHandle stdout release releaseThread release releaseSock Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A simple telnet client using Conduit
On Wed, Jan 11, 2012 at 10:28 PM, Erik de Castro Lopo mle...@mega-nerd.com wrote: Thanks for the input Felipe. Felipe Almeida Lessa wrote: On line 29, instead of liftIO $ do mapM_ ... runResourceT $ do Well that was because that whole block needs to run in IO. My point is that the second runResourceT is not necessary. Regarding threads, you should use resourceForkIO [1] which has a quite nicer interface. I did read about resourceForkIO and it says: Introduce a reference-counting scheme to allow a resource context to be shared by multiple threads. Once the last thread exits, all remaining resources will be released. In my case, I don't have any resources that are shared between threads. All I have is the actual ThreadId returned by forkIO. Since that ThreadId actually isn't used explicitly anywhere (but is implicitly passed to killThread when release releaseThread is called). Actually, hsock is shared between both threads. With your original code, it gets closed regardless of what the other thread is doing. Which in this case is what you want, but you need to be careful. The other thing about your solution is the question of what happens to the ThreadId returned by resourceForkIO. Rewriting your solution to explicity handle the ThreadId I get: telnet :: String - Int - IO () telnet host port = runResourceT $ do (releaseSock, hsock) - with (connectTo host $ PortNumber $ fromIntegral port) hClose liftIO $ mapM_ (\h - hSetBuffering h LineBuffering) [ stdin, stdout, hsock ] tid - resourceForkIO $ sourceHandle stdin $$ sinkHandle hsock sourceHandle hsock $$ sinkHandle stdout liftIO $ killThread tid release releaseSock The problem here is that I am not sure if the explicit killThread is actually needed [...] What about inverting which thread gets to do what? _ - resourceForkIO $ sourceHandle hsock $$ sinkHandle stdout sourceHandle stdin $$ sinkHandle hsock release releaseSock My reasoning is that: - 'sourceHandle stdin' will close after the user presses ^D, thereby reaching 'release releaseSock'. - After the socket is closed, 'sourceHandle hsock' will close as well, killing the thread. Note that without 'release releaseSock' the socket would not be closed until the other thread died. [...] and it is, I think my solution, where killThread happens automatically is actually better. If what happens within the outer call to resourceT is a long running process, your solution (in the absence of the explicit killThread) could leave threads lying around that would have been cleaned up much earlier in my soltuion. Actually, I'm not sure if my solution is better or worse than yours. The question is how long does it take for the thread to die after hsock gets closed? If the answer is right away, then my solution is simpler =). Otherwise, you solution is less resource-hungry. Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A simple telnet client using Conduit
Felipe Almeida Lessa wrote: What about inverting which thread gets to do what? _ - resourceForkIO $ sourceHandle hsock $$ sinkHandle stdout sourceHandle stdin $$ sinkHandle hsock release releaseSock Thats an interesting idea. Unfortunately this doesn't work correctly in that if the server disconnects, the client doesn't detect it and hangs with one end of the connection closed. Actually, I'm not sure if my solution is better or worse than yours. The question is how long does it take for the thread to die after hsock gets closed? If the answer is right away, then my solution is simpler =). Otherwise, you solution is less resource-hungry. Well GHC runtime threads are very cheap while sockets/file descriptors are in comparison a very much limited resource. That means that code should be written to clean up sockets/fds in preference to cleaning up threads. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How to catch all exceptions that could be caught?
Hi, With Prelude.catch, I could write catch () $ \_ - return Nothing. But with Control.Exception.catch, I must specify a type for the _. What should I do? PS: In Java document, a function declaration would tell us both the incoming args and outgoing, AND what exceptions would it throw. But it does not seem to exist in Haskell document? And the most awful part is that even when the program failed with error message, I still did not know what exception was this. Take recv: does not exist (Connection refused) for example. -- 竹密岂妨流水过 山高哪阻野云飞 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to catch all exceptions that could be caught?
On 01/12/12 13:03, Magicloud Magiclouds wrote: Hi, With Prelude.catch, I could write catch () $ \_ - return Nothing. But with Control.Exception.catch, I must specify a type for the _. What should I do? Use SomeException for the type, as it is the base of the exception hierarchy. (Although Haskell does not have classes in the OOP sense and therefore does not have a built-in means of expressing subtype relations, it emulates this in a somewhat awkward manner for exceptions.) Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] decoupling type classes
Hi all, I have an idea about type classes that I have been experimenting. It appears to be a generalization to Haskell’s type classes and seems to be doable. It seems to related the three ideas: type classes, implicit parameters, and (typed) dynamic scoping. But I don't know whether it is good or not. I hope to get some opinions before going further. Basically, Haskell’s type classes passes dictionaries around. Each dictionary contains one or more “methods”. When “names” which belong to a dictionary are called, we invoke functions that match its principle type in the call site's scope. I have an experimental system which “decouples” the dictionary. Instead of passing on a dictionary, it passes individual “implicit parameters around. Those implicit parameters are type inferenced and they can contain type parameters just as methods in a type class. Similarly, they are resolved by their types in the call site's scope. The convenience of this approach compared to Haskell’s type classes is that we no longer require a user of a type class to define ALL the methods in a type class. For example, a user could just define a method + without defining other methods in the Num class: -, *, … He can use the method + independently. For example, if + is defined on the String type to be concatenation, we can use + in another function: weirdConcat x y = x + y + y This has a utility, because the methods in the Num class don’t “make sense” for Strings except +, but the current type class design requires us to define them. Note here that weirdConcat will not have the type (Num a) = a - a - a, since we no longer have the Num class, it is decoupled into separate methods. There is another benefit of this decoupling: it can subsume the functionality of MPTC. Because the methods are no longer grouped, there is no “common” type parameter to the methods. Thus we can easily have more than one parameter in the individual methods and conveniently use them as MPTC methods. SOME IMPLEMENTATION DETAILS Here is how it can be implemented. When we see an “undefined” variable in a function definition which has been declared as “overloaded function”, we store the function name, and the type variables that are associated with it. For example, overload g — (explicitly declare g as an overloaded function) f x y (String s) = … … let z = g x s y in … … We don’t know what x and y are, but we know from the body of f that their types satisfy this pattern: g ’a String ’b. Thus we store this pattern constraint as an extra (implicit) argument in the type of f: f :: a → b → String (exist g: g a String b) We may have multiple such arguments. At the call sites of f, we look for a function g in the scope that satisfies the pattern g ‘a String ’b, but we don’t pass on the substitution, so they remain polymorphic. Once found, the function is passed as an extra parameter to f. This is essentially dictionary passing, but without grouping. It can be also more efficient because the parameters may be stored in registers. Here g is explicitly declared as “overloaded”, although my experimental system doesn’t need this. Any undefined variable inside function body automatically becomes overloaded. This may cause unintended overloading and it catches bugs late. That’s why we need the “overload” declarations. But the automatic overloading of the undefined may be useful in certain situations. For example, if we are going to use Haskell as a shell language. Every “command” must be evaluated when we type them. If we have mutually recursive definitions, the shell will report “undefined variables” either way we order the functions. The automatic overloading may solve this problem. The undefined variables will temporarily exist as automatic overloaded functions. Once we actually define a function with the same name AND satisfies the type constraints, they become implicit parameters to the function we defined before. If we call a function whose implicit parameters are not associated, the shell reports error very similar to Haskell’s “type a is not of class Num …” RELATIONSHIP TO DYNAMIC SCOPING It seems to be helpful to think of the “method calls” as referencing dynamically scoped variables. They are dispatched depending on the bindings we have in the call site's scope (and not the scope where the method is defined!). So it is very much similar to the much-hated dynamic scoping. But the dispatching is more disciplined — it doesn't just match the name. It must match both the name and the inferred principle type. This intuition also explains why local instances shouldn't be allowed, because if we capture the variables at the definition site, the method call becomes statically scoped. -- yin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to catch all exceptions that could be caught?
On 12 January 2012 17:34, Gregory Crosswhite gcrosswh...@gmail.com wrote: On 01/12/12 13:03, Magicloud Magiclouds wrote: Hi, With Prelude.catch, I could write catch () $ \_ - return Nothing. But with Control.Exception.catch, I must specify a type for the _. What should I do? Use SomeException for the type, as it is the base of the exception hierarchy. But it is usually recommended that you *don't* do this, as it even captures Ctrl-c invocations: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html#g:4 -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to catch all exceptions that could be caught?
Yes, that is a problem. But consider my PS in original mail, I have no idea what exception should I catch. Where could I get that information? On Thu, Jan 12, 2012 at 2:49 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 12 January 2012 17:34, Gregory Crosswhite gcrosswh...@gmail.com wrote: On 01/12/12 13:03, Magicloud Magiclouds wrote: Hi, With Prelude.catch, I could write catch () $ \_ - return Nothing. But with Control.Exception.catch, I must specify a type for the _. What should I do? Use SomeException for the type, as it is the base of the exception hierarchy. But it is usually recommended that you *don't* do this, as it even captures Ctrl-c invocations: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html#g:4 -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- 竹密岂妨流水过 山高哪阻野云飞 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to catch all exceptions that could be caught?
Use SomeException for the type, as it is the base of the exception hierarchy. But it is usually recommended that you *don't* do this, as it even captures Ctrl-c invocations: I think there are situation when it is justified to catch almost all exceptions. And people do that a lot, which often leads to ctrl-c not properly working (e.g. we had this in HUnit before 1.2.4.2). The way I deal with this is: someAction `catches` [ -- Re-throw AsyncException, otherwise execution will not terminate -- on SIGINT (ctrl-c). All AsyncExceptions are re-thrown (not -- just UserInterrupt) because all of them indicate severe -- conditions and should not occur during normal operation. Handler (\e - throw (e :: AsyncException)), Handler (\e - yourHandler $ e :: SomeException) ] Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to catch all exceptions that could be caught?
On 01/12/12 16:49, Ivan Lazar Miljenovic wrote: But it is usually recommended that you *don't* do this, as it even captures Ctrl-c invocations: Is that true in all threads, or just in the main thread? Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to catch all exceptions that could be caught?
On 01/12/12 17:07, Simon Hengel wrote:
I think there are situation when it is justified to catch almost all
exceptions. And people do that a lot, which often leads to ctrl-c not
properly working (e.g. we had this in HUnit before 1.2.4.2).
Indeed, and in fact this situation is a very natural occurrence whenever
you are writing code that takes an arbitrary IO action, executes it, and
then returns either the result or the exception that it threw. The code
that I last used for this took advantage of catchJust and looked roughly
like the following:
execute :: IO a → IO (Either SomeException a)
execute action =
catchJust
(\e → case fromException e of {Just (_ :: AsyncException) → Nothing; _ →
Just e})
(Right $ action)
(return . Left)
Cheers,
Greg
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to catch all exceptions that could be caught?
On 01/12/12 17:23, Gregory Crosswhite wrote:
Indeed, and in fact this situation is a very natural occurrence whenever
you are writing code that takes an arbitrary IO action, executes it, and
then returns either the result or the exception that it threw. The code
that I last used for this took advantage of catchJust and looked roughly
like the following:
execute :: IO a → IO (Either SomeException a)
execute action =
catchJust
(\e → case fromException e of {Just (_ :: AsyncException) → Nothing; _ →
Just e})
(Right $ action)
(return . Left)
Cheers,
Greg
Ugh, I have no idea why the spacing got eaten; it was meant to look like:
execute :: IO a - IO (Either SomeException a)
execute action =
catchJust
(\e - case fromException e of
Just (_ :: AsyncException) - Nothing;
_ - Just e
)
(Right $ action)
(return . Left)
Cheers,
Greg
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to catch all exceptions that could be caught?
On 01/12/12 16:58, Magicloud Magiclouds wrote: Yes, that is a problem. But consider my PS in original mail, I have no idea what exception should I catch. Where could I get that information? In my experience, exceptions fall into three categories. First, when performing IO, some functions throw an exception instead of returning an error code, as is the case for many of the functions in System.IO; however, in these cases the exceptions that can be thrown are clearly documented. Second, when a bug in your code has caused it to reach a point where it can no longer proceed, such as when there is a deadlock, when there is an infinite loop, when you violated a precondition of a pure function by for example calling head on an empty list, etc.; in such cases it is very unlikely that you would even want to catch and gracefully recover from them, so an exception specification would not help you very much anyway. Third, when you are running someone else's code and you want to be able to catch any exceptions it throws so that you can handle the error reporting yourself; in this case the only thing that you care about is whether the exception is an AsyncException or not, since if it is an AsyncException then you should almost certainly should just let it propagate up the call stack rather than dealing with it yourself. Incidentally, in all of these cases catching *all* exceptions is a bad idea unless you really know what you are doing for the reasons that others here have pointed out, so I apologize for misleading you with that suggestion. Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to catch all exceptions that could be caught?
Thank you so much. I was always confused by what exception should I catch. On Thu, Jan 12, 2012 at 3:49 PM, Gregory Crosswhite gcrosswh...@gmail.com wrote: On 01/12/12 16:58, Magicloud Magiclouds wrote: Yes, that is a problem. But consider my PS in original mail, I have no idea what exception should I catch. Where could I get that information? In my experience, exceptions fall into three categories. First, when performing IO, some functions throw an exception instead of returning an error code, as is the case for many of the functions in System.IO; however, in these cases the exceptions that can be thrown are clearly documented. Second, when a bug in your code has caused it to reach a point where it can no longer proceed, such as when there is a deadlock, when there is an infinite loop, when you violated a precondition of a pure function by for example calling head on an empty list, etc.; in such cases it is very unlikely that you would even want to catch and gracefully recover from them, so an exception specification would not help you very much anyway. Third, when you are running someone else's code and you want to be able to catch any exceptions it throws so that you can handle the error reporting yourself; in this case the only thing that you care about is whether the exception is an AsyncException or not, since if it is an AsyncException then you should almost certainly should just let it propagate up the call stack rather than dealing with it yourself. Incidentally, in all of these cases catching *all* exceptions is a bad idea unless you really know what you are doing for the reasons that others here have pointed out, so I apologize for misleading you with that suggestion. Cheers, Greg -- 竹密岂妨流水过 山高哪阻野云飞 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
