Re: [Caml-list] Modules and record fields

[Ollie Frolovs <ollie.frolovs.2012@my.bristol.ac.uk>]

Aha. Now I understand what happens but I don’t understand why. Specifically, why would the compiler in Solarized.orange.r access the field “r" in the **current scope** of the value Solarized.orange, what use is this? In other words why Solarized.orange.r is not equivalent to Solarized.(orange.r) equivalent to Solarized.orange.(r), if that makes sense? There must be a good reason.

On 25 May 2014, at 14:57, Gabriel Scherer <gabriel.scherer@gmail.com> wrote:

> 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
> <ollie.frolovs.2012@my.bristol.ac.uk> wrote:
>> It does, but I am rather disturbed by the compiler warning. I usually aim not to have them, particularly when I am new to the language, assuming that they at least hint at unsafe programming techniques.
>> 
>> Update: I’ve put Solarized interface and definitions into separate files (rather than having both as module Solarized = … in the main file)  and there is no warning anymore for some reason. Unless there is something else I’m doing differently without realising it.
>> 
>> I suppose that solves my problem. Thanks everybody!
>> 
>> solarize.mli:
>> 
>> type colour = {r:int; g:int;  b:int}
>> val base03 : colour
>> val orange : colour
>> 
>> (* END *)
>> 
>> solarize.ml:
>> 
>> type colour = {r:int; g:int;  b:int}
>> let base03 = {r=0x00; g=0x2b; b=0x36}
>> let orange = {r=0xcb; g=0x4b; b=0x16}
>> 
>> (* END *)
>> 
>> main.ml:
>> 
>> …
>> Solarized.(Sdl.set_render_draw_color ren orange.r orange.g orange.b 0xff)
>> …
>> (* END *)
>> 
>> 
>> On 25 May 2014, at 11:59, Gabriel Kerneis <gabriel@kerneis.info> wrote:
>> 
>>> On Sun, May 25, 2014 at 11:30:20AM +0100, Ollie Frolovs wrote:
>>>> let module S = 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