Re: [sv-ec] Err-5


Subject: Re: [sv-ec] Err-5
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Tue Nov 18 2003 - 18:12:13 PST


Ray,

My comments below in blue.

    Arturo

----- Original Message -----
From: "Ryan, Ray" <Ray_Ryan@mentorg.com>
To: "'sv-ec@server.eda.org'" <sv-ec@eda.org>
Sent: Tuesday, November 18, 2003 4:21 PM
Subject: [sv-ec] Err-5

The first paragraph of revised Err-5 contains:

"... The built-in package is implicitly wildcard imported into every
compilation unit (see Section 18.2). Thus, declarations in the built-in
package are directly available in any scope (like system tasks and
functions) unless they are redefined by user code."

A couple issues:
- The section reference for wildcard import should be to 18.4

    0K. I'll change that

- As I understand it(?). A package import is a data_declaration and so should be
  imported into some 'scope'. Unless we define an additional (outer level) scope
  at the compilation unit level, we will need to use the 'local_root' (IE an import
  cannot exist outside of a module, class, package ...).
  So the statement above should be:

  ... The built-in package is implicitly wildcard imported into the local_root of
      every compilation unit. ...

    The name local_root does not exist. Instead, I propose:

    "... The built-in package is implicitly wildcard imported into the outermost
     scope of every compilation unit (see Section 18.4). ..."

- The statement about the declarations in the built-in package being "directly
  available in any scope" could be misleading. What comes to mind is the
  following:
    a) 'foo' is declared in the built-in package.
    b) 'foo' is also declared in class 'bar'.
    c) 'bar' contains the declaration of function 'myfunc'.
    d) class 'foo_ton' extends class 'foo'.

  In the scope of the function 'myfunc', 'foo' should refer to the 'foo' in
  the class 'bar' (even though the built-in foo is "directly available" and there
  is no local declaration of 'foo'). The same applies to the scope of 'foo-ton'.

  Here I'd suggest removing the word 'directly'.

    But that wouldn't be true. Because the built-in pacakge is wildcard imported,
    the built-in identifiers are available without any further qualification. There is
    no need to use :: (although it is available). The scenario you present is a
    straightforward scope resolution issue, no special rules apply.

- I'd prefer the built-in package to have a name (rather than 'he who shall not
  be named'). This is just a preference - there is nothing technically wrong
  with the null name.

    That is a plausible way to define it. However, that would be incompatible with
    other mainstream languages such as C++ and Java. Plus, the committee did
    approve this form.

- Ray



This archive was generated by hypermail 2b28 : Tue Nov 18 2003 - 18:13:21 PST