Studying and Maintaining GNAT, Is There Any Interest in a New Group?

Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[patrick]

Hi Everyone

If I started a new group with the goal of discussing GNAT internals and maintaining GNAT it outside of Adacore, would anyone join?

As a group, we might be able to get the GCC people to adopt patches and features. A single person might not have the clout.

It could give the language new life if the current free, open source compiler most of us use today continues to move in a direction towards unpaid hobbyist use or commercial use with high fees.

It would be a moderated group and we could kick people out for posting about Pascal or human evolution 10 times a day :)

We could create another section in the group for general questions too, for those that feel that the signal to noise here is not good.

Please let me know-Pat

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Dan'l Miller]

Name/affiliation alone will not be enough to influence anyone.  Your clout would come from maintaining a separate fork in Git (such as on GitHub/etc) that has better content (either bug fixes or features) than FSF GNAT or than AdaCore GPL Community Edition.  It does not need to be a superset of AdaCore's features; importation of some AdaCore advances can lag by months.  Rather the fork must contain content that is respectable in its own right as sought-after bug fixes or sought-after features that cannot be obtained (for now) elsewhere.

Your clout would come from code that works, not from a name or from an affiliation.  To do this, this new group would need to be prepared to maintain a fork of FSF GNAT for a long term, analogous to back in the mid-1990s when Lucid XEmacs added X Windows support to a fork of GNU Emacs, which eventually pressured GNU Emacs to follow XEmacs's leadership.  (Note however that Lucid Software went bankrupt during that effort, so there is that.)

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[patrick]

I have two disabled kids and a sickly wife, she dropped to 82lbs last year. 

I home school most of the time and work whenever I can. I am in no position to become a one man Adacore. I can study the code base and make a few patches if I get lots and lots of help.

I think the original goals for the group are within reason and should not be expanded until they are proven successful

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Luke A. Guest]

The issues are:

1) GCC isn’t the nicest to work with.
2) It’s most likely that AdaCore won’t merge your stuff in.
3) starting from Ada95 and not Ada 2012 is a mistake.
4) a lot of people are finding that they would rather:
  a) Start a new compiler, or
  b) Start a new language derived from Ada.

You would better off contributing to 4a.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Jeffrey R. Carter]

On 08/25/2018 02:27 PM, patrick@spellingbeewinnars.org wrote:
> 
> If I started a new group with the goal of discussing GNAT internals and maintaining GNAT it outside of Adacore, would anyone join?

What would this group do that the FSF GNAT maintainers don't do?

-- 
Jeff Carter
"I snapped my chin down onto some guy's fist and
hit another one in the knee with my nose."
Play It Again, Sam
129

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[patrick]

So correct me if I am wrong but the FSF people don't actually do anything with GNAT do they? 

I thought they were simply taking new revisions from Adacore after Adacore waits for a prolonged period.

Is there anyone maintaining gnat outside of Adacore? Is there anyone that can take GNAT in a new direction?

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Luke A. Guest]

<patrick@spellingbeewinnars.org> wrote:

> 
> Is there anyone maintaining gnat outside of Adacore? Is there anyone that
> can take GNAT in a new direction?
> 

AFAIK there isn’t.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[patrick]

Hi Luke

I was wondering if the patches came from a group, whether the GCC people would accept them without or without Adacore.

I know what trouble you have had with GCC and trying to get GNAT ported over to ARM many years ago.

However, could it be safe to say that most of the bugs are in the runtime and not in the code generation?

So please forget what I was saying about forking an old version of GNAT, looks like a really bad idea as it pretty much looks like it was bolted on without any consultation from the GCC people.

Thanks

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[patrick]

> AFAIK there isn’t.

So this would mean that there is a purpose for the group, an alternative to Adacore which has pressure to pay bills and whatnot and may be taking the main free, open source Ada compiler in an unwanted direction.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Simon Wright]

patrick@spellingbeewinnars.org writes:

> I was wondering if the patches came from a group, whether the GCC
> people would accept them without or without Adacore.

I'm far from expert on GCC procedures, but all three of the Ada
front-end maintainers (see [1]) are AdaCore employees, and I don't think
you're going to get approval for updates to Ada internals from anyone
else.

If it's OS-related (I see some of this because Darwin) you stand more
chance.

[1] https://github.com/gcc-mirror/gcc/blob/master/MAINTAINERS

> I know what trouble you have had with GCC and trying to get GNAT
> ported over to ARM many years ago.

That was very frustrating. When others (including me) joined in with
more evidence things improved.

But it can be hard to get the evidence, particularly for rare
happenings; I'm convinced there's a bug in the bare-board RTS related to
an interrupt occuring during a protected entry, reported almost a year
ago, no resolution yet so far as I know.

> However, could it be safe to say that most of the bugs are in the
> runtime and not in the code generation?

When a new compiler release is being made, almost all the bugs will be
in the compiler; the RTS is pretty stable. The interface to the RTS can
change a bit (for Cortex GNAT RTS, GCC7->GCC8 involved a minor change to
the way tagged types are handled, and how secondary stacks are
allocated).

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[patrick]

Hi Simon

The Adacore gatekeepers thing just doesn't really bother me, we could distribute patched versions and the GCC people would eventually catch on if the Adacore guys were blocking good code. 

However I am discouraged with what you are saying about the bugs being on the compiler side and not so much in the RTS.

The runtime is well commented and is mostly Ada. I could see myself understanding this and making patches at some point but GCC is one of the most complex pieces of software ever produced. It's totally out of my league. 

I am not sure what to do?

I don't even know what the a4 project is that Luke spoke of and Byron has not had a commit in over a year and is a massive undertaking.

What will GNAT look like in 5 years? :( Doesn't seem worth including in the instrumentation control software I am slowly-slowly writing.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Luke A. Guest]

Simon Wright <simon@pushface.org> wrote:

>> I know what trouble you have had with GCC and trying to get GNAT
>> ported over to ARM many years ago.
> 
> That was very frustrating. When others (including me) joined in with
> more evidence things improved.

That really pissed me off. They kept saying it worked for them. Well, they
had complete sources which nobody else had, so, quel surprise??

This is a major issue in how things are done right now.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Luke A. Guest]

<patrick@spellingbeewinnars.org> wrote:

> However I am discouraged with what you are saying about the bugs being on
> the compiler side and not so much in the RTS.

It’s more the bugs are in the Ada front end, not the GCC backend, which is
the codegen.

> I don't even know what the a4 project is

I did make a list with option numbers, I said 4a, which was to start a new
compiler.

> that Luke spoke of and Byron has not had a commit in over a year and is a
> massive undertaking.

Which is one reason to start designing a new language which was 4b.

> What will GNAT look like in 5 years? :( Doesn't seem worth including in
> the instrumentation control software I am slowly-slowly writing.

Who knows?

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[patrick]

Ah, I get it, sorry Luke, bit dense here today.....

I can't start an Ada compiler but I have a suggestion if someone wants to.

Look at GnuCOBOL.

It's very plain-jane, run of the mill in a lot of ways. It uses bison/flex for the compiler. It generates C code. It does not have enough comments but it is a good compiler.

I know everybody hates C here but I believe generated C can be safe. The runtime could still be written in Ada with just the entry points being C friendly.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Luke A. Guest]

<patrick@spellingbeewinnars.org> wrote:
> Ah, I get it, sorry Luke, bit dense here today.....
> 
> I can't start an Ada compiler but I have a suggestion if someone wants to.
> 
> Look at GnuCOBOL.
> 
> It's very plain-jane, run of the mill in a lot of ways. It uses
> bison/flex for the compiler. It generates C code. It does not have enough
> comments but it is a good compiler.

A new compiler needs a radical new design.

> 
> I know everybody hates C here but I believe generated C can be safe. The
> runtime could still be written in Ada with just the entry points being C friendly.
> 

Ada can import and export C fine.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Paul Rubin]

Simon Wright <simon@pushface.org> writes:
> I'm far from expert on GCC procedures, but all three of the Ada
> front-end maintainers (see [1]) are AdaCore employees, and I don't think
> you're going to get approval for updates to Ada internals from anyone
> else.

Unless you've got some particular reason to believe that (e.g. based on
experience submitting patches), I tend to be skeptical.  Most FOSS
projects love getting good patches (patches that work, are tested,
conform to the project's standards and interfaces, etc.)  What they
don't like is "homework assignments", i.e. someone else coming along and
telling them to do some work (unless they are a paying customer of
course).  

I haven't been involved with GNAT at all, but I've contributed to GCC
and have found the maintainers to generally be receptive to patches
where the submitter is the one who does the work, and they're at least
somewhat willing to advise about what work is needed.  What they don't
want is "please implement feature X" or even "here is my crappy patch,
please clean it up, test it, rework it so it fits the rest of the
codebase, etc., all for free".  That's what support contracts are for.

When it's a clean patch that really improves things and includes all
necessary documentation and tests, it is usually smooth sailing.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Rene]

Am 26.08.2018 um 01:16 schrieb Paul Rubin:
> Simon Wright <simon@pushface.org> writes:
>> I'm far from expert on GCC procedures, but all three of the Ada
>> front-end maintainers (see [1]) are AdaCore employees, and I don't think
>> you're going to get approval for updates to Ada internals from anyone
>> else.
> 
> Unless you've got some particular reason to believe that (e.g. based on
> experience submitting patches), I tend to be skeptical.  Most FOSS
> projects love getting good patches (patches that work, are tested,
> conform to the project's standards and interfaces, etc.)  What they
> don't like is "homework assignments", i.e. someone else coming along and
> telling them to do some work (unless they are a paying customer of
> course).
> 

I agree. The proposal sounds a bit like "Hey, I have a great idea what 
needs to be done but somebody has to do (most of) it."

If you approach people like this you probably will hear the answer "I'm 
sorry, your idea may be great, but you have do it yourself because 
nobody will do it for you."

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Simon Wright]

Paul Rubin <no.email@nospam.invalid> writes:

> Simon Wright <simon@pushface.org> writes:
>> I'm far from expert on GCC procedures, but all three of the Ada
>> front-end maintainers (see [1]) are AdaCore employees, and I don't
>> think you're going to get approval for updates to Ada internals from
>> anyone else.
>
> Unless you've got some particular reason to believe that (e.g. based
> on experience submitting patches), I tend to be skeptical.  Most FOSS
> projects love getting good patches (patches that work, are tested,
> conform to the project's standards and interfaces, etc.)  What they
> don't like is "homework assignments", i.e. someone else coming along
> and telling them to do some work (unless they are a paying customer of
> course).
>
> I haven't been involved with GNAT at all, but I've contributed to GCC
> and have found the maintainers to generally be receptive to patches
> where the submitter is the one who does the work, and they're at least
> somewhat willing to advise about what work is needed.  What they don't
> want is "please implement feature X" or even "here is my crappy patch,
> please clean it up, test it, rework it so it fits the rest of the
> codebase, etc., all for free".  That's what support contracts are for.
>
> When it's a clean patch that really improves things and includes all
> necessary documentation and tests, it is usually smooth sailing.

A patch that fixes a bootstrap-preventing ICE on Darwin is (a) likely
not to be in the Ada internals even if it's in the Ada directories, (b)
equally likely to be discussed/accepted by Darwin maintainers as by Ada
maintainers.

A small patch that fixed a wide character encoding problem was approved
but the identical patch actually applied (some time later) was
originated by an AdaCore employee. (I was miffed about this, you can
tell)

A patch that fixed an ICE was rejected because AdaCore had a better fix
in mind for their own source tree (I can see there may well be
fork-related issues here). Aside from the hairy nature of the compiler
internals, this is my main reason for not trying to add features to the
compiler: AdaCore have a development plan that we aren't party to, and
almost any change could be affected. Also, I have quite enough to
interest me anyway!

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Dan'l Miller]

On Saturday, August 25, 2018 at 4:48:07 PM UTC-5, Luke A. Guest wrote:
> <patrick@spellingbeewinnars.org> wrote:
> 
> > However I am discouraged with what you are saying about the bugs being on
> > the compiler side and not so much in the RTS.
> 
> It’s more the bugs are in the Ada front end, not the GCC backend, which is
> the codegen.

Although it might be quibbling over the definition of “front-end” and “back-end”, it is my belief that the vast majority of the bugs outside of the runtime is either:
1) front-end proper:
lack of fidelity (to the _LRM_ or to nuanced explanations in the _AARM_) in the Ada-language semantic-adornment of the AST
and
2) lack of fidelity in the GIGI tree-transducer middle layer (which might be truly one-of-a-kind unique to GNAT) effectively •outside• the Ada-language-source-code front-end proper and the GENERIC/GIMPLE/RTL back-end proper:
Between a) the Ada-language semantic-tree in the written-in-Ada front-end proper and b) the GCC GENERIC/GIMPLE/RTL back-end that is shared among all GCC languages, there exists the GIGI () tree-transducer that observes snippets of Ada-front-end's semantically-adorned AST to then instantiate the analogous C/C++-language semantics in that branch of the GENERIC/GIMPLE's back-end semantic tree.

