[cfe-dev] [GSoC 2014] Project RFC

[Gavin Howard]

     All,
     My name is Gavin Howard, and I am a student at BYU. I'm hoping to
apply for GSoC 2014 to write a frontend for LLVM. The frontend would be for
a language I have designed called LFyre. I have a website at
http://lfyre.com/ and a development blog at http://lfyre.blogspot.com/. I
have attached an RFC with details about the project, and I would appreciate
any comments. Thanks.
     God Bless,
     Gavin Howard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140311/5960283f/attachment.html>
-------------- next part --------------
LFyre Frontend for LLVM
=======================

Introduction
------------
My name is Gavin Howard, and I am a student at BYU. I'm hoping to apply for GSoC
2014 to write a frontend for LLVM. The frontend would be for a language I have
designed called LFyre. I have a website at http://lfyre.com/ and a development
blog at http://lfyre.blogspot.com/.

History
-------
I started working on ideas for LFyre from the moment I had my first seg fault as
I was learning how to program in C and C++. I was sure there was a better way. I
had started as a Java programmer, so I was used to garbage collection, but I did
NOT like it. I actually liked C, and C++ less so, but in my mind, it was really
inexcusable that we are still manually managing memory.

Some months later, I came across a dead project name lfyre on SourceForge, and I
asked the owner if I could resurrect it. He gave his permission, and I took over
in December 2012.

Since that time, I have been reading, researching, and learning about languages
and language design. Like all would-be language designers, I wanted LFyre to be
my "dream" language, but I also knew that I wasn't smart enough to know what I
really wanted. So I spent over a year figuring it out.

At this point, LFyre is basically fully designed. I've already written a working
lexer. It's time for me to get LFyre working.

That's where LLVM comes in. My plan was to build the compiler from scratch, and
the biggest reason was that LFyre has custom needs for its linker. A few days
ago, I was on the #llvm IRC channel, and one of the users told me it's possible
to even extend the linker.

Questions
---------
There are some questions I need to answer.

*** Question 1: How would LLVM benefit? ***

Of course, there is the standard answer that another frontend could bring more
developers and users to LLVM. But aside from that...

Like I said, LFyre has custom linker needs, mostly based on resolving collisions
between compiler-generated metadata. LFyre programs have access, at runtime, to
ALL of the data generated by a compiler at compile-time. The linker would need
to make sure that each bit of data would be unique. By having an LLVM frontend,
I will be writing a pass for the linker that could then, if accepted, be applied
to lld.

Really, I don't expect that I will simply be writing an IR generator. If there's
something I could add to LLVM to make things easier for me, but would also be
beneficial for the project as a whole, I would definitely do it (with approval,
of course). And while such extensions can't be predicted, they've happened in
the past, such as "cc 10" for GHC and "cc 11" for HiPE.

In other words, I fully intend to become acquainted with LLVM's internals and
become a regular contributor. Writing a frontend would be a nice way for me to
do that without having to learn the entire LLVM infrastructure all at once (and
ask endless questions that would drive any mentor crazy).

So in short, the benefits to LLVM are:
1.  A mentoring period for a new contributor.
2.  A new frontend, with all of the implied benefits.
3.  New capabilities in LLVM, if LFyre requires them.

*** Question 2: Why would anyone need a new language? ***

This question is tough to answer. The honest answer is that in reality, no one
needs a new language. Sure, we may WANT better languages, but we don't NEED any.

With that said, I'm going to answer another question: how would LFyre benefit
software developers in general?

Again, that question is hard to answer, mostly because it is subjective. And I'm
biased.

But I didn't just throw together a random conglomeration of ideas. I did a lot
of reading on the Internet. I read opinions, articles, blogs, white papers, and
everything inbetween, trying to get a picture of what software developers want.

The result is elegant, easy, and powerful. LFyre has the power of C and Lisp's
extensibility, combined into a clean and unambiguous Pythonic syntax.

Today, if you need something to interface with hardware, you usually write in C
and C++, and you would suffer through the inevitable memory bugs. Once LFyre is
a viable language, you'd have a language with the power of C mixed with complete
safety.

Today, if you want an extensible language, you write in Lisp, and its lack of
syntax is SO hard to learn. LFyre is just as extensible, but it's readable, too.

Today, if you want to write generic type-safe containers, you use C++ templates.
Now, templates are not that bad, except that they generate a lot of code. LFyre
doesn't have templates, but it has the same ability, using reflection. I wrote
about it at http://lfyre.blogspot.com/2014/01/the-great-template-debate.html.
The advantage is that LFyre does not have to instantiate different code for each
use of the template.

As expected, I could go on and on.

I must admit that these opinions are quite biased; I've spent a lot of time on
this language, and I want to believe that it was designed well. You'll have to
judge for yourself. If you want more information, that's great; I've documented
the whole process on my blog (see link above).

So in short, we don't NEED a language, but I've made this language as well as I
could, so who knows? It might actually be a big help to future programmers. You
will have to be the judge on that.

*** Question 3: What about after GSoC? ***

Okay, I have a little explanation to do here.

First of all, I do want to bootstrap the lexer and parser back into LFyre. Both
would make wonderful additions to LFyre's standard library, so yes, I intend to
rewrite them both.

LFyre is currently licensed under the Apache License V2.

I mention both of those points because I don't want any confusion. LFyre's lexer
and parser will be very much a part of The LFyre Project. Plus, LLVM's langauge
of choice is C++ and C. But I've noticed that there are a few frontends written
in another language, such as the Scheme compiler which is written in Scheme.

Writing in LFyre itself has the advantages of "eating my own dog food." It will
make it much easier to find design flaws in the language and correct them.

If that is a problem, then this may not be a very good project to sponsor.

With all of that said, I intend to make this the first full LFyre compiler. If
LLVM does have what I need, or is as extensible as I've been told, I can't see
any reason not to make LLVM the official LFyre compiler.

And because it will be the official compiler, I will continue to maintain and
improve it after GSoC. I've stuck with the project this long; I'm not going to
abandon it now, nor after GSoC.

Last Thoughts
-------------
If the jury decides that an LFyre frontend would not be a good GSoC project, I'm
okay with that, but I'd still like to do a project. The one I have my eye on is
the Universal Driver listed on the Clang Open Projects page. I will be building
a toolchain of my own, and quite frankly, writing toolchains sound a lot more
fun than other types of software.