From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Augusta: An open source Ada 2012 compiler (someday?) Date: Mon, 31 Mar 2014 18:43:28 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <1f0a85a6-ea4d-4d30-8537-0ce9063f992a@googlegroups.com> <89a0ea84-83e2-4693-b2ea-ea9da65bbc73@googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1396309409 18933 69.95.181.76 (31 Mar 2014 23:43:29 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 31 Mar 2014 23:43:29 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:19066 Date: 2014-03-31T18:43:28-05:00 List-Id: "Peter C. Chapin" 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.