State of the compiler market

State of the compiler market

[john]

Hi, 

I have honestly been searching on Google for this, but I can't easily find out who produces a commercial (or free) compiler for Ada 2012, other than AdaCore. Can anyone give me some pointers please? 

I've looked at some compilers I've used in the past but they seem to have stagnated around Ada 95.

Also, are there any modern (i.e. Later than Ada 95) compilers for a MIPS target, or for any DSPs? 

Many thanks
John

Re: State of the compiler market

[Luke A. Guest]

<john@mccabe.org.uk> wrote:
> Hi, 
> 
> I have honestly been searching on Google for this, but I can't easily
> find out who produces a commercial (or free) compiler for Ada 2012, other
> than AdaCore. Can anyone give me some pointers please? 
> 
> I've looked at some compilers I've used in the past but they seem to have
> stagnated around Ada 95.
> 
> Also, are there any modern (i.e. Later than Ada 95) compilers for a MIPS
> target, or for any DSPs? 
> 
> Many thanks
> John
> 

That's basically it. 

Re: State of the compiler market

[Per Sandberg]

Well
GCC with is basically it where AdaCore is the main-maintainer of the
  Ada-frontend (gnat) and gdb

And concerning MIPS there is a open cross built on debian:
	https://packages.debian.org/sid/devel/gnat-5-mips-linux-gnu
/Per



Den 2017-02-23 kl. 01:26, skrev john@mccabe.org.uk:
> Hi,
>
> I have honestly been searching on Google for this, but I can't easily find out who produces a commercial (or free) compiler for Ada 2012, other than AdaCore. Can anyone give me some pointers please?
>
> I've looked at some compilers I've used in the past but they seem to have stagnated around Ada 95.
>
> Also, are there any modern (i.e. Later than Ada 95) compilers for a MIPS target, or for any DSPs?
>
> Many thanks
> John
>

Re: State of the compiler market

[gautier_niouzes]

For Ada 2012 it's probably AdaCore's GNAT only so far.
For Ada 2005 there are some other options - whether they are complete is another question. At least PTC ObjectAda can build correctly a program using maps, containers and the dot notation for objects (e.g. GLOBE_3D demos).

Here is a compiler list obtained by googling, then filtered over time:
http://unzip-ada.sourceforge.net/#adacomp

_________________________ 
Gautier's Ada programming 
http://gautiersblog.blogspot.com/search/label/Ada 
NB: follow the above link for a valid e-mail address 

Re: State of the compiler market

[joakimds]

The ICC Ada compiler supports Ada 2005:
http://www.irvine.com/

Best regards,
Joakim Strandberg

Den torsdag 23 februari 2017 kl. 07:01:58 UTC+1 skrev gautier...@hotmail.com:
> For Ada 2012 it's probably AdaCore's GNAT only so far.
> For Ada 2005 there are some other options - whether they are complete is another question. At least PTC ObjectAda can build correctly a program using maps, containers and the dot notation for objects (e.g. GLOBE_3D demos).
> 
> Here is a compiler list obtained by googling, then filtered over time:
> http://unzip-ada.sourceforge.net/#adacomp
> 
> _________________________ 
> Gautier's Ada programming 
> http://gautiersblog.blogspot.com/search/label/Ada 
> NB: follow the above link for a valid e-mail address

Re: State of the compiler market

[Jeffrey R. Carter]

On 02/23/2017 01:26 AM, john@mccabe.org.uk wrote:
>
> I have honestly been searching on Google for this, but I can't easily find out who produces a commercial (or free) compiler for Ada 2012, other than AdaCore. Can anyone give me some pointers please?

It's a sad but true fact that AdaCore is the only company producing an Ada-12 
compiler.

> I've looked at some compilers I've used in the past but they seem to have stagnated around Ada 95.

In 2000, about half of the compiler vendors offered compilers for ISO/IEC 
8652:2007. There are probably fewer vendors now, and about the same number of 
compilers, so that proportion has probably gone up.

-- 
Jeff Carter
"I'll get broads up here like you wouldn't believe.
Swingers. Freaks. Nymphomaniacs. Dental hygienists."
Play It Again, Sam
125

Re: State of the compiler market

[Per Sandberg]

Could agree on that but a fair question is:
How many real compiler-vendors are there fo C and C++?

A "real" vendor is a vendor using a complete different code-base for the 
compiler, not just branding or forking gcc.

/Per
	


Den 2017-02-23 kl. 19:03, skrev Jeffrey R. Carter:
> On 02/23/2017 01:26 AM, john@mccabe.org.uk wrote:
>>
>> I have honestly been searching on Google for this, but I can't easily
>> find out who produces a commercial (or free) compiler for Ada 2012,
>> other than AdaCore. Can anyone give me some pointers please?
>
> It's a sad but true fact that AdaCore is the only company producing an
> Ada-12 compiler.
>
>> I've looked at some compilers I've used in the past but they seem to
>> have stagnated around Ada 95.
>
> In 2000, about half of the compiler vendors offered compilers for
> ISO/IEC 8652:2007. There are probably fewer vendors now, and about the
> same number of compilers, so that proportion has probably gone up.
>

Re: State of the compiler market

[Paul Rubin]

Per Sandberg <per.s.sandberg@bahnhof.se> writes:
> Could agree on that but a fair question is:
> How many real compiler-vendors are there fo C and C++?

Gcc, Clang, icc, Microsoft, I guess that's all the current C++ that I
can think of though there are probably a few more.  "Current" for now
means the compiler supports C++14 or comes pretty close.

There's plenty of C compilers around, especially in the embedded world.
CompCert (compcert.inria.fr) has a formally verified code generator,
which has never been done for Ada.

Re: State of the compiler market

[Randy Brukardt]

...
> I have honestly been searching on Google for this, but I can't easily find 
> out who
> produces a commercial (or free) compiler for Ada 2012, other than AdaCore.
> Can anyone give me some pointers please?

So far as I know, only AdaCore has a full Ada 2012 compiler.

The next release of Janus/Ada will support a smattering of Ada 2012 
features, to go with a smattering of Ada 2007 features, and most (but not 
quite all) of Ada 95. (Customers should be able to try a preview of this 
version next month.)

Both PTC compilers (ObjectAda and Apex) are Ada 2005, as is Irvine.

Everything else seems to be stuck on Ada 95.

                          Randy.

Re: State of the compiler market

[john]

Many thanks for all your replies. This does seem a little unfortunate.

Are any of you using the ICC compiler?I dropped an email to them asking for a bit more info as their website mentions TI DSP support, but the pages about that show it's as being supported on hosts up to Windows XP, and proudly show a link to a TI announcement from 2002.

Re: State of the compiler market

[Ingo M.]

Am Donnerstag, 23. Februar 2017 01:26:19 UTC+1 schrieb jo...@mccabe.org.uk:

> I've looked at some compilers I've used in the past but they seem to have stagnated around Ada 95.

As long as there is no complete official BNF available for the Ada 2012 standard there will be no motivation to develop another compiler. A few years ago I was seriously interested to develop an Ada/C transpiler but I realized that it makes no sense with the current state of scattered documentation. 

There are only the Ada reference manuals and rationales available so that I would have to climb all pieces of information together. This is so time consuming that it's only affordable by a paid developer. That's what (only) Adacore has, hence no competition.

I can understand that Adacore doesn't want competition. However, they will face serious competition by Rust when it's ready for production use.

Re: State of the compiler market

[Jeffrey R. Carter]

On 02/25/2017 11:48 AM, Ingo M. wrote:
>
> As long as there is no complete official BNF available for the Ada 2012
> standard there will be no motivation to develop another compiler. A few years
> ago I was seriously interested to develop an Ada/C transpiler but I realized
> that it makes no sense with the current state of scattered documentation.

So what is Annex P?

http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-P.html

-- 
Jeff Carter
"Oh Lord, bless this thy hand grenade, that with it thou
mayst blow thine enemies to tiny bits, in thy mercy."
Monty Python and the Holy Grail
24

Re: State of the compiler market

[Ingo M.]

> So what is Annex P?
> 
> http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-P.html

I complained about the BNF already years ago. One poster (anon546) confirmed my concerns. Quote: "The BNF has always been in error with missing definitions. It should be corrected but I think it never will be."

http://compgroups.net/comp.lang.ada/ada-2012-bnf-syntax-summary-incomplete/1413223

Maybe your reference is complete this time, or that I am just confused by the syntax which was (is?) not BNF but a variant of BNF.

Whatever, I will take a closer look at it.

Thanks.

Re: State of the compiler market

[Jeffrey R. Carter]

On 02/25/2017 03:25 PM, Ingo M. wrote:
> I complained about the BNF already years ago. One poster (anon546) confirmed
> my concerns. Quote: "The BNF has always been in error with missing
> definitions. It should be corrected but I think it never will be."
>
> http://compgroups.net/comp.lang.ada/ada-2012-bnf-syntax-summary-incomplete/1413223

