gmane.comp.lang.haskell.libraries

Re: #2309: containers: specialize functions that fail in a Monad to Maybe

Isaac Dupree — 2008-07-24T15:28:06

Well, what are the guidelines in this case? Proposer's discretion? If a week has gone by and no one has commented further, I guess you should commit the change (or ask someone who can, to do so). At least, the ticket shouldn't be closed until either (1) the patches have been applied (and this stated), or (2) until it's explicitly (or clearly) been dropped with no change made. If the patches are different from what you actually posted before, you might want to first post the actual patches you're planning to apply. -Isaac

Re: agreeing a policy for maintainers and hackageDB

Ross Paterson — 2008-07-23T21:57:00

OK, I think there's broad agreement, except for the minor point of what value to use for unmaintained packages, and most people find it hard to care enough to settle that issue. So I'll just go with the above and clean up later if we ever come to a decision on that point.

Re: proposal #2461: add Traversable generalizations of mapAccumLand mapAccumR

Ross Paterson — 2008-07-23T11:52:44

Yes (actually the applicative functor and its mirror image). Full code in the patch attached to the ticket. Indeed, it's convenient for numbering elements of a container from the left or from the right: mapAccumL (\ n x -> (n+1, (n,x))) 0 mapAccumR (\ n x -> (n+1, (n,x))) 0 zipping with a sufficiently long list: mapAccumL (\ (x:xs) y -> (xs, (x,y))) xs0 and the list versions of these functions are already in Data.List (and the Haskell 98 List module). Probably in Conal or Edward Kmett's libraries. Data.Monoid has the Monoid version.

Re: proposal #2461: add Traversable generalizations of mapAccumLand mapAccumR

David Menendez — 2008-07-23T01:49:29

I take it these would be implemented using a state transformer monad? That is, something along these lines: mapAccumL f a tb = runState (mapM (\b -> State (\a -> f a b)) tb) a Presumably, we don't want to include every possible specialization of 'traverse', but I can imagine it being awkward to simulate mapAccumL/R with a state monad if the actual code is short. Incidentally, is there a Backward applicative functor transfomer defined anywhere? newtype Backward f a = Backward { runBackward :: f a } deriving Functor instance Applicative f => Applicative (Backward f) where pure = Backward . pure (Backward f) <*> (Backward a) = Backward (f <**> a) It shows up in at least one of the early applicative functor papers, and it seems like it would be handy for generalizing things like mapAccumL vs mapAccumR.

proposal #2461: add Traversable generalizations of mapAccumL andmapAccumR

Ross Paterson — 2008-07-22T16:12:48

The proposal is to add the following functions to Data.Traversable, generalizing the list versions in Data.List: -- |The 'mapAccumL' function behaves like a combination of 'fmap' -- and 'foldl'; it applies a function to each element of a structure, -- passing an accumulating parameter from left to right, and returning -- a final value of this accumulator together with the new structure. mapAccumL :: Traversable t => (a -> b -> (a, c)) -> a -> t b -> (a, t c) -- |The 'mapAccumR' function behaves like a combination of 'fmap' -- and 'foldr'; it applies a function to each element of a structure, -- passing an accumulating parameter from right to left, and returning -- a final value of this accumulator together with the new structure. mapAccumR :: Traversable t => (a -> b -> (a, c)) -> a -> t b -> (a, t c) These functions are handy for things like labelling trees, zipping, etc. Deadline: 3 weeks

Re: Proposal: new signal-handling API

Duncan Coutts — 2008-07-22T11:51:22

On Mon, 2008-07-21 at 14:23 -0700, Bryan O'Sullivan wrote: Ah, another good reason to rewrite awaitSignal in terms of addSignalHandler. That's one of the new things with the internal implementation in ghc; it now captures the whole siginfo_t structure (and pushes it down an internal pipe) rather than just the signal number. Duncan

Re: #2309: containers: specialize functions that fail in a Monadto Maybe

Ross Paterson — 2008-07-22T11:29:45

Well, the aim was to make the API safer.

Re: Proposal: new signal-handling API

Bryan O'Sullivan — 2008-07-21T21:23:14

