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.

[HT154]

Sorry for the delay on this, it got lost in the shuffle!

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

Amending notably does not extend a module. A module that extends another may define further non-local members. Put differently, if module A extends module B, that's similar to writing class A extends B { ... }; if module A amends module B, that's similar to saying a = new B { ... } (or a = (b) { ... }, if module B also amends a module).

Extending a module to inherit its unqualified type resolution is certainly a valid pattern in Pkl! That said, it may not be desirable in all cases.

Instead, a from import 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.

The feature request I linked previously (#966) covers this. We are soliciting feedback there to help prioritize this feature, so I'd encourage you to chime in over in that thread to provide some context about your use case and how that would improve your DSL's user experience.

[Frnd-me]

Thanks, I commented at #966.

[Frnd-me]

Checking in on this, is there any feedback regarding the expected behavior here?