Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!uwm.edu!zaphod.mps.ohio-state.edu!rpi!uupsi!cmcl2!lanl!lambda!jlg
From: jlg@lambda.UUCP (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: Anyone want to design a language?
Message-ID: <14242@lambda.UUCP>
Date: 20 Feb 90 21:58:01 GMT
References: <4489:05:14:19@stealth.acf.nyu.edu>
Distribution: usa
Lines: 67

From article <4489:05:14:19@stealth.acf.nyu.edu>, by brnstnd@stealth.acf.nyu.edu:
> [...]
> A line-based syntax also feels very dirty: there are exceptions for
> multiple statements on a line, exceptions for single-statement
> structures, etc.

I don't understand what excaptions you are refering to.  If the recognized
statement separater is semicolon, then make the end_of_line character an
alias for semicolon.  Now you have a line-based syntax which is (almost)
identical to the non line-based version you started with.  Productivity
experiments have shown that people work better if the end_of_line is
also the end_of_statement and the end_of_comment marker.  (And, don't
bring up compound statements at this point.  Experiments have also
shown that people work better if flow control is _not_ done with 
so-called compound statements.)

> 8. Eliminate arrays in favor of pointers and macros.
> 
> Say what? You need some way to express the concept of a contiguous
> region of memory. That's what arrays are for. How do pointers cleanly
> express multidimensional arrays? The language should know something
> about arrays, even if just for efficiency.

Hear, hear!!!

> 13. Declarations anywhere.
> 
> Yeah.

I third that motion!  Compilers are multipass these days everywhere.
Why not take advantage of it?

> 14. Control flow statements, control structures: [ various ]
> 
> I have some rather heretical thoughts on this subject. I'll make them
> clear in another message. (Remember that this isn't Ada. Given an
> infinite loop ... endloop, if, and break, you don't need to provide
> a terminating loop as a basic construct. Define it instead as a standard
> macro. Ada's infinite variety of control structures is awful.)

I disagree.  Ada's control constructs are among the few thing they did well.
Furthermore, they aren't all that complicated - they are completely defined
in the last 7 pages of chapter 5 in the Ada standard document (and, _MOST_
of that text is examples).

> [...]
> I agree with C's philosophy of only allowing bit packing inside
> structures. Other packing methods would really mangle the concept of
> pointers.

In languages with recursive data types, direct dynamic memory (like 
ALLOCATABLE in Fortran 90), and type coersion I've never seen the 
need for pointers _AT_ALL_!!  So, rejecting something because it
interferes with pointers is a null issue.

> 20. Parameter passing: [ various ideas ]
> 
> This has to be dealt with very carefully. I like C's solution: it's clean
> while allowing every trick Ada can do. A general principle here (which
> you appear to disagree with) is that the form of a function call can
> make clear the fact that a variable is not modified.

It is a good idea for side-effects to be visible.  On the other hand, it
is also a good idea (an often more important) for aliasing (or the lack
thereof) to be visible.  C's solution is anything but 'clean'.

J. Giles