On Sat, Jul 19, 2008 at 10:07 AM, Duncan Coutts worc.ox.ac.uk> wrote: True. Actually, awaitSignal isn't the same as sigwaitinfo; the latter returns the siginfo_t for the received signal.

Re: #2391 Network.listenOn (PortNumber n) Sometimes Picks IPv6

Curt Sampson — 2008-07-21T19:22:01

Personally, I like it. I use it myself when I just need to cons up a quick connection for some TCP stuff that I'll replace later with a proper setup (though I imagine I'll replace that with a library--or I'll have just memorized the API--somwhere around my fifth networking project in Haskell). But what I really imagined that the Network library was used for was student projects that focused on implementing a protocol talking to or listening on a TCP socket, where you wanted to focus on actually doing the protocol rather than the details of binding, name lookup, and so on. For this, it's perfect. The Network library is the equivalent of the bits of IO that are in the Prelude (putStrLn, etc.). Indeed, but consider this: when I run netcat as "nc localhost 4321", I won't be able to connect to the Haskell program listening on that port on my NetBSD machine. Same goes if I use a non-v6 aware telnet with a domain name from any other machine. This is not a theoretical situation; I've twice in the past two wee

Re: #2309: containers: specialize functions that fail in a Monad toMaybe

Nicolas Pouillard — 2008-07-21T13:19:43

_______________________________________________ Libraries mailing list Libraries< at >haskell.org http://www.haskell.org/mailman/listinfo/libraries

Re: #2391 Network.listenOn (PortNumber n) Sometimes Picks IPv6

Aaron Denney — 2008-07-21T12:54:33

Sounds reasonable to me -- my prefered solution would be to deprecate listenOn. But I don't have code using it. OTOH, the stability is "provisional". I think there is room for an easier to use interface than the full Network.Socket, but I don't think listenOn is it. Perhaps more like a parameterizable skeleton server? The same port will of course be connected differently on different machines. I think we're quibling over the meaning of namespace here, but e.g. port 22 is for ssh on both IPv4 and IPv6. And do we also have both Service and Service6 constructors? The same exact issue arises.

Re: #2391 Network.listenOn (PortNumber n) Sometimes Picks IPv6

Curt Sampson — 2008-07-21T11:43:10

If I recall correctly: If you're listening on interface '*', you just call accept() and block. If you want to listen on two separate sockets, you can't do this. You can listen on IPv4 and IPv6 addresses using one socket by using IPv4 to IPv6 translation, but that was what got interesting. I think that this was more or less what you were saying. Anyway, I'm quite happy with having listenOn listen on all interfaces that implement v4 and all interfaces that implement v6; it's just whether it's implementable in some reasonable way that I worry about. And you'll note, for example, we already distinguish between a PortID for listening to "one of v4 or v6, depending on OS" (PortNumber Int) and for listening on Unix domain sockets (UnixSocket String). Well, perhaps the idea there was that if you wanted to start doing this, you should be using Network.Socket instead of Network, anyway. If you bind by hostname (e.g., "localhost") they have separate namespaces. I suppose you could take only addresses, but then

Re[2]: Proposal: Extensible exceptions

Bulat Ziganshin — 2008-07-21T11:10:35

Hello Simon, Monday, July 21, 2008, 3:01:45 PM, you wrote: for me, it's like hot ice :)

Re[4]: Proposal: new signal-handling API

Bulat Ziganshin — 2008-07-21T11:09:29

Hello Duncan, Monday, July 21, 2008, 2:56:24 PM, you wrote: i think that problem is not that they launch threads. they just not have any exception sent to it. exceptions are standard way of cleanup, so exit/signals should send exceptions. to all threads that wants to clean up that, for example, about automatic sending special exceptions EXIT and SIGNAL x, to every haskell thread? i know one problem of this design - sometimes threads should synchronize their cleanup, so subthread cleans first, and superthread next

Re: Proposal: Extensible exceptions

Simon Marlow — 2008-07-21T11:01:45

A useful class of exceptions is those that can occur anywhere, because they arise from external stimulus, such as the user pressing Control-C. We currently lump these into "AsyncExceptions", but I'm not wedded to the name. I just thought I'd point out that it's useful to be able to identify exceptions from this class. Cheers, Simon

Re: Re[2]: Proposal: new signal-handling API

Duncan Coutts — 2008-07-21T10:56:24

