RE: [sv-ec] Re: Feedback from Freescale on name resolution issues

I'm continuing to worry away at this (name binding
in inline constraints) because I believe we have a
fairly important usability problem here, and a real
opportunity to resolve a good fix.

So far (unless I've missed something) we have...

(1) the current rule whereby names are preferentially 
    bound into the target object;

(2) the suggestion (Gord's?) that randomize...with be
    permitted to have a list of those names that are 
    to be bound into the object:
   obj.randomize() with (var1, ..., varN) {constraints};

(3) use of "item." as a prefix to names in the constraints
    to mean "bind into the target", with the appearance of
    "item." suppressing the current rule (1)

I and others have already described various objections to (1).
However, we must preserve backwards compatibility with it,
so any new syntax or behaviour that we choose must be 
clearly distinguishable from it.

It's clear that (2) will do the job, but I don't see it as
a practical usable solution.  Maintenance of the list of
data members is messy, and if the list and/or constraints
are long it will be hard to tie them together visually.

When I suggested (3) I was mistakenly assuming that "item" is
a reserved word.  It isn't, of course.  This is a show-stopper, 
because the risk of a name conflict with a data member "item" 
in the object is too great, and the consequences too confusing.

But I'm not willing to let this go, I'm afraid.  So here 
are some rescue attempts:

(4) Adopt form (3), but promote "item" to be a reserved word.
(5) Choose a different existing reserved word to use in
    form (3), in place of "item".
(6) Borrow the abbreviated syntax from 'e' and use "." as the
    prefix:
      obj.randomize() with {.x < .y + x;};
(7) In a modification of suggestion (2):  instead of putting
    a list of names in the parens, provide just one identifier, 
    freely chosen by the programmer, which is to be treated as 
    an alias for the object being randomized:
      obj.randomize() with (thing) {thing.x < thing.y + x;};

I imagine (4) will be offensive to many, and will break too
much existing code for comfort.

I couldn't find any really good candidate keywords for (5);
you could just about imagine "class", "solve", "alias" 
or "instance" but none of those sounds good to me.

(6) is straightforward, but experience from 'e' suggests 
that it can be error-prone and rather hard to read.  Worse,
it means that a single "." appearing in the right place
in a constraint can dramatically affect the meaning of
the whole constraint set.  That sounds like a disaster
waiting to happen.

(7) seems to me to be a useful compromise.  It could also
be retrofitted to the array-method syntax, allowing users
to work around a (much less problematic) name conflict that
can exist there with the current "item" syntax.  And it has
the advantage that it is a completely different syntactic
form than the present one, clearly flagging the different
behaviour.
-- 
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.

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