From import

[Frnd-me]

As far as I understand from the documentation, a module prefix is required when importing, so all imported members must be accessed via their module name. While this ensures clarity, it introduces significant syntactic noise. Would it be possible to introduce a from "..." import ... syntax to allow unqualified access to specific module members?

So going from:

import "module.pkl"

...

  states {
    ["a"] = new module.Initial {
      after {
        ["t"] = new module.Timeout {
          delay = "10"
          do = new module. Raise { event = new module.Internal { topic = "e" } }
        }
      }
      
...

To:

from "module.pkl" import Initial, Timeout, Raise
// or
from "module.pkl" import *

  states {
    ["a"] = new Initial {
      after {
        ["t"] = new Timeout {
          delay = "10"
          do = new Raise { event = new Internal { topic = "e" } }
        }
      }

My specific use case is a Pkl-based DSL where references to the module name are frequent.

[HT154]

Hi there!

If you using module amending, you do get the behavior you're looking for:

amends "module.pkl"

...

  states {
    ["a"] = new Initial {
      after {
        ["t"] = new Timeout {
          delay = "10"
          do = new Raise { event = new Internal { topic = "e" } }
        }
      }
      
...

Amending a module puts all types (classes and typealiases) defined in the parent (or any of its parents) in scope. Notably, properties and methods are treated differently and require explicit qualification with module.<name>.

Also worth noting: module is a keyword in Pkl. Naming a module module.pkl and importing it requires you to use backticks to disambiguate module as an identifier, eg.

import "module.pkl"
foo = new `module`.Initial { ... }

Related topics have come up a few times in the past:

• Issue covering import destructuring: [Feature Request] Import deconstruction (& aliasing/macros) #966. We're soliciting feedback here so I'd encourage you to chime in!
• Why wildcard imports and import inheritance is problematic allow to inherit imports from amended file #865
• Explicit aliasing of imported types to make them available to amending modules Have an imported module in a template be available when amending it #758

[Frnd-me]

Hello, thanks for your quick reply :)

Amending is not quite the same, in my opinion, because it necessarily extends the module. However, one may not always want to do this.

For example, one cannot define a new property, method, or class in the module because it would be unresolved: it cannot be found in the module being extended (in case of a property), or it would need to be declared local. As written in the documentation, "As a consequence, it cannot define new properties, methods, or classes, unless they are declared as local."

amends "module.pkl"

foo = StateMachine {
...
  states {
    ["a"] = new Initial {
      after {
        ["t"] = new Timeout {
          delay = "10"
          do = new Raise { event = new Internal { topic = "e" } }
        }
      }     
...
}

Here, foo would be unresolved (assuming that it does not exist in module.pkl. New modules that are not extended cannot be created in that way, which may be considered quite restrictive.

Instead, a from <module> import <identifiers> is a common feature in other languages that does not allow extending/amending a module; rather, it specifies which parts of the module should be placed in scope.