–– Pkl Error –– Type alias definitions must not be cyclic

[Kieren]

typealias AddressedTypeMapping<T> = Mapping<String, ( AddressedTypeMapping<T> | T )>

I have tried to define the above type alias in order to be able to generate a configuration structure where specific configuration class objects can be organised in nested groups. So that the nested key Strings form an 'address' that the config file parser can instantiate as a single associated Object that might be referred to multiple times by other parts of the configuration file.

The intention is to 'flatten' or organise part of the configuration structure for usability in creating and maintaining a configuration file, while using (otherwise confusing) hierarchal structure of said objects for configuration elsewhere.

–– Pkl Error –– Type alias definitions must not be cyclic

The error generated here is quite clear and self explanatory. My question I suppose is, is this a firm restriction of the language and/or is there another way for this to be achieved with pkl?

[holzensp]

Currently, this is a hard restriction. We've been thinking about adding elements and entries to Typed objects also. That might resolve this ask. One of the problems here is that Pkl is lazy, so you can very easily "tie the knot," i.e. embed an object in itself, creating an infinite nesting. For Pkl to resolve something is a class, it only needs to have the outer structure (that is to say, it doesn't have to evaluate all the properties). Deciding whether something is a AddressedTypeMapping<T> would require forcing the entire structure. If said structure contains such self-reference, that's a StackOverflow.

[Kieren]

Thanks for clarifying this. I am trying to define a (possibly infinite) variable depth (nest-able) Mapping where the object Type T is always the leaf value of any nesting or the innermost object. I can see from your description why I can't have this though.

[bioball]

I'll also say that it's possible to implement this; we can let a stack overflow surface to users as a stack overflow.

There's many valid use-cases to want a typealias to be cyclic. For example:

typealias JsonValue = Number|Boolean|String|Null|Mapping<String, JsonValue>|Listing<JsonValue>

[Kieren]

+1 from me on that.
It would be nice to be able to define acyclic graphs – as in your more articulate example of json – while accepting the responsibility of not stuffing it up by creating a cycle leading to a stack overflow. FWIW in my use case I do want to write files that configure cyclic graphs but by using a set of acyclic ones to avoid those problems.