[Docs] Future plans for type system & type inference?

[izelnakri]

Hi again @JakeStanger,

I couldn't find any mentions for a plan to adopt/not-to-adopt an advanced type system. Have you considered eventually to implement types? Seems like this could be a great feature and I bet you've already thought about this ;) This could be particularly useful for things like kubernetes-helm customizations, OpenAPI specs, bigger system-level configurations.

Would be great if you could share your plans or thoughts about a more advanced type system somewhere in the docs.

Thanks again for the cornlang, fantastic work!

[JakeStanger]

Hey, types are not something I want to add into the language/spec as I think that's a detail for the consuming application to consider, not the configuration language. I believe that if you delegate too much to the configuration, it starts taking on the role of the programming language.

For example, when using through Rust & serde, you already get strong typing through Rust's type system and get a deserialization error if your config does not match the struct 'schema'.

That said, I am open to the idea of some typing through the tooling, perhaps with integration for JSON schemas so that you do get some real-time feedback.

Another possible option is to open up the parser's error handling a bit so that application code could hook into that and throw a parser error with the same detailed span & trace info that you get already, so that it looks seamless to the end user.

[izelnakri]

Eventually I think I'll use the corn-cli for building helm charts locally with my helm package tool helman. I had built helman 4 years ago and haven't checked the updates since then, 4 years ago helm didnt have a way to have a local downloads to a folder like helm_charts or having them versioned locally, like one would do with npm, cargo etc.

I might tie $ helman build to corn so I can improve my helman workflow(if helman is still needed, helm was very basic 4 years ago). Having a typesystem runtime for corn-cli workflows could be very useful for universal typespec generation and DX. I understand your concern with keeping corn-cli runtime minimal and possibility to address some use-cases this in rust with serde.

Would you be interested in building additional cli tool/language like TypeScript for corn? Maybe tcorn or torn which could extend on corn?

Maybe there is a better practice nowadays for helm and nix-env extension use-cases that I'm not familiar with, openapi usecase could be handled in the authored programming language environment as you mentioned(serde for rust). I would have wished openapi could use something like corn, to make the outputs more readable and terse than json or yaml.

I think there might be a space for something for a more advanced typed configuration language but without nix functions,. A language with typesystem std & documentation(commenting on each key of an object) however I'm not fully up to date with all the ongoing DX efforts currently happening with the upcoming nix versions neither.

[JakeStanger]

Would you be interested in building additional cli tool/language like TypeScript for corn? Maybe tcorn or torn which could extend on corn?

This isn't something I'd want to take on myself. More than anything I just don't have the time, but I also personally don't see a need for it for the reasons above. I am open to making any changes to libcorn that'd make it easy for others to build this sort of thing though.

I think there might be a space for something for a more advanced typed configuration language but without nix functions,.

You might be interested in Apple's pkl lang they announced the other day, if you haven't seen it already. It sits somewhere between Corn and Nix and includes types.

[izelnakri]

I am open to making any changes to libcorn that'd make it easy for others to build this sort of thing though.

Pkl seems to be what I need(rather than corn) for my specific use-cases, thanks for turning my attention to Pkl. I would love it if I could convert pkl files to corn files, although this isnt in your specific interest as a compatibility research standpoint, would you be willing to introduce breaking changes to corn if some compatibility/or wild expression differences arise between corn and Pkl? Seems like you’d be interested in making such changes to libcorn if certain contribution/issues arise I just want to confirm ;)

[JakeStanger]

I'm willing to expand libcorn in a generic way to make it easier to integrate if the requirement arises, but I do not want to make changes that would be specific like tying in pkl support. I'd also like to avoid breaking changes at this point (especially to the language itself), as the language is in-use and I view it as near-complete.