> On 24 Dec 2013, at 7:40 am, [email protected] wrote:
>
> > The VHDL standards says nothing about the error messages. It just
> > says what is a correct unit and what isn't.
>
> I don't understand the term 'unit' in this context.
I mean design unit.
> And yet you are not parsing the last choice (generate_statement) of
> the context (concurrent_statement) as if it were a context free
> grammar.
>
> 0.2.1 Syntactic description
>
> The form of a VHDL description is described by means of context-free
> syntax,...
> -----
>
> Instead you are treating it as one of Monsieur Tesnière's Dependency
> Grammars insisting that the first replacement rule (generate_label)
> must be missing due to oversight, when the fledgling VHDL design
> description author in this case was trying to use a sequential
> statement where it was not allowed, blocked in a Context Free
> Grammar by the lack of a label production. You are taking context
> without a basis in intent nor the syntactic description.
>
> And yes the it was detectable through your error messages.
>
> Translating Context Free Grammar into it's other common description,
> Phrase Structure Grammar allows one to see you were treating the
> generate_statement rule as a dependency grammar. You do the same
> thing with the keyword Postponed for the same last choice rule where
> instead is should be dealt with:
>
> concurrent_assertion_statement ::= [§
> 9.4]
> [ label : ] [ postponed ] assertion ;
>
> concurrent_procedure_call_statement ::= [§
> 9.3]
>
> [ label : ] [ postponed ] procedure_call ;
>
> concurrent_signal_assignment_statement ::= [§
> 9.5]
>
> [ label : ] [ postponed ] conditional_signal_assignment
> | [ label : ] [ postponed ] selected_signal_assignment
>
> process_statement ::= [§
> 9.2]
>
> [ process_label : ]
> [ postponed ] process [ ( sensitivity_list ) ] [ is ]
> process_declarative_part
> begin
> process_statement_part
> end [ postponed ] process [ process_label ] ;
>
> for disambiguating between concurrent statements for assertion,
> procedure call, signal assignment and process statement.
>
> And without seriously checking, assuming ghdl supports the use of
> postponed, disambiguation is done through a lookahead of one (from
> Postponed) determining that the following token is an identifier and
> predicate tests on the identifier to determine how it is declared.
>
> And ghdl appears to do that:
>
> when Tok_Identifier =>
> Target := Parse_Name (Allow_Indexes => True);
> Stmt := Parse_Concurrent_Assignment (Target);
> if Get_Kind (Stmt) =
> Iir_Kind_Component_Instantiation_Statement
> and then Postponed
> then
> Error_Msg_Parse ("'postponed' not allowed for " &
> "an instantiation statement");
> Postponed := False;
> end if;
>
> You might note I wrote the preceding paragraph prior to looking in
> parse.adb. where we see you treat postponed as as prefix attribute
> (and it can be treated that way).
>
> An instantiation statement (as well as a generate statement) can not
> be decorated with postponed).
>
> > That's being said, feel free to open a ticket so that this issue
> > kept recorded.
>
> I don't particularly care if the error message is corrected. I put
> this out for the entertainment value. And if anyone ever asks
> someone could take out this diatribe and tell the story of why the
> error message says what it does.
>
> VHDL is supposed to be parsed as if it were a Context Free
> left-recursive grammar.
No, I don't agree with that. Nothing in the LRM tells how files
should be parsed. The LRM just says that the grammar is
context free.
> ghdl isn't the first VHDL tool to do this
> as I've said. The only error here is having an error message that
> demonstrates it was syntactically analyzed (the last
> concurrent_statement choice) as if it were not context free.
> Otherwise you couldn't tell, certainly not without looking at
> source code.
>
> And the correct way to maintain the fiction that syntactical analysis
> was context free is to have error messages for non-terminals
> (concurrent_statement in this case). Something only generally
> available to parser generators recently (explaining why it's common
> to deal with the last choice as if by dependency grammar, examining
> input (units?) as if you know there is no alternative production
> (choice).
>
> ghdl's implementation of it's parsing concurrent statement points to
> a historic shortcoming in parser generators (the entertainment part)
> while not visible being so limited. The only possible implication I
> can think of for that would be that ghdl was implemented in Ada
> traversing a bnf intended as input to a parser generator.
>
> There's a few other places in the parser that support that, for
> instance ghdl's implementation of use_clause, identical to one
> implemented with YACC. And it's also common to do dependency
> grammars for use_clause, it's a matter of conservation of effort
> otherwise requiring identifiers be handled twice.
>
> Should 1076-20XX include the proposed Hierarchical Libraries
> (http://www.eda.org/twiki/bin/view.cgi/P1076/HierarchicalNamespaces)
>
> the BNF description for use_clause would become both more elaborate
> and easier to implement, depending on predicate tests like
> library__name (excuse the lack of italics, I chose not to convert
> the format).
>
> And I did warn you the subject was akin to arguing the relative
> merits of staples and paperclips.
Yes.
> Essentially the error message output cannot be reached (inferred)
> without treating the syntax for generate as a dependency grammar.
I think this is really far fetch. The LRM says nothing about error
messages, and a tool that simply crash on invalid source file would
be conformant (albeit not very helpful).
Tristan.
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
