If not Ada, what else...

If not Ada, what else...

[Alex R. Mosteo]

Hello,

I'm a big supporter of Ada, but I'm the only person that I know that uses it 
in my work environment (mobile robotics research). Everyone is using either 
C, C++, python or java.

I ceased looking into other languages because I am so comfortable with Ada. 
I fear I may have missed some interesting boat.

Do you know of other languages worth to look at (i.e. that will make an Ada 
programmer somewhat happy), that are at least as "popular" as Ada, besides 
these ones mentioned above?

Re: If not Ada, what else...

[Ludovic Brenta]

Alex R. Mosteo wrote on comp.lang.ada:
> Hello,
>
> I'm a big supporter of Ada, but I'm the only person that I know that uses it
> in my work environment (mobile robotics research). Everyone is using either
> C, C++, python or java.
>
> I ceased looking into other languages because I am so comfortable with Ada.
> I fear I may have missed some interesting boat.
>
> Do you know of other languages worth to look at (i.e. that will make an Ada
> programmer somewhat happy), that are at least as "popular" as Ada, besides
> these ones mentioned above?

Modula 2? Plain old Pascal?

Modula 3 and Eiffel could be contenders but probably not in robotics
because they mandate garbage collection; this probably precludes any
kind of hard real-time work.

--
Ludovic Brenta.

Re: If not Ada, what else...

[Alex R. Mosteo]

Ludovic Brenta wrote:

> Alex R. Mosteo wrote on comp.lang.ada:
>> Hello,
>>
>> I'm a big supporter of Ada, but I'm the only person that I know that uses
>> it in my work environment (mobile robotics research). Everyone is using
>> either C, C++, python or java.
>>
>> I ceased looking into other languages because I am so comfortable with
>> Ada. I fear I may have missed some interesting boat.
>>
>> Do you know of other languages worth to look at (i.e. that will make an
>> Ada programmer somewhat happy), that are at least as "popular" as Ada,
>> besides these ones mentioned above?
> 
> Modula 2? Plain old Pascal?
> 
> Modula 3 and Eiffel could be contenders but probably not in robotics
> because they mandate garbage collection; this probably precludes any
> kind of hard real-time work.

Eiffel is something I will have to check eventually, even if only as a 
hobby.

> 
> --
> Ludovic Brenta.

Re: If not Ada, what else...

[Maciej Sobczak]

On Apr 20, 12:39 pm, "Alex R. Mosteo" <alejan...@mosteo.invalid>
wrote:


> Do you know of other languages worth to look at (i.e. that will make an Ada
> programmer somewhat happy), that are at least as "popular" as Ada, besides
> these ones mentioned above?

Don't take me wrong, but your question can be translated as:

"Do you know of other languages that are *popular*, but that I never
heard of and none of my friends have heard of?"

So what is the meaning of "popular", then? :-)

My advice: don't make your life more difficult that it already is and
stick to what you know and like. These are the two most important
factors of successful project.

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

Re: If not Ada, what else...

[Alex R. Mosteo]

Maciej Sobczak wrote:

> On Apr 20, 12:39 pm, "Alex R. Mosteo" <alejan...@mosteo.invalid>
> wrote:
> 
> 
>> Do you know of other languages worth to look at (i.e. that will make an
>> Ada programmer somewhat happy), that are at least as "popular" as Ada,
>> besides these ones mentioned above?
> 
> Don't take me wrong, but your question can be translated as:
> 
> "Do you know of other languages that are *popular*, but that I never
> heard of and none of my friends have heard of?"

Yeah, I guess it was somewhat contradictory. But from time to time I hear 
about D, Ruby, Scala, and wonder if these are going somewhere or what.

Alex.

Re: If not Ada, what else...

[Peter C. Chapin]

On Thu, 21 Apr 2011 10:46:06 +0200, "Alex R. Mosteo"
<alejandro@mosteo.invalid> wrote:

>Yeah, I guess it was somewhat contradictory. But from time to time I hear 
>about D, Ruby, Scala, and wonder if these are going somewhere or what.

I am fond of Scala. It's a very different sort of language than Ada, but in
its world it is also very nice. I believe it may be going somewhere as
well.

Peter

Re: If not Ada, what else...

[Robert Matthews]

Alex R. Mosteo wrote:

> Hello,
> 
> I'm a big supporter of Ada, but I'm the only person that I know that uses
> it in my work environment (mobile robotics research). Everyone is using
> either C, C++, python or java.
> 
> I ceased looking into other languages because I am so comfortable with
> Ada. I fear I may have missed some interesting boat.
> 
> Do you know of other languages worth to look at (i.e. that will make an
> Ada programmer somewhat happy), that are at least as "popular" as Ada,
> besides these ones mentioned above?

This may not be quite what you are looking for, but I find it intriguing: 
"Mercury", located at: http://www.mercury.csse.unimelb.edu.au/index.html

For an old Ada programmer the following from the web site gives me
a warm fuzzy feeling ;)

"Mercury is a new logic/functional programming language, which combines the 
clarity and expressiveness of declarative programming with advanced static 
analysis and error detection features."

Shame it doesn't have an Ada back end.

Robert Matthews

Re: If not Ada, what else...

[Georg Bauhaus]

On 4/21/11 7:19 PM, Robert Matthews wrote:

> "Mercury is a new logic/functional programming language, which combines the
> clarity and expressiveness of declarative programming with advanced static
> analysis and error detection features."
>
> Shame it doesn't have an Ada back end.

Once I have tried to translate the compiler's sources  (in C)
on Mac OS X.  Only went so far.  And only after tackling
automess, IIRC.

Sad. ;-)

Re: If not Ada, what else...

[Florian Weimer]

* Robert Matthews:

> For an old Ada programmer the following from the web site gives me
> a warm fuzzy feeling ;)
>
> "Mercury is a new logic/functional programming language, which combines the 
> clarity and expressiveness of declarative programming with advanced static 
> analysis and error detection features."

If Mercury is in, then the ML family (Standard ML, Objective Caml,
Visual F#, Haskell) is probably not too distant, either. 8-)

Re: If not Ada, what else...

[Robert Matthews]

Florian Weimer wrote:

> If Mercury is in, then the ML family (Standard ML, Objective Caml,
> Visual F#, Haskell) is probably not too distant, either. 8-)

I thnk you are placing Mercury in the "functional" category; think of
it rather as a strongly typed Prolog (though with some extra 
functional bits).

Robert Matthews

Re: If not Ada, what else...

[Brad Cantrell]

If you really want to compare Ada with functional languages, you
should try Erlang. The promise of functional languages are in non-
mutable variables and functions with no side effects which qualifies a
language as being a "pure functional" language. Erlang is almost a
subset of Haskell, the only difference is that its dynamically typed.
It relies on pattern matching with guards much as Haskell does. But
what sets Erlang apart from Haskell is that threading is built into
the language so that it has practical value in dealing with the
outside world. Whereas with Haskell needing modads to communicate with
the outside world, program state is saved in threads with Erlang. I
think if you experiment with threading with Erlang and then with Ada
you will find that the tasks in Erlang will provide more practical
concurrency. Im not saying one is better than the other, I leave that
up to you to decide.

Re: If not Ada, what else...

[Peter C. Chapin]

On Fri, 22 Apr 2011 10:49:41 -0700 (PDT), Brad Cantrell
<cantrellb@gmail.com> wrote:

>If you really want to compare Ada with functional languages, you
>should try Erlang. The promise of functional languages are in non-
>mutable variables and functions with no side effects which qualifies a
>language as being a "pure functional" language. Erlang is almost a
>subset of Haskell, the only difference is that its dynamically typed.
>It relies on pattern matching with guards much as Haskell does. But
>what sets Erlang apart from Haskell is that threading is built into
>the language so that it has practical value in dealing with the
>outside world.

Erlang is cool but I have to put in a pitch for Scala here. Scala comes
with an "actors" library that is modeled after Erlang's approach to
concurrency (message passing). However, like Ada, Scala is statically
typed.

The upcoming 2.9 release of Scala will also include parallel collections
that can be iterated over with parallel for loops (and, in fact, support
many other parallelized operations). This is accomplished without adding
any syntax to the language. Scala's native syntax is extensible enough as
is. For example:

// This method operates on a sequence of type T.
def someMethod[T](data: Seq[T]) = {
   for (item <- data par) {
     // Parallelized loop. Iterations are spread over multiple cores.
   }
}

In the above code 'par' is actually a method being applied to 'data.' The
for loop ends up being parallelized not because the compiler treats it in a
special way, but rather because of the behavior of the 'par' method.

Peter

Re: If not Ada, what else...

[Georg Bauhaus]

On 4/23/11 4:20 AM, Peter C. Chapin wrote:

> // This method operates on a sequence of type T.
> def someMethod[T](data: Seq[T]) = {
>     for (item<- data par) {
>       // Parallelized loop. Iterations are spread over multiple cores.
>     }
> }
>
> In the above code 'par' is actually a method being applied to 'data.' The
> for loop ends up being parallelized not because the compiler treats it in a
> special way, but rather because of the behavior of the 'par' method.

Would 'par' be a normal method or would the programmer
make sure that it operates nicely in parallel, e.g.
does not mess with "shared" variables?

Re: If not Ada, what else...

[Peter C. Chapin]

On Sat, 23 Apr 2011 11:55:56 +0200, Georg Bauhaus
<rm.dash-bauhaus@futureapps.de> wrote:

>On 4/23/11 4:20 AM, Peter C. Chapin wrote:
>
>> // This method operates on a sequence of type T.
>> def someMethod[T](data: Seq[T]) = {
>>     for (item<- data par) {
>>       // Parallelized loop. Iterations are spread over multiple cores.
>>     }
>> }
>>
>> In the above code 'par' is actually a method being applied to 'data.' The
>> for loop ends up being parallelized not because the compiler treats it in a
>> special way, but rather because of the behavior of the 'par' method.
>
>Would 'par' be a normal method or would the programmer
>make sure that it operates nicely in parallel, e.g.
>does not mess with "shared" variables?

'par' is a method provided by the collections library. The programmer is
responsible for making sure the loop body is parallel-safe.

Peter

Re: If not Ada, what else...

[Florian Weimer]

* Robert Matthews:

> Florian Weimer wrote:
>
>> If Mercury is in, then the ML family (Standard ML, Objective Caml,
>> Visual F#, Haskell) is probably not too distant, either. 8-)
>
> I thnk you are placing Mercury in the "functional" category; think of
> it rather as a strongly typed Prolog (though with some extra 
> functional bits).

I know that it's closer to Prolog, but it's so far away from Ada that
at this point, the distinction does not matter anymore.

Re: If not Ada, what else...

[Peter C. Chapin]

On Fri, 22 Apr 2011 23:39:29 +0200, Florian Weimer <fw@deneb.enyo.de>
wrote:

>I know that it's closer to Prolog, but it's so far away from Ada that
>at this point, the distinction does not matter anymore.

I also have an interest in Mercury but I haven't had the time to study it
much yet. The language is very different than Ada... which is good. I've
heard it said (maybe in this newsgroup) that a programming language isn't
worth learning unless it changes the way you think about programming. If
you've never used a logic language before, learning Mercury will probably
have that effect. However, unlike Prolog, Mercury does a lot more analysis
statically (and consequently it has much high execution efficiency). My
understanding is that one of its goals is to be a logic language suitable
for software engineering.

On the other hand Mercury is very much a niche language. Is it even out of
the research stage yet? Languages like Erlang, Scala, and F# (to name
three) bring functional programming to the table and are also being used in
at least some commercial ventures.

Peter

Re: If not Ada, what else...

[björn lundin]

On 20 Apr, 12:39, "Alex R. Mosteo" <alejan...@mosteo.invalid> wrote:
> Hello,
>
> I'm a big supporter of Ada, but I'm the only person that I know that uses it
> in my work environment (mobile robotics research). Everyone is using either
> C, C++, python or java.

Instead of looking for a new language, you could perhaps talk to these
guys?

<http://mdh.diva-portal.org/smash/get/diva2:319413/FULLTEXT01>

To me, it looks like mobile robotics research.
And they do use Ada.
/Björn

Re: If not Ada, what else...

[Piotr Trojanek]

On Apr 20, 12:39 pm, "Alex R. Mosteo" <alejan...@mosteo.invalid>
wrote:
> Hello,
>
> I'm a big supporter of Ada, but I'm the only person that I know that uses it
> in my work environment (mobile robotics research). Everyone is using either
> C, C++, python or java.
>
> I ceased looking into other languages because I am so comfortable with Ada.
> I fear I may have missed some interesting boat.
>
> Do you know of other languages worth to look at (i.e. that will make an Ada
> programmer somewhat happy), that are at least as "popular" as Ada, besides
> these ones mentioned above?

Alex, I am in a kind of similar position - in my robotics team all the
people
are using C++. I have simply decided not to bother and do my work with
Ada.

There are a lot of programming languages around and people use ALL of
them
to program their robots. Please take a look at the list of languages,
which
you can use for Lego NXT programming (Ada is also there!):
http://en.wikipedia.org/wiki/Lego_Mindstorms_NXT#Programming

The question is what is your focus in a robotics research? If it is a
RT control,
than I see no point in not using Ada. If you are interested in AI,
then Lisp is
probably the way to go. It has been shown, that virtually any language
can be
used for a robotic research. I think you should simply pick a one,
which allows
you to focus on what is your primary goal.

--
Piotr

Re: If not Ada, what else...

[Dmitry A. Kazakov]

On Sat, 23 Apr 2011 04:50:43 -0700 (PDT), Piotr Trojanek wrote:

> The question is what is your focus in a robotics research? If it is a RT control,
> than I see no point in not using Ada. If you are interested in AI, then Lisp is
> probably the way to go.

I always did AI in Ada and see no point in using Lisp for that. There is a
common opinion that Lisp and Prolog are good for AI, which is as ungrounded
as the opinion that C is good for drivers. I think that Ada is especially
good for AI because AI is quite nasty when it comes to testing. Often you
cannot figure out whether the problem is due to a bug or a logical error.
Ada sufficiently reduces the bug rate. That helps much.

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

Re: If not Ada, what else...

[Georg Bauhaus]

On 4/23/11 2:23 PM, Dmitry A. Kazakov wrote:
> On Sat, 23 Apr 2011 04:50:43 -0700 (PDT), Piotr Trojanek wrote:
>
>> The question is what is your focus in a robotics research? If it is a RT control,
>> than I see no point in not using Ada. If you are interested in AI, then Lisp is
>> probably the way to go.
>
> I always did AI in Ada and see no point in using Lisp for that. There is a
> common opinion that Lisp and Prolog are good for AI, which is as ungrounded
> as the opinion that C is good for drivers. I think that Ada is especially
> good for AI because AI is quite nasty when it comes to testing. Often you
> cannot figure out whether the problem is due to a bug or a logical error.
> Ada sufficiently reduces the bug rate. That helps much.

Would the work have been just a little easier if there
was a plugable standard garbage collector?

Re: If not Ada, what else...

[Dmitry A. Kazakov]

On Sat, 23 Apr 2011 16:30:42 +0200, Georg Bauhaus wrote:

> On 4/23/11 2:23 PM, Dmitry A. Kazakov wrote:
>> On Sat, 23 Apr 2011 04:50:43 -0700 (PDT), Piotr Trojanek wrote:
>>
>>> The question is what is your focus in a robotics research? If it is a RT control,
>>> than I see no point in not using Ada. If you are interested in AI, then Lisp is
>>> probably the way to go.
>>
>> I always did AI in Ada and see no point in using Lisp for that. There is a
>> common opinion that Lisp and Prolog are good for AI, which is as ungrounded
>> as the opinion that C is good for drivers. I think that Ada is especially
>> good for AI because AI is quite nasty when it comes to testing. Often you
>> cannot figure out whether the problem is due to a bug or a logical error.
>> Ada sufficiently reduces the bug rate. That helps much.
> 
> Would the work have been just a little easier if there
> was a plugable standard garbage collector?

No, because I doubt that a standard collector would work with the
heuristics I used, e.g. for factorization of decision trees, pruning,
cloning upon modification etc. GC does not help in establishing various
"uses", "depends" relationships, like strong, weak, read-only,
weakly-ordered references etc. Which is the whole work. These relationships
cannot be derived from the program, they must be programmed. Since you have
to do this anyway, collection becomes a negligible problem. I don't
remember if I even had a memory leak.

I am very suspicious about usefulness of standard GC in general. I think
that Ada represents a good example of why GC is not needed. If Ada
supported unconstrained components in a less boring form, I bet that the
issue of GC support could be closed. I also think that semantically the
idea of magically working GC contradicts to higher level abstractions. It
can work only in some strata, not too high, not too low. Hence GC is bad
for design.

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

Re: If not Ada, what else...

[Piotr Trojanek]

On Apr 23, 2:23 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Sat, 23 Apr 2011 04:50:43 -0700 (PDT), Piotr Trojanek wrote:
> > The question is what is your focus in a robotics research? If it is a RT control,
> > than I see no point in not using Ada. If you are interested in AI, then Lisp is
> > probably the way to go.
>
> I always did AI in Ada and see no point in using Lisp for that. There is a
> common opinion that Lisp and Prolog are good for AI, which is as ungrounded
> as the opinion that C is good for drivers. I think that Ada is especially
> good for AI because AI is quite nasty when it comes to testing. Often you
> cannot figure out whether the problem is due to a bug or a logical error.
> Ada sufficiently reduces the bug rate. That helps much.

I did not mean, that it is not possible to do an AI in Ada. And of
course
you will benefit from all the strong points of Ada, when it comes to
AI.
This was just an example. My point is, that you should take a tool,
which
allows you to focus on your task at hand.

In other words - you can also do a multi-threading in Lisp, right? But
when it comes to the real-time programming it is not just a matter of
garbage collector, that we will do the job in Ada.

--
Piotr

C++/cmake project, injecting Ada... (was Re: If not Ada, what else...)

[Alex R. Mosteo]

As I was writing this reply, I realized that focusing in a particular case 
at hand may provide better food for though and more precise solutions. So I 
have renamed the thread accordingly. Now, the scenario is like this:

A fairly conventional open source project for doing some high-level 
simulations. C++ based, using cmake for building. Developers using an 
assortment of linux OSses: Ubuntu 10.04, 10.10, Fedora (last 2 or 3 
versions). Eventually, MacOSX could enter the fray. Remember, this is 
loosely cooperative research, nobody mandates the devel platform to a 
particularly tight version.

The project uses several libraries: boost, YARP, opencv, etc, which are 
located by cmake. Somehow all this compiles in such varied environments.

Now, let's suppose the contributions are fairly self-contained (e.g., 
providing a particular class instance for an abstract base class). I know 
how to interface Ada and C/C++, don't mind to write glue code as needed, 
etc.

The challenge: throwing Ada into this mix without disrupting everyone's 
workflow to an unreasonable level. The obstacles that I see, and for which 
your ideas are most welcome:

1) Compiler. Debian/Ubuntu could be easy (Debian in particular): the Ada 
compiler is packaged and uses the system gcc. No idea about Fedora. The 
AdaCore GPL package brings in its own gcc/g++ versions, which have to be 
used to compile the C/C++ parts. Thus, it forces people to throw the stock 
system compiler in favor of the one I need. Not nice in my book. No 
workaround that I can see. Perhaps the .cgpr file offers a way? My early 
conclusion: use stock Ada compilers, doable with Debian, no-go in Mac?

2) Build framework: I read somewhere that gprbuild should be used instead. 
Obviously, I don't like being the newcomer and having to propose that cmake 
has to go in favor of an unknown tool. Also, not sure of how gprbuild would 
deal with C/c++ libraries that can be packaged differently depending on OS 
versions. Alternatively, I confess not having any idea how a few Ada sources 
could be integrated with cmake. Would very much like to know if this is 
doable. I read quite some time ago about difficulties (that were solved 
IIRC) faced by the PlPlot project with their Ada binding; I failed when I 
tried to replicate that, mostly because my very limited knowledge of cmake. 
Anyone here has done it?

3) Ada compiler bugs: given my personal experience, better to stick to 
"conservative" Ada coding. No synchronized interfaces or other fancy 
novelties. A minor sacrifice.

4) ???

Basically, I'd like to blend in some Ada as painlessly as possible, if 
possible at all...

Piotr Trojanek wrote:

> On Apr 20, 12:39 pm, "Alex R. Mosteo" <alejan...@mosteo.invalid>
> wrote:
>> Hello,
>>
>> I'm a big supporter of Ada, but I'm the only person that I know that uses
>> it in my work environment (mobile robotics research). Everyone is using
>> either C, C++, python or java.
>>
>> I ceased looking into other languages because I am so comfortable with
>> Ada. I fear I may have missed some interesting boat.
>>
>> Do you know of other languages worth to look at (i.e. that will make an
>> Ada programmer somewhat happy), that are at least as "popular" as Ada,
>> besides these ones mentioned above?
> 
> Alex, I am in a kind of similar position - in my robotics team all the
> people
> are using C++. I have simply decided not to bother and do my work with
> Ada.

< This was written before the scenario above: >

I do that when it's my own code, that most likely nobody will touch. But it 
feels rude to impose an unknown (for the rest) language on a group of people 
which are not my subordinates (some might say that I would be doing them a 
favor ;-)). It's also a hard decision if you'd like to attract contributors 
in an open source project (which is the case for the one that I'm just 
starting).

I guess a good chance is to keep using Ada in "boundary" things that may 
make people exposed to Ada without having to "fight" it head-on. The 
interested ones can go further.

> 
> There are a lot of programming languages around and people use ALL of
> them
> to program their robots. Please take a look at the list of languages,
> which
> you can use for Lego NXT programming (Ada is also there!):
> http://en.wikipedia.org/wiki/Lego_Mindstorms_NXT#Programming
> 
> The question is what is your focus in a robotics research? If it is a
> RT control,
> than I see no point in not using Ada. If you are interested in AI,
> then Lisp is
> probably the way to go. It has been shown, that virtually any language
> can be
> used for a robotic research. I think you should simply pick a one,
> which allows
> you to focus on what is your primary goal.

I'm actually into planning/task allocation (although I have to use robot 
hardware, but using non-RT libraries like player, ROS or YARP). Also lots of 
networking. So in my case Ada is a better choice than Lisp, I think.

Alex.

> 
> --
> Piotr

Re: C++/cmake project, injecting Ada...

[Ludovic Brenta]

"Alex R. Mosteo" <alejandro@mosteo.invalid> writes:
> As I was writing this reply, I realized that focusing in a particular
> case at hand may provide better food for though and more precise
> solutions. So I have renamed the thread accordingly. Now, the scenario
> is like this:
>
> A fairly conventional open source project for doing some high-level
> simulations. C++ based, using cmake for building. Developers using an
> assortment of linux OSses: Ubuntu 10.04, 10.10, Fedora (last 2 or 3
> versions). Eventually, MacOSX could enter the fray. Remember, this is
> loosely cooperative research, nobody mandates the devel platform to a
> particularly tight version.
>
> The project uses several libraries: boost, YARP, opencv, etc, which
> are located by cmake. Somehow all this compiles in such varied
> environments.
>
> Now, let's suppose the contributions are fairly self-contained (e.g.,
> providing a particular class instance for an abstract base class). I
> know how to interface Ada and C/C++, don't mind to write glue code as
> needed, etc.
>
> The challenge: throwing Ada into this mix without disrupting
> everyone's workflow to an unreasonable level. The obstacles that I
> see, and for which your ideas are most welcome:

