What is PCF exactly?

[joffrey-bion]

It is mentioned in a couple places that PCL PCF is a static subset of PKL. Are there any details about what this subset is made of? And spec or documentation for it?

[bioball]

Are you referring to PCF? We do not have a specification for it yet. But, PCF is basically "Pkl, but only the data".

[joffrey-bion]

Thanks, yeah it was a typo, on the most important word of the question 😅 sorry. Fixed.

Yeah I understood the part about being the static subset of PKL, but I wanted to know if I can read more about it anywhere (like what exactly is allowed and forbidden).
For some applications, PKL might be slightly to programmable, while PCF is probably declarative enough. It would be great to be able to impose the strictness of PCF in the input too

[odenix]

I wonder if there could be multiple dialects that we can select from when authoring a module. For example: fully static, mostly static (e.g., static + variables), fully dynamic. Just a thought.

[sdeleuze]

I would be interested by more details on PCF as well (spec, tooling) for the same reasons than @joffrey-bion.

[sanabel-al-firdaws]

this question is important to know if i should use pkl to generate json or use PCF insted of json

[bioball]

Generally, you should either generate a well-known static format (like JSON/YAML), or eval into structs/classes in the various language bindings that exist.

[sin-ack]

I would like some information on this as well. My use-case is that we have two layers of configuration where a higher-level definition orchestrates lower-level isolated tasks and passes configuration down to them. These files cannot be evaluated together because they are within different layers of the application. I have a Pkl serializer which emits an expression that can be passed in using a client module reader (throws for any typed object that's non-Dynamic for now), and use that to pass the configuration down. If there was a "formal" specification of PCF I could reference this in my serializer and explicitly know what to and not to support.

A tangential question: Are all PCF expressions valid Pkl expressions if embedded within a Dynamic?

[bioball]

A tangential question: Are all PCF expressions valid Pkl expressions if embedded within a Dynamic?

Yes, that's the goal of PCF, although there's this edge-case where this is valid PCF but not valid Pkl:

foo {
  [new {}] = 1
}

You can import a PCF file directly into Pkl, but you'd lose any types that the data originally came from. This adds a lot of rough corners if you're trying to consume said PCF in Pkl, because the types might be important for the semantics of your program.

Are your two configuration layers both Pkl eval's? If so, I think #994 would be a better fit for what you're trying to do. With this, you'd be able to do something like:

// in the higher level layer

output {
  bytes = new Serializer {}.serialize(myValue)
}

// in the lower level layer
value = new Deserializer {}.deserialize(read("someFile").bytes)

[sin-ack]

Are your two configuration layers both Pkl eval's?

Yup.

If so, I think #994 would be a better fit for what you're trying to do.

Yup, that would be a huge help! However, how would that handle stuff like typed objects, the originating classes of which may not necessarily exist within the scope of the lower-layer module?

[bioball]

Ah, the lower-layer module would need to have the same packages available, otherwise it wouldn't be able to initialize instance of those types.

[sin-ack]

Right. The idea is that the upper layer sends down something shapeless to the lower layer which can then deserialize it into a "schema" by doing something like:

local config = new Configuration {
    ...(import("configuration:///this").config)
}