Ada to Ada Translator ?

Ada to Ada Translator ?

[foo wong]

Hi Everyone

My name is Patrick. I have been posting here for years, I am just keep deleting my google accounts because I don't like being spied on.

It's pretty obvious by now that Adacore is trying to make their free, open source offerings commercially unfriendly, demo-ware only.

There has also been a lot of discussion about compiler bugs.

You probably already know about this but I just found Ada yacc and flex tools:

https://github.com/Ada-France

I only have 1 to 2 hours a week to program so I won't be able to do very much but I think I might have a useful idea and I wanted to share it, maybe people with more programming time will accomplish more than I can.


Why not use ayacc and aflex to create an Ada source to Ada source translator.

Is there a bug Adacore won't attend to?  Why not re-implement that part of the runtime yourself.

I don't think there are any problems with nested subprograms but let's just say there was. Your could run your source through a translator that re-implemented these using trampolines in pure Ada without using nested sub-programs and then you could send the output to gnat.

If we all worked together, over time, we might be able to create a new Ada compiler that had a BSD/LGPL runtime and no more license games.

I will start this if I can, check back with me in 10 years :)

-Patrick

Re: Ada to Ada Translator ?

[Simon Wright]

foo wong <crap@spellingbeewinnars.org> writes:

> It's pretty obvious by now that Adacore is trying to make their free,
> open source offerings commercially unfriendly, demo-ware only.

Surprising statement considering their presence on Github.

> There has also been a lot of discussion about compiler bugs.

You wouldn't expect much discussion about the times when the compiler
got it right.

Re: Ada to Ada Translator ?

[foo wong]

Hi Simon

I am not trying to be confrontational, it's just that you supported this exact statement a year ago:


https://groups.google.com/forum/#!searchin/comp.lang.ada/demo-ware%7Csort:date/comp.lang.ada/cdCDljZtBVg/GF8CmMJ6AQAJ


> It's not that I am missing a feature, it's just that I am tired of
> Adacore's games and I want to have independence from them. I feel like
> they are trying to make free Ada compiler options "demo-ware" for
> their expensive paid options.

Why are you surprised?

-Simon Wright 8/24/18


GPL'ing everything and participating on github does not make them hostile to free software. It's just that they had the same software under GPL that was under more permissive licenses before, why the license change unless they want to force a paid option?

-Patrick

P.S warning half-sleep post

Re: Ada to Ada Translator ?

[foo wong]

sorry, tense error:

"It's just that they had the same"

"It's just that they have the same"

Re: Ada to Ada Translator ?

[Simon Wright]

foo wong <crap@spellingbeewinnars.org> writes:

> I am not trying to be confrontational, it's just that you supported
> this exact statement a year ago:
>
> https://groups.google.com/forum/#!searchin/comp.lang.ada/demo-ware%7Csort:date/comp.lang.ada/cdCDljZtBVg/GF8CmMJ6AQAJ
>
>
>> It's not that I am missing a feature, it's just that I am tired of
>> Adacore's games and I want to have independence from them. I feel like
>> they are trying to make free Ada compiler options "demo-ware" for
>> their expensive paid options.
>
> Why are you surprised?
>
> -Simon Wright 8/24/18

I thought that conversation was about the compiler, this one about other
tools.

> GPL'ing everything and participating on github does not make them
> hostile to free software. It's just that they had the same software
> under GPL that was under more permissive licenses before, why the
> license change unless they want to force a paid option?

AdaCore made a legitimate decision to only make public releases on pure
GPL terms. This gave rise to some hostility.

As I remember, this was because the licence position of libraries that
had been initially released under GMGPL changed; AdaCore stated that the
license was now pure GPL, in spite of downloadable releases of the code
still having the per-file GMGPL licence statement. Interesting conflict
with FSF advice there.

Later on, code for public release had the GCC Runtime Exception
terms automatically stripped.

Now, library code released as part of the Community Edition has the
Runtime Exception stripped, but the equivalent code on Github (where it
exists; e.g. not ASIS) retains it.

Re: Ada to Ada Translator ?

[foo wong]

Thanks Simon but this is still weird-weird-wierd

It's just a bunch of games. I personally can't keep it straight.

If a small company wanted to create an instrument with Ada embedded on let's say an ARM based circuit board, there is just so much non-sense to deal with in the Ada world and it's just so much easier with C++.

Adacore is our leader in the free software world and they are leading us into the abyss .

We really need another compiler. One that is doesn't play license games and that is designed to solve the problem Ada was created for, embedded parallel hardware use.

I am not sure if I can do this but I will fork the older GMGPL code to create it, if I can. It will be small and simple, like the TinyC compiler vs GCC

Re: Ada to Ada Translator ?

[Simon Wright]

foo wong <crap@spellingbeewinnars.org> writes:

> If a small company wanted to create an instrument with Ada embedded on
> let's say an ARM based circuit board, there is just so much non-sense
> to deal with in the Ada world and it's just so much easier with C++.
>
> Adacore is our leader in the free software world and they are leading
> us into the abyss.

Not sure that it's really AdaCore's job to do this; there's a publicity
issue. Maybe the Ada Information Clearinghouse/Ada Resource Association
(https://www.adaic.org) would be a better place? I suspect it's
lightly-staffed.

> We really need another compiler. One that is doesn't play license
> games and that is designed to solve the problem Ada was created for,
> embedded parallel hardware use.

Technically
-----------

It's not the compiler, it's the RTL. The FSF native compiler (which you
would get with e.g. Debian) has no licence games beyond what the FSF GCC
Runtime Exception requires (i.e., practically none).

The CE arm-eabi compiler comes with full-GPL RTLs. However, the
compiler is fully capable of compiling a different RTL, and the tools
will happily work with it.

I started working on my Cortex GNAT RTS[1] because of concerns,
expressed here, similar to the ones you raise (and because it's fun). It
has the FSF Runtime Exception (it has to be GPL-based, because it's
derived mainly from the FSF RTS) and runs over FreeRTOS[2], which
(thankfully) has an MIT licence.

AdaCore's Ada Drivers Library[3] has a BSD 3-clause licence.

[1] https://github.com/simonjwright/cortex-gnat-rts
[2] https://www.freertos.org
[3] https://github.com/AdaCore/Ada_Drivers_Library

Practically
-----------

All very well having a compiler and RTS that could be used to develop
your proprietary product, but if you aren't aware of it you'll choose
C++.

I can't see AdaCore announcing that you can use their CE toolset with
this other RTS, but they can't support it for free (or at all)

Re: Ada to Ada Translator ?

[G.B.]

On 18.05.19 17:26, foo wong wrote:

> We really need another compiler. One that is doesn't play license games and that is designed to solve the problem Ada was created for, embedded parallel hardware use.

In the end, it is the money that you are talking about, am I right?

Money that you don't have or that you do not want to spend on
an Ada compiler when an unsupported C++ compiler is seemingly
cheap or free for use in commercial closed source projects.
But, actually, commercial options for C and C++ seem to be
around $$$ to $$$$, not that different from Ada prices, I think?

Can AdaCore, or any other Ada vendor, pursue a strategy of
giving away a free compiler that allows use in commercial
closed source projects? Perhaps so as to generate an Ada mass
market for embeeded systems that attracts lots of programmers to Ada
who in return will help garner interest in payed Ada tools once they
get absorbed by industry?

(Ada's economic problem, still true or not, seems to be on record as of day One:
the problem that is created by a perception of a government mandate and the
corresponding knee jerk reaction of any reasonably well trained MBA.
"There's big money, so let's get as much as we can, as long as is possible."
Ada prices for embedded are not for the garage shop, nor are offerings
for other languages. And perhaps early Ada pricing is why Ada became
dominantly used in sufficiently funded surroundings (transport, defense).)

> I am not sure if I can do this but I will fork the older GMGPL code to create it, if I can.

At face value, the license exception applies to that very compiler's
sources, unchanged. It does not extend to derivative works which you
seem to have in mind when mentioning to fork.
You don't own GCC copyright, with or without linking exception or GMGPL,
but, to be sure, ask a lawyer first.

Re: Ada to Ada Translator ?

[Simon Wright]

"G.B." <bauhaus@notmyhomepage.invalid> writes:

> At face value, the license exception applies to that very compiler's
> sources, unchanged.

Actually the compiler sources are plain GPL; the RTS sources have the
exception.

> It does not extend to derivative works which you seem to have in mind
> when mentioning to fork.

Agreed that this is a potentially contentious area: the Exception says
that it 'applies to a given file (the "Runtime Library") that bears a
notice placed by the copyright holder of the file stating that the file
is governed by GPLv3 along with this Exception' - are you entitled to
maintain the Exception in a derivative work? if you do, does it count?
(you not being the sole copyright holder).

I've carefully avoided this issue in my Cortex GNAT RTS by assigning the
copyright to the FSF :-)

Re: Ada to Ada Translator ?

[Optikos]

On Sunday, May 19, 2019 at 12:08:33 PM UTC-5, Simon Wright wrote:
> "G.B." <bauhaus@notmyhomepage.invalid> writes:
> 
> > At face value, the license exception applies to that very compiler's
> > sources, unchanged.
> 
> Actually the compiler sources are plain GPL; the RTS sources have the
> exception.
> 
> > It does not extend to derivative works which you seem to have in mind
> > when mentioning to fork.
> 
> Agreed that this is a potentially contentious area: the Exception says
> that it 'applies to a given file (the "Runtime Library") that bears a
> notice placed by the copyright holder of the file stating that the file
> is governed by GPLv3 along with this Exception' - are you entitled to
> maintain the Exception in a derivative work? if you do, does it count?
> (you not being the sole copyright holder).

If a legitimate copyright holder places the Runtime Library Exception in a file, then anyone may create derivative works of that file with the Runtime Library Exception still in effect as long as all the restrictions regarding Target Code and Compilation Process being an Eligible Compilation Process are obeyed (e.g., no intermediate code was emitted then processed by a nonGPL-compliant Compilation Process).  Whether the source code (e.g., incremental maintenance; drastic departure) is the derivative work or whether the object code then executable is the derivative work makes no difference to copyright law; they are all derivative works under the GPL.  If Simon's worry applies to source-code derivative works, then it applies to object-code & executable derivative works as well.

BIGGER ISSUE:
The vastly more germane dicey question legally is whether Patrick's proposed generated Ada-to-Ada source code qualifies as Target Code (and thus gets to enjoy the Runtime Library Exception's generous nonGPL-license permissions for Target Code emitted from an Eligible Compilation Process) or whether it would be deemed the onerous intermediate representation that then decisively revokes the permissions of the Runtime Library Exception for any programmer using the ineligible Compilation Process.

