
Universal configuration language - peterbotond
https://github.com/vstakhov/libucl
======
lifthrasiir
Any sufficiently complicated configuration language contains an ad hoc,
informally-specified, bug-ridden, slow implementation of half of Common Lisp.
[1]

[1] A variation of
[https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule](https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule)

~~~
CmonDev
Isn't it ironic how they are used more than Lisp though? Maybe they don't
implement that other, worse part?

------
usrusr
Yet another tool to parse one large string into a map of smaller strings.
Trouble with configuration files is rarely caused by insufficient syntax
features, but insufficient schema validation seems to be a consistent source
of wtf-moments: a mistyped key here, a duplicate key there, that's what is
stealing our time (duplicate key: first definition wins? last definition wins?
both get concatenated? doesn't matter, if i was aware of having two of them i
would have fixed it in a second).

What i want from a configuration helper library is nothing less than an
internal DSL for specifying the typed structure of allowed/expected keys,
together with their default values and a short "what is this" description
available at runtime. This would be enough to generate nice empty
configuration templates and create warnings for unexpected keys (be it from
typos or from unexpected duplicates).

Fancy syntax features for the configuration files themselves would be only
secondary niceties. And candidates for "stupid" preprocessors ("stupid" in
that they would not have to know about the appllicaton's configuration
schema).

~~~
cebka
UCL has support for json schema ([http://json-schema.org/](http://json-
schema.org/)) so you can achieve some cool things with it. However, it is
apparently not a full DSL.

------
moe
This looks terrible. An "almost-JSON" with... macros? Seriously?

What problem is this looking to solve?

Why not just use TOML or YAML?

~~~
espadrine
JSON offers data structures that everybody understands, so having a
configuration language that has exactly those is what I want in a
configuration language.

TOML isn't it (some JSON can't be put in TOML by design). YAML is definitely
easier to edit than JSON, but just like XML its flaw is in its complexity
(both in syntax and in specialized structures, such as references or types).

That's why I made dotset
([http://espadrine.github.io/dotset/](http://espadrine.github.io/dotset/)). It
doesn't have macros™. And it's a YAML subset.

~~~
vidarh
YAML horrible enough to make me avoid tools when I have other alternatives of
functional parity.

Semantic whitespace is the second most horrible syntax "feature" after lisp-y
parentheses. I even prefer XML over YAML.

------
andridk
Currently, I prefer [toml]([https://github.com/toml-
lang/toml](https://github.com/toml-lang/toml)) for configuration. Both
languages can be exported to JSON.

~~~
fibo
TOML is nice, but also YAML is Great! Both coming from Perl community btw

------
andrewaylett
I am, I'm sorry to say, unconvinced. I'm not keen on 'magic' behaviours like
auto-converting of values to arrays -- while the behaviour of the document may
be well specified globally, it's nice to be able to see what something's going
to do based on immediate (or even no) context.

What I'm very much liking at the moment is the way Dropwizard uses Jackson's
YAML (and by extension, JSON) parsing for configuration -- your configuration
file maps 1-1 to a class in your application, and Jackson is configured to
fail if you're either missing a field that's not marked as optional or you've
got extra fields in your YAML that don't map to anything. Type-safety FTW!

On the subject of wanting to refer to earlier bits of configuration: if you
need to use one value as part of another, your configuration system might not
be exposing the right level of detail. Of course, you might not be able to
change that.

------
clarkm
This has some good ideas, but it's very similar to HOCON. I think it's more
worthwhile to focus on improving the HOCON spec rather than building yet
another configuration json superset.

[https://github.com/typesafehub/config/blob/master/HOCON.md](https://github.com/typesafehub/config/blob/master/HOCON.md)

------
bshimmin
The "Automatic arrays creation" bit rather worries me - it strikes me that
very often if you have non-unique keys, it's because you've made a mistake, so
automatically converting that object into an array would probably result in
misconfiguration.

------
_random_
Looks interesting, however the only reason JSON is generally used IMHO is
because it's light and compatible. There is no reason to make the new language
look like JS (a lame legacy language). It could look like YAML but still
support JSON for legacy stuff.

------
moomin
Doesn't Lisp already exist?

~~~
krapp
A "configuration language" by definition (in my opinion) should not be Turing
complete. A configuration language is for storing state - key/value pairs or
simple structures of primitive types, nothing more (or as little more as
necessary), nothing less.

Once you introduce enough complexity (branching, recursion) you've just
created another application with global variables for the main application to
access - a capability that will probably almost never be desired (see XML),
and the ability to unserialize into functions or otherwise executable code,
which will also almost never be desired (XML, Yaml, probably a lot of things.)

~~~
chriswarbo
> A "configuration language" by definition (in my opinion) should not be
> Turing complete.

One of the key insights of LISP is that s-expressions are a simple, universal
format. Yes, they can be used for code, but they can also be used for static
configuration data. In fact, LISP originally used s-expressions _solely_ for
data; code was meant to be written with m-expressions (
[http://en.wikipedia.org/wiki/M-expression](http://en.wikipedia.org/wiki/M-expression)
). Once `eval` was implemented, s-expressions could be used for code and data,
so the idea of m-expressions was abandoned.

> A configuration language is for storing state - key/value pairs or simple
> structures of primitive types, nothing more (or as little more as
> necessary), nothing less.

The trouble with "universal" formats like this is that there's no universal
agreement on what's a "primitive type" (what happens when I write `0.1`? Are
booleans primitive, or should we use `0` and `1`?) and what's a "simple
structure" (can I make a circular list?). That in itself wouldn't be too bad,
but these languages tend to hard-code special syntax to particular types and
structures, so any types or structures we may want to add must either be
second-class citizens, or would require hacking the parser.

~~~
krapp
I suppose you would have to draw a in the sand somewhere as far as types go,
and it depends on the language. I know TOML allows dates as a type, which
seems useful, but then you could just stick to ints and use Unix timestamps, I
guess it depends on how strict you want to be.

But to me, a primitive type at least can't evaluate to anything other than
itself, and also doesn't include pointers or references. In Lisp terms I guess
it would be an atom? Likely at least numeric values, booleans (in whatever
form), chars and some kind of tainted string (tainted in that it can't be
evaluated as code, even if you try to do so.)

>and what's a "simple structure" (can I make a circular list?)

A simple structure as I define it is a collection that contains primitive
types, so not, like, an array of function pointers or anything. Array, struct,
tuple, map, etc. I think a circular list as a type might be interesting and
definitely useful (does it exist anywhere?) If I ever design a programming
language that's one of the things I want to add.

------
jermo
The Typesafe Config is somewhat similar in the JVM world.

[https://github.com/typesafehub/config](https://github.com/typesafehub/config)

------
sysk
[http://xkcd.com/927/](http://xkcd.com/927/)

