Re: [sv-bc] Resolving name resolution

Mark,

I don't really want to get into an examples war at this point.
We've already done that.  I've posted my suggested rules and
you've posted yours.  I don't really want to rehash all of
the discussions.

One thing that I'll take issue about:

Mark Hartoog wrote:
[...]
> 
> The philosophical question that Gordon raises is a serious question. One
> can argue that we have gone overboard and made System Verilog too
> flexible and this will make it more difficult to use. My problem with
> this argument is that P1800 is already an approved standard. It seems to
> me the time to have had the discussion of this philosophical question
> was before we approved the P1800 standard. In order to seriously do much
> about this issue now, we have to start making backwards incompatible
> changes in the language. I think that would be a bad idea at this time.

You are at least implying, if not stating, that your interpretation
is "compliant" and mine is not.  That is, at very least, arguable.
Otherwise we wouldn't be trying to determine how to apply the
rules in the first place.

There is only one place where I want to change a clear rule --
resolution within inline constraints.  And even there I think we
can find some middle ground (I hope).

All of the other aspects revolve around relative weighting
and interpretations of various rules and precedent.  Claiming
that my interpretations are not compatible is based on
*your* interpretation.  I also have never claimed that my
initial suggested rules (from months ago) were final anymore
that you have about your rules.

Finally, SV 1800-2008 has already made interpretations, syntax
changes, etc. that are clearly incompatible with the 2005 spec
which itself has issues with perfect 1364 compatibility.  So I
don't think the "it's a spec we can't change it" argument is
terribly strong.  Even 1364-2005 made an incompatible change
versus 1364-2001 with respect to generates due to having
sufficient problems with the 2001 approved definitions.

I absolutely agree that changes in this area are serious and any
potential issues in anyone's suggestions need to be very carefully
evaluated.  I do not however concede that even a known compatibility
issue is necessarily "a bad thing".  If the long-term ramifications
for the language warrant it, we should do it.  That is the
discussion that needs to happen and one that I've been trying
to have for many months now.  Unfortunately no one has wanted
to engage until now and we are now very short for time.

SV, particularly in the more complex TB areas and interactions
was brought about via history that we both know.  There was
certainly very little time to fully recognize and address
complex issues and their ramifications.  SV is still a
relatively young spec -- changes and clarifications in
critical areas are better to do now rather than having
even deeper problems in the future.

Gord
-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


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