Tristan,
> > 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.
Jim is proposing this as a new FT29 proposal. We can pick up the discussion
again in that context.
> ...
> 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.
That's true, but I think it's a difficulty that already exists in other
parts of the grammar.
> ... Some that come to mind are:
> >
> > procedure .....;
> > procedure ..... is ...
> >
> > function .....;
> > function ..... is ...
> Not quiet the same, as 'procedure ...' is always a specification.
Good point.
> > attribute a : T;
> > attribute a of ... is ...;
> I think there is a pending discussion on simplifying
> attribute specifications.
Yes, but that doesn't mean removing the existing syntax. The suggestion is
to provide syntactic sugar for simple cases. Hence, the problem of
distinguishing between an attribute declaration and an attribute
specification still exists.
> > group g is ...;
> > group x : g (...);
> Let's deprecate group template declaration and group declaration.
That will take two revisions to achieve (assuming everyone agrees).
Meanwhile, the problem of distinguishing between them still exists.
> > 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.
Sorry, I didn't mean introducing futher new reserved words. I meant having
more than just the reserved word "context" at the start of a context
reference.
> ...
> 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 ?
I think that, in common usage, people write use clauses for packages that
they refrence, so that dependency is made explicit. Implicit dependencies
mainly arise from instantiated design entities, either through direct
instantiation, or through default binding to instances of components.
In the case of direct instantiation of entities, if you required something
like a with clause, users would push back. Their argument would be that
they've never had to state which entities they're using before, so why force
them to in context declarations? I would expect their reaction to be to
avoid context declarations and to stay with the old approach.
In the case of default binding to instantiated components, which is the 99%
case for synthesizable models, the binding isn't done until elaboration. So
there isn't an analysis-time dependency between the design units anyway.
The dependency would have to be handled outside the language, eg, through
make files.
Cheers,
PA
-- Dr. Peter J. Ashenden peter@ashenden.com.au Ashenden Designs Pty. Ltd. www.ashenden.com.au PO Box 640 Ph: +61 8 8339 7532 Stirling, SA 5152 Fax: +61 8 8339 2616 Australia Mobile: +61 414 70 9106Received on Thu Dec 2 16:52:41 2004
This archive was generated by hypermail 2.1.8 : Thu Dec 02 2004 - 16:52:43 PST