Path: utzoo!attcan!uunet!wuarchive!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cica!iuvax!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.misc
Subject: Re: Q Design Goals
Message-ID: <1970@l.cc.purdue.edu>
Date: 27 Feb 90 15:49:10 GMT
References: <22569:05:10:24@stealth.acf.nyu.edu< <111966@ti-csl.csc.ti.com>
Organization: Purdue University Statistics Department
Lines: 81

In article <111966@ti-csl.csc.ti.com<, gateley@m2.csc.ti.com (John Gateley) writes:
> 
< 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.

As someone who uses C, I must absolutely demur with the idea that
efficiency and flexibility can be achieved in C.  C neither has
the variety of primitive operators nor types to achieve this.  I
am frequently having to do these primitives in clumsy assembler
form, although the ideas are largely machine independent, although
the actual instructions are not.  It is sometimes even difficult to
do these in such a way that the compiler will not clobber registers
which should not be clobbered.  How would you write a recursive
algorithm which holds three registers, used in many of the stages
of the otherwise simple recursion, for a special purpose?  Two of
these registers must be adjacent; a double long shift is used, and
an overflow test, if available.

> 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.

Readable to the average programmer should definitely be dropped.  One 
should not expect a program involving acceptance-replacement algorithms
for the generation of infinite-precision random variables to be understood
by anyone without a knowledge of probability and the use of bit operations
in producing real numbers.  Something usable by the ignorant is unlikely
to do a good job for the enlightened.  A good language should make it easy
for the genius to produce good output; none of them even allow it now.

Optimization is going to be hard to do, and highly machine dependent.  The
presence or absence of a even a single hardware instruction can change the
relative performance of two algorithms by a large factor.  I see no way that
this can be completely left to the machine.

> 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.

The problem is not already solved, and is not impossible.  CL is a clumsy
language, not suited to producing efficient code.  You have seen a point,
that even good use of a construct can only be made if one understands the
construct.  Requiring that they be translated into a clumsy setup cannot
lead to any kind of efficiency.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)