Re: [sv-bc] Why no 'output' continuous assignments from a function call?

Steven,

    It is a conundrum of language evolution that it happens incrementally,
but defines concepts without any natural time ordering.

    In a year, the world will forget which came first, the internal
side-effect or the output port side effect. It will probably never
realize that one was "grandfathered"-in, and the other was "stillborn".
Instead, some code transformation that moves a hidden side-effect
up into the call site's argument list will be met with an error.

    Perhaps the user will see the error and say AH HA! that's where
my problem was! Why didn't the compiler complain earlier?

    Or else he'll say: This used to compile, and the transformed code
is equivalent to the original, so why do I get a compile error NOW?

    Perhaps the LRM should prescribe that functions called within continuous
assignment expressions must be pure. We would have to note this
exception to backward compatibility and give a good rationale.

    Or perhaps continuous assignment expressions need their own scope
so "automatic" variables can be used to form form input/output
connections between multiple function calls.

    I take no position as to which would be better for the user community,
but I am not totally sold on your "finger in the dike" policy.

Greg

Steven Sharp wrote:
>>According to 10.3, "it shall be illegal to call a function with
>>output ... arguments ... in an expression that is not within
>>a procedural statement." This means that a function call can
>>drive at most one continuous assignment, and, for example,
>>
>> assign a = f(y, b);
>>
>>would be illegal for
>>
>> function f(input y, output b);
>
>
> Even if it were legal, this would not be a continuous assignment to b.
> The returning of a function output argument value is defined to be a
> *procedural* assignment. So you would not have two continuous assignments;
> you would have a continuous assignment that did a procedural assignment
> as a side-effect of evaluation. Having side-effects violates the
> desire for continuous assignments to behave like combinational logic.
> We can't eliminate the pre-existing ability to have side-effects, but
> we don't have to allow new mechanisms for it.
>
> Steven Sharp
> sharp@cadence.com
>
>
Received on Thu Nov 4 13:41:10 2004