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

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

[Peter Chapin]

In another thread Shark8 posted a proposal to build an IDE+compiler for
Ada 2012. In his post he notes that having a second open source compiler
offering (besides GNAT) for Ada would be good for the Ada community.

I agree.

GNAT is a fine product but it would enrich the eco-system if there were
alternatives. Accordingly I started a pet project for myself to build an
Ada 2012 compiler from the ground up which I'm calling "Augusta." The
project is here:

    https://github.com/pchapin/augusta

I am not as naive as I probably sound. I fully understand that such a
project is massive and not likely to actually ever be completed.
Fortunately that's not important to me. The project is just a hobby
project and its *real* purpose is to provide me with a source of
entertainment in my off hours. It can fulfill that role perfectly well
even if it never amounts to anything. This situation also frees me to
make design choices that interest me without feeling the need to justify
them rationally. For example Augusta will be written in Scala and will
target LLVM. I choose these technologies because I like them and I'd
like to learn more about them, not because I think they are somehow the
"best" or most logical choices.

I have been planning to announce Augusta's existence to the community at
some point but right now the project is 99% talk and 1% action (at most)
and I had thought to wait until the balance was a little different.
However, Shark8's announcement of his IDE proposal made this seem like a
reasonable time. I support his desire to develop such tools and who
knows... perhaps Augusta can play some role in his project someday.

Right now Augusta is little more than a place holder with some documents
outlining my vision for the project. I have set a release date for
myself of December 31, 2020 in an effort to apply some structure to my
work. My hope is to have something "interesting" done by that time...
although I'm not going to claim it will be full Ada 2012.

In the meantime I've been using Augusta as a source of class examples
and student exercises in a compiler course I'm teaching at Vermont
Technical College. The work there has been in a sub-project called
Allegra which is intended to be a compiler for a series of highly
reduced Ada subsets with increasing complexity. In addition to
supporting my course, my thought was to use Allegra as a kind of
experimentation space for the technologies that will ultimately be part
of Augusta. However, I'm not clear how much, if any, of the methods used
in Allegra would actually transfer to the more complex Augusta project
itself.

Anyway, enough said... I invite anyone who is interested to browse
around in the project. Let me know if you have any questions or comments.

Peter

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

[Tero Koskinen]

19.3.2014 15:24, Peter Chapin wrote:
> Accordingly I started a pet project for myself to build an Ada 2012
> compiler from the ground up which I'm calling "Augusta."
...
> The project is just a hobby project and its *real* purpose is to
> provide me with a source of entertainment in my off hours.
...
> For example Augusta will be written in Scala and will target LLVM.

Me too! (Started to write a compiler as a hobby.)

Except that I selected Clojure instead of Scala, the compiler
backend is totally custom and the frontend language isn't Ada,
but instead very simple procedural language with some of the
keywords and syntax borrowed from Ada [1].

Thanks to having a language built on top of JVM and therefore
able to use Java tools easily, I have also built parser with
Antlr 4 [2].

Combined with Antlr 4 these new "JVM languages" are quite good
for prototyping various areas of compiler design. You get
results quick enough that you don't get bored. As a downside,
(with Clojure) the code is unmaintainable mess of parenthesis:
(letfn [(has-i [i s] (some (fn [x] (= (last x) i)) s))
(find-first [pred coll] (first (filter pred coll)))] ...)
[3]


What comes to Ada compilers,
it is nice to always see someone to start a new open source
Ada compiler to "compete" with GNAT (or just for hobby), however
in the history all of the earlier attempts have sadly failed.
Open source Ada community might be too small and diverse for
such a project.

One alternative approach could be to persuade one of
the existing Ada vendors to open source their compiler;
perhaps even create a (kickstarter) project to collect
the money required for it. (Like it was done for Blender.[4])


> Peter

Yours,
  Tero


[1] Example program at
https://bitbucket.org/tkoskine/antlr-ir/src/2fb34374ea8ded16ae6cc7769d7ce5536f65193f/examples/main.ir?at=default
[2]
https://bitbucket.org/tkoskine/antlr-ir/src/2fb34374ea8ded16ae6cc7769d7ce5536f65193f/IR.g4?at=default
[3]
https://bitbucket.org/tkoskine/antlr-ir/src/2fb34374ea8ded16ae6cc7769d7ce5536f65193f/src/ir/gen_amd64.clj?at=default#cl-467
[4] https://en.wikipedia.org/wiki/Blender_%28software%29#History

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

[Peter Chapin]

On 2014-03-19 14:56, Tero Koskinen wrote:

> Me too! (Started to write a compiler as a hobby.)

It's definitely an interesting area to tinker with.

> Combined with Antlr 4 these new "JVM languages" are quite good
> for prototyping various areas of compiler design. You get
> results quick enough that you don't get bored.

Yes, for small languages they do work well. How well such an approach
scales to a full sized language (of any sort) is much less clear. I am
also curious about the extent to which the functional paradigm can be
used to simplify(?) compiler implementation. Scala, like many functional
languages has nice pattern matching features that seem to be useful but
that is just a small matter in the grand scheme of functional programming.

> What comes to Ada compilers,
> it is nice to always see someone to start a new open source
> Ada compiler to "compete" with GNAT (or just for hobby), however
> in the history all of the earlier attempts have sadly failed.

It is easy to understand why. I intend to work around this issue by just
redefining "success." Of course my definition might not be very
interesting to most people... but that's fine.

Peter

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

[Brian Drummond]

On Wed, 19 Mar 2014 09:24:36 -0400, Peter Chapin wrote:

> In another thread Shark8 posted a proposal to build an IDE+compiler for
> Ada 2012. In his post he notes that having a second open source compiler
> offering (besides GNAT) for Ada would be good for the Ada community.
> 
> I agree.
> 
> GNAT is a fine product but it would enrich the eco-system if there were
> alternatives. Accordingly I started a pet project for myself to build an
> Ada 2012 compiler from the ground up which I'm calling "Augusta." The
> project is here:
> 
>     https://github.com/pchapin/augusta

Good luck!

> For example Augusta will be written in Scala and will
> target LLVM. I choose these technologies because I like them and I'd
> like to learn more about them, not because I think they are somehow the
> "best" or most logical choices.

LLVM appears to have problems supporting nested (locally declared) 
subprograms. This appears to be behind slow progress on the Dragonlace 
project, to use Gnat as an LLVM front end.

Tristan Gingold has recently added an experimental LLVM interface to GHDL 
(a VHDL compiler; I strongly believe Ada and VHDL users should talk to 
each other more than they do!) and he also ran into this.

As VHDL makes heavy use of parallel processes, he indicated he would re-
use his implementation of processes- essentially closures - to support 
local subprograms. I don't know the details of how he does this.

(The other advantage of gcc as a backend is that it opens up many more 
target processors. It would be nice to be able to support both, and the 
code required in ghdl to support both is really not very much)

- Brian

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

[Peter Chapin]

On 2014-03-19 19:04, Brian Drummond wrote:

> LLVM appears to have problems supporting nested (locally declared) 
> subprograms. This appears to be behind slow progress on the Dragonlace 
> project, to use Gnat as an LLVM front end.

Thanks for the heads up... I'll have to keep that in mind. One advantage
of having a project that is 99% talk and only 1% action is that I'm not
deeply committed to a particular back-end technology yet. I do know that
I don't want to deal with all the low level code generation stuff, however.

> Tristan Gingold has recently added an experimental LLVM interface to GHDL 
> (a VHDL compiler; I strongly believe Ada and VHDL users should talk to 
> each other more than they do!) and he also ran into this.

I tend to agree about the VHDL/Ada connection.

> As VHDL makes heavy use of parallel processes, he indicated he would re-
> use his implementation of processes- essentially closures - to support 
> local subprograms. I don't know the details of how he does this.

Scala supports nested functions on the JVM. It does this, I believe, by
creating closures in some way. I'm not sure of the details right now but
it sounds like a technique that is "well known" in some circles.

Peter

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

[Brian Drummond]

On Wed, 19 Mar 2014 19:24:13 -0400, Peter Chapin wrote:

> On 2014-03-19 19:04, Brian Drummond wrote:
> 
>> LLVM appears to have problems supporting nested (locally declared)
>> subprograms. This appears to be behind slow progress on the Dragonlace
>> project, to use Gnat as an LLVM front end.
> 
> Thanks for the heads up... I'll have to keep that in mind. One advantage
> of having a project that is 99% talk and only 1% action is that I'm not
> deeply committed to a particular back-end technology yet. I do know that
> I don't want to deal with all the low level code generation stuff,
> however.