There are 2 areas where GNAT can easily make a mistake:
1) misinterpret (or malenforce) the normative _LRM_ and/or the nuanced explanations in the _AARM_ in the Ada semantically-adorned AST written in Ada language
or
2) mistranscribe the ‘equivalent‘ C/C++ semantics in GENERIC/GIMPLE via the GIGI tree transducer, written in C language.  Just like beauty, ‘equivalent’ degenerates to:  equivalent is in the eye of the beholder.  (And the human being of high IQ has a bigger eye-of-the-beholder than GIGI's observation of mere subset of the Ada AST.  GIGI's eye-of-the-beholder naturally has tunnel vision.)

On Saturday, August 25, 2018 at 5:05:52 PM UTC-5, Luke A. Guest wrote:
> A new compiler needs a radical new design.

Luke, GIGI is the general vicinity for fulfilling your prophetic prediction of the future:  A radical new Ada-compiler design would eliminate the tree-transducer's transcription of snippets of Ada's semantically-adorned AST (in Ada-language source code) into GENERIC/GIMPLE C/C++ semantic tree (in C-language source code).  In short, a radical new Ada-compiler design would eliminate GIGI.  Luke & Shark8 take especial note:  eliminate the need for GIGI entirely, then one has a drastically entirely-different-than-GNAT design for a next-gen Ada compiler.  Luke, despite your ridicule of studying Ada's antiquity, •that• elimination of GIGI is precisely why studying William Wulf's DIANA from decades ago is intellectually stimulating & rewarding as getting the creative juices flowing in the mind when contemplating what a next-gen Ada compiler might have at its heart instead of the bug-prone complication that GNAT has at its heart:  AdaAST-GIGI-C/C++AST, 2 separate trees and a transducer-of-clever-snippets between them.  (I suspect sometimes the scope of that cleverness there in GIGI is insufficiently narrow/not-omniscient-enough, hence mistranscription bug.)

Although Figure 1.1 is the front-end/back-end diagram that most people hold in their head (and dear to their heart) from a compiler-construction textbook, I find Figure 1.2 to much more lucidly reveal GNAT's inner workings in a nutshell for repeated reference in the mind's eye:
https://www2.adacore.com/gap-static/GNAT_Book/html/node5.htm#SECTION03120000000000000000

It is not entirely clear (to me) what GIGI stands for, btw.  One of the “G”s could stand for GNAT; the other could stand for GENERIC or GIMPLE.  One of the “I”s could stand for instantiation (as in instantiating a snippet/extract of the Ada AST into GENERIC/GIMPLE's C-language tree).  One guess:  GNAT-Internal GENERIC/GIMPLE Instatiator.  Perhaps only the original designers of GIGI know for sure:  Robert Dewar, RWS, perhaps Edmond Schonberg.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Dan'l Miller]

On Sunday, August 26, 2018 at 2:54:11 PM UTC-5, Dan'l Miller wrote:
> Perhaps only the original designers of GIGI know for sure:  Robert Dewar, RWS, perhaps Edmond
> Schonberg.

RMS, sorry, Mr. Stallman, if you ever read this.  (W and M are next to each other on my Dvorak-layout keyboard.)

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Lucretia]

On Sunday, 26 August 2018 20:54:11 UTC+1, Dan'l Miller  wrote:
> On Saturday, August 25, 2018 at 4:48:07 PM UTC-5, Luke A. Guest wrote:
> > <patrick@spellingbeewinnars.org> wrote:
> > 
> > > However I am discouraged with what you are saying about the bugs being on
> > > the compiler side and not so much in the RTS.
> > 
> > It’s more the bugs are in the Ada front end, not the GCC backend, which is
> > the codegen.
> 
> Although it might be quibbling over the definition of “front-end” and “back-end”, it is my belief that the vast majority of the bugs outside of the runtime is either:

There is no quibbling, I was pointing out his error in what he thought was what.

< removed rambling >

> On Saturday, August 25, 2018 at 5:05:52 PM UTC-5, Luke A. Guest wrote:
> > A new compiler needs a radical new design.
> 
> Luke, GIGI is the general vicinity for fulfilling your prophetic prediction of the future:  A radical new Ada-compiler design would eliminate the tree-transducer's transcription of snippets of Ada's semantically-adorned AST (in Ada-language source code) into GENERIC/GIMPLE C/C++ semantic tree (in C-language 

What are you going on about?

>source code).  In short, a radical new Ada-compiler design would eliminate GIGI.  Luke & Shark8 take especial note:  eliminate the need for GIGI entirely, then one has a drastically entirely-different-than-GNAT design for a next-gen 

That's exactly the point, it would be a completely different design, a completely different compiler, hence nothing from GCC/GNAT.

>Ada compiler.  Luke, despite your ridicule of studying Ada's antiquity, •that• elimination of GIGI is precisely why studying William Wulf's DIANA from decades ago is intellectually stimulating & rewarding as getting the creative juices flowing in the mind when contemplating what a next-gen Ada compiler might have 

I never said anything about not learning from DIANA, I said don't implement it. Reason is simple, it was designed using Ada83, we have OO now and OO fits a compiler perfectly and would be a hell of a lot nicer than a bunch of variant records/enums.


>at its heart instead of the bug-prone complication that GNAT has at its heart:  AdaAST-GIGI-C/C++AST, 2 separate trees and a transducer-of-clever-snippets between them.  (I suspect sometimes the scope of that cleverness there in GIGI is insufficiently narrow/not-omniscient-enough, hence mistranscription bug.)

What the hell are you on about????
 
< removed >

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Dan'l Miller]

On Sunday, August 26, 2018 at 5:52:54 PM UTC-5, Lucretia wrote:
> On Sunday, 26 August 2018 20:54:11 UTC+1, Dan'l Miller  wrote:
> > On Saturday, August 25, 2018 at 4:48:07 PM UTC-5, Luke A. Guest wrote:
> > > <patrick@spellingbeewinnars.org> wrote:
> > > 
> > > > However I am discouraged with what you are saying about the bugs being on
> > > > the compiler side and not so much in the RTS.
> > > 
> > > It’s more the bugs are in the Ada front end, not the GCC backend, which is
> > > the codegen.
> > 
> > Although it might be quibbling over the definition of “front-end” and “back-end”, it is my belief that
> > the vast majority of the bugs outside of the runtime is either:
> 
> There is no quibbling, I was pointing out his error in what he thought was what.

No, I was the one at the risk of quibbling by pointing out that GNAT has this weird not-truly-front-end, not-truly-back-end 3rd layer called GIGI tree transducer to convert between the two (i.e., Ada versus C/C++) semantic trees, where the Ada semantic tree is in the Ada-language-source-code front-end and the C/C++ semantic tree is in the C-language-source-code back-end of GNAT.

My main point is:  I suspect that (except for brand new revisions of the Ada _LRM_) most bugs are not in the GNAT true-•front•-end in Ada-language source-code nor in the GNAT true-•back•-end in C-language source-code shared with the rest of GCC.  I suspect that the vast majority of lingering compiler bugs in GNAT have their root cause in less-than-perfect tree-transduction from Ada semantic tree to C/C++-GENERIC/GIMPLE semantic tree, due in turn to having blinders on or tunnel vision, not looking at enough context in the large.

> > On Saturday, August 25, 2018 at 5:05:52 PM UTC-5, Luke A. Guest wrote:
> > > A new compiler needs a radical new design.
> > 
> > Luke, GIGI is the general vicinity for fulfilling your prophetic prediction of the future:  A radical new
> > Ada-compiler design would eliminate the tree-transducer's transcription of snippets of Ada's
> > semantically-adorned AST (in Ada-language source code) into GENERIC/GIMPLE C/C++ semantic tree
> > (in C-language 
> 
> What are you going on about?

My sentences are precisely worded to say what needs to be said without further rebuttal by me, stating the same thing again.  If something specific is unclear, please narrow your request for information.

> > source code).  In short, a radical new Ada-compiler design would eliminate GIGI.  Luke & Shark8 take
> > especial note:  eliminate the need for GIGI entirely, then one has a drastically entirely-different-than
> > GNAT design for a next-gen 
> 
> That's exactly the point, it would be a completely different design, a completely different compiler,
> hence nothing from GCC/GNAT.

Yes, eliminating GNAT's need for a tree transducer between 2 semantic trees (one for Ada, the other for C/C++) is the “radical new design” of a next-gen Ada compiler.  We agree there.

> > Ada compiler.  Luke, despite your ridicule of studying Ada's antiquity, •that• elimination of GIGI is
> > precisely why studying William Wulf's DIANA from decades ago is intellectually stimulating &
> > rewarding as getting the creative juices flowing in the mind when contemplating what a next-gen Ada
> > compiler might have 
> 
> I never said anything about not learning from DIANA, I said don't implement it.

I seem to recall an unrelenting general pox on all historical-Ada houses as the overall gist from you.

> Reason is simple, it was designed using Ada83, we have OO now and OO fits a compiler perfectly and
> would be a hell of a lot nicer than a bunch of variant records/enums.

Yes, we're narrowly in agreement there.  DIANA's representing of the semantic information as a directed acyclic graph (DAG) is borrowable though in general for an OO redesign of DIANA.

Conversely, GNAT's trick is to use the AST as a tree, not a true DAG, then emulate the DAGness via the tree by repeated repeated repeated repeated traversals of the AST to semantically adorning it during parsing more & more syntax that reveals more & more semantic-meaning and then finally to tree-transduce it to GENERIC/GIMPLE to synthesize the ‘equivalent’ C/C++-semantics tree.  The measure of GNAT's complexity (as an admirably clever engineering-design-trick achievement) is how many repeated transversals of a tree does it take to emulate a DIANA-esque semantic DAG's joins/unbranching.  At least some of the re-traversals of the true-front-end's Ada semantic tree seem to correspond to where one would expect joins/unbranching in a DAG.  More study in this vicinity will reveal more GIGI-specific wisdom and more DIANA-specific wisdom, and a useful conceptual isomorphism between them, as the 2 schools of thought effectively critique each other.

> > at its heart instead of the bug-prone complication that GNAT has at its heart: 
> > AdaAST-GIGI-C/C++AST, 2 separate trees and a transducer-of-clever-snippets between them.
> > (I suspect sometimes the scope of that cleverness there in GIGI is insufficiently
> > narrow/not-omniscient-enough, hence mistranscription bug.)
> 
> What the hell are you on about????

Unlike all other replies along all branches of all threads deriving from the OP, I actually started doing what the OP sought technologically:  start discussing the actual internal design of GNAT for the purpose of how to understand it for the purpose of how to maintain it.  (I am not sure that we need a new group/forum; what is wrong with discussing the design/internals of GNAT here on c.l.a?)

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Simon Wright]

Luke A. Guest <laguest@archeia.com> writes:

> <patrick@spellingbeewinnars.org> wrote:
>
>> However I am discouraged with what you are saying about the bugs
>> being on the compiler side and not so much in the RTS.
>
> It’s more the bugs are in the Ada front end, not the GCC backend,
> which is the codegen.

There are also bugs in the front/back end interface, which can be
triggered by unusual Ada usages. But, (a) unusual, (b) when found, fixed
quickly (IME).

And there are bugs in the backend; e.g. currently some problems with
LTO/Darwin.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Lucretia]

On Monday, 27 August 2018 03:38:32 UTC+1, Dan'l Miller  wrote:

> > There is no quibbling, I was pointing out his error in what he thought was what.
> 
> No, I was the one at the risk of quibbling by pointing out that GNAT has this weird not-truly-front-end, not-truly-back-end 3rd layer called GIGI tree transducer to convert between the two (i.e., Ada versus C/C++) semantic trees, where the Ada semantic tree is in the Ada-language-source-code front-end and the C/C++ semantic tree is in the C-language-source-code back-end of GNAT.
> 
> My main point is:  I suspect that (except for brand new revisions of the Ada _LRM_) most bugs are not in the GNAT true-•front•-end in Ada-language source-code nor in the GNAT true-•back•-end in C-language source-code shared with the rest of GCC.  I suspect that the vast majority of lingering compiler bugs in GNAT have their root cause in less-than-perfect tree-transduction from Ada semantic tree to C/C++-GENERIC/GIMPLE semantic tree, due in turn to having blinders on or tunnel vision, not looking at enough context in the large.