As was pointed out to you then (2012), twice, and you have chosen to ignore, the 
things you claim are undefined are in fact defined to be equivalent to other 
definitions.

--
Jeff Carter
"Oh Lord, bless this thy hand grenade, that with it thou
mayst blow thine enemies to tiny bits, in thy mercy."
Monty Python and the Holy Grail
24

Re: State of the compiler market

[Dmitry A. Kazakov]

On 2017-02-25 11:48, Ingo M. wrote:

> As long as there is no complete official BNF available for the Ada
> 2012 standard there will be no motivation to develop another compiler. A
> few years ago I was seriously interested to develop an Ada/C transpiler
> but I realized that it makes no sense with the current state of
> scattered documentation.

1. Of course Ada Reference Manual has BNF, it had it since the day one.

2. It is easier to design parser without any generators, so no BNF is 
even needed. Especially when the rules are too cluttered so that they 
rather hide the syntax than explain it.

3. Ada parser is the least problem, so minor that there is nothing to 
talk about. It is a matter of a pair days to work out.

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

Re: State of the compiler market

[G.B.]

On 25/02/2017 12:29, Dmitry A. Kazakov wrote:
> 3. Ada parser is the least problem, so minor that there is nothing to talk about. It is a matter of a pair days to work out.

For example, importing a C function, or calling an Ada
function that is known to use setjmp/longjmp,
how can the Ada compiler optimize use of local variables passed
to that function by reference, or by copy, in the presence of
Ada exceptions?

How do other advertised languages tackle these situations?
I guess that there is the usual rhetorical appeal, such as
to "pragmatism". "We have never heard of such problems."
"Talk to our service representative to see if we can
find a solution for you." $...

Re: State of the compiler market

[Ingo M.]

Dmitry A. Kazakov:

> 1. Of course Ada Reference Manual has BNF, it had it since the day one.

It was (and possibly still is, I'll check it) incomplete, or a variant of BNF with unspecified elements. For details read http://compgroups.net/comp.lang.ada/ada-2012-bnf-syntax-summary-incomplete/1413223

> 2. It is easier to design parser without any generators, so no BNF is 
> even needed. Especially when the rules are too cluttered so that they 
> rather hide the syntax than explain it.

Generators for BNF are usual but I don't like generators. I favor Wirth's Pascal style which is illustrated in his compiler manual. It requires a lot more code to write. However, such code is way easier to maintain (IMHO) than cluttered generator code, in particular if new features are to be added.

> 3. Ada parser is the least problem, so minor that there is nothing to 
> talk about. It is a matter of a pair days to work out.

Maybe, but an incomplete BNF is useless anway.

Re: State of the compiler market

[Dmitry A. Kazakov]

On 2017-02-25 15:46, Ingo M. wrote:
> Dmitry A. Kazakov:
>
>> 1. Of course Ada Reference Manual has BNF, it had it since the day one.
>
> It was (and possibly still is, I'll check it) incomplete, or a
> variant  of BNF with unspecified elements. For details read
> http://compgroups.net/comp.lang.ada/ada-2012-bnf-syntax-summary-incomplete/1413223

Clearly there is no difference if expression is static or not for the 
parser.

>> 3. Ada parser is the least problem, so minor that there is nothing to
>> talk about. It is a matter of a pair days to work out.
>
> Maybe, but an incomplete BNF is useless anway.

That is no reason for lacking commercial Ada compilers or any other 
compilers new or old.

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

Re: State of the compiler market

[Ingo M.]

> Clearly there is no difference if expression is static or not for the 
> parser.

For the parser, yes. Compilers and transpilers however need every piece of information, otherwise there would be no need to mention "static".

Re: State of the compiler market

[Dmitry A. Kazakov]

On 2017-02-25 16:49, Ingo M. wrote:
>> Clearly there is no difference if expression is static or not for the
>> parser.
>
> For the parser, yes. Compilers and transpilers however need every
> piece of information, otherwise there would be no need to mention "static".

Sure, but that has nothing to do with syntax and grammars.

Ada reference manual defines semantics far more detailed and precise 
than manuals of languages enjoying multitude of compilers...

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

Re: State of the compiler market

[G.B.]

On 25/02/2017 15:46, Ingo M. wrote:
> Maybe, but an incomplete BNF is useless anway.

A complete BNF/ABNF/EBNF/you-name-it, if possible, might render
parsing still tricky and might fool authors of parsers into
making too simple assumptions: parsing Ada, e.g., profits from
both look-ahead and look-back(*).

Exceptions from CFG-hammered "pair-y" modes of expression,
thus exceptions in general won't surprise those who are tackling
W3 grammars that have extra-grammatical descriptions besides the
variant of EBNF they use. Hardly a sign of commercial
failure, though. Just not easy.

__
(*) Looking at ubiquitous source code highlighters,
they consistently fail when confronted with Perl or Ada,
in the presence of the tick mark. I'm curious whether there
could exist an Ada grammar sufficiently re-formulated
such that the LL/LR/LALR(k) requirements of these parsers
are satisfied.

Re: State of the compiler market

[Luke A. Guest]

G.B. <bauhaus@notmyhomepage.invalid> wrote:

> __
> (*) Looking at ubiquitous source code highlighters,
> they consistently fail when confronted with Perl or Ada,
> in the presence of the tick mark. I'm curious whether there

Ada needs 2 token look ahead for that exact reason.

Ada's grammar in the RM is flawed in that it doesn't have the pragma's
included and also over complicated.

Re: State of the compiler market

[Dmitry A. Kazakov]

On 2017-02-26 01:11, Luke A. Guest wrote:

> Ada needs 2 token look ahead for that exact reason.

Not really, if the parser is aware of the context. A character literal 
may appear only when an operand is expected. Attribute may only in the 
context of an operation. They never meet.

(The Ada expressions parser in Simple Components does not have look ahead.)

> Ada's grammar in the RM is flawed in that it doesn't have the pragma's
> included and also over complicated.

Yes, it tries to pack some semantics into.

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

Re: State of the compiler market

[Luke A. Guest]

<john@mccabe.org.uk> wrote:
> Hi, 
> 
> I have honestly been searching on Google for this, but I can't easily
> find out who produces a commercial (or free) compiler for Ada 2012, other
> than AdaCore. Can anyone give me some pointers please? 

This is an issue for us open source people, the idea of a new compiler has
been discussed here before. Randy has stated people shouldn't bother, but I
disagree as there are reasons to have another one. One reason being that if
there isn't an alternative there will be one company monopolising the
future of the language and there will be no further work to expand the
language into new areas and will continue to stay in aerospace.

If this happens, a new language derived from Ada would need to happen and
fast. Again, this has been discussed, see the thread started by David
Botton about the getadanow logo competition.

Re: State of the compiler market

[Randy Brukardt]

"Luke A. Guest" <laguest@archeia.com> wrote in message 
news:1813789782.509760763.093426.laguest-archeia.com@nntp.aioe.org...
> <john@mccabe.org.uk> wrote:
>> Hi,
>>
>> I have honestly been searching on Google for this, but I can't easily
>> find out who produces a commercial (or free) compiler for Ada 2012, other
>> than AdaCore. Can anyone give me some pointers please?
>
> This is an issue for us open source people, the idea of a new compiler has
> been discussed here before. Randy has stated people shouldn't bother, but 
> I
> disagree as there are reasons to have another one.

To be fair, I've said people shouldn't bother simply because the odds of it 
reaching a usable state are near zero. As several people have noted, the 
parser is the easy part. Figuring out Ada resolution rules, Ada tasking, the 
Ada optimization rules, and many other things will sap anyone of energy long 
before they complete it. (Note that we never had an intent to build a full 
Ada compiler when we started out. We got pushed that way when others got 
interested. And 35+ years have elapsed...)

I think a better approach would be to convince an existing Ada 95 
implementation to go open source and then enhance that to do the things 
desired (Ada 2020 support, etc.). I'd consider it if (a) there were people 
truly interested and (b) it was reasonably obvious how to monitize the 
result (that is, provide enough revenue for living).

                                Randy.

Re: State of the compiler market

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> I think a better approach would be to convince an existing Ada 95 
> implementation to go open source and then enhance that to do the things 
> desired (Ada 2020 support, etc.). 

1. I found a few google hits for Ada 2020 but nothing like a concrete
list of changes or proposals.  Just "ARG is working on it".  Is there
anything public?

2. Is there really serious difficulty extending an Ada 95 compiler to
handle Ada 2012?

I'm a FOSS supporter myself, but in the case of an alternate Ada
implementation, I'd think the most interesting possibility would be for
someone (maybe Adacore) to team up with the CompCert guys and make a
verified Ada compiler.

> Figuring out Ada resolution rules, Ada tasking, the Ada optimization
> rules, and many other things will sap anyone of energy long before
> they complete it.

How bad is this really?  Is the ARM that hard to read (I've never
tried)?  On the surface Ada doesn't seem particularly harder than Java,
and certainly easier than C++.  But I haven't gone into the deeper
corners or used it much.

Re: State of the compiler market

[antispam]

Paul Rubin <no.email@nospam.invalid> wrote:
> 
> I'm a FOSS supporter myself, but in the case of an alternate Ada
> implementation, I'd think the most interesting possibility would be for
> someone (maybe Adacore) to team up with the CompCert guys and make a
> verified Ada compiler.

Maybe a blasphemy here, but if you go trough full formal
verification does Ada offer significant advantages over C or
C++?  L4.sec guys deliver code via C and apparently this did
not hamper their efforts.  Potentially Ada may be more
productive, however in formaly verified project actual C coding
is likely to be small part of total effort, so replacing
C with Ada should not make much difference.  I would think
that Ada strength is in intermediate area where better
checking in compiler and safer programming practices
lead to faster delivery of reasonably good program.

-- 
                              Waldek Hebisch

Re: State of the compiler market

[Paul Rubin]

antispam@math.uni.wroc.pl writes:
>> team up with the CompCert guys and make a verified Ada compiler.
> Maybe a blasphemy here, but if you go trough full formal verification
> does Ada offer significant advantages over C or C++?

You mean if the application is verified?  Depends on what has been
verified, I suppose ;).  The idea of CompCert is just that the compiler
is verified so there's less worry about compiler bugs.  That's
independent of the verification processes you might use for your
application.

> L4.sec guys deliver code via C and apparently this did
> not hamper their efforts.

SEL4 is apparently around 10 KLOC of C and 480 KLOC of Isabelle/HOL
proofs, and the C was apparently produced (not sure whether manually or
automatically) by some kind of derivation from an executable
specficiation written in Haskell.  I haven't actually read the SEL4
papers but that comes from a quick glance.  They are accessible from
here:  http://ts.data61.csiro.au/projects/seL4/

> Ada strength is in intermediate area where better checking in compiler
> and safer programming practices lead to faster delivery of reasonably
> good program.

This is reasonable to say.  Also Ada's verification tools like SPARK
supply more automation than what's available for C as far as I can tell.

Re: State of the compiler market

[antispam]

Paul Rubin <no.email@nospam.invalid> wrote:
> antispam@math.uni.wroc.pl writes:
> >> team up with the CompCert guys and make a verified Ada compiler.
> > Maybe a blasphemy here, but if you go trough full formal verification
> > does Ada offer significant advantages over C or C++?
> 
> You mean if the application is verified?  Depends on what has been
> verified, I suppose ;).  The idea of CompCert is just that the compiler
> is verified so there's less worry about compiler bugs.  That's
> independent of the verification processes you might use for your
> application.

