RE: [sv-ec] rules for overriding virtual method

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Fri Jul 11 2008 - 00:48:49 PDT
Even at the Big 3, there are a large number of engineers of Asian
origin, for example (or Israeli, for that matter). That includes those
working in the USA and the UK.

> Furthermore, English is the second language of almost all the 
> implementors at that vendor.  We have a collective 
> responsibility to ensure that the LRM is sufficiently precise 
> and comprehensible to facilitate their understanding.

I have repeatedly said that the LRM is not only for implementors. It is
also for users that have to understand how to use the damn thing. Most
of them certainly don't have representatives on the WG.

And even for native English speakers like myself, ambiguities cause no
end of problems. Consider how many times we have disagreed among
ourselves how a certain LRM paragraph is to be interpreted.

But I don't think anyone was actually intending to say that clarifying
ambiguities is not important.

As for the matter at hand, Mantis 2385 mentions some other ambiguities
in the same paragraph. I'll add the comments from this discussion to
there.

Mantis 2392 discusses ambiguities in extern module declarations, which
are similar, but there the ambiguities seem more "advanced". The current
text there says, "An extern module declaration shall match the actual
module declaration's port and parameter lists in correspondence of
names, positions, and their equivalent types." That seems clearer than
the text in 8.19.

Regards,
Shalom
---------------------------------------------------------------------
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.
Received on Fri Jul 11 00:49:41 2008

This archive was generated by hypermail 2.1.8 : Fri Jul 11 2008 - 00:50:22 PDT