Re: module dependency question

--000000000000e8ee600656bd598f
Content-Type: text/plain; charset="UTF-8"

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 <[email protected]>
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 <[email protected]>
> wrote:
>
>> In your example, `N` will be a dependency of `M` and thus a transitive
>> dependency of the current module.
>>
>
>

--000000000000e8ee600656bd598f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I shouldn&#39;t have put it that way! I am deriving s=
ignatures from the typed AST so am using the Env.find_xxx</div><div>functio=
ns and thus indirectly accessing the signature files.</div><div>nonetheless=
, it seems that, for my purposes, if an externally defined type is used in =
a module but its structure remains &#39;unexamined&#39; throughout that mod=
ule, ie. treated abstractly, it is not a meaningful dependency and I don&#3=
9;t need to know anything more about it.</div><div>unfortunately an awkward=
 example has occurred to me:</div><div><br></div><div>let v=3D fst@@ M.f()<=
/div><div><br></div><div>here the structure of N.t is being revealed but fs=
t being a polymorphic function means I still have to go to the typexpr</div=
><div>to know that the N.t is involved, which is where I find a Path.t, tha=
t it is global, and can make the appropriate Env.find to compose a signatur=
e item. So there is no typed AST variant term here to garner the Path.t - a=
s far as I can see,</div><div>that N.t is being de-composed has to be detec=
ted and then the typexpr of &#39;fst=C2=A0@@ ...&#39;=C2=A0 has to be consu=
lted in order to</div><div>know whether a global Path.t is involved. this c=
omplicates matters for me. after all there could be any number of tuple</di=
v><div>decomposing functions defined, and what else?!=C2=A0</div><div>so I =
think I need a general way to determine &#39;is this type being decomposed =
in some way&#39;, whether it is by tuple projection, record label, variant =
name etc...</div><div><br></div><div>by the way, why is there no Env.find_e=
xtension_constructor function?</div><div>I&#39;m sure there&#39;s a very go=
od reason (never possible to fully define?) :)</div><div><br></div><div>tha=
nks.</div><div><br></div><div><br></div><div><br></div></div><br><div class=
=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr=
">On Thu, 16 Jul 2026 at 13:34, Florian Angeletti &lt;<a href=3D"mailto:flo=
[email protected]">[email protected]</a>&gt; wrote:<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

 =20
   =20
 =20
  <div>
    What is the motivation for adding the constraint of not opening any
    other files?<br>
    You will need to open the interface of M to discover its
    dependencies at one point or another.<br>
    <br>
    <div>On 16/07/2026 at 17:19, K wrote :<br>
    </div>
    <blockquote type=3D"cite">
     =20
      <div dir=3D"ltr">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?</div>
      <br>
      <div class=3D"gmail_quote">
        <div dir=3D"ltr" class=3D"gmail_attr">On Thu, 16 Jul 2026 at 13:07,
          Florian Angeletti &lt;<a href=3D"mailto:[email protected]" targe=
t=3D"_blank">[email protected]</a>&gt;
          wrote:<br>
        </div>
        <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex">In
          your example, `N` will be a dependency of `M` and thus a
          transitive <br>
          dependency of the current module.<br>
        </blockquote>
      </div>
    </blockquote>
    <br>
  </div>

</blockquote></div>

--000000000000e8ee600656bd598f--