Re: Extending Gcc For a New Language

[Kevin Atkinson <kevina at gnu dot org>]

On Wed, 5 Mar 2003, Kevin Atkinson wrote:

Oops.  I forgot the question.

> 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).
> 
> For the implementation I am considering two choices
> 
> 1) Writing the compiler in its own language that emits C (or perhaps 
> C++) code and then uses gcc to compile it.
> 
> 2) Extending Gcc to support the new language.
> 
> Because my language will offer features not currently supported by C or 
> C++ (and probably Java, Ada, and Fortune but I don't know enough about 
> those languages to be sure), it will me more than simply writing a new 
> front end.  

I would like to know what would be involved in extending Gcc to support 
the features, or if it is even possible to do so without a rewrite of a 
significant part of gcc.

> Some of the features the language may offer:
> 
> * Type inference in the style of most functional programming languages, but 
> perhaps a bit more limited.  Generally global variables and function 
> parameters will have the types specified, but the compiler will be 
> expected to infer the types for local variables.
> 
> * No user written header files, instead the compiler will emit the 
> necessary information.  When no optimizations are used it will only emit 
> function phototypes and the like.  When using optimization it will emit 
> more such as function definitions for functions which are good inlining 
> candidates.
> 
> * An optional garbage collector.  When active the collector will only be 
> used for some objects, AND the user will be allowed to free objects 
> explicitly. (I know has support for garbage collection but I don't know 
> how powerful it is and if it can handle objects being freed by the user)
> 
> * Very precise typing of objects.  Types can be limited by arbitrary 
> boolean expressions such as limiting an integer to a particular range.  If 
> the compiler can not verify the conditions at compile time it is expected 
> to be able to optionally emit code to check for it at runtime.
> 
> I think that should cover it for now.  I will be about a year before I 
> give any serious thought into my new language.  So don't expect to much 
> specific information.
> 
> 

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