Hi, I'm the author of ocaml-zmq
On Sun, Apr 3, 2011 at 6:33 PM, Brian Ledger <bpl29 <at> cornell.edu> wrote: > The exemplifying problem in this domain is how to integrate getsockopt and > setsockopt into our interface. OCaml-ZMQ solves this problem by fragmenting > the functions into a set of 21 separately named functions. Each function has > the appropriate argument and result types, so it is impossible for the client > to pass data of the incorrect type to the system. > Caravan solves this problem more elegantly by using an opaque option type. > The option type abstracts the get and set functions of each option, and each > option > is instantiated with the appropriate safety measures for the > client. This keeps intact the original getsockopt and setsockopt functions > with their original arguments both ordered and correct. All that, and the > entire mechanism is invisible to the client! I must say I like your approach very much, however in some cases having 21 methods allows the user to write the code in a more declarative fashion for example "subscribe sock ..." vs "setsockopt sock subscribe ..." or "has_more sock" vs "getsockopt sock rcvmore". > No Build Dependencies > Other than the obvious ZMQ installation, Caravan does not require any > additional libraries to run. This is in contrast to the OCaml-ZMQ project, > which uses an unnecessary Uint library to handle unsigned integer options. Well using Uint keeps the user from passing negative arguments plus respects the type of the original options so I thought it was necessary. Why do you think it is unnecessary? > Error Handling > The ZMQ guide for writing bindings states "The binding should use [the] > standard error mechanism of the language, whether it is error codes, > exceptions, etc." The standard error mechanism in OCaml is the > 'try-raise-with' clause. This obviates the need for zmq_errno, return codes, > and cumbersome error frameworks. However, OCaml-ZMQ is implemented with > error codes anyway. > Caravan maps the POSIX error codes to a series of distinct OCaml exceptions, > which are raised in C when an error is detected. Furthermore, at this > granularity, it was possible to specify for each exception it's > function-specific message as it was declared in the API. This means that > exceptions are more informative, and can be handled using the natural syntax > of OCaml's exception mechanism. Agreed, revamping exceptions is actually in the roadmap. Besides the previous diferences there is another one between the two bindings: ocaml-zmq uses phantom types to prevent the user from calling subscribe, unsubscribe and create devices with the wrong kind of socket, while Caravan just allows that to happen. Why am I bringing up phantom types? Because the phantom types is really the only thing keeping both both bindings from being merged. If the users feel there is no real need for the extra type safety, I'll gladly drop the phantom types, and I'll offer myself to merge the bindings. Best regards Pedro Borges _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
