On 05.08 14:32, Frederik Eaton wrote: > > If it is documented maybe it could be done at the level of an > > implicit parameter? > > Do you think implicit parameters are better than TLS?
Implicit parameters are explicit and the type checker guards that they are not undefined (and thus are safe in the presence of callbacks). I haven't used implicit parameters extensively because I prefer the monadic approach. > > I don't consider these very different: > > 1) use one thread from a pre-allocated pool to do a task > > 2) fork a new thread to do the task > > > > With TLS they are vastly different. > > If you don't consider them different, then you can start using (2) > instead of (1). Performance reasons or access to a shared resources. Also 2) would mean in many cases making currently local state global which is not nice. > Can you give the API for your library? I have a hard time imagining > how it could not be obvious that a thread pool is being used. e.g. various withFooResource :: (Foo -> IO a) -> IO a can use worker threads. > > As said before the monadic approach can be quite clean. I haven't used > > implicit parameters that much, so I won't comment on them. > > Perhaps you can give an example? As I said, a single monad won't > suffice for me, because different libraries only know about different > parts of the state. With TLS, one can delimit the scope of parameters > by making the references to them module-internal, for instance. > > With monads, I imagine that I'll need for each parameter > > (1) a MonadX class, with a liftX member > (2) a catchX function > (3) a MonadY instance, for each wrapped monad Y (thus the number of > such instances will be O(n^2) where n is the number of parameters) That is usually the wrong approach. Newtype something like "StateT AppState IO". Use something like: runWithPart :: (AppState -> c) -> (c -> IO a) -> AppM a to define nice actions for different parts of the libraries. Usually this is very easy if one uses combinators and high level constructs and messier if it is hard to find the right combinators. If you look at the various web frameworks in Haskell you will notice that most of them live happily with one monad and don't suffer from problems because of that. > With TLS, I need > > (1) a declaration "x = unsafePerformIO $ newIOParam ..." And don't have any static guarantees that you have done all the proper initialization calls before you use them. In the previous example we were using a lot of libraries using hidden state. How do we guarantee that they have valid values in TLS? Also if we have two pieces of the same per-thread state that we wish to use in one thread (e.g. db-connections) then the TLS approach becomes quite hard. Here is a naive and dirty implementation. The largest problem is that TypeRep is not in Ord. An alternative approach using Dynamic would be possible, but I like the connection between the key and the associated type. http://www.cs.helsinki.fi/u/ekarttun/haskell/TLS/ Not optimized for performance at all. - Einar Karttunen _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
