tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: proplist



On Wed, 21 Apr 2010 04:50:52 +0000
David Holland <dholland-tech%netbsd.org@localhost> wrote:

> On Thu, Apr 15, 2010 at 09:50:05PM -0400, der Mouse wrote:
>  > > Ugliness is highly subjective.  This form can be considered ugly
>  > > because it has a lot of completely extraneous double quotes.  For
>  > > example.
>  > 
>  > Not completely extraneous.  _Something_ has to delimit strings, and
>  > whether it's better to use " " or <long-string> <long-string/>
>  > is...well, I suppose "highly subjective" about covers it.
> 
> Well yes. Except, the names of *fields* generally are (and generally
> should be) identifiers, not the general case of strings. So while
> string values ultimately need to be quoted or escaped somehow, field
> names shouldn't be. This leads to formats like
> 
>       foo {
>          bar = 3;
>          baz = "qwerty";
>       }
> 
> (modulo assorted variant punctuation)
> 
> which are in general much easier to read and edit and thus much more
> suitable for config files than XML is.
> 
> The parsing for any of these formats, even the Common Lisp one, is
> trivial. The hard part is interfacing the parser results to an
> [...]

When I wrote the examples I was tempted in using symbols instead of
strings for the key part, but to preserve case, | would then have to be
used instead of " so quoting would still have been required.  Of course
that is specific to the CL standard reader which by default converts
symbol names to uppercase.

But as you previously mentioned, avoiding to use the native reader could
also be more secure, allowing full control over recursion, allocation,
what gets imported into the environment and what gets evaluated.  Then
any simple recursive text format for which only a minimal parser is
necessary could do for any language (including one similar to what you
suggested, which I agree is sane for configuration files).  This also
reminds me of some previous work in this area, including libcfg+...
-- 
Matt


Home | Main Index | Thread Index | Old Index