GHDL has a level called "ortho", pretty much an intermediate language 
representing the syntax tree, with three backend translators : 

to gcc (gimple) code, whence gcc provides all the optimisation passes, 
and the low level code generation to (potentially) any of its backend 
targets; 

to llvm (experimentally in the current trunk) - I haven't tried this yet.

to "mcode" - ghdl's own JIT compiler (x386 only so far). Astonishingly 
(to me anyway) I benchmarked this JIT version - which is tiny as 
compilers go, under 0.8MB source - the executable was only 20% slower 
than gcc -O2. Now I might just have been lucky (or unlucky!) on the 
testcase I picked, but I was expecting a naive translator to be quite a 
bit slower than gcc...

The interfaces from "ortho" to gcc and llvm are 100kbytes and 250kbytes 
of source; mostly Ada, naturally. (the gcc interface includes ONE C file. 
Guess where most of the problems are... :-) I see the LLVM interface also 
has one C++ file; and it is much smaller...

https://sourceforge.net/projects/ghdl-updates/

May be worth some investigation as an approach to retain portability 
between back-ends. 

(There is also a mode where "ortho" can be saved, inspected, and later 
passed to the gcc backend, to simplify working on the compiler).

My own dreams of an independent Ada compiler involve using this 
intermediate level as a proven piece of the puzzle.

>> (I strongly believe Ada and VHDL users should
>> talk to each other more than they do!) and he also ran into this.
> 
> I tend to agree about the VHDL/Ada connection.

Even just because of VHDL's relative popularity in the FPGA world; there 
are 2 StackExchange questions tagged "vhdl" for every question tagged 
"ada". And yet not many VHDL users realise there's an equally good or 
better language for the software aspects of their design.

-- Brian

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

[Lucretia]

On Wednesday, 19 March 2014 13:24:36 UTC, Peter Chapin  wrote:
> In another thread Shark8 posted a proposal to build an IDE+compiler for
> Ada 2012. In his post he notes that having a second open source compiler
> offering (besides GNAT) for Ada would be good for the Ada community.

It is, but the way he is considering it seems to hark back to the olden days of Ada compilers.

> I agree.
>
> GNAT is a fine product but it would enrich the eco-system if there were
> alternatives. Accordingly I started a pet project for myself to build an
> Ada 2012 compiler from the ground up which I'm calling "Augusta." The
> project is here:
>
>     https://github.com/pchapin/augusta

A couple of months ago I was searching the net for other Ada compilers, subsets mainly. Only ones I found were either Ada 83 (original ones) or the Ada-ish (not really a subset) from the Crafting a compiler in C book. I was searching as I was planning to build a subset of Ada 2012 (in Ada 2012 using GNAT). I actually started the code today before I heard about these two threads.

> I am not as naive as I probably sound. I fully understand that such a
> project is massive and not likely to actually ever be completed.

As long as you don't expect all the annexes, I don't see why not.

> In the meantime I've been using Augusta as a source of class examples
> and student exercises in a compiler course I'm teaching at Vermont
> Technical College. The work there has been in a sub-project called

Do you have a website with the course materials at all? Always worth a look. Why don't you set up your compiler as a means for students to add to, i.e. add floating point support, add real-time annex, etc. That would get your compiler off the ground faster and might even take less than 6 years to complete.

> Allegra which is intended to be a compiler for a series of highly

You might want to change the name as there is a project with that name already, see #Ada on Freenode.

> reduced Ada subsets with increasing complexity. In addition to

This is surely what pragma Profile and pragma Restriction are for, this is the basis of my compiler.

> Anyway, enough said... I invite anyone who is interested to browse
> around in the project. Let me know if you have any questions or comments.

Ok.

Luke.

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

[J-P. Rosen]

Le 20/03/2014 11:23, Lucretia a écrit :
>> I am not as naive as I probably sound. I fully understand that such a
>> > project is massive and not likely to actually ever be completed.
> As long as you don't expect all the annexes, I don't see why not.
> 
All those who have been involved in an Ada compiler will tell you that
it is a lot more difficult than it appears, unless you stick to the
Pascal subset and don't care for validation.

In the early days of Ada, we have seen compilers announcing proudly that
they passed 95% of the validation and that delivery was expected in a
few weeks - they never succeeded to pass the remaining 5%.

For example, and as a test, make sure you are able to understand the
implications of 4.3.3 (a nightmare for code generation), or 13.14, or
3.10.2(3/2)...

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

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

[Shark8]

On 19-Mar-14 06:24, Peter Chapin wrote:
> I have been planning to announce Augusta's existence to the community at
> some point but right now the project is 99% talk and 1% action (at most)
> and I had thought to wait until the balance was a little different.
> However, Shark8's announcement of his IDE proposal made this seem like a
> reasonable time. I support his desire to develop such tools and who
> knows... perhaps Augusta can play some role in his project someday.

I'm glad that it gave you a bit of motivation to announce your project. :)

It would be nifty if our two projects could "play nice" together; I 
wasn't considering making the translator proper a plugin, but maybe that 
sort of route would be beneficial -- it definitely bears thinking about.

> I am not as naive as I probably sound. I fully understand that such a
> project is massive and not likely to actually ever be completed.
> Fortunately that's not important to me. The project is just a hobby
> project and its *real* purpose is to provide me with a source of
> entertainment in my off hours. It can fulfill that role perfectly well
> even if it never amounts to anything.

Sometimes those are the best projects -- of course I might be a bit 
biased. (*Insert sidelong glance at the dozen or so projects that are in 
various states of [in]completion.*)

> This situation also frees me to
> make design choices that interest me without feeling the need to justify
> them rationally. For example Augusta will be written in Scala and will
> target LLVM. I choose these technologies because I like them and I'd
> like to learn more about them, not because I think they are somehow the
> "best" or most logical choices.

Nice.
I have Haskell on my "next to learn" list, and I think Scala is on there 
too... from what I've heard/read about them they seem like interesting 
programming languages.

> Right now Augusta is little more than a place holder with some documents
> outlining my vision for the project. I have set a release date for
> myself of December 31, 2020 in an effort to apply some structure to my
> work. My hope is to have something "interesting" done by that time...
> although I'm not going to claim it will be full Ada 2012.

2020 is better than the "someday" I have on a lot of my projects -- my 
OS project springs to mind instantly. (Though a lot of my unfinished 
projects could be seen as 'subprojects' under the OS-project.)

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

[Shark8]

On 19-Mar-14 11:56, Tero Koskinen wrote:
> One alternative approach could be to persuade one of
> the existing Ada vendors to open source their compiler;
> perhaps even create a (kickstarter) project to collect
> the money required for it. (Like it was done for Blender.[4])

Hm, anyone want to buy the rights to Rational from Atego and modernize 
the R1000? ;)

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

[Qun-Ying]

There is another Ada compiler project, and it seems not developed anymore.

http://gela.ada-ru.org/
http://forge.ada-ru.org/gela/wiki

It is based on the TenDRA compiler.

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

[Shark8]

On 19-Mar-14 16:04, Brian Drummond wrote:
> I strongly believe Ada and VHDL users should talk to
> each other more than they do!

Isn't that because VHDL is essentially concerned about hardware and 
[most] programmers are essentially worried about software? -- That said, 
would if be possible/feasible to have a compiler that takes a VHDL 
description of some architecture and Ada source and compile it to run on 
that architecture?

I'm certainly no expert on VHDL, all I really know about it is from 
Wikipedia, but a quick search reveals several PDFs that indicate my 
understanding is not entirely wrong and that this might be possible 
(though 'feasible' and 'desirable' are distinct attributes):

How to design your own CPU on FPGAs with VHDL
http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCgQFjAA&url=http%3A%2F%2Fopencores.org%2Fusercontent%2Cdoc%2C1262702554&ei=VyIrU7yTCZLiqAHs2IHQAw&usg=AFQjCNEN_M7VC32q01YXXOF_VU7lF-Ohbw&sig2=FVTaWxQqZ7d-FpVwMzXnOA&bvm=bv.62922401,d.aWM

Processor Implementation in VHDL
http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=0CDQQFjAC&url=http%3A%2F%2Fpeople.tamu.edu%2F~akshitdayal%2F468%2FMIPS-Implementation.pdf&ei=VyIrU7yTCZLiqAHs2IHQAw&usg=AFQjCNEjFFTyaFtik_fnHvxX-qUzL3xotw&sig2=_W3m4sd-Yj5CptA50GdUqw&bvm=bv.62922401,d.aWM

