Are Generic types not actual types?

[rohan-datar]

I am trying to define a converter so that I can render some files in a custom format. I'm running into some issues when using generic type parameters to select different types for my converter. Here's a very simplified example of what I'm talking about:
foo.pkl

words = Listing<String> {
    "1"
    "2"
    "3"
}

numbers = Listing<Int> {
    4
    5
    6
}

myRenderer = new JsonRenderer {
   converters {
    [Listing<String>] = (i) -> toInt(i)
   }
}

output {
    files {
        ["words.json"] {
            value = words
            renderer = myRenderer
        }
        ["numbers.json"] {
            value = numbers
            renderer = JsonRenderer
        }
    }
}

This fails to evaluate with the following error:

–– Pkl Error ––
No viable alternative at input `converters {\n        [Listing<String>]`.

17 | [Listing<String>] = (i) -> toInt(i)
                     ^

Is this expected? Is there something that separates generic types that prevents them from being used in like this?

[bioball]

The issue you're running into here is that types aren't values.

When defining a converter, you're actually asked to provide a class value, and not a type. Here's the API docs for converters: https://pkl-lang.org/package-docs/pkl/current/base/ValueRenderer.html#converters

So, in the below snippet:

converters {
  [String] = (it) -> /* etc */
}

We are defining a mapping entry whose key, String is referencing an object of type Class. It's not actually a type. That's also why Pkl is erroring when you define this key:

    [Listing<String>] = (i) -> toInt(i)

This is invalid syntax, because Listing<String> cannot be interpreted as a value. And, going a little further, Pkl's converters don't provide a way to say "use this conversion for all Listing<String>". You'll need to find a different way to express your desired conversion, for example, maybe target all Listings and conditionally transform any of its members.

[rohan-datar]

I see. That makes sense.

It might be worth making this distinction in the docs. The example there is seems to imply that converters operate on types with this line:

In addition to type based converters, renderers also support path based converters:

[bioball]

Ah, thanks for pointing that out. #860 to fix.