Re: [sv-bc] Query related with the visibility of enum member.

> I regard anonymous notations as a huge advantage.

Only if one stays within that notation. But we don't have that luxury,
because netlists and debuggers and scripts use names. Where there is
no name in the RTL, we are forced to invent one in a way that's
consistent across tools.

-- Brad

On Fri, May 14, 2010 at 12:43 PM, Greg Jaxon <Greg.Jaxon@synopsys.com> wrote:
> Brad Pierce wrote:
>
> Greg,
>
>
>
> I don’t see the need for anonymous types in SV. Is there one?
>
> It's all in which way you want to cut with Occam's razor:  Simplifying the
> language complicates its usage.
> Why should code authors have to invent names for things to which they will
> never explicitly refer?
> The more names, the more name collisions and the more uncatchable typos.
>
> More generally, we seem to spend an inordinate amount of time on anonymous
> generate blocks, anonymous sequential blocks containing declarations,
> anonymous types. Is there any advantage to these besides not needing to
> invent a name?
>
> I regard anonymous notations as a huge advantage.
> It's the root of all grammatical language structures, e.g. all algebras.
> What if you needed a temp var name for each intermediate result in an
> algebraic expression?
> You'd never be able to recite the formulae for quadratic roots from memory.
>
> The time spent on this now is just paying our debt plus interest for not
> spending the time to do it right in the first place.
>
> Under the assumption that, because of “legacy”, we couldn’t simply forbid
> anonymous types, even if they were worthless, I’m with you until the
> concluding paragraph
>
>
>
>>I think saying  int a = mystruct :: NO;  would be the right way to access
>> this label.
>>I also think an enum type name should function as a scope for accessing its
>> labels.
>
>
>
> Other than convenience, why wouldn’t it be one or the other of these, not
> both?
>
> Iin DhiRAj's testcase, the enum type is anonymous, which excludes the second
> possibility.
>
> We do have a clumsy legacy - dating back to C for how enum values must
> behave.
> It isn't pretty, but here is my best story for how this ought to work:
> An enum type declaration introduces a new scope within which the tags must
> be unique.
> At the close of the declaration, this scope is implicitly imported into the
> nearest parent scope - wildcard-like ( enum_t::* )  - and re-exported.
> [Note that this allows several enum types to have the same tag, but
> precludes uses which would be ambiguous.]
> [This is an imperfect analogy in a few respects.  I would not insist that
> the parent scope
>  must explicitly refer to the enum value to complete its wildcard import.
>  Instead, I'd say that (especially for anonymous enum types), legacy
> requires the import
>  to be forcibly completed.  Once again this challenges us to define
> precisely how
>  to resolve collisions and name shadowing.  There are nuances worth debating
> here - but
>  I feel the analogy to scope-importation is a powerful model which would
> save the committee
>  a lot of time in writing these rules.]
>
> I don't see any reason or precedent to disallow several access methods to
> get to these names.
> Currently you can use either p1::val or p2::val to get to val
> if package p1 imported it from package p2 and re-exports it.
>
> Having these scopes available and addressable via :: means you can always
> get to the enum value you need.
> When you import pkg::enum_t, you won't get its labels,
> but you'll be able to address enum_t::red and enum_t::blue, ...
> Potentially you could also define :: for type-valued expressions such as
> $type( mystruct.boolean )::NO
> But in DiRAj's testcase, mystruct::NO seemed like the obvious route to go.
>
> Greg Jaxon
> Disclaimer:  These are just my humble language design ideas, not my
> employer's voting position or product-delivery commitment.
>
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Greg
> Jaxon
> Sent: Friday, May 14, 2010 10:11 AM
> To: Rich, Dave
> Cc: Dhiraj Kumar Prasad; sv-bc@server.eda.org; Surya Pratik Saha
> Subject: Re: [sv-bc] Query related with the visibility of enum member.
>
>
>
> What Dave says is true, but it does not address why systems have diverged.
> This enum type in your example has no name - it is anonymous.
> The identifier boolean is the name of a field in mystruct.
>
> This brings us to the heart of the matter.  At the point where the enum type
> is created, we are no longer
> defining names in the global ($unit) scope - names are now being declared
> within the struct's scope.
> The BNF only imagines field names are being declared .  But of course any
> anonymous types that
> get declared are confined to this scope (won't be equivalent to similar
> types in other structs or in $unit).
> This view comes from the C++ world where structs and classes are close
> relatives.
> Were this an SV class declaration, you'd insist that the enum labels belong
> to the class scope.
>
> Similarly, if the enum is declared in some named block nested elsewhere,
> you'd want its labels confined
> to the nearest enclosing scope around the enum declaration.
>
> It happens that a struct scope is especially limiting - there is a
> temptation to make a special rule
> promoting these labels to some outer scope.  But I find no such rule
> exception in the LRM.
>  "NO" is not necessarily visible in mod1.
>
> You might say that structs aren't scopes.  But I can have two structs with
> the field name boolean
> and they don't get a name duplication error, I just can't have two fields
> called boolean in the same
> struct.  "Scope" is an accurate description of these semantics.  The
> question is whether and how
> to apply it to incidental name declarations like the enum labels.  The full
> answer impacts how these
> names get resolved in any default value assignment made to this or other
> fields of the struct and
> whether an enum value NO precludes having a field named NO, or if such a
> field name would eclipse
> the enum value.
>
> I think saying  int a = mystruct :: NO;  would be the right way to access
> this label.
> I also think an enum type name should function as a scope for accessing its
> labels.
>
> Greg Jaxon
> Disclaimer:  These are personal opinions, and do not reflect my employer's
> voting position or product commitments.
>
> Rich, Dave wrote:
>
> dhiRAj,
>
>
>
> A enumerated type declares set of integral named constant members in the
> same scope that the enumerated type name exists. That is why you are not
> allowed to repeat the names in more than one enumerated type in the same
> scope, or re-use the name for any other identifier in the same scope. The
> identifiers (names) of an enumerated type have the same visibility rules of
> any other identifier.
>
>
>
> Dave
>
>
>
>
>
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Dhiraj
> Kumar Prasad
> Sent: Friday, May 14, 2010 12:44 AM
> To: sv-bc@server.eda.org
> Cc: Surya Pratik Saha; Dhiraj Kumar Prasad
> Subject: [sv-bc] Query related with the visibility of enum member.
>
>
>
> Hello,
>
> I have a query related with visibility of enum member.
>
> For the following testcase
>
> typedef struct {
>             enum {NO,YES} boolean;
>             }mystruct;
>
> module mod1();
>
> int a = NO;
> endmodule
>
> "NO" will be visible inside module ?? As some of the standard tools are
> passing  while others
> are showing error.
>
> Regards,
> dhiRAj
>
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.