# Module types / aliases

**URL:** <https://discuss.ocaml.org/t/module-types-aliases/9557>\
**Category:** Learning\
**Created:** [March 24, 2022, 8:08am UTC](https://discuss.ocaml.org/t/module-types-aliases/9557 "2022-03-24T08:08:19Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![progman](https://avatars.discourse-cdn.com/v4/letter/p/8797f3/32.png) [@progman](https://discuss.ocaml.org/u/progman)\
**Post date:** [March 24, 2022, 8:08am UTC](https://discuss.ocaml.org/t/module-types-aliases/9557/1 "2022-03-24T08:08:19Z")

</div>

consider:

```auto
module type list = module type of List (* module expression iis an alias *)
module type list2 = module type of Stdlib__List (* mod-exp is not an alias *)
module M=Stdlib__List (* but type of module expression here IS alias! *)

```

the type declarations lead me to believe a module expression carries a type  
independent of its context but the declaration of M, the creation of an alias, suggests  
otherwise.  
why is it that the module expression Stdlib\_\_List in this position doesn’t remain a non-alias?

---

<div class="post-metadata">

**Author:** ![vlaviron](https://avatars.discourse-cdn.com/v4/letter/v/ec9cab/32.png) [@vlaviron](https://discuss.ocaml.org/u/vlaviron)\
**Post date:** [March 24, 2022, 10:46am UTC](https://discuss.ocaml.org/t/module-types-aliases/9557/2 "2022-03-24T10:46:22Z")

</div>

It’s not clear what behaviour you find unexpected.  
In your code, you have two module types (which are computed by expanding any aliases) and a module alias.  
I expect that `module type of M` will give you the same result as `module type of List`.  
Does that answer your question ?

---

<div class="post-metadata">

**Author:** ![progman](https://avatars.discourse-cdn.com/v4/letter/p/8797f3/32.png) [@progman](https://discuss.ocaml.org/u/progman)\
**Post date:** [March 24, 2022, 1:00pm UTC](https://discuss.ocaml.org/t/module-types-aliases/9557/3 "2022-03-24T13:00:04Z")

</div>

the module expressions of the two module type declarations are List and Stdlib\_\_List respectively and their module types are recorded (in the typed-tree) respectively as Mty\_alias and Mty\_ident - alias and non-alias.  
but with module M = Stdlib\_\_List the module expression Stdlib\_\_List is carrying Mty\_alias (in field mod\_type).  
my expectation, based on the non-alias status of the 2nd module type declaration,  
is for Mty\_ident not Mty\_alias.  
as [module M=Stdlib\_\_List] is the introduction of an alias it would be no surprise  
to see the md\_type of the declaration recorded this way but the module expression is a separate entity and not to be effected by its context, or so I thought.

is unification forcing the Mty\_alias of the module expression even though Stdlib\_\_List is obviously not an alias?  
my interest is in having an unambiguous indication of alias/non-alias status.

---

<div class="post-metadata">

**Author:** ![vlaviron](https://avatars.discourse-cdn.com/v4/letter/v/ec9cab/32.png) [@vlaviron](https://discuss.ocaml.org/u/vlaviron)\
**Post date:** [March 24, 2022, 1:47pm UTC](https://discuss.ocaml.org/t/module-types-aliases/9557/4 "2022-03-24T13:47:10Z")

</div>

> [@progman](#):
>
> my interest is in having an unambiguous indication of alias/non-alias status.

The distinction between alias and not alias is not meaningful in expressions; each alias also has a regular module type, and even non-alias modules can be seen as aliases to themselves conceptually, so the type you’ll get on the expression might be either of those depending on which one is more useful in the context. You should look inside the environments stored in the typedtree if you want a reliable way to know whether a given module was defined as an alias or not.

---

<div class="post-metadata">

**Author:** ![progman](https://avatars.discourse-cdn.com/v4/letter/p/8797f3/32.png) [@progman](https://discuss.ocaml.org/u/progman)\
**Post date:** [March 24, 2022, 2:23pm UTC](https://discuss.ocaml.org/t/module-types-aliases/9557/5 "2022-03-24T14:23:16Z")

</div>

that’s great. thanks!
