From: Gabriel Scherer <gabriel.scherer@gmail.com>
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: Anders Peter Fugmann <anders@fugmann.net>,
caml users <caml-list@inria.fr>
Subject: Re: [Caml-list] Who was working on ocaml bindings for zeromq?
Date: Mon, 20 Jan 2014 10:50:48 +0100 [thread overview]
Message-ID: <CAPFanBE=tfFOdMjZ9B+0STnzucga08SOch9N1hCC=gEdR+iQug@mail.gmail.com> (raw)
In-Reply-To: <20140120091242.GC26447@frosties>
> 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
<goswin-v-b@web.de> 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
next prev parent reply other threads:[~2014-01-20 9:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-13 15:48 Goswin von Brederlow
2014-01-13 15:58 ` Daniel Bünzli
2014-01-16 8:35 ` Goswin von Brederlow
2014-01-16 21:04 ` Anders Peter Fugmann
2014-01-18 11:33 ` Goswin von Brederlow
2014-01-19 17:16 ` Anders Peter Fugmann
2014-01-20 9:12 ` Goswin von Brederlow
2014-01-20 9:50 ` Gabriel Scherer [this message]
2014-01-21 9:59 ` Anders Peter Fugmann
2014-01-13 17:02 ` David Sheets
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPFanBE=tfFOdMjZ9B+0STnzucga08SOch9N1hCC=gEdR+iQug@mail.gmail.com' \
--to=gabriel.scherer@gmail.com \
--cc=anders@fugmann.net \
--cc=caml-list@inria.fr \
--cc=goswin-v-b@web.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox