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

FWIW, and FBOW (for better or worse),

Superlog was created before and independently of the 1364-2001 standard.
One of the goals of Superlog was to import and be as compatible with as
much as C as possible. C lets you declare variables in scopes without
having to name them, so why can't we do the same thing here. 

Also remember that a variable declaration in a 'for' loop iterator is an
unnamed block. I don't think would be a good idea to make the looping
statement a hidden block just because someone declared an iterator
variable.

Nesting modules came out of a recursive definition that $root was
essentially a top level module, and any module definition was itself a
nested module definition. It probably no different then class
containment when classes are declared inside other classes.

Dave




> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Cliff
> Cummings
> Sent: Thursday, August 11, 2005 8:34 PM
> To: sv-bc@eda.org
> Subject: Re: [sv-bc] Is an unnamed block with declarations a scope?
> 
> Hi, All -
> 
> No need to reply to my email address. I will continue to read the
thread
> on sv-bc@eda.org (one copy in my email inbox is enough).
> 
> I have no great attachment to declarations in unnamed blocks. I
thought
> they were there for those who did not want to name everything and who
did
> not expect to have hierarchical reference to the local variables.
> 
> If we decide to get rid of them, we should do so soon and get Stu and
I to
> quick-email our SV students to notify them of the pending change (I
have
> been showing the construct, noting the capability, but only on one
slide
> and with no great emphasis that anyone should do this).
> 
> As far as variable protection goes, could this be easily addressed by
> using the same "local" and "protected" keywords that are used in class
> data declarations for the same purpose?
> 
> Isn't module nesting also used to eliminate a hierarchical path to
local
> variables? (I'm not crazy about module nesting either). Seems like the
> only good reason for module nesting is to put a visible wrapper around
a
> module that one intends to encrpyt. Any other good uses for nested
> modules?
> 
> Regards - Cliff