Subject: snmpconf some language issues

From: Steve Moulton <[email-masked]>
Date: Mon, 19 Mar 2001 21:22:03 -0500

There has been some language issues discussion among a few people
that needs to be forwarded to the list.  Here it is.

	- Steve

---

Steve,

A quick read of the comments suggests that we should post to the main
list. I do not agree with all the proposed changes, but they indicate at
least one engineers questions on reading the current draft. If ray has a
question, then others might. Even if we choose not to include goto (and
for now I would probably come down on the side of not including int), we
can answer the question. 

I do not see any show stoppers here though.
/jon
> 
> Ray is working his way through the language in building a compiler,
> and the following issues have come up in the -05 draft in the
> repository.  
> 
> 	- Steve
> 
> 
> ------- Forwarded Message
> 
> From: Ray Byler <[email-masked]>
> Message-Id: <[email-masked]>
> To: [email-masked]
> 
> 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.
> 
> 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.
> 
> ========================================================
> 
> 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;
> 
> 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?
> 
> ========================================================
> 
> 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.
> 
> ========================================================
> 
> 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.
> 
> ========================================================
> 
> 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.
> 
> ========================================================
>  
> 
> ------- End of Forwarded Message
> 
> 
> 
> 

Thanks,
/jon
--

Jon Saperia		     [email-masked]
			     Phone: 617-744-1079
			     Fax:   617-249-0874
			     http://www.jdscons.com/

------- End of Forwarded Message

---

From: Steve Waldbusser <[email-masked]>
Date: Tue, 20 Mar 2001 13:19:39 -0800

Ray, Steve,

> 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".

> enclosing loops to a label for some sort of special

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

> allows us to write things like:

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

> developer on his own to figure out what is allowed

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

> 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.

> 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.

> 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