I'm not at all opposed to the intent of the proposal and I'll gladly change my vote to yes when my concerns are addressed. I believe that the way you have structured the sentences (used in equality and comparison) is less clear because it forces readers to read the second sentence to fully understand what the first sentence is really saying - some may even read it as a contradiction. I don't think your proposed change addresses this point - notice how I also suggested the work "only" in the second sentence but that does not resolve the apparent contradiction. That's why I tried to be up-front in the first sentence and proposed "One or both operands can be an expression of type string", which is perhaps not elegant, but clear. As for the section on concatenation, I acknowledge that the use of the term "like" can be corrected, but do believe the rest of the existing verbiage is clearer. The existing text "If at least one operand is of type string ..." is IMHO unambiguous and clear. When I read the proposal I was left with the impression that assigning a concatenation of all string literals to a string would perhaps not be evaluated as integral concatenation. The intent here is to retain backward compatibility and I believe that perhaps the best way to describe this is to say that concatenation is self-determined - hence unaffected by the left-hand-side context. Arturo -----Original Message----- From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of jonathan.bromley@doulos.com Sent: Friday, May 01, 2009 3:10 AM To: sv-ec@eda.org Subject: [sv-ec] Mantis 2700, ballot items #36-40: Arturo's and Stu's feedback Stu: > For the equality operator, the proposed new text states: > "If both operands are string literals, the operator is > the same equality operator as for integer types" > > Should "integer types" be "integral types"? > > The same question applies to the matching text for > the comparison operators. Yes, sorry, that was just a careless slip. I hope EC can agree that as a friendly amendment, as Stu suggests. Arturo: > Items 37 & 38 are misleading. The part in Equality and Comparison that says: > Each operand can be a string literal or an expression of string > type. If one of the two operands is a string literal, it shall be > implicitly converted to string type ? > Can be misinterpreted to mean that when both operands are string > literals the operation is a string operation. Agreed. May I suggest adding the word "exactly" as follows: If exactly one of the two operands is a string literal, it shall be implicitly converted to string type in the offending phrase in both Equality and Comparison? > Likewise, the change to concatenation seems to change the semantics > of string s = { "a", "b", "c" } and is IMHO less clear than the > original text Really? The original text had an internal contradiction in this case; its first sentence says that string literal operands are converted to string type, but its third sentence says that if all the operands are string literals then the expression "behaves like a concatenation of integral types". I don't know what "like" means here, but I'm guessing it means that the effect is a standard Verilog vector concatenation, which is what the proposed new text aims to say. -- 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. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri May 1 10:58:05 2009
This archive was generated by hypermail 2.1.8 : Fri May 01 2009 - 10:58:44 PDT