Subject: Re: [vhdl-200x] Corrections to Minutes for VHDL-200X-FT meeting,S an Jose Dec 4, 2003
From: Rick Munden (munden@acuson.com)
Date: Thu Dec 18 2003 - 08:48:50 PST
Matthias,
You make a good point. Some argue that if you don't like a new feature
you don't have to use it. I find that most of the code I work with was
originally written by someone else. How do I restrict their usage of a
new feature that makes code maintenance more difficult?
Rick Munden
Matthias Wächter wrote:
> 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
>
This archive was generated by hypermail 2b28 : Thu Dec 18 2003 - 08:50:36 PST