Allow import(...) in typealiases

[sin-ack]

I'm currently working on a Pkl-based DSL for an internal tool at work, where we have many abstract classes with concrete implementations the user is intended to pull in. I want to make it easier for our users to do this. Consider the following:

import "@package/actions/foo.pkl" as actions_foo
import "@package/missions/foo.pkl" as missions_foo

missions {
    new missions_foo.FooMission {
        // ...
    }
}

actions {
    new actions_foo.FooAction {
        // ...
    }
}

I first tried doing this:

local FooAction = import("@package/actions/foo.pkl").FooAction

However Pkl told me that I can't use locals as types. Then I tried typealias, like this:

local typealias FooAction = import("@package/actions/foo.pkl").FooAction

This one fails with a cryptic "No viable alternative" error, which I presume comes from ANTLR. Right now, I have to resort to this:

import "@package/actions/foo.pkl" as actions_foo
import "@package/missions/foo.pkl" as missions_foo

local typealias FooAction = actions_foo.FooAction
local typealias FooMission = missions_foo.FooMission

Which works, but is ugly. Would it be possible to allow import() calls in typealiases? Is it a good idea?

[StefMa]

I guess you can create a PklProject file and add your imports as dependencies.
You can't really rename the modules but with that approach they are shorter to use in your pkl files.

Wait.. Nevermind. Just realized that you used the same name of your module pkl files 🙈

[holzensp]

import("something") is an expression (i.e. value), as opposed to a type, so it has rather hefty implications for parsers (and especially IDE autocomplete) to mix those domains. That said, the stated objective...

where we have many abstract classes with concrete implementations the user is intended to pull in. I want to make it easier for our users to do this.

... sets of a few low-level alarm bells, though. Are you absolutely sure people need to extends classes? In most cases, amends is enough, even for derived properties. Have a look at the last repository that I defunctionized: https://github.com/holzensp/pklTsConfig/commits/main/ (I got started from this commit)

"No viable alternative" error, which I presume comes from ANTLR.

Your presumption is correct. We're working on improving that, but It's Complicated™.

Which works, but is ugly.

Why is this ugly? Okay, you bind a name, which you might have been able to do without, but is that prohibitive?

[sin-ack]

Are you absolutely sure people need to extends classes? In most cases, amends is enough, even for derived properties.

I have a Listing<Base> defined within the template that I provide to the users as the "entrypoint". How would this work with amends? Here's an example:

// src/provider.pkl
abstract class Provider {
  fixed kind: String

  // Some properties that should exist on every provider...
  a: Int
}

// src/providers/foo.pkl
import "../provider.pkl"

class FooProvider extends Provider {
  fixed kind = "foo"

  // Some new properties...
  b: Int
}

// main.pkl

providers: Listing<Provider> // <-- How would I ensure type correctness with "amends"?

// User code
amends "@dependency/main.pkl"

import "@dependency/providers/foo.pkl"

providers {
  new foo.FooProvider {
    a = 1
    b = 2
  }
}

Why is this ugly? Okay, you bind a name, which you might have been able to do without, but is that prohibitive?

It's certainly not a dealbreaker, but it would be much nicer to be able to simplify it to one statement. In my head the way it worked is similar to Typescript's import() expression, which is allowed in their type declarations. Although, even better would be default export of a type from a Pkl file, but that might be pushing it too far...