RE: [vhdl-200x-ft] Revised FT18: condition operator

Selon Peter Ashenden <peter@ashenden.com.au>:

> Tristan,
>
> Thanks very much for getting involved in this effort. Your input is much
> appreciated.
>
> Regarding your comments:
>
> > It is interesting for "??" to be an operator ?
> > How confusing would be assignment such as:
> > res <= ?? a = '1';
>
> Presumably you would write
>
> res <= ?? a;
>
> Since a is of some type such as BIT or STD_ULOGIC, the ?? operator would
> convert it to BOOLEAN. The aim is to avoid having to to a = '1' in contexts
> that are syntactically conditions.
Sure.
I was not precise enough. My concern is on the proliferation of operators.
The more operator the less you easily undertand complex expressions.
What about 'res <= ?? a shl b + c;' ?
Of course, you can use parenthesis. But in this case, why introducing more
unary operator. I am pretty sure no one use the 'abs' operator without
parenthesis. So, was it interesting to provide the 'abs' operator ? 'abs'
could have been a regular function. (Note, I don't want to discuss on 'abs',
since it is really too late).

> > Why allowing "??" in expressions ?
[...]
> You could consider not allowing it as a prefix operator in expressions.
> That is, allow it to be declared as a function named "??", but not to have
> syntax to invoke it as a prefix operator. However, this would introduce an
> inconsistency, that there is an operation with an operator symbol but that
> can't be invoked as an operator. I would prefer to be consistent and have
> concrete syntax for invoking any operator.
This is a valid argument.

[...]
> > My third concern is the profusion of logical operators in
> > standard. This shows something is turning wrong.
>
> I presume you're referring to the proliferation of overloaded versions of
> the operators. I think the argument is that something was already wrong and
> we're trying to fix it. What was wrong was that we didn't provide
> overloaded versions for common usages. In the case of BIT-based types, we
> only provided logical operators with the following signatures:
OK.
I think these functions must be explicitly defined in std.standard.

Tristan.
Received on Thu Dec 2 00:53:31 2004