5 ms·

As has come up in this thread already, any discussion of typed config languages nowadays that doesn't mention Cue (https://cuelang.org/ https://cuelang.org/) se

by kbd 5y ago

As has come up in this thread already, any discussion of typed config languages nowadays that doesn't mention Cue (https://cuelang.org/ https://cuelang.org/) seems incomplete. They really seem to be tackling the problem in a thorough way. I hope it catches on. For anyone who knows more about Cue: right now you can go from Cue<->yaml (in fact, their docs on yaml also use the "no" case as an example: https://cuelang.org/docs/integrations/yaml/ https://cuelang.org/docs/integrations/yaml/) to integrate with existing systems, but I suppose eventually the goal would be to have direct support in libraries like Serde?

kevincox 5y ago
(disclaimer: author) Cue is a very cool language, but it is quite different than the "typed config language" that I have described here. Maybe I picked a poor title but in the post I am talking about using the type information to "improve" parsing. IIUC Cue does not due this, it parses in a "dynamically typed" manor, then uses the type system to evaluate the turing complete (or close to it) expression language.
- kbd 5y ago
  Yeah that's why I was asking about Cue's eventual goals with libraries like Serde. I assume eventually they'd like to be able to auto-generate type definitions for a target language, but I don't know. > Cue does not due this, it parses in a "dynamically typed" manor, then uses the type system to evaluate the turing complete (or close to it) expression language. As I understand it Cue would help in two ways currently. 1. It would be able to type-check existing yaml files to catch things like the "no" case. 2. if you write your config in Cue, it would output properly-typed yaml to avoid things like "no".
  - kevincox 5y ago
    Yes. I agree. It would "prevent" the "no case" by returning an error on parse/evaluation. However the solution described here can do better. It can correctly parse the no case. Basically by knowing it is parsing a string the grammar can be simpler, it doesn't have to decide if it is a int/bool/string anymore.
assemblylang 5y ago
Was going to mention Cue. Works great in cases where you want to add a touch of structure to your existing yaml configuration, such as types and bounds checking.

by kbd 5y ago

kevincox 5y ago

(disclaimer: author) Cue is a very cool language, but it is quite different than the "typed config language" that I have described here. Maybe I picked a poor title but in the post I am talking about using the type information to "improve" parsing. IIUC Cue does not due this, it parses in a "dynamically typed" manor, then uses the type system to evaluate the turing complete (or close to it) expression language.

kbd 5y ago
Yeah that's why I was asking about Cue's eventual goals with libraries like Serde. I assume eventually they'd like to be able to auto-generate type definitions for a target language, but I don't know. > Cue does not due this, it parses in a "dynamically typed" manor, then uses the type system to evaluate the turing complete (or close to it) expression language. As I understand it Cue would help in two ways currently. 1. It would be able to type-check existing yaml files to catch things like the "no" case. 2. if you write your config in Cue, it would output properly-typed yaml to avoid things like "no".
- kevincox 5y ago
  Yes. I agree. It would "prevent" the "no case" by returning an error on parse/evaluation. However the solution described here can do better. It can correctly parse the no case. Basically by knowing it is parsing a string the grammar can be simpler, it doesn't have to decide if it is a int/bool/string anymore.

assemblylang 5y ago

Was going to mention Cue. Works great in cases where you want to add a touch of structure to your existing yaml configuration, such as types and bounds checking.