Once you have verified compilation process it is natural to
go for full formal verfication, from specification to
machine code.  Actually, given that formal verfication
of chips is quite advanced once can go for verfication
up to logic gates.  This is it should be possible to
exclude logic bugs in chips.
 
> > L4.sec guys deliver code via C and apparently this did
> > not hamper their efforts.
> 
> SEL4 is apparently around 10 KLOC of C and 480 KLOC of Isabelle/HOL
> proofs, and the C was apparently produced (not sure whether manually or
> automatically) by some kind of derivation from an executable
> specficiation written in Haskell.  I haven't actually read the SEL4
> papers but that comes from a quick glance.  They are accessible from
> here:  http://ts.data61.csiro.au/projects/seL4/

I read one of the papers and they write that translation
from Haskell to C was done by hand.  They state that
they used subset of Haskell avoiding features hard
to translate to lever level language, so presumably
one could create appropriate translator.  OTOH IIRC
according to their time report writing C code took less
than 15% of total time, so it is possible that doing
translation manually was faster than developing
translator program.

> > Ada strength is in intermediate area where better checking in compiler
> > and safer programming practices lead to faster delivery of reasonably
> > good program.
> 
> This is reasonable to say.  Also Ada's verification tools like SPARK
> supply more automation than what's available for C as far as I can tell.

Few years ago I talked with guy from Microsoft Research doing
formal verfication.  He claimed that their tools checked
more things than SPARK.  And also he claimed that they
needed less annotations (he said that methodology of
SEL4 required about 8 times more annotations than
required by Microsoft tools).  Main point was availability
of quite strong proof engine and automatic generation
of intermediate conditions.

-- 
                              Waldek Hebisch

Re: State of the compiler market

[Paul Rubin]

antispam@math.uni.wroc.pl writes:
> Once you have verified compilation process it is natural to go for
> full formal verfication, from specification to machine code.

Of course that's a very complicated process that's not always feasible.

>> SEL4 is apparently around 10 KLOC of C and 480 KLOC of .. proofs

> according to their time report writing C code took less
> than 15% of total time

Given that it was 2% of the code per the above, 15% of the time doesn't
make it sound easy.

> Few years ago I talked with guy from Microsoft Research doing formal
> verfication.  He claimed that their tools checked more things than
> SPARK. 

I can believe that, especially with older versions of SPARK.  I'd be
interested to know which verification system the guy was describing.

> Main point was availability of quite strong proof engine and automatic
> generation of intermediate conditions.

Stuff is certainly getting better.

Re: State of the compiler market

[antispam]

Paul Rubin <no.email@nospam.invalid> wrote:
> antispam@math.uni.wroc.pl writes:
> > Once you have verified compilation process it is natural to go for
> > full formal verfication, from specification to machine code.
> 
> Of course that's a very complicated process that's not always feasible.
> 
> >> SEL4 is apparently around 10 KLOC of C and 480 KLOC of .. proofs
> 
> > according to their time report writing C code took less
> > than 15% of total time
> 
> Given that it was 2% of the code per the above, 15% of the time doesn't
> make it sound easy.

That 15% included related proof annotations -- going from verified
Haskell to verified C.
 
> > Few years ago I talked with guy from Microsoft Research doing formal
> > verfication.  He claimed that their tools checked more things than
> > SPARK. 
> 
> I can believe that, especially with older versions of SPARK.  I'd be
> interested to know which verification system the guy was describing.

He was from M. Leino group.  IIRC system in question were boogie
and VCC.

> > Main point was availability of quite strong proof engine and automatic
> > generation of intermediate conditions.
> 
> Stuff is certainly getting better.

-- 
                              Waldek Hebisch

Re: State of the compiler market

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87varxjouh.fsf@nightsong.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> I think a better approach would be to convince an existing Ada 95
>> implementation to go open source and then enhance that to do the things
>> desired (Ada 2020 support, etc.).
>
> 1. I found a few google hits for Ada 2020 but nothing like a concrete
> list of changes or proposals.  Just "ARG is working on it".  Is there
> anything public?

The date isn't even firm yet, so it's rather early to read too much into 
that. But all of the work is publically available on Ada-auth.org. Summaries 
and the like will likely wait until wee get closer to a deadline (who can 
tell today if the parallel block and loop stuff will get mature enough to 
include??).

> 2. Is there really serious difficulty extending an Ada 95 compiler to
> handle Ada 2012?

Everything is possible with software, but how much effort are you willing to 
put in? There aren't any major breakages, but there's a lot of new stuff to 
integrate. It took me a month to get the grammar (alone) to be usable and 
not break anything already implemented.

> I'm a FOSS supporter myself, but in the case of an alternate Ada
> implementation, I'd think the most interesting possibility would be for
> someone (maybe Adacore) to team up with the CompCert guys and make a
> verified Ada compiler.
>
>> Figuring out Ada resolution rules, Ada tasking, the Ada optimization
>> rules, and many other things will sap anyone of energy long before
>> they complete it.
>
> How bad is this really?  Is the ARM that hard to read (I've never
> tried)?  On the surface Ada doesn't seem particularly harder than Java,
> and certainly easier than C++.  But I haven't gone into the deeper
> corners or used it much.

Ada resolution is unique in that the type of anything can determine the type 
of an expression. This allows overloading on function results (only) which 
is generally not allowed in other languages. But it also can lead to 
expressions that are very complex to figure out the types:
     F1.all := F2 + F3;
All of these can be overloaded (as well as "+", which acts like a function 
for this purpose), and if there is a unique solution, the Ada compiler has 
to find it.

I often find bizarre (to me) special cases in the code of Janus/Ada, and I 
often try to get rid of them. And then most of the time, I have to put them 
back because they're needed for some wacky ACATS test (or old user bug 
report).

We had 14 man-years of development into our Ada 83 compiler; while I don't 
have an exact number for our Ada 95 compiler, it has to be double that. Some 
of it clearly came from the much smaller hosts of the era, but most of it is 
just Ada being big.

                                 Randy.
 

Re: State of the compiler market

[Luke A. Guest]

Randy Brukardt <randy@rrsoftware.com> wrote:
> "Paul Rubin" <no.email@nospam.invalid> wrote in message 

>> 1. I found a few google hits for Ada 2020 but nothing like a concrete
>> list of changes or proposals.  Just "ARG is working on it".  Is there
>> anything public?
> 
> The date isn't even firm yet, so it's rather early to read too much into 
> that. But all of the work is publically available on Ada-auth.org. Summaries 
> and the like will likely wait until wee get closer to a deadline (who can 
> tell today if the parallel block and loop stuff will get mature enough to 
> include??).

If parallel blocks / loops aren't included, Ada will miss the boat *again*
wrt massively parallel architectures. I can see Ada being used for GPGPU
and shaders, e.g. SPIR-V generation using Ada.

If this happens, sorry to say but we may as well let it die and define a
new language inspired by Ada for future work as Ada will never seem to move
on and expand into different and well deserving areas. 


>> 2. Is there really serious difficulty extending an Ada 95 compiler to
>> handle Ada 2012?
> 
> Everything is possible with software, but 

Not everything. See stupid "I want X impossible software project" on
guru.com

Luke

Re: State of the compiler market

[reinkor]

I got a bit scared from this discussion since I am investing much time in developing an application in Ada. 

Can Adacore's (gnat) public licence safeguard the language is available the coming 10-20 years? I.e. can I stay relaxed? :-)

Adacore and licensing (again), was: Re: State of the compiler market

[Simon Clubley]

On 2017-03-01, reinkor <reinkor@gmail.com> wrote:
> I got a bit scared from this discussion since I am investing much time in
> developing an application in Ada. 
>
> Can Adacore's (gnat) public licence safeguard the language is available the
> coming 10-20 years? I.e. can I stay relaxed? :-)

If you are using Adacore's free GNAT distribution instead of the FSF
distribution then your resulting product will have to be open source.

Are you aware of this ?

Simon.

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

Re: Adacore and licensing (again), was: Re: State of the compiler market

[reinert]

> 
> If you are using Adacore's free GNAT distribution instead of the FSF
> distribution then your resulting product will have to be open source.
> 
> Are you aware of this ?
> 
> Simon.
> 

Yepp. And I assume potential users will hesitate to spend much time to learn to use something closed source from a small business :-)

Re: Adacore and licensing (again), was: Re: State of the compiler market

[Simon Clubley]

On 2017-03-01, reinert <reinkor@gmail.com> wrote:
>> 
>> If you are using Adacore's free GNAT distribution instead of the FSF
>> distribution then your resulting product will have to be open source.
>> 
>> Are you aware of this ?
>> 
>> Simon.
>> 
>
> Yepp. And I assume potential users will hesitate to spend much time to learn to use something closed source from a small business :-)

Good. Given that I have had to explain this to more than one person
over the years who simply hadn't realised this, I just wanted to be
sure you knew.

Simon.

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

Re: Adacore and licensing (again), was: Re: State of the compiler market

[Robert Eachus]

On Wednesday, March 1, 2017 at 1:36:40 PM UTC-5, Simon Clubley wrote:
> On 2017-03-01, reinert <reinkor@gmail.com> wrote:
> >> 
> >> If you are using Adacore's free GNAT distribution instead of the FSF
> >> distribution then your resulting product will have to be open source.
> >> 
> >> Are you aware of this ?
> >> 
> >> Simon.
> >> 
> >
> > Yepp. And I assume potential users will hesitate to spend much time to learn to use something closed source from a small business :-)
> 
> Good. Given that I have had to explain this to more than one person
> over the years who simply hadn't realised this, I just wanted to be
> sure you knew.
> 
> Simon.

Don't scare people too much.  Use whatever version of GNAT (or other compiler) you want during development.  When you get ready to ship a commercial product, the version you use to compile THAT is important, consult your lawyer type stuff.  If all you distribute to your customers is source code, none of that applies.

When I was at MITRE, our group tried to keep code compiling through two different compilers during development.  Occasionally this turned out to be handy, if one compiler didn't work with a new OS release or there was a bug where we needed to wait for a compiler fix. It also let us find errors in the RM, and more interesting, thinkos, where it had to be that way in the standard, but it just seemed wrong.  For example, what happens if there are several ways to evaluate the expression in a static type declaration?  For example:

    Big: constant := 3**300 / 9**140 - 2**31; -- fits in a 32-bit integer.

But evaluating it sure doesn't.  Most compilers now have built-in bignum packages now, but you know that the compiler is not going to evaluate that the way you would.  Are there still cases where (some) compilers will reject otherwise legal programs do to (compile-time) capacity limits?  I'm sure there are, but I'm also sure that they are very hard to reach. 

Re: Adacore and licensing (again), was: Re: State of the compiler market

[Luke A. Guest]

Robert Eachus <rieachus@comcast.net> wrote:

>>> Yepp. And I assume potential users will 
>> Good. Given that I have had to explain this to more than one person
>> over the years who simply hadn't realised this, I just wanted to be
>> sure you knew.
>> 
>> Simon.
> 
> Don't scare people too much.  Use whatever version of GNAT (or other
> compiler) you want during development.  When you get ready to ship a
> commercial product, the version you use to compile THAT is important,
> consult your lawyer type stuff.  If all you distribute to your customers
> is source code, none of that applies.
> 

The issue is there are numerous free compilers for other languages, yet
only one for Ada. So that isn't really an argument for most people here.

Re: Adacore and licensing (again), was: Re: State of the compiler market

[Dennis Lee Bieber]

On Sun, 5 Mar 2017 23:17:43 +0000, Luke A. Guest <laguest@archeia.com>
declaimed the following:

>
>The issue is there are numerous free compilers for other languages, yet
>only one for Ada. So that isn't really an argument for most people here.

	Really? GnuCOBOL (former OpenCOBOL) generates C source code, so one
still has to have a compliant C compiler -- and looks to be the only one
that might implement the Report Writer... WildCat COBOL .NET now redirects
to an "Open-Cobol" mingw. COBOL for GCC supposedly only supports a small
subset of COBOL -- for Linux; Tiny COBOL for Linux aimed at the 85 standard
-- don't know if it supports Report Writer.

	Pity the Fujitsu COBOL 4 that came with my ~2000 text books only
installs on 32-bit Win9X (I could never get the installer to work on WinXT
even in compatibility mode). IT supported the Report Writer AND had a GUI
builder/event handler model.

	Let's see what the Raincode compiler provides (if they approve a
non-company hobbyist download)


	Okay -- looks like a good spread for FORTRAN, even ignoring the
translators to C and Java.



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

Re: Adacore and licensing (again), was: Re: State of the compiler market

[Robert Eachus]

On Sunday, March 5, 2017 at 6:17:46 PM UTC-5, Luke A. Guest wrote:
 
> The issue is there are numerous free compilers for other languages, yet
> only one for Ada. So that isn't really an argument for most people here.

Hmmm. my point is that you don't need to resolve these issues until you have a product ready for sale.  If buying a commercial Ada Core license, or offering your product open source is an issue to be resolved, you may have years before you need an answer.  As for which free version of GNAT to use, you can definitely kick that decision down the road, without restricting your options later.

Finally, if you package your product so that the customer compiles it as part of the installation process?  No cross contamination, and worst case your customer has to issue two mgets or whatever.

Re: Adacore and licensing (again), was: Re: State of the compiler market

[Simon Clubley]

On 2017-03-05, Robert Eachus <rieachus@comcast.net> wrote:
> On Wednesday, March 1, 2017 at 1:36:40 PM UTC-5, Simon Clubley wrote:
>> On 2017-03-01, reinert <reinkor@gmail.com> wrote:
>> >> 
>> >> If you are using Adacore's free GNAT distribution instead of the FSF
>> >> distribution then your resulting product will have to be open source.
>> >> 
>> >> Are you aware of this ?
>> >> 
>> >> Simon.
>> >> 
>> >
>> > Yepp. And I assume potential users will hesitate to spend much time to learn to use something closed source from a small business :-)
>> 
>> Good. Given that I have had to explain this to more than one person
>> over the years who simply hadn't realised this, I just wanted to be
>> sure you knew.
>> 
>> Simon.
>
> Don't scare people too much.  Use whatever version of GNAT (or other
> compiler) you want during development.  When you get ready to ship a
> commercial product, the version you use to compile THAT is important,
> consult your lawyer type stuff.  If all you distribute to your
> customers is source code, none of that applies.
>

I understand what you are saying but you need to look at it another way.

The problem is that people are used to open source tools which don't
impose any licence restrictions on the code they generate.