My first reaction is: don't do it.  The chances of failure are very
high, if only because of the diversity of platforms and the absence of a
"stock" Ada compiler on each.  The integration between Ada and cmake is
another potential hurdle.  Any failure will be promptly blamed on "your
non-standard language and tools" even though cmake is just as
"non-standard" as gprbuild; you'll end up being the only person in
charge of debugging everyone else's build problems.

It should be possible, however, to create separate add-ons in Ada.
Compile these add-ons independently from the main project, using
gnatmake or gprmake; do not require any developer not interested in your
add-ons to change anything to their toolchain.  The interfacing between
the add-ons and the main project is the crux of the matter; if you could
do it via some sort of interprocess communications, you would be able to
isolate your add-ons from the main project very well.  Otherwise,
provide a shared library that the main project can dlopen() and call
(use pragma Export to expose the API to the shared library).

A last resort perhaps: fork the open source project; do anything you
like in Ada, replace cmake with gprbuild or whatever.  Merge from the
open source project from time to time.  Care only about your platform;
if anyone is interested in building on another, provide assistance as
needed.  Publish your sources in a separate branch in their version
control system if you can (and if the VCS supports merges well, i.e. it
is not CVS or subversion...) or in a monotone database if you must.

-- 
Ludovic Brenta.

Re: C++/cmake project, injecting Ada...

[Alex R. Mosteo]

Ludovic Brenta wrote:

> "Alex R. Mosteo" <alejandro@mosteo.invalid> writes:
>> As I was writing this reply, I realized that focusing in a particular
>> case at hand may provide better food for though and more precise
>> solutions. So I have renamed the thread accordingly. Now, the scenario
>> is like this:
>>
>> A fairly conventional open source project for doing some high-level
>> simulations. C++ based, using cmake for building. Developers using an
>> assortment of linux OSses: Ubuntu 10.04, 10.10, Fedora (last 2 or 3
>> versions). Eventually, MacOSX could enter the fray. Remember, this is
>> loosely cooperative research, nobody mandates the devel platform to a
>> particularly tight version.
>>
>> The project uses several libraries: boost, YARP, opencv, etc, which
>> are located by cmake. Somehow all this compiles in such varied
>> environments.
>>
>> Now, let's suppose the contributions are fairly self-contained (e.g.,
>> providing a particular class instance for an abstract base class). I
>> know how to interface Ada and C/C++, don't mind to write glue code as
>> needed, etc.
>>
>> The challenge: throwing Ada into this mix without disrupting
>> everyone's workflow to an unreasonable level. The obstacles that I
>> see, and for which your ideas are most welcome:
> 
> My first reaction is: don't do it.  The chances of failure are very
> high, if only because of the diversity of platforms and the absence of a
> "stock" Ada compiler on each.  The integration between Ada and cmake is
> another potential hurdle.  Any failure will be promptly blamed on "your
> non-standard language and tools" even though cmake is just as
> "non-standard" as gprbuild; you'll end up being the only person in
> charge of debugging everyone else's build problems.

I see my fears are then reasonable, because that's how I feel too. It's not 
bad enough that few people know/use Ada, one is further excluded by things 
like this.

> It should be possible, however, to create separate add-ons in Ada.
> Compile these add-ons independently from the main project, using
> gnatmake or gprmake; do not require any developer not interested in your
> add-ons to change anything to their toolchain.  The interfacing between
> the add-ons and the main project is the crux of the matter; if you could
> do it via some sort of interprocess communications, you would be able to
> isolate your add-ons from the main project very well.  Otherwise,
> provide a shared library that the main project can dlopen() and call
> (use pragma Export to expose the API to the shared library).

This is an interesting possibility, and in fact IPC in this particular lab 
is many times done via YARP (tell about killing flies with cannons), 
meaning, if you don't know it, that processes are totally independent, 
communicating over sockets. So this is a possibility to keep in mind. Also 
the dlopen possibility is interesting, although a bit less attractive 
because dlopen shenaningans are not used right now (I suspect). Still worth 
to keep in mind, thanks. 

> A last resort perhaps: fork the open source project; do anything you
> like in Ada, replace cmake with gprbuild or whatever.  Merge from the
> open source project from time to time.  Care only about your platform;
> if anyone is interested in building on another, provide assistance as
> needed.  Publish your sources in a separate branch in their version
> control system if you can (and if the VCS supports merges well, i.e. it
> is not CVS or subversion...) or in a monotone database if you must.

Last resort indeed :) Although interesting from the POV of seeing how 
gprbuild would deal with a large complex cmake project. Perhaps worth it 
(once) only for that part of the experience.

Thank for your opinions, much valued because I know you're deeply 
experienced into the Debian/open source community. I see that basically my 
understanding of the situation was on target :(

Going again over it, I still think that perhaps exploring the cmake+Ada way 
is the more promising in terms of achieving something with relative ease? I 
see two venues here:

1) Just drop all advantages of gprbuild dependency management, and compile 
each Ada file to object code. Problems I see: what happens with gnatbind?

2) Somehow massage cmake into using a single call to gprbuild, and normally 
use it to compile the Ada part into a library. I guess this library can be 
easily linked with the rest of C/C++ compiled sources, since I have seen 
cmake projects which build many intermediate libraries. Since there's only 
one interaction between cmake and Ada (launching gprbuild), perhaps the 
problem of debugging everyone's else builds would be a reasonable burden; 
especially if the Ada parts are disabled by default and only compiled by 
people interested in them.

Alex.

Re: C++/cmake project, injecting Ada...

[stefan-lucks]

On Fri, 29 Apr 2011, Alex R. Mosteo wrote:

> 2) Somehow massage cmake into using a single call to gprbuild, and normally 
> use it to compile the Ada part into a library. 

If your sub-project is strictly Ada only, then perhaps you could massage 
cmake into using a single call of gnatmake. 

  Disadvantage: less flexibility than with gprbuild 

  Advantage: you don't need to maintain any project-file



-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: C++/cmake project, injecting Ada...

[Alejandro R. Mosteo]

On Friday, April 29, 2011 at 10:17:18 AM UTC+2, Alex R. Mosteo wrote:

> >> The challenge: throwing Ada into this mix without disrupting
> >> everyone's workflow to an unreasonable level.

> 2) Somehow massage cmake into using a single call to gprbuild, and normally 
> use it to compile the Ada part into a library. I guess this library can be 
> easily linked with the rest of C/C++ compiled sources, since I have seen 
> cmake projects which build many intermediate libraries. Since there's only 
> one interaction between cmake and Ada (launching gprbuild), perhaps the 
> problem of debugging everyone's else builds would be a reasonable burden; 
> especially if the Ada parts are disabled by default and only compiled by 
> people interested in them.

Sorry for resurrecting this 4-year old thread, but yesterday I gave a new shot at this and I think things have changed for the better with CMake.

To summarize, the challenge was to contribute Ada code to a C/C++ project using the CMake build environment and with minimal disruption for all parts involved.

What I've found is that CMake 2.8 adds an "external project" build command that enables calling gprbuild with ease. If you're in a debian-based distro which packages gnat, the other contributors that are interested in compiling your Ada part just need to install a package. To me that qualifies as minimal disruption :)

Advantages to each side:

1) The Ada contributor can keep using the wonderful Ada built-in dependency management. If he wants to share a library, an appropriately crafted gpr file will expose the code to the C/C++ side in the usual way. If the result is a mere executable things are even simpler.

2) The C/C++ side just keeps working as usual, enabling the Ada parts if needed.

I've prepared a couple of CMake helper macros that give the basic idea and can be enhanced for more involved actions (like installing the Ada library, etc). It is here [1]. Basically, you issue an add_ada_library() and that's it for the CMake side.

Incidentally, I saw another effort to integrate gnat and CMake, but it seems it is going the full CMake way: adding Ada support so source files are recognized and compiled individually and so on. I'm not sure how the binding stage is managed there, but for interested people here it is too [2].

[1] https://github.com/mosteo/ada4cmake
[2] https://github.com/offa/cmake-ada

Re: C++/cmake project, injecting Ada... (was Re: If not Ada, what else...)

[Dirk Heinrichs]

Alex R. Mosteo wrote:

> 2) Build framework: I read somewhere that gprbuild should be used instead.
> Obviously, I don't like being the newcomer and having to propose that
> cmake has to go in favor of an unknown tool. Also, not sure of how
> gprbuild would deal with C/c++ libraries that can be packaged differently
> depending on OS versions. Alternatively, I confess not having any idea how
> a few Ada sources could be integrated with cmake. Would very much like to
> know if this is doable.

I use omake (from the Mojave project) to build my Ada stuff, so it is 
doable. Just read chapter 2 (The GNAT Compilation Model) of the GNAT User's 
Guide. This should tell you all you need to compile your Ada sources with 
any build tool you want. The reason for using omake? Well, it's not GNU 
make, thus it comes with dependency tracking, build command checksumming, 
built-in build cache, background execution with source file monitoring, etc.

Bye...

	Dirk

If not Ada, what else...

[luvhed]

C/C++ with MIRSA rules enabled? At least you will get some of the checks that Ada performs for you.

H.

Re: If not Ada, what else...

[Paul Rubin]

luvhed@gmail.com writes:
> C/C++ with MIRSA rules enabled? At least you will get some of the
> checks that Ada performs for you.

You still would face way too many trip-ups and pitfalls.  

People who think they know C well enough to avoid those pitfalls should
look at:

http://www.cl.cam.ac.uk/~pes20/cerberus/notes50-2015-05-24-survey-discussion.html

There is also the famous "C++ FQA" (frequently questioned answers).

Re: If not Ada, what else...

[Rod Kay]

... gardening ?

(In response to subject line.)

Re: If not Ada, what else...

[jm.tarrasa]

nim, at http://nim-lang.org/index.html

There are things I don't like. Nevertheless, It's an interesting language. It looks that the author has experience in languages.  And it looks that has an active and growing community.

Hardtyped, generics with much more semantic information than Ada, concurrency, closures, iterators, named loops, positional or named parameters, lists, hash arrays, sets, array slices, overloaded operators, OOP, exptions tye except and try finally.
The compiler (initially was written in Pascal) compiles to C and then to binary.

As I said, there are things I don't like:
* Indentation is meaningful, marks blocks, like python
* Identifiers are case sensitive... only the first letter. !! astonishing
* Arrays are declared in a weird way, base type looks like an index:
  array [1..20,int] translates to Ada array[1..20] of integer. !! weird.

Nevertheless it's interesting and has interesting features. Not my language but interesting. 

Re: If not Ada, what else...

[Anh Vo]

On Wednesday, July 8, 2015 at 11:11:13 AM UTC-7, jm.ta...@gmail.com wrote:
> nim, at http://nim-lang.org/index.html
>   array [1..20,int] translates to Ada array[1..20] of integer. !! weird.

Ada does not this syntax. Indeed, you hands will be slapped if you attempt to compile it.

Anh Vo

Re: If not Ada, what else...

[jm.tarrasa]

> Ada does not this syntax. Indeed, you hands will be slapped if you attempt to compile it.
> 

Uuups Sorry. :-P

Yeah, that's Pascal, that's what I'm doing now.

Re: If not Ada, what else...

[David Botton]

> nim

The closest contender to Ada is D (and in many areas is ahead of Ada, but in key areas lacking and not likely to get fixed), not Nim (or Rust, since comes up often in same breath) by a long shot. Also, for most projects, if you are going to use a Python like language may as well just use python. If compiled Python needed use cython or Nuitka.

David Botton

Re: If not Ada, what else...

[jm.tarrasa]

El jueves, 9 de julio de 2015, 0:15:42 (UTC+2), David Botton  escribió:
> > nim
> 
> The closest contender to Ada is D (and in many areas is ahead of Ada, but in key areas lacking and not likely to get fixed),

That's an interesting topic. I don't know D (I have prejudices against languages that use curly brackets). In what areas is ahead Ada and in what key areas is crippled?

>not Nim (or Rust, since comes up often in same breath) by a long shot. Also, for most projects, 

Well, Nim is still immature and a little buggy. By the way, Rust author has abandoned Rust and turned into Nim. An .

> if you are going to use a Python like language may as well just use python. If compiled Python needed use cython or Nuitka.

Well, Nim is not a Python like language at all. It uses indentation to mark blocks instead of curly brackets or begin..end.

Anyway, I don't see my self programming Nim, I'm not supporting it. I was just answering the post about other languages, but leaving the mainstream.

Re: If not Ada, what else...

[G.B.]

On 09.07.15 09:28, jm.tarrasa@gmail.com wrote:
> El jueves, 9 de julio de 2015, 0:15:42 (UTC+2), David Botton  escribió:
>>> nim
>>
>> The closest contender to Ada is D (and in many areas is ahead of Ada, but in key areas lacking and not likely to get fixed),
>
> That's an interesting topic. I don't know D (I have prejudices against languages that use curly brackets). In what areas is ahead Ada and in what key areas is crippled?
>
>> not Nim (or Rust, since comes up often in same breath) by a long shot. Also, for most projects,
>
> Well, Nim is still immature and a little buggy. By the way, Rust author has abandoned Rust and turned into Nim. An .

Is Nim one of those languages that its authors develop
because they like developing programming languages,
and be it based mainly on personal acquaintance with
some language theory and a few translation techniques?

If feels like it is the 1970s again, people succeeding
in finding someone who pays them for writing yet another
separate programming language. ("Ah! Goal getters...!")
Industry not co-ordinating its own needs, just waiting
to be presented with something that has "won"...

After skimming the Nim docs, the concepts I see  make me think:
What's unique about it? Something that would let industry
switch from competitive offerings of "the same"?

Re: If not Ada, what else...

[Dennis Lee Bieber]

On Thu, 9 Jul 2015 00:28:53 -0700 (PDT), jm.tarrasa@gmail.com declaimed the
following:


>Well, Nim is not a Python like language at all. It uses indentation to mark blocks instead of curly brackets or begin..end.
>
	Pardon?

	Looking at the nim main page, the code samples shown are practically
python with a few added keywords ("let" -- shades of original K&K BASIC,
although nim is using that to define a write-once name [claims to define an
immutable object, but if the name itself can't be reused?], named "block",
etc.)
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: If not Ada, what else...

[David Botton]

> That's an interesting topic. I don't know D (I have prejudices against languages that use curly brackets). In what areas is ahead Ada and in what key areas is crippled?

D is lacking - #1 no way to switch braces to begin and end :), the ability to create new ranged types no via OO. It does have a concept of types above C and C++ but no where near Ada's. As an extension of that it can only create 0 indexed arrays, but you can use enumerations, so some support. There are other issues but mostly revolve around lacks in terms of defining types and as a direct result compile time checks related to those lacks. It's way ahead of C/C++, Java, etc. and there are ways to create types in OO but then all checks become dynamic.

D is ahead - 3 true open source (no virused runtimes) implementations (dmd, lcd2, gdc), phobos (D's runtime) is incredibly rich, functional, parallel computing, concurrency, etc. Ada's annexes are primitive in comparison. Easier interfacing with C. Community support, resources, etc. etc. dub - package management and build system, etc. built in unit testing, better syntax for pre and post conditions, and tons more.

A few tweaks to D's type system and not sure Ada would have anything all that unique or beneficial at all.

> Well, Nim is still immature and a little buggy. By the way, Rust author has abandoned Rust and turned into Nim. An .

Goes to show you both languages no more than a fad.

The author of Rust went to nim because of C output since he is working on an OS. BTW, D has already successfully been used for creating OSes, etc.

> Well, Nim is not a Python like language at all.

Oh my, it was created to be a compilable Python from the start.....

David Botton

Re: If not Ada, what else...

[Bob Duff]

David Botton <david@botton.com> writes:

> D is lacking - #1 no way to switch braces to begin and end :),...

But (and I'm sure you know this), Ada doesn't merely use begin and end.
It uses (e.g.) if/else/end if and the like.

I don't find Pascal's begin/end syntax any better than C's curly braces;
begin/end contains the same information as {}, is more verbose for
no reason, and suffers from the dangling else problem, just like C.
"if/else/end if" is superior to both -- you can tell what "end if"
is the "end" of.  And no dangling else.

> D is ahead ...

Garbage collection (if I recall correctly).

- Bob

Re: If not Ada, what else...

[David Botton]

> But (and I'm sure you know this), Ada doesn't merely use begin and end.
> It uses (e.g.) if/else/end if and the like.

Of course, just a preference and half joking. I think the main reason I haven't jumped in to D is the lack of Ada's type system. I also really like having spec and body.

> D is ahead ...
> 
> Garbage collection (if I recall correctly).

Yes, you can also control in code what is or is not under the GC's eye. There are numerous other features I like, such as being able to mark safety levels of code, of course the normalized use of a class for defining objects, etc.

D (or more specifically D2) was a smart move, take the best of the past and remodel with out concern for breaking with that past. Unfortunately they didn't fully get the importance of static typing to the point of being able to set ranges, etc. I'm actually surprised considering the great work done on the rest of D, I consider it a major oversight and it seems there is little interest to fix it.

It would be nice for Ada to do a rethink.

David Botton

Re: If not Ada, what else...

[Paul Rubin]

David Botton <david@botton.com> writes:
> It would be nice for Ada to do a rethink.

Ada 2012 seems like a move in the right direction.

Re: If not Ada, what else...

[David Botton]

> Ada 2012 seems like a move in the right direction.

You could say that about every version even the first. It is unlikely that there will be a rethink from the top down (not enough financial incentive since no one pursuing new markets), but perhaps if there is ever a new front end effort it can be done from the bottom up.

David Botton

Re: If not Ada, what else...

[Paul Rubin]

David Botton <david@botton.com> writes:
> You could say that about every version even the first. 

Well, the big win of Ada 2012 is SPARK integration, it seems to me.
There's nothing like that for D.  I looked at the Wikipedia page about D
and didn't see much to recommend it over Ada, except garbage collection
which puts it in a different class of languages.  For desktop and server
applications I like lightweight concurrency, garbage collection,
functional idioms, and maybe even dynamic types, but for low level
systems code Ada is still looking good to me.

Re: If not Ada, what else...

[David Botton]

> Well, the big win of Ada 2012 is SPARK integration, it seems to me.

Adding Pre/Post, etc. is more like Eiffel integration. Not that big a deal to be officially part of the language itself, but not unwelcome.

If you manage your types well in Ada you need far less of these "extras". More emphasis on Ada's real strength in typing is a smarter investment in the language and leaving proving tools outside the language. I certainly hope things don't go further than they already have in this direction.

From a marketing perspective  AdaCore made a mistake reversing the original direction of SPARK to distance itself as far from Ada as possible. The Ada name is burnt in the US and it was good marketing to create distance. They should have just changed their name to CodeCore and marketed their multiple language products all focused on "correct code".

> There's nothing like that for D.

Actually there is and has been there for some time. Pre/Post, invariants, etc. and with a syntax that is far cleaner.

>  I looked at the Wikipedia page about D

Better to look at dlang.org and if you are comfortable directly with the language specs  and as per another post to look at Phobos (the runt time) which puts D way ahead in most areas. (Of course D is also truly open source no runtime license games)

The feature of Ada (and is a big one) that places Ada ahead of D (and other languages) is the type system of Ada that has been in place since Ada 83. Since then Ada has suffered from feature creep issues due to reluctance to throw away the dross and accept more incompatibilities between versions.

> and didn't see much to recommend it over Ada, except garbage collection

The funny thing is that I don't consider that a big deal at all. I enjoy Ada in particular because of the ways I get around needing to have a GC because of it (interestingly enough those features like nested procedures are part of D too).

> which puts it in a different class of languages.

That is one of the nice things about D, that it doesn't put it in a different class of languages given the ability to avoid use of the GC if you choose and when you choose.

BTW, Ada has always considered a D like implementation of a GC, just that only 3 implementations of Ada, that I know of, ever did it. Does that put Ada in a different category now too?

In fact D and Ada are _exactly_ in the same space, designed to be systems languages and general purpose. (Actually there are a number of device drivers written in D at least 2 OSes, etc.) Ada unlike SPARK is not a niche language, just being forced in to one.

My point in bringing up D, a language that is almost there, is that the extreme niche thinking that is towing Ada around has harmed Ada acceptance and is creating road blocks for Ada's long term future.

If D tweaked its type system a bit not sure Ada would make much sense for anyone other than long term old projects.

>  For desktop and server
> applications I like lightweight concurrency, garbage collection,
> functional idioms, and maybe even dynamic types, but for low level
> systems code Ada is still looking good to me.

I am not advocating D, nor asking the D people to consider improving their type system, I'm advocating community efforts to improve Ada's general purpose use and avoid it further sinking in to extreme niche use that will make Ada in to SPARK or another niche language of little use outside that niche.

David Botton

Re: If not Ada, what else...

[David Botton]

To be fair, subtype predicates (and any work in the direction of tighter type contracts) are a clear step in the direction I was referring to as real Ada worthy additions.

I have an agenda of only three things in connection to Ada 1) Stopping Ada from being closed off to general purpose use by those that want it to become a completely niche language 2) To bolster and advocate use and community support of non-GPL virused runtime versions of GNAT to offset (as best as possible) the damage caused by license games from small minded thinking 3) Encourage people in AdaCore's niche market to hire AdaCore for their top notch support services. (There is no conflict here, good engineers often make poor businessmen.)

My reason for the agenda is simple, I enjoy using Ada and appreciate its benefits to facilitate correct and readable code in most project scenarios and wish I could be freely advocating its use and pushing it more, but hard to convince some one to get in to bed with GPL runtimes on the only compiler around without "IP" and license scares being tossed at it to discourage use.

David Botton

Re: If not Ada, what else...

[Bob Duff]

David Botton <david@botton.com> writes:

> To be fair, subtype predicates (and any work in the direction of tighter type
> contracts) are a clear step in the direction I was referring to as real Ada
> worthy additions.

Subtype predicates are my favorite feature added in Ada 2012.
I did much of the design work on them.  I'd prefer they be
called "invariants", though -- but that's a different feature.

I did not agree with the split into Static_Predicate and
Dynamic_Predicate.  (And GNAT has Predicate as an implementation
defined feature -- that's what I use in my code.)

- Bob

Re: If not Ada, what else...

[Paul Rubin]

David Botton <david@botton.com> writes:
>> Well, the big win of Ada 2012 is SPARK integration, it seems to me.
> Adding Pre/Post, etc. is more like Eiffel integration. Not that big a
> deal to be officially part of the language itself, but not unwelcome.

The old SPARK overloaded Ada's comment syntax, which has always felt
crufty to me.  Similar things happen in other languages and I've never
been enamored of it.  E.g. Doxygen, Haddock, etc.  It's ok if an
experimental tool like Liquid Haskell works by munching code comments,
but I'd want it to become part of the official language when it grows up.

> If you manage your types well in Ada you need far less of these
> "extras". More emphasis on Ada's real strength in typing is a smarter
> investment in the language and leaving proving tools outside the
> language. I certainly hope things don't go further than they already
> have in this direction.

I remember being disappointed that (unless I missed something) there
doesn't seem to be a way to put assertions in the middle of a function
body and have Spark check them statically.  Am I mistaken about that?  I
hope they add it.

> From a marketing perspective AdaCore made a mistake reversing the
> original direction of SPARK to distance itself as far from Ada as
> possible. The Ada name is burnt in the US and it was good marketing to
> create distance. They should have just changed their name to CodeCore
> and marketed their multiple language products all focused on "correct
> code".

I think Ada is somewhat rehabilitated now, partly because of Ada 2012.
I was aware of SPARK before that, when it was a separate expensive tool
from a specialty vendor.  Without it, Ada was just a clumsy and
bureaucratic Pascal-like language.  I got much more interested in using
it when it became part of the GNAT collection.

>> There's nothing like that for D.
> Actually there is and has been there for some time. Pre/Post,
> invariants, etc. and with a syntax that is far cleaner.

Are there tools like SPARK for statically verifying the D annotations?

> The feature of Ada (and is a big one) that places Ada ahead of D (and
> other languages) is the type system of Ada that has been in place
> since Ada 83. 

I may be missing something here, but I don't see where Ada's type system
is that much better than C++'s, and it's way behind Haskell's.  Ranged
types are useful but you can implement them (with runtime checks) in
other languages.  They're interesting in Ada 2012 mostly because of the
possibility of checking them statically with Spark.

Another big advantage of Ada is much more precisely defined semantics
than C++'s.  To quote another poster, the Ada community has put colossal
effort into certifying compilers and solidifying the standard.  I don't
know how D fares in this comparison.

> The funny thing is that I don't consider that a big deal at all. I
> enjoy Ada in particular because of the ways I get around needing to
> have a GC because of it

There are generally ways to program without a GC, but if your
application constraints allow you to use one, it can make your code
simpler and more maintainable, as well as speeding development.  Are you
programming to solve puzzles or are you trying to get a task
accomplished?  If you like puzzles, try Forth ;-).

> BTW, Ada has always considered a D like implementation of a GC, just
> that only 3 implementations of Ada, that I know of, ever did it. Does
> that put Ada in a different category now too?

Ada with a GC would be interesting and in a different category but it
would lose its suitability for constrained, realtime environments.  At
that point it's competing with Java (and Java's offspring like Scala).

> In fact D and Ada are _exactly_ in the same space, designed to be
> systems languages and general purpose. (Actually there are a number of
> device drivers written in D at least 2 OSes, etc.) Ada unlike SPARK is
> not a niche language, just being forced in to one.

I guess in my world, any non-GC'd language is niche (it's used for
either small embedded environments, high-assurance realtime, or
maximizing performance like for numerics or big network servers).  For
the general purpose middle ground, current trends are toward GC'd
languages that support functional-programming idioms, which Ada isn't so
hot at.

> I am not advocating D, nor asking the D people to consider improving
> their type system, I'm advocating community efforts to improve Ada's
> general purpose use and avoid it further sinking in to extreme niche
> use that will make Ada in to SPARK or another niche language of little
> use outside that niche.

I think Ada is an attractive choice for lots of things that people
(including me) are currently doing with C and C++, but I consider those
to be niche languages today too (unlike 20 years ago).

Re: If not Ada, what else...

[David Botton]

> I think Ada is somewhat rehabilitated now, partly because of Ada 2012.
> I was aware of SPARK before that, when it was a separate expensive tool
> from a specialty vendor.  Without it, Ada was just a clumsy and
> bureaucratic Pascal-like language.  I got much more interested in using
> it when it became part of the GNAT collection.

So now an expensive vendor tool is still an expensive vendor tool and SPARK is thought to be an extension of a clumsy bureaucratic Pascal like language......

Sounds like things got worse.

> There's nothing like that for D.

Nope. Nor does Ada. SPARK does.

> Are there tools like SPARK for statically verifying the D annotations?

We are talking about Ada not SPARK. If you like SPARK and it fits your needs great.

> I may be missing something here, but I don't see where Ada's type system
> is that much better than C++'s,

So in C++ you can create new incompatible types with various ranges, use them for array indexes, true enums? 

> and it's way behind Haskell's.

Different, but also something to investigate for Ada.

>  Ranged
> types are useful but you can implement them (with runtime checks) in
> other languages.

That is what you don't understand, Ada is about compile time checks and that comes with contacts. Contracts on the types, contracts on the interfaces.


>  They're interesting in Ada 2012 mostly because of the
> possibility of checking them statically with Spark.

And why mostly of little interest to me.

> Another big advantage of Ada is much more precisely defined semantics
> than C++'s.  To quote another poster, the Ada community has put colossal
> effort into certifying compilers and solidifying the standard.

Well, once upon a time Ada compilers were certified. I don't believe AdaCore does that anymore. In the end of the day they are the only vendor and so they are the standard....


>  I don't
> know how D fares in this comparison.

Actually I'd say today D and Ada are again in the same boat.

 
> There are generally ways to program without a GC, but if your
> application constraints allow you to use one, it can make your code
> simpler and more maintainable, as well as speeding development.

And if you use Ada long enough you learn to use the Stack most of the time to accomplish the same thing and you don't get sloppy which tends to happen to GC dependent programmers.

> Are you
> programming to solve puzzles or are you trying to get a task
> accomplished?  If you like puzzles, try Forth ;-).

If you know your tools you use them, Ada is an excellent tool that helps mold your code as you go in to solving problems in reusable and reliable ways. It is why I use Ada for "hacking"

I've actually written software in Forth. It had its place in the days of tight memory constraints.

> Ada with a GC would be interesting and in a different category but it
> would lose its suitability for constrained, realtime environments.  At
> that point it's competing with Java (and Java's offspring like Scala)

Ada does have a GC in some implementations as I pointed out. You are having trouble separating language from runtime environment. A GC in Ada or D is something you can choose to use.

BTW, I've never had the need but there are ways to use a GC even the current GNAT's on most platforms.

A GC doesn't change the language unless the language requires its use. Neither Ada or D does so.


> I guess in my world, any non-GC'd language is niche (it's used for
> either small embedded environments, high-assurance realtime, or
> maximizing performance like for numerics or big network servers).  For
> the general purpose middle ground, current trends are toward GC'd
> languages that support functional-programming idioms, which Ada isn't so
> hot at.

You can use D in that environment, although Ada is better at it. Repl clauses, etc. are also pluses.

> I think Ada is an attractive choice for lots of things that people
> (including me) are currently doing with C and C++, but I consider those
> to be niche languages today too (unlike 20 years ago).

No still general purpose. You need to look at the language itself to make that determination not just how it is being used currently.

C and C++ are still heavily used in general use cases, from embedded to UI and Game Dev, etc.

If anything C#, Python, Java are more niche, just their niche is where the vast majority of programs and programmers are. You would be a fool to use any of the three in anything critical (safety, time, etc.)

Even Haskell, OCAML, etc. are fairly niche. All he scripting languages are niche.

Ada, D, C, C++ are all geared for full range dev across the entire spectrum. Ada due to external issues in tool and compiler availability is the more limited currently, but almost as broad.

David Botton

Re: If not Ada, what else...

[Patrick Noffke]

On Friday, July 10, 2015 at 2:10:44 PM UTC-5, David Botton wrote:
> > I may be missing something here, but I don't see where Ada's type system
> > is that much better than C++'s,
> 
> So in C++ you can create new incompatible types with various ranges, use them for array indexes, true enums? 
> 

In C++11 you have enum class which makes an enum its own type.  You can still cast it to the class type, but you can't willy-nilly use it as an int as with the old-style enum.

This generates an error:

    enum class Junk : int
    {
        One, Two, Three
    };

    int a = Junk::One; // error:  cannot convert to int

Where this is allowed:

    int a = (int) Junk::One;

But there's nothing to prevent you from using the old style.  Even -Wold-style-cast doesn't generate a warning for this:

    enum Junk
    {
        One, Two, Three
    };

    int a = One;

(I guess because it's not technically a C cast -- enum really is just an int.)

I'm curious -- how would you create incompatible types with different ranges in C++?  AFAIK the language itself or the standard library don't provide that.

Pat

Re: If not Ada, what else...

[Brian Drummond]

On Fri, 10 Jul 2015 12:43:55 -0700, Patrick Noffke wrote:

> On Friday, July 10, 2015 at 2:10:44 PM UTC-5, David Botton wrote:
>> > I may be missing something here, but I don't see where Ada's type
>> > system is that much better than C++'s,
>> 
>> So in C++ you can create new incompatible types with various ranges,
>> use them for array indexes, true enums?
>> 
>> 
> In C++11 you have enum class which makes an enum its own type.  You can
> still cast it to the class type, but you can't willy-nilly use it as an
> int as with the old-style enum.
> 
> This generates an error:
> 
>     enum class Junk : int {
>         One, Two, Three
>     };
> 
>     int a = Junk::One; // error:  cannot convert to int
> 
> Where this is allowed:
> 
>     int a = (int) Junk::One;

And you can loop over the enum range (without explicitly naming its first 
and last tokens), and index arrays with them, etc, right?

-- Brian

Re: If not Ada, what else...

[Björn Lundin]

On 2015-07-11 12:46, Brian Drummond wrote:
> On Fri, 10 Jul 2015 12:43:55 -0700, Patrick Noffke wrote:
> 
>> On Friday, July 10, 2015 at 2:10:44 PM UTC-5, David Botton wrote:
>>>> I may be missing something here, but I don't see where Ada's type
>>>> system is that much better than C++'s,

> And you can loop over the enum range (without explicitly naming its first 
> and last tokens), and index arrays with them, etc, right?
> 

And also use them is case/switch statements
where missing values generates compiler errors ?

as in

procedure junk1 is
  type Junk_Type is (One, Two, Three);
  Junk  : Junk_Type := Junk_Type'Last;
begin
  case Junk is
    when One => null;
    when Two => null;
  end case;
end Junk1;


gcc -c -x ada junk1.ada
junk1.ada:10:03: missing case value: "three"
gnatmake: "junk1.ada" compilation error

--
Björn

Re: If not Ada, what else...

[Georg Bauhaus]

On 11.07.15 12:59, Björn Lundin wrote:
> On 2015-07-11 12:46, Brian Drummond wrote:
>> On Fri, 10 Jul 2015 12:43:55 -0700, Patrick Noffke wrote:
>>
>>> On Friday, July 10, 2015 at 2:10:44 PM UTC-5, David Botton wrote:
>>>>> I may be missing something here, but I don't see where Ada's type
>>>>> system is that much better than C++'s,
>
>> And you can loop over the enum range (without explicitly naming its first
>> and last tokens), and index arrays with them, etc, right?
>>
>
> And also use them is case/switch statements
> where missing values generates compiler errors ?

Yes. <tongue-in-cheeck>Albeit, without standards bureaucracy!</>

int main()
{
   enum junk_t { One, Two, Three };
   enum junk_t junk;
   
   switch (junk) {
   case One: break;
   case Two: break;
   }
   return 0;
}

clang -Werror main.m
main.m:6:11: error: enumeration value 'Three' not handled in switch
       [-Werror,-Wswitch]
   switch (junk) {
           ^
1 error generated.

The others have learned from our No-No language!

Re: If not Ada, what else...

[Björn Lundin]

On 2015-07-11 15:41, Georg Bauhaus wrote:
> 
> Yes. <tongue-in-cheeck>Albeit, without standards bureaucracy!</>
..
> clang -Werror main.m
> main.m:6:11: error: enumeration value 'Three' not handled in switch
>       [-Werror,-Wswitch]
>   switch (junk) {
>           ^
> 1 error generated.
> 
> The others have learned from our No-No language!

So it seems.
But does -Werror with clang mean 'turn warnings to errors'?

if so,
what if this switch is not used?
Anyway, it is a fall in forward direction.

--
Björn

Re: If not Ada, what else...

[Patrick Noffke]

On Saturday, July 11, 2015 at 5:48:13 AM UTC-5, Brian Drummond wrote:
> On Fri, 10 Jul 2015 12:43:55 -0700, Patrick Noffke wrote:
> 
> > On Friday, July 10, 2015 at 2:10:44 PM UTC-5, David Botton wrote:
> >> > I may be missing something here, but I don't see where Ada's type
> >> > system is that much better than C++'s,
> >> 
> >> So in C++ you can create new incompatible types with various ranges,
> >> use them for array indexes, true enums?
> >> 
> >> 
> > In C++11 you have enum class which makes an enum its own type.  You can
> > still cast it to the class type, but you can't willy-nilly use it as an
> > int as with the old-style enum.
> > 
> > This generates an error:
> > 
> >     enum class Junk : int {
> >         One, Two, Three
> >     };
> > 
> >     int a = Junk::One; // error:  cannot convert to int
> > 
> > Where this is allowed:
> > 
> >     int a = (int) Junk::One;
> 
> And you can loop over the enum range (without explicitly naming its first 
> and last tokens), and index arrays with them, etc, right?
> 

Um, no.  Adding enum class was a baby step in the right direction.  I'm a bit surprised though that range-based for loops don't work over an enum class.  Seems there's interest in doing so:
http://stackoverflow.com/questions/8498300/allow-for-range-based-for-with-enum-classes

Pat

Re: If not Ada, what else...

[David Botton]

> Um, no.  Adding enum class was a baby step in the right direction.  I'm a bit surprised though that range-based for loops don't work over an enum class.  Seems there's interest in doing so:
> http://stackoverflow.com/questions/8498300/allow-for-range-based-for-with-enum-classes


What I don't understand is why the C++ communities doesn't just adopt D as a replacement and finish. While D is certainly not Ada it is for sure what C++ should be.

In both cases C++ and D, neither "got it" in terms of the importance of types and how they improve the overall contracts in all software development and increase its robustness in ways the current cruches they add can not.

There just is not imperative language outside Ada that has understood the types and compile type checks for types is the real magic for efficiently implemented robust software.

David Botton

Re: If not Ada, what else...

[Maciej Sobczak]

> What I don't understand is why the C++ communities doesn't just adopt D as a replacement and finish.

Becaue D is not different enough. For many programmers (me including), D is too similar to C++ to make the improvement credible.

This is a typical problem with any new technology that claims to be "better" at the same time trying to remain as similar to the old stuff as possible. The small space for actual improvement that results from such compromises is too little to justify the effort.

> While D is certainly not Ada it is for sure what C++ should be.

There is a contradiction in this statement, since it both shows the goal and at the same time suggests that it should not be met.

Considering the massive success that C++ achieved in its respective market niche, it is difficult to argue that C++ should be something else than it already is. And if you really need something else, just move to Ada. Half-assed solutions are only distractions.

> In both cases C++ and D, neither "got it" in terms of the importance of types

Considering the assumed constraint of backward compatibility with C, they got the importance of types very well. More complete support for OO and templates are strong features, making it difficult for Ada to compete in these areas.

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

Re: If not Ada, what else...

[Serge Robyns]

On Monday, 13 July 2015 16:16:11 UTC+2, David Botton  wrote:
> > Um, no.  Adding enum class was a baby step in the right direction.  I'm a bit surprised though that range-based for loops don't work over an enum class.  Seems there's interest in doing so:
> > http://stackoverflow.com/questions/8498300/allow-for-range-based-for-with-enum-classes
> 
> 
> What I don't understand is why the C++ communities doesn't just adopt D as a replacement and finish. While D is certainly not Ada it is for sure what C++ should be.
> 
> In both cases C++ and D, neither "got it" in terms of the importance of types and how they improve the overall contracts in all software development and increase its robustness in ways the current cruches they add can not.
> 
> There just is not imperative language outside Ada that has understood the types and compile type checks for types is the real magic for efficiently implemented robust software.
> 
> David Botton

Dear David,

I've been reading this thread with great attention, as I'm in the initial phase of a major project.  My interest for Ada is as old my return from HP where I used to program there in a special version of Pascal that was used to write the MPE-XL OS.  Since then only Ada fitted the bill of readable code and reliability on top of that. (I've been looking at modula back then initially.)

Now with this discussion regarding D and I even started looking at Go and I'm puzzled.  I've read there that some people consider D dead.  Moreover, I'm not sure I can use D on all the platform I'm aiming at.  In a nutshell I need an environment that helps me writing code right from inception (the range type example is one of these things I like in Ada), supports reliable concurrent programming, can read XML (without needing DOM), interface to Oracle and other RDBMS, and compile native code for Linux, AIX, Solaris and others ....

I'm not sure D fits the complete bill and believe Ada still exceeds.

Re: If not Ada, what else...

[David Botton]

> Since then only Ada fitted the bill of readable code and reliability on top of that. (I've been looking at modula back then initially.)

Agreed

> Now with this discussion regarding D and I even started looking at Go and I'm puzzled.

Go is Oberon with C syntax and some week concurrency features, not worthy of much time. Is also seriously broken for anything more than script size software.

>  I've read there that some people consider D dead. 

I was not advocating D, only pointing out the next best thing to Ada, but by wide margin. To be precise talking about D2, D is dead and was replaced by D2.

> Moreover, I'm not sure I can use D on all the platform I'm aiming at.

Then likely you can't use Ada on them either. D has 3 backend options, GCC, LLVM and its own. Ada only has GCC... In fact my complaint is that I can't use Ada on the most important mobile and desktop platforms because it is married to GCC.

>  In a nutshell I need an environment that helps me writing code right from inception (the range type example is one of these things I like in Ada), supports reliable concurrent programming, can read XML (without needing DOM), interface to Oracle and other RDBMS, and compile native code for Linux, AIX, Solaris and others ....
> I'm not sure D fits the complete bill and believe Ada still exceeds.

D actually does everything you listed just as well or better. Ada as a language is far stronger for sure (I am one of its biggest advocates), but Ada suffers from few bindings, foolish license games, much weaker standard runtime library, no package management system with automatic builds like dub (although Gnoga now has the start of one and will be in the next 1.2 release in the coming months), Ada has a much more limited set of targets, etc.

I could probably go on, but I'm an Ada advocate and right now doing what I can to fix the holes in Ada from the shortsighted lack of almost all investment in real R&D for Ada's environment by the few vendors it has had/has, mostly because the niche market they cater(ed) to are mostly hardware oriented with little need for "environment".

If you use Ada today it is mostly because of the language's strengths that were already in Ada 83 not because Ada (yet) offers a better or wider set of features to other languages and development environments (It simply does not, but could and should have especially given the age and amounts of money involved in the contracts of yesteryear).

David Botton

Re: If not Ada, what else...

[Anh Vo]

On Thursday, July 16, 2015 at 6:50:49 PM UTC-7, David Botton wrote:
> > Since then only Ada fitted the bill of readable code and reliability on top of that. (I've been looking at modula back then initially.)
> 
> Agreed
> 
> > Now with this discussion regarding D and I even started looking at Go and I'm puzzled.
> 
> Go is Oberon with C syntax and some week concurrency features, not worthy of much time. Is also seriously broken for anything more than script size software.
> 
> >  I've read there that some people consider D dead. 
> 
> I was not advocating D, only pointing out the next best thing to Ada, but by wide margin. To be precise talking about D2, D is dead and was replaced by D2.
> 
> > Moreover, I'm not sure I can use D on all the platform I'm aiming at.
> 
> Then likely you can't use Ada on them either. D has 3 backend options, GCC, LLVM and its own. Ada only has GCC... In fact my complaint is that I can't use Ada on the most important mobile and desktop platforms because it is married to GCC.
> 

I have to disagree with you on Ada marrying to GCC. You probably meant GNAT marrying  to GCC since GNAT is a tool, not a computer language.

Anh Vo

Re: If not Ada, what else...

[Serge Robyns]

On Friday, 17 July 2015 19:07:30 UTC+2, Anh Vo  wrote:

> 
> I have to disagree with you on Ada marrying to GCC. You probably meant GNAT marrying  to GCC since GNAT is a tool, not a computer language.
> 

What is a language without the tool to understand it.  The tool becomes an obstacle if it restricts you on what you want to achieve.  In my case, GNAT and GNATPRO could be the reason I'll stay with Ada from the "tool" perspective besides the language benefits.  However, I do join David on some of his points with regards to the language backwards compatibility becoming a hurdle (and not only for Ada, but also for C++).  I've also learned the painful way with the help of this group that Ada has failed at some places to be readable, such as a standalone tick mark (') and a few other particular idiosyncrasies.  I must say this is one of my deepest disappointments. And this is why I've been reading this thread with great attention.

I'll continue my prototype in Ada and re-evaluate my options before the code base has become to large to move.  I could return to the 'C' family languages if this will be the best option.

Re: If not Ada, what else...

[Anh Vo]

On Friday, July 17, 2015 at 2:29:00 PM UTC-7, Serge Robyns wrote:
> On Friday, 17 July 2015 19:07:30 UTC+2, Anh Vo  wrote:
> 
> > 
> > I have to disagree with you on Ada marrying to GCC. You probably meant GNAT marrying  to GCC since GNAT is a tool, not a computer language.
> > 
> 
> What is a language without the tool to understand it. >>

Tool such as compilers used to implement among other things syntactic and semantic checks. Again, It has nothing to do with GCC specifically.

Anh Vo

Re: If not Ada, what else...

[David Botton]

> I have to disagree with you on Ada marrying to GCC. You probably meant GNAT marrying  to GCC since GNAT is a tool, not a computer language.
> 
> Anh Vo

No, I meant Ada. GNAT = Ada since there is not likely to be another implementation of the language nor even an update of any compilers to the current or future standards.

There is more than enough talent in this community to produce a new community front end (and I actually am working on one, but I am not the right guy at all and not sure I plan on implementing the Ada standard if I end up doing it alone fully, for sure will change toss "tagged" out the window).

David Botton

Re: If not Ada, what else...

[Paul Rubin]

David Botton <david@botton.com> writes:
> No, I meant Ada. GNAT = Ada since there is not likely to be another
> implementation of the language nor even an update of any compilers to
> the current or future standards.

Are you serious, is GNAT really the only implementation of Ada 2012?

I see a huge list of Ada 95 implementations here:

  http://www.ada-auth.org/cpl/lists/CPLbase.html

And I figured that the updates only stopped because (per J-P. Rosen's
recent post) vendors aren't doing ACAA validations any more.

I know some of those vendors are still selling product but I don't know
that they've been updated for Ada 2012.  I don't see what's so difficult
about it if customers are asking for it--the changes are not that large.

Re: If not Ada, what else...

[Jeffrey R. Carter]

On 07/19/2015 09:20 AM, Paul Rubin wrote:
> 
> Are you serious, is GNAT really the only implementation of Ada 2012?

Yes, GNAT is, AFAIK, the only implementation of Ada 12. There have been no
announcements here of any other implementations. If you want portability among
compiler vendors, Ada 12 is not the way to go.

> I see a huge list of Ada 95 implementations here:
> 
>   http://www.ada-auth.org/cpl/lists/CPLbase.html

Not long after the publication of the 95 standard, all vendors had
implementations. A similar amount of time after the publication of the 07
standard, about half of the vendors had implementations (and many who didn't
still don't). Now, nearing 3 yrs after the publication of the 12 standard, only
1 vendor has an implementation.

-- 
Jeff Carter
"C's solution to this [variable-sized array parameters] has real
problems, and people who are complaining about safety definitely
have a point."
Dennis Ritchie
25

Re: If not Ada, what else...

[Paul Rubin]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
> Yes, GNAT is, AFAIK, the only implementation of Ada 12. There have
> been no announcements here of any other implementations.

Thanks, that is interesting.  How on earth did Ada 12 get through the
standardization process if none of the other compiler vendors were on
board?  Usually those committees have representatives from all the
involved companies, with everyone trying to get their feature in.

Re: If not Ada, what else...

[Tero Koskinen]

20.7.2015, 0:15, Paul Rubin kirjoitti:
> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
>> Yes, GNAT is, AFAIK, the only implementation of Ada 12. There have
>> been no announcements here of any other implementations.
>
> Thanks, that is interesting.  How on earth did Ada 12 get through the
> standardization process if none of the other compiler vendors were on
> board?  Usually those committees have representatives from all the
> involved companies, with everyone trying to get their feature in.
>

However, there are multiple Ada 2005 compilers.

Irvine ICCAda supports Ada 2005, ApexAda and ObjectAda from PTC(Atego) 
support Ada 2005, Janus/Ada supports one or two Ada 2005 features.

Also, I think RRSoftware (Janus/Ada) got some of their features to Ada 
2005&2012. (They just don't have enough manpower/time to implement all 
of Ada 2005/2012 as fast as others.)

Yours,
  Tero

Re: If not Ada, what else...

[Paul Rubin]

Tero Koskinen <tero.koskinen@iki.fi> writes:
> However, there are multiple Ada 2005 compilers.
> Irvine ICCAda supports Ada 2005, ApexAda and ObjectAda from PTC(Atego)
> support Ada 2005, Janus/Ada supports one or two Ada 2005 features.
> Also, I think RRSoftware (Janus/Ada) got some of their features to Ada
> 2005&2012. ...

Thanks.  I now wonder if Ada 2012 has gotten much uptake from the
traditional big users.  I would have thought so since it's a real
improvement over older versions, but I understand how critical-systems
users might be more technologically conservative than internet startups
for example.  Maybe they're all still using Ada 2005 or Ada 95 and plan
to stay with it.

Re: If not Ada, what else...

[Dennis Lee Bieber]

On Mon, 20 Jul 2015 10:31:05 -0700, Paul Rubin <no.email@nospam.invalid>
declaimed the following:

>Tero Koskinen <tero.koskinen@iki.fi> writes:
>> However, there are multiple Ada 2005 compilers.
>> Irvine ICCAda supports Ada 2005, ApexAda and ObjectAda from PTC(Atego)
>> support Ada 2005, Janus/Ada supports one or two Ada 2005 features.
>> Also, I think RRSoftware (Janus/Ada) got some of their features to Ada
>> 2005&2012. ...
>
>Thanks.  I now wonder if Ada 2012 has gotten much uptake from the
>traditional big users.  I would have thought so since it's a real
>improvement over older versions, but I understand how critical-systems
>users might be more technologically conservative than internet startups
>for example.  Maybe they're all still using Ada 2005 or Ada 95 and plan
>to stay with it.

	Heck... At work we are running an OpenVMS/VAX (not Alpha) emulation on
Windows boxes in order to run a cross-platform Ada-83 compiler (no longer
in production, to my knowledge) to build the boot software for some
aircraft flight systems.

	Do not expect that to be upgraded anytime soon -- bad enough it takes
months for a sub-contractor to independently certify the boot software
doesn't contain superfluous code, or unpredictable timings... Having to get
a new build chain (OS, compiler, etc.) certified is not in the $$$.

	Heck -- we've had a study running just to certify a different toolchain
where the only difference is WinXP vs Win7 -- when the toolchain doesn't
even produce binaries for Intel architectures! IE: are the resultant
binaries completely identical when the same source is built on each OS --
if there is ANY difference, it must be evaluated to be proven to have no
effect.

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

Re: If not Ada, what else...

[Shark8]

On Monday, July 20, 2015 at 7:16:56 PM UTC-6, Dennis Lee Bieber wrote:
> 
> 	Heck... At work we are running an OpenVMS/VAX (not Alpha) emulation on
> Windows boxes in order to run a cross-platform Ada-83 compiler (no longer
> in production, to my knowledge) to build the boot software for some
> aircraft flight systems.

Hm, given that; are you excited about the project to port OpenVMS to x86_64? I heard from a friend that the Ada compiler (along w/ Fortran, C and C++) is going to be updated.

Re: If not Ada, what else...

[Dennis Lee Bieber]

On Mon, 20 Jul 2015 20:09:12 -0700 (PDT), Shark8 <onewingedshark@gmail.com>
declaimed the following:

>On Monday, July 20, 2015 at 7:16:56 PM UTC-6, Dennis Lee Bieber wrote:
>> 
>> 	Heck... At work we are running an OpenVMS/VAX (not Alpha) emulation on
>> Windows boxes in order to run a cross-platform Ada-83 compiler (no longer
>> in production, to my knowledge) to build the boot software for some
>> aircraft flight systems.
>
>Hm, given that; are you excited about the project to port OpenVMS to x86_64? I heard from a friend that the Ada compiler (along w/ Fortran, C and C++) is going to be updated.

	Well, it would put some meaningful dynamic process priorities on the
hardware <G>

	I'm still have no idea how they handled the four-level hardware system
of the VAX on two-level processors (user/super) even in emulation.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: If not Ada, what else...

[J-P. Rosen]

Le 20/07/2015 19:31, Paul Rubin a écrit :
> Thanks.  I now wonder if Ada 2012 has gotten much uptake from the
> traditional big users.  I would have thought so since it's a real
> improvement over older versions, but I understand how critical-systems
> users might be more technologically conservative than internet startups
> for example.  Maybe they're all still using Ada 2005 or Ada 95 and plan
> to stay with it.

Airbus D&S (previously EADS) announced during the Ada-Europe conference
in Madrid that the software for the Ariane 6 rocket would be developped
in Ada 2012, with intensive use of contracts.

-- 
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: If not Ada, what else...

[Dennis Lee Bieber]

On Tue, 21 Jul 2015 07:43:11 +0200, "J-P. Rosen" <rosen@adalog.fr>
declaimed the following:

>Le 20/07/2015 19:31, Paul Rubin a écrit :
>> Thanks.  I now wonder if Ada 2012 has gotten much uptake from the
>> traditional big users.  I would have thought so since it's a real
>> improvement over older versions, but I understand how critical-systems
>> users might be more technologically conservative than internet startups
>> for example.  Maybe they're all still using Ada 2005 or Ada 95 and plan
>> to stay with it.
>
>Airbus D&S (previously EADS) announced during the Ada-Europe conference
>in Madrid that the software for the Ariane 6 rocket would be developped
>in Ada 2012, with intensive use of contracts.

	Ah... wanting to avoid a repeat of the Ariane-5 fiasco? <G>
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: If not Ada, what else...

[J-P. Rosen]

Le 21/07/2015 14:47, Dennis Lee Bieber a écrit :
>> Airbus D&S (previously EADS) announced during the Ada-Europe conference
>> >in Madrid that the software for the Ariane 6 rocket would be developped
>> >in Ada 2012, with intensive use of contracts.
> 	Ah... wanting to avoid a repeat of the Ariane-5 fiasco? <G>

Fiasco? Ariane-5 has the highest rate of succesful flights of all
rockets. Presumably you meant Ariane 501?

Even though, 1) few (if any) rockets had a fully succesful maiden
flight, and 2) the problem was fully a management issue, with a decision
to skip appropriate testing due to political pressure.

No language can help...

-- 
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: If not Ada, what else...

[David Botton]

> Are you serious, is GNAT really the only implementation of Ada 2012?

Yes

> I see a huge list of Ada 95 implementations here:

Correct there was still some "mandate" money around and hopes for the old style long term support contracts to keep coming so they updated to '95. Less than a handful had enough business to justify 2005 (not sure how many even completely updated) and AdaCore already managed to leverage most of the leftover Ada market post 95 so there was little reason for vendors to keep going other than finish off existing contracts.

The way business is done has changed and none of the Ada vendors have managed to adapt, nor likely ever too. It takes a lot of humility to be nimble enough to make things work in any business especially today and takes even more humility to cultivate a language community without a "mandate" or google budget. The Ada world has never been known for that trait (but there are/have been a few good men)... (Oh my if I had a dollar for every snort...)

> I know some of those vendors are still selling product but I don't know
> that they've been updated for Ada 2012.  I don't see what's so difficult
> about it if customers are asking for it--the changes are not that large.

Vendors are not aligned with the current markets and trends, so there is no incentive for updates as they can't make money using the old models. AdaCore still has some life in it by leveraging the continued work of the open source communities with their own additions (even if not fully appreciating the contributions of the open source community by publishing a GPL runtime virus version in the fake guise of an open source developer edition, but as I've said many times they do contribute back to the FSF, so while they are not heroes, but they are not villains by any means either).

Re: If not Ada, what else...

[Gour]

David Botton <david@botton.com> writes:

> D actually does everything you listed just as well or better. Ada as a
> language is far stronger for sure (I am one of its biggest advocates),
> but Ada suffers from few bindings, foolish license games, much weaker
> standard runtime library, no package management system with automatic
> builds like dub (although Gnoga now has the start of one and will be
> in the next 1.2 release in the coming months), Ada has a much more
> limited set of targets, etc.

This is interesting observation about D…Considering that you’re even
considering writing another front-end, I wonder if you checked the
status of Modula-2 R10? (https://bitbucket.org/trijezdci/m2r10)

It looks that the spec is done and the guy (trijezdci) is now (again)
working on “bootstrap compiler”?



Sincerely,
Gour

-- 
Abandoning all attachment to the results of his activities, 
ever satisfied and independent, he performs no fruitive action, 
although engaged in all kinds of undertakings.

Re: If not Ada, what else...

[David Botton]

> if you checked the
> status of Modula-2 R10? (https://bitbucket.org/trijezdci/m2r10)

My hobby interest for the front end is about Ada (perhaps fixing the OO syntax, but still Ada). It is not a serious project as I am both the wrong person for the job and have other higher priorities even in my hobbies. However, I am enjoying the experimenting and paying around with writing a compiler.

David Botton

Re: If not Ada, what else...

[Niklas Holsti]

On 15-07-21 19:24 , David Botton wrote:
>> if you checked the status of Modula-2 R10?
>> (https://bitbucket.org/trijezdci/m2r10)
>
> My hobby interest for the front end is about Ada (perhaps fixing the
> OO syntax, but still Ada).

If you remove "tagged", as you said in another post, in my opinion it is 
no longer Ada (post 95).

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

Re: If not Ada, what else...

[Simon Wright]

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

> On 15-07-21 19:24 , David Botton wrote:
>>> if you checked the status of Modula-2 R10?
>>> (https://bitbucket.org/trijezdci/m2r10)
>>
>> My hobby interest for the front end is about Ada (perhaps fixing the
>> OO syntax, but still Ada).
>
> If you remove "tagged", as you said in another post, in my opinion it
> is no longer Ada (post 95).

   abstract class type A is
      procedure P1 (This : in out T) is abstract;
   end A;

   class type T is new A with
      overriding procedure P1 (This : in out A);
      not overriding function F1 (This : A) return Integer;
   private
      V : Integer;
   end T;

etc etc; not a million miles from Ada as we know it.

Re: If not Ada, what else...

[David Botton]

>    abstract class type A is
>       procedure P1 (This : in out T) is abstract;
>    end A;
> 
>    class type T is new A with
>       overriding procedure P1 (This : in out A);
>       not overriding function F1 (This : A) return Integer;
>    private
>       V : Integer;
>    end T;
> 
> etc etc; not a million miles from Ada as we know it.

Things would have been so different had Ada not missed its window of opportunity with a syntax more familiar to developers and investments in bindings and interfaces been made.

David Botton

Re: If not Ada, what else...

[Pascal Obry]

Le mardi 21 juillet 2015 à 12:36 -0700, David Botton a écrit :
> Things would have been so different had Ada not missed its window of 
> opportunity with a syntax more familiar to developers and investments 
> in bindings and interfaces been made.

There is zero proof about this and I really don't think it would have
changed anything. The current OO syntax for Ada is just good to me and
I do not see why developers should have a problem with just this
syntax!

It is just too easy to blame a language for this where developers are
just leaning toward languages that are more permissive because of the
hacker beast living in them :)

My 2 cents!

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: If not Ada, what else...

[Jean François Martinez]

On Tuesday, July 21, 2015 at 9:36:47 PM UTC+2, David Botton wrote:

.
> 
> Things would have been so different had Ada not missed its window of opportunity with a syntax more familiar to developers and investments in bindings and interfaces been made.
> 
> David Botton

The problem was not syntax.  The problems were:

1) Being produced by the eeeeeeeeeevil DOD.   That meant politically correct people shunned and disparaged it
2) Missing the PC revolution.  When everyone was learning C/C++ with 100$ Turbo C either there was no Ada compiler or it was completley unaffordable for someone paying from his own pocket.  Thus the loads of Windows software were written in C/C++
3)  To miss the object train.  In the crucial 1985-1995 years when you had to be a object-oriented or die Ada wasn't. That and number two meant employers found it was far easier to recruit C/C++ programmers than Ada ones.
4) Last but not least being a disaster at marketing.  Look at the K&R book.  It is a delight to read with plenty of attractive little examples and exercises who make the reader feel smart (today I would call many of them demagogic like the infamous one: "while (*dst++=*src++);  -- No longer sure about the syntax) the Ada books were booooooooooooring.  Look at the the Barnes one.  If you skip the introduction you will have to read a gazillion pages about types before there is some action (instructions).  That meant many potential users leafed through it and discarded the book and the language, then they leafed through the K&R and went for it.  

Out of competition:  Perhaps because Ada is a language for senior programmers.  When you are a junior programmer you don't underntand the benefits of readability, maintanability and non error-prone syntax (In those years I was a fan of... APL!).  When you get older you understand but you move into management or system administration.

Re: If not Ada, what else...

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3845 bytes --]


"Jean François Martinez" <darkquark99@gmail.com> wrote in message 
news:e8521a43-2bbf-4970-a17b-b585d021f235@googlegroups.com...
>On Tuesday, July 21, 2015 at 9:36:47 PM UTC+2, David Botton wrote:
>
>.
>>
>> Things would have been so different had Ada not missed its window of 
>> opportunity with a syntax more familiar to >>developers and investments 
>> in bindings and interfaces been made.
>>
>> David Botton
>
>The problem was not syntax.  The problems were:
>
>1) Being produced by the eeeeeeeeeevil DOD.   That meant politically 
>correct people shunned and disparaged it

Certainly true for some.

>2) Missing the PC revolution.  When everyone was learning C/C++ with 100$ 
>Turbo C either
>there was no Ada compiler or it was completley unaffordable for someone 
>paying from his
>own pocket.  Thus the loads of Windows software were written in C/C++

Janus/Ada cost $99 for MS-DOS during this period. By the time Windows came 
out, Ada was already far behind and it really didn't matter (although both 
ObjectAda and Janus/Ada were available for under $500 for Windows). (The 
Meridian compiler and other competitors of ours also had Ada compilers with 
similar pricing during the MS-DOS  days.)

Ada didn't quite compete with $29 JRT and $49 Turbo Pascal, but those are 
not C either.

So your premise here is very flawed.

>3)  To miss the object train.

Yup.

>  In the crucial 1985-1995 years when you had to be a object-oriented or 
> die Ada
> wasn't. That and number two meant employers found it was far easier to 
> recruit C/C++
> programmers than Ada ones.

Of course, this was mainly because people using C++ first got useful modules 
that way, and they confused modularity (of critical use) with 
object-orientedness (less useful). But that was a hill that Ada could not 
climb, even if we were right.

>4) Last but not least being a disaster at marketing.

Couldn't argue with this, although the example makes no sense.

> Look at the K&R book.  It is a delight to read with plenty of attractive 
> little examples and exercises who make the reader feel smart (today I 
> would call many of them demagogic like the infamous one: "while 
> (*dst++=*src++);  -- No longer sure about the syntax) the Ada books were 
> booooooooooooring.  Look at the the Barnes one.  If you skip the 
> introduction you will have to read a gazillion pages about types before 
> there is some action (instructions).  That meant many potential users 
> leafed through it and discarded the book and the language, then they 
> leafed through the K&R and went for it.

I never, ever recommended the Barnes book to anyone in those days for that 
very reason. (Sorry John. ;-). But there were dozens of Ada 83 books and no 
one had any reason to depend on a dry one. Indeed, we (RR Software) even had 
our own Ada 83 book, and it's nothing like the Barnes book. For Ada 95, the 
best book was Cohen's "Ada as a Second Language". It's too bad that he never 
updated it (he'd left the Ada world by then).

Even today, you surely don't have to use John's book (it made my legs get 
numb when I tried to leaf through the copy he gave me last year - at least 
it didn't cause me to go over my baggage allowance when returning home!). I 
recommend "Ada Distilled" (which has the advantage of being free, too).

>Out of competition:  Perhaps because Ada is a language for senior 
>programmers.

I'm not sure why you consider this "out of competition". I think this is the 
main reason: Ada is for people who want to write correct, working programs. 
It's not for hacking (although some of use can be pretty effective hacking 
in Ada), it's certainly not for prototyping, and so on. So it never was 
"sexy", and it's not really intended to be fun (unless you have a very weird 
sense of fun like mine!!).

                                         Randy.

Re: If not Ada, what else...

[Georg Bauhaus]

On 28.07.15 00:59, Randy Brukardt wrote:
> Ada is (...)  certainly not for prototyping

For Ada to be useful here, the specifics of the prototype might
play a role, I think:
If the prototype depends on libraries inaccessible from Ada, o.K.
But otherwise, since prototyping seems more about shams, facades,
hollow building blocks, reduced feature set, speed, fake data, limited
I/O support, etc., why would C, say, be better for prototyping
than Ada? When would SETL, or Python, or BigEEMathSimPack be better
suited? If, for example, a LAMP style prototype of some Web based
service is to be made, then using either Ada, or Java, or C# doesn't
look so forbidding, although it might not be socially acceptable.

(I'm currently porting a collection of Python programs from one
Python environment to another. The code has evolved from a prototype.
I wish Python had Ada like types and parameter profiles if only
because of the added value of documenting What This Thing Is™.
How is a prototype useful when the language used for prototyping
tends to vaporize the Why-and-How of its choices and structure?)

Re: If not Ada, what else...

[Paul Rubin]

Georg Bauhaus <bauhaus@futureapps.invalid> writes:
> why would C, say, be better for prototyping than Ada? When would SETL,
> or Python, or BigEEMathSimPack be better suited?

See:

    Haskell vs. Ada vs.  C++ vs. Awk vs. ...: An Experiment in Software
    Prototyping Productivity

    by Paul Hudak and Mark P. Jones

    http://web.cecs.pdx.edu/~apt/cs457_2005/hudak-jones.pdf

> How is a prototype useful when the language used for prototyping
> tends to vaporize the Why-and-How of its choices and structure?)

It lets you test out the intended program features and solidify the
specification.  In fact you often don't start with much of a
specification at all, but rather just a general idea of what you're
trying to do.  Then you try things out, squeeze things in, get feedback
from users and iterate the design, etc.  At the end you've got something
you can use as a reference when figuring out what a more permanent
version should do.  It's like making a pencil sketch before starting an
oil painting.

Re: If not Ada, what else...

[darkestkhan]

On Tuesday, July 28, 2015 at 7:22:17 AM UTC, Paul Rubin wrote:
> Georg Bauhaus writes:
> > why would C, say, be better for prototyping than Ada? When would SETL,
> > or Python, or BigEEMathSimPack be better suited?
> 
> See:
> 
>     Haskell vs. Ada vs.  C++ vs. Awk vs. ...: An Experiment in Software
>     Prototyping Productivity
> 
>     by Paul Hudak and Mark P. Jones
> 
>     http://web.cecs.pdx.edu/~apt/cs457_2005/hudak-jones.pdf
> 

1994, still not Ada 95, C++ w/o stl etc. I wonder how this would look today.

Re: If not Ada, what else...

[G.B.]

On 28.07.15 09:22, Paul Rubin wrote:
> Georg Bauhaus <bauhaus@futureapps.invalid> writes:
>> why would C, say, be better for prototyping than Ada? When would SETL,
>> or Python, or BigEEMathSimPack be better suited?
>
> See:
>
>      Haskell vs. Ada vs.  C++ vs. Awk vs. ...: An Experiment in Software
>      Prototyping Productivity
>
>      by Paul Hudak and Mark P. Jones
>
>      http://web.cecs.pdx.edu/~apt/cs457_2005/hudak-jones.pdf

O.K., so when the problem lends itself so well to equations of
relation, as in this real world example of geometrical constraints,
then Haskell is an inescapably natural choice, in particular
for the programmer suitably skilled in mathematics. (I mean it.)

Views seem to differ when the same approach (higher order
function types) is used in drafting GUIs: following flows
becomes as easy as interpreting the diagnostic output of
C++'s functional template computation hitting an error.

I find it a little unfortunate that much emphasis is put on
notions such as "elegance" or "conciseness" and "almost like
writing a paper" (and not a prototype? :), but that some features
are just barely mentioned, like "prototyping support", which I
thought would be rather interesting to know. There are mentions
of the Prelude, though.

Granted, when exploring a model of an algorithm in the abstract,
what could be better than a concise, formal abstraction?
(And not something for controlling a computer more directly,
like Ada or C++?)

Which could mean that SPARK is a surprisingly good prototyping
language! Specifically, to the extent that provers will handle
primitive recursive functions, to match Ada operations later.
(Is that practical?)

>> How is a prototype useful when the language used for prototyping
>> tends to vaporize the Why-and-How of its choices and structure?)
>
> (...) It's like making a pencil sketch before starting an
> oil painting.

I do hope this process of producing a (executable) specification
isn't as frequently doomed to become a production item by managerial
decision to reuse as I have witnessed! The suggestion of Hudak & Jones
(NB: WG members FP) may even support this view in spite of Bird's
Chapter 7 (Efficiency, Fusions), or considering much use of "strict".
(Line count up, complexity of code up, doubled effort through
understanding and controlling evaluation, ...)

Re: If not Ada, what else...

[Randy Brukardt]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87lhe0px07.fsf@jester.gateway.sonic.net...
...
> It's like making a pencil sketch before starting an oil painting.

And much like those pencil sketches (many of which seem to end up in art 
museums if the painter is famous enough -- the Prada in Madrid was full of 
them), in many cases those prototypes become the product. And that's the 
problem with that sort of prototyping -- a language that focuses on ease of 
writing has to sacrifice ease of maintenance (simply because a lot less is 
written down), and if the product stays in that language there is going to 
be a big cost down the road.

I always do my prototyping in Ada for that very reason -- if the prototype 
works well enough (like the Web server and search engines did), it doesn't 
have to be rewritten just to add the robustness needed for something that 
will be used decades. But I doubt that I'd ever convince the masses of that 
value of that approach.

                             Randy.

Re: If not Ada, what else...

[darkestkhan]

On Monday, July 27, 2015 at 10:59:23 PM UTC, Randy Brukardt wrote:
> I'm not sure why you consider this "out of competition". I think this is the 
> main reason: Ada is for people who want to write correct, working programs. 
> It's not for hacking (although some of use can be pretty effective hacking 
> in Ada), it's certainly not for prototyping, and so on. So it never was 
> "sexy", and it's not really intended to be fun (unless you have a very weird 
> sense of fun like mine!!).

