On Tue, 21 Feb 2006, John Meacham wrote:
> Yeah, this is why I have held off on a specific design until we get a
> better idea of what the new IO library will look like. I am thinking it
> will have to involve some abstract event source type with primitive
> routines for creating this type from things like handles,fds, or
> anything else we might want to wait on. so it is system-extendable in
> that sense in that implementations can just provide new event source
> creation primitives.
>
> The other advantage of this sort of thing is that you would want things
> like the X11 library to be able to provide an event source for when an
> X11 event is ready to be read so you can seamlessly integrate your X11
> loop into your main one.
>
> The X11 library would create such an event source from the underlying
> socket but just return the abstract event source so the implementation
> can change (perhaps when using a shared memory based system like D11 for
> instance) without affecting how the user uses the library in a portable
> way.
Could an application reasonably choose between several dispatching
systems? For example, I'm working on a Macintosh here, where instead
of X11 Apple provides its NextStep based GUI with its own apparently
fairly well defined event system. I don't know that system very well,
but a MacOS Haskell GUI application would probably want to look in
that direction for event integration. Meanwhile, I might want to
work with kqueue, on the same platform, because it supports filesystem
events along with the usual select stuff.
Donn Cave, [EMAIL PROTECTED]
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