What if some small outfit simply didn't think to ask the question ?

Goto http://libre.adacore.com/ and tell me where it explicitly says
on that page that your generated code will be covered by the GPL.
You could interpret the language on that page as simply meaning that
you are using an unsupported free compiler with no other restrictions
on it's use.

Even on http://libre.adacore.com/download/configurations there's still
no explicit language about this. You have to click through to a link
called "technology comparison chart" to finally discover that your
generated code will be covered by the GPL.

Now assume however that your small potential Ada developer does follow
these links to discover that they have to pay serious money to use the
Adacore compiler to produce closed source binaries.

How do you that will sit with them when they have fully free or even
low cost access to a wide range of other language options ?

Will they even think to consider that the FSF GNAT is fully free ?

Will they even know the FSF GNAT is a different compiler option to
the Adacore option ?

I like Ada (which should be obvious by now) but the compiler situation
is really lousy.

Simon.

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

Re: Adacore and licensing (again), was: Re: State of the compiler market

[Lucretia]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

> I understand what you are saying but you need to look at it another way.
> 
> The problem is that people are used to open source tools which don't
> impose any licence restrictions on the code they generate.
> 
> What if some small outfit simply didn't think to ask the question ?
> 

> How do you that will sit with them when they have fully free or even
> low cost access to a wide range of other language options ?
> 

Exactly, and this has happened where the small startup cannot afford the support contract.

> Will they even think to consider that the FSF GNAT is fully free ?

Yes, but you still require the support tools, gprtools and in turn the support libs which are then GPLv3.

> 
> Will they even know the FSF GNAT is a different compiler option to
> the Adacore option ?

Which won't be as up to date, there's no comparison table what is and isn't supported in either so it's a matter of hitting the bug box and then having to wait a year for a potential fix,

> 
> I like Ada (which should be obvious by now) but the compiler situation
> is really lousy.

Absolutely is.

Re: Adacore and licensing (again), was: Re: State of the compiler market

[Simon Wright]

Lucretia <laguest9000@googlemail.com> writes:

>> Will they even think to consider that the FSF GNAT is fully free ?
>
> Yes, but you still require the support tools, gprtools and in turn the
> support libs which are then GPLv3.

How does that matter? GCC itself is GPLv3, that has no effect on the
generated code provided that the runtime (e.g. libstdc++, bison as well
as the Ada RTS) has the runtime library exception or equivalent.

The only AdaCore-provided library that might end up in delivered code
and that doesn't have the runtime library exception appears to be
ASIS. Not a huge problem for most of us. And we don't know what will
come with GNAT GPL 2017.

Re: State of the compiler market

[volkert]

On Wednesday, March 1, 2017 at 9:43:42 AM UTC+1, reinkor wrote:
> I got a bit scared from this discussion since I am investing much time in developing an application in Ada. 
> 
> Can Adacore's (gnat) public licence safeguard the language is available the coming 10-20 years? I.e. can I stay relaxed? :-)

I asked my myself the same question. That was 15 years ago. GNAT and its tools are still alive and they are getting better and better. I am also sure, that AdaCore has some longterm contracts ... but in some way, i am sharing you feeling, because i am not sure about the amount of new projects using Ada. 

Volkert, digging into SPARK 2014:-)

Re: State of the compiler market

[J-P. Rosen]

Le 01/03/2017 à 15:28, volkert@komponentenwerkstatt.de a écrit :
>> Can Adacore's (gnat) public licence safeguard the language is
>> available the coming 10-20 years? I.e. can I stay relaxed? :-)
> I asked my myself the same question. That was 15 years ago. GNAT and
> its tools are still alive and they are getting better and better. I
> am also sure, that AdaCore has some longterm contracts ... but in
> some way, i am sharing you feeling, because i am not sure about the
> amount of new projects using Ada.
Don't forget that Gnat (even the Pro version) is free software. If for
some reason AdaCore were to go out of business, any company could take over.

AdaCore tells the story of a customer who asked that the sources be put
in escrow as a safety measure. They replied: "well, if you really want
to waste money... but you already have all the sources!"

-- 
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: State of the compiler market

[G.B.]

On 01/03/2017 15:28, volkert@komponentenwerkstatt.de wrote:
> I am also sure, that AdaCore has some longterm contracts ... but in some way, i am sharing you feeling, because i am not sure about the amount of new projects using Ada.

After yesterday's speech, some of the money that it has
announced as to be spent in US-American infrastructure
might find its way into Ada pockets.
So, if the popularity driven free market doesn't favor
Ada for whatever reason, planning and financing infra-
structure projects might find it a reasonable choice.
Almost needless to say, infrastructure programs tend to
imply long term contracts.

Re: State of the compiler market

[john]

On Wednesday, 1 March 2017 14:28:56 UTC, Volkert  wrote:
> On Wednesday, March 1, 2017 at 9:43:42 AM UTC+1, reinkor wrote:
> > I got a bit scared from this discussion since I am investing much time in developing an application in Ada. 
> > 
> > Can Adacore's (gnat) public licence safeguard the language is available the coming 10-20 years? I.e. can I stay relaxed? :-)
> 
> I asked my myself the same question. That was 15 years ago. GNAT and its tools are still alive and they are getting better and better. I am also sure, that AdaCore has some longterm contracts ... but in some way, i am sharing you feeling, because i am not sure about the amount of new projects using Ada. 

I remember being at a presentation where Joyce Tokar was talking about the contract Tartan had to support their Ada compiler for 25 years or something on (I think) some Raptor system; I think that might've been 1994 or 1995. Presumably there is still some support for it, either from Tartan Software, Inc, for the TMS320C3x and C4x, or DDC-I for the M68K, i960 and Mil-Std-1750A but it looks like none of those even do Ada95.

Re: State of the compiler market

[Dennis Lee Bieber]

On Mon, 6 Mar 2017 15:15:34 -0800 (PST), john@mccabe.org.uk declaimed the
following:

>I remember being at a presentation where Joyce Tokar was talking about the contract Tartan had to support their Ada compiler for 25 years or something on (I think) some Raptor system; I think that might've been 1994 or 1995. Presumably there is still some support for it, either from Tartan Software, Inc, for the TMS320C3x and C4x, or DDC-I for the M68K, i960 and Mil-Std-1750A but it looks like none of those even do Ada95.

	Not really a surprise... In the realms of avionics and likely other
high-integrity fields, even patching a compiler bug requires
recertification of that compiler (though the recert may only need to study
the section affected by the fix and take credit for previous certification
for the rest) -- along with subsequent recertification of the applications
produced by that compiler. Changing compiler on the level of Ada-83 to
Ada-95 and recertifying the entire software chain would be extremely
costly.

	As an example -- it is cheaper to get a Windows box with an emulator
(Charon-VAX) certified in order to run a previously certified OpenVMS and
Ada-83 cross-development system than to convert the development to a new
Ada compiler running on a different OS and recertify everything (sure, the
application still gets certified for each updates, but that's working from
a known base).

	Afterall, the lifecycle of the target hardware is easily expected to be
20-40 years.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: State of the compiler market

[Jacob Sparre Andersen]

reinkor <reinkor@gmail.com> writes:

> I got a bit scared from this discussion since I am investing much time
> in developing an application in Ada.
>
> Can Adacore's (gnat) public licence safeguard the language is
> available the coming 10-20 years? I.e. can I stay relaxed? :-)

I think you can.

My bet is that Ada will be around at least another 20 years.

At some point we will have accept to break backwards compatibility, but
I can't see how and when it will happen.

Greetings,

Jacob
-- 
»If you're going to have crime,
 it might as well be organized crime.«      -- Lord Vetinari

Re: State of the compiler market

[Lucretia]

On Tuesday, 27 June 2017 09:29:58 UTC+1, Jacob Sparre Andersen  wrote:

> At some point we will have accept to break backwards compatibility, but
> I can't see how and when it will happen.

Some people have been saying this for years, but how long it long enough to wait? I think it's worth starting to look at this now.

Luke

Re: State of the compiler market

[Dmitry A. Kazakov]

On 28/06/2017 12:40, Lucretia wrote:
> On Tuesday, 27 June 2017 09:29:58 UTC+1, Jacob Sparre Andersen  wrote:
> 
>> At some point we will have accept to break backwards compatibility, but
>> I can't see how and when it will happen.
> 
> Some people have been saying this for years, but how long it long
> enough to wait? I think it's worth starting to look at this now.

I don't think is would be necessary to break much. I like to think about 
it as reworking the type system and expressing existing things on that 
basis.

Even generics can be left as they are once the need of having them 
disappear. You just move to them the Annex J.

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

Re: State of the compiler market

[Luke A. Guest]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:


> Even generics can be left as they are once the need of having them 
> disappear. You just move to them the Annex J.
> 

