# What is a qualified import?

**URL:** <https://forum.canton.network/t/what-is-a-qualified-import/2061>\
**Category:** App Development\
**Tags:** imports\
**Created:** [February 9, 2021, 2:26pm UTC](https://forum.canton.network/t/what-is-a-qualified-import/2061 "2021-02-09T14:26:38Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![krmmalik](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/krmmalik/32/1410_2.png) [@krmmalik](https://forum.canton.network/u/krmmalik)\
**Post date:** [February 9, 2021, 2:26pm UTC](https://forum.canton.network/t/what-is-a-qualified-import/2061/1 "2021-02-09T14:26:38Z")

</div>

OK, I’m going through this post line by line.

> [@Using a standard library module with constraints (map function)](https://discuss.daml.com/t/using-a-standard-library-module-with-constraints-map-function/2057/3):
>
> @anthony’s answer is going in the right direction, but, as I understand it, you not only want 4 parties, you want to verify that they are 4 different parties. We’ll need two new functions for that. The first one is DA.List.unique, which is True if there are no duplicates in the given list. The second one is notElem, which is True if its first argument (type a) is not present in its second argument (type [a], or "list of a"). Using those, you could write something like: module Main where impo…

What is the need for `import qualified` for `DA.List` here?

Are there other modules with the same name, is that the reason?

I checked a couple of reference docs in the documentation both for [File structure](https://docs.daml.com/daml/reference/file-structure.html) and [Packages](https://docs.daml.com/daml/reference/packages.html)

It seems to suggest that some modules can have the same name so that’s why sometimes you need to do a qualified import?

Do I understand this correctly?

---

<div class="post-metadata">

**Author:** ![anthony](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/anthony/32/419_2.png) [@anthony](https://forum.canton.network/u/anthony)\
**Post date:** [February 9, 2021, 3:35pm UTC](https://forum.canton.network/t/what-is-a-qualified-import/2061/2 "2021-02-09T15:35:36Z")

</div>

Excellent questions, moved to a separate topic so it’s easier for others to find if they have the same question.

Also to answer your question a qualified import makes it so that all functions in `DA.List` need to be referred to as `DA.List.functionName` rather than `functionName`. This is to avoid naming conflicts where two modules have a function with the same name because if you called `functionName` and it was in two different modules the compiler wouldn’t know which one you were referring to.

---

<div class="post-metadata">

**Author:** ![Gary\_Verhaegen](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/gary_verhaegen/32/81_2.png) [@Gary\_Verhaegen](https://forum.canton.network/u/Gary_Verhaegen)\
**Post date:** [February 9, 2021, 3:58pm UTC](https://forum.canton.network/t/what-is-a-qualified-import/2061/3 "2021-02-09T15:58:05Z")

</div>

Hi @krmmalik,

> What is the need for `import qualified` for `DA.List` here?

When you start a new Daml file, by default you have access to all of the functions defined in a “special” module called [Prelude](https://docs.daml.com/daml/stdlib/Prelude.html). It’s only special in that it is automatically imported in all Daml files.

Daml comes with many other modules, however, but these have to be manually imported. There are multiple ways to do that. Schematically, assuming you have a file `Module.daml` with content like:

```haskell
module Module where

one = 1
two = 2

```

Obviously not a very useful one, but it will serve its purpose. Here are a few examples of how `import` statements work:

```haskell
import Module

test = script do
  assert $ one == 1
  assert $ two == 2
  assert $ Module.one == 1
  assert $ Module.two == 2

```

```haskell
import Module as M

test = script do
  assert $ one == 1
  assert $ two == 2
  assert $ M.one == 1
  assert $ M.two == 2

```

```haskell
import qualified Module as M

test = script do
  assert $ M.one == 1
  assert $ M.two == 2

```

```haskell
import qualified Module

test = script do
  assert $ Module.one == 1
  assert $ Module.two == 2

```

```haskell
import qualified Module (one)

test = script do
  assert $ Module.one == 1

```

```haskell
import Module (one)

test = script do
  assert $ one == 1
  assert $ Module.one == 1

```

So you have a few options:

- A naked `import Module` lets you access all the names in `Module` either directly as `name` or “qualified” as `Module.name`.
- Adding an `as` to the import statement changes the prefix used when qualifying an imported name.
- Adding the `qualified` keyword restricts the imported name to only their qualified form.
- Adding a list of names to the import statement restricts the import to just those names.

Now imagine `Module.daml` has:

```haskell
module Module where

map = "map"

```

and you want to write:

```haskell
import Module

test = script do
  assert $ map == "map" -- compilation error

```

This is the case described by @anthony: the compiler doesn’t know which `map` you’re referring to (there is one in `Module`, but there is also one in `Prelude`).

You can still qualify the names if you want:

```haskell
import Module

test = script do
  assert $ Module.map == "map"
  assert $ Prelude.map (*2) [1, 3, 7] == [2, 6, 14]

```

So, bottom line:

- There is no error if you have multiple imports that add the same name to the local list of available names.
- There is an error if you try to use an unqualified version of a name that has been imported multiple times.
- You can always qualify names at the point of use.

So using a qualified import is not necessary to resolve the ambiguity: you could choose to only qualify the names that do have a conflict.

I simply prefer, as a matter of personal taste, to always qualify all of my imports. I think that makes the code easier to read because, when I look at some of my code, I immediately know where a name comes from. Other people think that makes the code harder to read because all the names have long prefixes. There isn’t really a “right” answer here (except, you know, mine), it really is a matter of personal preference.

---

<div class="post-metadata">

**Author:** ![krmmalik](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/krmmalik/32/1410_2.png) [@krmmalik](https://forum.canton.network/u/krmmalik)\
**Post date:** [February 9, 2021, 4:15pm UTC](https://forum.canton.network/t/what-is-a-qualified-import/2061/4 "2021-02-09T16:15:28Z")

</div>

Thanks for your answer. I am continually impressed with how much thought has gone into DAML.  
As a non-coder but someone that has always wanted to be able to create something meaningful via code I’ve tried a number of languages and environments and ended up giving up quickly despite the community being quite large.

DAML is the first platform I have come across, where even though I am finding each day a struggle (due to my weakness in coding) I am continually inspired to continue because of what DAML makes possible.

I hope I’m still able to utter these same words in the next few months but this is how I feel about it right now.

The documentation leaves a fair bit to be desired for non-coders however, but that’s also understandable because your key demographic is probably still coders.

---

<div class="post-metadata">

**Author:** ![krmmalik](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/krmmalik/32/1410_2.png) [@krmmalik](https://forum.canton.network/u/krmmalik)\
**Post date:** [February 9, 2021, 4:18pm UTC](https://forum.canton.network/t/what-is-a-qualified-import/2061/5 "2021-02-09T16:18:53Z")

</div>

Absolutely wonderful explanation. I’m very grateful for all the time you’re taking each day to break down each point for me and really help me understand what is going on. My greatest challenge in trying to create something meaningful in any coding environment is learning to become intimately familiar with the syntax so this helps me a huge deal.

I can totally understand too, why you would qualify imports as well. When you did that, it definitely made the code easier for me to read as well.

---

<div class="post-metadata">

**Author:** ![Luciano](https://yyz2.discourse-cdn.com/flex034/user_avatar/forum.canton.network/luciano/32/319_2.png) [@Luciano](https://forum.canton.network/u/Luciano)\
**Post date:** [February 25, 2021, 7:29am UTC](https://forum.canton.network/t/what-is-a-qualified-import/2061/6 "2021-02-25T07:29:56Z")

</div>

I wrote a short blog post explaining qualified imports here:

> [@Managing namespaces in Daml](https://discuss.daml.com/t/managing-namespaces-in-daml/1984):
>
> Shortly after joining DA, I was fortunate to have the opportunity of working on a large client project making heavy use of Daml. I’d like to share one of the software engineering approaches I learnt, which I think every budding Damler runs into sooner or later: handling namespaces. In an object-oriented language like Java, class methods will have namespaces assigned automatically. For instance: class Cat { boolean fur; } In the above snippte fur inherits the Cat namespace, so you can use a …