You don't seem to understand how compilers or GCC is structured. There is no weird 3rd layer.

Compilers use multiple intermediate representations starting with an asbstract syntax tree, the passes take in the AST and modify it or create a new tree/IR until it gets to the point where code generation can take place. That's essentially it

Source Language -> Front-end -> AST -> IR -> IR -> .. -> IR -> Codegen -> Assembly code -> Assembler -> Machine code -> Linker -> Executable

 
> > > semantically-adorned AST (in Ada-language source code) into GENERIC/GIMPLE C/C++ semantic tree
> > > (in C-language 
> > 
> > What are you going on about?
> 
> My sentences are precisely worded to say what needs to be said without further rebuttal by me, stating the same thing again.  If something specific is unclear, please narrow your request for information.

Why use 1 word when 50 will do, right?
 
> > That's exactly the point, it would be a completely different design, a completely different compiler,
> > hence nothing from GCC/GNAT.
> 
> Yes, eliminating GNAT's need for a tree transducer between 2 semantic trees (one for Ada, the other for C/C++) is the “radical new design” of a next-gen Ada compiler.  We agree there.

No, see above, you always need that, because that's what compilers do. All compilers have language neutral IR's, your front end has to convert from source language to that IR, whether it's GCC's GENERIC/GIMPLE or LLVM or Firm.
 
> I seem to recall an unrelenting general pox on all historical-Ada houses as the overall gist from you.

Nope, I said that there is literally no point in trying to reimplement the same software which people didn't like at the time, repeating history, i.e. the source stored as an IR in a database. People didn't want it then, they ain't gonna want it now because getting source in and out of a DB is a pain, yes I know that's what happens with source control, but that's the way it is.

> Unlike all other replies along all branches of all threads deriving from the OP, I actually started doing what the OP sought technologically:  start discussing the actual internal design of GNAT for the purpose of how to understand it for the purpose of how to maintain it.  (I am not sure that we need a new group/forum; what is wrong with discussing the design/internals of GNAT here on c.l.a?)

https://gcc.gnu.org/onlinedocs/gccint/index.html <<- the book you need to read to understand the internals of GCC, it's not an easy or nice read.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Dan'l Miller]

On Monday, August 27, 2018 at 9:46:22 AM UTC-5, Lucretia wrote:
> On Monday, 27 August 2018 03:38:32 UTC+1, Dan'l Miller  wrote:
> 
> > > There is no quibbling, I was pointing out his error in what he thought was what.
> > 
> > No, I was the one at the risk of quibbling by pointing out that GNAT has this weird not-truly-front-end,
> > not-truly-back-end 3rd layer called GIGI tree transducer to convert between the two (i.e., Ada versus
> > C/C++) semantic trees, where the Ada semantic tree is in the Ada-language-source-code front-end
> > and the C/C++ semantic tree is in the C-language-source-code back-end of GNAT.
> > 
> > My main point is:  I suspect that (except for brand new revisions of the Ada _LRM_) most bugs are not
> > in the GNAT true-•front•-end in Ada-language source-code nor in the GNAT true-•back•-end in C
> > language source-code shared with the rest of GCC.  I suspect that the vast majority of lingering
> > compiler bugs in GNAT have their root cause in less-than-perfect tree-transduction from Ada semantic
> > tree to C/C++-GENERIC/GIMPLE semantic tree, due in turn to having blinders on or tunnel vision, not
> > looking at enough context in the large.
> 
> You don't seem to understand how compilers or GCC is structured. There is no weird 3rd layer.
> 
> Compilers use multiple intermediate representations starting with an asbstract syntax tree, the passes
> take in the AST and modify it or create a new tree/IR until it gets to the point where code generation can
> take place. That's essentially it
> 
> Source Language -> Front-end -> AST -> IR -> IR -> .. -> IR -> Codegen -> Assembly code -> Assembler -> Machine code -> Linker -> Executable

And there is where you made your mistake.  That is in fact the bland non-innovative straight-from-the-textbook layering for C/C++ in GCC and many other languages' compilers.

Instead for GNAT the correction to your diagram looks like this:

Ada source Language -> Ada front-end written in Ada -> AdaAST from raw syntax repeatedly repeatedly repeatedly repeatedly traversed to adorn the AdaAST with Ada semantic adornments -> ••C/C++ semantic tree•• -> IR -> IR -> … -> IR -> Codegen -> Assembly code -> Assembler -> Machine code -> Linker -> Executable or DLL

What is peculiar to GNAT is tree transduction from Ada semantics to C/C++ semantics.  This was Dewar's & RMS's (& Schonberg's?) et. al.'s clever trick in 1993 to make Ada compatible with GCC's pre-existing design:  transduce the Ada front-end's semantics tree into the C/C++ •front•-end's C/C++ semantics tree (after, via repeated repeated repeated repeated traversals, preserving the •tree• structure for representing semantics instead of most prior Ada compilers' semantics-DAG, because tree-to-tree transduction is difficult enough, whereas DAG-to-tree transduction is much more impractical).

As I said at the outset, the very nature of this discussion risks accusations of quibbling what is and is not so-called IR in the so-called back-end.  ('Tis funny that you discounted the existence of the risk of quibbling over where the boundary between front-end & back-end precisely falls in GCC and then launched full-throttle right into that predicted quibbling.)  Personally, for the GCC C/C++ compiler, I place the authoring of the C/C++ semantic tree in the front-end, not the back-end, because, well, C/C++ semantics is a property of C/C++ language standardization.  GNAT has a clever rear-of-(Ada-)front-end-to-rear-of(-C/C++)-front-end transduction that is not commonplace in most other compilers.

All of your diagram's stages are to incrementally •lower• layers.  GNAT has—in addition to all that—a •lateral• transduction to the output of another language's (C/C++'s) •front•-end.  Even if you insist on quibbling that the authoring of the C/C++ semantics tree is in the back-end in GCC's C/C++ compiler, GNAT has an additional semantic-tree-to-semantic-tree transduction that is absent in GCC's C/C++ compiler.  GCC's C/C++ compiler has exactly one semantics-tree, not two, regardless of whether one categorizes it as front-end or back-end.

> Why use 1 word when 50 will do, right? 

Because in as little as one word, you get it factually incorrect.  Then it requires a well-worded progression of higher thought to untangle & dissect the incorrectness lucidly for all readers to understand the finer points imbued throughout the correction.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Bill Findlay]

On 27 Aug 2018, Simon Wright wrote
(in article <lysh30kv4l.fsf@pushface.org>):

> Luke A. Guest <laguest@archeia.com> writes:
>
> > <patrick@spellingbeewinnars.org> wrote:
> >
> > > However I am discouraged with what you are saying about the bugs
> > > being on the compiler side and not so much in the RTS.
> >
> > It´s more the bugs are in the Ada front end, not the GCC backend,
> > which is the codegen.
>
> There are also bugs in the front/back end interface, which can be
> triggered by unusual Ada usages. But, (a) unusual, (b) when found, fixed
> quickly (IME).
>
> And there are bugs in the backend; e.g. currently some problems with
> LTO/Darwin.

Could you say more about that, Simon?
It might explain some difficulties I have been experiencing.

-- 
Bill Findlay

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Shark8]

On Saturday, August 25, 2018 at 2:24:28 PM UTC-6, pat...@spellingbeewinnars.org wrote:
> 
> I am not sure what to do?
> 
> I don't even know what the a4 project is that Luke spoke of and Byron has not had a commit in over a year and is a massive undertaking.

I know it hasn't -- I've been a bit... depressed the past couple of years. That really takes a toll when there's only one person working the project. Things are looking up now, and I hope to get development restarted soon; though this likely will involve first typing up design documents and bringing the current codebase up to spec.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Shark8]

On Monday, August 27, 2018 at 10:54:48 AM UTC-6, Bill Findlay wrote:
> On 27 Aug 2018, Simon Wright wrote:
> 
> > Luke A. Guest writes:
> >
> > > patrick wrote:
> > >
> > > > However I am discouraged with what you are saying about the bugs
> > > > being on the compiler side and not so much in the RTS.
> > >
> > > It愀 more the bugs are in the Ada front end, not the GCC backend,
> > > which is the codegen.
> >
> > There are also bugs in the front/back end interface, which can be
> > triggered by unusual Ada usages. But, (a) unusual, (b) when found, fixed
> > quickly (IME).
> >
> > And there are bugs in the backend; e.g. currently some problems with
> > LTO/Darwin.
> 
> Could you say more about that, Simon?
> It might explain some difficulties I have been experiencing.
> 
> -- 
> Bill Findlay

Well, one bug that seems to recur frequently is mishandling of RENAMES, and not obscure renamings either, things like attribute renaming:
  Length : Natural renames Some_Array'Length;
(Though they might have special-cased this particular one.)

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:3892c779-2924-405c-b88d-19389fc5ba3e@googlegroups.com...
...
>Although it might be quibbling over the definition of "front-end" and 
>"back-end", it is
>my belief that the vast majority of the bugs outside of the runtime is 
>either:
...

For what is't worth, based on my lengthy experience with Ada, bugs are most 
often errors of omission rather than errors of commission. That goes for 
every Ada compiler that's I've worked with (and we worked with most of them 
when Claw was being developed in the early days of Ada 95 support). Same 
seems to be the case when looking at new ACATS tests. Errors of omission are 
failures to implement a Legality Rule, or a runtime check, or to implement 
some needed special case within the compiler. Implementing actually the 
wrong thing is much less likely. The ACATS of course can help with missing 
rules and checks; it's not as useful for missing special cases (as those 
tend to be compiler-specific).

                                                    Randy.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Randy Brukardt]

"Lucretia" <laguest9000@googlemail.com> wrote in message 
news:1ceec6d8-c5c4-49b1-9808-a3580bba3f8e@googlegroups.com...
...
>I never said anything about not learning from DIANA, I said don't
>implement it. Reason is simple, it was designed using Ada83, we have
>OO now and OO fits a compiler perfectly and would be a hell of a lot
>nicer than a bunch of variant records/enums.

Fitting OO into a compiler design could very easily turn into a nightmare of 
required overriding routines, making it very painful to add new kinds of 
nodes. I used a design like that in the Claw Builder, and the OO parts 
gummed up the works to the extent that modification is difficult. 
(Especially if you want to develop code using an agile style, which IMHO is 
the only successful way to develop code.)

Variants and enums in Ada are fully checked (either at compile-time or 
runtime), so a lot of the advantages of OO are also available using them. 
(Case completeness checks in particular make it hard to forget to implement 
something.) And they put the emphasis on the operations rather than on the 
objects, which can be an advantage for some sorts of code.

I don't claim to know the right answer here, but I do know that 
variants/enums/cases are very useful design tool *in Ada* (not so much in 
other languages). If one sticks to a strict OO design, you can easily end up 
working a lot harder than necessary and make maintenance harder than 
necessary.

                                                 Randy.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Dmitry A. Kazakov]

On 2018-08-27 23:27, Randy Brukardt wrote:
> "Lucretia" <laguest9000@googlemail.com> wrote in message
> news:1ceec6d8-c5c4-49b1-9808-a3580bba3f8e@googlegroups.com...
> ...
>> I never said anything about not learning from DIANA, I said don't
>> implement it. Reason is simple, it was designed using Ada83, we have
>> OO now and OO fits a compiler perfectly and would be a hell of a lot
>> nicer than a bunch of variant records/enums.
> 
> Fitting OO into a compiler design could very easily turn into a nightmare of
> required overriding routines, making it very painful to add new kinds of
> nodes.

Which is not even possible with variant records. Enumeration types are 
not extensible and have no classes anyway to allow building a 
*comparable* case. E.g.

    type Choice is (A, B);
    type Var (Mode : Choice) is record
       case Mode is
          when A => ...
          when B => ...
       end case;
    end record;

1. How do you extend Choice:

    type Choice_Ext is new Choice with (C, D, E); -- This not Ada

2. How do you declare Var to accept any descendant of Choice as a 
discriminant?

    type Var (Mode : Choice'Class) is record -- This not Ada

3. How do you extend the variant record Var contains?

    type Var_Plus (Mode : Choice_Ext) is new Var with ? -- This not Ada

Since nothing of that kind is possible, what you propose is monolithic 
design AKA "god-class", when the variant record must know *in advance* 
all future "extensions", which are extensions no more. You will need to 
change the declarations of Choice and Var each time and then revisit all 
client code they appear.

And if the above were possible, how would it be different from 
inheritance as we know it?

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

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:pm2tfi$1sv1$1@gioia.aioe.org...
> On 2018-08-27 23:27, Randy Brukardt wrote:
>> "Lucretia" <laguest9000@googlemail.com> wrote in message
>> news:1ceec6d8-c5c4-49b1-9808-a3580bba3f8e@googlegroups.com...
>> ...
>>> I never said anything about not learning from DIANA, I said don't
>>> implement it. Reason is simple, it was designed using Ada83, we have
>>> OO now and OO fits a compiler perfectly and would be a hell of a lot
>>> nicer than a bunch of variant records/enums.
>>
>> Fitting OO into a compiler design could very easily turn into a nightmare 
>> of
>> required overriding routines, making it very painful to add new kinds of
>> nodes.
>
> Which is not even possible with variant records. Enumeration types are not 
> extensible and have no classes anyway to allow building a *comparable* 
> case. E.g.
>
>    type Choice is (A, B);
>    type Var (Mode : Choice) is record
>       case Mode is
>          when A => ...
>          when B => ...
>       end case;
>    end record;
>
> 1. How do you extend Choice:

Why would you want to? In the case of something like a compiler, there is no 
reason to extend anything rather than simply modifying it to add the 
additional capabilities. (That probably goes for anything whose code doesn't 
have a sane reuse case, which in my experience is a substantial portion of 
any program.) Certainly in a viable compiler, you have ownership on all of 
the node types, so modifying them is not the issue it might be with code 
that is reusable.

So to add a new kind of node, you just add additional enumeration literal C 
to Choice. And the Ada compiler will complain if you forget to add C to any 
case statements (assuming you avoided the use of "others"). And you'll get 
runtime errors if you access the wrong variant. It's not even worth the time 
to try to find everything thta needs to be modified -- I generally just 
change the things I know about and let compilation and testing (which is 
easy and extensive for a compiler) find the rest.

>    type Choice_Ext is new Choice with (C, D, E); -- This not Ada
>
> 2. How do you declare Var to accept any descendant of Choice as a 
> discriminant?
>
>    type Var (Mode : Choice'Class) is record -- This not Ada

There aren't any descendants of Choice, so this is not a problem. Indeed, I 
can't imagine any value whatsoever to using extension in this case -- it's 
really only useful as part of OO designs.

> 3. How do you extend the variant record Var contains?
>
>    type Var_Plus (Mode : Choice_Ext) is new Var with ? -- This not Ada

Just modify Var with your favorite editor. Not everything benefits from 
extension.

Case in point: I recently added new node types into Janus/Ada for the 
various Ada 2012 expressions (if expression, raise expression, etc.). This 
was done by just adding them to the existing node type. There isn't any 
reason to have them in a separate type (even if you're operating in Ada 95 
mode, you could still encounter the nodes if some withed unit was compiled 
in Ada 2012 mode). It's just additional support.

Now, obviously a full OO design would have each node kind supported by a 
separate type. But even there, you wouldn't separate them from the others 
(you never want or care about specifically Ada 95 nodes).

> Since nothing of that kind is possible, what you propose is monolithic 
> design AKA "god-class", when the variant record must know *in advance* all 
> future "extensions", which are extensions no more.

Why in advance? One *modifies* code in maintenance; one doesn't tie both 
hands behind your back! It's hard enough to work on a compiler without 
making arbitrary rules preventing the modification of types.

> You will need to change the declarations of Choice and Var each time and 
> then revisit all client code they appear.

Yes, of course. And Ada makes this easy to do safely.

> And if the above were possible, how would it be different from inheritance 
> as we know it?

Inheritance is nearly useless! It helps a tiny bit in code reuse, but it is 
better still to only write the code once! Having to write dozens of 
overridding subprograms that don't actually add any semantics is just busy 
work of no value.

                                           Randy.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> Fitting OO into a compiler design could very easily turn into a nightmare of 
> required overriding routines, making it very painful to add new kinds of 
> nodes. 

I agree with this from a different perspective.  I greatly enjoyed
Andrew Appel's book "Modern Compiler Implementation in ML" and based on
it, if I were to try writing a compiler for real, I'm quite sure I'd use
a functional-programming approach if possible, probably in Haskell or
maybe Idris, though ML is of course possible too.  People interested in
writing compilers should check out the book.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Luke A. Guest]

Paul Rubin <no.email@nospam.invalid> wrote:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> Fitting OO into a compiler design could very easily turn into a nightmare of 
>> required overriding routines, making it very painful to add new kinds of 
>> nodes. 
> 
> I agree with this from a different perspective.  I greatly enjoyed
> Andrew Appel's book "Modern Compiler Implementation in ML" and based on
> it, if I were to try writing a compiler for real, I'm quite sure I'd use
> a functional-programming approach if possible, probably in Haskell or
> maybe Idris, though ML is of course possible too.  People interested in
> writing compilers should check out the book.
> 

I have the C version of that book, bought before I got into Ada. I can see
how FP languages help in the construction of the front end of a compiler,
but forcing FP on the rest of the compiler where you’re not doing tree
walking, I’m not so sure.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Dmitry A. Kazakov]

On 2018-08-29 02:16, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:pm2tfi$1sv1$1@gioia.aioe.org...
>> On 2018-08-27 23:27, Randy Brukardt wrote:
>>> "Lucretia" <laguest9000@googlemail.com> wrote in message
>>> news:1ceec6d8-c5c4-49b1-9808-a3580bba3f8e@googlegroups.com...
>>> ...
>>>> I never said anything about not learning from DIANA, I said don't
>>>> implement it. Reason is simple, it was designed using Ada83, we have
>>>> OO now and OO fits a compiler perfectly and would be a hell of a lot
>>>> nicer than a bunch of variant records/enums.
>>>
>>> Fitting OO into a compiler design could very easily turn into a nightmare
>>> of required overriding routines, making it very painful to add new kinds of
>>> nodes.
>>
>> 1. How do you extend Choice:
> 
> Why would you want to? In the case of something like a compiler, there is no
> reason to extend anything rather than simply modifying it to add the
> additional capabilities.

Which makes the initial claim void. There is no nightmare and nothing to 
override what is not known in advance. For each "when" of the variant 
case there is an "override" in the inheritance scenario. If you know all 
"whens" you also know all "overrides".

>> Since nothing of that kind is possible, what you propose is monolithic
>> design AKA "god-class", when the variant record must know *in advance* all
>> future "extensions", which are extensions no more.
> 
> Why in advance? One *modifies* code in maintenance; one doesn't tie both
> hands behind your back! It's hard enough to work on a compiler without
> making arbitrary rules preventing the modification of types.

That is the exact meaning of "in advance": before the final version of 
the program unit gets ready all variants must be known.

>> You will need to change the declarations of Choice and Var each time and
>> then revisit all client code they appear.
> 
> Yes, of course. And Ada makes this easy to do safely.

Mostly yes, but the distributed overhead of maintenance is still there 
and it is no so safe as advertised. Consider the client code:

    if Current.Token = Integer_Token then
       -- Do something
    else
       -- Do something else
    end if;

Here Integer_Token was used in the meaning "scalar". Later on somebody 
adds Float_Token and boom, it meant to be "scalar"! Even if replaced by 
case it is still could be unsafe if subtypes used:

    case Current.Token is
       when Scalar_Tokens => -- A subtype with Integer_Token in it
       when others =>
    end case;

You must remember to make the subtype Scalar_Tokens covering the newly 
added Float_Token or else you get an intractable bug.

Note that inheritance would handle this safely. It will be:

    Current.Token.Do_Something; -- A dispatching call override

Do_Something would be abstract must-be-overridden for Float_Token.

>> And if the above were possible, how would it be different from inheritance
>> as we know it?
> 
> Inheritance is nearly useless! It helps a tiny bit in code reuse, but it is
> better still to only write the code once! Having to write dozens of
> overridding subprograms that don't actually add any semantics is just busy
> work of no value.

It helps massively, especially interfaces, of course only when used 
properly during analysis and design phase in order to describe 
abstraction. One should use the strengths of typing instead of working 
around them. Variant records in place of interfaces is a path leading to 
weak typing. I don't say that one should never use variant records, I 
say that one should not misuse them.

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

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Paul Rubin]

Luke A. Guest <laguest@archeia.com> writes:
> I have the C version of that book, bought before I got into Ada. I can see
> how FP languages help in the construction of the front end of a compiler,
> but forcing FP on the rest of the compiler where you’re not doing tree
> walking, I’m not so sure.

It wouldn't have occurred to me that any "forcing" would be involved,
since the approach seems very natural.  Past the front end there are
usually a bunch of IR rewriting passes, and sometimes multiple IR's
involving translation steps.  Then at the end there is instruction
selection, which in the book is done by tree pattern recognition (other
approaches are also possible).

This paper was pretty impressive, about cleaning up a compilation phase
by replacing a traditional data structure with a functional one:

https://www.cs.tufts.edu/~nr/pubs/zipcfg.pdf

I think I've linked it before, so you may have seen it already.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:pm5l0r$dek$1@gioia.aioe.org...
> On 2018-08-29 02:16, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:pm2tfi$1sv1$1@gioia.aioe.org...
>>> On 2018-08-27 23:27, Randy Brukardt wrote:
>>>> "Lucretia" <laguest9000@googlemail.com> wrote in message
>>>> news:1ceec6d8-c5c4-49b1-9808-a3580bba3f8e@googlegroups.com...
>>>> ...
>>>>> I never said anything about not learning from DIANA, I said don't
>>>>> implement it. Reason is simple, it was designed using Ada83, we have
>>>>> OO now and OO fits a compiler perfectly and would be a hell of a lot
>>>>> nicer than a bunch of variant records/enums.
>>>>
>>>> Fitting OO into a compiler design could very easily turn into a 
>>>> nightmare
>>>> of required overriding routines, making it very painful to add new 
>>>> kinds of
>>>> nodes.
>>>
>>> 1. How do you extend Choice:
>>
>> Why would you want to? In the case of something like a compiler, there is 
>> no
>> reason to extend anything rather than simply modifying it to add the
>> additional capabilities.
>
> Which makes the initial claim void. There is no nightmare and nothing to 
> override what is not known in advance. For each "when" of the variant case 
> there is an "override" in the inheritance scenario. If you know all 
> "whens" you also know all "overrides".

Surely you "know" them; my point is that there is an incredible amount of 
busy-work needed to write them (as opposed to just modifying the handful of 
places that need that).

For instance, one has to write tree-walking code into every override, as 
there is no good way to do that with inheritance (the override has to make a 
dispatching call on itself on the child mode(s)). The only way to do that 
with though inheritance is to move all of the tree-walking stuff outside of 
the OO operations (as is done in the tree container) -- but then you are no 
longer using strong typing on the children -- the number and kinds of the 
children have to be checked with manual code.

>>> Since nothing of that kind is possible, what you propose is monolithic
>>> design AKA "god-class", when the variant record must know *in advance* 
>>> all
>>> future "extensions", which are extensions no more.
>>
>> Why in advance? One *modifies* code in maintenance; one doesn't tie both
>> hands behind your back! It's hard enough to work on a compiler without
>> making arbitrary rules preventing the modification of types.
>
> That is the exact meaning of "in advance": before the final version of the 
> program unit gets ready all variants must be known.

Umm, we're talking about a compiler, and there never is a "final" version of 
a compiler. Unless it is dead where no one cares anymore. (That's true of 
most decent-sized systems.) I might have a release version of Janus/Ad 
today, but there will be another version next year and undoubtably that will 
require node changes. (Indeed, it must, since I forgot to make qualified 
expressions a "name" last time around. That means qualified expressions need 
components for indexing and selection, and means shuffling variants about to 
avoid duplication.)

>>> You will need to change the declarations of Choice and Var each time and
>>> then revisit all client code they appear.
>>
>> Yes, of course. And Ada makes this easy to do safely.
>
> Mostly yes, but the distributed overhead of maintenance is still there and 
> it is no so safe as advertised. Consider the client code:
>
>    if Current.Token = Integer_Token then
>       -- Do something
>    else
>       -- Do something else
>    end if;
>
> Here Integer_Token was used in the meaning "scalar". Later on somebody 
> adds Float_Token and boom, it meant to be "scalar"!

Sure, but OO doesn't really help here: most properties aren't strictly 
tree-like. For instance, many type categories don't follow inheritance rules 
(limited being the obvious example).

> Even if replaced by case it is still could be unsafe if subtypes used:
>
>    case Current.Token is
>       when Scalar_Tokens => -- A subtype with Integer_Token in it
>       when others =>
>    end case;
>
> You must remember to make the subtype Scalar_Tokens covering the newly 
> added Float_Token or else you get an intractable bug.

As noted before, use of "others" should be discouraged in case statements on 
enumerations. That's an important item in our style guide; a bigger 
organization probably would include it in their tool-based style checks.