Interesting considering that I don't see any problem when it comes to prototyping in Ada... in fact I would say that Ada is very good at it.
[I even ended up writing prototypes of things that later on had to be implemented in C/C++]

Re: If not Ada, what else...

[Jacob Sparre Andersen]

darkestkhan <darkestkhan@gmail.com> writes:

> Interesting considering that I don't see any problem when it comes to
> prototyping in Ada... in fact I would say that Ada is very good at it.
> [I even ended up writing prototypes of things that later on had to be
> implemented in C/C++]

I must agree here.

You may even see me writing prototypes in Ada, where the final product
has to be written in Basic, C or Java - or even implemented in a
spreadsheet.

I still do some prototyping in Bash, but this is mostly because I
haven't found/written a suitable library for connecting non-Ada tools to
my Ada programs in a (writing) efficient way.

At the moment I'm working on a prototype where the production version
most likely will be written in assembly or some highly processor
specific language by the customer.  But Ada is very practical for
writing algorithms in a readable form.

Greetings,

Jacob
-- 
"... but it was, on the other hand, very good at being a slow
 and dim-witted pupil."
"I had no idea they were supposed to be in short supply"

Re: If not Ada, what else...

[Simon Wright]

Jacob Sparre Andersen <sparre@nbi.dk> writes:

> At the moment I'm working on a prototype where the production version
> most likely will be written in assembly or some highly processor
> specific language by the customer.  But Ada is very practical for
> writing algorithms in a readable form.

I designed a Mascot[1] kernel for a dual-processor F2420 machine[2] in
Ada in about 1985. There was a small part (context switching) where "at
this point, a miracle occurs". The implementation (in assembler) had one
error on delivery and was in service (I believe) up to 2011.

This led to unfounded rumours that we had an Ada compiler for the
machine!

Interestingly, Ravenscar has some commonality with Mascot's approach.

[1] http://async.org.uk/Hugo.Simpson/MASCOT-3.1-Manual-June-1987.pdf
[2] http://www.cbronline.com/news/ferranti_offers_f2420_at_five_times_power_of_fm1600e

Re: If not Ada, what else...

[EGarrulo]

On Tuesday, July 28, 2015 at 12:59:23 AM UTC+2, Randy Brukardt wrote:
> I'm not sure why you consider this "out of competition". I think this is the 
> main reason: Ada is for people who want to write correct, working programs. 
> It's not for hacking (although some of use can be pretty effective hacking 
> in Ada), it's certainly not for prototyping, and so on. So it never was 
> "sexy", and it's not really intended to be fun (unless you have a very weird 
> sense of fun like mine!!).

Why wouldn't Ada be good for hacking?  The only drawback I can see
does not relate to the language itself, but to the lack of flexible
standard libraries.  For example, in an experiment comparing the
productivity of some programming languages[1], and where Haskell 
comes way ahead of the pack, authors note that "[...] the Haskell
prototype was most concise for three reasons: [...] (2) the use of
higher-order functions, and (3) the use of standard list-manipulating
primitives in the standard [library] Prelude."  Ada supports higher-
order functions, but it has nothing like the standard library Prelude
in Haskell, or the STL in C++.  And I find it ironic that Stepanov
wrote the original version of the C++ STL in Ada, but then it never
found its way into the Ada standard.

Why wouldn't Ada be good for prototyping?  I would say that the 
opposite is true, because many recurring abstractions can be 
conveniently expressed; and the compiler lets you code mindlessly,
with the certainty that any stupid mistake will be fixed before the
program runs.  I have prototyped software in Python and I have found
it draining: the program runs until the interpreter finds
a stupid mistake and -- boom! -- you have to fix it and restart
again.  I am sure that had I used Ada instead, I would have completed
my prototypes much earlier.

If anything, I would say that Ada lacks a clear explanation of
how to "think in Ada".  Bluntly, it seems that even long-time
Ada programmers don't understand Ada deeply.

--

[1] http://haskell.cs.yale.edu/?post_type=publication&p=366

Re: If not Ada, what else...

[EGarrulo]

On Wednesday, July 29, 2015 at 2:38:43 PM UTC+2, EGarrulo wrote:
> Bluntly, it seems that even long-time
> Ada programmers don't understand Ada deeply.

Or -- more likely -- some long-time Ada programmers can't explain
Ada clearly.

Re: If not Ada, what else...

[Paul Rubin]

EGarrulo <egarrulo@gmail.com> writes:
> Why wouldn't Ada be good for hacking?  The only drawback I can see
> does not relate to the language itself, but to the lack of flexible
> standard libraries.

Lack of garbage collection (at least in most implementations) is the
first thing that comes to mind.

> Ada supports higher- order functions, but it has nothing like the
> standard library Prelude in Haskell, or the STL in C++.

Ada doesn't have meaningful HOF's in the sense of Haskell, afaik.  But
I thought Ada generics were like the C++ STL?

> Why wouldn't Ada be good for prototyping?  I would say that the 
> opposite is true, because many recurring abstractions can be 
> conveniently expressed; and the compiler lets you code mindlessly,
> with the certainty that any stupid mistake will be fixed before the
> program runs.

1) no garbage collection, 2) recurring abstractions like dynamically
growable lists, strings, dictionaries, etc. might be doable in Ada but
are built into Haskell, Python, etc.  

> I have prototyped software in Python and I have found it draining: the
> program runs until the interpreter finds a stupid mistake and -- boom!
> -- you have to fix it and restart again.

Right, you have to code in a style where you expect that to happen, but
it's fairly easy to develop that.

> I am sure that had I used Ada instead, I would have completed my
> prototypes much earlier.

I'd be interested in seeing Ada solutions to a few of the earlier Euler
problems, let's say selected from the first 25.  You could either look
at the problems and pick a few.  Or alternatively, pick a number N
between 1 and 25 before looking at the problems, and then do problem
number N.

Or even simpler: print a list of the first 100 primes.  This is 3 lines
of code in Haskell, see the illustration at the top of www.haskell.org .

Here is an exercise that is easy in Haskell but surprisingly tedious in
languages like Ada: a number is "5-smooth" or "Hamming" if it has no
prime factors greater than 5.  So 10, 12, and 15 are 5-smooth but 11,
13, and 14 are not.  The first 20 Hamming numbers are:

   [1,2,3,4,5,6,8,9,10,12,15,16,18,20,24,25,27,30,32,36]

I was going to ask for the millionth such number, but you need arbitrary
precision arithmetic for it.  So, what is the 10000th such number?  That
one fits in 64 bits, but is not really feasible to reach by counting.

Re: If not Ada, what else...

[Björn Lundin]

On 2015-07-29 17:41, Paul Rubin wrote:
> 
>
 2) recurring abstractions like dynamically
> growable lists, strings, dictionaries, etc. might be doable in Ada but
> are built into Haskell, Python, etc.  

See Ada.Containers.*

> Or even simpler: print a list of the first 100 primes.  This is 3 lines
> of code in Haskell, see the illustration at the top of www.haskell.org .
> 
> Here is an exercise that is easy in Haskell but surprisingly tedious in
> languages like Ada: a number is "5-smooth" or "Hamming" if it has no
> prime factors greater than 5.  So 10, 12, and 15 are 5-smooth but 11,
> 13, and 14 are not.  The first 20 Hamming numbers are:
> 
>    [1,2,3,4,5,6,8,9,10,12,15,16,18,20,24,25,27,30,32,36]
> 
> I was going to ask for the millionth such number, but you need arbitrary
> precision arithmetic for it.  So, what is the 10000th such number?  That
> one fits in 64 bits, but is not really feasible to reach by counting.
> 

They look really mathematical.
Haskell territory ?

How is Haskell doing in Ada territory, like
concurrency etc ?


--
Björn

Re: If not Ada, what else...

[Paul Rubin]

Björn Lundin <b.f.lundin@gmail.com> writes:
> See Ada.Containers.*

Will look there, but those kinds of containers are more useful with GC.

> How is Haskell doing in Ada territory, like concurrency etc ?

It's partly on the implementation, but GHC's concurrency is far superior
to GNAT's in my opinion.  GNAT uses Posix threads while GHC supports
lightweight threads with parallel garbage collection.  It can handle
millions of concurrent threads on a large server:

  http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf

GHC also supports software transactional memory (STM), that let threads
composably share mutable data without the traditional hazards of lock
inversion etc.  Haskell's type system statically verifies that STM
operations aren't improperly mixed with I/O that could wedge the runtime:

  http://book.realworldhaskell.org/read/software-transactional-memory.html

GHC also supports various kinds of deterministic parallelism, like the
"par" operator that lets you very simply annotate that two operations
can be done in parallel (on separate cpu cores):

  https://donsbot.wordpress.com/2007/11/29/use-those-extra-cores-and-beat-c-today-parallel-haskell-redux/

The cool thing about this is it doesn't affect the datatypes in the
program, and if you use it improperly, your program might run slower
instead of faster, but it will still find the right answers.

There are also data parallelism libraries that will let you spin array
computations off to SIMD units or GPU's, but Ada probably has similar
libraries.

There is an online book about parallel and concurrent programming in
Haskell (scroll down for the TOC):

  http://chimera.labs.oreilly.com/books/1230000000929/index.html

================

Where Ada beats Haskell is in deterministic timing and memory footprint.
SPARK has ways to verify that an Ada function can't possibly throw an
exception.  That's difficult in Haskell, because programs constantly use
the memory allocator, and there can also be unpredictable GC pauses at
any time in the program.  Ada can also compile to small cpu targets
because of its small or nonexistent runtime system.

So I'd see the archetypal Ada application as a critical embedded system
like a jet engine controller, while the archetypal Haskell application
is something like a compiler or internet server that must not give wrong
answers, but where a pause in execution (or even an OOM crash followed
by a failover or workaround) is annoying but not disastrous.

Re: If not Ada, what else...

[Björn Lundin]

On 2015-07-29 20:27, Paul Rubin wrote:
> Björn Lundin <b.f.lundin@gmail.com> writes:
>> See Ada.Containers.*
> 
> Will look there, but those kinds of containers are more useful with GC.

I think you are missing the point.
Many things in Ada is done without allocating with 'new'
And things that are, if OO, may inherit from
Ada.Finalized, which gives a call to the objects'
'Finalize' method where deallcation - if necessary - can be done.
So, the user does not fiddle with new/free.



  declare
  package Stuff_Pkg is new Ada.Containers.Doubly_Linked_Lists(Stuff_Type);
  Stuff_data : Stuff_type;
  Stuff_List : Stuff_Pkg.List
  begin
   for i in 1 ..100 loop
     Stuff_list.Append(Stuff_data):
   end loop;

   -- use stuff_list here

  end;

 --no mem leak here
> 
>> How is Haskell doing in Ada territory, like concurrency etc ?
> 
> It's partly on the implementation, but GHC's concurrency is far superior
> to GNAT's in my opinion.  GNAT uses Posix threads while GHC supports
> lightweight threads with parallel garbage collection.  It can handle
> millions of concurrent threads on a large server:
> 
>   http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf
> 
> GHC also supports software transactional memory (STM), that let threads
> composably share mutable data without the traditional hazards of lock
> inversion etc.  Haskell's type system statically verifies that STM
> operations aren't improperly mixed with I/O that could wedge the runtime:
> 
>   http://book.realworldhaskell.org/read/software-transactional-memory.html
> 
> GHC also supports various kinds of deterministic parallelism, like the
> "par" operator that lets you very simply annotate that two operations
> can be done in parallel (on separate cpu cores):
> 
>   https://donsbot.wordpress.com/2007/11/29/use-those-extra-cores-and-beat-c-today-parallel-haskell-redux/
> 
> The cool thing about this is it doesn't affect the datatypes in the
> program, and if you use it improperly, your program might run slower
> instead of faster, but it will still find the right answers.
> 
> There are also data parallelism libraries that will let you spin array
> computations off to SIMD units or GPU's, but Ada probably has similar
> libraries.
> 
> There is an online book about parallel and concurrent programming in
> Haskell (scroll down for the TOC):
> 
>   http://chimera.labs.oreilly.com/books/1230000000929/index.html
> 
> ================
> 
> Where Ada beats Haskell is in deterministic timing and memory footprint.
> SPARK has ways to verify that an Ada function can't possibly throw an
> exception.  That's difficult in Haskell, because programs constantly use
> the memory allocator, and there can also be unpredictable GC pauses at
> any time in the program.  Ada can also compile to small cpu targets
> because of its small or nonexistent runtime system.
> 
> So I'd see the archetypal Ada application as a critical embedded system
> like a jet engine controller, while the archetypal Haskell application
> is something like a compiler or internet server that must not give wrong
> answers, but where a pause in execution (or even an OOM crash followed
> by a failover or workaround) is annoying but not disastrous.
> 

Interesting reading

-- 
--
Björn

Re: If not Ada, what else...

[Paul Rubin]

Björn Lundin <b.f.lundin@gmail.com> writes:
>> Will look there, but those kinds of containers are more useful with GC.
> I think you are missing the point.  Many things in Ada is done without
> allocating with 'new' And things that are, if OO, may inherit from
> Ada.Finalized, which gives a call to the objects' 'Finalize' method
> where deallcation - if necessary - can be done.  So, the user does not
> fiddle with new/free.

Right, that's sort of like C++ RAII.  But GC gives you much more
flexibility.  For example, maybe you want to allocate a container and
then pass it to another thread to work on it.

Re: If not Ada, what else...

[Dmitry A. Kazakov]

On Wed, 29 Jul 2015 15:18:11 -0700, Paul Rubin wrote:

> But GC gives you much more
> flexibility.  For example, maybe you want to allocate a container and
> then pass it to another thread to work on it.

As if you could not do this without GC.

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

Re: If not Ada, what else...

[David Botton]

> > But GC gives you much more
> > flexibility.  For example, maybe you want to allocate a container and
> > then pass it to another thread to work on it.
> 
> As if you could not do this without GC.

Actually most GC implementations don't handle cross thread allocations well. Ada was created with facility to support GC and possible to use the Boehm GC with it and some have in the past. However, a well designed Ada program rarely has much use for GC and it tends to sloppy dev most of the time.

David Botton

Re: If not Ada, what else...

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87wpximwv0.fsf@jester.gateway.sonic.net...
> Björn Lundin <b.f.lundin@gmail.com> writes:
>>> Will look there, but those kinds of containers are more useful with GC.
>> I think you are missing the point.  Many things in Ada is done without
>> allocating with 'new' And things that are, if OO, may inherit from
>> Ada.Finalized, which gives a call to the objects' 'Finalize' method
>> where deallcation - if necessary - can be done.  So, the user does not
>> fiddle with new/free.
>
> Right, that's sort of like C++ RAII.  But GC gives you much more
> flexibility.  For example, maybe you want to allocate a container and
> then pass it to another thread to work on it.

What does this have to do with GC? When you pass a container to another 
task, it gets passed like any other parameter (by-reference in this case). 
There's no need to create an explicit access type.

You need explicit access types in Ada only when you need to have a 
dynamically organized structure. And even some of those can be replaced by a 
container (lots of structures are really multi-way trees, so the tree 
container ought to work well for managing them). (There's also a few cases 
involving function returns where one might need them for efficiency 
reasons -- but worrying about that is premature optimization -- only 
introduce access types if you've demonstrated that the performance is 
insufficient.)

                                  Randy.

Re: If not Ada, what else...

[Georg Bauhaus]

On 29.07.15 20:27, Paul Rubin wrote:
> Björn Lundin<b.f.lundin@gmail.com>  writes:
>> >See Ada.Containers.*
> Will look there, but those kinds of containers are more useful with GC.

See Randy Brukardt's repeated admonishment to use Ada.Containers
precisely because they handle storage.

Re: If not Ada, what else...

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1478 bytes --]

"Georg Bauhaus" <bauhaus@futureapps.invalid> wrote in message 
news:mpb8r3$a2i$1@dont-email.me...
> On 29.07.15 20:27, Paul Rubin wrote:
>> Björn Lundin<b.f.lundin@gmail.com>  writes:
>>> >See Ada.Containers.*
>> Will look there, but those kinds of containers are more useful with GC.
>
> See Randy Brukardt's repeated admonishment to use Ada.Containers
> precisely because they handle storage.

I'll repeat it so he doesn't have to look it up: the whole point of using 
such containers is that they handle all of the storage management for you. 
When using the containers, you don't have to (and shouldn't, IMHO) use any 
access types at all. The container element can be any non-limited type, 
which of course includes other containers.

Ada 2012 added tree and queue containers, as well as adding syntactic sugar 
for iterators and indexing, such that containers usage can look pretty much 
like using a built-in array type. (It's more complex under the covers, of 
course, but the whole idea is to hide complexity.) And the bounded forms of 
the containers gives memory certainty for applications that need that.

It would be completely unnecessary to use any GC with the Ada containers. 
You (arguably) need it when you use raw access types, and can't use subpools 
or a custom storage pool to manage the storage sensibly. That comes up 
rather rarely in Ada 2012 (unless, of course, you are writing a container 
implementation).

                                  Randy.

Re: If not Ada, what else...

[Paul Rubin]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> It would be completely unnecessary to use any GC with the Ada containers. 

It just depends on what the program is doing--if the absence of GC
constrains how you organize your program, then you are missing out on
something by not having it.

Consider a multi-threaded program whose threads communicate through
async queues.  So a work request comes into one thread, it gets decoded
into a dictionary (container instance), and then the dictionary is
dropped onto a queue.  Another thread later picks it up and processes
it, sending the results through yet another queue.  This is a very
common way to write a Python or Erlang program.  But it means you can't
rely on syntactic scoping to know when a container is no longer in use.
You either have to carefully track where every reference might be, or
else use an automatic reclamation scheme (refcounts, GC, or whatever).

Re: If not Ada, what else...

[Niklas Holsti]

On 15-07-30 07:54 , Paul Rubin wrote:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> It would be completely unnecessary to use any GC with the Ada containers.
>
> It just depends on what the program is doing--if the absence of GC
> constrains how you organize your program, then you are missing out on
> something by not having it.
>
> Consider a multi-threaded program whose threads communicate through
> async queues.  So a work request comes into one thread, it gets decoded
> into a dictionary (container instance), and then the dictionary is
> dropped onto a queue.  Another thread later picks it up and processes
> it, sending the results through yet another queue.  This is a very
> common way to write a Python or Erlang program.  But it means you can't
> rely on syntactic scoping to know when a container is no longer in use.
> You either have to carefully track where every reference might be, or
> else use an automatic reclamation scheme (refcounts, GC, or whatever).

No problem doing that with Ada containers. The first thread creates the 
dictionary in its own container variable, then uses the container's Move 
operation to move the data into the queue. This erases the first 
thread's container variable, so its finalization has essentially nothing 
to do. The second thread uses Move to extract the data from the queue 
into its own container variable; when that variable is finalized, the 
dictionary data are deallocated.

Reference counting or whatever is done within the container libraries.

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

Re: If not Ada, what else...

[Dmitry A. Kazakov]

On Wed, 29 Jul 2015 21:54:58 -0700, Paul Rubin wrote:

> Consider a multi-threaded program whose threads communicate through
> async queues.  So a work request comes into one thread, it gets decoded
> into a dictionary (container instance), and then the dictionary is
> dropped onto a queue.  Another thread later picks it up and processes
> it, sending the results through yet another queue.

Since queues marshal data there is no place for GC here. You put a *copy*
into the queue on one side and get another *copy* on the other. Queues,
messages, mailboxes etc are all by-value.

One of the advantages of Ada's tasking was the rendezvous allowing
by-reference passing, since rendezvous is a synchronous call.

Queueing references (I do it all the time implementing drivers and
protocols) is a great pain and GC is no help, because of canceling requests
and other sorts of stuff requiring deterministic time and order of
execution such actions. GC (at least a built-in one) has no place in
systems programming.

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

Re: If not Ada, what else...

[Paul Rubin]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> Since queues marshal data there is no place for GC here. You put a *copy*

Oh I see, I didn't realize that.  In Python you'd only be passing references.

> Queueing references (I do it all the time implementing drivers and
> protocols) is a great pain and GC is no help, because of canceling
> requests and other sorts of stuff requiring deterministic time and
> order of execution such actions.  GC (at least a built-in one) has no
> place in systems programming.


GC makes it simple, at the cost of deterministic timing.  I can
understand why you might not want that in an Ada program.  I don't see
how it affects ordering.  GC works perfectly fine in systems programming
except for some low level operations or if you're doing something timing
sensitive.  Think of the Lisp machine.

Re: If not Ada, what else...

[Dmitry A. Kazakov]

On Wed, 29 Jul 2015 23:47:41 -0700, Paul Rubin wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> Since queues marshal data there is no place for GC here. You put a *copy*
> 
> Oh I see, I didn't realize that.  In Python you'd only be passing references.
> 
>> Queueing references (I do it all the time implementing drivers and
>> protocols) is a great pain and GC is no help, because of canceling
>> requests and other sorts of stuff requiring deterministic time and
>> order of execution such actions.  GC (at least a built-in one) has no
>> place in systems programming.
> 
> GC makes it simple, at the cost of deterministic timing.  I can
> understand why you might not want that in an Ada program.  I don't see
> how it affects ordering.

Because a reference does not enforce any specific order it only throws some
constraints in. If you wanted to use GC you would have to stuff things with
"hard" and "soft" references to ensure, for example, a proper order of
finalization (of interdependent things like driver, connection, I/O
request, variable).

"Soft" and "hard" references quickly become an utter mess without any
decent means to test it, e.g. that the mandated order is indeed enforced in
all cases. How do you test that? How could you prove anything about it? How
do you maintain software changes when you know nothing about the effects of
adding/removing a reference?

Furthermore, maintaining these references requires memory and other
containers to stuff them into. It is frequently 1-n relationships, thus you
have to keep a whole list of "soft" and/or "hard" references in an object.
Soft references require a lot of cycles to keep them updated, these cycles
are all synchronous walking-through lists and doing callbacks. Imagine that
in an interrupt routine! Worse, it is not a bounded time, there is no limit
on the number of "soft" references. Even worse it is not task-safe, you
will need interlocking on top of that huge pile of mess. You will get nice
deadlocks if not more complicated interlocking is used, an interlocking
that would require even more CPU cycles and even more context switches. And
priority inversions would be your least concern.

It is great to have things non-deterministic when dealing with system
resources, which are all singletons! When will the GC free a resource bound
to a to-be-collected object (e.g. a communication port)? How do you wait
for this, where do you wait for this?

And why all that? Because somebody was too lazy to think the design
through?

> Think of the Lisp machine.

Better not, I want to sleep at night... (:-))

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

Re: If not Ada, what else...

