Subject: Re: [vhdl-200x] Corrections to Minutes for VHDL-200X-FT meeting,S an Jose Dec 4, 2003
From: Swart, Chuck (cswart@model.com)
Date: Thu Dec 18 2003 - 11:18:49 PST
To throw more gasoline on the fire.
The attempt to simplify syntax in a c-like fashion is not universally
supported.
I refer to Java, which was derived in large part from C/C++
1) Java does not allow implicit conversions from integer to boolean.
So you can't say
if(int1)...
You must say if(int1 >0 1) ...
etc.
2) Java makes extensive use of functions converting objects to strings
The name of these methods is toString, not toStr. Again, the decision
was made to
use the longer, more descriptive names.
3) Java does not have a preprocessor.
4) Java uses long names.
To quote "Java: An Introduction to Computer Scirnce & Programming" by
Walter Savitch: "It is part of the culture of the Java language that
programmers use long, clear identifiers and do
not use abbreviations for identifier names....Most programmers
eventually get used to the long, clear names
and even come to prefer them."
My point is not that Java "got it right" but that the C style of short
names, many implicit conversions, etc.
is far from universally accepted. We should be very careful in deciding
whether to move VHDL in this direction.
Chuck Swart
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 - 11:20:30 PST