Re: Some additional obscure questions...

[Bob Natale <Bob.Natale@AppliedSNMP.com>]

At 2/6/2003:08:36 PM, Randy Presuhn wrote:

Hi Randy,

I really want to thank you and Mike for
carrying this discussion forward.  I think
the two of you have actually helped me to
formulate an understanding of the problem
in a broader context and I will be able to
compress that understanding into a small set
of bullet items that I will post separately
later.

I do have some responses to some of the
particular points you raised in the exchange
below that I'd still like to go over at least
this one last time.

>> Again, I can't understand.  I parse all IMPORTs
>> up-front.  Is there an argument for not doing so?
>
>If module "A" defines "a" and IMPORTS "b", and module
>"B" defines "b" and IMPORTS "a", this strategy will fail.

That's another "circular" example.  I just don't think
they are very compelling.

>I guess it comes down to how one looks at compiler design.

Yes, that is definitely true.  And your and Mike's
postings have caused me to wake up to the fact that
when we (in our industry) use the term "MIB compiler"
we are often talking about different tools that are
designed to meet different sets of requirements
(albeit with some intersections).

>If one starts from the premise that SMIv2 is genetically related
>to ASN.1, it's very natural to support references like these, since
>the ASN.1 specifications are very emphatic that these sorts of
>things are legitimate ASN.1  Of course, this is just developer
>psychology.

Understood.  And you're right (by implication here):
I don't start from that position exactly -- I start
from the premise that the SMI is some incompletely
defined adaptation of a subset of ASN.1.  The
"incompleteness" and "adapted" aspects lead to
difficulties about assumptions based on pure ASN.1
(about which I am not even remotely an authority).

>> I don't consider type references to be "forward
>> references" of consequence...only those that
>> "violate" (my opinion) naming hierarchy consistency
>> rules.
>
>I'd strongly disagree here, though this is a function of what
>the compiler needs to generate.  If one wants to generate
>code for range checks, etc., or to produce informative
>diagnostics in the case where the MIB author has erred,
>resolution of (potentially forward) type references matters
>a great deal.

Agreed.  In my case, I have a much more limited set
of requirements for my "MIB compiler" -- ensure that
input MIBs satisfy the fixed syntactic requirements
of the SMI and generate structured output formats
for MIB access runtime functions.

>...
>> Sorry, I just don't follow your thinking here.
>> TruthValue should parsed at the IMPORTS statement;
>> at that point, its permissible SYNTAX values are
>> known.
>
>That's certainly not the way I would have implemented it,
>though I freely admit that my thinking about SMIv2 is colored
>by its ASN.1 "parentage".

Ok.  I admit I don't know enough about pure ASN.1
to say why you should not parse an object definition
when at the IMPORT point...but in practice that seems
to work very well for my purposes.

>> >Resolving things after the parsing phase, as opposed to during, qualifies
>> >as forward-referencing in my book.  Perhaps not yours and that's why we've
>> >got some disagreement on some of the issues.
>>
>> Maybe.  Maybe I'm just losing track of terminology
>> here.  Or maybe I'm not understanding your examples.
>> Clearly it's my view that the above TruthValue example
>> is an example of what I *want* to see...and not a
>> forward reference of any kind.
>
>Even if the TC definition appears *later* in the *same* module?

This never *needs* to happen (IMHO).  Good practice
and common sense argues for defining TCs before you
use them in object definitions.

If it *had* to happen...by some explicit requirement
of the SMI or by some unavoidable consequence of
other explicit requirements of the SMI...then I'd
have a different opinion about supporting such
forward references.

>> >Not supporting them just means that someone, somewhere, will get to deal
>> >with the headache when their MIB doesn't work with a particular compiler
>> >because they put 'b' before 'a'.
>>
>> No, it means they should have put 'a' before 'b'
>> because it is consistent with the naming hierarchy
>> design of the SMI.  It means that enforcing such
>> consistency will likely aid them in avoiding even
>> greater design carelessness in the future.  Furthermore,
>> the effort to put 'a' before 'b' is not significant,
>> assuming that one puts some effort into the up-front
>> MIB design process.  We should always encourage that
>> and discourage unnecessary looseness that permits
>> people to skimp on up-front analysis and design.
>...
>
>If one imports "a" from a "real" ASN.1 module, all bets are off
>that a single-pass depth-first algorithm will work.

I'll take your word for that.  I guess I'm assuming
that we're importing from SNMP SMI modules and that
that is not the same as a "real" ASN.1 module.

Again, thanks a lot.  My understanding has broadened.
My basic position has not changed, but the context
for which I would now assert is more limited.  As I
said, I will sum this up in a small bullet list in
a separate message a bit later.

Cheers,

BobN