RE: [sv-ac] 1678 name resolution and the rewriting algorithm of 1549

Hi John,

Yes you are right about the examples. I don't think that they may result
in an illegal code, but in a code that probably was not intended. 

However, I don't think that it is possible to have such conflicts
without local variables (not necessarily as arguments.) The conflicts
described in 1678 are between signals defined in an internal sequence
and signals that are defined in the environment that instantiates it.
The only variables that are declared inside a sequence/property are
local variables all other are declared outside. So I cannot see
conflicts in instances that do not use local variables.

Am I missing something?

Doron

-----Original Message-----
From: John Havlicek [mailto:john.havlicek@freescale.com] 
Sent: Sunday, November 04, 2007 7:01 PM
To: Bustan, Doron
Cc: john.havlicek@freescale.com; sv-ac@eda.org
Subject: Re: [sv-ac] 1678 name resolution and the rewriting algorithm of
1549

Hi Doron:

I think that if you take the old example from 1678
and apply the rewriting algorithm as it is now and 
treat the names naively just as the identifiers that
appear in the source, then you will still get the 
unintended conflicts or aliasing.

Try it and let me know of you agree.  This is what
I wrote up in the example more carefully, so if 
you just delete the differentiating information from
the names in the example, you should see the same 
conflict.

My point is that this is the kind of name resolution
that is handled routinely in elaboration.  It is not
particular to local variables.

J.H.

> X-ExtLoop1: 1
> X-IronPort-AV: E=Sophos;i="4.21,368,1188802800"; 
>    d="scan'208";a="311428686"
> X-MimeOLE: Produced By Microsoft Exchange V6.5
> Content-class: urn:content-classes:message
> Date: Sun, 4 Nov 2007 15:48:12 +0200
> X-MS-Has-Attach: 
> X-MS-TNEF-Correlator: 
> Thread-Topic: [sv-ac] 1678 name resolution and the rewriting algorithm
of 1549
> Thread-Index: AcgdXOsOLiYXJKC2RFifPUCfDmHMZQBjEaBg
> From: "Bustan, Doron" <doron.bustan@intel.com>
> X-OriginalArrivalTime: 04 Nov 2007 13:48:13.0407 (UTC)
FILETIME=[581566F0:01C81EE9]
> 
> John,
> 
> Can you give an example of name conflict with the up to date 1549?
> 
> I don't see it.
> 
> Doron
> 
> -----Original Message-----
> From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org]
On
> Behalf Of John Havlicek
> Sent: Friday, November 02, 2007 4:26 PM
> To: sv-ac@server.eda.org
> Subject: [sv-ac] 1678 name resolution and the rewriting algorithm of
> 1549
> 
> Hi Folks:
> 
> In 1549, we introduced a local variable declaration notation=20
> in the abstract syntax.
> 
> In revising the rewriting algorithm, I deleted the parts about
> making local variable names unique.  The rules for overshadowing
> in 1549 make this unnecessary in some cases.  Doron asked about
> this, but I seemed to convince him that the overshadowing took=20
> care of the problems.
> 
> However, 1678 points out that a naive treatment of local variable
> identifiers results in name resolution issues when local variables are
> passed as actual arguments to other instances.  The overshadowing
> mechanism of 1549 does not take care of this problem.
> 
> I do not think that this problem is specific to local variables.  When
> rewriting and substituting actual arguments, we must respect name
> resolution.  Simply looking at the identifiers, references,
> etc. written in the source code is not good enough.  There can be
> incorrect aliasing for all sorts of things other than local variables.
> 
> In order to resolve 1678, I think we need to add some language
> (hopefully a small amount) to say that name resolution still needs to
> be taken care of properly when following the rewriting algorithm.
> 
> Name resolution is not something that we should be trying to capture
> in Annex F, so I don't think we should make a special point about
> making local variable identifiers unique.  That would give the wrong
> impression that other references do not also need to be accounted for
> with care.
> 
> I have uploaded to Mantis 1678 and attached below an example of
> carrying out the rewriting algorithm while paying attention to name
> resolution.  I don't envision it being added to the LRM.
> 
> J=2EH.
> 
> 
> --=20
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.