Subject: RE: [vhdl-200x] Corrections to Minutes for VHDL-200X-FT meeting,S an Jose Dec 4, 2003
From: Bailey, Stephen (SBailey@model.com)
Date: Thu Dec 18 2003 - 08:58:58 PST
Hi Matthias,
We have no plans on applying implicit type conversions anywhere in an expression other than at the top level in the context of a condition. There are significant issues with applying them to a broader expression context and those issues are fundamental to VHDL (that is, not easily, possibly impossible, to change).
-Steve Bailey
> Stephen,
>
> On Wed, 17 Dec 2003, Bailey, Stephen wrote:
> > The suggestion, and I was not privy to your reply to Jim, was to
> > extend the use of implied conversions to expressions, when this
> > language change was previously proposed as "only allowed in
> > conditions".
> >
> > If the proposal said this, it was a mistake. We specifically
> > discussed the problems with implicit conversions applied anywhere in
> > an expression back in July and knew this would cause all kinds of
> > problems. That is why we decided we needed to limit it to the
> > top-level of the expression and only within the context that the
> > language recognizes as a *condition*.
>
> If I understand Andy correctly (and if not, then that's my
> opinion), he is
> sure that limiting the implicit conversion to the *condition* will by
> itself lead to confusion at people using this feature. They
> will say: Hey,
> if VHDL is _that_ cool, why not have implicit conversion in the
> *expressions* as well? And -then!- the problem is here: (1) We cannot
> remove the feature anymore, (2) the pressure on standardizing
> Verilog-like
> implicit conversions in *expressions* will get higher, and the next
> proposal will be that VHDL allows implicit boolean equivalence within
> expressions. Then we have Verilog-VHDL.
>
> Of course, ensuring backward compatibility allows Andy, me
> and all other
> guys with a fable for strong typing to write "if cond = '1'
> then" in our
> closed chambers. But the issues here are, especially in the aerospace
> industry, proofreading, verification, certification, and not
> to forget,
> composability. And the less ambiguous the code is, the faster it is to
> read and to verify. You not always have to deal with your own
> code in the
> real world.
>
> Yours,
> - Matthias Waechter
> TTChip Entwicklungs-GesmbH
>
> --
> "To get control over people, make them trust you.
> To make people trust you
> don't try to tell them the truth about history
> but make happen what you told them about the future."
>
This archive was generated by hypermail 2b28 : Thu Dec 18 2003 - 09:00:35 PST