Subject: snmpconf Policy MIB: General language issues

From: Pablo Halpern <[email-masked]>
Date: Fri, 03 Nov 2000 16:30:32 -0500

Hi,

I'm working with Jon Saperia on implementing the Policy-based management 
MIB. In reading the October 11 draft, I came up with a number of issues 
related to the C-like language that is described in the document. Jon 
encouraged me to air these issues in this forum, so that we can get other 
people's brains involved. In order to keep the discussion manageable, I 
will post each issue with a different subject line, so that each issue can 
have its own thread of discussion.  First, though, here are some general 
thoughts:

I understand that we trying not to create a new language. However, we must 
recognize that any time we try to create a subset of a language, we are, in 
effect, creating a new language. Imagine, for example, if we were to say, 
"We're going to write a book. The story will be a subset of 'The Wizard of 
Oz'. Some examples of features that will be removed are the wicked witch, 
the tornado, and all mention of Kansas." The resulting story would, of 
course, be much shorter than the original, but we could not create it just 
be chopping out parts. We would have to plug up the holes in the story line 
in order for it to hold together.  We would have to create additional 
pieces of plot to explain what the characters are doing in Oz, why the are 
seeking out the Wizard, etc. The final book would retain some of the flavor 
of "The Wizard of Oz", but would not be a simple subset.

So it is with the language we are "not creating" here. We are chopping out 
about 75% of the language; not just pointers, structures, and floating 
point, but also function definitions, void, volatile, const, enum, storage 
classes, linkage, sizeof, unions and more. This leaves some major holes 
that must be plugged if the language is to hold together. For example, what 
does "char*" mean if there are no pointers?  Failure to plug these holes 
with NEW (read non-C) syntax and semantics will leave a lot to the 
implementor's imagination, resulting in serious interoperability problems.

In the next few posts I make to this list, I will be proposing some 
additions to the language. My intent is not to create a new language except 
to the degree that it is necessary to make it work. Please read my 
proposals with that in mind.

- Pablo
---------------------------------------------------------------------
Pablo Halpern                                    [email-masked]
http://www.halpernwightsoftware.com