[I am not a lawyer.  This posting is merely a remembrance of my understanding for my own usage.  Please consult a copyright-law & contract-law lawyer if these matters affect you.]

> I've carefully avoided this issue in my Cortex GNAT RTS by assigning the
> copyright to the FSF :-)

Re: Ada to Ada Translator ?

[Simon Wright]

Optikos <optikos@verizon.net> writes:

> The vastly more germane dicey question legally is whether Patrick's
> proposed generated Ada-to-Ada source code qualifies as Target Code
> (and thus gets to enjoy the Runtime Library Exception's generous
> nonGPL-license permissions for Target Code emitted from an Eligible
> Compilation Process) or whether it would be deemed the onerous
> intermediate representation that then decisively revokes the
> permissions of the Runtime Library Exception for any programmer using
> the ineligible Compilation Process.

Seems to me (but of course IANAL) that

   'The "Compilation Process" transforms code entirely represented in
   non-intermediate languages designed for human-written code, and/or in
   Java Virtual Machine byte code, into Target Code. Thus, for example,
   use of source code generators and preprocessors need not be
   considered part of the Compilation Process, since the Compilation
   Process can be understood as starting with the output of the
   generators or preprocessors.'
   
covers Patrick's scheme.

Re: Ada to Ada Translator ?

[Simon Wright]

Optikos <optikos@verizon.net> writes:

> On Sunday, May 19, 2019 at 12:08:33 PM UTC-5, Simon Wright wrote:
>> "G.B." <bauhaus@notmyhomepage.invalid> writes:

>> > It does not extend to derivative works which you seem to have in
>> > mind when mentioning to fork.
>> 
>> Agreed that this is a potentially contentious area: the Exception
>> says that it 'applies to a given file (the "Runtime Library") that
>> bears a notice placed by the copyright holder of the file stating
>> that the file is governed by GPLv3 along with this Exception' - are
>> you entitled to maintain the Exception in a derivative work? if you
>> do, does it count?  (you not being the sole copyright holder).

I was thinking about whether I could modify a file to which the
Exception applied and pass that file on to you retaining the Exception;
since there are now two copyright holders involved.

> If a legitimate copyright holder places the Runtime Library Exception
> in a file, then anyone may create derivative works of that file with
> the Runtime Library Exception still in effect as long as all the
> restrictions regarding Target Code and Compilation Process being an
> Eligible Compilation Process are obeyed

Maybe, maybe not. Where does it say that in the licence(s)?

> Whether the source code (e.g., incremental maintenance; drastic
> departure) is the derivative work or whether the object code then
> executable is the derivative work makes no difference to copyright
> law; they are all derivative works under the GPL.  If Simon's worry
> applies to source-code derivative works, then it applies to
> object-code & executable derivative works as well.

Don't understand why you think this is news.

Re: Ada to Ada Translator ?

[Optikos]

On Sunday, May 19, 2019 at 4:42:03 PM UTC-5, Simon Wright wrote:
> Optikos writes:
> 
> > On Sunday, May 19, 2019 at 12:08:33 PM UTC-5, Simon Wright wrote:
> >> "G.B." <bauhaus@notmyhomepage.invalid> writes:
> 
> >> > It does not extend to derivative works which you seem to have in
> >> > mind when mentioning to fork.
> >> 
> >> Agreed that this is a potentially contentious area: the Exception
> >> says that it 'applies to a given file (the "Runtime Library") that
> >> bears a notice placed by the copyright holder of the file stating
> >> that the file is governed by GPLv3 along with this Exception' - are
> >> you entitled to maintain the Exception in a derivative work? if you
> >> do, does it count?  (you not being the sole copyright holder).
> 
> I was thinking about whether I could modify a file to which the
> Exception applied and pass that file on to you retaining the Exception;
> since there are now two copyright holders involved.
> 
> > If a legitimate copyright holder places the Runtime Library Exception
> > in a file, then anyone may create derivative works of that file with
> > the Runtime Library Exception still in effect as long as all the
> > restrictions regarding Target Code and Compilation Process being an
> > Eligible Compilation Process are obeyed
> 
> Maybe, maybe not. Where does it say that in the licence(s)?

The comprehension of multiple places, taken together:

1) RLE:  “This GCC Runtime Library Exception (‘Exception’) is an •additional permission• under section 7 of the GNU General Public License, version 3 (‘GPLv3’).”
Hence, anything that GPLv3 permits being done to copies of this file still stand as permissible, including Patrick modifying it.

2) RLE: “It applies to a given file (the ‘Runtime Library’) that bears a notice placed by the •copyright holder• of the file stating that the file is governed by GPLv3 along with this Exception.”
Note that FSF is the original copyright holder and that FSF placed RLE notification in the affected file.  But, unless he assigns it to someone else, the right to copy Patrick's modifications to the affected RLE-licensed file reside with Patrick as another copyright holder of the derivative work that contains the modifications.  Patrick would presumably choose to not remove the RLE in his derivative-work copies (although he could do so [just as AdaCore does] to convert them to pure GPLv3 without the RLE.  So “the copyright holder” is FSF for ancestral portions of this RLE-licensed file and “the copyright holder” is Patrick for his modifications.  (Patrick as a matter of convenience to his users might optionally assign his right to copy to FSF to make pull requests possible and to allay any legal fears of Patrick's users, but this is not absolutely required.)

3) GPLv3: “You ••may convey•• a work based on the Program, or the •••modifications••• to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:  … [elided for brevity] …
c) … This License will therefore apply, ••••along with any applicable section 7 additional terms [i.e., the RLE] ••••, to the whole of the work, and all its parts, regardless of how they are packaged.
… [elided for brevity]”
Hence, the RLE-licensed modified file is able to be conveyed (i.e., distributed) as long as the GPLv3 terms & conditions are met.  Presumably Patrick would obey them, so no harm no foul.

Therefore, the text of RLE+GPLv3 clearly overtly state what I stated in a prior posting, without worry and without FUD.

> > Whether the source code (e.g., incremental maintenance; drastic
> > departure) is the derivative work or whether the object code then
> > executable is the derivative work makes no difference to copyright
> > law; they are all derivative works under the GPL.  If Simon's worry
> > applies to source-code derivative works, then it applies to
> > object-code & executable derivative works as well.
> 
> Don't understand why you think this is news.

Simon, if you are worried that modifying RLE-licensed files might cause the RLE to evaporate, then compiling them to object code and linking them as an executable also would cause the RLE to evaporate.  But no such RLE evaporation occurs, neither when compiling to object code nor when linking as an executable.  Once again, the FUD has been dismantled, replaced by plain-language reading of the RLE+GPLv3 that directly states & lucidly teaches its wisdom for the commonperson to understand when reading with comprehension.

[I am not a lawyer.  This posting is merely a remembrance of my understanding for my own usage.  Please consult a copyright-law & contract-law lawyer if these matters affect you.]

Re: Ada to Ada Translator ?

[Simon Wright]

Optikos <optikos@verizon.net> writes:

> Simon, if you are worried that modifying RLE-licensed files might
> cause the RLE to evaporate, then compiling them to object code and
> linking them as an executable also would cause the RLE to evaporate.

