Five Years After

Five Years After

[Jeffrey R. Carter]

In 2000, when ISO/IEC 8652:1995 was 5 years old, every compiler vendor had a 
compiler for it.

In 2012, when ISO/IEC 8652:2007 was 5 years old, about half of the comiler 
vendors had a compiler for it.

in 2017, when ISO/IEC 8652:2012 was 5 years old, one compiler vendor had a 
compiler for it.

Can we extrapolate and conclude that when Ada 2X is five years old, there will 
be no compiler vendors with a compiler for it?

-- 
Jeff Carter
"My brain hurts!"
Monty Python's Flying Circus
21

Re: Five Years After

[Jacob Sparre Andersen]

Jeffrey R. Carter wrote:

> In 2000, when ISO/IEC 8652:1995 was 5 years old, every compiler vendor
> had a compiler for it.
>
> In 2012, when ISO/IEC 8652:2007 was 5 years old, about half of the
> comiler vendors had a compiler for it.
>
> in 2017, when ISO/IEC 8652:2012 was 5 years old, one compiler vendor
> had a compiler for it.
>
> Can we extrapolate and conclude that when Ada 2X is five years old,
> there will be no compiler vendors with a compiler for it?

Hopefully not.

Greetings,

Jacob
-- 
»When Roman engineers built a bridge, they had to stand under it while
 the first legion marched across. If programmers today worked under
 similar ground rules, they might well find themselves getting much more
 interested in Ada!«                                     -- Robert Dewar

Re: Five Years After

[gautier_niouzes]

> Can we extrapolate and conclude that when Ada 2X is five years old, there will 
> be no compiler vendors with a compiler for it?

Or half a compiler ;-)

Re: Five Years After

[Nasser M. Abbasi]

On 1/13/2018 6:36 AM, Jeffrey R. Carter wrote:
> In 2000, when ISO/IEC 8652:1995 was 5 years old, every compiler vendor had a
> compiler for it.
> 
> In 2012, when ISO/IEC 8652:2007 was 5 years old, about half of the comiler
> vendors had a compiler for it.
> 
> in 2017, when ISO/IEC 8652:2012 was 5 years old, one compiler vendor had a
> compiler for it.
> 
> Can we extrapolate and conclude that when Ada 2X is five years old, there will
> be no compiler vendors with a compiler for it?
> 

Did first a linear fit, so in 2023 (assuming this is when
Ada2X will be), it shows there will be -0.23799 compiler
vendors.

I used 2.5 vendors for 2012, which is half the 5 vendors
you said there were in 2000.

In[19]:= data={{2000,5},{2012,2.5},{2017,1}};
f= Fit[data, {1,x}, x] (*linear fit*)
Out[20]= 465.759 -0.230349 x  (*the line equation*)

f/.x->2023 (*see what happens at year 2023*)

Out[21]= -0.237991
-----------------

Using Quadratic fit, shows there will be -1.15588 compiler
vendors.

In[16]:= data={{2000,5},{2012,2.5},{2017,1}};
f= Fit[data, {1,x,x^2}, x]
Out[17]= -21276.4+21.425 x-0.00539216 x^2

f/.x->2023
Out[18]= -1.15588

Since it is not possible physically to have negative
compiler vendors, then using zero seems to make more
sense.

--Nasser

Re: Five Years After

[Jeffrey R. Carter]

On 01/13/2018 08:45 PM, Nasser M. Abbasi wrote:
> 
> I used 2.5 vendors for 2012, which is half the 5 vendors
> you said there were in 2000.

I didn't say there were 5 vendors in 2000; I'm sure there were more. Nor is it 
likely that the number of vendors in 2012 was the same as in 2000.

It's probably better to use proportions than actual numbers: 2000 => 1.0, 2012 
=> 0.5, 2017 => 0.1 (to one significant digit).

The earliest that Ada 2X will be five years old will be 2025.

-- 
Jeff Carter
"My brain hurts!"
Monty Python's Flying Circus
21

Re: Five Years After

[Luke A. Guest]

Jeffrey R. Carter <spam.jrcarter.not@spam.not.acm.org> wrote:

> 
> Can we extrapolate and conclude that when Ada 2X is five years old, there will 
> be no compiler vendors with a compiler for it?
> 

Maybe it’s time to rethink Ada2?

Re: Five Years After

[Robert Eachus]

On Sunday, January 14, 2018 at 2:13:12 PM UTC-5, Luke A. Guest wrote:
> Jeffrey R. Carter <spam.jrcarter.not@spam.not.acm.org> wrote: 
> Maybe it’s time to rethink Ada2?

It might be, but then again what really needs to be surveyed are:

Who is offering SPARK, and how many corporate projects are using it, and which version.

Who is supplying Ada compiler support for projects which have "frozen" project 
language levels at Ada 83/87, Ada 95, Ada 2007, and Ada 2012.

I could see projects deciding that Ada 95 was too big a change--in spite of all the work we did to limit migration issues.  On the other hand Ada 2007, and 2012 may have been seen as too small a change to bother with.  Also having a validated compiler doesn't seem to matter as much as it did in the last century. ;-)

Re: Five Years After

[Luke A. Guest]

Robert Eachus <rieachus@comcast.net> wrote:

>> Maybe it’s time to rethink Ada2?
> 
> It might be, but then again what really needs to be surveyed are:

I thought no it is. Take what is required, strip wha isn’t. There’s a lot
that could change.

> 
> Who is offering SPARK, and how many corporate projects are using it, and which version.

AdaCore.

> Who is supplying Ada compiler support for projects which have "frozen" project 
> language levels at Ada 83/87, Ada 95, Ada 2007, and Ada 2012.

See above considering there’s no other vendor right now who supplies Ada
above 95.


