Re: draft minutes from the sming interim:

[Dave Shield <D.T.Shield@csc.liv.ac.uk>]

> Dave> The analogy that springs to mind is HTML comments <!-- .... -->
> Dave> and their use for server-parsed configuration <!--#cmd .... -> A
> Dave> similar technique could well be used here.
> 
> Which are if I understand correctly still formally comments and not
> language featured directives...

They're comments as far as a basic HTML parser is concerned, yes.

I'm not quite sure what you mean by "language featured directives",
but XSSI seems to include both assignments and conditionals, so
has the starting points for a rudimentary programming language.
(It doesn't seem to have loop constructs - but those would be
 relatively simple to add if necessary).


> Directives might get rather complicated once you leave the space of
> simple hints for parsers to supress certain warnings/errors.
> Directives to drive code generators really are no longer simple
> directives but end up being little languages on their own.

Which is why it would seem sensible:
   a)  Not to get hung up on defining the details of such a
	language when there's some debate about the need for it.
   b)  To define a basic syntax framework for such a language
	so that it could be safely defined later, if necessary.

If, for example, this group decided on HTML-style comment syntax,
and declared <!--# ... --> as reserved for future use, then anyone
writing a new-style MIB would know to avoid this sort of contruct.
 (I'm not suggesting that this syntax would actually be the most
appropriate choice - it's just an example of the basic concept).

  As long as you could decide *now* how to recognise such compiler
directives, I don't see why you necessary need to fix the precise
details of those directives straight away.   They feel like an
"added extra" over and above the basic language.


Dave