Selon Peter Ashenden <peter@ashenden.com.au>:
> Tristan,
>
> > 1) Note that to use IEEE_STD_CONTEXT, you have to write:
> > library IEEE; context IEEE.IEEE_STD_CONTEXT; Maybe we should
> > go further with only: context IEEE.IEEE_STD_CONTEXT;
>
> The problem is that you need to have a denotation for the name IEEE. The
> library clause introduces such a denotation. I guess you could have a
> special rule for context references that assumes the prefix of a selected
> name denotes a library, but I'd be very reluctant to do that.
Either I would. This is not in the selected_name spirit, but I think this
may be disputed.
I just wanted to emphasis the need of the library clause.
> Perhaps a simpler solution that would work in 99% of cases would be to add
> IEEE to the impicit library clause. That is, each design unit would
> implicitly have
>
> library STD, IEEE, WORK; use STD.STANDARD.all;
>
> in their context clause. What do you think?
I am *very* reluctant to make IEEE special.
> > 2) The 'context' reserved word can either start a
> > context_declaration or a context_reference. This is not very good.
> > Suggestion:
> > use context xxx;
> > or
> > with context xxx;
>
> What is your concern? Is it the need for look-ahead in parsing a design
> unit to see if you have a context reference or a context declaration? Or is
> it a human factors concern?
Sure this is manageable.
But all the examples are declarations/specifications. With context, you
have two differents level, so look-ahead is a little bit more difficult.
While you are parsing context clause and you find 'context xxx is', you should
back-track farther: end of context clauses, start of a library unit.
This can also make the life of syntax color highlighting editor.
> We already have other cases of a reserved word staring two different (though
> related) constructs. Some that come to mind are:
>
> procedure .....;
> procedure ..... is ...
>
> function .....;
> function ..... is ...
Not quiet the same, as 'procedure ...' is always a specification.
> attribute a : T;
> attribute a of ... is ...;
I think there is a pending discussion on simplifying attribute specifications.
> group g is ...;
> group x : g (...);
Let's deprecate group template declaration and group declaration.
> I think the proposed syntaxes for context declarations and context
> references are sufficiently distinct, both for a parser and for a human
> reader, not to need extra keywords.
Well, this is not a new reserved word.
[...]
> > 5) A major (?) problem with the context clauses, as they are
> > written in VHDL LRM is that you don't easily know which
> > design units you are using. Ie, if your methodology is not to
> > use 'ieee.std_logic_arith' (for example), then it is
> > difficult to check your designs do not use it. Ada has 'with
> > clauses'. In C, if you want to use feature of stdio, you
> > have to include it. VHDL is really more permissive. It is a
> > problem for VHDL users ?
> > Suggestion: add a 'with clause'.
>
> You are right that dependencies between units are implicit. Clause 11.4 of
> the LRM describes this in terms of references from one unit to another
> introducing a dependency. Ada makes the dependencies explicit through its
> "with" clauses.
>
> I would suggest that this is an orthogonal issue to that of context
> declarations (the topic of FT18). Hence, it should properly be addressed as
> a separate proposal. However, I don't see much hope for introducing such a
> feature. The stable door was open in 1987 and the horse bolted long ago!
> All legacy models rely on the dependency semantics as they currently stand.
> Perhaps someone who was involved in the original language design might be
> able to recall the rationale?
Why not make dependencies explicit in context declarations ? And in units using
context declarations ? (then the issue is less orthogonal).
What's your / others opinion ?
Tristan.
Received on Thu Dec 2 00:31:16 2004
This archive was generated by hypermail 2.1.8 : Thu Dec 02 2004 - 00:31:29 PST