Indirect module import

Let’s say I have a module A where I imported Map function from DA.Map following way:
import DA.Map (Map)

Having other module B which imports module A (qualified as AModule), can I refer to the Map function without directly importing DA.Map into the B module?

As it happens in many programming languages, importing is not transitive. There are languages that allow you to explicitly re-export modules and this is something we might look into in the future. As input to the team, what use case drives your interest into this feature?

@stefanobaghino-da thank you for reply. Well I’m new to Daml so it’s hard to find really persuading use case for input. But let’s say you build complex-ish project, reusing several basic modules (still specific to your project) in other project modules, which defines more specific behavior for specific entities/types/structures. And obviously, you need to accumulate the import list as far as you go deeper.
I’d rather ask, which use cases drive to keep import being not transitive? Honestly, hardly imagine them.

Daml modules do allow you to use an explicit export list, and if you use this you can explicitly re-export something imported from another module. So you can have a file:

module A (
  Map(..)
) where

import DA.Map (Map(..)

and

module B where

import A (Map(..))

data Test = Test (Map Int Int)

and this will work. This is behaviour inherited from Daml’s Haskell heritage, and works exactly the same way.

Andrae:

Daml modules do allow you to use an explicit export list, and if you use this you can explicitly re-export something imported from another module.

I don’t recommend to rely on this. The reexport is available in Daml but it’s not available when you interact with things over the ledger API which ime just ends up being confusing.

Oleg:

I’d rather ask, which use cases drive to keep import being not transitive?

I think this is the tendency of most modern programming languages with some form of structured module system. A good reason for this is to limit leaking unnecessary dependencies (or implementation details) into client code or having to specify a way in which you can prevent a specific import to transitively get in scope without you wanting to do so. Explicitly re-exporting makes more sense in my opinion, because it leaves the door open to the option but requires an opt-in that you general want to have control over.

Hi Andrae, doesn’t work at all. I’ve got errors right on the module A (even before starting with B):
“error: parse error on input ‘Map’”
The exact code I typed:

module Daml.Finance.Interface.Types.Common.Types(
      (Map(..)
) where

import DA.Map (Map(..)) ...

screenshot:

It’s VSCode, project sdk-version: 2.5.0.
Any ideas?

That looks like you have an extra ( between lines 4 & 5. What is the error reported by the IDE?

Oleg:

module Daml.Finance.Interface.Types.Common.Types(
      (Map(..)
) where

import DA.Map (Map(..))

Hi Andrae, sorry, my bad. I don’t know how I missed that
However I’m still verifying how the solution behaves.
Thank you so much for pointing this out!

Is it described somewhere in more details? I’m not quite sure I’ve completely got it. Maybe some other ledger API related restrictions ? Trying to find something on docs.daml.com but still no success

Daml inherits its import semantics from Haskell, so for the precise details you can refer to the Haskell 2010 Language Report.