From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 59B2F7EE4B for ; Thu, 3 Oct 2013 20:43:14 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of milanst@gmail.com) identity=pra; client-ip=209.85.223.174; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="milanst@gmail.com"; x-sender="milanst@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of milanst@gmail.com designates 209.85.223.174 as permitted sender) identity=mailfrom; client-ip=209.85.223.174; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="milanst@gmail.com"; x-sender="milanst@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-ie0-f174.google.com) identity=helo; client-ip=209.85.223.174; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="milanst@gmail.com"; x-sender="postmaster@mail-ie0-f174.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikCABS6TVLRVd+ulGdsb2JhbABZhBGDKL4dgRoIFg4BAQEBBwsLCRIqgiUBAQQBIx0BGx0BAwELBgULDwImAgIiAREBBQEcBogGAQMJBp4rjAFRgwqEIQoZJw1kiQEBBQyBHY4oB4JqgTkDmAGQFBgphGog X-IPAS-Result: AikCABS6TVLRVd+ulGdsb2JhbABZhBGDKL4dgRoIFg4BAQEBBwsLCRIqgiUBAQQBIx0BGx0BAwELBgULDwImAgIiAREBBQEcBogGAQMJBp4rjAFRgwqEIQoZJw1kiQEBBQyBHY4oB4JqgTkDmAGQFBgphGog X-IronPort-AV: E=Sophos;i="4.90,1027,1371074400"; d="scan'208";a="29021783" Received: from mail-ie0-f174.google.com ([209.85.223.174]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 03 Oct 2013 20:43:13 +0200 Received: by mail-ie0-f174.google.com with SMTP id u16so6389412iet.19 for ; Thu, 03 Oct 2013 11:43:12 -0700 (PDT) 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=zdMEwTN7oNqqalVHiA8qki3bOFcWfr20PfDbUOLhkGA=; b=KqutW+sBa88o5UGJy1F9IDAgET2Wt7PP5B9N9XteDSs3DRKqpOml0fFwVvWj/Ue0wv cXvgjRMlE/YP1P+qpaVBj09LeShvEEX4UjFd2tqdFEuUwfYR+VzKCf8hOwWyJGTzCmll O6yVIRKl2omcTHo0WGjtyGLQI2fMgsR8T3OnyWerrQpDWSxNLgEvef69kLbwLF5yAlSL qWLxUV1Xgu6TRz4Z2PHk0oM7L64baRiIiaEaZ5iOUtOoD+zF2J3QvqILe0E6g3YF0bp5 EEkWNp5W6prdIq8g5sscmYeOqxZCzlKEh2ALb98x7VaDMNpR6TXUaTV5YgUiOr+GjA/L 8Y7Q== X-Received: by 10.43.11.69 with SMTP id pd5mr1637061icb.62.1380825792109; Thu, 03 Oct 2013 11:43:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.63.11 with HTTP; Thu, 3 Oct 2013 11:42:31 -0700 (PDT) In-Reply-To: <524DAD23.7070206@frisch.fr> References: <524DAD23.7070206@frisch.fr> From: =?UTF-8?Q?Milan_Stanojevi=C4=87?= Date: Thu, 3 Oct 2013 14:42:31 -0400 Message-ID: To: Alain Frisch Cc: Caml List Content-Type: text/plain; charset=UTF-8 Subject: Re: [Caml-list] empty mli for executable > The empty interface implies that toplevel values computed by those modules > don't need to be stored in the global symbol slots. Those slots are roots > for the GC and are thus scanned every time it runs. The fewer global > symbols, the quicker the GC will be. Well, this is the theory, I'd be > really surprised if this materialized in a speed up which can be observed. Thanks, Alain. Just one question about this. Let's say I have a toplevel value in my executable and an empty mli. How is this toplevel value then retained? Is it part of some other root set ? > Having an empty interface has a much more practical interest, in general: it > allows the compiler to detect unused declarations in the implementation (if > the corresponding warnings are enabled), and thus to reduce code rot. Yes, I've been doing this, it is a very useful feature of the compiler.