Rubbish. I quote section 1 of the RLE:

   You have permission to propagate a work of Target Code formed by
   combining the Runtime Library with Independent Modules, even if such
   propagation would otherwise violate the terms of GPLv3, provided that
   all Target Code was generated by Eligible Compilation Processes. You
   may then convey such a combination under terms of your choice,
   consistent with the licensing of the Independent Modules.

Anyway, no point in discussing this further since neither of us is a
lawyer.

Re: Ada to Ada Translator ?

[Optikos]

On Wednesday, May 22, 2019 at 1:59:57 AM UTC-5, Simon Wright wrote:
> Optikos writes:
> 
> > Simon, if you are worried that modifying RLE-licensed files might
> > cause the RLE to evaporate, then compiling them to object code and
> > linking them as an executable also would cause the RLE to evaporate.
> 
> Rubbish.

Excellent!  We are making progress.  Finally we agree that your unfounded fear is total rubbish.  There is no way for the RLE to evaporate than to violate one one of the terms of the RLE or of the GPLv3.  Modification of an RLE-licensed file is clearly not one of those violations.

> I quote section 1 of the RLE:
> 
>    You have permission to propagate a work of Target Code formed by
>    combining the Runtime Library with Independent Modules, even if such
>    propagation would otherwise violate the terms of GPLv3, provided that
>    all Target Code was generated by Eligible Compilation Processes. You
>    may then convey such a combination under terms of your choice,
>    consistent with the licensing of the Independent Modules.
> 
> Anyway, no point in discussing this further since neither of us is a
> lawyer.

Not where I live.  Each citizen (who is not a mentally impaired person who has been declared wards of the state) is expected to read each contract with comprehension to reach full understanding.  You can bury your head under the sand as an ostrich, but I am not allowed to under the (Texas) system of law in which I live.

Re: Ada to Ada Translator ?

[Simon Wright]

Optikos <optikos@verizon.net> writes:

> On Wednesday, May 22, 2019 at 1:59:57 AM UTC-5, Simon Wright wrote:
>> Optikos writes:
>> 
>> > Simon, if you are worried that modifying RLE-licensed files might
>> > cause the RLE to evaporate, then compiling them to object code and
>> > linking them as an executable also would cause the RLE to evaporate.
>> 
>> Rubbish.
>
> Excellent!  We are making progress.  Finally we agree that your
> unfounded fear is total rubbish.  There is no way for the RLE to
> evaporate than to violate one one of the terms of the RLE or of the
> GPLv3.  Modification of an RLE-licensed file is clearly not one of
> those violations.

Your argument boils down to "if a implies x then b implies x" which is,
as stated, rubbish.

>> Anyway, no point in discussing this further since neither of us is a
>> lawyer.
>
> Not where I live.  Each citizen (who is not a mentally impaired person
> who has been declared wards of the state) is expected to read each
> contract with comprehension to reach full understanding.  You can bury
> your head under the sand as an ostrich, but I am not allowed to under
> the (Texas) system of law in which I live.

If I sign a contract, then in most cases UK law will hold me to it even
if I didn't read it.

Which is much the same as your system in practice; if you're going to
sign a contract, get a real lawyer who does know what they're doing to
check it over first. What do you do when you're buying a house? "read
[the] contract with comprehension to reach full understanding" and then
go ahead and sign without further ado?

Re: Ada to Ada Translator ?

[foo wong]

Unfortunately, this seems like a typical thread here. Lots of bickering and a lot theory. Very little co-operation or offers to join in to help.

First and foremost, I wanted to bring an idea to the Ada community that might help others. I have very little time to program and I would love it if Ada was not tied so tightly to a company that is not helping it to succeed.

Sorry, I am only going to add to the bickering... I am not sure if G.B is affiliated with Adacore but this statement makes me think so:

"Can AdaCore, or any other Ada vendor, pursue a strategy of
giving away a free compiler that allows use in commercial
closed source projects?"

Anyone that is allowed to commit to GCC should not be asking this sort of rhetorical question. All of the other languages supported by GCC are intended to make commercial software easy to develop with GCC. Are the folks behind the other languages withholding code to make more platforms available or releasing GCC code much later then their other offerings posted elsewhere. GNAT is the odd one out and it's an obvious sales ploy.
 
There are so many brilliant people here, if you guys worked together, Ada would not have to be in this state. Randy's posts are helpful in that now I know that Yacc/Flex is enough to build a compiler and I am not even proposing a compiler but rather an Ada to Ada source translator.

All libraries are written in Ada. Just to stick with the topic I brought up earlier, if nested subprograms were translated into more primitive Ada code, then the translator would translate any library code. The only grammar that is required is for core Ada.

Also I would like to mention that the worst thing that Adacore is doing is with holding new targets. They bought up Ada vendors that had support for various targets but they did not merge this into GNAT FSF. Now there is support for ARM but there could have been long ago but the ARM support is coming with strings attached.

I am going to receive a severe mailing list beating for saying this but it seems to me that Adacore has lead FLOSS Ada to a point where it is a fish out of water.

It's great that it is being used for games and web servers and such but Ada has gills and fins, it's supposed to be in the water.

This is not what it was designed to do. It's supposed to be used to control missiles and tanks and could be used for non-military purposes as spin-off. Ada 95 added OO and there there is a ton of stuff like interfaces and whatnot but is any of this needed to fire off a tank shell or missile?

Where is the target support!

I personally don't want to create weapons rather scientific instruments.

Based on this website:
https://wiki.osdev.org/Ada_Bare_bones

These are the parts that the translator would need to translate into more primitive Ada code:

"""

pragma Discard_Names;
pragma Restrictions (No_Enumeration_Maps);
pragma Normalize_Scalars;
pragma Restrictions (No_Exception_Propagation);
pragma Restrictions (No_Finalization);
pragma Restrictions (No_Tasking);
pragma Restrictions (No_Protected_Types);
pragma Restrictions (No_Delay);
pragma Restrictions (No_Recursion);
pragma Restrictions (No_Allocators);
pragma Restrictions (No_Dispatch);
pragma Restrictions (No_Implicit_Dynamic_Code);
pragma Restrictions (No_Secondary_Stack);
"""

but even some of these could be skipped over. If I am the one that ends up doing this, I will only be focused on hardware embedded Ada and I will focus on new targets  and not every last corner-case feature

Re: Ada to Ada Translator ?

[Shark8]

On Wednesday, May 22, 2019 at 6:57:05 AM UTC-6, foo wong wrote:
> Unfortunately, this seems like a typical thread here. Lots of bickering and a lot theory. Very little co-operation or offers to join in to help.
Yes, this is indeed the case in a lot of these discussions, even when the topic is interesting — and one of the reasons I want to do Byron [MIT licensed] is to just get the hell away from all the GPL bullcrap that's so unproductive.

Another reason is to have a free compiler with no entanglements with C. I don't want dependency on clib or anything else for the compiler... that just seems utterly counterproductive from either the security or correctness/provability standpoints.

> First and foremost, I wanted to bring an idea to the Ada community that might help others. I have very little time to program and I would love it if Ada was not tied so tightly to a company that is not helping it to succeed.
I completely understand, and agree with you here — while AdaCore does a lot, it's rather obvious that they aren't interested in moving/marketing Ada outside fairly restricted niches, and I suspect that having alternate & affordable alternatives to GNAT would go a long way to break that mentality.