CPU Project
http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=0CDsQFjAD&url=http%3A%2F%2Fweb.cecs.pdx.edu%2F~mperkows%2FCLASS_VHDL_99%2Fcpu_project.pdf&ei=VyIrU7yTCZLiqAHs2IHQAw&usg=AFQjCNEupGSBWrUUFEayGWjm6xKtyaeKAQ&sig2=Plj713lv0vUcXuONu8HcKw&bvm=bv.62922401,d.aWM

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

[Shark8]

On 20-Mar-14 03:23, Lucretia wrote:
> On Wednesday, 19 March 2014 13:24:36 UTC, Peter Chapin  wrote:
>> In another thread Shark8 posted a proposal to build an IDE+compiler for
>> Ada 2012. In his post he notes that having a second open source compiler
>> offering (besides GNAT) for Ada would be good for the Ada community.
>
> It is, but the way he is considering it seems to hark back to the olden days of Ada compilers.

True; I can see the merits in Ada 83's Library, and how that could be 
extended/expanded.

Just because something is older than another doesn't mean it's worse: as 
an example consider LISP and PHP, LISP is far older (`58) than PHP 
(`95), and LISP is far better for building any real system in... but PHP 
markets itself as "easy to use" (and that's both [trivially] true, and 
completely false [when you consider all the things you have to manually 
do to ensure a robust/correct application]).

>> I agree.
>>
>> GNAT is a fine product but it would enrich the eco-system if there were
>> alternatives. Accordingly I started a pet project for myself to build an
>> Ada 2012 compiler from the ground up which I'm calling "Augusta." The
>> project is here:
>>
>>      https://github.com/pchapin/augusta
>
> A couple of months ago I was searching the net for other Ada compilers,
> subsets mainly. Only ones I found were either Ada 83 (original ones) or
> the Ada-ish (not really a subset) from the Crafting a compiler in C book.
> I was searching as I was planning to build a subset of Ada 2012 (in
> Ada 2012 using GNAT). I actually started the code today before I heard
> about these two threads.

I look forward to seeing it; I'm sure there are others here, too.

>> I am not as naive as I probably sound. I fully understand that such a
>> project is massive and not likely to actually ever be completed.
>
> As long as you don't expect all the annexes, I don't see why not.

I don't expect them, I demand them! (Unfortunately my demands will not 
be met.) ;)

>> In the meantime I've been using Augusta as a source of class examples
>> and student exercises in a compiler course I'm teaching at Vermont
>> Technical College. The work there has been in a sub-project called
>
> Do you have a website with the course materials at all? Always worth a
> look. Why don't you set up your compiler as a means for students to add
> to, i.e. add floating point support, add real-time annex, etc. That
> would get your compiler off the ground faster and might even take less
> than 6 years to complete.

IOW, co-opt them into helping your own goals along; I approve.
(It also fits with Randy's "Eat your own dogfood.")

>> Allegra which is intended to be a compiler for a series of highly
>
> You might want to change the name as there is a project with that
> name already, see #Ada on Freenode.

Sometimes naming is the hard part... what's worse, though, is when the 
name is "the same, but different". (e.g. “NEXTSTEP”, “NextStep”, 
“NeXTstep”, “NeXTStep”, and “NeXTSTEP”.)

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

[erlo]

On 03/20/2014 07:13 PM, Shark8 wrote:
> On 19-Mar-14 11:56, Tero Koskinen wrote:
>> One alternative approach could be to persuade one of
>> the existing Ada vendors to open source their compiler;
>> perhaps even create a (kickstarter) project to collect
>> the money required for it. (Like it was done for Blender.[4])
> 
> Hm, anyone want to buy the rights to Rational from Atego and modernize
> the R1000? ;)

IBM bought Rational at some point in time, did they sell it? I know that
the company I work for got more than one R1000 through IBM.

Erlo

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

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]

"J-P. Rosen" <rosen@adalog.fr> wrote in message 
news:lgeh3m$gqq$1@dont-email.me...
> Le 20/03/2014 11:23, Lucretia a écrit :
>>> I am not as naive as I probably sound. I fully understand that such a
>>> > project is massive and not likely to actually ever be completed.
>> As long as you don't expect all the annexes, I don't see why not.
>>
> All those who have been involved in an Ada compiler will tell you that
> it is a lot more difficult than it appears, unless you stick to the
> Pascal subset and don't care for validation.
>
> In the early days of Ada, we have seen compilers announcing proudly that
> they passed 95% of the validation and that delivery was expected in a
> few weeks - they never succeeded to pass the remaining 5%.
>
> For example, and as a test, make sure you are able to understand the
> implications of 4.3.3 (a nightmare for code generation), or 13.14, or
> 3.10.2(3/2)...

Heck, we (the ARG) aren't quite sure how you implement accessibility checks 
for Ada 2005 and Ada 2012 (see AI12-0016-1 for some thinking); you could 
waste a lot of time trying to figure that out. And like J-P says, a 95% 
solution isn't good for much -- the real solution is 95% different. :-)

It's for good reason that 3.10.2 is informally named "The Heart of 
Darkness"! ;-)

                              Randy.

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

[Randy Brukardt]

"erlo" <erlo@valid.not> wrote in message news:lgfqqn$jp2$1@dont-email.me...
> On 03/20/2014 07:13 PM, Shark8 wrote:
...
>> Hm, anyone want to buy the rights to Rational from Atego and modernize
>> the R1000? ;)
>
> IBM bought Rational at some point in time, did they sell it? I know that
> the company I work for got more than one R1000 through IBM.

