RE: [sv-ec] issues on queue syntax

Shalom

Thanks for your response.

> the existing LRM is certainly confusing. It implies that
> queues use the same or similar syntax to that of arrays.

I absolutely agree that this is a problem.  Too many places in the
LRM rather glibly say, in effect, "queues are more-or-less the 
same as arrays" and, ultimately, leave us none the wiser.

> You yourself recognize the need for some clarifications and
> enhancements, implying that the current LRM does not quite work.

No argument.  At the very least, it leaves some worrying
partially-answered questions.

> > Apart from the backward-compatibility issues involved
> > (queues have been around for a long time) there is a
> 
> [SB] Arrays were around a long time also.

Yes, but assignment patterns weren't.  The old (pre- 
assignment patterns) form of structure literal simply
didn't work, and I suggest we discount it entirely.

> [SB] I think something like $explode is a great idea. It 
> would be useful for all types of arrays, not just queues,
> and in many contexts (e.g., $display).

It's interesting to note that Tcl suffers very much this kind
of problem with its lists.  There have been many attempts
at dealing with it over the years, some apparently automatic
(the [eval] and [concat] commands, which automatically 
explode one level of list structure) and some explicit
(the new $expand{} syntax that's being added to Tcl 8.5).
So we are not alone in having this problem to worry about.

> > If someone can provide an example of the *existing* queue
> > syntax that is ambiguous in some way, then we should
> > review that.  
> 
> [SB] But without the note that you suggest below, the 
> existing syntax IS ambiguous, because concatenations
> do not work that way. See Mantis 412, for example.

But that's exactly what I'm saying - that {} should
have a special meaning when used in a queue context,
and its meaning should be that it takes elements 
*and one-dimensional arrays of elements* and flattens
them into a single large array.  I agree that this needs
clarification, but I suspect that it works without change
to existing code, and that it would legitimize the examples
of which 412 disapproves.

> [SB] What is the definition of a 'queue context'? Remember that
> expressions can have complex sub-expressions of many types.

I reckon it's the same problem as we have with assignment
patterns.  If I write

  int s[2] = '{1,2};

there is no difficulty because the assignment pattern can
inherit its data type from the context.  Similarly, if
I write

  int q1[$] = {1, 2}; 
  int q2[$] = {q1, 3};   // yields {1,2,3}

the {} queue-expression "operators" can infer from the
context that they should be constructing queues of ints.
As Mantis 412 correctly points out, '{} doesn't work here
because of the requirement to concatenate queues and 
elements; hence my position that the existing de-facto
{} syntax should be retained but clarified.

Both {} and '{} are in trouble if they form part of
a more complex expression where the type is not well
defined.  In both cases, type qualification (or static
casting, or whatever SV calls it) does the job: we can
write 
  some_array_type'{a,b}
to disambiguate an assignment pattern, and (if you follow
my suggested rules) we can write
  some_queue_type'( {a,b} )
to provide unambiguous context for a {} queue expression.

So, in conclusion:

1. You can make assignment patterns work just fine for 
  queues as well as regular arrays, but you need an
  array-flattening operator (my "$explode") to express
  some of the most useful operations on queues.
2. You can probably make the existing queue syntax work
  in a stable unambiguous manner, but it would involve
  a significant amount of work on the LRM and in particular
  it would require the recognition that queues and arrays
  are quite different in some ways.

(1) is probably the cleaner fix, but it breaks large amounts
of existing code.  (2) is a little messier, and entails 
non-trivial LRM editing.  I am pretty much convinced that
both solutions can work.  I'm guessing that (2) is
much more acceptable to the user community.
-- 
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

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.