> 
> I could see projects deciding that Ada 95 was too big a change--in spite
> of all the work we did to limit migration issues.  On the other hand Ada
> 2007, and 2012 may have been seen as too small a change to bother with. 
> Also having a validated compiler doesn't seem to matter as much as it did
> in the last century. ;-)

There’s some really nice additions in 2005 and 2012. But I think the
language is getting too large, maybe.

> 
> 

Re: Five Years After

[bozovic.bojan]

PTC ObjectAda supports Ada 2005 standard, according to information on their web site.

Re: Five Years After

[Nasser M. Abbasi]

On 1/22/2018 11:23 PM, Luke A. Guest wrote:
  last century. ;-)
> 
> There’s some really nice additions in 2005 and 2012. But I think the
> language is getting too large, maybe.
> 

All languages are getting too large. Have you looked at
"modern" Fortran for example? It is getting bigger
and more complex than C++ and Ada combined :)

Committee members have to do something, else they
will run out of work. So the only thing they could
do is keep making the computer languages more and more
complicated.

--Nasser

Re: Five Years After

[Dmitry A. Kazakov]

On 24/01/2018 14:16, Nasser M. Abbasi wrote:

> Committee members have to do something, else they
> will run out of work.

On the contrary, more complexity, more work.

> So the only thing they could do is keep making the computer languages
> more and more complicated.

Nothing happens without scientific efforts towards new concepts of 
language design. There was no any advance for more than 30 years. The 
compiler market was demolished long ago, so there is no commercial 
interest in any research.

Languages are designed either by hobbyists or by monopolists for 
purposes of customer lock and stiffening competition. They recycle old 
ideas good and bad all the same, just like fashion designers do their 
collections.

There is no push from the programmers' side either because there is no 
interest in software quality in general, quality does not sell.

Ergo, use Ada while you can.

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

Re: Five Years After

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:p4a2ah$58s$1@gioia.aioe.org...
> On 24/01/2018 14:16, Nasser M. Abbasi wrote:
...
>> So the only thing they could do is keep making the computer languages
>> more and more complicated.
>
> Nothing happens without scientific efforts towards new concepts of 
> language design. There was no any advance for more than 30 years. The 
> compiler market was demolished long ago, so there is no commercial 
> interest in any research.
>
> Languages are designed either by hobbyists or by monopolists for purposes 
> of customer lock and stiffening competition. They recycle old ideas good 
> and bad all the same, just like fashion designers do their collections.

This is one the best descriptions of modern language design that I've heard! 
Part of the problem is that few of these so called language designers have 
much exposure to many languages, so one doesn't really even know what does 
and does not work. And some features (exception contracts come to mind) are 
declared bad as much because of bad designs which inevitably lead to bad 
outcomes.

Ada is not immune to this, unfortunately. There is always pressure to add 
some pet feature from some other favorite language, and I have to hope that 
ultimately we will resist adding too much of that sort of stuff.

                                 Randy.

Re: Five Years After

[Simon Clubley]

On 2018-01-23, Luke A  Guest <laguest@archeia.com> wrote:
> Robert Eachus <rieachus@comcast.net> wrote:
>> Who is supplying Ada compiler support for projects which have "frozen" project 
>> language levels at Ada 83/87, Ada 95, Ada 2007, and Ada 2012.
>
> See above considering there?s no other vendor right now who supplies Ada
> above 95.
>

Is Adacore actually cutting back on the number of supported platforms ?

I've recently been told that Adacore no longer support VMS. I wonder
if this is a one-off or part of a larger cutback in the number of
platforms that Adacore are willing to support.

>
>> 
>> I could see projects deciding that Ada 95 was too big a change--in spite
>> of all the work we did to limit migration issues.  On the other hand Ada
>> 2007, and 2012 may have been seen as too small a change to bother with. 
>> Also having a validated compiler doesn't seem to matter as much as it did
>> in the last century. ;-)
>
> There?s some really nice additions in 2005 and 2012. But I think the
> language is getting too large, maybe.
>

Going the other way, a subset of Ada might be useful as well.

There's serious potential for a good small language that could serve
as an easily implemented C language replacement. It's possible that
a subset of Ada with just the core features implemented and hence
without vast amounts of required runtime library support could
serve that purpose.

Think of something that had the kind of functionality of a beefed up
version of Oberon with all of the Ada type safety features imported
into it for example.

Simon.

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

Re: Five Years After

[Björn Lundin]

On 2018-01-24 14:50, Simon Clubley wrote:
> 
> Is Adacore actually cutting back on the number of supported platforms ?
> 
> I've recently been told that Adacore no longer support VMS. I wonder
> if this is a one-off or part of a larger cutback in the number of
> platforms that Adacore are willing to support.
> 

It seems so. We have support on AIX, and last summer I think,
we got mail that they will not develop more features for that platform
They released the 7.4.2LTS (Long Time Support) version,
which is supported as is (Ada 2012) but nothing new will come to it.

I _think_ the same goes for Solaris both on intel and sparc.


-- 
--
Björn

Re: Five Years After

[Simon Clubley]

On 2018-01-24, Björn Lundin <b.f.lundin@gmail.com> wrote:
> On 2018-01-24 14:50, Simon Clubley wrote:
>> 
>> Is Adacore actually cutting back on the number of supported platforms ?
>> 
>> I've recently been told that Adacore no longer support VMS. I wonder
>> if this is a one-off or part of a larger cutback in the number of
>> platforms that Adacore are willing to support.
>> 
>
> It seems so. We have support on AIX, and last summer I think,
> we got mail that they will not develop more features for that platform
> They released the 7.4.2LTS (Long Time Support) version,
> which is supported as is (Ada 2012) but nothing new will come to it.
>
> I _think_ the same goes for Solaris both on intel and sparc.
>

Interesting, thanks.

Simon.

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

Re: Five Years After

[Mehdi Saada]

> There's serious potential for a good small language that could serve
> as an easily implemented C language replacement. It's possible that
> a subset of Ada with just the core features implemented and hence
> without vast amounts of required runtime library support could
> serve that purpose.
 
> Think of something that had the kind of functionality of a beefed up
> version of Oberon with all of the Ada type safety features imported
> into it for example.

I'm a  in position to talk, and I know peanuts about Oberon, but can I ask you something... What is "core" for you ? Is tasking part of it ? Full-featured generics ? Support for exceptions or clause representations ? Class-wide programming and interfaces ? Or what do you not feel as essential ?
I'm sure there's a bunch others would deem essential and "core". But I am sure too, those things put together already make for a big piece of work for compiler designers.
Remove any of it, Ada will feel hollow... Or I just found myself a purist :-P
Plus, if it's only for having a safer and nicer equivalent to D or Rust, it's not worth the effort, and I doubt people will even consider.

Re: Five Years After

[Shark8]

On Wednesday, January 24, 2018 at 8:12:51 AM UTC-7, Mehdi Saada wrote:
> > There's serious potential for a good small language that could serve
> > as an easily implemented C language replacement. It's possible that
> > a subset of Ada with just the core features implemented and hence
> > without vast amounts of required runtime library support could
> > serve that purpose.
>  
> > Think of something that had the kind of functionality of a beefed up
> > version of Oberon with all of the Ada type safety features imported
> > into it for example.
> 
> I'm a  in position to talk, and I know peanuts about Oberon, but can I ask you something... What is "core" for you ? Is tasking part of it ? Full-featured generics ? Support for exceptions or clause representations ? Class-wide programming and interfaces ? Or what do you not feel as essential ?
> I'm sure there's a bunch others would deem essential and "core". But I am sure too, those things put together already make for a big piece of work for compiler designers.
> Remove any of it, Ada will feel hollow... Or I just found myself a purist :-P
> Plus, if it's only for having a safer and nicer equivalent to D or Rust, it's not worth the effort, and I doubt people will even consider.

I rather agree; but if there was a small "core" replacement for C, I think it would have to be (1) representation clauses, (2) tasking, and (3) generics.

Re: Five Years After

[Simon Clubley]

On 2018-01-24, Shark8 <onewingedshark@gmail.com> wrote:
> On Wednesday, January 24, 2018 at 8:12:51 AM UTC-7, Mehdi Saada wrote:
>> > There's serious potential for a good small language that could serve
>> > as an easily implemented C language replacement. It's possible that
>> > a subset of Ada with just the core features implemented and hence
>> > without vast amounts of required runtime library support could
>> > serve that purpose.
>>  
>> > Think of something that had the kind of functionality of a beefed up
>> > version of Oberon with all of the Ada type safety features imported
>> > into it for example.
>> 
>> I'm a  in position to talk, and I know peanuts about Oberon, but can I ask you something... What is "core" for you ? Is tasking part of it ? Full-featured generics ? Support for exceptions or clause representations ? Class-wide programming and interfaces ? Or what do you not feel as essential ?
>> I'm sure there's a bunch others would deem essential and "core". But I am sure too, those things put together already make for a big piece of work for compiler designers.
>> Remove any of it, Ada will feel hollow... Or I just found myself a purist :-P
>> Plus, if it's only for having a safer and nicer equivalent to D or Rust, it's not worth the effort, and I doubt people will even consider.
>
> I rather agree; but if there was a small "core" replacement for C, I think it would have to be (1) representation clauses, (2) tasking, and (3) generics.

Tasking is a really big problem here - it requires a lot of RTL/OS support.

The overall goal for me would be to bring the advantages of Ada to areas
where it is not currently used for various reasons. That means a number
of practical tradeoffs need to be made.

The language is great but the compiler situation is absolutely _horrible_.

The compilers are only available for a limited number of platforms,
code written in the freely available Adacore compiler (not FSF compiler)
is subject to mandatory licencing under the GPL, and the full language
is so heavy that writing a full Ada compiler from scratch is a massive
undertaking.

There is however a small core in the Ada language that could bring
benefits elsewhere but without all the overhead of a full blown
Ada implementation.

When talking about a C replacement, you need:

1) Something that can easily generate code to run on bare metal without
OS support and on a wide range of targets in general.

2) Compilers that are easily portable to a wide range of environments.
[Note that the environment the compiler runs on may not be the same as
the environment it generates code for so this is different from 1) above.]

3) Compilers that are a lot easier to write than a current Ada compiler is.

4) The ability to write library code without the caller needing to know
that it is calling code written in Ada.

5) There must be no licence restrictions on what the user can do with
the generated code.

Notice that none of the above items talk about the language features.
They do however talk about some of the various practical reasons why
Ada is not used more than it currently is.

Oh, and about item (4). Apart from needing to call adainit/adafinal,
there's this little gem taken from:

https://gcc.gnu.org/onlinedocs/gnat_ugn/Binding-with-Non-Ada-Main-Programs.html

|Currently the GNAT run time requires a FPU using 80 bits mode precision. Under
|targets where this is not the default it is required to call
|GNAT.Float_Control.Reset before using floating point numbers (this include
|float computation, float input and output) in the Ada code. A side effect is
|that this could be the wrong mode for the foreign code where floating point
|computation could be broken after this call. 

Simon.

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

Re: Five Years After

[Lucretia]

On Wednesday, 24 January 2018 19:06:52 UTC, Simon Clubley  wrote:

> >> I'm a  in position to talk, and I know peanuts about Oberon, but can I ask you something... What is "core" for you ? Is tasking part of it ? Full-featured generics ? Support for exceptions or clause representations ? Class-wide programming and interfaces ? Or what do you not feel as essential ?

I based on Oberon, the syntax needs to be massaged to take away the Wirthianisms that are just horrible. i.e. Uppercase keywords, ; or . and being optional or not, begin...end everywhere adding bulk.

> > I rather agree; but if there was a small "core" replacement for C, I think it would have to be (1) representation clauses, (2) tasking, and (3) generics.
> 
> Tasking is a really big problem here - it requires a lot of RTL/OS support.

True, but at least you don't have to mess about with pthreads and not know if something's going to work or not. Having an abstracted tasking mechanism also adds to portability.
 
> The language is great but the compiler situation is absolutely _horrible_.

It's a total mess.
 
> The compilers are only available for a limited number of platforms,

As was pointed out in that reddit thread, just look at the targets supported by Lazarus.

> code written in the freely available Adacore compiler (not FSF compiler)
> is subject to mandatory licencing under the GPL, and the full language
> is so heavy that writing a full Ada compiler from scratch is a massive
> undertaking.

Yup.
 
> There is however a small core in the Ada language that could bring
> benefits elsewhere but without all the overhead of a full blown
> Ada implementation.
> 
> When talking about a C replacement, you need:
> 

I agree with all those points, plus

6) Be able to use multiple backends so it's more portable to other targets, i.e. iOS, Android, Switch, PS4 (all using LLVM).

Luke.

Re: Five Years After

[Simon Clubley]

On 2018-01-24, Lucretia <laguest9000@googlemail.com> wrote:
> On Wednesday, 24 January 2018 19:06:52 UTC, Simon Clubley  wrote:
>
> I based on Oberon, the syntax needs to be massaged to take away the
> Wirthianisms that are just horrible. i.e. Uppercase keywords, ; or . and being
> optional or not, begin...end everywhere adding bulk.
>

I think of Oberon as being a really good idea but which is strangled by
some horrible syntax features. The mandatory uppercase keywords is the
number one feature that I dislike about Oberon - it makes Oberon code
look really ugly.

>  
>> The compilers are only available for a limited number of platforms,
>
> As was pointed out in that reddit thread, just look at the targets supported
> by Lazarus.
>

Lazarus is just the IDE on top of Free Pascal. You can use Free Pascal
without needing Lazarus.

I've actually wondered if it's possible to replace the Free Pascal
front end with an Ada front end and then use the existing Free Pascal
optimiser and code generators.

It would be a more lightweight backend than LLVM with an interesting
range of code generators. Of course, actually looking at the Free
Pascal source code (which is on my to-do list for some time in the
future) might quickly reveal that the front end is closely tied to
the back end...

Simon.

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

Re: Five Years After

[Lucretia]

On Thursday, 25 January 2018 00:29:22 UTC, Simon Clubley  wrote:
> On 2018-01-24, Lucretia <me@somewhere.com> wrote:
> > On Wednesday, 24 January 2018 19:06:52 UTC, Simon Clubley  wrote:
> >
> > I based on Oberon, the syntax needs to be massaged to take away the
> > Wirthianisms that are just horrible. i.e. Uppercase keywords, ; or . and being
> > optional or not, begin...end everywhere adding bulk.
> >
> 
> I think of Oberon as being a really good idea but which is strangled by
> some horrible syntax features. The mandatory uppercase keywords is the
> number one feature that I dislike about Oberon - it makes Oberon code
> look really ugly.

As I said above, keywords, begin...end in conditionals/loops, ; and . used where he likes.
 
> > As was pointed out in that reddit thread, just look at the targets supported
> > by Lazarus.
> >
> 
> Lazarus is just the IDE on top of Free Pascal. You can use Free Pascal
> without needing Lazarus.

I know, but most people just call fpc by the Lazarus name.
 

Re: Five Years After

[Shark8]

On Wednesday, January 24, 2018 at 1:34:54 PM UTC-7, Lucretia wrote:
> On Wednesday, 24 January 2018 19:06:52 UTC, Simon Clubley  wrote:
> 
> > >> I'm a  in position to talk, and I know peanuts about Oberon, but can I ask you something... What is "core" for you ? Is tasking part of it ? Full-featured generics ? Support for exceptions or clause representations ? Class-wide programming and interfaces ? Or what do you not feel as essential ?
> 
> I based on Oberon, the syntax needs to be massaged to take away the Wirthianisms that are just horrible. i.e. Uppercase keywords, ; or . and being optional or not, begin...end everywhere adding bulk.

Are upper-case keywords a Wirthianism? AFAIK, Oberon is the only one with case-sensitivity for keywords (Algol-W, Pascal, Modula, and [even if not developed-by, certainly influenced-by Wirth] Ada).

';' as a separator rather than a terminator makes a certain amount of sense -- after all we don't say Function K(A : Integer; B : Character; C : Float;) Return Natural; -- but, OTOH, it *does* essentially necessitate a ";" null-statement, which I think was a good idea to avoid in Ada with "null;".

Also, I much prefer Begin and End to { and } and rather like that Ada chose to go with keywords rather than symbols -- but it was smart to subsume them into things like If/Else/End If and Loop/End Loop via the Sequence_Of_Statements grammar-construct.

Re: Five Years After

[Dennis Lee Bieber]

On Fri, 26 Jan 2018 13:25:00 -0800 (PST), Shark8 <onewingedshark@gmail.com>
declaimed the following:

>
>Are upper-case keywords a Wirthianism? AFAIK, Oberon is the only one with case-sensitivity for keywords (Algol-W, Pascal, Modula, and [even if not developed-by, certainly influenced-by Wirth] Ada).
>
	Pascal User Manual and Report 3rd (aka Jensen&Wirth) uses lowercase
keywords in the text (and mentions that hand written program listings
should underline them to emphasize reserved status). States they may be
written in upper or lowercase.

	Programming in Modula-2 3rd text uses upper case for reserved words --
but the sentence "These latter are written in capital letters and must not
be used as identifiers." is not clear on if upper case is a convention, or
a requirement. Ah, wait -- the "Report" section of the book states "These
reserved words consist exclusively of capital letters ..."
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Five Years After

[Nasser M. Abbasi]

On 1/26/2018 3:25 PM, Shark8 wrote:

> 
> Are upper-case keywords a Wirthianism? AFAIK, Oberon is the only one with case-sensitivity for keywords (Algol-W, Pascal, Modula, and [even if not developed-by, certainly influenced-by Wirth] Ada).

in module3 keywords must be all UPPER CASE.

http://www.faqs.org/faqs/Modula-3-faq/

--Nasser

Re: Five Years After

[Robert Eachus]

On Wednesday, January 24, 2018 at 2:06:52 PM UTC-5, Simon Clubley wrote:

> Oh, and about item (4). Apart from needing to call adainit/adafinal,
> there's this little gem taken from:
> 
> https://gcc.gnu.org/onlinedocs/gnat_ugn/Binding-with-Non-Ada-Main-Programs.html
> 
> |Currently the GNAT run time requires a FPU using 80 bits mode precision. Under
> |targets where this is not the default it is required to call
> |GNAT.Float_Control.Reset before using floating point numbers (this include
> |float computation, float input and output) in the Ada code. A side effect is
> |that this could be the wrong mode for the foreign code where floating point
> |computation could be broken after this call. 

This may look horrible/  It is correct, but not very horrible.  There are four use cases here:

1) You are on a PC with an x86, AMD64 (EM64_T), an IBM mainframe or several other chips?  On the PC there is 80-bit support (old x87 floating-point) but you may prefer to use SIMD 64-bit floating point.  On IBM Z-series, they have a funky 128-bit type which may fit your needs.  Anyway you are covered (just use Float for 32-bits or Long_Float for 64-bits.  If the compiler wants to use 80-bit (IEEE Extended) for multiplication or division with two fixed point operands, or fixed-point value output?  Expect the (GNAT) compiler to handle those cases correctly.

2) You are on a chip which only supports up to 64-bit float types, and need more.  Years ago I wrote a package to do 64-bit float and integer arithmetic on machines which only supported up to 32 bit types.  Hmmm. A 64-bit to 128-bit float package should be possible, one sign bit, a 31-bit exponent and a 97 bit mantissa including a hidden bit shouldn't be too hard.  But this should be a very small class.  When high precision is needed even supercomputers use polynomials in nth roots of one.*

3) You use 64-bit float and really care about the IEEE features like signed zeroes, soft underflow, etc.*  If the settings you care about are supported, this is warning you that the code calling the Ada program may set the values in a way you don't like.  Worse, you need settings which are not supported by the chip.  Tough!  In theory, compilers should provide software to emulate features that are not provided in hardware.  For some settings, this is easy. for some like rounding modes, very, very tough.  You just have to ask yourself if you can live with the hardware.  If you can't why are you living with the hardware?

4) If you don't care about these issues, or more likely don't know enough about them to care?  Put in the GMAT.Float_Control_Reset call if the code will be running on a machine that needs it, and be aware that you could be living in a state of sin.  If both the calling code and the Ada code use floating point types, and you expect to pass floating point parameters or data back and forth?  You are not only living in a state of sin, but may be getting errors all over the place.  (Worse, if you don't run and check test cases with known results, the code may run and produce bad answers!)  In any case you will need to learn enough about (IEEE) floating point types to make sure that both halves of the program are using the same formats.

What punishment goes with case 4?  You may be forced to read Annex G.  Worst case, read Annex G, IEEE 754-3008 and the GNAT documentation.  Reading this might save a lot of pain: http://steve.hollasch.net/cgindex/coding/ieeefloat.html

As an example of the trouble you might get into, C specifies that certain float functions actually take IEEE double values as parameters.  If passed in registers, no real problems, but passing such values on the stack may be lethal.  I can tell you that such dragons exist but I don't even know the names of all the languages where they can be hiding.  (If all else fails, pass the exponent and mantissa separately as integers.  Used to have to do that to interface between DEC VAXes and other minicomputers.)

* Decades ago, there was a special issue of Ada Letters which included the full NUMWG report, including source, I think for test code which disassembled floating-point numbers into exponent and mantissa.  Is that source on-line anywhere?  I think it supports up to 128-bit float types, but the code is designed for accuracy and readability, not speed.
     

Re: Five Years After

[Randy Brukardt]

"Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 
message news:p4alg9$ec0$1@dont-email.me...
...
> There is however a small core in the Ada language that could bring
> benefits elsewhere but without all the overhead of a full blown
> Ada implementation.

That was the original theory behind the Janus/Ada implementation (way back 
in 1981). We eventually abandoned it and commited to a full Ada 83 compiler 
mainly because Ichbiah did such a good job in using each feature to support 
the others. With the possible exception of tasking (and tasking isn't really 
optional in a multicore world), pretty much all of the remainder of Ada 83 
is needed in order to make a solid core.

Otherwise, one ends up having to design replacements for expensive to 
implement features like up-and-down type resolution (needed to support 
overloading on result types, and without that, you will have a lot of issues 
with operator overloading), generics, finalization (if you are dealing with 
Ada 95), and more.

                           Randy.

Re: Five Years After

[Dennis Lee Bieber]

On Wed, 24 Jan 2018 13:50:18 -0000 (UTC), Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> declaimed the following:

>
>Going the other way, a subset of Ada might be useful as well.
>

	Though such would violate the original DoD intent for Ada: no
supersets, no subsets, ONE language to replace the plethora of languages in
use by the military in the 70s.

	A subset would not pass the ACVC, and prior to the DoD releasing "Ada"
as a trademark, could not legally be referred to as supporting the Ada
language.

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Five Years After

[Robert Eachus]

On Wednesday, January 24, 2018 at 8:50:20 AM UTC-5, Simon Clubley wrote:

> I've recently been told that Adacore no longer support VMS. I wonder
> if this is a one-off or part of a larger cutback in the number of
> platforms that Adacore are willing to support.

Special case, I think.  Ada Core was paid by DEC to support everything that DEC Ada did, and Ada 95.  This included support for DEC specific, non-ANSI floating-point types.  I can't imagine supporting those features without a VAX to test on.  Once you turn off your last VAX or Alpha? machine, you can't test the VMS parts of the Ada Core port, even if there are still some users.

I suspect that the DoD was paying for VMS support somewhere, since certain algorithms used by Cheyenne Mountain used those types.  No big deal to change to IEEE standard types as long as all the software was updated together.  The DoD doesn't want to have an argument between different commands and Cheyenne Mountain about whether a particular missile targets a protected area or will miss.  (There are/were VAXen in the various commands, like Southern Command, and at ground launch sites, radar and other sensor sites, etc.)
 

Re: Five Years After

[Dennis Lee Bieber]

On Wed, 24 Jan 2018 09:07:22 -0800 (PST), Robert Eachus
<rieachus@comcast.net> declaimed the following:

>
>Special case, I think.  Ada Core was paid by DEC to support everything that DEC Ada did, and Ada 95.  This included support for DEC specific, non-ANSI floating-point types.  I can't imagine supporting those features without a VAX to test on.  Once you turn off your last VAX or Alpha? machine, you can't test the VMS parts of the Ada Core port, even if there are still some users.
>
>I suspect that the DoD was paying for VMS support somewhere, since certain algorithms used by Cheyenne Mountain used those types.  No big deal to change to IEEE standard types as long as all the software was updated together.  The DoD doesn't want to have an argument between different commands and Cheyenne Mountain about whether a particular missile targets a protected area or will miss.  (There are/were VAXen in the various commands, like Southern Command, and at ground launch sites, radar and other sensor sites, etc.)
> 

	My previous employer runs VMS in a virtualization environment on a
Windows server -- in order to run a validated Ada-83 cross-compiler for
68040. It would cost too much to recertify a different compiler for the
flight software, not to mention the software itself..
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Five Years After

[Jeffrey R. Carter]

On 01/24/2018 02:50 PM, Simon Clubley wrote:
> 
> Going the other way, a subset of Ada might be useful as well.

We shouldn't call it Ada, though. Maybe Stainless (better than Rust).

> There's serious potential for a good small language that could serve
> as an easily implemented C language replacement. It's possible that
> a subset of Ada with just the core features implemented and hence
> without vast amounts of required runtime library support could
> serve that purpose.

Ada 83
+ User-defined finalization for record types
+ Support for passive tasks
+ Support for integers with unsigned representations
+ A decent standard library

would be good. Nice to have would include

+ Relaxed declaration order
+ Object.Operation syntax for record types
+ Hierarchical namespace

and probably some other things not springing to mind ATM.

Going the other way,

Ada 95
- Tagged types
- Anonymous access types
+ User-defined finalization for record types
+ Object.Operation syntax for record types
+ A decent standard library

would be about equivalent.

-- 
Jeff Carter
"You couldn't catch clap in a brothel, silly English K...niggets."
Monty Python & the Holy Grail
19

Re: Five Years After

[Dennis Lee Bieber]

On Wed, 24 Jan 2018 18:55:21 +0100, "Jeffrey R. Carter"
<spam.jrcarter.not@spam.not.acm.org> declaimed the following:

>On 01/24/2018 02:50 PM, Simon Clubley wrote:
>> 
>> Going the other way, a subset of Ada might be useful as well.
>
>We shouldn't call it Ada, though. Maybe Stainless (better than Rust).

	Too close to Steelman? <G>
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Five Years After

[Lucretia]

On Wednesday, 24 January 2018 13:50:20 UTC, Simon Clubley  wrote:

> Going the other way, a subset of Ada might be useful as well.
> 
> There's serious potential for a good small language that could serve
> as an easily implemented C language replacement. It's possible that
> a subset of Ada with just the core features implemented and hence
> without vast amounts of required runtime library support could
> serve that purpose.
> 
> Think of something that had the kind of functionality of a beefed up
> version of Oberon with all of the Ada type safety features imported
> into it for example.

True but what features? With Ada, you need generics to be able to do anything due to the strictness. Would this new Oberon/Ada/C inspired language need generics?

What other features would be required? I'd definitely go with ranged types at least, I like OO, I never got to grips with functional, but due to current hypetrains, people would want at least first class functions. What about pointers?

Luke.

Re: Five Years After

[Simon Clubley]

On 2018-01-24, Lucretia <laguest9000@googlemail.com> wrote:
> On Wednesday, 24 January 2018 13:50:20 UTC, Simon Clubley  wrote:
>
>> Going the other way, a subset of Ada might be useful as well.
>> 
>> There's serious potential for a good small language that could serve
>> as an easily implemented C language replacement. It's possible that
>> a subset of Ada with just the core features implemented and hence
>> without vast amounts of required runtime library support could
>> serve that purpose.
>> 
>> Think of something that had the kind of functionality of a beefed up
>> version of Oberon with all of the Ada type safety features imported
>> into it for example.
>
> True but what features? With Ada, you need generics to be able to do anything
> due to the strictness. Would this new Oberon/Ada/C inspired language need
> generics?
>
> What other features would be required? I'd definitely go with ranged types at
> least, I like OO, I never got to grips with functional, but due to current
> hypetrains, people would want at least first class functions. What about
> pointers?
>

Ranged types (and pointers, but only Ada style pointers) would be
absolutely mandatory. Of course, that then raises the question of
runtime exceptions in some environments... (Maybe the exceptions
could be local to the current source file only).

Generics are an interesting one. The focus in my mind is on keeping
any required runtime support for language features to an absolute
minimum. It's possible to do more in the compiler front end provided
it didn't require massive amounts of design work and coding to
implement specific functionality.

The point would be to keep the language (and hence the compiler and
runtime) lightweight but still have a better language than C.

Simon.

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

Re: Five Years After

[Maciej Sobczak]

> Also having a validated compiler doesn't seem to matter as much as it did in the last century. ;-)

Interestingly, within the safety-critical domain, "validation" (or "qualification", which is a more specialized term) means more than ACATS tests can offer, and outside of this domain nobody cares about it anyway. In some sense, this effort, even though very well-intended and representing an objectively good engineering practice, was simply misplaced.

-- 
Maciej Sobczak * http://www.inspirel.com

Re: Five Years After

[G. B.]

Maciej Sobczak <see.my.homepage@gmail.com> wrote:
>> Also having a validated compiler doesn't seem to matter as much as it
>> did in the last century. ;-)
> 
> Interestingly, within the safety-critical domain, "validation" (or
> "qualification", which is a more specialized term) means more than ACATS
> tests can offer, and outside of this domain nobody cares about it anyway.

In other domains, programmers who care about validation 
will be suffer from despair and ridicule.

Re: Five Years After

[Randy Brukardt]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:292710c7-3520-406f-9e6b-1fb030ada211@googlegroups.com...
>> Also having a validated compiler doesn't seem to matter as much as it did 
>> in the last century. ;-)
>
>Interestingly, within the safety-critical domain, "validation" (or 
>"qualification", which
> is a more specialized term) means more than ACATS tests can offer, and 
> outside
> of this domain nobody cares about it anyway. In some sense, this effort, 
> even
> though very well-intended and representing an objectively good engineering
> practice, was simply misplaced.

Everyone agrees that the ACATS test suite offers a lot of value to both 
implementers and users (implementers because an independently sourced and 
trustworthy set of tests is very helpful to creating and maintaining an Ada 
compiler -- it is especially good IMHO in preventing errors of omission, 
which are often the hardest to find; users because the test suite provides a 
modicum of portability; Ada compilers accept essentially the same language 
since they've all been tested with the same set of tests). This certainly is 
true since I'm paid money every year to maintain and enhance the test 
suite -- that wouldn't be the case if people didn't see a value.

The value to formal testing ("conformity assessment") is substantially less, 
especially nowdays when machines are fast enough that anyone can run the 
ACATS in a few hours. That is, you can do your own testing in a day or two 
to prove that your vendor is actually telling the truth about conformity. 
Why would you want to pay some formal testing $$$ to do what you can do 
yourself?

Thus, I've been spending some of the ACATS effort on making it easier to 
self-test. Using the new(ish) grading tools and some other tools that I'll 
be posting shortly as "submitted tools", one can essentially test a GNAT 
implementation against the ACATS without a lot of hand work. (You do have to 
understand enough about your implementation and your target to configure the 
ACATS itself.) The hope is to get the value of independent testing without 
the costs.

Of course, formal third-party testing is still available if someone wants 
it.

                         Randy.

Re: Five Years After

[Maciej Sobczak]

> Everyone agrees that the ACATS test suite offers a lot of value to both 
> implementers and users (implementers because an independently sourced and 
> trustworthy set of tests is very helpful to creating and maintaining an Ada 
> compiler -- it is especially good IMHO in preventing errors of omission, 
> which are often the hardest to find;

Sorry, but I cannot agree here. There is nothing that saves ACATS authors from errors of omission. The language is itself so complex that creating a complete (and I really mean formally complete) set of requirements is impractical and without such a set it is not possible to create a complete (again, I mean it) set of tests. As a result, there are areas of the language that were quit well understood by language designers and more or less well understood by language users, that are not covered by ACATS tests at all and therefore not properly implemented by compilers. I have myself found several compiler bugs by only playing with and shuffling ideas from textbook examples (and we have discussed them here on this group).

> This certainly is 
> true since I'm paid money every year to maintain and enhance the test 
> suite

Ironically, the bare fact that you are still being paid for this work is itself a proof that these tests are still not complete. ;-) ;-) ;-)

> Ada compilers accept essentially the same language 
> since they've all been tested with the same set of tests).

Unfortunately, no. Every single version of whatever compiler accepts a different language than its previous version. This is how the bugs are fixed (or introduced), among others.

The problem is - non of our programs is really a mashup of unit tests from ACATS, the state space is too big for this. It is really good that the tests run fine. Heck - it's really good that they exist at all! But these facts do not always translate into satisfactory user experience. Ultimately, my intent is to compile my own programs, not the tests - and apparently, the whole concept of compiler testing is too big to extrapolate from a set of unit tests to a set of all possible user programs. Maybe Ada as a language has already crossed the border at which such an approach is valid at all.
In which case a different approach to compiler validation might be needed.

-- 
Maciej Sobczak * http://www.inspirel.com

Re: Five Years After

[Robert Eachus]

