Re: [Caml-list] Modules and record fields

[Gabriel Scherer <gabriel.scherer@gmail.com>]

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 = struct
  type t = { f: int }
end

module M = struct
  open A
  let v = { f = 1 }
  type u = { 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
<ollie.frolovs.2012@my.bristol.ac.uk> wrote:
> 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
>