[camoberg]

Well, I would say that we did spend considerable time and energy among peoole with vast experience from designing various kinds of languages before we ended up going down the path towards what became YANG. If you poke around the IETF mailing list archives I think you will find ample amounts of justification before we were given the green light from the IAB.

I meant to say "easily readable in it's native encoding". I.e. Looking at the source in your favourite text editor.

[ZenoArrow]

Thanks for the clarification. Out of interest, did you evaluate building a Lisp DSL? If so, any pros and cons you identified from that approach? I would've thought it would have been a quicker option to get going, though if you've reached version 1 you've put in the groundwork required now.

[camoberg]

I know that parts of the original design team for YANG are old lisp-fans, but I can't recall the option of developing a lisp-based DSL ever being evaluated. I would personally suggest that the fit would not be very good, since YANG is fundamentally a modeling language that "models the hierarchical organization of data as a tree in which each node has a name, and either a value or a set of child nodes." (https://tools.ietf.org/html/rfc7950#section-4.1).

But I happen to personally think that a datalog- or lisp-based policy language for YANG-modelled data sources would be a very interesting concept.

[ZenoArrow]

> "models the hierarchical organization of data as a tree in which each node has a name, and either a value or a set of child nodes"

That matches the structure of Lisp. Lisp code is basically set out as an AST. A Lisp node basically either contains a function and a list, or a function and simple value(s). The former can be thought of as a parent node, the latter can be thought of as a child node.

[camoberg]

So what you're saying then is that YANG could be a data modeling language for Lisp ;-)