Re: snmpconf some language issues

[Steve Waldbusser <waldbusser@xxxxxxxxxxxxxx>]

Ray, Steve,

  Thanks for the comments. Look for my responses inline:


> The policy language document doesn't define what
> "break" and "continue" do.  Are
> their actions the same as in C i.e. break causes
> the innermost enclosing loop to be exited immediately.

The key to understanding this is in the following text from section 6:

  This language is formally defined as a subset of ISO C++ [19], but
  only allows those constructs that may be expressed in the Extended
  Backus-Naur Form (EBNF) documented here. This is done because while
  EBNF doesn't fully specify syntactical rules (it allows constructs
  that are invalid) and doesn't specify semantic rules, it can
  successfully be used to define the subset of the language that is
  required for conformance to this standard. Unless explicitly described
  herein, the meaning of any construct expressed in the EBNF can be
found
  by reference to the ISO C++ standard.

There's two ways to restate this:


1. Imagine 3 sets of syntax, X, Y, and Z:

  Where X is *any syntax*, Y is C++ syntax, and Z is PolicyScript
  syntax. Y is a subset of X and Z is a subset of Y:

     X

       |-----------------|
       |  Y              |
       |    |------|     |
       |    |      |     |
       |    |  Z   |     |
       |    |      |     |
       |    |------|     |
       |                 |
       |-----------------|

  X allows the construct "foreach i (*)", but the C++ spec doesn't
  allow that syntax, so it is excluded from Y. Y allows "ap->next",
  but the PolicyScript BNF doesn't allow it, so it is excluded from
  Z. Z (PolicyScript) contains all syntax that is both valid C++ AND
  valid in the PolicyScript BNF. Or you could imagine running code
  conformant to the PolicyScript BNF through a C++ compiler. If it
  barfs, it was bad PolicyScript.

2. All the policyScript BNF does is subset C++, providing much (but
   not all of the syntactical definition of PolicyScript.  It defers
   some syntax and nearly all semantics to C++.

   In other words, if something isn't specifically defined in
   PolicyScript, it is whatever the C++ spec says.

It's important to note the statement "EBNF doesn't fully specify
syntactical rules (it allows constructs > that are invalid)". For
example, the C BNF allows 'continue' and 'break' outside of loops and
switches. The following examples are valid in the BNF but not in the
language.

test(){
    continue;
    break;

    int i;
    i = ++sizeof(i);

    printf("") = 5;
}

Many things like these are practically impossible to define using a
BNF. (BTW, the C BNF can be found at
http://wwwold.dkuug.dk/jtc1/sc22/open/n2794/n2794.txt
in Annex A on page 465.)

Anyway, the answer to your question is "refer to the C++ spec".

> If this is the case then you might want to consider
> adding goto to the jump statements (and a label to go
> with it).  This would allow you to jump out of all
> enclosing loops to a label for some sort of special
> handling.

Yes, that was considered a while ago but skipped because it was seen as
not very important for policy scripts.


> Also the language as written allows us to do things we
> probably don't want to do with string_literals and
> char_constants. For example,
>
> string_literal --> primary_expression -->
>     postfix_expression --> unary_expression
>
> char_constant  --> primary_expression -->
>     postfix_expression --> unary_expression
>
> allows us to write things like:
>
>             "abc" = 99;
>             'c'   = 4;

Yes, this is in the same spirit of my examples above.

> Many C language definitions allow this too,
> leaving it to C type-checking to catch.  Is each
> developer on his own to figure out what is allowed
> for LHV and RHV?

As you might expect, the answer is "you must do what C++ says to do".

> Since all variables are in the same scope, I'm assuming
> that once declared, variables stay around and are not
> discarded on leaving a block.
>
> Having all variables in a single scope and allowing them to
> be declared anywhere presents a problem.
>
>         var a = 5;
>
>         var a;
>
> Does the value of a remain 5, or is it reinitialized?  The
> simplest solution, of course,  is simply not to allow it
> i.e. redefinition of a variable should be a semantic error.

It isn't allowed because it is in the same scope. Refer to C++'s rules
for redeclaring variables in the same scope.

> Do we want to allow variables to have the same names as
> library functions e.g. "var writeVar = 5;" ?
> It greatly simplifies things if we don't allow this.

I'm deeply conflicted. If it greatly simplifies things I'm all for it.
But I'm concerned it might be a can of worms. I'm still thinking.

> If the use of a reserved word such as "auto" must cause
> a RTE, then the lexer has to be expanded to check for all
> these reserved words.  That greatly expands the size of
> the lexer in a limited-memory environment.  It would be
> better to make this a recommendation and not a requirement.

As a recommendation it has little value, so the choices are to make it a
requirement or get rid of it. Originally I thought this was low cost so
I was OK with it. Now I'm leaning towards getting rid of it.


Steve