You need generics in a strongly typed language, without them you can't do
much.

More needs to be done in the standard library, like other languages include
things that are expected as standard.

Re: State of the compiler market

[Dmitry A. Kazakov]

On 28/06/2017 15:54, Luke A. Guest wrote:
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> 
>> Even generics can be left as they are once the need of having them
>> disappear. You just move to them the Annex J.
> 
> You need generics in a strongly typed language,

Only if I need it untyped. The core idea of generics is that you can 
create polymorphism outside types just by substituting different formal 
generic parameters into a piece of code. I don't believe this cannot be 
achieved through dynamic polymorphism.

> without them you can't do much.

This requires a demonstration.

> More needs to be done in the standard library, like other languages include
> things that are expected as standard.

I have my reservations about having a large standard library. It is nice 
to have some things ready to use but it also makes people lazily 
choosing a solution which may be not suitable for the problem at hand.

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

Re: State of the compiler market

[Shark8]

On Wednesday, June 28, 2017 at 4:40:55 AM UTC-6, Lucretia wrote:
> On Tuesday, 27 June 2017 09:29:58 UTC+1, Jacob Sparre Andersen  wrote:
> 
> > At some point we will have accept to break backwards compatibility, but
> > I can't see how and when it will happen.
> 
> Some people have been saying this for years, but how long it long enough to wait? I think it's worth starting to look at this now.
> 
> Luke

I think it might be.
One thing that might be good to do is look into how to make the language smaller -- for example, if there were a way to define "abstract interfaces" (to include custom/user-defined attributes), we could simplify the language by defining things like discrete, scalar, numeric, array "abstract interfaces" containing the predefined language attributes. (While at first glance, most of that is just "moving things around" it does allow for some nice consolidation.)

I also think the ability to be able to define [[Long_]Long_]String in terms of the appropriate [[Long_]Long_]Character and having the [[Long_]Long_]String-packages be instantiations thereof would simplify things as well. (This would allow a single 'generic' definition in the standard.)

Re: State of the compiler market

[gautier_niouzes]

Le jeudi 29 juin 2017 03:26:46 UTC+2, Shark8 a écrit :
> On Wednesday, June 28, 2017 at 4:40:55 AM UTC-6, Lucretia wrote:
> > On Tuesday, 27 June 2017 09:29:58 UTC+1, Jacob Sparre Andersen  wrote:
> > 
> > > At some point we will have accept to break backwards compatibility, but
> > > I can't see how and when it will happen.
> > 
> > Some people have been saying this for years, but how long it long enough to wait? I think it's worth starting to look at this now.
> > 
> > Luke
> 
> I think it might be.
> One thing that might be good to do is look into how to make the language smaller [...]