For Ada/Ada translation, perhaps the most interesting would be some manner of back-porting the new features to old Ada — I imagine being able to compile your Ada2020 down to Ada83 (say for DEC's Ada compiler) would be a *huge* boon to the community — the real question here would be how to integrate the new-features into the generated-code and there are three realizations that I can envision off the top of my head. (1) Generate library/object code + the spec-files to interface with them; (2) Fully generate the execution-code, including things like predicate-checks, explicitly; and (3) Generate the files, but reducing the explicit execution-code as much as possible into a library that is either externally linked or explicit machine-code insertions.

> There are so many brilliant people here, if you guys worked together, Ada would not have to be in this state. Randy's posts are helpful in that now I know that Yacc/Flex is enough to build a compiler and I am not even proposing a compiler but rather an Ada to Ada source translator.
To have as useful a translator as possible your proposed translator would have to understand the underlying semantics of the GNAT extensions and the equivalent in standard-Ada, which might not exist, and so would have to have something similar to the above conceptual Ada2020-to-Ada83 compiler.

> All libraries are written in Ada. Just to stick with the topic I brought up earlier, if nested subprograms were translated into more primitive Ada code, then the translator would translate any library code. The only grammar that is required is for core Ada.
What is the use-case of the "nested subprograms" example? I just don't get it... plus, capturing the context of those subprograms might be a bit more complex than you're thinking: if they use local variables, the the realization might be better as a GENERIC subprogram with those very objects as formal parameters.

> Also I would like to mention that the worst thing that Adacore is doing is withholding new targets. They bought up Ada vendors that had support for various targets but they did not merge this into GNAT FSF. Now there is support for ARM but there could have been long ago but the ARM support is coming with strings attached.
Second-worst; the elimination of DOTNET and JVM targets is really irksome. (And it seems like the long-shot of getting MS to make an Ada-implementation for DOTNET is actually more likely than AdaCore updating their DOTNET implementation.)

> I am going to receive a severe mailing list beating for saying this but it seems to me that Adacore has lead FLOSS Ada to a point where it is a fish out of water.
Why would you get a beating for this?
It's fairly obvious: there are tons of other languages, even those with corporate sponsors [eg Go, Rust], that don't beat the GPL licensing horse. — There are languages that *don't* stir up fear, uncertainty, and doubt with potentially expensive legal processes and thus drive away small/medium businesses.

> It's great that it is being used for games and web servers and such but Ada has gills and fins, it's supposed to be in the water.
> 
> This is not what it was designed to do. It's supposed to be used to control missiles and tanks and could be used for non-military purposes as spin-off. Ada 95 added OO and there there is a ton of stuff like interfaces and whatnot but is any of this needed to fire off a tank shell or missile?
Ada was designed for this, yes; but it was *ALSO* designed to be a GENERAL PURPOSE programming language to replace the literally HUNDREDS of languages being used by the DOD. — It did so, reducing the number of languages in-use by an order of magnitude.

> Where is the target support!
> 
> I personally don't want to create weapons rather scientific instruments.
I'm involved in Astronomy right now, Ada is perfectly suitable for the tasks here; in fact, a *LOT* of complexity could be reduced if we were to have a single, distributed Ada program doing all of our command-and-control as well as data-production. — We could probably reduce the 25-30 computers in-use for data-acquisition/operations to perhaps 8, have a single code-base, and more assurance with respect to scheduling, maintenance, data-correctness, and implementation-correctness.

> Based on this website:
> https://wiki.osdev.org/Ada_Bare_bones
> 
> These are the parts that the translator would need to translate into more primitive Ada code:
> 
> """
> 
> pragma Discard_Names;
> pragma Restrictions (No_Enumeration_Maps);
> pragma Normalize_Scalars;
> pragma Restrictions (No_Exception_Propagation);
> pragma Restrictions (No_Finalization);
> pragma Restrictions (No_Tasking);
> pragma Restrictions (No_Protected_Types);
> pragma Restrictions (No_Delay);
> pragma Restrictions (No_Recursion);
> pragma Restrictions (No_Allocators);
> pragma Restrictions (No_Dispatch);
> pragma Restrictions (No_Implicit_Dynamic_Code);
> pragma Restrictions (No_Secondary_Stack);
> """
> 
> but even some of these could be skipped over. If I am the one that ends up doing this, I will only be focused on hardware embedded Ada and I will focus on new targets and not every last corner-case feature
??

Forgive me, but I don't see how these restriction pragmas dovetail into an Ada-Ada translator... at all. Could you explain how you see them doing so?

Re: Ada to Ada Translator ?

[Optikos]

On Wednesday, May 22, 2019 at 10:24:10 AM UTC-5, Shark8 wrote:
> On Wednesday, May 22, 2019 at 6:57:05 AM UTC-6, foo wong wrote:
> > Just to stick with the topic I brought up earlier, if nested subprograms were translated into more
> > primitive Ada code, then the translator would translate any library code. The only grammar that is
> > required is for core Ada.
> What is the use-case of the "nested subprograms" example? I just don't get it... 

Spark8, please consider the following cascading ramifications.  Why do you think that the ARG has killed off nested subprograms, lambdas, and closures?

The implementation of named nested subprograms facilitates the implementation of unnamed nested subprograms (i.e., lambdas).  The implementation of lambdas facilitates the the implementation of closures.  Closures facilitate functional programming.  Functional programming facilitates correctness proofs.  Having another mechanism for Ada correctness proofs than SPARK facilitates the rise of a true competitor to GNAT+SPARK.  The rise of a true competitor to GNAT+SPARK facilitates the rise of a true direct competitor to AdaCore as a company.  Therefore, rewind:  nip named & unnamed nested subprograms in the bud.

Btw, this cascading-ramification sequence over in C++land could permit the rise of a C++ correctness prover (done all wobbly on shaky C foundations, but still it also could be at least •marketed• as a SPARK+GNAT competitor, even if it isn't as good).

> plus, capturing the
> context of those subprograms might be a bit more complex than you're thinking: if they use local
> variables, the the realization might be better as a GENERIC subprogram with those very objects as
> formal parameters.

As much as I loathe their usage of the C++ template engine as a poor-man's functional programming language with atrocious syntax, Boost C++ libraries can serve as inspiration for how to implement lambdas and closures in the Ada-to-Ada code generator, especially in older Boost libraries targeting older C++ compilers that lack C++11-&-onward language support for lambdas and closures.

> > Based on this website:
> > https://wiki.osdev.org/Ada_Bare_bones
> > 
> > These are the parts that the translator would need to translate into more primitive Ada code:
> > 
> > """
> > 
> > pragma Discard_Names;
> > pragma Restrictions (No_Enumeration_Maps);
> > pragma Normalize_Scalars;
> > pragma Restrictions (No_Exception_Propagation);
> > pragma Restrictions (No_Finalization);
> > pragma Restrictions (No_Tasking);
> > pragma Restrictions (No_Protected_Types);
> > pragma Restrictions (No_Delay);
> > pragma Restrictions (No_Recursion);
> > pragma Restrictions (No_Allocators);
> > pragma Restrictions (No_Dispatch);
> > pragma Restrictions (No_Implicit_Dynamic_Code);
> > pragma Restrictions (No_Secondary_Stack);
> > """
> > 
> > but even some of these could be skipped over. If I am the one that ends up doing this, I will only be
> > focused on hardware embedded Ada and I will focus on new targets and not every last corner-case
> > feature
> ??
> 
> Forgive me, but I don't see how these restriction pragmas dovetail into an Ada-Ada translator... at all.
> Could you explain how you see them doing so?

Patrick is proposing that his Ada-to-Ada code generator would accept all valid GNAT source code.  As such as GNAT-wrapper, it would need to at least parse & accept GNAT extensions so as to pass them through verbatim (and/or modified slightly if they interfere with the not-pass-through portions of the Ada-to-Ada code generator).

What would be really cool would be for the Ada-to-Ada code generator to accept Digital Ada's extensions too, especially a.app, which would permit multistage programming in a compile-time Ada interpreter as a rather direct competitor to MetaOCaml.

Re: Ada to Ada Translator ?

[Randy Brukardt]

"Optikos" <optikos@verizon.net> wrote in message 
news:29eb5a31-64d0-45f3-8c2e-7a715ac8f02d@googlegroups.com...
> Functional programming facilitates correctness proofs.

??? Functional programming mostly facilities inefficiency and madness. :-) 
There's no problem with doing correctness proofs on any sort of code --  
that's the sort of thing optimizers have been doing since people invented 
compilers.

                                 Randy.

Re: Ada to Ada Translator ?

[G. B.]

foo wong <crap@spellingbeewinnars.org> wrote:
> Unfortunately, this seems like a typical thread here. 

It is, addressing typical questions.

> Sorry, I am only going to add to the bickering... I am not sure if G.B is
> affiliated with Adacore but this statement makes me think so:

I‘m not, never was.

> All of the other languages supported by GCC are intended to make
> commercial software easy to develop with GCC. Are the folks behind the
> other languages withholding code to make more platforms available or
> releasing GCC code much later then their other offerings posted elsewhere. 

So lack of free committer-supported runtimes with commercially permissive
licensing it is now...

> GNAT is the odd one out and it's an obvious sales ploy.

Yes, but given the Ada embedded market, what is the incentive to a small
compiler support company of giving their assets away for free?

> There are so many brilliant people here, if you guys worked together, Ada
> would not have to be in this state.

How many professors and exceptionally skillful people have worked person
years to make a single  first Ada compiler with run-time?

Re: Ada to Ada Translator ?

[Optikos]

On Wednesday, May 22, 2019 at 7:33:05 AM UTC-5, Simon Wright wrote:
> Optikos writes:
> 
> > On Wednesday, May 22, 2019 at 1:59:57 AM UTC-5, Simon Wright wrote:
> >> Optikos writes:
> >> 
> >> > Simon, if you are worried that modifying RLE-licensed files might
> >> > cause the RLE to evaporate, then compiling them to object code and
> >> > linking them as an executable also would cause the RLE to evaporate.
> >> 
> >> Rubbish.
> >
> > Excellent!  We are making progress.  Finally we agree that your
> > unfounded fear is total rubbish.  There is no way for the RLE to
> > evaporate than to violate one one of the terms of the RLE or of the
> > GPLv3.  Modification of an RLE-licensed file is clearly not one of
> > those violations.
> 
> Your argument boils down to "if a implies x then b implies x" which is,
> as stated, rubbish.

Your line of reasoning effectively boils down to ‘when an RLE+GPLv3-licensed file is modified, the RLE can (under some interpretation) magically dismantle itself in ways that are not overtly stated in the RLE and that are not overtly stated in th GPLv3’.  I use the if-fallacy-then-fallacy fallacy to be the proverbial flaw in the Persian rug so that you are drawn into the conversation.  Please quote from RLE+GPLv3 to find any support whatsoever for your “maybe not” novel interpretation where the RLE's Grant of Additional Permission can magically dismantle itself if Patrick (or his code generator) simply performs maintenance transformations of RLE-licensed source code (which would leave the RLE notification intact, unlike AdaCore's removal of the RLE each release of GPL Community Edition).

