RE: A new issue with IR 2099

Chuck,

> This new proposal is consistent with the current idea that 
> potentially visible declarations loose to declared 
> declarations, even implicitly declared ones (think of 
> implicitly declared labels).

Isn't the intent of changes in VHDL-2007 that potentially visible explicit
declarations win over implicit declarations? In that case, in your example
with alias un_un, wouldn't it be more consistent for the potentially visible
explicit declaration of "=" from numeric_std to win over the implicit alias
of the predefined "="?

Regarding Example 5: Yes, the predefined "=" for std_logic would not be
visible. That would be a consequence of the preference for protentially
visible explicit declarations over implicit declarations. I think it is a
consistent conceptual model.

Regarding John's extension of the example: I think the "=" visible in the
declarative region under consideration should be the implicit alias declared
in p_test. It's only weird if you expect transitivity of use clauses, which
is not the case. Just because it's hidden in p_test doesn't mean it has to
remain hidden in a region that uses declarations from p_test.

End $0.02.

Cheers,

PA

--
Dr. Peter J. Ashenden         peter@ashenden.com.au
Ashenden Designs Pty. Ltd.    www.ashenden.com.au
PO Box 640                    VoIP: sip://0871270078@sip.internode.on.net
Stirling, SA 5152             Phone (mobile):  +61 414 70 9106
Australia


> -----Original Message-----
> From: owner-isac@server.eda.org 
> [mailto:owner-isac@server.eda.org] On Behalf Of Chuck Swart
> Sent: Thursday, 15 March 2007 10:54 AM
> To: isac@server.eda.org
> Cc: john ries
> Subject: A new issue with IR 2099
> 
> 
> EXAMPLE 5:
> 
>   package p1 is
>     function "=" (a,b: ieee.std_logic_1164.std_logic ) return boolean;
>     ...
>   end package p1;
> 
>   package p_test is
>     use work.p1.all;
>     ...
>     alias std_logic is ieee.std_logic_1164.std_logic;
>     -- implicit "="
>     -- alias "=" is ieee.stdlogic_1164."=" (a,b: std_logic) 
> return boolean;
>   end package p_test;
> 
> John Ries has raised an issue concerning this example.
> His  question is:
> 
> Suppose in a declarative region you
>     use p_test.all;
> 
> Which, if any, "=" operator for std_logic is visible?
> It can't be the overloaded "=" from p1, since visibility 
> isn't transitive through packages. Is it the predefined "=" 
> implicitly declared in package p_test. If so, this is pretty 
> weird, since the predefined "=" is not visible in package 
> p_test, by our proposal. If not, we need a rule to make it 
> not visible.
> 
> John has suggested the following modification to our proposed rules:
> 
> For aliases, the priorities are, in order:
> 
> 1) explicitly declared aliases
> 
> 2) implicitly declared aliases
> 
> 3) potentially visible aliases, via USE clauses, whether 
> explicit or implicit.
> 
> A quick check of the other examples produce no changes in net 
> results, except for  EXAMPLE 5.
> 
> For EXAMPLE 5 the implicitly declared "=" associated with the 
> alias would be visible in the package p_test. Also, to answer 
> John's question, if you USED p_test you would see the same 
> implicitly declared "=".
> 
> This new proposal is consistent with the current idea that 
> potentially visible declarations loose to declared 
> declarations, even implicitly declared ones (think of 
> implicitly declared labels).
> 
> Here is my only problem with this new proposal:
> 
> In package numeric_std we have:
> 
>   type UNRESOLVED_UNSIGNED is array (NATURAL range <>) of STD_ULOGIC;
>   function "=" (L, R: UNRESOLVED_UNSIGNED) return BOOLEAN;
> 
> Now suppose we write:
> 
> LIBRARY ieee;
> USE ieee.numeric_std.ALL;
> ENTITY e IS
> ...
> ALIAS un_un is unresolved_unsigned; -- I prefer short names
> ...
> 
> If you did this then you wouldn't see the overloaded "=" from 
> numeric_std, but instead would get the predefined "=" operation.
> 
> On the other hand, this is exactly what the current LRM 
> dictates, and I don't know of any problems reported in this area.
> 
> What do you folks think about this issue?
> 
> 
> 
> -- 
> 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.