Re: How to get Ada to 'cross the chasm'?

Re: How to get Ada to 'cross the chasm'?

[Randy Brukardt]

Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
news:flkvhfF1m7fU1@mid.individual.net...
> On 18-05-10 01:05 , Randy Brukardt wrote:
>> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
>> news:flegbrFj0qjU1@mid.individual.net...
>>> On 18-05-04 01:27 , Randy Brukardt wrote:
>>>
>>>   [snip]
>>>
>>>> There is no realistic chance that Ada will
>>>> ever be changed enough to make it amenable to GC.
>
>    [snip]
>
>> If one uses the canonical linked-list
>> implementation of finalization, objects with controlled parts remain
>> reachable until the appropriate master goes away -- so nothing gets
>> collected. (And a similar effect is necessary regardless of how
>> finalization
>> is implemented.) There still can be an underlying GC and it can be used
>> just
>> fine -- no one said anything about it actually be able to collect much.
>
> Can one summarize the effect of the current Ada rules as follows:
>
> - for dynamically allocated objects that do not need finalization, a GC
> implementation could release them when they become unreachable, just as in
> other languages,
>
> - for objects that do need finalization, a GC implementation would have to
> delay releasing the objects until their types go out of scope, which in
> most cases would not happen before the program is about to terminate?
>
> If so, the conclusion is that GC is becoming ineffective for Ada, because
> Ada programming style is changing to make more use of controlled types and
> finalization.

Correct, this is a perfect summary. Perhaps it should be clarified that
these are all objects designated by some access type, but of course you 
don't
need any way to deallocate local objects - they go away for free.

                 Randy.

How to get Ada to “cross the chasm”?

[Dan'l Miller]

http://cppdepend.com/blog/?p=994

“According to Moore, the marketer should focus on one group of customers at a time, using each group as a base for marketing to the next group. The most difficult step is making the transition between visionaries (early adopters) and pragmatists (early majority).”

Do we all agree that Ada has never quite crossed the chasm (although it almost did during the late 1980s)?  How can Ada cross the chasm?

How will Ada use one base of programmers/software-engineers as a basis to move onto convincing another group of programmers/software-engineers of Ada's advantages?  Or is the purpose of Ada to preach to its current choir without trying to fill the pews with new parishioners?

How to get Ada to “cross the chasm”?

[Dan'l Miller]

Here is the referent book to which the WWWpage is referring:  https://en.wikipedia.org/wiki/Crossing_the_Chasm

“According to Moore, the marketer should focus on one group of customers at a time, using each group as a base for marketing to the next group. The most difficult step is making the transition between visionaries (early adopters) and pragmatists (early majority). This is the chasm that he refers to. If a successful firm can create a bandwagon effect in which enough momentum builds, then the product becomes a de facto standard. However, Moore's theories are only applicable for ••disruptive or discontinuous innovations••.”

Is Ada a disruptive leap forward?  If Ada95 had occurred while C++ was still in its cfront* era, then hands down, the answer would be a resounding yes.  Ada83 was effectively a mostly-yes, but the main message wasn't so much a great leap forward in capability (although Grady Booch's HOOD of that era and Alexander Stepanov's Ada version of what was to become C++'s Standard Template Library were arguably visions best expressed in Ada83 at the time due to lack of serious competitors).  No, Ada83's public persona was primarily the strictness of its semantic rule-set.   For those clever enough to see it, those compile-time assurances are a disruptive leap forward, but they often were not received as such by the pragmatists on the righthand side of the chasm.  For their marketspaces, SPARK and the Ravenscar Profile are disruptive leaps forward.  There is a chance that Ada2020's provably-correct tasking could be a disruptive leap forward, assuming 1) that it is actually (theoretically) achievable and 2) that to accomplish it doesn't incur restrictions that are too Draconian.

* For a decade, C-with-Classes and then renamed C++ had a single reference implementation:  cfront from Bell Labs, which translated CwC early on and C++ later on to C language, which was then compiled.

What would it take for Ada202X post-Ada2020 to be a disruptive leap-forward technology as coup de grâce after Ada2020's provably-correct tasking?

Re: How to get Ada to "cross the chasm"?

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:5e30eddf-5d24-40d5-b1a4-ad3746408bd6@googlegroups.com...

>Is Ada a disruptive leap forward?

I could make a pretty strong case that "disruptive leaps" are destroying 
human society. Not sure I would want to be a part of any such thing.

                                            Randy.

Re: How to get Ada to "cross the chasm"?

[Dmitry A. Kazakov]

On 26/04/2018 00:48, Randy Brukardt wrote:
> "Dan'l Miller" <optikos@verizon.net> wrote in message
> news:5e30eddf-5d24-40d5-b1a4-ad3746408bd6@googlegroups.com...
> 
>> Is Ada a disruptive leap forward?
> 
> I could make a pretty strong case that "disruptive leaps" are destroying
> human society. Not sure I would want to be a part of any such thing.

They rather replace the old society with a new one, usually by 
eliminating the members of the old, sometimes, physically. So a 
disruptive programming language leap is unlikely to happen. However a 
direct wire-to-brain interface could do that in some future.

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

Re: How to get Ada to “cross the chasm”?

[Paul Rubin]

"Dan'l Miller" <optikos@verizon.net> writes:
> How will Ada use one base of programmers/software-engineers as a basis
> to move onto convincing another group of programmers/software-
> engineers of Ada's advantages?  Or is the purpose of Ada to preach to
> its current choir without trying to fill the pews with new
> parishioners?

I'd like to know why Rust was invented: there was obviously a need for a
safer alternative to C++, but was Ada the answer that everyone simply
overlooked?

I think answering your question would require an informed and critical
comparison between Rust and Ada.  Something with real depth rather than
"verbose vs curly braces".  I do know Rust has formal-methods work going
on.

I've read about Rust a little but haven't yet tried to use it.  I've
played with Ada a little but not done anything serious.  In practice I
use C++ when I want to write low level compiled code these days, but of
course its shortcomings are well known.

I'm not convinced that a need for a non-garbage-collected big-systems
language even exists any more.  Obviously low-level, high reliability
realtime programming is important, but they tend to run on small
systems, or else they can be in fairly small subsystems of a bigger
system.  Tim Sweeney's well-known talk "The Next Mainstream Programming
Language" conveys a similar idea:

https://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf

Re: How to get Ada to “cross the chasm”?

[Dan'l Miller]

On Monday, April 16, 2018 at 12:36:03 AM UTC-5, Paul Rubin wrote:
> "Dan'l Miller" writes:
> > How will Ada use one base of programmers/software-engineers as a basis
> > to move onto convincing another group of programmers/software-
> > engineers of Ada's advantages?  Or is the purpose of Ada to preach to
> > its current choir without trying to fill the pews with new
> > parishioners?
> ...
> Tim Sweeney's well-known talk "The Next Mainstream Programming
> Language" conveys a similar idea:
> 
> https://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf

What an awesome fundamental approach to language design:  focus first and foremost on the troublesome frequent use-cases.  Customer first.  Not unlike Ada83 with DoD/NATO as customer first back in the day.

Re: How to get Ada to “cross the chasm”?

[Mehdi Saada]

Do most of those that choose Rust even aware of the existence or full capabilities of Ada 2012 ? Have they chosen weighing all pros and cons ? Doubt so.

Lady Ada is too good for its time, and for most people/programmers(being people), which happens to be idiot, not used to think rationally, or who lack the very ability. Not even talking about higher people dictating technical choices without being software engineers themselves...
One could count ad nauseam the list of things whose real worth has been overlooked in their time.

Re: How to get Ada to ?cross the chasm??

[Simon Clubley]

On 2018-04-16, Mehdi Saada <00120260a@gmail.com> wrote:
> Do most of those that choose Rust even aware of the existence or full
> capabilities of Ada 2012 ? Have they chosen weighing all pros and cons ?
> Doubt so.
>

Until the Ada compiler situation is sorted, then it doesn't matter how
powerful the language is and there's also no point doing widespread
promotion of Ada in today's world.

"Ada compiler situation" in this case means freely available compilers
for a wide range of architectures and operating systems and without the
GPL being used to constrain what you can do with your compiled binary.

(For anyone reading this who is not aware, the free Adacore compiler
available from the Adacore website imposes the GPL on any binaries that
you compile with it; you have to use the FSF branch to avoid this
constraint.)

Simon.

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

Re: How to get Ada to ?cross the chasm??

[Luke A. Guest]

Simon Clubley

> Until the Ada compiler situation is sorted, then it doesn't matter how
> powerful the language is and there's also no point doing widespread
> promotion of Ada in today's world.
> 

Yup, not only this but blog articles which point to software only available
in pro versions don’t help. They also recently said they’re working on
llvm, also useless because they’ll either not release it as open or they’ll
find a way to change the license to GPL.

Re: How to get Ada to ?cross the chasm??

[Dan'l Miller]

> They also recently said they’re working on 
> llvm, also useless because they’ll either not
> release it as open or they’ll 
> find a way to change the license to GPL.

Wait, when/where did AdaCore publicly say that they are working on an LLVM backend for GNAT?

(Their recent newsletter effectively said that the GCC-backended GNAT of today could generate aarch64-apple-darwin target, but that it had to be debugged only in the iOS simulator on Mac, not on actual iOS hardware.)

Re: How to get Ada to ?cross the chasm??

[Luke A. Guest]

Dan'l Miller <optikos@verizon.net> wrote:
>> They also recently said they’re working on 
>> llvm, also useless because they’ll either not
>> release it as open or they’ll 
>> find a way to change the license to GPL.
> 
> Wait, when/where did AdaCore publicly say that they are working on an
> LLVM backend for GNAT?

On irc.


> (Their recent newsletter effectively said that the GCC-backended GNAT of
> today could generate aarch64-apple-darwin target, but that it had to be
> debugged only in the iOS simulator on Mac, not on actual iOS hardware.)
> 

Which is also something which won’t see the light of day outside pro.

Re: How to get Ada to ?cross the chasm??

[toanpx.hut]

Sure. I think GNAT GPL is major obstacle for small team/start-up to adopt ADA. Another obstacle is the opensource/user-submit library. Ada should adapt to the development of IT world rather than stays in its traditional market.

Re: How to get Ada to ?cross the chasm??

[Lucretia]

On Tuesday, 10 July 2018 03:41:40 UTC+1, toanp...@gmail.com  wrote:
> Sure. I think GNAT GPL is major obstacle for small team/start-up to adopt ADA. 

It certainly is and has been proven to be so.

> Another obstacle is the opensource/user-submit library. Ada should adapt to the 
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A what?

> development of IT world rather than stays in its traditional market.

This and having the people who extend the language be more reasonable about depreacting old stuff is the only way it'll continue to live on. Once these people die, if nobody else takes over, the language will die, but it'll happen sooner if they don't embrace deprecating old stuff.

Re: How to get Ada to ?cross the chasm??

[Jacob Sparre Andersen]

Lucretia <laguest9000@googlemail.com> writes:
> On Tuesday, 10 July 2018 03:41:40 UTC+1, toanp...@gmail.com  wrote:

>> Sure. I think GNAT GPL is major obstacle for small team/start-up to
>> adopt ADA.
>
> It certainly is and has been proven to be so.

Why not spend time and resources promoting FSF GNAT builds, instead of
complaining about an AdaCore GNAT build?

If you remembered to link to where people can get a FSF GNAT build[1] every
time you respond to a discussion about to the license of GNAT GPL/GNAT
CE, people would be much more likely to notice that they don't have to
use GNAT GPL/GNAT CE.

Greetings,

Jacob

[1] FSF GNAT 8 is included in Debian, Fedora and Ubuntu.  FSF GNAT 7 is
    packaged for Windows in MSys (http://www.msys2.org/).
-- 
The backhoe is the natural predator of the fiber optic cable.

Re: How to get Ada to ?cross the chasm??

[Dan'l Miller]

On Monday, July 9, 2018 at 11:55:36 PM UTC-5, Jacob Sparre Andersen wrote:
> Lucretia  writes:
> > On Tuesday, 10 July 2018 03:41:40 UTC+1, toanp...@gmail.com  wrote:
> 
> >> Sure. I think GNAT GPL is major obstacle for small team/start-up to
> >> adopt ADA.
> >
> > It certainly is and has been proven to be so.
> 
> Why not spend time and resources promoting FSF GNAT builds, instead of
> complaining about an AdaCore GNAT build?
> 
> If you remembered to link to where people can get a FSF GNAT build[1] every
> time you respond to a discussion about to the license of GNAT GPL/GNAT
> CE, people would be much more likely to notice that they don't have to
> use GNAT GPL/GNAT CE.
> 
> Greetings,
> 
> Jacob
> 
> [1] FSF GNAT 8 is included in Debian, Fedora and Ubuntu.  FSF GNAT 7 is
>     packaged for Windows in MSys (http://www.msys2.org/).

Hmmm, what an interesting microstrategy.  As long as this is just mentioning textual proper-noun names, not deemed as excessive ‘advertising’ via spammy URLs, this is an excellent idea—not just on c.l.a, but everywhere:  StackOverflow, Slashdot, Reddit, and so forth.

A corollary is:  What can be done to FSF GNAT to make it that no one would even •want• to download AdaCore's GPL Community Editions at all, ever, in the first place?  I.e., what is deficient in FSF GNAT that, if improved, would cause FSF GNAT to practically eclipse all desire throughout humankind for AdaCore's GPL Community Editions to the point where people only talk of FSF GNAT as the premier brandname, never of AdaCore's GPL Community Editions?

Re: How to get Ada to ?cross the chasm??

[Lucretia]

On Tuesday, 10 July 2018 13:06:57 UTC+1, Dan'l Miller  wrote:
> Hmmm, what an interesting microstrategy.  As long as this is just mentioning textual proper-noun names, not deemed as excessive ‘advertising’ via spammy URLs, this is an excellent idea—not just on c.l.a, but everywhere:  StackOverflow, Slashdot, Reddit, and so forth.
> 
> A corollary is:  What can be done to FSF GNAT to make it that no one would even •want• to download AdaCore's GPL Community Editions at all, ever, in the first place?  I.e., what is deficient in FSF GNAT that, if improved, would cause FSF GNAT to practically eclipse all desire throughout humankind for AdaCore's GPL Community Editions to the point where people only talk of FSF GNAT as the premier brandname, never of AdaCore's GPL Community Editions?

It would need to be updated more often than it is and not be as buggy.

Re: How to get Ada to ?cross the chasm??

[Simon Wright]

Lucretia <laguest9000@googlemail.com> writes:

> On Tuesday, 10 July 2018 13:06:57 UTC+1, Dan'l Miller  wrote:

>> A corollary is: What can be done to FSF GNAT to make it that no one
>> would even •want• to download AdaCore's GPL Community Editions at
>> all, ever, in the first place?  I.e., what is deficient in FSF GNAT
>> that, if improved, would cause FSF GNAT to practically eclipse all
>> desire throughout humankind for AdaCore's GPL Community Editions to
>> the point where people only talk of FSF GNAT as the premier
>> brandname, never of AdaCore's GPL Community Editions?
>
> It would need to be updated more often than it is and not be as buggy.

Annually isn't all that bad; it's what GCC does. And AdaCore, even for
supported customers (you can get wavefronts, but good luck installing
those as project-standard for any sort of critical system)

And I don't believe that FSF GCC is any more buggy than CE.

Re: How to get Ada to ?cross the chasm??

[Alejandro R. Mosteo]

On 10/07/2018 16:26, Simon Wright wrote:
> Lucretia <laguest9000@googlemail.com> writes:
> 
>> On Tuesday, 10 July 2018 13:06:57 UTC+1, Dan'l Miller  wrote:
> 
>>> A corollary is: What can be done to FSF GNAT to make it that no one
>>> would even •want• to download AdaCore's GPL Community Editions at
>>> all, ever, in the first place?  I.e., what is deficient in FSF GNAT
>>> that, if improved, would cause FSF GNAT to practically eclipse all
>>> desire throughout humankind for AdaCore's GPL Community Editions to
>>> the point where people only talk of FSF GNAT as the premier
>>> brandname, never of AdaCore's GPL Community Editions?
>>
>> It would need to be updated more often than it is and not be as buggy.
> 
> Annually isn't all that bad; it's what GCC does. And AdaCore, even for
> supported customers (you can get wavefronts, but good luck installing
> those as project-standard for any sort of critical system)
> 
> And I don't believe that FSF GCC is any more buggy than CE.

FWIW, I normally test my projects with the latest AdaCore and FSF 
versions and since a couple of years (as 2012 feature-dust settled) I 
haven't found significant differences.

Re: How to get Ada to ?cross the chasm??

[Björn Lundin]

On 2018-07-10 14:06, Dan'l Miller wrote:
> 
> A corollary is:  What can be done to FSF GNAT to make it that no one would even •want• to download AdaCore's GPL Community Editions at all, ever, in the first place?

A full run-time.
downloading Gnat GPL 2018 64-bit windows was a disappointment

from system.ads

> pragma Restrictions (No_Exception_Propagation);
> --  Only local exception handling is supported in this profile
>
> pragma Restrictions (No_Exception_Registration);
> --  Disable exception name registration. This capability is not used >
because
> --  it is only required by exception stream attributes which are not
> supported
> --  in this run time.
>
> pragma Restrictions (No_Implicit_Dynamic_Code);
> --  Pointers to nested subprograms are not allowed in this run time,
> in order
> --  to prevent the compiler from building "trampolines".
>
> pragma Restrictions (No_Finalization);
> --  Controlled types are not supported in this run time
>
> pragma Restrictions (No_Tasking);
> --  Tasking is not supported in this run time
>
> pragma Discard_Names;
> --  Disable explicitly the generation of names associated with
> entities in
> --  order to reduce the amount of storage used. These names are not
> used anyway
> --  (attributes such as 'Image and 'Value are not supported in this
> run time).


No tasking and only local exception is not enough for me.
I have not contemplated what the other restrictions really means for me


-- 
--
Björn

Re: How to get Ada to ?cross the chasm??

[Simon Wright]

Björn Lundin <b.f.lundin@gmail.com> writes:

> A full run-time.
> downloading Gnat GPL 2018 64-bit windows was a disappointment
>
> from system.ads
>
>> pragma Restrictions (No_Exception_Propagation);
>> --  Only local exception handling is supported in this profile
>>
>> pragma Restrictions (No_Exception_Registration);
>> --  Disable exception name registration. This capability is not used
>> because
>> --  it is only required by exception stream attributes which are not
>> supported
>> --  in this run time.
>>
>> pragma Restrictions (No_Implicit_Dynamic_Code);
>> --  Pointers to nested subprograms are not allowed in this run time,
>> in order
>> --  to prevent the compiler from building "trampolines".
>>
>> pragma Restrictions (No_Finalization);
>> --  Controlled types are not supported in this run time
>>
>> pragma Restrictions (No_Tasking);
>> --  Tasking is not supported in this run time
>>
>> pragma Discard_Names;
>> --  Disable explicitly the generation of names associated with
>> entities in
>> --  order to reduce the amount of storage used. These names are not
>> used anyway
>> --  (attributes such as 'Image and 'Value are not supported in this
>> run time).
>
>
> No tasking and only local exception is not enough for me.
> I have not contemplated what the other restrictions really means for me

Those restrictions are what you'd find in a zero-footprint bare machine
package. Are you quite sure about what you downloaded?

Re: How to get Ada to ?cross the chasm??

[Björn Lundin]

On 2018-07-10 16:19, Simon Wright wrote:

>> No tasking and only local exception is not enough for me.
>> I have not contemplated what the other restrictions really means for me
> 
> Those restrictions are what you'd find in a zero-footprint bare machine
> package. Are you quite sure about what you downloaded?
> 

Hmm, hang on. There are two system.ads
The one stated above is in
x86_64-pc-mingw32\BSPs\native-x86_64\zfp\arch

and the other is in
x86_64-pc-mingw32\7.3.2\adainclude


The one quoted above is the first one.
But it makes more sense if the compiler would use the second one.
The reason I thought it was the first one is silent crashes
on tasks- But that migth have other reasons.

But what is the
x86_64-pc-mingw32\BSPs\native-x86_64\zfp\arch\system.ads
doing here? cross compile ? to what?


-- 
--
Björn

Re: How to get Ada to ?cross the chasm??

[Dennis Lee Bieber]

On Tue, 10 Jul 2018 16:57:19 +0200, Björn Lundin <b.f.lundin@gmail.com>
declaimed the following:

>
>But what is the
>x86_64-pc-mingw32\BSPs\native-x86_64\zfp\arch\system.ads
>doing here? cross compile ? to what?
>

	Just what it says... Zero-Foot-Print (ie; NO run time) for Native (bare
board) x86-64.


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

Re: How to get Ada to ?cross the chasm??

[Björn Lundin]

On 2018-07-10 17:31, Dennis Lee Bieber wrote:
> On Tue, 10 Jul 2018 16:57:19 +0200, Björn Lundin <b.f.lundin@gmail.com>
> declaimed the following:
> 
>>
>> But what is the
>> x86_64-pc-mingw32\BSPs\native-x86_64\zfp\arch\system.ads
>> doing here? cross compile ? to what?
>>
> 
> 	Just what it says... Zero-Foot-Print (ie; NO run time) for Native (bare
> board) x86-64.
> 

Well, yes, but I have not seen that before in other ada core
distributions. What does BSP stand for?


-- 
--
Björn

Re: How to get Ada to ?cross the chasm??

[Lucretia]

On Tuesday, 10 July 2018 19:12:30 UTC+1, björn lundin  wrote:
> On 2018-07-10 17:31, Dennis Lee Bieber wrote:
> > On Tue, 10 Jul 2018 16:57:19 +0200, Björn Lundin <>
> > declaimed the following:
> > 
> >>
> >> But what is the
> >> x86_64-pc-mingw32\BSPs\native-x86_64\zfp\arch\system.ads
> >> doing here? cross compile ? to what?
> >>
> > 
> > 	Just what it says... Zero-Foot-Print (ie; NO run time) for Native (bare
> > board) x86-64.
> > 
> 
> Well, yes, but I have not seen that before in other ada core
> distributions. What does BSP stand for?

It's for embedded or bare metal work. Board Support Package, i.e. definitions of registers n stuff for a board, i.e. STM32*.

Re: How to get Ada to ?cross the chasm??

[Maciej Sobczak]

> A corollary is:  What can be done to FSF GNAT to make it that no one would even •want• to download AdaCore's GPL Community Editions at all, ever, in the first place?

SPARK.

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

Re: How to get Ada to ?cross the chasm??

[Dan'l Miller]

On Tuesday, July 10, 2018 at 1:26:36 PM UTC-5, Maciej Sobczak wrote:
> On Tuesday, July 10, 2018 at 7:06:57 AM UTC-5, Dan'l Miller wrote:
> > A corollary is:  What can be done to FSF GNAT to make it that no one would even •want• to download
> > AdaCore's GPL Community Editions at all, ever, in the first place?
> 
> SPARK.

Outside of AdaCore's paying dual-license customers, SPARK (and thus SPARK Library) has a GPL license, because it is outside of AJPO's Ada9X Project's contractual requirement to require licensing of the NYU Ada compiler and the FSU Ada standard library via GMGPL originally, morphed to GPLv3 with Runtime Library Extension nowadays.  Does any source-code repository for SPARK licensed by GPLv3 with •Runtime Library Exception• or GMGPL exist at all (even if quite old, even if from Altran Praxis prior to acquisition by AdaCore)?

Conversely, for projects that are already licensed by GPLv3 (and thus the viral spread of SPARK Library's GPLv3 to them is a big idempotent no-op), does there exist a non-licensing/technical impracticality of using GPLed SPARK with GPLv3-RLEed FSF GNAT?

Re: How to get Ada to ?cross the chasm??

[Simon Wright]

Jacob Sparre Andersen <jacob@jacob-sparre.dk> writes:

> Lucretia <laguest9000@googlemail.com> writes:
>> On Tuesday, 10 July 2018 03:41:40 UTC+1, toanp...@gmail.com  wrote:
>
>>> Sure. I think GNAT GPL is major obstacle for small team/start-up to
>>> adopt ADA.
>>
>> It certainly is and has been proven to be so.
>
> Why not spend time and resources promoting FSF GNAT builds, instead of
> complaining about an AdaCore GNAT build?
>
> If you remembered to link to where people can get a FSF GNAT build[1] every
> time you respond to a discussion about to the license of GNAT GPL/GNAT
> CE, people would be much more likely to notice that they don't have to
> use GNAT GPL/GNAT CE.
>
> Greetings,
>
> Jacob
>
> [1] FSF GNAT 8 is included in Debian, Fedora and Ubuntu.  FSF GNAT 7 is
>     packaged for Windows in MSys (http://www.msys2.org/).

Darwin:
https://sourceforge.net/projects/gnuada/files/GNAT_GCC%20Mac%20OS%20X/

(I'm sorry about the use of spaces in that name, I didn't set it up. I'm
rather reluctant to change it now and lose all the links (and download
history))

Re: How to get Ada to “cross the chasm”?

[Dan'l Miller]

On Monday, April 16, 2018 at 12:36:03 AM UTC-5, Paul Rubin wrote:
> "Dan'l Miller" writes:
> > How will Ada use one base of programmers/software-engineers as a basis
> > to move onto convincing another group of programmers/software-
> > engineers of Ada's advantages?  Or is the purpose of Ada to preach to
> > its current choir without trying to fill the pews with new
> > parishioners?
> 
> I'd like to know why Rust was invented: there was obviously a need for a
> safer alternative to C++, but was Ada the answer that everyone simply
> overlooked?

I keep seeing hints in the Rust community that they are aware of the existence of Ada but have never written a program in Ada because of perceived insurmountable time-expenditure/odds/learning-curve.

https://www.reddit.com/r/rust/comments/2og8xf/why_rust_started_rather_than_ada

https://www.reddit.com/r/rust/comments/48vh1m/rust_vs_ada

https://lwn.net/Articles/547614

http://lambda-the-ultimate.org/node/5277

to pick a few.

> I think answering your question would require an informed and critical
> comparison between Rust and Ada.

I haven't yet found •that• blow-by-blow-narrated feature-comparison between Rust and Ada.  But regarding “need for a non-garbage-collected big-systems language even exists any more” as you stated below, this book at the URL below is by far the most scathing critique of C++2011 and C++2014 (and by inference C++2017).  [C++11, C++14, and C++17 are effectively a trilogy that effectively drastically overhauls C++ to be a rather different language than C++1998 and its bug-fix C++2003.]  So Rust is one vector of momentum for big-systems languages, going in roughly the same direction as Ada:  safety and de-emphasis of write-once just-barely-working C-language source code.  But the resurgence of popularity of C++ is apparently occurring due to (or in spite of?) an avalanche of new very finicky language features that are easy to utilize incorrectly.

http://shop.oreilly.com/product/0636920033707.do

Scott Meyers _Effective C++_ series books from the 1990s had an over-arching message effectively of:  ‘just stay away from these troubled topics in C++ and you'll be just fine.’  But this new book in the series has a drastically different feel and message.  It is written in the same self-help book style as his 1990s books at the level of the surface text, but the subtext for the clever reader with deep-insight reading comprehension is effectively a subversive harsh critique of modern C++.  Out of the 42 gotchas that Meyers explores in breadth & depth, there are numerous places where Meyers incredulously gasps* how surprising a new feature of C++ is or behaves.  (And I am using ‘surprise’ there as a pejorative, as in violations of the Principle of Least Surprise.)

* Even though the book is ink-on-paper, the reader can quite clearly hear the author's open-mouth drop-jawed gasps in the implied subtext that the author plasters over with the self-help surface-text.

The reason that I bring this up is:  there is a sector of the programming/engineering society who thinks that a big-systems language not only needs the 42 language features at the heart of Meyers most-recent book in his _Effective C++_ series, but—more troubling—these 42 language features need to be messy affairs that need a 300-page book to untangle various knots.  Many of these 42 language features in isolation seem to be very much needed to bring C++'s vision into fruition (fixing various gaps, goofs & gaffs in C++2003), but the reader of _Effective Modern C++_ is easily left with the feeling of:  “oh really?!, certainly some other programming language could tame the beast of these features quite differently and still accomplish all the same goals to the same degree of efficiency (and vastly better correctness and vastly less chance of taking a misstep off the narrow path through a field of hellfires and landmines).”

>  Something with real depth rather than
> "verbose vs curly braces".  I do know Rust has formal-methods work going
> on.

Coq-esque and Zed-notation-esque systems of logic need to be the future of Ada.

> I'm not convinced that a need for a non-garbage-collected big-systems
> language even exists any more.  Obviously low-level, high reliability
> realtime programming is important, but they tend to run on small
> systems, or else they can be in fairly small subsystems of a bigger
> system.

Conversely, these aren't small systems in the Commodore-64 sense.  These embedded systems and tablet computers are 1 or 2 or 3 decimal orders of magnitude bigger (e.g., DRAM; MIPS; FLOPS in GPUs/physics-processors) than minicomputers prior to 1990.  Low power utilization and augmented-reality commonplace in consumer devices begets a prohibition on luxurious interpreted-language and automatic-garbage-collection techniques.  Even IoT devices are having processors and operating systems and amounts of DRAM that would put some minicomputers of that era to shame; those are the same minicomputers that were large systems during the era in which Ada1983 was designed.

The vast majority of the new language features in C++{2011, 2014, 2017} fall into the category of:  the programmer helps the compiler out by declaring finer-points of programmer-intent so as to evoke various optimizations & efficiencies by the compiler.  Okay, there is that on one hand.  Then on the other hand, the {OCaml, Swift, Rust, Dart} & even interpreted/JIT-compiled {Python, Java, Ruby, Perl6} and, yes, even Ada approach is that the compiler/language-translator can cleverly deduce highly-efficient implementations without C++{2011, 2014, 2017}'s fine-grained syntactic & semantic constructs.  It seems the only way for this to be true for Ada is for Ada202X to have a CoQ-esque or Zed-notation-esque logic-deducing theorem prover in it.  (Indeed, the provably-correct tasking of Ada2020 might need it as well.)

It appears that the future is
1) C++{2011, 2014, 2017}'s need for Scott Meyer's _Effective Modern C++_ untangling of knots, where the compiler is a happy intelligent dog of sorts who looks to its master to teach the dog new tricks (and to not be malicious)
versus
2) CoQ-esque or Zed-notation-esque logic-deducing theorem provers grinding on the source code to effectively have a rigorous argument with the compiler-theorem-prover about the correctness of the source code as mathematical proof, where the compiler-theorem-prover is effectively an automated peer-review mechanism of sorts.
versus
3) glorified PHP where the language-translator just doesn't care that all that much about strict-enforcement principles & correctness on one hand or squeezing out efficiency on the other hand, but rather these languages focus on the programmer adoringly loving to typewrite their source code on a keyboard, right down in new editions of the language to even debating which identifier names in the standard libraries/frameworks are the very most beautiful that programmers would enjoy typewriting. (C#, Java, and Swift seem to fall into this category.)
versus
4) classic cars of yesteryear that don't try to compete with modern cars, but rather just stay refurbished enough to keep running.

I am hoping that #4 is not the model for Ada:  “Hey, look kids, there goes a Model Ada down the road.  I haven't seen one of those antiques since I was your age.  Wow, we used to think that that Model Ada was what the future would be like; boy, were we wrong.”  I am very much hoping that Ada sees #2 above as its emerging mission to extrapolate its current foundation of strengths.

(I am really really hoping that the Ada1995 era of mimicking C/C++ feature-set has reached its natural conclusion, so that #1 above is precluded for Ada.  In #3 above, I am pretty sure that Swift on iOS/MacOS, C# on Windows, Java on Android, and Dart on Fuchsia all have the programmers-love-to-typewrite-me marketspace all locked up on their respective walled gardens; the only question is whether one of them will emerge as cross-platform to the other 3 to then compete in the portability domain with the historically portability-minded languages:  C, C++, and Ada.)

Re: How to get Ada to “cross the chasm”?

[Dan'l Miller]

On Tuesday, April 17, 2018 at 10:53:15 AM UTC-5, Dan'l Miller wrote:
> On Monday, April 16, 2018 at 12:36:03 AM UTC-5, Paul Rubin wrote:
> > "Dan'l Miller" writes:
> > > How will Ada use one base of programmers/software-engineers as a basis
> > > to move onto convincing another group of programmers/software-
> > > engineers of Ada's advantages?  Or is the purpose of Ada to preach to
> > > its current choir without trying to fill the pews with new
> > > parishioners?
> > 
> > I'd like to know why Rust was invented: there was obviously a need for a
> > safer alternative to C++, but was Ada the answer that everyone simply
> > overlooked?
> 
> I keep seeing hints in the Rust community that they are aware of the existence of Ada but have never written a program in Ada because of perceived insurmountable time-expenditure/odds/learning-curve.
> 
> https://www.reddit.com/r/rust/comments/2og8xf/why_rust_started_rather_than_ada
> 
> https://www.reddit.com/r/rust/comments/48vh1m/rust_vs_ada
> 
> https://lwn.net/Articles/547614
> 
> http://lambda-the-ultimate.org/node/5277
> 
> to pick a few.
> 
> > I think answering your question would require an informed and critical
> > comparison between Rust and Ada.
> 
> I haven't yet found •that• blow-by-blow-narrated feature-comparison between Rust and Ada.

  But I found something roughly in the ballpark:  comparison of Rust to nearly all the lack-of-safeties that Ada stands (or tries to stand) against.  See URL below.

> http://shop.oreilly.com/product/0636920033707.do
> 
> Scott Meyers _Effective C++_ series books from the 1990s had an over-arching message effectively of: 
> ‘just stay away from these troubled topics in C++ and you'll be just fine.’  But this new book in the series
> has a drastically different feel and message.  It is written in the same self-help book style as his 1990s
> books at the level of the surface text, but the subtext for the clever reader with deep-insight reading
> comprehension is effectively a subversive harsh critique of modern C++.

And here is a (self-)critique of where (some current or prior version of) Rust falls short of its goals in whole or in part.

https://doc.rust-lang.org/nomicon

Re: How to get Ada to “cross the chasm”?

[Paul Rubin]

"Dan'l Miller" <optikos@verizon.net> writes:
> I keep seeing hints in the Rust community that they are aware of the
> existence of Ada but have never written a program in Ada because of
> perceived insurmountable time-expenditure/odds/learning-curve.

Heh, nice.  They found it easier to invent a whole new language than
read an Ada book ;-).

> this book at the URL below is by far the most scathing critique of
> C++2011 and C++2014 (and by inference C++2017)...

I like that book and didn't see it as a scathing critique, but I came to
it as a naive reader.

> Scott Meyers _Effective C++_ series books from the 1990s had an
> over-arching message effectively of: ‘just stay away from these
> troubled topics in C++ and you'll be just fine.’

That's still the over-arching message of the current C++ world:

https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces-cpp-core-guidelines

> * Even though the book is ink-on-paper, the reader can quite clearly
> hear the author's open-mouth drop-jawed gasps 

Heehee, I must have missed those.  I'm sure they are there but I wasn't
looking at them.

> but the reader of _Effective Modern C++_ is easily left with the
> feeling of: “oh really?!, certainly some other programming language
> could tame the beast of these features quite differently

Don't forget the requirement of not breaking legacy C++ code.  Doing
better by getting rid of that requirement was part of the idea of Rust.

> Coq-esque and Zed-notation-esque systems of logic need to be the
> future of Ada.


You probably understand this stuff better than I do, so I don't mean to
be telling you stuff you already know.  I'm writing this partly to check
my own understanding.

Coq is based on constructive type theory (CTT) which is more usually
associated with functional programming than imperative programming.  It
can be used to prove theorems about imperative programs, but also, Coq
itself can be seen as an ML dialect with super-precise types.  For
example, the CompCert verified C compiler (compcert.inria.fr) is written
in Coq.

Z-notation is used to specify the behaviour of a program, which is then
verified using external tools like SPARK using state transformer logic
(Hoare triples, separation logic, etc).

State transformer logic is practice more "powerful" than CTT, but much
harder to use.  CTT usually only tries to prove the denotational
correctness of a program, but not its resource bounds or even its
totality.  So CompCert's proofs only aim to guarantee that CompCert will
never generate wrong code, not that the compiler will never "diverge"
(fail to produce an output, e.g. by running out of memory and crashing).

Divergence in a compiler is annoying but not disastrous the way wrong
code would be.  If Compcert runs out of memory, you can refactor your
program or compile it on a bigger computer.  I remember being surprised
to learn that a lot of SPARK is about proving that your programs never
throw exceptions or crash or experience arithmetic overflow in machine
ints.  In functional programming we normally don't think about that too
much.

Obviously in critical realtime systems you do care about totality, the
program MUST give a right answer, not merely refrain from giving wrong
answers.  But since even a perfectly correct program can give a wrong or
divergent answer if the power fails or cosmic rays flip memory bits in
the hardware, critical systems MUST also have ECC, redundant CPUs and
power, etc. etc.  If you don't have that hardware redundancy then Ada
instead of Coq might very well be overkill on the software side.

So we're back to the idea that critical realtime systems are a niche
that necessarily require extreme approaches in hardware as well as the
software, while non-realtime systems (even correctness-critical ones
like compilers) don't need totality assurance beyond what one gets from
normal software testing.  That means they can use GC, which really does
make life a lot simpler.

Btw, here's some cheap dev boards with safety-oriented cpus (intended
for medical and automotive applications):

http://www.ti.com/tools-software/launchpads/launchpads.html#hercules_mcu

They use cpus with dual processor cores running in lockstep and that
have ECC on the internal flash and ram (I thought I remembered something
about the internal data paths having it too).  If you're not using a CPU
like that, and you're not short of ram or cpu cycles, then what does
using Ada really buy you?

> Low power utilization and augmented-reality commonplace in consumer
> devices begets a prohibition on luxurious interpreted-language and
> automatic-garbage-collection techniques.

Meh, how much of that code is really computation intensive?  An
augmented-reality system likely has a GPU-like processor doing the heavy
computation, while the surrounding stuff (UI etc.) can well be written
in Python.  Here's a little embedded board (ARM Cortex M0, 256KB flash,
32KB ram) that runs Python nicely: https://www.adafruit.com/product/3500

> Even IoT devices are having processors and operating systems and
> amounts of DRAM that would put some minicomputers of that era to
> shame;

Yep, it's great.  That means we can use garbage collected, interpreted
languages on them now. ;)

> It seems the only way for this to be true for Ada is for Ada202X to
> have a CoQ-esque or Zed-notation-esque logic-deducing theorem prover
> in it.

This is much harder to use than we might hope.  It's not all that
automatic, and the more automated ones (as mentioned above) tend to rely
on garbage collection among other things.

> I am hoping that #4 is not the model for Ada: “Hey, look kids, there
> goes a Model Ada down the road...."

Heehee, as an occasional Forth user (not for anything serious, but it's
fun) I sympathize with this.

Re: How to get Ada to “cross the chasm”?

[Dan'l Miller]

On Thursday, April 19, 2018 at 12:57:07 AM UTC-5, Paul Rubin wrote:
> "Dan'l Miller" writes:
> > Coq-esque and Zed-notation-esque systems of logic need to be the
> > future of Ada.
> 
> ...
> Coq is based on constructive type theory (CTT) which is more usually
> associated with functional programming than imperative programming.  It
> can be used to prove theorems about imperative programs, but also, Coq
> itself can be seen as an ML dialect with super-precise types.  For
> example, the CompCert verified C compiler (compcert.inria.fr) is written
> in Coq.

  Yes, that is true, but the Coq community has been pushing Coq far beyond its origins in CTT & derivational-type theory for merely functional programming.  Coq is increasingly setting its sights on the wild-west worlds of C and machine code:

http://plv.csail.mit.edu/bedrock

https://www.lri.fr/~paulin/LASER/course-notes.pdf

https://dl.acm.org/citation.cfm?doid=2676724.2693162

http://vst.cs.princeton.edu

https://archive.org/details/CertifiedProgrammingWithDependentTypes

https://galois.com/blog/2014/07/tech-talk-verifying-c-programs-coq-using-vst

https://www.microsoft.com/en-us/research/publication/coq-worlds-best-macro-assembler/?from=http%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fum%2Fpeople%2Fnick%2Fcoqasm.pdf

http://www.cl.cam.ac.uk/%7Epes20/pip2014-slides/PiP2014.pdf


> Z-notation is used to specify the behaviour of a program, which is then
> verified using external tools like SPARK using state transformer logic
> (Hoare triples, separation logic, etc).

I bring up Z-notation as a relatively-widely-known example of logic-based system-specification language to the Ada community because I find it extraordinarily odd that on one hand Ada seeks to be the safety language for critical systems (OMG! we're all gonna die without Ada), but then on the other hand defines Ada's language semantics in English prose that compiler vendors cannot take as direct input into their compiler implementations.  (And then the Ada community argues for decades on end here at comp.lang.ada whether this darned compiler versus my exemplary program versus the ARM/AARM got it wrong regarding some unexpected Ada behavior, when a nontrivial fraction of these debates have the unverified-incompleteness* of or the ambiguity of English prose in the ARM as the root cause.)

* Oops, the ARG forgot to handle that case, which might have been easily caught under formal-methods analysis of a non-prose specification of Ada's semantics.

Speaking of SPARK, here is SPARK-esque analogue for a subset of C++:

http://EscherTech.com/papers/CanCPlusPlusBeMadeAsSafeAsSpark.pdf

http://EscherTech.com/papers/CanCPlusPlusBeMadeAsSafeAsSpark.ppt

Btw, Luke Guest, your envisioned out-with-the-cruft-&-in-with-the-well-oiled-machine Ada for the 21st century would not have its language specification in English prose.

Re: How to get Ada to “cross the chasm”?

[Paul Rubin]

"Dan'l Miller" <optikos@verizon.net> writes:
> Coq is increasingly setting its sights on the wild-west worlds of C
> and machine code: [links]

Thanks, yes, I had seen some of those, will look at the others.  But,
it's a niche area.  Most programmers I meet these days have never
written anything in C or machine code.  Realtime programming in general
is a niche area: most programmers I know have never done any.  Critical
systems are also niche, and realtime critical systems are the most niche
of all.  And finally I don't know whether BIG critical realtime systems
exist at all; and if they do, whether they could be split up.

Ada, especially with high-end verification methods, is about the
intersection of it all, i.e. critical AND hard-realtime AND large.
Those are intense requirements and it takes a lot of work to satisfy
them.  If you aren't faced with those requirements, why do all that
work?  Non-realtime means you can use arbitrary precision arithmetic
(eliminating all those proofs about integer overflow) and garbage
collection (automating memory management).  Realtime but non-critical
means you can get adequate reliability from traditional software testing
instead of proof systems.  Realtime and critical, but not too large,
means you can jettison a lot of Ada's features and work with a much more
tractable subset (e.g. the original SPARK).

"Crossing the chasm" gives a picture of a large set of problems for
which Ada is the best solution, where the challenge is getting people to
appreciate this fact.  But I'm having trouble seeing the large set of
problems, especially once formal verification is part of the
prescription:

- If the problem is not realtime, it's probably easier to use a garbage
  collected language instead of Ada.  Realtime is a niche area of
  programming, so even if Ada completely takes it over, the "chasm"
  between Ada and the wider programming world is not even slightly
  crossed.

- If the problem is not critical (human safety is not endangered, and
  mistakes aren't enormously expensive to repair), then at least for
  now, verification is still much harder than ordinary testing.  If
  you're proposing making verification as easy as testing, that's great,
  but it's a mammoth research problem rather than a matter of
  straightforward advocacy or tool development.

- A lot of not-so-critical realtime code is being written in C (e.g. on
  embedded MCUs in consumer electronics).  I'd agree that we're probably
  better off if that stuff was instead done in Ada, with or without
  formal verification.

- Finally I think there are realtime problems like bit-banging comms
  protocols that might have been done with software back in the day, but
  that now get done with FPGA's (i.e. in VHDL or Verilog) now that
  FPGA's are cheap, since it's much easier to get deterministic timing
  with FPGA's than with CPUs.  So a fair number of applications have
  actually been removed from Ada's problem space.

> defines Ada's language semantics in English prose that compiler
> vendors cannot take as direct input into their compiler
> implementations.

Yes, this is an area where mechanized semantics would be a big win.
They had to do that for C in order to write CompCert.  You might look at
Twelf which is designed for such purposes.

> Speaking of SPARK, here is SPARK-esque analogue for a subset of C++:
> http://EscherTech.com/papers/CanCPlusPlusBeMadeAsSafeAsSpark.pdf

Thanks, this is interesting.

Re: How to get Ada to “cross the chasm”?

[Dan'l Miller]

On Friday, April 20, 2018 at 5:27:10 AM UTC-5, Paul Rubin wrote:
> - Finally I think there are realtime problems like bit-banging comms
>   protocols that might have been done with software back in the day, but
>   that now get done with FPGA's (i.e. in VHDL or Verilog) now that
>   FPGA's are cheap, since it's much easier to get deterministic timing
>   with FPGA's than with CPUs.  So a fair number of applications have
>   actually been removed from Ada's problem space.

note the FPGA-instead-of-GPU for FPGAs in datacenters on the Intel Arria 10 GX GPU card:
https://www.theregister.co.uk/2018/04/13/slicker_server_rackery_and_epyc_gateways

the other big FPGA manufacturer is doing much the same for FPGAs in datacenters:
https://www.theregister.co.uk/2018/03/19/xilinx_everest_acap_super_fpga

Embedded realtime systems are going to be going mainstream in data processing with FPGAs in the datacenter.  Ada's traditional marketspace is going to get much bigger very quickly.

Also, we always talk about Ada+SPARK.  Why not Ada+VHDL, which is its syntactic cousin, as a smooth and seamless programming environment for FPGA development:  software and netmask in sibling languages?

Re: How to get Ada to “cross the chasm”?

[Shark8]

On Friday, April 20, 2018 at 7:25:41 AM UTC-6, Dan'l Miller wrote:
> 
> Also, we always talk about Ada+SPARK.  Why not Ada+VHDL, which is its syntactic cousin, as a smooth and seamless programming environment for FPGA development:  software and netmask in sibling languages?

If I had a good $30 Million or so, I'd totally drop it on hiring out for an Ada+VHDL IDE (not editor, environment) with:
- An IR on the order of AIR or DIANA, though with database-storage as a consideration.
- Implementation of the better-than-Continuous-Integration *AND* versioning solution described in this paper: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.26.2533&rep=rep1&type=pdf
- Written in 100% Ada; SPARK proving for the compiler-proper.
- Modularized tools, such as pluggable backends.
- Implementation of my Ada Project Manager solution, after rewriting it in pure Ada syntax.
- Application of SPARK provers to VHDL.

And all the above means you could have provers on entire systems, H/W and S/W!

Re: How to get Ada to “cross the chasm”?

[Paul Rubin]

Shark8 <onewingedshark@gmail.com> writes:
> for an Ada+VHDL IDE

Dan'l Miller also mentioned Ada+VHDL.  What is it?  I don't see many
search results.  Of course there is a well-known general resemblance
between Ada and VHDL, but I don't know of any meaningful composition of
them.

> - Written in 100% Ada; SPARK proving for the compiler-proper.

Why would you want to do that, when a ton of SPARK verification
conditions are about proving integer overflow safety, memory
boundedness, and other freedom from exceptions?  E.g. I think it stops
you from using natural programming techniques like recursion (at least,
MISRA C does not allow recursion).  That is all crucial for realtime
systems, but a compiler is not a realtime system.

If you use CompCert's approach (use recursion and unbounded arithmetic
and automatic memory management in the compiler as much as you want,
prove that the compiler won't generate bad code, use ordinary software
testing to give reasonable assurance that the compiler doesn't crash,
and call it a day) you can probably save a heck of a lot of work.

Is it even possible to guarantee that a compiler can accept every valid
program and also never crash?  If Ada programs can have nested
parenthesized expressions or begin/end blocks of arbitrary depth, then
any sane approach to parsing will eventually run out of memory if the
nesting is deep enough.

CompCert itself is already a magnificant feat.  I have no idea whether a
fully proven compiler in SPARK is feasible at all.  Has anyone ever done
anything like that?

> - Application of SPARK provers to VHDL.

Does anyone do that?  There's some work on HDL verification but it uses
completely different approaches.

Re: How to get Ada to “cross the chasm”?

[Shark8]

On Friday, April 20, 2018 at 11:41:23 AM UTC-6, Paul Rubin wrote:
> Shark8 writes:
> > for an Ada+VHDL IDE
> 
> Dan'l Miller also mentioned Ada+VHDL.  What is it?

I was meaning it in the sense of using both together, like saying OpenGL+PostScript for a hypothetical windowing-system.

> Of course there is a well-known general resemblance between Ada and VHDL, but I don't know of any meaningful composition of them.

It's more than superficial: VHDL is an outgrowth of the DoD's VHIC (Very High Speed Integrated Circuit) project.

Had the proposed APSE come to fruition, I imagine a VHDL analog would have been done either separately or [more likely] as an extension. (APSE links: https://www.sciencedirect.com/science/article/abs/pii/0920548987900481 https://en.wikipedia.org/wiki/APSE  )

> > - Written in 100% Ada; SPARK proving for the compiler-proper.
> 
> Why would you want to do that, when a ton of SPARK verification
> conditions are about proving integer overflow safety, memory
> boundedness, and other freedom from exceptions?  E.g. I think it stops
> you from using natural programming techniques like recursion (at least,
> MISRA C does not allow recursion).  That is all crucial for realtime
> systems, but a compiler is not a realtime system.

The need for correctness within the compiler is clear, and the only way that scales with something as complex as a compiler is proving. (Extensive tests simply aren't good enough.)

> If you use CompCert's approach (use recursion and unbounded arithmetic
> and automatic memory management in the compiler as much as you want,
> prove that the compiler won't generate bad code, use ordinary software
> testing to give reasonable assurance that the compiler doesn't crash,
> and call it a day) you can probably save a heck of a lot of work.

"Extraordinary testing" simply isn't good enough.

> Is it even possible to guarantee that a compiler can accept every valid
> program and also never crash?  

In complete generality, no. (Because of the "and" in conjunction with physical machine limitations.)

>
> If Ada programs can have nested
> parenthesized expressions or begin/end blocks of arbitrary depth, then
> any sane approach to parsing will eventually run out of memory if the
> nesting is deep enough.

HOWEVER; it is possible to detect this situation and shut down compilation w/o corruption.

Within the constraints of the physical machine [and bookkeeping mechanisms], it is possible to ensure every possible valid program is translatable into IR.

> CompCert itself is already a magnificant feat.  I have no idea whether a
> fully proven compiler in SPARK is feasible at all.  Has anyone ever done
> anything like that?

I don't know; I think there is some work in this area, but this is more 2nd-hand info guessing.

> > - Application of SPARK provers to VHDL.
> 
> Does anyone do that?  There's some work on HDL verification but it uses
> completely different approaches.

Unknown; but it's possible that those same "completely different approaches" could be applied to Ada as well.

Re: How to get Ada to “cross the chasm”?

[Paul Rubin]

Shark8 <onewingedshark@gmail.com> writes:
>> If you use CompCert's approach (use recursion and unbounded arithmetic
>> and automatic memory management in the compiler as much as you want,
>> prove that the compiler won't generate bad code, use ordinary software
>> testing to give reasonable assurance that the compiler doesn't crash,
>> and call it a day) you can probably save a heck of a lot of work.
>
> "Extraordinary testing" simply isn't good enough.

Why do you say that?  Even for ordinary testing, not extraordinary?  The
testing is not to protect against wrong-code generation since the
theorem prover does that.  The testing only gives some assurance (the
same level that you get from normal commercial software, i.e. not
mathematical proof but reasonable practical confidence), that the
compiler won't do something like crash from a memory leak.

That means that the compiler is allowed to use garbage collection, as
CompCert does.  It makes writing the compiler much easier.  I think
SPARK programs are not allowed to use garbage collection because SPARK
has to guarantee that the programs never crash.

A compiler is not like a jet engine controller.  If it generates wrong
code, that's potentially disastrous.  But if it doesn't work at all,
that's only annoying.  You need SPARK for the jet engine controller
because it HAS TO WORK or the plane stops flying and people die.  If the
compiler doesn't work, you lose a little bit of development time filing
a bug report with the maintainers and finding a workaround.

Therefore, verifying a compiler with SPARK (which means giving up
garbage collection and arbitrary-precision integers, instead making
yourself satisfy a lot of verification conditions about not overflowing
machine-width integers) seems like a waste of effort.  All you really
care about is not getting wrong code.  You can accept a low probability
of outright failure to not generate any code at all.

Re: How to get Ada to “cross the chasm”?

[Shark8]

On Friday, April 20, 2018 at 3:25:58 PM UTC-6, Paul Rubin wrote:
> Shark8 writes:
> >> If you use CompCert's approach (use recursion and unbounded arithmetic
> >> and automatic memory management in the compiler as much as you want,
> >> prove that the compiler won't generate bad code, use ordinary software
> >> testing to give reasonable assurance that the compiler doesn't crash,
> >> and call it a day) you can probably save a heck of a lot of work.
> >
> > "Extraordinary testing" simply isn't good enough.
> 
> Why do you say that?  Even for ordinary testing, not extraordinary?

Meltdown and Spectre -- which stem from caching and speculative execution.

It's about the *properties* here, not just whether "A:= 1 + A;" correctly generates an increment, or whether it can overflow.

> The testing is not to protect against wrong-code generation since the
> theorem prover does that.  The testing only gives some assurance (the
> same level that you get from normal commercial software, i.e. not
> mathematical proof but reasonable practical confidence), that the
> compiler won't do something like crash from a memory leak.

Again; not sufficient.
In such an IDE the VHDL has to have some manner of proving properties; which SPARK does do (a lot of your cited VCs, like lack of overflows, are there because they invalidate properties that need to hold).

> That means that the compiler is allowed to use garbage collection, as
> CompCert does.  It makes writing the compiler much easier.  I think
> SPARK programs are not allowed to use garbage collection because SPARK
> has to guarantee that the programs never crash.

Never crashing is a good thing; it's far better to have a controlled exit than possibly leave things in a inconsistent state.

> A compiler is not like a jet engine controller. If it generates wrong
> code, that's potentially disastrous.  But if it doesn't work at all,
> that's only annoying.  You need SPARK for the jet engine controller
> because it HAS TO WORK or the plane stops flying and people die.  If the
> compiler doesn't work, you lose a little bit of development time filing
> a bug report with the maintainers and finding a workaround.

Except we're also talking about the possible production of chips via VHDL; something like, oh, a pacemaker ASIC or a microcontroller for automotive-use... say in the braking or throttle system.

As such, it *SHOULD* be treated as a critical system: it's not just SW that you can hot-patch, it's also etched HW that is essentially set in stone. So, yes, it should be provably correct.

> Therefore, verifying a compiler with SPARK (which means giving up
> garbage collection and arbitrary-precision integers, instead making
> yourself satisfy a lot of verification conditions about not overflowing
> machine-width integers) seems like a waste of effort.  All you really
> care about is not getting wrong code.  You can accept a low probability
> of outright failure to not generate any code at all.

Except you're flat-out wrong; the system needs to be provable, not just in correctness but in the properties of the underlying constructs.

It needs to be a system where, upon submission of a "project" the compilation-result is either "success, and provable from source to object", or "Error, because of XXX." -- Where XXX is something like "inputs exceeded working memory" or "could not prove properties Y & Z." or "Semantic-error, violation of LRM N.N.N." or the like. -- There should be no "low probability of failure".

Re: How to get Ada to “cross the chasm”?

[Paul Rubin]

Shark8 <onewingedshark@gmail.com> writes:
>> Why do you say that?  Even for ordinary testing, not extraordinary?
> Meltdown and Spectre -- which stem from caching and speculative execution.

What does that have to do with anything?  

> It's about the *properties* here, not just whether "A:= 1 + A;"
> correctly generates an increment, or whether it can overflow.

I can't tell what you mean by this.  I may be missing something basic.

> In such an IDE the VHDL has to have some manner of proving properties;

That sounds like you're talking about proofs embedded in the VHDL code,
that prove SPARK-like VC's about the circuit being described.  That's
fine and necessary.  But the topic I asked about is the proofs used in
the compiler, not the proofs embedded in the compiled program.

> Never crashing is a good thing; it's far better to have a controlled
> exit than possibly leave things in a inconsistent state.

1. Of course it's a good thing, but is it CRITICAL?  For a jet engine it
is critical.  For a compiler I'm claiming it's not critical.  I'm open
to persuasion but at the moment I don't see the other side.  Let's put
it another way: you are running a crashfree compiler when a mischievous
billionaire offers you $10 million if you let him smash your computer
with a sledgehammer (setting you back a day or so while you buy a new
computer and restore your backups to it).  If you take the $10 million,
I claim you would have been ok without the crashfree compiler.

2. What inconsistent state is left if the compiler crashes?  It's just a
usermode program.  There's an error message saying that the compiler
crashed, and hopefully some diagnostic info saying how the crash
happened.

3. There are many ways compilation can fail, even if the compiler
software is perfect, such as a power failure in the office, problems
with the computer hardware, the building being hit by a meteor or
tsunami, or the above-described mischievous billionaire showing up.  At
a typical office there's maybe 1e-3 chance that one of those things
happens on a given day (the billionaire is the least likely of course),

With a well-tested compiler (verified like CompCert, but not SPARK
verified), you have at worst 1e-6 chance of hitting an input that it
can't compile (you get an error message instead, not wrong code).  How
much are you willing to pay to decrease the 1e-6 to 1e-10 by using
SPARK?  If the amount is more than zero, what are you doing about the
1e-3 chance of other problems?

Anyway, you have not explained how it's even conceptually possible to
write a SPARK verified Ada compiler that compiles every possible Ada
program, rather than a restricted subset.  If there's a VC requiring the
compiler to never use more than N bytes of memory, then what do you do
with an input that uses N+1 levels of nested parentheses (rejecting it
and printing an error message is no different than crashing and printing
an error message)?  If there's not such a VC, how can you guarantee that
your compiler never crashes from memory exhaustion?

Really, SPARK is great, but I think I'm seeing some overreaching claims
for it in this thread.

Re: How to get Ada to “cross the chasm”?

[Shark8]

On Friday, April 20, 2018 at 6:10:06 PM UTC-6, Paul Rubin wrote:
> Shark8  writes:
> >> Why do you say that?  Even for ordinary testing, not extraordinary?
> > Meltdown and Spectre -- which stem from caching and speculative execution.
> 
> What does that have to do with anything?  
> 
> > It's about the *properties* here, not just whether "A:= 1 + A;"
> > correctly generates an increment, or whether it can overflow.
> 
> I can't tell what you mean by this.  I may be missing something basic.

What I mean by both of these is there are other items in-play, in such a combined HW/SW environment, than mere "correctness". There are properties that are absolutely crucial to specify and ensure: the Spectre and Meltdown bugs are examples of this (regarding the property of "access control" being violated because of the implementation of 'caching' and 'speculative execution' and interactions between them).

Proving properties is going to be one of the major things to allow for efficient parallelization, possibly chosen at runtime, to move things back to the realm of software. (The video https://www.infoq.com/presentations/Thinking-Parallel-Programming is an excellent progression into parallelism and culminates in just how important properties [algebraic in the talk, but generalizable] are.)

> 
> > In such an IDE the VHDL has to have some manner of proving properties;
> 
> That sounds like you're talking about proofs embedded in the VHDL code,
> that prove SPARK-like VC's about the circuit being described.  That's
> fine and necessary.  But the topic I asked about is the proofs used in
> the compiler, not the proofs embedded in the compiled program.

That [proof in VHDL] would be good, too.
But having the compiler, the translator (VHDL-to-circuit), provable is necessary in order to ensure that the circuit you get *IS* the circuit described by the VHDL.

Full implementation conformance to H.3.2 (Pragma Inspection_Point) and H.3.1 (Pragma Reviewable) of Ada requires a lot of information; and H.3.1 (13) & (14) in particular thrust in the direction, though only requiring reporting, whereas this method is fully automatable and could produce exact, provable correspondence between source and object.

> 
> > Never crashing is a good thing; it's far better to have a controlled
> > exit than possibly leave things in a inconsistent state.
> 
> 1. Of course it's a good thing, but is it CRITICAL?

How is it not?
Just because "best practices" of "the industry" says it's a-ok to have to clean and rebuild because the previous output was corrupted [perhaps a bad build-system] somehow doesn't mean it's not critical.

You have to keep rebuilding until it's *RIGHT*. (It's not hard real-time; but what happens to your SW company [I'll assume a SW-dev company because this is C.L.A.] if you never have any runnable executable? It'll die because it's not producing SW.)

But even disregarding hypotheticals, how important is it that your tools give you the right answer? [Often, very.]
Now, how important is it that the computer CPU be accurate [within its digital constraints]? (Intel FP error)
How about that your computer HW be correct? (Meltdown, Spectre; Phenom's TLB; Pentium F00F)

What we're talking about here is a system that produces both the software and the hardware; and so in order to have any assurance that you-as-a-programmer are getting what you specify (either HW or SW) as the output [if there is any output] the system-as-a-whole should be reliable. -- And, transitively, the criticality of software and hardware that would produced is part of the criticality of the compiler.

There are too many variables, too many outputs and possible inputs to make such an endeavor viable with testing methodologies -- it simply doesn't scale -- the only way that does scale is proof: the ability to say "here are the properties that must hold", feed the program to your provers, and verify that they do.

If we do the above with our compiler, then we have the excellent property that any modification we make to the IDE (and compiler(s)) retain the properties we proved and retain their correctness and, therefore, produce correct output.

And, after producing this verified compiler, we can have full confidence in what we compile with it is indeed what was specified -- for everything, regardless of its own criticality. 

> 
> 2. What inconsistent state is left if the compiler crashes?  It's just a
> usermode program.  There's an error message saying that the compiler
> crashed, and hopefully some diagnostic info saying how the crash
> happened.

Or you're left with a incorrect object. (I've had this happen, w/o an error message; then it dissapears when you clean/rebuild.)

But see above about the transitivity of criticality.

> 
> 3. There are many ways compilation can fail, even if the compiler
> software is perfect, such as a power failure in the office, problems
> with the computer hardware, the building being hit by a meteor or
> tsunami, or the above-described mischievous billionaire showing up.  At
> a typical office there's maybe 1e-3 chance that one of those things
> happens on a given day (the billionaire is the least likely of course),

Those things are part of the variance of life and there's nothing we can do to eliminate them [esp. in the realm of SW], but we can [and do] mitigate them... like UPS in the case of power outage.

> With a well-tested compiler (verified like CompCert, but not SPARK
> verified), you have at worst 1e-6 chance of hitting an input that it
> can't compile (you get an error message instead, not wrong code).

Errors are fine, your compiler saying "Hey, I can only handle 128 parenthesis nestings" or "I can't represent 2**65" or "Hey, quit feeding me crap!" -- not that hose would be the actual error-text.

But that's qualitatively different than being able to say: this code that is output is provably correct in translation from the input.

> How much are you willing to pay to decrease the 1e-6 to 1e-10 by using
> SPARK?  If the amount is more than zero, what are you doing about the
> 1e-3 chance of other problems?
> 
> Anyway, you have not explained how it's even conceptually possible to
> write a SPARK verified Ada compiler that compiles every possible Ada
> program, rather than a restricted subset.

Every possible program WITHIN THE LIMITATIONS OF THE COMPUTER *AND* provably correct translation.

The key is in the intermediate representation -- you have the representation only able to represent syntactically (and, also, ideally) semantically correct Ada programs... Then you just need to prove production of the IR. (Let's assume that tokenizing is proved in a state-machine consuming characters or whatever.)

Lastly, you prove the code-generation of IR-to-target.

Done.

> If there's a VC requiring the
> compiler to never use more than N bytes of memory, then what do you do
> with an input that uses N+1 levels of nested parentheses (rejecting it
> and printing an error message is no different than crashing and printing
> an error message)?

(1) I reject the idea that /CRASHING/ is at all in the same category as a controlled exit. You know the GNAT bug box? _THAT_ is a crash, you *don't* get the [should-be] actual error message from that.

(2) Why should there be a VC for maximum memory?

(3) Depending on the design, we could reduce a lot of memory usage. [There's a reason multiple passes were used in early resource-constrained machines.]

(4) But maybe it would be good to have an upperbound for what the compiler proper could use. [As opposed to, say, the IDE's own implementation of provers; which I imagine would only need correctness proof.]

> If there's not such a VC, how can you guarantee that
> your compiler never crashes from memory exhaustion?

Why are you so hung up on memory exhaustion?


> Really, SPARK is great, but I think I'm seeing some overreaching claims
> for it in this thread.

Perhaps so; but the state of the industry is shameful. I mean look at how the filesystem is used as an ad hoc database in programming, or build-systems. Or the monstrosities called Continuous Integration [See the Experimental-DB/Workspaces paper upthread].

I believe there needs to be a bigger push towards correctness, and Ada probably needs a couple of good "killer apps" to really "cross the chasm", and a proven compiler/IDE would hit the mark on both of those.

Re: How to get Ada to “cross the chasm”?

[Dan'l Miller]

On Friday, April 20, 2018 at 8:50:32 PM UTC-5, Shark8 wrote:
> I believe there needs to be a bigger push towards correctness, and Ada probably needs a couple of good
> "killer apps" to really "cross the chasm", and a proven compiler/IDE would hit the mark on both of those.

If I were the one that had the $30 million, I'd hire you, Edward, to fully execute this vision.  I agree wholeheartedly with nearly everything that you have written.  (And the part that I haven't yet agreed with is merely because I need to ponder it more.)

Re: How to get Ada to “cross the chasm”?

[Paul Rubin]

Shark8 <onewingedshark@gmail.com> writes:
>> 1. Of course it's a good thing, but is it CRITICAL?
> How is it not?

As I'm accustomed to the term, "critical" means, approximately, that the
system can kill someone (in a real practical way, not just a theoretical
one) if the condition is not met.  It's a critical condition of
pacemaker firmware that the pacemaker never stops running (because that
means your heart stops).  I hope that makes sense.  Condition not met =>
dead person as an obvious result, not merely as a concocted scenario.
Ok?

Nowadays we can take a step back and say it's a critical condition of a
compiler that (if you use it to compile firmware for pacemakers) that
the compiler never generate wrong code.  Bob Dewar didn't agree with
this and I wanted to ask him about it, but I never got the chance, so
I'm going with it.  The idea is just that wrong code can make the
pacemaker misbehave and kill someone.  Deploying it in 1000s of
pacemakers magnifies the risk.

Now you're going even further and saying that the compiler is like a
pacemaker, so that if it unexpectedly stops running, the result is also
a dead person.  I'm surprised by this claim and think it is wrong,
though as I said I'm open to pursuasion.  You type "make" to compile
your program, the compiler runs for a little while, then whoops, it
prints an error message and quits instead of generating code.  Where is
the dead person?  I see an inconvenienced programmer but that's a lot
less serious.  A compiler is not like a pacemaker.

> And, transitively, the criticality of software and hardware that
> would produced is part of the criticality of the compiler.

If the hardware has 1e-4 chance of failing on a given day and the
software has 1e-6 chance, my first question is what you are going to do
about the hardware, since it is 100x more likely to be the cause of
failure.  Until you've made the hardware much more reliable, the 1e-6
chance of software failure is in practice not different than zero.

> You have to keep rebuilding until it's *RIGHT*. (It's not hard
> real-time; but what happens to your SW company [I'll assume a SW-dev
> company because this is C.L.A.] if you never have any runnable
> executable?

This is a compiler that's been tested and works, at least by the
standards of good testing processes.  If there's still a problem, you
open a ticket with the compiler vendor and they work with you to deal
with the issue.  At worst you might have to refactor your program
somewhat.

> It'll die because it's not producing SW.

I don't see a dead person there.  Dead company just means some financial
losses to some investors somewhere, and some programmers available for
new jobs (not always nice, but it beats being dead).  The investors in
turn took a calculated risk and they write it off.  If they want to
minimize their risks, they buy treasury notes.

Companies die all the time, for all sorts of reasons, usually
mismanagement.  A compiler repeatedly getting stuck is such an
implausible cause that it's not worth thinking about, unless the much
more likely possibilities are taken care of first.

> Errors are fine, your compiler saying "Hey, I can only handle 128
> parenthesis nestings" or "I can't represent 2**65" or "Hey, quit
> feeding me crap!" -- not that hose would be the actual error-text.

Now you're saying the same thing as me: we can live with a compiler that
can fail (and print an error) on certain valid inputs.

> But that's qualitatively different than being able to say: this code
> that is output is provably correct in translation from the input.

Right, you can only assert some property about the output if you
actually got output.

> Every possible program WITHIN THE LIMITATIONS OF THE COMPUTER *AND*
> provably correct translation.

That's what you get with CompCert, more or less.  The idea of SPARK is
to also guarantee that you will never reach the limitations of the
computer.  It's for situations where signalling an error because you hit
a limit is not allowed.  It is hard, much harder than a CompCert-level
proof.

> The key is in the intermediate representation

Nah, you still have the same problem.  Those deeply nested expressions
may have produced IR that makes your register allocator blow its stack.

> (1) I reject the idea that /CRASHING/ is at all in the same category
> as a controlled exit.

OK, terminology.  It's a user mode program, so crashing just means it
stops unexpectedly for whatever reason.  If there's a memory leak, at
some point the memory allocator prints an error message and the program
stops.  Or if an Ada program signals a constraint error, some runtime
exception handler does something similar.  There's not actually an
uncontrolled exit like when some godawful C program dereferences an
invalid pointer.  We're gentlemen here after all ;-).

I've been calling both of the above situations crashes but if you want
different terminology like "controlled exit", then fine, call it that.

Actually I think the best mathematical term for this is "divergence" and
it's more neutral than either "crash" or "controlled exit", so is that
ok with you?  If your program says 2+2=5 then that's a wrong answer, but
if it prints a diagnostic and performs a controlled exit, we call it
"divergence" rather than "wrong answer" because you never actually got
an answer.  We certainly can't call it a right answer!

SPARK aims for something different, which is to prove totality for a
real machine.  Totality means the absence of divergence.  Totality for a
compiler means that for any valid input, the compiler MUST produce
output that matches the input.  Any other result, including any
controlled exit other than "compilation is complete", is not allowed.

CompCert AIUI it right has a proof of totality on an abstract machine.
You then simulate the abstract machine on a real machine (pretty
efficiently, using Ocaml).  The abstract machine has unlimited memory,
so at some point the simulation might conceivably hit the real
computer's limits and experience "controlled exit", i.e. diverge.

If you are saying divergences of that sort can be ok, then fine, we're
on the same page, we agree that a compiler doesn't need provable
totality.  There are other programs that DO need totality proofs, and
that's what SPARK is for.

> (2) Why should there be a VC for maximum memory?

Because you haven't proven totality if you haven't proven that the
program won't exhaust memory.  Do you actually use SPARK?  I haven't
done anything with it yet, but I've looked at Barnes' book about it, and
it puts a LOT of emphasis on issues like this.

> Why are you so hung up on memory exhaustion?

Because it's a way for programs to diverge.  If you want to prove that a
program never diverges, you have to prove that it doesn't exhaust
memory.  I'm treating it as important because SPARK treats it as
important.  That's why SPARK (iirc) doesn't allow recursion, and Ada
(even without SPARK) doesn't allow dynamic memory allocation.  Actually
if you also don't allow indirect function calls, you may already have a
syntactic proof of bounded memory, so you might not need a special VC
for it.

Recursion is everywhere in most compilers, by the way (lots of tree
structure).  So if you're not allowed to use it, your style is already
cramped pretty badly.

> I believe there needs to be a bigger push towards correctness, and Ada
> probably needs a couple of good "killer apps" to really "cross the
> chasm", and a proven compiler/IDE would hit the mark on both of those.

For the reasons we've discussed, I don't think provable totality is a
crucial or even achievable property of a compiler.  It can be an
important property of an operating system, so maybe an OS would be a
better "chasm crosser" than a compiler.

Re: How to get Ada to "cross the chasm"?

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message
news:87k1t1s9lx.fsf@nightsong.com...
...
>> Never crashing is a good thing; it's far better to have a controlled
>> exit than possibly leave things in a inconsistent state.
>
> 1. Of course it's a good thing, but is it CRITICAL?  For a jet engine it
> is critical.  For a compiler I'm claiming it's not critical.  I'm open
> to persuasion but at the moment I don't see the other side.  Let's put
> it another way: you are running a crashfree compiler when a mischievous
> billionaire offers you $10 million if you let him smash your computer
> with a sledgehammer (setting you back a day or so while you buy a new
> computer and restore your backups to it).  If you take the $10 million,
> I claim you would have been ok without the crashfree compiler.

I just want $50 for every compiler crash. Then I can retire. ;-)

> 2. What inconsistent state is left if the compiler crashes?  It's just a
> usermode program.  There's an error message saying that the compiler
> crashed, and hopefully some diagnostic info saying how the crash
> happened.

For Ada at least, you also have the programming environment. If a crash
corrupts that, you can be in deep do-do. (If a crash corrupts the Janus/Ada
project file, the only realistic fix is to delete it and reconstruct. That's
not very efficient!)

...
> Really, SPARK is great, but I think I'm seeing some overreaching claims
> for it in this thread.

I personally think SPARK is the worst thing every to happen to Ada, because
it took the focus off of the great things that Ada 2012 itself can do for
you (without any verification) and onto something that only makes sense for
a niche. And it seems to have kept the AdaCore people from pursuing some of
those great things. (If you could send that $10 million this way, I'd take a
swing at them, but as it stands I need to pay for food and shelter first...
:-)

                                   Randy.

Re: How to get Ada to "cross the chasm"?

[Simon Wright]

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

> I personally think SPARK is the worst thing every to happen to Ada,
> because it took the focus off of the great things that Ada 2012 itself
> can do for you (without any verification) and onto something that only
> makes sense for a niche.

I might not go as far as that, but I'm deeply impressed by people who
can use SPARK without formal training and possibly even ongoing
handholding.

I tried proving a quicksort and failed dismally; my fault no doubt, but
the CE version of the tool seemed a little flaky, where fixing what it
seemed to be saying was the problem resulted in a game of cyclic
whack-a-mole.

And Time!

Re: How to get Ada to "cross the chasm"?

[Paul Rubin]

Simon Wright <simon@pushface.org> writes:
> I tried proving a quicksort and failed dismally

Verifying a sorting algorithm is traditionally a tough challenge for a
proof system.  You have to prove that the output is a permutation of the
input, that it is sorted, and that the algorithm terminates.  Each of
those can be a bit messy, depending.  It is doable, but you might start
out with something easier.

Re: How to get Ada to "cross the chasm"?

[Dmitry A. Kazakov]

On 26/04/2018 01:02, Randy Brukardt wrote:

> I personally think SPARK is the worst thing every to happen to Ada, because
> it took the focus off of the great things that Ada 2012 itself can do for
> you (without any verification) and onto something that only makes sense for
> a niche.

The worst thing is that Ada 2012 does not integrate SPARK into the 
language with an ability to prove only things the programmers wants to 
have proved instead of all-or-nothing approach.

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

Re: How to get Ada to "cross the chasm"?

[Mehdi Saada]

Please bear with my ignorance, but from the exterior, it does seem that verification can switch on or off at a very fine level of granularity. At least in Spark 2014, with pragma spark_mode on/off.
I'm surprised to read that seniors/experts like Randy almost despise Spark. Can you provide more information ?
Do you find that:
1) the idea of proving formally is most of the time too much time consuming/almost not feasible for humans ?
2) good idea, but badly integrated with the language ?
3) good idea, but the focus on it made designers lose focus on improving soundness of the language, so that the compiler would not need additional tools and efforts to achieve the same level of code quality ?

I suspect it's 3. Are there elaborated critics of the formal proof tendency somewhere on the web, NOT coming from C or some lazy/poorly typed language's people ?

Re: How to get Ada to "cross the chasm"?

[Dmitry A. Kazakov]

On 2018-04-26 19:38, Mehdi Saada wrote:
> Please bear with my ignorance, but from the exterior, it does seem that verification can switch on or off at a very fine level of granularity. At least in Spark 2014, with pragma spark_mode on/off.
> I'm surprised to read that seniors/experts like Randy almost despise Spark. Can you provide more information ?
> Do you find that:
> 1) the idea of proving formally is most of the time too much time consuming/almost not feasible for humans ?

It is impossible to prove everything, neither theoretically nor 
practically. Therefore the statement must be qualified - what is it you 
are going to prove.

> 2) good idea, but badly integrated with the language ?

It is an excellent idea. E.g. types conformance is proved because the 
language is statically typed and it is almost zero cost for the 
programmer. Other things may have low, medium, intolerably high cost or 
impossible. The language must allow to specify what exactly must be 
proved in the form of contract specification.

> 3) good idea, but the focus on it made designers lose focus on improving soundness of the language, so that the compiler would not need additional tools and efforts to achieve the same level of code quality ?

In my view they have been focused on wrong things all the time since Ada 
2005. E.g things like limited aggregates and return, dynamic predicates 
only diminish language soundness.

> I suspect it's 3. Are there elaborated critics of the formal proof tendency somewhere on the web, NOT coming from C or some lazy/poorly typed language's people ?

There is no point in that critique unless they object all-or-nothing 
approach, which is then a tautology, because that thing is nonexistent 
anyway.

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

Re: How to get Ada to "cross the chasm"?

[G. B.]

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

> It is impossible to prove everything, neither theoretically nor 
> practically. 

Hence dynamic checks that, if used as defined in „Design 
by Contract“, will give programmers a way of trying another 
solution at runtime.

Seems different than just halting the program because 
mathematics could not deliver a complete demonstration
of the program’s never-fails property.

Re: How to get Ada to "cross the chasm"?

[Dmitry A. Kazakov]

On 27/04/2018 11:23, G. B. wrote:
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> 
>> It is impossible to prove everything, neither theoretically nor
>> practically.
> 
> Hence dynamic checks that, if used as defined in „Design
> by Contract“, will give programmers a way of trying another
> solution at runtime.

Nope. Hence a contract to mandate exceptional behavior that cannot be 
avoided or proven non-existent.

> Seems different than just halting the program because
> mathematics could not deliver a complete demonstration
> of the program’s never-fails property.

No, it is still demonstrated just at another level of abstraction. You 
replace absence of overflow with a requirement to have Constraint_Error 
on overflow. You replace absence of exception with absence of unhandled 
exception etc.

An undesired program state is not a bug, an unanticipated state is.

If you cannot eliminate a state you *define* that state.

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

Re: How to get Ada to "cross the chasm"?

[Randy Brukardt]

"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:d39f8a7e-1568-48a2-982d-f1ac6cecf975@googlegroups.com...
> Please bear with my ignorance, but from the exterior, it does seem that 
> verification can switch on or off at a very fine level of granularity. At 
> least in Spark 2014, with pragma spark_mode on/off.
> I'm surprised to read that seniors/experts like Randy almost despise 
> Spark. Can you provide more information ?
> Do you find that:
> 1) the idea of proving formally is most of the time too much time 
> consuming/almost not feasible for humans ?
> 2) good idea, but badly integrated with the language ?
> 3) good idea, but the focus on it made designers lose focus on improving 
> soundness of the language, so that the compiler would not need additional 
> tools and efforts to achieve the same level of code quality ?

Pretty much all of the above. A lot of things aren't worth the effort to 
prove (as Paul noted in his previous notes). At least not *special* effort. 
Full algorithmic proof falls into this category for most things. OTOH, Ada 
has a lot of information that the compiler uses to do essentially proofs to 
make the code better. (Indeed, a tool like Codepeer is just an overgrown 
compiler optimizer.) One can easily imagine feeding back that information to 
the programmer to show problematic areas (that's what I'm trying to do with 
future versions of Janus/Ada).

Too much focus on static proving leads to neglecting what can be done with 
dynamic checks and especially a combination of both. After all, Ada 
compilers go to great lengths to eliminate dynamic checks; the checks that 
can't be eliminated that way are potential problem areas. The same is true 
for contracts.

Anyway, I shouldn't talk too much about this as someone might actually do it 
before I can get the time, and that would not be great. :-)

                                               Randy.

Re: How to get Ada to "cross the chasm"?

[Dmitry A. Kazakov]

On 27/04/2018 01:19, Randy Brukardt wrote:

> Too much focus on static proving leads to neglecting what can be done with
> dynamic checks and especially a combination of both.

Easy, kill dynamic checks, one more self-inflicted problem solved.

There is no such thing as dynamic check. It is either a contract to 
raise exception or a language bug.

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

Re: How to get Ada to "cross the chasm"?

[Norman Worth]

Randy Brukardt wrote:
> "Mehdi Saada" <00120260a@gmail.com> wrote in message
> news:d39f8a7e-1568-48a2-982d-f1ac6cecf975@googlegroups.com...
>> Please bear with my ignorance, but from the exterior, it does seem that
>> verification can switch on or off at a very fine level of granularity. At
>> least in Spark 2014, with pragma spark_mode on/off.
>> I'm surprised to read that seniors/experts like Randy almost despise
>> Spark. Can you provide more information ?
>> Do you find that:
>> 1) the idea of proving formally is most of the time too much time
>> consuming/almost not feasible for humans ?
>> 2) good idea, but badly integrated with the language ?
>> 3) good idea, but the focus on it made designers lose focus on improving
>> soundness of the language, so that the compiler would not need additional
>> tools and efforts to achieve the same level of code quality ?
> 
> Pretty much all of the above. A lot of things aren't worth the effort to
> prove (as Paul noted in his previous notes). At least not *special* effort.
> Full algorithmic proof falls into this category for most things. OTOH, Ada
> has a lot of information that the compiler uses to do essentially proofs to
> make the code better. (Indeed, a tool like Codepeer is just an overgrown
> compiler optimizer.) One can easily imagine feeding back that information to
> the programmer to show problematic areas (that's what I'm trying to do with
> future versions of Janus/Ada).
> 
> Too much focus on static proving leads to neglecting what can be done with
> dynamic checks and especially a combination of both. After all, Ada
> compilers go to great lengths to eliminate dynamic checks; the checks that
> can't be eliminated that way are potential problem areas. The same is true
> for contracts.
> 
> Anyway, I shouldn't talk too much about this as someone might actually do it
> before I can get the time, and that would not be great. :-)
> 
>                                                 Randy.
> 
> 
> 
> 
Back when I was doing active programming, I ran into a problem, usually 
a small one, that required a formal proof about once a year.  I did do 
programming that required reliable and proper results back then.

Re: How to get Ada to "cross the chasm"?

[Paul Rubin]

Mehdi Saada <00120260a@gmail.com> writes:
> Are there elaborated critics of the formal proof tendency somewhere on
> the web, NOT coming from C or some lazy/poorly typed language's people ?

http://lambda-the-ultimate.org/node/683#comment-6122 is interesting.

Re: How to get Ada to "cross the chasm"?

[Paul Rubin]

Mehdi Saada <00120260a@gmail.com> writes:
> At least in Spark 2014... Do you find that:
> 1) the idea of proving formally is most of the time too much time
> consuming/almost not feasible for humans ?

One thing I'd add is that automatic proving has gotten much better.
There's a page at Adacore (don't have the url offhand) mentioning some
Spark-83 program that had several hundred verification conditions (=
assertions needing to be proved).  SPADE was able to prove around half
of the VC's automatically, which meant the other half required
manually-written proofs.  With Spark-2014 and CVC3, the automatic
portion went up to around 90%.  

> 3) good idea, but the focus on it made designers lose focus on
> improving soundness of the language, so that the compiler would not
> need additional tools and efforts to achieve the same level of code
> quality ?

Well that's kind of philosophical, but I'd say the software world should
support a spectrum of approaches ranging from casual to extreme.  Casual
would mean something like Python or a spreadsheet.  Intermediate might
be something like Ada without SPARK.  Extreme requires proofs, or else
it wouldn't be extreme.

So should Ada support extreme approaches?  Or should it stay with
intermediate ones and leave the extreme ones to something else, and what
would the something else be?  I've always thought Ada aimed directly at
supporting the most rigorous approaches available, which means extreme
ones.  So to me, SPARK is part of what makes Ada interesting.

Re: How to get Ada to “cross the chasm”?

[Brian Drummond]

On Fri, 20 Apr 2018 06:44:43 -0700, Shark8 wrote:

> On Friday, April 20, 2018 at 7:25:41 AM UTC-6, Dan'l Miller wrote:
>> 
>> Also, we always talk about Ada+SPARK.  Why not Ada+VHDL, which is its
>> syntactic cousin, as a smooth and seamless programming environment for
>> FPGA development:  software and netmask in sibling languages?
> 
> If I had a good $30 Million or so, I'd totally drop it on hiring out for
> an Ada+VHDL IDE (not editor, environment) with:
> - An IR on the order of AIR or DIANA, though with database-storage as a
> consideration.
> - Implementation of the better-than-Continuous-Integration *AND*
> versioning solution described in this paper:
> http://citeseerx.ist.psu.edu/viewdoc/download?
doi=10.1.1.26.2533&rep=rep1&type=pdf
> - Written in 100% Ada; SPARK proving for the compiler-proper.
> - Modularized tools, such as pluggable backends.
> - Implementation of my Ada Project Manager solution, after rewriting it
> in pure Ada syntax.
> - Application of SPARK provers to VHDL.
> 
> And all the above means you could have provers on entire systems, H/W
> and S/W!

Formal methods have more traction in hardware (ASIC rather than FPGA) 
design, so VHDL users might be very open to a SPARK-like prover. 

Further, the restrictions placed on Ada to make it SPARK provable have a 
lot in common with the restrictions placed on VHDL to make it 
synthesisable, so there may well be some synergy there.

One thing I have (experimentally) used Ada for, was to code an algorithm 
in generic form, and instantiane in with both floating point (reference 
model) and various resolutions/ranges of fixed point, to prototype a 
hardware solution meeting specific accuracy goals. 

Ada's fixed point makes it a dream for DSP algorithm prototyping, before 
porting to VHDL and hardware. And this is a big market - EDA is in the 
billions with System-C and System-Verilog and other languages dedicated 
almost purely to hardware design verification; it could certainly support 
that sort of budget. Ada has a lot to offer here, especially with its 
cultural compatibility to VHDL.

Add SPARK/VHDL and you could be on to something.

-- Brian

-- Brian

Re: How to get Ada to “cross the chasm”?

[Paul Rubin]

Brian Drummond <brian@shapes.demon.co.uk> writes:
> Formal methods have more traction in hardware (ASIC rather than FPGA) 
> design, so VHDL users might be very open to a SPARK-like prover. 

I think that ASIC formal methods (at least historically) relate mostly
to finite model checking.  I don't know if SPARK is really relevant
there.  I usually think of "theorem proving" as being about infinite
models, though of course that's not required.

Re: How to get Ada to “cross the chasm”?

[Paul Rubin]

"Dan'l Miller" <optikos@verizon.net> writes:
> Embedded realtime systems are going to be going mainstream in data
> processing with FPGAs in the datacenter.

Hmm.  FPGAs in the datacenter are usually about doing specialized
computation efficiently: examples include things like machine learning
using the DSP blocks on the FPGA's, or (famously) bitcoin mining.
So I wouldn't count that as either realtime or embedded.

Embedded usually means the processor is there to perform some
specialized computation to control hardware.  So seeing FPGA's in the
data center used for general purpose computation is actually cool
because it means FPGA's have escaped from the embedded realm.  They are
instead computing something and sending the answer over the internet.

Similarly, realtime to me means the answer must be delivered within some
specific deadline, usually measured in microseconds, or else disaster
ensues.  If the answer is being delivered over the internet, they any
interruption in network connectivity means the deadline is missed.    

So I can't consider anything running in a data center to be realtime
enough to need formal verification.  If your network reliability is
99.99% (on average it is out less than 1 second a day, including for
reasons like power failures) you are doing great.  Therefore it is
sufficient if your software delivers answers with 99.999% reliability, a
level you can easily reach with traditional testing methods.  The
likelihood of software failure is then swamped by the likelihood of
network failure.

Note that the 0.0001% failure allowance above doesn't mean that the
program is allowed to ever deliver wrong answers.  It just means that
the possibility of a deadline miss (where the program takes longer than
you expected, or fails to give you an answer at all) can be tolerated if
the likelihood is low enough.  Formal assurance against wrong answers is
most easily done by methods that are in tension with realtime
guarantees.  So deciding what methods to use requires understanding what
the complete system has to do.

Re: How to get Ada to “cross the chasm”?

[Dan'l Miller]

On Friday, April 20, 2018 at 2:34:39 PM UTC-5, Paul Rubin wrote:
> "Dan'l Miller" writes:
> > Embedded realtime systems are going to be going mainstream in data
> > processing with FPGAs in the datacenter.
> 
> Hmm.  FPGAs in the datacenter are usually about doing specialized
> computation efficiently: examples include things like machine learning
> using the DSP blocks on the FPGA's, or (famously) bitcoin mining.
> So I wouldn't count that as either realtime or embedded.

The functionality formerly of network processors is moving to many-core general-purpose processors (with or without accompanying FPGA) in data-centers.

https://en.wikipedia.org/wiki/Data_Plane_Development_Kit#Projects

“We have a goal of being able to forward, with packet filtering at rates of at least 14.88Mpps*. This is 'line rate' on a 10Gbps interface. There is simply no way to use today's FreeBSD (or linux) in-kernel stacks for this type of load.”  [but now with DPDK that is within reach]

* mega-packets per second in the hard-realtime unit of measure commonplace on network processors (NPs)

Believe me, sustained fiber-optic line-rate 10Gbps packet processing is hard realtime (which is a little dubious with Linux instead of bare-metal, but hey, anything that cracks the hard-realtime whip to get Linux to nearer and nearer to being an RTOS is welcome!).

With proper software design, imagine a 1024GiB-DRAM ccNUMA multi-socket confederation of, say, many-core Intel Xeon processors with HyperTransport between them with proper processor affinity meticulously assigned, so that one or two of the Xeons are doing DPDK line-rate processing one or two(-duple-redundant) fiber-optic lines and then feeding slower-rate events (e.g., PIP multicast-topology-change requests) to other Xeons running routing software on general-purpose processors.  Now imagine instead of that application supporting multicast video at, say, a cable-TV network, instead this same architecture is re-targeted for other protocols in the protocol-stack, such as sophisticated serving of traditionally software-speed content on the WWW now at line rate.  Now imagine the death of dynamically interpreted scripting languages on the WWW servers, favoring vast stores of pre-computed** pure-HTML5-page content served at line-rate by this hardware & DPDK architecture.  We in telecom have been laying the groundwork for this for a decade.  It is now coming more & more into full fruition.  Intel's $16 billion purchase of Altera was a happy surprise accelerant to our SDN/NFV vision of migrating the network processing out of the telecom central office to the enterprise data center.  Just as you no longer expect the telephone to be dumb 1930s-era-technology PSTN POTS 4-wire or 2-wire analog device with all the smarts in a Lucent 5ESS telephone switch at the telecom central office (replaced by intelligent devices:  smart phones and wireline VoIP), in the near future the same type of displacement revolution will occur to today's era of turtle-speed WWW servers in the enterprise:  replace slow interpreted-language WWW servers with line-rate WWW/anti-DDOS servers.  By, say, 2025, 10Gb/s line-rate servers will be the norm.  Whichever language facilitates it, will dominate line-rate WWW/anti-DDOS servers & security-enforcement servers in the enterprise data centers for a decade or two.  Right now Ada should have had the lead when measured by long-standing language features in support of this vision, C++17 has the momentum, and Rust is the potential wild-card disruptor.

** pre-computed at the relatively slow rate of product-inventory management of a product in, say, an SQL database at, say, a retailer's website

(The cloud will bifurcate into 2 services:  nonrealtime data-processing and realtime line-rate WWW/anti-DDOS servers.)

Re: How to get Ada to “cross the chasm”?

[Dan'l Miller]

On Friday, April 20, 2018 at 4:16:58 PM UTC-5, Dan'l Miller wrote:
> ... many-core Intel Xeon processors with HyperTransport between them

Oops, I meant many-core AMD EPYC processors with HyperTransport between them or many-core Intel Xeon processors with QuckPath between them.

Re: How to get Ada to “cross the chasm”?

[Simon Wright]

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

> So I can't consider anything running in a data center to be realtime
> enough to need formal verification.

What about the bank keeping track of your money?

What about those crazy high-frequency traders?

Re: How to get Ada to “cross the chasm”?

[Paul Rubin]

Simon Wright <simon@pushface.org> writes:
> What about the bank keeping track of your money?

Not realtime, or at least not hard realtime.  Nobody cares if checking
your bank balance online takes a millisecond longer than it was supposed
to.  They might care about the statistical distribution of the latency
but they don't care at all about a single query.  (Hard) realtime means
that disaster ensures if a deadline is missed even once.

> What about those crazy high-frequency traders?

Their machines are not in data centers.

Re: How to get Ada to “cross the chasm”?

[Paul Rubin]

Paul Rubin <no.email@nospam.invalid> writes:
>> What about the bank keeping track of your money?
> Not realtime, or at least not hard realtime.

Ok, millisecond deadlines wasn't really the right thing to look at.  But
anyway, yeah, the bank computer is not even slightly a realtime system.
If the bank computer tracking your money is down for 5 minutes there
will be a minor panic at the bank's internal support desk and an
investigation afterwards to find out what happened (I know someone who
works at one of those desks so I hear about this sometimes) but it's not
that big a deal in the scheme of things.  If there's a 3 hour outage it
might make the headlines, but it's still not comparable to anything like
a plane crash.  The main US interbank transfer system (ACH) takes 2 or 3
days to clear a payment.

Re: How to get Ada to “cross the chasm”?

[Dan'l Miller]

On Saturday, April 21, 2018 at 4:28:23 PM UTC-5, Paul Rubin wrote:
> Simon Wright writes:
> > What about the bank keeping track of your money?
> 
> Not realtime, or at least not hard realtime.  Nobody cares if checking
> your bank balance online takes a millisecond longer than it was supposed
> to.  They might care about the statistical distribution of the latency
> but they don't care at all about a single query.  (Hard) realtime means
> that disaster ensures if a deadline is missed even once.

https://en.wikipedia.org/wiki/Erlang_(unit)

Hard realtime has fixed-duration time deadlines that if missed make the late numerically-correct answer or late logically-correct event just as wrong as if the answer was numerically incorrect or illogical.  Elastic realtime often can be nearly as strict:  if the rate of successfully-computed retirement* of transactions cannot keep up with the erlangs of arrival rate of commencement of non-elidible transactions during extant-expected-peak (not theoretical peak) busy periods whose duration is longer than the elasticity time-duration, then some of those incoming transactions are going “fall on the cutting room floor” so to speak—the proverbial bit bucket.  If those transactions are Visa or MasterCard (or even Bitcoin nowadays) financial transactions, societal pandemonium will occur far more severely than one 90-year old grandma dying because her pacemaker skipped one beat.  If Visa and MasterCard cannot successfully account for a slew of transactions during extant-peak-busy times, suddenly people stop trusting electronic forms of money as a stand-in for paper & metal-coin money.  It wouldn't take too many steps to suddenly quickly arrive in points of freeze-up of the financial system to the point of, for example, General Motors Corporation going out of business because they cannot make payroll because they cannot take out their rolling 30-60-90-day rolling line-of-credit loans.  (General Motors Corporation was replaced by General Motors, Inc. for substantially this reason, eliding details to make it fit succinctly herein.)

* retirement here would (must) be one of the following:
1) sufficient funds, payment made;
2) insufficient funds, payment denied;
3) DoS/DDoS prevention, transaction balked overtly.
Successful retirement prohibits silent failure where retried transactions (e.g., due to timeout of the momentarily prior same-terminal/same-card transactions), especially where the tries and their retries (e.g., due to customer/merchant frustration) get confused or are non-idempotent. 

So maldesigned systems where erlangs of transaction-commencement exceed erlangs of successful retirement are another form of (slightly elastic**) realtime failure due to results arriving late to the point that they are completely useless/wrong.

** The elasticity time duration is the time-duration of a timeout of a credit-card customer an a terminal, because retries out of frustration add further traffic during the would-have-been-peak time period, raising the peak to disastrously higher and higher levels, assuring further deadline misses as retirement rate cannot keep up with transaction commencement rate.

This is how network processors define realtime regarding arrival rate of, say, Ethernet frames at, say, 10Gb/s.  The elasticity time duration is so short that elastic realtime very closely approximates hard realtime the way that engineering zero due to tolerance approximates true zero that the difference between definitions is purely academic and effectively moot.

> > What about those crazy high-frequency traders?
> 
> Their machines are not in data centers.

The heck they are not!  Arbitrage traders place their servers as close to telecom data centers (called central offices) as they can get!  At any price!  If they cannot get into the same telecom central office as the target financial market, they might instead even be in an outdoor cabinet along a railroad easement so that they can be at a repeater station along a main-trunk fiber-optic cable transmission line just outside their target financial exchange to shave off a few milliseconds of router switching time here and there.  Indeed, they try to eliminate layer-3 Internet routing entirely as much as possible, leasing expensive layer-0 (e.g., DWDM wavelength) or layer-1 (e.g., SONET-SDH) or layer-2 (PBB-TE Ethernet) transmission channel to have as direct least-routed least-touched-by-hardware-dataplane switch-fabrics as possible!

Arbitrage trading is a slightly different definition of “late”.  Instead of fixed length of time being the deadline, the deadline is being the fastest.  Second in the race misses the deadline, and is considered total failure, because the arbitrage opportunity was lost (along with hundreds of thousands or millions of dollars).

Re: How to get Ada to “cross the chasm”?

[Paul Rubin]

"Dan'l Miller" <optikos@verizon.net> writes:
> then some of those incoming transactions are going “fall on the
> cutting room floor” so to speak—the proverbial bit bucket.

That's not how those transactions.  They're not datagrams and they don't
fall on the floor.  If they don't get through there is a retry.  

>> Their machines are not in data centers.
> The heck they are not!  Arbitrage traders place their servers as close
> to telecom data centers (called central offices) as they can get!

I've always heard that low latency HFT traders want to put their gear in
the same building as the financial exchange, maybe even right on the
trading floor or next to it.  They wouldn't want to be miles away in a
data center.  I'll ask about this though.  I'll admit that I thought of
"data center" as meaning "internet" rather than direct fiber, and that
wasn't exactly right.

> Second in the race misses the deadline, and is considered total
> failure, because the arbitrage opportunity was lost (along with
> hundreds of thousands or millions of dollars).

That sounds like nothing was lost, but rather, a potential gain wasn't
realized.  Those guys do 1000s of transactions a second and don't care
if they miss a few.  They've got a box that steadily converts
electricity to money, like bitcoin mining.  If they turn it off for a
few minutes, the money stops during the downtime, but nothing bad
happens.  They don't LOSE money while it is off.

Also, they want the opposite of critical systems development.  Thought
experiment: you proudly deliver your SPARK-verified Ada HFT system to
your Wall Street customer.  They turn it on and it generates profits and
they are happy.  Now some demented C programmer comes along and wants to
swap out your beautifully verified inner loop with some crazy pointer
mangling and type casting madness.  This not only invalidates your SPARK
proofs, but it's actually explicitly undefined behaviour according to
the C standard.  But 1) it empirically seems to work, at least on some
particular combination of compiler, version, and optimization flags; and
2) it runs 1% faster than your Ada code.

What do you think happens next?  My bet is they want the speedup and
don't care about the proofs.

Re: How to get Ada to "cross the chasm"?

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message
news:8736zqkwat.fsf@nightsong.com...
>...
> Those are intense requirements and it takes a lot of work to satisfy
> them.  If you aren't faced with those requirements, why do all that
> work?

Why do that work even if you have those those requirements? That's the
beauty of Ada -- one can get static checking for essentially free from
well-designed code. (And it's not appreciably harder than writing "typical"
code.) You have to write assertions into your code in any case (if you want
testing to actually be able to prove anything), so doing so in a structured
manner seems like a win-win.

>  Non-realtime means you can use arbitrary precision arithmetic
> (eliminating all those proofs about integer overflow)

That might work for integers, but for real numbers such math has very
different characteristics and rules than the "usual" math. It's trivially
easy to use up vast amounts of memory that way. And the point is never to
"eliminate proofs about overflow" but rather to get the right answer in a
reasonable time. Almost every program written is soft-realtime in the sense
that an answer is required immediately in a human time frame. (How long will
you wait for a web page to load? Probably not more than a few seconds.)

> and garbage
> collection (automating memory management).

If you are doing any memory management in Ada 2012, you had better have very
strict requirements on time and/or space. Or be an Ada implementer.
Otherwise, you are just an idiot. There are many good ways to write Ada 2012
code that don't involve any (explicit) memory management. (Local objects and
containers being the best.) One almost never needs to use "new".

> Realtime but non-critical
> means you can get adequate reliability from traditional software testing
> instead of proof systems.

I assume you don't care much about software quality, because testing alone
proves absolutely nothing. I don't even bother anymore on most of my code;
if it runs, it works (or at least, it is assumed to work).

That's in large part because my Ada compiler (and everybodies Ada compiler)
detects many problems at compile-time and with good design will detect the
majority of the rest at runtime. (The ones it can't detect are the cases
when the wrong problem was solved, and no system could ever detect those.)

The future of Ada (IMHO) is to move more of that runtime detection into the
compiler, so that the benefits are essentially free and most importantly,
can be gained incrementally. As you say, full verification will always be
too expensive for most programs -- but that doesn't mean that you should
then completely ignore the possibilities of proofs to detect bugs.

For me, SPARK was always the wrong direction for Ada; it matters what gets
done out of the box, not what some magical extra tool can do.

                      Randy.
.

Re: How to get Ada to "cross the chasm"?

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:de23c005-4b50-4910-9327-6d4acdaa7270@googlegroups.com...
...
>4) classic cars of yesteryear that don't try to compete with modern cars,
> but rather just stay refurbished enough to keep running.
>
>I am hoping that #4 is not the model for Ada:

It pretty much has to be. We aren't allowed to do anything that would break 
substantial amounts of existing code. That pretty much ties our hands in 
terms of some of the improvements that otherwise could be made -- and 
continues to pile up cruft in order to avoid such things at intersections. 
Don't get me wrong -- this isn't going to collapse Ada improvements 
tommorrow or in the near future, but it does limit what we can actually do. 
(Real garbage collection is impossible for Ada and so far as I can tell it 
never will be.)

> I am very much hoping that Ada sees #2 above as its emerging mission
> to extrapolate its current foundation of strengths.

I personally doubt it, because building a model that actually could keep all 
of the cruft needed for compatibility would be very hard. If one could 
eliminate the worst mistakes of Ada (non-overloaded objects, the entire 
private characteristic model, coextensions, etc.) you maybe could do it. But 
then the FUD factor would come into play - how do you verify that the new 
definition doesn't introduce severe incompatibilities that weren't in the 
old one? If you can't do that somehow, you'll have a hard time getting sign 
on from part of the existing Ada community. (And it makes no sense to 
alienate your existing customers in a chase for new ones.)

                     Randy.

Re: How to get Ada to “cross the chasm”?

[Jere]

On Monday, April 16, 2018 at 1:36:03 AM UTC-4, Paul Rubin wrote:
> I'd like to know why Rust was invented: there was obviously a need for a
> safer alternative to C++, but was Ada the answer that everyone simply
> overlooked?
I to have been messing with Rust lately and it is a fun language.  I would
wager a guess that it simply targets a different demographic than Ada
currently does (not say that Ada doesn't want to target that 
demographic though).  From my work in it over the last year, I would say
that some of the big reasons people like Rust (at least in embedded):

1.  It favors static allocation over dynamic whenever possible.  This is
huge for small embedded systems.

2.  It is currently implemented on LLVM which is a huge pool of untapped
user base for Ada (I don't think there are any current Ada implementations
on LLVM with the most recent being somewhere around GNAT 4.7 or 4.8? Or
do any other compiler vendors target LLVM at all?).

3.  The default state of Rust in a couple of areas appears to be more 
safe.  In some places where Ada defines something to be erroneous (such
as two tasks modifying the same data without synchronization), Rust 
forces it to be a compiler error by default.  A note on this:  This
is a very specific comment to only a couple of areas.  In my opinion,
Ada is generally a more safe language overall.

4.  It is not hindered by backwards compatibility concerns.  They take
into consideration backwards compatibility, but the language is not 
beyond totally removing a feature or library in favor of another (in
fact, it has done so many times).  I know that will make some here squirm,
but the reality of it is if someone is willing to change languages
completely, there are many in that camp who are less worried about backwards
compatibility.  To be fair though, Rust is a really young language, so
it can also get away with it more easily.

5.  Many like the inheritance model that it uses.  I find it very interesting.
I won't say it is superior to Ada's (I don't believe that).  In fact, I would
be willing to guess of at least one person here who would not like it at all.
It's sort of a hybrid composition model.  I don't know if it is unique (I am
sure other languages have something similar), but that is definitely an area
many of its users really like.

6.  The license situation is much nicer out of the gate.  There are two 
available licenses to choose from (Apache and MIT).  I do wish there was
a GPL option as well (for those who like it), but the user base it targets
is just different. 

7.  The language restrictions it sets makes a lot of typically "runtime"
errors into compiler errors.  The tradeoff here is the compiler is
very much more picky than even an Ada compiler.  It is much more difficult
to get a complex program to compile in Rust than it is in Ada (which 
is slightly ironic given the learning curve comment alluded to in another
message earlier).  They say that the borrow checker is a cruel mistress, 
and they do not lie.

8.  Making pointers completely "unsafe" and by default using references
which cannot be null and cannot be deallocated manually. This leads to
much safer code with compile time enforcement.

I don't think any of these make Rust any better, but based on comments I
have seen on stackoverflow and reddit, they are some of the things users
of the language commented on in different contexts.

> 
> I think answering your question would require an informed and critical
> comparison between Rust and Ada.  Something with real depth rather than
> "verbose vs curly braces".  I do know Rust has formal-methods work going
> on.
>

I'm not sure the languages are similar enough to do a fair comparison.  They
both approach things very differently.  Ada targets software development
much more (Readability, problem domain describing types, etc.).  Rust doesn't
(at least yet) seem to target that area.  Also Rust is still very infant and
is changing a lot.  Rust from a couple of years ago has many differences than
rust today.  

I will say that Ada currently has a superior generics capability.
Rust is very weak in that area.  Rust currently has a much larger user
footprint in its language development, so it will make changes in a much
different fashion than Ada might (for better or for worse).

I feel like the learning curve on Rust is much more difficult than
that of Ada's (which is in contrast to a comment made earlier I believe).

All in all, I feel like Ada is currently a generally safer language to
program in.  I've been writing code in both and still prefer Ada, but I
do see some promising features out of Rust.

Re: How to get Ada to “cross the chasm”?

[Lucretia]

On Wednesday, 18 April 2018 14:29:30 UTC+1, Jere  wrote:

> 1.  It favors static allocation over dynamic whenever possible.  This is
> huge for small embedded systems.

So does Ada.
 
> 2.  It is currently implemented on LLVM which is a huge pool of untapped
> user base for Ada (I don't think there are any current Ada implementations
> on LLVM with the most recent being somewhere around GNAT 4.7 or 4.8? Or
> do any other compiler vendors target LLVM at all?).

Last LLVM based version, from Apple, is llvmgcc42-2336.11, which is based on LLVM 2.7 and based on GCC 4.0.1 (sources say) - 4.2 (version above).

Which is ancient and would require rewriting the glue between GNAT and LLVM.

> 4.  It is not hindered by backwards compatibility concerns.  They take

There are a lot of people who would love to see a new Ada version break away from the previous versions, possibly even a rewrite removing all the crap that's not really required and basically, an Ada for the 21st century.

> 6.  The license situation is much nicer out of the gate.  There are two 

See above comments.
 
> 7.  The language restrictions it sets makes a lot of typically "runtime"
> errors into compiler errors.  The tradeoff here is the compiler is
> very much more picky than even an Ada compiler.  It is much more difficult
> to get a complex program to compile in Rust than it is in Ada (which 
> is slightly ironic given the learning curve comment alluded to in another
> message earlier).  They say that the borrow checker is a cruel mistress, 
> and they do not lie.

Yet people still bitch about how "hard" it is to get an Ada program to compile.

> I'm not sure the languages are similar enough to do a fair comparison.  They
> both approach things very differently.  Ada targets software development
> much more (Readability, problem domain describing types, etc.).  Rust doesn't

This is where Ada really shines, but it could go further with endian describing. There is no other language which does this, at all

Luke.

Re: How to get Ada to “cross the chasm”?

[Dan'l Miller]

On Wednesday, April 18, 2018 at 12:02:18 PM UTC-5, Lucretia wrote:
> ...
> There are a lot of people who would love to see a new Ada version break away from the previous
> versions, possibly even a rewrite removing all the crap that's not really required and basically, an Ada for
> the 21st century.

This would be extraordinarily difficult to do •within• the Ada community/standardization, because doing so would of course be a critique of Ichbiah's decisions and thus a disloyalty to Ichbiah himself.  This would be far easier to do in a new (reference-implementation) compiler that, while optionally providing an Ada backwards-compatibility mode, feels free to go explore a new era, unfettered by, say, Ada83.  In particular, the compiler could be modular in the sense of unplugging the Ichbiah semantics of compiler-enforced rule-set and plugging in, say, Rust's borrow-checker/et.al. on a per-project basis.

There is Ada-the-syntax that (with the exception of discriminants) is awesome.  Then there is Ada-the-Ichbiah-compiler-enforced-ruleset-from-Ada83 and then there is Ada-the-1995-compiler-enforced-ruleset and then there is the Ada-the-2005/2012-compiler-enforced-ruleset.  We have 3 or so eras of definition of safety.  Rust shows a 4th.  Randy is proposing some sort of 5th definition of safety for provably-correct tasking in Ada2020.  With so many schools of thought vying for the safety crown, this area is ripe for pluggable modularity for different schools of thought.  Even better if the axiom systems were made not-mutually-exclusive:  I'll take no-Ichbiah, some of Tucker's, all of Randy's, and the borrow checker from Rust—or some other combination for a different project.  Hence, why the compiler-enforcement of rule-set (and the ARM that defines it) should be some form of source code that declares an axiomatic system of logic, vaguely similar to Zed Notation.  Now •that• would be an Ada for the 21st century.

> ...
> Yet people still bitch about how "hard" it is to get an Ada program to compile.

Make it harder.  Let the programmers-love-to-typewrite-me languages continue conquering the ease-of-compiling marketspace.  Swift, C#, and Java value this over almost all other goals, especially Swift's seemingly never ending renaming to even more-beautiful identifiers and typing-convenience features.  Ada needs to fully conquer the source-code-is-a-rigorous-mathematical-proof marketspace; Rust and perhaps Ocaml+Coq are gaining on Ada in that race.

> ...
> This is where Ada really shines, but it could go further with endian describing. There is no other
> language which does this, at all

Well, there was PL/I from which Ada got the idea of meticulous control of the layout of records.  Ichbiah's Green was competing in a 1970s ecosystem that had a background commentary of “why not just pick PL/I”.  Multics had picked PL/I.  Prime Computer had picked PL/I, refashioned as PL/P.  Intel and Digital Research had picked PL/I, refashioned as PL/M.

https://www.ibm.com/support/knowledgecenter/en/SSY2V3_4.2.0/com.ibm.entpli.doc_4.2/lr/lsh-bigendian.htm

Re: How to get Ada to “cross the chasm”?

[Dennis Lee Bieber]

On Wed, 18 Apr 2018 10:59:25 -0700 (PDT), "Dan'l Miller"
<optikos@verizon.net> declaimed the following:


>Well, there was PL/I from which Ada got the idea of meticulous control of the layout of records.  Ichbiah's Green was competing in a 1970s ecosystem that had a background commentary of “why not just pick PL/I”.  Multics had picked PL/I.  Prime Computer had picked PL/I, refashioned as PL/P.  Intel and Digital Research had picked
PL/I, refashioned as PL/M.

	Yet all four finalists, as I recall, chose Pascal as the starting point
for language design.


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

Re: How to get Ada to “cross the chasm”?

[Jere]

On Wednesday, April 18, 2018 at 1:02:18 PM UTC-4, Lucretia wrote:
> On Wednesday, 18 April 2018 14:29:30 UTC+1, Jere  wrote:
> 
> > 1.  It favors static allocation over dynamic whenever possible.  This is
> > huge for small embedded systems.
> 
> So does Ada.
>  

This is an interesting point.  I would agree that programmers here at
comp.lang.ada promote avoiding access types whenever possible (Ada access 
types are more similar to pointers in the Rust world), but the Ada 
language itself doesn't really promote that.  It leaves the implementation 
of many aspects up to the compiler vendor.  Take, for example, discriminated 
records with a default discriminant.  The language standard doesn't direct 
how to implement that.  GNAT uses static allocation and throws an exception 
if you try to use a discriminant with very large range to create an array 
within the struct.  If I understand Randy's posts from other email chains, 
in Janus it can use the heap to allocate the array.  The secondary stack is 
another example.  It can be implemented as static only (I do this for my bare 
metal runtimes), heap, or a combination of both based on size (I think GNAT does
this normally?).  Ada's bounded containers are another example.  As far
as I can see in the standard, they don't require the use of static allocation
and can be heap implemented by the vendor.  The implementation advice
asks that they are implemented without heap, but it isn't binding (Which
makes them a portability nightmare for bare metal environments).  

NOTE:  That is my understanding based on emails here and what I have read in
the RM.  I apologize if I have misread.

I'm not saying this because I think Ada is bad (on the contrary, I prefer
Ada over Rust), but as a bare metal developer, Ada is frustratingly 
not specific on how memory is allocated by many basic language building 
blocks.  In the core Rust language, I know where the heap memory comes 
into play, so it is much easier to develop bare metal.

Re: How to get Ada to “cross the chasm”?

[Simon Wright]

Jere <jhb.chat@gmail.com> writes:

>  The secondary stack is another example.  It can be implemented as
> static only (I do this for my bare metal runtimes), heap, or a
> combination of both based on size (I think GNAT does this normally?).

In Cortex GNAT RTS, I leave it as a fixed proportion of each task's
stack. (10% - in s-parame.adb). I believe that full GNAT has a mixed
strategy.

Info at [1] on pragma (and aspect, almost certainly)
Secondary_Stack_Size - which I don't support yet[2]. Nor do I have a
System.Parameter.Sec_Stack_Percentage :-( - more to do.

[1]
https://gcc.gnu.org/onlinedocs/gnat_rm/Pragma-Secondary_005fStack_005fSize.html
[2] as in, you can of course specify it, but I ignore it. Sorry.

Re: How to get Ada to “cross the chasm”?

[Niklas Holsti]

On 18-05-04 16:30 , Jere wrote:
> On Wednesday, April 18, 2018 at 1:02:18 PM UTC-4, Lucretia wrote:
>> On Wednesday, 18 April 2018 14:29:30 UTC+1, Jere  wrote:
>>
>>> 1.  It favors static allocation over dynamic whenever possible.  This is
>>> huge for small embedded systems.
>>
>> So does Ada.
>>
>
> This is an interesting point.  I would agree that programmers here at
> comp.lang.ada promote avoiding access types whenever possible (Ada access
> types are more similar to pointers in the Rust world), but the Ada
> language itself doesn't really promote that.

The Ada language surely helps avoid access types, as it lets us create 
local variables of dynanmic size. There may be pointers under the hood 
for such objects, but not visible access types.

> It leaves the implementation of many aspects up to the compiler vendor.

Yes, but there are some language features to mitigate that, such as the 
pragma No_Implicit_Heap_Allocation.

> Take, for example, discriminated records with a default discriminant.
> The language standard doesn't direct how to implement that.

True.

> GNAT uses static allocation

Not universally, I think. AIUI, GNAT uses static allocation (of the size 
of the largest variant) if the object is on the library level; stack 
allocation for a local variable (possibly secondary stack); and (of 
course) heap allocation if the object is dynamically allocated.

> and throws an exception if you try to use a discriminant with very
> large range to create an array within the struct.

Only if the (largest variant of the) object would exceed the memory 
available in the area where it is created.

> If I understand Randy's posts from other email chains,
> in Janus it can use the heap to allocate the array.

Yes, so I too believe.

> The secondary stack is another example.

That is not even a standard concept in Ada, but an implementation concept.

> Ada's bounded containers are another example.  As far as I can see
> in the standard, they don't require the use of static allocation
> and can be heap implemented by the vendor.

Yes, although IMO only an insane cross-compiler for bare metal would use 
heap allocation for such objects (except, perhaps, when at library level).

Unfortunately, I believe that pragma No_Implicit_Heap_Allocation would 
not warn about such insanity (because, if the program uses a bounded 
container, that use is explicit, not implicit). This could be an 
improvement of that pragma in some future Ada.

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

Re: How to get Ada to “cross the chasm”?

[Jere]

On Friday, May 4, 2018 at 3:07:40 PM UTC-4, Niklas Holsti wrote:
> On 18-05-04 16:30 , Jere wrote:
> > GNAT uses static allocation
> 
> Not universally, I think. AIUI, GNAT uses static allocation (of the size 
> of the largest variant) if the object is on the library level; stack 
> allocation for a local variable (possibly secondary stack); and (of 
> course) heap allocation if the object is dynamically allocated.
> 
sorry, I was mixing terms.  I wasn't trying to point out static lifetime, 
but more static vs dynamic allocation or maybe no-heap vs heap allocated.  
Not sure what the absolute correct term is.  I was always taught the 
terms static vs dynamic allocation, but I can see where what I said
was confusing.

 
> > The secondary stack is another example.
> 
> That is not even a standard concept in Ada, but an implementation concept.

That was kind of my point.  The language doesn't define how unconstrained
types are returned.  It could be stack or heap.  I'm not so much worried
about whether the language defines that a "secondary stack" is used or 
not but more about the practicality of how the data is passed. Sorry
about that, it was just meant to be used for example since it was an
existing implementation.  I meant no malice.

> 
> > Ada's bounded containers are another example.  As far as I can see
> > in the standard, they don't require the use of static allocation
> > and can be heap implemented by the vendor.
> 
> Yes, although IMO only an insane cross-compiler for bare metal would use 
> heap allocation for such objects (except, perhaps, when at library level).
> 

Possibly, but it would have been better if the language would have been
more explicit about it.  I can make my own, so not the end of the world.

Re: How to get Ada to “cross the chasm”?

[Dennis Lee Bieber]

On Fri, 4 May 2018 22:07:37 +0300, Niklas Holsti
<niklas.holsti@tidorum.invalid> declaimed the following:

>On 18-05-04 16:30 , Jere wrote:
>> The secondary stack is another example.
>
>That is not even a standard concept in Ada, but an implementation concept.
>

	And usage of such is not permitted in the avionics software to which
I've been exposed. Merely because it seemed to be a dynamically allocated
structure.


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

Re: How to get Ada to “cross the chasm”?

[Simon Wright]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

> On Fri, 4 May 2018 22:07:37 +0300, Niklas Holsti
> <niklas.holsti@tidorum.invalid> declaimed the following:
>
>>On 18-05-04 16:30 , Jere wrote:
>>> The secondary stack is another example.
>>
>>That is not even a standard concept in Ada, but an implementation
>>concept.
>>
>
> 	And usage of such is not permitted in the avionics software to
> which I've been exposed. Merely because it seemed to be a dynamically
> allocated structure.

That's true for unrestricted runtimes, but I hardly think you'd be using
those in avionics software? (mind, when I worked on a missile guidance
system, we used unrestricted GNAT on VxWorks. That work started in 2000,
so we didn't have much experience with pragma Restrictions, and I
wouldn't know how to check what restrictions GNAT supported then
(3.16a1). Nowadays we have No_Secondary_Stack[1].

OK, there may be no dynamic (heap) allocation in restricted secondary
stack, but since it's allocated as part of the task stack you'd have a
hard row to hoe proving that it won't overflow! Lick a finger and hope.

In my Cortex GNAT RTS, the secondary stack is allocated in the stack of
the wrapper procedure that calls the task body .. so secondary stack
overflow would smash the stack of another task, most likely (primary
stack grows down, secondary stack grows up). Ugh.

[1]
https://gcc.gnu.org/onlinedocs/gnat_rm/No_005fSecondary_005fStack.html

Re: How to get Ada to “cross the chasm”?

[Paul Rubin]

Simon Wright <simon@pushface.org> writes:
> OK, there may be no dynamic (heap) allocation in restricted secondary
> stack, but since it's allocated as part of the task stack you'd have a
> hard row to hoe proving that it won't overflow! Lick a finger and
> hope. ...
> https://gcc.gnu.org/onlinedocs/gnat_rm/No_005fSecondary_005fStack.html

Actually I don't understand why there is a secondary stack?  In C++ such
objects are placed on the primary stack, which afaict works out about
the same way.  If the object size is statically known (and recursion is
not allowed or is restricted to a known depth) then with luck one can
prove that the stack won't overflow.  If the size is unknown then a
secondary stack doesn't seem to help.

Re: How to get Ada to “cross the chasm”?

[Niklas Holsti]

On 18-05-05 23:02 , Paul Rubin wrote:
> Simon Wright <simon@pushface.org> writes:
>> OK, there may be no dynamic (heap) allocation in restricted secondary
>> stack, but since it's allocated as part of the task stack you'd have a
>> hard row to hoe proving that it won't overflow! Lick a finger and
>> hope. ...
>> https://gcc.gnu.org/onlinedocs/gnat_rm/No_005fSecondary_005fStack.html
>
> Actually I don't understand why there is a secondary stack?  In C++ such
> objects are placed on the primary stack, which afaict works out about
> the same way.  If the object size is statically known (and recursion is
> not allowed or is restricted to a known depth) then with luck one can
> prove that the stack won't overflow.  If the size is unknown then a
> secondary stack doesn't seem to help.

One reason is that when a function evaluates an expression that creates 
an object of a large, dynamic size (eg. an array expression) on the 
secondary stack, this object can be returned /in situ/ as the function's 
return value, without being copied. Stuff can be left on the secondary 
stack when a function returns; it does not have to be pushed/popped in 
synchrony with calls and returns. AIUI, GNAT uses a mark-release method 
for managing secondary stack allocations.

This makes it still harder to compute a bound on the secondary-stack 
usage (to avoid stack overflow), but perhaps the dynamic size of the 
objects allocated on the secondary stack already prevents that 
computation, in practice, for typical applications.

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

Re: How to get Ada to “cross the chasm”?

[Paul Rubin]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> One reason is that when a function evaluates an expression that
> creates an object of a large, dynamic size (eg. an array expression)
> on the secondary stack, this object can be returned /in situ/ as the
> function's return value, without being copied.

Ok, but that pattern is so common that allocating the space in the
primary stack before calling the function is a standard optimization
that every serious C++ compiler knows how to do.  Then the function
writes the result into the primary stack and the caller can still use it
after the function returns.  Could Ada not do it the same way?

Re: How to get Ada to “cross the chasm”?

[G.B.]

On 06.05.18 01:06, Paul Rubin wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>> One reason is that when a function evaluates an expression that
>> creates an object of a large, dynamic size (eg. an array expression)
>> on the secondary stack, this object can be returned /in situ/ as the
>> function's return value, without being copied.
> 
> Ok, but that pattern is so common that allocating the space in the
> primary stack before calling the function is a standard optimization
> that every serious C++ compiler knows how to do.  Then the function
> writes the result into the primary stack and the caller can still use it
> after the function returns.  Could Ada not do it the same way?

Does C++ have objects, not allocated via *new*, whose size in bytes will
be known only at run time?

Re: How to get Ada to “cross the chasm”?

[Paul Rubin]

"G.B." <bauhaus@notmyhomepage.invalid> writes:
> Does C++ have objects, not allocated via *new*, whose size in bytes will
> be known only at run time?

It has them, but you are not required to use them ;-).  If you want
proofs of memory bounds, you are better off not using those kinds of
objects.

Re: How to get Ada to “cross the chasm”?

[Dennis Lee Bieber]

On Sat, 05 May 2018 16:37:32 -0700, Paul Rubin <no.email@nospam.invalid>
declaimed the following:

>"G.B." <bauhaus@notmyhomepage.invalid> writes:
>> Does C++ have objects, not allocated via *new*, whose size in bytes will
>> be known only at run time?
>
>It has them, but you are not required to use them ;-).  If you want
>proofs of memory bounds, you are better off not using those kinds of
>objects.

	And for the avionics I have been exposed to -- you do not use
constructs that require the secondary stack... Same reason -- size not
known until run-time.

	Granted -- it was a bit tedious to not be able to just concatenate
literal strings with the result of, say 'image() to format an output line;
instead needing to specify the entire literal including space for the
varying data, and substring (fixed dimensions) to placeholder(s).


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

Re: How to get Ada to “cross the chasm”?

[Dmitry A. Kazakov]

On 2018-05-06 03:15, Dennis Lee Bieber wrote:
> On Sat, 05 May 2018 16:37:32 -0700, Paul Rubin <no.email@nospam.invalid>
> declaimed the following:
> 
>> "G.B." <bauhaus@notmyhomepage.invalid> writes:
>>> Does C++ have objects, not allocated via *new*, whose size in bytes will
>>> be known only at run time?
>>
>> It has them, but you are not required to use them ;-).  If you want
>> proofs of memory bounds, you are better off not using those kinds of
>> objects.
> 
> 	And for the avionics I have been exposed to -- you do not use
> constructs that require the secondary stack... Same reason -- size not
> known until run-time.
> 
> 	Granted -- it was a bit tedious to not be able to just concatenate
> literal strings with the result of, say 'image() to format an output line;
> instead needing to specify the entire literal including space for the
> varying data, and substring (fixed dimensions) to placeholder(s).

A job for a contract. I always wanted to be able to contract the stack 
space of a subprogram in Ada. The contract should be conditional of the 
arguments. In the case of "&" it is the caller's stack contract to 
verify since the result of concatenation goes to the caller's stack.

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

Re: How to get Ada to “cross the chasm”?

[Simon Wright]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

> 	And for the avionics I have been exposed to -- you do not use
> constructs that require the secondary stack... Same reason -- size not
> known until run-time.

Just for interest, I just rebuilt AdaCore's Certyflie with the
restriction No_Secondary_Stack; no problems. Might be different if
there'd been any debug output, of course.

I didn't try rebuilding the Ada_Drivers_Library like this: I've already
had to remove No_Recursion, because the library includes directory
traversal in file systems.

Re: How to get Ada to “cross the chasm”?

[Niklas Holsti]

On 18-05-06 11:02 , Simon Wright wrote:
> Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
>
>> 	And for the avionics I have been exposed to -- you do not use
>> constructs that require the secondary stack... Same reason -- size not
>> known until run-time.
>
> Just for interest, I just rebuilt AdaCore's Certyflie with the
> restriction No_Secondary_Stack; no problems.

Just from curiosity: did you check that the linked program did not 
include any secondary-stack functions? I've found that some versions of 
GNAT Pro for the SPARC/LEON do not fully obey the No_Secondary_Stack 
restriction in the gnat.adc file.

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

Re: How to get Ada to “cross the chasm”?

[Simon Wright]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> On 18-05-06 11:02 , Simon Wright wrote:
>> Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
>>
>>> 	And for the avionics I have been exposed to -- you do not use
>>> constructs that require the secondary stack... Same reason -- size
>>> not known until run-time.
>>
>> Just for interest, I just rebuilt AdaCore's Certyflie with the
>> restriction No_Secondary_Stack; no problems.
>
> Just from curiosity: did you check that the linked program did not
> include any secondary-stack functions? I've found that some versions
> of GNAT Pro for the SPARC/LEON do not fully obey the
> No_Secondary_Stack restriction in the gnat.adc file.

The map file only shows that s-secsta was linked because of
s-tarest. Maybe the map only shows the first reason for linking. I see
that although the main crazyflie application doesn't use the secondary
stack, the support library does; and sure enough, it's string
catenation, in one place, in the logging subsystem. Could have been
avoided by careful assignment to slices of a fixed string.

Re: How to get Ada to “cross the chasm”?

[Niklas Holsti]

On 18-05-06 13:16 , Simon Wright wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>
>> On 18-05-06 11:02 , Simon Wright wrote:
>>> Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
>>>
>>>> 	And for the avionics I have been exposed to -- you do not use
>>>> constructs that require the secondary stack... Same reason -- size
>>>> not known until run-time.
>>>
>>> Just for interest, I just rebuilt AdaCore's Certyflie with the
>>> restriction No_Secondary_Stack; no problems.
>>
>> Just from curiosity: did you check that the linked program did not
>> include any secondary-stack functions? I've found that some versions
>> of GNAT Pro for the SPARC/LEON do not fully obey the
>> No_Secondary_Stack restriction in the gnat.adc file.
>
> The map file only shows that s-secsta was linked because of
> s-tarest. Maybe the map only shows the first reason for linking. I see
> that although the main crazyflie application doesn't use the secondary
> stack, the support library does; and sure enough, it's string
> catenation, in one place, in the logging subsystem. Could have been
> avoided by careful assignment to slices of a fixed string.

So GNAT did not complain about the support library violating 
No_Secondary_Stack?

Perhaps someone should report this to AdaCore... I'll put it on my 
to-do-list, for the SPARC/LEON compiler case.

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

Re: How to get Ada to “cross the chasm”?

[Simon Wright]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> On 18-05-06 13:16 , Simon Wright wrote:
>> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>>
>>> On 18-05-06 11:02 , Simon Wright wrote:
>>>> Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
>>>>
>>>>> 	And for the avionics I have been exposed to -- you do not use
>>>>> constructs that require the secondary stack... Same reason -- size
>>>>> not known until run-time.
>>>>
>>>> Just for interest, I just rebuilt AdaCore's Certyflie with the
>>>> restriction No_Secondary_Stack; no problems.
>>>
>>> Just from curiosity: did you check that the linked program did not
>>> include any secondary-stack functions? I've found that some versions
>>> of GNAT Pro for the SPARC/LEON do not fully obey the
>>> No_Secondary_Stack restriction in the gnat.adc file.
>>
>> The map file only shows that s-secsta was linked because of
>> s-tarest. Maybe the map only shows the first reason for linking. I see
>> that although the main crazyflie application doesn't use the secondary
>> stack, the support library does; and sure enough, it's string
>> catenation, in one place, in the logging subsystem. Could have been
>> avoided by careful assignment to slices of a fixed string.
>
> So GNAT did not complain about the support library violating
> No_Secondary_Stack?
>
> Perhaps someone should report this to AdaCore... I'll put it on my
> to-do-list, for the SPARC/LEON compiler case.

Hold fire on that! the restriction was only applied in the application
project, not the support library.

When I applied the retriction to the support library, it found 12 units
that couldn't be compiled: only one of these was in Ada_Drivers_Library
(stm32-board.adb; but there were 3 spec files that failed the check).

Re: How to get Ada to “cross the chasm”?

[Jacob Sparre Andersen]

Paul Rubin wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

>> One reason is that when a function evaluates an expression that
>> creates an object of a large, dynamic size (eg. an array expression)
>> on the secondary stack, this object can be returned /in situ/ as the
>> function's return value, without being copied.
>
> Ok, but that pattern is so common that allocating the space in the
> primary stack before calling the function is a standard optimization
> that every serious C++ compiler knows how to do.  Then the function
> writes the result into the primary stack and the caller can still use
> it after the function returns.  Could Ada not do it the same way?

How would you do it with this example?

   with Ada.Numerics.Discrete_Random;
   with Ada.Strings.Fixed;
   with Ada.Text_IO;
   
   procedure Random_String is
   
      subtype Lengths is Integer range 10 .. 20;
   
      package Random_Lengths is
        new Ada.Numerics.Discrete_Random (Result_Subtype => Lengths);
   
      Generator : Random_Lengths.Generator;
   
      function Example (C : in Character) return String is
         use Ada.Strings.Fixed;
      begin
         return Random_Lengths.Random (Generator) * C;
      end Example;
   
   begin
      Random_Lengths.Reset (Generator);
   
      Ada.Text_IO.Put_Line (Example ('H'));
      Ada.Text_IO.Put_Line (Example ('e'));
      Ada.Text_IO.Put_Line (Example ('l'));
      Ada.Text_IO.Put_Line (Example ('l'));
      Ada.Text_IO.Put_Line (Example ('o'));
   end Random_String;

Greetings,

Jacob
-- 
»But you have to be a bit wary of a ship that collects
 snowflakes.«                                  -- Diziet Sma

Re: How to get Ada to “cross the chasm”?

[Paul Rubin]

Jacob Sparre Andersen <jacob@jacob-sparre.dk> writes:
>> Then the function writes the result into the primary stack and the
>> caller can still use it after the function returns.
>
> How would you do it with this example? ...
>    procedure Random_String is  ...

I couldn't tell quite what that example was doing, but C++ std::strings
are allocated on the heap, so it looks to me like the return value is a
single pointer.  Std::vector should be similar while std:array is just
for fixed size arrays.  I think C++ may be more willing in general than
Ada to heap-allocate data, which is freed when it goes out of scope.

Re: How to get Ada to “cross the chasm”?

[Jacob Sparre Andersen]

Paul Rubin <no.email@nospam.invalid> writes:
> Jacob Sparre Andersen <jacob@jacob-sparre.dk> writes:
>> Paul Rubin wrote:
>>> Then the function writes the result into the primary stack and the
>>> caller can still use it after the function returns.
>>
>> How would you do it with this example? ...
>>    procedure Random_String is  ...
>
> I couldn't tell quite what that example was doing, but C++
> std::strings are allocated on the heap, so it looks to me like the
> return value is a single pointer.  Std::vector should be similar while
> std:array is just for fixed size arrays.  I think C++ may be more
> willing in general than Ada to heap-allocate data, which is freed when
> it goes out of scope.

Imagine it wasn't a string, but some other explicitly fixed size array.

I can't see how the compiler in this case can preallocate the array on
the primary stack as you write above.

It the explanation that C++ simply doesn't allow functions to return
indefinite types, and thus prevents the programmers from using the stack
for indefinite types?

Greetings,

Jacob
-- 
"Human beings just can't not communicate."

Re: How to get Ada to “cross the chasm”?

[Paul Rubin]

Jacob Sparre Andersen <jacob@jacob-sparre.dk> writes:
> Imagine it wasn't a string, but some other explicitly fixed size array.
> I can't see how the compiler in this case can preallocate the array on
> the primary stack as you write above.

If it's fixed size, what's the problem?

> It the explanation that C++ simply doesn't allow functions to return
> indefinite types, 

I'm not sure what you mean by an indefinite type.  If it means a type
whose size isn't known at compile time, then I wouldn't consider it
fixed size in the sense of the previous paragraph.  

https://en.wikipedia.org/wiki/Return_value_optimization

discusses this topic in more detail.

Re: How to get Ada to “cross the chasm”?

[Jacob Sparre Andersen]

Paul Rubin <no.email@nospam.invalid> writes:
> Jacob Sparre Andersen <jacob@jacob-sparre.dk> writes:

>> Imagine it wasn't a string, but some other explicitly fixed size
>> array.  I can't see how the compiler in this case can preallocate the
>> array on the primary stack as you write above.
>
> If it's fixed size, what's the problem?

It is only fixed once an object of the type is declared.  It sounds like
you need to read up on "indefinite types" in Ada.

>> It the explanation that C++ simply doesn't allow functions to return
>> indefinite types, 
>
> I'm not sure what you mean by an indefinite type.  If it means a type
> whose size isn't known at compile time, then I wouldn't consider it
> fixed size in the sense of the previous paragraph.

Indefinite types are types, where not all constraints are decided until
you actually create an object of that type.

Greetings,

Jacob
-- 
Photos from the Faroe Islands:
       http://billeder.sparre-andersen.dk/The_Faroe_Islands/

Re: How to get Ada to 'cross the chasm'?

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message
news:87d0y97lda.fsf@nightsong.com...
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>> One reason is that when a function evaluates an expression that
>> creates an object of a large, dynamic size (eg. an array expression)
>> on the secondary stack, this object can be returned /in situ/ as the
>> function's return value, without being copied.
>
> Ok, but that pattern is so common that allocating the space in the
> primary stack before calling the function is a standard optimization
> that every serious C++ compiler knows how to do.  Then the function
> writes the result into the primary stack and the caller can still use it
> after the function returns.  Could Ada not do it the same way?

It usually does when the size of the object is known at compile time. The
secondary stack is mainly used for returning object whose size is not known
at compile-time. (Note: I don't know the details of the GNAT
implementation.) The classic example is a function returning a string:

   function My_Image (Val : in Integer) return String;

Here, the size of the string returned isn't known until the function figures
it out; there's no way for the caller to know that (as it doesn't
necessarily know anything about the body).

Janus/Ada returns such objects on the heap rather than horsing around with a
second stack. (When I get a Round Tuit, I'm going to move static-sized
objects to essentially be parameters to the function, one of zillion
projects that I need to do someday soon.) It keeps track of them and frees
them up when they're no longer needed (using a mechanism very similar to
finalization). The cost isn't much different than the secondary stack, and
you can't really analyze either very well.

            Randy.


                     Randy.

Re: How to get Ada to “cross the chasm”?

[jm.tarrasa]

> > 4.  It is not hindered by backwards compatibility concerns.  They take
> 
> There are a lot of people who would love to see a new Ada version break away from the previous versions, possibly even a rewrite removing all the crap that's not really required and basically, an Ada for the 21st century.

Backward compatibility is great. Most software that ran in Windows 95 still runs in Windows 10. On the other side, Gtk: Themes written for 3.18 break in 3.20 https://blogs.gnome.org/mclasen/2015/11/20/a-gtk-update/

But there is a point that you must correct problems even breaking compatibility.  I know that in software, with long term deployments, it is not easy. Many backend software in banks and assurance companies is still COBOL, and they don't dare to migrate it. But someday, you have to break with past to advance.

It would be wonderful that Ada experts that have experience to know the problems and drawbacks of Ada, correct them even breaking compatibility.
That would be the "Ada Successor Language"
https://groups.google.com/d/topic/comp.lang.ada/CrPqENqxl4g/discussion
No chance. It looks like current specification is perfect so far, only needs additions, not amendments.
Ada experts don't want to change anything, and non Ada experts create Go, Rust, Swift, Erlang, Nim...

Re: How to get Ada to “cross the chasm”?

[Dmitry A. Kazakov]

On 2018-07-14 11:27, jm.tarrasa@gmail.com wrote:

> Backward compatibility is great. Most software that ran in Windows 95 still runs in Windows 10. On the other side, Gtk: Themes written for 3.18 break in 3.20 https://blogs.gnome.org/mclasen/2015/11/20/a-gtk-update/

Yep, GTK is exemplary showing how not to do it. They learned nothing 
from the disaster of going from GTK 2 to GTK 3.

> But there is a point that you must correct problems even breaking compatibility.

"Backward compatibility" is a preferred method of argument ARG members 
use to reject proposals without considering them. (:-))

If somebody proposes something you simply say it would be backward 
incompatible to do. Mission accomplished.

I doubt there is any real problem in Ada that cannot be resolved keeping 
*everything* backward compatible.

> Ada experts don't want to change anything, and non Ada experts create Go, Rust, Swift, Erlang, Nim...

Everybody has his pet ideas. In order to change anything there must be a 
consensus or somebody extremely influential with iron will and fists.

Non Ada experts, being non experts, keep on creating yet another garbage 
language of the day...

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

Re: How to get Ada to “cross the chasm”?

[Shark8]

On Saturday, July 14, 2018 at 4:07:16 AM UTC-6, Dmitry A. Kazakov wrote:
> 
> I doubt there is any real problem in Ada that cannot be resolved keeping 
> *everything* backward compatible.

There are some things that can't be fixed while keeping backwards compatibility and *NOT* adding yet-another-way-to-do-this; which is what C++ did with it's myriad of pointers and references.

A couple of good examples:
* Anonymous access types,
* Protected objects (What's in the private section ought to be the body, IMO.)
       protected type Signal_Object is
          entry Wait;
          procedure Signal;
          function Is_Open return Boolean;
       private
          Open : Boolean := False; -- WHY ARE WE EXPOSING THIS?
       end Signal_Object;

> 
> > Ada experts don't want to change anything, and non Ada experts create Go, Rust, Swift, Erlang, Nim...
> 
> Everybody has his pet ideas. In order to change anything there must be a 
> consensus or somebody extremely influential with iron will and fists.
This is true.
And there is some merit to the complaint of enshrining backwards compatibility; there is also merit to the ARG's default position of prioritizing backwards compatibility.

Considering the experience of compiling 25- or 30-year old Ada, on a completely different OS, with a completely different compiler, and needing less than 10 changes to compile and get an executable, due IIRC to the new 'SOME' keyword which had been used as an identifier & having to split a single file into two due to GNAT's limitations the reliability inherent in such backwards compatibility cannot be denied. -- I've had a few experiences with trying to compile 2-year old C or C++ in college and being unable to do so w/o major changes. -- That's a practical difference between Ada and C++.

> 
> Non Ada experts, being non experts, keep on creating yet another garbage 
> language of the day...
To be fair, some of these languages have some interesting ideas and I'd be hesitant to cal them 'garbage', Erlang for example is quite interesting: being functional and embracing the actor model for concurrency. (I had wanted to build an Erlang in Ada, but its problem is that the only language standard I could find is REALLY old/outdated.)

Re: How to get Ada to “cross the chasm”?

[Dmitry A. Kazakov]

On 2018-07-14 16:28, Shark8 wrote:
> On Saturday, July 14, 2018 at 4:07:16 AM UTC-6, Dmitry A. Kazakov wrote:
>>
>> I doubt there is any real problem in Ada that cannot be resolved keeping
>> *everything* backward compatible.
> 
> There are some things that can't be fixed while keeping backwards compatibility and *NOT* adding yet-another-way-to-do-this; which is what C++ did with it's myriad of pointers and references.
> 
> A couple of good examples:
> * Anonymous access types,

Ada needs a proper abstract access type interface. Built-in anonymous 
access will become its a library implementation of with certain 
properties. No problem.

Blow the library, keep the language small.

> * Protected objects (What's in the private section ought to be the body, IMO.)
>         protected type Signal_Object is
>            entry Wait;
>            procedure Signal;
>            function Is_Open return Boolean;
>         private
>            Open : Boolean := False; -- WHY ARE WE EXPOSING THIS?
>         end Signal_Object;

Same as above. Protected and task types must be interfaces. There is 
nothing wrong leaving depreciated syntax for a specific implementation 
of. Newer programs will simply inherit from abstract task or abstract 
protected interface using normal Ada syntax and normal privacy rules. No 
new syntax, no new constructs, just making the type system to do its job.

One of few issues that cannot be fixed is this:

   X : Integer; -- Must be illegal, immutable should have been default

>>> Ada experts don't want to change anything, and non Ada experts create Go, Rust, Swift, Erlang, Nim...
>>
>> Everybody has his pet ideas. In order to change anything there must be a
>> consensus or somebody extremely influential with iron will and fists.
> This is true.
> And there is some merit to the complaint of enshrining backwards compatibility; there is also merit to the ARG's default position of prioritizing backwards compatibility.

Unless used as an excuse not to address language problems.

>> Non Ada experts, being non experts, keep on creating yet another garbage
>> language of the day...
> To be fair, some of these languages have some interesting ideas and I'd be hesitant to cal them 'garbage', Erlang for example is quite interesting: being functional and embracing the actor model for concurrency. (I had wanted to build an Erlang in Ada, but its problem is that the only language standard I could find is REALLY old/outdated.)

The only problem is that such languages are typically built around a 
single idea, usefulness of which likely exaggerated to the point of the 
opposite or not useful at all, tried and dropped 40 years ago, tied 
again 20 years ago ...

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

Re: How to get Ada to “cross the chasm”?

[Niklas Holsti]

On 18-07-14 17:28 , Shark8 wrote:
> On Saturday, July 14, 2018 at 4:07:16 AM UTC-6, Dmitry A. Kazakov wrote:
>>
>> I doubt there is any real problem in Ada that cannot be resolved keeping
>> *everything* backward compatible.
>
> There are some things that can't be fixed while keeping backwards
> compatibility and *NOT* adding yet-another-way-to-do-this; which
> is what C++ did with it's myriad of pointers and references.
>
> A couple of good examples:
     [snip]
> * Protected objects (What's in the private section ought to be the body, IMO.)
>        protected type Signal_Object is
>           entry Wait;
>           procedure Signal;
>           function Is_Open return Boolean;
>        private
>           Open : Boolean := False; -- WHY ARE WE EXPOSING THIS?
>        end Signal_Object;

The answer to your shouted question is (as I suspect you know): because 
a protected type declaration defines a type that will be used to declare 
objects, and the compiler must know the size, structure and alignment of 
the data contained in the object before it can make code to create such 
an object.

If the private component declarations were moved to the body, clients 
of the package that defines the protected type would come to depend on 
the body of that package.

Nevertheless, as such a dependency is usually not fatal (resulting also 
from generics) I don't see why Ada could not be extended to allow the 
private component declarations to be optionally postponed to the body, 
for example with this declaration syntax (just a what-came-first-to-mind 
sketch):

    protected type Signal_Object is
       entry Wait;
       procedure Signal;
       function Is_Open return Boolean;
    private in body; -- NOT current Ada!
    end Signal_Object;

and this body syntax (the declarations of the object components come 
first, because the operations must see them):

    protected body Signal_Object is
       Open : Boolean := False;  -- NOT current Ada!
       entry Wait
          ...  -- Body of Wait.
       ... -- Bodies of Signal and Is_Open.
    end Signal_Object;

I don't see any backward compatibility problem with this.

Of course it is "yet another way" to declare the components of a 
protected type. So what? If you convince enough people that this kind of 
protected declaration is desirable, you might be able to convince the 
ARG to add it to Ada. I think it can be done without breaking backward 
compatibility with current Ada.

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

Re: How to get Ada to “cross the chasm”?

[Brad Moore]

On Saturday, July 14, 2018 at 9:48:59 AM UTC-6, Niklas Holsti wrote:
> On 18-07-14 17:28 , Shark8 wrote:
> > On Saturday, July 14, 2018 at 4:07:16 AM UTC-6, Dmitry A. Kazakov wrote:
> >>
> >> I doubt there is any real problem in Ada that cannot be resolved keeping
> >> *everything* backward compatible.
> >
> > There are some things that can't be fixed while keeping backwards
> > compatibility and *NOT* adding yet-another-way-to-do-this; which
> > is what C++ did with it's myriad of pointers and references.
> >
> > A couple of good examples:
>      [snip]
> > * Protected objects (What's in the private section ought to be the body, IMO.)
> >        protected type Signal_Object is
> >           entry Wait;
> >           procedure Signal;
> >           function Is_Open return Boolean;
> >        private
> >           Open : Boolean := False; -- WHY ARE WE EXPOSING THIS?
> >        end Signal_Object;
> 
> The answer to your shouted question is (as I suspect you know): because 
> a protected type declaration defines a type that will be used to declare 
> objects, and the compiler must know the size, structure and alignment of 
> the data contained in the object before it can make code to create such 
> an object.
> 
> If the private component declarations were moved to the body, clients 
> of the package that defines the protected type would come to depend on 
> the body of that package.
> 
> Nevertheless, as such a dependency is usually not fatal (resulting also 
> from generics) I don't see why Ada could not be extended to allow the 
> private component declarations to be optionally postponed to the body, 
> for example with this declaration syntax (just a what-came-first-to-mind 
> sketch):
> 
>     protected type Signal_Object is
>        entry Wait;
>        procedure Signal;
>        function Is_Open return Boolean;
>     private in body; -- NOT current Ada!
>     end Signal_Object;
> 
> and this body syntax (the declarations of the object components come 
> first, because the operations must see them):
> 
>     protected body Signal_Object is
>        Open : Boolean := False;  -- NOT current Ada!
>        entry Wait
>           ...  -- Body of Wait.
>        ... -- Bodies of Signal and Is_Open.
>     end Signal_Object;
> 
> I don't see any backward compatibility problem with this.
> 
> Of course it is "yet another way" to declare the components of a 
> protected type. So what? If you convince enough people that this kind of 
> protected declaration is desirable, you might be able to convince the 
> ARG to add it to Ada. 

Well, I cant speak for others, but I am so far not convinced that this kind of protected declaration is desirable.

I think it can be done without breaking backward 
> compatibility with current Ada.

I think what you are asking for is too close to what is already available, and so I think there is not enough benefit to add "more ways to doing the same thing"

Here are two ways to do something similar.

First, we could use an incomplete type (Taft amendment type) to move the protected type declaration to the body of a package, as in...

package Q
is

   type Signal_Object is limited private;

   procedure Wait   (Item : in out Signal_Object);
     --  with Nonblocking => False;

   procedure Signal (Item : in out Signal_Object);
     --  with Nonblocking;

   function Is_Open (Item : Signal_Object) return Boolean;
     --  with Nonblocking;

   function Create return Signal_Object;

private

   type Private_In_Body;
   type Signal_Object is not null access Private_In_Body;

end Q;

package body Q is

   protected type Private_In_Body is
      entry     Wait;
      procedure Signal;
      function  Is_Open return Boolean;
   private
      Open : Boolean := False;
   end Private_In_Body;

   protected body Private_In_Body is

      function Is_Open return Boolean is
      begin
         return Open;
      end Is_Open;

      procedure Signal is
      begin
         Open := True;
      end Signal;

      entry Wait when Open is
      begin
         null;
      end Wait;

   end Private_In_Body;

   function Create return Signal_Object is
   begin
      return new Private_In_Body;
   end Create;

   procedure Signal (Item : in out Signal_Object) is
   begin
      Item.Signal;
   end Signal;

   function Is_Open (Item : Signal_Object) return Boolean is
      (Item.Is_Open);

   procedure Wait   (Item : in out Signal_Object) is
   begin
      Item.Wait;
   end Wait;

end Q;

We are hiding the implementation behind an access type, but that is not exposed in the public part of the package, so that seems OK to me.
The public view is not of a protected type, but instead a limited type, however with Ada 202x, we will be able to specify that the Wait call is a call that can block (via the Nonblocking aspect), which gives more of a clue about the implementation.

I think a reasonable approach however is to have the protected type declared in the private part of the package. 
Here is one way to do that using protected interfaces....

package P is

   type  Signal_Interface is protected interface;

   procedure Wait   (Item : in out Signal_Interface) is abstract;
   procedure Signal (Item : in out Signal_Interface) is abstract;
   function Is_Open (Item : Signal_Interface) return Boolean is abstract;

end P;

with P;

package R is
   type Signal_Object is synchronized new P.Signal_Interface with private;

   overriding
   procedure Wait   (Item : in out Signal_Object)
     with Synchronization => By_Entry;

   overriding
   procedure Signal (Item : in out Signal_Object)
      with Synchronization => By_Protected_Procedure;

   overriding
   function Is_Open (Item : Signal_Object) return Boolean;

private

   protected type Signal_Object is new P.Signal_Interface with
      entry Wait_For_Signal;
      procedure Set_Signal;
      function Signal_Is_Open return Boolean;
   private
      Open : Boolean := False;
   end Signal_Object;

end R;

package body R is

   protected body Signal_Object is

      procedure Set_Signal is
      begin
         Open := True;
      end Set_Signal;

      function Signal_Is_Open return Boolean is
      begin
         return Open;
      end Signal_Is_Open;

      entry Wait_For_Signal when Open is
      begin
         null;
      end Wait_For_Signal;

   end Signal_Object;

   overriding
   function Is_Open
     (Item : Signal_Object)
      return Boolean is
   begin
      return Item.Signal_Is_Open;
   end Is_Open;

   overriding procedure Signal
     (Item : in out Signal_Object) is
   begin
      Item.Set_Signal;
   end Signal;

   overriding procedure Wait
     (Item : in out Signal_Object) is
   begin
      Item.Wait_For_Signal;
   end Wait;

end R;

with Ada.Text_IO; use Ada.Text_IO;
with Q;
with R;

procedure Main
is
begin -- Main

   Example_1 :
   declare
      The_Signal : Q.Signal_Object := Q.Create;

      task T;
      task body T is
      begin
         delay 5.0;
         Put_Line ("Signalling...");
         Q.Signal (The_Signal);
      end T;
   begin

      Put_Line ("The Signal is " &
                (if Q.Is_Open (The_Signal) then "Open" else "False"));

      Put_Line ("Waiting...");
      Q.Wait (The_Signal);
      Put_Line ("Done");
   end Example_1;

   Example_2 :
   declare
      The_Signal : R.Signal_Object;

      task T;
      task body T is
      begin
         delay 5.0;
         Put_Line ("Signalling...");
         The_Signal.Signal;  -- Dot_Prefix notation
      end T;
   begin

      Put_Line ("The Signal is " &
                (if The_Signal.Is_Open then "Open" else "False"));

      Put_Line ("Waiting...");
      The_Signal.Wait;
      Put_Line ("Done");
   end Example_2;

end Main;

The advantage of this second example, is that the client of the package is more aware that the type, Signal_Object, is a protected object. Also, because it is a tagged type, the dot prefix notation can be used when making the calls, as shown in Example_2.

Alternatively, we could have not used interfaces, but declared the protected type in the private part, while using a limited type in the public part as the partial view of the type.

Other variants are also possible, such as using a controlled type to provide finalization for types involving heap allocation, etc.

Brad Moore

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

Re: How to get Ada to “cross the chasm”?

[AdaMagica]

Am Samstag, 14. Juli 2018 16:28:16 UTC+2 schrieb Shark8:
> * Protected objects (What's in the private section ought to be the body, IMO.)
>        protected type Signal_Object is
>           entry Wait;
>           procedure Signal;
>           function Is_Open return Boolean;
>        private
>           Open : Boolean := False; -- WHY ARE WE EXPOSING THIS?
>        end Signal_Object;

Where is the problem? I don't see one. It's not more exposed than

package P is
  type X is private;
private
  type X is record
    I: Integer;
  end record;
end P;

Re: How to get Ada to “cross the chasm”?

[Dmitry A. Kazakov]

On 2018-07-15 16:32, AdaMagica wrote:
> Am Samstag, 14. Juli 2018 16:28:16 UTC+2 schrieb Shark8:
>> * Protected objects (What's in the private section ought to be the body, IMO.)
>>         protected type Signal_Object is
>>            entry Wait;
>>            procedure Signal;
>>            function Is_Open return Boolean;
>>         private
>>            Open : Boolean := False; -- WHY ARE WE EXPOSING THIS?
>>         end Signal_Object;
> 
> Where is the problem? I don't see one. It's not more exposed than
> 
> package P is
>    type X is private;
> private
>    type X is record
>      I: Integer;
>    end record;
> end P;

Yes, but it does not feel right. It is OK when protected type is a 
compilation unit. It is not OK when it is nested. BTW, it is not OK for 
nested packages either:

    package A is
       package P is
          type X is private;
       private
          type X is record
             I: Integer;
          end record;
       end P;
    end A;

I would prefer something like:

    package A is
       package P is
          type X is private;
       end P;
    private
       package private P is
          type X is record
             I: Integer;
          end record;
       end P;
    end A;

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

Re: How to get Ada to “cross the chasm”?

[Dennis Lee Bieber]

On Sat, 14 Jul 2018 02:27:33 -0700 (PDT), jm.tarrasa@gmail.com declaimed
the following:

>
>But there is a point that you must correct problems even breaking compatibility.  I know that in software, with long term deployments, it is not easy. Many backend software in banks and assurance companies is still COBOL, and they don't dare to migrate it. But someday, you have to break with past to advance.
>

	Or not... Raincode Labs provides IBM compatible COBOL, PL/I, ASM370
compilers, a JCL interpreter, and a CICS emulator -- all running on Windows
.NET/Azure -- for the sole purpose of allowing old software to be ported to
new hardware. (As I recall, if you pay for the full system, it even
integrates with Visual Studio -- the free COBOL does not).

	And so many places are running OpenVMS in virtual VAX and Alpha
systems.


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

Re: How to get Ada to “cross the chasm”?

[Marius Amado-Alves]

Of course Rust is fun: it has macros, and many glyphs:-)

Re: How to get Ada to “cross the chasm”?

[Mehdi Saada]

I have trouble believing that Adacore (free) forbid completely selling softwares in other licenses as GPL or the likes of. I have no technical knowledge of these things, but I feel like  your points of view are a bit... one sided ?

Re: How to get Ada to “cross the chasm”?

[Simon Wright]

Mehdi Saada <00120260a@gmail.com> writes:

> I have trouble believing that Adacore (free) forbid completely selling
> softwares in other licenses as GPL or the likes of. I have no
> technical knowledge of these things, but I feel like your points of
> view are a bit... one sided ?

There is no doubt that if you distribute an executable built with the
distributed GNAT GPL you have to do so under the GPL (all *your* sources
distributed too), because the RTS has the full GPL.

This is not necessarily the case for an executable built with FSF GCC
(it depends what other sources are involved besides your own code and
the runtime).

I see no reason why an executable built with GNAT GPL but with a
different RTS (that doesn't have the full GPL) need be distributed under
the GPL. So, in theory, you might be able to use the RTS from FSF GNAT
with GNAT GPL (but I wouldn't hold out much hope, the interface between
the compiler and the RTS is subject to change: the last time FSF GCC and
GNAT GPL were compatible was FSF GCC 6 and GNAT GPL 2016).

Re: How to get Ada to ?cross the chasm??

[Simon Clubley]

On 2018-04-18, Simon Wright <simon@pushface.org> wrote:
>
> I see no reason why an executable built with GNAT GPL but with a
> different RTS (that doesn't have the full GPL) need be distributed under
> the GPL. So, in theory, you might be able to use the RTS from FSF GNAT
> with GNAT GPL (but I wouldn't hold out much hope, the interface between
> the compiler and the RTS is subject to change: the last time FSF GCC and
> GNAT GPL were compatible was FSF GCC 6 and GNAT GPL 2016).

Even if that is true, how many people do you think would go to that
effort instead of just using a language where the compiler authors
don't play such GPL games ?

As I have said before, Ada is a good language but with a horrible
compiler situation.

Simon.

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

Re: How to get Ada to ?cross the chasm??

[Simon Wright]

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

> On 2018-04-18, Simon Wright <simon@pushface.org> wrote:
>>
>> I see no reason why an executable built with GNAT GPL but with a
>> different RTS (that doesn't have the full GPL) need be distributed
>> under the GPL. So, in theory, you might be able to use the RTS from
>> FSF GNAT with GNAT GPL (but I wouldn't hold out much hope, the
>> interface between the compiler and the RTS is subject to change: the
>> last time FSF GCC and GNAT GPL were compatible was FSF GCC 6 and GNAT
>> GPL 2016).
>
> Even if that is true, how many people do you think would go to that
> effort instead of just using a language where the compiler authors
> don't play such GPL games ?

Hardly any. But I was coming from Cortex GNAT RTS[1], where you can use
GNAT GPL 2017 to build code using an FSF-derived RTS.

[1] https://github.com/simonjwright/cortex-gnat-rts/tree/gnat-gpl-2017

Re: How to get Ada to ?cross the chasm??

[invalid]

On 2018-04-18, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2018-04-18, Simon Wright <simon@pushface.org> wrote:
>>
>> I see no reason why an executable built with GNAT GPL but with a
>> different RTS (that doesn't have the full GPL) need be distributed under
>> the GPL. So, in theory, you might be able to use the RTS from FSF GNAT
>> with GNAT GPL (but I wouldn't hold out much hope, the interface between
>> the compiler and the RTS is subject to change: the last time FSF GCC and
>> GNAT GPL were compatible was FSF GCC 6 and GNAT GPL 2016).
>
> Even if that is true, how many people do you think would go to that
> effort instead of just using a language where the compiler authors
> don't play such GPL games ?
>
> As I have said before, Ada is a good language but with a horrible
> compiler situation.

I agree with this. But the same is true of several other major languages.

Re: How to get Ada to ?cross the chasm??

[Simon Clubley]

On 2018-04-17, Mehdi Saada <00120260a@gmail.com> wrote:
> I have trouble believing that Adacore (free) forbid completely selling
> softwares in other licenses as GPL or the likes of. I have no technical
> knowledge of these things, but I feel like  your points of view are a
> bit... one sided ?

Adacore force the GPL on any software developed using the Community
version. See

https://www.adacore.com/gnatpro/comparison

where it says (under Community) "For open source GPL software".

Oh, and it's not "one sided", it's called giving the Ada community
a dose of cold reality. You can talk about the advantages of Ada all
you want but Ada's advantages mean nothing until the Ada compiler
situation matches the compiler situation for other languages.

Any compiler which imposes the GPL on any software developed using
it would be absolutely dead on arrival in many environments especially
when compilers for other languages are available for free which do
not impose such constraints.

GPL based software development is a small subset of all the software
development out there.

Also, as far as I can see (and I am willing to be corrected here if
I am wrong) it means that you can't even write a library in Ada under
something other than the GPL if you are going to use the Community
version. As soon as you compile the library source with the Community
version, it falls under the GPL and hence any software using your
library also falls under the GPL.

In order to create an Ada library with a LGPL or MIT licence
(for example), you have to fall back to the FSF version which
does not have that constraint.

Simon.

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

Re: How to get Ada to ?cross the chasm??

[J-P. Rosen]

Le 18/04/2018 à 14:44, Simon Clubley a écrit :
> You can talk about the advantages of Ada all
> you want but Ada's advantages mean nothing until the Ada compiler
> situation matches the compiler situation for other languages.
Sure. Other languages use FSF GCC. So, the situation does match the
situation for other languages. What's the problem?

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

Re: How to get Ada to ?cross the chasm??

[Simon Clubley]

On 2018-04-18, J-P. Rosen <rosen@adalog.fr> wrote:
> Le 18/04/2018 à 14:44, Simon Clubley a écrit :
>> You can talk about the advantages of Ada all
>> you want but Ada's advantages mean nothing until the Ada compiler
>> situation matches the compiler situation for other languages.
> Sure. Other languages use FSF GCC. So, the situation does match the
> situation for other languages. What's the problem?
>

Luke has already given examples of how the FSF code base is behind
the GNAT Pro code base.

In addition, I will also point out that the FSF version is supported
on fewer targets than the GNAT Pro version is.

One direct personal example is OpenVMS. When OpenVMS was still
a supported GNAT Pro target, I could never get the FSF version
to build for Alpha. One person did get a FSF compiler built for
Itanium but he started with GNAT Pro on Alpha, which is an
option that was not available to me.

In addition, the Platforms table here (which doesn't even cover the
FSF version) makes for interesting reading:

https://www.adacore.com/gnatpro/comparison

I was interested to see there's no bare metal support for x86 listed
and that Android is restricted to the mega-bucks development options...

(And yes, I know there's been a third-party port for Android if you
are running FreeBSD.)

Simon.

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

Re: How to get Ada to ?cross the chasm??

[Jacob Sparre Andersen]

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

> Luke has already given examples of how the FSF code base is behind the
> GNAT Pro code base.

And sometimes the GNAT Pro releases are almost a year behind the
available FSF GCC code base.  Things move a bit up and down.

AdaCore pushes to FSF are to the best of my knowledge typically only a
few weeks behind the internal AdaCore GCC tree.  (GCC release freezes
are an exception to this rule.)

Greetings,

Jacob (a happy user of FSF GNAT on Debian)
-- 
"It ain't rocket science!" - Well, some of it is!

Re: How to get Ada to ?cross the chasm??

[Dan'l Miller]

On Wednesday, April 18, 2018 at 7:44:04 AM UTC-5, Simon Clubley wrote:
> On 2018-04-17, Mehdi Saada wrote:
> > I have trouble believing that Adacore (free) forbid completely selling
> > softwares in other licenses as GPL or the likes of. I have no technical
> > knowledge of these things, but I feel like  your points of view are a
> > bit... one sided ?
> 
> Adacore force the GPL on any software developed using the Community
> version. See
> 
> https://www.adacore.com/gnatpro/comparison
> 
> where it says (under Community) "For open source GPL software".
> 
> Oh, and it's not "one sided", it's called giving the Ada community
> a dose of cold reality. You can talk about the advantages of Ada all
> you want but Ada's advantages mean nothing until the Ada compiler
> situation matches the compiler situation for other languages.
> 
> Any compiler which imposes the GPL on any software developed using
> it would be absolutely dead on arrival in many environments especially
> when compilers for other languages are available for free which do
> not impose such constraints.
> 
> GPL based software development is a small subset of all the software
> development out there.
> 
> Also, as far as I can see (and I am willing to be corrected here if
> I am wrong) it means that you can't even write a library in Ada under
> something other than the GPL if you are going to use the Community
> version. As soon as you compile the library source with the Community
> version, it falls under the GPL and hence any software using your
> library also falls under the GPL.
> 
> In order to create an Ada library with a LGPL or MIT licence
> (for example), you have to fall back to the FSF version which
> does not have that constraint.

Survey:  truly how bad is using FSF GNAT in practice?  It of course lacks all the extras and older language editions (e.g., ASIS, Ada1983, Ada1995, Ada2005, AJIS).  And sure, FSF GNAT lags by up to 24 months compared to GNAT Pro Enterprise/Assurance level; feature-by-feature bugfix-by-bugfix FSF GNAT lags by less than 12 months when compared to GNAT GPL Community Edition.

I think that the real problem with AdaCore is the lack of sub-$1000 non-GPL annual license for mass-market operating systems on mass-market ISAs, such as Windows, MacOS, Android, and iOS.  Looking at some other compiler vendors of non-Ada languages, each of them have a sub-$1000 non-GPL license available:  RemObjects $800/year (all target mass-market OSes/ISAs included), Microsoft $500/year (all mass-market target OSes/ISAs included), Intel $700/year/OS.

I am always baffled by why AdaCore doesn't hire an engineer for GNAT on mass-market OSes on mass-market ISAs (or even one engineer per each mass-market OS), because only 150 to 200 $1000 annual licenses would more than fully cover all costs for that engineer.  The likelihood of an even greater quantity of such mass-market annual licenses would be quite high, which implies profit instead of break-even.  Likewise for other Ada compiler vendors.

Re: How to get Ada to ?cross the chasm??

[Lucretia]

On Wednesday, 18 April 2018 15:31:26 UTC+1, Dan'l Miller  wrote:

> Survey:  truly how bad is using FSF GNAT in practice?  It of course lacks all the extras and older language editions (e.g., ASIS, Ada1983, Ada1995, Ada2005, AJIS).  And sure, FSF GNAT lags by up to 24 months compared to GNAT Pro Enterprise/Assurance level; feature-by-feature bugfix-by-bugfix FSF GNAT lags by less than 12 months when compared to GNAT GPL Community Edition.

FSF GNAT is the only GNAT I use. I have GPL installed, only to test when something won't compile.

12-24 months is a long fucking time for a bugfix. Currently, GNAT has issues with C++ binding (not the C import wrap kind, the pragma (CPP_*, *) kind). If we're left waiting for something that's that important, and I bet we will be, that's not on, imo.

> I think that the real problem with AdaCore is the lack of sub-$1000 non-GPL annual license for mass-market operating systems on mass-market ISAs, such as Windows, MacOS, Android, and iOS.  Looking at some other compiler vendors of non-Ada languages, each of them have a sub-$1000 non-GPL license available:  RemObjects $800/year (all target mass-market OSes/ISAs included), Microsoft $500/year (all mass-market target OSes/ISAs included), Intel $700/year/OS.

This is truly not an argument either. Say someone's deciding whether to use C or Ada and there's this sub £/$/€ 1000 compiler for Ada. They will just go with C, because there's a fucking C compiler everywhere for nothing. Seriously, look at how many C compilers there actually are. There's loads of em, all free.

> I am always baffled by why AdaCore doesn't hire an engineer for GNAT on mass-market OSes on mass-market ISAs (or even one engineer per each mass-market OS), because only 150 to 200 $1000 annual licenses would more than fully cover all costs for that engineer.  The likelihood of an even greater quantity of such mass-market annual licenses would be quite high, which implies profit instead of break-even.  Likewise for other Ada compiler vendors.

Other compiler vendor's won't do shit for OSS, the only reason AdaCore do is because they started at NYU and was spun out as a separate company, I've no idea how it became French, tbh.

Re: How to get Ada to ?cross the chasm??

[Dan'l Miller]

On Wednesday, April 18, 2018 at 12:08:42 PM UTC-5, Lucretia wrote:
> On Wednesday, 18 April 2018 15:31:26 UTC+1, Dan'l Miller  wrote:
> > I think that the real problem with AdaCore is the lack of sub-$1000 non-GPL annual license for
> > mass-market operating systems on mass-market ISAs, such as Windows, MacOS, Android, and iOS. 
> > Looking at some other compiler vendors of non-Ada languages, each of them have a sub-$1000
> > non-GPL license available:  RemObjects $800/year (all target mass-market OSes/ISAs included),
> > Microsoft $500/year (all mass-market target OSes/ISAs included), Intel $700/year/OS.
> 
> This is truly not an argument either. Say someone's deciding whether to use C or Ada and there's this
> sub-£/$/€ 1000 compiler for Ada. They will just go with C, because there's a fucking C compiler
> everywhere for nothing. Seriously, look at how many C compilers there actually are. There's loads of em, all free.

The question is not Ada versus C (at any price).  The question is Ada versus crapola.  Rust is the very first language to come along since, say, PL/I and Ada during the 1970s that seems to have some degree of understanding what being not-crapola means.  The question is how much is the average developer (per seat when in a team) willing to pay annually for a not-crapola compiler toolchain on mass-market operating systems for mass-market ISAs that permits the compiler vendor to hire a critical mass of developers to keep it going as a viable for-profit business.  By its very nature, crapola needs to be free, because it has no added value beyond perhaps being a ubiquitous commodity.  I think that developers of for-profit software are willing to pay very-low thousands* of dollars to have not-crapola tools that perform correctness checks/proofs.

* but not tens of thousands, most especially not annually

The several Ada compiler vendors who do not even yet have full Ada2005 or Ada2012 feature-set are fairly direct evidence that they don't have sufficient funding to hire a critical mass of developers to keep the chain-reaction going.  10 years is an extraordinarily long time to wait for the compiler to catch up with the language standard.

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-04-18 20:08 , Lucretia wrote:
> On Wednesday, 18 April 2018 15:31:26 UTC+1, Dan'l Miller  wrote:
>
>> Survey:  truly how bad is using FSF GNAT in practice?

I used it exclusively for about 10 years for a commercial, closed-source 
product. It was ok, but I deliberately stayed away from the newest 
language features until they had been stable in GNAT Pro for a while. 
Also, I used only the basic compiler, and neither GPS nor any of the 
surrounding tool-sets for databases, GUIs, etc.

>> I think that the real problem with AdaCore is the lack of sub-$1000
>> non-GPL annual license for mass-market operating systems on
>> mass-market ISAs, such as Windows, MacOS, Android, and iOS.

Janus/Ada and some versions of ObjectAda are or were in that range, but 
have not, I believe, sold in "mass-market" numbers.

> Other compiler vendor's won't do shit for OSS, the only reason
> AdaCore do is because they started at NYU and was spun out as a
> separate company,

AIUI, making the compiler open-source (maybe even GPL) was a condition 
in the original government contract that NYU won and which produced the 
first GNAT.

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

Re: How to get Ada to ?cross the chasm??

[Dan'l Miller]

On Wednesday, April 18, 2018 at 4:03:52 PM UTC-5, Niklas Holsti wrote:
> > On Wednesday, 18 April 2018 15:31:26 UTC+1, Dan'l Miller  wrote:
> >> I think that the real problem with AdaCore is the lack of sub-$1000
> >> non-GPL annual license for mass-market operating systems on
> >> mass-market ISAs, such as Windows, MacOS, Android, and iOS.
> 
> Janus/Ada and some versions of ObjectAda are or were in that range, but 
> have not, I believe, sold in "mass-market" numbers.

Some were toy compilers that accompanied books on Ada.  Others thought that the following Ada spec was “supporting” Ada on Windows:  forcing Ada to look verbatim like C for Win32.  Not just any old C conventions & idioms, but Microsoft's really obnoxious C conventions & idioms of that era.

https://unzip-ada.sourceforge.io/za_html/win32__ads.htm

No, supporting Ada on Windows (UWP and WPF), Android SDK, iOS CocoaTouch, and MacOS Cocoa mass-market OSes/frameworks/ISAs would look a lot more like RemObjects in doing via their Elements Compiler confederation for Swift on Windows, Swift on Android, Java on iOS, Java on Windows, C# on Android JVM, C# on processor-native machine code on Android, C# on processor-native machine code on Windows, C# on processor-native machine code on iOS & on MacOS and the corresponding mass-market ISAs.  (And gee, what a shame that RemObjects came from the Borland/Embarcadero ObjectPascal heritage instead from the Ada heritage; it would have been quite nice to see Ada in the Elements Compiler confederation instead of or in addition to ObjectPascal.)

https://docs.ElementsCompiler.com

The gargantuan (extraordinarily-useful) object model below is what supporting Microsoft Windows 10 looks like nowadays, such as supported by not only Microsoft toolchain & languages, but also by RemObjects' {Swift, Java, ObjectPascal}, and increasingly the new Ada-WinRT and WinRT-Rust.  But any Ada compilers that “support” Microsoft OSes out of the box are stuck in the Win32 era not much different than as shown in that cruel Ada spec above.  What is especially sad is that Microsoft has gone to great lengths over the past 1.5 decades to make this rich object library language agnostic, designed for language projections to feel native in each language—which has worked out especially well for C#, F# (a sibling of OCaml), Visual Basic, and the emerging C++/WinRT, Ada-WinRT, and WinRT-Rust (but which didn't work out nearly so well for the grafted-on foreign-feeling /CX and /CLI “divided by” sublanguages in C++/CX and C++/CLI, hence why C++/WinRT is on a juggernaut to replace /CX and /CLI as we speak).

https://docs.microsoft.com/en-us/uwp/api

Android SDK, iOS CocoaTouch, and MacOS Cocoa of course each have their own analogous rich object model that Ada is shut out of currently and for the foreseeable future.   “Batteries included” is not the mantra of any Ada compiler for targeting Windows 10 UWP, Windows 10 WPF, Android SDK, iOS CocoaTouch, or MacOS Cocoa.  Until Ada-WinRT came along in recent days, Ada compiler vendors at most provided a thin wrapper around the deprecated Win32; no sane person would pay $1000 per year for •that•.

Re: How to get Ada to ?cross the chasm??

[Shark8]

On Wednesday, April 18, 2018 at 10:01:31 PM UTC-6, Dan'l Miller wrote:
> 
> But any Ada compilers that “support” Microsoft OSes out of the box are stuck in the Win32 era not much different than as shown in that cruel Ada spec above.

What's truly sad is that many APIs would do a *lot* better as Ada than as C or C++, simply because of the addition of aspects and pre/post-conditions. (With the addition of static/disjoint subtypes [see below] following close behind.)

Type Example_Enumeration is ( Steve, Dave, Mary, Alice, Marco, Diana );
Subtype Man is Example_Enumeration
  with Static_Predicate => Men in Steve | Dave | Marco;

Procedure Shave_API( Someone : Man );
-- Or whatever, the point is we can *EASILY* model something like OpenGL's
-- massive list of enumerations, with functions that accept limited subsets.

> What is especially sad is that Microsoft has gone to great lengths over the past 1.5 decades to make this rich object library language agnostic, designed for language projections to feel native in each language—

This is true, but I'm not sure how to address the problem. A lot of it has to do with the limited amount of resources we have to develop Ada, due to our small size, which remains small in part due to the above problem.

Perhaps 95% of "what's holding us back" is the combination of the above [usually expressed as "lack of libraries"] and the compiler/tooling situation.

Re: How to get Ada to ?cross the chasm??

[Dmitry A. Kazakov]

On 19/04/2018 16:28, Shark8 wrote:
> On Wednesday, April 18, 2018 at 10:01:31 PM UTC-6, Dan'l Miller wrote:
>>
>> But any Ada compilers that “support” Microsoft OSes out of the box are stuck in the Win32 era not much different than as shown in that cruel Ada spec above.
> 
> What's truly sad is that many APIs would do a *lot* better as Ada than as C or C++, simply because of the addition of aspects and pre/post-conditions.

Not really, usually API cannot trust them anyway.

Dynamic constraints enforced by the OS via supervisor calls rather than 
embedded in the caller's code might very useful. Unfortunately Ada does 
not have these either.

What is indeed a lot better in Ada is an ability to return an indefinite 
string. Another important thing is default values. Third is protected 
interfaces regardless their severe limitations. API that supports timed 
entry calls is a lot simpler to use.

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

Re: How to get Ada to ?cross the chasm??

[Dan'l Miller]

On Thursday, April 19, 2018 at 9:28:24 AM UTC-5, Shark8 wrote:
> On Wednesday, April 18, 2018 at 10:01:31 PM UTC-6, Dan'l Miller wrote:
> > 
> > But any Ada compilers that “support” Microsoft OSes out of the box are stuck in the Win32 era not much different than as shown in that cruel Ada spec above.
> 
> What's truly sad is that many APIs would do a *lot* better as Ada than as C or C++, simply because of the addition of aspects and pre/post-conditions. (With the addition of static/disjoint subtypes [see below] following close behind.)

This is true.  And it is the kind of value-add that only a human being can perform, given current technology.  Ada-WinRT is a major step in the right direction—and even more so if the code generator were finished & publicly available.  But to truly show off Ada would require manually adding portions of the specification that can only be expressed in Ada (or via formal methods).

> > What is especially sad is that Microsoft has gone to great lengths over the past 1.5 decades to make this rich object library language agnostic, designed for language projections to feel native in each language—
> 
> This is true, but I'm not sure how to address the problem. A lot of it has to do with the limited amount of resources we have to develop Ada, due to our small size, which remains small in part due to the above problem.
> 
> Perhaps 95% of "what's holding us back" is the combination of the above [usually expressed as "lack of libraries"] and the compiler/tooling situation.

Well, yes there is all that from a how-did-we-get-here retrospective perspective.  But perhaps more beneficial is to ask:  why is Rust garnering so much revolutionary energy over there (and Ada far far less so)?  Rust seems to have the angry young turks thing going.  There is that kind of energy.  But from this day forward, Ada needs a very public fire in its belly to attract perhaps a different kind of fervent energy (e.g., more formal methods—more than just SPARKy subsets of Ada; more code-generation-of-Ada harvesting at least interfaces to other languages' vast OO frameworks, such as UWP on Windows 10, Android SDK, CocoaTouch on iOS, Cocoa on MacOS; indeed! harvesting whole codebases of other languages in the fashion of RemObjects' ElementCompiler-confederation's shared-AST among C#, Swift, Java, and ObjectPascal with ObjectPascal being an über-Alles/Eye-of-Sauron central-nexus among the confederation of the other languages into a single compiler).  Ada (plus SPARK and Coq) would be a stronger foundation for being an über-Alles/Eye-of-Sauron language importing, analyzing, and taming isomorphic transliterations of other languages than ObjectPascal is in ElementsCompiler.  Some sort of fire in our belly like that!

Ada needs a new purpose to live a vibrant bigger life, far beyond what Ichbiah and the DoD envisioned in the 1970s.

Re: How to get Ada to ?cross the chasm??

[gautier_niouzes]

There is an alternative to a thin win32 wrapper: GNAT FSF and GWindows ( https://sourceforge.net/projects/gnavi/ ).
Cost 0$.

Re: How to get Ada to ?cross the chasm??

[Dan'l Miller]

On Friday, April 20, 2018 at 11:32:22 AM UTC-5, gautier...@hotmail.com wrote:
> There is an alternative to a thin win32 wrapper: GNAT FSF and GWindows ( https://sourceforge.net/projects/gnavi/ ).
> Cost 0$.

Licensed under GPLv2.  Website offers absolutely no non-GPL/nonviral license for a license fee.  Hence, licensed for use by only copylefted software.  Does not support modern Microsoft era:  WPF, WinRT = UWP, XAML, Windows Store.

Re: How to get Ada to ?cross the chasm??

[gautier.de.montmollin]

Le vendredi 20 avril 2018 19:45:52 UTC+2, Dan'l Miller a écrit :
> On Friday, April 20, 2018 at 11:32:22 AM UTC-5, gautier...@hotmail.com wrote:
> > There is an alternative to a thin win32 wrapper: GNAT FSF and GWindows ( https://sourceforge.net/projects/gnavi/ ).
> > Cost 0$.
> 
> Licensed under GPLv2.  Website offers absolutely no non-GPL/nonviral license for a license fee.
> Hence, licensed for use by only copylefted software.

Actually GWindows is GMGPL (look at the code, the SF page is unaccurate on this point).

> Does not support modern Microsoft era:  WPF, WinRT = UWP, XAML, Windows Store.

That's a big advantage, at least regarding WPF. At the job we are reprogramming a legacy interface that was done with WPF 5 years ago and is desperately slow despite lots of efforts, and the result (after 2 days of development) displays the same thing (actually much more) in 1 second when the WPF version took 1 minute (so, a factor 60).
The lesson: don't get fooled by Microsoft's marketing, especially on products that they don't use themselves!

Re: How to get Ada to ?cross the chasm??

[gautier_niouzes]

Le vendredi 20 avril 2018 19:45:52 UTC+2, Dan'l Miller a écrit :
> > On Friday, April 20, 2018 at 11:32:22 AM UTC-5, gautier...@hotmail.com wrote:
>> > > There is an alternative to a thin win32 wrapper: GNAT FSF and GWindows ( https://sourceforge.net/projects/gnavi/ ).
>> > > Cost 0$.
> > 
> > Licensed under GPLv2.  Website offers absolutely no non-GPL/nonviral license for a license fee.
> > Hence, licensed for use by only copylefted software.
Actually GWindows is GMGPL (look at the code, the SF page is unaccurate on this point).

> > Does not support modern Microsoft era:  WPF, WinRT = UWP, XAML, Windows Store.
That's a big advantage, at least regarding WPF. At the job we are reprogramming a legacy interface that was done with WPF 5 years ago and is desperately slow despite lots of efforts, and the result (after 2 days of development) displays the same thing (actually much more) in 1 second when the WPF version took 1 minute (so, a factor 60).
The lesson: don't get fooled by Microsoft's marketing, especially on products that they don't use themselves!

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

<gautier_niouzes@hotmail.com> wrote in message 
news:aca158b7-8d47-4cbc-a859-a46e2937c7a9@googlegroups.com...
> There is an alternative to a thin win32 wrapper: GNAT FSF and GWindows ( 
> https://sourceforge.net/projects/gnavi/ ).
> Cost 0$.

Or the free version of Claw. (Claw being the library that DB copied to make 
GWindows.)

And of course there is the paid version of Claw, with a usual commercial 
license. http://www.rrsoftware.com/html/prodinf/claw/claw.htm

              Randy.

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:06adad02-803a-4dc7-b5d8-f9a5d8faa3ab@googlegroups.com...
...
>The gargantuan (extraordinarily-useful) object model below is what
>supporting Microsoft Windows 10 looks like nowadays,

...and it will be something completely different in 3-5 years. Because it 
always is. Unless you have 10's of millions of dollars, you simply cannot 
keep up with those changes. We tried and gave up years ago. Aonix (now PTC) 
tried and gave up years ago, too.

Moreover, new software is incredibly ugly and hard to use compared to the 
older stuff. I don't even want to help people write that crap - if that 
leaves me unemployable, so be it.

                              Randy.

Re: How to get Ada to ?cross the chasm??

[Jeffrey R. Carter]

On 04/18/2018 11:03 PM, Niklas Holsti wrote:
> 
> AIUI, making the compiler open-source (maybe even GPL) was a condition in the 
> original government contract that NYU won and which produced the first GNAT.

As I recall, the contract required that

* The compiler implement the entire Ada-95 core language
* The source of the compiler be freely available
* The compiler be freely available
* The compiler be usable to produce proprietary S/W

-- 
Jeff Carter
"I was in love with a beautiful blonde once, dear.
She drove me to drink. That's the one thing I'm
indebted to her for."
Never Give a Sucker an Even Break
109

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Lucretia <laguest9000@googlemail.com> writes:
> This is truly not an argument either. Say someone's deciding whether
> to use C or Ada and there's this sub £/$/€ 1000 compiler for Ada. They
> will just go with C, because there's a fucking C compiler everywhere
> for nothing. Seriously, look at how many C compilers there actually
> are. There's loads of em, all free.

There's also non-free C compiler vendors like Rowley and Green Hills
doing good business.  I don't like anti-GPL whining as a matter of
principle (if someone can't handle the GPL because they want to write
non-free software, why do they expect a compiler vendor to give away the
store?) but I do sympathize with the issue that GNAT Pro is quite
expensive.  So I'm supportive of a $1K-ish product.  I can tell you even
as an unfunded developer, that $1K wouldn't be enough to sway a language
choice for a serious project ($25K is maybe another matter).

I was in some discussions with a hardware guy about an embedded project
a while back.  The compiler possibilities were:

   - a couple of commercial Forth compilers that were around $1500 for a
     one-time perpetual license with 1 year of maintenance, plus some
     annual fee if you wanted updates.  The hardware guy liked these
     compilers because they had good support for embedded development
     and he liked the language.

   - Any of a number of free Forth implementations.  This might have
     been workable.  It would have been used just for low level stuff by
     the hardware guy.  The higher level stuff would be written by me
     and I was interested in using Ada for that.
     
   - GNAT Pro (something like $25K).  We would have needed outside
     funding for this, or anyway some revenue from selling the product.
     $1500 would have been a heck of a lot more doable.

   - Gnat GPL -- I (as the software guy) was ok with this.  The goal was
     to sell a hardware product, and given its target market, releasing
     its internal software under GPL would actually have helped sell it.

   - GNAT FSF - didn't really think about this since I didn't feel like
     we needed to hold the code back.

   - GCC or some other C or C++ compiler - I was interested in Ada
     because of stronger safety properties, but in practice this might
     have worked out ok.  Rust wasn't really a consideration.

   - interpreted language du jour: didn't really consider at the time,
     but probably should have.  Even low powered embedded cpus can run
     them acceptably now.  

Re: How to get Ada to ?cross the chasm??

[Simon Wright]

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

> Also, as far as I can see (and I am willing to be corrected here if I
> am wrong) it means that you can't even write a library in Ada under
> something other than the GPL if you are going to use the Community
> version. As soon as you compile the library source with the Community
> version, it falls under the GPL and hence any software using your
> library also falls under the GPL.

There are a host[1] of licenses compatible with the GPL.

And, in any case, the fact that you compiled your library with the GNAT
CE makes no difference if you provide me wih the source and I use FSF
GNAT (or Janus, for example) to compile it myself.

I think that Dan'l's remarks about the GCC Runtime Library Exception vs
LGPL may have some force. The libraries I've worked with have been
mainly concerned with code that's intimately bound up with the compiler,
so the RLE is a no-brainer; otherwise, perhaps LGPL or maybe the BSD
3-clause license[2] (which is what AdaCore have used for their Ada Drivers
Library[3]).

[1] https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
[2] https://directory.fsf.org/wiki/License:BSD_3Clause
[3] https://github.com/AdaCore/Ada_Drivers_Library

Re: How to get Ada to ?cross the chasm??

[Dan'l Miller]

On Wednesday, April 18, 2018 at 9:36:12 AM UTC-5, Simon Wright wrote:
> Simon Clubley writes:
> 
> > Also, as far as I can see (and I am willing to be corrected here if I
> > am wrong) it means that you can't even write a library in Ada under
> > something other than the GPL if you are going to use the Community
> > version. As soon as you compile the library source with the Community
> > version, it falls under the GPL and hence any software using your
> > library also falls under the GPL.
> 
> There are a host[1] of licenses compatible with the GPL.
> ...
> [1] https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses

Well, not so fast.  Clubley's “fall under” is correct.  Although Wright is narrowly correct, the narrowness of the precise correctness of “compatible with” is highly misleading.

How many months have 28 days?  The narrowly-precise correct answer is:  all of them.  This style of mathematically-narrow correctness is what is at play here with “compatible with the GPL”.  The best correct answer is of course to transparently answer both interpretations in one fell swoop:  all of them and only February on non-leap-years.

https://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean

GNU's “compatible with the GPL” can very easily be misinterpreted.  First let's consider licenses that are incompatible with the GPL.  If you statically link GPLed object code with, say, Microsoft EULAed object code, you have prima-facie violation of the GPL right from the git-go:  you cannot release the source code for the EULAed software, because (even if you have the source) the EULA prohibits publicly releasing the EULAed source code.

Next let's consider licenses that are deemed “compatible” with the GPL but that lack the copyleft demand to released source code.  Let's take, say, the Boost Software License (BSL).  Normally, if you modify Boost source code, you are not compelled in any legal way to release those modified lines of source code to anyone.  But if you statically link that BSLed object code with GPLed object code, you have the •opportunity• to do what the GPL absolutely requires:  release your modifications to the Boost source code publicly.  You don't have a prima-facie violation of the GPL yet, hence BSL is so-called “compatible” with the GPL.  You only violate the copyleft provisions of the GPL if you of your own volition refuse to publicly release your modifications to the BSLed source code; hence it was not the BSL that was the root cause of the violation of the GPL's terms; hence the BSL is compatible with the GPL's copyleft terms.

(Note that there exist other license-of-other-code mechanisms of being prima facie in violation of the GPLv3 right from the git-go (e.g., patents; prohibitions on reverse engineering); thus there exist other ways of a license being incompatible with the GPL.  I am simply utilizing the copyleft's demand to publicly release the source code as the most-often-encountered example, and the one that Clubley was mentioning above.)

Clubley's “fall under” more accurately captures what is going on here.  “Falls under” does •not• mean:  all licenses of statically-linked object code are retroactively retexted as now GPL itself, requiring new licensing text to be issued by the original copyright holder(s).  Clubley's “falls under” ••does in fact•• mean:  the copyleft terms of the GPL apply to nonGPLed object code that was statically linked to the GPLed code, which is clearly the meaning that Clubley was intending to convey:  the not-originally-copylefted source code becomes copylefted here by its object code being statically linked with copylefted-from-the-git-go object code.  Colloquially, this transitivity of spread of the copyleft's demand for public release of source code of not-otherwise-copylefted source code is what is termed ‘viral’ pejoratively.

(Btw, I limit these examples to static linking within an executable.  1) Dynamic linking GPLed code to an otherwise not-copylefted executable and 2) dynamic linking not-copylefted object code to an otherwise GPLed executable both require vastly more detailed analysis of precisely how the dynamic linking transpired and what knew what about the interfaces across that boundary, which even gets into the thorny topic of the Oracle-v.-Google case of whether declarations of subroutines can be copyrighted, and if they can, what is and is not fair-use of those declarations of subroutines.  The vast majority of the time [e.g., not LGPL; the executable being the link-loader rather than the OS; the interface across the DLL is parameterless procedure with no string identifier name such as indexing into an array of addresses where that array starts at a well-known address]—the DLL case is almost exactly the same as the statically-linked case regarding the spread of the copyleft's release-the-source-code demand to otherwise not-otherwise-copylefted object code and thus to its not-otherwise-copylefted source code.)

Re: How to get Ada to ?cross the chasm??

[Lucretia]

On Wednesday, 18 April 2018 16:56:47 UTC+1, Dan'l Miller  wrote:

> > There are a host[1] of licenses compatible with the GPL.
> > ...
> > [1] https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
> 
> Well, not so fast.  Clubley's “fall under” is correct.  Although Wright is narrowly correct, the narrowness of the precise correctness of “compatible with” is highly misleading.

Compatible licenses aren't the issue here. Ada is already a minority language, it's going nowhere until people stop putting libs under GPL, because people won't or can't use them for anything closed source - there are still some industries where software is closed source.

Re: How to get Ada to ?cross the chasm??

[Simon Clubley]

On 2018-04-18, Simon Wright <simon@pushface.org> wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>
>> Also, as far as I can see (and I am willing to be corrected here if I
>> am wrong) it means that you can't even write a library in Ada under
>> something other than the GPL if you are going to use the Community
>> version. As soon as you compile the library source with the Community
>> version, it falls under the GPL and hence any software using your
>> library also falls under the GPL.
>
> There are a host[1] of licenses compatible with the GPL.
>

That list appears to be the list of various non-GPL licences which you
can use in a program which has been licenced under the GPL.

I am talking about the opposite problem which is when a library which
is GPL licenced is used in a program which is not GPL licenced.

In that case, you cannot change the GPL licence to, say, LGPL or MIT,
and the program itself falls under the GPL as a result of linking
against the GPL library.

> And, in any case, the fact that you compiled your library with the GNAT
> CE makes no difference if you provide me wih the source and I use FSF
> GNAT (or Janus, for example) to compile it myself.
>

That bit is true but it means you cannot supply pre-packaged libraries
using the Community version and it means you have to write your code
with the limitations of the other compilers in mind.

It also means you cannot supply a binary only version of the library
so it cannot be used in various commercial situations.

>
> [1] https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses

Simon.

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

Re: How to get Ada to ?cross the chasm??

[invalid]

On 2018-04-18, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2018-04-18, Simon Wright <simon@pushface.org> wrote:
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
> It also means you cannot supply a binary only version of the library
> so it cannot be used in various commercial situations.

The socialists will answer that by saying yes you can, you just have to
provide the source. RedHat, etc. Blah, blah, blah.

Bad socialists! Bad!

I can't wait for the day Stallman keels over and the FSF fanboys have to get
real jobs. %^*!

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 
message news:pb7vm8$860$1@dont-email.me...
...
> That bit is true but it means you cannot supply pre-packaged libraries
> using the Community version and it means you have to write your code
> with the limitations of the other compilers in mind.

Which is a good idea in any case. Portable Ada code >> Ada code that works 
only with one compiler.

                      Randy.

Re: How to get Ada to ?cross the chasm??

[Lucretia]

On Wednesday, 18 April 2018 13:44:04 UTC+1, Simon Clubley  wrote:

> Oh, and it's not "one sided", it's called giving the Ada community
> a dose of cold reality. You can talk about the advantages of Ada all
> you want but Ada's advantages mean nothing until the Ada compiler
> situation matches the compiler situation for other languages.

Yup.
 
> Any compiler which imposes the GPL on any software developed using
> it would be absolutely dead on arrival in many environments especially
> when compilers for other languages are available for free which do
> not impose such constraints.

Exactly!
 
> GPL based software development is a small subset of all the software
> development out there.
> 
> Also, as far as I can see (and I am willing to be corrected here if
> I am wrong) it means that you can't even write a library in Ada under
> something other than the GPL if you are going to use the Community
> version. As soon as you compile the library source with the Community
> version, it falls under the GPL and hence any software using your
> library also falls under the GPL.

Exactly right. Also, people who write a library and then open it under pure GPL are basically making sure that work will go to waste as nobody is going to use that, no company's will use it, unless they can afford to pay for the alternative license, if it actually has one.
 
> In order to create an Ada library with a LGPL or MIT licence
> (for example), you have to fall back to the FSF version which
> does not have that constraint.

Which is also behind on patches from the maintainers, it's even the GPL version which is itself behind the Pro version.

Luke.

Re: How to get Ada to ?cross the chasm??

[Simon Wright]

Lucretia <laguest9000@googlemail.com> writes:

> On Wednesday, 18 April 2018 13:44:04 UTC+1, Simon Clubley  wrote:

>> Also, as far as I can see (and I am willing to be corrected here if
>> I am wrong) it means that you can't even write a library in Ada under
>> something other than the GPL if you are going to use the Community
>> version. As soon as you compile the library source with the Community
>> version, it falls under the GPL and hence any software using your
>> library also falls under the GPL.
>
> Exactly right.

Well, no: see "Can I use GPL-covered editors such as GNU Emacs to
develop nonfree programs? Can I use GPL-covered tools such as GCC to
compile them?" at
https://www.gnu.org/licenses/gpl-faq.html#CanIUseGPLToolsForNF

It's the runtime that does it.

Re: How to get Ada to ?cross the chasm??

[Simon Clubley]

On 2018-04-18, Simon Wright <simon@pushface.org> wrote:
> Lucretia <laguest9000@googlemail.com> writes:
>
>> On Wednesday, 18 April 2018 13:44:04 UTC+1, Simon Clubley  wrote:
>
>>> Also, as far as I can see (and I am willing to be corrected here if
>>> I am wrong) it means that you can't even write a library in Ada under
>>> something other than the GPL if you are going to use the Community
>>> version. As soon as you compile the library source with the Community
>>> version, it falls under the GPL and hence any software using your
>>> library also falls under the GPL.
>>
>> Exactly right.
>
> Well, no: see "Can I use GPL-covered editors such as GNU Emacs to
> develop nonfree programs? Can I use GPL-covered tools such as GCC to
> compile them?" at
> https://www.gnu.org/licenses/gpl-faq.html#CanIUseGPLToolsForNF
>
> It's the runtime that does it.

Technically yes, but in practice very few people are going to write
a new runtime. Most people are going to say "to hell with this" and
just use another language...

This means that in practical terms, saying "the Community version does
impose the GPL on any programs compiled with it" is correct.

Simon.

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

Re: How to get Ada to ?cross the chasm??

[Jeffrey R. Carter]

On 04/18/2018 02:44 PM, Simon Clubley wrote:
> 
> Also, as far as I can see (and I am willing to be corrected here if
> I am wrong) it means that you can't even write a library in Ada under
> something other than the GPL if you are going to use the Community
> version. As soon as you compile the library source with the Community
> version, it falls under the GPL and hence any software using your
> library also falls under the GPL.

This is not true (or wasn't the last time I read the GPL). It says that if you 
distribute binaries created with GPLed S/W, that you must also make the full 
sources available under the GPL. If you don't distribute anything, then it 
doesn't matter if you use GPLed S/W. If you distribute source code, then your 
code is only required to fall under the GPL if it's derived from GPLed S/W. Only 
if you distribute binaries can your choice of compiler cause your code to fall 
under the GPL.

-- 
Jeff Carter
"[T]he Musgroves had had the ill fortune
of a very troublesome, hopeless son, and
the good fortune to lose him before he
reached his twentieth year ..."
Persuasion
154

Re: How to get Ada to ?cross the chasm??

[invalid]

On 2018-04-18, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2018-04-17, Mehdi Saada <00120260a@gmail.com> wrote:
>> I have trouble believing that Adacore (free) forbid completely selling
>> softwares in other licenses as GPL or the likes of. I have no technical
>> knowledge of these things, but I feel like  your points of view are a
>> bit... one sided ?
>
> Adacore force the GPL on any software developed using the Community
> version. See

And it's all based on Robert Dewar's work that was paid for by U.S. grants
funded by American Tax Dollars. The guy was a genius in more ways than one.

This situation is not just bad, it's offensive.

> In order to create an Ada library with a LGPL or MIT licence
> (for example), you have to fall back to the FSF version which
> does not have that constraint.

Which is really OK, but the fact basically only one compiler is available to
people (not corporations) who want to develop in Ada is a very bad
situation, indeed.

Re: How to get Ada to ?cross the chasm??

[Simon Wright]

invalid <address@is.invalid> writes:

> And it's all based on Robert Dewar's work that was paid for by
> U.S. grants funded by American Tax Dollars. The guy was a genius in
> more ways than one.
>
> This situation is not just bad, it's offensive.

Pretty sure that GCC was chosen for entirely practical reasons (who in
government would want to pay to re-write multiple code generators from
scratch?) which meant GPL.

Re: How to get Ada to ?cross the chasm??

[invalid]

On 2018-04-18, Simon Wright <simon@pushface.org> wrote:
> invalid <address@is.invalid> writes:
>
>> And it's all based on Robert Dewar's work that was paid for by
>> U.S. grants funded by American Tax Dollars. The guy was a genius in
>> more ways than one.
>>
>> This situation is not just bad, it's offensive.
>
> Pretty sure that GCC was chosen for entirely practical reasons (who in
> government would want to pay to re-write multiple code generators from
> scratch?) which meant GPL.

Not sure why you brought gcc into the discussion, and at one time I knew
more about the history of gnat than I can remember now. I must have blocked
it out. As you remember gnat 3.15p was not GPL and still had the full
runtime exemption. Whether Adacore is GPL or not (and it is somehow not for
the companies that buy *cough* support for it *cough*) is not related to
using gcc.

Re: How to get Ada to ?cross the chasm??

[Simon Wright]

invalid <address@is.invalid> writes:

> On 2018-04-18, Simon Wright <simon@pushface.org> wrote:
>> invalid <address@is.invalid> writes:
>>
>>> And it's all based on Robert Dewar's work that was paid for by
>>> U.S. grants funded by American Tax Dollars. The guy was a genius in
>>> more ways than one.
>>>
>>> This situation is not just bad, it's offensive.
>>
>> Pretty sure that GCC was chosen for entirely practical reasons (who
>> in government would want to pay to re-write multiple code generators
>> from scratch?) which meant GPL.
>
> Not sure why you brought gcc into the discussion, and at one time I
> knew more about the history of gnat than I can remember now. I must
> have blocked it out. As you remember gnat 3.15p was not GPL and still
> had the full runtime exemption.

I brought GCC into the discussion because GNAT uses the GCC back-end for
the actual code generation as it has always done.

I just downloaded 3.15p sources (from Sourceforge; google it if you
want) and the compiler was, as it is now, pure GPL. From
e.g. par-ch2.adb,

--          Copyright (C) 1992-2002 Free Software Foundation, Inc.          --
--                                                                          --
-- GNAT is free software;  you can  redistribute it  and/or modify it under --
-- terms of the  GNU General Public License as published  by the Free Soft- --
-- ware  Foundation;  either version 2,  or (at your option) any later ver- --
-- sion.  GNAT is distributed in the hope that it will be useful, but WITH- --

etc. The runtime sources were GPLv2 with the GMGPL exception; just as
now for supported or FSF releases they have the GCC Runtime Library
exception.

>                            Whether Adacore is GPL or not (and it
> is somehow not for the companies that buy *cough* support for it
> *cough*) is not related to using gcc.

I don't know what snarky point you're trying to make with your
coughing. Seems pretty invalid to me, like your username.

Re: How to get Ada to ?cross the chasm??

[Olivier Henley]

Personally I really appreciate having quality staff (AdaCore) maintaining the heavy stuff. All the work they do to polish, update, fix, bring new projects to the ecosystem is great and has to be paid somehow. 

I would be quite happy with a "proportional royalties" model. Everyone uses the pro version and pay a ratio of their product profitability (say 1-5%).

The Unreal game engine enforce such a deal. You do not make money, you owe nothing, you do money building on others work, you owe to others.

Re: How to get Ada to ?cross the chasm??

[briot.emmanuel]

> Adacore force the GPL on any software developed using the Community
> version. See


Correct me if I am wrong, but basically your message is:

<<<
I want to make money selling my software, but I certainly don't want to pay anything to any other software provider for this. They should all give me for free what I need.
>>>

Does your own software even have a free version somewhere ? If yes, then your message becomes much more consistent, otherwise please reconsider your own policy.

Re: How to get Ada to ?cross the chasm??

[Maciej Sobczak]

> Correct me if I am wrong, but basically your message is:
> 
> <<<
> I want to make money selling my software, but I certainly don't want to pay anything to any other software provider for this. They should all give me for free what I need.
> >>>

Not necessarily. The message might be as well:

<<<
I want to make money selling my software, and I have *tons* of free solutions to build upon. In such an rich (pun intended) ecosystem, I do not need to consider anything that does not fall into this group. Heck, there is so much of everything, that I don't even have time to consider everything that is free, so why bother considering something that is not free?
>>>

> Does your own software even have a free version somewhere ?

It does not need to. Very likely somewhere there is already a free version of the same thing, anyway. Which means that most likely it is not the software that he is selling [this is actually very important].

> If yes, then your message becomes much more consistent

It is very consistent already. The guy needs free bricks to build his system and he will get them. Because there are so many of them to choose from. You might argue that Ada is better, but in order to understand why it is better he needs to invest his time, which involves a certain cost with UNcertain return. It's even worse - he would need to invest his time, so that you can convince him to later invest his money into your compiler. This is double cost then. In the world where so many things are *free* *now*, this just does not make any sense.
That's why he is not your future customer.

The days of paid compilers are over.

Disclaimer: I have described the reality, not preached it.

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

Re: How to get Ada to ?cross the chasm??

[Lucretia]

On Friday, 20 April 2018 09:16:16 UTC+1, briot.e...@gmail.com  wrote:

> Correct me if I am wrong, but basically your message is:
> 
> <<<
> I want to make money selling my software, but I certainly don't want to pay anything to any other software provider for this. They should all give me for free what I need.
> >>>

Not if that person is also giving stuff away for free that others can and do use, especially people who provide that compiler. Seems like a fair trade to me.
 

Re: How to get Ada to ?cross the chasm??

[invalid]

On 2018-04-20, briot.emmanuel@gmail.com <briot.emmanuel@gmail.com> wrote:
>
>> Adacore force the GPL on any software developed using the Community
>> version. See
>
>
> Correct me if I am wrong, but basically your message is:
>
><<<
> I want to make money selling my software, but I certainly don't want to pay anything to any other software provider for this. They should all give me for free what I need.
>>>>
>

Can't speak for the guy you're quoting but I understood his comments had to
do with the lousy compiler situation for Ada. Most individual developers who
don't have a product to ship _today_ cannot afford the multiple tens of
thousands of dollars it costs to buy support for Adacore's publicly funded
goldmine.

And there are not any other affordable compilers for Ada for people who
_are_ willing to pay a reasonable price. Intel sells pretty good Fortran and
C/C++ compilers for about USD 1.250.

The compiler situation today is bad overall, not just for Ada. But it's
particularly bad for Ada.

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"invalid" <address@is.invalid> wrote in message 
news:slrnpdpiv9.ntv.address@is.invalid...
> On 2018-04-20, briot.emmanuel@gmail.com <briot.emmanuel@gmail.com> wrote:
...
> And there are not any other affordable compilers for Ada for people who
> _are_ willing to pay a reasonable price. Intel sells pretty good Fortran 
> and
> C/C++ compilers for about USD 1.250.

What's affordable? The Janus/Ada Personal Edition is still $195 (including 3 
months of support). I don't know the PTC pricelist these days, but they used 
to have ObjectAda versions under $1K.

If you are in the Ada = GNAT camp, well, your out of luck and probably ought 
to be. ;-)

                     Randy.

Re: How to get Ada to ?cross the chasm??

[Dan'l Miller]

On Wednesday, April 25, 2018 at 6:41:07 PM UTC-5, Randy Brukardt wrote:
> "invalid" wrote in message 
> news:slrnpdpiv9.ntv.address@is.invalid...
> > On 2018-04-20, briot.emmanuel wrote:
> ...
> > And there are not any other affordable compilers for Ada for people who
> > _are_ willing to pay a reasonable price. Intel sells pretty good Fortran 
> > and
> > C/C++ compilers for about USD 1.250.
> 
> What's affordable? The Janus/Ada Personal Edition is still $195 (including 3 
> months of support).

I am willing to pay $195 annually for Ada2012 per target-OS per target-ISA for all of the following:
1) 64-bit Apple ARM for iOS (e.g., MacOS-hosted cross-compiler), which would require an LLVM-backend to permit the proper files to be generated to permit using LLVM's debugger on Apple iDevices)
2) 64-bit AMD64 for MacOS
3) 64-bit AMD64 for Windows 10
4) 64-bit Samsung Exynos ARM for Android native-processor (not JVM) (e.g., either Linux- or MacOS- or Windows10-hosted cross-compiler)

All or nothing on those 4, because I am interested in portability of Ada to put an end to needing to write C# or C++/CX on Windows 10, Swift or Objective-C(++) on iOS & MacOS, and Java or Kotlin on Android.  Where do I send my four times $195 = $780 check today?

Indeed, I am willing to double the money to support 32-bit on those platforms, even though increasingly 32-bit legacy app support is unfortunately becoming a moot point on some of those platforms.  So any Ada compilers available for all 8 {OS, ISA} targets for $1560?

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:487851e9-69aa-43be-a3a7-39eaf9687fc0@googlegroups.com...
...
>Indeed, I am willing to double the money to support 32-bit on those 
>platforms,
>even though increasingly 32-bit legacy app support is unfortunately 
>becoming
>a moot point on some of those platforms.  So any Ada compilers available 
>for
>all 8 {OS, ISA} targets for $1560?

The 64-bit platforms haven't been created yet. The majority of programs 
don't need the extra address space (of course, if you have to interface to 
something 64-bit, that's moot) and the extra size cost is substantial (which 
matters to a compiler that was always designed with the space used as the #1 
criteria).

In any case, I'd love to do the Linux runtime and the x64 code generator 
(code generators are fun and rewarding in a way that hardly any other parts 
of a compiler are -- there's a reason I never let anyone else work on 
those). I just need some other source of income so I'd have the time. :-)

I'd guess that any new platforms would be priced differently (probably more 
$$ with a longer built-in support period); my intent was to move in the 
direction of nearly free acquistion and significant support fees (since that 
is where the work - and renewals - are).

                      Randy.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
>> C/C++ compilers for about USD 1.250.
> What's affordable? The Janus/Ada Personal Edition is still $195

Part of the thread context is that people want Ada 2012 and they want
SPARK.  Janus Ada doesn't yet support Ada 2012 although I guess you
could use SPARK as an external verifier for Janus's Ada 95.

Also, on the rrsoftware.com site I don't see Janus Ada offered for
anything but desktop computers.  There's an unpursued opportunity in
embedded targets ;-).  Seriously, that's how companies like Rowley
(rowley.co.uk) make a living.  They don't try to compete with GCC on the
desktop.  I don't know if Rational has any development budget these
days, but embedded is an area where Janus Ada could really do some good.

> Why do that work even if you have those those requirements? That's the
> beauty of Ada -- one can get static checking for essentially free from
> well-designed code.

Well, the discussion was about using SPARK to prove much more
complicated assertions.  I agree that a decent type system is a big help
but a proof system goes a lot further.  You can think of a proof system
as a type system that is Turing complete.  That means you can verify
arbitrarily complex properties of a program, but (just like when you
proved theorems in math class) it's a lot of work, whose cost might or
might not be justified, depending.

> That might work for integers, but for real numbers such math has very
> different characteristics and rules than the "usual" math.

Definitely true, but a completely separate topic.  

> I assume you don't care much about software quality, because testing alone
> proves absolutely nothing.

Oh come on, that's a platitude.  Testing (if any tests pass) proves that
the program works at least some of the time.  Careful testing proves (or
anyway gives good confidence) that the program works most of the time.
The actual meaning of your platitude is that testing can't prove that
the program never fails, so you have to think about your application's
failure tolerance.

If failure of the program can injure or kill someone, then as
enlightenment philosophers and proof geeks we can say you need formal
verification.  Almost any other type of failure boils down to your
losing some money (in many cases just the cost of releasing a fix).
Deciding whether to deploy the software (and how much to spend on
testing and/or verification) can then be seen as a betting proposition,
where you evaluate likely costs, probabilities, etc., and make a
rational choice.

> I don't even bother anymore on most of my code; if it runs, it works
> (or at least, it is assumed to work).

Heh, are you telling me that Janus Ada has never been tested?  Which one
of us did you say doesn't care about software quality?  ;-)

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87k1su7nag.fsf@nightsong.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>>> C/C++ compilers for about USD 1.250.
>> What's affordable? The Janus/Ada Personal Edition is still $195
>
> Part of the thread context is that people want Ada 2012 and they want
> SPARK.  Janus Ada doesn't yet support Ada 2012 although I guess you
> could use SPARK as an external verifier for Janus's Ada 95.

It does support a small amount of Ada 2012 (aspects and libraries), and if I 
wasn't answering these sorts of messages, it probably would be supporting 
more. ;-)

> Also, on the rrsoftware.com site I don't see Janus Ada offered for
> anything but desktop computers.  There's an unpursued opportunity in
> embedded targets ;-).  Seriously, that's how companies like Rowley
> (rowley.co.uk) make a living.  They don't try to compete with GCC on the
> desktop.  I don't know if Rational has any development budget these
> days, but embedded is an area where Janus Ada could really do some good.

We offer embedded kits, but those are much higher priced because of the 
greatly increased support requirements. (There is no such thing as an 
out-of-the-box embedded deployment, at least not commercially.) We used to 
have a number of customers on the 16-bit versions of that (mostly 
programming 186 chips), but those moved to other development systems when 
the 186 hardware was retired. Since then, I don't think anyone has even 
asked about it. (And of course any such system has to run on a desktop.)

My goal from the very beginning was to bring structured, strongly typed 
programming to anyone needing to program. That hasn't changed, even though 
the programs have. These days, I'd expect Ada's biggest contribution 
(outside of embedded, an area that is well-covered by others) to be on 
(possibly distributed) server-side programs in client-server environments. 
The client should be very thin so Ada doesn't have much to offer there 
(unless you use Gnoga on the server and have no separate client at all).

>> Why do that work even if you have those those requirements? That's the
>> beauty of Ada -- one can get static checking for essentially free from
>> well-designed code.
>
> Well, the discussion was about using SPARK to prove much more
> complicated assertions.

Again, why?

>  I agree that a decent type system is a big help
> but a proof system goes a lot further.  You can think of a proof system
> as a type system that is Turing complete.  That means you can verify
> arbitrarily complex properties of a program, but (just like when you
> proved theorems in math class) it's a lot of work, whose cost might or
> might not be justified, depending.

I'm not interested in a separate proof system, nor are most users 
interested. But a compiler does a lot of that stuff already (especially in 
the optimizer), and moreover, every Ada compiler does a lot of work to 
eliminate unneeded checks. It's not much of a leap to turn this into static 
checking in many cases (they'd have to be warnings in the Ada scheme of 
things, but that's not an real issue, since many compilers have 
warnings-are-errors as a standard mode).

The beauty of this is that it allows people to ease into the checking of 
Ada, starting just with the type system and built-in checks, then adding 
subtypes with ranges, null exclusions, and eventually graduating to full use 
of Pre/Post and  predicates. That's in part how I learned to love Ada; the 
longer I use it the more new ways I find to get Ada to do some of the 
checking for me.

It's hard as heck to get people to change everything about their programming 
experience at once. Starting programmers out writing better-C-in-Ada-syntax 
and gradually letting them find about the other benefits that they can have 
is the way to hook them for life. (Although that often requires getting 
through to clueless management.)

...
>> I assume you don't care much about software quality, because testing 
>> alone
>> proves absolutely nothing.
>
> Oh come on, that's a platitude.  Testing (if any tests pass) proves that
> the program works at least some of the time.  Careful testing proves (or
> anyway gives good confidence) that the program works most of the time.
> The actual meaning of your platitude is that testing can't prove that
> the program never fails, so you have to think about your application's
> failure tolerance.

I don't really consider that testing. Moreover, modern programs almost 
completely defy the ability to be tested in any systematic way (see below).

...
>> I don't even bother anymore on most of my code; if it runs, it works
>> (or at least, it is assumed to work).
>
> Heh, are you telling me that Janus Ada has never been tested?  Which one
> of us did you say doesn't care about software quality?  ;-)

Janus/Ada is the exception -- I said "most". ;-)

Even for Janus/Ada, I've long since given up on unit testing. Unit testing 
only works if it is run in a known environment (symbol table, source trees, 
etc.) Setting up that environment is a huge undertaking. Or you could just 
compile a targetted test program and all of that happens essentially for 
free.

So testing Janus/Ada is using a large suite of tests (about 1400 tests plus 
the ACATS) to get reproduceable results. One can use tools to flag unusual 
results and essentially automate the process -- it takes about 4 hours to 
run these days (the early ACATS used to take 7 days to run on an early IBM 
PC -- machines have come a long way).

But GUI programs are almost untestable in any repeatable way. I tried a 
number of tools to get repeatability, but they really didn't scale because 
the models would break every time something new got added. Maintaining the 
tests was more work than writing the program. (Most them are just 
maintaining configuration files anyway, so there is almost nothing else to 
test.)

And as far as the servers go (web and mail), reproducible testing requires a 
stream of input. That's also a pain to create. So for most testing, I simply 
field them and let the Internet provide the stream of data. (I'm sane enough 
to keep the previous version around in case the new one turns out to be a 
brick, which happens more often than I care to admit.) I trust that the 
strong Ada error recovery and logging facilities will let me find any 
problems quickly, and usually without impacting most transactions. 
(Worst-case is a short-term denial of service.)

That works in all of those cases because Ada detects a lot of problems at 
compile-time or runtime, so very little could happen that would actually be 
dangerous. (Obviously, if I was a bank, I might need to take a different 
approach.)

                        Randy.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> We offer embedded kits, but those are much higher priced because

If they are in the $1K-$2K range, that's competitive with the C and
Forth products that I mentioned.  If they're much above that, people
will be thinking about GNAT Pro.

> moved to other development systems when the 186 hardware was retired.
> Since then, I don't think anyone has even asked about it. (And of
> course any such system has to run on a desktop.)

If you've got a reasonable ARM target that supports some common dev
boards, you're doing good, and should advertise that on your site.

> These days, I'd expect Ada's biggest contribution (outside of
> embedded, an area that is well-covered by others) to be on (possibly
> distributed) server-side programs in client-server environments.

I just don't see this.  I hear about Gnoga but it seems like a case of
using Ada for the sake of using Ada.  If someone wants an old-fashioned,
statically typed imperative language for server side apps, they're far
more likely to use Java.  It might be convincing ("crossing the chasm")
to replace some of the traditional C infrastructure (nginx might be a
good place to start) with Ada, but only if you can come close to the old
stuff's performance.  Or preferably, beat the old stuff's performance
outright.

I couldn't imagine writing a substantial server app entirely in Ada.  I
could see writing some critical subsystems in Ada and my interest in Ada
is partly motivated by that idea.  Embedded seems a lot more promising.

>> Well, the discussion was about using SPARK to prove much more
>> complicated assertions.
> Again, why?

You'd have to ask the folks who started the thread ;).  But
https://www.dwheeler.com/essays/high-assurance-floss.html
is a nice overview of why approaches like SPARK are interesting.

> It's hard as heck to get people to change everything about their
> programming experience at once. Starting programmers out writing
> better-C-in-Ada-syntax and gradually letting them find about the other
> benefits that they can have is the way to hook them for life.

I think convincing C programmers to switch to Ada won't help "cross the
chasm" even if 100% successful.  C was a 1980's thing and there aren't
that many programmers using it any more.  Lots of terrifically good
programmers these days have never written a line of C in their lives.
The starting point is very often either Javascript on the web side, or
something like Python on the computational side.  Then if they want
types, there is Java, Scala, Ocaml, Haskell, etc.  IMHO Ada's advantages
over those languages, for applications that need it, are more in the
area of runtime determinism (e.g. manual memory management) than types.
And I think that's important only in a fairly small class of
expectations.  Maybe I'm wrong, but I don't see a breakout.

> But GUI programs are almost untestable in any repeatable way.

Eh?  Of course they're not.  You produce a GUI event stream similar to
what an actual user would produce, and check that the program does the
right thing.  There are many tools for this.

> That works in all of those cases because Ada detects a lot of problems
> at compile-time or runtime, so very little could happen that would
> actually be dangerous.

I guess it depends what you are trying to do.

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87po2la2qt.fsf@nightsong.com...
...
> Maybe I'm wrong, but I don't see a breakout.

I haven't seen any chance of a breakout since 1990. I just want the ability 
to do the right thing for pretty much everyone who programs. History says 
that they'll ignore it anyway, and that none of it will matter anyway when 
the robots slaughter us all. :-)

>> But GUI programs are almost untestable in any repeatable way.
>
> Eh?  Of course they're not.  You produce a GUI event stream similar to
> what an actual user would produce, and check that the program does the
> right thing.  There are many tools for this.

I answered that in the next sentence. Those "streams of events" are only 
usable when there is no significant change to the GUI from when the test was 
created. Move a button or menu entry and the test has to be built all over 
again.

Building tests is hard in general, and doing so more than once is a 
non-starter. (There's a reason that the ACATS is such a big deal to Ada 
developers.)

>> That works in all of those cases because Ada detects a lot of problems
>> at compile-time or runtime, so very little could happen that would
>> actually be dangerous.
>
> I guess it depends what you are trying to do.

Absolutely. I wouldn't want to do this with banking software or an auto 
safety system, but as you previously said, most software isn't going to kill 
or main or bankrupt someone. Nothing I've done ever has been in that 
category, and I doubt that will change.

                             Randy.

Re: How to get Ada to ?cross the chasm??

[Jacob Sparre Andersen]

Paul Rubin wrote:

> I couldn't imagine writing a substantial server app entirely in Ada.

Why not?  (That's what I spend most of my time doing.)

One of the two projects I'm working on now is already ~1M lines of Ada
in the server.

The other one is starting up, and will contain a mix of Ada, R and
Python to cater to the preferences of the project participants.  The R
and Python parts will be carefully shielded from the users and the
internet by the Ada part.

Greetings,

Jacob
-- 
"For there are only two reasons why war is made against a
 republic: The one, to become lord over her: the other, the
 fear of being occupied by her."       -- Nicolo Machiavelli

Re: How to get Ada to ?cross the chasm??

[patrick]

Hi Everyone

I was having trouble reading this thread so I thought I would print it, bad idea! It's already 46 pages.

I want to weigh in on this.

For those who don't know me. I studied Ada everyday in 2012. I bought or printed 53lbs of Ada books. I failed. After 1 year, I just couldn't write the software I wanted to write in Ada and I basically moved on.

While I hope to change this in late 2018 early 2019, I am not a professional program, I make my living repairing and/or reselling scientific instruments, please keep this in mind.

I am very grateful for all the help I received in 2012 and I still want to use Ada.

I have some things to say and this is only meant as CONSTRUCTIVE criticism.

Instead of talking about how to get Ada over the Chasm, could we stop for a moment and talk about who has already made it over the chasm and is eating Ada's lunch. I believe this to be largely C++ with a bit of Java perhaps.

C++ is huge and it is complicated, much like Ada but IMHO, there is no comparison between the two. Indeed Barnes, said "ease yourself into the language" and this can be done. Can it with Ada? Aside from toy programs that don't do anything, how does one start with simple useful Ada code. To me, this is Free Pascal, not Ada at all.

People can start with processing and have fun with Arduinos, then move to C and then move to C++. In fact there are multiple roads to C++ fluency and they are fun. The sheer number of programmers really means something because this means a larger community and more libraries which in turn brings even more programmers.

Many/most languages have their bigots but Ada has so many. In this list and in most of the Ada books I have read there is an air of snobbery about Ada and how it is so much better than language XYZ etc.

I don't like PHP and no one in their right mind would say it was a better language technically but is it better in other ways?

I heard an interview with Rasmus Lerdorf, he thinks PHP is so great because it is accessible. He was very happy to hear about a dentist that wrote a dental clinic management program in PHP.

Python is taught to elementary kids yet it is also good enough for Google and NASA. Are these organizations stupid for using it? Could be we be rubbing people the wrong way with our stance?(I have joined the snob band wagon at times myself)

Is Ada not catching on because of a GPL licensing issue? Really? I don't even know what is missing from the FSF version vs the Adacore GPL version, it's certainly not an issue for me, my main problem has been the limited libraries and the difficulty in interfacing with C to create the libraries that do not exist with Ada.

In fact is there not fewer and fewer Ada libraries each year? Sure there are new ones but it seems to me that the old ones are becoming more and more stale.

For Ada to succeed I believe it has to SCALE DOWN and be more friendly and accepting and we have to interface more easily with C.

Again I am grateful for the help her but is this not a very judgmental place? If someone doesn't like the formatting of your code, your going to hear about it. Regular posters seem to be consistently engaged in posturing, trying to prove that they are better Ada programmers than the other regular posters.

Other lists suffer from this but perhaps not to the same extent. Would you want to send your high school age child to ask a question here? They would be fine if they announced they are a newbie or young but failing this, they will get flamed. It seems that everyone is expected to be a professional programmer here. I remember many years ago posting to the "python newbie" list. I felt very comfortable as I was expected to have dumb questions.

Ada is huge and then there is the standard library to learn and potentially another build system with GPR.

I am not using Ada right now but I just posted to the list about using shared objects because I am slowly trying to figure out how to write up a document(or possibly a book as I have a publishers account) that will introduce simple ways to mix Ada with C and to introduce a subset of the language to new programmers. We don't have a large enough community to support the libraries that probably a lot of programmers need. IMHO it's critical to be able to write your own bindings.

And there there is the hugeness of the language. How could any dentist or young person be expected to cover it all? I think it's important to learn a subset. I am personally trying to only use Ada83 and this is the subset I would like to eventually include in a book or PDF.

Please stop to consider how programming languages are acquired, it's the people programming in their pajamas that will be tomorrow's C++ programmer or they might be in a management position and deciding what language will be used.

Please also consider how we appear to others. VCRs are gone now but it my understanding that BETA was much better than VHS but it died. Better doesn't mean it lives on, there are other forces.

-Patrick

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

patrick@spellingbeewinnars.org writes:
> Indeed Barnes, said "ease yourself into the language" and this can be
> done. Can it with Ada? Aside from toy programs that don't do anything,
> how does one start with simple useful Ada code.

I didn't see any obstacle to that.  I didn't write anything significant
in Ada, but I wrote enough to find that I preferred it to C.  Am I
missing something?  

Re: How to get Ada to ?cross the chasm??

[Simon Wright]

patrick@spellingbeewinnars.org writes:

> Python is taught to elementary kids yet it is also good enough for
> Google and NASA.

And AdaCore engineers who use it to support tools - such as GPS
customisations, to name but one.

Re: How to get Ada to ?cross the chasm??

[Jeffrey R. Carter]

On 04/29/2018 02:39 AM, patrick@spellingbeewinnars.org wrote:
> 
> Instead of talking about how to get Ada over the Chasm, could we stop for a moment and talk about who has already made it over the chasm and is eating Ada's lunch. I believe this to be largely C++ with a bit of Java perhaps.
> 
> C++ is huge and it is complicated, much like Ada but IMHO, there is no comparison between the two. Indeed Barnes, said "ease yourself into the language" and this can be done. Can it with Ada? Aside from toy programs that don't do anything, how does one start with simple useful Ada code. To me, this is Free Pascal, not Ada at all.

If you limit Ada to features that C++ has, you have to get rid of tasking, 
packages, and user-defined numeric types. What's left is similar to Pascal. Why 
is it OK for C++ to be equivalent to Pascal but not to start with the Pascal 
subset + packages with Ada?

-- 
Jeff Carter
"Ditto, you provincial putz?"
Blazing Saddles
86

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
> If you limit Ada to features that C++ has, you have to get rid of
> tasking,

http://en.cppreference.com/w/cpp/thread
http://en.cppreference.com/w/cpp/experimental/concurrency

> packages,

https://gcc.gnu.org/wiki/cxx-modules (probably not as good as Ada
packages)

> and user-defined numeric types.

??? Of course C++ has that through operator overloading.

Re: How to get Ada to ?cross the chasm??

[Jeffrey R. Carter]

On 04/29/2018 02:39 AM, patrick@spellingbeewinnars.org wrote:
> 
> In fact is there not fewer and fewer Ada libraries each year? Sure there are new ones but it seems to me that the old ones are becoming more and more stale.

S/W doesn't become stale. If a library is complete, correct, and reliable, why 
should it ever be modified again?

-- 
Jeff Carter
"Ditto, you provincial putz?"
Blazing Saddles
86

Re: How to get Ada to ?cross the chasm??

[Dmitry A. Kazakov]

On 2018-04-29 09:57, Jeffrey R. Carter wrote:
> On 04/29/2018 02:39 AM, patrick@spellingbeewinnars.org wrote:
>>
>> In fact is there not fewer and fewer Ada libraries each year? Sure 
>> there are new ones but it seems to me that the old ones are becoming 
>> more and more stale.
> 
> S/W doesn't become stale. If a library is complete, correct, and 
> reliable, why should it ever be modified again?

To make it incompatible? That is the way C libraries live, e.g. GTK 2 vs 
GTK 3.

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

Re: How to get Ada to ?cross the chasm??

[patrick]

That's fair but that's not the only issue. If no one appears to be maintaining the software then it becomes less attractive. Issues can come up later and with no one to apply a bug fix, it could be a real problem. 

And that's just the technical aspect, poor presentation is a problem even if there are no technical issues. Software that has not been updated for 10 years just isn't going to be as appealing as software that was updated a year ago.

I am not a fan of Ruby on Rails but David Heinemeier Hansson did a good job of promoting it and getting people excited about it. I don't think there is anything similar here and that's sad because I bet there is very good software being overlooked due to non-technical issues.

Re: How to get Ada to ?cross the chasm??

[Mehdi Saada]

As a beginner, I'll say two/three things about what just made me upset :
> That's fair but that's not the only issue. If no one appears to be maintaining the software then it becomes less attractive. Issues can come up later and with no one to apply a bug fix, it could be a real problem. 
Maintaining means usually fixing bugs that are not possible thanks to strong static checking. Hence, don't be surprised if the same Ada S/W works without maintaining 15 years later.
> Software that has not been updated for 10 years just isn't going to be as appealing as software that was updated a year ago.
Why so ? If it still works, why should you care about lack of advertising ?
Binding parts do age, but it's the same for every language. Yeah, sure the size of the community does play a role here. But the language's qualities have nothing to do with it...
> I am not a fan of Ruby on Rails but David Heinemeier Hansson did a good job of promoting it and getting people excited about it.
Relying on fashion like this is very much asking for contempt from people who do try to judge things/products rationally. If you think that is bigotry or arrogance... poor you.

> They would be fine if they announced they are a newbie or young but failing this, they will get flamed.
Yeah, that's called peer judgement. If you are offended by constructive criticism, you better don't ask any help...
> Would you want to send your high school age child to ask a question here? 
I am a youngster, asked dumb questions, and got adapted answers. Never the post was ignored. You just don't know what you're talking about. Actually, I'm very grateful to people here.

> And there there is the hugeness of the language. How could any dentist or young person be expected to cover it all?
No one is asking this, and it's not necessary to program. He/She can learn what they need to do what they want, step by step.
I do (try to) program in my pyjama. I don't have to know the entire language, because I'll never ever have to use it all in a project. Why would I bother then ? Plus, the standard libraries are really simple to use, because you don't HAVE to understand how they work, but only what they provide.
The only persons who are really bothered by this hugeness are compiler' writers and the like, but that's just their job.
> VCRs are gone now but it my understanding that BETA was much better than VHS but it died. Better doesn't mean it lives on, there are other forces.
Ah, Betacap... funny, my father worked in it.
Do you really think more/better advertising could have change something ? Choices are not rational in most cases, and if merely being better is your loss in the end, there's nothing to regret. Better disappearing than being dumbed down.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Mehdi Saada <00120260a@gmail.com> writes:
> Maintaining means usually fixing bugs

I don't believe that.  There are always improvements to make that aren't
bug fixes.  Think of Ada-2012.  How much code do you personally use
(other than embedded) that hasn't been improved in the past 15 years?

Re: How to get Ada to ?cross the chasm??

[Dmitry A. Kazakov]

On 2018-04-29 16:34, Paul Rubin wrote:
> Mehdi Saada <00120260a@gmail.com> writes:
>> Maintaining means usually fixing bugs
> 
> I don't believe that.  There are always improvements to make that aren't
> bug fixes.  Think of Ada-2012.

What is with Ada 2012?

> How much code do you personally use
> (other than embedded) that hasn't been improved in the past 15 years?

How do you know it was an improvement?

I cannot remember much improvements. It could be a psychological factor, 
but most code changes I usually notice are to worse.

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> What is with Ada 2012?

It's less than 15 years old and it's at least supposedly an improvement
over earlier versions of Ada.  I got interested in Ada because of it.

Re: How to get Ada to ?cross the chasm??

[Dmitry A. Kazakov]

On 2018-04-29 16:59, Paul Rubin wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> What is with Ada 2012?
> 
> It's less than 15 years old and it's at least supposedly an improvement
> over earlier versions of Ada.  I got interested in Ada because of it.

OK. You can see how subjective it is. To me Ada 2005 and 2012 go away 
from original Ada ideas.

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

Re: How to get Ada to ?cross the chasm??

[patrick]

Thanks for the feedback Luke. I didn't know that about the FSF vs GPL version and yeah, I showed up on ##C on freenode a few years ago and got beat up on sight :)

I will come out of my Ada83 shell someday but for now I don't have much time to program in Ada and I figure I better just use a small subset and get started coding.

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87fu3eozdz.fsf@nightsong.com...
> Mehdi Saada <00120260a@gmail.com> writes:
>> Maintaining means usually fixing bugs
>
> I don't believe that.  There are always improvements to make that aren't
> bug fixes.  Think of Ada-2012.  How much code do you personally use
> (other than embedded) that hasn't been improved in the past 15 years?

The programming editor I use regularly hasn't been maintained since 1986. 
I've rarely felt a need to replace it for text editing. (Unfortunately, it 
won't run on Windows 7 or 10, I'm not sure what I'm going to do about that.) 
We never upgraded the bookkeeping software that RRS uses - it was purchased 
in 1999. Etc.

People throw away working things WAAAY too fast IMHO. :-)

                             Randy.

Re: How to get Ada to ?cross the chasm??

[Jeffrey R. Carter]

On 04/29/2018 01:33 PM, patrick@spellingbeewinnars.org wrote:
> That's fair but that's not the only issue. If no one appears to be maintaining the software then it becomes less attractive. Issues can come up later and with no one to apply a bug fix, it could be a real problem.
> 
> And that's just the technical aspect, poor presentation is a problem even if there are no technical issues. Software that has not been updated for 10 years just isn't going to be as appealing as software that was updated a year ago.

This is a common attitude among those who cannot create complete, correct, 
robust S/W, and so assume that no one can. Such software exists, however, and is 
more common among Ada created by S/W engs than in the rest of the S/W world.

I take exactly the opposite view: if a library is being used and has not needed 
modifications for quite a while, then it's more likely that it's complete, 
correct, and reliable and something I'll want to use.

-- 
Jeff Carter
"Ditto, you provincial putz?"
Blazing Saddles
86

Re: How to get Ada to ?cross the chasm??

[Simon Clubley]

On 2018-04-29, Jeffrey R. Carter <spam.jrcarter.not@spam.not.acm.org> wrote:
> On 04/29/2018 02:39 AM, patrick@spellingbeewinnars.org wrote:
>> 
>> In fact is there not fewer and fewer Ada libraries each year? Sure there are new ones but it seems to me that the old ones are becoming more and more stale.
>
> S/W doesn't become stale. If a library is complete, correct, and reliable, why 
> should it ever be modified again?
>

Software does become stale when it starts getting probed for security
issues in new ways and you need to fix the security issue that laid
unfixed or years or even decades and maybe do a redesign to fix any
underlying problems.

This is a CLI, not a library, but it demonstrates the point:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17482

That's something I discovered and yes, that's a DCL vulnerability
that laid undiscovered in VMS for 33 years until I found it.

So, yes, your software can indeed become stale and need fixing.

Simon.

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

Re: How to get Ada to ?cross the chasm??

[Jeffrey R. Carter]

On 04/30/2018 03:06 PM, Simon Clubley wrote:
> 
> Software does become stale when it starts getting probed for security
> issues in new ways and you need to fix the security issue that laid
> unfixed or years or even decades and maybe do a redesign to fix any
> underlying problems.

S/W that is correct and reliable has no security issues, by definition.

> This is a CLI, not a library, but it demonstrates the point:
> 
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17482
> 
> That's something I discovered and yes, that's a DCL vulnerability
> that laid undiscovered in VMS for 33 years until I found it.

That S/W didn't become stale; it was always incorrect and unreliable.

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

Re: How to get Ada to ?cross the chasm??

[Simon Clubley]

On 2018-04-30, Jeffrey R. Carter <spam.jrcarter.not@spam.not.acm.org> wrote:
> On 04/30/2018 03:06 PM, Simon Clubley wrote:
>> 
>> Software does become stale when it starts getting probed for security
>> issues in new ways and you need to fix the security issue that laid
>> unfixed or years or even decades and maybe do a redesign to fix any
>> underlying problems.
>
> S/W that is correct and reliable has no security issues, by definition.
>

There is a difference between that and software that you just _think_
is correct and reliable.

>> This is a CLI, not a library, but it demonstrates the point:
>> 
>> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17482
>> 
>> That's something I discovered and yes, that's a DCL vulnerability
>> that laid undiscovered in VMS for 33 years until I found it.
>
> That S/W didn't become stale; it was always incorrect and unreliable.
>

It was an example of how security issues can live undetected for
a very long time in heavily used production code until someone
probes the software in a new way for security issues.

Simon.

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

Re: How to get Ada to ?cross the chasm??

[Dan'l Miller]

On Monday, April 30, 2018 at 11:56:54 AM UTC-5, Jeffrey R. Carter wrote:
> On 04/30/2018 03:06 PM, Simon Clubley wrote:
> > 
> > Software does become stale when it starts getting probed for security
> > issues in new ways and you need to fix the security issue that laid
> > unfixed or years or even decades and maybe do a redesign to fix any
> > underlying problems.
> 
> S/W that is correct and reliable has no security issues, by definition.

Software isn't written (yet) by definitions.  Software is currently written as a manual tradecraft by human beings who at best hold an axiom system in their mind when crafting their design and their lines of code (and at worst hold vague rules of thumb as a perceived reference model of how the underlying machine is thought to work; Nancy Leveson goes into the necessity of this obfuscating-the-details mental model in her book _Safeware: System safety and computers_).

For example, if mandatory Harvard architectures* were the norm when the operating system's source code was authored (e.g., ARM), then the operating system is ported to a von Neumann architecture** (e.g., Intel, AMD with ), then suddenly the operating system's underlying axiom system changed beneath it at the hardware level.  Suddenly, the operating system is oblivious to the need to inhibit data from being executable machine instructions.  This is an example of Simon Clubley's “probing for security issues in new ways”.  An extant example of the reverse direction effectively occurred when Intel & AMD & ARM & POWER & Alpha & SPARC all added their various-named analogues of NX bit to emulate Harvard architecture protections on a von Neumann architecture.  Then suddenly operating systems had the security axiom system shifted underneath them to properly securely enact a de facto Harvard architecture when  they had insecurely assumed von Neumann up until that point.

https://en.wikipedia.org/wiki/NX_bit
https://en.wikipedia.org/wiki/Harvard_architecture
https://en.wikipedia.org/wiki/Modified_Harvard_architecture
https://en.wikipedia.org/wiki/Von_Neumann_architecture

> > This is a CLI, not a library, but it demonstrates the point:
> > 
> > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17482
> > 
> > That's something I discovered and yes, that's a DCL vulnerability
> > that laid undiscovered in VMS for 33 years until I found it.
> 
> That S/W didn't become stale; it was always incorrect and unreliable.

Yes, if & only if your design extraordinarily-wisely considered the entire universe of axiom systems, not only now known, but knowable until the end of time in the far future.  But practically speaking, for mere mortals/non-gods, such foresight is at least impractical if not impossible, so Simon Clubley is more correct in practice than you on this issue.

Randy, hence the provability of anything in Ada (e.g., tasking in Ada2020) is only as good as an explicitly enumerated inventory of axioms.  The very most awesome would be for Ada-for-the-21st-century to declare such axioms in the Ada source code (for source-code-requested Ada-compiler-based correctness proving).  Almost as awesome would be for the ARM to declare such axioms in a declarative language other than English prose (so that they can be parsed by compiler vendors when authoring/analyzing their compiler's source code).  Somewhat stinky but better than nothing would be for the ARG to overtly declare such axioms in English prose in writing in the ARM.  Living dangerously would be for some members of the ARG to hold differing partial axiom systems mentally in their head while writing the ARM.  Total failure is likely from no one ever attempting to enumerate any axioms on which (shaky house-of-cards) (so-called-)provability is based.

Re: How to get Ada to ?cross the chasm??

[Simon Wright]

Pleased to note that the Analytical Engine was Harvard architecture
(well, there would have been 4 paths: cards specifying the operations to
be executed, different cards specifying the store addresses to be read
to the mill/written back, cards with numerical values to be written to
store, and the store itself).

Re: How to get Ada to ?cross the chasm??

[Jeffrey R. Carter]

On 04/29/2018 02:39 AM, patrick@spellingbeewinnars.org wrote:
> 
> I am not a professional program[mer], I make my living repairing and/or reselling scientific instruments, please keep this in mind.

I'm going to hijack this comment and twist it to serve as a way to repeat yet again:

Ada is a language for software engineers. If you're a S/W eng, Ada supports the 
way you think and you'll be able to produce correct, reliable, simple, clear, 
and understandable S/W using it much more quickly than with most other languages.

If you're not a S/W eng (a coder), Ada will fight you every step of the way and 
you won't like it. Coders prefer coders' languages that let them easily make as 
big a mess as they like.

In my experience, S/W engs are about 2% of developers. 98% of developers are 
coders. So, on one side of the chasm we have Ada and the S/W engs who like it. 
On the other side we have everyone else.

How can we get Ada to cross the chasm?

1. Dumb Ada down until it becomes a coders' language. Some steps have been taken 
in this direction: see anonymous access types, for example.

2. Find an effective way to distinguish S/W engs from coders and prohibit coders 
from developing S/W.

We can hope that 1. won't proceed any further and liability will force us to 2., 
but I'm not holding my breath.

-- 
Jeff Carter
"Ditto, you provincial putz?"
Blazing Saddles
86

Re: How to get Ada to ?cross the chasm??

[patrick]

This is exactly what the OP was concerned about, how to get Ada out of one demographic into another. 

Again are all the other languages for inferior programmers?

Using a subset does not mean the language is dumbed down. 

"2. Find an effective way to distinguish S/W engs from coders and prohibit coders from developing S/W. "

This is mind-bogglingly arrogant. 

coding/software engineering is very important and important to teach children. What path is there for young people to learn Ada and enjoy using it.

Of all the work with Ada I think that Rolf's work with Ada-AVR is the most valuable. Someday, when it's done, it might give young people something fun to do with Ada.

They can write web servers and whatever else they want with it. See the problems on this list.... A great guy is writing 1M lines of code to create a web server and someone has to put him down for it.....senseless and more arrogance

Re: How to get Ada to ?cross the chasm??

[Jeffrey R. Carter]

On 04/29/2018 12:50 PM, patrick@spellingbeewinnars.org wrote:
> 
> "2. Find an effective way to distinguish S/W engs from coders and prohibit coders from developing S/W."
> 
> This is mind-bogglingly arrogant.

The topic is how to get Ada to "cross the chasm". The chasm is between the S/W 
engs who like Ada and the coders who don't. I know from experience that coders 
will not willingly use Ada. There are 2 ways to get Ada to cross that chasm: 
turn Ada into a language that coders like or get rid of the chasm by getting rid 
of coders (getting rid of S/W engs will also get rid of the chasm, but not in a 
way that gets Ada more widely used). I see no other way. If you do, then we 
should know what it is, but you should be aware that this has been discussed for 
decades without anything changing.

If pointing out the only 2 ways to get Ada to cross the chasm is arrogant, then 
so be it.

-- 
Jeff Carter
"Ditto, you provincial putz?"
Blazing Saddles
86

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

patrick@spellingbeewinnars.org writes:
> They can write web servers and whatever else they want with it. See
> the problems on this list.... A great guy is writing 1M lines of code
> to create a web server and someone has to put him down for
> it.....senseless and more arrogance

If you meant me, no it wasn't my intention to put Jacob down.  He is
very knowledgeable and a great programmer and I admire him.  But, I
don't understand the choice to write 1M lines of Ada for a web server.

Re: How to get Ada to ?cross the chasm??

[patrick]

Hi Paul

Thanks for saying this. Maybe phrase things differently next time.

I admire him too.

Ada has features that might make for a very interesting web server and he is a bright guy so let's just cheer him on, something good will happen.

Re: How to get Ada to ?cross the chasm??

[Björn Lundin]

On 2018-04-29 17:09, Paul Rubin wrote:
> patrick@spellingbeewinnars.org writes:
>> They can write web servers and whatever else they want with it. See
>> the problems on this list.... A great guy is writing 1M lines of code
>> to create a web server and someone has to put him down for
>> it.....senseless and more arrogance
> 
> If you meant me, no it wasn't my intention to put Jacob down.  He is
> very knowledgeable and a great programmer and I admire him.  But, I
> don't understand the choice to write 1M lines of Ada for a web server.
> 

A more likely interpretation is that Jacob put a webserver on EXISTING code.
That he did not write 1M code to CREATE a web server,
but he put a web server on, say a process that is part of a Warehouse
Management System. They tend to live for many years (20-30 years are not
unheard of)


-- 
--
Björn

Re: How to get Ada to ?cross the chasm??

[Jacob Sparre Andersen]

Björn Lundin wrote:

> A more likely interpretation is that Jacob put a webserver on EXISTING
> code.

Yes.  Thanks for clarifying.

> That he did not write 1M code to CREATE a web server, but he put a web
> server on, say a process that is part of a Warehouse Management
> System. They tend to live for many years (20-30 years are not unheard
> of)

Exactly.

Greetings,

Jacob
-- 
"There are two ways of constructing a software design. One way is to
 make it so simple that there are obviously no deficiencies. And the
 other way is to make it so complicated that there are no obvious
 deficiencies."  -- C. A. R. Hoare

Re: How to get Ada to ?cross the chasm??

[Warren]

On Sunday, 29 April 2018 06:51:00 UTC-4, pat...@spellingbeewinnars.org  wrote:
> This is exactly what the OP was concerned about, how to get Ada out of one demographic into another. 
> 
> Again are all the other languages for inferior programmers?
> 
> Using a subset does not mean the language is dumbed down. 

Yes, subsets are a great way to start out. I remember looking at SL/I (Student Language One) on the IBM-1130 way back when, which was a PL/I subset. The PL/I language would have been too large to start out with. At that time, all of those features would have been too much for that 8K core machine anyway, heh heh.

I think this discussion needs to divide into two main categories:

 - embedded programming (which I see no Ada problem for)
 - POSIX day-to-day programming

The biggest impediment to Ada in the POSIX world IMO is the fact that it is basically a "C World". Yes, you can call C/C++ functions from Ada and even design struct mappings etc.

But the biggest PITA for Ada programming in a C environment is the durn C macros!  You end up having write programs to digest the macros you need and put them into Ada terms. Then if you move to another POSIX platform, you may need to tweak this again (errno.h for example).

> "2. Find an effective way to distinguish S/W engs from coders and prohibit coders from developing S/W. "
> 
> This is mind-bogglingly arrogant. 

I have to agree. The distinction may have its place when hiring for a position but even then, degrees and Phd don't guarantee.

Another part of the problem is the chicken and egg problem:

I'd love to do my work in Ada where I work, but it would be unfair of me to introduce it here. They can barely hire C++ programmers where I live, let alone find someone that is proficient in Ada.  If I left behind a legacy of Ada code here, they'd never let me retire!

Warren

Re: How to get Ada to ?cross the chasm??

[Jeffrey R. Carter]

On 05/11/2018 10:19 PM, Warren wrote:
> 
>> "2. Find an effective way to distinguish S/W engs from coders and prohibit coders from developing S/W."
>>
>> This is mind-bogglingly arrogant.
> 
> I have to agree.

This was taken out of context. In context, the person you are quoting is saying 
that listing the only 2 ways to get Ada to cross the chasm is arrogant.

-- 
Jeff Carter
"Since I strongly believe that overpopulation is by
far the greatest problem in the world, this [Soylent
Green] would be my only message movie."
Charleton Heston
123

Re: How to get Ada to ?cross the chasm??

[G.B.]

On 11.05.18 22:19, Warren wrote:

> Another part of the problem is the chicken and egg problem:
> 
> I'd love to do my work in Ada where I work, but it would be unfair of me to introduce it here. They can barely hire C++ programmers where I live, let alone find someone that is proficient in Ada.  If I left behind a legacy of Ada code here, they'd never let me retire!

How many weeks or months does it take for a programmer to become reasonably
fluent in any of these languages? Apple Computer Inc. doesn't suffer
from their introduction of Swift. Programmers who work in places
that use Microsoft Corporation's languages tend to know some C# or VB.NET,
possibly having used C or some Pascal before, and nothing had turned
C# or VB.NET into economic obstacles after their introduction.

So, chicken indeed, somewhere.

OTOH, it seems that HR managers are really made to ask for preexisting
specializations when they name languages. "... candidate ... knows C++ ...
Microsoft Windows ..." isn't really asking about C++. They want
to know if the programmer knows Win32 vocabulary as addressed using
Microsoft's "C++/CLI" language, or, maybe, which .NET collections of
types they have used as these are to be used on a six months project.

Note to candidates: some HR managers are impressed if you have used
the IDE of choice. More important for measuring "professionalism"
than quality of programs.


(Consider
Delphi vs Visual Studio,
Netbeans vs Eclipse,
GNAT PS vs Emacs,
....)

Re: How to get Ada to ?cross the chasm??

[Jacob Sparre Andersen]

Warren wrote:

> I'd love to do my work in Ada where I work, but it would be unfair of
> me to introduce it here. They can barely hire C++ programmers where I
> live, let alone find someone that is proficient in Ada.  If I left
> behind a legacy of Ada code here, they'd never let me retire!

If you can find Pascal/Delphi programmers, then the trick is to hire
them a year or two before you retire, so you can get them started in
Ada.

One of my current customers has even done this with consultants.

It does cost something to get people started with Ada, but I believe it
is worth the effort in the long run.  (Unfortunately, I don't have
access to data to back this belief.)

Greetings,

Jacob
-- 
"No!  The universe is ours."

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Jacob Sparre Andersen <jacob@jacob-sparre.dk> writes:
> If you can find Pascal/Delphi programmers, then the trick is to hire
> them a year or two before you retire, so you can get them started in Ada.

What's that about?  The surface syntax is similar but is there not a lot
more going on?  I try to imagine my own prospective learning curve to
become good at Ada, and Pascal/Delphi is about 1% of the way there.

Re: How to get Ada to ?cross the chasm??

[Jacob Sparre Andersen]

Paul Rubin wrote:
> Jacob Sparre Andersen <jacob@jacob-sparre.dk> writes:

>> If you can find Pascal/Delphi programmers, then the trick is to hire
>> them a year or two before you retire, so you can get them started in
>> Ada.
>
> What's that about?  The surface syntax is similar but is there not a
> lot more going on?  I try to imagine my own prospective learning curve
> to become good at Ada, and Pascal/Delphi is about 1% of the way there.

A part of it is a matter of attitude to software development.

Another part is simply not to find the syntax intimidating or annoying.

The most recent batch of consultants got a two-day introduction to Ada
for Pascal programmers, before they were sent to on-the-job learning.
The on-the-job learning involved making reasonably well-specified
extensions to existing packages with me and two other experienced Ada
developers nearby for answering questions.

The one thing I definitely will spend more time on, next time I have to
teach Ada to Pascal programmers is the string types in the standard
library.  I underestimated the need for explaining those.

If people have to design APIs or plan large-scale changes, they
definitely need more than two days of introduction to Ada, before I will
let them near the task, but as a junior developer on a project, you
don't need to have read and understood every single page of the LRM.

Greetings,

Jacob
-- 
Adlai Stevenson said it all when, at an event during the
1956 Presidential campaign, a woman shouted, "You have the
vote of every thinking person!" Stevenson shouted back,
"That's not enough, madam, we need a majority!"

Re: How to get Ada to ?cross the chasm??

[Lucretia]

On Sunday, 29 April 2018 01:39:10 UTC+1, pat...@spellingbeewinnars.org  wrote:

> Is Ada not catching on because of a GPL licensing issue? Really? I don't even know what is missing from the FSF version vs the Adacore GPL version, it's certainly not an issue for me, my main problem has been the limited libraries and the difficulty in interfacing with C to create the libraries that do not exist with Ada.

There are issues, but it's mainly when you hit a bug box in the FSF version which doesn't happen in the GPL version that it mainly becomes apparent.
 
> For Ada to succeed I believe it has to SCALE DOWN and be more friendly and accepting and we have to interface more easily with C.

But we also need people to stop looking at one piece of Ada and saying "ew! Pascal!" or "I can't read this, it's too verbose!" These are comments I've come across a lot. More people need to be more open minded about programming languages and get out of the "it has to have braces or I won't use it" mentality. To me, that is snobbishness to the extreme, it's also incredibly stupid.

> Again I am grateful for the help her but is this not a very judgmental place? If someone doesn't like the formatting of your code, your going to hear about it. Regular posters seem to be consistently engaged in posturing, trying to prove that they are better Ada programmers than the other regular posters.

Try hanging out on #C or #C++ (whatever their IRC channels are called), you'll come up against a lot worse people there.
 
> Ada is huge and then there is the standard library to learn and potentially another build system with GPR.

Ada is large, GPR is just one of many project systems that exist, GPR is specific to GNAT though.

> I am not using Ada right now but I just posted to the list about using shared objects because I am slowly trying to figure out how to write up a document(or possibly a book as I have a publishers account) that will introduce simple ways to mix Ada with C and to introduce a subset of the language to new programmers. We don't have a large enough community to support the libraries that probably a lot of programmers need. IMHO it's critical to be able to write your own bindings.

Binding generation can be very time consuming, see my SDL2 bindings. If I decided to do a quick thin binding, it'd feel all wrong, it would just be like writing C in Ada. I decided to take a mixed level binding approach, by adding thin where it doesn't really matter much, but also by making Ada types and mapping them to the C "types," i.e. the numeric types. For other things, they get wrapped in Ada and are higher level. The library isn't done and probably never will be as SDL2 is still evolving, and always will be.

> And there there is the hugeness of the language. How could any dentist or young person be expected to cover it all? I think it's important to learn a subset. I am personally trying to only use Ada83 and this is the subset I would like to eventually include in a book or PDF.

You don't need to cover it all, you can do a lot with types, subprograms, generics and packages. I haven't touched tasking since uni.

I think limiting yourself to Ada83 is not the best way, you miss out on various things added, i.e. interfaces for OO, extended return for assignment in place for limited types, just to mention a few. Also look into "pragma Restrictions" if you want the compiler to stop you using some feature.
 
Luke.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Jacob Sparre Andersen <jacob@jacob-sparre.dk> writes:
>> I couldn't imagine writing a substantial server app entirely in Ada.
> Why not?  (That's what I spend most of my time doing.)  One of the two
> projects I'm working on now is already ~1M lines of Ada in the server.

Why write 1M lines of Ada when you can write 1/10th as much code in a
HLL?  Why worry about potential integer overflow every time you do
arithmetic?  How much of your effort goes into manual memory management?
Why not use a language and runtime that handles all that for you
automatically?

And if your app runs on one cpu, what does Ada's solidity get you under
Joe Armstrong (designer of Erlang)'s dictum that a non-distributed
system can never be reliable, since the power cord is a single point of
failure?  Conversely, if your app is distributed, what does Ada get you
that normal failover machinery doesn't?

> The other one...  The R and Python parts will be carefully shielded
> from the users and the internet by the Ada part.

That sounds like a much more practical approach.  

Re: How to get Ada to ?cross the chasm??

[gautier_niouzes]

Le dimanche 29 avril 2018 07:22:43 UTC+2, Paul Rubin a écrit :

> Why write 1M lines of Ada when you can write 1/10th as much code in a
> HLL?  Why worry about potential integer overflow every time you do
> arithmetic? 

Precisely, you worry less because there are automatic, built-in ways to decect problems.
Of course (it is in any language) you need to do some mental calculation for choosing the right integer types. That's another story.

> How much of your effort goes into manual memory management?

You are assuming Ada forces you into manual memory management.
In Ada you can use most objects on stack (this includes unconstrained types); for those that need dynamic resizing you can use Vector's and other containers using controlled types that do deterministic garbage collection.
I do entire applications with UI, data management & number-crunching without using any "access", "new" and "Unchecked_Deallocation".

> Why not use a language and runtime that handles all that for you
> automatically?

Sure, it is called Ada 2005, Ada 2012 :-)
I'm afraid you are confused about what Ada really is because don't code enough in it...

Re: How to get Ada to ?cross the chasm??

[gautier_niouzes]

Le dimanche 29 avril 2018 07:22:43 UTC+2, Paul Rubin a écrit : 

> Why write 1M lines of Ada when you can write 1/10th as much code in a HLL?

You are doing completely wrong assumptions about how you can abstract things in Ada.
The fact that Ada covers low-level features doesn't mean it is not a HLL as well.
Actually it is an ALL (Any Level Language) :-) .

> Why worry about potential integer overflow every time you do arithmetic? 

Precisely, in Ada you worry *less* about those things because there are automatic, built-in ways to detect problems.

Of course (as in any language) you need to do some mental calculation for choosing the right integer types.
But that's another story. 

> How much of your effort goes into manual memory management? 

You are assuming Ada forces you into manual memory management. 
In Ada you can use most objects on stack (this includes unconstrained types); for those that need dynamic resizing you can use Vector's and other containers using controlled types that do deterministic garbage collection. 
I do entire applications with UI, data management and number-crunching without using any "access", "new" and "Unchecked_Deallocation". 

> Why not use a language and runtime that handles all that for you 
> automatically? 

Sure, it is called Ada 2005, Ada 2012 :-) 
I'm afraid you are confused about what Ada really is because you don't code enough in it... 
_________________________ 
Gautier's Ada programming 
http://sf.net/users/gdemont/

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

gautier_niouzes@hotmail.com writes:
> Of course (as in any language) you need to do some mental calculation
> for choosing the right integer types.

You occasionally need to use machine integers for performance or compact
representation.  The vast majority of the time that doesn't happen, so
you can just use ordinary (i.e. arbitrary-precision) integers, which
should be the default integers in any HLL.  HLL is of course a nebulous
and subjective term, but I remember one guy proposing that it meant that the
default storage management is by garbage collected, and I'd add that the
default integers are arbitrary-precision.  So maybe it's circular
reasoning, but by that notion, Ada is not an HLL.

> In Ada you can use most objects on stack (this includes unconstrained
> types); for those that need dynamic resizing you can use Vector's and
> other containers using controlled types that do deterministic garbage
> collection.

Sure, that's like C++ smart pointers and containers.  I'm familiar with
the approach and it's nice for some purposes, but it still needs a lot
of attention, and constrains your style quite a lot.

Re: How to get Ada to ?cross the chasm??

[Simon Wright]

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

> constrains your style quite a lot

I found that the effort of rewriting an event dispatcher to Ravenscar
constraints made a vast improvement (the previous version had,
admittedly, "jest growed").

Re: How to get Ada to ?cross the chasm??

[Jeffrey R. Carter]

On 04/29/2018 09:01 AM, Paul Rubin wrote:
> 
> I'm familiar with the approach [using containers to avoid manual memory
> management] and it's nice for some purposes, but it still needs a lot of
> attention, and constrains your style quite a lot.

Of course, you should be able to write complex systems without a lot of 
attention, and your style should have no constraints on it at all.

The biggest constraint on style is having to use those finicky control 
structures instead of just having conditional gotos all over the place. Clearly 
the latter, being less of a constraint on your style, is better.

-- 
Jeff Carter
"Ditto, you provincial putz?"
Blazing Saddles
86

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
> Of course, you should be able to write complex systems without a lot
> of attention, and your style should have no constraints on it at all.

The idea, of course, is to let the machine do more of the work since
it's better at mindless and repetitive tasks than humans are.  Plus, you
can work more productively by focusing your attention on your actual
problem instead of on that low level stuff.

> The biggest constraint on style is having to use those finicky control
> structures instead of just having conditional gotos

It's the other way around.  You're constrained from using HOFs and
immutable data that are simple to reason about, instead of finicky
control structures and other low-level manipulation that it's far
preferable to leave to the compiler.

I looked at the Ada solution to
https://rosettacode.org/wiki/Hamming_numbers

and the person missed the whole point of the problem, which is to use a
sane algorithm.  And yet they still around about 5x as much code as the
"classic" Haskell solution, and their program crashed from integer
overflow for n=1692.

They posted code for n=1000000 that used a bignum package, but they
didn't show the answer, and they must not have tested the code because
it never would have finished (it would have had to count up to around 5e83).

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87bme2oy91.fsf@nightsong.com...
...
> It's the other way around.  You're constrained from using HOFs and
> immutable data that are simple to reason about, instead of finicky
> control structures and other low-level manipulation that it's far
> preferable to leave to the compiler.

If you're doing that in Ada, you're doing it wrong. Use a container, use 
bignums if you have to (although that is very rarely necessary - integer 
algorithms tend to have small ranges). Futzing with "finicky control 
structures" (what the heck is that anyway, the only control structures Ada 
has are the normal ones like if and case) is unnecessary and "low-level 
manipulation" is something you do only when you need direct hardware acesss.

If you're writing "new" in Ada 2012, you had better be rewriting something 
that proved to be too slow in testing. (Or writing an Ada runtime.:-) 
Otherwise, you are wasting your time and energies. If you're explicitly 
putting "access" into an the interface of an ADT, you probably are copying 
the design of some other language -- it's almost never necessary in Ada. And 
so on.

If Ada has a problem in these areas, it is that you *can* do those 
lower-level things. That causes people (even ones that know better, like me) 
try to do better than the compiler/runtime stuff. You aren't likely to do 
so.

                                   Randy.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> Futzing with "finicky control structures" (what the heck is that
> anyway, the only control structures Ada has are the normal ones like
> if and case)

Well there are also loops etc.  If you want to make a new array whose
elements are the squares of all the elements of an old array, you end up
writing a loop.  In functional style you can get rid of the loop and
write something like "new_array =  map(square, old_array)".

This article discusses FP style and why you might want to use it:

https://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf

It's from 1984 and its code examples are in a language called Miranda
that nobody uses any more, but it was a forerunner of Haskell, and the
Miranda code could be translated straightforwardly and end up looking
cleaner.

Re: How to get Ada to ?cross the chasm??

[Dmitry A. Kazakov]

On 2018-05-01 06:26, Paul Rubin wrote:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> Futzing with "finicky control structures" (what the heck is that
>> anyway, the only control structures Ada has are the normal ones like
>> if and case)
> 
> Well there are also loops etc.  If you want to make a new array whose
> elements are the squares of all the elements of an old array, you end up
> writing a loop.

But I don't want it. There is no practical need in array operations 
using arrays as a whole.

> In functional style you can get rid of the loop and
> write something like "new_array =  map(square, old_array)".

In Ada and in any other language, honestly, if I could, I would define 
an ADT with the corresponding algebra if I needed it:

    type Vector is array (...) of ...;
    function "*" (Left, Right : Vector) return Vector;

The "squaring" would be old_array * old_array. Or even old_array ** 2.

Such manipulation must have some sense. That differentiates software 
engineering from coding mentioned in this discussion. Manipulation on 
data structures do not come from nowhere, for its own sake. There is the 
problem space's logic and structures the program artifacts implement.

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

Re: How to get Ada to ?cross the chasm??

[gautier_niouzes]

> > Well there are also loops etc.  If you want to make a new array whose
> > elements are the squares of all the elements of an old array, you end up
> > writing a loop.
> 
> But I don't want it. There is no practical need in array operations 
> using arrays as a whole.

Programmers in R do it all the time (leading to very convoluted code!) because they discover sooner or later that loops with many iterations, or worse, nested loops, kill the performance of their programs. Perhaps it's the case with other script languages. I've seen series of complicated array operations in Python just for the sake of avoiding a trivial loop. In the end it's still much slower than Ada, but the script programmers knowing only their language have the satisfaction of having "optimized" their code.

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

<gautier_niouzes@hotmail.com> wrote in message 
news:1c4c7bd9-fa68-4ea2-8419-098becb6993e@googlegroups.com...
>> > Well there are also loops etc.  If you want to make a new array whose
>> > elements are the squares of all the elements of an old array, you end 
>> > up
>> > writing a loop.
>>
>> But I don't want it. There is no practical need in array operations
>> using arrays as a whole.
>
>Programmers in R do it all the time (leading to very convoluted code!)
> because they discover sooner or later that loops with many iterations,
> or worse, nested loops, kill the performance of their programs. Perhaps
> it's the case with other script languages. I've seen series of complicated
>array operations in Python just for the sake of avoiding a trivial loop. In
> the end it's still much slower than Ada, but the script programmers
> knowing only their language have the satisfaction of having "optimized"
> their code.

And better, this is likely coming to Ada 2020 using the 'Reduce attribute 
(see AI12-0242-1 and AI12-0262-1). Some of the examples justifying this 
feature are quite maddening.

For instance:
   Num_Outputs : constant Natural :=
          (for P of Formal_Params => 
Boolean'Pos(P.Is_Operation_Output))'Reduce("+",0);
   -- Count "in out" and "out" parameters in a parameter list.

Cool, but is this really making the code more readable?

Put_Line("[" & (for I in Inputs'Range => (if I = Inputs'First then "" else 
", ") & "VN" & Inputs(I)) & "]");
   -- Display a properly formatted list of inputs.

Again, wouldn't this have been better written as a function rather than a 
one-liner? And using "reduce" for string *construction* seems confusing at 
best (nothing is being reduced here).

This should let Paul write the kind of code that he wants to write; whether 
one really gets the benefits of Ada from doing so is another question 
altogether.

                                                   Randy.

P.S. The reason this feature is being considered is that it is easily 
executed in parallel; and a lot of loops are better written this way as it 
avoids the need for an accumulator in a parallel loop, which necessarily 
needs some sort of synchronization.

Re: How to get Ada to ?cross the chasm??

[Dmitry A. Kazakov]

On 02/05/2018 00:32, Randy Brukardt wrote:

> P.S. The reason this feature is being considered is that it is easily
> executed in parallel; and a lot of loops are better written this way as it
> avoids the need for an accumulator in a parallel loop, which necessarily
> needs some sort of synchronization.

Or just for Schadenfreude, maybe? (:-))

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> For instance:
>    Num_Outputs : constant Natural :=
>           (for P of Formal_Params => 
> Boolean'Pos(P.Is_Operation_Output))'Reduce("+",0);
>    -- Count "in out" and "out" parameters in a parameter list.
>
> Cool, but is this really making the code more readable?

Is that some kind of syntactic extension in the compiler?  I'm used to
reduce being an ordinary function.  But "+" in double quotes looks like
a character string, so the compiler must be figuring out what it does.

It also looks like you can add up booleans, where true=1 and false=0?
That is also surprising, if booleans are a separate type from integers.

> Put_Line("[" & (for I in Inputs'Range => (if I = Inputs'First then "" else 
> ", ") & "VN" & Inputs(I)) & "]");
>    -- Display a properly formatted list of inputs.
>
> Again, wouldn't this have been better written as a function rather than a 
> one-liner? And using "reduce" for string *construction* seems confusing at 
> best (nothing is being reduced here).

On the surface that looks like what other languages call a list
comprehension.  But then it seems to be concatenating all those strings?
So it's reducing a concatenation operation over the list of strings.

I agree that it looks confusing in Ada.  If the goal was only to support
parallel evaluation, there were probably easier ways.

> This should let Paul write the kind of code that he wants to write;

It's too syntactically clumsy to be convenient, but besides the
parallelism benefit, it might also be easier to formally verify than an
explicit loop would be.

Re: How to get Ada to ?cross the chasm??

[Dmitry A. Kazakov]

On 02/05/2018 16:23, Paul Rubin wrote:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> For instance:
>>     Num_Outputs : constant Natural :=
>>            (for P of Formal_Params =>
>> Boolean'Pos(P.Is_Operation_Output))'Reduce("+",0);
>>     -- Count "in out" and "out" parameters in a parameter list.
>>
>> Cool, but is this really making the code more readable?
> 
> Is that some kind of syntactic extension in the compiler?  I'm used to
> reduce being an ordinary function.  But "+" in double quotes looks like
> a character string, so the compiler must be figuring out what it does.

That is the operator's name, e.g.

    function "+" (Left, Right : Integer) return Integer;

> It also looks like you can add up booleans, where true=1 and false=0?

Boolean'Pos (X) returns universal integer. Boolean'Pos (False) = 0, 
Boolean'Pos (True) = 1. So the kludge sums all True outcomes of 
Is_Operation_Output.

So it is possible to decipher, but that is by no means Ada (TM).

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

Re: How to get Ada to ?cross the chasm??

[Jeffrey R. Carter]

On 05/01/2018 06:26 AM, Paul Rubin wrote:
> something like "new_array =  map(square, old_array)".

What functional language has arrays?

-- 
Jeff Carter
"My little plum, I am like Robin Hood. I take from
the rich, and I give to the poor. ... Us poor."
Poppy
96

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
> What functional language has arrays?

Are there any that don't?

  https://hackage.haskell.org/package/array-0.5.1.0/docs/Data-Array.html
  http://caml.inria.fr/pub/docs/manual-ocaml/libref/Array.html
  etc.

In practice you'd use lists or trees for many things that you'd use
arrays for in other languages though.  The "map" example I gave was
illustrative.

Re: How to get Ada to ?cross the chasm??

[Jeffrey R. Carter]

On 05/01/2018 11:02 AM, Paul Rubin wrote:
> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
>> What functional language has arrays?
> 
> Are there any that don't?

None that I have any familiarity with (admittedly a limited subset) do. They 
have lists, and operations that let you use lists with an array-like syntax, but 
no arrays.

-- 
Jeff Carter
"My little plum, I am like Robin Hood. I take from
the rich, and I give to the poor. ... Us poor."
Poppy
96

Re: How to get Ada to ?cross the chasm??

[patrick]

Hi Again

This will be my last post to this thread. I am truly grateful for the support I have received over the years here and I really do want to see this language succeed but could everyone take a step back and look at this thread. 

The OP had a valid concern, how to get different demographics to adopt. This thread just rambles on and on about another topics and most of it is OT bickering and I am the only person that has voiced any concern about getting young people to use Ada. 

What future is there for any language, programming or spoken without young people involvement...

I hope I can post back to the list with replies to help people, I don't think I can do anything else at this point. I am certainly not in any sort of position to help with Ada and education or I certainly have limited clout here to change anyone's minds

Re: How to get Ada to ?cross the chasm??

[Lucretia]

On Tuesday, 1 May 2018 16:45:19 UTC+1, pat...@spellingbeewinnars.org  wrote:
> Hi Again
> 
> This will be my last post to this thread. I am truly grateful for the support I have received over the years here and I really do want to see this language succeed but could everyone take a step back and look at this thread. 
> 
> The OP had a valid concern, how to get different demographics to adopt. This thread just rambles on and on about another topics and most of it is OT bickering and I am the only person that has voiced any concern about getting young people to use Ada. 

You're not the only one.

Re: How to get Ada to ?cross the chasm??

[Dan'l Miller]

On Tuesday, May 1, 2018 at 10:45:19 AM UTC-5, pat...@spellingbeewinnars.org wrote:
> ... but could everyone take a step back and look at this thread. 
> 
> The OP had a valid concern, how to get different demographics to adopt. This thread just rambles on and on about another topics and most of it is OT bickering and I am the only person that has voiced any concern about getting young people to use Ada. 

I am the original poster.  I happen to adore this entire thread quite lovingly; it is almost exactly what I envisioned when I kicked it all off by making the original posting.  The only thing wrong with it is that there needs to be even more of it, especially regarding how to thoroughly disrupt the status quo in Ada by having her date some new marriage-minded suitors (e.g., Coq, VHDL, LLVM, melding Ada & Rust via pluggable modularity:  imagine Ada syntax plus opting into Rust's borrow-checker as PRAGMA SEMANTICS( BORROW-CHECKER ) or something like that).

What •you• consider ••off topic•• along all the branches of this thread, I consider ...

> What future is there for any language, programming or spoken, without young people involvement...

... to be ••topics that are frequently uninteresting to youth••.

Youth is typically attracted to shiny objects; I know because I was young once not all that long ago. Until Ada has (at least the beginnings of movement toward) a new shininess of some sort to glitter & sparkle danglingly in the sun, don't expect much fervent move-heaven-&-earth-to-get-there interest from youth.  All the existing old shininess in Ada is what attracted us decades ago when we were in our youth.  (My university taught most of its computer science classes using Ada1983 back in the 1980s.)

Btw, just because I like the existing so-called “off topic” branches of this thread, it would be interesting if you actually do keep posting along this thread with ideas for what would attract youth to Ada.  Perhaps you are seeing some low-hanging easy-to-pick fruit that the rest of us are missing.  To wit, if I were writing that book that you are proposing/writing, I would jettison as much of Ada1983 (lacking OO!) as possible, focusing instead on Ada1995 (with OO!) if you absolutely must narrow to one edition.  S. Tucker Taft's vision is far far far more palatable to youth's tastes than Jean Ichbiah's.  Also, I think that narrowing to one edition of Ada is entirely misguided unless that edition is Ada2012, because the book that needs to be written for youth/beginners is not the one you propose, but rather a 1000-page encyclopedia of Ada-by-recipes, lambasting other languages then showing the golden wonderfulness of Ada on that microtopic:
1) here are smart pointers in C++2017, but here is better memory management in Ada2012;
2) here is spooky mistake-making type inference in other languages (worst in C++2017, btw; see Scott Meyers's aforementioned horror book), but here is the better way of highly-readable literate-design in Ada2012;
3) here is UWP=WinRT programming in C++/WinRT and C++/CX, but here is the better way in Ada-WinRT;
4) here is multithreaded programming in Java, but here is the better way in Ada2012;
5) here are futures in C++2017 and here is the vastly better Grand Central Dispatch in Objective-C and Swift, but here is how to accomplish that same design in Ada;
6) here is a thread pool where all member threads pend competitively on a single message queue in POSIX threads in C, but here is how to better accomplish that same design in Ada2012;
7) here are clunky bitfields in C (and worse, there total absence in so many languages), and here is how to memory-map a nybble & bits register set of an FPGA or ASIC in Ada2012;
8) here is such-&-such convenient syntax in Python, Ruby, Perl6, Haskell, OCaml, etc, but here is the analogous convenient syntax in Ada2012.
9) here are the oft-proposed-never-standardized concept maps in C++ templates, but here they have existed for decades in Ada generics;
10) here are reactive extensions in C#, but here they are in RxAda;
11) here are each of the Gang of Four design patterns in other languages, but here they are done better in Ada2012;
and
12) so forth for hundreds and hundreds of microtopics in computer programming, where the tone can vary from we-got-that-too-isms to lambasting other languages' half-baked conceptual disasters in C++ and Java especially to lambasting Python/Ruby/Lua/Haskell/ML/F#/C#/Java/Kotlin on performance via actual empirical timing measurements on analogously-designed implementations in those languages versus Ada.

By writing such a 1000-page encyclopedia of Ada recipes for common programming microtopics, you will have crafted your own shiny object that youth will find attractive, because it is like a bound book form of StackOverflow.

Re: How to get Ada to ?cross the chasm??

[Dan'l Miller]

On Tuesday, May 1, 2018 at 12:07:41 PM UTC-5, Dan'l Miller wrote:
> 7) ... clunky bitfields in C (and worse, there total absence in so many languages)

  Dang autocorrect!  “their" not “there".

Oh, and how could I forget:

13) here is an API in some other language (e.g., C, C++), and here is how to wrap it safely in a thick Ada-centric design instead of a unchecked_* thin interface that lacks the benefits of Ada.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Dan'l Miller" <optikos@verizon.net> writes:
> I would jettison as much of Ada1983 (lacking OO!) as possible,
> focusing instead on Ada1995 (with OO!) if you absolutely must narrow
> to one edition.

In the functional-programming world we tend to think of OO as a failed
1990s experiment that still has a zombie following in the "enterprise"
sector.  Even C++ has moved mostly from OO to template generics.

> rather a 1000-page encyclopedia of Ada-by-recipes... :
> 1) here are smart pointers in C++2017, but here is better memory
> management in Ada2012;
> 2) here is spooky mistake-making type inference in other languages...

This would be great to see.  Rosettacode.org might be a good place to
put some examples.  There's lots of Ada code there already that mostly
looks ok, but I don't remember any that really stand out.

> especially to lambasting Python/Ruby/Lua/Haskell/ML/F#/C#/Java/Kotlin
> on performance via actual empirical timing measurements on
> analogously-designed implementations in those languages versus Ada.

That will persuade almost nobody using those languages, since they are
primarily writing internet stuff.  We just don't care how slow the
languages are.  Any query you make over the internet will require at
least a 100 msec communication roundtrip, plus whatever the computation
time is.  If Ada can do the computation in 20 microseconds while Python
takes a whole millisecond, the user will never notice that 50x slowdown.
And the developer is happy to take the slowdown in order to ship their
product a week earlier.

Obviously there are exceptions and bottlenecks but those are correctly
handled as special cases.  The old 90-10 rule is now more like 95-5 or
even 99-1.  See:

https://cr.yp.to/talks/2015.04.16/slides-djb-20150416-a4.pdf

> that youth will find attractive, because it is like a bound book form
> of StackOverflow.

Even an oldie like me doesn't look at bound books that much any more.  I
doubt many young'uns even know what they are.  If it's not online it
doesn't exist.

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

<patrick@spellingbeewinnars.org> wrote in message 
news:41092874-0561-43f3-8f94-23886cb002cb@googlegroups.com...
...
> What future is there ...

Not much in my opinion. People have never (in my lifetime, at least) had any 
interest in doing things well over doing things fast. Ada is about doing 
things well. In the current environment, not only doesn't want to do it 
well, they mostly just want to throw stuff at the wall until something 
sticks. (In my experience, the only things that stick the wall are cherry 
tomato seeds, and they had to be cleaned off the wall before going 
home...long story. ;-)

Ada has no chance of success in this environment.

But as I noted, it doesn't matter. The current approach of humanity will get 
us all killed off soon enough. In mean time, I at least want to continue 
doing things well. So Ada remains important to me. Life is too short to care 
about the idiotic masses -- they'll never come around until it's too late 
anyway.

                                           Randy.

Re: How to get Ada to ?cross the chasm??

[David Trudgett]

Newsgroups really need that like button. Lol.

David

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
> None that I have any familiarity with (admittedly a limited subset)
> do. They have lists, and operations that let you use lists with an
> array-like syntax, but no arrays.

Can you name *one* FP language that doesn't have arrays?  One in actual
use, not an obscure toy language or research testbed.

Re: How to get Ada to ?cross the chasm??

[Dan'l Miller]

On Tuesday, May 1, 2018 at 12:34:14 PM UTC-5, Paul Rubin wrote:
> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
> > None that I have any familiarity with (admittedly a limited subset)
> > do. They have lists, and operations that let you use lists with an
> > array-like syntax, but no arrays.
> 
> Can you name *one* FP language that doesn't have arrays?  One in actual
> use, not an obscure toy language or research testbed.

I am pretty sure that Jeffrey Carter's school of thought would be focusing on how •mutability• of arrays is handled as •not•-in-situ assignments to a memory location at an offset from a base address.  To wit, here is the rub in Haskell documentation:

“… In the incremental case, we have a function that produces an empty array of a given size and another that takes an array, an index, and a value, producing a new array that differs from the old one only at the given index. Obviously, a naive implementation of such an array semantics would be intolerably inefficient, either requiring a new copy of an array for each incremental redefinition, or taking linear time for array lookup; thus, serious attempts at using this approach employ sophisticated static analysis and clever run-time devices to avoid excessive copying. …”

I am pretty sure that Jeffrey Carter's school of thought would be focusing on the “clever run-time devices to avoid excessive copying” there in cases where the design or problem-space precludes monolithic arrays created with wholesale-known values at each element en masse.  I am pretty sure that his school of thought would be pointing out that Haskell's “clever run-time devices to avoid excessive copying” in essence produces a •list•* of deltas to the array in the incremental case (which are then scooped up en masse when creating a monolithic array initialization from those incrementally written array-elements).

* or considering this array as hash table, where the incremental updates to certain elements are de facto hash-table ‘collisions’, which are typically represented by an array of potential/initially-empty linked lists

https://www.haskell.org/tutorial/arrays.html

Btw, Pat, in the 1000-page encyclopedia of commonplace Ada recipes (and lambasting other languages) this would be:
15) here are incremental writes to an array in Haskell, but here is Ada's better way for in-situ writes to arbitrary elements within an array, along with space & time performance analysis, comparing Haskell to Ada.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Dan'l Miller" <optikos@verizon.net> writes:
> I am pretty sure that Jeffrey Carter's school of thought would be
> focusing on the “clever run-time devices to avoid excessive copying”

Haskell in fact has mutable arrays just like you're used to, but using
them safely requires treating them as something like i/o devices, so the
array state is threaded through a computation that's separated off from
the rest of your program by the type system.  It's a little bit hard to
explain.  The upshot is that it's there if you need it, but you're
better off avoiding it if you can.

Ben Lippmeier (one of the GHC developers at times) has one of the better
critiques of Haskell's array story, starting on page 17 here:

http://benl.ouroborus.net/papers/2010-impure/lippmeier-impure-world.pdf

Re: How to get Ada to ?cross the chasm??

[G.B.]

On 01.05.18 10:17, Jeffrey R. Carter wrote:
> On 05/01/2018 06:26 AM, Paul Rubin wrote:
>> something like "new_array =  map(square, old_array)".
> 
> What functional language has arrays?
> 

APL does! ;-)

-- 
"HOTDOGS ARE NOT BOOKMARKS"
Springfield Elementary teaching staff

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87o9i2pkcr.fsf@nightsong.com...
...
> Sure, that's like C++ smart pointers and containers.  I'm familiar with
> the approach and it's nice for some purposes, but it still needs a lot
> of attention, and constrains your style quite a lot.

Which is a good thing. It escapes me why spaghetti code is long since 
considered a bad thing, but writing spaghetti data is some sort of 
necessity. "Smart pointers" are rather kick-the-can; the only sensible 
solution is no pointers.

If Ada didn't constrain the sensible ways to get things done, I would 
literally never get anything done. (That was the main reason I came to Ada 
in the first place, to save my from myself in an anything goes environment.)

                                 Randy.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
>> of attention, and constrains your style quite a lot.
> Which is a good thing. It escapes me why spaghetti code is long since 
> considered a bad thing, but writing spaghetti data is some sort of 
> necessity.

I think you and Jeff misunderstood me about style constraining.  I mean
the constraints MAKE you write spaghetti code when you prefer otherwise.
Like if Ada got rid of its structured control flow statements so the
only thing you could use was if...goto, that's the type of style
constraint I'm thinking of.

You might have imagined something like eliminating goto (decreasing
spaghetti instead of increasing it) but I meant it the other way around ;-).

> "Smart pointers" are rather kick-the-can; the only sensible solution
> is no pointers.

A cleaner approach imho is immutable data passed by reference (this is
how most of functional programming works).  It's not really feasible to
code in that style in Ada, as far as I can tell.  Aside from language
issues, I think it's unfeasible without a gc, but maybe I'm wrong.

Re: How to get Ada to ?cross the chasm??

[gautier_niouzes]

Le mardi 1 mai 2018 05:45:08 UTC+2, Paul Rubin a écrit :

> A cleaner approach imho is immutable data passed by reference (this is
> how most of functional programming works).  It's not really feasible to
> code in that style in Ada, as far as I can tell.  Aside from language
> issues, I think it's unfeasible without a gc, but maybe I'm wrong.

What do you miss with unconstrained types? They don't need gc.
Here is an example:
https://sourceforge.net/p/cbsg/code/HEAD/tree/corporate_bullshit.adb
String is just another unconstrained array type.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

gautier_niouzes@hotmail.com writes:
> What do you miss with unconstrained types? They don't need gc....
> String is just another unconstrained array type.

It gets messier when the data contains possibly-circular references to
other data.  If you want to program without GC for spiritual or moral
reasons, then sure, you can do it with enough effort.  If you have to
program without GC for practical reasons (it definitely imposes runtime
costs and you might be on a small system), then unlucky you, you've got
some work to do.  But if you can afford the overhead and just want to
get your program working, then GC makes life much simpler.

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87efiuope8.fsf@nightsong.com...
> gautier_niouzes@hotmail.com writes:
>> What do you miss with unconstrained types? They don't need gc....
>> String is just another unconstrained array type.
>
> It gets messier when the data contains possibly-circular references to
> other data.

Right: "spaghetti data". Again, why is spaghetti data acceptable but 
spaghetti code not acceptable? Data with random references to other data is 
no more structured than code full of gotos. We never allow the latter, why 
allow the former??

                            Randy.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> Right: "spaghetti data". Again, why is spaghetti data acceptable but 
> spaghetti code not acceptable? Data with random references to other data is 
> no more structured than code full of gotos. We never allow the latter, why 
> allow the former??

Here's a complete Haskell program for printing the first 20 prime
numbers, using cyclic data (what you call "spaghetti"):

    main = print . take 20 . sieve $ [2..] where
      sieve (p:xs) = p : sieve [a | a <- xs, a`rem`p /= 0]

The idea is that sieve is a self-referential list, created by taking the
infinite list [2,3,4,5...], and yielding its first element followed by
what you get by (recursively) sieving the result of filtering out
multiples of the first element from the rest of the list.  So the sieve
output is prime numbers.  The program then just takes 20 elements of the
sieve output and prints them.

Obviously there are more efficient algorithms and you could code
something like the above with arrays and loops and whatnot, but the
above was very easy to write.

Here's a harder problem: generate a list of numbers that have no prime
factors bigger than 5.  These are called "Hamming numbers".  The first
20 of them are:

   1 2 3 4 5 6 8 9 10 12 15 16 18 20 24 25 27 30 32 36

Question: what is the 1691st Hamming number?  (Answer: 2125764000, that
was chosen because it's the largest one that fits in 32 bits).  Or if
you have 64-bit ints, what is the 10000th one?  

The page

   http://rosettacode.org/wiki/Hamming_numbers

has a bunch of implementations including in Ada and Haskell.  The
Haskell example ("The classic version") is very simple and fast, using
"spaghetti".  It finds the 1691st and 10000th Hamming numbers instantly,
and the millionth one in about 0.5 seconds on an Intel i5.

Implementing the same algorithm in Ada is of course possible but it's
enough of a pain that whoever wrote the Ada code on that page didn't
even try (maybe someone here can fix that).  Instead it just counts
upwards and tests each number.  It takes about 15 seconds to find the
1691st number on the same machine, and at that rate would take about 64
years to find the 10000th.  It doesn't attempt to find the millionth (it
claims that's just a matter of using bignums, overlooking how long it
would take to count up to the answer, which is around 5e83).

Despite that, the Ada code is still about 5x longer than the Haskell
code.  Fixing the algorithm would likely bloat it by another 2x or so.

So basically it's not "spaghetti", it's having power tools and the
ability to use them.

Re: How to get Ada to ?cross the chasm??

[Mehdi Saada]

Easy ? Easy ?? Maybe for people who do have learnt Haskell and its abstruse syntax. I find the Ada version for prime number way easier to READ.
Your example makes me think about Perl. Quick n' dirty. Especially dirty for future reader.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Mehdi Saada <00120260a@gmail.com> writes:
> Easy ? Easy ?? Maybe for people who do have learnt Haskell and its
> abstruse syntax. I find the Ada version for prime number way easier to
> READ.  Your example makes me think about Perl. Quick n'
> dirty. Especially dirty for future reader.

You get used to the syntax.  The correctness of the Haskell version is
simple to prove by induction.  An Ada implementation of that algorithm
would be longer to code and maybe messy to prove.  Admittedly though,
it's not a very good algorithm so picking a different one is ok.

The Hamming number example would require considerably more machinery.
I'm not even sure how I'd do it in Ada, i.e. maybe with OO.

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87lgd1heva.fsf@nightsong.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> Right: "spaghetti data". Again, why is spaghetti data acceptable but
>> spaghetti code not acceptable? Data with random references to other data 
>> is
>> no more structured than code full of gotos. We never allow the latter, 
>> why
>> allow the former??
>
> Here's a complete Haskell program for printing the first 20 prime
> numbers, using cyclic data (what you call "spaghetti"):
>
>    main = print . take 20 . sieve $ [2..] where
>      sieve (p:xs) = p : sieve [a | a <- xs, a`rem`p /= 0]
>
> The idea is that sieve is a self-referential list, created by taking the
> infinite list [2,3,4,5...], and yielding its first element followed by
> what you get by (recursively) sieving the result of filtering out
> multiples of the first element from the rest of the list.  So the sieve
> output is prime numbers.  The program then just takes 20 elements of the
> sieve output and prints them.

I don't see anything "cyclic" or "self-referential" here. This is just a set 
of lists, and there is nothing particularly interesting about them (in 
partcular, there are *no* references involved in a list unless you need to 
keep a reference to a particular element, certainly doesn't happen here).

There's no particular problem implementing an infinite list in Ada; there 
isn't such a container predefined but it would be relatively easy to write 
one. We did spend some time looking at how the Ada iteration constructs 
would work with such a container and we were pretty certain that they would 
work fine. I don't think an infinite list would do much memory 
allocation/deallocation -- there wouldn't be much reason to actually 
materialize nodes (you have to materialize the elements of course, but those 
are usually copied into/out of a container, so the materialization would be 
short-lived and local).

Ada might be hamstrung here by not having useful lambas, meaning that this 
particular implementation probably wouldn't work. But it's hard to tell...

> Obviously there are more efficient algorithms and you could code
> something like the above with arrays and loops and whatnot, but the
> above was very easy to write.

Of course, only a high priest of programming could possibly understand what 
it does. (Even with your explanation, I can't quite figure how it is 
supposed to actually execute.)

...
>... Instead it just counts upwards and tests each number.  ...
>
> Despite that, the Ada code is still about 5x longer than the Haskell
> code.  Fixing the algorithm would likely bloat it by another 2x or so.

I cannot imagine a sane way to implement an infinite list that would have 
any other effect. (For that matter, any insane way, either.) Ergo, the 
underlying implementation of the Haskell code has to do something like that 
in order to figure out the answers. (There's no free lunch. :-)

> So basically it's not "spaghetti", it's having power tools and the
> ability to use them.

A lot of power tools should never be used by the untrained. (Think of all of 
the chainsaw accidents.) No one should try writing code like you have shown 
here - it's essentially write-only code, and virtually all code is read much 
more than it is written. (Assuming that your code actually gets used at 
all.) Ada, of course, is about readability and maintainability of the 
code -- the need to use tricks is always a bad thing (even when it happens 
in Ada.)

                                   Randy.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> I don't see anything "cyclic" or "self-referential" here. This is just a set 
> of lists, and there is nothing particularly interesting about them (in 
> partcular, there are *no* references involved in a list unless you need to 
> keep a reference to a particular element, certainly doesn't happen here).

This list contains a reference to itself:

    x = 1 : 2 : 3 : x

If you try to print it, you'll see "1,2,3,1,2,3,1,2,3,1,2,3..." ad
infinitum until you interrupt the program.  It is infinitely long, but
occupies a finite amount of memory.

The the prime-generation program, imagine you have a sequence of lists
L1, L2, L3, etc.  We'll split each list into its head (first element)
and tail (rest of the elements).  L1 will be the infinite list

  2, 3, 4, 5 ....

And we can describe that as H1 and T1 (H=head and T=tail), so
H1=2 and T1=[3,4,5...].

Now recursively define H_n to be the first element of T_(n-1) and
T_n to be the result of filtering all the multiples of H_N from the
tail of T_(n-1).  So L2 is  3, 5, 7, etc.  That is, H2=3 and
L2=[5,7,9,...].

Following the recursion, we get H3=5 and L3=[5,7,11,...].  We eliminated
9 because it is a multiple of H3 so we filtered it out.

The primes then are just [H1,H2,H3...] which is what that definition said.

> I don't think an infinite list would do much memory
> allocation/deallocation

Well it depends on what you do with the contents: in the Hamming number
example you do have to keep a lot of them around.

> Ergo, the underlying implementation of the Haskell code has to do
> something like that in order to figure out the answers. (There's no
> free lunch. :-)

Yes, that's exactly right: the burden is moved from the application
programmer to the language implementation.  As an application programmer
who likes to avoid work, I like languages whose implementations do more
of it so that I don't have to.  Or alternatively, using the same amount
of application development effort with such languages, I can write a
program that does more.

> A lot of power tools should never be used by the untrained.

Sure, I agree with this, programming still takes some skill.  But that
Hamming number code isn't particularly mysterious.  Back in the day,
programmers would learn techniques like hash tables, recursion, etc.;
and then when given a problem they would either 1) see a solution from
techniques they knew; or 2) not immediately see a solution and have to
spend more time thinking, studying new techniques or whatever.  In an
interview setting a programmer who didn't understand hash tables might
miss a few questions that hash tables would immediately solve.  The
programmer could then cure the gap in their knowledge by reading about
hash tables in a programming book and working through a few examples.

The picture I'm trying to convey is that functional programming brings
some new techniques that (like hash tables) let you easily solve certain
problems once you know the tricks, that would be hard to solve
otherwise.  The idea of repeatedly filtering a lazily generated list is
one of those tricks, and makes the primes and the Hamming number
solutions very natural.  The well-known intro CS text "Structure and
Interpretation of Computer Programs" (mitpress.mit.edu/sicp) discusses
this trick quite a lot.

I got interested in Haskell about 5 years ago and have spent quite a bit
of time on it on and off since then.  I can report that it's one of the
most interesting things I've ever done as a programmer.  I've learned a
lot and enjoyed it and highly recommend it.  I don't think that it's the
answer to everything (there is no answer to everything, Ada is not the
answer to everything either), but it's a valuable tool to have in one's
toolbox.  If you like a tool and see a problem you can use it on, why
would you look for ways to *not* use it?

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87zi1gz3kl.fsf@nightsong.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> I don't see anything "cyclic" or "self-referential" here. This is just a 
>> set
>> of lists, and there is nothing particularly interesting about them (in
>> partcular, there are *no* references involved in a list unless you need 
>> to
>> keep a reference to a particular element, certainly doesn't happen here).
>
> This list contains a reference to itself:
>
>    x = 1 : 2 : 3 : x

And is illegal in any reasonable programming language... ;-)

> If you try to print it, you'll see "1,2,3,1,2,3,1,2,3,1,2,3..." ad
> infinitum until you interrupt the program.  It is infinitely long, but
> occupies a finite amount of memory.

If you say so. I can't see any sensible way to implement such a thing; 
indeed I would have said it was impossible to implement but apparently you 
have an example to the contrary.

...
>> Ergo, the underlying implementation of the Haskell code has to do
>> something like that in order to figure out the answers. (There's no
>> free lunch. :-)
>
> Yes, that's exactly right: the burden is moved from the application
> programmer to the language implementation.

True, but only if the problem actually matches the language implementation. 
A language like Ada that is built around readability and reuse allows one to 
build things once and use them forever. You're not stuck to just what the 
implementation can do.

> But that Hamming number code isn't particularly mysterious.

Says you. Lists of numbers are not a technique I would think of to do 
anything (partly because it would be so horribly inefficient).

>  Back in the day,
> programmers would learn techniques like hash tables, recursion, etc.;
> and then when given a problem they would either 1) see a solution from
> techniques they knew; or 2) not immediately see a solution and have to
> spend more time thinking, studying new techniques or whatever.

What day was this? I've been programming 40+ years and don't remember any 
time when the average programmer thought about anything. Generally, they 
just started throwing code at the problem until it was solved or the boss 
gave it to someone else. ;-)

That minority of us that engineer software do think about our code before we 
start, but the effort is put on abstraction and organization - the actual 
solution is almost irrelevant to that. Real problems are much larger and 
complex than any simple technique could be used to solve anyway.

...
> The picture I'm trying to convey is that functional programming brings
> some new techniques that (like hash tables) let you easily solve certain
> problems once you know the tricks, that would be hard to solve
> otherwise.

I agree with this, but the problem is the majority of such problems aren't 
realistic in the first place. (Who cares about Hamming numbers?) And most of 
the other techniques can be used just as well in Ada (recursion, for 
instance; the map containers provide hash tables, etc.). Once you get the 
stuff where you need lambdas with closures, you're just writing tricky code 
that only a few (if any) will understand. (Ada is all about building 
long-lived programs; I haven't started a new program in quite a few years, 
just improving existing ones.)

...
> If you like a tool and see a problem you can use it on, why
> would you look for ways to *not* use it?

...but you also have to figure how that fits in with the entire system. 
Pretty much no one is solving simple stand-alone problems. It's a lot harder 
to debug a program that uses a whole bunch of different languages that 
barely work together. You might have one problem that actually would solve 
well in Haskell, but the entire system has dozens of problems and many of 
them aren't likely to be functional in nature (like the GUI to talk to the 
system).

In any case, this is an Ada forum and there isn't point about talking about 
other languages here, other than to point out how Ada is better. ;-)

                          Randy.

Re: How to get Ada to ?cross the chasm??

[Dennis Lee Bieber]

On Fri, 4 May 2018 18:29:17 -0500, "Randy Brukardt" <randy@rrsoftware.com>
declaimed the following:

>"Paul Rubin" <no.email@nospam.invalid> wrote in message 
>news:87zi1gz3kl.fsf@nightsong.com...

>> This list contains a reference to itself:
>>
>>    x = 1 : 2 : 3 : x
>
>And is illegal in any reasonable programming language... ;-)
>
>> If you try to print it, you'll see "1,2,3,1,2,3,1,2,3,1,2,3..." ad
>> infinitum until you interrupt the program.  It is infinitely long, but
>> occupies a finite amount of memory.
>
>If you say so. I can't see any sensible way to implement such a thing; 
>indeed I would have said it was impossible to implement but apparently you 
>have an example to the contrary.
>

	Not as a one-liner... but...

PythonWin 2.7.13 (default, Jun 26 2017, 14:28:43) [MSC v.1500 64 bit
(AMD64)] on win32.
Portions Copyright 1994-2008 Mark Hammond - see 'Help/About PythonWin' for
further copyright information.
>>> x = [1, 2, 3]
>>> x.append(x)
>>> print x
[1, 2, 3, [...]]
>>> 

	Slight difference is that the entire list becomes an element, it is not
a one level sequence of repeating entities (older version of Python would
recursively print until a limit on recursion was reached 

[1, 2, 3, [1, 2, 3, [1, 2, 3, [ etc

-- newer ones detect the recursion and use the [...] notation)


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

Re: How to get Ada to ?cross the chasm??

[Ben Bacarisse]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

> On Fri, 4 May 2018 18:29:17 -0500, "Randy Brukardt" <randy@rrsoftware.com>
> declaimed the following:
>
>>"Paul Rubin" <no.email@nospam.invalid> wrote in message 
>>news:87zi1gz3kl.fsf@nightsong.com...
>
>>> This list contains a reference to itself:
>>>
>>>    x = 1 : 2 : 3 : x
>>
>>And is illegal in any reasonable programming language... ;-)
>>
>>> If you try to print it, you'll see "1,2,3,1,2,3,1,2,3,1,2,3..." ad
>>> infinitum until you interrupt the program.  It is infinitely long, but
>>> occupies a finite amount of memory.
>>
>>If you say so. I can't see any sensible way to implement such a thing; 
>>indeed I would have said it was impossible to implement but apparently you 
>>have an example to the contrary.
>
> 	Not as a one-liner... but...
>
> PythonWin 2.7.13 (default, Jun 26 2017, 14:28:43) [MSC v.1500 64 bit
> (AMD64)] on win32.
> Portions Copyright 1994-2008 Mark Hammond - see 'Help/About PythonWin' for
> further copyright information.
>>>> x = [1, 2, 3]
>>>> x.append(x)
>>>> print x
> [1, 2, 3, [...]]
>>>> 
>
> 	Slight difference is that the entire list becomes an element, it is not
> a one level sequence of repeating entities

I'd say that's more than a slight difference!  If you needed this in
Python you could get close with

>>> import itertools
>>> x=[1,2,3]
>>> x=itertools.cycle(x)

but the result is not a list thought it is, of course, an "iterable".

In Ada:

   type Node;
   type List is access Node;
   type Node is record N: Integer; Next: List; end record;
   ...
   H : List := new Node'(1, new Node'(2, new Node'(3, null)));
   ...
   H.Next.Next.Next := H;

In C:

  typedef struct node { int n; struct node *next; } node;
  ...
  node *x = &(node){ 1, &(node){ 2, &(node){ 3 } } };
  x->next->next->next = x;

My Ada is very rusty, so there may well be much better ways to do this.

-- 
Ben.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
>> If you try to print it, you'll see "1,2,3,1,2,3,1,2,3,1,2,3..."
> If you say so. I can't see any sensible way to implement such a thing;

The semantics are similar to call-by-name parameter passing in Algol 60.
Basically "a : b : c : ..." becomes syntax sugar for a list whose head
is the value a, and whose tail is an unevaluated function call.  As you
iterate down the list, at each iteration you print the head element and
call the tail-generating function.  The tail-generating function gives
you the next element, plus a new tail-generating function that generates
the rest of the tail.  SICP discusses the pattern at length:

http://mitpress.mit.edu/sites/default/files/sicp/full-text/book/book-Z-H-24.html#%_sec_3.5

> In any case, this is an Ada forum and there isn't point about talking about 
> other languages here, other than to point out how Ada is better. ;-)

Ok, fair enough.  I try to be a wide-spectrum programmer who doesn't
believe in single magic bullets that can solve every problem, so I'm
interested in using Ada in its areas of particular strength.  So I got
sidetracked when this thread headed (as I see it) outside of those
areas.  But ok, yeah, I'll try to stay more focused here on Ada's strong
points, thanks. ;-)

I still can't resist posting this article about how its authors
seriously simplified the internals of the optimizing compiler they were
working on, by replacing a central imperative data structure with a
functional one:

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

Even if the technical details don't make sense, the development
experience it describes (dealing with multiple iterations of extending a
bug-prone chunk of code) is likely to be familiar for anyone who has
worked inside a compiler.

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-06 02:35 , Paul Rubin wrote:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
   ...
>> In any case, this is an Ada forum and there isn't point about talking about
>> other languages here, other than to point out how Ada is better. ;-)
>
> Ok, fair enough.

Please note Randy's smiley! I certainly want to see critique of Ada on 
this forum, as well as praise, and most certainly I want to hear about 
languages that solve some problems better than Ada currently does. For 
example, the discussions about Rust memory safety, and memory management 
in general.

> I try to be a wide-spectrum programmer who doesn't
> believe in single magic bullets that can solve every problem, so I'm
> interested in using Ada in its areas of particular strength.

As I see it, when Ada was originally designed to be a wide-spectrum 
language the design was successful in the sense that it covered most 
application areas of the main-stream languages in use at that time; only 
"weird" languages like Lisp and Snobol (as they were seen then) were out 
of scope for the aims of Ada. Today, the spectrum of languages is wider, 
and, in particular, languages that are enabled by garbage collection are 
in common use.

The problem for Ada, today, is that it is very difficult to extend the 
Ada spectrum to cover both its traditional core area -- real-time 
embedded systems -- and the areas where garbage-collected languages 
shine, because of the non-functional issues (time and space consumption) 
that require different approaches at the two ends of the spectrum.

> But ok, yeah, I'll try to stay more focused here on Ada's strong
> points, thanks. ;-)

I see your smiley, and hope you will continue to prod the weak points, too.

> I still can't resist posting this article about how its authors
> seriously simplified the internals of the optimizing compiler they were
> working on, by replacing a central imperative data structure with a
> functional one:
>
> https://www.cs.tufts.edu/~nr/pubs/zipcfg.pdf

I am very attracted by applicative / functional data structures (and try 
to design my Ada programs around such ideas), but they do have a cost 
(or different costs, compared to mutable structures).

That paper describes a nice applicative structure to represent program 
control flow graphs. The central idea is that the structure comes with a 
"focus" that is an edge in the graph, and is the point where the graph 
can be (applicatively) transformed by adding nodes, etc. To traverse the 
graph the focus must be moved, and the paper says that "Movement in any 
direction takes constant time and requires the allocation of two new 
heap objects." Compare that cost (two heap allocations) with traversing 
a pointer...

The end effect of this cost depends on the properties of the algorithms 
applied to the data structure, such as the frequency of graph traversals 
versus the frequency of graph mutations. The paper reports good results 
(the applicative structure decreases execution time about 10%), but 
perhaps other graph algorithms are slower with the applicative structure.

Moving the focus back to Ada, efficient applicative data structures are 
interesting for real-time systems because they could reduce 
locking/blocking times: a "reader task" could quickly grab a (logical) 
immutable copy of a large data structure and read the data at its own 
speed, without interfering with "writer" tasks that transform their own 
(logical) copies of the data structure.

The Ada programs for satellites on which I am currently working often 
meet with such problems, and either work slower (mutual exclusion 
between readers and writers), use more memory (dual physical copies of 
the data structure) and/or pass the problem to the satellite operators 
(commands to mutate the on-board data structure are delayed or failed if 
the data structure is in use by some reader). Better solutions are needed.

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

Re: How to get Ada to ?cross the chasm??

[Dmitry A. Kazakov]

On 2018-05-06 10:34, Niklas Holsti wrote:

> The problem for Ada, today, is that it is very difficult to extend the 
> Ada spectrum to cover both its traditional core area -- real-time 
> embedded systems -- and the areas where garbage-collected languages 
> shine, because of the non-functional issues (time and space consumption) 
> that require different approaches at the two ends of the spectrum.

I disagree. It is not difficult if attention were paid to fixing the 
type system. These areas require an elaborated type system in order to 
be able to create more powerful abstractions without sinking into a mess 
of generic instances.

I don't believe GC is ever needed. It is used to handle ad-hoc low-level 
objects or low-level spaghetti structures, as Randy called them. And a 
low-level network of ad-hoc functions in functional approach is not 
appealing either.

Ada should stop parroting pool language and borrow their mistakes.

> Moving the focus back to Ada, efficient applicative data structures are 
> interesting for real-time systems because they could reduce 
> locking/blocking times: a "reader task" could quickly grab a (logical) 
> immutable copy of a large data structure and read the data at its own 
> speed, without interfering with "writer" tasks that transform their own 
> (logical) copies of the data structure.

You need to merge incoherent copies at some point later. More removed 
the point is, more difficult it becomes and more expensive could be a 
rollback, in case something happens. I have an intuitive feeling that in 
general lock-free approach does not work at large scale and is effective 
only at the low level and tight times.

> The Ada programs for satellites on which I am currently working often 
> meet with such problems, and either work slower (mutual exclusion 
> between readers and writers), use more memory (dual physical copies of 
> the data structure) and/or pass the problem to the satellite operators 
> (commands to mutate the on-board data structure are delayed or failed if 
> the data structure is in use by some reader). Better solutions are needed.

Yes.

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

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-06 12:53 , Dmitry A. Kazakov wrote:
> On 2018-05-06 10:34, Niklas Holsti wrote:
   ...
>> Moving the focus back to Ada, efficient applicative data structures
>> are interesting for real-time systems because they could reduce
>> locking/blocking times: a "reader task" could quickly grab a (logical)
>> immutable copy of a large data structure and read the data at its own
>> speed, without interfering with "writer" tasks that transform their
>> own (logical) copies of the data structure.
>
> You need to merge incoherent copies at some point later.

In my applications, that would not be a big problem. In many cases the 
writers can be serialized, in other cases writers update separate parts 
of the data structure and merging would be easy. Other applications 
could have more problems, but applicative data structures do tend to 
provide high-level, merge-like operations.

> I have an intuitive feeling that in general lock-free approach does
> not work at large scale and is effective only at the low level and
> tight times.

If the data structure is applicative, it does not have to be lock-free. 
The applicative property should make lock holding durations very short 
because the structure looks immutable to pure readers.

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

Re: How to get Ada to ?cross the chasm??

[Dmitry A. Kazakov]

On 2018-05-06 17:32, Niklas Holsti wrote:
> On 18-05-06 12:53 , Dmitry A. Kazakov wrote:
>> On 2018-05-06 10:34, Niklas Holsti wrote:
>    ...
>>> Moving the focus back to Ada, efficient applicative data structures
>>> are interesting for real-time systems because they could reduce
>>> locking/blocking times: a "reader task" could quickly grab a (logical)
>>> immutable copy of a large data structure and read the data at its own
>>> speed, without interfering with "writer" tasks that transform their
>>> own (logical) copies of the data structure.
>>
>> You need to merge incoherent copies at some point later.
> 
> In my applications, that would not be a big problem. In many cases the 
> writers can be serialized, in other cases writers update separate parts 
> of the data structure and merging would be easy. Other applications 
> could have more problems, but applicative data structures do tend to 
> provide high-level, merge-like operations.

Maybe it is not a structure, but a set of assorted buckets of data? 
Maybe a simple monitor task with a queue would do the job? Whatever it 
is under real-time constraint you need to have each update visible 
within some bounded time interval.

>> I have an intuitive feeling that in general lock-free approach does
>> not work at large scale and is effective only at the low level and
>> tight times.
> 
> If the data structure is applicative, it does not have to be lock-free. 
> The applicative property should make lock holding durations very short 
> because the structure looks immutable to pure readers.

"Applicative" is not a substantial property that hints any concrete 
implementation of publisher/subscribers bound through the data 
structure. If Ada should do anything, then provide much better support 
for user ADTs than it has now.

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

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-06 20:40 , Dmitry A. Kazakov wrote:
> On 2018-05-06 17:32, Niklas Holsti wrote:
>> On 18-05-06 12:53 , Dmitry A. Kazakov wrote:
>>> On 2018-05-06 10:34, Niklas Holsti wrote:
>>    ...
>>>> Moving the focus back to Ada, efficient applicative data structures
>>>> are interesting for real-time systems because they could reduce
>>>> locking/blocking times: a "reader task" could quickly grab a (logical)
>>>> immutable copy of a large data structure and read the data at its own
>>>> speed, without interfering with "writer" tasks that transform their
>>>> own (logical) copies of the data structure.
>>>
>>> You need to merge incoherent copies at some point later.
>>
>> In my applications, that would not be a big problem. In many cases the
>> writers can be serialized, in other cases writers update separate
>> parts of the data structure and merging would be easy. Other
>> applications could have more problems, but applicative data structures
>> do tend to provide high-level, merge-like operations.
>
> Maybe it is not a structure, but a set of assorted buckets of data?

Both cases occur in satellite SW. An example of the former case 
(structure) is various forms of configuration data (some people may know 
the acronym "PUS") that guide the real-time processing but are also 
subject to changes from ground commands. An example of the latter case 
(buckets) is the so-called "data pool" that stores data acquired from 
various SW and HW sources, with various sampling periods, and is 
periodically monitored and reported (telemetered) and sporadically used 
for computations and control decisions.

> Whatever it is under real-time constraint you need to have each
> update visible within some bounded time interval.

Visibility is not often a problem; stability is. A reader task must 
usually be provided with data that are stable and coherent for the 
duration of the reader task job, even if higher-priority, 
higher-frequency writer tasks need to update the data concurrently.

>>> I have an intuitive feeling that in general lock-free approach does
>>> not work at large scale and is effective only at the low level and
>>> tight times.
>>
>> If the data structure is applicative, it does not have to be
>> lock-free. The applicative property should make lock holding durations
>> very short because the structure looks immutable to pure readers.
>
> "Applicative" is not a substantial property that hints any concrete
> implementation of publisher/subscribers bound through the data
> structure. If Ada should do anything, then provide much better support
> for user ADTs than it has now.

An applicative data structure is a data structure that can be mutated 
only by constructing what seems to be a modified copy of the entire 
original data structure, but without actually copying most of the data, 
and leaving the original data structure available unmodified.

In other words, a mutated version of the structure can be constructed 
only by applying a function to the original version, with the function 
returning the mutated version without harm to the original version.

Such data structures tend to be based on "structure sharing" through 
internal pointers that are not visible to the clients. In functional 
languages with garbage collection these pointers are managed 
automatically. In present Ada, the implementor of an applicative data 
structure must manage the structure-sharing pointers explicitly, perhaps 
with the help of controlled types.

I don't know how to extend Ada to make applicative data structures 
easier to implement in Ada.

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

Re: How to get Ada to ?cross the chasm??

[Dmitry A. Kazakov]

On 2018-05-06 21:27, Niklas Holsti wrote:

>> "Applicative" is not a substantial property that hints any concrete
>> implementation of publisher/subscribers bound through the data
>> structure. If Ada should do anything, then provide much better support
>> for user ADTs than it has now.
> 
> An applicative data structure is a data structure that can be mutated 
> only by constructing what seems to be a modified copy of the entire 
> original data structure, but without actually copying most of the data, 
> and leaving the original data structure available unmodified.

That is not a visible property the client may or should see.

> In other words, a mutated version of the structure can be constructed 
> only by applying a function to the original version, with the function 
> returning the mutated version without harm to the original version.

This is easily done in present Ada using handles to a reference-counted 
objects. The client copies a handle to the structure or its atomic part. 
So long it holds the handle its view remain intact. The writer 
overwrites the publicly visible handle with a new instance which has no 
effect on the client. When the client drops the handle the old version 
is collected (or not in some cases where memory is managed in a 
different way).

> Such data structures tend to be based on "structure sharing" through 
> internal pointers that are not visible to the clients. In functional 
> languages with garbage collection these pointers are managed 
> automatically. In present Ada, the implementor of an applicative data 
> structure must manage the structure-sharing pointers explicitly, perhaps 
> with the help of controlled types.

As I said it is quite easy and I used the described approach many times, 
e.g. for dealing with decision trees.

> I don't know how to extend Ada to make applicative data structures 
> easier to implement in Ada.

I have a few points. The key issues are:

1. Interface inheritance. The handle must have the same interface as the 
target object. It is tedious to write each time:

    type Node_Interface is interface;
    ... node operations

    type Node_Object is ... and Node_Interface with ...;
    type Node_Handle is ... and Node_Interface with null record;

2. Delegation.

2.a. Node_Handle must automatically delegate interface calls to its target.

2.b. Node_Handle interface calls might wish to take a mutex in the 
prologue and release it in the epilogue. Such trivial methods of 
composition must be supported.

3. Sane constructors and destructors

4. Sane user-defined aggregates

5. Parallel hierarchies handling

6. Sane handling of assignment, without controlled helper type kludges 
and access types. In particular, deference + update must be delegated to 
procedure and not split into two operations.

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> This is easily done in present Ada using handles to a
> reference-counted objects.

That's not much different from gc from the user's perspective, other
than problems handling cycles.  Once you can use refcounting then most
of the standard applicative data structures (at least those intended for
strict evaluation)should work.

Re: How to get Ada to ?cross the chasm??

[Dmitry A. Kazakov]

On 07/05/2018 03:31, Paul Rubin wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> This is easily done in present Ada using handles to a
>> reference-counted objects.
> 
> That's not much different from gc from the user's perspective, other
> than problems handling cycles.

Cycles are easily avoidable too by separating target objects and 
handles. All target objects types go into the private part of the 
package. When only handles are visible there is no way the end user 
could construct a cycle.

The difference to GC is determinism and efficiency. You don't need to 
lock in order to decide if the object must be reclaimed.

If the overhead and non-determinism of GC is OK, then of course there 
would be no problem with adding detection of cycles in reference counted 
object. I did that for an implementation of graphs, not a big deal at all.

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> The difference to GC is determinism and efficiency. You don't need to
> lock in order to decide if the object must be reclaimed.

I don't see it.  I saw the word "lock" and thought you meant a
concurrency lock, but I think you mean the notorious GC pause.  Yes that
was a noticible issue in the 1980s but it's much less of one now.  In
any case, something similar happens with refcounting: if you drop the
last reference to a large structure, you have to recursively traverse
the structure to decrement the refcount of everything that the structure
contains pointers to.  So you still get arbitrarily long pauses.

There are in fact realtime gc algorithms with guaranteed upper bounds on
pause length, though they aren't used that often because conventional
algorithms work well enough and have better overall performance.  A
non-realtime system won't notice a millisecond pause now and then, and a
realtime system better not use refcounting either.

Refcounting is also less efficient than gc because of the need to
twiddle the refcounts all the time.  That's especially expensive in
multiprocessor systems since you have to protect every refcount
operation with a lock.  (C++ std::shared_ptr refcounts have such a lock and
it's slow as heck)

There has been more than a decade of pain in the Python community over
this.  CPython (the main implementation of Python) wraps a "Global
interpreter lock" (GIL) around the whole interpreter, which means the
threads of a multi-threaded Python program don't run in parallel even on
multicore computers.  The GIL can't be removed because the overhead of
locking all the refcount operations would slow down the interpreter too
much.  And Python's refcount system can't be replaced by a GC because of
the vast amount of C extensions that would have to be updated to no
longer deal with the refcounts.  Alternate Python implementations like
IronPython and MicroPython do in fact use GC and it's much nicer that
way.

Regarding concurrency: any concurrent system is non-deterministic by
definition.  So handling non-determinisism is simply part of the deal
when you find yourself writing a concurrent program.

Re: How to get Ada to ?cross the chasm??

[Dmitry A. Kazakov]

On 2018-05-07 19:49, Paul Rubin wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> The difference to GC is determinism and efficiency. You don't need to
>> lock in order to decide if the object must be reclaimed.
> 
> I don't see it.  I saw the word "lock" and thought you meant a
> concurrency lock,

This too, because when the last reference count is zeroed it is only one 
task that is still aware of the object, therefore its finalization can 
be done without locking.

> but I think you mean the notorious GC pause.  Yes that
> was a noticible issue in the 1980s but it's much less of one now.  In
> any case, something similar happens with refcounting: if you drop the
> last reference to a large structure, you have to recursively traverse
> the structure to decrement the refcount of everything that the structure
> contains pointers to.  So you still get arbitrarily long pauses.

No, because I know the structures I deal with and can avoid that 
choosing proper design.

> There are in fact realtime gc algorithms with guaranteed upper bounds on
> pause length, though they aren't used that often because conventional
> algorithms work well enough and have better overall performance.  A
> non-realtime system won't notice a millisecond pause now and then, and a
> realtime system better not use refcounting either.

Millisecond is very long for many applications, especially when 
interlocking is involved which leads to priority inversion and other 
nasty effects at the places you expect it least.

> Refcounting is also less efficient than gc because of the need to
> twiddle the refcounts all the time.  That's especially expensive in
> multiprocessor systems since you have to protect every refcount
> operation with a lock.

1. It is three machine instructions load; increment-and-swap; branch if 
zero, when done in a lock-free manner. Except for very hard real-time it 
OK to have a second and even a third attempt.

2. In Ada controlled objects are by reference. Therefore you will not 
change the count when passing handles as argument to subprograms. This 
is as efficient as it can be.

> Regarding concurrency: any concurrent system is non-deterministic by
> definition.  So handling non-determinisism is simply part of the deal
> when you find yourself writing a concurrent program.

Why? Determinism means same output/behavior for same input. Concurrency 
introduces non-determinism only in presence of race conditions. BTW, GC 
is a perfect source of race conditions.

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> This too, because when the last reference count is zeroed it is only
> one task that is still aware of the object, therefore its finalization
> can be done without locking.

The big object contains many references to other objects, and those
objects' refcounts don't necessarily become zero when the big object's
last reference goes away.  They all have to be updated while other tasks
might be simultaneously updating them.

>> So you still get arbitrarily long pauses.
> No, because I know the structures I deal with and can avoid that
> choosing proper design.

In other words you are manually managing memory, which is what
refcounting is supposed to get you out of.  If you spent even one minute
figuring out that proper design, that's a minute that a GC-using
programmer could have spent doing something productive.

> Millisecond is very long for many applications,

In such a system you better not use a refcount scheme either, without a
WCET analysis.

I'd add as well: most refcount systems I know of don't move objects
around in memory, so you get memory fragmentation and high cache miss
rates.  GC systems typically compact the heap when the GC runs, with
heap sizes chosen so that "minor" collections put the most recently
allocated (and in practice most frequently used) part of the heap into
the processor's L2 cache.

> 1. It is three machine instructions load; increment-and-swap; branch
> if zero, when done in a lock-free manner.

What processor do you mean, that has an increment-and-swap instruction?
I don't think the x86 has this.  You would use LOCK CMPXCHG which is
quite slow.

> Why? Determinism means same output/behavior for same
> input. Concurrency introduces non-determinism only in presence of race
> conditions.

Concurrency means that the program responds to input from multiple
independent sources whose timing is outside of the program's control.
That's non-deterministic by definition.  "Same output/behavior for same
input" doesn't mean much because you can't expect to ever get the same
input.  For a concurrent program to be correct, it must correctly handle
every possible interleaving of input events.

There is no deterministic timing in anything nontrivial either, again
because of caches in the memory system and the i/o peripherals.  Even
without caching there is no determinism.  In the old days of rotating
hard disks, the latency of a read operation would vary slightly because
of the motion of air molecules inside the drive, i.e. it was affected by
thermal noise.  This was sometimes used a source of physical random data
to seed random number generators in software systems.

So when multiprocessors and critical timing are involved, determinism in
real-world programming simply doesn't exist.  Any concurrency scheme or
WCET analysis must take this into account.

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87po27fbv9.fsf@nightsong.com...
...
> I'd add as well: most refcount systems I know of don't move objects
> around in memory, so you get memory fragmentation and high cache miss
> rates.  GC systems typically compact the heap when the GC runs, ...

That would be extreme hard to do with Ada, since you'd have to avoid moving 
anything that is "pinned" by a representation clause, anything that uses 
'Address (unless you are prepared to follow that into all possible places), 
and anything imported/exported. You'd also have to be prepared to adjust 
'Access/'Unchecked_Access of aliased components. Sounds like a nightmare.

Similarly, figuring out what is reachable sounds like a nightmare, with 
local access objects of various kinds, access objects that point to stack 
objects, access values that come from foreign languages (i.e. C), and 
various tasking issues.

And of course the finalization issue mentioned before.

One could probably implement GC that worked for some subset of objects, but 
for the full language that seems both difficult and worthless (the latter 
because finalizing early is not allowed, so you could really only collect 
objects with trivial finalization).

                                           Randy.

Re: How to get Ada to ?cross the chasm??

[Dmitry A. Kazakov]

On 07/05/2018 22:29, Paul Rubin wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> This too, because when the last reference count is zeroed it is only
>> one task that is still aware of the object, therefore its finalization
>> can be done without locking.
> 
> The big object contains many references to other objects, and those
> objects' refcounts don't necessarily become zero when the big object's
> last reference goes away.

If referenced object counts are > 1 they are not going to be finalized. 
So the point stands, no locking is ever required upon finalization.

>>> So you still get arbitrarily long pauses.
>> No, because I know the structures I deal with and can avoid that
>> choosing proper design.
> 
> In other words you are manually managing memory, which is what
> refcounting is supposed to get you out of.

For big objects, yes, because default methods fail. For large objects 
there is usually additional knowledge about their allocation order which 
is not available for the compiler, e.g. a LIFO order etc. This allows a 
much more effective and simple memory management than making forward 
references, backward references, strong references, weak references 
straight.

> If you spent even one minute
> figuring out that proper design, that's a minute that a GC-using
> programmer could have spent doing something productive.

Not at all. This is an old discussion about up-front analysis and design 
vs. "spinal-cord-programming". Ada was designed for people who do not 
consider investing their time in software design useless.

>> Millisecond is very long for many applications,
> 
> In such a system you better not use a refcount scheme either, without a
> WCET analysis.
> 
> I'd add as well: most refcount systems I know of don't move objects
> around in memory, so you get memory fragmentation and high cache miss
> rates.  GC systems typically compact the heap when the GC runs, with
> heap sizes chosen so that "minor" collections put the most recently
> allocated (and in practice most frequently used) part of the heap into
> the processor's L2 cache.

You get fragmentation due to excessive use of pointers and not caring 
about memory management in the first place.

I don't want objects moving in the memory that is for sure. It is a huge 
distributed performance hit because all pointers must be managed in all 
tasks and in all container objects. It is wasting resources per 
definition, because moving object solves no actual problem space issue, 
it is a purely an artifact of faulty implementation.

>> 1. It is three machine instructions load; increment-and-swap; branch
>> if zero, when done in a lock-free manner.
> 
> What processor do you mean, that has an increment-and-swap instruction?
> I don't think the x86 has this.  You would use LOCK CMPXCHG which is
> quite slow.

On Intel it could be fetch-and-add. Anything a modern processor has is 
in order of magnitude faster than any GC implementation, even taking and 
releasing the spin lock, should the processor had no atomic instructions 
at all, is greatly faster. And the impact is further diminished when 
penalties for dereferencing managed pointers while locking the target 
from being moved is taken into account.

>> Why? Determinism means same output/behavior for same
>> input. Concurrency introduces non-determinism only in presence of race
>> conditions.
> 
> Concurrency means that the program responds to input from multiple
> independent sources whose timing is outside of the program's control.

No, that is irrelevant. Determinism is a property of the system and not 
of its inputs. Consider it a black box. You feed the inputs and get the 
outputs. How many little threads are in the box does not matter.

[...]
> So when multiprocessors and critical timing are involved, determinism in
> real-world programming simply doesn't exist.  Any concurrency scheme or
> WCET analysis must take this into account.

It is a fallacy argument. All physical world is non-deterministic, yet 
it is no problem to create a deterministic system out of stochastically 
misbehaving atoms and molecules.

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> If referenced object counts are > 1 they are not going to be
> finalized. So the point stands, no locking is ever required upon
> finalization.

I'm still perplexed by this.  You have to decrement all those refcounts.
While this is happening, other threads may also be messing with them.
You need locks (at least in the form of atomic instructions which work
by hardware locks, i.e. that are much slower than normal instructions)
to prevent data races.

When you decrement the counts, some of them might reach zero so their
objects need freeing (and traversal).  That too can be arbitrarily
complicated.  Niklas mentions you can possibly do that incrementally,
but that sounds complicated and GC algorithms can also do that.  So I
don't see wy not use one.

> For large objects there is usually additional knowledge about their
> allocation order which is not available for the compiler

Meh, maybe, though it's unclear whether this will help enough to care
about in practice, so it would have to be justified by concrete evidence
on a case by case basis.

> Not at all. This is an old discussion about up-front analysis and
> design vs. "spinal-cord-programming". Ada was designed for people who
> do not consider investing their time in software design useless.

But in this case it sounds like you're burning the effort on solving a
problem that someone else already solved.  Like if your application has
a matrix and you need its inverse, you can call a general purpose matrix
solver from a math library, or you can write a special one that uses
some property of your application's matrix.

Will the special solver be of practical benefit even if it's somehow
objectively better (like saving a cpu-millisecond when it's called once
a week)?  Very possibly not.  Even on your specific problem, will it
*actually* beat the general purpose solver that was optimized for years
by specialist numerics geeks?  Again very possibly not.  I believe the
default presumption is to prefer the general purpose one.  For one thing
you don't have to redesign it when your application changes and the
matrix now has different properties.

GC is like the general purpose math library, highly tuned and optimized,
probably adequate for specific problems even when you can find a way to
beat it, which you might not be able to.  Why spend your time on the
one-off solution before encountering concrete problems with the general
one?

> I don't want objects moving in the memory that is for sure. It is a
> huge distributed performance hit

There's enough experience with these GC's that a claim of a significant
performance hit is only credible if it's backed by profile data showing
the GC is taking too much time for that app.  The usual advice for Java
is configure the GC so it's using around 10% of the cpu cycles (assuming
you have enough memory).  Even if a non-defragmenting scheme uses 0% of
the cycles, you're likely to lose more than 10% to cache misses that a
compacting scheme prevents.

So for a particular program, this question can only be definitely
answered with benchmarks, but the general pattern of observations over
lots of different programs is that the GC tends to win.

> On Intel it could be fetch-and-add. Anything a modern processor has is
> in order of magnitude faster than any GC implementation,

Ok, it looks like there's LOCK XADD, though that's less powerful than
LOCK CMPXCHG.  You need the LOCK prefix either way, but it does look to
me that on recent x86's, LOCK is less expensive than I remembered, so
maybe you're onto something.  LOCK CMPXCHG on Skylake-X has 10 cycle
latency vs 9 cycles for LOCK XADD according to p. 252 of
http://agner.org/optimize/instruction_tables.pdf .  That's actually
pretty good, I thought it was much worse.  But ordinary ADD is 1 cycle
and can often be overlapped with other instructions.

> No, that is irrelevant. Determinism is a property of the system and
> not of its inputs. Consider it a black box. You feed the inputs and
> get the outputs. How many little threads are in the box does not
> matter.

The system includes the program and its input sources.  My usual picture
of a concurrent system is a network server connected to 1000s of clients
over the internet.  So the internet and its random delays are part of
the system.  It can't be seen as deterministic in any useful way.

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-09 08:02 , Paul Rubin wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> If referenced object counts are > 1 they are not going to be
>> finalized. So the point stands, no locking is ever required upon
>> finalization.
>
> I'm still perplexed by this.  You have to decrement all those refcounts.
> While this is happening, other threads may also be messing with them.
> You need locks (at least in the form of atomic instructions which work
> by hardware locks, i.e. that are much slower than normal instructions)
> to prevent data races.

But the atomic instructions are usually much faster than a kernel lock.

> When you decrement the counts, some of them might reach zero so their
> objects need freeing (and traversal).  That too can be arbitrarily
> complicated.  Niklas mentions you can possibly do that incrementally,
> but that sounds complicated

As I recall, the method is that if you find that an object's reference 
count becomes zero, but you don't want to spend time *right now* to 
recursively decrement references from that object, you add the object to 
a global list of "garbage objects", and handle it later, as your 
recycling budget allows, or if no other memory is left. Not very 
complex, but one would have to prove that there is enough time to 
recycle objects "in the background" without hampering real-time 
behaviour, which is perhaps not so easy. But real-time GC is more 
complex, I believe.

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> But the atomic instructions are usually much faster than a kernel lock.

They're not as bad as I thought.  I remembered timings like 100 cycles,
which on a superscalar machine is enough for several hundred
instructions.  But Agner Fog's optimization guide gives figures like 10
cycles for recent Intel cpus.  I'm quite impressed by that and wonder
what happens when multiple cpu sockets are involved.

Re: How to get Ada to ?cross the chasm??

[Dmitry A. Kazakov]

On 09/05/2018 07:02, Paul Rubin wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> If referenced object counts are > 1 they are not going to be
>> finalized. So the point stands, no locking is ever required upon
>> finalization.
> 
> I'm still perplexed by this.  You have to decrement all those refcounts.
> While this is happening, other threads may also be messing with them.

Yes, but you cannot increment a count without holding another increment 
on it. Thus the count is already > 1 when another task tries to 
increment it. Therefore my decrement will never result in 0.

> You need locks (at least in the form of atomic instructions which work
> by hardware locks, i.e. that are much slower than normal instructions)
> to prevent data races.

That is right, but the only penalty you get is probably spilling the 
cache, while other methods would require full locking, possibly context 
switches and necessarily priority inversion and increasing granularity.

> When you decrement the counts, some of them might reach zero so their
> objects need freeing (and traversal).  That too can be arbitrarily
> complicated.

Yes, if you have a long chain of references which all go to zero. I 
would argue that this is bad design from the start.

1. As Niklas said deep nesting alone is a problem.

2. If all references go coherently, then they need not to be there and 
should be merged into a single holder. Ada's protected object is quite 
handy to design elaborated locks. I used to have designs where 
publisher/subscriber services, enumeration, locking and reference 
counting were handled by one protected type.

>> For large objects there is usually additional knowledge about their
>> allocation order which is not available for the compiler
> 
> Meh, maybe, though it's unclear whether this will help enough to care
> about in practice, so it would have to be justified by concrete evidence
> on a case by case basis.

Yes, that is a point too. There is no universal solution to the problem, 
only a toolbox of means to advance it. GC does not fit into my toolbox.

>> Not at all. This is an old discussion about up-front analysis and
>> design vs. "spinal-cord-programming". Ada was designed for people who
>> do not consider investing their time in software design useless.
> 
> But in this case it sounds like you're burning the effort on solving a
> problem that someone else already solved.  Like if your application has
> a matrix and you need its inverse, you can call a general purpose matrix
> solver from a math library, or you can write a special one that uses
> some property of your application's matrix.

My argument is that GC is never a solution, but an attempt to sweep 
unsolved problems under the carpet.

>> I don't want objects moving in the memory that is for sure. It is a
>> huge distributed performance hit
> 
> There's enough experience with these GC's that a claim of a significant
> performance hit is only credible if it's backed by profile data showing
> the GC is taking too much time for that app.  The usual advice for Java
> is configure the GC so it's using around 10% of the cpu cycles (assuming
> you have enough memory).  Even if a non-defragmenting scheme uses 0% of
> the cycles, you're likely to lose more than 10% to cache misses that a
> compacting scheme prevents.

I doubt any such measures, being useless as they are for having no 
predictive force, are even methodically correct. It is incredibly 
difficult to estimate the time spent by the clients of GC. What is 
measured is probably the GC task with all distributed overhead in the 
clients and the overhead of the overall design uncounted. The question 
of the effect on the time granularity is not answered at all.

>> No, that is irrelevant. Determinism is a property of the system and
>> not of its inputs. Consider it a black box. You feed the inputs and
>> get the outputs. How many little threads are in the box does not
>> matter.
> 
> The system includes the program and its input sources.

That is the system in the loop. It is useless to talk about its 
properties because there is no means to observe them - all inputs and 
outputs are consumed.

> My usual picture
> of a concurrent system is a network server connected to 1000s of clients
> over the internet.  So the internet and its random delays are part of
> the system.  It can't be seen as deterministic in any useful way.

It cannot be seen in any useful way. A useful way could be a client view 
on the system and its parts.

BTW, when you reading a true random generator output, that is 
deterministic even if the values are random. And conversely, when you 
transport a sequence of natural numbers over a channel with random 
delays, the sequence is still deterministic.

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> You need locks (at least in the form of atomic instructions
> That is right, but the only penalty you get is probably spilling the
> cache

Oh ok, yeah, if you meant atomic increments the whole time, that clears
up some confusion.  The cache spill cost (around 10 cycles, as posted
elsewhere) is much smaller than software locks, though still much larger
than ordinary arithmetic.  As mentioned earlier, the cost of atomic
refcount operations has proved too expensive for Python, though Python
uses refcounts far more extensively than an Ada application likely
would.

The Python tests of atomic refcount operations were done some years ago
so it might be worth trying them again with present-day hardware, hmm.

> Yes, if you have a long chain of references which all go to zero. I
> would argue that this is bad design from the start.

I don't see the problem with a long chain of references per se: linked
lists are another ancient data structure and there's nothing wrong with
having a long one or managing its storage automatically.  That was done
all the time in Lisp.  Obviously anything that potentially required
traversing the list would have a WCET problem.

> It is incredibly difficult to estimate the time spent by the clients
> of GC. What is measured is probably the GC task with all distributed
> overhead in the clients and the overhead of the overall design
> uncounted.

Hmm, this is an interesting claim that I won't say is wrong, but I
haven't heard it before and am surprised by it and am skeptical.  I've
always just run the profiler and believed when it said the program was
spending X% of its time in GC.  Profiling usually works by sampling the
CPU program counter to identify the busy parts of the code.  I don't
know where the other overhead would come from.  There's overhead
inherent in using a given data structure (say a search tree instead of a
hash table) but I wouldn't ascribe that to the GC.  The GC just makes it
easier to choose that type of structure.

As for weak pointers, it looks like C++ std::shared_ptr/weak_ptr
actually involves two objects in the heap.  There's the controlled
object itself, and there's the shared_ptr structure.  The shared_ptr
structure contains a pointer to the controlled object, plus the count of
strong references and the count of weak references.  When the strong
refcount goes to zero, the controlled object is freed, but the
shared_ptr structure must be kept until both counts go to zero (so that
you can tell whether a weak reference is still alive).  If Ada weak
pointers work the same way, this sounds like yet more storage
management, plus there is still the overhead of adjusting refcounts all
the time.

So I'm still skeptical that this can beat a GC approach, where pointers
are just ordinary machine words that can be copied freely, their types
tracked statically at compile time, and with no atomic operations needed
except while the GC is running.  I wonder if there's a reasonable way to
benchmark a comparison.

Fwiw I don't see anything in Ada95 Distilled about how to manage weak
references or adjust refcounts automatically, but maybe GNAT has
libraries for that.

Re: How to get Ada to ?cross the chasm??

[Dmitry A. Kazakov]

On 2018-05-09 23:33, Paul Rubin wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> You need locks (at least in the form of atomic instructions
>> That is right, but the only penalty you get is probably spilling the
>> cache
> 
> Oh ok, yeah, if you meant atomic increments the whole time, that clears
> up some confusion.  The cache spill cost (around 10 cycles, as posted
> elsewhere) is much smaller than software locks, though still much larger
> than ordinary arithmetic.  As mentioned earlier, the cost of atomic
> refcount operations has proved too expensive for Python, though Python
> uses refcounts far more extensively than an Ada application likely
> would.
> 
> The Python tests of atomic refcount operations were done some years ago
> so it might be worth trying them again with present-day hardware, hmm.

[ Since versions of Python are not compatible and ridden with bugs there 
is little use in whatever measurements on its implementation. ]

>> Yes, if you have a long chain of references which all go to zero. I
>> would argue that this is bad design from the start.
> 
> I don't see the problem with a long chain of references per se: linked
> lists are another ancient data structure and there's nothing wrong with
> having a long one or managing its storage automatically.  That was done
> all the time in Lisp.

See, if they do that in Lisp it is a good advise to do otherwise! (:-))

Low-level lists should not use reference-counting. E.g. I frequently 
allocate lists in an arena pool. I also have a list design with all 
pointers hidden inside the storage pool.

>> It is incredibly difficult to estimate the time spent by the clients
>> of GC. What is measured is probably the GC task with all distributed
>> overhead in the clients and the overhead of the overall design
>> uncounted.
> 
> Hmm, this is an interesting claim that I won't say is wrong, but I
> haven't heard it before and am surprised by it and am skeptical.  I've
> always just run the profiler and believed when it said the program was
> spending X% of its time in GC.  Profiling usually works by sampling the
> CPU program counter to identify the busy parts of the code.  I don't
> know where the other overhead would come from.  There's overhead
> inherent in using a given data structure (say a search tree instead of a
> hash table) but I wouldn't ascribe that to the GC.  The GC just makes it
> easier to choose that type of structure.

I would say that about 80% of all time measurements are plain wrong. The 
80% of the rest 20% are subtly wrong. It does not matter much if the 
measurement is intended for benchmarking, because the relation of two 
wrong measurements is still right, at least in the sign. Or even in one 
significant digit, if you are lucky (:-)).

But measuring GC vs. alternative memory management must be exact and it 
is a very difficult problem in itself.

> As for weak pointers, it looks like C++ std::shared_ptr/weak_ptr
> actually involves two objects in the heap.  There's the controlled
> object itself, and there's the shared_ptr structure.  The shared_ptr
> structure contains a pointer to the controlled object, plus the count of
> strong references and the count of weak references.  When the strong
> refcount goes to zero, the controlled object is freed, but the
> shared_ptr structure must be kept until both counts go to zero (so that
> you can tell whether a weak reference is still alive).  If Ada weak
> pointers work the same way, this sounds like yet more storage
> management, plus there is still the overhead of adjusting refcounts all
> the time.

That depends on the implementation. I keep the list of weak references 
in the object itself, so there is no heap memory involved. The weak 
reference is a limited controlled type, of course.

> So I'm still skeptical that this can beat a GC approach, where pointers
> are just ordinary machine words that can be copied freely, their types
> tracked statically at compile time, and with no atomic operations needed
> except while the GC is running.  I wonder if there's a reasonable way to
> benchmark a comparison.

If you can track pointers statically you need no pointers at all. You 
just tack the objects instead.

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

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:pd0ukp$7mu$1@gioia.aioe.org...
> On 2018-05-09 23:33, Paul Rubin wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
...
>>> It is incredibly difficult to estimate the time spent by the clients
>>> of GC. What is measured is probably the GC task with all distributed
>>> overhead in the clients and the overhead of the overall design
>>> uncounted.
>>
>> Hmm, this is an interesting claim that I won't say is wrong, but I
>> haven't heard it before and am surprised by it and am skeptical.

At least in a language like Ada, reachability tracking is itself a 
complicated problem. One needs some sort of code thunk or data structure to 
be able to find all of the stand-alone access objects/parameters (these are 
the ones that root data structures), including the ones buried in private 
types. The overhead of such a structure/code is clearly outside of the GC 
modules themselves (it has to belong to the compiled user code, so it 
doesn't get picked up by standard profiling). Whether that overhead is 
mainly in time or mainly in spaace can be traded off, but that won't change 
for a particular implementation (implementing that once surely is enough).

Comparing that to an environment that doesn't use GC is always going to be 
difficult. On top of which, one really ought to include any extra overhead 
incurred in explicit storage management (finalization, for instance) if one 
was going to get a really fair answer. This is a tough problem, any real 
answer would only be valid for a particular pair of programs.

I personally prefer to have my complications explicit, so I can attack them 
if performance improvement is needed. YMMV.

                               Randy.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> [ Since versions of Python are not compatible and ridden with bugs
> there is little use in whatever measurements on its implementation. ]

Sorry but I have to notice that every day, far more practical Python
code is being written than practical Ada code.  Sure Python 3 is
incompatible with Python 2, but nowhere near as incompatible as Algol 68
was with Algol 60.  Sure Python programs have bugs, but if you're like
most people who drive a car to work every day, you accept a nonzero
probability that your car won't start because you don't want to pay for
an ultra-reliable car built to NASA specifications.  Ada in the
practical world is an unpopular competitor to Python for similar
reasons.  

Anyway, the observation about locks affecting refcount manipulation
timing has nothing to do with the surrounding application.

> Low-level lists should not use reference-counting. E.g. I frequently
> allocate lists in an arena pool.

So you delete all the lists at the same time?  What if you have two
5-element lists, (a b x y z) and (c d x y z) where both share the same
3-element tail?  You might be finished with the first while wanting to
continue using the second.  Even if you disallow circular lists, you
still probably want something like refcounting.

> But measuring GC vs. alternative memory management must be exact and
> it is a very difficult problem in itself.

It doesn't sound difficult for a short benchmark if you have enough
memory.  You can turn off GC completely, so when you allocate memory it
is never freed until the benchmark finishes.  Then the GC time is zero
and you can compare the runtime to running the same program with the GC
enabled.  Although, it might be faster with GC turned on, because of
caching.

Ben Zorn in the 1990s did a lot of tests where he captured complete
execution traces of programs using different GC methods.  It should be
possible to classify all the primitive operations in a trace and count
up the ones that are part of GC.  I don't know if he did that though.

> That depends on the implementation. I keep the list of weak references
> in the object itself, so there is no heap memory involved.

Do you mean a count of weak references (along with the count of strong
references), or do you chain all the weakrefs together somehow, so you
can find them all and invalidate them when the object is freed?

> If you can track pointers statically you need no pointers at all. You
> just track the objects instead.

I mean the compiler knows the memory layout of each datatype, so if the
datatype contains pointers, it knows where they are, and it knows the
types of the pointed-to objects.  That means starting from some known
objects with known types, the GC can recursively find all the reachable
objects and reclaim the unreachable memory.  That's in contrast with
conservative GC where the runtime can't necessarily figure out the types
of all the objects.  Conservative GC is a terrifying concept in theory,
but it works surprisingly well in practice.  It has been used in Ada in
the past.

Re: How to get Ada to ?cross the chasm??

[Dmitry A. Kazakov]

On 11/05/2018 03:07, Paul Rubin wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> [ Since versions of Python are not compatible and ridden with bugs
>> there is little use in whatever measurements on its implementation. ]
> 
> Sorry but I have to notice that every day, far more practical Python
> code is being written than practical Ada code.  Sure Python 3 is
> incompatible with Python 2, but nowhere near as incompatible as Algol 68
> was with Algol 60.

Algol 60 and 68 considered different languages.

> Sure Python programs have bugs,

I mean Python itself. It took a lot of time for me to work around issues 
with about half of Python API not working. Therefore my projection is 
that whatever they measured could possibly be not working, or doing not 
the things they thought, or maybe never existed in first place. Sorry 
for a bit of Python bashing in response to Ada bashing... (:-))

>> Low-level lists should not use reference-counting. E.g. I frequently
>> allocate lists in an arena pool.
> 
> So you delete all the lists at the same time?

All logically connected lists. Let you write a compiler and allocate 
some intermediate stuff in a bunch of lists. After the phase end you 
just drop the storage pool they live in and be done with that.

>> But measuring GC vs. alternative memory management must be exact and
>> it is a very difficult problem in itself.
> 
> It doesn't sound difficult for a short benchmark if you have enough
> memory.  You can turn off GC completely, so when you allocate memory it
> is never freed until the benchmark finishes.  Then the GC time is zero
> and you can compare the runtime to running the same program with the GC
> enabled.  Although, it might be faster with GC turned on, because of
> caching.
> 
> Ben Zorn in the 1990s did a lot of tests where he captured complete
> execution traces of programs using different GC methods.  It should be
> possible to classify all the primitive operations in a trace and count
> up the ones that are part of GC.  I don't know if he did that though.
> 
>> That depends on the implementation. I keep the list of weak references
>> in the object itself, so there is no heap memory involved.

As I said, it is a difficult and interesting methodological problem. And 
any results from 90's can be safely ignored because new multi-core 
architectures make it hugely different (I don't say worse or better, but 
different).

> Do you mean a count of weak references (along with the count of strong
> references), or do you chain all the weakrefs together somehow, so you
> can find them all and invalidate them when the object is freed?
> 
>> If you can track pointers statically you need no pointers at all. You
>> just track the objects instead.
> 
> I mean the compiler knows the memory layout of each datatype, so if the
> datatype contains pointers, it knows where they are, and it knows the
> types of the pointed-to objects.  That means starting from some known
> objects with known types, the GC can recursively find all the reachable
> objects and reclaim the unreachable memory.  That's in contrast with
> conservative GC where the runtime can't necessarily figure out the types
> of all the objects.  Conservative GC is a terrifying concept in theory,
> but it works surprisingly well in practice.  It has been used in Ada in
> the past.

That would be statically known types. Which is very different from 
statically known objects. And even with statically known types the 
pointers might be not statically known:

    type My_Integer (Indirect : Boolean := False) is record
       case Indirect is
          when True =>
             Reference : access Integer;
          when False =>
             Value : Integer;
       end case;
    end My_Integer;

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

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-11 13:04 , Dmitry A. Kazakov wrote:
> On 11/05/2018 03:07, Paul Rubin wrote:

    [snip]

>> That's in contrast with
>> conservative GC where the runtime can't necessarily figure out the types
>> of all the objects.  Conservative GC is a terrifying concept in theory,
>> but it works surprisingly well in practice.  It has been used in Ada in
>> the past.
>
> [snip] And even with statically known types the
> pointers might be not statically known:
>
>    type My_Integer (Indirect : Boolean := False) is record
>       case Indirect is
>          when True =>
>             Reference : access Integer;
>          when False =>
>             Value : Integer;
>       end case;
>    end My_Integer;

That would not bother a conservative GC much; it would use the record's 
contents as potential pointers (to whatever type of object) without 
caring about the value of the Indirect discriminant.

If Indirect = False, but the Value happens to be a valid pointer to or 
into a heap object, the conservative GC would consider the heap object 
"reachable" and refrain from collecting it. So collection would not find 
all the garbage, but usually it would find most of it.

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

Re: How to get Ada to ?cross the chasm??

[Dmitry A. Kazakov]

On 11/05/2018 12:57, Niklas Holsti wrote:
> On 18-05-11 13:04 , Dmitry A. Kazakov wrote:
>> On 11/05/2018 03:07, Paul Rubin wrote:
> 
>     [snip]
> 
>>> That's in contrast with
>>> conservative GC where the runtime can't necessarily figure out the types
>>> of all the objects.  Conservative GC is a terrifying concept in theory,
>>> but it works surprisingly well in practice.  It has been used in Ada in
>>> the past.
>>
>> [snip] And even with statically known types the
>> pointers might be not statically known:
>>
>>    type My_Integer (Indirect : Boolean := False) is record
>>       case Indirect is
>>          when True =>
>>             Reference : access Integer;
>>          when False =>
>>             Value : Integer;
>>       end case;
>>    end My_Integer;
> 
> That would not bother a conservative GC much; it would use the record's 
> contents as potential pointers (to whatever type of object) without 
> caring about the value of the Indirect discriminant.
> 
> If Indirect = False, but the Value happens to be a valid pointer to or 
> into a heap object, the conservative GC would consider the heap object 
> "reachable" and refrain from collecting it. So collection would not find 
> all the garbage, but usually it would find most of it.

Yes, but if we start not collecting objects we could do just same 
without pointers. The compiler could allocate Reference for each 
instance of My_Integer and never free it.

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

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:871sejyp8d.fsf@nightsong.com...
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
...
> So you delete all the lists at the same time?

Yes, of course.

> What if you have two
> 5-element lists, (a b x y z) and (c d x y z) where both share the same
> 3-element tail?

That sort of sharing almost never makes sense in an Ada context. Remember 
that each individual list element is mutable, so one has to be able to 
"split" any sharing if a node gets modified. It certainly can be programmed, 
but it would take a relatively rare set of operations for that to be of 
benefit.

                      Randy.

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87d0y4zf7d.fsf@nightsong.com...
...
> Fwiw I don't see anything in Ada95 Distilled about how to manage weak
> references or adjust refcounts automatically, but maybe GNAT has
> libraries for that.

No wonder you don't understand: Ada 95 had none of the container stuff or 
other features that reduces the memory management burden without using GC. 
At a minimum, you need to consider Ada 2005, but the most recent Ada is 
best.

                  Randy.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> No wonder you don't understand: Ada 95 had none of the container stuff or 
> other features that reduces the memory management burden without using GC. 
> At a minimum, you need to consider Ada 2005, but the most recent Ada is 
> best.

Ah, ok, I was also going by

  http://cowlark.com/2014-04-27-ada/index.html

which claims Ada has no standardized way to release allocated memory (so
each implementation had its own way).  If you can suggest a good place
to read about the current standard method I'd appreciate it.

> you understand a Pascal-like subset of Ada and then pretty much ignore
> all of the other possibilities. If you did that for C++, you'd get
> essentially C; would that be a fair way to look at C++'s
> capabilities??

To be fair, the Pascal-like subset I looked into first was SPARK (I read
John Barnes' book about it) since SPARK was the aspect of Ada that at
first interested me the most.  I'd be interested to know how the Ada
2012 containers differ from C++ STL containers.  As mentioned elsewhere
I believe that the same guy (Alex Stepanov) had a hand in the design of
both.

Re: How to get Ada to ?cross the chasm??

[Simon Wright]

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

>  I'd be interested to know how the Ada 2012 containers differ from C++
> STL containers.  As mentioned elsewhere I believe that the same guy
> (Alex Stepanov) had a hand in the design of both.

They were introduced in Ada 2005. The initial design (by Matt Heaney,
see [1]) was based on the STL: one reason was that there was an existing
design philosophy to base the Ada work on; another, that there existed
literature about the STL. In hindsight, I don't think that literature
has helped a lot.

[1] http://www.sigada.org/ada_letters/sept2004/charles.pdf

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-11 01:52 , Paul Rubin wrote:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> No wonder you don't understand: Ada 95 had none of the container stuff or
>> other features that reduces the memory management burden without using GC.
>> At a minimum, you need to consider Ada 2005, but the most recent Ada is
>> best.
>
> Ah, ok, I was also going by
>
>   http://cowlark.com/2014-04-27-ada/index.html
>
> which claims Ada has no standardized way to release allocated memory (so
> each implementation had its own way).

That summary of Ada has many inaccuracies, but mostly minor ones. Pity 
that they have not been corrected (some of the examples are 
syntactically wrong, too).

For releasing allocated heap memory, Ada.Unchecked_Deallocation is just 
as standard as "free" in C. People are just scared by the name, and by 
the asymmetry between the simple, primitive "new" keyword and the long 
library-level name Unchecked_Deallocation.

Logically, perhaps Ada should not have included a "new" keyword to 
allocate heap memory, but should have had something like a generic 
library function Ada.Unchecked_Allocation, which is "unchecked" in the 
sense that there is no guarantee that the allocated memory will be 
released when no longer needed. I can imagine the confusion that would 
have caused...

> If you can suggest a good place
> to read about the current standard method I'd appreciate it.

The idea is just to use the standard containers, including the ones that 
can handle indefinite types like String, instead of doing "new" and 
Unchecked_Deallocation yourself. And to use cursors pointing to elements 
of a container, instead of using visible access types. The containers 
then manage the heap allocations and releases.

However, I don't think this method will free you from worrying about 
dangling references -- I believe a cursor can be left dangling, just as 
an access value can be. (I haven't yet had occasion to do such 
container-centric Ada programming, although I have used the Ada 
containers in less central roles.)

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

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:flkuk5F1ft1U1@mid.individual.net...
...
> However, I don't think this method will free you from worrying about 
> dangling references -- I believe a cursor can be left dangling, just as an 
> access value can be. (I haven't yet had occasion to do such 
> container-centric Ada programming, although I have used the Ada containers 
> in less central roles.)

Correct. However, an implementation can detect dangling cursors if it wants 
to, so (depending on implementation), you could get an exception raised when 
using one (unlike a dangling pointer which does whatever [formally, 
"erroneous execution"]). The main reason that we didn't require dangling 
pointer detection is that a perfect scheme is quite expensive -- but a 
99.99...% detection scheme is reasonably efficient and IMHO should be part 
of every implementation (possibly with some way to turn it off if maximum 
performance is needed).

                                Randy.

Re: How to get Ada to ?cross the chasm??

[Lucretia]

On Thursday, 10 May 2018 23:52:18 UTC+1, Paul Rubin  wrote:
> "Randy Brukardt" <randy@ com> writes:
> > No wonder you don't understand: Ada 95 had none of the container stuff or 
> > other features that reduces the memory management burden without using GC. 
> > At a minimum, you need to consider Ada 2005, but the most recent Ada is 
> > best.
> 
> Ah, ok, I was also going by
> 
>   http://cowlark.com/2014-04-27-ada/index.html

I wouldn't, that uses some weird syntax, it's like he's a C programmer doing Ada.

> which claims Ada has no standardized way to release allocated memory (so
> each implementation had its own way).  If you can suggest a good place
> to read about the current standard method I'd appreciate it.

Bullshit.

http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-13-11-2.html
 
> To be fair, the Pascal-like subset I looked into first was SPARK (I read
> John Barnes' book about it) since SPARK was the aspect of Ada that at
> first interested me the most.  I'd be interested to know how the Ada
> 2012 containers differ from C++ STL containers.  As mentioned elsewhere
> I believe that the same guy (Alex Stepanov) had a hand in the design of
> both.

Your previous post about him says he worked on *a* container library for Ada83 (it was in 1989) and he even says he never touched Ada much since then. So, no, he didn't have a hand in the current implementation.

I think it was Matthew Heaney who provided them, https://groups.google.com/forum/#!topic/comp.lang.ada/luv71Ex0CDc to the ARG for standardising, IIRC.

Luke.

Re: How to get Ada to ?cross the chasm??

[Marius Amado-Alves]

On Friday, 11 May 2018 13:46:34 UTC+1, Lucretia  wrote:
> On Thursday, 10 May 2018 23:52:18 UTC+1, Paul Rubin  wrote:
> > "Randy Brukardt" <randy@ com> writes:
> > > No wonder you don't understand: Ada 95 had none of the container stuff or 
> > > other features that reduces the memory management burden without using GC. 
> > > At a minimum, you need to consider Ada 2005, but the most recent Ada is 
> > > best.
> > 
> > Ah, ok, I was also going by
> > 
> >   http://cowlark.com/2014-04-27-ada/index.html
> 
> I wouldn't, that uses some weird syntax, it's like he's a C programmer doing Ada.
> 
> > which claims Ada has no standardized way to release allocated memory (so
> > each implementation had its own way).  If you can suggest a good place
> > to read about the current standard method I'd appreciate it.
> 
> Bullshit.
> 
> http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-13-11-2.html
>  
> > To be fair, the Pascal-like subset I looked into first was SPARK (I read
> > John Barnes' book about it) since SPARK was the aspect of Ada that at
> > first interested me the most.  I'd be interested to know how the Ada
> > 2012 containers differ from C++ STL containers.  As mentioned elsewhere
> > I believe that the same guy (Alex Stepanov) had a hand in the design of
> > both.
> 
> Your previous post about him says he worked on *a* container library for Ada83 (it was in 1989) and he even says he never touched Ada much since then. So, no, he didn't have a hand in the current implementation.
> 
> I think it was Matthew Heaney who provided them, https://groups.google.com/forum/#!topic/comp.lang.ada/luv71Ex0CDc to the ARG for standardising, IIRC.
> 
> Luke.

Unfortunately, Ada.Containers is greatly modelled on the STL, yes. But it's nevertheless of excellent quality. Matthew Heaney provided the bulk of a prototype implementation that most probably has been integrated into the current GNATs.

My understanding of what happen in the 1980's: Alex Stepanov was looking for, and into, generic programming, and the only language providing that was Ada 83, and he looked briefly into her, but then for some reason he teamed up with Stoutstroup for generics in C++, which they did the C way, with preprocessing, hence "template". So the strange history of Ada.Containers is Ada 83 -> STL -> Ada 2005.

The goal in the 1980's was to make the data structure algorithms (linked lists, etc.) generic on the element type. Ada 83 was excellent for that, but the opportunity was waisted for some reason. Also, they let the algorithmic aspect show up more than it should, in the STL and then in Ada.Containers. Instead of the algebraic structure. All that fussing with null values, etc. This was the unfortunate part of Ada.Containers being modelled on the STL.

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-07 23:29 , Paul Rubin wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
    ...
>>> So you still get arbitrarily long pauses.
>> No, because I know the structures I deal with and can avoid that
>> choosing proper design.
>
> In other words you are manually managing memory, which is what
> refcounting is supposed to get you out of.

No, Dmitry just knows (by design of the data structure) that there are 
no long/deep chains of references needing to be updated.

>> Millisecond is very long for many applications,
>
> In such a system you better not use a refcount scheme either, without a
> WCET analysis.

Some kind of WCET analysis is very often needed in real-time systems 
whatever kind of memory management is used. This is another of the ways 
in which such systems differ from the typical applications of GC-based 
languages.

However, there is a functional programming language, Hume, designed for 
real-time systems, 
https://en.wikipedia.org/wiki/Hume_(programming_language).

> I'd add as well: most refcount systems I know of don't move objects
> around in memory, so you get memory fragmentation and high cache miss
> rates.

Real-time systems with reference counting often use special "heaps" or 
"pools" with block sizes designed to fit the application and to avoid or 
minimize fragmentation. Caches are often small, and main memories not 
very large either, so the penalty for cache misses is often less than in 
larger server-like systems. For example, in my current project a RAM 
access needs only 2 wait states, and we in fact run with the D-cache 
disabled (this reminds me that we should experiment to see if the 
program is faster or slower with the D-cache enabled...)

The most critical task in this application has a 500 Hz frequency and is 
budgeted at something like 0.5 - 0.8 ms per activation. The application 
uses reference counting for some data structures, but the 500 Hz task is 
designed not to use it directly; a lower-frequency support task supplies 
and receives the reference-counted data to and from the 500 Hz task. 
Just as an example.

I think Dmitry often deals with shorter times and higher task 
frequencies. But then his stuff is ground-based and runs on more 
powerful processors.

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> Some kind of WCET analysis is very often needed in real-time systems
> whatever kind of memory management is used.

I'd say this is a niche area for which I'm surprised the methods we're
discussing are ever viable.  Remember that even traditional imperative
data structures like hash tables have terrible enough WCET that they
can't be used in realtime systems.  So these systems have to be
programmed in special ways that are not very relevant to what's best for
the mainstream.

> https://en.wikipedia.org/wiki/Hume_(programming_language).

Interesting!

> Real-time systems with reference counting often use special "heaps" or

I'd still like to know if there is careful analysis about max structure
depth and WCET, particularly formal analysis.

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-09 04:20 , Paul Rubin wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>> Some kind of WCET analysis is very often needed in real-time systems
>> whatever kind of memory management is used.
>
> I'd say this is a niche area

It is one of the core areas for the Ada language, and constrains the 
evolution of the language.

> for which I'm surprised the methods we're
> discussing are ever viable.

Which methods are these? I'm perhaps lost.

Reference counts are certainly viable for real-time systems, provided 
that long/deep chains of references are avoided (or handled by the 
"garbage list" method) which is often possible.

Applicative data structures could be viable, if worst-case time and 
space bounds can be found -- even if they are less than tight. It seems 
that Dmitry uses such data structures, although he may not call them by 
this name.

There has been a lot of work on and promotion of GC for real-time 
systems, but most practitioners are still not convinced. The real-time 
Javas tried to separate GC memory from non-GC memory, but it's been a 
while since I've seen any mention of real-time Java.

> Remember that even traditional imperative
> data structures like hash tables have terrible enough WCET that they
> can't be used in realtime systems.  So these systems have to be
> programmed in special ways that are not very relevant to what's best for
> the mainstream.

There are alternatives (balanced trees, for example) which allow useful 
WCETs.

There is also an area called "probabilistic WCET/timing analysis" in 
which WCETs are not single-valued, but distributions; if one can pick a 
"WCET" from the distribution such that the risk of the actual execution 
time exceeding this "WCET" is smaller than the risk of the HW failing, 
this "WCET" can be considered a realistic WCET. That could be a useful 
approach to the WCET of hash tables. (I'm emotionally repulsed by the 
probabilistic approach, but I have to admit it seems the only practical 
path for WCET analysis of current high-end processors. With the possible 
of exception of the Mill processor, under development.)

>> Real-time systems with reference counting often use special "heaps" or
>
> I'd still like to know if there is careful analysis about max structure
> depth and WCET, particularly formal analysis.

Sorry, I don't understand what you want to know. Clarify, please.

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>>> WCET analysis
>> I'd say this is a niche area
> It is one of the core areas for the Ada language, and constrains the
> evolution of the language.

Sure, that's fine, one of Ada's core areas targets a niche (but
important) class of applications.  I think the idea of "Crossing the
chasm" was to get Ada more widely used outside the niche, in a
mainstream that mostly doesn't care about WCET beyond wanting programs
to be reasonably responsive most of the time.  

>> for which I'm surprised the methods we're discussing are ever viable.
> Which methods are these? I'm perhaps lost.

Applicative data structures, and methods in general that use dynamic
memory allocation extensively.  I'm used to the idea of a realtime
program as being something you could reasonably write in MISRA C or
Forth, i.e. it would tend to have completely static storage, mostly
straight-line code in fixed-sized loops, even with not too many "if"
statements past some kind of event dispatch.  That is probably a little
too constrained though.

I've played around with this and it's cool:
https://github.com/tomahawkins/atom

> Reference counts are certainly viable for real-time systems, provided
> that long/deep chains of references are avoided (or handled by the
> "garbage list" method) which is often possible.

ISTM that if the total amount of live data is bounded, then GC time is
also bounded, so GC can still be ok to use.

> There has been a lot of work on and promotion of GC for real-time
> systems, but most practitioners are still not convinced.

I agree with this, I'm not convinced either.  I'd be interested to know
what the proposed application areas are.  In my own mind there's a
pretty large divide between general purpose applications (that I'd run
on a server using a GC'd language) and realtime ones (that I'd run on an
MCU with no dynamic memory allocation at all).  But I know in reality
there's an in-between area. 

> I'm emotionally repulsed by the probabilistic approach, but I have to
> admit it seems the only practical path for WCET analysis of current
> high-end processors.

I have doubts about the reliability of the high-end processors
(speculative execution, N layers of caches, branch prediction etc).  But
we're headed into an era when ubiquitous critical systems (self-driving
cars) are controlled by artificial neural nets trained by statistical
machine learning, where absolutely nobody understands why the system
decides any particular thing.  Scary times.

>> I'd still like to know if there is careful analysis about max structure
>> depth and WCET, particularly formal analysis.
> Sorry, I don't understand what you want to know. Clarify, please.

E.g. I look at that GADT-checked Haskell red-black tree indexed using
zippers, and can imagine that being implemented with a refcounted
system.  Some bounds on the tree size give consequent bounds on its
depth, so it could conceivably be used in a system with a WCET analysis.
What I wonder is whether anyone does that in practice.  I imagine
working on a realtime system like your satellite stuff, and going into
the office saying I wanted to use something like that.  My boss would
probably tell me I was crazy.

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-10 01:03 , Paul Rubin wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
    ...
>>> for which I'm surprised the methods we're discussing are ever viable.
>> Which methods are these? I'm perhaps lost.
>
> Applicative data structures, and methods in general that use dynamic
> memory allocation extensively.  I'm used to the idea of a realtime
> program as being something you could reasonably write in MISRA C or
> Forth, i.e. it would tend to have completely static storage, mostly
> straight-line code in fixed-sized loops, even with not too many "if"
> statements past some kind of event dispatch.  That is probably a little
> too constrained though.

Well, there is a scale: real-time system; hard real-time system; 
life-critical hard real-time system. The fixed-size loops and other very 
strong constraints on control structures are perhaps required at the 
last level. But at that level the usual practice is to omit even the 
real-time kernel and use a single thread.

(Your mention of Forth I don't understand. I see Forth as one large step 
below C in language level -- cripes, one even has to manage the stack 
manually! -- and requiring extremely careful coding to avoid the program 
going off the rails. Moreover, I don't see any particular support in 
Forth for real-time aspects or control-flow restrictions such as loops 
with static iteration bounds.)

The concept of "dynamic allocation" is interestingly vague. All 
real-time applications I've seen have dynamic allocation in various data 
buffers and queues, even if they never use the system heap. Of course, 
the designers foresee that the buffers and queues can become full, and 
design the application to be robust and degrade gracefully if that happens.

The problem with heap allocation, I think, is that is hard to foresee 
and describe the conditions under which the heap might overflow, in part 
because of fragmentation. This could be mitigated by using 
application-defined storage pools, in Ada or other languages. Dedicating 
a storage pool of a defined size to a specific kind of objects, perhaps 
with a fixed size, can avoid or reduce fragmentation and lets one define 
a memory budget for that kind of objects, which can help SW operators 
avoid overflows.

> I've played around with this and it's cool:
> https://github.com/tomahawkins/atom

"Compile-time task scheduling" probably means fixed task frequencies, 
rather than event-driven, preemptive tasks, am I right?

>>> I'd still like to know if there is careful analysis about max structure
>>> depth and WCET, particularly formal analysis.
>> Sorry, I don't understand what you want to know. Clarify, please.
>
> E.g. I look at that GADT-checked Haskell red-black tree indexed using
> zippers, and can imagine that being implemented with a refcounted
> system.  Some bounds on the tree size give consequent bounds on its
> depth, so it could conceivably be used in a system with a WCET analysis.
> What I wonder is whether anyone does that in practice.

Balanced tree structures are certainly used in real-time systems, but 
the ones I've seen have not been applicative. As you say, there are 
bounds on the tree size, from which WCET bounds can be computed (usually 
based on measurements of test cases, followed by analytical 
extrapolation to the maximum depth).

> I imagine working on a realtime system like your satellite stuff, and
> going into the office saying I wanted to use something like that.
> My boss would probably tell me I was crazy.

There are certainly two aspects: technical feasibility, and the need for 
qualification and acceptance by product assurance. New ideas as hard to 
get past product assurance people, who tend to be quite conservative 
(with good reason).

Ideally, one should show that although the new idea adds complexity at 
one point (eg. reference counting or GC) it will reduce complexity in 
other places (eg. by making some data structures applicative and 
therefore simplifying high-level task/timing interactions). It may still 
be necessary to put more than normal effort in the verification and 
validation of the new type of SW.

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

Re: How to get Ada to ?cross the chasm??

[Dennis Lee Bieber]

On Thu, 10 May 2018 23:47:25 +0300, Niklas Holsti
<niklas.holsti@tidorum.invalid> declaimed the following:


>
>The concept of "dynamic allocation" is interestingly vague. All 
>real-time applications I've seen have dynamic allocation in various data 
>buffers and queues, even if they never use the system heap. Of course, 
>the designers foresee that the buffers and queues can become full, and 
>design the application to be robust and degrade gracefully if that happens.
>
	In my limited (4 years) exposure, the closest thing to "dynamic
allocation" took place during program initialization. Your "buffers and
queues" are allocated and set-up before the software transitions into
"running" state. Anything could take place during said initialization, but
once "running" everything was from pre-allocated memory regions. And
nothing is ever freed -- it merely moves from one application controlled
list/queue structure to another. If a failure in allocation occurs, the
software either restarts (basically, reboots the processor) or (if some
memory location keeps track of restart attempts) reports a fatal error
condition and never goes into operational mode.

>"Compile-time task scheduling" probably means fixed task frequencies, 
>rather than event-driven, preemptive tasks, am I right?
>
	Even Ada's tasking wasn't allowed -- apparently because the RTL isn't
deterministic enough. Instead, some minimal RTOS was embedded into the
application environment and Ada procedures were activated as tasks in the
RTOS (with defined stack sizes, priorities, etc.).



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

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-11 02:15 , Dennis Lee Bieber wrote:
> On Thu, 10 May 2018 23:47:25 +0300, Niklas Holsti
> <niklas.holsti@tidorum.invalid> declaimed the following:
>>
>> The concept of "dynamic allocation" is interestingly vague. All
>> real-time applications I've seen have dynamic allocation in various data
>> buffers and queues, even if they never use the system heap. Of course,
>> the designers foresee that the buffers and queues can become full, and
>> design the application to be robust and degrade gracefully if that happens.
>>
> 	In my limited (4 years) exposure, the closest thing to "dynamic
> allocation" took place during program initialization. Your "buffers and
> queues" are allocated and set-up before the software transitions into
> "running" state. Anything could take place during said initialization, but
> once "running" everything was from pre-allocated memory regions.

Yes yes, but at run-time the program allocates space dynamically, as 
needed, _in_ the buffers and queues, though usually not by the "new" 
keyword but by some application-defined "allocate buffer block" or 
"enqueue" operation. And these allocations can fail at run-time, at 
least under overload conditions.

In Ada, one might define the buffers and queues as storage pools 
(themselves statically allocated) and use the "new" keyword to allocate 
space in a buffer or queue, and Unchecked_Deallocation to release the 
space. That would be entirely equivalent to the standard way of using 
statically allocated buffers and queues, but now the program would, 
probably, violate the coding rules that forbid "dynamic allocation", at 
least in the opinion of the product assurance staff.

> And nothing is ever freed -- it merely moves from one application
> controlled list/queue structure to another.

Which dynamically frees the space in the first list/queue, from which 
the data are removed.

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> Yes yes, but at run-time the program allocates space dynamically, as
> needed, _in_ the buffers and queues, though usually not by the "new"
> keyword but by some application-defined "allocate buffer block" or
> "enqueue" operation. And these allocations can fail at run-time, at
> least under overload conditions.

I'm still kind of surprised to hear that.  I thought Ada programs (once
running) were supposed to never fail, which means no dynamic anything,
just a few allocations that might fail during startup, and then run with
those resources and only those resources.

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-11 11:10 , Paul Rubin wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>> Yes yes, but at run-time the program allocates space dynamically, as
>> needed, _in_ the buffers and queues, though usually not by the "new"
>> keyword but by some application-defined "allocate buffer block" or
>> "enqueue" operation. And these allocations can fail at run-time, at
>> least under overload conditions.
>
> I'm still kind of surprised to hear that.  I thought Ada programs (once
> running) were supposed to never fail,

"Not fail" = work according to the specifications.

Suppose the specification says: "If a packet is received when the 
received-packet-queue is full, the program shall discard the new packet 
and increment the lost-packet counter", you see how the program is 
expected to work if it cannot allocate space _in_ the queue at run time.

An alternative specification could say, instead: "If a packet is 
received when the received-packet-queue is full, the program shall make 
room in the queue for the new packet by discarding the oldest enqueued 
packet from the queue". And the program would implement that, instead.

A third possiblity is to specify: "The program shall start the reception 
of a new packet only when the received-packet-queue is not full". This 
pushes the problem back to the entity sending the packets; perhaps the 
HW will lose any packets sent when the program is not trying to receive 
them, or perhaps there is flow-control on the link, and the sending 
entity is blocked (which may lead to an overflow of the transmission 
queues on the sending side).

> which means no dynamic anything,
> just a few allocations that might fail during startup, and then run with
> those resources and only those resources.

My point was about the meaning of "dynamic". People often think that 
"dynamic allocation" is only allocation from the system heap. But that 
is a surface distinction, because application-defined buffers and queues 
are also subject to run-time (and therefore "dynamic") allocation and 
release of space. The deeper question is if those allocations are 
certain to succeed (which could be ensured by some known or imposed 
limits on the input and output rates etc.) or may fail, and of course a 
failed allocation should not make the program fail to obey its 
specifications.

On the system level, the conditions (typically abnormal input rates) 
under which the dynamic allocations may fail should be understood and 
suitable recovery actions defined in the program specifications.

One problem with dynamic allocations from the system heap is that the 
conditions for failure (heap exhaustion) are global, depending on all 
uses of the heap, which makes it hard to specify how the program should 
handle a particular allocation failure.

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

Re: How to get Ada to ?cross the chasm??

[Jeffrey R. Carter]

On 05/11/2018 01:15 AM, Dennis Lee Bieber wrote:
> 
> 	Even Ada's tasking wasn't allowed -- apparently because the RTL isn't
> deterministic enough. Instead, some minimal RTOS was embedded into the
> application environment and Ada procedures were activated as tasks in the
> RTOS (with defined stack sizes, priorities, etc.).

Most such claims were false. Every reported case that I saw of real-time S/W 
that actually used Ada-83 tasking as it was meant to be used worked fine. In 
some cases where tasking wasn't used, when I dug down far enough, the real 
reason was that the developers didn't understand concurrency. On DOD cost-plus 
contracts, such unproven claims were used to increase profits.

There may be cases where tasking was used, was shown to be unacceptable, and so 
tasking was not used in the final S/W. However, I've never heard of one.

-- 
Jeff Carter
"C++: The power, elegance and simplicity of a hand grenade."
Ole-Hjalmar Kristensen
90

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-11 02:15 , Dennis Lee Bieber wrote:

   [about restrictions imposed in critical SW]

> 	Even Ada's tasking wasn't allowed -- apparently because the RTL isn't
> deterministic enough.

In my experience of such cases, the crux is usually not non-determinism, 
but the requirement to validate, or qualify, the Run-Time System. A 
"full Ada" RTS is complex, which means that it is hard and/or expensive 
to qualify for a certain target system.

> Instead, some minimal RTOS was embedded into the
> application environment and Ada procedures were activated as tasks in the
> RTOS (with defined stack sizes, priorities, etc.).

If the minimal RTOS is smaller or less complex (and of course also less 
expressive and less functional) it is also cheaper to qualify to the 
same level of trust. It may also be easier to reuse the minimal RTOS for 
different applications on different target systems, with smaller 
changes, and therefore with less effort for requalifying the RTOS for 
new target systems, spreading the qualification cost over many 
applications and users.

Several Ada compiler vendors provide simplified Ravenscar RTSes, and 
some provide even simpler and more restricted RTS versions for more 
critical applications. (I forget what these are called. I don't know of 
any standard Ada RTS profile that is more restrictive than Ravenscar, so 
the names are probably vendor-specific.)

In the space domain, it is not unusual for some highly critical SW to be 
forbidden to use any real-time kernel, forcing the SW to be 
single-threaded. This is common for any SW that resides in (true) 
read-only memory and cannot be patched in flight. Typical cases are the 
"boot SW" or some fall-back "recovery" SW that takes over when the main 
SW fails and is used only to analyse the problem and to patch the main SW.

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> (Your mention of Forth I don't understand. I see Forth as one large
> step below C in language level -- cripes, one even has to manage the
> stack manually! -- and requiring extremely careful coding to avoid the
> program going off the rails. Moreover, I don't see any particular
> support in Forth for real-time aspects or control-flow restrictions
> such as loops with static iteration bounds.)

Forth is interesting and while I'd consider it lower level than C, the
Forth newsgroup participants would disagree vociferously.  It focuses
the mind to the point that someone wrote a book comparing it to Zen
meditation.  Its implementation techniques are startlingly clever and
I'd consider studying and using it to be a worthwhile exercise for any
serious programmer.  I use it in some personal projects because I like
the mental exercise and because of how it forces me to simplify problems
to their bare essentials.  That said, its heyday was the 1970s-80s
minicomputer era and (contra what the Forthers say) doing anything
serious with it today seems to me like an exercise in masochism.  I'm
far faster at C than I am at Forth, the opposite of what Forth
programmers claim.

Forth is usually implemented as a very simple threaded-code interpreter
(the "inner" or "address" interpreter) written in assembly language,
plus a source-language interpreter (the "outer" or "text" interpreter)
written in Forth itself.  The inner interpreter is maybe a few dozen asm
instructions and implements a 2-stack VM.  The outer interpreter is
basically an assembler for the VM, plus it often lets you write
definitions directly in assembly language with the assembler itself
written in Forth, using Forth syntax.  There is sometimes a cooperative
multitasker that itself is just a handful of instructions that basically
swaps stack pointers around between tasks.

The whole implementation is simple enough that the programmer can and
does understand and maintain the whole thing, all the way down to the
hardware (OS?  We don't need no stinking OS).  You can have a
respectable interactive interpreter in a few KB of program space using
maybe 100 bytes of ram.  Or you could have a complete IDE-like
environment on a minicomputer with 8k of ram and a floppy drive.

It's conducive to realtime control applications because there is such
a direct mapping between Forth code and machine code, even closer than
C in my opinion.  When a Forther types "2 2 + ." to the text
interpreter they can predict exactly what instructions the machine
will run.  There's not dozens of layers of libraries between the user
program and the machine.  There's usually no heap allocation, GC,
background tasks, or anything else happening while the program runs.

Its main touted feature is its interactivity: in some ways it's more
like using a debugger than a compiler.  You get some weird piece of
poorly documented hardware and you can put Forth on it, and start poking
at the control registers (defining functions to bang them in sequence
etc.) and figuring out what stuff does.

I got a couple of small STM8 8-bit MCU boards from Aliexpress for about
0.5 euro each.  They have 8K of program flash and 1k of ram, and they
can run a reasonable interactive Forth.  Forth must have had the same
attraction on 1970s minicomputers that an interactive Python prompt does
on PC's today.

This book about Forth development methods predated the whole Agile
movement by decades(?):  http://thinking-forth.sourceforge.net/

Maybe mentioning Agile is poor recommendation here since I guess Ada
users have a dim view of Agile.  I can sympathize with that, at least
as far as production code is concerned.  But even when one has to ship
reliable production code at the end of the day, it's useful to be able
to first slap out a crappy prototype that lets you explore the
possible feature space and implementation strategies.  Tools like
Python and (at the lower level) Forth are great for that.

I liked this article although Forthers complain about it and some of
their disagreements with it are valid:

http://yosefk.com/blog/my-history-with-forth-stack-machines.html

> The concept of "dynamic allocation" is interestingly vague. All
> real-time applications I've seen have dynamic allocation in various
> data buffers and queues, even if they never use the system heap.

Yeah I'm used to a much more limited style of realtime system, that
uses a few fixed memory locations or maybe fixed sized arrays, plus
some simple functions and loops, with no heap allocation after the
initialization phase.  But of course things can be much more
complicated.

>> https://github.com/tomahawkins/atom
> "Compile-time task scheduling" probably means fixed task frequencies,
> rather than event-driven, preemptive tasks, am I right?

Pretty much.  It's been a while since I tried it, but it is made for
HRT and its intended application was motor controllers, so not much
complex communication.  IIRC the user program is compiled to a single
event loop where the different "tasks" each get to look at each event
and possily act on it.  It is designed for constant-time execution, so
instead of

  if (condition) then f(); else g();

its conditional execution construct (called "mux" instead of "if")
compiles into

   r1 = f()
   r2 = g()
   result = condition ? r1 : r2 ;

That is, both branches are executed and then the condition selects
which value to use.  The whole program is constructed that way, so the
main loop is supposed to use the exact same number of machine cycles
on every pass, no matter what the individual tasks decide to do.

> New ideas as hard to get past product assurance people, who tend to
> be quite conservative (with good reason).

Yep, I'd be conservative about something like that too.  In a weird
way, even though Forth has no safety checks, its simplicity reflects a
form of extreme conservativism.

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-12 01:39 , Paul Rubin wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>> (Your mention of Forth I don't understand. I see Forth as one large
>> step below C in language level -- cripes, one even has to manage the
>> stack manually! -- and requiring extremely careful coding to avoid the
>> program going off the rails. Moreover, I don't see any particular
>> support in Forth for real-time aspects or control-flow restrictions
>> such as loops with static iteration bounds.)
>
> Forth is interesting and while I'd consider it lower level than C, the
> Forth newsgroup participants would disagree vociferously.

Yes. It's weird how some people fall in love with strange things -- like 
Forth, or Ada...

> Its implementation techniques are startlingly clever

There have been compilers of higher-level languages that generate 
threaded code that looks like the code one expects from Forth; on the 
other hand, I believe there are now Forth compilers that can emit a more 
conventional kind of code. I'm not sure if threaded code was invented in 
connection with Forth, or was adopted in Forth because it suited the 
interactive environment.

If you want a thrill (hair-raising kind), have a look at how Gforth 
implements threaded Forth code by cutting and splicing machine code 
generated by gcc from C source for the interpreter.

> That said, its heyday was the 1970s-80s minicomputer era

Around that time, I was using an HP2100 16-bit mini (64 KiB of magnetic 
core memory) for controlling an astronomical radio telescope and its 
instruments. To replace the very limited HP-Basic which had been used 
before, we considered implementing a Forth system -- the commercial 
Forth costing more than the university was eager to pay.

In the end we used HP-Algol instead. The programming process was 
"interesting". To edit a source code file: load the interactive editor 
from paper tape, load the source code from paper tape, edit (as in 
Basic) the lines that need changes, save the edited source on paper tape.

To build the program: load the compiler from paper or magnetic tape 
(fortunately a single-pass compiler), load a source file from paper tape 
and compile it, get the object on paper tape, repeat for all changed 
source files. Then splice the new and old object-code tapes together 
with Scotch tape, load the linker from paper or magnetic tape, feed in 
the spliced object tapes, get the executable on paper tape, load that 
tape, press Run. Ah, nostalgia...

The interactive Forth had a certain attraction, in comparison.

> and (contra what the Forthers say) doing anything
> serious with it today seems to me like an exercise in masochism.

I agree. There are very few situations were I would consider using 
Forth; possibly for some very small embedded device that must be 
reprogrammable on itself, without cross-programming from a PC.

> Forth is usually implemented...   There is sometimes a cooperative
> multitasker that itself is just a handful of instructions that basically
> swaps stack pointers around between tasks.

I cannot resist to note that I implemented a cooperative multi-tasker 
for the HP2100 Algol system eulogized above. It was dirt simple: the 
machine had two working registers and no stack. Some of the users of the 
earlier Basic-based SW were amazed to see the typewriter terminal 
printing at the same time as the ADC was reading data at the same time 
as the magnetic tape was spinning.

Not having a stack meant that subprograms were not reentrant, so one had 
use a certain amount of care in choosing when to switch tasks.

> It's conducive to realtime control applications because there is such
> a direct mapping between Forth code and machine code, even closer than
> C in my opinion.  When a Forther types "2 2 + ." to the text
> interpreter they can predict exactly what instructions the machine
> will run.

For the "2 2 +" part, yes. For the "." part, not so much. And once the 
program gets larger, knowing exactly which instructions the compiler 
will emit for each statement helps little to understand the whole, I think.

> Maybe mentioning Agile is poor recommendation here since I guess Ada
> users have a dim view of Agile.

Agile versus waterfall depends on the project's goals rather than the 
language, I feel. In some projects -- space on-board SW is typical -- 
the customer knows what is wanted, based on intense earlier analysis of 
the mission, its scientific or technical aims, SW/HW trade-offs etc. In 
agile projects there is flexibility in the scope, the HW, the 
functionality, everything.

IMO Ada is well suited for agile development, because you can refactor 
things wildly and the compiler will help you put it into shape again. In 
a less strict language, conflicts or incompatibilities caused by 
refactoring can stay hidden until the program fails with a run-time 
error -- much harder to correct.

(That said, the support that the GPS IDE currently offers for 
refactoring is very rudimentary, being limited to renaming things 
systematically -- usually one identifier at a time :-( )

>> The concept of "dynamic allocation" is interestingly vague. All
>> real-time applications I've seen have dynamic allocation in various
>> data buffers and queues, even if they never use the system heap.
>
> Yeah I'm used to a much more limited style of realtime system, that
> uses a few fixed memory locations or maybe fixed sized arrays, plus
> some simple functions and loops, with no heap allocation after the
> initialization phase.

I seem to have difficulty communicating my point here. Do you equate 
"dynamic" with "heap"?

In my view, if your system has a UART and accumulates incoming 
characters into a line buffer until in comes a CR to end the line, you 
are allocating space dynamically in the buffer for each incoming 
character. Now that is an extreme example, but I hope it shows what I am 
driving at: in principle, if the program uses up space, when needed, in 
any "memory" that can fill up, it is allocating that space dynamically, 
even if this "memory" is not the system heap.

>>> https://github.com/tomahawkins/atom
> ... It is designed for constant-time execution, so
> instead of
>
>   if (condition) then f(); else g();
>
> its conditional execution construct (called "mux" instead of "if")
> compiles into
>
>    r1 = f()
>    r2 = g()
>    result = condition ? r1 : r2 ;

In the WCET analysis community, this coding style is called "single-path 
programming". There are some advocates, and even some HW development for 
it. One has to rethink one's algorithms, but it is claimed that the 
worst case is usually no worse than for a conventional algorithm.

> That is, both branches are executed and then the condition selects
> which value to use.

Another approach is to execute only the selected branch, but to ensure 
that both branches use the same amount of time, inserting dummy 
instructions in the shorter branch if needed. There have been posts on 
comp.arch.embedded form people who are doing that.

Of course this approach does not work as well on machines that have 
variable instruction timing from caches etc.

> The whole program is constructed that way, so the
> main loop is supposed to use the exact same number of machine cycles
> on every pass, no matter what the individual tasks decide to do.

The problem in a main-loop system is combining high-frequency tasks with 
low-frequency tasks that do complex computations. The main loop has to 
suspend and resume the complex computation frequently, which is not so 
easy unless one does a full task-context switch.

>> New ideas as hard to get past product assurance people, who tend to
>> be quite conservative (with good reason).
>
> Yep, I'd be conservative about something like that too.  In a weird
> way, even though Forth has no safety checks, its simplicity reflects a
> form of extreme conservativism.

I am reminded of the Mythbusters TV shows where the goal is to construct 
just about anything with duct tape :-)

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

Re: How to get Ada to ?cross the chasm??

[Jeffrey R. Carter]

On 05/12/2018 11:29 AM, Niklas Holsti wrote:
> 
> Agile versus waterfall depends on the project's goals rather than the language, 
> I feel. In some projects -- space on-board SW is typical -- the customer knows 
> what is wanted, based on intense earlier analysis of the mission, its scientific 
> or technical aims, SW/HW trade-offs etc. In agile projects there is flexibility 
> in the scope, the HW, the functionality, everything.

Agile is coders' response to employers who heard that they should hire S/W engs 
who use a method: We'll call what we do (shut up and start coding) a method. 
We'll throw in pair programming so they hire twice as many of us. (When 
engineering S/W, code generation should be mechanical.)

> I am reminded of the Mythbusters TV shows where the goal is to construct just 
> about anything with duct tape :-)

And here I thought the goal was to blow things up.

-- 
Jeff Carter
"Death awaits you all, with nasty, big, pointy teeth!"
Monty Python & the Holy Grail
20

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-12 13:57 , Jeffrey R. Carter wrote:
> On 05/12/2018 11:29 AM, Niklas Holsti wrote:
>>
>> Agile versus waterfall depends on the project's goals rather than the
>> language, I feel. In some projects -- space on-board SW is typical --
>> the customer knows what is wanted, based on intense earlier analysis
>> of the mission, its scientific or technical aims, SW/HW trade-offs
>> etc. In agile projects there is flexibility in the scope, the HW, the
>> functionality, everything.
>
> Agile is coders' response to employers who heard that they should hire
> S/W engs who use a method: We'll call what we do (shut up and start
> coding) a method.

Seriously, no. Agile SW development is an attempt to avoid the typical 
waterfall problem of a long delay from the customer saying what they 
want, to the customer seeing the SW the developers implemented -- and 
discovering that (a) the customer's requirements were misunderstood, 
and/or (b) the customer now wants or needs something else.

I've not worked in any (formally) agile projects, so my view may be 
idealised. But AIUI, the first step is certainly not coding; it is to 
talk in depth with the customer about the background and overall aims of 
the SW project, find out what seems to be a good *minimum* set of 
functionality to start from, formalise requirements *only* for that 
part, and then implement it, in the first sprint.

Agile SW development can be seen as a process of continuous requirements 
elicitation interleaved with implementation and refactoring, making use 
of the sad fact that it is easier for the customers to ask for changes, 
extensions, or deletions to some SW they can see and use, than to state 
complete requirements for SW that does not yet exist.

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

Re: How to get Ada to ?cross the chasm??

[Jeffrey R. Carter]

On 05/12/2018 05:51 PM, Niklas Holsti wrote:
> 
> I've not worked in any (formally) agile projects, so my view may be idealised. 
> But AIUI, the first step is certainly not coding; it is to talk in depth with 
> the customer about the background and overall aims of the SW project, find out 
> what seems to be a good *minimum* set of functionality to start from, formalise 
> requirements *only* for that part, and then implement it, in the first sprint.

"[T]he [Agile] idea that it's bad to spend an
appropriate time at the beginning of the project
to clarify the overall requirements and design ..."

"... the Agile catechism: we're Agile, we
don't need to stop and think, we just go ahead
and code!"

Bertrand Meyer

-- 
Jeff Carter
"Death awaits you all, with nasty, big, pointy teeth!"
Monty Python & the Holy Grail
20

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
> "... the Agile catechism: we're Agile, we don't need to stop and
> think, we just go ahead and code!"

I think in the high-assurance community they use the term "rapid
prototyping" for this style of development, and they see it as a good
thing, as long as you don't claim that the thing produced that way is
the final product.  This is about a US Navy project where they compared
a bunch of different rapid prototyping approaches.

http://haskell.cs.yale.edu/wp-content/uploads/2011/03/HaskellVsAda-NSWC.pdf

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:pd6h9u$tvp$1@dont-email.me...
> On 05/12/2018 11:29 AM, Niklas Holsti wrote:
>>
>> Agile versus waterfall depends on the project's goals rather than the 
>> language, I feel. In some projects -- space on-board SW is typical -- the 
>> customer knows what is wanted, based on intense earlier analysis of the 
>> mission, its scientific or technical aims, SW/HW trade-offs etc. In agile 
>> projects there is flexibility in the scope, the HW, the functionality, 
>> everything.
>
> Agile is coders' response to employers who heard that they should hire S/W 
> engs who use a method: We'll call what we do (shut up and start coding) a 
> method. We'll throw in pair programming so they hire twice as many of us. 
> (When engineering S/W, code generation should be mechanical.)

I think you're confusing "agile programming" with the related but silly 
"extreme programming" and "test-driven development".

Agile programming itself is simply a style where one uses a relatively short 
development cycle with the intent to have a usable/testable version of the 
end product as early and as continuously as possible. This allows feedback 
from the customer and from testing the product itself.

I've *always* programmed in an agile manner, long before anyone decided to 
get rich giving it a name and pushing high-priced seminars. IMHO, the 
lower-case "agile" is the only sane way to develop software.

Imagine building an Ada compiler using a waterfall model. You'd spend a year 
creating design documents. And for what: a well-designed Ada package 
specification is itself a fine design document. I spend time (usually 
outside of the office) thinking about the design of new features, packages, 
and so forth, but I rarely write any of that down until I actually outline 
the package specifications involved. (Sometimes these I'll write down an 
outline, but that's mainly because of the reality of my work these days (and 
also advancing age!), when I might very well go several weeks between 
starting/designing a project and having enough time to actually complete the 
implementation. I won't remember the design details without some notes.)

I also have a meta-rule that I try not to write more code at a time than I 
can write/compile/test in a single day. (Not always practical, but I much 
prefer that.) I try to break dow each taask into subtasks that can be 
completed in a day and preferably tested by itself. The basic idea is to 
always have a working compiler (that's critically important if a customer 
needs an immediate fix -- doesn't happen very often but you can be sure that 
it will happen when the compiler isn't usable :-). Whenever one has a 
working compiler, it's possible to find regressions (a very common problem 
in compiler work), bugs, and some omissions via the test suites (which are 
trivial to run; these days I have them run by a batch file called "X"; can't 
get more trivial than that).

Ada works great for agile programming, as Niklas said, because the compiler 
helps make sure that you've made all of the changes needed as part of a new 
feature. It might make refectoring a bit harder, but that's actually OK -- a 
lot of refactoring is just churn - it might make the code look a bit better, 
but it really doesn't help the ultimate goal (getting a working product). So 
it helps put a brake on the desire to "simplify" everything; rather, one 
only does it when there is really an important reason (usually because code 
needs to be generalized to support a new requirement).

                                      Randy.

Re: How to get Ada to ?cross the chasm??

[Jeffrey R. Carter]

On 05/15/2018 12:21 AM, Randy Brukardt wrote:
> 
> I think you're confusing "agile programming" with the related but silly
> "extreme programming" and "test-driven development".
> 
> Agile programming itself is simply a style where one uses a relatively short
> development cycle with the intent to have a usable/testable version of the
> end product as early and as continuously as possible. This allows feedback
> from the customer and from testing the product itself.

Did you see the Meyer quotes from another post? Clearly "shut up and start 
coding" was a common feature of the Agile projects he reported on.

Iterative methods have been around for a lot longer than Agile, and I've 
preferred them. Short iterations are also often a good idea.

-- 
Jeff Carter
"I've got to stay here, but there's no reason
why you folks shouldn't go out into the lobby
until this thing blows over."
Horse Feathers
50

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:pdf5nq$bcu$1@dont-email.me...
> On 05/15/2018 12:21 AM, Randy Brukardt wrote:
>>
>> I think you're confusing "agile programming" with the related but silly
>> "extreme programming" and "test-driven development".
>>
>> Agile programming itself is simply a style where one uses a relatively 
>> short
>> development cycle with the intent to have a usable/testable version of 
>> the
>> end product as early and as continuously as possible. This allows 
>> feedback
>> from the customer and from testing the product itself.
>
> Did you see the Meyer quotes from another post? Clearly "shut up and start 
> coding" was a common feature of the Agile projects he reported on.

Surely, bad management is possible with any programming style! And following 
some programming technique slavishly without understanding why is clearly 
the mark of bad management.

                       Randy.

Re: How to get Ada to ?cross the chasm??

[Jeffrey R. Carter]

On 05/15/2018 11:32 PM, Randy Brukardt wrote:
> 
> Surely, bad management is possible with any programming style! And following
> some programming technique slavishly without understanding why is clearly
> the mark of bad management.

Yes, and the technique they followed slavishly included "shut up and start 
coding". And it was named Agile.

-- 
Jeff Carter
"My dear Mrs. Hemoglobin, when I first saw you, I
was so enamored with your beauty I ran to the basket,
jumped in, went down to the city, and bought myself a
wedding outfit."
Never Give a Sucker an Even Break
111

Re: How to get Ada to ?cross the chasm??

[Dan'l Miller]

On Wednesday, May 16, 2018 at 11:58:01 AM UTC-5, Jeffrey R. Carter wrote:
> On 05/15/2018 11:32 PM, Randy Brukardt wrote:
> > 
> > Surely, bad management is possible with any programming style! And following
> > some programming technique slavishly without understanding why is clearly
> > the mark of bad management.
> 
> Yes, and the technique they followed slavishly included "shut up and start 
> coding". And it was named Agile.

Yikes!  It sounds like they missed the whole point of Agile:  to get stakeholders actually *talking* to each other (verbally in person, respectfully), instead of blindly throwing something over the cubicle walls at each other that was banged out on the keyboard heads down shut-up.

(I cannot say at all that I am a fervent advocate of Agile in all of its overhyped incarnations.  I especially detest the pairing-of-personnel in Extreme Programming.  The replacement of iterations of well-spoken well-thought-out requirements documents with “stories” on 3"x5" cards seems sophomoric and infantile, and a clear invitation to misinterpretation but then later a defiant attitude “I've got it right here in writing on a 3x5 card” (intentionally cryptically tersely, but we'll just ignore those defects).  But worse, the switch from engineering language to newspaper language (e.g., “stories”; publishing-esque daily deadlines; programmers as journalists interviewing the user to get take-aways/the-scoop) sends our fading-profession further down the road of newspaper hacks, from whence the term hacker in tech culture actually historically derives, both linguistically and semantically.  But all that being said, Agile was supposed to get stakeholders actually speaking verbally to each other, not shut-up and bang away blindly on the keyboard.)

Tying this back to getting Ada to cross the chasm, Ada's nearly-user-readable lucid syntax is actually anathema to the newspaper-hack mentality of Agile zealots, because mere-mortal users are not supposed to be allowed into the inner-sanctum of the sacred newspaper to see how the sausage is made.  Only high-priest bona-fide journalists are allowed into the freedom-of-speech's inner-sanctum at the newspaper, who decides what is & isn't speech and what may be freely said in that speech.  The same with Agile journalist-programmers harshly interpreting the terse crypto-speak on the 3"x5" cards that were taken as journalist's notes during the journalist's interview/press-conference with the user.  If users could lucidly read Ada source code or a textual requirements document (instead of, say, C++ crypto-syntax and C++'s vast amounts of implicit compiler-generated subtle activity in the subtext of the C++ source code that never distinctly occupies even a single overt ASCII character of C++ source code), then any mere-mortal user could have the newspaper's sacrosanct freedom of speech.  And users actually understanding source code just isn't allowed in newspaper-journalist-esque Agile.  Users are only supposed to see the newspaper/program that was published the next day/week based on the 3x5-card journalistic notes in the user-interview/press-conference, and then users are brow-beaten to complain only around the edges about small matters, and then only in ways that cannot be refuted by “Oh yeah?  Well, you said the opposite on this 3x5 card!”

Conversely, Microsoft's pre-Agile form of agile can be thought of as Scrum-cells rethought, where program management are movie directors directing the production of a movie, dynamically forming go-forth-&-prosper scrum-cells/cross-functional-teams to go forth and devise a practical solution to each topic-problem in a short time-duration bringing back their proposed solutions to the movie director's yea or nay, then the personnel are reallocated every few hours or every few days to a different scrum-cell to solve a new problem pursuant to making-the-movie/writing-the-program.  As it turns out, writing software and movie-making are very similar, whereas, in hyped Agile, newspapers don't resemble software development much at all other than having a keyboard to typewrite on.  And I have witnessed this software-development-as-movie-directing variant actually work quite well at high velocity at 2 employers.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
> Yes, and the technique they followed slavishly included "shut up and
> start coding".

If they are shipping product and you're not, maybe their methods deserve
more credibility than yours.

Re: How to get Ada to ?cross the chasm??

[Dan'l Miller]

On Monday, May 14, 2018 at 5:21:28 PM UTC-5, Randy Brukardt wrote:
> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
> news:pd6h9u$tvp$1@dont-email.me...
> > On 05/12/2018 11:29 AM, Niklas Holsti wrote:
> >>
> >> Agile versus waterfall depends on the project's goals rather than the 
> >> language, I feel. In some projects -- space on-board SW is typical -- the 
> >> customer knows what is wanted, based on intense earlier analysis of the 
> >> mission, its scientific or technical aims, SW/HW trade-offs etc. In agile 
> >> projects there is flexibility in the scope, the HW, the functionality, 
> >> everything.
> >
> > Agile is coders' response to employers who heard that they should hire S/W 
> > engs who use a method: We'll call what we do (shut up and start coding) a 
> > method. We'll throw in pair programming so they hire twice as many of us. 
> > (When engineering S/W, code generation should be mechanical.)
> 
> I think you're confusing "agile programming" with the related but silly 
> "extreme programming" and "test-driven development".

https://www.amazon.com/gp/product/3319051547/ref=x_gr_w_bb_sout?ie=UTF8&tag=x_gr_w_bb_sout-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=3319051547&SubscriptionId=1MGPYB6YW3HWK55XCGG2

For people who admire Eiffel (and its historical influence on Ada's pre- and post-conditions), Bertrand Meyer's book _Agile!: The good, the hype, and the ugly_ does a decent job of deconstructing the overheated hype surrounding Agile and its 4 main variants:  Scrum, Extreme Programming, Lean Software, and Crystal.  What remains after distilling off the more-volatile gases of the hype is a set of very interesting thoughts to ponder, likely leading to wisdom.

(Of these 4, Lean and Crystal are the least frequently known/hyped.)

https://en.wikipedia.org/wiki/Lean_software_development#Lean_software_practices

https://en.wikiversity.org/wiki/Crystal_Methods

Re: How to get Ada to ?cross the chasm??

[wilson]

On 5/14/2018 6:21 PM, Randy Brukardt wrote:
> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message
> news:pd6h9u$tvp$1@dont-email.me...
>> On 05/12/2018 11:29 AM, Niklas Holsti wrote:
>>>
>>> Agile versus waterfall depends on the project's goals rather than the
>>> language, I feel. In some projects -- space on-board SW is typical -- the
>>> customer knows what is wanted, based on intense earlier analysis of the
>>> mission, its scientific or technical aims, SW/HW trade-offs etc. In agile
>>> projects there is flexibility in the scope, the HW, the functionality,
>>> everything.
>>
>> Agile is coders' response to employers who heard that they should hire S/W
>> engs who use a method: We'll call what we do (shut up and start coding) a
>> method. We'll throw in pair programming so they hire twice as many of us.
>> (When engineering S/W, code generation should be mechanical.)
> 
> I think you're confusing "agile programming" with the related but silly
> "extreme programming" and "test-driven development".
> 
> Agile programming itself is simply a style where one uses a relatively short
> development cycle with the intent to have a usable/testable version of the
> end product as early and as continuously as possible. This allows feedback
> from the customer and from testing the product itself.
> 
> I've *always* programmed in an agile manner, long before anyone decided to
> get rich giving it a name and pushing high-priced seminars. IMHO, the
> lower-case "agile" is the only sane way to develop software.
> 
> Imagine building an Ada compiler using a waterfall model. You'd spend a year
> creating design documents. And for what: a well-designed Ada package
> specification is itself a fine design document. I spend time (usually
> outside of the office) thinking about the design of new features, packages,
> and so forth, but I rarely write any of that down until I actually outline
> the package specifications involved. (Sometimes these I'll write down an
> outline, but that's mainly because of the reality of my work these days (and
> also advancing age!), when I might very well go several weeks between
> starting/designing a project and having enough time to actually complete the
> implementation. I won't remember the design details without some notes.)
> 
> I also have a meta-rule that I try not to write more code at a time than I
> can write/compile/test in a single day. (Not always practical, but I much
> prefer that.) I try to break dow each taask into subtasks that can be
> completed in a day and preferably tested by itself. The basic idea is to
> always have a working compiler (that's critically important if a customer
> needs an immediate fix -- doesn't happen very often but you can be sure that
> it will happen when the compiler isn't usable :-). Whenever one has a
> working compiler, it's possible to find regressions (a very common problem
> in compiler work), bugs, and some omissions via the test suites (which are
> trivial to run; these days I have them run by a batch file called "X"; can't
> get more trivial than that).
> 
> Ada works great for agile programming, as Niklas said, because the compiler
> helps make sure that you've made all of the changes needed as part of a new
> feature. It might make refectoring a bit harder, but that's actually OK -- a
> lot of refactoring is just churn - it might make the code look a bit better,
> but it really doesn't help the ultimate goal (getting a working product). So
> it helps put a brake on the desire to "simplify" everything; rather, one
> only does it when there is really an important reason (usually because code
> needs to be generalized to support a new requirement).
> 
>                                        Randy.
> 
> 
Randy

I think you just presented a very good, realistic programming process. 
Thank you.

Leon

Re: How to get Ada to ?cross the chasm??

[Dennis Lee Bieber]

On Sat, 12 May 2018 12:29:05 +0300, Niklas Holsti
<niklas.holsti@tidorum.invalid> declaimed the following:

>In my view, if your system has a UART and accumulates incoming 
>characters into a line buffer until in comes a CR to end the line, you 
>are allocating space dynamically in the buffer for each incoming 
>character. Now that is an extreme example, but I hope it shows what I am 
>driving at: in principle, if the program uses up space, when needed, in 
>any "memory" that can fill up, it is allocating that space dynamically, 
>even if this "memory" is not the system heap.
>

	By that interpretation, any program using "static arrays" with an index
tracking "current location" can be considered to be doing "dynamic
allocation".



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

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-12 18:45 , Dennis Lee Bieber wrote:
> On Sat, 12 May 2018 12:29:05 +0300, Niklas Holsti
> <niklas.holsti@tidorum.invalid> declaimed the following:
>
>> In my view, if your system has a UART and accumulates incoming
>> characters into a line buffer until in comes a CR to end the line, you
>> are allocating space dynamically in the buffer for each incoming
>> character. Now that is an extreme example, but I hope it shows what I am
>> driving at: in principle, if the program uses up space, when needed, in
>> any "memory" that can fill up, it is allocating that space dynamically,
>> even if this "memory" is not the system heap.
>>
>
> 	By that interpretation, any program using "static arrays" with an index
> tracking "current location" can be considered to be doing "dynamic
> allocation".

Yes, if the static array can become full in a way that prevents the 
program from continuing normally.

As I remember, this discussion started from the common prohibition of 
"dynamic memory allocation" in critical high-reliability SW.

It is probably true that the people who establish and enforce such 
prohibitions mean "dynamic allocation from the system heap", but IMO 
there is a spectrum of "dynamic memory allocation" mechanisms with 
different levels of determinism.

The spectrum starts with the system heap as the least deterministic 
mechanism, passes through "application heaps" or application-defined 
storage pools with more or less dedication to certain types of 
application objects, and ends at the level of the (admittedly extreme) 
example of the UART buffer, which is very deterministic in the sense 
that it contains exactly one type of object (an UART character), and one 
can describe, pretty easily and exactly, the case(s) in which it might 
overflow and what the program should do in those cases.

Anyway, if you are developing SW that "shall not allocate memory 
dynamically", I'm 99% certain that you will satisfy your product 
assurance group if you show that your SW contains no allocators ("new 
sometype") -- even if your SW uses its own memory pools logically 
similar to the system heap. No product assurance person would consider 
the UART buffer as a case of dynamic memory allocation.

The question that interests me is: if dynamic allocation in the system 
heap is too risky for critical SW, where in this spectrum of dynamic 
memory allocation mechanisms does that risk go away, and why? And if 
some risk remains in the mechanism that I would like to use for the SW, 
what should/must I do to defend against that risk?

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> The question that interests me is: if dynamic allocation in the system
> heap is too risky for critical SW, where in this spectrum of dynamic
> memory allocation mechanisms does that risk go away, and why?

The situation you're describing, overflow of a fixed buffer, seems no
different from a stack overflow, and critical-software guidelines
typically prohibit recursion to eliminate the chance of a stack
overflow.  So that buffer overflow possibility should also be
eliminated.

I think of critical embedded applications as being primarily control
applications, i.e. the I/O is to analog or digital ports that are single
wires directly connected to sensors, actuators, etc., with no buffering.

If the application is also communicating with other devices then I'd
hope the communication part of both devices (including flow control to
make sure the buffers never overfill) is included in the verification
process, or else the communication stuff is outside of the critical
portion of the code.

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-12 22:59 , Paul Rubin wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>> The question that interests me is: if dynamic allocation in the system
>> heap is too risky for critical SW, where in this spectrum of dynamic
>> memory allocation mechanisms does that risk go away, and why?
>
> The situation you're describing, overflow of a fixed buffer, seems no
> different from a stack overflow, and critical-software guidelines
> typically prohibit recursion to eliminate the chance of a stack
> overflow.  So that buffer overflow possibility should also be
> eliminated.

The difference is how the overflow can/cannot be eliminated.

Taking the wide interpretation of "dynamic allocation", stack space is 
indeed dynamically allocated by every push and released by every pop. 
But a suitable programming discipline (no recursion, no dynamically 
sized stack-allocated data) allows a static computation of an upper 
bound on the stack usage. Statically allocating a stack area of that 
size eliminates the risk of overflow.

For the UART input-line buffer, the number of non-CR characters received 
before a CR character depends on external causes; the receiving program 
cannot control it; it can only control what it, itself, does, if the 
buffer threatens to overflow.

> I think of critical embedded applications as being primarily control
> applications, i.e. the I/O is to analog or digital ports that are single
> wires directly connected to sensors, actuators, etc., with no buffering.

I think most such applications also have logging functions, at least in 
order to report errors as anomaly events. Such events could occur at a 
higher rate than the log channel can consume them.

> If the application is also communicating with other devices then I'd
> hope the communication part of both devices (including flow control to
> make sure the buffers never overfill)

Flow control can also *cause* buffer overflow: if the receiver says 
"stop sending" to the sender, it can cause overflow of the sender's 
transmission queue. Queue-length bounds become a global system problem.

> is included in the verification
> process, or else the communication stuff is outside of the critical
> portion of the code.

To be sure the communication stuff should usually be considered less 
critical than the control part. But today, when time-and-space-isolated 
partitions are not yet common, they are still part of the same program, 
thus usually under the same coding and design rules.

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> For the UART input-line buffer, the number of non-CR characters
> received before a CR character depends on external causes;

1) In a critical system, the sending end would be part of the system and
it wouldn't be allowed to send that many characters

2) the receiving end could have to process one character at a time (or
one token at a time, any token > N chars considered invalid and so the
chars can be thrown away one by one).  Port speed would be set low
enough to satisfy WCET requirements on the receiving end.  In a case
where flooding is even possible, the sending end must be non-critical.

> I think most such applications also have logging functions, at least
> in order to report errors as anomaly events.

Well I've never worked on such an application in real life (I arrived at
this subject through being interested in logic and proofs as topics in
math) so you know way more than I do about how they actually work.  But
I imagine the app being something like an engine controller in a car.

So there might be some variables counting how many anomalies of a
given type had occurred, or maybe even a log of the past N such events
for some small fixed N, and there'd be no persistent memory so you'd
have to connect the ECU up to an analyzer before powering it off, or
maybe even run your diagnostics with the analyzer connected.

Maybe in todays cars the ECU could send log data to some centralized
logging computer constantly but the other receiving end would be
non-critical.

> if the receiver says "stop sending" to the sender, it can cause
> overflow of the sender's transmission queue. Queue-length bounds
> become a global system problem.

Sure, just like WCET.  If both ends are critical then analysis must
ensure that overflow doesn't happen.  

> But today, when time-and-space-isolated partitions are not yet common,
> they are still part of the same program, thus usually under the same
> coding and design rules.

Yeah I'm familiar with big apps that aren't realtime-critical, and have
a reasonable picture of how very small critical Atom-like apps work.
But I'm aware there is a middle area that's still critical, but more
complicated than the Atom-like stuff, where my picture is hazy.

Re: How to get Ada to ?cross the chasm??

[Dennis Lee Bieber]

On Sun, 13 May 2018 10:03:18 -0700, Paul Rubin <no.email@nospam.invalid>
declaimed the following:


>Well I've never worked on such an application in real life (I arrived at
>this subject through being interested in logic and proofs as topics in
>math) so you know way more than I do about how they actually work.  But
>I imagine the app being something like an engine controller in a car.
>
>So there might be some variables counting how many anomalies of a
>given type had occurred, or maybe even a log of the past N such events
>for some small fixed N, and there'd be no persistent memory so you'd
>have to connect the ECU up to an analyzer before powering it off, or
>maybe even run your diagnostics with the analyzer connected.
>
>Maybe in todays cars the ECU could send log data to some centralized
>logging computer constantly but the other receiving end would be
>non-critical.
>

	OBD-II defines a set of available error codes, and the ECU likely has
an array defined for each code supported (not all standard codes need to be
used by all vehicles). For each slot/code, a time-stamp of last occurrence,
a count of repeats (and a count of non-repeats -- some codes will clear
after a number of success cycles).

	IOWs; the log is bounded -- it is not something like a Linux syslog
file that just grows based upon the amount of logged activity until some
operation may rotate files...



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

Re: How to get Ada to ?cross the chasm??

[Dennis Lee Bieber]

On Sat, 12 May 2018 22:04:32 +0300, Niklas Holsti
<niklas.holsti@tidorum.invalid> declaimed the following:

>
>Yes, if the static array can become full in a way that prevents the 
>program from continuing normally.
>

	Then the program is erroneous either in design or specification -- it
either requires larger array/buffers from the start, or the requirements
need to state what should be done when the existing buffer is filled (drop
new data, drop old data, log an exception and reboot {and yes, that IS a
valid design option}). The buffer space is a process fixed quantity once
initialization has completed; one can not, upon filling a buffer, ask the
system to allocate more memory to the process. In effect, the heap only
exists during initialization, and once transitioned to "running" there is
no more available heap -- anything left might be stack space (though often
even the stack is a predetermined/fixed size)

	Dynamic allocation, by everyone I know, implies asking for memory to be
added to the process space while it is running.


>The question that interests me is: if dynamic allocation in the system 
>heap is too risky for critical SW, where in this spectrum of dynamic 
>memory allocation mechanisms does that risk go away, and why? And if 
>some risk remains in the mechanism that I would like to use for the SW, 
>what should/must I do to defend against that risk?

	As mentioned, the SW requirements should state what the expected
behavior is should a produce fill a buffer faster than a consumer empties
it. And as I mentioned, that could be "drop earliest", "drop newest",
log/reboot (on the basis that the SW/HW appears to be malfunctioning, a
reboot will clear memory and reset hardware devices).

	Attempting to allocate new memory while running changes timing
behavior: incrementing a pointer and comparing to a limit is constant time,
and either succeeds (not full/empty) or fails (full/empty) with defined
processing. Increment/compare followed by optional "ask system to find a
new chunk of memory for the process" has indeterminate timing; especially
if the request also fails -- and if such dynamic allocation of memory to a
process were to be permitted, it would likely need to have locks around it
so that a mult-process system doesn't have two processes trying to allocate
memory at the same time... Timing impact across processes.


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

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-12 23:01 , Dennis Lee Bieber wrote:
> On Sat, 12 May 2018 22:04:32 +0300, Niklas Holsti
> <niklas.holsti@tidorum.invalid> declaimed the following:
>
>>
>> Yes, if the static array can become full in a way that prevents the
>> program from continuing normally.
>>
>
> 	Then the program is erroneous either in design or specification -- it
> either requires larger array/buffers from the start, or the requirements
> need to state what should be done when the existing buffer is filled (drop
> new data, drop old data, log an exception and reboot {and yes, that IS a
> valid design option}).

Yes. But why cannot the same approach be taken for dynamic allocation 
from the system heap? That is, there could be a requirement saying that 
the program should reboot if an allocation from the system heap fails.

I've seen two motivations: One is that a system heap tends to degrade by 
fragmentation, preventing the embedded program from running for an 
indefinite duration, as is usually required. Another motivation is that 
it is too hard to understand and foresee the conditions under which the 
system heap could become full; the users (operators) of the program 
could not be given a rule-book saying what is allowed (certain not to 
cause heap overflow) and what is risky (might cause heap overflow).

I have not kept up with heap structures, but I would assume that 
fragmentation can be avoided, at least if the size spectrum of an 
application's heap allocations is known.

The second problem could be approached by some kind of quota system for 
various kinds of data, or (equivalently) by separate heaps dedicated to 
specific kinds of data.

> The buffer space is a process fixed quantity once
> initialization has completed; one can not, upon filling a buffer, ask the
> system to allocate more memory to the process. In effect, the heap only
> exists during initialization, and once transitioned to "running" there is
> no more available heap -- anything left might be stack space (though often
> even the stack is a predetermined/fixed size)

If you a priori forbid dynamic heap allocation at run time, then yes, 
you will not leave any memory for the heap (after initialization, at 
least). But that is your choice.

> 	Dynamic allocation, by everyone I know, implies asking for memory to be
> added to the process space while it is running.

Huh? That seems to be confusing "malloc" with "sbreak", to speak in Unix 
terms.

As you just said, above, an embedded bare-metal program already owns all 
of the memory the machine has, so there is no way to ask for more. The 
question is if some of the memory should be organized into a heap, or 
into several heaps, or other kinds of dynamically allocated memory.

> 	Attempting to allocate new memory while running changes timing
> behavior: incrementing a pointer and comparing to a limit is constant time,
> and either succeeds (not full/empty) or fails (full/empty) with defined
> processing. Increment/compare followed by optional "ask system to find a
> new chunk of memory for the process" has indeterminate timing; especially
> if the request also fails -- and if such dynamic allocation of memory to a
> process were to be permitted, it would likely need to have locks around it
> so that a mult-process system doesn't have two processes trying to allocate
> memory at the same time... Timing impact across processes.

Ok, that shows two more possible motivations for not using system heap: 
variability of the time required for allocation (and perhaps for 
release, too), and the need to use locks if the heap is shared by 
multiple tasks. But some heap structures have good WCET bounds (buddy 
systems, for example), and many acceptable data structures need locks 
(inter-task message queues, for example). So I don't feel that these 
motivations are as strong as the two I quoted above.

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

Re: How to get Ada to ?cross the chasm??

[Dennis Lee Bieber]

On Sun, 13 May 2018 16:41:51 +0300, Niklas Holsti
<niklas.holsti@tidorum.invalid> declaimed the following:

>Ok, that shows two more possible motivations for not using system heap: 
>variability of the time required for allocation (and perhaps for 
>release, too), and the need to use locks if the heap is shared by 
>multiple tasks. But some heap structures have good WCET bounds (buddy 
>systems, for example), and many acceptable data structures need locks 
>(inter-task message queues, for example). So I don't feel that these 
>motivations are as strong as the two I quoted above.

	The message queue tends to be a bounded time -- you know (or can
determine) the worst case time to perform lock, adjust queue pointers,
unlock... and if needed, interrupts are disabled so no task switch takes
place. If using circular buffers, one may not even need locks as the write
pointer must be "ahead" (in the circle) of the read pointer (I forget if
the implementation used "same => empty queue" or "delta of 1 => empty") and
(as the message queues tend to be defined as one producer, one consumer)
incrementing pointers can be done without locking.


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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>> Its implementation techniques are startlingly clever
> There have been compilers of higher-level languages that generate
> threaded code that looks like the code one expects from Forth;

Sure, threaded code has been around forever, but Forth's cleverness goes
way beyond that: see Yosefk's article that I linked to.  

> on the other hand, I believe there are now Forth compilers that can
> emit a more conventional kind of code.

Yes, those have been around forever too: just generate machine
instructions instead of an address list, and maybe add a little bit of
peephole optimization.  In Forth jargon this is called "subroutine
threading".  Less common but also well-established are actual optimizing
compilers with register allocation, that track the stack flow so that
when the top few stack slots are in registers, words like SWAP generate
no code at all.

> I'm not sure if threaded code was invented in connection with Forth,

I don't think so.

> If you want a thrill (hair-raising kind), have a look at how Gforth
> implements threaded Forth code by cutting and splicing machine code
> generated by gcc from C source for the interpreter.

Yes, that's quite amazing :).

> an HP2100 16-bit mini... we considered implementing a Forth system --
> the commercial Forth costing more than the university was eager to
> pay.

Hmm, http://forth.org/fig-forth/contents.html doesn't show a FIG-Forth
(public domain Forth) port to that machine, slightly surprising.  I
don't have the impression that the commercial Forths of the era
(Polyforth?) were very expensive for an institutional budget (i.e. they
were more like Janus Ada than GNAT Pro to use a c.l.a. comparison) but I
don't know your university's budget or what Forth Inc was actually
charging.

> In the end we used HP-Algol instead. The programming process was
> "interesting". To edit a source code file: load the interactive editor
> from paper tape, load the source code from paper tape...

Yikes!  Yeah people like Forth because it avoided that type of thing.
BASIC might have been another possibility?

> The interactive Forth had a certain attraction, in comparison.

Exactly so.

> There are very few situations were I would consider using Forth;
> possibly for some very small embedded device that must be
> reprogrammable on itself, without cross-programming from a PC.

It can also be useful to include Forth as a configuration or debugging
interface in an embedded device.  

> I cannot resist to note that I implemented a cooperative multi-tasker
> for the HP2100 Algol system eulogized above. It was dirt simple: the
> machine had two working registers and no stack.

Nice :)

> I seem to have difficulty communicating my point here. Do you equate
> "dynamic" with "heap"?

Well Forth has something like a malloc heap but it's actually rather
rarely used, and I somewhat mis-used the term when I referred to heap
allocation.  The main chunk of storage in Forth is called the
"dictionary" because word definitions go there, but basically everything
else goes there too.  It's a linear chunk of memory where allocation
happens by moving a pointer forward, and de-allocation usually doesn't
happen except by rebooting the system.  So you'd create an array by
moving the pointer forward that many words, and then you'd have the
array forever.

> In my view, if your system has a UART and accumulates incoming
> characters into a line buffer until in comes a CR to end the line, you
> are allocating space dynamically in the buffer for each incoming
> character.

I would say a typical Forth app wouldn't do that during operation.  It
might read single characters or fixed sized packets from the UART, using
a software protocol or hardware flow control to make sure the other side
didn't send stuff before the receiving program was ready.

For interaction, Forth traditionally has a fixed array called TIB
(terminal input buffer) which holds a line of input.  I'm not sure if
the standard says what is supposed to happen if you type too long a
line.  ISTR it says that TIB is supposed to be at least 84 bytes in a
conforming implementation, unless the limitation is documented.

> The problem in a main-loop system is combining high-frequency tasks
> with low-frequency tasks that do complex computations. The main loop
> has to suspend and resume the complex computation frequently, which is
> not so easy unless one does a full task-context switch.

Atom has some stuff to help with that.  You might like the CUFP slides,
that are still in wayback:

https://web.archive.org/web/20131220122421/http://cufp.galois.com/2008/slides/HawkinsTom.pdf

Re: How to get Ada to ?cross the chasm??

[Dmitry A. Kazakov]

On 09/05/2018 00:26, Niklas Holsti wrote:

> I think Dmitry often deals with shorter times and higher task 
> frequencies. But then his stuff is ground-based and runs on more 
> powerful processors.

True.

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

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-07 20:49 , Paul Rubin wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> The difference to GC is determinism and efficiency. You don't need to
>> lock in order to decide if the object must be reclaimed.
>
> I don't see it.  I saw the word "lock" and thought you meant a
> concurrency lock, but I think you mean the notorious GC pause.  Yes that
> was a noticible issue in the 1980s but it's much less of one now.  In
> any case, something similar happens with refcounting: if you drop the
> last reference to a large structure, you have to recursively traverse
> the structure to decrement the refcount of everything that the structure
> contains pointers to.  So you still get arbitrarily long pauses.

True in general, but in the kinds of applications that I work on, and I 
believe in Dmitry's applications too, the length of such nested pointer 
chains is small and bounded. In fact, in all my current uses of 
reference counting, there are no nested pointers in any 
reference-counted object, so no recursive ref-count decrementation.

For the general case, I remember seeing some papers where the recursive 
reference-count decrementation was amortized over time, by recursing 
only by a bounded amount, and leaving (enqueuing) the rest of the job 
for later. This is similar to the GC systems where collection pauses are 
bounded.

> Regarding concurrency: any concurrent system is non-deterministic by
> definition.  So handling non-determinisism is simply part of the deal
> when you find yourself writing a concurrent program.

When one writes a concurrent program, the aim is to ensure that the 
program behaves as deterministically as required, even though the inputs 
are non-deterministic in content or timing. For example, schedulability 
analysis is one tool for ensuring a deterministic result (deadlines are 
met) in the face of non-deterministic inputs (variable input timings and 
task triggerings).

Additional non-determinism from the run-time SW system, such as 
garbage-collection pauses or large variations in allocation times due to 
heap fragmentation, is then an undesirable complication.

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

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-07 10:25 , Dmitry A. Kazakov wrote:
> On 07/05/2018 03:31, Paul Rubin wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> This is easily done in present Ada using handles to a
>>> reference-counted objects.
>>
>> That's not much different from gc from the user's perspective, other
>> than problems handling cycles.
>
> Cycles are easily avoidable too by separating target objects and
> handles. All target objects types go into the private part of the
> package. When only handles are visible there is no way the end user
> could construct a cycle.

True for a single such data structure; much harder if the client 
combines different, independently implemented data structures and 
stores, in one structure, handles that point at the other structure, and 
perhaps in the other direction too. Since the implementations of the two 
data structures are ignorant of each other's existence, neither can 
detect such cross-structure cycles, I believe.

GC-based languages handle such cross-structure cycles in the same way as 
within-structure cycles.

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

Re: How to get Ada to ?cross the chasm??

[Dmitry A. Kazakov]

On 2018-05-08 23:28, Niklas Holsti wrote:
> On 18-05-07 10:25 , Dmitry A. Kazakov wrote:
>> On 07/05/2018 03:31, Paul Rubin wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>> This is easily done in present Ada using handles to a
>>>> reference-counted objects.
>>>
>>> That's not much different from gc from the user's perspective, other
>>> than problems handling cycles.
>>
>> Cycles are easily avoidable too by separating target objects and
>> handles. All target objects types go into the private part of the
>> package. When only handles are visible there is no way the end user
>> could construct a cycle.
> 
> True for a single such data structure; much harder if the client 
> combines different, independently implemented data structures and 
> stores, in one structure, handles that point at the other structure, and 
> perhaps in the other direction too. Since the implementations of the two 
> data structures are ignorant of each other's existence, neither can 
> detect such cross-structure cycles, I believe.

Yes, but that is a bad design anyway. I would say that all such cases 
fall into the category when references going in one direction are strong 
and the backward ones are weak.

> GC-based languages handle such cross-structure cycles in the same way as 
> within-structure cycles.

Yes, but my argument is that it only hides the logical error. The 
reference that is semantically weak acts as a strong one preventing 
collection of an unused object. Circular references are never right.

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> Yes, but my argument is that it only hides the logical error. The
> reference that is semantically weak acts as a strong one preventing
> collection of an unused object. Circular references are never right.

I don't see the issue here.  Circular linked lists are a venerable data
structure of which there are many assembly code examples in Knuth vol 1
from the 1960s.  Similarly, graphs are data and some of them have
cycles.  Some algorithms might have trouble with cyclic data, but others
handle it ok.

Re: How to get Ada to ?cross the chasm??

[Dmitry A. Kazakov]

On 09/05/2018 09:23, Paul Rubin wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> Yes, but my argument is that it only hides the logical error. The
>> reference that is semantically weak acts as a strong one preventing
>> collection of an unused object. Circular references are never right.
> 
> I don't see the issue here.  Circular linked lists are a venerable data
> structure of which there are many assembly code examples in Knuth vol 1
> from the 1960s.

Sure, but references in such a list should never be used for memory 
management. This is because a list is not an object/container, it a pair 
of steps down on the abstraction ladder.

> Similarly, graphs are data and some of them have
> cycles.  Some algorithms might have trouble with cyclic data, but others
> handle it ok.

Graphs are exemplary for the need of a careful design with weak and 
strong references. BTW, reference counted nodes have an advantage that 
you can decide if the subgraph is shared with another task, and not to 
clone it before updating if it is not. My point is that all such 
situations are subject for careful design (of memory management in 
particular). GC is only an obstacle here.

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

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-09 00:46 , Dmitry A. Kazakov wrote:
> On 2018-05-08 23:28, Niklas Holsti wrote:
>> On 18-05-07 10:25 , Dmitry A. Kazakov wrote:
>>> On 07/05/2018 03:31, Paul Rubin wrote:
>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>>> This is easily done in present Ada using handles to a
>>>>> reference-counted objects.
>>>>
>>>> That's not much different from gc from the user's perspective, other
>>>> than problems handling cycles.
>>>
>>> Cycles are easily avoidable too by separating target objects and
>>> handles. All target objects types go into the private part of the
>>> package. When only handles are visible there is no way the end user
>>> could construct a cycle.
>>
>> True for a single such data structure; much harder if the client
>> combines different, independently implemented data structures and
>> stores, in one structure, handles that point at the other structure,
>> and perhaps in the other direction too. Since the implementations of
>> the two data structures are ignorant of each other's existence,
>> neither can detect such cross-structure cycles, I believe.
>
> Yes, but that is a bad design anyway. I would say that all such cases
> fall into the category when references going in one direction are strong
> and the backward ones are weak.

That makes it difficult to maintain value semantics for these data 
structures; how could one have "weak" and "strong" values?

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

Re: How to get Ada to ?cross the chasm??

[Dmitry A. Kazakov]

On 2018-05-09 21:41, Niklas Holsti wrote:
> On 18-05-09 00:46 , Dmitry A. Kazakov wrote:
>> On 2018-05-08 23:28, Niklas Holsti wrote:
>>> On 18-05-07 10:25 , Dmitry A. Kazakov wrote:
>>>> On 07/05/2018 03:31, Paul Rubin wrote:
>>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>>>> This is easily done in present Ada using handles to a
>>>>>> reference-counted objects.
>>>>>
>>>>> That's not much different from gc from the user's perspective, other
>>>>> than problems handling cycles.
>>>>
>>>> Cycles are easily avoidable too by separating target objects and
>>>> handles. All target objects types go into the private part of the
>>>> package. When only handles are visible there is no way the end user
>>>> could construct a cycle.
>>>
>>> True for a single such data structure; much harder if the client
>>> combines different, independently implemented data structures and
>>> stores, in one structure, handles that point at the other structure,
>>> and perhaps in the other direction too. Since the implementations of
>>> the two data structures are ignorant of each other's existence,
>>> neither can detect such cross-structure cycles, I believe.
>>
>> Yes, but that is a bad design anyway. I would say that all such cases
>> fall into the category when references going in one direction are strong
>> and the backward ones are weak.
> 
> That makes it difficult to maintain value semantics for these data 
> structures; how could one have "weak" and "strong" values?

Weak and strong references. E.g let there be a list of files to show, 
the references in the list are weak. In the files directory the 
references to the files are strong. When you remove a file from the 
directory that removes the file and renders the weak reference in the 
list invalid. The list is updated to remove the file from there. If list 
references were strong the file will never be removed.

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

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-07 00:02 , Dmitry A. Kazakov wrote:
> On 2018-05-06 21:27, Niklas Holsti wrote:
>
>>> "Applicative" is not a substantial property that hints any concrete
>>> implementation of publisher/subscribers bound through the data
>>> structure. If Ada should do anything, then provide much better support
>>> for user ADTs than it has now.
>>
>> An applicative data structure is a data structure that can be mutated
>> only by constructing what seems to be a modified copy of the entire
>> original data structure, but without actually copying most of the
>> data, and leaving the original data structure available unmodified.
>
> That is not a visible property the client may or should see.

The client naturally sees if the data structure provides an interface 
with value semantics or with reference semantics. Value semantics are 
nicer for the client, but expensive if the implementation uses full, 
deep, copies. Applicative data structures provide value semantics 
without needing deep copies, by using hidden references.

A client with infinite time and space resources would not care if the 
value semantics are provided expensively or cheaply. A client with 
finite resources does care.

>> In other words, a mutated version of the structure can be constructed
>> only by applying a function to the original version, with the function
>> returning the mutated version without harm to the original version.
>
> This is easily done in present Ada using handles to a reference-counted
> objects.

Yes, it surely can be implemented in Ada, for some value of "easily". 
The GC-based languages, especially the lazy functional ones, provide 
value semantics by default, and systematic ways to make value semantics 
efficient by means of applicative data structures.

> As I said it is quite easy and I used the described approach many times,
> e.g. for dealing with decision trees.

I too have implemented such things in Ada. I would not call it "quite 
easy", however.

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

Re: How to get Ada to ?cross the chasm??

[Dmitry A. Kazakov]

On 2018-05-08 23:02, Niklas Holsti wrote:
> On 18-05-07 00:02 , Dmitry A. Kazakov wrote:
>> On 2018-05-06 21:27, Niklas Holsti wrote:
>>
>>>> "Applicative" is not a substantial property that hints any concrete
>>>> implementation of publisher/subscribers bound through the data
>>>> structure. If Ada should do anything, then provide much better support
>>>> for user ADTs than it has now.
>>>
>>> An applicative data structure is a data structure that can be mutated
>>> only by constructing what seems to be a modified copy of the entire
>>> original data structure, but without actually copying most of the
>>> data, and leaving the original data structure available unmodified.
>>
>> That is not a visible property the client may or should see.
> 
> The client naturally sees if the data structure provides an interface 
> with value semantics or with reference semantics.

How? Usually Ada does not advertise the method of parameter passing.

> Value semantics are 
> nicer for the client, but expensive if the implementation uses full, 
> deep, copies. Applicative data structures provide value semantics 
> without needing deep copies, by using hidden references.

Maybe you mean mutability here. By-value can be mutable if there is an 
identity of the object keeping the value.

> A client with infinite time and space resources would not care if the 
> value semantics are provided expensively or cheaply. A client with 
> finite resources does care.
> 
>>> In other words, a mutated version of the structure can be constructed
>>> only by applying a function to the original version, with the function
>>> returning the mutated version without harm to the original version.
>>
>> This is easily done in present Ada using handles to a reference-counted
>> objects.
> 
> Yes, it surely can be implemented in Ada, for some value of "easily". 
> The GC-based languages, especially the lazy functional ones, provide 
> value semantics by default, and systematic ways to make value semantics 
> efficient by means of applicative data structures.

I don't see how

    X := new T'(...);

is much simpler than

    Handle := Ref (new T'(...));

You could have the sugar above if you convinced ARG to finally introduce 
user-defined access types.

With more luck you could convince them to have user-defined assignment, 
to be able to write:

    Handle := T'(...);

Or even user-defined aggregates and constructors to write just:

    Handle := (...);

>> As I said it is quite easy and I used the described approach many times,
>> e.g. for dealing with decision trees.
> 
> I too have implemented such things in Ada. I would not call it "quite 
> easy", however.

You need to do it only once, actually. Handles are easily reused. The 
only problem is generics.

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

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-06 12:53 , Dmitry A. Kazakov wrote:
> On 2018-05-06 10:34, Niklas Holsti wrote:
    ...
>> Moving the focus back to Ada, efficient applicative data structures
>> are interesting for real-time systems because they could reduce
>> locking/blocking times: a "reader task" could quickly grab a (logical)
>> immutable copy of a large data structure and read the data at its own
>> speed, without interfering with "writer" tasks that transform their
>> own (logical) copies of the data structure.
>
> You need to merge incoherent copies at some point later. More removed
> the point is, more difficult it becomes and more expensive could be a
> rollback, in case something happens.

One of the beauties of applicative data structures is that there is no 
need to roll back changes to a structure; if you keep a reference to the 
original structure, it remains valid (using more memory, of course).

The paper that Paul Rubin referenced has a nice example: when they 
changed their compiler's control-flow graph into an applicative 
structure, they could let the compiler perform some potential 
optimizations eagerly and early, before the optimization is known to be 
valid; if it turns out to be invalid, it can be "rolled back" simply by 
discarding the optimized version of the control-flow graph and returning 
to the un-optimized version.

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> The Ada programs for satellites on which I am currently working often
> meet with such problems, and either work slower (mutual exclusion
> between readers and writers), use more memory (dual physical copies of
> the data structure) and/or pass the problem to the satellite operators
> (commands to mutate the on-board data structure are delayed or failed
> if the data structure is in use by some reader). Better solutions are
> needed.

I think the natural Ada-flavored solution is use more memory.  You're
describing a classic transactional database update which has
traditionally been implemented using shadow pages.  Basically you write
the record in two places, then commit the transaction by flipping a
pointer.

A low-tech approach if you have MMU hardware is copy-on-write.  That is
how Redis (redis.io) does disk snapshots: when you ask for one, the
process forks, so the child process shares its memory pages with the
parent.  The child process then writes its memory to disk.  If the
parent updates a page while this is happening, the MMU traps the update
and makes a new copy of the page in the parent space.

Using a functional data structure like a red-black tree is also natural,
and this is how Happstack-State (a Haskell database) works.  But I think
its performance isn't that great.

You should definitely check out the book "Purely Functional Data
Structures" by Chris Okasaki if you haven't seen it already.

Because I can't resist, here's a beautiful Haskell implementation of
red-black trees using zippers, with the RB-tree invariants guaranteed by
the type signature:

  https://gist.github.com/2660297 (based on https://redd.it/ti5il)

With newer GHC's you can put the type-level natural numbers directly
into the signature, making it even prettier.

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-06 21:38 , Paul Rubin wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>> The Ada programs for satellites on which I am currently working often
>> meet with such problems, and either work slower (mutual exclusion
>> between readers and writers), use more memory (dual physical copies of
>> the data structure) and/or pass the problem to the satellite operators
>> (commands to mutate the on-board data structure are delayed or failed
>> if the data structure is in use by some reader). Better solutions are
>> needed.
>
> I think the natural Ada-flavored solution is use more memory.  You're
> describing a classic transactional database update which has
> traditionally been implemented using shadow pages.  Basically you write
> the record in two places, then commit the transaction by flipping a
> pointer.

Yes, something like that is sometimes used.

> Because I can't resist, here's a beautiful Haskell implementation of
> red-black trees using zippers, with the RB-tree invariants guaranteed by
> the type signature:
>
>   https://gist.github.com/2660297 (based on https://redd.it/ti5il)

The ideas behind the implementation may be beautiful, but the code is 
painful to my eyes; for example:

    insertAt x (BC pb pa py (EC gb ga (R ul ua ur) gc)) = insertAt g gc
      where p = if pb then B x pa py else B py pa x
            u = B ul ua ur
            g = if gb then R p ga u else R u ga p

One of the things I really like in Ada, and in the Ada programming 
style, is the emphasis on readability, and the ability to provide 
meaningful names for operation parameters, both in the operation 
declaration _and_ in calls. Quick, what is the meaning of the argument 
"py" to insertAt?

The concepts of functional programming are attractive to me, but the 
practical problems or long, position-specific argument lists, and the 
style of using very short identifiers, scare me.

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>    insertAt x (BC pb pa py (EC gb ga (R ul ua ur) gc))...
> Quick, what is the meaning of the argument "py" to insertAt?

Being used to Haskell, I see at a glance that "py" is in the expression
"BC pb pa py ...".  I know right away that BC is a data constructor,
because Haskell is case-sensitive and types and data constructors start
with capital letters while ordinary values use lower-case letters.  So I
look at where BC is defined, in the type definition for Context:

    -- we can go left or right from a red node hole, creating a hole for
    -- a black node
      BC   :: Bool -> a -> Node Black n a -> Context m Red n a  
              -> Context m Black n a

So py is a black-colored subtree that goes into a red-colored hole in
the surrounding tree, if I understand zippers properly.

Fwiw, if I mis-remember which arg is which and make a mistake writing
code, I'll almost certainly get a compile-time type error right away and
figure out what went wrong.  It's usual to write this sort of code
interactively, so you type a few lines, invoke the compiler, fix any
errors it reports, and repeat.  If the module you're working on isn't
too large, the compilation happens very fast.

> The concepts of functional programming are attractive to me, but the
> practical problems or long, position-specific argument lists, and the
> style of using very short identifiers, scare me.

The short-identifier style is helped out a lot by the type system
catching simple mistakes.  That moves the "cursor" of convenience vs
verbosity more towards convenience than where a typeless language would
have it, for a given level of error avoidance.

Long, position-specific arg lists are usually a code smell to be
avoided, but Haskell has a record syntax if you want to use named
arguments.  Instead of

  data Person = Person String String Int

you can say

  data Person = Person { name :: String, address :: String, age :: Int }

and then

  john = Person { name="John Jones", address="3 Main Street", age=25 }

instead of

  john = Person "John Jones" "3 Main Street" 25

Haskell's record syntax has various drawbacks and is considered a weak
spot in current versions of Haskell, but it is there if you want to use
it.

Also, because it's convenient to create new types in Haskell, you can
give different types to the args of a function, so the type system will
catch putting them in the wrong order.  So the signature of the
file-opening function is:

   openFile :: FilePath -> IOMode -> IO Handle

In Python you'd use a string like "r", "w", or "r+w" to say the file
opening mode, but in Haskell, IOMode is like an enumeration type in Ada:

  data IOMode = ReadMode | WriteMode | AppendMode | ReadWriteMode	 

So if you try to pass a string instead, you get a type error.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> and most certainly I want to hear about languages that solve some
> problems better than Ada currently does. For example, the discussions
> about Rust memory safety, and memory management in general.

Someone asked earlier what has changed in the PL world since the 1980s,
and it seems to me the ideas going into Rust's memory safety might be an
example.  I.e. they seem like an outgrowth of Girard's linear logic from
the late 1980s and its interpretation from the 1990s as a logic of
resources.  I'm not well versed about this though, so maybe I'm wrong.
Anyway, it's an area where Ada could catch up.

> As I see it, when Ada was originally designed to be a wide-spectrum
> language the design was successful in the sense that it covered most
> application areas of the main-stream languages in use at that time;
> only "weird" languages like Lisp and Snobol (as they were seen then)
> were out of scope for the aims of Ada. Today, the spectrum of
> languages is wider, and, in particular, languages that are enabled by
> garbage collection are in common use.

Sure, yet today's interpreted, dynamic languages (Python, Ruby, JS) are
bodged-up sugared versions of Lisp.  So what was different in the 1980s?
Mainly imho, that cpu cycles and memory were a scarce resource then, but
are in abundance now.  So Lisp was used mostly in academia where it was
feasible to use a big expensive computer as the quickest approach to
solving your problem, even if a smaller one would have sufficed with
more effort.

E. W. Dijkstra in his 1972 Turing Award lecture famously said:

    "With a few very basic principles at its foundation, it [LISP] has
    shown a remarkable stability. Besides that, LISP has been the
    carrier for a considerable number of in a sense our most
    sophisticated computer applications. LISP has jokingly been
    described as “the most intelligent way to misuse a computer”. I
    think that description a great compliment because it transmits the
    full flavour of liberation: it has assisted a number of our most
    gifted fellow humans in thinking previously impossible thoughts."

These days though, machine resources are plentiful and we can use those
methods freely, so we do, outside of the areas where they don't work.

> "Movement in any direction takes constant time and requires the
> allocation of two new heap objects." Compare that cost (two heap
> allocations) with traversing a pointer...

Typically with serious GC, allocating new heap objects is basically free
(you bump a pointer in the free memory region).  Collecting them takes
some time that you can measure with profiling, which tends to not be
that large a fraction of total execution time.  I've seen some studies
that indicate GC bloats up a program's memory consumption by 3x-5x but
doesn't have that big an effect on runtime.  That's reasonably borne out
by well-known benchmarks of C vs Java vs Ocaml etc.  Haskell is slower
(unless you write in contorted style) mostly because of lazy evaluation,
I think.  But ISTM that idiomatic Haskell runs around 4x slower than
idiomatic C, which is perfectly sufficient most of the time.

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-07 04:49 , Paul Rubin wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>  ...
>> As I see it, when Ada was originally designed to be a wide-spectrum
>> language the design was successful in the sense that it covered most
>> application areas of the main-stream languages in use at that time;
>> only "weird" languages like Lisp and Snobol (as they were seen then)
>> were out of scope for the aims of Ada. Today, the spectrum of
>> languages is wider, and, in particular, languages that are enabled by
>> garbage collection are in common use.
>
> Sure, yet today's interpreted, dynamic languages (Python, Ruby, JS) are
> bodged-up sugared versions of Lisp.  So what was different in the 1980s?
> Mainly imho, that cpu cycles and memory were a scarce resource then, but
> are in abundance now.

I think there was more to it: Lisp and relatives did not then provide 
the standard functionality that most mainstream applications needed: 
database functions, GUIs, real-world interactions, and so on. They were 
good in their niche, but it would have needed bravery (and probably 
nonstandard language extensions) to embark on translating a COBOL 
application into Lisp.

Today, through lots of development of the principles and practices of 
such languages, and better standardisation and de-facto, internet-based 
standard libraries, this mainstream functionality is available, and so 
the languages can be used for mainstream applications. And, as you say, 
the extra resource requirements have been swamped by the increase in 
mainstream computer resources. Whether that will still continue for long 
is in doubt.

> These days though, machine resources are plentiful

In some contexts (servers desk PCs) yes, in others (embedded systems, 
portable systems, battery-powered systems) not so plentiful.

>> "Movement in any direction takes constant time and requires the
>> allocation of two new heap objects." Compare that cost (two heap
>> allocations) with traversing a pointer...
>
> Typically with serious GC, allocating new heap objects is basically free
> (you bump a pointer in the free memory region).

In a multi-threaded system I believe a lock would be needed, unless 
there are very suitable atomic-update instructions and a smart lock-free 
method.

> But ISTM that idiomatic Haskell runs around 4x slower than
> idiomatic C, which is perfectly sufficient most of the time.

Not sufficient in most of the embedded applictions I have worked on. But 
I admit that space-based systems have been exceptionally 
resource-constrained. Some easing is visible now. While my current 
application has 8 MiB of RAM (up from 4 MiB in the preceding app), a 
colleague is working on satellite SW for a computer with 100 MiB of RAM 
-- an amount that would have been unimaginable a few years ago. But the 
processor clock is only some 60 MHz, IIRC, so while there is lots of 
space, there is not lots of time.

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> I think there was more to it: Lisp and relatives did not then provide
> the standard functionality that most mainstream applications needed:
> database functions, GUIs, real-world interactions, and so on.  They
> were good in their niche, but it would have needed bravery (and
> probably nonstandard language extensions) to embark on translating a
> COBOL application into Lisp.

Of course GUIs originated in Smalltalk and Lisp systems, and SQL can be
seen as a functional programming language with automatic storage
management.  By the time GUIs were mainstream (1990s?) it seems to me
that Lisp systems had all the necessary functions.  COBOL of course
still had the legacy codebase and ecosystem, but the Y Combinator
startup incubator famously has roots in the Viaweb e-commerce system
system (it later became Yahoo Stores) that was originally written in
Lisp.

> In some contexts (servers desk PCs) yes, in others (embedded systems,
> portable systems, battery-powered systems) not so plentiful.

The smallest such systems, true, but the average smart phone these days
has GB of memory and multi-core GHz processors.  (A joke: I've been
wanting for a while to develop a Haskell dialect for small embedded
systems.  It will be called Control-H and the file extension will be a
backspace character.)

Here's a wonderful little low-powered board with a 48 MHz ARM Cortex M0
with 256k of flash memory and 32k of ram:

  https://www.adafruit.com/product/3500

They are shipped with MicroPython (actually the Circuitpython fork)
pre-installed in the flash, so you can plug the board into a USB port
and immediately type Python commands at it.  I have a couple of them and
they are great.  MicroPython uses garbage collection and works fine (if
the program is not too big) with 32k of ram.  It was squeezed with some
pain into the BBC Micro:bit which has 16k of ram, and is being
successfully used in education on that board.

Of course using Python and and a 32k ARM instead of C and a 1k 8-bitter
isn't efficient, but it's a cheap enough part, using 10-20 mW at full
speed, that you frequently won't care.

This functional Lisp dialect for MCUs (written in Finland if you're
feeling nationalistic) was also really cool for a while:
https://github.com/sbp/hedgehog

> [bump allocation] In a multi-threaded system I believe a lock would be
> needed

I think GHC might use a separate minor heap for each thread.
Surprisingly a quick scan of various literature doesn't establish this
firmly though.  I do know that Erlang uses a separate heap per
lightweight process, so some processes can run while others are GCing.

>> idiomatic Haskell runs around 4x slower than idiomatic C
> Not sufficient in most of the embedded applictions I have worked on.

I'd expect those applications have hot and cold spots like everything
else, so the 4x should also usually suffice.  Many space applications
were historically written in Forth on much slower hardware than you're
using now.  Forth traditionally used a simple threaded-code interpreter
that (while quite memory efficient) was maybe 10x slower than assembly
or compiled C code.  You'd use assembly for speed-critical subroutines
and Forth for the rest.  The convincing obstacles to Haskell or Lisp are
more likely to be memory and nondeterminism, than pure speed.

> While my current application has 8 MiB of RAM (up from 4 MiB in the
> preceding app)...  But the processor clock is only some 60 MHz

That's a big fast system compared to the historical Lisp environments!  

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-09 03:53 , Paul Rubin wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>> I think there was more to it: Lisp and relatives did not then provide
>> the standard functionality that most mainstream applications needed:
>> database functions, GUIs, real-world interactions, and so on.  They
>> were good in their niche, but it would have needed bravery (and
>> probably nonstandard language extensions) to embark on translating a
>> COBOL application into Lisp.
>
> Of course GUIs originated in Smalltalk and Lisp systems,

I should have said "UI" rather than "GUI", but my fingers were entrained 
by the currently more common acronym. I had in mind the vendor-specific 
SW tools for creating UIs to databases and other on-line systems, before 
the standard windowing systems and before the web.

> The smallest such systems, true, but the average smart phone these days
> has GB of memory and multi-core GHz processors.

Yes, but energy efficiency is becoming very important even there, for 
battery life and to avoid scorching the user's hands. If a 4x increase 
in execution time means the battery has to be charged 4x as often...

However, I suppose that with a proper OS, it is easier to divide the 
programs running on the device into "hot spots" -- programs/services 
that are always running and account for the major part of the energy -- 
and "cool spots" -- programs that are called up now and then, and for 
which the energy consumption is not critical -- and to choose the 
language for each program accordingly.

> MicroPython uses garbage collection and works fine (if
> the program is not too big) with 32k of ram.

Yes, "if the program is not too big". But I agree that there are many 
applications that fit in such small systems, even with GC and other 
less-than-100% efficiencies.

> This functional Lisp dialect for MCUs (written in Finland if you're
> feeling nationalistic) was also really cool for a while:
> https://github.com/sbp/hedgehog

Looks nice, and why not. There are certainly applications for 
microcontrollers where it is worth-while to use larger HW models to gain 
programming convenience and margins.

>> [bump allocation] In a multi-threaded system I believe a lock would be
>> needed
>
> I think GHC might use a separate minor heap for each thread.
> Surprisingly a quick scan of various literature doesn't establish this
> firmly though.  I do know that Erlang uses a separate heap per
> lightweight process, so some processes can run while others are GCing.

A thread can have its own initial heap, for short-lived thread-local 
data, but in my applications the bigger chunks of data usually end up 
being sent from one thread to another, implying either copying between 
heaps or some kind of inter-thread locking at some later point.

>>> idiomatic Haskell runs around 4x slower than idiomatic C
>> Not sufficient in most of the embedded applictions I have worked on.
>
> I'd expect those applications have hot and cold spots like everything
> else, so the 4x should also usually suffice.

The system engineers (a couple of levels above me in the industrial 
contractor-subcontractor hierarchy) are damnably good at specifying HW 
that is just about sufficient for the SW applications they specify. So 
one tries not to waste HW resources.

There are certainly "cool spots" in the applications that do not 
contribute much to the CPU load, and could be 4x slower without blowing 
the budget. Sometimes one can relax to a more functional programming 
style in those parts, but using different languages and run-time systems 
in "hot" and "cool" spots would be cumbersome in such bare-metal, 
single-program systems.

> Many space applications were historically written in Forth on much
> slower hardware than you're using now.

(I found a list of Forth applications in space at 
http://web.archive.org/web/20101024223709/http://forth.gsfc.nasa.gov/. 
Almost all from the USA, and most using the Harris Forth-oriented 
processor.)

Certainly some of the HW was slower. But the crux of the matter is not 
the absolute HW power, but the cost of margins: can one afford to buy, 
launch, and supply energy to a 4x more powerful processor, just to have 
the luxury of a functional or GC programming language? When the 
necessary algorithms can be implemented more or less as easily in a 
conventional, procedural, non-GC language?

> Forth traditionally used a simple threaded-code interpreter
> that (while quite memory efficient) was maybe 10x slower than assembly
> or compiled C code.  You'd use assembly for speed-critical subroutines
> and Forth for the rest.

Indeed, on small processors with weak instruction sets and short 
registers, using an interpreter can be very advantageous, decreasing 
code size with minor impact on speed. Even the Apollo spacecraft had 
part of their guidance SW implemented in that way.

> The convincing obstacles to Haskell or Lisp are
> more likely to be memory and nondeterminism, than pure speed.

It depends. In embedded SW there are often both very time-critical 
functions and less time-critical functions. Some space-based SW have 
used Lisp-like languages for the latter -- things like higher-level 
planning; failure detection, isolation and recovery; and other functions 
were AI methods are slowly entering.

>> While my current application has 8 MiB of RAM (up from 4 MiB in the
>> preceding app)...  But the processor clock is only some 60 MHz
>
> That's a big fast system compared to the historical Lisp environments!

Sure, but the application requirements are also larger. The CPU load in 
my current application is about 40%. Slowing down the code by factor of 
4x would be impossible with this HW. The system engineers do trade-offs 
between dedicated HW (FPGAs etc) and processor HW (SW functions) and do 
not provide lavish margins for the latter.

Some functions in space-based SW do have almost ridiculous amounts of 
time available. Many anomalies and failures can take hours or days to 
become critical -- say, a loss of attitude control leading to a loss of 
solar electrical power, which must be corrected before the batteries are 
drained. For such functions, the ability to easily program complex, 
AI-like algorithms would be welcome, and I believe is coming into use.

A final note: a couple of years ago, there seemed to be a group within 
the European Space Agency who were promoting Java for on-board SW (I'm 
not sure if this was some real-time Java with limited GC, or normal 
Java). I haven't seen any results so far, but then I don't have much 
visibility into ESA. The hot topic in ESA today seems to be model-based 
design and automatic code generation, which means that the coding 
language is seen as less important.

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> I had in mind the vendor-specific SW tools for creating UIs to
> databases and other on-line systems, before the standard windowing
> systems and before the web.

Oh ok, yeah, those existed on mainframes and were probably written in
assembler and COBOL.  LISP was still ivory-tower in that era, I think.

> Looks nice, and why not. There are certainly applications for
> microcontrollers where it is worth-while to use larger HW models to
> gain programming convenience and margins.

Yes, even in the hardware world, there's claims that 8-bit MCUs are
essentially obsolete and you might as well use a 32-bitter
(e.g. Cortex-M0) no matter how simple your application is.  I wonder
what the most energy efficient commodity MCUs you can get are.  Current
ARM stuff is apparently quite a bit more efficient than the familiar
(though older) PIC and AVR stuff, and even than the TI MSP430 which made
energy efficiency a big selling point.  TI now seems to be moving
towards ARM even in that product line, the MSP432 being Cortex-M4 based.

> in my applications the bigger chunks of data usually end up being sent
> from one thread to another

I'm not sure if this suffices but I know that the GHC GC stops all the
threads while it is running, so it can rearrange the heaps at that time.
Between GC runs, you can copy stuff freely.

In Erlang, all inter-process (and therefore inter-heap) communication is
by copying, except for some large pointer-free objects that are
reference counted, and the overhead doesn't seem too bad.  Here, an
Erlang guy claims that the Curiosity Mars Rover, while programmed in C,
uses an Erlang-like approach to achive reliability:

http://jlouisramblings.blogspot.com/2012/08/getting-25-megalines-of-code-to-behave.html

> (I found a list of Forth applications in space at
> http://web.archive.org/web/20101024223709/http://forth.gsfc.nasa.gov/. Almost
> all from the USA, and most using the Harris Forth-oriented processor.)

The main attraction of the Harris processor for space applications was
that the chip itself was radiation hardened.  I might ask some Forth
people whether much Forth stuff was launched into space on conventional
processors.  I know it was used on the ground a lot for stuff like
telescope control.

> can one afford to buy, launch, and supply energy to a 4x more powerful
> processor, just to have the luxury of a functional or GC programming
> language?

Under the 90-10 rule the idea is you'd accept the 4x slowdown to more
easily write the 90% of the code that's using 10% of the execution
cycles, while still writing the other 10% the "hard" way.  So the total
execution time changes from 0.1+0.9 to 0.4+0.9, a 1.3x slowdown, nowhere
near as bad as 4x.  There's probably a 1.3x typical slowdown from C to
Ada, but I'd consider that to be worth it for Ada's higher safety.

Also the 4x figure was for Haskell, and I think it comes mostly from
laziness rather than GC (you have to use lifted types everywhere, etc.)
With OCaml I believe the typical slowdown is much less than 2x.  

> Indeed, on small processors with weak instruction sets and short
> registers, using an interpreter can be very advantageous, decreasing
> code size with minor impact on speed. Even the Apollo spacecraft had
> part of their guidance SW implemented in that way.

Memory was probably more of a constraint than electrical power, or the
interpreter may have just been more convenient.  I remember reading that
the astronauts' drinking water on Apollo came as a by-product from the
hydrogen fuel cells that produced the electricity.  To produce enough
water for that, the amount of power must have also been pretty high.

> The CPU load in my current application is about 40%. Slowing down the
> code by factor of 4x would be impossible with this HW.

1.3x would be ok though ;).  

> group within the European Space Agency who were promoting Java for
> on-board SW (I'm not sure if this was some real-time Java with limited
> GC, or normal Java).

You can program Java with minimal use of the GC by just avoiding calling
"new".  Lots of Javacard processors have no GC at all.  You call "new"
to create a few objects when the applet starts, and keep using them
through the entire run.  You even can program Lisp the same way, using
data mutation functions like setq (set! in Scheme) heavily, and realtime
Scheme programming is sometimes done that way.  Gerry Sussman (Scheme
co-inventor) programmed the mirror support system for a big telescope in
Scheme that had to respond to mirror vibration at I think some kHz, so
he must have done something to avoid GC pauses.  It's harder in Haskell
where mutation is more of a dirty word.

Re: How to get Ada to ?cross the chasm??

[Marius Amado-Alves]

"There's probably a 1.3x typical slowdown from C to Ada, but I'd consider that to be worth it for Ada's higher safety."

Indeed it would be worth it, but there's no slowdown at all in most reports I've seen from here and there.

Re: How to get Ada to ?cross the chasm??

[Jeffrey R. Carter]

On 05/11/2018 02:20 PM, Marius Amado-Alves wrote:
> "There's probably a 1.3x typical slowdown from C to Ada, but I'd consider that to be worth it for Ada's higher safety."
> 
> Indeed it would be worth it, but there's no slowdown at all in most reports I've seen from here and there.

Correct C is usually slower than correct Ada that does the same thing, because 
an Ada compiler can optimize away many checks that will be left in the C because 
it's too much effort to manually prove that they will never fail.

-- 
Jeff Carter
"C++: The power, elegance and simplicity of a hand grenade."
Ole-Hjalmar Kristensen
90

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
> Correct C is usually slower than correct Ada that does the same thing,
> because an Ada compiler can optimize away many checks that will be
> left in the C because it's too much effort to manually prove that they
> will never fail.

Going by the Alioth shootout and by the Unzip-Ada program discussed here
recently, Ada = 1.3x slower sounds about right to me.  I'd consider that
to be part of the price (and worth paying) for Ada to leave checks *in*
that the C compiler would unsafely omit.  I don't think the Ada compiler
can prove that much safety by itself (maybe a little bit involving
aliases) that a C compiler can't.  SPARK is a different story, but that
ramps up the development effort to a new level.

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-11 20:39 , Paul Rubin wrote:
> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
>> Correct C is usually slower than correct Ada that does the same thing,
>> because an Ada compiler can optimize away many checks that will be
>> left in the C because it's too much effort to manually prove that they
>> will never fail.
>
> Going by the Alioth shootout and by the Unzip-Ada program discussed here
> recently, Ada = 1.3x slower sounds about right to me.

I suspect that if one would look deeply into the C versions of such 
benchmark programs, one would find non-portability (= undefined 
behaviour), and that writing the C in a really portable and well-defined 
form might increase the execution time. But I have no proof.

Robert Dewar used to say that when some Ada source code is _really_ 
semantically equivalent to some C source code, GNAT is expected to 
produce the same machine code for the Ada as GCC/C produces for the C, 
or at last not slower code.

I don't much care about small speed differences; I find C programming so 
painful and disgusting that I would no longer willingly undertake any C 
project. (I am of pensionable age, so I can get out of the rat-race when 
I want to, and focus on my own Ada projects :-))

> I don't think the Ada compiler can prove that much safety by itself
> (maybe a little bit involving aliases) that a C compiler can't.

If one uses specific array index types, as good Ada style requires, an 
Ada compiler can trivially omit many array bounds checks for which a 
bounds-checking C compiler would have to use a global data-flow and 
variable-value analysis to prove that the check could be omitted.

Another Ada win could come from access types with null exclusion.

> SPARK is a different story, but that
> ramps up the development effort to a new level.

The CodePeer analysis tool from AdaCore is a compromise. It can be used 
to prove that no run-time checks will fail, but it is not as 
constraining as SPARK, I believe. On the other hand, it may require more 
manual assistance in the form of contracts added to the Ada source.

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> I suspect that if one would look deeply into the C versions of such
> benchmark programs, one would find non-portability (= undefined
> behaviour), and that writing the C in a really portable and
> well-defined form might increase the execution time.

Sure, that's the point.  That explains the 1.3x slowdown and also
explains why it is worth it.

> Robert Dewar used to say that when some Ada source code is _really_
> semantically equivalent to some C source code, GNAT is expected to
> produce the same machine code for the Ada as GCC/C produces for the C,

Yes, but constructions that express the same programmer intent are not
semantically the same between the two languages.  Particularly a[i] is a
checked reference in Ada and unchecked in C, and similarly a+b is (or
should be) a checked integer addition in Ada, but it's UB in C in the
case of overflow.  

> I don't much care about small speed differences; I find C programming
> so painful and disgusting that I would no longer willingly undertake
> any C project. (I am of pensionable age, so I can get out of the
> rat-race when I want to, and focus on my own Ada projects :-))

Heh, understandable about C, but can I interest you in Haskell for some
new projects ;-)?

> If one uses specific array index types, as good Ada style requires, an
> Ada compiler can trivially omit many array bounds checks for which a
> bounds-checking C compiler would have to use a global data-flow

If you mean the index is in an int range type, then the Ada compiler
should have to make a range check every time you modify the index,
unless it can statically prove that the new value is in range.  So
you've just moved the check from one place to another.

> Another Ada win could come from access types with null exclusion.

True.

> The CodePeer analysis tool from AdaCore is a compromise. It can be
> used to prove that no run-time checks will fail

Oh that sounds interesting.  I didn't know about it.

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-11 22:50 , Paul Rubin wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

>> Robert Dewar used to say that when some Ada source code is _really_
>> semantically equivalent to some C source code, GNAT is expected to
>> produce the same machine code for the Ada as GCC/C produces for the C,
>
> Yes, but constructions that express the same programmer intent are not
> semantically the same between the two languages.  Particularly a[i] is a
> checked reference in Ada and unchecked in C, and similarly a+b is (or
> should be) a checked integer addition in Ada, but it's UB in C in the
> case of overflow.

Yes, but for those examples, I think Robert Dewar would have assumed the 
Ada code to be compiled without the run-time checks, in order to have 
semantic equivalence. Alternatively, the C code would have to guard a[i] 
with checks on i. The case a+b would be harder to guard in the C form.

>> The CodePeer analysis tool from AdaCore is a compromise. It can be
>> used to prove that no run-time checks will fail
>
> Oh that sounds interesting.  I didn't know about it.

As I understand CodePeer, it is basically a weakest-precondition 
generator. You point it at a subprogram and it will give you the weakest 
precondition on parameters and globals that ensures that there will be 
no run-time error in the subprogram. It can also (of course) do 
inter-procedural analysis and make use of the various contracts 
specified in the program, as well as the usual type-specific constraints.

I haven't yet used CodePeer much myself, but a colleage did manage to 
prove run-time-error absence in a full on-board SW project for a quite 
complex instrument controller.

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> As I understand CodePeer, it is basically a weakest-precondition
> generator.  You point it at a subprogram and it will give you the
> weakest precondition on parameters and globals that ensures that there
> will be no run-time error in the subprogram.

Aha, I guess that tells you what contracts to write, so then maybe you
can then back up a level to the callers and do something similar to
ensure the contracts are fulfilled, etc.  It sounds pretty cool, but
apparently it's a proprietary product, not something I can try out
myself.  Thanks though.

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-11 22:50 , Paul Rubin wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

>> If one uses specific array index types, as good Ada style requires, an
>> Ada compiler can trivially omit many array bounds checks for which a
>> bounds-checking C compiler would have to use a global data-flow
>
> If you mean the index is in an int range type, then the Ada compiler
> should have to make a range check every time you modify the index,
> unless it can statically prove that the new value is in range.

Yes, but often the compiler can do that.

> So you've just moved the check from one place to another.

Sometimes that is so. But sometimes the value is used in many places, or 
frequently, and modified in one place, or rarely, so the number of 
checks is reduced, in the static and/or dynamic measure.

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

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:flmdbnFbrgaU1@mid.individual.net...
> On 18-05-11 22:50 , Paul Rubin wrote:
>> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>
>>> If one uses specific array index types, as good Ada style requires, an
>>> Ada compiler can trivially omit many array bounds checks for which a
>>> bounds-checking C compiler would have to use a global data-flow
>>
>> If you mean the index is in an int range type, then the Ada compiler
>> should have to make a range check every time you modify the index,
>> unless it can statically prove that the new value is in range.
>
> Yes, but often the compiler can do that.
>
>> So you've just moved the check from one place to another.
>
> Sometimes that is so. But sometimes the value is used in many places, or 
> frequently, and modified in one place, or rarely, so the number of checks 
> is reduced, in the static and/or dynamic measure.

Also note that in the common special case of loop iteration, no checks are 
needed at all, either at the generation of the index or it's use:

     for I in Arr'Range loop
          ... Arr(I) ...
     end loop;

I cannot be outside of it's range by construction, so no checks needed there 
other than the usual loop termination check, and that being the case, no 
checks are needed on the array indexing, either.

For many of the Ada checks, the existence of a check that can fail indicates 
poorly written Ada code and/or a potential bug. I'm working toward having 
the compiler (optionally) identify these during compilation, so that one can 
improve the code to eliminate the danger *before* testing.

                     Randy.

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-12 00:45 , Randy Brukardt wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
> news:flmdbnFbrgaU1@mid.individual.net...
>> On 18-05-11 22:50 , Paul Rubin wrote:
>>> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>>
>>>> If one uses specific array index types, as good Ada style requires, an
>>>> Ada compiler can trivially omit many array bounds checks for which a
>>>> bounds-checking C compiler would have to use a global data-flow
>>>
>>> If you mean the index is in an int range type, then the Ada compiler
>>> should have to make a range check every time you modify the index,
>>> unless it can statically prove that the new value is in range.
>>
>> Yes, but often the compiler can do that.
>>
>>> So you've just moved the check from one place to another.
>>
>> Sometimes that is so. But sometimes the value is used in many places, or
>> frequently, and modified in one place, or rarely, so the number of checks
>> is reduced, in the static and/or dynamic measure.
>
> Also note that in the common special case of loop iteration, no checks are
> needed at all, either at the generation of the index or it's use:
>
>      for I in Arr'Range loop
>           ... Arr(I) ...
>      end loop;
>
> I cannot be outside of it's range by construction, so no checks needed there
> other than the usual loop termination check, and that being the case, no
> checks are needed on the array indexing, either.

Yes, but for the analogous C loop, a bounds-checking C compiler would 
seldom need deep analysis to come to the same conclusion, using perhaps 
one or two checks on the loop limits against the size of the array 
(which a bounds-checking C compiler would have to pass around, to 
simulate the Ada 'Length attribute).

> For many of the Ada checks, the existence of a check that can fail indicates
> poorly written Ada code and/or a potential bug. I'm working toward having
> the compiler (optionally) identify these during compilation, so that one can
> improve the code to eliminate the danger *before* testing.

I like that idea.

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

Re: How to get Ada to ?cross the chasm??

[J-P. Rosen]

Le 12/05/2018 à 00:04, Niklas Holsti a écrit :
>> Also note that in the common special case of loop iteration, no checks
>> are
>> needed at all, either at the generation of the index or it's use:
>>
>>      for I in Arr'Range loop
>>           ... Arr(I) ...
>>      end loop;
>>
>> I cannot be outside of it's range by construction, so no checks needed
>> there
>> other than the usual loop termination check, and that being the case, no
>> checks are needed on the array indexing, either.
> 
> Yes, but for the analogous C loop, a bounds-checking C compiler would
> seldom need deep analysis to come to the same conclusion, using perhaps
> one or two checks on the loop limits against the size of the array
> (which a bounds-checking C compiler would have to pass around, to
> simulate the Ada 'Length attribute).
I doubt it, because the loop index can be modified at any time. It might
be provable if the index is local to the loop (is it possible in C, or
is it just C++?), its address is not taken, it is not visible from nor
passed to any function, it can be proven that the upper bound is not
changed by the loop...

Very far away from the general guarantee of Ada!

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

Re: How to get Ada to ?cross the chasm??

[Jeffrey R. Carter]

On 05/11/2018 08:59 PM, Niklas Holsti wrote:
> 
> Robert Dewar used to say that when some Ada source code is _really_ semantically 
> equivalent to some C source code, GNAT is expected to produce the same machine 
> code for the Ada as GCC/C produces for the C, or at last not slower code.

Dewar said he had a collection of equivalent C and Ada programs that produced 
identical machine code when compiled with GCC and GNAT.

-- 
Jeff Carter
"Since I strongly believe that overpopulation is by
far the greatest problem in the world, this [Soylent
Green] would be my only message movie."
Charleton Heston
123

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-04 03:07 , Paul Rubin wrote:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> I don't see anything "cyclic" or "self-referential" here. This is just a set
>> of lists, and there is nothing particularly interesting about them (in
>> partcular, there are *no* references involved in a list unless you need to
>> keep a reference to a particular element, certainly doesn't happen here).
>
> This list contains a reference to itself:
>
>     x = 1 : 2 : 3 : x

Can you construct such a list in Haskell without using and setting 
explicit references? I know very little about Haskell, but I can't see 
how it could be done using just functions and applications. Is there 
some kind of "letrec" for recursive data objects (as opposed to 
recursive functions)?

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>>     x = 1 : 2 : 3 : x
> Can you construct such a list in Haskell without using and setting
> explicit references?

If you mean writing the list without using x on both sides of the equal
sign, you could use a fixpoint combinator:
   
    Prelude Control.Monad.Fix> let f = fix ([1,2,3]++)
    Prelude Control.Monad.Fix> take 20 f
    [1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2]

But fix is written something like this:

   fix f = x where x = f x

and there's an explicit reference there.  There's a corresponding object
called the Y combinator in untyped lambda calculus that can be written
without such a reference, but I think it's not possible to write it that
way in a typed system, because of the "strong normalization" property of
typed lambda calculus.  There's some discussion here:

https://en.wikibooks.org/wiki/Haskell/Fix_and_recursion


> Is there some kind of "letrec" for recursive data objects (as opposed
> to recursive functions)?

There's no letrec per se, since ordinary let is allowed to be recursive.
Mathematically when self-reference happens in data rather than functions
it's called "corecursion" rather than recursion, but most people just
call such data recursive, slightly incorrectly I think.  Fwiw, recursive
data is supposedly called "codata".

There's an argument for eliminating unrestricted recursion from
programming so that all functions must eventually return, so codata is
the only way to implement non-termination (like if you wanted to write
an OS).  You get a programming language that's non-Turing-complete (you
can tell by inspection whether a given program halts, based on whether
it uses codata) but the claim is that Turing completeness is not that
useful in practice:

http://www.jucs.org/jucs_10_7/total_functional_programming

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-09 00:31 , Paul Rubin wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>>>     x = 1 : 2 : 3 : x
>> Can you construct such a list in Haskell without using and setting
>> explicit references?
>
> If you mean writing the list without using x on both sides of the equal
> sign, you could use a fixpoint combinator:
>
>     Prelude Control.Monad.Fix> let f = fix ([1,2,3]++)
>     Prelude Control.Monad.Fix> take 20 f
>     [1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2]
>
> But fix is written something like this:
>
>    fix f = x where x = f x
>
> and there's an explicit reference there.

Thanks, this explains it.

> There's an argument for eliminating unrestricted recursion from
> programming so that all functions must eventually return, ...
>
> http://www.jucs.org/jucs_10_7/total_functional_programming

Interesting, especially the places where some appeal is made to 
quantitative termination (complexity) properties. The fact about the 
limitations of languages where all programs necessarily terminate, and 
the consequent need for a hierarchy of languages, were new to me.

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>> and there's an explicit reference there.
> Thanks, this explains it.

Note though that the need for the explicit reference is a consequence of
the type system, not something inherent in the concept of corecursion.
In a lazy version of Scheme you could write that list without any
explicit self-reference using the Y combinator,

    Y = λf. (λx. f (x x)) (λx. f (x x))

(Don't ask me to explain how that works, but there is a description in
Wikipedia).  It's just that the Y combinator can't be written under a
Haskell-style type system, and it allows you to implement unrestricted
recursion.

Re: How to get Ada to ?cross the chasm??

[Nasser M. Abbasi]

On 5/2/2018 5:28 PM, Paul Rubin wrote:

> Here's a complete Haskell program for printing the first 20 prime
> numbers, using cyclic data (what you call "spaghetti"):
> 
>      main = print . take 20 . sieve $ [2..] where
>        sieve (p:xs) = p : sieve [a | a <- xs, a`rem`p /= 0]
> 

fyi, Here is the equivalent Mathematica program

          Prime[Range[20]]

which gives

{2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47,
53, 59, 61, 67, 71}

Shorter, and much easier to understand :)

Mathematica is higher level language, so in a way, the whole
program of prime is build-into the language.

--Nasser

Re: How to get Ada to ?cross the chasm??

[gautier_niouzes]

Le mercredi 2 mai 2018 02:46:40 UTC+2, Paul Rubin a écrit :

> It gets messier when the data contains possibly-circular references to
> other data.  If you want to program without GC for spiritual or moral
> reasons, then sure, you can do it with enough effort.  If you have to
> program without GC for practical reasons (it definitely imposes runtime
> costs and you might be on a small system), then unlucky you, you've got
> some work to do.

Which one?

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

gautier_niouzes@hotmail.com writes:
> Which one?

I don't understand this question.

Re: How to get Ada to ?cross the chasm??

[gautier_niouzes]

Le jeudi 3 mai 2018 09:20:59 UTC+2, Paul Rubin a écrit :
> gautier_niouzes@hotmail.com writes:
> > Which one?
> 
> I don't understand this question.

Which extra work do you expect without GC ?

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

gautier_niouzes@hotmail.com writes:
> Which extra work do you expect without GC ?

For example, in your "corporate bullshit generator" I see functions like:

   function Sentences (Possible_Dialog_Mark : String) return String is
   begin
      case R100 is
         when  1 ..  33 =>  --  Recursion stops in this case. Prob = p.
            return Sentence;
         when 34 ..  80 =>
            return Sentences (Possible_Dialog_Mark) & Sentence;
         when 81 .. 100 =>
            return
               Sentences (Possible_Dialog_Mark) &
               Paragraph_End_Mark & Paragraph_Mark &
               Possible_Dialog_Mark & Sentence;
      end case;
   end Sentences;

This function appears to call itself recursively, generating a bunch of
strings and concatenating them together.  I'm not sure but it looks to
me like these concatenations are done by copying the strings around,
which is quite inefficient once the strings get large and the recursion
gets deep.

What the function is really generating is a tree structure, with nodes
that can be expanded into further nodes or to sentences.  So you should
really represent those sentences as trees, where you print a sentence by
traversing the tree recursively.

You can do the same thing with job titles: they are really structures
too.  If Alice is the co-assistant-vice-president of whatever, then
Alice's assistant would be the assistant-co-assistant-vice-president of
whatever, and so on.  She could have senior and junior assistants,
co-assistants, and executive assistants, they'd have assistants of their
own, etc.

Now let's say Alice's job title is X (represented as a tree).  She hires
Bob as an assistant, so Bob's title is assistant-X.  Bob's job title
should be a node with a field saying "assistant" and a pointer to
Alice's job title.  The company directory has an entry for Alice
containing her name and a pointer to her title, and a similarly entry
for Bob.  Note that Alice's title is a subtree of Bob's title, so they
share structure in memory.

Next, Alice leaves the company.  Bob doesn't get a promotion (keeping in
the spirit of your program, he's an assistant who happens to not assist
anybody) and he is still in the directory.  So you have to keep Alice's
title around until all of her assistants have also left or been promoted
or whatever.  But then you have to free the memory, or else your program
has a leak.

There are various ways you can deal with this storage management issue.
So you can think up a workable approach, implement and debug it, write
regression tests and monitoring for it, etc.  Or you can just not think
about it at all, allocate new data whenever you want, and let GC take
care of freeing it.

I vote for GC :).

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87h8no1nli.fsf@nightsong.com...
...
> What the function is really generating is a tree structure, with nodes
> that can be expanded into further nodes or to sentences.  So you should
> really represent those sentences as trees, where you print a sentence by
> traversing the tree recursively.

Surely, and you can use the tree container to represent such a tree. No GC, 
no explicit memory management, no fuss, no muss.

And similarly in the original code, presuming that it is fast enough. The 
compiler does any needed memory managment. The cost of doing that is rarely 
an issue (see the many threads here on premature optimization).

...
> There are various ways you can deal with this storage management issue.
> So you can think up a workable approach, implement and debug it, write
> regression tests and monitoring for it, etc.  Or you can just not think
> about it at all, allocate new data whenever you want, and let GC take
> care of freeing it.

Or you can just use the built-in facilities of Ada to do the storage 
management and not think about it. The original code above did that and 
somehow you managed to decide that it wasn't good enough unless it had to 
use GC somehow.

> I vote for GC :).

Desire for GC is a good way to tell people who want to build quality 
software from those who just want to throw software at the wall. :-)

In any event, why are you here? There is no realistic chance that Ada will 
ever be changed enough to make it amenable to GC. I proposed such changes 
multiple times in the past and got nowhere with them. (The problem being 
that the location of finalization of most objects is too late for any useful 
GC to be possible -- it's generally associated with the access type, which 
is usually declared at the library level. Thus GC can't clean up most 
objects until the type goes away -- which is usually when the program 
exits.) The compatibility issues have only gotten worse in the mean time --  
we've tied down the finalization rules more in the intervening years, so 
there is likely to be more code that depends upon them.

                                    Randy.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> Surely, and you can use the tree container to represent such a tree.

Is that something like C++ std::shared_ptr that uses reference counting?
Ok, that would work, but is not too much different from GC, has thread
safety issues, etc.

> And similarly in the original code, presuming that it is fast
> enough. The compiler does any needed memory managment.

That program is a huge static data structure embedded in Ada code, so
you have to recompile the whole thing to add a new job title!  You call
that systems software?! ;-)

> The cost of doing that is rarely an issue (see the many threads here
> on premature optimization).

The cost of GC is rarely an issue either, so resisting using it is also
a premature optimization, of course ;).

I do find in C++ the alternative to GC is often copying data around all
over the place, which is what that program does.  That can get
expensive.  If Alice is deep enough in the bureaucracy, her job title
might be a megabyte long.  And if it's copied into the job titles of her
1000s of direct and indirect assistants, that's GB's of memory right
there instead of a few KB of pointers.

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:874ljo1hvy.fsf@nightsong.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> Surely, and you can use the tree container to represent such a tree.
>
> Is that something like C++ std::shared_ptr that uses reference counting?
> Ok, that would work, but is not too much different from GC, has thread
> safety issues, etc.

No, it's a tree container. Just like a list container or map container -- it 
essentially implements a reusable tree structure. How the memory is managed 
is up to the implementation (other than it must be managed -- not leak.)

All of the Ada containers have "cursors", which serve the reference 
function. You need something like that to specify where to insert something 
in a tree ("insert_child (tree, parent)" - the parent is represented by a 
cursor). As with the rest of the container, the implementation of cursors is 
not part of the standard -- the implementation can make them as safe or 
unsafe as they want. (Checking for most problems is allowed but not 
mandated; I would have preferred to mandate checking but lost that 
discussion.)

>> And similarly in the original code, presuming that it is fast
>> enough. The compiler does any needed memory managment.
>
> That program is a huge static data structure embedded in Ada code, so
> you have to recompile the whole thing to add a new job title!  You call
> that systems software?! ;-)

Depends on the job, of course. Much of my software indeed works that way, 
because there is much less security issues with compiled-in settings. (For 
instance, the web server that runs Ada-Auth.org uses a package of parameters 
that require a recompilation to change. No attacker can change those 
parameters, regardless of what bugs occur, since there isn't any runtime 
object.) That only really works for settings that change very rarely -- but 
that is the case with most software anyway (once it is installed, it rarely 
changes again until replaced).

              Randy.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> All of the Ada containers have "cursors", which serve the reference 
> function. You need something like that to specify where to insert something 
> in a tree ("insert_child (tree, parent)" - the parent is represented by a 
> cursor).

Ok, but can you insert the same child tree into multiple places in the
parent?  If yes, what happens if you insert it in 5 places, then delete
3 of them, then insert a few more, then delete some of those?  Is there
reference counting, or are you supposed to do it manually?  If manually,
why would you choose to use such a system if you had an automatic one
available?

What if you want one of the elements of a tree node to be a pointer to
its parent?  That's very common in (say) expression trees in compilers,
which you work on, or similarly in XML DOM objects or the like.  So
that's a natural source of circular structure in data.  In that case,
reference counting can fail because if you delete a node, its subtrees
can become unreachable while still containing references.  GC is a
completely normal way to handle this.

> Depends on the job, of course. Much of my software indeed works that way, 
> because there is much less security issues with compiled-in settings.

There is something to be said for that, but I've still been taught that
a principle of configuration management (CM) is to keep stuff like
compilers away from the system as much as you can, so who knows.  In the
case of the corporate jargon generator though, I'd consider the phrase
lists to be data rather than settings.  So having them compiled into the
program still seems awfully primitive.

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87vac4z2lh.fsf@nightsong.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> All of the Ada containers have "cursors", which serve the reference
>> function. You need something like that to specify where to insert 
>> something
>> in a tree ("insert_child (tree, parent)" - the parent is represented by a
>> cursor).
>
> Ok, but can you insert the same child tree into multiple places in the
> parent?

No, of course not. Because if you could, you'd no longer have a tree. If you 
have shared nodes, then you have a DAG (directed acyclic graph). We talked 
about but ultimately decided not to have a graph container, mainly because 
it is hard to describe how many of the operations would work, particularly 
the iterators. (The iterators have to be able to visit *all* of the nodes 
exactly once in some defined order.)

A DAG or worse yet, an unstructured graph with circularities, is precisely 
the kind of thing I was thinking of when I was talking about "spaghetti 
data".

Data structures should be - ahem - structured! Perhaps they might have some 
weak references (like a cursor) into them, but hopefully not.

...
> What if you want one of the elements of a tree node to be a pointer to
> its parent?

That's a basic part of the tree data structure, every node has a Parent 
operation.

...
> So that's a natural source of circular structure in data.

Nope. You are confusing the references needed to construct a data structure 
with the much weaker ones needed to navigate it. Just because there is a 
mechanism to find the parent doesn't make the structure circular.
Note that as a container, all of the operations on the container keep it 
properly consistent, so if a node is deleted, the parent pointers and the 
like are updated. You (the user of the tree container) do not have to do any 
of this bookkeeping, and you don't have to worry about a broken tree, 
either.

When one builds their own data structures from scratch, one has to worry 
about (accidentally or on purpose) making circularities, about maintaining 
the structure's invariants, as well as memory management. GC might help with 
the memory management end, but a better solution is to let the 
compiler/runtime deal with the entire set of issues by using a pre-made data 
structure. (And you get better syntax and capabilities with the pre-made 
structure, including iterators and (in Ada 2020) aggregates.)

...
>> Depends on the job, of course. Much of my software indeed works that way,
>> because there is much less security issues with compiled-in settings.
>
> There is something to be said for that, but I've still been taught that
> a principle of configuration management (CM) is to keep stuff like
> compilers away from the system as much as you can, so who knows.

Depends on the audience, surely. In programs that I expected to be used by 
less-technical others, one has to provide configuration through a GUI, which 
means that one has to write the GUI, read the results in the main server, be 
prepared to change the configuration on the fly, deal with the tasking 
issues that occur when using variables that might change, etc. A whole heck 
of a lot more work than declaring ...

     package AS_Params is
          Root_Path : constant String := "D:\Webroot\";
          ...
     end As_Params;

This puts the configuration into a single Ada package, so it's not 
distributed everywhere (THAT would be bad). It's easy to find if something 
needs to be changed, and I'm not afraid of compilers (I write 'em as part of 
my living! :-).


> In the
> case of the corporate jargon generator though, I'd consider the phrase
> lists to be data rather than settings.  So having them compiled into the
> program still seems awfully primitive.

See above. I'd probably put all of the phrases into a giant aggregate in a 
configuration package. If someone more ambitious than me wanted to make the 
GUI and other changes necessary to make the things changable on the fly, 
they could do so without altering the rest of the program.

                         Randy.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> A DAG or worse yet, an unstructured graph with circularities, is precisely 
> the kind of thing I was thinking of when I was talking about "spaghetti 
> data".

I still don't understand this angst about circularities.  Edges in a
graph are like streets in a city, that let you navigate from one place
to another.  I don't think the city I live in is "spaghetti" just
because the street topology is such that it's possible to drive around
in circles.  Traffic would be a big mess if we ripped out streets until
that became impossible.

> Nope. You are confusing the references needed to construct a data structure 
> with the much weaker ones needed to navigate it. Just because there is a 
> mechanism to find the parent doesn't make the structure circular.

It's true that you can implement the parent link with weak references
and there are advantages to doing that, but also complications.  

> When one builds their own data structures from scratch, one has to worry 
> about (accidentally or on purpose) making circularities,

Or to misquote Dr. Strangelove, one can stop worrying and learn to love
the GC :).

> [corporate jargon generator] If someone more ambitious than me wanted
> to make the GUI and other changes necessary to make the things
> changable on the fly, they could do so without altering the rest of
> the program.

I spent a little while looking into that and it doesn't seem easy.
There are a few dozen phrase lists that could be made configurable, but
there are also a bunch of different combining rules but if you want
those to be configurable too, you end up designing a DSL to make such
templates.  That's very easy in Lisp but not so easy in Ada.

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-09 23:03 , Paul Rubin wrote:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
    ...
>> [corporate jargon generator] If someone more ambitious than me wanted
>> to make the GUI and other changes necessary to make the things
>> changable on the fly, they could do so without altering the rest of
>> the program.
>
> I spent a little while looking into that and it doesn't seem easy.
> There are a few dozen phrase lists that could be made configurable, but
> there are also a bunch of different combining rules but if you want
> those to be configurable too, you end up designing a DSL to make such
> templates.  That's very easy in Lisp but not so easy in Ada.

It is easy to embed a DSL in Ada, and use the Ada compiler on it.

"Stop worrying and learn to love your Ada compiler!"

I use this technique frequently, when I want a more powerful DSL than 
OpenToken can easily provide, or want a DSL that can be metaprogrammed 
in Ada.

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> It is easy to embed a DSL in Ada, and use the Ada compiler on it.

Maybe reasonable some of the time, maybe even in the case of the CBSG.
The CBSG takes around 7 seconds to compile on a fairly fast box and has
around 100KB of code of which maybe 80% is phrases.  An occasional
update taking 7 seconds is probably ok.  My smallest actively used
(virtual) server has 64MB of ram, which can probably host GNAT.

I won't contrive a scenario of wanting to run the CBSG on an MCU.  Still
though, it seems marginal.  The approach wouldn't scale to something
like a routing table, which can be MBs in size and updated many times a
second, but would want a DSL of its own.

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87lgcszjdn.fsf@nightsong.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> A DAG or worse yet, an unstructured graph with circularities, is 
>> precisely
>> the kind of thing I was thinking of when I was talking about "spaghetti
>> data".
>
> I still don't understand this angst about circularities.  Edges in a
> graph are like streets in a city, that let you navigate from one place
> to another.  I don't think the city I live in is "spaghetti" just
> because the street topology is such that it's possible to drive around
> in circles.

You must live in a rare city with almost all grid streets. (And one would 
not represent a grid using a graph!)
Almost any modern suburb have streets that snake around all which ways 
without getting anywhere useful. (Yes, there's usually some sort of trunk, 
but even those are constrained by topography, such as the lakes here in 
Madison.) That's my definition of spaghetti!! (Aside: I got partially lost 
last night coming back from a friend's house because the normal street was 
closed for construction. I followed a street that started south but turned 
east (away from the freeway!) and had no cross streets that went through to 
the south or east. Definitely a form of spaghetti!!)

> ... you end up designing a DSL to make such
> templates.  That's very easy in Lisp but not so easy in Ada.

Says you, who seems to have no idea of what the capabilities of Ada really 
are or how to use it. These sorts of things aren't difficult and one has the 
huge advantage of actually ending up with code that you can understand again 
5 years in the future. You seem to want to program in a particular style 
that comes from some other programming language, expect to get some sort of 
benefits from doing so in Ada, yet don't seem to understand why a different 
style makes more sense for Ada. We made the serious mistake of making 
allowances in the OOP design for such people, and that led to several of the 
worst features of Ada. And those had no impact on the uptake (or lack 
thereof) of Ada. I surely hope that we've (the Ada community) learned better 
by now.

                                 Randy.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
>> ... you end up designing a DSL to make such
>> templates.  That's very easy in Lisp but not so easy in Ada.
>
> Says you, who seems to have no idea of what the capabilities of Ada really 
> are or how to use it.

Maybe I'm wrong but I see Ada as an Algol/Pascal descended imperative
language partway between C and C++ in let's call it "automation level",
whose main attractions are 1) much higher safety from type and pointer
errors than C or C++ have, and 2) a really serious package and module
system to help encapsulate big system components.

I've enough C, C++, Pascal etc. in my life to have a sense (at least
based on the above) of what to expect from Ada.  Solid low-level code is
one of those things, ease of writing DSL's is not one ;-).  The GNAT
environment is a huge resource hog compared to a small Lisp system
(Janus might be smaller).  The CBSG program takes around 7 seconds to
compile and you're proposing running such a compilation on every update,
instead of a Lisp read or database operation that would take
milliseconds on a system using one of those programs.

Again in the CBSG case, that 7 second compilation is probably ok, nobody
wants to update it that frequently or deploy it across 1000s of
servers.  But the approach doesn't generalize.

> We made the serious mistake of making allowances in the OOP design for
> such people, and that led to several of the worst features of Ada.

Well, that was 1995 and the OOP drugs were in the water everywhere then ;-).
Things are saner now, I think.

Re: How to get Ada to ?cross the chasm??

[Luke A. Guest]

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

> Maybe I'm wrong but I see Ada as an Algol/Pascal descended imperative

You know C and by extension C++ are Algol derives too, right?

> language partway between C and C++ in let's call it "automation level",

I would say Ada’s a much higher level language than C++. I’ve no idea what
you mean by "automation level.”

> whose main attractions are 1) much higher safety from type and pointer
> errors than C or C++ have, and 2) a really serious package and module
> system to help encapsulate big system components.

Also proper generics, a real built in task system which isn’t isn’t just
launching functions in threads and then Join()’ing a la Go.

You should also check out separates, no other language has those. 

> I've enough C, C++, Pascal etc. in my life to have a sense (at least
> based on the above) of what to expect from Ada.  Solid low-level code is

I still say it has the best data structuring abilities of any language.

> one of those things, ease of writing DSL's is not one ;-).  The GNAT

Tools are limited to half arsed re compiler compilers.

> environment is a huge resource hog compared to a small Lisp system
> (Janus might be smaller).  The CBSG program takes around 7 seconds to
> compile and you're proposing running such a compilation on every update,

You can’t compare parsing a language like Ada to LISP, FFS! 


>> We made the serious mistake of making allowances in the OOP design for
>> such people, and that led to several of the worst features of Ada.
> 
> Well, that was 1995 and the OOP drugs were in the water everywhere then ;-).
> Things are saner now, I think.
> 

Oh, your an OOP denier! 

Re: How to get Ada to ?cross the chasm??

[Nasser M. Abbasi]

On 5/9/2018 7:03 PM, Luke A. Guest wrote:

> 
> Oh, your an OOP denier!
> 

I read on the interner that the current trend is functional programming.

OOP is so old fashioned now.

--Nasser
  

Re: How to get Ada to ?cross the chasm??

[Luke A. Guest]

Nasser M. Abbasi <nma@12000.org> wrote:
> On 5/9/2018 7:03 PM, Luke A. Guest wrote:
> 
>> 
>> Oh, your an OOP denier!
>> 
> 
> I read on the interner that the current trend is functional programming.
> 
> OOP is so old fashioned now.

What a load of crap. Functional is way older. OO is useful, the problem is
the other languages which force everything to be an object.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Luke A. Guest <laguest@archeia.com> writes:
>> Maybe I'm wrong but I see Ada as an Algol/Pascal descended imperative
> You know C and by extension C++ are Algol derives too, right?

One can get philosophical but I wouldn't say they are.  

> I would say Ada’s a much higher level language than C++. I’ve no idea what
> you mean by "automation level.”

I wanted to avoid the flame war about HLL vs LLL and just compare how
much language does for the user automatically.  I think C++ is higher
level than C in that regard.  It seems to me that Ada is somewhere
between the two, but I could go for it being equal to C++.  I'd be
interested to hear the case that Ada (by itself) is goes further than
C++.  Ada with SPARK could be seen as different.

> Also proper generics, a real built in task system which isn’t isn’t
> just launching functions in threads and then Join()’ing a la Go.

C++ generics are hackier (so less proper, maybe) but from what I can
tell, at least as powerful as Ada's and maybe more so.  The C++
concurrency TS is not yet standardized but there's some info here:

 http://en.cppreference.com/w/cpp/experimental/concurrency

The Seastar library (http://seastar-project.org/) uses futures/promises
and some C++17 syntactic features in an interesting way.  I'd like to
know if it's as convenient to do something similar in Ada.

Ada's tasking approach is more traditional and may be preferable a lot
of the time though.

> You should also check out separates, no other language has those. 

Do you mean "procedure xyz is separate" so you put the implementation
outside the package body?  In C++ you can say "int someclass::xyz(...)"
for a similar effect.

> I still say it has the best data structuring abilities of any language.

Not sure what you mean by that?  

> Tools are limited to half arsed re compiler compilers.

Or by that?

> You can’t compare parsing a language like Ada to LISP, FFS! 

Of course not!  Lisp just makes it easier to write out nested lists and
manipulate them in functions.  Not too surprising since it stands for
"list processing" after all ;).  That facility is very handy for DSL's.

Fwiw I think the capitalized name LISP fell out of use in the 1970s.
I'd still refer to a 1960s-era program as being written in LISP but a
more recent version of the same program as being written in Lisp.  I'm
not sticky about it myself but I think some Lisp users nowadays get
upset if you say LISP. ;-)

> Oh, your an OOP denier! 

"The problem with object-oriented languages is they've got all this
implicit environment that they carry around with them. You wanted a
banana but what you got was a gorilla holding the banana and the entire
jungle." --Joe Armstrong (inventor of Erlang)

Re: How to get Ada to ?cross the chasm??

[Luke A. Guest]

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

>> You know C and by extension C++ are Algol derives too, right?
> 
> One can get philosophical but I wouldn't say they are.  

And you’re wrong.

>> I would say Ada’s a much higher level language than C++. I’ve no idea what
>> you mean by "automation level.”
> 
> I wanted to avoid the flame war about HLL vs LLL and just compare how
> much language does for the user automatically.  I think C++ is higher
> level than C in that regard.  It seems to me that Ada is somewhere

It’s not a flamewar, try the language, you’ll see. 

> concurrency TS is not yet standardized but there's some info here:
> 
>  http://en.cppreference.com/w/cpp/experimental/concurrency
> 

I’ve not checked it properly yet, but I don’t expect much more than a thin
wrapper around a thread api.

> 
>> You should also check out separates, no other language has those. 
> 
> Do you mean "procedure xyz is separate" so you put the implementation
> outside the package body?  In C++ you can say "int someclass::xyz(...)"
> for a similar effect.

But Ada’s package system helps here as it’s more robust, c++’s way is just
dumping something in another file and let the linker deal with it.

> 
>> I still say it has the best data structuring abilities of any language.
> 
> Not sure what you mean by that?  

As in sizing, alignment and placement. See representation clauses.

>> Tools are limited to half arsed re compiler compilers.
> 
> Or by that?

You mentioned parsing,
> 
>> You can’t compare parsing a language like Ada to LISP, FFS! 
> 
> Of course not!  Lisp just makes it easier to write out nested lists and

I didn’t mention lists. You mentioned compiling the language, I’m talking
about parsing the source which is part of the compilation process.

>> Oh, your an OOP denier! 
> 
> "The problem with object-oriented languages is they've got all this
> implicit environment that they carry around with them. You wanted a
> banana but what you got was a gorilla holding the banana and the entire
> jungle." --Joe Armstrong (inventor of Erlang)
> 

That’s only true for:

1) languages like Java which force everything to be an object.
2) languages like C++ where programmers insist on replacing RTTI because
it’s too slow or not available in the compiler, si they end up producing
this massive object hierarchy.

You don’t do this in Ada, because it’s not retarded. Not everything is an
object. Not everything is a function.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Luke A. Guest <laguest@archeia.com> writes:
>> One can get philosophical but I wouldn't say they are.  
> And you’re wrong.

Well, that's philosophical, but I think of nested functions and scopes
as one of Algol's defining features.  Pascal has them, Ada has them, C
doesn't have them, C++ didn't have them until C++11 lambdas made it so
it sort of half-assedly has them now.

>>> I would say Ada’s a much higher level language than C++.
> It’s not a flamewar, try the language, you’ll see.

Do you have an example?

> But Ada’s package system helps here as it’s more robust

True.  There's a modules proposal for C++ but it is probably a ways out.

>>> I still say it has the best data structuring abilities of any language.
> As in sizing, alignment and placement. See representation clauses.

Sounds like PL/I but Ada seems to be missing decimal representation ;).

> I didn’t mention lists. You mentioned compiling the language, I’m talking
> about parsing the source which is part of the compilation process.

I just mean GNAT is a big system.  I had to install 50+ of MB of Debian
packages (using 100s of MB of disk) in order to compile the CBSG.  By
comparison the Picolisp package (picolisp.com) is 825KB and includes a
database, GUI app framework, Prolog engine, etc.

Of course an Ada compiler could be a lot smaller than GNAT, though
probably not as small as this: http://prog21.dadgum.com/116.html

> You don’t do this in Ada, because it’s not retarded. Not everything is
> an object. Not everything is a function.

The trend in C++ is to move away from OOP towards template generics,
which are descended from Ada generics.  This guy worked on both and the
interview is interesting:

 http://stlport.org/resources/StepanovUSA.html

Re: How to get Ada to ?cross the chasm??

[Dmitry A. Kazakov]

On 2018-05-10 04:07, Paul Rubin wrote:

> The trend in C++ is to move away from OOP towards template generics,
> which are descended from Ada generics.  This guy worked on both and the
> interview is interesting:
> 
>   http://stlport.org/resources/StepanovUSA.html

Many decades old news. It was a mistake at the Ada's side repeated and 
magnified to every possible insanity in C++.

There should never be generics. They greatly damaged the language and 
keep on damaging it, poisoning every language rule and twist any 
language change. To excuse Ada 83, it had no other "generic programming" 
support other than having messy generics. Then there was little 
understanding and interest in that because even plain ADTs were quite 
new then. Generic programming is about sets of ADTs (AKA classes). C++ 
had no such excuse. They failed to design a consistent model of classes, 
gave up and tried to compensate with templates going an "easy" way. What 
a spectacular failure!

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

Re: How to get Ada to ?cross the chasm??

[Shark8]

On Wednesday, May 9, 2018 at 6:41:50 PM UTC-6, Paul Rubin wrote:
> Luke A. Guest writes:
> > I would say Ada’s a much higher level language than C++. I’ve no idea what
> > you mean by "automation level.”
> 
> I wanted to avoid the flame war about HLL vs LLL and just compare how
> much language does for the user automatically.  I think C++ is higher
> level than C in that regard.  It seems to me that Ada is somewhere
> between the two, but I could go for it being equal to C++.  I'd be
> interested to hear the case that Ada (by itself) is goes further than
> C++.  Ada with SPARK could be seen as different.

Ah!
You'll probably want to read this: http://sworthodoxy.blogspot.com/2017/03/comparing-ada-and-high-integrity-c.html

The TLDR conclusion is stated in the first paragraph: "I have often suspected that use of a safety critical or high integrity coding standard for C++ would yield a level of safety and software reliability approximately equivalent to using Ada with no restrictions. [...] I was mostly correct in my suspicions."

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Shark8 <onewingedshark@gmail.com> writes:
> You'll probably want to read this:
> http://sworthodoxy.blogspot.com/2017/03/comparing-ada-and-high-integrity-c.html

Thanks, that is a helpful document.  It seems to me that Ada is safer
than C++ but C++ has more convenient ways to do some things.  I enjoy
using C++ and can write programs in it that seem to work, which is good
enough for some purposes, but I have trouble trusting it for anything
important.  That's why I got interested in Ada.

You've probably seen this: http://yosefk.com/c++fqa/

Re: How to get Ada to ?cross the chasm??

[Luke A. Guest]

Randy Brukardt <randy@rrsoftware.com> wrote:

> worst features of Ada. And those had no impact on the uptake (or lack 
> thereof) of Ada. I surely hope that we've (the Ada community) learned better 
> by now.

What are they?

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Luke A. Guest" <laguest@archeia.com> wrote in message 
news:714867531.547602535.258330.laguest-archeia.com@nntp.aioe.org...
> Randy Brukardt <randy@rrsoftware.com> wrote:
>
>> worst features of Ada. And those had no impact on the uptake (or lack
>> thereof) of Ada. I surely hope that we've (the Ada community) learned 
>> better
>> by now.
>
> What are they?

All of the stuff about anonymous access types along with some other details.

                 Randy.

Re: How to get Ada to ?cross the chasm??

[Jeffrey R. Carter]

On 05/10/2018 12:56 AM, Randy Brukardt wrote:
> 
> Says you, who seems to have no idea of what the capabilities of Ada really
> are or how to use it.

Q: What do you call someone who

* Has said he doesn't know Ada
* Is not trying to learn Ada
* Prefers short programs in write-only languages
* Posts frequently in c.l.a

?

Bonus Q: What do you call such a person whose posts tend to be long?

-- 
Jeff Carter
"I don't know why I ever come in here. The
flies get the best of everything."
Never Give a Sucker an Even Break
102

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
> * Has said he doesn't know Ada

False, I've used it for some simple things and asked for suggestions
about where to study the more advanced features.  It's a huge language
and if "crossing the chasm" means getting everyone to read the 1000 page
(or whatever) ARM, then Ada is doomed.

> * Is not trying to learn Ada

False, you suggested "Ada Distilled" in response to that request
mentioned above and I read it.

> * Prefers short programs in write-only languages

Of course I prefer short programs to long ones that do the same thing.
Don't you?  Are you saying bloat is good?  They are (in general) more
readable since there is less to read.  "Write-only" is in the mind of
the beholder.  "Crossing the chasm" is not going to happen if "hello
world" requires writing a novel.

> * Posts frequently in c.l.a

Well sure, some of the time.  Ada is interesting.

Re: How to get Ada to ?cross the chasm??

[Dennis Lee Bieber]

On Thu, 10 May 2018 10:34:23 -0700, Paul Rubin <no.email@nospam.invalid>
declaimed the following:

>about where to study the more advanced features.  It's a huge language
>and if "crossing the chasm" means getting everyone to read the 1000 page
>(or whatever) ARM, then Ada is doomed.
>

	Then Ada has been doomed since 1980:

"Designed by committee"		(so was COBOL and it lasted)

"Too large"					(and all these things like pre/post-conditions
are just making it larger -- I have a strong suspicion that
pre/post-conditions would be considered dead code to be removed from
avionics software)

"Compiler is too slow"		(something wrong with one's software
development practices when the compiler speed is of more concern than the
lifetime of a correct application)


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

Re: How to get Ada to ?cross the chasm??

[Simon Wright]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

> I have a strong suspicion that pre/post-conditions would be considered
> dead code to be removed from avionics software

If you've proved that the conditions won't be violated, you needn't
generate code to check them - any more than you need to generate code
for language-defined checks.

Then you end up passing invalid data to your inertial reference system
... oops

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
> 	Then Ada has been doomed since 1980:
> "Designed by committee"		(so was COBOL and it lasted)

I don't see that as a problem: Haskell and Scheme were also designed by
committees and PL geeks are very fond of them.

> "Too large"

There's some confusion here, I wrote that

>> if "crossing the chasm" means getting everyone to read the 1000 page
>>(or whatever) ARM, then Ada is doomed.

That doesn't mean the language's largeness implies doom all by itself.
C++ is large but it's mainstream.  The issue is whether you have to read
a 1000 page document to use the language at all, or if it's sufficient
to start with a subset and expand outward from there.  Most C++ users
start with a subset, and I suspect not very many know the full language.
I myself certainly don't.

I would have thought starting with a subset of Ada is also legitimate,
but if it's not, then Ada is probably doomed.

> "Compiler is too slow"		(something wrong with one's software
> development practices when the compiler speed is of more concern than the
> lifetime of a correct application)

That was in the discussion of how to add more phrases to the CBSG, which
is to say, how to change its configuration in a deployment environment.
Randy's answer was to just include the Ada compiler as part of the
deployment, and add phrases by modifying and recompiling the Ada code.

I think Ada programmers are used to the idea of the development
environment and the deployment environment being two different things.
A big slow development environment might be tolerable, but if the Ada
compiler is part of the deployment as well, then its size and speed have
to be considered again.  The program takes 7 seconds to recompile on a
fast x86 box, and 1.5 minutes on an ARM server that I just tested.

Since anything post-deployment is "run time", that number has to be
considered as part of the runtime performance, which makes GNAT (with
this implementation approach) look pretty terrible compared to something
like Forth or Picolisp.

Anyway, one of the claimed advantages of Ada over C++ is that Ada's
module system makes compilation faster, so perhaps you're trying to have
it both ways.

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-10 23:00 , Paul Rubin wrote:
> Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
   ...
>> "Compiler is too slow"		(something wrong with one's software
>> development practices when the compiler speed is of more concern than the
>> lifetime of a correct application)
>
> That was in the discussion of how to add more phrases to the CBSG, which
> is to say, how to change its configuration in a deployment environment.
> Randy's answer was to just include the Ada compiler as part of the
> deployment, and add phrases by modifying and recompiling the Ada code.

Ah, I think that answer/suggestion (embed the DSL in Ada) came from me, 
not initially from Randy.

Clearly, if the SW is deployed on a system that is too small to run the 
Ada compilation quickly, that solution does not work, and one has to 
implement a non-embedded DSL (or simpler input format) that can be read 
and processed rapidly enough. Although the Ada language does not have 
standard support for that (well, beyond the 'Value attribute for 
enumeration types), there are libraries that help.

I often use the OpenToken library where one defines the structure of the 
DSL in the Ada program itself, using an OpenToken-specific meta-DSL 
embedded in Ada, and the program is then immediately able to read and 
parse input text according to that DSL. A little like lex/yacc, but 
without the separate tools and steps to generate the lexer and parser code.

> I think Ada programmers are used to the idea of the development
> environment and the deployment environment being two different things.
> A big slow development environment might be tolerable, but if the Ada
> compiler is part of the deployment as well, then its size and speed have
> to be considered again.  The program takes 7 seconds to recompile on a
> fast x86 box, and 1.5 minutes on an ARM server that I just tested.

The CBSG could perhaps be redesigned to isolate the DSL part into 
separate packages so that only those packages would need to be recompiled.

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> The CBSG could perhaps be redesigned to isolate the DSL part into
> separate packages so that only those packages would need to be
> recompiled.

It is already designed like that.  The package containing those phrases
is the one that takes 1.5 minutes to recompile on the ARM.  Recompiling
the rest of the packages would add even more time, though not that much
more since they are smaller.  The package with the phrases is about 2
KLOC or 100KB, and most of it is string constants, so I have no idea why
its compilation is that slow.

Re: How to get Ada to ?cross the chasm??

[gautier_niouzes]

It's very kind from everybody here to think about deployment and other aspects of the CBSG.
Actually the compile time (a few seconds on a "normal" machine) is perfectly fine for something that is updated a small number of times a year.
The selection of new words takes a lot more than the compile time - browsing lengthy brochures, pick catchy words or expressions...
So there is no need to worry at all about the compilation phase.

On the run time side, the generation of the online page ( http://cbsg.sf.net ) takes around 1/1000 second (time is displayed at the bottom), so there is no rush to tune anything there.

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-11 04:32 , gautier_niouzes@hotmail.com wrote:
> It's very kind from everybody here to think about deployment and
> other aspects of the CBSG.

At least on my part, CBSG is only being used as an example or starting 
point for discussing when it is practical or impractical to embed a DSL 
in Ada, compared to implementing an Ada interpreter for DSL text read in 
at Ada run-time.

> Actually the compile time (a few seconds
> on a "normal" machine) is perfectly fine for something that is
> updated a small number of times a year.

Indeed. The discussion hypothetically assumed much more frequent updates.

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> At least on my part, CBSG is only being used as an example or starting
> point for discussing when it is practical or impractical to embed a
> DSL in Ada, compared to implementing an Ada interpreter for DSL text
> read in at Ada run-time.

Me too, though the comparison on my part was to using a "code is data"
language like Lisp.  Another approach would be to have an embeddable
extension language in a library, which for the GNU project means Guile,
a Scheme interpreter that has gotten quite large and powerful.  The rest
of the world seems to have settled on Lua or sometimes Python or
Javascript for this purpose.  Lua has language warts but is a small and
clean implementation that's nice for embedding.  Python is a nicer
language but its main implementation is rather clumsy IMHO.  And
Javascript is, well, Javascript.

I'm partial to the Scheme/Lisp approach myself and I think Guile is an
admirable Scheme implementation, but it's become closer to a full
featured standalone system, while for embedding purposes I'd prefer
something smaller.

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-11 02:21 , Paul Rubin wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>> The CBSG could perhaps be redesigned to isolate the DSL part into
>> separate packages so that only those packages would need to be
>> recompiled.
>
> It is already designed like that.  The package containing those phrases
> is the one that takes 1.5 minutes to recompile on the ARM.  Recompiling
> the rest of the packages would add even more time, though not that much
> more since they are smaller.  The package with the phrases is about 2
> KLOC or 100KB, and most of it is string constants, so I have no idea why
> its compilation is that slow.

Perhaps the compiler is being asked to optimise the code, which is 
probably useless for this package. Try it with very low optimisation level?

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> Perhaps the compiler is being asked to optimise the code, which is
> probably useless for this package. Try it with very low optimisation
> level?

Yeah I thought of that and will figure out how to do it.  It still
shouldn't be THAT slow though.  Something weird is going on with the
code and/or the compiler.  The 1 ghz ARM box that took 1.5 minutes to
compile it is slow by today's standards but it's much faster than the
servers and workstations in use at the time GNAT was written.

If you actually look at the CBSG, it's full of case statements like

        case R33 is
           when 1  => return "key people";
           when 2  => return "human resources";
           when 3  => return "customers";
           ... (33 total cases)

R33 is a function defined in delerium.adb as follows:

   function R33 return T33 is begin return T33 (R (33)); end;

T33 and R33 are declared in delerium.ads like this:

   type T33 is range 1 .. 33; function R33 return T33;

where R is

   --  R (N) returns a random number between 1 and N.
   function R (N : Positive) return Positive;

There are similar definitions to T33 and R33 for all the integers from 1
to 500.  I.e. 500 integer range types T1...T500 and 500 random number
functions R1...R500, one for each of those types.  A Pentagon-like
approach to software architecture, if you will.  So I wonder if that
might be slowing the compiler down.

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87k1sb1dt3.fsf@nightsong.com...
...
> That doesn't mean the language's largeness implies doom all by itself.
> C++ is large but it's mainstream.  The issue is whether you have to read
> a 1000 page document to use the language at all, or if it's sufficient
> to start with a subset and expand outward from there.  Most C++ users
> start with a subset, and I suspect not very many know the full language.
> I myself certainly don't.
>
> I would have thought starting with a subset of Ada is also legitimate,
> but if it's not, then Ada is probably doomed.

Starting with a subset is certainly fine. Starting with a subset and then 
assuming that *all* of the capabilities of the language are similar to 
what's in the subset is not so fine. But that appears to be what you're 
doing in these discussions -- you understand a Pascal-like subset of Ada and 
then pretty much ignore all of the other possibilities. If you did that for 
C++, you'd get essentially C; would that be a fair way to look at C++'s 
capabilities??

                                 Randy.

Re: How to get Ada to ?cross the chasm??

[Dennis Lee Bieber]

On Thu, 10 May 2018 13:00:24 -0700, Paul Rubin <no.email@nospam.invalid>
declaimed the following:

>Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
>> 	Then Ada has been doomed since 1980:
>> "Designed by committee"		(so was COBOL and it lasted)
>
>I don't see that as a problem: Haskell and Scheme were also designed by
>committees and PL geeks are very fond of them.
>

	<SNIP>

	All my quoted comments were paraphrases (hey, it's been nearly 40
years, my memory isn't that perfect) of statements seen already back in
1980.

	For my comparative language course (so small we met in a conference
room) I used
https://www.amazon.com/Programming-Ada-Introduction-Graduated-Prentice-Hall/dp/0137306970/ref=sr_1_1?ie=UTF8&qid=1525994959&sr=8-1&keywords=ada+graduated+example
and the SIGPlan preliminary RM for my presentation (following the students
who'd chosen Algol and Pascal made it easy -- I could focus on the
differences/improvements rather than reiterate the same basic language
features)





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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
>>> "Designed by committee"		(so was COBOL and it lasted)
> 	All my quoted comments were paraphrases (hey, it's been nearly
> 40 years, my memory isn't that perfect) of statements seen already
> back in 1980.

Oh ok, I thought you were referring to more recent discussion on this
thread.  But I've always thought the claim that Ada (83) was designed by
committee was bogus, because it was in fact designed by Jean Ichbiah.

I've on the other hand seen it claimed that Ada was (my interpretation)
rescued from oblivion by none other than Richard Stallman, who freaked
out at the proposal to make GNAT part of the GNU project, because Ada as
then envisioned couldn't accomodate separate compilation.  Jean Ichbiah
had instead decided there had to be a library of compiled packages that
the compiler had to access while compiling, which made the order in
which separate modules were compiled critical.  After discussions with
Stallman, Bob Dewar then came up with a way to allow Ada packages to be
compiled separately from each other, and everyone uses that scheme
today.  See: http://www.ada2012.org/files/Thoughts_on_Ada.pdf .

> 	For my comparative language course (so small we met in a conference
> room) I used [shortened]  https://www.amazon.com/dp/0137306970

Thanks!  That book is from 1980 though.  I'll keep looking at the online
Ada 2012 stuff for now.

Re: How to get Ada to ?cross the chasm??

[Dennis Lee Bieber]

On Thu, 10 May 2018 17:05:59 -0700, Paul Rubin <no.email@nospam.invalid>
declaimed the following:

>
>Oh ok, I thought you were referring to more recent discussion on this
>thread.  But I've always thought the claim that Ada (83) was designed by
>committee was bogus, because it was in fact designed by Jean Ichbiah.
>

	Remember though, that there was a competition with different teams
offering their take on answering the DoD requirements -- so in that sense
Green is what fell out of the various ideas <G>; and between the winning
Green and Mil-Std 1815 (not 1815A, I'm talking the Dec 1980 standard that
so many seem to forget about) were no doubt some changes made under DoD
suggestion/review.

	All my references are currently in storage (I'm slowly moving across
the county) or I'd maybe have a bit more of that history (in my viewpoint).

	From the foreword to 1815A (hmm, looks like Adobe Reader can OCR the
page images, if a bit imperfectly) reads "Ada is the result of a collective
effort to design a common language tor programming large scale and reek
time systems." (for "tor" read "for" and for "reek" read "real-")

{I hesitate to go further as that foreword is loaded with names of
participants still active here}

>I've on the other hand seen it claimed that Ada was (my interpretation)
>rescued from oblivion by none other than Richard Stallman, who freaked
>out at the proposal to make GNAT part of the GNU project, because Ada as
>then envisioned couldn't accomodate separate compilation.  Jean Ichbiah
>had instead decided there had to be a library of compiled packages that
>the compiler had to access while compiling, which made the order in
>which separate modules were compiled critical.  After discussions with
>Stallman, Bob Dewar then came up with a way to allow Ada packages to be
>compiled separately from each other, and everyone uses that scheme
>today.  See: http://www.ada2012.org/files/Thoughts_on_Ada.pdf .
>

	Hmmm, even that article ignores the three years from Mil-Std 1815 to
1815A. However -- I do wonder how much of that matter could be traced to
the concurrent (to Steelman) STONEMAN requirements from the DoD for an Ada
Programming Support Environment interacting with concepts for the Ada
language itself.
	
>> 	For my comparative language course (so small we met in a conference
>> room) I used [shortened]  https://www.amazon.com/dp/0137306970
>
>Thanks!  That book is from 1980 though.  I'll keep looking at the online
>Ada 2012 stuff for now.

	Well -- so was my senior year when I had that comparative language
course <G>; it is based upon the final Green language proposal, published
nearly a year before Mil-Std 1815.



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

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-11 03:05 , Paul Rubin wrote:

> I've on the other hand seen it claimed that Ada was (my interpretation)
> rescued from oblivion by none other than Richard Stallman, who freaked
> out at the proposal to make GNAT part of the GNU project, because Ada as
> then envisioned couldn't accomodate separate compilation.

Ada has always allowed separate compilation. In the early days of Ada 83 
compilation could be so slow that rebuilding a whole, large program 
could take a week. Separate compilation was essential. Some Ada 
environments (Rational) almost insisted on separate compilation of each 
subprogram, let alone each package.

The issue with Stallman, GNAT and GNU was on the practicalities of 
adapting the GCC compilation model to Ada in a way that also satisfies 
the Ada rules on _when_ an Ada module must be recompiled.

> Jean Ichbiah had instead decided there had to be a library of compiled
> packages that the compiler had to access while compiling,

IAUI this was a DoD requirement for Ada. The central point of the 
library was that separate compilation should not let one circumvent the 
language rules (dependencies, consistency, etc.), whether by mistake or 
on purpose.

> which made the order in which separate modules were compiled critical.

The natural order: if module A depends on the (interface of) module B, 
then the (interface of) module B must be compiled before module A. In 
other words, if (the interface of) module B changes, then module A must 
be recompiled before the program is linked.

The Ada library broke the GCC principle that every source-code file (.c) 
is compiled into an object file (.o), and so broke the principles on 
which "make" operates (by incorporating the dependency-tracking into the 
library).

The library-based Ada compilers were certainly practical for Ada 
programming, and most of them had a tool to suggest a compilation order, 
similar to "make". But inter-language "make" was complicated.

> After discussions with
> Stallman, Bob Dewar then came up with a way to allow Ada packages to be
> compiled separately from each other,

Separate compilation was possible before; what was invented was a way to 
avoid implementing the Ada library concretely as some kind of database 
of the compiled modules.

The idea in the GNAT "source-based library" is to view the set of Ada 
_source code_ files as the "Ada library", and implement "with" in the 
same way as "#include": the withed declarations are (re-)compiled on the 
fly when the withing unit is compiled. The penalty for such 
recompilation is smaller today, with faster machines and compilers.

Then every source-code module (.ads and .adb pair, plus possible 
separate subunits) is compiled into its own object file (.o). The 
compiler further tracks dependencies in the "Ada library information" 
files (.ali) files, which (in a sense) correspond to the dependency 
files that can be automatically generated from a C compilation and 
translated into "make" dependencies.

 > and everyone uses that scheme today.

Some do, some don't.

Certainly the source-based library makes compiling Ada programs more 
similar to the process for other languages and so helps novices start 
with Ada.

It's interesting and somehow paradoxical that many C/C++ programming 
systems implement "precompiled headers" to avoid the recompilation of 
the header files for each "#include". A C/C++ system with precompiled 
headers is implementing a "C library" similar to the original "Ada 
library", although better hidden from the users.

Moreover, I recall that in some C++ compilers it was important to 
compile templates in a particular order, but perhaps this problem has 
been solved now, with the better standardisation of templates.

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> Ada has always allowed separate compilation. In the early days of Ada
> 83 compilation could be so slow that rebuilding a whole, large program
> could take a week. Separate compilation was essential. Some Ada
> environments (Rational) almost insisted on separate compilation of
> each subprogram, let alone each package.

A week?!  Ouch!  Was that the NYU compiler written in SETL?  Anyway
here's another version of that story:

https://www.dwheeler.com/essays/make-it-simple-dewar.html

This was also interesting:

https://www2.adacore.com/gap-static/GNAT_Book/html/node5.htm#SECTION03130000000000000000

But, you unquestionably understand the issue better than I do.

What I don't understand is, why didn't the same issue apply to Pascal?
Didn't it also need whole-program typechecking?  And I wonder what ML
does?  Haskell (GHC) does write out something like interface files (.hi)
generated from the source files, and linking uses them.

> the withed declarations are (re-)compiled on the fly when the withing
> unit is compiled. The penalty for such recompilation is smaller today,
> with faster machines and compilers.

It's just the .ads that's included, right?  Was the speed that bad an
issue even on the old machines?  Is Ada really harder to compile than
Pascal?  I've always liked this article even though I never used Turbo
Pascal:  http://prog21.dadgum.com/116.html

> It's interesting and somehow paradoxical that many C/C++ programming
> systems implement "precompiled headers"

Of course the way C and C++ use headers is horrendous but it's
historical baggage.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Paul Rubin <no.email@nospam.invalid> writes:
> Is Ada really harder to compile than Pascal?  I've always liked this
> article even though I never used Turbo Pascal:
> http://prog21.dadgum.com/116.html

Actually the part I had in mind is in a different post:

  http://prog21.dadgum.com/47.html

It says:

  On one of those cheap, floppy-only, 8088 PC clones from the late
  1980s, the compilation speed of Turbo Pascal was already below the "it
  hardly matters" threshold. Incremental builds were in the second or
  two range. Full rebuilds were about as fast as saying the name of each
  file in the project aloud. And zero link time. Again, this was on an
  8MHz 8088. By the mid-1990s, Borland was citing build times of
  hundreds of thousands of lines of source per minute.

and goes on from there to explain why Turbo Pascal was so fast.

Re: How to get Ada to ?cross the chasm??

[gautier_niouzes]

On Friday, May 11, 2018 at 11:14:27 AM UTC+2, Paul Rubin wrote:

> It says:
> 
>   On one of those cheap, floppy-only, 8088 PC clones from the late
>   1980s, the compilation speed of Turbo Pascal was already below the "it
>   hardly matters" threshold. Incremental builds were in the second or
>   two range. Full rebuilds were about as fast as saying the name of each
>   file in the project aloud. And zero link time. Again, this was on an
>   8MHz 8088. By the mid-1990s, Borland was citing build times of
>   hundreds of thousands of lines of source per minute.
> 
> and goes on from there to explain why Turbo Pascal was so fast.

It is correct - I did lots of Turbo Pascal on a 2nd-hand original IBM PC with two floppies. Since it was 4.7MHz it was a bit slower as described, but later on 25MHz or more machines you needed a large project to notice a rebuild. The compilation was straightforward; the whole effort was on reducing the build time. For instance a compiled unit resulted in a single .tpu file with: the parsed declarations of the specification (called interface) and the machine code of the body (called implementation). When you compiled from the IDE it took source texts from the open editor windows instead of from files to gain a bit of time (much, with floppies). For the fun of it, I've included that latter feature in my LEA project ( https://sourceforge.net/projects/l-e-a/ ) :-)

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-11 12:09 , Paul Rubin wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>> Ada has always allowed separate compilation. In the early days of Ada
>> 83 compilation could be so slow that rebuilding a whole, large program
>> could take a week. Separate compilation was essential. Some Ada
>> environments (Rational) almost insisted on separate compilation of
>> each subprogram, let alone each package.
>
> A week?!  Ouch!  Was that the NYU compiler written in SETL?

I only heard about such cases, never experienced them personally (I 
started using Ada with the DEC VAX Ada compiler, a very decent one, and 
my programs were not that large). AIUI the week-long builds were with 
production Ada compilers, not the SETL-based compiler. But the programs 
involved were quite large, perhaps even by today's standards.

But those were the days when compilation speeds were expressed in Lines 
Per Minute, whatever the source language.

> What I don't understand is, why didn't the same issue apply to Pascal?
> Didn't it also need whole-program typechecking?

The original "teaching" Pascal had no module system and no separate 
compilation so there was no problem.

Later, "production" Pascal programming systems invented their own module 
systems and separate compilation systems, one example being Turbo 
Pascal. Even later, modules were standardised in the new Pascal standards.

I don't know how eg. the GNU Pascal compiler implements whole-program 
checks; perhaps in the same way as GNAT.

>> the withed declarations are (re-)compiled on the fly when the withing
>> unit is compiled. The penalty for such recompilation is smaller today,
>> with faster machines and compilers.
>
> It's just the .ads that's included, right?

Usually, but of course it has to be done recursively when the "withed" 
declaration has its own "with" clauses. In the case of generic 
instantiation and in-lining, the "withed" body (.adb) may be needed too.

> Was the speed that bad an issue even on the old machines?

I don't know if the first Ada implementors ever did any comparative 
measurements before choosing the traditional Ada library approach. The 
essay you referenced, by David Wheeler, explains how the GNAT team 
hand-optimised the GNAT front-end to support the current source-based 
approach; perhaps the same could have been done back then.

> Is Ada really harder to compile than Pascal?

Well, which Pascal do you mean?

There is no question that Ada 83 was much larger in scope and harder to 
compile (into efficient code) than the original Pascal. I think that is 
still true for Ada 2012 and current Pascal, but I don't know enough 
about the latter to understand the magnitude of the difference.

> I've always liked this article even though I never used Turbo
> Pascal:  http://prog21.dadgum.com/116.html

That makes a point about the smallness of the Turbo Pascal compiler. 
AIUI the compiler was written in assembly language by a very skilled 
programmer, and was aimed at fast compilation rather than fast code (any 
machine code was blazing fast compared to Basic...).

Perhaps Randy could quote some comparative size numbers for the early 
versions of Janus/Ada? Though I understand that Janus/Ada required HW 
memory extenders for the early PCs, just as the early Alsys compilers 
did (according to the Wheeler essay; again I have no personal experience).

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

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:fllcvaF4mg7U1@mid.individual.net...
...
> That makes a point about the smallness of the Turbo Pascal compiler. AIUI 
> the compiler was written in assembly language by a very skilled 
> programmer, and was aimed at fast compilation rather than fast code (any 
> machine code was blazing fast compared to Basic...).

Correct: Turbo Pascal was fast because they found a way to fit it all in 
memory at once (tough on machines that only had 256K or so of memory) and 
because they didn't try to produce good code. Probably 95% of the 
compilation time for Turbo Pascal was disk I/O (something they always left 
out of their compilation speeds -- no compiler could have compiled more than 
a thousand lines or so a second on early MS-DOS because one couldn't read 
the source code any faster than that).

> Perhaps Randy could quote some comparative size numbers for the early 
> versions of Janus/Ada? Though I understand that Janus/Ada required HW 
> memory extenders for the early PCs, just as the early Alsys compilers did 
> (according to the Wheeler essay; again I have no personal experience).

Janus/Ada for PCs ran on bare MS-DOS (originally in 256K of memory, later in 
512K). It could use extended/expanded memory if it was available to expand 
the symboltable; and later versions used a code-swapping mechanism to keep 
the entire thing in memory.

But virtually the entire time (including today), Janus/Ada was primarily 
disk-bound -- the rather extensive I/O took the vast majority of the 
compilation time. The only exception is the optimizer (which can be turned 
off).

I recall that the early PC versions took 2-4 minutes to compile a 
decent-sized Ada package with basic optimization. This was very competitive 
with other compilers for other languages on early PCs and CP/M (we tried a 
number of them in the early days). That is, it wasn't that compiling Ada was 
slow. It was that compiling anything on machines of that era was slow.

                                                    Randy.

Re: How to get Ada to ?cross the chasm??

[Lucretia]

On Friday, 11 May 2018 10:09:34 UTC+1, Paul Rubin  wrote:

> But, you unquestionably understand the issue better than I do.
> 
> What I don't understand is, why didn't the same issue apply to Pascal?

Pascal never had packages, only later dialects did. Pascal was developed as a teaching language, Wirth said that it was down to implementers to extend the language. It was underdefined and should never have been extended the way it was, IMO, it should've been kept as a simple teaching language.

> > the withed declarations are (re-)compiled on the fly when the withing
> > unit is compiled. The penalty for such recompilation is smaller today,
> > with faster machines and compilers.
> 
> It's just the .ads that's included, right?  Was the speed that bad an
> issue even on the old machines?  Is Ada really harder to compile than
> Pascal?  I've always liked this article even though I never used Turbo

Yes it is. See the grammar, it's very ambiguous. Pascal's grammar can be taken from the page and written directly as functions to make a a recursive descent parser.

When creating a parser for Ada, you need to first work out where to put pragma, because for some stupid reason, they didn't bother to include it in the correct places in the grammar, seriously, search for "pragma" http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-P.html

You then need go through and sort out the grammar so it will work for you, whether hand coding or tool. You then have *syntactic* names all over the place which is part of overload resolution.

It's tricky.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Lucretia <laguest9000@googlemail.com> writes:
>> What I don't understand is, why didn't the same issue apply to Pascal?
> Pascal never had packages, only later dialects did.

Well ok, but were modules (a la Turbo Pascal) not enough to trigger this
problem?

>> Is Ada really harder to compile than Pascal?
> Yes it is. See the grammar, it's very ambiguous....  You then have
> *syntactic* names all over the place which is part of overload
> resolution. .. It's tricky.

Thanks, this is an informative explanation.

Re: How to get Ada to ?cross the chasm??

[Dennis Lee Bieber]

On Fri, 11 May 2018 02:09:33 -0700, Paul Rubin <no.email@nospam.invalid>
declaimed the following:


>What I don't understand is, why didn't the same issue apply to Pascal?

	Jensen&Wirth Pascal did not have "include/import" or any other
capability for separate files... Every program was contained within a
single source file; every compilation compiled the entire program.

	I don't recall if UCSD Pascal allowed for separate compilation (some
Googling indicates it did). Alcor Pascal (another p-code type
implementation; sold as TRS-80 Pascal by RatShack) used text files (hex
representation) for object files, and one /could/ use a text editor to
extract functions and build up a new code module from parts. 

	Heck -- Google results show that the concept of separate compilation
for Pascal was worthy of research papers at both ACM and IEEE around 1980.


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

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:fll3dmF2i4fU1@mid.individual.net...
...
> > and everyone uses that scheme today.
>
> Some do, some don't.

Right. Janus/Ada uses a variation of the library scheme (it long predates 
the GNAT "source-based" design), and the Rational compiler (available these 
days from PTC) also uses a strong library design.

The Intermetrics compiler and its derivitives also use a GNAT-like 
"source-based" design.

But that's virtually irrelevant for a primarily Ada program. Every Ada 
compiler comes with a make-like tool that builds programs, typically just 
given the name of the main subprogram and some options. No need in Ada for 
complex make-files; all of that is required and managed by the language.

The original vision for the Janus/Ada eco-system included compilers for 
other languages (C and assembler at a minimum) that could implement Ada 
package bodies. That allowed complete interoperation between Ada and C and 
assembler code, without losing the advantages of Ada's unit management.

As a practical matter, though, that mechanism didn't allow direct use of 
existing C code, and thus the C part was never built.

The alternative of bringing the disadvantages of the unstructured C method 
to Ada never crossed my mind -- that would have been going backwards in 
terms of ease of program construction.

                                                             Randy.

Re: How to get Ada to ?cross the chasm??

[Simon Wright]

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

> All of the Ada containers have "cursors", which serve the reference
> function.

Tree cursors are defined to continue to designate an element even if it
gets moved in the tree (bcause of insertion/deletion of other
elements). Is this true of all cursors? (I may have got muddled by the
"tampering" issue).

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lybmdv28p5.fsf@pushface.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> All of the Ada containers have "cursors", which serve the reference
>> function.
>
> Tree cursors are defined to continue to designate an element even if it
> gets moved in the tree (bcause of insertion/deletion of other
> elements). Is this true of all cursors? (I may have got muddled by the
> "tampering" issue).

Yes. There's an issue with vector cursors, they can become invalid because 
of "sliding" -- but vector cursors are rarely used (since the entire point 
of the container is to allow indexing, it's usually accessed that way).

Tampering (in part) is a way to ensure that remains true; you aren't allowed 
to insert into a container while it is being iterated, for instance.

                       Randy.

Re: How to get Ada to ?cross the chasm??

[Simon Wright]

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

> Yes. There's an issue with vector cursors, they can become invalid
> because of "sliding" -- but vector cursors are rarely used (since the
> entire point of the container is to allow indexing, it's usually
> accessed that way).

Thanks.

I suppose one could include a 'generation' value in the vector,
incremented every time an element is removed or added, copied to a
cursor on creation of the cursor, and checked when the cursor is used. A
lot of work, for a slight amount of gain.

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lyfu36zh6w.fsf@pushface.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> Yes. There's an issue with vector cursors, they can become invalid
>> because of "sliding" -- but vector cursors are rarely used (since the
>> entire point of the container is to allow indexing, it's usually
>> accessed that way).
>
> Thanks.
>
> I suppose one could include a 'generation' value in the vector,
> incremented every time an element is removed or added, copied to a
> cursor on creation of the cursor, and checked when the cursor is used. A
> lot of work, for a slight amount of gain.

Janus/Ada does (will do) something like that to detect almost all 
dangling/mispointed cursors, but it doesn't have to be quite that intensive.

                       Randy.

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-04 01:27 , Randy Brukardt wrote:

   [snip]

> There is no realistic chance that Ada will
> ever be changed enough to make it amenable to GC.

Ouch and wow, when did that direction change?

As I remember it, for a long time the mantra was that Ada (83, 95, ...) 
was compatible with GC, but vendors did not implement GC because there 
was no immediate demand from the current users (chicken and egg situation).

I also remember that some people successfully used the "conservative" GC 
tools, such as the Boehm GC, with ordinary Ada programs and Ada 
compilers (one problem being that for arrays, some compilers used 
"offset pointers" pointing to the location of the hypothetical element 
at index zero, even if the actual first index was not zero). Were these 
people misguided? Perhaps this way before controlled types and Finalize 
operations were introduced? Seems to me that a vanilla Boehm GC would 
not be able to call the right Finalize before discarding an object.

The Ada implementations targeting the JVM or .NET were/are claimed to 
use the GC provided by the target. Were/are these somehow "non-Ada" 
implementations?

> I proposed such changes
> multiple times in the past and got nowhere with them. (The problem being
> that the location of finalization of most objects is too late for any useful
> GC to be possible -- it's generally associated with the access type, which
> is usually declared at the library level. Thus GC can't clean up most
> objects until the type goes away -- which is usually when the program
> exits.)

So the issue is possible side-effects of user-defined Finalize 
operations, and when those side-effects are allowed to happen? If so, 
I'm surprised that defining the timing of such side effects was 
considered more important than being compatible with an implementation 
using GC. Too bad.

Usually GC systems are criticized for finalizing some objects too late. 
Funny that an Ada GC would be damned for doing it too early...

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

Re: How to get Ada to ?cross the chasm??

[Egil H H]

On Tuesday, May 8, 2018 at 10:41:33 PM UTC+2, Niklas Holsti wrote:
> On 18-05-04 01:27 , Randy Brukardt wrote:
> 
>    [snip]
> 
> > There is no realistic chance that Ada will
> > ever be changed enough to make it amenable to GC.
> 
> Ouch and wow, when did that direction change?
> 
> As I remember it, for a long time the mantra was that Ada (83, 95, ...) 
> was compatible with GC, but vendors did not implement GC because there 
> was no immediate demand from the current users (chicken and egg situation).
> 

Indeed, 
RM 4.8(15/3):
"27  {AI05-0229-1} Implementations are permitted, but not required, to provide garbage collection."



http://www.ada-auth.org/standards/aarm12_w_tc1/html/AA-4-8.html
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0229-1.txt?rev=1.28


-- 
~egilhh

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Egil H H" <ehh.public@gmail.com> wrote in message 
news:78ca61a2-5d11-46f4-9ce7-7fce500ca1dd@googlegroups.com...
> On Tuesday, May 8, 2018 at 10:41:33 PM UTC+2, Niklas Holsti wrote:
>> On 18-05-04 01:27 , Randy Brukardt wrote:
>>
>>    [snip]
>>
>> > There is no realistic chance that Ada will
>> > ever be changed enough to make it amenable to GC.
>>
>> Ouch and wow, when did that direction change?
>>
>> As I remember it, for a long time the mantra was that Ada (83, 95, ...)
>> was compatible with GC, but vendors did not implement GC because there
>> was no immediate demand from the current users (chicken and egg 
>> situation).
>>
>
> Indeed,
> RM 4.8(15/3):
> "27  {AI05-0229-1} Implementations are permitted, but not required, to 
> provide garbage collection."

Yes, it's permitted -- but nothing says that it can be useful. :-)

It could be useful on types that have no subcomponents that need 
finalization -- but that rules out most of the Ada library and a good 
percentage of the open source libraries out there as well.

                              Randy.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
>> "27  {AI05-0229-1} Implementations are permitted, but not required, to 
>> provide garbage collection."
> Yes, it's permitted -- but nothing says that it can be useful. :-)

Certainly it's hugely limited if the system is prevented from moving
objects around in memory during GC.  I don't see anything in the Ada
Distilled description of access types that would prevent that, so I'll
have to read your other post more carefully.

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:flegbrFj0qjU1@mid.individual.net...
> On 18-05-04 01:27 , Randy Brukardt wrote:
>
>   [snip]
>
>> There is no realistic chance that Ada will
>> ever be changed enough to make it amenable to GC.
>
> Ouch and wow, when did that direction change?
>
> As I remember it, for a long time the mantra was that Ada (83, 95, ...) 
> was compatible with GC, but vendors did not implement GC because there was 
> no immediate demand from the current users (chicken and egg situation).

That was the same mantra used to justify not loosening the finalization 
rules to allow early finalization. However, such a loosening had to be 
fairly restricted (one can't allow it to happen anywhere, or every Finalize 
routine would have to be protected against tasking issues -- even if no 
tasking is used for the objects in question). I believe I suggested allowing 
it anywhere that a master is finalized, assuming the object in question is 
inaccessible.

Probably the complication is why there was no appetite; the argument was 
that we needed someone implementing GC before we bother to fix the rules for 
GC. But since the rules essential prohibit useful GC, no one is going to 
implement it until they know those are going to be fixed. Ergo, no progress.

>The Ada implementations targeting the JVM or .NET were/are claimed to use 
>the GC provided by the target. Were/are these somehow "non-Ada" 
>implementations?

I'm sure they were fine. If one uses the canonical linked-list 
implementation of finalization, objects with controlled parts remain 
reachable until the appropriate master goes away -- so nothing gets 
collected. (And a similar effect is necessary regardless of how finalization 
is implemented.) There still can be an underlying GC and it can be used just 
fine -- no one said anything about it actually be able to collect much.

                    Randy.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> implementation of finalization, objects with controlled parts remain 
> reachable until the appropriate master goes away

Meh, finalization is ugly in connection with GC and it's reasonable to
expect GC to have no observable effects, so it can't be expected to do
things like close files.  An Ada GC would be very useful even if it were
restricted to datatypes that didn't have those sorts of finalizers.

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-10 01:05 , Randy Brukardt wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
> news:flegbrFj0qjU1@mid.individual.net...
>> On 18-05-04 01:27 , Randy Brukardt wrote:
>>
>>   [snip]
>>
>>> There is no realistic chance that Ada will
>>> ever be changed enough to make it amenable to GC.

    [snip]

> If one uses the canonical linked-list
> implementation of finalization, objects with controlled parts remain
> reachable until the appropriate master goes away -- so nothing gets
> collected. (And a similar effect is necessary regardless of how finalization
> is implemented.) There still can be an underlying GC and it can be used just
> fine -- no one said anything about it actually be able to collect much.

Can one summarize the effect of the current Ada rules as follows:

- for dynamically allocated objects that do not need finalization, a GC 
implementation could release them when they become unreachable, just as 
in other languages,

- for objects that do need finalization, a GC implementation would have 
to delay releasing the objects until their types go out of scope, which 
in most cases would not happen before the program is about to terminate?

If so, the conclusion is that GC is becoming ineffective for Ada, 
because Ada programming style is changing to make more use of controlled 
types and finalization.

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

Re: How to get Ada to ?cross the chasm??

[gautier_niouzes]

> But then you have to free the memory, or else your program has a leak.
> There are various ways you can deal with this storage management issue.

Thank you for looking at the CBSG. There are indeed tons of temporary data produced in almost no time, so it is certainly an interesting example.

Now, the surprise (for you):
- there is no memory to be freed
- there is no leak
- there is no storage management issue.
Just try this:

with Produce_Corporate_Bullshit;
procedure Noleak is
begin
  loop
    Produce_Corporate_Bullshit;
  end loop;
end;

At each iteration (1/2 second on my 1.66 GHz netbook) around 100 A4 pages of bla bla are produced, final HTML size around 400KB.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

gautier_niouzes@hotmail.com writes:
> Now, the surprise (for you):
> - there is no memory to be freed
> - there is no leak
> - there is no storage management issue.

There is storage management issue because there's all that string
pasting and there's no issue of adding and deleting data like would
happen in a real bogo-corporation as I described.

I wasn't able to compile the program because the Delerium file was
missing (I did find the .ads file which was also needed).  Is there
another url for it?

> At each iteration (1/2 second on my 1.66 GHz netbook) around 100 A4
> pages of bla bla are produced, final HTML size around 400KB.

Even on a netbook 800KB/s sounds awfully slow for a program like that.
So I have to wonder what it's up to.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Paul Rubin <no.email@nospam.invalid> writes:
> I wasn't able to compile the program because the Delerium file was
> missing ....  Is there another url for it?

Ignore this, I found the zip file that has everything.  Thanks!

Re: How to get Ada to ?cross the chasm??

[gautier_niouzes]

Le vendredi 4 mai 2018 06:28:06 UTC+2, Paul Rubin a écrit :
> 
> Ignore this, I found the zip file that has everything.  Thanks!

So now you were able to run the program ?...

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

gautier_niouzes@hotmail.com writes:
> Le vendredi 4 mai 2018 06:28:06 UTC+2, Paul Rubin a écrit :
>> Ignore this, I found the zip file that has everything.  Thanks!
> So now you were able to run the program ?...

Yes, I hit a few snags but was able to build and run it.  I would
suggest recreating the zip file with a Linux zip program, since it
appears to have been built with a Windows program that the Linux one
doesn't know how to decode (I was able to get around that).

It's an interesting program, going against what I've always been taught
as principles of flexible software because of all the compiled-in data.
But the result is like a 50 foot cube of solid granite, completely
impervious to anything, and in Ada that might be a virtue.

Re: How to get Ada to ?cross the chasm??

[gautier_niouzes]

Le mardi 8 mai 2018 04:19:42 UTC+2, Paul Rubin a écrit :

> Yes, I hit a few snags but was able to build and run it.  I would
> suggest recreating the zip file with a Linux zip program, since it
> appears to have been built with a Windows program that the Linux one
> doesn't know how to decode (I was able to get around that).

The Zip format is system-agnostic (shameless plug : https://unzip-ada.sourceforge.io/ )

> It's an interesting program, going against what I've always been taught
> as principles of flexible software because of all the compiled-in data.
> But the result is like a 50 foot cube of solid granite, completely
> impervious to anything, and in Ada that might be a virtue.

You are shifting again the subject: the point was to understand with a simple example how you can use Ada's unconstrained types without accumulating garbage...

Re: How to get Ada to ?cross the chasm??

[Dan'l Miller]

On Monday, May 7, 2018 at 9:47:12 PM UTC-5, gautier...@hotmail.com wrote:
> Le mardi 8 mai 2018 04:19:42 UTC+2, Paul Rubin a écrit :
> 
> > Yes, I hit a few snags but was able to build and run it.  I would
> > suggest recreating the zip file with a Linux zip program, since it
> > appears to have been built with a Windows program that the Linux one
> > doesn't know how to decode (I was able to get around that).
> 
> The Zip format is system-agnostic (shameless plug : https://unzip-ada.sourceforge.io/ )

PKZIP format or gzip format?

Re: How to get Ada to ?cross the chasm??

[gautier_niouzes]

> PKZIP format or gzip format?

Zip-Ada is around PKZIP (.zip).
NB: both formats (.zip and .gz) are system-agnostic.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

gautier_niouzes@hotmail.com writes:
> The Zip format is system-agnostic (shameless plug :
> https://unzip-ada.sourceforge.io/ )

Nice, I'll check that out.

> You are shifting again the subject: the point was to understand with a
> simple example how you can use Ada's unconstrained types without
> accumulating garbage...

There's no issue of accumulating garbage in that example because it's
all stack-allocated data.  Garbage becomes relevant when you allocate
objects that have pointers to other allocated objects, and the objects'
lifetimes aren't known in advance.  The CBSG avoids creating pointers by
copying strings around repeatedly when building large strings from
shorter ones.  Even still though, the allocation and access pattern is
simple enough that stack management suffices.

Fwiw, the CBSG's memory consumption is not guaranteed to be bounded
because there is no limit on the possible recursion depth, but that's
unlikely to be a problem in practice since the probability decreases
exponentially with the depth.  And one could always add an explicit
limit.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

gautier_niouzes@hotmail.com writes:
> https://unzip-ada.sourceforge.io/ )

I downloaded this and found:

1) the file fizzip.adb didn't compile because it used 'Image in an
improper way in a bunch of places.  I found on Stack Overflow that
there's a GNAT attribute 'Img that got it to work.

2) gprbuild made a zipada program but no unzipada.  Unzip is commented
out of the .prj file.

3) The bunzip program it builds is around 25% slower than the default
Linux one, which is reasonable if it's safer, i.e. specifically if it's
free of potentially unsafe memory accesses.  I heard somewhere that
optimized GNAT turns off subscript checking by default, which seems
un-Ada-like.  But, from C++ stdlib containers, I think subscript checks
are cheaper than most people might expect.

4) The lzma_enc program it builds runs noticeably faster than 
xz --format=lzma, but it also doesn't compress as well, so I suspect the
algorithms are similar but the parameters are different.   I don't
see a way to set the compression level in the Ada version.  I might
experiment with xz's settings to find one that matches lzma_enc.

I'm very glad that someone implemented those programs in Ada since there
have historically been various bugs in the C versions that allowed code
injection exploits etc.

Regarding crossing the chasm, it would sure be nice if Ada (at least
GNAT) were more interoperable with C and C++ on Linux, in the sense of
using the same makefiles and similar command line tools.  Ada seems to
want to be in its own world of Gprbuild and .prj files.

Re: How to get Ada to ?cross the chasm??

[Luke A. Guest]

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

> Regarding crossing the chasm, it would sure be nice if Ada (at least
> GNAT) were more interoperable with C and C++ on Linux, in the sense of
> using the same makefiles and similar command line tools.  Ada seems to
> want to be in its own world of Gprbuild and .prj files.
> 

You don’t have to use gprbuild, you can everything from a makefile if you
want to just using gnatmake and/or gcc.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Luke A. Guest <laguest@archeia.com> writes:
> You don’t have to use gprbuild, you can everything from a makefile if you
> want to just using gnatmake and/or gcc.

Thanks.  The zip-ada package came with some build scripts for Windows
plus a prj file, so on Linux I used gprbuild which mostly worked.  I
didn't realize gcc+makefiles was an alternative.  I'd have to write a
makefile for the purpose, but it may be worth the effort of improving
the Linux packaging for this program.

Re: How to get Ada to ?cross the chasm??

[gautier_niouzes]

Note that the project files for GNAT have the .gpr extension and those for ObjectAda have the .prj extension (the .prj are binary files).

Re: How to get Ada to ?cross the chasm??

[gautier_niouzes]

Le mardi 8 mai 2018 07:46:46 UTC+2, Paul Rubin a écrit :
> gautier_niouzes@hotmail.com writes:
> > https://unzip-ada.sourceforge.io/ )
> 
> I downloaded this and found:
> 
> 1) the file fizzip.adb didn't compile because it used 'Image in an
> improper way in a bunch of places.  I found on Stack Overflow that
> there's a GNAT attribute 'Img that got it to work.

It's corrected in rev. r622:
https://sourceforge.net/p/unzip-ada/code/622/

> 2) gprbuild made a zipada program but no unzipada.  Unzip is commented
> out of the .prj file.

Corrected as well in rev. 620:
https://sourceforge.net/p/unzip-ada/code/620/

> 3) The bunzip program it builds is around 25% slower than the default
> Linux one, which is reasonable if it's safer, i.e. specifically if it's
> free of potentially unsafe memory accesses.  I heard somewhere that
> optimized GNAT turns off subscript checking by default, which seems
> un-Ada-like.  But, from C++ stdlib containers, I think subscript checks
> are cheaper than most people might expect.
> 
> 4) The lzma_enc program it builds runs noticeably faster than 
> xz --format=lzma, but it also doesn't compress as well, so I suspect the
> algorithms are similar but the parameters are different.   I don't
> see a way to set the compression level in the Ada version.  I might
> experiment with xz's settings to find one that matches lzma_enc.

There is no match because I've programmed the MA part of LZMA from scratch.
My version is less sophisticated than the original.

> I'm very glad that someone implemented those programs in Ada since there
> have historically been various bugs in the C versions that allowed code
> injection exploits etc.

Actually there are probably still obvious bugs waiting around.
I found an out-of-range issue (perhaps harmless) in a ~30 years old code:
  https://sourceforge.net/p/infozip/bugs/49/
Probably professional hackers do find them all the time...

Some vulnerabilities in Zip-Ada (archive unpacking side) were detected through fuzzing:
  https://blog.adacore.com/running-american-fuzzy-lop-on-your-ada-code
They could be quickly fixed thanks to the exceptions, range checks, validity checks, ...

> Regarding crossing the chasm, it would sure be nice if Ada (at least
> GNAT) were more interoperable with C and C++ on Linux, in the sense of
> using the same makefiles and similar command line tools.  Ada seems to
> want to be in its own world of Gprbuild and .prj files.

IMHO using makefiles only would be a regression: you don't need to explain an Ada compiler about unit dependencies for instance. Anyway you can launch gprbuild in a makefile.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

gautier_niouzes@hotmail.com writes:
> It's corrected in rev. r622:
> https://sourceforge.net/p/unzip-ada/code/622/

This is weird, when I clicked the "download" button it gave me
zipada53.zip.  Is that an obsolete version?  I did an svn checkout and
got the current version (629) which built ok with gprbuild.  It's late
here so I'll test it some other time.

The revision 622 comment says "regressed 'Image to pre-Ada-2012 form,
for pleasing gcc version 5.4.0 20160609".  But I'm using the default
GNAT with Debian 9 and that seems to use gcc6.  Is that supposed to
support Ada 2012?  I thought last time I played with it, I was able to
use Ada 2012 features.

> There is no match because I've programmed the MA part of LZMA from
> scratch.  My version is less sophisticated than the original.

Oh hmm, it would be REALLY useful to have a safe replacement for the
historically buggy 7z and maybe by extension xz.  

> Actually there are probably still obvious bugs waiting around....

If they are subscript overruns that trigger constraint error exceptions
in the Ada code and crash the program, that's still much safer than the
C behaviour of allowing malicious code injection, so it's a huge
improvement.  Going past that calls for using SPARK to show the absence
of subscript and int overflow errors, which might or might not be on
your radar.  Even further (and probably a lot harder) would be SPARK
verification that compressing something and uncompressing it restores
the original input.

>   https://blog.adacore.com/running-american-fuzzy-lop-on-your-ada-code

Oh this is great, I had been wondering whether AFL could be used with
Ada.  It is important.  Thanks.

Re: How to get Ada to ?cross the chasm??

[gautier_niouzes]

Le mardi 8 mai 2018 11:03:38 UTC+2, Paul Rubin a écrit :

> This is weird, when I clicked the "download" button it gave me
> zipada53.zip.  Is that an obsolete version?
There is a release max once or twice a year, with testing etc. I don't do a release after each checkin. You find this pattern often in other software. BTW, SourceForge and GitHub offer to build a Zip file from the latest checkin.

> I did an svn checkout and
> got the current version (629) which built ok with gprbuild.  It's late
> here so I'll test it some other time.


> The revision 622 comment says "regressed 'Image to pre-Ada-2012 form,
> for pleasing gcc version 5.4.0 20160609".  But I'm using the default
> GNAT with Debian 9 and that seems to use gcc6.  Is that supposed to
> support Ada 2012?  I thought last time I played with it, I was able to
> use Ada 2012 features.

My mistake: I thought Value'Image was Ada 2012, but it seems to be a Ada 2020 feature put early into GNAT.

Re: How to get Ada to ?cross the chasm??

[Simon Wright]

gautier_niouzes@hotmail.com writes:

> My mistake: I thought Value'Image was Ada 2012, but it seems to be a
> Ada 2020 feature put early into GNAT.

It's in the current ALRM, see my post upthread.

Re: How to get Ada to ?cross the chasm??

[Jeffrey R. Carter]

On 05/08/2018 04:31 PM, Simon Wright wrote:
> gautier_niouzes@hotmail.com writes:
> 
>> My mistake: I thought Value'Image was Ada 2012, but it seems to be a
>> Ada 2020 feature put early into GNAT.
> 
> It's in the current ALRM, see my post upthread.

It's in Ada-12 with TC1. Recent versions of GNAT support it in most cases. I've 
encountered some cases where GNAT rejects it though it looks correct to me.

-- 
Jeff Carter
"Damn it, Jim, I'm an actor, not a doctor."
124

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

gautier_niouzes@hotmail.com writes:
> My mistake: I thought Value'Image was Ada 2012, but it seems to be a
> Ada 2020 feature put early into GNAT.

Well ok, but is there something I tell my version of GNAT (6.3.0) to
enable it?  Or do I need a newer version?  

Re: How to get Ada to ?cross the chasm??

[Simon Wright]

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

> gautier_niouzes@hotmail.com writes:
>> My mistake: I thought Value'Image was Ada 2012, but it seems to be a
>> Ada 2020 feature put early into GNAT.
>
> Well ok, but is there something I tell my version of GNAT (6.3.0) to
> enable it?  Or do I need a newer version?  

GNAT GPL >= 2016 is OK (for simple uses, anyway).

FSF GCC >= 7 is OK.

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

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

<gautier_niouzes@hotmail.com> wrote in message 
news:244b242a-09a8-48d2-918b-77e9b171098f@googlegroups.com...
Le mardi 8 mai 2018 11:03:38 UTC+2, Paul Rubin a écrit :
...
>> The revision 622 comment says "regressed 'Image to pre-Ada-2012 form,
>> for pleasing gcc version 5.4.0 20160609".  But I'm using the default
>> GNAT with Debian 9 and that seems to use gcc6.  Is that supposed to
>> support Ada 2012?  I thought last time I played with it, I was able to
>> use Ada 2012 features.
>
>My mistake: I thought Value'Image was Ada 2012, but it seems to be a
> Ada 2020 feature put early into GNAT.

Neither: it was added by the 2016 Corrigendum to Ada 2012. Formally, that's 
Ada 2012 (a corrigendum is a "correction" to the Standard, not a new 
version), but you need a very recent compiler for that to be the case in 
practice. I usually say something like "Ada 2012 as corrected by TC1".

                     Randy.

Re: How to get Ada to ?cross the chasm??

[J-P. Rosen]

Le 08/05/2018 à 22:12, Randy Brukardt a écrit :
>> My mistake: I thought Value'Image was Ada 2012, but it seems to be a
>> Ada 2020 feature put early into GNAT.

Anyway, it's just a minuscule improvement to writing, with no new
feature and no benefit in reading.

Use the good ol' T'image(v), and don't worry about versions

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

Re: How to get Ada to ?cross the chasm??

[Björn Lundin]

On 2018-05-08 22:24, J-P. Rosen wrote:
> Le 08/05/2018 à 22:12, Randy Brukardt a écrit :
>>> My mistake: I thought Value'Image was Ada 2012, but it seems to be a
>>> Ada 2020 feature put early into GNAT.
> 
> Anyway, it's just a minuscule improvement to writing, with no new
> feature and no benefit in reading.

I disagree. It is more than that
I affects 'with' statments sometimes.
And it makes the code look better/easier to read
Below an uncompiled exsample of
 * old ways nees more 'withs' - which may affect elaboration order
 * makes the code harder to read

  --------------------
  package Core_Types is
  type Handling_Unit_System_Status_Type is
         (Auto, Semi_Auto, Out_Of_System);

    type Assignment_Result_Type is (Success, Failure, Severe_Failure);
    type Assignment_Identity_Type is 1 .. 99_999;
  end Core_Types;
  --------------------

  --------------------
  with core_types;
  package Trp_Assignments is
    type Assignment_type is record
       Assignment_Identity : core_types.Assignment_Identity_Type ;
       Assignment_Result : core_types.Assignment_Result_Type;
       Handling_Unit_System_Status:
           core_types.Handling_Unit_System_Status_Type ;
    end record;

  -------------------------------------------
  with core_types; -- ONLY NEEDED FOR do_stuff_old_way
   package body Transport_Handler is

    procedure do_stuff_old_way(Asm : Trp_Assignments.Assignment_type) is
    begin
      -- NEED THE 'with core_types'


      log("id" & core_types.Assignment_Identity_Type'Image(
                       Asm.Assignment_Identity) & " " &
          "result " & core_types.Assignment_Result_Type'image(
                       Asm.Assignment_Result) & " " &
          "status " & core_types.Handling_Unit_System_Status_Type'Image(
                      Asm.Handling_Unit_System_Status));

    end do_stuff_old_Way;


    procedure do_stuff_new_way(Asm : Trp_Assignments.Assignment_type) is
    begin
      -- DOES NOT NEED THE 'with core_types'
      log("id" & Asm.Assignment_Identity'Image & " " &
          "result " & Asm.Assignment_Result'Imgaer & " " &
          "status " & Asm.Handling_Unit_System_Status'Image);
    end do_stuff_new_Way;

  end Trp_Assignments;



> Use the good ol' T'image(v), and don't worry about versions

Not when can be avoided - for me anyway


-- 
--
Björn

Re: How to get Ada to ?cross the chasm??

[J-P. Rosen]

Le 09/05/2018 à 11:27, Björn Lundin a écrit :
> On 2018-05-08 22:24, J-P. Rosen wrote:
>> Anyway, it's just a minuscule improvement to writing, with no new
>> feature and no benefit in reading.
> I disagree. It is more than that
> I affects 'with' statments sometimes.

That's a good point, however if you have a variable of a type declared
in another package, I think it is extremely unlikely that you don't need
to "with" the package for some other reason (like, in your example,
simply assigning a value to the variable).

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

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

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

"Björn Lundin" <b.f.lundin@gmail.com> wrote in message 
news:pcueuk$nso$1@dont-email.me...
...
>> Use the good ol' T'image(v), and don't worry about versions
>
> Not when can be avoided - for me anyway

It should be noted that one can use Obj'Image exclusively once it is 
available, because the prefix can always be qualified if necessary and that 
adds exactly one character to the attribute reference (and it's a lot 
shorter if qualification isn't needed).

My plan (once I'm using a Janus/Ada that supports it consistently, probably 
a few years still even though it is supported in the leading edge version 
now) is to completely forget the subtype version exists and use the object 
version consistently.

(Note that J-P was one of the few people that didn't support this extension, 
so it's fair for him to be consistent - but he was wrong then and he's wrong 
now. ;-)

                      Randy.


                       Randy.

Re: How to get Ada to ?cross the chasm??

[Simon Wright]

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

> 1) the file fizzip.adb didn't compile because it used 'Image in an
> improper way in a bunch of places.  I found on Stack Overflow that
> there's a GNAT attribute 'Img that got it to work.

It's proper in Ada2012, and recent GNATs. ARM K.2(88)ff

http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-K-2.html#p88

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-08 08:46 , Paul Rubin wrote:

> Regarding crossing the chasm, it would sure be nice if Ada (at least
> GNAT) were more interoperable with C and C++ on Linux, in the sense of
> using the same makefiles and similar command line tools.

No no no nooooo... the Ada way is so much nicer!

For many years, I just used gnatmake to compile all my Ada programs. And 
I was so happy that I did not have write any more sh*tty makefiles. But 
gprbuild is okay, too, and of course has more functionality (libraries, 
scenario variables).

> Ada seems to want to be in its own world of Gprbuild and .prj files.

We must hope that C/C++ will come to their senses and introduce a proper 
module system, allowing an Ada-like automatic inter-module dependency 
analysis for those languages too. Banish #include...

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

Re: How to get Ada to ?cross the chasm??

[Dmitry A. Kazakov]

On 08/05/2018 23:59, Niklas Holsti wrote:

> For many years, I just used gnatmake to compile all my Ada programs. And 
> I was so happy that I did not have write any more sh*tty makefiles. But 
> gprbuild is okay, too, and of course has more functionality (libraries, 
> scenario variables).

I still prefer gnatmake. It is a pity they seems killed it. It looks 
like newer gnatmake just calls gprbuild. Then the gates of hell open if 
gprconfig does not find GNAT. Could it just call gcc and shut up?

I just spent two days generating *.cgpr and passing it to gprbuild via 
--config to work around it.

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

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87po2cyty7.fsf@nightsong.com...
> gautier_niouzes@hotmail.com writes:
>> Now, the surprise (for you):
>> - there is no memory to be freed
>> - there is no leak
>> - there is no storage management issue.
>
> There is storage management issue because there's all that string
> pasting and there's no issue of adding and deleting data like would
> happen in a real bogo-corporation as I described.

Surely. But some "Paul Rubin" guy just said:

"Yes, that's exactly right: the burden is moved from the application
programmer to the language implementation."

...and that's exactly what's happening here. The same thing would happen in 
a GC implementation - they tend to be even worse because the programmers 
almost never consider how much garbage they are creating.

And I doubt that it would be hard to add or delete data; for a program like 
this doing it on the fly is overkill anyway. Reading it from a file would be 
easy to add if you wanted to.

                               Randy.

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87in88m43h.fsf@nightsong.com...
...
> A cleaner approach imho is immutable data passed by reference (this is
> how most of functional programming works).  It's not really feasible to
> code in that style in Ada, as far as I can tell.

Why do you say that? It's not done that often, but plenty feasible: an 
immutably limited type is always passed by reference, and constants don't 
change (with a few technical exceptions easily avoided if you wish), so one 
can easily use limited records in that way:

      type Data is limited record ...

      function Munge (Obj : in Data) return Data;

The problem comes (in any design) when you start using references rather 
than the actual objects; my point was that you need to minimize references 
(in all forms) to really reduce these issues. A reference necessarily leads 
to dangling references or methods to avoid such -- and that way leads to 
madness (or GC, roughly equivalent ;-).

Claw uses references in only a very few targetted situations; almost 
everything in the GUI is constructed by aggregation. Works great (even if a 
bit stale since it is for Win32).

                                    Randy.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> The problem comes (in any design) when you start using references
> rather than the actual objects;... and that way leads to madness (or
> GC, roughly equivalent ;-).

Yes, that's the point, you end up learning to love the GC, or at least
live with it.

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87muxiorcx.fsf@nightsong.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> The problem comes (in any design) when you start using references
>> rather than the actual objects;... and that way leads to madness (or
>> GC, roughly equivalent ;-).
>
> Yes, that's the point, you end up learning to love the GC, or at least
> live with it.

No, you learn to avoid references -- they're rarely needed. And everything 
is better off without them. People who can't design without them are the 
problem - not Ada's (or any other language, for that matter) memory 
management.

                  Randy.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> No, you learn to avoid references -- they're rarely needed.  And
> everything is better off without them.

The first sentence is true, the second is dubious.  Automobiles are
rarely needed either, you can usually get where you're going some other
way, but is everything better off without them?

> People who can't design without them are the problem - not Ada's (or
> any other language, for that matter) memory management.

I don't see where people who can't design without them even come into
the picture.  Someone who can program with gc but not without it is like
someone who can drive a car but can't ride a bike.  The bike can go
places that the car cannot, so the person's possible destinations are
limited (although in 2018 that's less important than you might think).

But if the person can use both bikes and cars, why would they want to go
everywhere by bike, if the car can get them to a given destination
faster?  If it's for recreation or exercise or something, then fine; but
if it's to just get to the destination efficiently, then it's silly.

Re: How to get Ada to ?cross the chasm??

[Jacob Sparre Andersen]

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

> Jacob Sparre Andersen <jacob@jacob-sparre.dk> writes:
>>> I couldn't imagine writing a substantial server app entirely in Ada.
>> Why not?  (That's what I spend most of my time doing.)  One of the two
>> projects I'm working on now is already ~1M lines of Ada in the server.
>
> Why write 1M lines of Ada when you can write 1/10th as much code in a
> HLL?

Because you then would have to maintain that HLL in a backward
compatible form for 30+ years.

And who says it can be written in 1/10th as much code in another
language?  (I guess it can, but only because we are pretty sure we can
do the same in Ada too.)

> Why worry about potential integer overflow every time you do
> arithmetic?

Better worry about it, than getting incorrect results.

> How much of your effort goes into manual memory
> management?

0!

> Why not use a language and runtime that handles all that for you
> automatically?

But we do.

> And if your app runs on one cpu, what does Ada's solidity get you
> under Joe Armstrong (designer of Erlang)'s dictum that a
> non-distributed system can never be reliable, since the power cord is
> a single point of failure?  Conversely, if your app is distributed,
> what does Ada get you that normal failover machinery doesn't?

Long-term survivability and maintainability.  Can you point me to any
application written in a HLL, which is still maintainable 30 years after
its first deployment, and after two changes in compiler/run-time
providers?

>> The other one...  The R and Python parts will be carefully shielded
>> from the users and the internet by the Ada part.
>
> That sounds like a much more practical approach.  

The R and Python parts are mostly there because we get some of the
development-time for free that way.  The Ada part is there to ensure
separation, and to check that the results from the R and Python
calculations make sense (if they make sense, we don't care if the code
did what the programmer intended).

Greetings,

Jacob
-- 
"The generation of random numbers is too important to be left to chance"

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Jacob Sparre Andersen <jacob@jacob-sparre.dk> writes:
> Because you then would have to maintain that HLL in a backward
> compatible form for 30+ years.

Do you expect people will be using that code in 30 years?  I think as
code has gotten easier to develop (because of HLLs), its lifetime has
gotten shorter rather than longer.  It's just like anything else.  When
clothing was made by labor-intensive manual processes, it was normal to
keep maintaining it.  So if you found a hole in one of your socks, you'd
patch the sock instead of replacing it.  Do you still do that?  I don't.

>> Why worry about potential integer overflow
> Better worry about it, than getting incorrect results.

Why not use arbitrary precision integers and get correct results without
worrying?

> Long-term survivability and maintainability.  Can you point me to any
> application written in a HLL, which is still maintainable 30 years after
> its first deployment, and after two changes in compiler/run-time
> providers?

I think systems weren't written in HLL's as much 30 years ago (1988!) as
today, and HLL's (unlike C) don't frequently have multiple
implementations (similar to Ada 2012 today).  HLL's themselves weren't
as popular or accessible then easier.  Languages themselves have
advanced a huge amount since that era, which was not much past halfway
between us and the dawn of computers.  Even Java wasn't invented til the
1990s, and Perl was from 1987.  People back then wrote stuff in C that
they'd undoubtedly use a HLL for today.  C hasn't gotten harder, but
HLL's are so much easier that using C would be silly.

But let's see, Macsyma (written in Lisp) started in 1968, is still
maintained and sold, and has run in many Lisp environments.  There's
other old Lisp code running too.  That's probably also lots of SQL code
from the 1970s and 1980s that's been migrated across multiple databases
and still maintained.  It wouldn't surprise me if some APL financial
programs from back then aren't also still being used.

Erlang was written 32 years ago and has been reimplemented once or twice
since then, though within the same company.  I don't know if very early
Erlang programs are still being used though.  It's absolutely the case
that Erlang programs are written to be maintained for 30 years.  In fact
they're supposed to run nonstop in phone switches for that long: you can
maintain an Erlang program and update its code without stopping it.  I
don't know if that's ever done with Ada.

> The Ada part is there to ensure separation, and to check that the
> results from the R and Python calculations make sense

Sure, that's fine, but it sounds like a fairly thin wrapper.

Re: How to get Ada to ?cross the chasm??

[Jacob Sparre Andersen]

Paul Rubin wrote:
> Jacob Sparre Andersen <jacob@jacob-sparre.dk> writes:

>> Because you then would have to maintain that HLL in a backward
>> compatible form for 30+ years.
>
> Do you expect people will be using that code in 30 years?

Not for sure.  But it has already been in operation for 30 years.

> Why not use arbitrary precision integers and get correct results
> without worrying?

Among other reasons because a fixed-length bar-code can't handle it.
Because a 28 m tall warehouse doesn't get 10 m taller just because you
accidentally add 11 to 27 somewhere in your application.  Etc.

> Languages themselves have advanced a huge amount since that era,

Have they?

Well.  We got OOP in an ISO standard for the first time in January 1995,
but what other major advances in the state of the art have we seen in
since 1988?

> Even Java wasn't invented til the 1990s, and Perl was from 1987.

What new did Java bring to the world of programming languages?

> People back then wrote stuff in C that they'd undoubtedly use a HLL
> for today.  C hasn't gotten harder, but HLL's are so much easier that
> using C would be silly.

What is your definition of a HLL?  Except that it apparently isn't C or
Ada?  Is it any language you can't write an operating system in?  Or?

>> The Ada part is there to ensure separation, and to check that the
>> results from the R and Python calculations make sense
>
> Sure, that's fine, but it sounds like a fairly thin wrapper.

Then I gave the wrong impression.  Checking that the results make sense
is a different operation than calculating the results, but that doesn't
make it trivial.

Greetings,

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

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Jacob Sparre Andersen <jacob@jacob-sparre.dk> writes:
>> Why not use arbitrary precision integers
> Among other reasons because a fixed-length bar-code can't handle it.

Worry about that when it's time to print the bar code, not when doing
the calculations.

> Well.  We got OOP in an ISO standard for the first time in January 1995,
> but what other major advances in the state of the art have we seen in
> since 1988?

Type inference, and languages built around the idea that types can
specify complex properties of the program, so that program behaviour can
be verified with typecheckers that are much simpler to use than SPARK.
Functional programming as something past being a research subject.

This book is good: http://www.cs.cmu.edu/~rwh/pfpl.html

So is this: https://softwarefoundations.cis.upenn.edu/

(Hmm, ok, it does look like ML goes back to the 1970s.  I thought it was
much newer.  The Definition of Standard ML was published in 1990.
Haskell is from the 1990s.)

>> Even Java wasn't invented til the 1990s, and Perl was from 1987.
> What new did Java bring to the world of programming languages?

Nothing new, but it's a widely used HLL in long-lived applications, that
has multiple implementations.  So it seemed like a good place to look
for 30yo HLL programs.  But on checking, I saw that it didn't exist 30
years ago.

> What is your definition of a HLL?  Except that it apparently isn't C
> or Ada?  Is it any language you can't write an operating system in?

It may be idiosyncratic but I'm going with something like this: HLL's
can handle large and potentially complicated data objects as easily as
low-level languages handle machine integers.  That means you can write
them as literals (e.g. Lisp S-expressions), create them as intermediate
values and pass them as arguments, include them in other data, etc. and
not have to manually manage their storage.  That in practice means that
the language is garbage collected.

>> Sure, that's fine, but it sounds like a fairly thin wrapper.
> Then I gave the wrong impression.  Checking that the results make sense
> is a different operation than calculating the results, but that doesn't
> make it trivial.

Hmm ok, but what advantage does Ada bring in checking the results?
Do you have some SPARK verification of the checker?

Re: How to get Ada to ?cross the chasm??

[Jacob Sparre Andersen]

Paul Rubin wrote:

>> What is your definition of a HLL?  Except that it apparently isn't C
>> or Ada?  Is it any language you can't write an operating system in?
>
> It may be idiosyncratic but I'm going with something like this: HLL's
> can handle large and potentially complicated data objects as easily as
> low-level languages handle machine integers.  That means you can write
> them as literals (e.g. Lisp S-expressions), create them as
> intermediate values and pass them as arguments, include them in other
> data, etc. and not have to manually manage their storage.

That sounds like Ada to me.

>>> Sure, that's fine, but it sounds like a fairly thin wrapper.
>> Then I gave the wrong impression.  Checking that the results make sense
>> is a different operation than calculating the results, but that doesn't
>> make it trivial.
>
> Hmm ok, but what advantage does Ada bring in checking the results?

That it is easier to write correct programs in Ada than in R and Python.

> Do you have some SPARK verification of the checker?

No.

Greetings,

Jacob
-- 
"Banning open source would have immediate, broad, and strongly negative
 impacts on the ability of many sensitive and security-focused DOD
 groups to protect themselves against cyberattacks" -- Mitre Corp.

Re: How to get Ada to ?cross the chasm??

[Mehdi Saada]

> Type inference, and languages built around the idea that types can
specify complex properties of the program.
Hmm, can't you do most of that with contracts like aspects Dynamic_Predicate and Type_Invariant ? What else would you like to have ?

Re: How to get Ada to ?cross the chasm??

[gautier_niouzes]

Le dimanche 29 avril 2018 20:52:41 UTC+2, Paul Rubin a écrit :

> It may be idiosyncratic but I'm going with something like this: HLL's
> can handle large and potentially complicated data objects as easily as
> low-level languages handle machine integers.  That means you can write
> them as literals (e.g. Lisp S-expressions), create them as intermediate
> values and pass them as arguments, include them in other data, etc. and
> not have to manually manage their storage. 

You definitely missed most of Ada language, because it's standard Ada features.
You can have expressions of types of any complexity returned from a function, as parameters, as operator parameters etc.
Catch up!

> That in practice means that the language is garbage collected.
That's only relevant for languages that do most of their memory management through heap. Much garbage is randomly created and need to be collected in an asynchronous way.
Ada has more powerful ways to manage memory, and it's automatic as well.
Mostly it's through stack; the eventual heap garbage is collected in a deterministic and recursive way, invisible to the programmer, through finalization. This avoids the memory leaks/jams you meet sometimes with all-heap-allocation-and-garbage-collection.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

gautier_niouzes@hotmail.com writes:
> You definitely missed most of Ada language, because it's standard Ada
> features.  You can have expressions of types of any complexity
> returned from a function, as parameters, as operator parameters etc.
> Catch up!

Ok, here is I write a nested array in Python:

   x = [[1, 2], [3, 4], [5,6]]

In Haskell I can add a type signature (but I don't have to, since the
compiler can figure it out automatically):

   x :: [[Integer]]
   x = [[1, 2], [3, 4], [5,6]]

Here's a dictionary in Python:

   { 'alice': 5, 'bob': 10, 'charlie': 15 }

If there's an equivalent in Ada, that's good to know.

> Ada has more powerful ways to manage memory, and it's automatic as well.
> Mostly it's through stack;

I wouldn't call that more powerful, but it's useful, and compilers for
gc'd languages sometimes can recognize situations where they can
stack-allocate stuff.  I do use unique_ptr in C++ so I'm familiar with
the style.  

Re: How to get Ada to ?cross the chasm??

[gautier_niouzes]

> If there's an equivalent in Ada, that's good to know.

procedure Test is
  type T is array(Integer range <>, Integer range <>) of Integer;
  x: T := ((1, 2), (3, 4), (5, 6));
begin
  null;
end Test;

But I guess you want to add "dynamic typing" to your latest definition of a HLL :-).

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

gautier_niouzes@hotmail.com writes:
>   x: T := ((1, 2), (3, 4), (5, 6));

Thanks.  Can you concatenate two arrays like that?

> But I guess you want to add "dynamic typing" to your latest definition
> of a HLL :-).

Nope, I'm into Haskell etc. these days ;-).

Re: How to get Ada to ?cross the chasm??

[Jere]

On Sunday, April 29, 2018 at 7:22:34 PM UTC-4, Paul Rubin wrote:
> gautier writes:
> >   x: T := ((1, 2), (3, 4), (5, 6));
> 
> Thanks.  Can you concatenate two arrays like that?
> 

You can:

   type Array_Element is array (Integer range <>) of Integer;
   type Array_Type is array (Integer range <>) of Array_Element(1..2);

   x : Array_Type := ((0,1), (2,3), (4,5));
   y : Array_Type := ((6,7), (8,9));
   z : Array_Type := x & y;
   a : Array_Type := z & Array_Type'(1 => (10,11));

full test program:

with Ada.Text_IO; use Ada.Text_IO;

procedure jdoodle is
    procedure Test is
        type Array_Element is array (Integer range <>) of Integer;
        type Array_Type is array (Integer range <>) of Array_Element(1..2);
        
        function To_String(Values : Array_Element; Count : Natural := 0) return String is
            Index : Integer := Values'First + Count;
        begin
            if Count = 0 then
                return "(" & Integer'Image(Values(Index)) & To_String(Values,1);
            elsif Count >= Values'Length then
                return ")";
            else
                return "," & Integer'Image(Values(Index)) & To_String(Values, Count + 1);
            end if;
        end To_String;
     
        x : Array_Type := ((0,1), (2,3), (4,5));
        y : Array_Type := ((6,7), (8,9));
        z : Array_Type := x & y;
        a : Array_Type := z & Array_Type'(1 => (10,11));
        
    begin
        for e of a loop
            Put_Line(To_String(e));
        end loop;
    end Test;

begin
    Test;
end jdoodle;

Re: How to get Ada to ?cross the chasm??

[Lucretia]

On Monday, 30 April 2018 00:22:34 UTC+1, Paul Rubin  wrote:

> > But I guess you want to add "dynamic typing" to your latest definition
> > of a HLL :-).
> 
> Nope, I'm into Haskell etc. these days ;-).

You don't even know what a high-level language is.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Lucretia <laguest9000@googlemail.com> writes:
> You don't even know what a high-level language is.

I don't think there's a real definition.  So neither one of us knows.
It's what we make of it.  I came across the notion that GC is the
defining feature in this article:

http://www.complang.tuwien.ac.at/anton/euroforth/ef14/papers/ertl.pdf

which says "garbage collection makes such things easy, and may be the
decisive feature for distinguishing high-level languages from
lower-level languages...".  So I went along with it.

Re: How to get Ada to ?cross the chasm??

[Luke A. Guest]

Paul Rubin <no.email@nospam.invalid> wrote:
> Lucretia <laguest9000@googlemail.com> writes:
>> You don't even know what a high-level language is.
> 
> I don't think there's a real definition.  So neither one of us knows.

I and anyone with a brain knows, you obviously don’t. Even C is a high
level language, it’s at the bottom of the pile though, followed by Pascal
and C++. Ada is as high level as you can get. GC doesn’t even come into it.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Luke A. Guest <laguest@archeia.com> writes:
> I and anyone with a brain knows, you obviously don’t. Even C is a high
> level language, it’s at the bottom of the pile though,

I don't think you get to decide unilaterally whether something is an
HLL, and expect others to bow before your wisdom.  As far as I can tell,
it's a somewhat subjective term.  I would not call C an HLL, but that's
just me.  I wouldn't call the others you mentioned HLL's either, but
that's more idiosyncratic.

Per https://en.wikipedia.org/wiki/High-level_programming_language :

    The terms high-level and low-level are inherently relative. Some decades
    ago, the C language, and similar languages, were most often considered
    "high-level", as it supported concepts such as expression evaluation,
    parameterised recursive functions, and data types and structures, while
    assembly language was considered "low-level". Today, many programmers
    might refer to C as low-level, as it lacks a large runtime-system (no
    garbage collection, etc.), basically supports only scalar operations,
    and provides direct memory addressing. It, therefore, readily blends
    with assembly language and the machine level of CPUs and
    microcontrollers.

> GC doesn’t even come into it.

Well, what *does* come into it, in your conception?

Re: How to get Ada to ?cross the chasm??

[Lucretia]

On Monday, 30 April 2018 04:37:38 UTC+1, Paul Rubin  wrote:
> Luke A. Guest <laguest@archeia.com> writes:
> > I and anyone with a brain knows, you obviously don’t. Even C is a high
> > level language, it’s at the bottom of the pile though,
> 
> I don't think you get to decide unilaterally whether something is an
> HLL, and expect others to bow before your wisdom.  As far as I can tell,

The fact that you think I decided what is and isn't a high level language proves just how uneducated you truly are.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Lucretia <laguest9000@googlemail.com> writes:
> The fact that you think I decided what is and isn't a high level
> language proves just how uneducated you truly are.

If you didn't decide, then who did?

Re: How to get Ada to ?cross the chasm??

[Lucretia]

On Monday, 30 April 2018 05:03:47 UTC+1, Paul Rubin  wrote:

> > The fact that you think I decided what is and isn't a high level
> > language proves just how uneducated you truly are.
> 
> If you didn't decide, then who did?

Any language higher than assembly language is a high level language, that's the definition, it's not hard.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

Lucretia <laguest9000@googlemail.com> writes:
> Any language higher than assembly language is a high level language,
> that's the definition, it's not hard.

Well, that's one way to look at it, that was probably more convincing in
the 1970s than now.

Here, the question got shut down basically because it doesn't have a
unique answer:

https://softwareengineering.stackexchange.com/questions/267583/why-is-c-still-in-the-category-of-high-level-language

Other web search results say similar things.  So I'm going to keep
considering it subjective instead of going by your say-so.  Anyway it's
a terminological quibble not worth getting hung up on.

You've probably seen this (from 1994), but if not, it might be more
relevant to the "crossing the chasm" question:

  http://haskell.cs.yale.edu/wp-content/uploads/2011/03/HaskellVsAda-NSWC.pdf

See particularly the tables on pages 9 and 12.

Re: How to get Ada to ?cross the chasm??

[Lucretia]

On Monday, 30 April 2018 06:11:55 UTC+1, Paul Rubin  wrote:

> > Any language higher than assembly language is a high level language,
> > that's the definition, it's not hard.
> 
> Well, that's one way to look at it, that was probably more convincing in
> the 1970s than now.

That is thought from much later than the 70's
 

Re: How to get Ada to ?cross the chasm??

[Lucretia]

On Monday, 30 April 2018 06:21:18 UTC+1, Lucretia  wrote:
> > Well, that's one way to look at it, that was probably more convincing in
> > the 1970s than now.
> 
> That is thought from much later than the 70's

If you're going to deny history, that's a very bad road to go down.

Re: How to get Ada to ?cross the chasm??

[Lucretia]

On Monday, 30 April 2018 04:37:38 UTC+1, Paul Rubin  wrote:

> I don't think you get to decide unilaterally whether something is an
> HLL, and expect others to bow before your wisdom.  As far as I can tell,

The fact that you seem to think I decide what a high level language is proves just how uneducated you truly are.

Re: How to get Ada to ?cross the chasm??

[Dan'l Miller]

On Sunday, April 29, 2018 at 4:20:46 PM UTC-5, Paul Rubin wrote:
> gautier_niouzes writes:
> > You definitely missed most of Ada language, because it's standard Ada
> > features.  You can have expressions of types of any complexity
> > returned from a function, as parameters, as operator parameters etc.
> > Catch up!
> 
> Ok, here is I write a nested array in Python:
> 
>    x = [[1, 2], [3, 4], [5,6]]
> 
> In Haskell I can add a type signature (but I don't have to, since the
> compiler can figure it out automatically):
> 
>    x :: [[Integer]]
>    x = [[1, 2], [3, 4], [5,6]]
> 
> Here's a dictionary in Python:
> 
>    { 'alice': 5, 'bob': 10, 'charlie': 15 }
> 
> If there's an equivalent in Ada, that's good to know.
> 
> > Ada has more powerful ways to manage memory, and it's automatic as well.
> > Mostly it's through stack;
> 
> I wouldn't call that more powerful, but it's useful, and compilers for
> gc'd languages sometimes can recognize situations where they can
> stack-allocate stuff.  I do use unique_ptr in C++ so I'm familiar with
> the style.

Paul, if clever typewriting conveniences would be what causes a niche programming language to “cross the chasm”, then Haskell would have crossed the chasm 20 years ago.   What causes a niche programming language to cross the chasm is when people popularly discover en masse that the language practically solves an enormous design problem that is either impractical or annoyingly obtuse to solve in •all• other already-crossed-the-chasm programming languages.  Merely mimicking the syntactic sugar that another already-crossed-the-chasm language already has is not what causes a programming language to cross the chasm (Java notwithstanding, because Java-the-dullard-borrower was pulled forcibly across the chasm due to its very useful frameworks).

For example, of all the already-crossed-the-chasm programming languages (not counting academic-research-only languages), only modern C++{11,14,17} has the ability to write compile-time expressions to manipulate run-time types at compile-time.  It took 3 editions of the standard to fine-tune the beast.  And an ugly-syntaxed beast is certainly is (by torturing parameterized types to be Turing complete)!   And needing language features that in some compilers cause 160-line (!) long error messages to be emitted for source code that at first, second, and third glances sure looks sane and intended.  But C++ can now write libraries (at all or efficiently) that would have been impractical in C++2003 and before.  Hence, C++{11,14,17} has reversed the waning & fading of C++2003, allowing C++{11,14,17} a rare re-crossing of the chasm after C++2003 was slipping back the wrong direction across the chasm.

Randy has a laudable goal of evolving Ada2020 to do something that no other already-crossed-the-chasm language has in its within-the-compiler repertoire:  provably-correct tasking.  It seems to be a race between Randy's vision and Rust's analogous vision, regarding which is first to cross the chasm, Ada2020 or Rust.

In this thread, Randy also touches on evolving Ada itself (not SPARK) to be an automated IV&V to use IEEE's and NASA's term.  (Randy, you should consider embracing IEEE's terminology of verification and validation, jettisoning “validated Ada compiler” for ‘verified* Ada compiler‘ so that then you can put IV&V meat on the conceptual skeleton; Ada needs to prove both of the Vs, not merely one.)  No already-crossed-the-chasm programming language has that degree of provable correctness either.

* To use IEEE's and NASA's terminology, an Ada compiler is •verified• to implement the ARM, but no one except the user community as a whole •validates• that the ARM's prose accomplishes usefulness to the software engineer.  Crossing or not crossing the chasm is a rather good proxy for an overt test of IEEE's & NASA's definition of the validation V.  If the ARG & Ada compiler vendors would have always put as much effort into IEEE's & NASA's validation V as the Ada community puts into the verification V, then Ada would have already crossed the chasm years ago.  Btw, I am not disparaging the ARG, the ARM, Ada2012, or Ada2020; I am merely pointing out that you are ever so close, but thus far lack rigor to move the ARM from tradecraft to mind-clarifying innovative breakthrough.

https://en.wikipedia.org/wiki/Verification_and_validation

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:45b9ca65-a983-4553-a580-d1ccde834c70@googlegroups.com...
>  (Randy, you should consider embracing IEEE's terminology of
> verification and validation, jettisoning "validated Ada compiler" for
> 'verified* Ada compiler' so that then you can put IV&V meat on the
> conceptual skeleton; Ada needs to prove both of the Vs, not merely one.)

The term "validated" hasn't been used formally since 1998, since it doesn't 
fit with ISO terminology. What we do for Ada using the ACATS is called 
"conformity assessment". (We informally equate that to "validated" so that 
older people aren't confused. ;-)

I don't think the term "verified" is allowed, either. You'd have look at ISO 
18009 to see the official terms (but I don't think that Standard is freely 
available).

                         Randy.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Dan'l Miller" <optikos@verizon.net> writes:
> For example, of all the already-crossed-the-chasm programming
> languages (not counting academic-research-only languages), only modern
> C++{11,14,17} has the ability to write compile-time expressions to
> manipulate run-time types at compile-time.

I don't understand what you mean by that: something like Haskell GADT's
(Ocaml has them too)?  It's certainly possible to have them without
making the type system Turing-complete.  C++ template metaprogramming is
Turing complete by complete accident, with the implementers surprised
when someone showed how to write a template that generated an error
message containing a list of prime numbers computed in the template
expansion ;-).

Here's an interesting challenge about statically validated API's using
types.  It's pretty straightforward in Haskell, and ugly solutions exist
in C++ and Java.  It's almost certainly impossible in C.  I've been
wondering whether Ada can do it and I've been wanting to read up on
Ada's type system to find out.  I wouldn't hold it against Ada if it
can't though, since Ada makes a reasonable choice in offloading complex
verification conditions to provers like SPARK:

http://blog.tmorris.net/posts/understanding-practical-api-design-static-typing-and-functional-programming/

> * To use IEEE's and NASA's terminology, an Ada compiler is •verified•

I wouldn't use that term any more.  In high-assurance programming
verified means mechanically checked with a proof system.

I'm looking forward to Ada2020 and it will be great if Randy implements
it.

Re: How to get Ada to ?cross the chasm??

[Dan'l Miller]

On Sunday, April 29, 2018 at 1:52:41 PM UTC-5, Paul Rubin wrote:
> This book is good: http://www.cs.cmu.edu/~rwh/pfpl.html
> 
> So is this: https://softwarefoundations.cis.upenn.edu/

The online version of this UPenn 3-volume set is a rather good read!  Thank you very much.  Of all that I have read (or tried to grok), this is by far the most lucid tutorial on Coq pursuant to applying Coq to provably-correct Ada.  As much as I disagree with so much of what you write (much more than what merely I reply) here on comp.lang.ada, your recommended readings are quite informative and deeply insightful.

Re: How to get Ada to ?cross the chasm??

[Paul Rubin]

"Dan'l Miller" <optikos@verizon.net> writes:
> The online version of this UPenn 3-volume set is a rather good read!

I'm glad you like it!

> As much as I disagree with so much of what you write (much more than
> what merely I reply) here on comp.lang.ada...

It's ok, now that you clicked that link, your indoctrination has
officially started and there is no turning back ;-).

Re: How to get Ada to ?cross the chasm??

[patrick]

Keep up the good work Jacob! and thanks for all your help over the years on this list

Re: How to get Ada to ?cross the chasm??

[jm.tarrasa]

> <<<
> I want to make money selling my software, but I certainly don't want to pay anything to any other software provider for this. They should all give me for free what I need.
> >>>
I don't want to pay that THAT MUCH for something, when I can get similar options for less or for free.

Many compilers have a free version and charge for extras (tools, libraries, bindings, analyzers, wizards, Database frameworks...) and with that free version you can compile whatever you want and sell your software. Gnat Pro charges for the basic compiler, and it is not cheap compared to others.

As toolchain, basic Ada compiler is far from other compilers.

Re: How to get Ada to ?cross the chasm??

[Lucretia]

On Friday, 13 July 2018 09:22:42 UTC+1, jm.ta...@gmail.com  wrote:

> I don't want to pay that THAT MUCH for something, when I can get similar options for less or for free.

Exactly.
 
> Many compilers have a free version and charge for extras (tools, libraries, bindings, analyzers, wizards, Database frameworks...) and with that free version you can compile whatever you want and sell your software. Gnat Pro charges for the basic compiler, and it is not cheap compared to others.
> 
> As toolchain, basic Ada compiler is far from other compilers.

This is because Ada compiler vendors are still stuck in the 1980's.

Re: How to get Ada to ?cross the chasm??

[Jacob Sparre Andersen]

jm.tarrasa@gmail.com writes:

> Many compilers have a free version and charge for extras

Just like with GNAT.

You grab the free version from FSF or your favourite distributor.

If you want to pay for support and extra tools, you go to PLC, AdaCore,
RR Software, ICC or one of the other providers of Ada compilers.
(Janus/Ada from RR Software is as far as I know the cheapest option for
a paid solution at the moment.)

Greetings,

Jacob
-- 
Growing older is compulsory. Growing up isn't.

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 
message news:pb7eii$bf1$1@dont-email.me...
...
> In order to create an Ada library with a LGPL or MIT licence
> (for example), you have to fall back to the FSF version which
> does not have that constraint.

Or you could just pay for a compiler rather than assuming some sort of free 
lunch. There's many of them available (see PTC, RRS, Irvine, etc., or even 
AdaCore). Is $195 really too much money?

                           Randy.

Re: How to get Ada to ?cross the chasm??

[Jacob Sparre Andersen]

Randy Brukardt wrote:

> Or you could just pay for a compiler rather than assuming some sort of
> free lunch. There's many of them available (see PTC, RRS, Irvine,
> etc., or even AdaCore). Is $195 really too much money?

195 USD is not too much money.  But having to use Microsoft Windows is
too much of an overhead for me.

Could RR Software make a crowd-funding/pre-pay deal on a Linux version
of Janus/Ada?  How many licenses would you need to sell, to be ready to
commit to deliver a Linux version of Janus/Ada?

Greetings,

Jacob
-- 
"The early bird may get the worm, but the second mouse gets the cheese!"

Re: How to get Ada to ?cross the chasm??

[Mehdi Saada]

"I just want the ability to do the right thing for pretty much everyone who programs." : Sure, but like Mr Jacob said, asking to use Windows beforehand seems a bit contradictory...
Instead of having to maintain multiple versions, is there a problem with platforms like Mingw or cygwin/cygnal ?
Or I should say "what is the problem", since you most likely thought of it before.

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:06afba26-ab67-4def-9320-c6b8fd851d6d@googlegroups.com...
> "I just want the ability to do the right thing for pretty much everyone 
> who programs." : Sure, but like Mr Jacob said, asking to use Windows 
> beforehand seems a bit contradictory...
> Instead of having to maintain multiple versions, is there a problem with 
> platforms like Mingw or cygwin/cygnal ?
> Or I should say "what is the problem", since you most likely thought of it 
> before.

We (RRS) started on CP/M and then MS-DOS. We did do a SCO Unix compiler 
decades ago, but we've never done any significant development on any Unix. 
So using a MingW would require throwing away almost all of our existing work 
(makes no sense).

The main reason we never supported Linux is simply lack of demand. I've been 
asked about it periodically, but never anywhere near as often as Windows 
versions. We're set up to support dozens of versions of things, just not 
using it right now. (That's why we'd always used a semi-custom version 
control; basic version control doesn't handle multiple versions of things 
managed in parallel at all.)

                                  Randy.

Re: How to get Ada to ?cross the chasm??

[Randy Brukardt]

"Jacob Sparre Andersen" <jacob@jacob-sparre.dk> wrote in message 
news:87muxnuuco.fsf@jacob-sparre.dk...
> Randy Brukardt wrote:
>
>> Or you could just pay for a compiler rather than assuming some sort of
>> free lunch. There's many of them available (see PTC, RRS, Irvine,
>> etc., or even AdaCore). Is $195 really too much money?
>
> 195 USD is not too much money.  But having to use Microsoft Windows is
> too much of an overhead for me.
>
> Could RR Software make a crowd-funding/pre-pay deal on a Linux version
> of Janus/Ada?  How many licenses would you need to sell, to be ready to
> commit to deliver a Linux version of Janus/Ada?

Probably not that many (surely more than 20, probably less than 100), but 
I'm pretty booked until Ada 2020 is in the bag (summer 2019). So I wouldn't 
want to promise something that I couldn't complete. [I've thought about this 
project in the past, it probably wouldn't be too hard of a conversion -- we 
had SCO Unix compiler back in the day, so the front-end has needed 
case-insensitive file support.]

                            Randy.

Re: How to get Ada to ?cross the chasm??

[marciant]

On Monday, April 30, 2018 at 10:32:04 PM UTC-4, Randy Brukardt wrote:
> "Jacob Sparre Andersen" ... wrote in message news: ...
> > Randy Brukardt wrote:
> >
> >> Or you could just pay for a compiler rather than assuming some sort of
> >> free lunch. There's many of them available (see PTC, RRS, Irvine,
> >> etc., or even AdaCore). Is $195 really too much money?
> >
> > 195 USD is not too much money.  But having to use Microsoft Windows is
> > too much of an overhead for me.
> >
> > Could RR Software make a crowd-funding/pre-pay deal on a Linux version
> > of Janus/Ada?  How many licenses would you need to sell, to be ready to
> > commit to deliver a Linux version of Janus/Ada?
> 
> Probably not that many (surely more than 20, probably less than 100),

Holy cow!  Then just ask here on c.l.a (and probably some of the other Ada forums) who/how many people would chip in.  I bet some would cough up some money even if they were not actually in personal need of that compiler variant just to shut up the "not enough Ada compilers" detractors! I would!

Vin

Re: How to get Ada to ?cross the chasm??

[Norman Worth]

Simon Clubley wrote:
> On 2018-04-17, Mehdi Saada <00120260a@gmail.com> wrote:
>> I have trouble believing that Adacore (free) forbid completely selling
>> softwares in other licenses as GPL or the likes of. I have no technical
>> knowledge of these things, but I feel like  your points of view are a
>> bit... one sided ?
> 
> Adacore force the GPL on any software developed using the Community
> version. See
> 
> https://www.adacore.com/gnatpro/comparison
> 
> where it says (under Community) "For open source GPL software".
> 
> Oh, and it's not "one sided", it's called giving the Ada community
> a dose of cold reality. You can talk about the advantages of Ada all
> you want but Ada's advantages mean nothing until the Ada compiler
> situation matches the compiler situation for other languages.
> 
> Any compiler which imposes the GPL on any software developed using
> it would be absolutely dead on arrival in many environments especially
> when compilers for other languages are available for free which do
> not impose such constraints.
> 
> GPL based software development is a small subset of all the software
> development out there.
> 
> Also, as far as I can see (and I am willing to be corrected here if
> I am wrong) it means that you can't even write a library in Ada under
> something other than the GPL if you are going to use the Community
> version. As soon as you compile the library source with the Community
> version, it falls under the GPL and hence any software using your
> library also falls under the GPL.
> 
> In order to create an Ada library with a LGPL or MIT licence
> (for example), you have to fall back to the FSF version which
> does not have that constraint.
> 
> Simon.
> 
One of the great fallacies propagated by the commercial software world 
is that GPL requires that software developed using tools licensed under 
it to be open source.  That is not the case.  Software developed using 
GNAT (or the other gcc family compilers) can be, and often is, 
proprietary.  The compiler itself is open source, and direct derivatives 
of it must be open source, but it stops there.  The libraries, although 
open source, are licensed so that they may be included in proprietary works.

It is expensive to develop a compiler.  The early decision to provide a 
free Ada compiler was very controversial.  It was done to make sure that 
something was out there.  The objections were mostly that it was unfair 
competition to commercial developers.  But commercial compilers did 
appear, and some of them are excellent.  Moreover, GNAT provided a cheap 
way for people to learn Ada.  On the downside, it may have turned some 
large companies away from the language by lessening the profit potential 
of the language.

Re: How to get Ada to ?cross the chasm??

[Simon Wright]

Norman Worth <nworth@comcastNOSPAM.net> writes:

> The compiler itself is open source, and direct derivatives of it must
> be open source, but it stops there.  The libraries, although open
> source, are licensed so that they may be included in proprietary
> works.

This is what gives rise to the problem: the compiler runtime library as
written/maintained by AdaCore has additional permisssions that allow
users to write proprietary software using it. This is the version of the
RTS that is supplied to their customers and ends up, somewhat later,
with the FSF compiler.

The Community Edition's RTS, on the other hand, has had the additional
permissions removed (by a script! you can see where they used to be) so
that it is vanilla GPL, and you can't release proprietary binaries using
it.

Re: How to get Ada to ?cross the chasm??

[ric.wai88]

On Wednesday, April 18, 2018 at 8:44:04 AM UTC-4, Simon Clubley wrote:
> On 2018-04-17, Mehdi Saada <00120260a@gmail.com> wrote:
> > I have trouble believing that Adacore (free) forbid completely selling
> > softwares in other licenses as GPL or the likes of. I have no technical
> > knowledge of these things, but I feel like  your points of view are a
> > bit... one sided ?
> 
> Adacore force the GPL on any software developed using the Community
> version. See
> 
> https://www.adacore.com/gnatpro/comparison
> 
> where it says (under Community) "For open source GPL software".
> 
> Oh, and it's not "one sided", it's called giving the Ada community
> a dose of cold reality. You can talk about the advantages of Ada all
> you want but Ada's advantages mean nothing until the Ada compiler
> situation matches the compiler situation for other languages.
> 
> Any compiler which imposes the GPL on any software developed using
> it would be absolutely dead on arrival in many environments especially
> when compilers for other languages are available for free which do
> not impose such constraints.
> 
> GPL based software development is a small subset of all the software
> development out there.
> 
> Also, as far as I can see (and I am willing to be corrected here if
> I am wrong) it means that you can't even write a library in Ada under
> something other than the GPL if you are going to use the Community
> version. As soon as you compile the library source with the Community
> version, it falls under the GPL and hence any software using your
> library also falls under the GPL.
> 
> In order to create an Ada library with a LGPL or MIT licence
> (for example), you have to fall back to the FSF version which
> does not have that constraint.
> 
> Simon.
> 
> -- 
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Microsoft: Bringing you 1980s technology to a 21st century world

This perplexes me though.. We use Ada commercially, and simply build FSF GNAT, which comes with the full run-time exception. It takes a bit of tinkering to get it going, but what doesn't in the open source world?

Re: How to get Ada to ?cross the chasm??

[Dan'l Miller]

On Wednesday, May 2, 2018 at 9:39:23 AM UTC-5, ric....@gmail.com wrote:
> ...  We use Ada commercially, and simply build FSF GNAT, which comes with the full run-time exception.
> It takes a bit of tinkering to get it going, but what doesn't in the open source world?

Do you ever notice any bugs in the FSF Ada compiler or its runtime (especially bugs that are absent in GNAT GPL Community Edition)?

Other people are saying that, yes, narrowly speaking FSF GNAT legalistically is an option due to more-favorable licensing of the run-time, but they are effectively compelled to copy bug fixes from GNAT GPL Community Edition's source code to fix those bugs.  When those bugs are in the runtime, then the only legal right one has to copy/distribute those snippets of AdaCore source code is GPLv3, not the Runtime Exception or LGPL or any other nonviral license.  Hence, AdaCore's GPLv3 licensing is effectively incompatible with FSF's Runtime Exception licensing until/if AdaCore itself performs the act of copying those snippets to fix those bugs.

Re: How to get Ada to ?cross the chasm??

[Niklas Holsti]

On 18-05-02 20:10 , Dan'l Miller wrote:
> On Wednesday, May 2, 2018 at 9:39:23 AM UTC-5, ric....@gmail.com
> wrote:
>> ...  We use Ada commercially, and simply build FSF GNAT, which
>> comes with the full run-time exception. It takes a bit of tinkering
>> to get it going, but what doesn't in the open source world?
>
> Do you ever notice any bugs in the FSF Ada compiler or its runtime
> (especially bugs that are absent in GNAT GPL Community Edition)?

Perhaps the question was not addressed generally, but my experience, 
over some 10 years of using the FSF GNAT (Debian and MinGW) to develop a 
commercial SW product was the following: I found one problem that I 
suspect to be an error in the implementation of Unbounded_String, but 
which was not serious enough for me to track it down and report it. 
However, I was conservative, and did not start using new Ada features 
until they had been available in GNAT for a couple of years.

> Other people are saying that, yes, narrowly speaking FSF GNAT
> legalistically is an option due to more-favorable licensing of the
> run-time,

I found the FSF GNAT option viable, and am grateful to the people who 
made and make it available for commercial non-FOSS SW.

> but they are effectively compelled to copy bug fixes from
> GNAT GPL Community Edition's source code to fix those bugs.

Or they can avoid using the buggy feature.

> When those bugs are in the runtime, then the only legal right one
> has to copy/distribute those snippets of AdaCore source code is
> GPLv3, not the Runtime Exception or LGPL or any other nonviral
> license.

I doubt that. IANAL, but I think most bug fixes are so small that 
copyright would not apply. If the correction to "N := N + 1" is to 
change it to "N := N - 1", I do not believe that AdaCore could claim 
copyright to the correction. Copyright also cannot be claimed on things 
that can essentially be done in only one way, that is, when the 
"expression" (the code) of the idea is implicit in the idea itself.

A direct importation of entire modules or larger pieces of code from the 
AdaCore run-time to the FSF run-time could be a violation of copyright. 
A re-implemenation of the module, even using the same algorithms as used 
by AdaCore, would not, AIUI, be a copyright violation. This is not about 
patentable ideas, but about expression of ideas.

A more severe limitation of the FSF GNAT is the non-availability of 
run-times for non-PC systems, such as embedded microcontrollers. Not all 
embedded systems can be implemented with Linux or MS Windows on x86. 
This is an area where amateurs could contribute, and several have.

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

Re: How to get Ada to ?cross the chasm??

[Simon Wright]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> I doubt that. IANAL, but I think most bug fixes are so small that
> copyright would not apply. If the correction to "N := N + 1" is to
> change it to "N := N - 1", I do not believe that AdaCore could claim
> copyright to the correction. Copyright also cannot be claimed on
> things that can essentially be done in only one way, that is, when the
> "expression" (the code) of the idea is implicit in the idea itself.
>
> A direct importation of entire modules or larger pieces of code from
> the AdaCore run-time to the FSF run-time could be a violation of
> copyright. A re-implemenation of the module, even using the same
> algorithms as used by AdaCore, would not, AIUI, be a copyright
> violation. This is not about patentable ideas, but about expression of
> ideas.

Not actually copyright, since (judging by the 2017 CE) it's assigned to
the FSF anyway. It's a licencing issue.

Re: How to get Ada to ?cross the chasm??

[Dan'l Miller]

On Thursday, May 3, 2018 at 12:00:20 PM UTC-5, Simon Wright wrote:
> Not actually copyright, since (judging by the 2017 CE) it's assigned to
> the FSF anyway. It's a licencing issue.

Yes, narrowly speaking, the license itself as a document (with 2 parties exchanging valuable consideration in exchange for agreed-upon terms) is evocation of contract law.  But, the contract in GPLv3 to copy/distribute those files or derivative works thereof (e.g., merged source code; object code; executables) has no legal basis other than in copyright laws' rights to copy.  So in the end, there is not one scintilla of license other than predicated entirely on copyright law in the GPL*; even the patent topics in GPLv3 are tied directly to rights to copy under copyright law.  (If you refuse to copy GPLv3 works & derived works, then you don't need to obey the patent terms in the license because you chose to not evoke the stated rights to copy under copyright law in the license by not using/copying the GPLed software in the first place.)

* At least in proprietary EULAs, some money is (typically) exchanged, which brings in at least one other body of law:  commerce law.  GPL lacks that overt purchase of the rights in the EULA, so rights in monetary-based commercial transactions via, say, the Uniform Commercial Code would be impractical to evoke regarding the GPL, since the GPL is not predicated on end users purchasing their rights (as typically occurs in EULAs).  The GPL grants rights for gratis predicated only on strict obedience to the contract, where using/deriving from the GPLed works is itself the valuable consideration to remind the user/copier to continue complying with the terms of the contract.

[I am speaking from the perspective of conservative law (e.g., Texas) as largely derived from pre-1776 British Common Law.  Some other systems of law (e.g., Napoleonic civil law in portions of Europe & colonial derivatives thereof; communist in PRChina and Vietnam) likely are not as compartmentalized.]

Re: How to get Ada to ?cross the chasm??

[Dan'l Miller]

On Thursday, May 3, 2018 at 12:00:20 PM UTC-5, Simon Wright wrote:
> Not actually copyright, since (judging by the 2017 CE) it's assigned to
> the FSF anyway. It's a licencing issue.

You do bring up an interesting point:  because AdaCore appears to immediately assign all rights to copy to Free Software Foundation the moment that AdaCore employees invoke the file-save function in their text editor in files comprising GNAT and its portion-of-GCC runtime, it seems that only Free Software Foundation would have legal standing to fully enforce the GPLv3-without-Runtime-Exception in GNAT GPL Community Edition.  As a spectator in the public audience not a party to any such dispute, it would be a fascinating to see years or decades from now whether a maintainer of FSF GNAT who wholesale copied nontrivial portions of GNAT GPL Community Edition into FSF GNAT repositories would evoke the ire of FSF enough (while maintaining FSF's own intellectual property in FSF repositories) for FSF to take legal action effectively against itself.  It is not clear at all precisely which nail AdaCore would hang its “but it is ours all ours” hat on—apparently certainly none of the files that say Copyright Free Software Foundation instead of Copyright AdaCore, Inc.

Please note that any official maintainer of FSF GNAT acting under authority of FSF would seem free to declare that FSF is evoking its right as owner of the rights to copy GNAT to relicense any portion of GNAT GPL Community Edition to which FSF has been assigned the rights to copy, adjusting the license for that copy from ‘•without• Runtime Exception’ to ‘•with• Runtime Exception’ as GPLv3 seems to overtly permit in section 7 Additional Terms “You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission.”  FSF and its official maintainers deemed to be working on behalf of FSF for FSF-assigned/owned intellectual property [e.g., FSF GNAT] are the “you” therein.  The Runtime Exception would be the “additional permission” therein.  AdaCore's irrevocable assignment to FSF would be the “for which you have or can give appropriate copyright permission” therein; FSF, not AdaCore, effectively owns it at the moment of irrevocable assignment of copyright of that file; that is what assignment means.

I am not a lawyer and have not passed the bar in any jurisdiction.  I am speaking for only myself in novelty-entertainment value for my own personal enjoyment as a purely-hypothetical/theoretical logic exercise regarding my understanding of plain-meaning reading of English prose.  Do not rely on any of this without consulting a lawyer.

Re: How to get Ada to “cross the chasm”?

[Olivier Henley]

Personally I really appreciate having quality staff (AdaCore) maintaining the heavy stuff. All the work they do to polish, update, fix, bring new projects to the ecosystem is great and has to be paid somehow. 

Let say the impedance match between different FSF versions, some "official" project/libs and developer project code varies a lot (eg A lot of github projects do not even build on platform xyz using xyz compiler. I did try a lot of them, this year, on many platforms. Its not that pretty.) 

I would be quite happy with a "proportional royalties" model. Everyone uses the pro version and pay a rato of their product profitability (say 1%). I make a small app that brings 0$ annually, I owe nothing to AdaCore. The year after it brings 1,000,000$ I owe AdaCore 10k$. 

The Unreal game engine enforce such a deal. You do not make money, you owe nothing, you do money building on others work, you owe to others.

I would even go further: an automated way to profile "runtime busyness" of code dependencies over a product. From this an "owing chain" could be determined and map the retribution of the end product profits. This way, the guy that made a quality png parser used upon thousand of profitable commercial projects would get paid accordingly. Such a system would probably boost quality and competition on all fronts.

Re: How to get Ada to “cross the chasm”?

[Mehdi Saada]

For dictionnaries, you can instantiate ada.strings.bounded ou unbounded, to get a variable-length string, then instantiate Ada.containers.bounded_hashed_maps like this:

first you have to overload the hash function a bit since it takes only the type String.
function Hash(A: your_string_type) is
(ada.string.Hash(To_String(A)));

then you create your hashed map package:
package hashed_maps is new ada.containers.bounded_hashed_maps
(Key_Type => your_string_type, Element_Type => another_string_type, Hash => Ada.string.Hash, Equivalent_Keys => "=");

and there you have your dictionary.
DIct: Map (Nombre_de_mots_max, Default_modulus(Nombre_de_mots_max));

I let you understand the subprograms, but most of them are self-evident, and repeat themselves all over the containers libraries.

Sure, there are no containers aggregates which would make the syntax more natural as in Python, but it's being studied for the next Ada. It doesn't hinder the use so much, though.

Re: How to get Ada to “cross the chasm”?

[Dmitry A. Kazakov]

On 2018-04-30 13:28, Mehdi Saada wrote:
> For dictionnaries, you can instantiate ada.strings.bounded ou unbounded, to get a variable-length string, then instantiate Ada.containers.bounded_hashed_maps like this:

Or, I suppose, Containers.Indefinite_Ordered_Maps.

However, from a string map I would expect bit more functionality than 
either map or "dictionary" offers. It also depends on whether the target 
objects in the map must be mutable, have an identity etc.

> Sure, there are no containers aggregates which would make the syntax more natural as in Python,

I don't find Python syntax of aggregates natural. It is rather 
incredibly cumbersome, counter-intuitive, lacks regularity and clarity 
Ada syntax has.

> but it's being studied for the next Ada. It doesn't hinder the use so much, though.

Well, I cautiously doubt it. As the history with iterators and implicit 
derefence shows we unlikely get the syntax and functionality we wanted.

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

Re: How to get Ada to “cross the chasm”?

[Mehdi Saada]

I must add I just had to look for 3 minutes, no more. I never used maps before. So if you patented programmer could make the effort before asking...

Re: How to get Ada to “cross the chasm”?

[Norman Worth]

Dan'l Miller wrote:
> http://cppdepend.com/blog/?p=994
> 
> “According to Moore, the marketer should focus on one group of customers at a time, using each group as a base for marketing to the next group. The most difficult step is making the transition between visionaries (early adopters) and pragmatists (early majority).”
> 
> Do we all agree that Ada has never quite crossed the chasm (although it almost did during the late 1980s)?  How can Ada cross the chasm?
> 
> How will Ada use one base of programmers/software-engineers as a basis to move onto convincing another group of programmers/software-engineers of Ada's advantages?  Or is the purpose of Ada to preach to its current choir without trying to fill the pews with new parishioners?
> 
I think one of the reasons Ada did not catch on in a really big way was 
the lack of a sponsor.  Yes, DoD was a sponsor in the early days, and 
they did a great job of defining the philosophy and launching the 
language.  But they gave up and mostly abandoned the language.  This was 
in large part because contractors and the corporate world refused to use 
Ada (in part because the programmers thought being labeled as an Ada 
programmer would mean their skills would be unmarketable).  Also, DoD 
sponsorship is a limited niche, you need a few corporate biggies to sign 
on and support the language.  (DoD also sponsored Jovial, an excellent 
language for its time, that persisted into the 1990s but was never 
available outside DoD.)  Several big companies gave it a brief look, but 
decided that the market was too limited or the language was too 
complicated for practical use.  Several universities adopted Ada as 
their primary language for teaching programming, but lack of support 
caused most of them to abandon it.

There are many objections to Ada.  It is a very large language, and is 
quite fussy.  People think that makes it hard to learn and hard to use. 
Those who use it know that you first learn a practical subset and use 
it, learning and adopting additional features as you encounter problems 
that need them.  This is particularly effective in a team programming 
environment where you get peer reviews of your code, a great leaning 
tool.  I have heard complaints about Ada's wordiness.  This is true - 
Ada is almost as verbose as COBOL.  But it is readable, and that 
wordiness also contributes to its reliability.  People think it 
generates poor and inefficient machine code.  Wrong, at least for the 
couple of compilers I've used.  It is particularly more efficient than 
the interpretive languages that are currently popular.  People say it 
makes the development cycle too slow, that it takes too much time to 
write a working program.  In today's get it out the door today, without 
much testing, world, that may be true.  But reliability does count for 
something on the bottom line.  People complain that modern tools that 
make for a productive shop are not available.  They are, but maybe not 
in the style and variety some want.

In general, Ada is just not popular.  It was never given the chance to 
gather a large following.

Re: How to get Ada to “cross the chasm”?

[guyclaude.burger]

Since this topic has somewhat turn into a Ada vs Rust/Haskell/whatever, could some experts show a piece of Ada code where the "borrower-checker" would more check/security ? Or are the paradigms too different to show a snippet close enough to (or IN ) Ada so that I can understand ?

Re: How to get Ada to “cross the chasm”?

[Dan'l Miller]

On Friday, May 4, 2018 at 11:13:09 AM UTC-5, guyclaud...@gmail.com wrote:
> Since this topic has somewhat turn into a Ada vs Rust/Haskell/whatever, could some experts show a piece
> of Ada code where the "borrower-checker" would more check/security ? Or are the paradigms too different
> to show a snippet close enough to (or IN ) Ada so that I can understand ?

The Ada source code that you are seeking (and corresponding Rust code) would demonstrate some form of utilization of the access keyword whose referent the borrow checker would track as either 1) mutably singly owned or 2) immutable shared.  As soon as the access keyword appears in source code, someone on c.l.a will say that a better memory-management design would be to either eliminate access altogether or bury it with a library.  Although I would applaud anyone who takes the time to craft such lucid demonstration Ada source code (as it would be illuminating to see variations on the theme), as soon as someone posts even a single line of Ada source code, there will be many replies that will conform to the 2nd sentence of this paragraph.  The main moral of the story (despite the quantity of the requisite back & forth replies) will tend to be the 1st sentence in this paragraph.

Ultimately it comes down to:  Rust's borrow checker in Ada would embrace accesses as much as references in Rust and smart-pointers in modern C++, but the trend of modern Ada is to de-emphasize accesses.  Ada-the-language and Ada-the-de-facto-culture are diverging over time.

Re: How to get Ada to "cross the chasm"?

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:94bd81e5-2ef5-41a2-973a-72f2ba4cecd1@googlegroups.com...
...
>Ultimately it comes down to:  Rust's borrow checker in Ada would embrace
>accesses as much as references in Rust and smart-pointers in modern C++,
>but the trend of modern Ada is to de-emphasize accesses.

Yes, that's one approach (see AI12-0240-1 for how that could work in Ada).

> Ada-the-language
>and Ada-the-de-facto-culture are diverging over time.

Doesn't have to. One needs something like the Rust borrow checker to safely 
implement the containers and other libraries in the "task-safe" world of Ada 
2020. But there's no need to expose those access values outside of the 
container. Indeed, it is much better for everyone if they are not exposed.

I'm working on a much simpler version of AI12-0240-1 (an alternative) that 
would mainly be designed to implement containers and other ADTs. The "borrow 
checked" access types in such a case are confined to the private part and 
body of the ADT, and don't cause issues with the rest of the program.

My point here is that these are not mutually exclusive positions: a "safe" 
access type can be very valuable even if its use is not very general. (It's 
hard in Ada to build a complex data structure without using an access type, 
and that's especially true if you want to implement the Ada runtime in Ada.)

                        Randy.

Re: How to get Ada to "cross the chasm"?

[Dan'l Miller]

On Friday, May 4, 2018 at 6:48:21 PM UTC-5, Randy Brukardt wrote:
> "Dan'l Miller" wrote in message 
> news:94bd81e5-2ef5-41a2-973a-72f2ba4cecd1@googlegroups.com...
> ...
> >Ultimately it comes down to:  Rust's borrow checker in Ada would embrace
> >accesses as much as references in Rust and smart-pointers in modern C++,
> >but the trend of modern Ada is to de-emphasize accesses.
> 
> Yes, that's one approach (see AI12-0240-1 for how that could work in Ada).

Wow!  That AI would be a big part of causing Ada2020 to cross the chasm.  The only portion that I wholeheartedly disagree with is:  !priority Very_Low.  Ada2020 needs this AI and task safety.  Jettison everything else if that is what it takes get those 2 accomplished.  Ada2020 needs a clear purpose (safety, safety, safety) or else Ada will have less & less reason to exist (as Rust 2.X or 3.X perhaps becomes safer than Ada2012).  Without these 2, Rust is eventually going to eat Ada's safety lunch (and C++ will continue eating away at Ada from whatever amorphous-amoeba niche that modern C++ has carved out:  rodeo-broncho-rider type inference convoluting the move semantics, pretty darned awesome lambdas, and force-fit-syntaxed Turing-complete templates)

I agree with you being the make-it-work-with-all-features-of-Ada task master—good job!  I agree with Tucker wholeheartedly on:

“… in my view, safe storage management is a
huge issue, and many languages have adopted full garbage collection, not
because it is a "good thing," but merely because having to deal with storage
leaks and dangling references is so painful.

“I think if Ada had a "mode" in which all storage management was safe and
automatic, and there were no dangling references or storage leaks, and yet
also no asynchronous garbage collector meaning that real-time guarantees are
straightforward, all in the presence of multitasking and/or parallelism, this
would be ••truly extraordinary••. …”

It will be fascinating to see your forthcoming counter-proposal to this AI.

Re: How to get Ada to "cross the chasm"?

[Luke A. Guest]

Dan'l Miller <> wrote:
>
> Wow!  That AI would be a big part of causing Ada2020 to cross the chasm. 
> The only portion that I wholeheartedly disagree with is:  !priority
> Very_Low.  Ada2020 needs this AI and task safety.  

I have to agree with this, this should be a high priority imo. Especially
since everyone and their dogs are jumping on the Rust bandwagon, this could
shut them up.

Re: How to get Ada to "cross the chasm"?

[Paul Rubin]

Luke A. Guest <laguest@archeia.com> writes:
> I have to agree with this, this should be a high priority imo. Especially
> since everyone and their dogs are jumping on the Rust bandwagon, this could
> shut them up.

Is this something like C++ std::unique_ptr except the compiler is
supposed to enforce 1) you never call something like .get() which
extracts an unrestricted pointer, and 2) you can never use a unique_ptr
variable if you've transferred away the ownership with the equivalent of
std::move (ordinary assignment in the AI example)?  In C++ doing that is
a runtime error, which isn't ideal.

1) seems easy, 2) looks very useful but might have far-reaching
implications for the compiler type checker.  Would it need something
like Rust's affine types?  I don't know how they work but if Ada got
them, maybe they could be used in lots of other ways as well.  

Re: How to get Ada to "cross the chasm"?

[Randy Brukardt]

"Luke A. Guest" <laguest@archeia.com> wrote in message 
news:431526826.547202380.696445.laguest-archeia.com@nntp.aioe.org...
> Dan'l Miller <> wrote:
>>
>> Wow!  That AI would be a big part of causing Ada2020 to cross the chasm.
>> The only portion that I wholeheartedly disagree with is:  !priority
>> Very_Low.  Ada2020 needs this AI and task safety.
>
> I have to agree with this, this should be a high priority imo. Especially
> since everyone and their dogs are jumping on the Rust bandwagon, this 
> could
> shut them up.

It got priority Very_Low because it was very late, it's very large, and it 
is not in the primary scope of Ada 2020 (as described by our WG 9 
instructions). The "very large" part means that we'd have to delay Ada 2020 
several years to properly vet this policy.

I'm trying to look for a radical simplification, as we managed with subpools 
and other proposals that were originally gigantic. Otherwise, we'll have no 
choice but to delay Ada 2020 or defer it. (My opinion only on this, it's 
never been discussed in a meeting.)

                                Randy.

Re: How to get Ada to "cross the chasm"?

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> I'm trying to look for a radical simplification... Otherwise, we'll
> have no choice but to delay Ada 2020 or defer it. 

If you mean "defer it" means ship Ada 2020 on schedule but postpone this
particular feature til post-Ada-2020, that might be reasonable, since
it's important to get it right in the long run.  Is it possible to do
what C++ does and release an experimental feature that might be changed
incompatibly in a future version?

Re: How to get Ada to "cross the chasm"?

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87lgcvf9tx.fsf@nightsong.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> I'm trying to look for a radical simplification... Otherwise, we'll
>> have no choice but to delay Ada 2020 or defer it.
>
> If you mean "defer it" means ship Ada 2020 on schedule but postpone this
> particular feature til post-Ada-2020, that might be reasonable, since
> it's important to get it right in the long run.  Is it possible to do
> what C++ does and release an experimental feature that might be changed
> incompatibly in a future version?

Not as part of the Standard, but we could make a "Technical Specification", 
which essentially describes a pre-standardization feature. That's definitely 
one the options that we'll consider.

I expect that I'll be able to report more on this topic after our June 
Lisbon meeting.

               Randy.

Re: How to get Ada to "cross the chasm"?

[Dan'l Miller]

Randy Bruckardt wrote:
> "Luke A. Guest" <lag...@archeia.com> wrote in message 
> news:431526826.547202380.696445.laguest-archeia.com@nntp.aioe.org... 
> > Dan'l Miller <> wrote: 
> >> 
> >> Wow!  That AI would be a big part of causing Ada2020 to cross the chasm. 
> >> The only portion that I wholeheartedly disagree with is:  !priority 
> >> Very_Low.  Ada2020 needs this AI and task safety. 
> > 
> > I have to agree with this, this should be a high priority imo. Especially 
> > since everyone and their dogs are jumping on the Rust bandwagon, this 
> > could 
> > shut them up. 
>
> It got priority Very_Low because it was very
> late, it's very large, and it is not in the primary
> scope of Ada 2020 (as described by our WG 9
> instructions). The "very large" part means that
> we'd have to delay Ada 2020 
> several years to properly vet this policy. 
>
> I'm trying to look for a radical simplification, as
> we managed with subpools 
> and other proposals that were originally
gigantic.
> Otherwise, we'll have no choice but to delay
> Ada 2020 or defer it.
> (My opinion only on this, it's never been
> discussed in a meeting.) 

Randy, there really have been only 2 technical ideas on this & related threads here on c.l.a that would likely decisively cause Ada to have a new reason to cross the chasm:
1) your task safety
and
2) retrofitting some variant of Rust’s borrow checker into Ada
(Third is nontechnical: somehow loosening the multi-tens-of-thousands-of-dollars stranglehold that GNAT Pro licensing has on Ada’s great-language-with-a-compiler-problem bad situation.)

I look forward to seeing the radical-simplification counterproposal of AI 240.  I am absolutely certain that Tucker’s first edition of this AI will be compared point by point to the radical simplification and then both to Rust’s borrow checker.

I suspect that a borrow checker in Ada is a required stepping stone to the task safety AI, but we haven’t seen that one either, so only time will tell, whether your task safety vision ends up dragging borrow-checker in through the backdoor.

You do realize that there exists a 3-way race in the next few years, don’t you?
1) Ada2020 with some sort of retrofit of Rust-esque borrow checker;
2) Rust 2.X or 3.X reaches sufficient feature parity with Ada2012 (or even the rest of Ada2020) to make all Ada points as moot as an Algol68-esque footnote in the history books.
3) someone designs AdaFe (pronounced Ada Iron) that would be effectively Tucker’s grand borrow-checker edition of AI 240: the merger of Rust’s safety semantics and Ada2012.  AdaFe could be that Ada for the 21st century that some people are mentioning, jettisoning a few of Ada’s worst features in the process.

Re: How to get Ada to “cross the chasm”?

[Jere]

On Friday, May 4, 2018 at 12:13:09 PM UTC-4, guyclaud wrote:
> Since this topic has somewhat turn into a Ada vs Rust/Haskell/whatever, could some experts show a piece of Ada code where the "borrower-checker" would more check/security ? Or are the paradigms too different to show a snippet close enough to (or IN ) Ada so that I can understand ?

They are very different languages.  I am going to try and show a couple of
situations caught by Rust at compile time.  They won't be perfect comparisons
though.  Keep in mind that Ada can pass objects by reference internally 
while in Rust it has to be explicitly requested.  

1.  Dangling references:  Keeping a reference to an object past its lifetime

Ada:
***********************************************
with Ada.Text_IO; use Ada.Text_IO;

procedure jdoodle is
    type Integer_Access is access all Integer;
    
    function Inner(Value : aliased in out Integer) return Integer_Access is
    begin
        return Value'Access;
    end Inner;
    
    function Outer return Integer_Access is
        Value : aliased Integer := 0;
    begin
        return Inner(Value);
    end Outer;
    
    Ptr : Integer_Access := Outer;  -- !!! Dangling reference
begin
    Put_Line("Hello World");
end jdoodle;
***********************************************
Hello World

gcc -c jdoodle.adb
gnatbind -x jdoodle.ali
gnatlink jdoodle.ali -o jdoodle



A attempt to the equivalent in Rust:
***********************************************
pub fn Inner(value : & mut i32) -> & mut i32 {
    return value;
}

pub fn Outer() -> &mut i32 {
    let mut x = 0 as i32;
    return Inner(&x);
}

pub fn main() {
    let ptr : &mut i32 = Outer;
    println!("Hello World")
}
***********************************************
Compiling playground v0.0.1 (file:///playground)
error[E0106]: missing lifetime specifier
 --> src/main.rs:5:19
  |
5 | pub fn Outer() -> &mut i32 {
  |                   ^ expected lifetime parameter
  |
  = help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from
  = help: consider giving it a 'static lifetime

You have to make it use a static lifetime to work (which removes the
dangling reference) while Ada does accept it as is.


2.  Concurrent Erroneous Access
Ada:
******************************************
with Ada.Text_IO; use Ada.Text_IO;
with Ada.Containers.Vectors;

procedure jdoodle is

    package Vectors is new Ada.Containers.Vectors(Positive,Integer);

    type Some_Type is limited record
        Data : Vectors.Vector;
    end record;
    
    Some_Object : aliased Some_Type;
    
    task Some_Task is
        entry Start;
    end Some_Task;
    
    task body Some_Task is
    begin
        accept Start;
        for Index in 1 .. 100 loop
            Some_Object.Data.Append(Index);
        end loop;
    end Some_Task;
    
begin
    Put_Line("Hello World");
    Some_Task.Start;
    for Index in 1 .. 100 loop
        Some_Object.Data.Append(Index);  -- !!! Possible Erroneous Memory Access
    end loop;
end jdoodle;
******************************************
Hello World

gcc -c jdoodle.adb
gnatbind -x jdoodle.ali
gnatlink jdoodle.ali -o jdoodle



Attempt at a similar setup in Rust:
******************************************
use std::vec;
use std::thread;

pub struct SomeType {
    pub data : vec::Vec<i32>
}

pub fn main() {
    let mut some_object = SomeType{
        data : vec::Vec::new()
    };
    
    println!("Hello World");
    
    let handler = thread::spawn(move || {
        for index in 1 .. 11 {
            some_object.data.push(index as i32);
        }
    });
    
    for index in 1 .. 11 {
        some_object.data.push(index as i32);
    }
    handler.join().unwrap();
}
******************************************
Compiling playground v0.0.1 (file:///playground)
error[E0382]: use of moved value: `some_object.data`
  --> src/main.rs:22:9
   |
15 |     let handler = thread::spawn(move || {
   |                                 ------- value moved (into closure) here
...
22 |         some_object.data.push(index as i32);
   |         ^^^^^^^^^^^^^^^^ value used here after move
   |
   = note: move occurs because `some_object` has type `SomeType`, which does not implement the `Copy` trait

If you try and remove the move specifier it then gives the error
that you need to put the move specifier to pass data into the thread.
Basically, in Rust it forces you to use synchronization primitives
on any variable being used in a thread (task equiv), which would be
similar to if Ada required all variables in a thread to be protected
types or fulfilled some other task safe context.

Again, the languages are quite different so it is really hard to 
put together an actual comparison.  Ada has many strengths over
Rust though.  It is always easy to find some area where language
x is better than langauge y in a particular area.  What matters
most is the whole package vs the whole package and how they affect
software development and design.

Re: How to get Ada to "cross the chasm"?

[Randy Brukardt]

"Jere" <jhb.chat@gmail.com> wrote in message 
news:661b1ce8-f4e4-4a4b-9a07-ebe36d75f010@googlegroups.com...
...
>Basically, in Rust it forces you to use synchronization primitives
>on any variable being used in a thread (task equiv), which would be
>similar to if Ada required all variables in a thread to be protected
>types or fulfilled some other task safe context.

This is essentially what Ada 2020 is requiring(*) for parallel execution. 
(Tasks are of course unchanged for compatibility reasons, and one can turn 
off the checks for parallel execution if you think you know what you're 
doing.)

(*) This has changed a lot and it is still is mostly imaginary (little 
wording to date) so I surely hope this remains true. If not, I'll recommend 
delaying Ada 2020 until it is true, I don't see any point in yet another way 
to screw up with no compiler help.

The formal definition is that only subprograms that are globally 
synchronized and nonblocking can be called from a parallel construct. Both 
global synchronization and nonblocking are statically checked.


                        Randy.

Re: How to get Ada to “cross the chasm”?

[G.B.]

On 04.05.18 21:05, Jere wrote:

> 1.  Dangling references:  Keeping a reference to an object past its lifetime
> 
> Ada:
> ***********************************************
> with Ada.Text_IO; use Ada.Text_IO;
> 
> procedure jdoodle is
>      type Integer_Access is access all Integer;
>      
>      function Inner(Value : aliased in out Integer) return Integer_Access is
>      begin
>          return Value'Access;
>      end Inner;
>      
>      function Outer return Integer_Access is
>          Value : aliased Integer := 0;
>      begin
>          return Inner(Value);
>      end Outer;
>      
>      Ptr : Integer_Access := Outer;  -- !!! Dangling reference
> begin
>      Put_Line("Hello World");
> end jdoodle;

Anything that can be done to prevent the above effect
should be welcome, if it is representative of what the
2012 RM allows. Or is this new *aliased* parameter thing
some I-know-what-I-am-doing Ada?

So, do explicitly *aliased* parameters indeed break all accessiblity
rules of Ada?  I noticed that it is mentioned in the RM alongside
parameters that are passed by reference already because their
type is a by-reference type. I'd expect then, that one
would drop *aliased* for those kinds of type, thus


     27. with Ada.Text_IO; use Ada.Text_IO;
     28.
     29. procedure jdoodle2 is
     30.     type T is tagged
     31.        record
     32.            Data :  Integer;
     33.        end record;
     34.
     35.     type T_Access is access all T;
     36.
     37.     function Inner(Value : in out T) return T_Access is
     38.     begin
     39.         return Value'Access;
                        |
         >>> non-local pointer cannot point to local object

     40.     end Inner;
     41.
     42.     function Outer return T_Access is
     43.         Value : aliased T := T'(Data => 0);
     44.     begin
     45.         return Inner(Value);
     46.     end Outer;
     47.
     48.     Ptr : T_Access := Outer;
     49. begin
     50.     Put_Line("Hello World");
     51. end jdoodle2;


The same dangling pointer effect reappears, however, when I put
*aliased* back, for no apparent reason:

     function Inner(Value : aliased in out T) return T_Access is
     begin
         return Value'Access;
     end Inner;

Re: How to get Ada to "cross the chasm"?

[Randy Brukardt]

"G.B." <bauhaus@notmyhomepage.invalid> wrote in message 
news:pckn7r$too$1@dont-email.me...
> On 04.05.18 21:05, Jere wrote:
>
>> 1.  Dangling references:  Keeping a reference to an object past its 
>> lifetime
>>
>> Ada:
>> ***********************************************
>> with Ada.Text_IO; use Ada.Text_IO;
>>
>> procedure jdoodle is
>>      type Integer_Access is access all Integer;
>>      function Inner(Value : aliased in out Integer) return Integer_Access 
>> is
>>      begin
>>          return Value'Access;
>>      end Inner;
>>      function Outer return Integer_Access is
>>          Value : aliased Integer := 0;
>>      begin
>>          return Inner(Value);

This should be illegal, as it fails an accessibility check. The parameter to 
Inner has to have the same (or longer) accessibility level as the function 
call to Inner, but it doesn't. So this is illegal. You get the same error 
with an allocator:

        Ptr : Integer_Access := new Integer'(Value);

Now, whether your favorite Ada compiler implements this rather obscure check 
properly is another question (it should, there are examples in the ACATS), 
but it's not a language question.

>>      end Outer;
>>      Ptr : Integer_Access := Outer;  -- !!! Dangling reference

Only if Outer was legal, which it is not.

>> begin
>>      Put_Line("Hello World");
>> end jdoodle;
>
> Anything that can be done to prevent the above effect
> should be welcome, if it is representative of what the
> 2012 RM allows. Or is this new *aliased* parameter thing
> some I-know-what-I-am-doing Ada?

Not needed and no. :-)

> So, do explicitly *aliased* parameters indeed break all accessiblity
> rules of Ada?

Surely not. The check moves to the parameter of the call, but it doesn't 
disappear.

>  I noticed that it is mentioned in the RM alongside
> parameters that are passed by reference already because their
> type is a by-reference type. I'd expect then, that one
> would drop *aliased* for those kinds of type, thus
>
>     27. with Ada.Text_IO; use Ada.Text_IO;
>     28.
>     29. procedure jdoodle2 is
>     30.     type T is tagged
>     31.        record
>     32.            Data :  Integer;
>     33.        end record;
>     34.
>     35.     type T_Access is access all T;
>     36.
>     37.     function Inner(Value : in out T) return T_Access is
>     38.     begin
>     39.         return Value'Access;
>                        |
>         >>> non-local pointer cannot point to local object
>
>     40.     end Inner;
>     41.
>     42.     function Outer return T_Access is
>     43.         Value : aliased T := T'(Data => 0);
>     44.     begin
>     45.         return Inner(Value);
>     46.     end Outer;
>     47.
>     48.     Ptr : T_Access := Outer;
>     49. begin
>     50.     Put_Line("Hello World");
>     51. end jdoodle2;
>
>
> The same dangling pointer effect reappears, however, when I put
> *aliased* back, for no apparent reason:
>
>     function Inner(Value : aliased in out T) return T_Access is
>     begin
>         return Value'Access;
>     end Inner;

The accessibility of an explicitly aliased parameter is that of the function 
result. It's specifically intended to make this sort of thing legal (as in 
returning an element of a container). The check moves to the parameter, 
because only at the call site does one know if the accessibility works (see 
the allocator case above).

So Inner is legal, but the call to Inner in Outer is illegal; thus no 
dangling pointer.

                        Randy.

Re: How to get Ada to "cross the chasm"?

[G.B.]

On 08.05.18 01:36, Randy Brukardt wrote:
>>>       Ptr : Integer_Access := Outer;  -- !!! Dangling reference
> Only if Outer was legal, which it is not.
> 

Any suspicions of incriminating coding opportunities thus blown away :).

Re: How to get Ada to “cross the chasm”?

[Lucretia]

Another resource that could be useful to add Ada to is https://learnxinyminutes.com, I found that whilst looking for SML.