Your “maybe not” is pure FUD.  All that I am asking you to do is quote snippets from RLE+GPLv3 to support your “maybe not” line of reasoning.  So far, you have not done so.

Re: Ada to Ada Translator ?

[Optikos]

On Saturday, May 18, 2019 at 10:26:38 AM UTC-5, foo wong wrote:
> Thanks Simon but this is still weird-weird-wierd
> 
> It's just a bunch of games. I personally can't keep it straight.
> 
> If a small company wanted to create an instrument with Ada embedded on let's say an ARM based circuit
> board, there is just so much non-sense to deal with in the Ada world and it's just so much easier with
> C++.
> 
> Adacore is our leader in the free software world and they are leading us into the abyss .
> 
> We really need another compiler. One that is doesn't play license games and that is designed to solve
> the problem Ada was created for, embedded parallel hardware use.
> 
> I am not sure if I can do this but I will fork the older GMGPL code to create it, if I can. It will be small and
> simple, like the TinyC compiler vs GCC

Patrick, I just investigated GnuCOBOL a little.  As a generator of C code without linking to GCC object code in any way (most especially GnuCOBOL does not dump out information extracted from a C-language AST from GCC), GnuCOBOL does not evoke any of the Target Code versus intermediate representation clauses of the Runtime Library Exception.  Mimicking this architectural principle for your yacc/bison-based and flex-based Ada-to-Ada translator would likewise not risk running afoul of the RLE.

With that it mind, why be interested in the 3.14p release of GNAT, which was the last release licensed under GMGPL?  Your Ada-to-Ada translator would be a mere user of current FSF GNAT (as if it were a human being), not linked to GNAT.  Your generated-Ada source code would run no more licensing risk than any other human-authored source code that gets compiled by FSF GNAT that has the RLE.  (Although stay away from GPL Community Edition of GNAT though if you want to avoid forcing all users' to be strict GPLv3.)

Or were you thinking of using GNAT compiler and its Ada AST in your Ada-to-Ada translator?  There would be license issues galore in this variant.

Btw, your Ada-to-Ada translator would effectively function as the #1 and #3 report of bugs in GNAT and publishing of fixes that I mention along another branch of this thread; the representation of the bug reports in GNAT would be source code instead of a bug database.  That alone would be a valuable contribution to the Ada community as a whole, especially the GNAT subset.

[I am not a lawyer.  This posting is merely a remembrance of my understanding for my own usage.  Please consult a copyright-law & contract-law lawyer if these matters affect you.]

Re: Ada to Ada Translator ?

[foo wong]

Hi Optikos

Thanks for all your great posts and help.

So with the Ada-Yacc/Flex, we are Berkley licensed and that's it. However if I started tearing out pieces from gnat 3.14, the generated code could contain GMGPL code taken from it(Likely after a lot of modification).


Let's say I wanted to implement nested sub-programs, gnat must have trampolines or something in there. I could rip these out without having to write them.

This would mean that the generated code would have to be GMGPL too.

If I didn't do this, everything could be BSD but then I would have to write everything from scratch and that could take quite a lot of time.

BTW, another plus with this, if gnat is not linking in any runtime, and the runtime was created by the source-to-source preprocessor, all of the targets that gcc supports would be possible as long as the preprocessor was able to generator the right support before it reached gnat.
 

-Patrick

Re: Ada to Ada Translator ?

[foo wong]

BTW, Adacore CAN change the license whenever they want and it is legally legitimate but that does not mean it was not done to make their free(as in cost) offerings less appealing. 

Free software projects are supposed to give their users a sense of ownership, Adacore treats it's users like sheep, I don't think that is legitimate

Re: Ada to Ada Translator ?

[Simon Wright]

foo wong <crap@spellingbeewinnars.org> writes:

> Free software projects are supposed to give their users a sense of
> ownership, Adacore treats it's users like sheep, I don't think that is
> legitimate

I think you're wrong about that.

Re: Ada to Ada Translator ?

[G.B.]

On 18.05.19 17:44, foo wong wrote:
> BTW, Adacore CAN change the license whenever they want

What makes you think so?

Statements to the contrary are part of the archive of this
news group.

Re: Ada to Ada Translator ?

[Optikos]

On Friday, May 17, 2019 at 9:21:57 AM UTC-5, foo wong wrote:
> Hi Everyone
> 
> My name is Patrick. I have been posting here for years, I am just keep deleting my google accounts because I don't like being spied on.
> 
> It's pretty obvious by now that Adacore is trying to make their free, open source offerings commercially unfriendly, demo-ware only.
> 
> There has also been a lot of discussion about compiler bugs.
> 
> You probably already know about this but I just found Ada yacc and flex tools:
> 
> https://github.com/Ada-France
> 
> I only have 1 to 2 hours a week to program so I won't be able to do very much but I think I might have a useful idea and I wanted to share it, maybe people with more programming time will accomplish more than I can.
> 
> 
> Why not use ayacc and aflex to create an Ada source to Ada source translator.
> 
> Is there a bug Adacore won't attend to?  Why not re-implement that part of the runtime yourself.
> 
> I don't think there are any problems with nested subprograms but let's just say there was. Your could run your source through a translator that re-implemented these using trampolines in pure Ada without using nested sub-programs and then you could send the output to gnat.
> 
> If we all worked together, over time, we might be able to create a new Ada compiler that had a BSD/LGPL runtime and no more license games.
> 
> I will start this if I can, check back with me in 10 years :)
> 
> -Patrick

There is OneWingedShark/Shark8's Byron partially-completed top-down LL(k) Ada-compiler parser named Byron over on GitHub.
https://github.com/OneWingedShark/Byron

Conversely, if you utilize Yacc & Flex, it would be LR(k) bottom-up parser, which would be an admirable accomplishment in its own right.  It is purported to be more difficult to craft meaningful error messages in LR parsers, because LL parsers can explain in detail what was expected but, without care in crafting the grammar, LR parsers can lack the context to make “hmmm, it looks like you were trying to do /this/, but I found troublesome /that/ instead” type of error messages.  Writing an LR-based (i.e., yacc-based) parser can create an awesome fast parser, but to do so requires a generous amount of expanding the base language's grammar to consider all the commonplace mistakes to build up enough context to emit that aforementioned type of useful error message.  Without that expansion of the base grammar into all the commonplace mistakes that the compiler-user can make, LR grammars tend to emit low-level-detail errors that some people have trouble deciphering due to speaking in terms of the compiler internals instead of speaking in terms of the language definition in the ARM.

Please don't let anyone rain on your parade.  If you feel an itch, go scratch it.  Go forth & prosper, because Ada will be better off due to your efforts.

Conversely, there might be less-effort ways of addressing your GNAT problem than building a new Ada compiler.

1) You could intentionally maintain your own bug database so that this kind of condescension does not occur:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88610

2) You could lead up a team that expands the battery of ACATS tests to which Ada compilers are subjected.  You could tighten the screws on quality control of FSF GNAT:  more ACATS tests in this #2 beget more bug reports in #1 above that get fixed in #3 below.

3) You could lead up a team that mildly forks each point release of FSF GNAT to fix the bugs in #1's bug database above (so that your add-on work is based on the latest FSF output from AdaCore, not latest GPL Community Edition).  Then submit pull requests to your bug fixes to official FSF GNAT.  Of course, AdaCore personnel are the vast majority of the FSF official maintainers, so they might not accept your pull requests, but that would be too bad so sad for them, not you, because you would just keep building out your the-better-Ada-is-over-here reputation, which by its mere existence causes your star to shine brighter than theirs.  Over time your forks could be perceived as the higher-quality FSF GNAT, which would cause some form of rectification to occur regarding official FSF GNAT at the top-brass level (e.g., Richard Stallman).

4) By doing #1 and #2 and #3 you could prove your claims regarding FSF GNAT quality control by laying out your claims in meticulous detail with demonstrable evidence & bug fixes.  This is likely to produce drastically quicker results in drastically improving open-source Ada-compiler quality than building a new compiler from scratch (if LLVM backend and BSD-esque licensing were not the top-priority goals).

Or in fewer words, you could stand up to AdaCore as an equal to wrest a little control away from them by being co-pilot.

Re: Ada to Ada Translator ?

[foo wong]

Thanks for your post Optikos

I am familiar with Byron and I am really rooting for this project.

The thing is, a source-to-source translator would work right away while a genuine compiler would not work until mostly complete.

The translator could just emit Ada code that is built from more and more primitive Ada code until it was trivial to build a true compiler for the output. 

Or this could could never come to pass and gnat/gcc could just compile it without a runtime needed.

Have a great day-Patrick

