[Caml-list] module dependency question

[Caml-list] module dependency question

[K]

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]

I have been labouring under the mis-apprehension that the global Path.t's
within the typed AST are sufficient to identify all dependencies of a
module.
But I think the following case illustrates differently:

consider a toplevel definition:
let v = M.f ()
where M.f: unit -> N.t

the dependency on M is clear but because the value v is not inspected in
any way, the type N.t is not a dependency unless going, say, beyond the
type AST description and iterating over the term's exp_type: typexpr
looking for global Path.t's.

Is this reasonable or is there a better way of going about identifying ALL
dependencies?

[-- Attachment #2: Type: text/html, Size: 765 bytes --]

Re: [Caml-list] module dependency question

[Florian Angeletti]

In your example, `N` will be a dependency of `M` and thus a transitive 
dependency of the current module.

Re: [Caml-list] module dependency question

[K]

[-- Attachment #1: Type: text/plain, Size: 403 bytes --]

Is iterating over the typexpr the right or reasonable way of uncovering
that transitive dependency (on type N.t specifically rather than on the
module N in its entirety) without recourse to opening any other file?

On Thu, 16 Jul 2026 at 13:07, Florian Angeletti <octa@polychoron.fr> wrote:

> In your example, `N` will be a dependency of `M` and thus a transitive
> dependency of the current module.
>

[-- Attachment #2: Type: text/html, Size: 708 bytes --]

Re: [Caml-list] module dependency question

[Florian Angeletti]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

What is the motivation for adding the constraint of not opening any 
other files?
You will need to open the interface of M to discover its dependencies at 
one point or another.

On 16/07/2026 at 17:19, K wrote :
> Is iterating over the typexpr the right or reasonable way of 
> uncovering that transitive dependency (on type N.t specifically rather 
> than on the module N in its entirety) without recourse to opening any 
> other file?
>
> On Thu, 16 Jul 2026 at 13:07, Florian Angeletti <octa@polychoron.fr> 
> wrote:
>
>     In your example, `N` will be a dependency of `M` and thus a
>     transitive
>     dependency of the current module.
>

[-- Attachment #2: Type: text/html, Size: 1546 bytes --]

Re: [Caml-list] module dependency question

[K]

[-- Attachment #1: Type: text/plain, Size: 2199 bytes --]

I shouldn't have put it that way! I am deriving signatures from the typed
AST so am using the Env.find_xxx
functions and thus indirectly accessing the signature files.
nonetheless, it seems that, for my purposes, if an externally defined type
is used in a module but its structure remains 'unexamined' throughout that
module, ie. treated abstractly, it is not a meaningful dependency and I
don't need to know anything more about it.
unfortunately an awkward example has occurred to me:

let v= fst@@ M.f()

here the structure of N.t is being revealed but fst being a polymorphic
function means I still have to go to the typexpr
to know that the N.t is involved, which is where I find a Path.t, that it
is global, and can make the appropriate Env.find to compose a signature
item. So there is no typed AST variant term here to garner the Path.t - as
far as I can see,
that N.t is being de-composed has to be detected and then the typexpr of
'fst @@ ...'  has to be consulted in order to
know whether a global Path.t is involved. this complicates matters for me.
after all there could be any number of tuple
decomposing functions defined, and what else?!
so I think I need a general way to determine 'is this type being decomposed
in some way', whether it is by tuple projection, record label, variant name
etc...

by the way, why is there no Env.find_extension_constructor function?
I'm sure there's a very good reason (never possible to fully define?) :)

thanks.




On Thu, 16 Jul 2026 at 13:34, Florian Angeletti <florian.angeletti@inria.fr>
wrote:

> What is the motivation for adding the constraint of not opening any other
> files?
> You will need to open the interface of M to discover its dependencies at
> one point or another.
>
> On 16/07/2026 at 17:19, K wrote :
>
> Is iterating over the typexpr the right or reasonable way of uncovering
> that transitive dependency (on type N.t specifically rather than on the
> module N in its entirety) without recourse to opening any other file?
>
> On Thu, 16 Jul 2026 at 13:07, Florian Angeletti <octa@polychoron.fr>
> wrote:
>
>> In your example, `N` will be a dependency of `M` and thus a transitive
>> dependency of the current module.
>>
>
>

[-- Attachment #2: Type: text/html, Size: 3382 bytes --]