Subject: RE: [vhdl-200x] Implicit conversion, Overloading, & Strong Typin g
From: Bailey, Stephen (SBailey@model.com)
Date: Fri Dec 19 2003 - 09:02:20 PST
While it is tiring to repeatedly correct misunderstandings, it continues to be necessary as I want everyone to fully comprehend and not misinterpret. I hope those on the list continue to bear with this even as we often cover the same ground. Comments below.
-Steve Bailey
> -----Original Message-----
> Hamish Moffatt wrote:
> > Bailey, Stephen wrote:
> >
> >>>> We actually discussed an alternative way to arrive at the same
> >>>> functionality. Since people seem to be hung up on this
> >
> > [..]
> >
> >>>
> >>> I don't agree. The "cond" operator is certainly just an example of
> >>> the overloading that VHDL already has - the implicit call is IMHO
> >>> unrelated, and the part that most object to.
> >>
> >>
> >> Both Jim and I have attempted to demonstrate how this is nearly
> >> identical to operator overload resolution. I'm sorry we
> have failed
> >> to convince you that it is. I can't think of any better examples.
>
> The problem is that you've had to invent invisible operators
> in order to
> make the argument.
The choices:
- Do nothing to address an enhancement request that is elevated in priority due to the desire to incorporate PSL as the property specification capability in VHDL. (I already pointed out the obvious language inconsistencies that arise if we do nothing.)
- Redefine the language so that if, etc. (as mentioned in a previous email) are operators that can be overloaded. Problems:
a. Not easy to introduce this new semantics for operator overloading in what is today a statement context. (Lots of LRM work, lots of work to convince people it is a good thing.)
b. Would not directly address the PSL issue. Therefore, we would need to say something like "the overloaded if conditional operator would be applied in the PSL boolean contexts."
- The proposal under discussion.
It is actually convenient that a single operator applies to all of these contexts because they are classified as a *condition* context. That context exists today. We did not invent it. PSL is already exploiting it. What we are defining is the implicit call. The operator would need to be explicitly declared and visible. It is not, by any stretch of the imagination, invisible.
> Overloading clearly has the potential to break the
> benefits of a strong typing system, but it's controllable because it
> only applies in a very limited context. However, the proposal
> effectively wants to overload certain *expressions*, in certain
> contexts.
There is no concept of overloading expressions in the language and we are not creating one. If such a concept existed, you would not need to type qualify string literals in calls to write, type qualify bit-string literals in countless contexts, etc.
(Now if people are as annoyed with these current usability issues I just described as I am, then perhaps overloading of expressions is not, prima facie, a bad thing. However, it is not what this proposal is about, so let's avoid that rat-hole.)
> This is clearly unacceptable - overloading
> expressions has no
> meaning, and would be dangerous if it was possible - and so you've
> invented invisible operators to do it. It's ingenious, but
> it's just a
> formalism which gives you exactly the same effect. If you want this
> effect, you should just say so, and say that the typing rules
> should be
> relaxed in conditionals. This does exactly the same thing,
> and saves the
> hassle of adding new invisible operators to the language.
No, that would be a hacker's way of changing the language. We have worked hard to provide a general solution that can be used, but does not need to be used and is consistent with strong-typing. (I'm liking more and more the suggestion to put the operator definitions in a separate package to avoid unintentional use.) It is backward compatible and it cannot be ambiguously extended outside of a specific context.
-Steve Bailey
This archive was generated by hypermail 2b28 : Fri Dec 19 2003 - 09:05:16 PST