padpowell@wateng.UUCP (PAD Powell [Admin]) (10/29/83)
Extract from net.lang.c:
----------------------------
From tjt@kobold.UUCP (T.J.Teixeira) Wed Dec 31 19:00:00 1969
Newsgroups: net.unix-wizards,net.lang.c
Subject: Re: From VMS to UNIX
o Further, the BLISS compile-time and macro-preprocessor
facilities are orders of magnitude more powerful
than what C gives you!
True, but C already gives you a dangerous amount! The problem with
extensive pre-processing is that the lexical appearance of the source
code no longer gives you enough information about the semantics of the
program.
For example, in most contexts in C, a name refers to a variable.
Exceptions to this are names following "." or "->" (structure elements)
or preceeding "(" (function names). This isn't complete information
since the storage class (static, automatic, parameter) is not directly
deducible from the name, nor is the type.
However, using the preprocessor, a name could be *anything*: a
constant, a keyword, punctuation, an entire expression (possibly
including free variables or side-effects). Yes, you can do *amazing*
things with the C preprocessor (look at the source code for the Bourne
shell or adb, or "Modular C", Stowe Boyd, SIGPLAN Vol 18 No 4). It may
look alot like C, but it's different enough to be considered a
different language.
To combat this, most C programmers use the convention of #define'ing
constants using UPPER CASE names, and making sure that #define'd macros
with parameters behave like a function call. If you want to extend the
compile-time facilities, I would prefer an approach similar to PL/1
that makes it explicit what is happening at compile time and what is
happening at run-time. If you want to extend the language, write a
pre-processor: don't kid yourself by hacking around with arcane macros
and call the result C.
Tom Teixeira, Massachusetts Computer Corporation. Littleton MA
...!{harpo,decvax,ucbcad,tektronix}!masscomp!tjt (617) 486-9581
-----------------------------------
I have been attempting to evaluate LISP as a programming language
for VLSI design, and after having read MANY LISP programs,
I have come to the same set of conclusions about LISP as a programming
environment. To make LISP usable, each particular interest group
defines/modifies/extends LISP for its own purposes. The result is a
set of islands of users, each with their own "flavour" of language,
which they claim is the "one, true, and holy LISP".
I like the LISP data structuring;
As a programming language I rank it in the same class as APL:
useful, highly unmaintainble, very hard to document, and VERY unportable.
Patrick
("Flamers better have some good counter examples,
as I can show you parts of FRANZ LISP that NOBODY here
has been able to figure out.") Powell