RE: [sv-ec] Scope resolution operator (::) to access class parameter assignments

The #() fix was added as part of

    http://www.eda-stds.org/svdb/bug_view_page.php?bug_id=725

Here is an excerpt from my text description --

"And it should be emphasized that an unspecialized
parameterized class is not itself really a type. This
can be confusing because of the default values that are
required for parameters. I would recommend adding and
requiring a #() syntax for the specialization of
parameterized types that pick up all the default values.

"The effected nonterminal is parameter_value_assignment
in A.4.1.1, which should be

  # ( [ list_of_parameter_assignments ] )

"This change would be generally useful anyway. It's
weird for #() to be legal in a declaration, but not
in an instantiation. Personally, I consider it a bug
in the BNF."

-- Brad

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: Thursday, June 22, 2006 7:31 AM
To: Gordon Vreugdenhil
Cc: Brad Pierce; sv-ec@eda-stds.org
Subject: Re: [sv-ec] Scope resolution operator (::) to access class
parameter assignments



Gordon Vreugdenhil wrote:
[...]
> If it weren't for the special magic default type for mailbox,
> I'd seriously suggest eliminating such implicit specializations
> and always requiring at least "stack #()" so that users know
> that a specialization is there.

It was just brought to my attention (Thanks Shalom!) that in 1364-2005
we have:

   parameter_value_assignment ::= # ( list_of_parameter_assignments )

But in 1800-2005 we have:

   parameter_value_assignment ::= # ( [ list_of_parameter_assignments ]
)

So "stack #()" is at least already legal.  But this change also
makes #() legal in all contexts.  I don't object but was wondering
if that was an intentional change in its scope.

Gord.
-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com