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

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.

> Why allowing "??" in expressions ?

I think this question is essentially whether the operation should be an
operator or a named conversion function, such as To_boolean.

If it were a named conversion function, it could be called in expressions
using the normal function call syntax, eg, To_boolean(a). It could also be
used as a conversion function in association lists. The problem, however,
is that it would be a homograph of like-named functions declared by users.
This would be a problem for existing models that declare such functions.

Alternatively, the operation could be an operator as the proposal suggests.
In that case, it could still be called in expressions using the normal
function call syntax, eg, "??"(a), and used as a conversion function in
association lists. It won't be a homograph of existing function
declarations, since there has not previously been an operator symbol "??".

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.

> My second concern is what you entitled 'this does not fit
> within my methodology'. The reply was: 'it is ok not to use
> it'. This is a too weak reply, since you can use this
> feature without knowing it. That's an advantage of language
> such as VHDL: you know when you use a feature or not. The
> natural way is to use a separate package, but this is not
> popular. Maybe the use of context clauses could defeat the
> 'too many packages' argument ?

I'll defer to the author of that part of the discussion to reply.

> 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:

  [bit, bit return bit]
  [bit_vector, bit_vector return bit_vector]

In response to user requests, we're adding further overloaded versions with
signatures:

  [bit_vector return bit]
  [bit, bit_vector return bit_vector]
  [bit_vector, bit return bit_vector]
  [bit, boolean return bit]
  [boolean, bit return bit]

Similarly for STD_ULOGIC and the vector types STD_ULOGIC_VECTOR and
STD_LOGIC_VECTOR.

Cheers,

PA

--
Dr. Peter J. Ashenden                        peter@ashenden.com.au
Ashenden Designs Pty. Ltd.                   www.ashenden.com.au
PO Box 640                                   Ph:  +61 8 8339 7532
Stirling, SA 5152                            Fax: +61 8 8339 2616
Australia                                    Mobile: +61 414 70 9106