If you had avoided "others", you'd get a compile-time error when Float_Token 
was added. I take a lot of advantage of that Ada feature!

> Note that inheritance would handle this safely. It will be:
>
>    Current.Token.Do_Something; -- A dispatching call override
>
> Do_Something would be abstract must-be-overridden for Float_Token.

Sure, but that's what's maddening about using OOP in this way. You have to 
define and implement *every* such operation that way for a new node before 
anything can be done (even compiling the changed program). There are likely 
to be hundreds of such operations for a compiler (certainly dozens). That is 
very much like monolithic waterfall development -- there is nothing agile 
about it.

I try to keep the compiler compiled almost all of the time when doing 
development, even when making major changes like new node kinds. 
Compile-time errors tend to get eliminated first. That's in part because 
code that isn't compilable shouldn't be checked in, and moreover we always 
need to be able to make fixes for customers. The time while the compiler 
isn't compilable is a risk period.

If instead you use some tool to make an empty set of TBDs for all of these 
routines, now you've totally eliminated any compiler-based help (all of the 
needed routines exist, they just don't *work*) and you have exactly the same 
need for testing that you would have had using a variant. So you've gained 
nothing.

>>> And if the above were possible, how would it be different from 
>>> inheritance
>>> as we know it?
>>
>> Inheritance is nearly useless! It helps a tiny bit in code reuse, but it 
>> is
>> better still to only write the code once! Having to write dozens of
>> overridding subprograms that don't actually add any semantics is just 
>> busy
>> work of no value.
>
> It helps massively, especially interfaces, of course only when used 
> properly during analysis and design phase in order to describe 
> abstraction. One should use the strengths of typing instead of working 
> around them. Variant records in place of interfaces is a path leading to 
> weak typing. I don't say that one should never use variant records, I say 
> that one should not misuse them.

I use strong typing to ensure that nodes don't get mixed with symbols or 
with memory allocation record or many other things. I don't see any point in 
treating nodes as different types. Spending a lot of extra time doing 
analysis to try to bring structure where there is little natural structure 
is wasteful at best.

And interfaces are only useful for true code reuse (across disparite 
systems). Other than that, the percentage of times when you have more than 
one instance of an interface approaches zero. In that case, an interface 
only adds overhead and busy-work.

                                                 Randy.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Luke A. Guest]

Paul Rubin <no.email@nospam.invalid> wrote:

> It wouldn't have occurred to me that any "forcing" would be involved,

My issue with FP is forcing recursion everywhere, that’s really unnatural
and very difficult to think in, it’s natural for some algorithms but not
all.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Paul Rubin]

Luke A. Guest <laguest@archeia.com> writes:
> My issue with FP is forcing recursion everywhere, that’s really
> unnatural and very difficult to think in, it’s natural for some
> algorithms but not all.

I'm not sure what you want to use instead.  Generally in Haskell one
doesn't use much explicit recursion but instead uses functions like map
and fold, to operate on collections all at once.  If you really want to
use something like a while-loop or for-loop, Ocaml has those:

 https://ocaml.org/learn/tutorials/if_statements_loops_and_recursion.html#For-loops-and-while-loops

but it's a pretty safe bet that they are just syntactic sugar for
recursive closures.  Haskell has some similar library functions that are
useful now and then:

http://hackage.haskell.org/package/monad-loops-0.4.3/docs/Control-Monad-Loops.html

Normally though, you wouldn't write a traditional imperative loop in a
functional language, because of the mutating index variable.  There are
alternate idioms and you get used to them.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Dmitry A. Kazakov]

On 2018-08-29 23:43, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:pm5l0r$dek$1@gioia.aioe.org...
>> On 2018-08-29 02:16, Randy Brukardt wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:pm2tfi$1sv1$1@gioia.aioe.org...
>>>> On 2018-08-27 23:27, Randy Brukardt wrote:
>>>>> "Lucretia" <laguest9000@googlemail.com> wrote in message
>>>>> news:1ceec6d8-c5c4-49b1-9808-a3580bba3f8e@googlegroups.com...
>>>>> ...
>>>>>> I never said anything about not learning from DIANA, I said don't
>>>>>> implement it. Reason is simple, it was designed using Ada83, we have
>>>>>> OO now and OO fits a compiler perfectly and would be a hell of a lot
>>>>>> nicer than a bunch of variant records/enums.
>>>>>
>>>>> Fitting OO into a compiler design could very easily turn into a
>>>>> nightmare
>>>>> of required overriding routines, making it very painful to add new
>>>>> kinds of
>>>>> nodes.
>>>>
>>>> 1. How do you extend Choice:
>>>
>>> Why would you want to? In the case of something like a compiler, there is
>>> no
>>> reason to extend anything rather than simply modifying it to add the
>>> additional capabilities.
>>
>> Which makes the initial claim void. There is no nightmare and nothing to
>> override what is not known in advance. For each "when" of the variant case
>> there is an "override" in the inheritance scenario. If you know all
>> "whens" you also know all "overrides".
> 
> Surely you "know" them; my point is that there is an incredible amount of
> busy-work needed to write them (as opposed to just modifying the handful of
> places that need that).
> 
> For instance, one has to write tree-walking code into every override, as
> there is no good way to do that with inheritance (the override has to make a
> dispatching call on itself on the child mode(s)). The only way to do that
> with though inheritance is to move all of the tree-walking stuff outside of
> the OO operations (as is done in the tree container) -- but then you are no
> longer using strong typing on the children -- the number and kinds of the
> children have to be checked with manual code.

This I don't understand. Why tree operations cannot be primitive and/or 
class-wide?

As a general observation, anything you can do with subtypes of a single 
type you can also do with a class of a types hierarchy. [There could be 
some obstacles regarding indefinite vs definite types, but they usually 
apply to both designs.]

>>>> Since nothing of that kind is possible, what you propose is monolithic
>>>> design AKA "god-class", when the variant record must know *in advance*
>>>> all
>>>> future "extensions", which are extensions no more.
>>>
>>> Why in advance? One *modifies* code in maintenance; one doesn't tie both
>>> hands behind your back! It's hard enough to work on a compiler without
>>> making arbitrary rules preventing the modification of types.
>>
>> That is the exact meaning of "in advance": before the final version of the
>> program unit gets ready all variants must be known.
> 
> Umm, we're talking about a compiler, and there never is a "final" version of
> a compiler.

Final = deployed, of course.

>>>> You will need to change the declarations of Choice and Var each time and
>>>> then revisit all client code they appear.
>>>
>>> Yes, of course. And Ada makes this easy to do safely.
>>
>> Mostly yes, but the distributed overhead of maintenance is still there and
>> it is no so safe as advertised. Consider the client code:
>>
>>     if Current.Token = Integer_Token then
>>        -- Do something
>>     else
>>        -- Do something else
>>     end if;
>>
>> Here Integer_Token was used in the meaning "scalar". Later on somebody
>> adds Float_Token and boom, it meant to be "scalar"!
> 
> Sure, but OO doesn't really help here: most properties aren't strictly
> tree-like. For instance, many type categories don't follow inheritance rules
> (limited being the obvious example).

[Non-]limited should have been an interface. There is nothing in it that 
is not. Non-limited = have copying operations and constructors. 
[Requires MD]

Same applies to by-reference vs. by-copy. By-reference = has identity.

Most Ada bells and whistles could be broken down into well-defined 
interfaces, which should be the goal of the language future changes.

>> Note that inheritance would handle this safely. It will be:
>>
>>     Current.Token.Do_Something; -- A dispatching call override
>>
>> Do_Something would be abstract must-be-overridden for Float_Token.
> 
> Sure, but that's what's maddening about using OOP in this way. You have to
> define and implement *every* such operation that way for a new node before
> anything can be done (even compiling the changed program).

Exactly. This is called being typed. Operations do not exist without 
types. The design with case-statements spread all over the client code 
is untyped because chunks of client code under "whens" are not 
attributed to any type, have no contract etc. OO allows us

1. To give a contract to this code
2. To refactor and reuse this code
3. To place it in separate compilation units *related* to the types 
involved.

> There are likely
> to be hundreds of such operations for a compiler (certainly dozens). That is
> very much like monolithic waterfall development -- there is nothing agile
> about it.

Here is where MI comes into play. These hundreds of operations belong to 
different interfaces. Tree manipulation and node semantics must be 
described separately.

> I try to keep the compiler compiled almost all of the time when doing
> development, even when making major changes like new node kinds.
> Compile-time errors tend to get eliminated first. That's in part because
> code that isn't compilable shouldn't be checked in, and moreover we always
> need to be able to make fixes for customers. The time while the compiler
> isn't compilable is a risk period.
> 
> If instead you use some tool to make an empty set of TBDs for all of these
> routines, now you've totally eliminated any compiler-based help (all of the
> needed routines exist, they just don't *work*) and you have exactly the same
> need for testing that you would have had using a variant. So you've gained
> nothing.

Morale, do not use crappy tools. Somebody might someday come with a tool 
that would generate all "whens" in all case statements filled with null- 
or raise-statement. Would that be a failure of Ada case-statement 
design? No. If you do that mess on language level (see dynamic 
predicates), that is the language mess. If you do mess with a tool, 
well, that is no language problem.

>>>> And if the above were possible, how would it be different from
>>>> inheritance
>>>> as we know it?
>>>
>>> Inheritance is nearly useless! It helps a tiny bit in code reuse, but it
>>> is
>>> better still to only write the code once! Having to write dozens of
>>> overridding subprograms that don't actually add any semantics is just
>>> busy
>>> work of no value.
>>
>> It helps massively, especially interfaces, of course only when used
>> properly during analysis and design phase in order to describe
>> abstraction. One should use the strengths of typing instead of working
>> around them. Variant records in place of interfaces is a path leading to
>> weak typing. I don't say that one should never use variant records, I say
>> that one should not misuse them.
> 
> I use strong typing to ensure that nodes don't get mixed with symbols or
> with memory allocation record or many other things.

But you allow mixing nodes freely? That is the problem. In a tree all 
nodes are same, but there is semantics of what the node represents and 
you allow mixing that semantics without mapping it onto types. Only one 
aspect of your design is strongly typed: tree manipulations, BTW, the 
aspect more or less marginal to computer design.

> I don't see any point in
> treating nodes as different types. Spending a lot of extra time doing
> analysis to try to bring structure where there is little natural structure
> is wasteful at best.

There might be categories of nodes sharing certain properties and in the 
end some refactored code. You cannot describe such things without some 
form of interface, dynamic (tagged) or static (generics).

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

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:pm87ue$ifg$1@gioia.aioe.org...
> On 2018-08-29 23:43, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
...
>> Surely you "know" them; my point is that there is an incredible amount of
>> busy-work needed to write them (as opposed to just modifying the handful 
>> of
>> places that need that).
>>
>> For instance, one has to write tree-walking code into every override, as
>> there is no good way to do that with inheritance (the override has to 
>> make a
>> dispatching call on itself on the child mode(s)). The only way to do that
>> with though inheritance is to move all of the tree-walking stuff outside 
>> of
>> the OO operations (as is done in the tree container) -- but then you are 
>> no
>> longer using strong typing on the children -- the number and kinds of the
>> children have to be checked with manual code.
>
> This I don't understand. Why tree operations cannot be primitive and/or 
> class-wide?

They are primitive. That's what forces writing the traversal code into every 
operation. Consider the following node:
    type Root_Node is abstract tagged null record;
    type Expr_Tree_Access is access Root_Node'Class;

    procedure Fold (Expr : in out Root_Node); -- Fold the tree.

    type Binop is new Root_Node with record
          Kind : Op;
          Left, Right : Expr_Tree_Access;
    end record;

and the implementation of the Folding operation:
     overriding
     procedure Fold (Expr : in out Binop);

     procedure Fold (Expr : in out Binop) is
     begin
           Fold (Expr.Left.all);
           Fold (Expr.Right.all);
           -- If Expr.Left and Expr.Right are constants, calculate the 
folded value.
     end Fold;

This operation has to do recursive (dispatching calls) on the children. And 
so does every other such operation that gets defined (dozens).

You can't write such code separately from the recursive calls without 
completely losing any typing. (You have to resort to generic formal 
subprograms or access-to-subprograms to do that, which are very weakly typed 
techniques.)

This gets much more complicated for items that have lists or worse 
lists-of-lists (like an Ada "name").

> As a general observation, anything you can do with subtypes of a single 
> type you can also do with a class of a types hierarchy. [There could be 
> some obstacles regarding indefinite vs definite types, but they usually 
> apply to both designs.]

This is true, you just have to write 3 times as much code to make the OO 
design work. And you lose the ability to do agile programming, because you 
have to implement so much new code to add a new node or operation (probably 
on the order of a week for either in an Ada compiler perspective -- dozens 
of operations and dozens of node types are needed there).


>>>>> Since nothing of that kind is possible, what you propose is monolithic
>>>>> design AKA "god-class", when the variant record must know *in advance*
>>>>> all
>>>>> future "extensions", which are extensions no more.
>>>>
>>>> Why in advance? One *modifies* code in maintenance; one doesn't tie 
>>>> both
>>>> hands behind your back! It's hard enough to work on a compiler without
>>>> making arbitrary rules preventing the modification of types.
>>>
>>> That is the exact meaning of "in advance": before the final version of 
>>> the
>>> program unit gets ready all variants must be known.
>>
>> Umm, we're talking about a compiler, and there never is a "final" version 
>> of
>> a compiler.
>
> Final = deployed, of course.

Which is relevant how? It's just a snapshot of a continual evolution.

...
>>> Note that inheritance would handle this safely. It will be:
>>>
>>>     Current.Token.Do_Something; -- A dispatching call override
>>>
>>> Do_Something would be abstract must-be-overridden for Float_Token.
>>
>> Sure, but that's what's maddening about using OOP in this way. You have 
>> to
>> define and implement *every* such operation that way for a new node 
>> before
>> anything can be done (even compiling the changed program).
>
> Exactly. This is called being typed. Operations do not exist without 
> types. The design with case-statements spread all over the client code is 
> untyped because chunks of client code under "whens" are not attributed to 
> any type, have no contract etc. OO allows us
>
> 1. To give a contract to this code
> 2. To refactor and reuse this code
> 3. To place it in separate compilation units *related* to the types 
> involved.

(1) There is no useful contracts for individual nodes -- all of the 
contracts with any meaning are on the tree as a whole. And it is the state 
of the nodes, rather than their kinds, which figure mainly into those 
contracts. (The state being part of the data, not part of the types.)

(2) Refactoring isn't any harder with a variant design than it is with a OO 
design -- I do those sorts of things all of the time. (But not too often, 
one has to be pretty sure before doing any refactoring that it really will 
benefit the program -- a lot of the time, such things end up being lateral 
moves where one problem is fixed, but only by introducing others. Ada, like 
almost anything real, is not that regular!)

(3) We abandoned this at the very beginning of Janus/Ada development -- the 
reason being that we were running in extremely space limited environments, 
and we couldn't afford to use extra calls in the code needed for any sort of 
encapsulation. (Similarly, we used a lot of global variables in early 
Janus/Ada because they were substantially cheaper the access than local 
variables on the Z80 machines. We knew better, but couldn't afford to do it 
right.)

While the global variable thing is surely worth stamping out (most of them 
are gone now, a few persistent ones that are heavily used remain), I'm 
unconvinced that adding a lot of Ada "goodness" would really work in an Ada 
compiler environment. You would need so many getter/setter routines that you 
would be spending 50% of your time adding/fixing them rather than doing 
anything useful. We've gotten a lot of mileage out of using aggregate 
assignments to ensure completeness rather than trying to make everything 
private.

As I said that the outset, I'm not sure what the right answer is, or even if 
there is a right answer.

>> There are likely
>> to be hundreds of such operations for a compiler (certainly dozens). That 
>> is
>> very much like monolithic waterfall development -- there is nothing agile
>> about it.
>
> Here is where MI comes into play. These hundreds of operations belong to 
> different interfaces. Tree manipulation and node semantics must be 
> described separately.

As noted above, I don't think that is possible. I certainly couldn't find 
any way to do it in the Claw Builder (other than using generic formals to to 
tree walkers -- and generics don't inherit).

>> I try to keep the compiler compiled almost all of the time when doing
>> development, even when making major changes like new node kinds.
>> Compile-time errors tend to get eliminated first. That's in part because
>> code that isn't compilable shouldn't be checked in, and moreover we 
>> always
>> need to be able to make fixes for customers. The time while the compiler
>> isn't compilable is a risk period.
>>
>> If instead you use some tool to make an empty set of TBDs for all of 
>> these
>> routines, now you've totally eliminated any compiler-based help (all of 
>> the
>> needed routines exist, they just don't *work*) and you have exactly the 
>> same
>> need for testing that you would have had using a variant. So you've 
>> gained
>> nothing.
>
> Morale, do not use crappy tools. Somebody might someday come with a tool 
> that would generate all "whens" in all case statements filled with null- 
> or raise-statement. Would that be a failure of Ada case-statement design? 
> No. If you do that mess on language level (see dynamic predicates), that 
> is the language mess. If you do mess with a tool, well, that is no 
> language problem.

Which does not answer the underlying question: how do you do agile 
development if adding an operation or new kind of node requires 4 days of 
coding?


...
>>> It helps massively, especially interfaces, of course only when used
>>> properly during analysis and design phase in order to describe
>>> abstraction. One should use the strengths of typing instead of working
>>> around them. Variant records in place of interfaces is a path leading to
>>> weak typing. I don't say that one should never use variant records, I 
>>> say
>>> that one should not misuse them.
>>
>> I use strong typing to ensure that nodes don't get mixed with symbols or
>> with memory allocation record or many other things.
>
> But you allow mixing nodes freely? That is the problem. In a tree all 
> nodes are same, but there is semantics of what the node represents and you 
> allow mixing that semantics without mapping it onto types. Only one aspect 
> of your design is strongly typed: tree manipulations, BTW, the aspect more 
> or less marginal to computer design.

For Ada at least, the only meaningful data structure is the expression tree. 
We don't care about the individual nodes outside of a handful of tree 
walking operations. Most everything talks specifically about the tree.

The tree does have different states -- but all of the nodes in the tree 
ought to be in the same state. One could imagine trying to encode the state 
into the types, but that would require copying/relinking nodes every time 
there is a state change (since Ada doesn't allow changing tags in existing 
objects). That would be a massive overhead, and since much of the cost of a 
compiler is managing nodes 
(allocation/deallocation/copying/reading/writing), the last thing you would 
want to do is increase that overhead.

>> I don't see any point in
>> treating nodes as different types. Spending a lot of extra time doing
>> analysis to try to bring structure where there is little natural 
>> structure
>> is wasteful at best.
>
> There might be categories of nodes sharing certain properties and in the 
> end some refactored code. You cannot describe such things without some 
> form of interface, dynamic (tagged) or static (generics).

Well, maybe you can't, but I do it all of the time. :-) Maybe I could do it 
a bit more often, but as I said above, most refactoring is just a waste of 
time (swapping known problems for new ones). It takes a lot of disipline not 
to waste time doing such things.

In any case, I don't expect ever to agree with you on these points. I think 
a lot of people take strong typing too far -- but of course the sweet spot 
is hard to find. There may be an argument for going further than I do, but 
my experience doesn't show much value to that.

                                                  Randy.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Dmitry A. Kazakov]

On 2018-08-31 01:25, Randy Brukardt wrote:

> They are primitive. That's what forces writing the traversal code into every
> operation. Consider the following node:
>      type Root_Node is abstract tagged null record;
>      type Expr_Tree_Access is access Root_Node'Class;
> 
>      procedure Fold (Expr : in out Root_Node); -- Fold the tree.
> 
>      type Binop is new Root_Node with record
>            Kind : Op;
>            Left, Right : Expr_Tree_Access;
>      end record;
> 
> and the implementation of the Folding operation:
>       overriding
>       procedure Fold (Expr : in out Binop);
> 
>       procedure Fold (Expr : in out Binop) is
>       begin
>             Fold (Expr.Left.all);
>             Fold (Expr.Right.all);
>             -- If Expr.Left and Expr.Right are constants, calculate the
> folded value.
>       end Fold;
> 
> This operation has to do recursive (dispatching calls) on the children. And
> so does every other such operation that gets defined (dozens).

Why isn't Fold class-wide:

    procedure Fold (Expr : in out Binop'Class) is
    begin
       Fold (Expr.Left.all);
       Fold (Expr.Right.all);
       Expr.Evaluate; -- This dispatches to the Op's implementation
    end Fold;

BTW, I prefer to fold constants before generating the tree. I.e. when 
Evaluate is called it returns either a value ("constant" node) or a new 
"dynamic" node.

>> As a general observation, anything you can do with subtypes of a single
>> type you can also do with a class of a types hierarchy. [There could be
>> some obstacles regarding indefinite vs definite types, but they usually
>> apply to both designs.]
> 
> This is true, you just have to write 3 times as much code to make the OO
> design work. And you lose the ability to do agile programming, because you
> have to implement so much new code to add a new node or operation (probably
> on the order of a week for either in an Ada compiler perspective -- dozens
> of operations and dozens of node types are needed there).

You would possibly save a comparable number of source lines in clients.

>>> Umm, we're talking about a compiler, and there never is a "final" version
>>> of a compiler.
>>
>> Final = deployed, of course.
> 
> Which is relevant how? It's just a snapshot of a continual evolution.

Each new release is another program. You might kill the whole package 
next time, the code is not stable. With OO I can have stable pieces of 
code frozen in separate packages which never change and keep adding 
volatile code without rewriting everything each time.

> ...
>>>> Note that inheritance would handle this safely. It will be:
>>>>
>>>>      Current.Token.Do_Something; -- A dispatching call override
>>>>
>>>> Do_Something would be abstract must-be-overridden for Float_Token.
>>>
>>> Sure, but that's what's maddening about using OOP in this way. You have
>>> to
>>> define and implement *every* such operation that way for a new node
>>> before
>>> anything can be done (even compiling the changed program).
>>
>> Exactly. This is called being typed. Operations do not exist without
>> types. The design with case-statements spread all over the client code is
>> untyped because chunks of client code under "whens" are not attributed to
>> any type, have no contract etc. OO allows us
>>
>> 1. To give a contract to this code
>> 2. To refactor and reuse this code
>> 3. To place it in separate compilation units *related* to the types
>> involved.
> 
> (1) There is no useful contracts for individual nodes -- all of the
> contracts with any meaning are on the tree as a whole. And it is the state
> of the nodes, rather than their kinds, which figure mainly into those
> contracts. (The state being part of the data, not part of the types.)

But when you fold constants you do that according to the types of the 
nodes. The question is if you try to map these types onto Ada types or not.

> (2) Refactoring isn't any harder with a variant design than it is with a OO
> design -- I do those sorts of things all of the time.

I find using free subprograms more difficult. They have no natural place 
to keep in. So I always forget which package holds this or that 
refactored subprogram and end up with several instances doing basically 
same thing.

> You would need so many getter/setter routines that you
> would be spending 50% of your time adding/fixing them rather than doing
> anything useful.

In my experience getter/setter tend to be stable. My problem is that 
they pollute package specification. This is one of the reasons why I'd 
like to have record interfaces:

    type Getters_Setters is interface record
       Field_1 : Integer; -- "Virtual" record field
       ...
    end record;
    type T is ... and Getters_Setters with ...

The type T need not to contain Field_1 physically. If it does not one 
should override getter and setter (in the private part).

> We've gotten a lot of mileage out of using aggregate
> assignments to ensure completeness rather than trying to make everything
> private.

It was wasting time, IMO. User-defined aggregates would be much simpler 
to add without burdening the language with dubious rules and 
counterintuitive constructs.

> Which does not answer the underlying question: how do you do agile
> development if adding an operation or new kind of node requires 4 days of
> coding?

I don't buy agile if that means generating false code. When I add an 
abstract operation I want the compiler to generate error messages the 
same way it does when a new case choice is added.

BTW, I feel uncomfortable about Ada 2005(?) change that a primitive 
function returning the type need not to be always overridden.

> For Ada at least, the only meaningful data structure is the expression tree.
> We don't care about the individual nodes outside of a handful of tree
> walking operations. Most everything talks specifically about the tree.

I'd like to have it reverse, hiding walking and exposing semantics of 
the nodes.

> In any case, I don't expect ever to agree with you on these points. I think
> a lot of people take strong typing too far -- but of course the sweet spot
> is hard to find. There may be an argument for going further than I do, but
> my experience doesn't show much value to that.

True, I want to push typing and static verification in general as far as 
possible. Nothing is too far to me. (:-))

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

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Robert A Duff]

Shark8 <onewingedshark@gmail.com> writes:

> On Monday, August 27, 2018 at 10:54:48 AM UTC-6, Bill Findlay wrote:
>> On 27 Aug 2018, Simon Wright wrote:
>> > And there are bugs in the backend; e.g. currently some problems with
>> > LTO/Darwin.
>>
>> Could you say more about that, Simon?
>> It might explain some difficulties I have been experiencing.

