Subject: RE: [vhdl-200x] Implicit conversion, Overloading, & Strong Typin g
From: Jonathan Bromley (email@example.com)
Date: Tue Dec 23 2003 - 03:13:19 PST
Although I've tried to read the whole of this thread I'm
coming to this discussion rather late, so please forgive me
if I'm covering old ground or missing a point somewhere.
When first I heard about the "if std_logic_signal then..."
idea it filled me with distaste, for the same reasons that
others have expressed. However, after more thought I now
firmly believe that it's a good idea and that **the current
proposals go nowhere near far enough**. In particular, we
have a proposed rather non-orthogonal hack in the form of
the "COND()" function.
Dare I suggest a slightly different approach?
There are a few places in VHDL where the type of an expression
is inevitable from the context. The obvious examples are
conditionals and array subscripts; less obviously, the
parameters of functions that have only one possible overloaded
definition. In such places, an implicit type conversion seems
both sensible and useful. However, we need to get that
type conversion under user control (at least in principle),
just in the same way that operator overloading gets things
under user control.
Suppose for a moment that the language were extended
so that any type name could be used to denote a conversion
function to that type from any expression. Such conversion
functions could, naturally, be user-defined. They would fit
with the existing language in which closely related types have
such functions implicitly defined, and would allow package
authors to simplify some aspects of type conversion in some
Now let's suppose that, in situtations where the type of an
expression is self-determined from the context,
the language always implicitly calls the type-name conversion
function as described in the previous paragraph. Now,
if not we_N then ...
is implicitly rewritten as
if BOOLEAN(not we_N) then ...
and **if and only if the relevant conversion has been defined**,
everything works as the minimal-keystroke enthusiasts would wish.
I can't see why the same shouldn't work for PSL boolean equivalence.
Note that this process has no effect on the expression itself.
The call to BOOLEAN() is there because if...then demands a
Boolean condition. If the expression were already of Boolean
type, then the call to BOOLEAN() would be harmless (BOOLEAN
and BOOLEAN are closely related types!).
Such a mechanism would be, as far as I can see, more uniform and
regular than what has been discussed so far. It solves the
original problem just as COND() does, but it extends the solution
so that it is useful elsewhere, without imposing the solution
on people who don't want it - if you don't define the relevant
conversion function, your use of the wrong type will fail.
-- 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: firstname.lastname@example.org Fax: +44 (0)1425 471573 Web: http://www.doulos.com
This archive was generated by hypermail 2b28 : Tue Dec 23 2003 - 03:35:06 PST