[sv-ec] Manti 2701, 2514 - response to Tom Alsop's feedback

Tom, EC,

Apologies if I muddied the waters in these two proposals.
Well-meaning attempts to make a description precise often
backfire and make it incomprehensible :-)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #44, Mantis 2701 ~~~~~
> [Alsop, Thomas R] I have a lot of issues with the wording and 
> understanding on this proposal for the new sub-clause 7.11.5. 
> 1.       ?Tools? should be ?Implementation?. 

OK, I wasn't aware this was the correct form of words.
 
> 2.       The third sentence states that ?For any such violating 
> operation, a warning shall be issued?, but then the next sentence it 
states ?
> Tools should issue exactly one warning?.  In clause 1.5 the 
> conventions for ?shall?, ?should?, ?may?, and ?can? are clear.  I 
> just want to make sure we are being clear in this new sub-clause WRT
> to these conventions. Seems like the 4th sentence should read that 
> ?Implementations shall issue exactly one warning??

Given

  int Q2[$:1]; // only [0:1] is allowed
  Q2 = {0,1,2,3};

I don't want to see TWO warnings, for the failed
attempts to write Q2[2] and Q2[3].  Just one warning
each time the assignment is executed.  I used "should"
here as an opt-out in case this proves hard to implement 
in some situations; the previous sentence's "shall issue
a warning" obliges tools to produce at least one, but it's
highly preferable that there should be exactly one.  If all
the vendors are OK with it, I'd happily change "should" 
to "shall" here.

> 3.       This sentence really confused me ?If a violating operation 
> attempts to write more than one element of a bounded queue, any 
> element with index less than or equal to the bound shall be written 
> exactly as it would be if the queue were unbounded.? Perhaps an 
> example would help. 

I guess the "if more than one element" phrase is strictly redundant, 
but the rule is applicable only to operations that write 
more than one element.  In the same example as above, I want

  Q2 = {0,1,2,3};

to write elements as follows:

  Q2[0] = 0; Q2[1] = 1;

just as it would have done if Q2 were unbounded, even though
the operation AS A WHOLE violates the queue's bound.  Would you
be OK with addition of that example?

I'll prepare a modified proposal with these two changes
(Tools=>Implementations, added example) in the hope that
EC can treat it as a friendly amendment next week.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #182, Mantis 2514 ~~~~~
> [Alsop, Thomas R] I agree with the premise of the proposal, just not
> with some of the wording as it?s not consistent with the draft8 
> wording.  Specifically the references to ?concrete type? (Clause 8.
> 24, third paragraph on page 142). à ?A generic class is not a type; 
> only a concrete specialization represents a type. In the example 
> above, the class
> vector becomes a concrete type only when it has had parameters 
> applied to it, for example?  But this proposal states ?A pure 
> constraint represents an obligation on any concrete (non-virtual) 
> derived class?, defining a concrete class to a non-virtual class. 
> I?m just unclear about using the wording of ?concrete?.

Fair enough.  I've always thought of "concrete" as an antonym
of "abstract" that doesn't need any further glossing, but I take
your point.  Clause 8.20 consistently uses "non-abstract" to
describe a class that isn't a virtual==abstract class, and 
I probably should have used the same form in this proposal;
again I'll prepare a modified version in the hope that it 
could be treated as a friendly amendment.

In my defence (and with my tongue firmly in cheek) I should
point out that at least I took the trouble to *define* my use
of the word "concrete", which is more than the draft LRM 
bothers to do in clause 8.24 .......

Thanks for the detailed review.
-- 
Jonathan Bromley
Consultant

Doulos - Developing Design Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project 
Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, 
UK
Tel:  + 44 (0)1425 471223                       Email: 
jonathan.bromley@doulos.com 
Fax:  +44 (0)1425 471573                        http://www.doulos.com

--------------------------------------------------------------------------------
Doulos Ltd is registered in England and Wales with company no. 3723454
Its registered office is 4 Brackley Close, Bournemouth International 
Airport,
        Christchurch, BH23 6SE, UK. 

This message may contain personal views which are not the views of
Doulos, unless specifically stated.


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