> Well, one bug that seems to recur frequently is mishandling of RENAMES, and not obscure renamings either, things like attribute renaming:
>   Length : Natural renames Some_Array'Length;

That's illegal, because Some_Array'Length denotes a value,
not an object, so you can't use it like that in an
object_renaming_declaration.  GNAT correctly detects
this error.  I don't see any mishandling here.
Am I missing something?

I would prefer to allow the above, but that's a language issue,
not a compiler issue.  And it's certainly not an issue specific
to the back end.

> (Though they might have special-cased this particular one.)

Not sure what you mean by that.

- Bob

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:pmavco$u5d$1@gioia.aioe.org...
> On 2018-08-31 01:25, Randy Brukardt wrote:
>
>> They are primitive. That's what forces writing the traversal code into 
>> every
>> operation. Consider the following node:
>>      type Root_Node is abstract tagged null record;
>>      type Expr_Tree_Access is access Root_Node'Class;
>>
>>      procedure Fold (Expr : in out Root_Node); -- Fold the tree.
>>
>>      type Binop is new Root_Node with record
>>            Kind : Op;
>>            Left, Right : Expr_Tree_Access;
>>      end record;
>>
>> and the implementation of the Folding operation:
>>       overriding
>>       procedure Fold (Expr : in out Binop);
>>
>>       procedure Fold (Expr : in out Binop) is
>>       begin
>>             Fold (Expr.Left.all);
>>             Fold (Expr.Right.all);
>>             -- If Expr.Left and Expr.Right are constants, calculate the
>> folded value.
>>       end Fold;
>>
>> This operation has to do recursive (dispatching calls) on the children. 
>> And
>> so does every other such operation that gets defined (dozens).
>
> Why isn't Fold class-wide:
>
>    procedure Fold (Expr : in out Binop'Class) is
>    begin
>       Fold (Expr.Left.all);
>       Fold (Expr.Right.all);
>       Expr.Evaluate; -- This dispatches to the Op's implementation
>    end Fold;

There's not one "evaluate" operation here; there are 6 different phases of 
tree operations (construction, lookup, resolution, checking, folding, and 
conversion to low-level IR). Most of these have to be separate because of 
various Ada rules (for instance, we used to do lookup as part of 
construction, but it has to be deferred for expressions in pragmas and 
aspect definitions). One walks the tree at least these times (and more if 
the tree has to be persisted -- for instance, if it is a default expression 
in a specification).


> BTW, I prefer to fold constants before generating the tree. I.e. when 
> Evaluate is called it returns either a value ("constant" node) or a new 
> "dynamic" node.

In Ada, you can't do folding until you know what the operations are, and you 
don't know that until after resolution (that is, "*" could be predefined, 
which you can fold, or user-defined, which you probably can't fold, and 
certainly can't treat as static).

>>> As a general observation, anything you can do with subtypes of a single
>>> type you can also do with a class of a types hierarchy. [There could be
>>> some obstacles regarding indefinite vs definite types, but they usually
>>> apply to both designs.]
>>
>> This is true, you just have to write 3 times as much code to make the OO
>> design work. And you lose the ability to do agile programming, because 
>> you
>> have to implement so much new code to add a new node or operation 
>> (probably
>> on the order of a week for either in an Ada compiler perspective --  
>> dozens
>> of operations and dozens of node types are needed there).
>
> You would possibly save a comparable number of source lines in clients.

That wasn't my experience with CBuild, but that's only a single example (and 
not a compiler, either).

>>>> Umm, we're talking about a compiler, and there never is a "final" 
>>>> version
>>>> of a compiler.
>>>
>>> Final = deployed, of course.
>>
>> Which is relevant how? It's just a snapshot of a continual evolution.
>
> Each new release is another program. You might kill the whole package next 
> time, the code is not stable. With OO I can have stable pieces of code 
> frozen in separate packages which never change and keep adding volatile 
> code without rewriting everything each time.

Which again is relevant how? You might not have to change some code 
depending on the code structure, but the number of changes really only 
matter in true spaggetti code (where everything is everywhere). Expression 
tree manipulations are only a small part of the compiler (less than 25%,  I 
think). You could make it more by putting statements and declarations into 
those trees, but that wouldn't buy much and wouldn't add that much code to 
the tree manipulations, either. A lot of the code is handling the 
environment (with clauses and the like) as well as symbol table operations.

...
>>> 1. To give a contract to this code
>>> 2. To refactor and reuse this code
>>> 3. To place it in separate compilation units *related* to the types
>>> involved.
>>
>> (1) There is no useful contracts for individual nodes -- all of the
>> contracts with any meaning are on the tree as a whole. And it is the 
>> state
>> of the nodes, rather than their kinds, which figure mainly into those
>> contracts. (The state being part of the data, not part of the types.)
>
> But when you fold constants you do that according to the types of the 
> nodes. The question is if you try to map these types onto Ada types or 
> not.

There's no real types involved here. The actual folding code is quite small, 
and there's only a handful of node kinds that are even involved. There's 
simply not enough benefit to extra typing on these things.

>> (2) Refactoring isn't any harder with a variant design than it is with a 
>> OO
>> design -- I do those sorts of things all of the time.
>
> I find using free subprograms more difficult. They have no natural place 
> to keep in. So I always forget which package holds this or that refactored 
> subprogram and end up with several instances doing basically same thing.

Yes, I agree that's a problem. But it's not a problem with a solution, since 
almost all compiler operations are cross operations, using symbol table 
information, expression tree information, and type information to create 
(three very different and mostly unrelated data structures). Very few of 
them obviously belong to any particular one, and any choice tends to be 
arbitrary.

...
>> Which does not answer the underlying question: how do you do agile
>> development if adding an operation or new kind of node requires 4 days of
>> coding?
>
> I don't buy agile if that means generating false code. When I add an 
> abstract operation I want the compiler to generate error messages the same 
> way it does when a new case choice is added.
>
> BTW, I feel uncomfortable about Ada 2005(?) change that a primitive 
> function returning the type need not to be always overridden.

I do too, but probably for the opposite reason: it's a fragile mechanism 
tied to a null extension. If you try to program agily, you might very well 
write the extension first and add the components later. Now you've suddenly 
got to override a bunch functions that were fine before -- which defeats the 
purpose of declaring the type first in the first place.

This problem is also a substantial one when using generic mix-ins, since the 
mix-in doesn't know about the functions in question and can't really do so. 
IMHO, it should work any time all of the components in the extension have 
well-defined defaults. Then the mix-in case would work with sufficient care, 
and if you want to force redefinition of everything, just have a component 
with no default.


>> For Ada at least, the only meaningful data structure is the expression 
>> tree.
>> We don't care about the individual nodes outside of a handful of tree
>> walking operations. Most everything talks specifically about the tree.
>
> I'd like to have it reverse, hiding walking and exposing semantics of the 
> nodes.
>
>> In any case, I don't expect ever to agree with you on these points. I 
>> think
>> a lot of people take strong typing too far -- but of course the sweet 
>> spot
>> is hard to find. There may be an argument for going further than I do, 
>> but
>> my experience doesn't show much value to that.
>
> True, I want to push typing and static verification in general as far as 
> possible. Nothing is too far to me. (:-))

<Grin>.

I have a different vision of static verification than you do; I'm primarily 
focused on static verification of Ada's dynamic checks. (Since that includes 
pragma Assert and the like, you can verify almost everything this way.) And 
I want the compiler to do that - not the least because I would like to show 
that there are other possible visions for Ada compilers than AdaCore's. (And 
if it gets people to buy more compilers from me, all the better. :-)

                                           Randy.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Randy Brukardt]

"Robert A Duff" <bobduff@TheWorld.com> wrote in message 
news:wcc5zzqtels.fsf@TheWorld.com...
> Shark8 <onewingedshark@gmail.com> writes:
>
>> On Monday, August 27, 2018 at 10:54:48 AM UTC-6, Bill Findlay wrote:
>>> On 27 Aug 2018, Simon Wright wrote:
>>> > And there are bugs in the backend; e.g. currently some problems with
>>> > LTO/Darwin.
>>>
>>> Could you say more about that, Simon?
>>> It might explain some difficulties I have been experiencing.
>
>> Well, one bug that seems to recur frequently is mishandling of RENAMES, 
>> and not obscure renamings either, things like attribute renaming:
>>   Length : Natural renames Some_Array'Length;
>
> That's illegal, because Some_Array'Length denotes a value,
> not an object, so you can't use it like that in an
> object_renaming_declaration.  GNAT correctly detects
> this error.  I don't see any mishandling here.
> Am I missing something?

Probably just that people are very confused about what one can rename. It's 
completely illogical, but as Bob says, it's a language issue and not 
(necessarily) a compiler issue.

For instance:
    Next : Natural renames Natural'Pred(1);
*is* legal, as Pred represents a function, and function results represent 
objects.

Similarly, in Ada 2012:
    Ren1 : Natural renames Func(1); -- Legal.
    Ren2 : Natural renames Natural'(Func(1)); -- Legal.
    Ren3 : Natural renames Natural(Func(1)); -- Illegal!!!

At least Ada 2020 will fix this one. But try this:
     Ren4 : Boolean renames Boolean'(A and B); -- Legal.
     Ren5 : Boolean renames Boolean'(A and then B); -- Illegal.
     Ren6 : Boolean renames "and"(A, B); -- Legal.
     Ren7 : Boolean renames A and B; -- Illegal.

"and" is an operator function here, so it's an object and can be renamed. 
But "and then" is an operation and thus can't be renamed. Ren7 is illegal be 
infix notation is not a "name", so this renaming is illegal syntax.

Note that every one of these renames was illegal in Ada 83. Someone thought 
that it was important to allow Ren1 in Ada 95, and that led to all of these 
bizarre cases.

Anyone who claims they understand what can and cannot be renamed intuitively 
is a liar. :-)

                                              Randy.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Simon Wright]

Bill Findlay <findlaybill@blueyonder.co.uk> writes:

> On 27 Aug 2018, Simon Wright wrote
> (in article <lysh30kv4l.fsf@pushface.org>):

>> There are also bugs in the front/back end interface, which can be
>> triggered by unusual Ada usages. But, (a) unusual, (b) when found,
>> fixed quickly (IME).
>>
>> And there are bugs in the backend; e.g. currently some problems with
>> LTO/Darwin.
>
> Could you say more about that, Simon?
> It might explain some difficulties I have been experiencing.

Sorry for delayed response.

It's https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005 - Early lto
debug not implemented on Darwin.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Bill Findlay]

On 1 Sep 2018, Simon Wright wrote
(in article <lywos5r7ek.fsf@pushface.org>):

> Bill Findlay<findlaybill@blueyonder.co.uk>  writes:
>
> > On 27 Aug 2018, Simon Wright wrote
> > (in article<lysh30kv4l.fsf@pushface.org>):
>
> > > There are also bugs in the front/back end interface, which can be
> > > triggered by unusual Ada usages. But, (a) unusual, (b) when found,
> > > fixed quickly (IME).
> > >
> > > And there are bugs in the backend; e.g. currently some problems with
> > > LTO/Darwin.
> >
> > Could you say more about that, Simon?
> > It might explain some difficulties I have been experiencing.
>
> Sorry for delayed response.
>
> It's https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005 - Early lto
> debug not implemented on Darwin.

Thanks for that - it's not what I was experiencing.

-- 
Bill Findlay

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Note that every one of these renames was illegal in Ada 83. Someone thought 
> that it was important to allow Ren1 in Ada 95, and that led to all of these 
> bizarre cases.

I think it was mostly accidental. We needed to say that the result of
a function call is an object (as opposed to a value, as in Ada 83),
because it needs to get finalized. This caused renaming of
function calls to become legal, which we viewed as harmless
and sometimes useful.

We didn't take the further step of making all the other cases
you mentioned legal. Perhaps we should have, just for uniformity.

- Bob

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Dmitry A. Kazakov]

