From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id C67677EE99 for ; Mon, 20 Jan 2014 10:51:29 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.214.44; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.214.44 as permitted sender) identity=mailfrom; client-ip=209.85.214.44; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-bk0-f44.google.com) identity=helo; client-ip=209.85.214.44; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-bk0-f44.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8DANfw3FLRVdYslGdsb2JhbABZg0NWqE2SZwEBB4ECCBYOAQEBAQcLCwkSKoIlAQEBAwFAARsSCwEDAQsGBQsNDSEiAREBBQEKEgYTEgcCh1UBAwkIDZtdjFyDCZFTChknAwoVT4RyEQEFDI4iAQFPB4Q4BJgigTKOeRgphFo7gTU X-IPAS-Result: Ah8DANfw3FLRVdYslGdsb2JhbABZg0NWqE2SZwEBB4ECCBYOAQEBAQcLCwkSKoIlAQEBAwFAARsSCwEDAQsGBQsNDSEiAREBBQEKEgYTEgcCh1UBAwkIDZtdjFyDCZFTChknAwoVT4RyEQEFDI4iAQFPB4Q4BJgigTKOeRgphFo7gTU X-IronPort-AV: E=Sophos;i="4.95,689,1384297200"; d="scan'208";a="53976828" Received: from mail-bk0-f44.google.com ([209.85.214.44]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 20 Jan 2014 10:51:29 +0100 Received: by mail-bk0-f44.google.com with SMTP id mz12so729937bkb.31 for ; Mon, 20 Jan 2014 01:51:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Y2RYmjAP6ikcZdncsIXs3BepOdXGLY9gOoIZLasECwY=; b=ON/eAmzEOWcNTa3sVeeWE4+EgGcpyXNez3Z4RDBKkFExEVr7FsVO70Iw0lRsL1b7Lh rpJMrVd90vULnI/We25kkSh8PrNdWmBKjk5e9WUjW/97Nkd6zOkzIqUzsmOY0DpGC7HI n51xFRxIdGRkijXCJfWNgMYCQAPIymN2x/k4mw7MOByUTC/M5MzW5Q80sb2i+ksNDGzh 9Ap+sUWvY3Od/O+1vG8GJy+fkqxdjcFZKJ1/lCTF4GoHlTcbayMnqmORp1nRei8UhHnt iEw6QLfYf3yz5/mSJFrtzDa3AAZd/eMVgjZtdfesJDMAokF7Bg6lCmSbg0cO+NsJVyzX deZQ== X-Received: by 10.204.167.81 with SMTP id p17mr294971bky.59.1390211488583; Mon, 20 Jan 2014 01:51:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.205.45.5 with HTTP; Mon, 20 Jan 2014 01:50:48 -0800 (PST) In-Reply-To: <20140120091242.GC26447@frosties> References: <20140113154808.GA21567@frosties> <20140116083541.GA27229@frosties> <52D84944.8090108@fugmann.net> <20140118113316.GA13285@frosties> <52DC086D.2080508@fugmann.net> <20140120091242.GC26447@frosties> From: Gabriel Scherer Date: Mon, 20 Jan 2014 10:50:48 +0100 Message-ID: To: Goswin von Brederlow Cc: Anders Peter Fugmann , caml users Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Who was working on ocaml bindings for zeromq? > 2) Note the _ there. The type is not polymorphic and gives an error > that it can't be unified or something. Don't have the exact error in > memory. > > I think there is something wrong with the way the socket types are > specified that cause this. First time I ever got that kind of error. This smells like value restriction kicking in because your avstract type is not marked as covariant, as explained for example here: http://www.reddit.com/r/ocaml/comments/t8g2e/pdf_relaxing_the_value_restriction_by_jacques/c4kf68s Note that there is a risk of bad interaction between: - adding a covariance annotation to your phantom type - using polymorphic variants for you phantom type parameter - switching from a purely-phantom to an internally-safe GADT implementation Covariance (or any other annotation) is always accepted for a purely-phantom implementation, but would often be rejected by the type-checker for a corresponding GADT implementation (and would be unsound anymay with many modes of use of polymorphic variants for that purpose). Switching to a GADT implementation is often an excellent idea in the life of a library using phantom types (I have no idea whether that is the case here), so it may be best to avoid variance claims and just add a unit parameter to those values that hit typing problems. On Mon, Jan 20, 2014 at 10:12 AM, Goswin von Brederlow wrote: > On Sun, Jan 19, 2014 at 06:16:29PM +0100, Anders Peter Fugmann wrote: >> Hi Goswin, >> >> Please see my reply below. For completeness your original mail is >> also included in full at the end of the mail. >> >> On 18/01/14 12:33, Goswin von Brederlow wrote: >> >3) sockets have phantom types, use them >> Agreed. >> >> >4) Polling is ugly >> Indeed this could be made simpler. > > Yesterday I actually run into a problem with this. Creating a socket > gave me a odd type (from memory): > > val stream: _[> `Push | `Pull | `Pub | `Sub | `Stream] ZMQ.Socket.t > val dealer: _[> `Push | `Pull | `Pub | `Sub | `Dealer] ZMQ.Socket.t > > A few problems with that: > > 1) A stream socket should be just `Stream. > > 2) Note the _ there. The type is not polymorphic and gives an error > that it can't be unified or something. Don't have the exact error in > memory. > > I think there is something wrong with the way the socket types are > specified that cause this. First time I ever got that kind of error. > > 3) Polling takes an ('a ZMQ.Socket.t, ZMQ.Socket.event) array. Trying > to poll a stream and dealer socket causes type errors. > > I think phantom typed sockets are incompatible with putting them into > an array outside the module. This needs an interface where you have a > poller instance and can add sockets to it one at a time. Internally > the phantom type is known to be "phantom" and the sockets can be put > into an array, hashtbl or list. > > I didn't have time yet to look into those problems. Currently I used > Obj.magic to make it work because I wanted to work on the application > instead of on zmq. But that certainly isn't a solution. > > > So in summary: We need a new polling interface (or phantom typing). > Not just because I don't like it but because it doesn't work for > combining different socket types. > > MfG > Goswin > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs