Re: Augusta: An open source Ada 2012 compiler (someday?)

["Randy Brukardt" <randy@rrsoftware.com>]

"Peter C. Chapin" <PChapin@vtc.vsc.edu> wrote in message 
news:lPmdnasFfvkFwKjO4p2dnAA@giganews.com...
>
> On 03/27/2014 05:51 PM, Niklas Holsti wrote:
>
>> More interesting to me would be work towards making Ada compiler
>> implementation easier. It seems to me that progress in formal methods,
>> functional and declarative languages, and computer power, since the
>> 80's, should make it possible...
>
> One reason why I choose Scala as an implementation language for Augusta is 
> because I wanted to see if I could productively take advantage of Scala's 
> functional features when writing a serious compiler. As much as I like 
> Ada, I don't think Ada is the most wonderful compiler implementation 
> language imaginable.

But of course Ada is the most wonderful language for everything. :-) :-)

Seriously, though, Ada's strengths are in building large long-lived systems, 
and any serious attempt to build an alternative Ada compiler has to plan to 
be a large, long-lived system. Add in the advantages in "eating your own 
dogfood", and it seems like the obvious choice for such a project.

It seems to me that you have other goals, which is of course fine, but it 
does a disservice to hold up something that's not really designed for long 
life as a true alternative system.

> For example Scala's algebraic data types and pattern matching make 
> processing trees quite enjoyable and compilers tend to use a lot of trees. 
> Also Scala has good support for creating what the community calls 
> "internal domain specific languages." See for example Graph for Scala 
> (http://www.scala-graph.org/), a library for manipulating graphs (perhaps 
> control flow graphs?) in a arguably elegant way. Finally, of course, there 
> might be interesting ways to use higher order functions. I won't know 
> until I try.

What's sad (to me) about this is that Ada has added a lot of stuff since Ada 
83 that might be very helpful to implementing an structuring a compiler. But 
all of the existing Ada front-ends originated in Ada 83 and don't use much 
in the way of Ada 95 features much less newer versions. (It simply doesn't 
make sense to rewrite large portions of a compiler's code just because one 
could -- a lot of the time, rewrites don't actually end up any better than 
the code they replaced, just swapping a set of known problems for unknown 
ones.)

For instance, Ada 2012 has tree containers that exist in large part because 
of how common such structures are in compilers and similar applications 
(like XML and HTML). It would be interesting, for instance, to see if an 
expression tree written using a class-wide node type stored in an indefinite 
tree container could be efficient enough to use in a compiler 
implementation. I'd probably at least consider such a structure (which would 
eliminate all storage management from being a concern) rather than a 
access-and-variants that we use. Maybe it wouldn't be better, but it would 
be different.

It also would be nice to predicates, preconditions, null exclusions, and so 
on, all of which can allow errors to be detected earlier and easier. 
(Janus/Ada has many self-checking features, but those all require some work 
on use by the programmers - it would be better to do that just at writing.)

My point is that there is a lot of the possibilities of Ada for compiler 
construction (especially of Ada 2012) that hasn't really been explored.

(I'm dubious that pattern matching has much to do with the construction of a 
compiler front-end, either; that's almost exclusively the provence of 
optimization and code generation, the parts of the compiler you're not 
planning to work on -- even though that's the fun part. :-)

                                      Randy.