On 2018-09-01 00:42, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:pmavco$u5d$1@gioia.aioe.org...
>> On 2018-08-31 01:25, Randy Brukardt wrote:
>>
>> Why isn't Fold class-wide:
>>
>>     procedure Fold (Expr : in out Binop'Class) is
>>     begin
>>        Fold (Expr.Left.all);
>>        Fold (Expr.Right.all);
>>        Expr.Evaluate; -- This dispatches to the Op's implementation
>>     end Fold;
> 
> There's not one "evaluate" operation here; there are 6 different phases of
> tree operations (construction, lookup, resolution, checking, folding, and
> conversion to low-level IR).

For each of them I would decide if that is a primitive or class-wide 
operation.

>> BTW, I prefer to fold constants before generating the tree. I.e. when
>> Evaluate is called it returns either a value ("constant" node) or a new
>> "dynamic" node.
> 
> In Ada, you can't do folding until you know what the operations are, and you
> don't know that until after resolution (that is, "*" could be predefined,
> which you can fold, or user-defined, which you probably can't fold, and
> certainly can't treat as static).

I meant folding universal constants. During/after type resolution one 
could generate the next tree and fold resolved constants then.

>>>>> Umm, we're talking about a compiler, and there never is a "final"
>>>>> version of a compiler.
>>>>
>>>> Final = deployed, of course.
>>>
>>> Which is relevant how? It's just a snapshot of a continual evolution.
>>
>> Each new release is another program. You might kill the whole package next
>> time, the code is not stable. With OO I can have stable pieces of code
>> frozen in separate packages which never change and keep adding volatile
>> code without rewriting everything each time.
> 
> Which again is relevant how?

To the meaning of "knowing in advance". You basically say that you do 
not know anything because the program gets sometimes changed.

> You might not have to change some code
> depending on the code structure, but the number of changes really only
> matter in true spaggetti code (where everything is everywhere). Expression
> tree manipulations are only a small part of the compiler (less than 25%,  I
> think). You could make it more by putting statements and declarations into
> those trees, but that wouldn't buy much and wouldn't add that much code to
> the tree manipulations, either. A lot of the code is handling the
> environment (with clauses and the like) as well as symbol table operations.

OK, that is basically this: it is not so much code, I can do it 
quick-and-dirty without much consideration. It is a valid argument in 
your case because you write and maintain this code all your life and 
could possibly do it while sleeping. (:-)) But as a general advice it is 
IMO wrong.

> I do too, but probably for the opposite reason: it's a fragile mechanism
> tied to a null extension. If you try to program agily, you might very well
> write the extension first and add the components later. Now you've suddenly
> got to override a bunch functions that were fine before -- which defeats the
> purpose of declaring the type first in the first place.

I ask what is agile here? The type with null extension is same. The 
operations are same. What was changed? Looks like useless and mindless 
activity to me.

> This problem is also a substantial one when using generic mix-ins, since the
> mix-in doesn't know about the functions in question and can't really do so.
> IMHO, it should work any time all of the components in the extension have
> well-defined defaults. Then the mix-in case would work with sufficient care,
> and if you want to force redefinition of everything, just have a component
> with no default.

Mix-in is never safe, should be replaced by MI and/or parallel type 
hierarchy mechanics.

> I have a different vision of static verification than you do; I'm primarily
> focused on static verification of Ada's dynamic checks. (Since that includes
> pragma Assert and the like, you can verify almost everything this way.)

It is OK, but low-level. One cannot organize such checks in a way of 
type checks,  which have inheritance, parameter matching, composition of 
new types. You lose a lot. Not everything can be checked by types, of 
course.

> And
> I want the compiler to do that - not the least because I would like to show
> that there are other possible visions for Ada compilers than AdaCore's. (And
> if it gets people to buy more compilers from me, all the better. :-)

It would be great to have a viable alternative to GNAT.

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

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Dmitry A. Kazakov]

On 2018-09-01 21:42, Robert A Duff wrote:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
> 
>> Note that every one of these renames was illegal in Ada 83. Someone thought
>> that it was important to allow Ren1 in Ada 95, and that led to all of these
>> bizarre cases.
> 
> I think it was mostly accidental. We needed to say that the result of
> a function call is an object (as opposed to a value, as in Ada 83),
> because it needs to get finalized. This caused renaming of
> function calls to become legal, which we viewed as harmless
> and sometimes useful.

I think distinction object vs. value is a wrong. Renaming should apply 
to named entities, e.g. *named* objects. Renaming anonymous things makes 
no sense, IMO.

> We didn't take the further step of making all the other cases
> you mentioned legal. Perhaps we should have, just for uniformity.

Uniformly counterintuitive. If an expression to be named, that 
intuitively should have semantics of a call. E.g.

    Line : String renames Get_Line (File);
begin
    loop
       Put_Line (Line); -- Dumping all the file
    end loop;
exception
    when End_Error => -- From Put_Line, not from declaration!
       null;

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

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[AdaMagica]

Am Samstag, 1. September 2018 00:51:42 UTC+2 schrieb Randy Brukardt:
> Similarly, in Ada 2012:
>     Ren1 : Natural renames Func(1); -- Legal.
>     Ren2 : Natural renames Natural'(Func(1)); -- Legal.
>     Ren3 : Natural renames Natural(Func(1)); -- Illegal!!!
> 
> At least Ada 2020 will fix this one. But try this:
>      Ren4 : Boolean renames Boolean'(A and B); -- Legal.
>      Ren5 : Boolean renames Boolean'(A and then B); -- Illegal.
>      Ren6 : Boolean renames "and"(A, B); -- Legal.
>      Ren7 : Boolean renames A and B; -- Illegal.

Ahem, perhaps my Gnat 2018 is not correct, but it rejects only Ren7, which is an expression, and that cannot be renamed according to syntax.

3.3(2) defines objects. (BTW: Shouldn't the term object here be in italics?)
Ren2 is a qualified expression with an object as operand. OK
Ren3 is a type conversion of an object, which is a name. A type conversion is not an object. So Gnat is wrong?
Ren4 and Ren5 both rename a qualified expression, but neither operand in an object. So Gnat is wrong again?

> Anyone who claims they understand what can and cannot be renamed intuitively 
> is a liar. :-)

True

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Jeffrey R. Carter]

On 09/02/2018 12:11 PM, AdaMagica wrote:
> Am Samstag, 1. September 2018 00:51:42 UTC+2 schrieb Randy Brukardt:
>> Similarly, in Ada 2012:
>>      Ren1 : Natural renames Func(1); -- Legal.
>>      Ren2 : Natural renames Natural'(Func(1)); -- Legal.
>>      Ren3 : Natural renames Natural(Func(1)); -- Illegal!!!
>>
>> At least Ada 2020 will fix this one. But try this:
>>       Ren4 : Boolean renames Boolean'(A and B); -- Legal.
>>       Ren5 : Boolean renames Boolean'(A and then B); -- Illegal.
>>       Ren6 : Boolean renames "and"(A, B); -- Legal.
>>       Ren7 : Boolean renames A and B; -- Illegal.
> 
> Ahem, perhaps my Gnat 2018 is not correct, but it rejects only Ren7, which is an expression, and that cannot be renamed according to syntax.

FSF GNAT 8.0.1 rejects all 3:

$ gnatmake renaming.ads
gcc-8 -c renaming.ads
renaming.ads:9:27: renaming of conversion only allowed for tagged types
renaming.ads:11:34: expect object name in renaming
renaming.ads:13:28: missing ";"
gnatmake: "renaming.ads" compilation error

-- 
Jeff Carter
"Blessed are they who convert their neighbors'
oxen, for they shall inhibit their girth."
Monty Python's Life of Brian
83

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[AdaMagica]

Am Sonntag, 2. September 2018 14:10:36 UTC+2 schrieb Jeffrey R. Carter:
> On 09/02/2018 12:11 PM, AdaMagica wrote:
> > Am Samstag, 1. September 2018 00:51:42 UTC+2 schrieb Randy Brukardt:
> >> Similarly, in Ada 2012:
> >>      Ren1 : Natural renames Func(1); -- Legal.
> >>      Ren2 : Natural renames Natural'(Func(1)); -- Legal.
> >>      Ren3 : Natural renames Natural(Func(1)); -- Illegal!!!
> >>
> >> At least Ada 2020 will fix this one. But try this:
> >>       Ren4 : Boolean renames Boolean'(A and B); -- Legal.
> >>       Ren5 : Boolean renames Boolean'(A and then B); -- Illegal.
> >>       Ren6 : Boolean renames "and"(A, B); -- Legal.
> >>       Ren7 : Boolean renames A and B; -- Illegal.
> > 
> > Ahem, perhaps my Gnat 2018 is not correct, but it rejects only Ren7, which is an expression, and that cannot be renamed according to syntax.
> 
> FSF GNAT 8.0.1 rejects all 3:
> 
> $ gnatmake renaming.ads
> gcc-8 -c renaming.ads
> renaming.ads:9:27: renaming of conversion only allowed for tagged types
> renaming.ads:11:34: expect object name in renaming
I guess this is Ren5.
Why should Ren4 be legal? Also "A and B" is an expression, not an object.
"and"(A,B) is a function call, thus an object, whereas infix "and" in Ren4 is not a function call, but an expression.

Ah, I found AARM 6.4(3.a/3). This makes Ren4 legal.
So of course "and then" not being an operator, the expression in Ren5 is not considered a function call.

Truly bizarre rules.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Randy Brukardt]

"AdaMagica" <christ-usch.grein@t-online.de> wrote in message 
news:9cfac5e5-5475-4219-96f1-970a47e91c28@googlegroups.com...
> Am Sonntag, 2. September 2018 14:10:36 UTC+2 schrieb Jeffrey R. Carter:
>> On 09/02/2018 12:11 PM, AdaMagica wrote:
>> > Am Samstag, 1. September 2018 00:51:42 UTC+2 schrieb Randy Brukardt:
>> >> Similarly, in Ada 2012:
>> >>      Ren1 : Natural renames Func(1); -- Legal.
>> >>      Ren2 : Natural renames Natural'(Func(1)); -- Legal.
>> >>      Ren3 : Natural renames Natural(Func(1)); -- Illegal!!!
>> >>
>> >> At least Ada 2020 will fix this one. But try this:
>> >>       Ren4 : Boolean renames Boolean'(A and B); -- Legal.
>> >>       Ren5 : Boolean renames Boolean'(A and then B); -- Illegal.
>> >>       Ren6 : Boolean renames "and"(A, B); -- Legal.
>> >>       Ren7 : Boolean renames A and B; -- Illegal.
>> >
>> > Ahem, perhaps my Gnat 2018 is not correct, but it rejects only Ren7, 
>> > which is an expression, and that cannot be renamed according to syntax.
>>
>> FSF GNAT 8.0.1 rejects all 3:
>>
>> $ gnatmake renaming.ads
>> gcc-8 -c renaming.ads
>> renaming.ads:9:27: renaming of conversion only allowed for tagged types
>> renaming.ads:11:34: expect object name in renaming
> I guess this is Ren5.
> Why should Ren4 be legal? Also "A and B" is an expression, not an object.
> "and"(A,B) is a function call, thus an object, whereas infix "and" in Ren4 
> is not a function call, but an expression.
>
> Ah, I found AARM 6.4(3.a/3). This makes Ren4 legal.
> So of course "and then" not being an operator, the expression in Ren5 is 
> not considered a function call.
>
> Truly bizarre rules.

Yup. For what it's worth, I started investigating this when I was writing an 
ACATS test to check that "a qualified expression of an object is an object" 
and the inverse. So that ACATS test is relatively new and GNAT probaby was 
changed to do this exactly right at that time. (It's not the sort of case an 
implementer is likely to worry about absent a test).

                                       Randy.

Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:pmg5ec$rr7$1@gioia.aioe.org...
> On 2018-09-01 00:42, Randy Brukardt wrote:
...
>>> BTW, I prefer to fold constants before generating the tree. I.e. when
>>> Evaluate is called it returns either a value ("constant" node) or a new
>>> "dynamic" node.
>>
>> In Ada, you can't do folding until you know what the operations are, and 
>> you
>> don't know that until after resolution (that is, "*" could be predefined,
>> which you can fold, or user-defined, which you probably can't fold, and
>> certainly can't treat as static).
>
> I meant folding universal constants. During/after type resolution one 
> could generate the next tree and fold resolved constants then.

Ystill can't fold those in Ada. Consider:

       A : constant Saturated := 2 + 2;

You can't fold "2 + 2" without doing resolution first, since Ada says that a 
user-defined "+" operator would be used here (which is probably the case for 
a Saturated type). It's pretty rare that the universal operations get used 
in Ada code. To fold this expression (assuming a typical implementation for 
saturated "+"), you'd have resolve the expression, inline the "+" code, and 
then fold that.

...
>> I have a different vision of static verification than you do; I'm 
>> primarily
>> focused on static verification of Ada's dynamic checks. (Since that 
>> includes
>> pragma Assert and the like, you can verify almost everything this way.)
>
> It is OK, but low-level. One cannot organize such checks in a way of type 
> checks,  which have inheritance, parameter matching, composition of new 
> types. You lose a lot. Not everything can be checked by types, of course.

Well, actually, class-wide preconditions/postconditions do in fact have 
those characteristics. Of course, you need an OO design to take advantage of 
that -- but the point is you don't have to do *everything* with types.

                               Randy.