They sold just the Rational Ada compiler to Atego in July 2012. (IBM didn't 
buy Rational for Ada, that's for sure!) You can find the announcement 
through the AdaIC's press page for Atego: 
http://www.adaic.org/company/atego/

                               Randy.

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

[Brian Drummond]

On Thu, 20 Mar 2014 11:35:37 -0700, Shark8 wrote:

> On 19-Mar-14 16:04, Brian Drummond wrote:
>> I strongly believe Ada and VHDL users should talk to each other more
>> than they do!
> 
> Isn't that because VHDL is essentially concerned about hardware and
> [most] programmers are essentially worried about software? 

These days most hardware designers worry about software too. For testing 
and verification, but also much hardware requires software in the form of 
drivers, API, applications, or contains its own CPU and requires embedded 
SW.

Add in the need to verify DSP algorithms, and hardware designers would 
love to see a language that natively supported fixed-point arithmetic.

instead, SystemC adds C++ classes to support user-specified datatypes 
including fixed point and is becoming popular...

There is also the move towards "high level synthesis" that can take code 
developed in a "high level language" meaning some dialect of C (or 
SystemC) and synthesise to hardware, bringing all the benefits of C to 
hardware design.

(now why do I find this depressing?)

>-- That said,
> would if be possible/feasible to have a compiler that takes a VHDL
> description of some architecture and Ada source and compile it to run on
> that architecture?

Not at all easy. An instruction set description of some architecture 
would be much easier - and allow a compiler to target any CPU for which 
such a description can be written.

I am more interested in the synergies between Ada and VHDL as languages. 
For example : 
A decent subset of Ada is nearly identical to VHDL, allowing users to 
switch between them quite painlessly.

The ability to model floating and fixed point and compare accuracy is 
very useful (VHDL doesn't natively support fixed point, but having a 
proven model to port to the fixed point libraries would be very useful)

Despite the long time use of formal tools (eg static timing analysis) in 
HW design, Ada is ahead in formal tools for correctness (SPARK et al)

The Spark restrictions on Ada share quite a lot with the restrictions 
inherent in the synthesisable subset of VHDL. 

High level synthesis techniques developed for other languages should be 
equally applicable to Ada and VHDL.

The only HLS work I know about for Ada is the York Hardware Ada Compiler

http://www.cs.york.ac.uk/ftpdir/reports/2005/YCST/09/YCST-2005-09.pdf

which is an interesting paper, but slightly undermined by the fact that 
the subset of Ada (at least in the published example) is essentially 
synthesisable VHDL!

- Brian

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

[J Kimball]

On 03/20/2014 06:15 PM, Randy Brukardt wrote:
> "J-P. Rosen" <rosen@adalog.fr> wrote in message
> news:lgeh3m$gqq$1@dont-email.me...
>> Le 20/03/2014 11:23, Lucretia a écrit :
>>>> I am not as naive as I probably sound. I fully understand that such a
>>>>> project is massive and not likely to actually ever be completed.
>>> As long as you don't expect all the annexes, I don't see why not.
>>>
>> All those who have been involved in an Ada compiler will tell you that
>> it is a lot more difficult than it appears, unless you stick to the
>> Pascal subset and don't care for validation.
>>
>> In the early days of Ada, we have seen compilers announcing proudly that
>> they passed 95% of the validation and that delivery was expected in a
>> few weeks - they never succeeded to pass the remaining 5%.
>>
>> For example, and as a test, make sure you are able to understand the
>> implications of 4.3.3 (a nightmare for code generation), or 13.14, or
>> 3.10.2(3/2)...
>
> Heck, we (the ARG) aren't quite sure how you implement accessibility checks
> for Ada 2005 and Ada 2012 (see AI12-0016-1 for some thinking); you could
> waste a lot of time trying to figure that out. And like J-P says, a 95%
> solution isn't good for much -- the real solution is 95% different. :-)
>
> It's for good reason that 3.10.2 is informally named "The Heart of
> Darkness"! ;-)
>
>                                Randy.
>
>

You are listening to what you're saying aren't you? I know we joke about things when we're uncomfortable with them. The people writing the rules don't know how to enforce them? There's an actual part of the manual that has a nick name "The Heart of Darkness!". Your own compiler can't even compete because of the labyrinth of rules.

Ada has become the American tax code. It's becoming abundantly clear that there has to be a massive break in backward compatibility in the next revision of the language that makes writing compilers easier, not just keeping AdaCore in business, but breaking out of the framework of Ada 95.

We find ourselves discussing this regularly in #ada on Freenode. Many of us see Ada as a sinking ship because of all its baggage. The ideals are strong, but the implementation is losing us.

I surely need to review the AIs for the next revision to see what's happening.

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

[Thomas Løcke]

On 03/24/2014 09:18 AM, J Kimball wrote:
> You are listening to what you're saying aren't you? I know we joke about
> things when we're uncomfortable with them. The people writing the rules
> don't know how to enforce them? There's an actual part of the manual
> that has a nick name "The Heart of Darkness!". Your own compiler can't
> even compete because of the labyrinth of rules.
>
> Ada has become the American tax code. It's becoming abundantly clear
> that there has to be a massive break in backward compatibility in the
> next revision of the language that makes writing compilers easier, not
> just keeping AdaCore in business, but breaking out of the framework of
> Ada 95.
>
> We find ourselves discussing this regularly in #ada on Freenode. Many of
> us see Ada as a sinking ship because of all its baggage. The ideals are
> strong, but the implementation is losing us.
>
> I surely need to review the AIs for the next revision to see what's
> happening.


Well said. I wholeheartedly agree.

-- 
Thomas Løcke | thomas@12boo.net | http://12boo.net

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

[Brian Drummond]

On Mon, 24 Mar 2014 10:17:07 +0100, Thomas Løcke wrote:

> On 03/24/2014 09:18 AM, J Kimball wrote:

>> We find ourselves discussing this regularly in #ada on Freenode. Many
>> of us see Ada as a sinking ship because of all its baggage. The ideals
>> are strong, but the implementation is losing us.
>>
>> I surely need to review the AIs for the next revision to see what's
>> happening.
> 
> 
> Well said. I wholeheartedly agree.

And another point of commonality with the VHDL community, especially 
after VHDL-2008 appeared, with the kitchen sink (for example, beating Ada 
to the re-introduction of Algol's conditional and case expressions, but 
with different syntax)

- Brian

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

[Peter Chapin]

On 2014-03-24 04:18, J Kimball wrote:

> Ada has become the American tax code. It's becoming abundantly clear
> that there has to be a massive break in backward compatibility in the
> next revision of the language that makes writing compilers easier, not
> just keeping AdaCore in business, but breaking out of the framework of
> Ada 95.

This is one reason why having multiple implementations is a good thing.
As an example the C++ community basically decided that template export,
as required by the C++ 1998 standard, wasn't worth the implementation
difficulties. As a result export has been removed from the C++ 2011
standard... despite the fact that there was one (only one) compiler that
implemented it.

If another compiler existed that *almost* implemented Ada 2012 but left
out controversial features (are there any?), and if that compiler proved
acceptable and useful to a significant part of the community, it would
help provide a kind of reality check on the standardization process.

I'm not saying Augusta will ever be mature enough to do this. I'm
speaking here in general terms about the value to the community of
having multiple competing implementations. It certainly seems, at the
moment, as if GNAT is the only viable Ada 2012 compiler in existence and
that isn't healthy for Ada.

Peter

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

[Luke A. Guest]

Thomas Løcke <thomas@12boo.net> wrote:
> On 03/24/2014 09:18 AM, J Kimball wrote:

>> We find ourselves discussing this regularly in #ada on Freenode. Many of
>> us see Ada as a sinking ship because of all its baggage. The ideals are
>> strong, but the implementation is losing us.
>> 
>> I surely need to review the AIs for the next revision to see what's
>> happening.
> 
> 
> Well said. I wholeheartedly agree.

Absolutely.

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

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4214 bytes --]

"J Kimball" <spam@example.com> wrote in message 
news:lgopof$unl$1@loke.gir.dk...
> On 03/20/2014 06:15 PM, Randy Brukardt wrote:
>> "J-P. Rosen" <rosen@adalog.fr> wrote in message
>> news:lgeh3m$gqq$1@dont-email.me...
>>> Le 20/03/2014 11:23, Lucretia a écrit :
>>>>> I am not as naive as I probably sound. I fully understand that such a
>>>>>> project is massive and not likely to actually ever be completed.
>>>> As long as you don't expect all the annexes, I don't see why not.
>>>>
>>> All those who have been involved in an Ada compiler will tell you that
>>> it is a lot more difficult than it appears, unless you stick to the
>>> Pascal subset and don't care for validation.
>>>
>>> In the early days of Ada, we have seen compilers announcing proudly that
>>> they passed 95% of the validation and that delivery was expected in a
>>> few weeks - they never succeeded to pass the remaining 5%.
>>>
>>> For example, and as a test, make sure you are able to understand the
>>> implications of 4.3.3 (a nightmare for code generation), or 13.14, or
>>> 3.10.2(3/2)...
>>
>> Heck, we (the ARG) aren't quite sure how you implement accessibility 
>> checks
>> for Ada 2005 and Ada 2012 (see AI12-0016-1 for some thinking); you could
>> waste a lot of time trying to figure that out. And like J-P says, a 95%
>> solution isn't good for much -- the real solution is 95% different. :-)
>>
>> It's for good reason that 3.10.2 is informally named "The Heart of
>> Darkness"! ;-)
>
> You are listening to what you're saying aren't you? I know we joke about 
> things
> when we're uncomfortable with them. The people writing the rules don't 
> know how to enforce them? There's an actual part of the manual that has a 
> nick name
>  "The Heart of Darkness!". Your own compiler can't even compete because of 
> the labyrinth of rules.

Not really. My compiler can't compete because I'm a lousy businessman and to 
a lesser extent because I'm rather burned out.

Some of these corner cases (especially "the Heart of Darkness") are obscure 
corners of the language of little interest to anyone. Until you try to get 
rid of them, and then the safety argument rears up (dangling pointers are a 
scourge).


> Ada has become the American tax code. It's becoming abundantly clear
> that there has to be a massive break in backward compatibility in the next
> revision of the language that makes writing compilers easier, not just 
> keeping
> AdaCore in business, but breaking out of the framework of Ada 95.

I'd be in favor of that, but I'm dubious that the customers that support Ada 
would want to make that sort of change. And if the customers don't come 
along, then there is little energy for anything to happen. After all, most 
hobbyest driven projects tend to wane after a couple of years, and that's 
not going to work for the sorts of long-lived projects that Ada is best at.

> We find ourselves discussing this regularly in #ada on Freenode. Many of 
> us
> see Ada as a sinking ship because of all its baggage. The ideals are 
> strong,
> but the implementation is losing us.