Re: Ada to Ada Translator ?

[foo wong]

Hi again Optikos

I just wanted to comment on the top down vs bottom compiler topic...

I am 100% certain that Ada could be compiled with yacc/flex alone . This is based on COBOL.

I spent most of 2012 with Ada but I have been with GnuCOBOL from 2013 till present. I can modify the runtime pretty well but I have not spent so much time with the compiler. However, I have spent /*some*/ time with it and I can say that it is highly complex. GnuCOBOl's use of yacc/flex may be a record holder.

COBOL is much-much harder to parse than Ada. There isn't really a standard library. The 2002 revision added OO and you can use classes and methods but for most of the history of COBOL, everything that would normally be a standard library was just made part of the core language. There are hundreds of reserved words but it goes well beyond this as they are used in sentences and the same reserved word has different meanings in different sentences.

GnuCOBOL is a great piece of software and while it is a very bad idea to use to control a tank, it could be used as a basic template for an Ada compiler.

-Patrick

Re: Ada to Ada Translator ?

[Randy Brukardt]

"Optikos" <optikos@verizon.net> wrote in message 
news:64883feb-3e49-4c6a-855c-6673068e970c@googlegroups.com...
...
>Conversely, if you utilize Yacc & Flex, it would be LR(k) bottom-up parser,
>which would be an admirable accomplishment in its own right.

Why? There are a number of such grammars out there, and Janus/Ada was 
designed from the beginning (in 1980!) using an LALR parser. (That was a 
requirement of the class project at the University of Wisconsin that formed 
the basis of Janus/Ada, and we discovered that switching was impractical as 
an LL parser was going to be several times larger than the 48K RAM available 
on CP/M-80. With some clever storage, we got the LR tables to fit with space 
to spare.)

>It is purported to be more difficult to craft meaningful error messages in 
>LR
>parsers, because LL parsers can explain in detail what was expected but,
>without care in crafting the grammar, LR parsers can lack the context to 
>make
>"hmmm, it looks like you were trying to do /this/, but I found troublesome
>/that/ instead" type of error messages.

This is definitely not true and irrelevant at the same time. :-) An LR 
parser has plenty of context (there is always a state that contains a vast 
amount of information). The problem (to the extent that there is one) is 
situations where you have already gone a long ways down an incorrect path 
before finding out a problem -- Ada luckily does not have many of these. 
(The worst one in Janus/Ada is an "is" following a subprogram in a package 
specification; you've gone too far for an correction to fix the situation.)

>Writing an LR-based (i.e., yacc-based) parser can create an awesome fast
>parser, but to do so requires a generous amount of expanding the base
>language's grammar to consider all the commonplace mistakes to build up
>enough context to emit that aforementioned type of useful error message.

Maybe for some languages, but there isn't much of that in Janus/Ada's 
grammar. Instead, error correction is based on the grammar tables 
themselves, and costs for insertion and deletions of tokens. That turns out 
to be cheap, fast, and reliable -- the only issue is getting the costs right 
(and they aren't that critical, they're mainly used to break ties).

But I think that error messages for *syntax* in a compiler are pretty much 
irrelevant these days; it's the IDE's job to check the syntax before calling 
the compiler, and in the IDE you only care about the first error anyway. 
Presuming the check is fast enough (and it is on all but the largest files), 
you check, then fix, then check again until it is correct.

                                         Randy.

Re: Ada to Ada Translator ?

[Optikos]

On Monday, May 20, 2019 at 6:19:55 PM UTC-5, Randy Brukardt wrote:
> "Optikos" wrote in message 
> news:64883feb-3e49-4c6a-855c-6673068e970c@googlegroups.com...
> ...
> >Conversely, if you utilize Yacc & Flex, it would be LR(k) bottom-up parser,
> >which would be an admirable accomplishment in its own right.
> 
> Why? There are a number of such grammars out there, and Janus/Ada was 
> designed from the beginning (in 1980!) using an LALR parser. (That was a 
> requirement of the class project at the University of Wisconsin that formed 
> the basis of Janus/Ada, and we discovered that switching was impractical as 
> an LL parser was going to be several times larger than the 48K RAM available 
> on CP/M-80. With some clever storage, we got the LR tables to fit with space 
> to spare.)

I said “admirable”, not unique.  I was speaking in the context of an open-source Ada language-translator, not a closed-source one.

> >It is purported to be more difficult to craft meaningful error messages in 
> >LR
> >parsers, because LL parsers can explain in detail what was expected but,
> >without care in crafting the grammar, LR parsers can lack the

I meant here:  easily-available-at-hand

> >context

-ual information

> >to make "hmmm, it looks like you were trying to do /this/, but I found
> >troublesome /that/ instead" type of error messages.
> 
> This is definitely not true and irrelevant at the same time. :-) An LR 
> parser has plenty of context (there is always a state that contains a vast 
> amount of information). The problem (to the extent that there is one) is 
> situations where you have already gone a long ways down an incorrect path 
> before finding out a problem

You demonstrated what I was saying:  in some LR reductions, the interesting detail vis a vis interesting abstraction were a too far away from each other to easily stitch back together in a meaningful way, such as for human-friendly error message that isn't speaking in compiler-internal speak (or worse, LR clever-table-compaction-speak).

> -- Ada luckily does not have many of these. 
> (The worst one in Janus/Ada is an "is" following a subprogram in a package 
> specification; you've gone too far for an correction to fix the situation.)
> 
> >Writing an LR-based (i.e., yacc-based) parser can create an awesome fast
> >parser, but to do so requires a generous amount of expanding the base
> >language's grammar to consider all the commonplace mistakes to build up
> >enough context to emit that aforementioned type of useful error message.
> 
> Maybe for some languages, but there isn't much of that in Janus/Ada's 
> grammar. Instead, error correction is based on the grammar tables 
> themselves, and costs for insertion and deletions of tokens. That turns out 
> to be cheap, fast, and reliable -- the only issue is getting the costs right 
> (and they aren't that critical, they're mainly used to break ties).
> 
> But I think that error messages for *syntax* in a compiler are pretty much 
> irrelevant these days; it's the IDE's job to check the syntax before calling 
> the compiler, and in the IDE you only care about the first error anyway. 
> Presuming the check is fast enough (and it is on all but the largest files), 
> you check, then fix, then check again until it is correct.

I didn't say “syntax”.  My “/this/” and “/that/” are wide-meaning enough to encompass semantic checks as well.  LR reductions are often abstracted enough at an index into a table to have (at the surface level without digging again) the easily-available-at-hand contextual information to give good-human-friendly semantic error messages of the category:  I thought we were doing /this/ but then you gave me conflicting /that/ semantically.  Because they are human-crafted for human consumption, LL parsers tend to not aggressively conflate abstractions as much as LR parser tables try to conflate commonality to avoid combinatorial or exponential explosion.  With LR parsers, there is more digging & sifting through what just got successfully (fully-syntactically and partially-semantically) parsed to analyze it.  LL grammars do somewhat less of that rediscovery because LL parsers tended to preserve more implicit knowledge of what has been accepted so far.  All that I am saying is that LL parsers tend to have more interesting accumulated state implicitly laying around locally that LR parsers need to overtly either accumulate via intentionally-crafted mementos a priori or go digging & sifting through a posteriori.

Re: Ada to Ada Translator ?

[Randy Brukardt]

"Optikos" <optikos@verizon.net> wrote in message 
news:a8d0f6ca-d5cf-4831-8803-9c1bb6198116@googlegroups.com...
>On Monday, May 20, 2019 at 6:19:55 PM UTC-5, Randy Brukardt wrote:
>> "Optikos" wrote in message
>> news:64883feb-3e49-4c6a-855c-6673068e970c@googlegroups.com...
>> ...
>> >Conversely, if you utilize Yacc & Flex, it would be LR(k) bottom-up 
>> >parser,
>> >which would be an admirable accomplishment in its own right.
>>
>> Why? There are a number of such grammars out there, and Janus/Ada was
>> designed from the beginning (in 1980!) using an LALR parser. (That was a
>> requirement of the class project at the University of Wisconsin that 
>> formed
>> the basis of Janus/Ada, and we discovered that switching was impractical 
>> as
>> an LL parser was going to be several times larger than the 48K RAM 
>> available
>> on CP/M-80. With some clever storage, we got the LR tables to fit with 
>> space
>> to spare.)
>
>I said "admirable", not unique.  I was speaking in the context of an 
>open-source
>Ada language-translator, not a closed-source one.

Which is relevant how? There are (or at least were) a number of YACC 
grammars for Ada floating around the web. And there's no difficulty in using 
them...

>> >to make "hmmm, it looks like you were trying to do /this/, but I found
>> >troublesome /that/ instead" type of error messages.
>>
>> This is definitely not true and irrelevant at the same time. :-) An LR
>> parser has plenty of context (there is always a state that contains a 
>> vast
>> amount of information). The problem (to the extent that there is one) is
>> situations where you have already gone a long ways down an incorrect path
>> before finding out a problem
>
>You demonstrated what I was saying:  in some LR reductions, the interesting 
>detail
>vis a vis interesting abstraction were a too far away from each other to 
>easily stitch
>back together in a meaningful way, such as for human-friendly error message 
>that
>isn't speaking in compiler-internal speak (or worse, LR 
>clever-table-compaction-speak).

