VHDL Issue Number: 1093 Classification: Language Deficiencies and Modeling Problems Language Version: VHDL-93 Summary: Replacement characters (from Ada) complicate parsing. Related Issues: Relevant LRM Sections: 13.10 Key Words and Phrases: replacement characters, lexical elements Current Status: ISAC-Approved 1076-1993 Disposition: N/A Disposition Rationale: N/A Superseded By: N/A ----------------------- Date Submitted: 1994/08/08 Author of Submission: Paul Graham (edited by Daniel Barclay) Author's Affiliation: COMPASS Design Automation, Inc. Author's Post Address: 5457 Twin Knolls Rd., Suite 100 Columbia, MD 21045 USA Author's Phone Number: 410-992-5700 Author's Fax Number: 410-993-3536 Author's Net Address: graham@compass-da.com / daniel@compass-da.com ----------------------- Date Analyzed: 8 June 1995 Author of Analysis: John Willis (jwillis@acm.org) Revision Number: $Revision: 1.10 $ Date Last Revised: $Date: 1995/06/20 22:56:36 $ Description of Problem ---------------------- I would the LRM to drop section 13.10, Allowable Replacements of Characters. I have two reasons, the first theoretical, the second practical. 1. Character replacements are necessary only to allow VHDL to be used on systems which do not support the set of basic graphic characters. Are there any such machines in the world? Perhaps. But are any of these machines capable of supporting VHDL tools? The concept of character replacements was taken from Ada. The Ada designers wanted to come up with a language which could replace all languages used by the DoD. The DoD probably operates some pretty ancient machines. So the Ada designers tried to limit the basic character set so that as many of these machines as possible could support Ada. Not only that, but they provided replacements for some of the basic characters. They probably thought that any machine which could not support the basic character set or some combination of the basic character and the replacement characters was worth ignoring. VHDL was not designed with old machines in mind. The basic tasks of VHDL, simulation, synthesis, and formal verification, require fast, high-capacity, modern machines. Retrofitting ancient machines with VHDL cannot have been a serious concern of the VHDL designers. I also don't think that maintaining basic-character-set compatibility with Ada was an important design goal of VHDL. Just consider how far VHDL has diverged from Ada, even in areas which are not specific to hardware description (use clauses, subelement association in calls to overloaded operators, etc.). Recall how the charcaters '[' and ']' were added to the basic character set in VHDL 1993. Were there any concerns about losing character set compatiblity with Ada? 2. To support the substitution of ":" for "#" in a based literal requires a lexer with two character lookahead. Consider: constant c : integer range 1 to 4:= 3; To a lexer with one character of lookhead, the sequence "4:" looks like the start of a based literal. Such a lexer parses the above example as ... "4:=" "3". However, a number of experts from comp.lang.ada agreed that an Ada compiler must parse the Ada equivalent c : integer range 1 .. 4:= 3; as ... "4" ":=" "3" instead of as ... "4:=" "3". Proposed Resolution ------------------- Remove this particular character substitution (or all character substitutions), or declare that "4:=" should be parsed as "4" ":=". VASG-ISAC Analysis & Rationale ------------------------------ A posting on comp.lang.vhdl looking for those who depend on any of the three character replacements only elicited a note from Doug Dunlop indicating that Ada had dropped the character replacement section. After checking with those who use VHDL on a variety of obscure mainframes, I could not find anyone who depended on these character replacements anymore. Most VHDL-87 and VHDL-93 analyzers already support these replacements, so the initial implementation cost is probably not much of a concern. VASG-ISAC Recommendation for IEEE Std 1076-1993 ----------------------------------------------- Use of any character replacement should be discouraged with the intent that the capability will disappear in a future language revision. VASG-ISAC Recommendation for Future Revisions --------------------------------------------- Section 13.10 should be deleted in the next revision of the LRM. This will free the '!' and '%' characters for use as special characters.