Re: [sv-bc] Naming of unnamed sequential blocks

Dave found a curious "loophole" though (excuse the pun).
An unnamed scope breaks the access path (by fully qualified names) to
all entities nested in it at any depth.  This would include paths to
explicitly named blocks.  The scope introduced by a local "for" index
apparently cannot be named, so acknowledging it means losing a
standard name for the entities it contains.  If the loop scope and
the loop body scope were the SAME scope (just with a speical rule
for initializing the loop index on each entry to the body), then a
coding style which always names the body block would bring the
things it contains back into the realm of well-named entities.

Steven Sharp wrote:
> Dave Rich wrote:
> 
>>But I disagree with the notion that the occurrence of declaring a
>>variable in an unnamed block creates a scope. Consider a 'for' loop with
>>a local declaration. I don't think users expect that to hide the nested
>>named blocks in the 'for' loop.
> 
> 
> I don't think anyone will agree with you on this.  Consider the
> following code:
> 
>   begin: foo
>     for (int i = 0; i < 10; i++)
>       a[i] = 0;
>     for (integer i = 0; i < 10; i++)
>       b[i] = 0;
>   end
>   
> If the implicit unnamed block for the for-loop is not a scope, then
> what scopes are the two variables named i in?  They clearly are not in
> scope foo, since there would then be two different variables named i in
> scope foo.  They are clearly in two separate scopes nested inside the
> scope foo.
> 
> Section 6.6 (draft 4) says:
> "Note that in SystemVerilog, data can be declared in unnamed blocks as
> well as in named blocks. This data is visible to the unnamed block and
> any nested blocks below it."
> 
> That matches the usual definition of a scope.
> 
> Section 19.13 (draft 4) describes "name spaces", a sloppy term in the
> LRM which mostly refers to something like a scope.  The 6th bullet says:
> "The block name space is introduced by named or unnamed blocks, the specify, 
> function, and task constructs. It unifies the definitions of the named blocks, 
> functions, tasks, parameters, named events, variable type of declaration and 
> user-defined types within the enclosing construct."
> 
> Note the mention of unnamed blocks here.
> 
> I don't think that you are really trying to say that these unnamed blocks
> aren't scopes, in the accepted meaning of the term.  You are trying to
> argue that these scopes affect hierarchical naming differently from other
> scopes.  Unfortunately, there is nothing in the standard to describe such
> rules, so the normal rules would apply.  Rules to get the kind of naming
> that you want would be more complex and inconsistent with the existing
> rules.  Such rules would potentially create other problems.
> 
> 
>>It's too late to debate whether it was a good idea to allow variables to
>>be declared in unnamed blocks. It will be in the IEEE-1800 standard. 
> 
> 
> I have to agree with you on this part.  It was already debated a long
> time ago, and the debate was settled on the basis that these unnamed
> blocks would act like scopes with tool-generated names.  Changing that
> behavior now would be a change to the standard, which could be brought
> up in a ballot comment, which would open it up to debate again.
> 
> Steven Sharp
> sharp@cadence.com
> 
> 
>