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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by sympa.inria.fr (Postfix) with ESMTPS id F29337F249 for ; Tue, 30 Oct 2012 03:21:22 +0100 (CET) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of sbleune@gmail.com) identity=pra; client-ip=209.85.223.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="sbleune@gmail.com"; x-sender="sbleune@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of sbleune@gmail.com designates 209.85.223.182 as permitted sender) identity=mailfrom; client-ip=209.85.223.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="sbleune@gmail.com"; x-sender="sbleune@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ie0-f182.google.com) identity=helo; client-ip=209.85.223.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="sbleune@gmail.com"; x-sender="postmaster@mail-ie0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUCAL04j1DRVd+2m2dsb2JhbABEsRySGQgjAQEBAQEICQsJFCeCHgEBAQQSAhMZAS0LAQMMAQUFCw0NISISAQUBChIGExIQh1IDDwucZWIJA44cgQqFCicDColOAQUMi2mGXQOVdIEajUcWKYFYgiwN X-IronPort-AV: E=Sophos;i="4.80,676,1344204000"; d="scan'208";a="160826913" Received: from mail-ie0-f182.google.com ([209.85.223.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 30 Oct 2012 03:21:22 +0100 Received: by mail-ie0-f182.google.com with SMTP id k10so13407170iea.27 for ; Mon, 29 Oct 2012 19:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=5CTfau8f+iOUlebnx8Lo4wXwxy2mL/3fLlpow/UZolQ=; b=bHBf9ka0wiveLGz29/u0hnDlq8T+ddo0hh+jtCc95AHvvxfpcSdgeNZD8Dj1DanR1k wwgT1juX++0U02lt9egnWwYHEVPMdeuEpswXjVWHzCQK3G/3fsvtG/lzBP0qE0SNbZew Q2D0NZiPmK1rNZ73aYFabwTLW9/Z0GXemnrhot4Rr+1A6oSHYQjbY2B5pn2QaH/wQ3QF UNlkvTQZVeep5moJ3AatUel6LoOo7zgwvBnsavWRfjX/zEBruIlNGrTnaPFzSbFO8+7T j3d3g9rGvNvOPyxi+syuPq882L1qG3Os3Vvzk7JjGu/Xjm7Tdt6k+GmECyfMlESMzUW4 RJng== Received: by 10.50.236.39 with SMTP id ur7mr146539igc.26.1351563680914; Mon, 29 Oct 2012 19:21:20 -0700 (PDT) MIME-Version: 1.0 Sender: sbleune@gmail.com Received: by 10.64.81.168 with HTTP; Mon, 29 Oct 2012 19:21:00 -0700 (PDT) In-Reply-To: <508F22BD.7010103@riken.jp> References: <508F22BD.7010103@riken.jp> From: "gallais @ ensl.org" Date: Tue, 30 Oct 2012 02:21:00 +0000 X-Google-Sender-Auth: 6e0nfwrKEQhXDQce2rHqkOMdywc Message-ID: To: Francois Berenger Cc: caml-list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] Why should I use .mli files? Hi Fran=E7ois, No need to work on big projects to benefit from abstraction: last time I used an .mli for something else than documentation was when I was implementing a simulator for a small machine whose memory was an array of hexadecimal numbers. After quite a long time spent tracking bugs, I realized that almost all of them were due to me screwing up the hexadecimal computations. Fast forward, a module [Hexa] with an abstract type [t] and various functions such as from_int: int -> Hexa.t minus : Hexa.t -> Hexa.t -> Hexa.t add_int: Hexa.t -> int -> Hexa.t ... and all my problems were gone: the typechecker was tracking the use of hexadecimal numbers for me and flagging all operations not going through these few secure functions as being ill-typed. That was a nice afternoon. -- gallais On 30 October 2012 00:43, Francois Berenger wrote: > Hello, > > Here is my stupid question of the day: > what's the use of those .mli files? > > Is it just to separate interface from implementation > so that the implementation of a module can be changed > without clients of its interface to have to bother? > > Does it make compilation of large software faster > by allowing for more parallelization and maybe later on avoiding to > recompile some parts? > > Usually I program in a pure functional style, so my modules > don't carry an internal state. > I feel like "if someone want to re-use a function, so be it". > If I really want to hide a function that I am afraid people > may call in an incorrect manner, I declare it internally > to some public function and use it correctly. > > Also, maybe I only work on toy-size OCaml projects. So, I never bothrered= to > create any .mli file. > I would like to know if I should bother about them. > > Thanks a lot, > Francois. > > -- > 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