Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!apple!sun-barr!newstop!texsun!smunews!ti-csl!m2!gateley
From: gateley@m2.csc.ti.com (John Gateley)
Newsgroups: comp.lang.misc
Subject: Re: Q Design Goals
Message-ID: <111966@ti-csl.csc.ti.com>
Date: 23 Feb 90 16:15:12 GMT
References: <22569:05:10:24@stealth.acf.nyu.edu> <24995:06:42:28@stealth.acf.nyu.edu>
Sender: news@ti-csl.csc.ti.com
Organization: TI Computer Science Center, Dallas
Lines: 51


In article <24995:06:42:28@stealth.acf.nyu.edu> brnstnd@stealth.acf.nyu.edu (Dan Bernstein) writes:
<[Design goals for Q]:
<Efficiency: Q compiles naturally to efficient code.
<Compilability: Q is easy to compile and optimize.
<Interoperability: If the OS supports it, Q can be linked with existing
<code from similar languages, without any special effort.
<Readability: Any code can be written without much fuss in a form that
<the average programmer can read.

I have a suggestion: instead of designing a whole new language, why not
just write a new front end for C. C satisfies your efficiency,
interoperability, flexibility, and simplicity goals for the
most part. With a front end, you can tweak it however you nead
to provide the rest.

The point I am really trying to make is the design goals above
are too restrictive. By saying Q compiles naturally, you are
tying it to the Von Nuemann(sp) architecture everyone is familiar
with. By saying Q is easy to compile, and optimize, you are tying
it to standard compiler technology. By requiring interoperability
you are requiring it to use data in the same way that most languages
currently do. Finally, by requiring it to be "readable to the average
programmer", you leave out the possibility for new control structure
types.

So, this language is going to be "yet-another-structured-programming-
software-engineering-save-the-world" language. Boring: try and develop
something new, something that HASN'T been done before.

<Extensibility: Compilers can add any kind of feature (new types, new
<operations, new control sequences, whatever) to Q without kludging too
<hard. (Kludging is a verb? Oh, well.) In other words, Q recognizes the
<existence of extensions and provides standard ways to introduce them.

This problem is either already solved (see Common Lisp macros and
type system), or is very challenging (read impossible). CL is easily
extensible through its use of macros. However, writing a new construct
which is EFFICIENTLY integrated with the existing language is difficult.
For most new constructs, there are many optimizations which can only
easily be applied if you see the original constructs. With macros,
they are translated into CL before the compiler sees them, thus the
optimizations can't be performed. This is an interesting problem
to attack.

<Likability: Q is easy to like.

You lost the fox, I don't like it anymore.

John
gateley@m2.csc.ti.com