Re: [sv-bc] Assignment pattern lvals (mantis 623)

Gord,

Thanks for the feedback.  There's a lot of good stuff there.
Let's take your last point first.  You write --

>we should require
>typed assignment patterns in all lval contexts for
>the current LRM.

Below I offer a compromise on this, but first some background.

The proposed functionality, while new, doesn't seem all that problematic
to me except perhaps for port connections.

Unfortunately, even if your suggested restriction were limited to
port connections, that would make exactly the requested use model
nonstandard.  A goal of assignment patterns as the left-hand side
of an assignment-like context is to generalize the polymorphism
of port connections.  Users ask, if I can use polymorphic assignment
patterns to drive signals across a port, then why not also to receive
signals across a port?

To users it's about symmetry.  It seems unnatural for concats to
work on both sides, and then to add an apparently new-and-improved
polymorphic concat that only works on one side.  But as you point out,
concats have a self-determined type.

(A key point for below -- users are viewing these as a generalization
of concat that does not discriminate against the unpacked.)

Correct me if I'm wrong, but I'm thinking that your main objection here
is that the elaboration of a module would need to use a stack discipline
and wait for the elaboration of its down designs, analogously to a function
evaluation suspending while the function calls within it are evaluated.

I can understand that objection, and would be willing to severely
restrict the form of (untyped) assignment patterns that can be used as
the left-hand side of an assignment-like context.  For the (untyped)
assignment pattern, what's needed in real practice is only the positional
form, and, moreover, only those in which the lvalues in the assignment
patterns have self-determined types of exactly the same width as the 
corresponding fields on the right-hand side.

The effect is a LHS concat that doesn't discriminate against the unpacked.

I don't think this restriction on the form of left-hand side (untyped)
assignment patterns is really needed outside of port connections, but
for consistency I wouldn't be opposed to declaring the more elaborate
untyped usages as also nonstandard on any kind of left-hand side.

-- Brad

p.s. All "assignment patterns" are untyped, i.e., polymorphic.  You can
combine a type and an assignment pattern to form an "assignment pattern
expression", which has that self-determined type.