[sv-ec] Queue concat issues (Mantis 412, 520, 522, 801)

This email is a summary of issues in various Mantis
items that need to have a single cohesive proposal
with follow-up changes in various places.


Mantis items 412, 520, 522, and 801 are all related to the
queue concatenation operations.  These operations are
primarily defined by example in 7.11.1 (1800-2008 Draft 3).

There are other examples (see the end of 7.6 and 7.4.6)
that imply that general unpacked array slicing and array
concatenation is permitted with the concat operations.

There are real rules for the conditions under which
the queue concat operations are permitted.  In addition,
there is at least some opinion that this should be an
aggregate form of operation (at least) rather than a
concat form.

Specifically, the syntax and rules for slices and/or unpacked
arrays in 7.11.1 need to be addressed and clarified in terms
of legal context and semantics.

We should try to come to some general consensus regarding
the syntax and intent before asking someone to write up
a proposal.


The rest of this email extracts a few of the relevant issues
from the 4 Mantis items.


 From 7.4.6:

     int a[x:y], b[y:z], e;
     a = {b[c -: d], e};

This seems to imply that concat can apply to an unpacked
slice and an element to produce a new unpacked array.


 From 7.4.6:

     string d[1:5] = '{ "a", "b", "c", "d", "e" };
     string p[];
     p = { d[1:3], "hello", d[4:5] };

     The preceding example creates the dynamic array p with contents
     "a", "b", "c", "hello", "d", "e".


This (pretty clearly) implies that the slice is flattened out.  But
the rules for element types, etc. are not specified.  This implies
that the queue operations from 7.11.1 apply to dynamic arrays.


 From "7.11.1 Queue operators":
     ... Also, queues support the same operations that can be performed
         on unpacked arrays and use the same operators and rules except
         as defined below:


All the special concat examples follow.  The implication is that
the concat operations should NOT apply to non-queue types.  But
that contradicts the other examples cited.



Gord.
-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


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