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 BEA0C7EE5B for ; Sun, 25 May 2014 17:03:28 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.128.170; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.128.170 as permitted sender) identity=mailfrom; client-ip=209.85.128.170; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ve0-f170.google.com) identity=helo; client-ip=209.85.128.170; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-ve0-f170.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQBAA4FglPRVYCqlGdsb2JhbABZDoNLWIJqqUWVVQF7CBYOAQEBAQcLCwkSKoIlAQEBBBIRHQEbEgsBAwwGBQsNAgIJHQICIQEBEQEFAQoSBhMSEIgLAQMRDacKaosngXKDDZhMChknAwpkhTYRAQUMgR6LEoEpATkzB4J1gUsEhF4FkxqBdoE9i3iEARgphChCOy8BgQk X-IPAS-Result: AqQBAA4FglPRVYCqlGdsb2JhbABZDoNLWIJqqUWVVQF7CBYOAQEBAQcLCwkSKoIlAQEBBBIRHQEbEgsBAwwGBQsNAgIJHQICIQEBEQEFAQoSBhMSEIgLAQMRDacKaosngXKDDZhMChknAwpkhTYRAQUMgR6LEoEpATkzB4J1gUsEhF4FkxqBdoE9i3iEARgphChCOy8BgQk X-IronPort-AV: E=Sophos;i="4.98,906,1392159600"; d="scan'208";a="76120699" Received: from mail-ve0-f170.google.com ([209.85.128.170]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 25 May 2014 17:03:27 +0200 Received: by mail-ve0-f170.google.com with SMTP id db11so8319692veb.29 for ; Sun, 25 May 2014 08:03:27 -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:content-transfer-encoding; bh=qAtCvakuJszmst4ATcH4jTyCXWTpAINJMZHoLW0NgB8=; b=vCB+2+C8xcTP6nscscOTU/rMEV7d0LdMvMTu1A5ecXOQjWyOkWdcKr7Xx9k+jY3B4r e7QC9ZWcZ2+mfJTu4EfEJhMPtAdJCohhJhIQ84OiIaKzZNvO9EtQzemlHXzfGrCG5/Qo 1eck/oEra5ycKcMR78WjrqsZ+hoTEMrg0qNaXGXTve3gzi+WOLeCWSVAk56hN7alkBgk FoMHwuQkrpzUby5GcM3pjNK8o4GmPYJpyTdUsRrn5X+kBwhF2h4bhtvns2cDCR9jFhJh aNomF1wW5szaKMAsoNxafe/837g+jyHbdITuuQdPItGUmwViw0mN8FCIE0POUeVpivfC GW+w== X-Received: by 10.221.42.135 with SMTP id ty7mr15721821vcb.14.1401030207002; Sun, 25 May 2014 08:03:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.90.227 with HTTP; Sun, 25 May 2014 08:02:46 -0700 (PDT) In-Reply-To: <5B604612-B40C-459F-9D5F-76B61ABE1B58@my.bristol.ac.uk> References: <52C51721-8564-472C-AA7A-2ABE66C4D809@my.bristol.ac.uk> <20140525105906.GB7716@kerneis.info> <15117B8E-A404-4911-AC68-769CDF00B22E@my.bristol.ac.uk> <5B604612-B40C-459F-9D5F-76B61ABE1B58@my.bristol.ac.uk> From: Gabriel Scherer Date: Sun, 25 May 2014 17:02:46 +0200 Message-ID: To: Ollie Frolovs Cc: Gabriel Kerneis , caml users Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] Modules and record fields When I write M.v.f, it is not always the case that the field f is exported by the module M. Consider for example: module A =3D struct type t =3D { f: int } end module M =3D struct open A let v =3D { f =3D 1 } type u =3D { f : string } end print_int M.v.f This rightly fails (with a warning) as one should write M.v.A.f to be fully precise about the scope. Note that M.v.M.f or M.(v.f) would have a completely different (and wrong) meaning. On Sun, May 25, 2014 at 4:56 PM, Ollie Frolovs wrote: > Aha. Now I understand what happens but I don=E2=80=99t understand why. Sp= ecifically, why would the compiler in Solarized.orange.r access the field = =E2=80=9Cr" in the **current scope** of the value Solarized.orange, what us= e is this? In other words why Solarized.orange.r is not equivalent to Solar= ized.(orange.r) equivalent to Solarized.orange.(r), if that makes sense? Th= ere must be a good reason. > > On 25 May 2014, at 14:57, Gabriel Scherer wro= te: > >> The presence or absence of a warning is unrelated to whether it's a >> local module or a separate file. Solarized.orange.r and >> Solarized.(orange.r) are not equivalent. Solarized.orange.r means that >> you access the field "r" (in the current scope) of the value >> Solarized.orange. Solarized.(orange.r) opens Solarized locally for >> both the resolution of the "orange" identifier and "r" field name. >> Your new version is equivalent (Solarized's opening scope is even >> wider). >> >> The warning comes from the fact that since 4.01, OCaml can resolve a >> field name not only by having its path given from the current scope >> (eg. Solarized.r), but also by reasoning on the type of the record >> value, even if the field name itself is not in scope. Accessing field >> names that are not in scope is considered bad practice, hence the >> warning (which is disabled by a few people that like this style). >> >> On Sun, May 25, 2014 at 2:46 PM, Ollie Frolovs >> wrote: >>> It does, but I am rather disturbed by the compiler warning. I usually a= im not to have them, particularly when I am new to the language, assuming t= hat they at least hint at unsafe programming techniques. >>> >>> Update: I=E2=80=99ve put Solarized interface and definitions into separ= ate files (rather than having both as module Solarized =3D =E2=80=A6 in the= main file) and there is no warning anymore for some reason. Unless there = is something else I=E2=80=99m doing differently without realising it. >>> >>> I suppose that solves my problem. Thanks everybody! >>> >>> solarize.mli: >>> >>> type colour =3D {r:int; g:int; b:int} >>> val base03 : colour >>> val orange : colour >>> >>> (* END *) >>> >>> solarize.ml: >>> >>> type colour =3D {r:int; g:int; b:int} >>> let base03 =3D {r=3D0x00; g=3D0x2b; b=3D0x36} >>> let orange =3D {r=3D0xcb; g=3D0x4b; b=3D0x16} >>> >>> (* END *) >>> >>> main.ml: >>> >>> =E2=80=A6 >>> Solarized.(Sdl.set_render_draw_color ren orange.r orange.g orange.b 0xf= f) >>> =E2=80=A6 >>> (* END *) >>> >>> >>> On 25 May 2014, at 11:59, Gabriel Kerneis wrote: >>> >>>> On Sun, May 25, 2014 at 11:30:20AM +0100, Ollie Frolovs wrote: >>>>> let module S =3D Solarized in >>>>> Sdl.set_render_draw_color ren S.orange.r S.orange.g S.orange.b 0xff >>>>> (* etc etc *) >>>> >>>> Doesn't this work with the latest version of the compiler? (with a >>>> warning "r is not visible in the current scope, and will not be >>>> selected if the type becomes unknown") >>>> >>>> -- >>>> Gabriel >>> >>> >>> -- >>> 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 >