Baloney. Janus/Ada writes messages in terms of deleted/inserted/replaced 
tokens, and those are always understandable by any human. And as I noted, 
there's not much point in syntax error correction anyway, as one can only 
fix one error at a time in any event (and all of the syntax should be in the 
IDE).

> -- Ada luckily does not have many of these.
> (The worst one in Janus/Ada is an "is" following a subprogram in a package
> specification; you've gone too far for an correction to fix the 
> situation.)
>
> >Writing an LR-based (i.e., yacc-based) parser can create an awesome fast
> >parser, but to do so requires a generous amount of expanding the base
> >language's grammar to consider all the commonplace mistakes to build up
> >enough context to emit that aforementioned type of useful error message.
>
> Maybe for some languages, but there isn't much of that in Janus/Ada's
> grammar. Instead, error correction is based on the grammar tables
> themselves, and costs for insertion and deletions of tokens. That turns 
> out
> to be cheap, fast, and reliable -- the only issue is getting the costs 
> right
> (and they aren't that critical, they're mainly used to break ties).
>
> But I think that error messages for *syntax* in a compiler are pretty much
> irrelevant these days; it's the IDE's job to check the syntax before 
> calling
> the compiler, and in the IDE you only care about the first error anyway.
> Presuming the check is fast enough (and it is on all but the largest 
> files),
> you check, then fix, then check again until it is correct.

I didn't say "syntax".  My "/this/" and "/that/" are wide-meaning enough to 
encompass semantic checks as well.  LR reductions are often abstracted 
enough at an index into a table to have (at the surface level without 
digging again) the easily-available-at-hand contextual information to give 
good-human-friendly semantic error messages of the category:  I thought we 
were doing /this/ but then you gave me conflicting /that/ semantically. 
Because they are human-crafted for human consumption, LL parsers tend to not 
aggressively conflate abstractions as much as LR parser tables try to 
conflate commonality to avoid combinatorial or exponential explosion.  With 
LR parsers, there is more digging & sifting through what just got 
successfully (fully-syntactically and partially-semantically) parsed to 
analyze it.  LL grammars do somewhat less of that rediscovery because LL 
parsers tended to preserve more implicit knowledge of what has been accepted 
so far.  All that I am saying is that LL parsers tend to have more 
interesting accumulated state implicitly laying around locally that LR 
parsers need to overtly either accumulate via intentionally-crafted mementos 
a priori or go digging & sifting through a posteriori. 

Re: Ada to Ada Translator ?

[Optikos]

On Tuesday, May 21, 2019 at 5:15:54 PM UTC-5, Randy Brukardt wrote:
> "Optikos" wrote in message 
> news:a8d0f6ca-d5cf-4831-8803-9c1bb6198116@googlegroups.com...
> >On Monday, May 20, 2019 at 6:19:55 PM UTC-5, Randy Brukardt wrote:
> >> "Optikos" wrote in message
> >> news:64883feb-3e49-4c6a-855c-6673068e970c@googlegroups.com...
> >> ...
> >> >Conversely, if you utilize Yacc & Flex, it would be LR(k) bottom-up 
> >> >parser,
> >> >which would be an admirable accomplishment in its own right.
> >>
> >> Why? There are a number of such grammars out there, and Janus/Ada was
> >> designed from the beginning (in 1980!) using an LALR parser. (That was a
> >> requirement of the class project at the University of Wisconsin that 
> >> formed
> >> the basis of Janus/Ada, and we discovered that switching was impractical 
> >> as
> >> an LL parser was going to be several times larger than the 48K RAM 
> >> available
> >> on CP/M-80. With some clever storage, we got the LR tables to fit with 
> >> space
> >> to spare.)
> >
> >I said "admirable", not unique.  I was speaking in the context of an 
> >open-source
> >Ada language-translator, not a closed-source one.
> 
> Which is relevant how?

Patrick's entire thread here is about an •open•-source tool that he is proposing.  Relevant means related to the matter at hand.

> There are (or at least were) a number of YACC 
> grammars for Ada floating around the web. And there's no difficulty in using 
> them...

Aren't all the “number of YACC grammars for Ada floating around on the web” rather out-of-date for only Ada83 or Ada95?  If Patrick is proposing a tool that is capable of parsing Ada2005 or Ada2012 or Ada2020, then modernizing those out-of-date yacc grammars to the current era is of some degree of difficulty.  Doing so in an open-source project would be some degree of laudable accomplishment, as some degree of incremental advancement.  (Even better if the modern-Ada Yacc grammar in the open source project were licensed with an MIT-esque permissive license instead of GPL, since GNAT and ELPA ada-mode for Emacs are both GPL-licensed.)

Furthermore, Patrick is effectively proposing something further:  parsing not merely bland modern Ada straight from the ISO standards, but also every GNAT extension so that his Ada-to-Ada code-generator is a drop-in front-end wrapping GNAT.  I am fairly certain that absolutely no extant open-source Yacc grammar for Ada has all the GNAT extensions (as well as parsing modern Ada2005 or Ada2012 or Ada2020).  I reiterate:  Such an open-source Yacc grammar comprehensive of all variants of Ada (so that it could be a completely transparent front-end to GNAT) “would be an admirable accomplishment in its own right” as I originally stated.

Re: Ada to Ada Translator ?

[Randy Brukardt]

"Optikos" <optikos@verizon.net> wrote in message 
news:1bb467ae-6e2c-4fef-aaab-556a8df71747@googlegroups.com...
...
>> There are (or at least were) a number of YACC
>> grammars for Ada floating around the web. And there's no difficulty in 
>> using
>> them...
>
>Aren't all the "number of YACC grammars for Ada floating around on the web"
>rather out-of-date for only Ada83 or Ada95?

Dunno. Since any computer science graduate (not to mention many others) can 
and probably has built a parser for some language, it's hardly that 
important to have one to reuse.

>If Patrick is proposing a tool that is capable of parsing Ada2005 or
>Ada2012 or Ada2020, then modernizing those out-of-date yacc
>grammars to the current era is of some degree of difficulty.

Maybe for self-taught programmers, but anyone who is familar with the basics 
of compiler construction can create/modify one very quickly. If it takes 
very long to understand someone else's parser, it's probably better to build 
your own. After all, the parser is probably less than 2% of a compiler or 
translator (even the lexer is likely to be harder).

>I reiterate:  Such an open-source Yacc grammar comprehensive of
>all variants of Ada (so that it could be a completely transparent
>front-end to GNAT) "would be an admirable accomplishment in its
>own right" as I originally stated.

That would take at most a week or two to create. The Janus/Ada grammar 
supports all of Ada 2012, and that only took about two weeks to build (most 
of the time being spent redoing the rest of the compiler to be able to 
detect/reject unimplemented stuff without crashing. the actual grammar work 
being only a day or so). It's just not that big of a deal. (The tool as a 
whole, of course, is a different story.)

                                          Randy.

Re: Ada to Ada Translator ?

[foo wong]

Hi Edward

I am just starting out here and I am making errors. The goal here would be to distill down Ada into primitive Ada code, until it could be compiled by gnat without a runtime but it would still be text book Ada code.

I thought that nested subprograms would require the runtime and I don't think they do now, sorry.

Backporting sounds like a great idea. I would like to start around Ada83 and have it compile with gnat without any gnat runtime, the runtime would be created be the ada/ada preprocessor. I would like to target new platforms.

So I guess where I was going with the pragmas, is that I would like to be able to write Ada code that had tasking/exceptions etc but by the time it reached gnat, these pragmas could be used to avoid linking to any runtime from Adacore.

I figure that these pragmas also serve as a sort of to-do list.

You work with Astronomy... I only found out a couple of years ago that the universe has at least 100-200 billion galaxies. What a fascinating field of study. It must be very demanding. I am just a fan on the sidelines :)

-Pat
P.S also thanks to Optikos for the feedback link to AdaGoop and Randy for feedback that shows me that this is a very doable project.

Re: Ada to Ada Translator ?

[Simon Wright]

foo wong <crap@spellingbeewinnars.org> writes:

> So I guess where I was going with the pragmas, is that I would like to
> be able to write Ada code that had tasking/exceptions etc but by the
> time it reached gnat, these pragmas could be used to avoid linking to
> any runtime from Adacore.

You might be interested in a note I wrote about creating an RTS that can
be used by the existing GNAT compiler; see [1], scroll down to 'RTS:
second stage'.

In my case, I was OK with a GPL/RLE runtime, so quite happy to modify
existing FSF GCC files where they were useful; but I don't think there'd
be any problem with reimplementing them. You might need to consider a
'clean room' approach (or not; IANAL).

