Re: Extending Gcc For a New Language

[Kevin Atkinson <kevina at gnu dot org>]

On Wed, 5 Mar 2003, Robert Dewar wrote:

> > Could you be a bit more specific.  Like what parts of gcc will need to be 
> > extended.  Not that I don't believe you, but a more detailed answer will 
> > give more confidence that gcc is suited for the task.
> 
> There is nothing in your very vague list of features (most of which have
> to do with front end semantics rather than runtime model) that would
> suggest that any extensions to the gcc framework are needed, I agree
> with Mike Stump.

Ask a vague question, get a vague answer, I guess.  In particular I would
like to know if GCC can support the features I list with a trivial front
end extension, or will additional code be needed to support it.  Here is a
my feature list again but with a bit more explanation.

* 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.  For example

  var x = 10;
  ...
  x = 10.25

Will gcc be able to figure out that the type that X needs to be?  What 
about

  int f(int);
  int f(double);

  var x = 10;
  f(x);
  x = 10.25

Will gcc be able to figure out x needs to be a double and will gcc be able 
to call the right f?

* No user written header files, instead the compiler will emit the
necessary information.  When no optimizations are used it will only emit
function prototypes and the like.  When using optimization it will emit
more such as function definitions for functions which are good inlining
candidates.

So gcc will be able to emit header files for object file X which contain
all the prototypes, etc needed to that other parts of the program can use
functions/variables defined in X?  When optimizing Gcc will also be able 
to determine if a function might be able to inline and if so also include 
the function definition in the header file.

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

So given a types

  int (-10 .. 10) i;
  int (-100 .. 100) j;

WIll gcc will be able to flag (i = 20) as an error at compile time?  Will
gcc be smart enough to know that in "for (i = 0; i <= 10; ++i)" it can not
exceed its limit and thus no run-time check is needed or that "j = i" is
safe but "i = j" is not and will need a run-time check.  Or that i /= 2 is
safe but i *= 2 may not be.

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