Re: Extending Gcc For a New Language

[Kevin Atkinson <kevina at gnu dot org>]

On Fri, 7 Mar 2003, Fergus Henderson wrote:

> Kevin Atkinson wrote:
> > 
> > For my Ph D I am seriously considering designing a new System Program 
> > language.  Unlike many other new languages, my new language will be 
> > designed to be suitable for low-level programming tasks such as written 
> > kernels and operating systems, It is designed to replace C and C++ 
> > (wishful thinking I know).
> 
> A fair bit of work has been done in this area.
> Have a look at Cyclone, for example:
> <http://www.research.att.com/projects/cyclone/>.
> It sounds like your goals are very similar to the goals of the people
> involved in the Cyclone project, so perhaps you should team up with them!

Well the language has some good ideas, but I am thinking about something 
far more ambitious.  A completely new language that does not inherit any of 
C ugliness.  In particular it will be of a completely different syntax.  I 
want the parser to be able to determine if an identifier is being used as 
a type or a variable, or something else with out having to keep track of 
which identifiers are which.  My language will offer all of C and C++ so a 
trivial rewrite of C and C++ code to my yet to be name language will be 
possible.

Furthermore, I disagree with the basic design philosophy of Cyclone.

1) I am strongly against protecting a user against himself.  I want a 
language that allows users to do dangerous this.  However, at the same 
time, it should not be possible to accentually do something dangerous 
inadvertently like the famous "if (a = b)".  I believe this is generally 
known as the principle of least surprise.

2) When my program does something illegal I *want* it to crash.  When I 
dereference a null pointer I want my program to crash at the point of the 
dereference.  I do not want to waste cycles checking for something that 
the operating system will cache just fine.  A dereference of a null pointer 
generally means an error on my part of a programmer and I want to know 
about it.  If a pointer may be null I will check for it myself.  Catching 
a "null pointer exception" is a rather heavy handed approach to a simple 
if (p == NULL).  Furthermore, catching the exception may also 
unintentionally hide bugs because the exception may be thrown inside a 
function and necessarily my fault.

On the other hand a would prefer out of bounds checks that crash the 
program when a pointer or index goes out of bounds.  But only during the 
debug process.

---
http://kevin.atkinson.dhs.org