Probably the best is to make a branch of GNAT, call your new language "Beb" (you'd have then Beb.Text_IO, Beb.Numerics, etc.) and start experimenting with it.
I'd have a few wishes like:
- rename String to Fixed_String and Unbounded_String to String
- make Sin, Cos, Log, etc. automatically visible just like "*" for floating-point types
G.
_____________________________________________________________
A free online game in Ada: http://pasta.phyrama.com/game.html

Re: State of the compiler market

[Lucretia]

On Thursday, 29 June 2017 06:46:46 UTC+1, gautier...@hotmail.com  wrote:

> > > Some people have been saying this for years, but how long it long enough to wait? I think it's worth starting to look at this now.
> > > 
> > > Luke
> > 
> > I think it might be.
> > One thing that might be good to do is look into how to make the language smaller [...]
> 
> Probably the best is to make a branch of GNAT, call your new language "Beb" (you'd have then Beb.Text_IO, Beb.Numerics, etc.) and start experimenting with it.
> I'd have a few wishes like:
> - rename String to Fixed_String and Unbounded_String to String
> - make Sin, Cos, Log, etc. automatically visible just like "*" for floating-point types

God no! Remove character and string from standard. Introduce code_points and unicode strings, add "net" packages, add "xml" packages. Basically all the text based stuff the modern world uses and every other language gets for free.

Add a "UI" package so that we can do Object Pascal type stuff easily. Ada can easily do UI or graphics, yet all that stuff in planes is handled by C++, why?

Possibly change the coding styles a bit to try to appeal to the C crowd.

Remove access types in functions, allow in out in them.

Allow custom types to have 'Image and other similar attributes.

That's just a start, but this would really need to be a new language in the same vein as Ada, not a fork.

Re: State of the compiler market

[gautier_niouzes]

> > Probably the best is to make a branch of GNAT, call your new language "Beb" (you'd have then Beb.Text_IO, Beb.Numerics, etc.) and start experimenting with it.
> > I'd have a few wishes like:
> > - rename String to Fixed_String and Unbounded_String to String
> > - make Sin, Cos, Log, etc. automatically visible just like "*" for floating-point types

Lucretia:

> God no!

No to what ?...

> Remove character and string from standard. Introduce code_points and unicode strings, add "net" packages, add "xml" packages. Basically all the text based stuff the modern world uses and every other language gets for free.

Sure. Note that xml is already since a while an "old fad", but this would be clearly needed for legacy stuff. Everybody think to those xml-based zombies that eat resources on enterprise servers...

> Add a "UI" package so that we can do Object Pascal type stuff easily. Ada can easily do UI or graphics, yet all that stuff in planes is handled by C++, why?

At least on the ground there are many UI options, but they are too specific IHMO to be frozen into a standard. But with Beb, you can try it now and see how it works!

> Possibly change the coding styles a bit to try to appeal to the C crowd.
> 
> Remove access types in functions, allow in out in them.
> 
> Allow custom types to have 'Image and other similar attributes.
> 
> That's just a start, but this would really need to be a new language in the same vein as Ada, not a fork.

It could be a new language reusing the experience and testing accumulated with Ada.
G.

Re: State of the compiler market

[Dmitry A. Kazakov]

On 29/06/2017 14:23, gautier_niouzes@hotmail.com wrote:

> It could be a new language reusing the experience and testing
> accumulated with Ada.

What about backward compatibility, existing code base, taking the 
community with?

I don't see any new fundamental discoveries to justify a new language 
design. There are a few things we understand better now, nothing 
incompatible with the Ada core.

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

Re: State of the compiler market

[Lucretia]

On Thursday, 29 June 2017 13:23:56 UTC+1, gautier...@hotmail.com  wrote:

> > God no!
> 
> No to what ?...

The current string mess. Remove it all and start again.

> > Remove character and string from standard. Introduce code_points and unicode strings, add "net" packages, add "xml" packages. Basically all the text based stuff the modern world uses and every other language gets for free.
> 
> Sure. Note that xml is already since a while an "old fad", but this would be clearly needed for legacy stuff. Everybody think to those xml-based zombies that eat resources on enterprise servers...
> 

Hardly legacy when people are using it for all types of config file stuff, even new stuff.

> > Add a "UI" package so that we can do Object Pascal type stuff easily. Ada can easily do UI or graphics, yet all that stuff in planes is handled by C++, why?
> 
> At least on the ground there are many UI options, but they are too specific IHMO to be frozen into a standard. But with Beb, you can try it now and see how it works!

It would get people going much faster, people like ui's, they like to be able to
see a window and then mess about with controls, then moving to GL and the like. People like graphics. Enable them.
 
> > That's just a start, but this would really need to be a new language in the same vein as Ada, not a fork.
> 
> It could be a new language reusing the experience and testing accumulated with Ada.

Yup, think this would be best, imo.

I'd also simplify the compilation process, have a program which with's it's packages, compile. Don't bother with this whole allow the compiler to take multiple compilation units all at the same time, allow separate compilation, just not the way it is now, it's confusing.

Luke.

Re: State of the compiler market

[G.B.]

On 29.06.17 16:47, Lucretia wrote:
> The current string mess. Remove it all and start again.

While at removing the string mess, remove strings altogether!

Strings' use cases are almost always just UI related:
be it an exception message, compiler diagnostic, an alert
box, and so forth: in the end, strings are almost always at
the human interface level. (Note that hashed keys need not
be strings.)  UI in just strings?

The presence of bare strings in programs is only a legacy and
reminiscent of

   (a) lack of typed data,
   (b) our habits that move towards ADTs slowly.

E.g., a notion of Message conveys not just an array of characters.
Microformats of text exist only because lenient management is
tolerant of stuff that "tends to work in 90% of the cases",
and "everyone else does it like this, plus we're not disruptors".
IT business could use that tolerance of bare strings
in more meaningful IT situations, those that promise higher
ROI than messing about strings.

Note that this posting is demonstrably not just a string.

Re: State of the compiler market

[Jacob Sparre Andersen]

Georg <bauhaus@notmyhomepage.invalid> wrote:

> While at removing the string mess, remove strings altogether!

Interesting point.  While I think I can follow you, I still think we
would need to have quite a lot of string-like types in the language
anyway (file names, directory names, host names, user-entered
characters, user-readable characters, XML, HTML, Ada identifiers, Ada
comments, Ada source file lines, ...).

Greetings,

Jacob
-- 
"I have no prejudice except against Pakistanis, which is normal."

Re: State of the compiler market

[Lucretia]

On Thursday, 29 June 2017 19:27:09 UTC+1, Jacob Sparre Andersen  wrote:
> Georg  wrote:
> 
> > While at removing the string mess, remove strings altogether!
> 
> Interesting point.  While I think I can follow you, I still think we
> would need to have quite a lot of string-like types in the language
> anyway (file names, directory names, host names, user-entered
> characters, user-readable characters, XML, HTML, Ada identifiers, Ada
> comments, Ada source file lines, ...).

There's no such thing as a character, there are only code points. Multiple code points can make up 1 "character." This is why the legacy string/character crap has to go.

But dump all the "other string types" to library level, not language level.

Re: State of the compiler market

[Lucretia]

On Thursday, 29 June 2017 18:22:53 UTC+1, G.B.  wrote:
> On 29.06.17 16:47, Lucretia wrote:
> > The current string mess. Remove it all and start again.
> 
> While at removing the string mess, remove strings altogether!

Well, not really, Unicode all the way. Provide the basics at the "string" / language level, then utils at the lib level.
 
There's just so much stuff I need unicode strings for and we just don't have good enough support for it.

Re: State of the compiler market

[J-P. Rosen]

Le 29/06/2017 à 21:01, Lucretia a écrit :
> There's just so much stuff I need unicode strings for and we just
> don't have good enough support for it.
Well, you have Wide_String if you can stay within the BMP, or
Wide_Wide_String if you need the whole Unicode. There are packages for
character characterization/translation. You have packages for
encoding/decoding UTF8/16/32. What is the extra support you need?

-- 
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: State of the compiler market

[Dmitry A. Kazakov]

On 30/06/2017 07:27, J-P. Rosen wrote:
> Le 29/06/2017 à 21:01, Lucretia a écrit :
>> There's just so much stuff I need unicode strings for and we just
>> don't have good enough support for it.
> Well, you have Wide_String if you can stay within the BMP, or
> Wide_Wide_String if you need the whole Unicode. There are packages for
> character characterization/translation. You have packages for
> encoding/decoding UTF8/16/32. What is the extra support you need?

Encoding must be a part of the string type. This is essential for 
dealing with OS/API bindings. E.g. an UTF-8 string must provide a view 
of an array of octets (for OS/API calls) and a view of an array of code 
points (for the application). The second view must constitute a class. 
We don't need explicit conversions between string types.

But the point is that the language should not have string types at all. 
The type system should be capable to define things as described above at 
the library level.

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

Re: State of the compiler market

[J-P. Rosen]

Le 30/06/2017 à 09:18, Dmitry A. Kazakov a écrit :
> Encoding must be a part of the string type. This is essential for
> dealing with OS/API bindings. E.g. an UTF-8 string must provide a view
> of an array of octets (for OS/API calls) and a view of an array of code
> points (for the application). The second view must constitute a class.
> We don't need explicit conversions between string types.
>
This is your opinion. I don't see why it must constitute a class. I tend
to use the simplest structure available for my need, hence avoid tagged
types unless they are the most appropriate structure.

Moreover, encodings are useful only at the boundary between the
application and the external world, internal processing should use the
internal form, i.e. characters (characters are the abstract notion to
which a code point is associated). Therefore, conversions at the
boundary seem quite appropriate

> But the point is that the language should not have string types at all.
> The type system should be capable to define things as described above at
> the library level.
Then you should be happy. There is absolutely no magic about String in
Ada (as opposed to most other languages), and string types ARE simply
defined in a package (namely Standard). They are known to the compiler
only for attributes that return a string type.

-- 
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: State of the compiler market

[Dmitry A. Kazakov]

On 30/06/2017 09:34, J-P. Rosen wrote:
> Le 30/06/2017 à 09:18, Dmitry A. Kazakov a écrit :
>> Encoding must be a part of the string type. This is essential for
>> dealing with OS/API bindings. E.g. an UTF-8 string must provide a view
>> of an array of octets (for OS/API calls) and a view of an array of code
>> points (for the application). The second view must constitute a class.
>> We don't need explicit conversions between string types.
>>
> This is your opinion. I don't see why it must constitute a class.

Because there is no reason to have exponentially exploding number of 
To_XXX_String functions. Semantically all strings are chains of code points.

> I tend
> to use the simplest structure available for my need, hence avoid tagged
> types unless they are the most appropriate structure.

A type need not to be tagged in order to have a class. Different string 
types have different representations anyway. There is no sense to put a 
tag in there, that will not make view conversion work. The tag will be 
in the String'Class only.

> Moreover, encodings are useful only at the boundary between the
> application and the external world, internal processing should use the
> internal form, i.e. characters (characters are the abstract notion to
> which a code point is associated). Therefore, conversions at the
> boundary seem quite appropriate

True, however for performance reasons many applications tend to deal 
with UTF-8 octets rather than with code points. I doubt anybody uses 
characters at all.

>> But the point is that the language should not have string types at all.
>> The type system should be capable to define things as described above at
>> the library level.
> Then you should be happy. There is absolutely no magic about String in
> Ada (as opposed to most other languages), and string types ARE simply
> defined in a package (namely Standard). They are known to the compiler
> only for attributes that return a string type.

The magic is called array. You have to use magic spell "type ... is 
array (...) of ..." with severe limitation coming with.

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

Re: State of the compiler market

[J-P. Rosen]

Le 30/06/2017 à 10:10, Dmitry A. Kazakov a écrit :
> Semantically all strings are chains of code points.
But different strings may use different encoded character sets, hence
different code points. Typically, Character is ISO8859-1 (Latin-1) while
Wide_Character is the BMP of Unicode (or the full Unicode if you
consider it as UTF-16 encoded, which does not change much from the
programmer's point of view).

> True, however for performance reasons many applications tend to deal 
> with UTF-8 octets rather than with code points. I doubt anybody uses 
> characters at all.
?? I certainly use it, or Wide_Character for ASIS applications. If you
need to sort strings, or do anything more complicated than storing
strings, you'd better decode the strings and not keep them as UTF-8.

> The magic is called array. You have to use magic spell "type ... is 
> array (...) of ..." with severe limitation coming with.
?? Array magic? It is a normal construct of any (almost) programming
language. Unless you are so OO-maniac as to consider that a 10-elements
structure should be an extension of a 9-elements structure...


-- 
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: State of the compiler market

[Dmitry A. Kazakov]

On 30/06/2017 12:10, J-P. Rosen wrote:
> Le 30/06/2017 à 10:10, Dmitry A. Kazakov a écrit :
>> Semantically all strings are chains of code points.
> But different strings may use different encoded character sets, hence
> different code points.

Even when they rarely do, that is a constraint, almost never static as 
you have no control on the text input.

>> True, however for performance reasons many applications tend to deal
>> with UTF-8 octets rather than with code points. I doubt anybody uses
>> characters at all.

> ?? I certainly use it, or Wide_Character for ASIS applications.

You probably do it as a code point, not as a character.

> If you
> need to sort strings, or do anything more complicated than storing
> strings, you'd better decode the strings and not keep them as UTF-8.

Why? The order induced by code points has no more sense that one induced 
by octets. For parsing and compiling I practically never use code 
points. Searching a table of tokens ordered by octets works just fine.

>> The magic is called array. You have to use magic spell "type ... is
>> array (...) of ..." with severe limitation coming with.
> ?? Array magic? It is a normal construct of any (almost) programming
> language.

Any construct which cannot be expressed through other constructs is 
magic per definition.

> Unless you are so OO-maniac as to consider that a 10-elements
> structure should be an extension of a 9-elements structure...

Huh, but arrays are OO-maniacal because an array slice is substitutable 
for array and conversely. In that sense one is an extension of another. 
This type equivalence induces a class of array/slice types, all done 
magically in Ada. The plea is to have a type mechanics to express such 
relationships at the library level.

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

Re: State of the compiler market

[Jacob Sparre Andersen]

Dmitry A. Kazakov wrote:

> But the point is that the language should not have string types at
> all. The type system should be capable to define things as described
> above at the library level.

And that is also how it is in Ada.

The only "hack" in Ada related to strings is that "abc" is a shortcut
for ('a', 'b', 'c').

Greetings,

Jacob
--
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?

Re: State of the compiler market

[Dmitry A. Kazakov]

On 30/06/2017 09:51, Jacob Sparre Andersen wrote:
> Dmitry A. Kazakov wrote:
> 
>> But the point is that the language should not have string types at
>> all. The type system should be capable to define things as described
>> above at the library level.
> 
> And that is also how it is in Ada.

No it is not.

> The only "hack" in Ada related to strings is that "abc" is a shortcut
> for ('a', 'b', 'c').

Lack of user-defined literals is only one problem. There is no class of 
strings with UTF-8 and UCS-4 strings as members of. Thus you cannot 
write a Put_Line working for all strings. In general there is no code 
reuse unless you messing up with generics. You need an instance for each 
string type and for each combination of two, three, four string types. 
And there is no array view of code points. E.g. with UTF-8 you are 
forced to work at the representation level of octets.

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

Re: State of the compiler market

[Lucretia]

On Friday, 30 June 2017 06:27:16 UTC+1, J-P. Rosen  wrote:
> Le 29/06/2017 à 21:01, Lucretia a écrit :
> > There's just so much stuff I need unicode strings for and we just
> > don't have good enough support for it.
> Well, you have Wide_String if you can stay within the BMP, or
> Wide_Wide_String if you need the whole Unicode. There are packages for
> character characterization/translation. You have packages for
> encoding/decoding UTF8/16/32. What is the extra support you need?

1) Character database.
2) Iterators over code points, word boundaries, grapheme clusters, etc.
3) BIDI iterators, if your want to render internationalised text.

That's just for starters. Like I said, a full implementation which is in the standard, not some half arsed thing which is scattered all over the place.

Re: State of the compiler market

[Lucretia]

On Friday, 30 June 2017 12:11:53 UTC+1, Lucretia  wrote:


> 1) Character database.
> 2) Iterators over code points, word boundaries, grapheme clusters, etc.
> 3) BIDI iterators, if your want to render internationalised text.
> 