The sort of assumptions made by the compiler are that - for example, to
create a Ravenscar task - there will exist a package
System.Tasking.Restricted.Stages, containing (at GCC 8/9, GNAT CE 2018)

   procedure Create_Restricted_Task
     (Priority             :        Integer;
      Stack_Address        :        System.Address;
      Size                 :        System.Parameters.Size_Type;
      Sec_Stack_Address    :        System.Secondary_Stack.SS_Stack_Ptr;
      Secondary_Stack_Size :        System.Parameters.Size_Type;
      Task_Info            :        System.Task_Info.Task_Info_Type;
      CPU                  :        Integer;
      State                :        Task_Procedure_Access;
      Discriminants        :        System.Address;
      Elaborated           :        Access_Boolean;
      Chain                : in out Activation_Chain;
      Task_Image           :        String;
      Created_Task         :        Task_Id);

I don't support exceptions, they're fearsomely complicated, and I don't
believe that embedded software should rely on exceptions to provide
continued execution past errors, and SPARK wouldn't allow them
anyway. See notes at [2] - especially Robert Dewar's remarks linked to
at the end.

[1]
https://forward-in-code.blogspot.com/2015/06/building-runtime-system-for-arm-eabi.html
[2] https://github.com/simonjwright/cortex-gnat-rts/wiki/ExceptionHandling

Re: Ada to Ada Translator ?

[foo wong]

Thanks G.B for the very civil response

and thanks Simon for the great links, I will read through these in detail

Re: Ada to Ada Translator ?

[Randy Brukardt]

Oops, sent too soon:

"Optikos" <optikos@verizon.net> wrote in message 
news:a8d0f6ca-d5cf-4831-8803-9c1bb6198116@googlegroups.com...
On Monday, May 20, 2019 at 6:19:55 PM UTC-5, Randy Brukardt wrote:
> "Optikos" wrote in message
> news:64883feb-3e49-4c6a-855c-6673068e970c@googlegroups.com...
...
> But I think that error messages for *syntax* in a compiler are pretty much
> irrelevant these days; it's the IDE's job to check the syntax before 
> calling
> the compiler, and in the IDE you only care about the first error anyway.
> Presuming the check is fast enough (and it is on all but the largest 
> files),
> you check, then fix, then check again until it is correct.

I didn't say "syntax".  My "/this/" and "/that/" are wide-meaning enough to 
encompass semantic checks as well.  LR reductions are often abstracted 
enough at an index into a table to have (at the surface level without 
digging again) the easily-available-at-hand contextual information to give 
good-human-friendly semantic error messages of the category:  I thought we 
were doing /this/ but then you gave me conflicting /that/ semantically. 
Because they are human-crafted for human consumption, LL parsers tend to not 
aggressively conflate abstractions as much as LR parser tables try to 
conflate commonality to avoid combinatorial or exponential explosion.  With 
LR parsers, there is more digging & sifting through what just got 
successfully (fully-syntactically and partially-semantically) parsed to 
analyze it.  LL grammars do somewhat less of that rediscovery because LL 
parsers tended to preserve more implicit knowledge of what has been accepted 
so far.  All that I am saying is that LL parsers tend to have more 
interesting accumulated state implicitly laying around locally that LR 
parsers need to overtly either accumulate via intentionally-crafted mementos 
a priori or go digging & sifting through a posteriori.

----

This is just a bunch of babble. Most compilers do all of their semantic 
analysis using an AST, and that would be the same regardless of the parsing 
technology. Janus/Ada doesn't use an AST for the entire program, but even in 
it, the grammar productions are irrelevant once semantic processing 
starts -- that's all driven by the synbol table and the relevant entites. 
The quality of semantic error messages is what the compiler writer makes 
them, and any claim that some technology makes it harder is probably an 
excuse for doing a bad job. (That's my attitude about bad Janus/Ada 
messages - I try to improve them, not complain about how hard it is.)

                                                 Randy.

Re: Ada to Ada Translator ?

[Optikos]

On Monday, May 20, 2019 at 6:19:55 PM UTC-5, Randy Brukardt wrote:
> "Optikos" wrote in message 
> news:64883feb-3e49-4c6a-855c-6673068e970c@googlegroups.com...
> ...
> >Conversely, if you utilize Yacc & Flex, it would be LR(k) bottom-up parser,
> >which would be an admirable accomplishment in its own right.
> 
> Why? There are a number of such grammars out there, and Janus/Ada was 
> designed from the beginning (in 1980!) using an LALR parser. (That was a 
> requirement of the class project at the University of Wisconsin that formed 
> the basis of Janus/Ada, and we discovered that switching was impractical as 
> an LL parser was going to be several times larger than the 48K RAM available 
> on CP/M-80. With some clever storage, we got the LR tables to fit with space 
> to spare.)

I said “admirable”, not unique.  I was speaking in the context of an open-source Ada language-translator, not a closed-source one.

> >It is purported to be more difficult to craft meaningful error messages in 
> >LR
> >parsers, because LL parsers can explain in detail what was expected but,
> >without care in crafting the grammar, LR parsers can lack the

I meant here:  easily-available-at-hand

> >context

-ual information

> >to make "hmmm, it looks like you were trying to do /this/, but I found
> >troublesome /that/ instead" type of error messages.
> 
> This is definitely not true and irrelevant at the same time. :-) An LR 
> parser has plenty of context (there is always a state that contains a vast 
> amount of information). The problem (to the extent that there is one) is 
> situations where you have already gone a long ways down an incorrect path 
> before finding out a problem

You demonstrated what I was saying:  in some LR reductions, the interesting detail vis a vis interesting abstraction were a too far away from each other to easily stitch back together in a meaningful way, such as for human-friendly error message that isn't speaking in compiler-internal speak (or worse, LR clever-table-compaction-speak).

> -- Ada luckily does not have many of these. 
> (The worst one in Janus/Ada is an "is" following a subprogram in a package 
> specification; you've gone too far for an correction to fix the situation.)
> 
> >Writing an LR-based (i.e., yacc-based) parser can create an awesome fast
> >parser, but to do so requires a generous amount of expanding the base
> >language's grammar to consider all the commonplace mistakes to build up
> >enough context to emit that aforementioned type of useful error message.
> 
> Maybe for some languages, but there isn't much of that in Janus/Ada's 
> grammar. Instead, error correction is based on the grammar tables 
> themselves, and costs for insertion and deletions of tokens. That turns out 
> to be cheap, fast, and reliable -- the only issue is getting the costs right 
> (and they aren't that critical, they're mainly used to break ties).
> 
> But I think that error messages for *syntax* in a compiler are pretty much 
> irrelevant these days; it's the IDE's job to check the syntax before calling 
> the compiler, and in the IDE you only care about the first error anyway. 
> Presuming the check is fast enough (and it is on all but the largest files), 
> you check, then fix, then check again until it is correct.

I didn't say “syntax”.  My “/this/” and “/that/” are wide-meaning enough to encompass semantic checks as well.  LR reductions are often abstracted enough at an index into a table to have (at the surface level without digging again) the easily-available-at-hand contextual information to give good-human-friendly semantic error messages of the category:  I thought we were doing /this/ but then you gave me conflicting /that/ semantically.  Because they are human-crafted for human consumption, LL parsers tend to not aggressively conflate abstractions as much as LR parser tables try to conflate commonality to avoid combinatorial or exponential explosion.  With LR parsers, there is more digging & sifting through what just got successfully (fully-syntactically and partially-semantically) parsed to analyze it.  LL grammars do somewhat less of that rediscovery because LL parsers tended to preserve more implicit knowledge of what has been accepted so far.  All that I am saying is that LL parsers tend to have more interesting accumulated state implicitly laying around locally that LR parsers need to overtly either accumulate via intentionally-crafted mementos a priori or go digging & sifting through a posteriori.

Re: Ada to Ada Translator ?

[Optikos]

On Friday, May 17, 2019 at 9:21:57 AM UTC-5, foo wong wrote:
> Hi Everyone
> 
> My name is Patrick. I have been posting here for years, I am just keep deleting my google accounts because I don't like being spied on.
> 
> It's pretty obvious by now that Adacore is trying to make their free, open source offerings commercially unfriendly, demo-ware only.
> 
> There has also been a lot of discussion about compiler bugs.
> 
> You probably already know about this but I just found Ada yacc and flex tools:
> 
> https://github.com/Ada-France

FYI, there also exists AdaGOOP (Ada Generator of Object-Oriented Parsers), which has had releases from June 2000 to 15 January 2008
https://AdaGOOP.MartinCarlisle.com

AdaGOOP is archived with SCAYACC and SCAFLex, which is a derivative of AYACC and AFLex.  AdaGOOP reportedly has been updated to generate Ada2005 code.  I have no idea whether AdaGOOP's snapshot of SCAYACC and SCAFLex is better or worse than Ada-France's AYACC and AFlex.

If you evaluate both 1) AdaGOOP's yacc & flex for Ada and 2) Ada-France's yacc & flex for Ada, please report back which one you think is better (e.g., in better shape, if forked from a common ancestor) and why.