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 C22887F7AD for ; Wed, 2 Mar 2016 15:17:39 +0100 (CET) IronPort-PHdr: 9a23:0kwqohYthmW3Nz37ygt/qTP/LSx+4OfEezUN459isYplN5qZpcWybnLW6fgltlLVR4KTs6sC0LqJ9f+6EjFQqb+681k8M7V0HycfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aJBzzOEJPK/jvHcaK1oLsh7/0pMeYPlUArQH+SI0xBS3+lR/WuMgSjNkqAYcK4TyNnEF1ff9Lz3hjP1OZkkW0zM6x+Jl+73YY4Kp5pIZoGJ/3dKUgTLFeEC9ucyVsvJWq5i/4UBCX63AAfmITmxtOS0iZvVCpFqv25w7zsuF63CzSGMTqRLQ3UHz26qJiVBbsiy4vODsw8WWRgct12vF1uhWk8i122YnSKKSUMuF9b+uJbNYbQ3FCT+5TXipMGZ+mYoYTSeEGOLAL/MHGu1ISoE7mVkGXD+T1x2oN2yb7 Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=yminsky@janestreet.com; spf=Pass smtp.mailfrom=yminsky@janestreet.com; spf=None smtp.helo=postmaster@mxout1.mail.janestreet.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of yminsky@janestreet.com) identity=pra; client-ip=38.105.200.112; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of yminsky@janestreet.com designates 38.105.200.112 as permitted sender) identity=mailfrom; client-ip=38.105.200.112; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.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@mxout1.mail.janestreet.com) identity=helo; client-ip=38.105.200.112; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="postmaster@mxout1.mail.janestreet.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CAAAB69dZWknDIaSZehAxtBql5kDWBZyGFcgKBPwc6EgEBAQEBAQEBEAEBAQEHFglQgi2CFQEBBBIRHQEBLAsBDwsLAwoCAgkdAgIhARIBBQEKEgYTEhCHagMSAwucSoExPjGKT2eEQAEEhhMDCoQ3AQEBAQEBBAEBAQEBAQETBgpxhReEOoI6gVWDJoE6hh4Mhwd0iHKFWoYVgXSCK4xLhwiGBhEegQ8nAoIvHoFuTIclgTsBAQE X-IPAS-Result: A0CAAAB69dZWknDIaSZehAxtBql5kDWBZyGFcgKBPwc6EgEBAQEBAQEBEAEBAQEHFglQgi2CFQEBBBIRHQEBLAsBDwsLAwoCAgkdAgIhARIBBQEKEgYTEhCHagMSAwucSoExPjGKT2eEQAEEhhMDCoQ3AQEBAQEBBAEBAQEBAQETBgpxhReEOoI6gVWDJoE6hh4Mhwd0iHKFWoYVgXSCK4xLhwiGBhEegQ8nAoIvHoFuTIclgTsBAQE X-IronPort-AV: E=Sophos;i="5.22,529,1449529200"; d="scan'208";a="166653497" Received: from mxout1.mail.janestreet.com ([38.105.200.112]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Mar 2016 15:17:38 +0100 Received: from tot-qpr-mailcore1.delacy.com ([172.27.56.68] helo=tot-qpr-mailcore1) by mxout1.mail.janestreet.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1ab7ar-0004cg-9c for caml-list@inria.fr; Wed, 02 Mar 2016 09:17:37 -0500 X-JS-Flow: external Received: by tot-qpr-mailcore1 with JS-mailcore (0.1) (envelope-from ) id BW1vYB-AAAAk2-HZ; 2016-03-02 09:17:37.237917-05:00 Received: from mail-yw0-f175.google.com ([209.85.161.175]) by mxgoog1.mail.janestreet.com with esmtps (UNKNOWN:AES128-GCM-SHA256:128) (Exim 4.72) (envelope-from ) id 1ab7ar-00065A-5I for caml-list@inria.fr; Wed, 02 Mar 2016 09:17:37 -0500 Received: by mail-yw0-f175.google.com with SMTP id u200so177521737ywf.0 for ; Wed, 02 Mar 2016 06:17:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nLWLGxShllNh09ENm71pw+pvM+7Glp1W8AQqtDPBWtQ=; b=AmngebhFhIuOSGXCjEytQcJ1GXTkPDW4rc+iQqk0jou/2KgCpnu6k4WrlGKSsGAAbn dJ3LVBAxZQQJih1bzNq13yuzhlDjTOgyg9K7QTBEw0bhWS27XcQPFi7VuTTi8CCN25Q5 Vnq3f6qASJG7xfawRe4V0C+soxfkE8/txP8e0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nLWLGxShllNh09ENm71pw+pvM+7Glp1W8AQqtDPBWtQ=; b=UlFZXiWGOu5vtuKeyEsLFYPvjm5Mptm4GmdiHhnSOnSHXTLr1iHWldq0neRl2W7hzm w9sn6q5jlF7+h8y0hqZsyHDe07v2PG3Oy/x9tBSeRUcLHh8KunyefRMJs+jEvtYTPY1E t5CAIhAOGiTk67CuXQFPLZpUAywg4G3TS2xzBV0tiYKdTJKJvPHxCK7XJsqsEGRKOSox KdBUaWJX8/xXURH2dZEk8d5XzjGS9XFa7WtUYBFgyEf+s74ZlEZMJYQ67F9NNrLHHEgP fIdxWtgwAnCsOmifTG5DbveWFY5ph/OufysUo1jNSb8bjIi9qP7nZTkf9YamniprdHe0 sOWQ== X-Gm-Message-State: AD7BkJK7aDjsOUqhdvGwQV+dSqC6d3DDeZ2qTbByYFzxehj1Z4BGqiu5m5IDWrfit0HcsLQGvB4raebHloFWuWnQIPzciIJViOZOpp7KuFtHBXjy4jQKxThVs/vhqL8Tv+BJfeXBgHWe+UPhuiRarCGPDQ== X-Received: by 10.129.85.85 with SMTP id j82mr14510704ywb.28.1456928256830; Wed, 02 Mar 2016 06:17:36 -0800 (PST) X-Received: by 10.129.85.85 with SMTP id j82mr14510694ywb.28.1456928256697; Wed, 02 Mar 2016 06:17:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.145.193 with HTTP; Wed, 2 Mar 2016 06:17:17 -0800 (PST) In-Reply-To: <8637s9gev3.fsf@gmail.com> References: <867fhlgjmj.fsf@gmail.com> <1456925836.1464341.537330890.53BDFE3A@webmail.messagingengine.com> <8637s9gev3.fsf@gmail.com> From:Yaron Minsky Date: Wed, 2 Mar 2016 09:17:17 -0500 Message-ID: To:Malcolm Matalka Cc:Leo White , "caml-list@inria.fr" Content-Type: text/plain; charset=UTF-8 X-JS-Processed-by: mailcore Subject: Re: [Caml-list] Are implicit modules too implicit? I think the library design issues with implicits are still quite open. Our intent with Core is to step pretty gradually into this area. I expect that some things like sexp-conversion will be moved to implicits pretty eagerly, but that we'll be quite cautious for a while. It's worth noting that modules must in this proposal be marked explicitly to be available for implicit selection. So you can grep for implicit modules to some degree at least. My guess is that with respect to Core, we'll end up in a state where implicits are used in a quite limited manner. I think they'll be quite useful, but I don't expect to have many kinds of implicits floating around in the scope by default. y On Wed, Mar 2, 2016 at 8:59 AM, Malcolm Matalka wrote: > 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 > > -- > 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