An overview of the keyword
issue
Whether keywords should be reserved in the language, or
identified depending on context.
Summary of the BLTF work, by Cristian Amitroaie
Terminology
- identifier = a legal e
identifier.
- keyword = an identifier
which has a specific meaning in a specific context (e.g. "if",
"package", "ignore"). Context refers to syntax. "me", "index", "it"
etc. do not fall under this category.
- keyphrase = a sequence of
more identifiers which has a specific meaning in a specific context
(e.g. "is a"). The spacing is unrestricted between the identifiers
(formally "is a" = 'i''s'WSPACE+'a', where WSPACE can be any mixture of
white spaces, tabs or new lines).
- reserved name = an
identifier that can appear in code only in a specific context. Code
does not include the processed data (e.g. x = "for" is legal code even
if "for" is a reserved name).
- reserved phrase = a
sequence of more identifiers that can appear in code only in a specific
context. Code does not include the processed data (e.g. x = "is a" is
legal code even if "is a" is a reserved phrase).
Keyword (From
Wikipedia, the free encyclopedia)
"In computer science, a keyword is an identifier which indicates a
specific command, and in most
circumstances, has been reserved for core language usage. Some common
keywords in many programming languages are: else, end, goto, if,
print, return, switch, then, while, etc. There are usually
restrictions about
reusing keywords as names for user-defined objects such as
variables or procedures, however some languages are extremely liberal
in this approach (such as PostScript), allowing core keywords to be
redefined for specific purposes. Languages vary as to what is provided
as a keyword and what is a library routine, for example some languages
provide keywords for input/output operations whereas in others these
are library routines.
Options
Solution 1 - No Reserved
This is the classic approach.
- advantage 1: free programmer
- disadvantage 1: encourages bad programming practices
- disadvantage 2: complicates parsing
- disadvantage 3: some work is in progress to deprecate this
solution
Solution 2 - Full
Reserved
All identifiers from keywords and keyphrases are reserved names. No
reserved phrases.
- advantage 1: easy parsing
- disadvantage 1: "a" is a reserved name since it comes from
split_ids("is a") and all other similar ("C", "is", "in", "list", "of"
etc.)
- disadvantage 2: Will break existing code. I am sure someone
is using "a" as a field name.
Solution 3 - Phrases
Reserved
The Keywords and Reserved Names sets are identical, that is all
keywords are reserved names.
The Keyphrases and Reserved Phrases sets are identical, that is all
keyphrases are reserved phrases.
- advantage 1: easy parsing
- advantage 2: some work is in progress to deprecate this solution
- disadvantge 1: might break existing code
Some open questions
We need a final agreement on the following issues:
1) all_values, get_all_units, error, error_f, message, message_f
These are routines, not keywords.
2) dut_error, dut_error_f
These are routines, not keywords.
3) get_enclosing_uint, try_eclosing unit
These are predefined methods, not keywords.
4) index, me, result, it
These are automatic variables, not keywords.
5) hr, min, sec, ms, us, ns, ps, fs
These are keywords and reserved names.
6) prev
It is a keyword and a reserved name. It appears in "for each using
index (my_index) prev (my_prev)".
7) list, key, of
These are keywords and reserved names. They appear in "list (key:id) of
s".
8) is
This is a keyword and a reserved name. It appears in "m() is {".
9) in
This is a keyword and reserved name. It appears in "for each (s) in
lof_s"
10) no_collect, count_only, per_instance, global, no_trace (see coverage
definition)
These are automatic variables, no keywords. Should we consider a syntax
like no_collect=TRUE for uniformity?
11) text, when, radix, weight, when, at_least, ignore, illegal, name (see
coverage definition)
These are automatic variables, no keywords.