wait statements in functions
don't you think the syntax should exclude those possibilities? of course
the LRM says a lot more than the syntax diagrams, but it is awkward to
work with a set of syntax with so many precedences. the syntax i am
working with has "subprogram_sequential_statement" which has no "wait" in
it. period.
You mean you don't allow a wait statement in a procedure body? Then your
syntax is *wrong*.
A lot of people read the BNF and are then confused when the LRM text makes
illegal certain constructs which the BNF allows. Consider this example:
constant_declaration ::=
CONSTANT identifier_list : subtype_indication [ := expression ] ;
A naive user might think that
constant c : bit_vector := 3;
is legal, since the BNF does not specifically disallow it. The BNF says
nothing about matching types. (In fact, VHDL could be extended to allow the
above statement, by providing an implicit type conversion from an integer
type to type BIT_VECTOR. Such an extension would not require a change to
the BNF. This might not be a bad idea for a hardware description language.)
Here's another example:
aggregate ::=
( element_association { , element_association } )
element_association ::=
[ choices => ] expression
This would seem to allow such "aggregates" as
(1)
-- illegal: a one-element aggregate requires named association
('0', 3 => '1')
-- illegal: cannot mix named and positional association
(OTHERS => '1', 3 => '1')
-- illegal: OTHERS must be the last choice
If you really want the BNF to specify these syntactic rules, you must be
willing to live with a much more complex BNF. For instance:
aggregate ::=
( positional_association, positional_association { , positional_association } [ , others_association ] )
| ( positional_association, others_association )
| ( others_association )
| ( named_association { , named_association } [ , others_association ] )
positional_association ::=
expression
named_association ::=
named_association_choices => expression
named_association_choices ::=
named_association_choice { | named_association_choice }
named_association_choice ::=
simple_expression
| discrete_range
| element_simple_name
others_association ::=
OTHERS => expression
And of course, even this syntax doesn't say that the type of an aggregate
must be determinable from its context, or that for an array aggregate an
OTHERS choice is only allowed if the aggregate appears in one of a set of
contexts, or that if a non-locally-static choice appears (in an array
aggregate, that is), it must be the only choice, or that the discrete_range
or simple_expression cases of a named_association_choice may not appear in a
record aggregate. (I leave it as an exercise to the reader to construct a
BNF which handles as many of these cases as possible.)
True, the BNF could be more specific in some cases, such as differentiating
between the kinds of statements that can appear immediately within a
function body from those that can appear immediately within a procedure
body. But the LRM writers had to choose between precision in the BNF, and
readability and conciseness.
--
(speaking only for myself) "Cekoslovakyalilastiramadiklarimizdanmissiniz."