I could see some relatively small tweaks, but I doubt that would help 
implementation effort much. In particular, one of the nastiest things is 
type resolution. But the part of type resolution that is hard is the ability 
to overload on result types. (That's not allowed by C++, for instance.) But 
a large part of the elegance and ease-of-use of operators comes from that 
ability. Taking it away would prevent a lot of common techniques (for 
instance, it's what allows overloading of enumeration literals).

I'd be more interested in regularizing some of the rules (such as making 
objects overloadable) -- but I doubt that would have any positive impact on 
the effort to implement Ada.

One could try removing/altering large but not frequently used areas -- fixed 
point, tasks, discriminant-dependent components come to mind -- but for each 
one, you'd lose a bunch of Ada fans.

> I surely need to review the AIs for the next revision to see what's 
> happening.

Nothing to speak of yet; too soon after Ada 2012 to do anything formally. 
We're just gathering ideas at this point.

                                  Randy.

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

[Dennis Lee Bieber]

On Mon, 24 Mar 2014 16:21:20 -0500, "Randy Brukardt" <randy@rrsoftware.com>
declaimed the following:

>"J Kimball" <spam@example.com> wrote in message 

>
>> Ada has become the American tax code. It's becoming abundantly clear
>> that there has to be a massive break in backward compatibility in the next
>> revision of the language that makes writing compilers easier, not just 
>> keeping
>> AdaCore in business, but breaking out of the framework of Ada 95.
>
>I'd be in favor of that, but I'm dubious that the customers that support Ada 
>would want to make that sort of change. And if the customers don't come 
>along, then there is little energy for anything to happen. After all, most 
>hobbyest driven projects tend to wane after a couple of years, and that's 
>not going to work for the sorts of long-lived projects that Ada is best at.
>

	Aye; The paying customers aren't going to put up with the cost of
recertifying something like a flight management system because a language
revision has dropped support for some feature (or just made a small change
in the semantics of existing syntax). And such systems may be in use for
20+ years.

	I think I've overheard stuff at work where they are talking about
having to do side-by-side examination of the generated object code to
validate a new release of the compiler -- without changing the language
standard in use.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

[J Kimball]

On 03/24/2014 06:18 PM, Dennis Lee Bieber wrote:
> On Mon, 24 Mar 2014 16:21:20 -0500, "Randy Brukardt" <randy@rrsoftware.com>
> declaimed the following:
>
>> "J Kimball" <spam@example.com> wrote in message
>
>>
>>> Ada has become the American tax code. It's becoming abundantly clear
>>> that there has to be a massive break in backward compatibility in the next
>>> revision of the language that makes writing compilers easier, not just
>>> keeping
>>> AdaCore in business, but breaking out of the framework of Ada 95.
>>
>> I'd be in favor of that, but I'm dubious that the customers that support Ada
>> would want to make that sort of change. And if the customers don't come
>> along, then there is little energy for anything to happen. After all, most
>> hobbyest driven projects tend to wane after a couple of years, and that's
>> not going to work for the sorts of long-lived projects that Ada is best at.
>>
>
> 	Aye; The paying customers aren't going to put up with the cost of
> recertifying something like a flight management system because a language
> revision has dropped support for some feature (or just made a small change
> in the semantics of existing syntax). And such systems may be in use for
> 20+ years.
>
> 	I think I've overheard stuff at work where they are talking about
> having to do side-by-side examination of the generated object code to
> validate a new release of the compiler -- without changing the language
> standard in use.
>

Why would an ATCS system change language revision at all? Anyone whose using features they don't want to give up can safely stay with old revisions of the language. GNAT has had those -gnat{83,95,05,12) switches for a long time. These are not valid reasons for not shaking things up. Even if some project decided to leave Ada, you may just as easily find new people approaching the language. Large projects who think just changing the switch in their Makefile to the new language revision is sufficient probably shouldn't be using Ada in the first place.

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

[Stefan.Lucks]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1728 bytes --]

On Mon, 24 Mar 2014, Randy Brukardt wrote:

> "J Kimball" <spam@example.com> wrote in message
> news:lgopof$unl$1@loke.gir.dk...

>> Ada has become the American tax code. It's becoming abundantly clear 
>> that there has to be a massive break in backward compatibility in the 
>> next revision of the language that makes writing compilers easier, not 
>> just keeping AdaCore in business, but breaking out of the framework of 
>> Ada 95.
>
> I'd be in favor of that, but I'm dubious that the customers that support 
> Ada would want to make that sort of change. And if the customers don't 
> come along, then there is little energy for anything to happen. After 
> all, most hobbyest driven projects tend to wane after a couple of years, 
> and that's not going to work for the sorts of long-lived projects that 
> Ada is best at.

What about moving not-so-often used language features into an annex?

Thus, if your customers demand the feature, you are allowed to support it. 
Furthermore, anyone supporting that feature would do so so in a completely 
compatible way.

But if you don't want to support that feature, or you can't for some 
reason, you are allowed to support Ada 20XY without that annex.

As an example, I would consider interfaces. The support for multiple 
inheritance from "interface" could could be moved into an annex, and thus 
become optional for the language implementer. The key-word "interface" 
should remain reserved, for compatibility reasons.


------  I  love  the  taste  of  Cryptanalysis  in  the morning!  ------
     <http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
--Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany--

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

[Michael B.]

> Ada has become the American tax code. It's becoming abundantly clear
> that there has to be a massive break in backward compatibility in the
> next revision of the language that makes writing compilers easier, not
> just keeping AdaCore in business, but breaking out of the framework of
> Ada 95.

But breaking compatibility is very dangerous. Python did this and now 
there are two incompatible languages: Python 2.x and Python 3.x. Many 
library maintainers said, they will never support 3.x.
Pascal made the same mistake. Instead of enhancing the language, Modula 
and Oberon were created. Today none of these three languages is used 
anywhere.
I'm sure Ada would suffer a similar fate.

Michael

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

[Randy Brukardt]

<Stefan.Lucks@uni-weimar.de> wrote in message 
news:alpine.DEB.2.10.1403251025030.10474@debian...
>On Mon, 24 Mar 2014, Randy Brukardt wrote:
>
>> "J Kimball" <spam@example.com> wrote in message
>> news:lgopof$unl$1@loke.gir.dk...
>
>>> Ada has become the American tax code. It's becoming abundantly clear
>>> that there has to be a massive break in backward compatibility in the
>>> next revision of the language that makes writing compilers easier, not
>>> just keeping AdaCore in business, but breaking out of the framework of
>>> Ada 95.
>>
>> I'd be in favor of that, but I'm dubious that the customers that support
>> Ada would want to make that sort of change. And if the customers don't
>> come along, then there is little energy for anything to happen. After
>> all, most hobbyest driven projects tend to wane after a couple of years,
>> and that's not going to work for the sorts of long-lived projects that
>> Ada is best at.
>
>What about moving not-so-often used language features into an annex?
>
>Thus, if your customers demand the feature, you are allowed to support it.
>Furthermore, anyone supporting that feature would do so so in a completely
>compatible way.
>
>But if you don't want to support that feature, or you can't for some
>reason, you are allowed to support Ada 20XY without that annex.

This would work, but it wouldn't have any effect on simplifying the Standard 
(since the wording in the Standard would have to be prepared to handle the 
feature -- that's especially likely to be an issue for things like 
interfaces, which have an effect on virtually every definition in the 
Standard). And if one doesn't simplify the Standard, it's fairly unlikely 
that you're actually going to simplify implementation that much.

>As an example, I would consider interfaces. The support for multiple
>inheritance from "interface" could could be moved into an annex, and thus
>become optional for the language implementer. The key-word "interface"
>should remain reserved, for compatibility reasons.

Right.

But as always, the difficulty would be agreeing on what goes into such an 
index. I'd vote for interfaces and anonymous access types, but I'm sure the 
fans of those features would not be very happy. And they probably have some 
features that I find important that they think ought to be in the junk bin.

You'd be amazed at how hard it is to even move a feature into Annex J 
(Obsolescent Features), even those are required to be implemented. I'm still 
hearing flack about the decision to move aspect pragmas there, even though 
entity-specific pragmas was one of worst ideas ever known to mankind. :-)

                                    Randy.

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

[Shark8]

On 25-Mar-14 12:41, Michael B. wrote:
> Instead of enhancing the language, Modula and Oberon were created.

To be fair, Wirth always considered Modula and Oberon to be separate 
languages, hence the different name.

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

[Simon Clubley]

On 2014-03-25, Shark8 <OneWingedShark@gmail.com> wrote:
> On 25-Mar-14 12:41, Michael B. wrote:
>> Instead of enhancing the language, Modula and Oberon were created.
>
> To be fair, Wirth always considered Modula and Oberon to be separate 
> languages, hence the different name.

And don't forget that Oberon is a series of related languages, with
different capabilities, not just the one language. :-)

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

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

[Shark8]

