Re: [vhdl-200x] PAR Progress Report and VHDL Enhancement wish list

On 4/03/11 11:40 AM, Jim Lewis wrote:
>
> This document is intended for the implementers of tools
> supporting the language and the advanced users of the language.

Somewhat belatedly I know, but we've been dealing with the aftermath of an
earthquake here in Christchurch. Consider this a recommendation for a
category of things to pursue in the revision of the standard. You may also
take it I'm in favor of the PAR change.

One of my earliest interests in VHDL standardization stems directly from the
above quoted sentence. VHDL has always been defined to be tool neutral.
There is however the ability to provide vendor advantage by not fully
integrating issues that have come up in the past but have not been mentioned
in the standard.

This class of things could be elaborated to remove late adopter
disadvantage. An example would be 'Qualified expressions lead to lexical
ambiguity'. The LRM tells us in the section on Lexical elements (15.),
wherein in Section 15.3:

"The text of each design unit, apart from text treated specially due to the
effect of tool directives (see 15.11), is a sequence of separate lexical
elements."

In the next paragraph:

"In some cases an explicit separator is required to separate adjacent
lexical elements (namely when, without separation, interpretation as a
single lexical element is possible)."

This issue crops up in distinguishing the lexical element Apostrophe (tick),
a delimiter, from a character literal has described in Issue Report 1045
against VHDL-93. I had no visibility into the VHDL-08 effort, but find it
mentioned in the ISAC minutes for 2007, attached to Lance Thompson's name.
http://www.vhdl.org/isac/Minutes/2007/
minutes-2007-01-11.txt and minutes-2007-02-01.txt. I'd also venture a guess
that Jim is cognizant of this one.

See http://www.vhdl.org/isac/IRs-VHDL-93/IR1045.txt

The issue has not been reflected in any changes to the LRM where the choices
would be to require a separator or provide a mechanism to disambiguate the
two lexical elements - delimiter apostrophe and character literal.

The VHDL LRM has at least one place requiring explicit separators, for the
predefined attribute (16.2) T'VALUE(X) a separator required before a unit
name (See Result para). No such requirement is explicitly stated to separate
basic lexical elements.

IR1045 is quite nifty, alleviating the need for backtracking lexical
analysis, or compliance verification for a required separator.

In keeping with the mime "intended for the implementers of tools
supporting the language", this and any other similar 'Easter Eggs' could be
fully documented. Not doing so disadvantages new implementers efforts over
established tools. Lexical analysis is also evaluation order dependent to
avoid back tracking, it wouldn't hurt to demonstrate that order either.
Further while remaining tool agnostic, implementation trade offs could be
outlined.

I've had the opportunity over the years to address the IR1045 issue 3 or 4
times with new implementers, as well as implementing it in a VHDL lexer
myself. Note this was original LRM-87 IR 225, without analysis, dated March
21, 1991.

This ambiguity is inherited from ADA-83, the public domain specification
approximately 60 percent in common with LRM-87. It's
shown there as a qualified expression on an aggregate.
http://coding.derkeiler.com/Archive/Ada/comp.lang.ada/2006-06/msg00042.html

Although the requirement to stop parsing is specified if the previous
lexical element in an identifier (e.g. ROMAIN'('X') see
http://diwww.epfl.ch/researchlgl/ada/components/gramact/lexical.english.html ).

Keith Thompson specifies this method as shown in
http://www.ada-europe.org/AUJ/PDF/AUJ_27_3.pdf
Ada User Journal Volume 27, Number 3, September 2006, The section Ada in
Context, Page 159 (Page 30 of the PDF file).

The analysis done by Daniel Barclay for IR1045 tells us there are six
preceding lexical elements that signal immediate cessation of scanning when
encountering an Apostrophe in VHDL: Right Paren delimiter, Right Bracket
delimiter, Keyword All, Identifier, String Literal and Character Literal.

You could imagine when contemplating altering the syntax of VHDL the problem
ought to be documented least that set of 6 predicate lexical elements grows
and catches anyone by surprise as the undocumented solution in Ada did for
some implementing VHDL-87.

There are bound to be other areas in the LRM forming natural barriers to
easy implementation of VHDL tools because of lack of coverage. The theme
being to encourage VHDL adoption by removing knowledge barriers or
alternatively tightening the VHDL specification to remove possible ambiguity.

The penalty in not addressing these types of barriers is the lack of VHDL
source code portability, and of course making it harder for tool developers
to adopt VHDL.

I've also felt the urge to classify enhancement wishlist items by what they
impact.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.