Subject: RE: [vhdl-200x] Implicit conversion, Overloading, & Strong Typin g
From: Bailey, Stephen (SBailey@model.com)
Date: Tue Dec 23 2003 - 07:59:41 PST
Hi Jonathan,
You have a nice insight in identifying that index (I suspect you intend to include indexed names and slice names in this context) and function calls with only one visible choice being similar to the condition case. The key being that the context identifies what conversion is required.
We'll need to evaluate this in more detail. However, I can say at this point in time, that possible extension to those contexts are possible independent of the current proposal. While users might see them as the same, from a language perspective, they are different contexts. They need to be addressed differently (that is, different LRM sections need modification, potential for side-effects in one area, but not the other, etc.).
What I particularly like about the potential extension to index/slice names is the ability to do:
port addr : IN std_logic_vector(31 downto 0);
...
shared variable mem : std_logic_2d_array;
...
mem(addr) := data;
data <= mem(addr);
But, there are other possible ways to provide this. An obvious way is to define indexing/slicing as an overloadable operator as C++ does. If you can think of any benefit of implicit conversion in this case instead of explicit overloading of indexing/slicing operators, let us know.
Personally, I'm not sure that I like applying implicit conversions in the context of actual parameters to a subprogram call when only one subprogram is visible and a conversion function is visible that provides the needed conversion. I think it would be alot easier to have this applied unintentionally. Also, I think it is a more difficult concept for users to understand why they need an explicit conversion in some cases, but not in others. (Would the compiler messages be helpful? I doubt it. I would expect the user to see the typical message about overload resolution ambiguity.) I'll need to think about it some more and defer it to post-fast track.
-Steve Bailey
> 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
> cases.
>
> 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:
> jonathan.bromley@doulos.com
> Fax: +44 (0)1425 471573 Web:
http://www.doulos.com
This archive was generated by hypermail 2b28 : Tue Dec 23 2003 - 08:01:56 PST