[Paul Rubin]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> If you wanted to use GC you would have to stuff things with
> "hard" and "soft" references to ensure, for example, a proper order of
> finalization (of interdependent things like driver, connection, I/O...

Oh I see, you mean order of finalizations.  Yeah that's an antipattern
in Java and basically not supported in Haskell, other than weakrefs.
GC works best for memory and stuff like file handles should be managed
by other means.

> And why all that? Because somebody was too lazy to think the design
> through?

http://c2.com/cgi/wiki?LazinessImpatienceHubris

Re: If not Ada, what else...

[Stefan.Lucks]

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

On Wed, 29 Jul 2015, Paul Rubin wrote:

> Here is an exercise that is easy in Haskell but surprisingly tedious in
> languages like Ada: a number is "5-smooth" or "Hamming" if it has no
> prime factors greater than 5.  So 10, 12, and 15 are 5-smooth but 11,
> 13, and 14 are not.  The first 20 Hamming numbers are:
>
>   [1,2,3,4,5,6,8,9,10,12,15,16,18,20,24,25,27,30,32,36]
>
> I was going to ask for the millionth such number, but you need arbitrary
> precision arithmetic for it.  So, what is the 10000th such number?  That
> one fits in 64 bits, but is not really feasible to reach by counting.
>

http://rosettacode.org/wiki/Hamming_numbers#Ada

--------  I  love  the  taste  of  Cryptanalysis  in  the morning!  --------
www.uni-weimar.de/de/medien/professuren/mediensicherheit/people/stefan-lucks
----Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany----

Re: If not Ada, what else...

[Paul Rubin]

Stefan.Lucks@uni-weimar.de writes:
> http://rosettacode.org/wiki/Hamming_numbers#Ada

That is not a reasonable solution IMHO.  It counts upwards
1,2,3... testing each number for the testing property.  Computers now
are fast enough that this can run through a 32-bit count without taking
all day, so it is able to find the 1691th number which is around 2e9.
But the 10000th number is around 3e17 and the Haskell program finds it
basically instantly.  The documentation for the Ada program mentions it
would have to use a bignum library to find the millionth Hamming number,
which overlooks the issue that the number is around 5e83 and counting
that far would take essentially forever.  The Haskell program gets it in
a few seconds.  You could implement the Haskell algorithm in Ada with
a page or two of code but it would be rather tedious.  

Re: If not Ada, what else...

[Waldek Hebisch]

Paul Rubin <no.email@nospam.invalid> wrote:
> Stefan.Lucks@uni-weimar.de writes:
> > http://rosettacode.org/wiki/Hamming_numbers#Ada
> That is not a reasonable solution IMHO.  It counts upwards
> 1,2,3... testing each number for the testing property.  Computers now
> are fast enough that this can run through a 32-bit count without taking
> all day, so it is able to find the 1691th number which is around 2e9.
> But the 10000th number is around 3e17 and the Haskell program finds it
> basically instantly.  The documentation for the Ada program mentions it
> would have to use a bignum library to find the millionth Hamming number,
> which overlooks the issue that the number is around 5e83 and counting
> that far would take essentially forever.  The Haskell program gets it in
> a few seconds.  You could implement the Haskell algorithm in Ada with
> a page or two of code but it would be rather tedious.  

AFAICS iterative version which uses array as a stream buffer
is about 20 lines long and quite easy to write.  In fact,
version which takes allowed prime divisors as paramenter
seem to be shorter than versions specialized to 2, 3 and 5.
So, Haskell version is smaller but other can be quite small
too.

-- 
                              Waldek Hebisch
hebisch@antispam.uni.wroc.pl 

Re: If not Ada, what else...

[Paul Rubin]

Waldek Hebisch <hebisch@antispam.uni.wroc.pl> writes:
>> > http://rosettacode.org/wiki/Hamming_numbers#Ada
> AFAICS iterative version which uses array as a stream buffer
> is about 20 lines long and quite easy to write. 

I'd be interested in seeing what that looks like.  There's a Java
version on rosettacode that uses priority queues and is somewhat messy.

Re: If not Ada, what else...

[Waldek Hebisch]

Paul Rubin <no.email@nospam.invalid> wrote:
> Waldek Hebisch <hebisch@antispam.uni.wroc.pl> writes:
> >> > http://rosettacode.org/wiki/Hamming_numbers#Ada
> > AFAICS iterative version which uses array as a stream buffer
> > is about 20 lines long and quite easy to write. 
> 
> I'd be interested in seeing what that looks like.  There's a Java
> version on rosettacode that uses priority queues and is somewhat messy.

See below: computational part has 19 lines, the rest is driver
to print result and a boilerplate.  This version is limited to
Integer size, need different type to get bigger size.  Number
of artitmetic operations is linear with n0, so with appripriate
numeric type could go to quite large n0.

with Ada.Integer_Text_IO;    --  1  10.1.2, A.10 Context clause
procedure  hamming is
n0 : constant integer := 1_691;
buff : array(1..n0) of Integer;
procedure hamn(n : Integer) is
    cand : array(1..3) of Integer;
    ind : array(1..3) of Integer := (1, 1, 1);
    p : array(1..3) of Integer := (2, 3, 5);
    cmin : Integer;
    begin
        buff(1) := 1;
        for j in 1..3 loop cand(j) := p(j)*buff(ind(j)); end loop;
        cmin := cand(1);
        for j in 2..3 loop
                if cand(j) < cmin then cmin := cand(j); end if;
        end loop;
        buff(i) := cmin;
        for j in 1..3 loop
            if cand(j) = cmin then ind(j) := ind(j) + 1; end if;
        end loop;
    end loop;
end hamn;

begin
   hamn(n0);
   for i in 1..10 loop
       Ada.Integer_Text_IO.put(buff(i));
   end loop;
   Ada.Integer_Text_IO.put(buff(n0));
end hamming;

-- 
                              Waldek Hebisch
hebisch@math.uni.wroc.pl 

Re: If not Ada, what else...

[Jeffrey R. Carter]

On 08/23/2015 09:26 AM, Waldek Hebisch wrote:
> 
> with Ada.Integer_Text_IO;    --  1  10.1.2, A.10 Context clause
> procedure  hamming is
> n0 : constant integer := 1_691;
> buff : array(1..n0) of Integer;
> procedure hamn(n : Integer) is

N is unreferenced.

>     cand : array(1..3) of Integer;
>     ind : array(1..3) of Integer := (1, 1, 1);
>     p : array(1..3) of Integer := (2, 3, 5);
>     cmin : Integer;
>     begin
>         buff(1) := 1;
>         for j in 1..3 loop cand(j) := p(j)*buff(ind(j)); end loop;
>         cmin := cand(1);
>         for j in 2..3 loop
>                 if cand(j) < cmin then cmin := cand(j); end if;
>         end loop;
>         buff(i) := cmin;

I is not defined.

>         for j in 1..3 loop
>             if cand(j) = cmin then ind(j) := ind(j) + 1; end if;
>         end loop;
>     end loop;

No matching "loop" for this "end loop;"

> end hamn;
> 
> begin
>    hamn(n0);
>    for i in 1..10 loop
>        Ada.Integer_Text_IO.put(buff(i));
>    end loop;
>    Ada.Integer_Text_IO.put(buff(n0));
> end hamming;

-- 
Jeff Carter
"I blow my nose on you."
Monty Python & the Holy Grail
03

Re: If not Ada, what else...

[Waldek Hebisch]

Jeffrey R. Carter <spam.jrcarter.not@spam.not.acm.org> wrote:
> On 08/23/2015 09:26 AM, Waldek Hebisch wrote:
> > 
> > with Ada.Integer_Text_IO;    --  1  10.1.2, A.10 Context clause
> > procedure  hamming is
> > n0 : constant integer := 1_691;
> > buff : array(1..n0) of Integer;
> > procedure hamn(n : Integer) is
> 
> N is unreferenced.

Oops, my editor messed formatting.  Fixing formatting I lost
a line (of course now formatting needs to be fixed again...).
> >     cand : array(1..3) of Integer;
> >     ind : array(1..3) of Integer := (1, 1, 1);
> >     p : array(1..3) of Integer := (2, 3, 5);
> >     cmin : Integer;
> >     begin
> >         buff(1) := 1;
            for i in 2..n loop
> >         for j in 1..3 loop cand(j) := p(j)*buff(ind(j)); end loop;
> >         cmin := cand(1);
> >         for j in 2..3 loop
> >                 if cand(j) < cmin then cmin := cand(j); end if;
> >         end loop;
> >         buff(i) := cmin;
> 
> I is not defined.
> 
> >         for j in 1..3 loop
> >             if cand(j) = cmin then ind(j) := ind(j) + 1; end if;
> >         end loop;
> >     end loop;
> 
> No matching "loop" for this "end loop;"
> 
> > end hamn;
> > 
> > begin
> >    hamn(n0);
> >    for i in 1..10 loop
> >        Ada.Integer_Text_IO.put(buff(i));
> >    end loop;
> >    Ada.Integer_Text_IO.put(buff(n0));
> > end hamming;
> 

-- 
                              Waldek Hebisch
hebisch@math.uni.wroc.pl 

Re: If not Ada, what else...

[Jeffrey R. Carter]

Making it look a bit more like Ada, and using an unbounded-integer pkg:

with Ada.Text_IO;
with PragmARC.Unbounded_Integers;

procedure Hamming is
   use PragmARC.Unbounded_Integers;

   Max : constant := 1_000_000;

   One   : constant Unbounded_Integer := To_Unbounded_Integer (1);
   Two   : constant Unbounded_Integer := To_Unbounded_Integer (2);
   Three : constant Unbounded_Integer := To_Unbounded_Integer (3);
   Five  : constant Unbounded_Integer := To_Unbounded_Integer (5);

   type Buffer is array (1 .. Max) of Unbounded_Integer;

   procedure Hamming (Buff : out Buffer) is
      type Work_List  is array (1 .. 3) of Unbounded_Integer;
      type Index_List is array (Work_List'Range) of Positive;

      P : constant Work_List := (Two, Three, Five);

      Cand : Work_List;
      Ind  : Index_List := (1, 1, 1);
      Min  : Unbounded_Integer;
   begin -- Hamming
      Buff (Buff'First) := One;

      All_Results : for I in Buff'First + 1 .. Buff'Last loop
         Candidates : for J in Work_List'Range loop
            Cand (J) := P (J) * Buff (Ind (J) );
         end loop Candidates;

         Min := Cand (Cand'First);

         Find_Min : for J in Cand'First + 1 .. Cand'Last loop
            if Cand (J) < Min then
               Min := Cand (J);
            end if;
         end loop Find_Min;

         Buff (I) := Min;

         Increment_Mins : for J in Work_List'Range loop
            if Cand (J) = Min then
               Ind (J) := Ind (J) + 1;
            end if;
         end loop Increment_Mins;
      end loop All_Results;
   end Hamming;

   type Buffer_Ptr is access Buffer;

   Buff : constant Buffer_Ptr := new Buffer;
begin -- Hamming
   Hamming (Buff => Buff.all);

   First_20 : for I in 1 .. 20 loop
      Ada.Text_IO.Put_Line
         (Item => Integer'Image (I) & ' ' & Image (Buff (I) ) );
   end loop First_20;

   Ada.Text_IO.Put_Line (Item => " 1691" & ' ' & Image (Buff (1691) ) );
   Ada.Text_IO.Put_Line
      (Item => Integer'Image (Max) & ' ' & Image (Buff (Max) ) );
end Hamming;

Which gives

$ time ./hamming
 1 1
 2 2
 3 3
 4 4
 5 5
 6 6
 7 8
 8 9
 9 10
 10 12
 11 15
 12 16
 13 18
 14 20
 15 24
 16 25
 17 27
 18 30
 19 32
 20 36
 1691 2125764000
 1000000
519312780448388736089589843750000000000000000000000000000000000000000000000000000000

real	0m6.534s
user	0m6.432s
sys	0m0.092s

on a 2-GHz Core 2 Duo. More modern processors will no doubt be faster.

The PragmAda Reusable Components are available at

https://pragmada.x10hosting.com/pragmarc.htm

PragmARC.Unbounded_Integers is only available in the beta version for ISO/IEC
8652:2007 since it uses Ada.Containers.

-- 
Jeff Carter
"I blow my nose on you."
Monty Python & the Holy Grail
03

Re: If not Ada, what else...

[Waldek Hebisch]

Paul Rubin <no.email@nospam.invalid> wrote:
> Waldek Hebisch <hebisch@antispam.uni.wroc.pl> writes:
> >> > http://rosettacode.org/wiki/Hamming_numbers#Ada
> > AFAICS iterative version which uses array as a stream buffer
> > is about 20 lines long and quite easy to write. 
> 
> I'd be interested in seeing what that looks like.  There's a Java
> version on rosettacode that uses priority queues and is somewhat messy.

I provided Ada version in another post.  However, several entries
in Rosetta Code use essentially the same method.  In particular:
ALGOL 68, AWK, BBC BASIC, C# (first and second), D (first version),
ERRE, Fortran, Go, Liberty BASIC, Nim, PARI/GP.

-- 
                              Waldek Hebisch
hebisch@math.uni.wroc.pl 

Re: If not Ada, what else...

[Georg Bauhaus]

On 29.07.15 17:41, Paul Rubin wrote:
> Here is an exercise that is easy in Haskell but surprisingly tedious in
> languages like Ada

OTOH, it keeps being surprisingly tedious to turn clear and simple
Haskell algorithms into something that respects time and storage. GHC
seems to have become just a little better over the years.

Naively computing a sum picking by picking every mth element
from a list,

picksum :: [Int] -> Int -> Int
picksum [] m = 0
picksum xs m
            | m <= 0 = 0
            | m  > 0 = mth xs
   where mth l@(y:ys) = y + mth (drop m l)
         mth []       = 0

Then, try this with the justly famed easy list notation, passing
[1 .. 12345678], or larger. (I have GHC 7.8.3, maybe that's too old?)

Of course, the language war soldier of Haskell will argue that the
enemy writer of the above algorithm was stupid, and that the same
thing happens if you do use lists in Ada, from Ada.Containers,
instead of what any competent programmer would be writing in either
language. Whatever that might be.

But it's definitely good for prototyping, that much seems obvious,
I think.

Re: If not Ada, what else...

[Paul Rubin]

Georg Bauhaus <bauhaus@futureapps.invalid> writes:
> picksum :: [Int] -> Int -> Int
> picksum [] m = 0
> picksum xs m
>            | m <= 0 = 0
>            | m  > 0 = mth xs
>   where mth l@(y:ys) = y + mth (drop m l)
>         mth []       = 0
>
> Then, try this with the justly famed easy list notation, passing
> [1 .. 12345678], or larger. (I have GHC 7.8.3, maybe that's too old?)
> Of course, the language war soldier of Haskell will argue that the
> enemy writer of the above algorithm was stupid,

Nah, there's a trick that's not obvious to beginners but it's one of the
first things you learn in functional programming, and it's not a big
deal once you know it.  Basically the recursive call to "mth" has to
return a value that gets added to y, which means the stack frame can't
get released til the addition has happened.  You instead want to write
it tail recursively with an accumulator, something like:

> ...        | m  > 0 = mth xs 0
>   where mth l@(y:ys) !a = mth (drop m l) (y+a)
>         mth [] a       = a

Note the !a in the pattern-- that's a strictness marker to stop
unevaluated sums from piling up on the stack.  Again it takes some
getting used to but you learn to spot these things.

I might have written the function like this:

p2 :: [Int] -> Int -> Int
p2 xs m = sum . map head . takeWhile (not . null) . iterate (drop m) $ xs

but the sum might have to be replaced with "foldl1' (+)" for strictness.

Re: If not Ada, what else...

[Georg Bauhaus]

On 30.07.15 07:17, Paul Rubin wrote:
> Basically the recursive call to "mth" has to
> return a value that gets added to y, which means the stack frame can't
> get released til the addition has happened.

Aren't these features (tail recursion, strict, ...) among the reasons
why Haskell got lazy strategies in the first place? And still, whenever
time and storage do matter, we need to know how to control another, rather
sophisticated machine. We still change our algorithms! I guess I'm
repeating old commentary.

> p2 :: [Int] -> Int -> Int
> p2 xs m = sum . map head . takeWhile (not . null) . iterate (drop m) $ xs

(Nitpick: This loops when m<=0, try "p2 [1] 0". (*)).  While

*Main> picksum [1 .. 123456789] 6
  
was done after some 28 seconds (19 seconds with your !a-ccumulator and pragma
{-# LANGUAGE BangPatterns #-}, news to me, thanks!), I waited minutes after
intense disk swapping for

*Main> p2 [1 .. 123456789] 6
^C

Seems another feature of prototyping is apparent: can't use larger data sets.
I guess I have also missed some way or other of controlling the prototyping
interpreter (GHCi) that would make it produce more efficient code, ways that
would be "obvious" to ... of course ;-)

__
(*) The effect is somewhat like that of asking the Heart of Gold for tea.
So, careful!

Re: If not Ada, what else...

[Paul Rubin]

Georg Bauhaus <bauhaus@futureapps.invalid> writes:
> Aren't these features (tail recursion, strict, ...) among the reasons
> why Haskell got lazy strategies in the first place?

Tail recursion is a standard FP thing and you have to do it in Scheme
and ML as well.  Haskell's lazy evaluation was an interesting experiment
that has its good and bad points.  The interesting next-generation FP
languages like Idris seem to have gone back to strict evaluation, though
there's stuff happening in the theory community that might show up in
languages further down the road, that might allow strict/lazy
combinations whose behavior is tracked by type systems better than has
been done in the past.

>> p2 xs m = sum . map head . takeWhile (not . null) . iterate (drop m) $ xs
> (Nitpick: This loops when m<=0, try "p2 [1] 0". (*)).  

Yeah, it was supposed to only be illustrative of how to compute the sum
without all that explicit recursion.  To handle the non-positve case, add
   p2 _ m | m <= 0 = 0

> {-# LANGUAGE BangPatterns #-}, news to me, thanks!), I waited minutes after
> intense disk swapping for
> *Main> p2 [1 .. 123456789] 6

OK, yeah, as predicted, the problem is that ghci isn't noticing it can
optimize sum as strict.  ghc -O would probably do it.  Try writing:

    import Data.List (foldl1')
    p2 :: [Int] -> Int -> Int
    p2 _ m | m <= 0 = 0
    p2 xs m = foldl1' (+)
              . map head
              . takeWhile (not . null)
              . iterate (drop m)
              $ xs

(Mostly the same thing, except for the formatting).

> Seems another feature of prototyping is apparent: can't use larger data sets.
> I guess I have also missed some way or other of controlling the prototyping
> interpreter (GHCi) that would make it produce more efficient code, ways that
> would be "obvious" to ... of course ;-)

I usually run ghci in an emacs window so I can kill the window (which
also kills the ghci process) if it goes berserk.  Also run "w" in
another window so you can see the memory consumption climbing in the
case of a space leak.  You can usually ctrl-c out of it if you do it
before the system is pushed into swapping.  Or you could use ulimit to
bound the memory footprint, or run in a VM, or whatever.

Re: If not Ada, what else...

[Paul Rubin]

Paul Rubin <no.email@nospam.invalid> writes:
>     import Data.List (foldl1')   ...
>     p2 xs m = foldl1' (+)

Actually this will fail on an empty list.  Better would be foldl' (+) 0

Re: If not Ada, what else...

[Georg Bauhaus]

On 30.07.15 20:37, Paul Rubin wrote:
> Paul Rubin <no.email@nospam.invalid> writes:
>>      import Data.List (foldl1')   ...
>>      p2 xs m = foldl1' (+)
>
> Actually this will fail on an empty list.  Better would be foldl' (+) 0
>
Down to 7 seconds. Given the component functions of p2, they made
me think about ways of arranging the parallel loops of Ada 2X.
Maybe around Cursor objects and generators.

Re: If not Ada, what else...

[darkestkhan]

On Wednesday, July 29, 2015 at 12:38:43 PM UTC, EGarrulo wrote:
> Why wouldn't Ada be good for hacking?  The only drawback I can see
> does not relate to the language itself, but to the lack of flexible
> standard libraries.  For example, in an experiment comparing the
> productivity of some programming languages[1], and where Haskell 
> comes way ahead of the pack, authors note that "[...] the Haskell
> prototype was most concise for three reasons: [...] (2) the use of
> higher-order functions, and (3) the use of standard list-manipulating
> primitives in the standard [library] Prelude."  Ada supports higher-
> order functions, but it has nothing like the standard library Prelude
> in Haskell, or the STL in C++.  And I find it ironic that Stepanov
> wrote the original version of the C++ STL in Ada, but then it never
> found its way into the Ada standard.

Check Annex A in Ada Reference Manual. You got Ada.Containers.* for standard containers, Ada.Strings.* for string handling (also Unbounded_Strings), Ada.Numerics.*, etc.
There are also Annexes C, D, F and G... (E is far too specific for distributed systems and usually not that much needed in day-to-day basis)

Re: If not Ada, what else...

[rriehle]

As to your comment about books, that is why I wrote Ada Distilled, to provide simple, fully coded, tested examples with line-by-line comments.   Although the Ada 2012 version is not quite ready (Ed Colbert of Absolute Software is updating it), many people still seem to find the Ada 95 version (which includes some 2005 examples) useful as a place to get started.   

You are correct about other things.   Greedy compiler and tool vendors ( with the exception of Meridian and RR Software) were overpricing the product so few hobbyists or start-ups could afford to choose Ada.   Only Meridian provided a fully functional Ada compiler for Windows at a reasonable price.    Janus was a really good compiler, but did not have easy support for Windows programming.   Alsys was huge, cumbersome, too expensive, and not suitable for any small organization.  The Alsys complier did generate some pretty good code, but no one was comcerned about that.  There weren't many other options.   

So, community colleges continued to prefer Turbo-Pascal, a product that wowed everyone at the time.  I talked with Phillipe Kahn about Ada.  He would have loved to have had an opportunity to create a Turbo-Ada, but the timing was wrong, and the opportunity was lost.   The one (and perhaps, only) good thing Reifer did when he was in charge at AJPO was fund the initial work on GNAT.   Once he left AJPO, he began to publicly disparage Ada, and that did not help at all.

The poorly worded letter from Emmett Page set the stage for Ada's quick demise within the DoD.   Now, there is no mandate, and most of the pekple I know in the DoD software community have interpreted that letter as, not simply cancelling the mandate, but cancelling Ada in favor of anything but Ada.   The camcellation of the mandate was a premature and devaststing event, occurring exactly at the moment when Ada, as a language design (Ads 95) was poised for extraordinary success.   


Ada, as a programming language, is still one of the very best for real engineering of software solutions (not so good for Q&D or hacking), but we have very few engineers in software pracrice.   We have lots of talented programmers, but few of them have any engineering background or understanding of engineering.   An interesting outcome of learning Ada, for many of them, was a better understanding of what we really meant by the term, software engineering.   

We, the past and present devotees of Ada, have made a lot of mistakes.   It is not clear that we can recover from the bad impression so many of our software developer colleagues have regarding Ada.   However, the new standard includes some advanced computer science and software engineering features not present in other, if any, software engineering languages: axiomatic program design (Hoare, Dijkstra), predicate calculus expressions, and much more.   

We can, perhaps, rescue Ada's reputation, by reaching out beyond our own narrow community with information about these powerful capabilities.   That can include more academic papers that use Ada, more articles in places that programmers read, offering to teach an Ada class at local colleges, and using Ada for more applications that real people use.   

I am now old, soon to enjoy my 80th birthday.  My time as an advocate will soon have passed.   Perhaps some of you who are younger can find the coursfe and energy to do something to promote real software engineering using the one language designed to support an engineering approach to software development: Ada.  It is, in my view, still Ada.   It is cerainly not C++. Never has been.   Why would anyone choose a language that is inherently error-prone and expect a result that is error-free?

Richard Riehle, PhD

Re: If not Ada, what else...

[Anh Vo]

On Wednesday, August 19, 2015 at 3:19:45 PM UTC-7, rri...@itu.edu wrote:
> As to your comment about books, that is why I wrote Ada Distilled, to provide simple, fully coded, tested examples with line-by-line comments.   Although the Ada 2012 version is not quite ready (Ed Colbert of Absolute Software is updating it), many people still seem to find the Ada 95 version (which includes some 2005 examples) useful as a place to get started.   
> 
> You are correct about other things.   Greedy compiler and tool vendors ( with the exception of Meridian and RR Software) were overpricing the product so few hobbyists or start-ups could afford to choose Ada.   Only Meridian provided a fully functional Ada compiler for Windows at a reasonable price.    Janus was a really good compiler, but did not have easy support for Windows programming.   Alsys was huge, cumbersome, too expensive, and not suitable for any small organization.  The Alsys complier did generate some pretty good code, but no one was comcerned about that.  There weren't many other options.   
> 
> So, community colleges continued to prefer Turbo-Pascal, a product that wowed everyone at the time.  I talked with Phillipe Kahn about Ada.  He would have loved to have had an opportunity to create a Turbo-Ada, but the timing was wrong, and the opportunity was lost.   The one (and perhaps, only) good thing Reifer did when he was in charge at AJPO was fund the initial work on GNAT.   Once he left AJPO, he began to publicly disparage Ada, and that did not help at all.
> 
> The poorly worded letter from Emmett Page set the stage for Ada's quick demise within the DoD.   Now, there is no mandate, and most of the pekple I know in the DoD software community have interpreted that letter as, not simply cancelling the mandate, but cancelling Ada in favor of anything but Ada.   The camcellation of the mandate was a premature and devaststing event, occurring exactly at the moment when Ada, as a language design (Ads 95) was poised for extraordinary success.   
> 
> 
> Ada, as a programming language, is still one of the very best for real engineering of software solutions (not so good for Q&D or hacking), but we have very few engineers in software pracrice.   We have lots of talented programmers, but few of them have any engineering background or understanding of engineering.   An interesting outcome of learning Ada, for many of them, was a better understanding of what we really meant by the term, software engineering.   
> 
> We, the past and present devotees of Ada, have made a lot of mistakes.   It is not clear that we can recover from the bad impression so many of our software developer colleagues have regarding Ada.   However, the new standard includes some advanced computer science and software engineering features not present in other, if any, software engineering languages: axiomatic program design (Hoare, Dijkstra), predicate calculus expressions, and much more.   
> 
> We can, perhaps, rescue Ada's reputation, by reaching out beyond our own narrow community with information about these powerful capabilities.   That can include more academic papers that use Ada, more articles in places that programmers read, offering to teach an Ada class at local colleges, and using Ada for more applications that real people use.   
> 
> I am now old, soon to enjoy my 80th birthday.  My time as an advocate will soon have passed.   Perhaps some of you who are younger can find the coursfe and energy to do something to promote real software engineering using the one language designed to support an engineering approach to software development: Ada.  It is, in my view, still Ada.   It is cerainly not C++. Never has been.   Why would anyone choose a language that is inherently error-prone and expect a result that is error-free?
> 

Happy birthday Richard. 

I am not sure if how many people have read this article. I have enjoyed it very much. As the result, I am proud to say that Ada and Spark doing better than the rest when compared 11 other university projects. This success story will brighten your birthday even more.

http://www.adacore.com/press/spark-going-to-the-moon/

Anh Vo

Re: If not Ada, what else...

[rriehle]

On Wednesday, August 19, 2015 at 3:58:04 PM UTC-7, Anh Vo wrote:
> On Wednesday, August 19, 2015 at 3:19:45 PM UTC-7, rri...@itu.edu wrote:
> > As to your comment about books, that is why I wrote Ada Distilled, to provide simple, fully coded, tested examples with line-by-line comments.   Although the Ada 2012 version is not quite ready (Ed Colbert of Absolute Software is updating it), many people still seem to find the Ada 95 version (which includes some 2005 examples) useful as a place to get started.   
> > 
> > You are correct about other things.   Greedy compiler and tool vendors ( with the exception of Meridian and RR Software) were overpricing the product so few hobbyists or start-ups could afford to choose Ada.   Only Meridian provided a fully functional Ada compiler for Windows at a reasonable price.    Janus was a really good compiler, but did not have easy support for Windows programming.   Alsys was huge, cumbersome, too expensive, and not suitable for any small organization.  The Alsys complier did generate some pretty good code, but no one was comcerned about that.  There weren't many other options.   
> > 
> > So, community colleges continued to prefer Turbo-Pascal, a product that wowed everyone at the time.  I talked with Phillipe Kahn about Ada.  He would have loved to have had an opportunity to create a Turbo-Ada, but the timing was wrong, and the opportunity was lost.   The one (and perhaps, only) good thing Reifer did when he was in charge at AJPO was fund the initial work on GNAT.   Once he left AJPO, he began to publicly disparage Ada, and that did not help at all.
> > 
> > The poorly worded letter from Emmett Page set the stage for Ada's quick demise within the DoD.   Now, there is no mandate, and most of the pekple I know in the DoD software community have interpreted that letter as, not simply cancelling the mandate, but cancelling Ada in favor of anything but Ada.   The camcellation of the mandate was a premature and devaststing event, occurring exactly at the moment when Ada, as a language design (Ads 95) was poised for extraordinary success.   
> > 
> > 
> > Ada, as a programming language, is still one of the very best for real engineering of software solutions (not so good for Q&D or hacking), but we have very few engineers in software pracrice.   We have lots of talented programmers, but few of them have any engineering background or understanding of engineering.   An interesting outcome of learning Ada, for many of them, was a better understanding of what we really meant by the term, software engineering.   
> > 
> > We, the past and present devotees of Ada, have made a lot of mistakes.   It is not clear that we can recover from the bad impression so many of our software developer colleagues have regarding Ada.   However, the new standard includes some advanced computer science and software engineering features not present in other, if any, software engineering languages: axiomatic program design (Hoare, Dijkstra), predicate calculus expressions, and much more.   
> > 
> > We can, perhaps, rescue Ada's reputation, by reaching out beyond our own narrow community with information about these powerful capabilities.   That can include more academic papers that use Ada, more articles in places that programmers read, offering to teach an Ada class at local colleges, and using Ada for more applications that real people use.   
> > 
> > I am now old, soon to enjoy my 80th birthday.  My time as an advocate will soon have passed.   Perhaps some of you who are younger can find the coursfe and energy to do something to promote real software engineering using the one language designed to support an engineering approach to software development: Ada.  It is, in my view, still Ada.   It is cerainly not C++. Never has been.   Why would anyone choose a language that is inherently error-prone and expect a result that is error-free?
> > 
> 
> Happy birthday Richard. 
> 
> I am not sure if how many people have read this article. I have enjoyed it very much. As the result, I am proud to say that Ada and Spark doing better than the rest when compared 11 other university projects. This success story will brighten your birthday even more.
> 
> http://www.adacore.com/press/spark-going-to-the-moon/
> 
> Anh Vo

Thanks, Anh.  I am pleased to see that some good projects are being developed in Ada.  We need to publicize this one, and any others that demonstrate the unique properties of software created with Ada.

My 80th is a few months away, but thanks for the congratulatory note. 

Send me your email address, please.  Mine, my personal email is laoxiaohai@juno.com.   I may have something to send you.    

Richard

Re: If not Ada, what else...

[Peter Chapin]

On Wed, 19 Aug 2015, rriehle@itu.edu wrote:

> On Wednesday, August 19, 2015 at 3:58:04 PM UTC-7, Anh Vo wrote:
>>
>> Happy birthday Richard.
>>
>> I am not sure if how many people have read this article. I have enjoyed 
>> it very much. As the result, I am proud to say that Ada and Spark doing 
>> better than the rest when compared 11 other university projects. This 
>> success story will brighten your birthday even more.
>>
>> http://www.adacore.com/press/spark-going-to-the-moon/
>>
>> Anh Vo
>
> Thanks, Anh.  I am pleased to see that some good projects are being 
> developed in Ada.  We need to publicize this one, and any others that 
> demonstrate the unique properties of software created with Ada.

I am involved with this project at Vermont Technical College where I am 
working with a small group of students on the flight control software. We 
have a web page here:

     http://www.cubesatlab.org/

and a blog here:

     http://cubesatlab.blogspot.com/

Both are a bit sketchy at this time but we hope to enhance them in the 
coming months. The project is looking at a 2018 launch on SLS with 
spacecraft delivery in the second half of 2017. We are in the early stages 
of development... in fact we are still gathering basic requirements. It 
should be fun!

Peter

Re: If not Ada, what else...

[Anh Vo]

> Thanks, Anh.  I am pleased to see that some good projects are being developed in Ada.  We need to publicize this one, and any others that demonstrate the unique properties of software created with Ada.
> 
> My 80th is a few months away, but thanks for the congratulatory note. 
> 
> Send me your email address, please.  Mine, my personal email is laoxiaohai@juno.com.   I may have something to send you.    
> 

Richard, I sent to your private email as you indicated couple days ago. Please check it if it was filtered out. Thanks.

Anh Vo

Re: If not Ada, what else...

[Anh Vo]

On Friday, August 21, 2015 at 8:14:24 AM UTC-7, Anh Vo wrote:
> > Thanks, Anh.  I am pleased to see that some good projects are being developed in Ada.  We need to publicize this one, and any others that demonstrate the unique properties of software created with Ada.
> > 
> > My 80th is a few months away, but thanks for the congratulatory note. 
> > 
> > Send me your email address, please.  Mine, my personal email is laoxiaohai@juno.com.   I may have something to send you.    
> > 
> 
> Richard, I sent to your private email as you indicated couple days ago. Please check it if it was filtered out. Thanks.
> 

Here is another gift for your soon 08th birthday Richard. I got it from The McHale Report <eletter@opensystemsmedia.com>.

http://mil-embedded.com/articles/what-language-ada-its-competition/

Anh Vo

Re: If not Ada, what else...

[Patrick Noffke]

On Friday, August 21, 2015 at 11:07:53 AM UTC-5, Anh Vo wrote:
> 
> http://mil-embedded.com/articles/what-language-ada-its-competition/
> 
What a horrible article.  There is no substance to how Ada is gaining popularity in universities (all they say is that AdaCore is providing them with tools).  

There is not even information, much less substantiation, on how Ada is "undergoing a revival of sorts" or actually gaining in popularity, despite very prominent text claiming so.

Patrick

Re: If not Ada, what else...

[Dmitry A. Kazakov]

On Tue, 21 Jul 2015 19:51:29 +0100, Simon Wright wrote:

> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> 
>> On 15-07-21 19:24 , David Botton wrote:
>>>> if you checked the status of Modula-2 R10?
>>>> (https://bitbucket.org/trijezdci/m2r10)
>>>
>>> My hobby interest for the front end is about Ada (perhaps fixing the
>>> OO syntax, but still Ada).
>>
>> If you remove "tagged", as you said in another post, in my opinion it
>> is no longer Ada (post 95).
> 
>    abstract class type A is
>       procedure P1 (This : in out T) is abstract;
>    end A;
> 
>    class type T is new A with
>       overriding procedure P1 (This : in out A);
>       not overriding function F1 (This : A) return Integer;
>    private
>       V : Integer;
>    end T;
> 
> etc etc; not a million miles from Ada as we know it.

Conceptually it is. Operations do not belong to types.

Then everybody agreed that the syntax of protected objects was a mistake.
Why repeating this flawed syntax for classes? It is again about
fundamentals, privacy is not a type property. It is of a module.

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

Re: If not Ada, what else...

[Simon Wright]

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

> On Tue, 21 Jul 2015 19:51:29 +0100, Simon Wright wrote:

>>    abstract class type A is
>>       procedure P1 (This : in out T) is abstract;
>>    end A;
>> 
>>    class type T is new A with
>>       overriding procedure P1 (This : in out A);
>>       not overriding function F1 (This : A) return Integer;
>>    private
>>       V : Integer;
>>    end T;
>> 
>> etc etc; not a million miles from Ada as we know it.
>
> Conceptually it is. Operations do not belong to types.

Huh?

> Then everybody agreed that the syntax of protected objects was a
> mistake.

I don't remember agreeing

> Why repeating this flawed syntax for classes? It is again about
> fundamentals, privacy is not a type property. It is of a module.

Well, as far as I can see protected types, tasks and (in this
not-to-be-taken-seriously proposal) classes are modules, in a way.

Re: If not Ada, what else...

[Dmitry A. Kazakov]

On Tue, 21 Jul 2015 22:06:54 +0100, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Tue, 21 Jul 2015 19:51:29 +0100, Simon Wright wrote:
> 
>>>    abstract class type A is
>>>       procedure P1 (This : in out T) is abstract;
>>>    end A;
>>> 
>>>    class type T is new A with
>>>       overriding procedure P1 (This : in out A);
>>>       not overriding function F1 (This : A) return Integer;
>>>    private
>>>       V : Integer;
>>>    end T;
>>> 
>>> etc etc; not a million miles from Ada as we know it.
>>
>> Conceptually it is. Operations do not belong to types.
> 
> Huh?

function "*" (X : Matrix; Y : Vector) return Vector;

To which type does "*" belong?

>> Then everybody agreed that the syntax of protected objects was a
>> mistake.
> 
> I don't remember agreeing

The object's private part should not appear in the package's public part.
It is a privacy breach.

>> Why repeating this flawed syntax for classes? It is again about
>> fundamentals, privacy is not a type property. It is of a module.
> 
> Well, as far as I can see protected types, tasks and (in this
> not-to-be-taken-seriously proposal) classes are modules, in a way.

Then they should be compilation units, which would make them unusable. 

Though they are already unusable when more than one type should be
declared. The most typical declaration order is types first:

   type X1 is ...
   type X2 is ...
   procedure Op1 (A : X1);
   procedure Op2 (B : X2; C : X1'Class);
   procedure Op3 (D : X1; E : X2'Class);
   ...
private
   type X1 is ...
   type X2 is ...

It cannot be reordered without a complicated system of forward incomplete
declarations which in the end would dilute the very idea of having type and
operations declared in one place, with brackets put around the place.
(Because the idea is based on a wrong concept)

And of course, there would be no way to derive privately from a more
specific type:

   type Q is new T with private;
private
   type Q is new S with ...;   -- S <: T

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

Re: If not Ada, what else...

[Jeffrey R. Carter]

On 07/21/2015 02:51 PM, Dmitry A. Kazakov wrote:
> On Tue, 21 Jul 2015 22:06:54 +0100, Simon Wright wrote:
> 
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>
>>> Operations do not belong to types.
>>
>> Huh?
> 
> function "*" (X : Matrix; Y : Vector) return Vector;
> 
> To which type does "*" belong?

A concept of programming by extension is that operations on extensible types do
belong to a type. In Ada terms, the operation belongs to the type of the
"controlling parameter". In many languages, the operation is contained in the
type declaration as in the suggested syntax, and the controlling parameter is
implicit.

Since you seem to think that every type should be extensible and all programming
should be by extension, I'd think this concept would be ingrained with you.

-- 
Jeff Carter
"I didn't squawk about the steak, dear. I
merely said I didn't see that old horse
that used to be tethered outside here."
Never Give a Sucker an Even Break
103

Re: If not Ada, what else...

[Dmitry A. Kazakov]

On Tue, 21 Jul 2015 15:55:26 -0700, Jeffrey R. Carter wrote:

> On 07/21/2015 02:51 PM, Dmitry A. Kazakov wrote:
>> On Tue, 21 Jul 2015 22:06:54 +0100, Simon Wright wrote:
>> 
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>>
>>>> Operations do not belong to types.
>>>
>>> Huh?
>> 
>> function "*" (X : Matrix; Y : Vector) return Vector;
>> 
>> To which type does "*" belong?
> 
> A concept of programming by extension is that operations on extensible types do
> belong to a type.

Why?

Anyway, that does not answer the question. To which type belongs
multiplication?

> Since you seem to think that every type should be extensible

Yes, or shrinkable, or exchangeable. The representation of the type values
is an implementation detail.

And, from the strong typing POV the value of another type is of another
type no matter how you obtained that value.

> and all programming should be by extension,

Not at all. Programming shall not be focused on the representation of
values.

> I'd think this concept would be ingrained with you.

On the contrary. I don't share this traditional flawed concept that the
only classes are ones obtained per extension. That indeed leads to the idea
of "true" types/classes and not-so-types, with operations of "true" types
belonging to them, and other operations not deserving much attention, well,
anything that does not fit the concept, does not exist, right?

Ada 83 already had classes of constrained subtypes, like String and String
(n..m), like Integer and Positive, like array and its slice etc. They share
operations.

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

Re: If not Ada, what else...

[Mart van de Wege]

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

> On Tue, 21 Jul 2015 15:55:26 -0700, Jeffrey R. Carter wrote:
>
>> On 07/21/2015 02:51 PM, Dmitry A. Kazakov wrote:
>>> On Tue, 21 Jul 2015 22:06:54 +0100, Simon Wright wrote:
>>> 
>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>>>
>>>>> Operations do not belong to types.
>>>>
>>>> Huh?
>>> 
>>> function "*" (X : Matrix; Y : Vector) return Vector;
>>> 
>>> To which type does "*" belong?
>> 
>> A concept of programming by extension is that operations on extensible types do
>> belong to a type.
>
> Why?
>
> Anyway, that does not answer the question. To which type belongs
> multiplication?
>

I'd say it's a multimethod, being dispatched on all its parameters, not
a member of a type.

Mart

-- 
"We will need a longer wall when the revolution comes."
    --- AJS, quoting an uncertain source.

Re: If not Ada, what else...

[Dmitry A. Kazakov]

On Wed, 22 Jul 2015 11:05:23 +0200, Mart van de Wege wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Tue, 21 Jul 2015 15:55:26 -0700, Jeffrey R. Carter wrote:
>>
>>> On 07/21/2015 02:51 PM, Dmitry A. Kazakov wrote:
>>>> On Tue, 21 Jul 2015 22:06:54 +0100, Simon Wright wrote:
>>>> 
>>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>>>>
>>>>>> Operations do not belong to types.
>>>>>
>>>>> Huh?
>>>> 
>>>> function "*" (X : Matrix; Y : Vector) return Vector;
>>>> 
>>>> To which type does "*" belong?
>>> 
>>> A concept of programming by extension is that operations on extensible types do
>>> belong to a type.
>>
>> Why?
>>
>> Anyway, that does not answer the question. To which type belongs
>> multiplication?
> 
> I'd say it's a multimethod, being dispatched on all its parameters, not
> a member of a type.

A full dispatch, assuming Matrix and Vector unrelated.

Multimethod is a full dispatch with all arguments and the result restricted
to the same types hierarchy, e.g.

   function "*" (Left, Right : Matrix) return Matrix;

E.g.

   X : Sparse_Matrix;
   Y : Band_Matrix;
   Z : Dense_Matrix;
   
   Z := X * Y;

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

Re: If not Ada, what else...

[Simon Wright]

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

> The object's private part should not appear in the package's public
> part.  It is a privacy breach.

To the eye, yes, but not to using software. If I can look at the overall
spec, I can see the private part anyway.

More to the point, devolving the private part of a protected type to the
private part of the enclosing package spec would resolve a lot of
declaration ordering problems; types that could otherwise go in the
private part of the package have to be in the public part.

That's somewhat related to the need for the Implementation package in
the Synchronized_Queues. There'd have been no need if we could have said
something like

   protected type Queue ... is
     new Queue_Interfaces.Queue with
      ...
   end Queue with private;

(rather a lot of 'with's there!)

Re: If not Ada, what else...

[Dmitry A. Kazakov]

On Wed, 22 Jul 2015 08:01:03 +0100, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> The object's private part should not appear in the package's public
>> part.  It is a privacy breach.
> 
> To the eye, yes, but not to using software. If I can look at the overall
> spec, I can see the private part anyway.

You can see bodies as well. What not to eliminate bodies and pack all the
code right at the declaration point?

> More to the point, devolving the private part of a protected type to the
> private part of the enclosing package spec would resolve a lot of
> declaration ordering problems;

Is it an argument for or against it?

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

Re: If not Ada, what else...

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:wubr7sju24uf.1emgiu7iypp5l.dlg@40tude.net...
> On Wed, 22 Jul 2015 08:01:03 +0100, Simon Wright wrote:
...
>> To the eye, yes, but not to using software. If I can look at the overall
>> spec, I can see the private part anyway.
>
> You can see bodies as well. What not to eliminate bodies and pack all the
> code right at the declaration point?

<sarcasm>Why not? That's what Java does, and obviously it's better than Ada 
because it uses curly brackets. </sarcasm>

                          Randy.

Re: If not Ada, what else...

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lyegk1jk41.fsf@pushface.org...
...
>> Why repeating this flawed syntax for classes? It is again about
>> fundamentals, privacy is not a type property. It is of a module.
>
> Well, as far as I can see protected types, tasks and (in this
> not-to-be-taken-seriously proposal) classes are modules, in a way.

Why use "sort-of modules" when Ada already has strong, well-designed 
modules? That's the main argument given by the Ada 9x team, and I for one 
have a hard time arguing that.

Languages with the "class = module" property never had any modules in the 
first place. They confused the benefits of modules with the (smaller) 
benefits of O-O. And so on. (If all you have is a hammer, everything looks 
like a nail...)

                                                  Randy.

Re: If not Ada, what else...

[Simon Wright]

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

> "Simon Wright" <simon@pushface.org> wrote in message 
> news:lyegk1jk41.fsf@pushface.org...
> ...
>>> Why repeating this flawed syntax for classes? It is again about
>>> fundamentals, privacy is not a type property. It is of a module.
>>
>> Well, as far as I can see protected types, tasks and (in this
>> not-to-be-taken-seriously proposal) classes are modules, in a way.
>
> Why use "sort-of modules" when Ada already has strong, well-designed
> modules? That's the main argument given by the Ada 9x team, and I for
> one have a hard time arguing that.

What I meant was that protected types, in particular, already have
private parts which are textually, but not programmatically, visible in
the public part of packages.

Re: If not Ada, what else...

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:ly1tfszqlf.fsf@pushface.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> "Simon Wright" <simon@pushface.org> wrote in message
>> news:lyegk1jk41.fsf@pushface.org...
>> ...
>>>> Why repeating this flawed syntax for classes? It is again about
>>>> fundamentals, privacy is not a type property. It is of a module.
>>>
>>> Well, as far as I can see protected types, tasks and (in this
>>> not-to-be-taken-seriously proposal) classes are modules, in a way.
>>
>> Why use "sort-of modules" when Ada already has strong, well-designed
>> modules? That's the main argument given by the Ada 9x team, and I for
>> one have a hard time arguing that.
>
> What I meant was that protected types, in particular, already have
> private parts which are textually, but not programmatically, visible in
> the public part of packages.

Protected types were intended to look like tasks, and they're clearly a bad 
design in the sense that they don't mesh well with the existing powerful 
modularity features. (The subpackage Implementation in the queue containers 
is exhibit A of that.) Adding a "class type" with similar syntax would have 
caused the same disaster, only worse. (Ada does *not* allow nested types, 
thus it would be impossible to encapsulate related types like enumerations 
and to a lesser extent access types [lesser only because of anonymous 
access, but that's another mistake -- sometimes two wrongs do make a right - 
;-)]. It would be very hard to allow nested types in general [I looked 
extensively at allowing some kinds of types in the private part of a 
protected type, and it would work so long as it was quite limited and none 
of the types was ever visible - still a lot weaker solution than an Ada 
package].

                                                 Randy.

Re: If not Ada, what else...

[Simon Wright]

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

> (The subpackage Implementation in the queue containers is exhibit A of
> that.)

I seem to remember that Martin Dowie and I had some input into this
practical but warty solution! (or "hack", I suppose)

Was there some reason why we don't have - for example -

   protected type P is
      --  publicly visible subprograms
   end P with private;

and the private part of P declared in the private part of the package?

   protected type P is
      --  publicly visible subprograms
   private
      --  etc, as now
   end P;

Re: If not Ada, what else...

[vincent.diemunsch]

Le mercredi 29 juillet 2015 09:11:47 UTC+2, Simon Wright a écrit :
> Was there some reason why we don't have - for example -
> 
>    protected type P is
>       --  publicly visible subprograms
>    end P with private;
> 
> and the private part of P declared in the private part of the package?
> 
>    protected type P is
>       --  publicly visible subprograms
>    private
>       --  etc, as now
>    end P;

or in the private part :

for protected type P use record
   -- etc, as now
 end record;

then in the body exactly the same as what we have.

Vincent

Re: If not Ada, what else...

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lyoaivxwr8.fsf@pushface.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> (The subpackage Implementation in the queue containers is exhibit A of
>> that.)
>
> I seem to remember that Martin Dowie and I had some input into this
> practical but warty solution! (or "hack", I suppose)
>
> Was there some reason why we don't have - for example -
>
>   protected type P is
>      --  publicly visible subprograms
>   end P with private;
>
> and the private part of P declared in the private part of the package?
>
>   protected type P is
>      --  publicly visible subprograms
>   private
>      --  etc, as now
>   end P;

I don't think it was ever considered. One of the advantages of the current 
scheme (from a language definition perspective, obviously not from a usage 
perspective) is that everything is available in one place, so the nasty 
problems of when is something available don't come up. Getting that right 
for a separated private part would be tricky.

There have been occassional proposals to let the private part of a package 
be compiled separately; that's relatively easy to accomplish within the GNAT 
compilation model (which doesn't generate anything for package specification 
anyway) but would be an earthquake for a library-based model where code is 
generated for every unit. This idea would seem to suffer from similar issues 
unless it was limited only to package specifications (which seems clunky).

Anyway, it might make sense to propose something -- the problem of hiding 
types to be used in the implementation of a protected type is not going to 
go away.

                                 Randy.

Re: If not Ada, what else...

[Vincent]

Le mardi 21 juillet 2015 21:51:39 UTC+2, Dmitry A. Kazakov a écrit :
> On Tue, 21 Jul 2015 19:51:29 +0100, Simon Wright wrote:
> 
> > Niklas Holsti writes:
> > 
> >> On 15-07-21 19:24 , David Botton wrote:
> >>>> if you checked the status of Modula-2 R10?
> >>>> (https://bitbucket.org/trijezdci/m2r10)
> >>>
> >>> My hobby interest for the front end is about Ada (perhaps fixing the
> >>> OO syntax, but still Ada).
> >>
> >> If you remove "tagged", as you said in another post, in my opinion it
> >> is no longer Ada (post 95).
> > 
> >    abstract class type A is
> >       procedure P1 (This : in out T) is abstract;
> >    end A;
> > 
> >    class type T is new A with
> >       overriding procedure P1 (This : in out A);
> >       not overriding function F1 (This : A) return Integer;
> >    private
> >       V : Integer;
> >    end T;
> > 
> > etc etc; not a million miles from Ada as we know it.
> 
> Conceptually it is. Operations do not belong to types.

But ARM, says :
---
3.2 Types and Subtypes
Static Semantics
1 A type is characterized by a set of values, and a set of primitive operations which implement the fundamental aspects of its semantics. An object of a given type is a run-time entity that contains (has) a value of the type.
----

So for me a type has both a set of values and a set of primitive operations.
A class type is simply a handler, an access or an interface, whatever one
calls it, to a class of types where each actual type has at least all of the primitive operations of the class.

Therefore, I find the above syntax of Simon not completely irrelevant, to say the least :-).


> 
> Then everybody agreed that the syntax of protected objects was a mistake.
> Why repeating this flawed syntax for classes? It is again about
> fundamentals, privacy is not a type property. It is of a module.

Who said that ?

Regards,

Vincent

Re: If not Ada, what else...

[Dmitry A. Kazakov]

On Wed, 22 Jul 2015 05:53:05 -0700 (PDT), Vincent wrote:

> So for me a type has both a set of values and a set of primitive operations.

Set of *all* operations defined on.

That still does not make operations belong to any type. An operation may
take number of types.

> A class type is simply a handler, an access or an interface, whatever one
> calls it,

Class type T'Class is the type representing values of all types derived
from T. It is not a handler, not an access, not an interface, just a type.

>> Then everybody agreed that the syntax of protected objects was a mistake.
>> Why repeating this flawed syntax for classes? It is again about
>> fundamentals, privacy is not a type property. It is of a module.
> 
> Who said that ?

I explained in other subthread. It breaks privacy and its syntax is
irregular.

It should have been kind of:

   type T is protected private;
   type T is protected record ...

and surely one should be able to derive from it or add the "protected"
aspect later to a non-protected type.

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

Re: If not Ada, what else...

[J-P. Rosen]

Le 21/07/2015 20:51, Simon Wright a écrit :
>    abstract class type A is
>       procedure P1 (This : in out T) is abstract;
>    end A;
> 
>    class type T is new A with
>       overriding procedure P1 (This : in out A);
>       not overriding function F1 (This : A) return Integer;
>    private
>       V : Integer;
>    end T;
> 
> etc etc; not a million miles from Ada as we know it.
And how would you make the difference between specific and class-wide
types? (A huge advantage of Ada over other OO models, IMHO)

-- 
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: If not Ada, what else...

[Simon Wright]

"J-P. Rosen" <rosen@adalog.fr> writes:

> Le 21/07/2015 20:51, Simon Wright a écrit :
>>    abstract class type A is
>>       procedure P1 (This : in out T) is abstract;
>>    end A;
>> 
>>    class type T is new A with
>>       overriding procedure P1 (This : in out A);
>>       not overriding function F1 (This : A) return Integer;
>>    private
>>       V : Integer;
>>    end T;
>> 
>> etc etc; not a million miles from Ada as we know it.
> And how would you make the difference between specific and class-wide
> types? (A huge advantage of Ada over other OO models, IMHO)

I have no idea, and I don't want to; just that someone said that
dropping the word 'tagged' would make the language not Ada. 

Re: If not Ada, what else...

[Shark8]

On Tuesday, July 21, 2015 at 2:05:53 PM UTC-6, J-P. Rosen wrote:
>
> And how would you make the difference between specific and class-wide
> types? (A huge advantage of Ada over other OO models, IMHO)

Good question.
One of the things that other OO-models get wrong is to shove everything into 'class' thus ignoring the fact the type is NOT the hierarchy-of-types rooted at that type. (ie. implicit conversion down that hierarchy.)

Though I don't see why the proposal couldn't use the 'Class attribute to do that, the bigger problem [IMO] is that by calling this a "class type" you are blurring the lines between that hierarchy and the actual type.

Re: If not Ada, what else...

[vincent.diemunsch]

Le mardi 21 juillet 2015 22:05:53 UTC+2, J-P. Rosen a écrit :
> Le 21/07/2015 20:51, Simon Wright a écrit :
> >    abstract class type A is
> >       procedure P1 (This : in out T) is abstract;
> >    end A;
> > 
> >    class type T is new A with
> >       overriding procedure P1 (This : in out A);
> >       not overriding function F1 (This : A) return Integer;
> >    private
> >       V : Integer;
> >    end T;
> > 
> > etc etc; not a million miles from Ada as we know it.
> And how would you make the difference between specific and class-wide
> types? (A huge advantage of Ada over other OO models, IMHO)
> 
> -- 
> 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

Hello Jean-Pierre,

Simply by declaring an operation OUTSIDE the class type declaration as :

Procedure Class_Wide_Operation (Object : in out T, X : integer);

Only primitive operations are in the class type declaration. This is very intuitive since you can in a way "see" the dispatch table associated to the record.

Regards,

Vincent

Re: If not Ada, what else...

[J-P. Rosen]

Le 22/07/2015 14:58, vincent.diemunsch@gmail.com a écrit :
> Simply by declaring an operation OUTSIDE the class type declaration
> as :
> 
> Procedure Class_Wide_Operation (Object : in out T, X : integer);
> 
> Only primitive operations are in the class type declaration. This is
> very intuitive since you can in a way "see" the dispatch table
> associated to the record.

No, that won't do it. You may want to define operations (that are not
methods) for a specific type, or for the class-wide type rooted at the
specific type. I don't think you can avoit the 'Class, which basically
brings us to the current solution (where you write "package ... is"
instead of "class ... is")

-- 
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: If not Ada, what else...

[Vincent]

Le mercredi 22 juillet 2015 15:40:08 UTC+2, J-P. Rosen a écrit :
> You may want to define operations (that are not methods) for a specific 
> type, or for the class-wide type rooted at the specific type.
> I don't think you can avoit the 'Class, which basically
> brings us to the current solution (where you write "package ... is"
> instead of "class ... is")

It simply takes the opposite view : instead of having a tagged type in Ada
and the need to add the 'Class to speak of the whole class derived from it,
you have the class type that represents any member of the class (as T'Class)
and you need to have something like CT'Root_Type.

Regards,

Vincent



> -- 
> 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: If not Ada, what else...

[David Botton]

> If you remove "tagged", as you said in another post, in my opinion it is 
> no longer Ada (post 95).

It certainly would not be backward compatible at least with that feature to Ada '95. As for the name Ada, even that is a question of worth, the name (in particular in the US) has been burned (mandate, licenses, etc.) and is a marketing fiasco for the most part. If I ever did go through with all the work to complete a new compiler, I'd really have to think about how closely I'd want to associate with the name Ada anyways. (Although obviously the base language is good stuff).

David Botton

Re: If not Ada, what else...

[Shark8]

On Thursday, August 20, 2015 at 10:40:50 PM UTC-6, polymorph self wrote:
> 
> CAn ada hang with lisp and haskell as far as abstraction and programming in the large?

For programming in the large, Ada is *REALLY* good -- as an example the YF-22 software consisted of 12 major avionics subsystems, across 650 modules, and 8 geographically separated contractors... and the integration took only 3 days.

There was a video on youtube of a Symbolics Ada [Ada implemented in Lisp] which. I think, would be really interesting for you. Unfortunately the video has been made private,, though Ada is mentioned on wikipeda here: https://en.wikipedia.org/wiki/Genera_%28operating_system%29#Other_languages_from_Symbolics

YouTube link, in case it ever becomes non-private: https://www.youtube.com/watch?v=r7hD_Ro75zo&feature=youtu.be

Re: If not Ada, what else...

[David Botton]

> CAn ada hang with lisp and haskell as far as abstraction and programming in the large?

You are joking right. I wouldn't consider anything but Ada for programming in the large, certainly not lisp or haskell which have their place in the system at times.

Re: If not Ada, what else...

[Paul Rubin]

David Botton <david@botton.com> writes:
>> I was aware of SPARK before that, when it was a separate expensive tool
> So now an expensive vendor tool is still an expensive vendor tool

But now there's a free version of SPARK, a big change.

> We are talking about Ada not SPARK. If you like SPARK and it fits your
> needs great.

Well, I'm thinking of SPARK as a component of Ada-2012.  Maybe that's
not exactly right but there's some conceptual sense to it.

> So in C++ you can create new incompatible types with various ranges,
> use them for array indexes, true enums?

I'm no C++ expert but I believe it has real enums (i.e. typed), unlike C
enums.  And since you can overload the [] operator and use whatever you
want as indexes, making incompatible range types and using them as
indexes is straightforward though a bit cumbersome.  It wouldn't
surprise me if there's a package for it (using templates) already.

> That is what you don't understand, Ada is about compile time checks
> and that comes with contacts. Contracts on the types, contracts on the
> interfaces.

Historically AFAIK range types in Ada were not statically checked.
Checking them is very complicated and can be partly automated these days
with SMT solvers, but in general you'd need proof assistants and lots of
manual effort.  Are we talking about the same thing?

> Well, once upon a time Ada compilers were certified. I don't believe
> AdaCore does that anymore.

There was some federal agency that did it, I thought.  It was eventually
shut down after it had served its purpose, which was getting
standardization to really mean something.

> And if you use Ada long enough you learn to use the Stack most of the
> time to accomplish the same thing and you don't get sloppy which tends
> to happen to GC dependent programmers.

This is no different from C++.  The usefulness of GC depends on what
kinds of programs you're writing, so it's true, lots of code doesn't
need it, but for some, it's great.  C++ programs these days use
reference counted smart pointers, which are a poor man's GC.

> Ada does have a GC in some implementations as I pointed out. You are
> having trouble separating language from runtime environment. A GC in
> Ada or D is something you can choose to use.

Yes, I'm just not sure why to use a GC in Ada.  If you can afford a GC's
overhead and accept the non-determinism it creates, why use Ada in the
first place, instead of something like Haskell?  I guess there might be
some situations.  But I mostly find Ada attractive for exactly the
problems in which GC is unattractive or unfeasible.

> BTW, I've never had the need but there are ways to use a GC even the
> current GNAT's on most platforms.

That's interesting and I'll look into it.

>> GC'd languages that support functional-programming idioms
> You can use D in that environment, although Ada is better at it. Repl
> clauses, etc. are also pluses.

Not sure what a repl clause is.  Ada doesn't support FP style very well,
which is fine because that was never its goal.

>> I consider [C and C++] ... to be niche languages
> No still general purpose. You need to look at the language itself to
> make that determination not just how it is being used currently.

I'd say you have to look at the problems people are trying to solve, and
the technology available for solving them.  These days most programming
is done on very powerful, underutilized cpus with tons of memory
compared to the problem, so GC'd languages are generally the most
productive approach for those applications.

> C and C++ are still heavily used in general use cases, from embedded
> to UI and Game Dev, etc.

Embedded is a niche, UI should be done in other languages these days,
and game dev is somewhat special because it's often realtime.  One of
the most successful games (Minecraft) was written in Java though, lots
of games use a combination of C++ and Lua, and there's this:
https://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf

> If anything C#, Python, Java are more niche, just their niche is where
> the vast majority of programs and programmers are. You would be a fool
> to use any of the three in anything critical (safety, time, etc.)

If the vast majority of programs and programmers are in a particular
place, then that place is by definition mainstream and not a niche ;-).
Only a few programmers are doing safety or time critical things, so THAT
is a niche.  But, an awful lot of mainstream programs and programmers
now are doing internet applications, which brings security concerns that
make unsafe languages like C problematic.  Ada might be ok if you leave
all the runtime checks enabled, though there's still a productivity
issue.  There's also no implementation that I know of with lightweight
multitasking like Go, so that cramps you if you want to run
high-concurrency servers.

> Even Haskell, OCAML, etc. are fairly niche. All the scripting
> languages are niche.

Scripting is mainstream in that it's how most stuff is being written.
Haskell and Ocaml are niche because while they have fairly broad
applicability, there's not much of a userbase and it's not clear that
Haskell has significant advantages for the typical CRUD app (Ocaml might
make more sense).  Or if you want something really "out there",
http://www.impredicative.com/ur/ might be of interest.

> Ada, D, C, C++ are all geared for full range dev across the entire
> spectrum. Ada due to external issues in tool and compiler availability
> is the more limited currently, but almost as broad.

Just because you CAN write something in Ada, D, C, C++, Forth, Assembler
etc. (those languages can all do pretty much anything) doesn't mean that
there's not a more effective alternative in a particular area.  What I'd
say is those languages are most effective in areas that are (as of 2015)
somewhat specialized in the way I see things.  Full range devs should be
able to use them when the task calls for it, but most tasks these days
probably don't.

Re: If not Ada, what else...

[J-P. Rosen]

Le 11/07/2015 04:31, Paul Rubin a écrit :
>> Well, once upon a time Ada compilers were certified. I don't believe
>> > AdaCore does that anymore.
> There was some federal agency that did it, I thought.  It was eventually
> shut down after it had served its purpose, which was getting
> standardization to really mean something.
> 
You are confusing two different things here. The AJPO (Ada Joint Program
Office) was a government agency established to start and develop the
language. It was closed when the language was considered grown up. It
was not in charge of validation.

There is a an organization, the ACAA (Ada Conformity Assesment
Authority) in charge of validation, whose "technical agent" is Randy
Bruckardt, and an ACAL (Ada Compiler Assesment Laboratory), currently
Adalog, in charge of doing the validations.

So the whole structure is in place if a vendor asks to validate its
compiler. What happens is that since the major customers don't require
validated compilers any more, and since validation is quite expensive,
nobody does it anymore. But if a big customer of AdaCore said they would
sign the contract only if the compiler is officially validated, I'm sure
AdaCore would do it.

There is also a kind of side effect of validation: it is so much
connected to the Ada spirit that every compiler keeps passing the
validation internally, and all the users know that the compiler is
passing the validation internally - therefore reducing the need for
official validation. AdaCore even provides a certificate of "internal
validation" without official value, but good enough for most customers.

-- 
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: If not Ada, what else...

[Georg Bauhaus]

On 11.07.15 04:31, Paul Rubin wrote:

> Historically AFAIK range types in Ada were not statically checked.
> Checking them is very complicated and can be partly automated these days
> with SMT solvers, but in general you'd need proof assistants and lots of
> manual effort.

The expressly bounded, named types of Ada to me are fundamental to sorting
things out. In many ways, for example: how could one find a function
from integers into integers to be from N -> {0, 1, ..., 10}, actually,
if there was no better way to specify the set of values in a type than
by saying "int"? Knowing more about the sets continues transitively, and
this knowledge is reflected in the definitions of user defined fundamental
types (with ranges etc.). They also match the problem description.

In C, when a function returns negative, this typically means one of the
known errors, or about |0 - INT_MIN| possible cases of overflow or worse.
How do we learn about the image that the function was supposed to compute?
Read comments? Studying the full source?

The existence, and perhaps proliferation of fusion into Haskell programs
OTOH turns them into mathematical riddles. I wonder if that's just what
fans of Haskell might like doing? Turning some simple Haskell equations
into fusioned somethings for reasons of *controlling* performance in time
vs space, which, IIUC, were not part of Haskell's design. They are not an
integral part of its expressive apparatus. (Sadly.) So we get to see
efficient manipulations of data in Haskell using all kinds of primitives
and strict so that code looks just like some kind of new, operation-
oriented  assembly language, using a fancy equational machine.

> Embedded is a niche,

I understand that embedded covers about half of the market of all
things that have computers in them. I don't know whether that's
money-wise or installation-wise.  Perhaps awareness isn't half, too.

Re: If not Ada, what else...

[Dmitry A. Kazakov]

On Sat, 11 Jul 2015 09:51:07 +0200, Georg Bauhaus wrote:

> On 11.07.15 04:31, Paul Rubin wrote:
> 
>> Historically AFAIK range types in Ada were not statically checked.
>> Checking them is very complicated and can be partly automated these days
>> with SMT solvers, but in general you'd need proof assistants and lots of
>> manual effort.
> 
> The expressly bounded, named types of Ada to me are fundamental to sorting
> things out. In many ways, for example: how could one find a function
> from integers into integers to be from N -> {0, 1, ..., 10}, actually,
> if there was no better way to specify the set of values in a type than
> by saying "int"? Knowing more about the sets continues transitively, and
> this knowledge is reflected in the definitions of user defined fundamental
> types (with ranges etc.).

Partially. Ada 83 didn't make it fully static, because it disregarded
operations. It is not enough to declare a range or, more generally, the set
of values to define a type. Because type includes operations. E.g. the
numbers 1..10 may not have unary minus, as they don't have inverses.

What Ada 83 did to resolve the problem was less typing. It relaxed
contracts to uphold them. Constraint_Error was added to the contracts of
all operations. Ada simplified issues with intermediate results by making
them of the base type (C used type promotion for this). This was a
compromise, but compromises never win.

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

Re: If not Ada, what else...

[Luke A. Guest]

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

>> C and C++ are still heavily used in general use cases, from embedded
>> to UI and Game Dev, etc.
> 
> Embedded is a niche, UI should be done in other languages these days,
> and game dev is somewhat special because it's often realtime.  One of
> the most successful games (Minecraft) was written in Java though, lots
> of games use a combination of C++ and Lua, and there's this:
> https://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf

I happen to believe that Ada is perfect for games. I'm producing the
current SDL2 bindings. I have a GL generator that just needs to generate
the GL bindings now. I will be binding Vulkan once it's out and I have a
project in mind to prove my ideas.

Luke

Assertions in SPARK (Was: If not Ada, what else...)

[Jacob Sparre Andersen]

Paul Rubin wrote:

> I remember being disappointed that (unless I missed something) there
> doesn't seem to be a way to put assertions in the middle of a function
> body and have Spark check them statically.  Am I mistaken about that?

You are.  I don't have a SPARK book right here, but IIRC it is simply:

   --# assert <expression>

Greetings,

Jacob
-- 
»Great minds discuss ideas,
 Average minds discuss events,
 Small minds discuss people.«

Re: Assertions in SPARK (Was: If not Ada, what else...)

[G.B.]

On 27.07.15 11:09, Jacob Sparre Andersen wrote:
> Paul Rubin wrote:
>
>> I remember being disappointed that (unless I missed something) there
>> doesn't seem to be a way to put assertions in the middle of a function
>> body and have Spark check them statically.  Am I mistaken about that?
>
> You are.  I don't have a SPARK book right here, but IIRC it is simply:
>
>     --# assert <expression>

Also worth considering is

--# check <expression>

which is different from assert in that is doesn't change
SPARK's mind about where the interesting points in the
paths are.

Re: Assertions in SPARK (Was: If not Ada, what else...)

[Peter Chapin]

On Mon, 27 Jul 2015, G.B. wrote:

>>> I remember being disappointed that (unless I missed something) there 
>>> doesn't seem to be a way to put assertions in the middle of a function 
>>> body and have Spark check them statically.  Am I mistaken about that?
>> 
>> You are.  I don't have a SPARK book right here, but IIRC it is simply:
>>
>>     --# assert <expression>
>
> Also worth considering is
>
> --# check <expression>
>
> which is different from assert in that is doesn't change SPARK's mind 
> about where the interesting points in the paths are.

The SPARK2014 version of these constructions are pragma Assert (similar to 
the check annotation) and pragma Assert_And_Cut (similar to the assert 
annotation). They are checked statically by the SPARK proof tools.

Peter

Re: If not Ada, what else...

[Pascal Obry]

Le jeudi 09 juillet 2015 à 21:26 -0700, Paul Rubin a écrit :
> David Botton <david@botton.com> writes:
> > You could say that about every version even the first. 
> 
> Well, the big win of Ada 2012 is SPARK integration, it seems to me.

Agreed. In some applications I have been able to replace comments by
pre/post condition. Far better to me and then checked at runtime.

For example relationship between 2 routines parameters (if A is True
then B cannot be zero) can be expressed by a pre condition. This is
really going in the right direction to me.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B