john: > On Jan 9, 2009, at 9:01 AM, Creighton Hogg wrote: > >2009/1/9 John A. De Goes <[email protected]>: > >> > >>If you're looking for a project to take on, I would suggest > >>starting with > >>the following: > >> > >>A high-level, type-safe AMQP client written in 100% Haskell, which > >>provides > >>a clean way of handling hundreds of unique message types. > >> > >>Then it would be possible to hook it up to any AMQP broker (most > >>likely > >>RabbitMQ). There are logical steps beyond the above (an embedded > >>Haskell > >>broker), but the above project is far from trivial. And the main > >>undertaking, I think, consists not in coding to the spec (for which > >>there is > >>some help; a JSON representation of the AMQP specification can be > >>processed > >>and used to emit language-specific code), but in finding a design > >>that works > >>well in Haskell. > ><snip & reorder> > >I apologize, but my question was geared more towards understanding > >what high-level OTP-like libraries Haskell is lacking, not full blown > >applications that haven't been written in Haskell. It sounded like > >you had some specific insight into this. > > > A Haskell AMQP client is not an application, but a library that > Haskell applications would use (if it existed). The use of the word > "client" refers to the client/server metaphor used in centralized > message broker systems like AMQP. > > Regarding the OTP specifically, Haskell doesn't have anything like it. > Haskell has bits and pieces, but they're not integrated in a single > stack, and much functionality is missing. For example, there's no way > to dynamically poke running Haskell code, to see what it's doing; no > way to update code on the fly as a process is running; no scalable > distributed database system; etc.
There are at least two ways to do dynamic code update, via compiled code, and via bytecode. -- Don _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
