Re: gccgo: A gcc frontend for Go, a new programming language

[Basile STARYNKEVITCH <basile at starynkevitch dot net>]

Joe Buck wrote:
> On Wed, Nov 11, 2009 at 11:26:36AM -0800, Basile STARYNKEVITCH wrote:
> > My feeling is that Google's Go (quite a nice language from the slides I just have read) is almost "canonically" the case 
> > for a front-end plugin.
>
> I have some major concerns about this suggestion.  Isn't this a recipe for
> getting people to stop contributing changes to gcc?
>
> You seem to want people to use plugins for everything.  I would prefer to
> see more limited uses.  Plugins are appropriate for small, specialized
> additions to gcc that aren't generally useful enough, or stable enough, to
> include in the main gcc distribution.  For example, a specialized static
> checker, or a pass to add an unusual kind of instrumentation, or something
> to gather statistics on a body of source code.


My intuitions (perhaps wrong) when posting my initial suggestion have been

* Google Go is still a niche language. And I would guess it is targetted to Linux & Unix variants (because I heard that 
Google does not use Windows on their web-crawling servers, but only Unix variants, mostly Linux). I really feel that a 
niche language is exactly a "small,  specialized addition to gcc that isn't generally useful enough, or stable enough, 
to be included in the main gcc distribution". I would be glad to

* Looking at other niche languages in the past having had a GCC front-end (D, Mercury, perhaps some Modula, or Cobol, or 
Pascal, ...) it seems that most of them are not accepted in the GCC trunk proper. As far as I understand, neither 
gcc-4.4 nor the current trunk can be configured to accept D or Mercury (or any else non-mainstream) langauge. So it 
seems that it is *extremely* difficult to have an experimental language accepted inside GCC core. But I admit I might be 
very wrong, because I don't know of all the details. My feeling (perhaps wrong) is that the GCC community don't care 
much about exotic languages (and that is sadly ok for me), only about very mainstream languages. In addition, some 
existing front-ends in GCC does not seem very used (I never met any person using gcj, and I don't know of many Debian 
packages compiled with it). Several FSF blessed language implementations (GNU Smalltalk, GNU Clisp, the future GNU 
Epsilon) are *not* GCC derived implementations.

* The current GCC trunk still lacks a few hooks for other frontend languages as plugins. I really believe that feature 
would be a good thing (notice that LLVM in contrast was initially designed to be a library usable by front-ends, with 
Clang appearing later). Because I am widely guessing that for people experimenting new languages, making a plugin would 
be a bit easier (assuming it is possible) and more importantly, distributing plugin binaries will hopefully be easier 
than distributing GCC variants. Of course, there will be a plugin mess (this is not avoidable).


* GCC branches & experimental variants are so complex that nobody uses them. This includes GCC variants for exotic 
languages. And even a bit used GCC variants (like D) are lagging w.r.t. to GCC core evolution (AFAIK D is only at GCC 
4.2 level).


I can tell it differently: imagine you are an academic (or a researcher at Google or some big corporation) wanting to 
experiment some new language. Today (end of 2009) you better not base your implementation on GCC (better use LLVM, or 
target some existing bytecode like CIL/C# -as F# does-, Java/JVM as Clojure & Scala do, ...- or build your own VM (as in 
Ocaml), or perhaps generate C code for GCC. We might aim to change that, and make easier to make new GCC front-ends. I 
feel that plugins could help here.

I am indeed hoping that in a couple of years, most systems having GCC installed will permit plugins for it.

Of course, we could also not care about GCC supporting strange front-ends.

In addition, plugin extensions required for front-ends will very probably have a lot more success if they are pushed by 
Google people than by random GCC hackers like me.

I do know quite well the Ocaml team, but I won't dare suggesting them to make an Ocaml front-end to GCC. Xavier Leroy 
(the head of Ocaml team at Inria) would rightly laugh at such a suggestion.

Regards.



--
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***