Re: Sane syntax

On Fri, Sep 14, 2012 at 6:10 PM, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On 09/14/2012 01:23 AM, Kinkie wrote:
>
>> 3. define a sane overall syntax, ignoring backwards compatibility,
>
> I am not sure others would support such a significant change/effort, but
> here is how I would approach this:
>
> I. Change parsing code so that all options have to call something like
>
> ConfigParser::nextElement()
>
> rather than calling one of
>
> strtok(NULL, w_space),
> strtok(NULL, my_special_pattern), or
> ConfigParser::strtokFile()
>
> functions and their combinations or variations. Converging on a
> well-defined element extraction API will require non-trivial adjustment
> of some of the parsing code, especially the one that uses custom
> strtok() patterns, such as "eol" parsing code. The syntax of some of
> those eol options will be changed.

Yes. An even more ambitious goal would be to remove responsiblity of
tokenising and making sense of the tokens from the modules,
themselves, moving that to a common framework to which modules
register interest.

Something like:
ConfigParser::RegisterKeyword("somekeyword",ConfigParseCallback);
LocalModule::ConfigParseCallback(String Keyword, list<string>
arguments, list<pair<string:string>> options)

Such a framework could accept lines in the form:
directive arg [arg..] option=value [option=value]

And could support in the framework things like quoting, subfile
inclusion, conditions etc.

For such operations I would suggest to use a generally familiar c-like
syntax instead of kludigng around what we have now
Things like:

directive_with_subfile readfrom(filelocation) option=modifier
include(filelocation)

> We may need to add a robust block-quoting mechanism to handle inclusion
> of HTML and other quote-reach text (see err_html_text for example).
> Alternatively, such directives should be converted to load their text
> from a file.

Blockquoting seems interesting. Also a blockcomment could be handy.

-- 
    /kinkie