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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 65D4E7F7AD for ; Wed, 2 Mar 2016 14:59:43 +0100 (CET) IronPort-PHdr: 9a23:+TK7ahT8vw/i9EyTnTcNF5Rom9psv+yvbD5Q0YIujvd0So/mwa64YBGN2/xhgRfzUJnB7Loc0qyN4/+mBjZLvcfJmUtBWaIPfidNsd8RkQ0kDZzNImzAB9muURYHGt9fXkRu5XCxPBsdMs//Y1rPvi/6tmZKSV3BPAZ4bt74BpTVx5zukbvipNuMOU4U1XKUWvBbElaflU3prM4YgI9veO4a6yDihT92QdlQ3n5iPlmJnhzxtY+a9Z9n9DlM6bp6r5YTGfayQ6NtabFfRAsmMnw4rJnvuB7rSROQvCZaVGgKxElmGQ/AuTTzWpz2ti6yk+Nh0S2ZNIWiSLU9RT2m7K5DRxrhiSNBPDk8pjKEwvdshb5W9Ury7yd0xJTZNdmY Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=mmatalka@gmail.com; spf=Pass smtp.mailfrom=mmatalka@gmail.com; spf=None smtp.helo=postmaster@mail-wm0-f43.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of mmatalka@gmail.com) identity=pra; client-ip=74.125.82.43; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="mmatalka@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of mmatalka@gmail.com designates 74.125.82.43 as permitted sender) identity=mailfrom; client-ip=74.125.82.43; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="mmatalka@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wm0-f43.google.com) identity=helo; client-ip=74.125.82.43; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="postmaster@mail-wm0-f43.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CFAACt8NZWlStSfUpehHmoMYcZimqBZ4YTAoFDORMBAQEBAQEBARABAQEBBwsLCSEvgi2CFQEBAwESLgEbHQEDDAYFCxYlDwEEDxEBBQEiEyKHaQEDCggEnDWBMT4xjR+CV4VOChknDVGDZgEBAQEBBQEBAQEBFQEFCgSEAoIChDqIbwWNLIlmjWOJGIVejQ4vgQ8iAYI1HoFQaohgAQEB X-IPAS-Result: A0CFAACt8NZWlStSfUpehHmoMYcZimqBZ4YTAoFDORMBAQEBAQEBARABAQEBBwsLCSEvgi2CFQEBAwESLgEbHQEDDAYFCxYlDwEEDxEBBQEiEyKHaQEDCggEnDWBMT4xjR+CV4VOChknDVGDZgEBAQEBBQEBAQEBFQEFCgSEAoIChDqIbwWNLIlmjWOJGIVejQ4vgQ8iAYI1HoFQaohgAQEB X-IronPort-AV: E=Sophos;i="5.22,529,1449529200"; d="scan'208";a="166650455" Received: from mail-wm0-f43.google.com ([74.125.82.43]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 02 Mar 2016 14:59:41 +0100 Received: by mail-wm0-f43.google.com with SMTP id l68so86648156wml.0 for ; Wed, 02 Mar 2016 05:59:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=XYODQ2QJNLhos1tS8jsmKD7N46eu2PwzRyjFjzykIGc=; b=DwnOQUT+XH/SjAXuEMbxhc4dMGGiKLGbqC8dRDV6CuVfKAThXMaU8ibOqSF0+SlMmB opkzGfkhlQzkeyalvCE6iUbD5LqRRUBFM8bah9T1vlS3/r1TrQ3nRlQalPlzCrIF7QLO fwXBhYKqRpslXLXK0Drw4SaWyF6FAChHXHNfNYjzpE40nwrXPhFYECcB3AdG8Yd+Gj++ zeM2M+D+McsOgiUO32+AE1H+7g4nwgeWHWgq7I/IrhfjdZ/0rBIfdtSBeV5/jTIXykL8 zlteOBe1VFg3O+/tEORwvHHMjS4m9uCMXqKIBYCq8qygfAxpwwmkBYoK36JaSa8IRWAV 1TBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=XYODQ2QJNLhos1tS8jsmKD7N46eu2PwzRyjFjzykIGc=; b=k8upR5GV2N6oPWlXyKt3n1YaYYg/Ghe5+t6pc2vAeJCF3+uY1dE/fmXyxcS5PU4hG9 aX1eq6vv48KXS21hkTMZGfwpSIUMb8bly+7oFmmlYllc5+t5qMIL/4wFdGmR0DJ2YY3/ M39B0F0djRLLjGZU8Xqm5M8LBqmFbzFBQEiTCBbMPh7xbTSoUCI4xU15ncblreqvUAjM G+FvbNPQOmsu7pJy5RBdk4JKJBJm6EzHOBriM7oDVfIehn9YMmxJdCs4m/hNL5HwIs8H 3aa3T5zRT1zkjTos/p0CGaNnuvuGpTMzywxkoRn/kMLqxXLabZLZOFyZmz6ljBSTQ9jm 0pfA== X-Gm-Message-State: AD7BkJIeMqWi3G+2KFCWf/4wHfmTwrBRo0FjMpDiFfhDwgVEAgVaEbYpYvJRWlMXlPYg6A== X-Received: by 10.194.142.135 with SMTP id rw7mr24815508wjb.84.1456927181495; Wed, 02 Mar 2016 05:59:41 -0800 (PST) Received: from localhost ([37.153.108.22]) by smtp.gmail.com with ESMTPSA id 73sm4301500wmy.22.2016.03.02.05.59.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Mar 2016 05:59:40 -0800 (PST) From: Malcolm Matalka To: Leo White Cc: caml-list@inria.fr References: <867fhlgjmj.fsf@gmail.com> <1456925836.1464341.537330890.53BDFE3A@webmail.messagingengine.com> Date: Wed, 02 Mar 2016 13:59:28 +0000 In-Reply-To: <1456925836.1464341.537330890.53BDFE3A@webmail.messagingengine.com> (Leo White's message of "Wed, 02 Mar 2016 08:37:16 -0500") Message-ID: <8637s9gev3.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Caml-list] Are implicit modules too implicit? Leo White writes: >> To me, this means going from a call-site, to the actual >> implementation is very difficult especially since I cannot even do some >> sort of grep to find all those things that implement an implicit module >> type. > > The best way of finding a variable's definition is to use merlin to jump to definition. > The same will be true for implicit call sites. 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]? > > Depending on how libraries are designed I would not expect it to be difficult to locate > the instances by hand. They are managed with the same scoping mechanisms as > ordinary values, and since they should rarely be used by name they can also be > given nice descriptive searchable names. 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. 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 Certainly this isn't needed for correctness, but it seems nicer than hoping people name their instances something sensible. Do you have any thoughts on how you think implicit modules would effect understanding a large application? > > Regards, > > Leo