On 26-Mar-14 13:39, Simon Clubley wrote:
> On 2014-03-25, Shark8 <OneWingedShark@gmail.com> wrote:
>> On 25-Mar-14 12:41, Michael B. wrote:
>>> Instead of enhancing the language, Modula and Oberon were created.
>>
>> To be fair, Wirth always considered Modula and Oberon to be separate
>> languages, hence the different name.
>
> And don't forget that Oberon is a series of related languages, with
> different capabilities, not just the one language. :-)

Ah, true, though the only ones I know of [off the top of my head] are:
Oberon, Oberon-2, and Component Oberon [IIRC].

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

[Simon Clubley]

On 2014-03-27, Shark8 <OneWingedShark@gmail.com> wrote:
> On 26-Mar-14 13:39, Simon Clubley wrote:
>> On 2014-03-25, Shark8 <OneWingedShark@gmail.com> wrote:
>>> On 25-Mar-14 12:41, Michael B. wrote:
>>>> Instead of enhancing the language, Modula and Oberon were created.
>>>
>>> To be fair, Wirth always considered Modula and Oberon to be separate
>>> languages, hence the different name.
>>
>> And don't forget that Oberon is a series of related languages, with
>> different capabilities, not just the one language. :-)
>
> Ah, true, though the only ones I know of [off the top of my head] are:
> Oberon, Oberon-2, and Component Oberon [IIRC].
>

Do you mean Component Pascal ?

Although it's got Pascal in it's name it's apparently (I've never used
Component Pascal) actually another Oberon derivative. [*]

Oberon-07 and Active Oberon are two other variants which come to mind.

Simon.

[*] To bring this back on topic, why does something which looks like
Ada have to be called Ada ? Call it something else and get people
using Ada without realising it. :-)

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

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

[Lucretia]

On Thursday, 27 March 2014 20:02:56 UTC, Simon Clubley  wrote:

> [*] To bring this back on topic, why does something which looks like
> Ada have to be called Ada ? Call it something else and get people
> using Ada without realising it. :-)

I've already mentioned doing this on #Ada, a fork of Ada. Take the basic language, strip it down to the basics and extend, replacing anything that's a little weird.

i.e. 1) add exception records

type E is exception
   record
      My_Data : Integer;
   end record;

2) User defined types having 'Image and 'Value, which call a subprogram which must be defined if these attributes are to be used - much like the stream operations do.

3) Replace tagged with just class, so:

type C is
   class
      ...
   end class;

For starters.

Luke.

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

[Niklas Holsti]

On 14-03-27 21:38 , Lucretia wrote:
> On Thursday, 27 March 2014 20:02:56 UTC, Simon Clubley  wrote:
> 
>> [*] To bring this back on topic, why does something which looks like
>> Ada have to be called Ada ? Call it something else and get people
>> using Ada without realising it. :-)
> 
> I've already mentioned doing this on #Ada, a fork of Ada.
> Take the basic language, strip it down to the basics

So, what are the "basics"?

This might work, if the "basics" is really so small a language that a
compiler can be implemented (and mantained) with much, much less effort
than a real Ada compiler.

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 to implement something like the SETL
version of Ada-Ed, but with acceptable performance for programs that are
not humongously large. At the same time, such work, at least if done in
an academic setting, could help to clarify the dark corners of the
language standard.

> and extend, replacing anything that's a little weird.

Weirdness is subjective and depends on one's upbringing (that is,
earlier programming languages). As a motivation for replacing something,
that does not get my support.

> i.e. 1) add exception records
> 
> type E is exception
>    record
>       My_Data : Integer;
>    end record;

I might support that for "real" Ada, too. But I believe there would have
to be restrictions on the nature of the record to avoid too complex
memory management when an exception is raised or handled.

> 2) User defined types having 'Image and 'Value, which call
> a subprogram which must be defined if these attributes are
> to be used - much like the stream operations do.

I support that. But there should be default implementations, just like
the stream operations have defaults. The defaults should be extended to
cover non-scalar types, too.

> 3) Replace tagged with just class, so:
> 
> type C is
>    class
>       ...
>    end class;

A mere sop to foreign conventions and creates useless non-uniformity
between different kinds of records. I'm against it.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

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

[Luke A. Guest]

Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
> On 14-03-27 21:38 , Lucretia wrote:
>> I've already mentioned doing this on #Ada, a fork of Ada.
>> Take the basic language, strip it down to the basics
> 
> So, what are the "basics"?

The basics are the main language.

> version of Ada-Ed, but with acceptable performance for programs that are
> not humongously large. At the same time, such work, at least if done in
> an academic setting, could help to clarify the dark corners of the
> language standard.

Can be done with llvm as a start with the hit interface.

>> 3) Replace tagged with just class, so:
>> 
>> type C is
>>    class
>>       ...
>>    end class;
> 
> A mere sop to foreign conventions and creates useless non-uniformity
> between different kinds of records. I'm against it.

Sop??

The class is a different concept to a record and should be implemented that
way, this will also make it more familiar to others, I.e. Help foster
adoption.

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

[J Kimball]

On 03/28/2014 12:12 AM, Shark8 wrote:
> On 27-Mar-14 15:32, Luke A. Guest wrote:
>> Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
>>> On 14-03-27 21:38 , Lucretia wrote:
>>>> I've already mentioned doing this on #Ada, a fork of Ada.
>>>> Take the basic language, strip it down to the basics
>>>
>>> So, what are the "basics"?
>>
>> The basics are the main language.
>>
>>> version of Ada-Ed, but with acceptable performance for programs that are
>>> not humongously large. At the same time, such work, at least if done in
>>> an academic setting, could help to clarify the dark corners of the
>>> language standard.
>>
>> Can be done with llvm as a start with the hit interface.
>>
>>>> 3) Replace tagged with just class, so:
>>>>
>>>> type C is
>>>>     class
>>>>        ...
>>>>     end class;
>>>
>>> A mere sop to foreign conventions and creates useless non-uniformity
>>> between different kinds of records. I'm against it.
>>
>> Sop??
>>
>> The class is a different concept to a record and should be implemented that
>> way, this will also make it more familiar to others, I.e. Help foster
>> adoption.
>
> I'd rather CLASS be used as, say, a shorthand for [essentially] signature-package use-cases (i.e. ensuring some type has some interface -- perhaps allowing a separately defined implementation).

Of the issues people are interested in, repurposing keywords isn't really a priority. Keywords always vary across languages and paradigms. It's just part of the curve of any language.

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

[Shark8]

On 27-Mar-14 15:32, Luke A. Guest wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
>> On 14-03-27 21:38 , Lucretia wrote:
>>> I've already mentioned doing this on #Ada, a fork of Ada.
>>> Take the basic language, strip it down to the basics
>>
>> So, what are the "basics"?
>
> The basics are the main language.
>
>> version of Ada-Ed, but with acceptable performance for programs that are
>> not humongously large. At the same time, such work, at least if done in
>> an academic setting, could help to clarify the dark corners of the
>> language standard.
>
> Can be done with llvm as a start with the hit interface.
>
>>> 3) Replace tagged with just class, so:
>>>
>>> type C is
>>>     class
>>>        ...
>>>     end class;
>>
>> A mere sop to foreign conventions and creates useless non-uniformity
>> between different kinds of records. I'm against it.
>
> Sop??
>
> The class is a different concept to a record and should be implemented that
> way, this will also make it more familiar to others, I.e. Help foster
> adoption.

I'd rather CLASS be used as, say, a shorthand for [essentially] 
signature-package use-cases (i.e. ensuring some type has some interface 
-- perhaps allowing a separately defined implementation).

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

[Georg Bauhaus]

On 27/03/14 23:32, Luke A. Guest wrote:
>
> The class is a different concept to a record and should be implemented that
> way, this will also make it more familiar to others, I.e. Help foster
> adoption.

A type is the thing that matters, I think, not its data.

I can imagine a request for tagged arrays or for discriminated
enumerations. And if one continues along this path, the following
study is reiterated: What is a good selection of type construction
facilities?

The original discussion, IIRC Robert Dewar mentioning it
here, seems to have been about

    class type T is ...   -- with T'Class, too

versus

    type T is tagged ...  -- with T'class, too

the former reflecting the position of "task" and "protected".
The vote by country was not unanimous.

Another association of keywords was package types.

As someone who has had to use "classes" that extend hash table
and then use the keys for what should be operation lets me
ask for something that emphasizes abstract types. Or, "thinking
in types". The class thingy really is a sop when it is not universal.
it does *not* seem to produce a good understanding of object oriented
design, but helps create many purportedly O-O programs instead.

