🚀 go-pugleaf

In article <1992Jul24.144708.3784@inmos.co.uk> bruce@cheetah.inmos.co.uk
(Bruce Stenning) writes:
[stuff by me deleted]

>One question:	Do you consider C a high-level language?  I'd call a low
>level language with the typing and control of a high-level language.
>There are a lot of things you can do in C that would be far less
>efficient in any other language.  The beauty of C is that it allows the
>programmer to write code that checks itself rather than this being done
>by the compiler.  It is very good practise to write code that is
>thoroughly checked than hope the compiler will catch it for you.
>Writing well-documented C code with meaningful variable names will mean
>that it will be maintainable and very efficient.

If I was being sarcastic, I'd call C a low level language with pretensions
of being a high level one! There are lots of languages that can readily
be as efficient as C at everything, given the same compiler technology.
Most of them are classed as "systems programming languages" or some such.
Some of them are (believe it or not!) lower level than C, others are at
a higher level (in terms of the checking they perform for you). Personally,
I write code with a reasonable set of conchecks, etc. My AmigaMUD database
code has some pretty comprehensive auditing code, for example. However,
for finding the dumber bugs, like missing parameters, mixed up parameters,
some kinds of typos, mixing up variable names, etc. I would much rather
have the compiler tell me about my mistakes than have to find them with
a debugger.

>Can you imagine writing something like UNIX in Pascal?  It would be an
>absolute nightmare.

Hasn't it been done?

To keep this discussion going, here's a random thought about C:

C's declarations are syntactically the same as the expressions that use
the declared variables. E.g.

    declaration:	char *((**ppapc)[SIZE]);
    usage		     *((**ppapc)[index])

(some of the parentheses are not necessary, but are there for clarity)

This sounds good, but produces a bunch of problems. One is that a typo
in your declarations can make the compiler think that you are into the
executable part of a function, so that it gets confused and misses some
declarations, etc. and you get a zillion error messages from one error.
Missing semicolons are quite bad for this. Another problem is what happens
with casts, where the identifier is omitted from the type form - they
often look wierd and some people have trouble figuring out what they
should look like. Also, since a lot of the type information is associated
with the identifier, and not the base type ('char' above), it is easy to
miss, say, a '*', and get the wrong declaration.

In my language, Draco, the above would be:

    declaration:	**[SIZE]*char ppapc;
{read: pointer to pointer to array of pointer to char}
    usage		ppapc**[index]*

Note that all operations are postfix in the expression, so no extra
parentheses were required. Also, the operations are again done in the
same order as in the declaration, but the two forms are syntactically
different (kind of prefix in the type, postfix in use), so the compiler
has much less trouble handling simple typos in declarations. I'm not
saying this is the best way to handle this stuff, but it does avoid the
above-mentioned problems that C has.

[My example started out having a function type, but Draco doesn't
bother with the '*' for the function declaration or call, since it
just doesn't make sense in this kind of language to have a function
value, as opposed to a pointer to a function, so the differences in
the forms were enough to obscure my already obscure point.]

--
Chris Gray   alberta!ami-cg!cg	 or   cg%ami-cg@CS.UAlberta.CA