Re: [Haskell-cafe] recursive matrix computations
On 19/04/2006, at 10:32 PM, Andrew U. Frank wrote: it appears possible to define matrix operations like LU- decomposition, SVD, inverse etc. in a recursive fashion (see transpose in the prelude). is this possible? has anybody code in haskell which does this (not asking for high performance here, more instructive value). thank you! I recall Paul Hudak coming up with a version of LU-decomposition in Haskell using Dooliitle's method. This was in response to a challenge by (I think) Arvind, at a meeting in Mystic CT, in 1989. --brian Brian Boutel Wellington New Zealand ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Google SoC
http://code.google.com/soc/ This is not news. SoC was presented a few days ago, and by now there are a lot of projects available, yet none(?) Haskell related :( This is a plea for Haskell FOSS project managers to apply as mentor organizations, so that we students can have a choice. Surely there are a lot of contributions that can be tackled by a motivated student in three months time. GHC related stuff, work in Visual Haskell, tasks in a given Haskell framework, Darcs stuff, you name it. Deadline for mentor organizations is May 1, but they might close it earlier if they get their hands full. pep ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Google SoC
On Fri, 2006-04-21 at 13:50 +0200, Pepe Iborra wrote: > http://code.google.com/soc/ > > This is not news. SoC was presented a few days ago, and by now there are a > lot of projects available, yet none(?) Haskell related :( > This is a plea for Haskell FOSS project managers to apply as mentor > organizations, so that we students can have a choice. > Surely there are a lot of contributions that can be tackled by a motivated > student in three months time. GHC related stuff, work in Visual Haskell, > tasks in a given Haskell framework, Darcs stuff, you name it. > > Deadline for mentor organizations is May 1, but they might close it earlier > if they get their hands full. Fear not! Plans are afoot. Expect an announcement shortly. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Current situation regarding global IORefs
Hi - I've run into the global mutable state problem described in http://www.haskell.org/hawiki/GlobalMutableState Since the page was last edited in March last year, I'm wondering if there have been any developments or further thoughts on how to safely create top level IORefs since they are absolutely essential for the library I'm writing. For my library, which implements a GUI, I have a Manager module which keeps track of which control currently has the keyboard focus etc, and I don't want to have to pass round the state of the manager to every control since this would be monstrously inconvenient and a total waste of space/time, so at the moment I'm reduced to: module Manager where keyboard :: IORef (Maybe Control) {-# NOINLINE keyboard #-} keyboard = unsafePerformIO $ newIORef Nothing The problem is that I don't know if this is guaranteed to be completely safe for all Haskell compilers or even for all future versions of ghc (?) Thanks, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Current situation regarding global IORefs
On Apr 21, 2006, at 9:56 AM, Brian Hulley wrote: Hi - I've run into the global mutable state problem described in http:// www.haskell.org/hawiki/GlobalMutableState Since the page was last edited in March last year, I'm wondering if there have been any developments or further thoughts on how to safely create top level IORefs since they are absolutely essential for the library I'm writing. For my library, which implements a GUI, I have a Manager module which keeps track of which control currently has the keyboard focus etc, and I don't want to have to pass round the state of the manager to every control since this would be monstrously inconvenient and a total waste of space/time, so at the moment I'm reduced to: module Manager where keyboard :: IORef (Maybe Control) {-# NOINLINE keyboard #-} keyboard = unsafePerformIO $ newIORef Nothing The problem is that I don't know if this is guaranteed to be completely safe for all Haskell compilers or even for all future versions of ghc (?) RE: the technique itself, you should also compile the module with - fno-cse. RE: the design, Isn't that bit of state local to a dialog/window/ control group or something? I understand that top level state is a problem in general that needs some sort of solution, but I'm not sure it's the right hammer here As far as I know, the only recent developments in this area are a rumor from the Simons that they are working on some sort of thread- local state which (under some sets of design decisions) can fill the needs of top level state. If you press them, they might be willing to give some details about this. Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Current situation regarding global IORefs
Robert Dockins wrote: On Apr 21, 2006, at 9:56 AM, Brian Hulley wrote: Hi - I've run into the global mutable state problem described in http:// www.haskell.org/hawiki/GlobalMutableState Since the page was last edited in March last year, I'm wondering if there have been any developments or further thoughts on how to safely create top level IORefs since they are absolutely essential for the library I'm writing. For my library, which implements a GUI, I have a Manager module which keeps track of which control currently has the keyboard focus etc, and I don't want to have to pass round the state of the manager to every control since this would be monstrously inconvenient and a total waste of space/time, so at the moment I'm reduced to: module Manager where keyboard :: IORef (Maybe Control) {-# NOINLINE keyboard #-} keyboard = unsafePerformIO $ newIORef Nothing The problem is that I don't know if this is guaranteed to be completely safe for all Haskell compilers or even for all future versions of ghc (?) RE: the technique itself, you should also compile the module with - fno-cse. Thanks RE: the design, Isn't that bit of state local to a dialog/window/ control group or something? I understand that top level state is a problem in general that needs some sort of solution, but I'm not sure it's the right hammer here There is only one GUI for the application and only one control in it can have the keyboard focus so it seems natural to use global state here, but I suppose I could also look into using a state monad. The advantage (perhaps also disadvantage ;-) ) of global state is that it allows me to easily convert all my old C++ singleton classes to Haskell modules... As far as I know, the only recent developments in this area are a rumor from the Simons that they are working on some sort of thread- local state which (under some sets of design decisions) can fill the needs of top level state. If you press them, they might be willing to give some details about this. I was kind of hoping that there would just be a safe, simple way to create a top level monomorphic IORef without having to use a pragma etc. Thanks, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Current situation regarding global IORefs
On Apr 21, 2006, at 10:34 AM, Brian Hulley wrote: Robert Dockins wrote: On Apr 21, 2006, at 9:56 AM, Brian Hulley wrote: Hi - I've run into the global mutable state problem described in http:// www.haskell.org/hawiki/GlobalMutableState Since the page was last edited in March last year, I'm wondering if there have been any developments or further thoughts on how to safely create top level IORefs since they are absolutely essential for the library I'm writing. For my library, which implements a GUI, I have a Manager module which keeps track of which control currently has the keyboard focus etc, and I don't want to have to pass round the state of the manager to every control since this would be monstrously inconvenient and a total waste of space/time, so at the moment I'm reduced to: module Manager where keyboard :: IORef (Maybe Control) {-# NOINLINE keyboard #-} keyboard = unsafePerformIO $ newIORef Nothing The problem is that I don't know if this is guaranteed to be completely safe for all Haskell compilers or even for all future versions of ghc (?) RE: the technique itself, you should also compile the module with - fno-cse. Thanks RE: the design, Isn't that bit of state local to a dialog/window/ control group or something? I understand that top level state is a problem in general that needs some sort of solution, but I'm not sure it's the right hammer here There is only one GUI for the application and only one control in it can have the keyboard focus so it seems natural to use global state here I'd suggest you consider not making those assumptions... they are the kinds of assumptions that can make later code reuse and maintenance more difficult than it should be. (Obviously, if code reuse/ maintenance is a low priority then it doesn't matter). , but I suppose I could also look into using a state monad. The advantage (perhaps also disadvantage ;-) ) of global state is that it allows me to easily convert all my old C++ singleton classes to Haskell modules... Ahhh... the singleton pattern. There is a debate among OO theorists about whether the singleton pattern is actually a good idea. I tend to side with those who say that it is Just Wrong. The reality is that "singletons" are only unique within some scope (OS process, VM, sandbox, whatever). "Global" state is similar; it is always bounded by _something_. I think its always better to make the boundaries explicit and aligned with the problem domain rather than implicit, because the implicit boundaries sometimes/often don't do what you want. As soon as you have an even slightly unusual execution environment, your assumptions can be violated (eg, within Java application containers *shudder*). I have to imagine using, eg, HS plugins with modules containing top-level state could cause all sorts of havoc. As far as I know, the only recent developments in this area are a rumor from the Simons that they are working on some sort of thread- local state which (under some sets of design decisions) can fill the needs of top level state. If you press them, they might be willing to give some details about this. I was kind of hoping that there would just be a safe, simple way to create a top level monomorphic IORef without having to use a pragma etc. I don't think that exists currently. Thanks, Brian. Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Current situation regarding global IORefs
Robert Dockins wrote: On Apr 21, 2006, at 10:34 AM, Brian Hulley wrote: Robert Dockins wrote: On Apr 21, 2006, at 9:56 AM, Brian Hulley wrote: Hi - I've run into the global mutable state problem described in http:// [snip] There is only one GUI for the application and only one control in it can have the keyboard focus so it seems natural to use global state here I'd suggest you consider not making those assumptions... they are the kinds of assumptions that can make later code reuse and maintenance more difficult than it should be. (Obviously, if code reuse/ maintenance is a low priority then it doesn't matter). , but I suppose I could also look into using a state monad. The advantage (perhaps also disadvantage ;-) ) of global state is that it allows me to easily convert all my old C++ singleton classes to Haskell modules... Ahhh... the singleton pattern. There is a debate among OO theorists about whether the singleton pattern is actually a good idea. I tend to side with those who say that it is Just Wrong. [snip] Thanks for the comments. I've now changed everything so that controls use a ManagerM monad which wraps up the state instead of using the IO monad so there are no longer any global variables. It wasn't as difficult as I had thought and as you say it makes everything much more scalable, although at the expense of having to use liftIO in various places. I've defined my state monad by: data MState = MState {keyboard:: !Maybe Control} -- etc - other state here also type ManagerM a = StateT MState IO a and everything works ok. However if I try to use a newtype instead of a type (to completely hide the representation) eg newtype ManagerM a = ManagerM (StateT MState IO a) deriving (Monad, MonadIO, MonadState) it won't compile. Does this mean it is not possible to wrap combined monads in a newtype? I notice that the examples in tutorials I've looked at tend to always just use type instead of newtype. Another point is that I'm not sure what is the "proper" way to represent the state itself ie should each component of the state be a separate IORef to avoid having to copy the whole state each time or is it better practice to just use an immutable record as I've done above? Thanks, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Current situation regarding global IORefs
On Apr 21, 2006, at 1:27 PM, Brian Hulley wrote: Robert Dockins wrote: On Apr 21, 2006, at 10:34 AM, Brian Hulley wrote: Robert Dockins wrote: On Apr 21, 2006, at 9:56 AM, Brian Hulley wrote: Hi - I've run into the global mutable state problem described in http:// [snip] There is only one GUI for the application and only one control in it can have the keyboard focus so it seems natural to use global state here I'd suggest you consider not making those assumptions... they are the kinds of assumptions that can make later code reuse and maintenance more difficult than it should be. (Obviously, if code reuse/ maintenance is a low priority then it doesn't matter). , but I suppose I could also look into using a state monad. The advantage (perhaps also disadvantage ;-) ) of global state is that it allows me to easily convert all my old C++ singleton classes to Haskell modules... Ahhh... the singleton pattern. There is a debate among OO theorists about whether the singleton pattern is actually a good idea. I tend to side with those who say that it is Just Wrong. [snip] Thanks for the comments. I've now changed everything so that controls use a ManagerM monad which wraps up the state instead of using the IO monad so there are no longer any global variables. It wasn't as difficult as I had thought and as you say it makes everything much more scalable, although at the expense of having to use liftIO in various places. This is true, and mildly irritating. One additional (very unfortunate) point is that higher-order IO monad combinators will not work on your monad, eg, the ones in Control.Exception. I hope H' will generalize the types to (use MonadIO) these combinators to make this sort of thing easier, because I think this is a great way to structure programs. *makes mental note to create a ticket for this* Sometimes I also think it would be nice if all the standard lib functions with IO types would instead take arbitrary MonadIO types, so you could avoid having to write down liftIO all the time I've defined my state monad by: data MState = MState {keyboard:: !Maybe Control} -- etc - other state here also type ManagerM a = StateT MState IO a and everything works ok. However if I try to use a newtype instead of a type (to completely hide the representation) eg newtype ManagerM a = ManagerM (StateT MState IO a) deriving (Monad, MonadIO, MonadState) it won't compile. Are you compiling with -fglasgow-exts? You're relying on generalized newtype deriving, which is a GHC extension. http://www.haskell.org/ghc/docs/latest/html/users_guide/type- extensions.html#newtype-deriving If that's not it, what's the error you are getting? Does this mean it is not possible to wrap combined monads in a newtype? I notice that the examples in tutorials I've looked at tend to always just use type instead of newtype. I usually use a newtype myself; but then I usually roll my own monads instead of using monad transformers (not a value judgement, just habit). Another point is that I'm not sure what is the "proper" way to represent the state itself ie should each component of the state be a separate IORef to avoid having to copy the whole state each time or is it better practice to just use an immutable record as I've done above? I usually use immutable records as you have done; it somehow "feels better". Unfortunately, going this way exposes you to the clunkiness of Haskell's record system. If all your record components are declared with a bang, you may be able to coerce the compiler to unbox the record (-funbox-strict-fields, I think), which would prevent copying altogether. Immutable records are also a little nicer to the garbage collector. However, I've never actually tried to measure the performance difference. If you're going to use a record of IORefs, you should probably go with ReaderT instead. Thanks, Brian. Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Current situation regarding global IORefs
On 21/04/06, Brian Hulley <[EMAIL PROTECTED]> wrote: > Robert Dockins wrote: > > On Apr 21, 2006, at 10:34 AM, Brian Hulley wrote: > >> Robert Dockins wrote: > >>> On Apr 21, 2006, at 9:56 AM, Brian Hulley wrote: > >>> > Hi - > I've run into the global mutable state problem described in http:// > >>[snip] > >> > >> There is only one GUI for the application and only one control in > >> it can have the keyboard focus so it seems natural to use global > >> state here > > > > I'd suggest you consider not making those assumptions... they are the > > kinds of assumptions that can make later code reuse and maintenance > > more difficult than it should be. (Obviously, if code reuse/ > > maintenance is a low priority then it doesn't matter). > > > >> , but I suppose I could also look into using a state monad. The > >> advantage (perhaps also disadvantage ;-) ) of global state is that > >> it allows me to easily convert all my old C++ singleton classes to > >> Haskell modules... > > > > > > Ahhh... the singleton pattern. There is a debate among OO theorists > > about whether the singleton pattern is actually a good idea. I tend > > to side with those who say that it is Just Wrong. [snip] > > Thanks for the comments. I've now changed everything so that controls use a > ManagerM monad which wraps up the state instead of using the IO monad so > there are no longer any global variables. It wasn't as difficult as I had > thought and as you say it makes everything much more scalable, although at > the expense of having to use liftIO in various places. > > I've defined my state monad by: > > data MState = MState {keyboard:: !Maybe Control} -- etc - other state here > also > type ManagerM a = StateT MState IO a > > and everything works ok. However if I try to use a newtype instead of a type > (to completely hide the representation) eg > > newtype ManagerM a = ManagerM (StateT MState IO a) deriving (Monad, MonadIO, > MonadState) > > it won't compile. Does this mean it is not possible to wrap combined monads > in a newtype? I notice that the examples in tutorials I've looked at tend to > always just use type instead of newtype. try deriving (Monad, MonadIO, MonadState MState) -- I find that newtype deriving doesn't like guessing at other class parameters, even with the fundeps there. > Another point is that I'm not sure what is the "proper" way to represent the > state itself ie should each component of the state be a separate IORef to > avoid having to copy the whole state each time or is it better practice to > just use an immutable record as I've done above? If you were to use IORefs/MVars, it would likely be enough to use ReaderT instead of StateT, since you likely wouldn't be replacing your mutable cells, just their contents. Both routes are okay -- note that Haskell data structure nodes are usually just bunches of pointers to values (or more properly, code which returns values) anyway, so you should only be copying a few pointers when updates are made. (In a similar way to how replacing the head of a list is constant time and space, and not linear.) - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Current situation regarding global IORefs
Robert Dockins wrote: Are you compiling with -fglasgow-exts? You're relying on generalized newtype deriving, which is a GHC extension. http://www.haskell.org/ghc/docs/latest/html/users_guide/type- extensions.html#newtype-deriving If that's not it, what's the error you are getting? 'MonadState does not have arity 1' (I see now from the docs and from Cale's clause below that the instance declaration would be instance MonadState MState ManagerM where ... hence the need for (MonadState MState) to be written in the deriving clause) Cale Gibbard wrote: try deriving (Monad, MonadIO, MonadState MState) -- I find that newtype deriving doesn't like guessing at other class parameters, even with the fundeps there. Thanks. The other compilation error was caused by the fact that newtype deriving doesn't work in a hs-boot file. I had Control and ManagerM defined in different modules, but when I just merged these into one module, and used Cale's deriving clause, everything now works.. (Perhaps it doesn't really matter about type/newtype in this case anyway since MState is hidden) [suggestions about ReaderT] I think I'll stick with an immutable state record for the moment since there does not seem to be a clear advantage one way or the other, and AFAIK ghc 6.4.2 at the moment does not use a write barrier for IORefs so every intergenerational garbage collection follows every IORef in existence which could slow things down for a large GUI with individual IORefs for each state component. Robert Dockins wrote: Sometimes I also think it would be nice if all the standard lib functions with IO types would instead take arbitrary MonadIO types, so you could avoid having to write down liftIO all the time Thanks for the suggestion - it is certainly a lot better to write liftIO inside my FFI wrappers than each time I use these functions elsewhere. Thanks, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Current situation regarding global IORefs
Brian Hulley wrote: Robert Dockins wrote: Sometimes I also think it would be nice if all the standard lib functions with IO types would instead take arbitrary MonadIO types, so you could avoid having to write down liftIO all the time Thanks for the suggestion - it is certainly a lot better to write liftIO inside my FFI wrappers than each time I use these functions elsewhere. [rearranged] One additional (very unfortunate) point is that higher-order IO monad combinators will not work on your monad, eg, the ones in Control.Exception. I hope H' I see now what you mean. This really kills any attempt to make my own api use MonadIO since things like bracket_ etc are fundamental. Thus the use of IO in Control.Exception has a kind of viral property that destroys all hope of eradicating liftIO from user code... Regards, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How to get Haddock to generate docs for a directory tree of modules
Hi - I've been looking at the docs for Haddock at http://haskell.org/haddock/haddock-html-0.7/index.html but I can't seem to find any option to recursively traverse a directory generating hyperlinked docs for all modules anywhere in the directory or any sub directory etc. Is there a simple undocumented flag I'm missing? Thanks, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Control.Exceptions and MonadIO
Robert Dockins wrote: > One additional (very unfortunate) point is that higher-order IO monad > combinators will not work on your monad, eg, the ones in > Control.Exception. Although that is true in general, for many useful and interesting cases (including ReaderT, the state transformer, and the newtype wrapping of IO) one _can_ use catch, bracket etc. constructs in MonadIO. Please see this message and the follow-up discussion: http://www.haskell.org/pipermail/haskell/2006-February/017547.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe