RE: [sv-bc] Issues on Queue Operators

Replying to sv-bc as well as sv-ec where it belongs, 
because I've had trouble sending to sv-ec for some reason.

There's no doubt that queue expression syntax is confusing
and gives rise to many difficulties.  Elsewhere in the 
language we now have reasonably clear meaning and intent
for concatenation {...} and assignment-pattern '{...}
but the queue expression syntax cuts across these two
meanings in a confused way.

In almost every respect a queue is merely a degenerate
form of dynamic array with some useful (but, as we have
seen, troublesome) syntax-sugar for writing expressions.
However, a queue has the property, not shared with a 
dynamic array, that it may be resized merely by being
the target of an assignment.  I believe this is the 
only property of queues that is not shared with
dynamic arrays.  Consequently I have for some time been
of the private opinion that the two constructs should
be merged, by removing the [$] declaration syntax of
queues and by adding to dynamic arrays the ability
to be resized automatically by copying.  It would also
be convenient to allow $ to mean "last subscript" of a 
dynamic array, as it currently does for a queue.

Once this simplifying step has been taken, it remains
only to resolve the mess over how to write expressions 
of queue or dynamic array type.

Since queues and dynamic arrays are of necessity not 
packed, the queue expression syntax is not of itself
ambiguous.  However, it is exceptionally confusing when
considered together with assignment-pattern syntax.
I'd like to consider a few common use cases:

(1) Constructing a queue or dynamic array _ab initio_:

   int Q[$];   // or int Q[];
   ...
   Q = {1, 2, 3, 4};

In this case it would clearly make much more sense to
use assignment pattern syntax.  The assignment pattern
"knows" that it is describing an unpacked array of int.
The number of elements is trivially inferred from the
pattern.  There is no asymmetry with the case where Q
is a simple unpacked array of four ints.  Without the
apostrophe, however, all is well: the queue Q cannot
possibly be the target for assignment of an ordinary
(packed) concatenation and so the {,,} must be 
interpreted as a queue expression.

(2) Appending to a queue:

   <declarations as above>
   Q = {Q[0:2], Q[1:3], 7};

This case is much more troublesome.  Plainly, an 
assignment pattern is no use here unless we can invent
a new operator that concatenates arrays by first flattening
them to elements and then concatenating those elements, in
the manner of the & concatenation operator in VHDL or the
[concat] command in Tcl.  On the other hand, the existing
queue syntax {,,} is unambiguous in its context; there
is no possibility of Q being the target for assignment of
a single packed value (concatenation) and so the {,,}
syntax must be interpreted as queue concatenation.

(3) Constructing a queue value some of whose elements
    have known values and some that are defaulted:

  Q = '{0:34, 1000:35, default:0};

I don't believe you can do quite this right now with 
queues, but it's clear that the assignment pattern syntax
fits the bill nicely.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

My tentative conclusion, then, is that the {,,,} queue 
expression syntax is unambiguous in its usual context,
but represents a disgustingly ugly clash with other uses 
of {} and should be gotten rid of as soon as possible.

As VHDL has already learnt the hard way, syntax that allows
you to concatenate an array with single elements in an
arbitrary mix is attractive at first glance but a can
of worms on closer inspection.  'e' has list concatenation,
but this works only because 'e' lists (dynamic arrays) 
cannot have lists as their elements, so concatenating 
two arrays can have only one possible meaning.  I believe
that the same restriction was true of queues in Superlog
(their elements could not be of queue type).

In SV things are more complicated.  Given that 
an array can have elements of array type, you have the
problem of whether a concatenation of two 3-element 
arrays is a single 6-element array or an array of 
two 3-element arrays.  Assignment patterns 
fix this, but (as has already been noted here) don't 
work if you mix arrays and elements in the pattern.

The simplicity of the queue expression syntax could
be rescued, and the rigour of assignment patterns 
preserved, if we could introduce an additional notation
into assignment patterns: an "array explode" operation
that would act, within an assignment pattern and only
within an assignment pattern, as if it were replaced by
a comma-separated list of the array's elements.  Only one
dimension of an array could be thus exploded. I'm tempted
to use inside-out curly brackets for that, on the grounds
that it's almost exactly the inverse of concatenation...

// append one int to a queue of ints

Q = '{ }Q{ , 7 };

but it's so ugly that I give up and leave it to someone
else to invent the right syntax.

Whatever the outcome, I'm glad to have had the chance to
express my frustration with the confusing and unnecessary
overlap between queues and dynamic arrays.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * 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                           Web: http://www.doulos.com

This e-mail and any  attachments are  confidential and Doulos Ltd. reserves 
all rights of privilege in  respect thereof. It is intended for the use of 
the addressee only. If you are not the intended recipient please delete it 
from  your  system, any  use, disclosure, or copying  of this  document is 
unauthorised. The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.