|[9 earlier articles]|
|Re: Languages that are hard to parse Satyam@satyam.com.ar (Satyam) (2005-05-22)|
|Re: Languages that are hard to parse DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2005-05-22)|
|Re: Languages that are hard to parse firstname.lastname@example.org (Tony Finch) (2005-05-24)|
|Re: Languages that are hard to parse email@example.com (2005-05-24)|
|Re: Languages that are hard to parse Martin.Ward@durham.ac.uk (Martin Ward) (2005-05-24)|
|Re: Languages that are hard to parse firstname.lastname@example.org (2005-05-26)|
|Re: Languages that are hard to parse email@example.com (2005-06-02)|
|Re: Languages that are hard to parse firstname.lastname@example.org (Alexios Zavras) (2005-06-02)|
|Re: Languages that are hard to parse email@example.com (Gene Wirchenko) (2005-06-04)|
|From:||firstname.lastname@example.org (Hannah Schroeter)|
|Date:||2 Jun 2005 01:03:12 -0400|
|Organization:||Schlund + Partner AG|
|References:||05-05-119 05-05-155 05-05-166 05-05-182|
Hans-Peter Diettrich <DrDiettrich@compuserve.de> wrote:
>glen herrmannsfeldt wrote:
>> To me, reserved words are used to make parsing easier, and not to
>> make programs easier to write.
>Reserved words also make programs easier to read (understand). Not
>only to parsers.
>[But they make them far harder to write. The reason that PL/I doesn't have
>reserved words is that COBOL has a huge list, so that programmers either
>need to keep a chart of them on the office wall to consult every time they
>invent a new name, or be sure every name includes a hyphen or digit to
>be sure it doesn't collide with one. -John]
I think what Lisp (in the sense of Common Lisp) does could be a good
No reserved words in the stricter sense, easy to parse and process.
There are restrictions in what you can do on the symbols from the
COMMON-LISP package, but then, you can mostly work in your own
packages, importing only the symbols you use from COMMON-LISP, so
from the user perspective only those imported symbols are somewhat
akin to reserved words.
Having separate meanings to symbols (usage as function name, as
variable name, as class name, etc.), i.e. several namespaces
(historically named Lisp-2 as the main separation is seen between
usage as function vs. usage as variable) alleviates issues too.
While LIST (from the COMMON-LISP package to be precise) is defined
as a standard function, you may still bind LIST as a variable, *and*
you still have the LIST function available in the scope of the variable
The same would even go for the names of the standard special forms
(which are perhaps nearest to what reserved words are usually used
for in many other languages, e.g. basic control structures).
Another example would be that Smalltalk seems to cope with a
rather lean syntax and with *very* few reserved words ("self" comes
to mind) and still much functionality.
Return to the
Search the comp.compilers archives again.