If you have heard about the difficulties when porting Delphi
programs to C#, even when written for .NET, raise your hands!
  ;-)

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

[Dmitry A. Kazakov]

On Thu, 27 Mar 2014 13:38:16 -0700 (PDT), Lucretia wrote:

> i.e. 1) add exception records
> 
> type E is exception
>    record
>       My_Data : Integer;
>    end record;

You will have a problem catching such exceptions because in Ada exceptions
are "values" not "types", like in C++.

That they are "value" among other allows enumeration like:

   when Error : Constraint_Error | Data_Error =>

If Constraint_Error and Data_Error were "types" what would be the type of
Error? You could move to classes of exceptions but that still would not
allow simple enumerations when instances are not siblings.

A related problem is renaming of exceptions. A renaming produce a new
object, but you still can catch it under original name because the result
has same "value."

In general if exceptions form a tree of related types you have a problem of
choosing between sets, possibly nested sets of types in exception handlers.
C++ does this by linear matching exceptions in the order they appear. This
is a mess.

> 2) User defined types having 'Image and 'Value, which call a subprogram
> which must be defined if these attributes are to be used - much like the
> stream operations do.

They should be primitive operations instead.

But the actual problem here is MD. It works with stream attributes through
cascaded dispatch *only* because streams enforce Stream_Element on all
implementations which decompose objects into Stream_Element_Arrays. This is
the reason why a stream attribute can *first* dispatch on the object type
and *then* on the stream. For 'Image and 'Value it would not work in
presence of Character, Wide_Character, Wide_Wide_Character. That is full
MD, or else you have to restrict it to single character type.
 
> 3) Replace tagged with just class, so:
> 
> type C is
>    class
>       ...
>    end class;

Class is not a type. Class is a set of types. A class can have a
"representative" type, which is already named in Ada as T'Class.

In short, you need not to specify that some type may be member of a class.
All types may. Why not?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Peter C. Chapin]

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.

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.

My intention has also been to use LLVM or something similar (C, the JVM, 
etc) as a back end to reduce the amount of work involved in actually 
getting executable code generated. I understand it is still necessary to 
generate code for whatever target I use, but the targets above are all 
higher level than machine language and so (I anticipate) easier to manage.

Peter

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

[Dan'l Miller]

On Thursday, March 27, 2014 3:02:56 PM UTC-5, Simon Clubley wrote:
> [*] To bring this back on topic, why does something which looks like
> Ada have to be called Ada ? Call it something else and get people
> using Ada without realising it. :-)

Back in the 1970s & 1980s, Ada standardization had a crystal-clear mission:  be the one true replacement imperative programming language for munitions & support systems of the US DoD and for the NATO allies.  Back in the 1970s & 1980s, C had a crystal-clear mission:  be the implementation language of UNIX and its derivatives.  Over time, C's mission extended to being the embedded real-time programming language (except where Ada was expected instead) and the language for hardware interfacing (except where Ada was expected instead) and eventually the language for non-Unix operating systems from Microsoft.  Nowadays, Ada standardization's mission can be thought of as:
1) cater to Ada's installed base of aerospace & military & vehicular industries, especially as the host language for Ravenscar/SPARK profile; and
2) give AdaCore a credible ambiance of not being the benevolent dictator of Ada (a la Guido van Rossum for Python or Larry Wall for Perl).  Note that #1 is considered the "paying customers" of AdaCore at the heart of #2, which means that #1 & #2 are intertwined as shared fate, not entirely independent.

I would submit that Ada 202X needs to have at least a third (quite independent) mission if not a fourth mission as well.  Once that third mission arises,  then what to add or shape in the Ada standard becomes less befuddling, if not crystal-clear obvious.  I suspect that the third mission could be:

3) Be the best replacement for C++.  Ada is the anti-C++ imperative multiparadigm language.  Ada borrows good ideas from C++, Java, C#, and so forth when Ada is viewed as deficient (e.g., interfaces, finalization).  But Ada leads even C++ on declaring useful restrictions to the compiler for the compiler to enforce in an attempt to marshall human thought to obey the design's rules consistently, although C++2011 is borrowing some of Ada's semantics in this regard and hence C++2011 is starting to catch up to Ada.  One area that is ripe for Ada202X to assert its lead as the wisest imperative programming language is C++'s ever-increasing dependence on meta-template programming (MTP), even in C++2011's & C++2014's standard library.  MTP begets a disgusting depth of cryptic compile-time error messages quite often in real-world app-domain code.  Hence, MTP is C++'s achilles heal for Ada to provide a useful alternative; hence mission #4.

4) Be the least-repulsive compile-time language interpreter/source-code-generator.  Since its inception, Ada has always emphasized overt declaration of the programmer's intent.  Given the way that OCaml and C++ have been trending in the past decade, functional programming at compile-time is a state-of-the-art feature-set of compile-time declaration that Ada lacks (ignoring a.app back in the 1990s, which has fallen into disuse and was imperative instead of functional).  Ada202X could bring back a.app or completely rethink a.app to be functional instead of imperative.  C++1998, C++2003, C++2011, and onward have MTP largely by accident when it was discovered that the C++ template expansion was by happenstance Turing complete when using various arcane syntaxes & conventions & idioms.  Hence, MTP wins the award for being the least thought out massive new feature in a programming language ever, I suspect.  Ada202X's compile-time language could borrow heavily from OCaml (especially MetaOcaml) but rethink OCaml's off-putting syntax.  Ada202X could think through what "extending the compiler" and "compile-time program generator" really means (a step that C++ never accomplished regarding MTP), especially regarding debugability and visibility to the interpreted (meta-)program that is generating the compiled (app-domain-)program.  Perhaps a portion of this rethinking of extending the compiler via compile-time declarations could include aspect-oriented programming, such as borrowing from AspectJ.

Even if you reject the two proposed missions stated above (which are provided merely to stoke fires of the mind), Ada desperately needs additional missions beyond #1 & #2 above.  Having a clear reason to live goes a long way toward continuing to live at all.

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

[Dmitry A. Kazakov]

On Fri, 28 Mar 2014 12:20:52 -0700 (PDT), Dan'l Miller wrote:

[...]
on Ada's missions.

More important missions for Ada as a language for software engineers IMO
are:

1. Portability. Ada has a very good standing here, but lacks support for
too many vital platforms. There are serious issues with streams, I/O, Ada
directories. Much must be done for networking and GUI.

2. Safety on programmer's demand, full integration of SPARK, static checks
mandated by the programmer, contracts put on exceptions,
initialization/finalization fixed, renaming fixed, re-dispatch ditched

3. Security (no support at all, so far)

4. Reuse, aspects not covered in 1-3, separate compilation support, dynamic
linking/loading support, MI, MD, proper interfaces, additive and replacing
models of inheritance, interface inheritance.

5. Concurrency and distributed computing. Little was done since Ada 95.
Concurrent types lack integration with the type system.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Peter Chapin]

On 2014-03-28 15:20, Dan'l Miller wrote:

> I would submit that Ada 202X needs to have at least a third (quite independent) mission if not a fourth mission as well

Ada has always been strong in the area of reliability. One obvious(?)
direction for Ada 202X would be the incorporation of some, most, or even
all of SPARK 2014. I'm not sure how that would fit into AdaCore's
business plan but it would certainly be movement forward in a direction
that Ada already tries to strongly support.

I've heard it said that "ordinary" programmers (whoever they are,
exactly) won't use formal verification techniques in their day-to-day
programming because such techniques are too difficult to use. It seems
like that is changing. Perhaps Ada 202X should lead the way.

> 4) Be the least-repulsive compile-time language interpreter/source-code-generator.

It sounds like you are talking about staged programming here. I agree
that's an interesting area and it even has potential application in
embedded systems where a first stage program can generate a specialized
and more efficient second stage program that runs on resource
constrained hardware.

Such a feature for Ada would probably require a way to represent Ada
code abstractly so the compiler can manipulate it. Using Scala as an
example (because I'm familiar with it)... in Scala you can write methods
that manipulate the abstract syntax tree of Scala code. These methods
can be executed by the compiler to generate code that is subsequently
compiled.

Ada has a standard that provides, at some level, an abstract view of Ada
code, namely ASIS. Perhaps Ada 202X should consider merging ASIS and Ada
in some way to provide a compile time "macro" facility for Ada. It
sounds scary hard, though. :)

Peter

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

[Shark8]

