Surya Pratik Saha wrote:
Hi,
In SV 2009 draft 7a LRM, section 6.22.2 Equivalent types, there is a
big example explaining type compatibility rules in SV. It mentions some
rule numbers also, but it is not clear which rule it tries to point
out. Also the last assignment as given below marked as illegal, but it
is not clear why.
s1.v5 = s2.v5; // illegal - types from s1 and s2
(rule 4)
BTW, none of the standard simulators or synthesis tool fail for the
case. I think LRM should correct it.
Which synthesis tool accepted the hierarchical reference, or the
initial block?
The divergence of implementations here is understandable due to the
vague notion of "scope" being applied in rule 4.
There are two sound theories on this subject:
Instance-specific: (i.e. this case is illegal) which is
required for class types, and arguably should also apply to purely
structural types.
Specialization-specific: (i.e. legal in this case, but illegal
given different parameterizations of sub for s1
and s2) which is all that is required to assure identical
storage layout for types whose meaning is otherwise independent of
stored data values.
Each idea has its place, and I'd be the last one to suggest that one
size must fit all.
The LRM is likely to have severe trouble getting all implementers to
produce just one unique "scope identity" given the three obvious choices
- parse-time static (sub)
- elaboration-time dynamic (sub#(...))
- linkage-time dynamic (sub#(...) sN)
I consider option 1 to be unsound and incorrect for any strongly-typed
language with SV's other features.
Name matching, even with a matching provenance, is not enough once
types can be parameterized.
There are significant advantages to recognizing and exploiting
structural similarities (type 2), especially for synthesis.
In fact, separately-linking language implementations have no means
whatsoever to enforce instance-specific typing (3).
So I too encourage P-1800 to revisit this topic in future editions of
the standard.
Greg Jaxon
--
Regards
Surya
--
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.
Received on Thu Aug 6 13:17:18 2009