Re: Some additional obscure questions...

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "Bob Natale" <Bob.Natale@AppliedSNMP.com>
> To: "Michael Kirkham" <mikek@muonics.com>
> Cc: <mibs@ops.ietf.org>
> Sent: Thursday, February 06, 2003 3:41 PM
> Subject: Re: Some additional obscure questions...
...
> 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.

I guess it comes down to how one looks at compiler design.
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.

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

> >Whether or not this falls into the common definition of a forward
> >reference is probably debatable.  Depending on the implementation, the
> >definition of 'TruthValue' may or may not be known at the time this object
> >is parsed.  But I doubt many compiler implementations are going to try to
> >figure out what 'false' means immediately upon parsing it.  They're going
> >to save it off somewhere in internal data structures to deal with once
> >everything is parsed, at which point it can do post-processing stuff that
> >includes verifying that 'false' is an okay DEFVAL for this object.  In
> >order to do that, the compiler is going to have to retain some of the
> >symbolic nature of the parsed data and resolve 'false' later through
> >implementation-specific algorithms.

That's exactly what I'd do.

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

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

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

Randy