Re: [sv-bc] Is an unnamed block with declarations a scope?

Steven,

    I agree with you that (3) is "unorthodox", and that such a
feature has probably never been delivered as user-level language
semantics.  But the semantics are not only precedented;
they are prior art in optimizing compilers.  I suspect we all
have something like this implemented internally already.

    In place of "inconsequential local variable" in our
discussions, please substitute "compiler temporary variable".
Compilers that rewrite SV RTL, must sometimes introduce intermediate
scopes while still preserving the user's scope hierarchy.

    So these constructs /do exist/.  I am just trying to
unify compiler temp blocks with users' unnamed blocks and thereby
avoid having a third sort of scope.  The "named block hierarchy"
is just a layer of shortcuts through the actual hierarchy.

    In practice, I think this is a good way to avoid exposing
users to vendor-specific compiler-generated block names.

> The obvious problem with this is that you now have a name that appears
> in one scope, but pollutes the name space of other scopes where it does
> not actually appear.  This has no precedent in Verilog, or any other
> language I am familiar with.  Therefore it is confusing.

The named block would be accessible (by its non-hierarchical name)
everywhere inside the nearest enclosing named parent block.

That scope cannot redeclare the name, but any nested scope (except
those down the path from named parent to named child) can redeclare
its identifier.  I don't know if this is "pollution" - it's just
the minimal requirement for keeping this proposal sane.

Named blocks are already funny and confusing.  They declare a name,
but don't cause their enclosing block to become a scope.  Under (2),
they can go from being accessible to inaccessible when you drop in
an "int i;" declaration somewhere above them.  Complex rules are
bad, in general.  But if you've got to have them, might as well
make them serve some good purpose.

`define is also confusing, polluting, etc. etc.

> Also, since this situation is unprecedented, the terminology needed to
> describe it probably won't fit into the existing specification of name
> spaces, requiring it to be completely rewritten.  This may introduce
> new errors in the specification.

The unifying feature is still just a single scoping hierarchy.
The adjectives "named" and "unnamed" naturally distinguish two kinds
of scopes in that hierarchy.  An accessible hierarchical name
is one whose prefix is a dotted sequence of all the (nested) named
blocks ending with the one which declares the accessible object.

LRM terminology is a little like reading tea leaves anyway, I
think we can say this clearly enough.

Greg Jaxon