brnstnd@stealth.acf.nyu.edu (02/22/90)
The working name for this language is hereby Q. Here's the start of a list of Q design goals, in no particular order. If I'm going to put my foot down on anything, I'll start with these. Follow up in this thread only to comment on design issues. If you want to criticize on religious grounds, move to alt.religion.computers: we want to design a language, not justify its existence. Portability: It is easy to write Q programs that run on many different platforms with few changes. Efficiency: Q compiles naturally to efficient code. Q can do most of what the computer can with a minimum of fuss. Efficiency takes back seat to portability by default; only in a small and thoroughly considered set of cases is portability sacrificed to efficiency. Compilability: Q is easy to compile and optimize. There are various ways (perhaps, e.g., assertions, antialiasing) for the programmer to both aid coding and maintenance and to help the compiler. Interoperability: If the OS supports it, Q can be linked with existing code from similar languages, without any special effort. (This is very important under UNIX.) Readability: Any code can be written without much fuss in a form that the average programmer can read. It takes at least a bit of effort to write obfuscated code. Flexibility: Q works for a wide variety of applications. (Ada's mistake is achieving flexibility at the expense of simplicity, cleanliness, efficiency, etc.) Simplicity: Whenever two constructions are merely syntactic manglings of each other, only the simpler one is part of the basic Q language, except in particular well-discussed cases where both constructions are natural. This implies a (smart) preprocessor. It's also the most important way in which Ada fails. Reliability: This includes a lot of different items. Cleanliness: Q isn't just a compendium of hacks. It's a sensible, straightforward language. Special cases are rare. Scale: Q supports the features needed for large programs: some form of modules, logical and physical information hiding and data abstraction, and so on. (One of C's major faults is that physical information hiding is the only straightforward way to achieve logical information hiding. ``Straightforward'' basically means without defeating type checking.) 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. Implementation Quality: Q compilers must do more than just compiling. For example, a compiler that provides extensions must have a way to turn them off. The particular quality-of-implementation requirements or suggestions aren't as important as the idea that they're part of a language. Likability: Q is easy to like. ---Dan
gateley@m2.csc.ti.com (John Gateley) (02/24/90)
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.comlgm@cbnewsc.ATT.COM (lawrence.g.mayka) (02/24/90)
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: ><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. ANSI Common Lisp indeed attacks the problem of optimizing new constructs via *compiler macros.* These are macros applicable only during compilation. A compiler macro may have the same name as a function. Indeed, that is (apparently) its intended role: to optimize at compile time what would otherwise be an ordinary function call. A compiler macro, like any macro, has access to its original, unevaluated, unexpanded, source-code arguments and can perform "smart" optimizations (or other transformations) on them as desired. ANSI Common Lisp also defines constructs for: - Obtaining information (about variables, functions, and declarations) from a lexical environment. - Augmenting a lexical environment with additional such information. - Enclosing a function in an environment. - Defining a handler for a declaration. I don't know of any specific language extensions designed using all these facilities yet, though. Lawrence G. Mayka AT&T Bell Laboratories lgm@ihlpf.att.com Standard disclaimer.
cik@l.cc.purdue.edu (Herman Rubin) (02/27/90)
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)
gateley@m2.csc.ti.com (John Gateley) (02/28/90)
In article <1970@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
<...
<CL is a clumsy
<language, not suited to producing efficient code.
<...
"Clumsy" is a clumsy word to use here :^). Not everybody wants or
needs ultra-optimized code. CL, and other dialects of Lisp like Scheme,
are NOT clumsy in too many other ways for me to do justice to here.
John
gateley@m2.csc.ti.com