On Thursday, January 25, 2018 at 4:09:28 PM UTC-5, Maciej Sobczak wrote:
> > Everyone agrees that the ACATS test suite offers a lot of value to both 
> > implementers and users (implementers because an independently sourced and 
> > trustworthy set of tests is very helpful to creating and maintaining an Ada 
> > compiler -- it is especially good IMHO in preventing errors of omission, 
> > which are often the hardest to find;
> 
> Sorry, but I cannot agree here. There is nothing that saves ACATS authors from errors of omission. The language is itself so complex that creating a complete (and I really mean formally complete) set of requirements is impractical and without such a set it is not possible to create a complete (again, I mean it) set of tests...

Almost every compiler developer is aware of the Halting Problem andGödel's incompleteness theorems.  However many programmers and software engineers, even if they are aware of them, do not 'get' the fact that you are up against them in a practical way whenever you use a compiler.  (Translating: There are legal Ada programs such that your compiler will either incorrectly reject or fail to halt when asked to compile one of those programs.  All compilers have bugs, at least one of which cannot be eliminated.)  In other words, no matter how much testing you do, you cannot eliminate all the bugs in a compiler.

Note that organizations which develop compilers tend to have an informal hierarchy of bugs.  The worst is usually assigned to programs that compile with no error messages but produce incorrect output or behavior.  Cases where the compiler crashes or rejects legal Ada programs tend to come next. Near the bottom of the list are incorrect or misleading error messages.  There is no requirement that some of those exist, but since there are a (countable) infinity of legal Ada programs, and also of illegal Ada programs, there will always be some cases where the compiler can't guess what the programmer had in mind.

> Unfortunately, no. Every single version of whatever compiler accepts a 
> different language than its previous version. This is how the bugs are fixed
> (or introduced), among others.

This is true in theory, but much less true in practice.  The Unix/Linux practice for distributing applications, including compilers is a case in point.  Often you will compile tens of thousands of lines of code with no error messages.  If you do get errors, they are much more likely to be from improper path arguments or directory locations for the tarball.

I used to say that there were two ways I could program (in Ada, Algol, Lisp, Pascal, PL/I and a few other languages):  In one I would produce tens of thousands of clean code with no compiler bugs found.  In the other I felt I was failing if I had less than one compiler bug discovered per 20 source lines. (I don't include C and C++ because even with lint, I have a long way to go from a clean compile to a working program.  In the languages listed, I almost never read the debugger documentation, and often never used the debugger.)

What is the difference?  In one case I would use only vanilla code.  I have more important things to do than debugging or sending in compiler bug reports.  In the other case I would use extreme corners of the language which often went untested by normal test suites.  An example:

with System; use Ascii; procedure Foo;

Many Ada programmers don't know that you can have more than one use clause following any with clause in a context clause.  Or that the use clauses don't have to relate to the with clause in any (semantic) way.  And Ascii is super special, it is a package that can appear in a use clause without being in any preceding with clause.

So should you use corner cases (with sharp corners)?  Only if you are trying to find compiler bugs.  Don't let this prevent you from using most, if not all of Ada.  But if you do need some tricky tasking code, try to keep any generics that interact with the tasking relatively simple.  Using multiple corner cases in one compilation unit is asking for trouble.

Re: Five Years After

[Randy Brukardt]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:e7a16703-b24e-42aa-81fd-7026932d6c32@googlegroups.com...
>> Everyone agrees that the ACATS test suite offers a lot of value to both
>> implementers and users (implementers because an independently sourced and
>> trustworthy set of tests is very helpful to creating and maintaining an 
>> Ada
>> compiler -- it is especially good IMHO in preventing errors of omission,
>> which are often the hardest to find;
>
>Sorry, but I cannot agree here. There is nothing that saves ACATS authors 
>from errors of omission.

Of course there is -- extensive coverage documentation. Of course that's not 
going to find *every* possible omission, but it tries to check that every 
sentence in the Standard is tested at least once.

And please note that "valuable" is not the same as "the only thing anyone 
ever needs"!! The ACATS is not now, and never was, intended to find compiler 
bugs per se. It is intended to prove a level of compliance with the Ada 
Standard - for instance that a task terminates when it is supposed to, and 
not sooner or later. It can't try to check every combination of features - 
such that a task given in a block in a generic subprogram that has as 
discriminant that is a generic formal parameter terminates on time -- that 
would be an impossible task.

> The language is itself so complex that creating a complete (and I really 
> mean
> formally complete) set of requirements is impractical and without such a 
> set it
> is not possible to create a complete (again, I mean it) set of tests.

Nobody is trying to do this, because it would be impossible (practically) 
even if one had unlimited money.

Real compiler testing has to be a combination of black box tests (the ACATS 
test suite being a great example) and tests designed to ensure code coverage 
and other sorts of white box tests. And I think every vendor also has a 
bunch tests created from user bug reports, mainly to try to ensure 
regressions don't happen. But there is no single technique that could 
provide anything like perfection for any real programming language. (Maybe 
for toy subsets.)

> As a result, there are areas of the language that were quit well 
> understood
> by language designers and more or less well understood by language users,
> that are not covered by ACATS tests at all and therefore not properly
> implemented by compilers. I have myself found several compiler bugs by 
> only
> playing with and shuffling ideas from textbook examples (and we have
> discussed them here on this group).

Repeat: The ACATS is not intended to find compiler bugs, only gross mistakes 
in the implementation of Ada features. (The obvious example is not 
implementing something at all.)

Besides, the ACATS only covers about 45% of the first level objectives, 
based on the parts of the Standard that I've analyzed to date. (Coverage 
might be a bit better overall, as some of the very basic sections haven't 
been analyzed yet, like most of the statements in Chapter 5 and expressions 
in Chapter 4.) (A lot of those aren't very interesting or likely, but 
untested is always a possibility for an omission or gross error.) There 
isn't ever going to be enough funding to close that gap.

>> This certainly is true since I'm paid money every year to maintain and
>> enhance the test suite
>
> Ironically, the bare fact that you are still being paid for this work is 
> itself a proof
> that these tests are still not complete. ;-) ;-) ;-)

Completeness is a goal that could never really be reached (probably some 
part of the objectives would be untestable in practice). And it doesn't 
matter, the test suite is still *valuable* even if not *perfect*.

>But these facts do not always translate into satisfactory user experience.

The ACATS has absolutely nothing to do with the user experience.

...
> In which case a different approach to compiler validation might be needed.

It will never be the least bit hard to find a bug in a compiler (for any 
realistic language). Surely not in an Ada compiler, C++ compiler, Java 
compiler, and so on.

At least not until humans are not allowed near computers. ;-)

                                               Randy.

Re: Five Years After

[Mehdi Saada]

Hum, I meant "in _NO_ position to talk". Obvious, but I prefer avoid such an occasion of future self-ridicule ... Please continue.