Mike-I'm going to take this opportunity to remind us all why we have a BNF syntax description in the first place. Back when we were preparing BIRD 104, I needed to provide this explanation at one point, so perhaps now is as good a time as any for a refresher.
Obviously BNF is a software technology thing. It describes a syntax in a way which is completely rigorous and precise. It leaves no room for misinterpretation. For example, the developer of the latest version of IBISCHECK knew exactly what we meant, didn't have to ask any questions about the syntax itself, and produced a completely correct parser. From what I could see of other aspects of their work, this person is a thorough professional, so the fact that they got it right came as no surprise to me.
As is so often the case, a rigorous and precise statement doesn't exactly make great reading. For example, I don't suppose there are many people who read mathematicians' proofs for the fun of it.
At the time, Ambrish requested a "plain English" version of the specification, and I provided it. Note, however, that "plain English" is an oxymoron, and that as carefully as I tried to write that description, there's still room for misinterpretation.
I still claim that we're mixing "specification" with "tutorial" in an undisciplined way that will produce a document which does neither job well. If we really want "plain English" text that introduces the specification in a way that's easy to read and learn from, I think that's a fine idea; however, that material should go into a separate tutorial document.
My 2c. Mike Steinberger On 12/06/2010 10:19 AM, Mike LaBonte wrote:
Arpad, For reference, the complete BNF listing: | <tree>: | <branch> | | <branch>: | ( <branch name> <leaf list> ) | | <leaf list>: | <branch> | <leaf> | <leaf list> <branch> | <leaf list> <leaf> | | <leaf>: | ( <parameter name> whitespace <value list> ) | | <value list>: | <value> | <value list> whitespace <value> | <value>: | <string literals> | <decimal number> | <decimal number>e<exponent> | <decimal number>E<exponent> |My proposal doesn't use the term "leaf", but it uses "sub-branch" which is not in the BNF at all. Since all of the things I call sub-branches happen to be leaves as defined by the BNF, I now see why you used the term "leaves". Yours is more consistent, but now I'm not too keen on our BNF. I won't make any argument about the BNF because it is functional and probably entrenched.Usually leaves are just values, not branches without sub-branches, and that threw me off. Your wording talks about the leaves that an AMI Parameter has, then says it "does not contain another branch". So you have to read the BNF to understand that here, a leaf is a kind of branch. Could we use the term "leaf branch"?The only other question I had is about the handling of required, optional, and "one of these" categories. If you are trying to say that Description is optional, Type and Usage are required, and one of Default, Format, or <data_type> is required, then maybe "any of the following leaves" might be changed to "one of the following leaves". Also the part about Description might alternatively be worded "An AMI Parameter branch may also contain a Description leaf but no branches or leaves other than Type, Usage, Format, <data_format>, or Description are permitted."Mike On 12/6/10 10:14 AM, "Arpad Muranyi" <Arpad_Muranyi@xxxxxxxxxx> wrote: Mike, Thanks for your comments. The problem I see with the terminology you are suggesting is that it contradicts the BNF definition we have on pg. 187: | <leaf>: | ( <parameter name> whitespace <value list> ) In order to use your terminology, we would have to change that too. This suggestion makes me wonder what is the most widely used (or most familiar) meaning of "leaf"? Arpad ========================================================== *From:* Mike LaBonte [mailto:milabont@xxxxxxxxx] *Sent:* Friday, December 03, 2010 1:59 PM *To:* Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx *Subject:* Re: [ibis-macro] Re: About the Typos BIRD comments from Fangyi Hmmm, re-reading these emails I think this is about what terminology to use for two different things: 1) Terminology for the structure of generic LISP-like parenthetical trees. Often a branch is a sublist, and the first keyword inside the left paren is considered the name of the branch. Any other items after the branch name are leaves (aka branch values) unless they are inside their own parentheses. In this regard Description would be a branch name and the string following it would be a leaf/value. 2) Special terminology to describe a 2-level bundle of branches and leafs as "AMI parameters", where there is some datum surrounded by prescribed meta-data to help interpret it. Therefore I think Arpad's latest wording is headed in the right direction to define #2 using the terminology of #1: |* A branch in the .ami file is an "AMI Parameter" if it |* contains the leaves Type, Usage, and any of the following |* leaves: |* |* Default |* <data_format> or Format <data_format> |* |* and does not contain another branch. A branch which |* contains one or more sub-branches may only contain the |* Description <string> leaf/value pair in addition to the |* sub-branches. But I would suggest changing it to: |* A branch in the .ami file is an "AMI Parameter" if it |* contains the sub-branches Type, Usage, and any of the |* following optional sub-branches: |* |* Default |* <data_format> or Format <data_format> |* Description |* |* A branch with sub-branches arranged as an AMI Parameter may |* not contain other sub-branches. Mike On 12/3/10 11:31 AM, "Arpad Muranyi" <Arpad_Muranyi@xxxxxxxxxx> wrote: Hello AMI Experts, This thread stopped a day or so ago without reaching a conclusion. I am going to summarize the questions I would like to get answered. 1) When does a branch become an "AMI parameter"? Does this have to be spelled out in the IBIS-ATM specification, or does this belong to a Cookbook or HOWTO document? Currently this is what I have in the Typos BIRD draft: |* A branch in the .ami file is an "AMI Parameter" if it |* contains the leaves Type, Usage, and any of the following |* leaves: |* |* Default |* <data_format> or Format <data_format> |* |* and does not contain another branch. A branch which |* contains one or more sub-branches may only contain the |* Description <string> leaf/value pair in addition to the |* sub-branches. 2) What is supposed to be passed into the AMI executable model in the parameter string, and what is supposed to be omitted from this string? Does this have to be spelled out in the IBIS-ATM specification, or does this belong to a Cookbook or HOWTO document? Currently this is what I have in the Typos BIRD draft: ******************************************************************************** REMOVE THIS PARAGRAPH if the next few are agreed on:**************************** |* The tree data structure passed in and out of the DLL |* described in section 3.1.2.6 of Section 10 of this document |* is similar to the tree data structure in the .ami file except |* the 'Reserved_Parameters' and 'Model_Specific' branch names are |* not included, the "AMI Parameter" branches become leaves and |* the "AMI parameters" of Usage Info and Out are not included. END OF REMOVED PARAGRAPH******************************************************** ******************************************************************************** |* |* The parameter string passed in and out of the DLL (described in |* section 3.1.2.6 of Section 10 of this document) is formatted |* the same way as the tree data structure in the .ami file with |* the following exceptions: |* |* 1) The "Reserved_Parameters" and "Model_Specific" branch |* names are not included |* 2) None of the Description leaf/value pairs are included |* 3) AMI Parameter branches or sub branches with Usage Info |* or Usage Out are omitted, but all other branches or sub |* branches are included |* 4) AMI Parameter branches with Usage In or Usage InOut |* become leaves |* 3) Define how/where the DLL returns Out or InOut parameters and how/where the EDA tool is supposed to look for these values. Does this have to be spelled out in the IBIS-ATM specification, or does this belong to a Cookbook or HOWTO document? There is nothing on this topic in the Typos BIRD draft, nor can I find anything about this in the current IBIS specification. Thanks, Arpad ==============================================================================