On 28-Mar-14 17:15, Peter Chapin wrote:
> Such a feature for Ada would probably require a way to represent Ada
> code abstractly so the compiler can manipulate it.

Something like DIANA (Descriptive Intermediate Attributed Notation for Ada)?

Wikipedia Link: 
http://en.wikipedia.org/wiki/DIANA_%28intermediate_language%29

ACM Link:
http://dl.acm.org/citation.cfm?id=SERIES10245.69574

Amazon link:
http://www.amazon.com/DIANA-Intermediate-Language-Ada-Computer/dp/3540126953/

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

[Georg Bauhaus]

On 29/03/14 01:15, Peter Chapin wrote:
> (...) you can write methods
> that manipulate the abstract syntax tree (...). These methods
> can be executed by the compiler to generate code that is subsequently
> compiled.
>
> (...) Perhaps Ada 202X should consider merging ASIS and Ada
> in some way to provide a compile time "macro" facility for Ada.

Given Lisp compilers, is there some report or story of how
its macro compiler was used for embedded systems? If not,
would *Ada change that?

Will Ada+ASIS introduce recursive generics in a way that
a programmer can understand?

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

[Georg Bauhaus]

On 29/03/14 01:15, Peter Chapin wrote:
> I've heard it said that "ordinary" programmers (whoever they are,
> exactly) won't use formal verification techniques in their day-to-day
> programming because such techniques are too difficult to use. It seems
> like that is changing. Perhaps Ada 202X should lead the way.

"Ordinary programmers" may apply to programmers who are primarily
natural scientists, engineers, business economists, or self-taught
(think of web programming).

The other group are mathematicians in disguise. (The classification
is the focus of Keith Devlin's "The Math Gene". Though I still need
to finish reading it.)

Just like some will successfully take an interest in abstract algebra
or topology or complex analysis, others will have "better" things
to do.

The killer argument, though, will be whether or not Ada based
formal methods, if deemed acceptable by the peers in management,
will mean more money.


(I'm in neither group.)

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

[Dan'l Miller]

On Friday, March 28, 2014 3:40:15 PM UTC-5, Dmitry A. Kazakov wrote:
> On Fri, 28 Mar 2014 12:20:52 -0700 (PDT), Dan'l Miller wrote:
> More important missions for Ada as a language for software engineers IMO
> are:
>
> 1. Portability. Ada has a very good standing here, but lacks support for
> too many vital platforms. There are serious issues with streams, I/O, Ada
> directories. Much must be done for networking and GUI.
> 
> 2. Safety on programmer's demand, full integration of SPARK, static checks
> mandated by the programmer, contracts put on exceptions,
> initialization/finalization fixed, renaming fixed, re-dispatch ditched
> 
> 3. Security (no support at all, so far)
> 
> 4. Reuse, aspects not covered in 1-3, separate compilation support, dynamic
> linking/loading support, MI, MD, proper interfaces, additive and replacing
> models of inheritance, interface inheritance.
> 
> 5. Concurrency and distributed computing. Little was done since Ada 95.
> Concurrent types lack integration with the type system.

No, Dmitry, those are not "more important"; they are merely features that accomplish some greater mission.  I speak of the greater missions.  For example, the already-existing portions of your #4 are features that permit programming in the large, which is needed by my #1, the military-aerospace industry.  Your #5 has always (since Ada1983 and Green) been viewed as essential to my #1.  The new innovations in your #4 would largely catch Ada202X up to the (perceived-)innovations in C++2011 regarding concurrency; see N2239, N2427, N2748, N2752, N2429, N2664, N2179, N2547, N2659, and N2660 at http://clang.llvm.org/cxx_status.html; the new innovations in your #4 would be be my #3.

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

[Dan'l Miller]

On Friday, March 28, 2014 3:40:15 PM UTC-5, Dmitry A. Kazakov wrote:
> On Fri, 28 Mar 2014 12:20:52 -0700 (PDT), Dan'l Miller wrote:
> 
> 
> 
> [...]
> 
> on Ada's missions.
> 
> 
> 
> More important missions for Ada as a language for software engineers IMO
> 
> are:
> 
> 
> 
> 1. Portability. Ada has a very good standing here, but lacks support for
> 
> too many vital platforms. There are serious issues with streams, I/O, Ada
> 
> directories. Much must be done for networking and GUI.
> 
> 
> 
> 2. Safety on programmer's demand, full integration of SPARK, static checks
> 
> mandated by the programmer, contracts put on exceptions,
> 
> initialization/finalization fixed, renaming fixed, re-dispatch ditched
> 
> 
> 
> 3. Security (no support at all, so far)
> 
> 
> 
> 4. Reuse, aspects not covered in 1-3, separate compilation support, dynamic
> 
> linking/loading support, MI, MD, proper interfaces, additive and replacing
> 
> models of inheritance, interface inheritance.
> 
> 
> 
> 5. Concurrency and distributed computing. Little was done since Ada 95.
> 
> Concurrent types lack integration with the type system.
> 
> 
> 
> -- 
> 
> Regards,
> 
> Dmitry A. Kazakov
> 
> http://www.dmitry-kazakov.de

No, Dmitry, those are not "more important"; they are merely features that accomplish some greater mission.  I speak of the greater missions.  For example, the portions of your #4 are features that permit programming in the large, which is needed by my #1, the military-aerospace industry.  The already-existing of your #5 has always (since Ada1983 and Green) been viewed as essential to my #1.  The new innovations in your #5 would largely catch Ada202X up to the (perceived-)innovations in C++2011 regarding concurrency; see N2239, N2427, N2748, N2752, N2429, N2664, N2179, N2547, N2659, and N2660 at http://clang.llvm.org/cxx_status.html; the new innovations in your #5 would be contained within my #3.

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

[Dmitry A. Kazakov]

On Sat, 29 Mar 2014 05:34:50 -0700 (PDT), Dan'l Miller wrote:

> On Friday, March 28, 2014 3:40:15 PM UTC-5, Dmitry A. Kazakov wrote:
>> On Fri, 28 Mar 2014 12:20:52 -0700 (PDT), Dan'l Miller wrote:
>> More important missions for Ada as a language for software engineers IMO
>> are:
>>
>> 1. Portability. Ada has a very good standing here, but lacks support for
>> too many vital platforms. There are serious issues with streams, I/O, Ada
>> directories. Much must be done for networking and GUI.
>> 
>> 2. Safety on programmer's demand, full integration of SPARK, static checks
>> mandated by the programmer, contracts put on exceptions,
>> initialization/finalization fixed, renaming fixed, re-dispatch ditched
>> 
>> 3. Security (no support at all, so far)
>> 
>> 4. Reuse, aspects not covered in 1-3, separate compilation support, dynamic
>> linking/loading support, MI, MD, proper interfaces, additive and replacing
>> models of inheritance, interface inheritance.
>> 
>> 5. Concurrency and distributed computing. Little was done since Ada 95.
>> Concurrent types lack integration with the type system.
> 
> No, Dmitry, those are not "more important"; they are merely features that
> accomplish some greater mission.  I speak of the greater missions.  For
> example, the already-existing portions of your #4 are features that permit
> programming in the large, which is needed by my #1, the military-aerospace
> industry.

Do you consider language mission in one of its application areas? I don't
think that is useful. For one, Ada was always considered a general-purpose
language. Then specialized languages do not really work. There is nothing
special in military software except for being more over budget than
anything else and decision making processes even further removed from
reality than usually. Ada-DoD alliance brought little good to Ada.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Peter Chapin]

On 2014-03-29 04:46, Georg Bauhaus wrote:

> Given Lisp compilers, is there some report or story of how
> its macro compiler was used for embedded systems? If not,
> would *Ada change that?

The only stuff I've read on this topic has been research papers about
toy languages. Off hand, I must admit, I don't know of any real life
application of staged programming in an embedded systems project. The
discussion I've seen has all been of a "what if" nature.

My dissertation is about a staged programming system for embedded
targets (wireless sensor networks specifically) [1,2]. While I'd like to
think it could be used for real programs, maybe after some clean up, I
don't believe anyone is doing so.

Ada is nice because it was designed to target embedded systems and yet
it also has some good, high level facilities as well. It could thus
potentially be used as both the language and the meta-language, which is
nice. The system I built for my dissertation uses two different
languages at the two stages which complicates things both theoretically
and pragmatically.

Peter

[1] http://web.vtc.edu/users/pcc09070/papers/chapin-dissertation.pdf
[2] https://github.com/pchapin/scala

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

[Randy Brukardt]

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