RE: [vhdl-200x-dta] Review of: [vhdl-200x] Revised white paper on type genericity

Jim,

Regarding the distinction between parameters and ports: I think the
distinction is useful for the user. They are semantically different
objects, so it's useful for the user to have different terms for them to
help keep the distinction clear. Yes, they both deal with interchange of
information between a provider and a client, but the semantic differences
from both the provider's perspective and the client's perspectives are
significant.

Regarding syntax: I'm not strongly wedded to specific syntax, so long as the
result "reads well." We already have inconsistency between subprogram and
other items with interface lists. In subprograms, the order of syntactic
elements is "procedure/function", name, interface list, "is". For
components and entities, the order is "component/entity", name, "is",
interface lists. For blocks, the order is different again, but I'll
discount them for this argument, since block interface lists are really a
definitional artifact and not used by designers.

In the case of components and entities, there's just one aspect to
elaboration. When you instantiate them, you provide both the generic and
port maps. So it makes a kind of sense for the generic and port list to be
syntactically close, and for the generic and port map to be syntactically
close. Compare this with generic subprograms, on the other hand, that have
a two-stage elaboration. First you elaborate the generic subprogram,
supplying a generic map, to get a allable procedure. Then you dynamically
elaborate the subprogram at one or more call sites, supplying a parameter
association list for each. So there's a kind of sense in syntactically
separating the generic list from the parameter list.

So while it may appear desirable to make the syntax of generic subprograms
as consistent as possible with other declarations, I'm not convinced that
it's imperative to do so. Recall what they say about "foolish consistency!"

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 9106
> -----Original Message-----
> From: owner-vhdl-200x-dta@eda.org 
> [mailto:owner-vhdl-200x-dta@eda.org] On Behalf Of Jim Lewis
> Sent: Friday, 23 April 2004 15:55
> To: 'vhdl-200x-dta@eda.org'
> Subject: Re: [vhdl-200x-dta] Review of: [vhdl-200x] Revised 
> white paper on type genericity
> 
> 
> Peter,
> With respect to the syntax for subprogram generics,
> I am concerned that V2 syntax is going in the wrong
> direction.  While I like consistency with ADA,
> I think we have a bigger requirement for consistency
> with VHDL.
> 
> One of the objectives of VHDL-200X-MP is
> to improve the consistency of VHDL syntax.  If you
> introduce this inconsistency in subprogram generics,
> I would need to propose optional syntax for entities
> and blocks that makes a flavor that is consistent
> with the new subprogram generics.  I really don't
> want to have to do this.
> 
> 
> Port vs. Parameter:
>  From a language developer's perspective using parameter
> makes sense.  From a user's perpsective, we are passing IO to 
> an object, so using a different keyword is inconsistent. Does 
> naming parameters and ports differently for the 
> compiler's/language developer's benefit buy us anything?
> 
> If really need to have a different keyword, perhaps in
> MP I can make the port and port map keywords optional
> for entities?
> 
> 
> Cheers,
> Jim
> 
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Jim Lewis
> Director of Training             mailto:Jim@SynthWorks.com
> SynthWorks Design Inc.           http://www.SynthWorks.com
> 1-503-590-4787
> 
> Expert VHDL Training for Hardware Design and Verification 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>