[sv-ec] Section 5.15 Array manipulation methods

<forwarding email from Paul Butler>

-------- Original Message --------
Subject: IEEE 1800-2005, section 5.15 Array manipulation methods
Date: Thu, 04 Jan 2007 12:15:19 -0600
From: Paul Butler <paul.butler@ni.com>
To: Neil.Korpusik@Sun.COM



The second sentence of 5.15.1 ends: ". . .that satisfy a given
expression."  Which expression is the "given expression" is not clear.
Also, the meaning of "satisfy" is unclear, although it implies to me that
the expression should evaluate to a Boolean type.  The most recent
antecedents for "expression" are in the previous section.  In particular,
Syntax 5-3 uses the word "expression" twice, which is somewhat confusing.

The final sentence of paragraph 4 in section 5.15.1 states:  "The optional
expression specified by the with clause must evaluate to a Boolean value."
 However, some of the examples (on the following page) show expressions
such as "item.atoi" and "s.tolower" which do not return a Boolean type,
although I suppose their values could be interpreted as Boolean in the
same sense that an "int" is a valid type for an "if" expression.  The
examples hint at how the non-boolean expressions affect their methods but
the preceding descriptive text is unclear to me.

Throughout section 5.15, I find the rules for the with expression unclear.
 For example, since I don't know of a requirement that overloaded
operators must return a particular type, I think I could overload the
comparison operators to return some type other than Boolean.  I could then
satisfy the requirement that, ". . .the relational operators (<,>,==) must
be defined for the element type. . ." such that an expression using the
relational operators doesn't return a Boolean.  How will that affect the
behavior of a method like "unique"?

Another troublesome example might be a case in which the relational
operators are defined in an unusual way.  For example, I might create a
type such that "Apple" > "Orange", "Orange" > "Grape", and "Grape" >
"Apple" all return true.  Some methods, such as "sort", might never finish
operating on an array of these "Fruit".

I'd like to have more information about the ordering methods.  One
property that comes to mind is stability.  I.e. Can I create a prioritized
sort by sorting on different keys in order of increasing key priority?
Some popular sorting algorithms will not produce my preferred result so, I
think my sequence could create a portability problem.  I could also
benefit from performance information.  If I know the sort methods use the
"Bubble sort" algorithm and that my input array is typically nearly
reverse sorted, I can benefit by reversing the array before sorting it.
This would create a different kind of portability problem.

It seems like the core of SV could support something like the C++ STL.
That would allow a user to choose from a variety of ordered containers,
all of which implement the same methods using different algorithms.  That
approach would improve both my portability problems.  Having access to the
source code would answer all my undocumented questions.

On an unrelated note, discussions like these would be easier if the LRM
included some kind of line numbering scheme.  Referring to a line "in the
middle of a page" is ambiguous,  different people are likely to count
paragraphs differently, etc.  I suggest marking every fifth line on each
page as the attached excerpt demonstrates.

Paul.Butler@ni.com
National Instruments
Austin, TX





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