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.
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
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.
Received on Fri May 14 12:44:05 2010