On Mon, 2008-07-21 at 02:37 -0400, Brandon S. Allbery KF8NH wrote: And that was my point. That this issue of cleaning up when the program is about to die is a good deal more general than signals or even posix. Currently libs that launch threads have no easy means of getting notified when the main thread is going to exit. This is just as true for exitWith as for posix signals. One can use a withLib function but even that's not easy if not all the libs threads are going to be launched then and there. withLib would have to save some MVar collection of threads and other threads the lib launched would have to be added/removed from the set. Then withLib would send exceptions to all the threads in it's collection. My intuition is that we should look at what erlang does. As I understand it they have something which allows them to tie threads such that when one dies the other dies. Duncan

Re: The NetBSD Foundation Moves to a Two Clause BSD License

Duncan Coutts — 2008-07-21T10:43:03

On Mon, 2008-07-21 at 13:35 +0900, Curt Sampson wrote: Thanks Curt, that was enlightening. Duncan

Re[4]: Proposal: new signal-handling API

Bulat Ziganshin — 2008-07-21T10:12:33

Hello Brandon, Monday, July 21, 2008, 10:37:20 AM, you wrote: well, is it what i'd in mind - not sure which variant is better: when main thread creates new thread, it saves its handle. if this thread creates new one - it does the same again. so when we send exception to main thread, it can do the same to all its subthreads, and so that recursive i've tried to use this model in my program (but not used yet), but not sure that it will really work and will be helpful generally speaking, we have an infrastructure of exception handling. when things go wrong, exception handlers kill files, burn out documents, so on. when signal arrives that means "things goes wrong" it will be wise to have opportunity to do the same. MAY BE, we should have just ability to send some exception to ALL threads in the program? how about adding to GHC API ability to get full list of threads? btw, i have even worse situation - in my program i call Haskell->C->Haskell and when operation should be terminated it's not easy to clea

Re: #2391 Network.listenOn (PortNumber n) Sometimes Picks IPv6

Aaron Denney — 2008-07-21T10:09:06

I don't see why it would introduce any more problems than listening on multiple IPv4 addresses, which is routine. However, this isn't something that listenOn can easily do by itself. The difficulty is, of course, is that listening on multiple points means having to multiplex them and select between them. I had heard that some OSes attempt to make it easier to transparently run old IPv4 programs by interpreting binding to all IPv4 addresses to include binding to IPv6, (or even vice-versa!), making it easy for addresses you don't want bound (say, because you want a different daemon handling it) to be bound. Basically, my position is that listenOn is the wrong interface -- it should take the host addresses as well as the port. The ports are the same namespace -- it shouldn't matter (much) whether TCP is running over IPv4 or IPv6. For a friendly interface, I'd have guessed they'd want to bind to both. But again, that's not trivial to portably shoehorn into one listening socket. When IPv6 is enabled, it

Re: Proposal: new signal-handling API

Simon Marlow — 2008-07-21T09:43:04

It just occurred to me that it would be relatively easy to add back support for blocking signals in a way that makes sense. We could add one MVar per signal, and have every signal handler do something like withMVar sigINT_lock $ \_ -> do ... (implemented under the hood in the API). That would let us provide a way to temporarily disable handlers for particular signals. It would have the effect of serialising the handlers for each signal too, I'm not sure if that's a good thing. We could provide a back door too, perhaps. Cheers, Simon

Re: Proposal: new signal-handling API

Simon Marlow — 2008-07-21T09:10:14

So one reason I wanted to deprecate the old API is that with signals run in separate threads it didn't really make sene. For example, asking for a signal to be ignored isn't useful on its own: there might be signal handlers for that signal already running, or just started and about to run. Blocking signals suffers from the same problem. (I know I left the blocking primitives around in the new API, I should really deprecate them though). Synchronising with signal handlers should be done using ordinary thread synchronisation. Have one big signal lock if you like, or one per signal, or one per handler - it's up to you. It's true that you can't synchronise with other people's signal handlers this way. But I think that's a feature, or at least not a bug. Even using SIG_IGN or sigprocmask() you couldn't stop a handler that had already been started anyway. To do what you describe with SIGINT, you would: - say to the default ^C handler "don't deliver any ^C exceptions until I tell you o