From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr 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 C7D737FB93 for ; Wed, 2 Mar 2016 15:24:18 +0100 (CET) IronPort-PHdr: 9a23:WK9xrhP7+Wz/y3UMBJgl6mtUPXoX/o7sNwtQ0KIMzox0KPr8rarrMEGX3/hxlliBBdydsKIbzbWM+P2wEUU7or+/81k6OKRWUBEEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i760zceF13FOBZvIaytQ8iJ35vxiLr5ps2bSj4LrQT+SIs6FA+xowTVu5teqqpZAYF19CH0pGBVcf9d32JiKAHbtR/94sCt4MwrqHwI6LoJvvRNWqTifqk+UacQTHF/azh0t4XXskzmRA+E4X8ZGkAfjhNMAAGNuBT/V4v4tijznuV40Siee8bxSOZndy6l6vJPRRigtycGKzNxpGXajeR0lL0B/VSnqgApkN2cW52cKPcrJvCVRtgdX2cUG58JDyE= Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=leo@lpw25.net; spf=None smtp.mailfrom=leo@lpw25.net; spf=None smtp.helo=postmaster@out3-smtp.messagingengine.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of leo@lpw25.net) identity=pra; client-ip=66.111.4.27; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="leo@lpw25.net"; x-sender="leo@lpw25.net"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of leo@lpw25.net) identity=mailfrom; client-ip=66.111.4.27; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="leo@lpw25.net"; x-sender="leo@lpw25.net"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@out3-smtp.messagingengine.com) identity=helo; client-ip=66.111.4.27; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="leo@lpw25.net"; x-sender="postmaster@out3-smtp.messagingengine.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DXAQBf9tZWlhsEb0JehHlTqx6QKjGFYgKBRjwQAQEBAQEBAQEQAQEBAQcNCQkhL0EBAQMJBIFaghUBAQMBQDkBBAsLDjgsKwaILAipUIUsilcBAQEBBgEBAQEBARQGiAaCRoZ9C0AYgQ+OJYhynFmOTDeCP4FuHi6FdlWCFQEBAQ X-IPAS-Result: A0DXAQBf9tZWlhsEb0JehHlTqx6QKjGFYgKBRjwQAQEBAQEBAQEQAQEBAQcNCQkhL0EBAQMJBIFaghUBAQMBQDkBBAsLDjgsKwaILAipUIUsilcBAQEBBgEBAQEBARQGiAaCRoZ9C0AYgQ+OJYhynFmOTDeCP4FuHi6FdlWCFQEBAQ X-IronPort-AV: E=Sophos;i="5.22,529,1449529200"; d="scan'208";a="205444880" Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Mar 2016 15:24:17 +0100 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id AD77A20911 for ; Wed, 2 Mar 2016 09:24:16 -0500 (EST) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Wed, 02 Mar 2016 09:24:16 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=lpw25.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=Vg7oHq9quughtJZ/xDrmdonn8lg=; b=dsqwCp cL0esQIJqHBoUVu31Zrxf6s8NfCzg1rg72mPGJh5eL6fzTk6gyOoyiViAfVIcwHp qdyP0jTRdU6D9duiHIYI0UtRi0Kj7dcg31kME6IcSrOfjHnBzyrIgu0eCWEeeF5y 1tS2PPsmnFTi8NT5ZnIY58nkKzbbjJDxx4dGI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Vg7oHq9quughtJZ /xDrmdonn8lg=; b=lo66sGhnSep2bQBsF2yl7PYyryRij/gScWmzfdTZe07Bp+A qsRxrjgVRK9qLJpKgp4HfTXMszir/DzmxuCpiSZQRbwTjDw6sSre7g+X/zpBBESK spGUMnPJwmrMyWRigCdM1iDJx2W3aA0TMSt20L2byLxJ5dK82sP/RIbBhw4I= Received: by web1.nyi.internal (Postfix, from userid 99) id 730E9AECF64; Wed, 2 Mar 2016 09:24:16 -0500 (EST) Message-Id: <1456928656.1475915.537363338.6E334EDB@webmail.messagingengine.com> X-Sasl-Enc: o9i+XkZauGvsh+eC1sJKGLAqlw603Fs0VGnOr7jM1Vl6 1456928656 From: Leo White To: Malcolm Matalka Cc: caml-list@inria.fr MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-04035516 In-Reply-To: <8637s9gev3.fsf@gmail.com> References: <867fhlgjmj.fsf@gmail.com> <1456925836.1464341.537330890.53BDFE3A@webmail.messagingengine.com> <8637s9gev3.fsf@gmail.com> Date: Wed, 02 Mar 2016 09:24:16 -0500 Subject: Re: [Caml-list] Are implicit modules too implicit? > In this case I'm interested in if I have a block of code like the > [print] function described in the paper knowing what possible code could > even be executed there and how to define its definition. For example, > how do I go from [show 5] to the module [Show_int]? I would expect to be able to ask merlin to automatically jump to [Show_int] from [show 5]. I would also expect merlin to be able to produce [show {Show_int} 5] given [show 5]. > In the paper, the Show implementation for an int is called Show_int and > for list Show_list, etc. But this is just a pleasant convention in the > paper. And could easily be a pleasant convention in a library. Or possibly [Int.Show] and [List.Show]. It's really a just a question of using sensible library design. > What if implicit modules required specifying what module type > they are implementing? That would make finding instances of Show > easier. How this would look is in the paper: > > implicit module Foo : Show = struct ... end > That wouldn't work as it would make Foo.t abstract. If/when OCaml supported transparent ascription (perhaps with :>) then you could write: implicit module Foo :> Show = struct ... end which would at least be correct, but I don't really see the benefit of forcing users to do this since the .mli file (which is where you should be looking for definitions anyway) will already contain: implicit module Foo : Show with type t = ... Of course it might contain: implicit module Foo : ShowAndOtherStuff with type t = ... or even: implicit module Foo : sig type t = .. ... end instead, but this is really a question of programming style, and those are best left up to users/organisations to decide on. > Do you have any thoughts on how you think implicit modules would effect > understanding a large application? The whole design of implicits is very careful to make things as explicit and predictable as possible. The strict position that the design takes around ambiguity (it is always an error) means that if you can see a module with the right type in scope then that is the module being used. I do not think reasoning about them will be difficult, but it obviously relies on people being sensible in how they design their libraries (just like everything else in programming). Regards, Leo