3 ms·
(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
by 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 agoYeah 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 agoYes. 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.