Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!think!husc6!cmcl2!stealth.acf.nyu.edu!brnstnd
From: brnstnd@stealth.acf.nyu.edu
Newsgroups: comp.lang.misc
Subject: Re: Anyone want to design a language?
Message-ID: <24349:04:46:47@stealth.acf.nyu.edu>
Date: 22 Feb 90 04:46:48 GMT
References: <4489:05:14:19@stealth.acf.nyu.edu> <14242@lambda.UUCP>
Reply-To: brnstnd@stealth.acf.nyu.edu (Dan Bernstein)
Organization: IR
Lines: 51

In article <14242@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
  [ make syntax line-based ]

I agree! Let's make it column-based, too. And let's reserve a column for
indicating comments. Wow, I think we're onto something here. :-)

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

Comments, yes. Statements, no. The studies you're referring to compared
line-based syntax to Pascal or C, where adding a semicolon after a block
or statement can cause a syntax error or change the meaning of the code.
Such syntactic problems disappear when loops are explicitly terminated.

A study in Computer Languages several years back found that terminated
loops ended up with by far the fewest errors per programmer.

> Ada's control constructs are among the few thing they did well.

Given the lack of any macro facility, they did fine. They would have
done much better to provide a standard method to define new control
structures, then reduced the standard set to three or four with no
special cases.

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

Oh, yeah! In a language with tasks, automatic threading, and message
passing, I've never seen the need for semaphores _AT_ALL_!! C'mon, be
serious.

> It is a good idea for side-effects to be visible.

One solution is declaring ``pure'' functions. A more general solution is
to allow a block to list each outside variable explicitly. This leads to
the idea that the compiler should be able to automatically generate such
lists within the code.

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

You have this hangup with aliasing... :-) I agree that there should at
least be a way to specify that parameters aren't aliased, and to include
that information into the function call syntax. This would take care of
most of the common cases.

---Dan