You just reminded me...

4) Normalisation conversion.
5) Sorting.
6) Unicode regular expressions.
7) Streaming.
8) Unbounded Unicode strings.

The amount of text processing people need to do in the 21st century is massive, Ada should make this easy to do, but it doesn't. Ada needs it's arse dragging into the modern world.

Re: State of the compiler market

[Petter Fryklund]

Den torsdag 29 juni 2017 kl. 13:36:04 UTC+2 skrev Lucretia:
> On Thursday, 29 June 2017 06:46:46 UTC+1, gautier...@hotmail.com  wrote:
> 
> > > > Some people have been saying this for years, but how long it long enough to wait? I think it's worth starting to look at this now.
> > > > 
> > > > Luke
> > > 
> > > I think it might be.
> > > One thing that might be good to do is look into how to make the language smaller [...]
> > 
> > Probably the best is to make a branch of GNAT, call your new language "Beb" (you'd have then Beb.Text_IO, Beb.Numerics, etc.) and start experimenting with it.
> > I'd have a few wishes like:
> > - rename String to Fixed_String and Unbounded_String to String
> > - make Sin, Cos, Log, etc. automatically visible just like "*" for floating-point types
> 
> God no! Remove character and string from standard. Introduce code_points and unicode strings, add "net" packages, add "xml" packages. Basically all the text based stuff the modern world uses and every other language gets for free.
> 
> Add a "UI" package so that we can do Object Pascal type stuff easily. Ada can easily do UI or graphics, yet all that stuff in planes is handled by C++, why?
> 

I agree, it took my then one-year old daughter less than 2 minutes to crash the entertainment system on a flight back from China. 

> Possibly change the coding styles a bit to try to appeal to the C crowd.
> 
> Remove access types in functions, allow in out in them.
> 
> Allow custom types to have 'Image and other similar attributes.
> 
> That's just a start, but this would really need to be a new language in the same vein as Ada, not a fork.

Re: State of the compiler market

[Alejandro R. Mosteo]

On 29/06/17 13:36, Lucretia wrote:

> Remove access types in functions, allow in out in them.

This is in Ada 2012.

Re: State of the compiler market

[Lucretia]

On Friday, 30 June 2017 14:57:48 UTC+1, Alejandro R. Mosteo  wrote:
> On 29/06/17 13:36, Lucretia wrote:
> 
> > Remove access types in functions, allow in out in them.
> 
> This is in Ada 2012.

Yes, I know. But that was added after the access type parameters, which was a hack around no in out.

Re: State of the compiler market

[darkestkhan]

On Friday, June 30, 2017 at 2:19:41 PM UTC, Lucretia wrote:
> On Friday, 30 June 2017 14:57:48 UTC+1, Alejandro R. Mosteo  wrote:
> > On 29/06/17 13:36, Lucretia wrote:
> > 
> > > Remove access types in functions, allow in out in them.
> > 
> > This is in Ada 2012.
> 
> Yes, I know. But that was added after the access type parameters, which was a hack around no in out.

How are you going to pass a subprogram to a subprogram if you remove access type parameters?

Re: State of the compiler market

[Dmitry A. Kazakov]

On 2017-07-01 10:06, darkestkhan wrote:
> On Friday, June 30, 2017 at 2:19:41 PM UTC, Lucretia wrote:
>> On Friday, 30 June 2017 14:57:48 UTC+1, Alejandro R. Mosteo  wrote:
>>> On 29/06/17 13:36, Lucretia wrote:
>>>
>>>> Remove access types in functions, allow in out in them.
>>>
>>> This is in Ada 2012.
>>
>> Yes, I know. But that was added after the access type parameters,
>> which was a hack around no in out.
> 
> How are you going to pass a subprogram to a subprogram if you remove
> access type parameters?

As it should have been:

    function Integrate
             (  X : Points;
                F : function (X : Float) return Float
             )  return Float;
    ...
    Result := Integrate (Data, Sine);

Access types are not required for downward closures.

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

Re: State of the compiler market

[Dirk Craeynest]

In article <o8ted9$8lc$1@franka.jacob-sparre.dk>,
Randy Brukardt <randy@rrsoftware.com> wrote:
>I think a better approach would be to convince an existing Ada 95 
>implementation to go open source and then enhance that to do the things 
>desired (Ada 2020 support, etc.).

Hear, hear!!!

Action for all: talk to your favorite Ada95/2005 vendor, and ask them
about their plans to upgrade to newer Ada features!

Dirk
Dirk.Craeynest@cs.kuleuven.be (for Ada-Belgium/Ada-Europe/SIGAda/WG9)

*** 22nd Intl.Conf.on Reliable Software Technologies - Ada-Europe'2017
*** June 12-16, 2017 *** Vienna, Austria *** http://www.ada-europe.org

Re: State of the compiler market

[Ivan Levashev]

26.02.2017 17:14, Dirk Craeynest пишет:
> Action for all: talk to your favorite Ada95/2005 vendor, and ask them
> about their plans to upgrade to newer Ada features!

For AdaMagic it means AdaCore, and AdaCore means there is no hope.

Elbrus was designed in Soviet times, and there was a great Ada-Elbrus
development system. The Elbrus itself matches Ada design. It has a
tagged memory design and a protected mode being more protected than what
it means on x86. In addition to common system tables there is a module
descriptor table, and data types are encapsulated by hardware. Memory
can only be read by a pointer, and a pointer can only be obtained by
performing valid operations. Some invalid operations are possible, but
they break the tag, and tagged value becomes just a number, not usable
as pointer anymore. In particular, data type can be restricted to be
operated by a particular module, and other modules just can't get into.

Hopefully, Elbrus survived all the tough past-USSR times, but it only
comes now with FORTRAN, C and C++ compilers, so targeting Elbrus is only
possible via Ada-to-C kind of translator (licensed to MapuSoft by
AdaCore). Which still only has this shameful Method (Object) syntax.

Elbrus is similar to CHERI, but CHERI is an academical stuff, and Elbrus
is already being delivered to some work places where technological
independence is a must. Also, CHERI assumed C from the beginning, while
in Soviet times there was no GOST for C, and effectively C-specific
issues were not considered. So it's a CPU for Ada, similar to Rational
R1000. CPU for Ada without corresponding modern Ada compiler.

Asm.js and WebAssembly is another reason to use Ada-to-C translation and
be ashamed of Method (Object) syntax. And have no hope for things to
ever improve.

Best Regards,
Ivan Levashev,
Barnaul

--
If you want to get to the top, you have to start at the bottom

Re: State of the compiler market

[Jacob Sparre Andersen]

john@mccabe.org.uk writes:

> I have honestly been searching on Google for this, but I can't easily
> find out who produces a commercial (or free) compiler for Ada 2012,
> other than AdaCore. Can anyone give me some pointers please?

PTC has announced that they are working on adding Ada 2012 features to
PTC ObjectAda.

If I remember the presentation at Ada-Europe 2017 correctly, the first
step is aspects, contracts, conditional expressions and expression
functions.

Greetings,

Jacob
-- 
"Computer language design is just like a stroll in the park.
 Jurassic Park, that is."                             -- Larry Wall