Ada Successor Language

Ada Successor Language

[Shark8]

	It occurs to me that in order to design a successor to Ada, there’s not merely one language that ought to be defined — but five — and the reason is that Ada is several languages all at once: there’s a language for generics, a language for proofs [SPARK], low-level hardware, and a language for tasking in addition to the Ada that maps to “normal” programming languages.
	One of the frustrations about Ada as-it-is is that there is a lot that seems like it could be “folded together”, things like (eg) all the Ada.[Wide_[Wide_]]Strings packages. Or, some sort of mechanism for [explicitly] showing the relationships between types.
	In order to do that we would need some sort of meta-language, wherein all the rest of the languages (ideally both syntactic and semantic) could be defined.

(1)	The Meta language
(2)	The Generic Language
(3)	The Concurrent/Parallelism language
(4)	The Proving language [SPARK]
(5)	The HW/Representation language

----------
Your thoughts?

Re: Ada Successor Language

[Luke A. Guest]

Shark8 <> wrote:

> 
> (1)	The Meta language
> (2)	The Generic Language
> (3)	The Concurrent/Parallelism language
> (4)	The Proving language [SPARK]
> (5)	The HW/Representation language
> 
> ----------
> Your thoughts?
> 

There’s a guy, eLucian, wanting to implement his own language because Ada
is too complex, his is level, where he has defined 5 compilers all written
in different languages with different capabilities. I don’t agree with
that, it’s way too complex! Plus, he wants others to do the work while he
makes the money on it, no thanks.

You could just use SML and implant those five things with that. But I
disagree there too.

Any successor needs to be much simpler in design but not scope. We should
retain multi-paradigm programming imperative and OOP, but increase that
with FP - I’m coming around to FP more, but it’s not the be all and end
all.

The grammar needs to be easier to implement so that tools can be developed
much more quickly. Simplify the grammar, maybe look at python and ruby for
hints on syntax structure.

Any successor needs to retain what Ada can do but also do things better
where Ada struggles and add features for modern programming. This new
language needs to retain the ability to develop anything from small
embedded to server, distributed and bigger applications.

One thing which makes Ada complicated from the compiler perspective is the
ability to take multiple compilation units at a time and the fact it’s
defined as being able to take them in one source file, I’d simplify that
and separate out the idea of a program, I do like not having to define a
“main” though.

I’ve said it before and it needs to be said again, a new language needs to
be Unicode from the start using UTF-8, text manipulation in Ada is painful
at this current stage. For embedded we can also define 8-bit character
sets. It needs real strings and a fully capable library.

We should adopt the common C shorthand operators, -=, +=, etc. Which means
picking a different /= operator, may as well use != here too.

Being able to override ‘image ‘value would be really useful, for custom
types, e.g. outputting a record in json format for example. Imagine a
custom image for an enumeration!

Parallel blocks, yes I know it’s coming, but it’s something that should
still exist in any new language. In fact as much tasking capabilities as
possible given how many cores we have now.

Keep the concept of restrictions and profiles/subsets.

Keep packages.

Support endian-ness from the start even on primitive types, I.e. not just
records.

The runtime needs to be permissively license to attract users.

My initial thoughts. I have other frustrations I can’t think of right now.

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-02 06:43, Shark8 wrote:
> 	It occurs to me that in order to design a successor to Ada, there’s not merely one language that ought to be defined — but five — and the reason is that Ada is several languages all at once: there’s a language for generics, a language for proofs [SPARK], low-level hardware, and a language for tasking in addition to the Ada that maps to “normal” programming languages.
> 	One of the frustrations about Ada as-it-is is that there is a lot that seems like it could be “folded together”, things like (eg) all the Ada.[Wide_[Wide_]]Strings packages. Or, some sort of mechanism for [explicitly] showing the relationships between types.
> 	In order to do that we would need some sort of meta-language, wherein all the rest of the languages (ideally both syntactic and semantic) could be defined.
> 
> (1)	The Meta language
> (2)	The Generic Language
> (3)	The Concurrent/Parallelism language
> (4)	The Proving language [SPARK]
> (5)	The HW/Representation language
> 
> ----------
> Your thoughts?

You forgot:

(6)  The language of type declarations

As for #1, that is possible to do, but then you will have just one more 
language on top of others. You cannot fuse meta- and object languages.

What one can do is to completely throw away #2 and merge reduced #5 with #6.

P.S. I don't understand this push for a new language. There are only few 
mistakes made in Ada with cannot be worked around. And there are 
problems unresolved on the theoretical level, like handling MD.

A new language solves nothing unless being conceptually new. Languages 
created in recent 30 years perfectly illustrate this thesis.

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

Re: Ada Successor Language

[Mehdi Saada]

> I don't understand this push for a new language.
Haven't you complained already how such or such area is unlikely to even be fixed because of backward compatibility ?
> We should adopt the common C shorthand operators, -=, +=, etc.
What's the problem with @ ? It's more elegant and versatile.

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-02 14:14, Mehdi Saada wrote:
>> I don't understand this push for a new language.
> Haven't you complained already how such or such area is unlikely to even be fixed because of backward compatibility ?

In most cases it is merely an excuse to reject a change. Most changes 
can be made keeping everything compatible.

E.g. for renaming one can use an alternative syntax (which is needed 
anyway) and let the old renaming slowly die.

>> We should adopt the common C shorthand operators, -=, +=, etc.
> What's the problem with @ ? It's more elegant and versatile.

You mean @ for idem as in

    X := Idem + 1;

It is semantically problematic because it limits the implementation or 
forces a wrong implementation in case of temporal, volatile, shared 
objects. A special operator would allow implementation via proper procedure.

It is analogous to automatic dereferencing and indexing. There will be 
no solution to until these operations will be done via user-defined 
procedure. No number of kludges and obscure helper type will ever work. 
Assignment is no different.

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

Re: Ada Successor Language

[Luke A. Guest]

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

>> We should adopt the common C shorthand operators, -=, +=, etc.
> What's the problem with @ ? It's more elegant and versatile.
> 

The proposal is to use +:=, -:=, etc which is ok but a little weird. The
other proposal is to use @ as the lhs shorthand.

Re: Ada Successor Language

[Dan'l Miller]

On Friday, June 1, 2018 at 11:43:52 PM UTC-5, Shark8 wrote:
> It occurs to me that in order to design a successor to Ada, there’s not merely one language that ought to be defined — but five — and the reason is that Ada is several languages all at once: there’s a language for generics, a language for proofs [SPARK], low-level hardware, and a language for tasking in addition to the Ada that maps to “normal” programming languages.
> 	One of the frustrations about Ada as-it-is is that there is a lot that seems like it could be “folded together”, things like (eg) all the Ada.[Wide_[Wide_]]Strings packages. Or, some sort of mechanism for [explicitly] showing the relationships between types.
> 	In order to do that we would need some sort of meta-language, wherein all the rest of the languages (ideally both syntactic and semantic) could be defined.
> 
> (1)	The Meta language
> (2)	The Generic Language
> (3)	The Concurrent/Parallelism language
> (4)	The Proving language [SPARK]
> (5)	The HW/Representation language

On Saturday, June 2, 2018 at 3:12:25 AM UTC-5, Dmitry A. Kazakov wrote:
> (6)  The language of type declarations

The successor to Ada should be hypoAda
a) that allows writing today's Ada as a library/personality
and
b) that allows writing a somewhat different Ada as an alternate personality.
That way all the backwards compatibility issues can be merely labeled as historical legacy in today's Ada, not brought over to hyperAda, but expressible in hypoAda so as to support today's Ada in the same compiler.

Note that something like hyperAda would be a better working name than succAda (successor to Ada) or even Ada++ (unless the next-gen Ada was to import much of C/C++'s symbol syntax:  ++, --, &, &&, {}, and so forth).  Btw, today's Ada needs a nickname too—perhaps Ada8652 from the ISO standard number.

Seed7 (a somewhat-Ada derivative) and Alphard (Carnegie-Mellon's 1970's research language) have already explored some of these hypoAda topics.  Alphard even had a sublanguage way of writing the syntax of various language's looping constructs;  Seed7 approaches the topic differently, but accomplished much the same result.

There should be some sort of ground-rules for hyperAda so that it doesn't go far afield with, say, C-family syntax as merely being a cousin of Rust.

Byron seeks to be modular in the backend to permit LLVM or libFirm or GIMPLE-RTL.  Byron could also be modular in the ‘lower-front-end’ so to speak to permit alternative Ada-esque personalities of front-end ••in the same compiler••, choosable on the compiler's command-line, as if the Ada-esque personality ‘upper-frontend’ were a pluggable DLL to the compiler:
A) today's Ada8652
B) Ada-merged-with-SPARK
C) Pascal-family-syntaxed hyperAda, leaving backwards compatibility behind in choices A and/or B
D) even Ada(-or-hyperAda)-semantics-expressed-C-crypto-syntax instead of Pascal syntax:  Ada with braces instead of begin/end, and a hundred other syntactic transliterations
E) and so forth.

Safety of user-defined operators (was: Ada Successor Language)

[G.B.]

On 02.06.18 14:43, Dmitry A. Kazakov wrote:

> It is semantically problematic because it limits the implementation or forces a wrong implementation in case of temporal, volatile, shared objects. A special operator would allow implementation via proper procedure.
> 
> It is analogous to automatic dereferencing and indexing. There will be no solution to until these operations will be done via user-defined procedure. No number of kludges and obscure helper type will ever work. Assignment is no different.
> 

What set of guarantees can user-defined Ada offer, in comparison,
when users will provide those operations to the compiler that are
now guarandteed by the language? (Where to "draw the line"?)

Example:

- typed, indexed RAM (array),

as opposed to

- typed, indexed data structure (user defined).

Re: Safety of user-defined operators

[Dmitry A. Kazakov]

On 2018-06-03 09:39, G.B. wrote:
> On 02.06.18 14:43, Dmitry A. Kazakov wrote:
> 
>> It is semantically problematic because it limits the implementation or 
>> forces a wrong implementation in case of temporal, volatile, shared 
>> objects. A special operator would allow implementation via proper 
>> procedure.
>>
>> It is analogous to automatic dereferencing and indexing. There will be 
>> no solution to until these operations will be done via user-defined 
>> procedure. No number of kludges and obscure helper type will ever 
>> work. Assignment is no different.
>>
> 
> What set of guarantees can user-defined Ada offer, in comparison,
> when users will provide those operations to the compiler that are
> now guarandteed by the language? (Where to "draw the line"?)
> 
> Example:
> 
> - typed, indexed RAM (array),
> 
> as opposed to
> 
> - typed, indexed data structure (user defined).

It is not who provides implementation but what the interface of an array 
is. The difference is between:

    Update (Get_Reference (A, I), V)

and

    Update (A, I, V)

There is no way #1 can handle all important cases of containers and 
there is no way to shape #1 in a way acceptable from the software design 
POV.

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

Re: Ada Successor Language

[ric.wai88]

Ada is an incredible languages as it is. It doesn't need a successor - it needs more adoption. 

Re: Ada Successor Language

[Dan'l Miller]

On Sunday, June 3, 2018 at 5:01:31 AM UTC-5, ric....@gmail.com wrote:
> Ada is an incredible languages as it is. It doesn't need a successor - it needs more adoption.

I actually agree with this for the most part.  Ada needs another compiler (or at least one of its few compiler vendors to market themselves differently) more than it needs a successor language.

The only way that Ada needs a successor is a minor variant that explores language changes that the ARG doesn't pursue, mostly in the category of great ideas that would break backwards compatibility on arcane topics.  But the chance that a successor to Ada would restrain itself to strictly being a minor variant is low, which is almost too much risk.

Conversely, what has cemented the view that C-family syntax is more readable than Pascal-family syntax is that there are a plethora of C-syntaxed cousin and sibling languages to C.  Ada looks like it is dead-end evolutionary branch.  Evolutionarily-dead-end Ada could have been named:  Duckbilled Platypus, Dodobird, Coelacanth.  Among these Coelacanth is best:  thought by many to be extinct, but still occasionally found in the wild.

What would be healthy for Ada is a new compiler whose front end is implemented as a honey pot to attract researchers to experiment with new variants of Ada, as they vaunt their researcwares as The Next Big Thing with much energy and fanfare.  Imagine someone even experimenting with •exactly• same Ada that we have today but with strictly one topic changed, either:

1) an entirely different memory model than Ada has today in its storage pools (or should I say, entirely different than the cattle chute that compilers & standard-library sends us down today);

or
2) an entirely different C-symbol cryptosyntax;

or
3) multimethods built-in;

or
4) some logic programming other than SPARK;

or
5) multistage programming source-code generation (instead of a preprocessor);

or
6) overt choice of different Ichbiah/Ada83 or Taft/Ada95 or Randy/Ada2020 or Rust-esque correctness enforcement;

or
7) a hundred other experiments.

Hence, the idea earlier in this thread for an Alphard-esque-on-steroids or Seed7-esque-on-steroids hypoAda on which today's Ada8652* can be implemented atop but also on which syntactic or semantic variants can be easily derived.  LLVM is an analogous honeypot for research on the backend.  Likewise, hypoAda could be another honeypot intentionally designed to attract researchers to fan the flames of energy among the universities (again) and among the tech billionaires (for the first time) regarding Ada.

* Ada8652 is all of the ISO 8652 eras:  Ada83, Ada95, Ada2005, Ada2012, Ada2020, …

Re: Ada Successor Language

[Shark8]

On Sunday, June 3, 2018 at 4:01:31 AM UTC-6, ric....@gmail.com wrote:
> Ada is an incredible languages as it is. It doesn't need a successor - it needs more adoption.

I actually agree; I'd like to see more adoption -- but there are some well-founded gripes, even among the hardcore Ada supporters -- and there have been several major design mistakes such as anonymous access types and access parameters. (The ARG so highly values backwards compatibility that, honestly, there's more chance of a successor language than the correction of most of these mistakes; just ask Randy.)

But a discussion like this allows us to discuss these problems, possibly even getting an 'ah-ha!' moment for solving them within current Ada. -- And if it does result in a successor language, we'll have a better idea of exactly what are the bad parts or how to correctly address what they were intended to.

Re: Ada Successor Language

[Lucretia]

On Sunday, 3 June 2018 11:01:31 UTC+1, ric....@gmail.com  wrote:
> Ada is an incredible languages as it is. It doesn't need a successor - it needs more adoption.

This is half of the problem. People have an irrational hatred of the language:

1) starting from the inception of the language.
2) from being told it's bad, usually by people who've never touched it, because they were told it's bad.

It's seen as old fashioned because it uses a Wirthian-esque syntax, yet C syntax is just as old.

People are stupid, see quotes (kind of) like:

1) "I can't read it, it's too verbose," some C/C++ programmer, who can't read words but apparently can read the crap that people write in those languages.
2) "I can't read it, it needs braces," yeah, because braces are so easy to read, same as 1.
3) "It achieves safety by tedium. It's about as fun as COBOL" << actual quote

Then on top of that we have:

1) Not enough tools.
2) Not enough libs.
3) Try finding *GOOD* auto-completion for Ada in an editor.
4) There's no one place to get Ada sources from, people want an equivalent of go get and rust's cargo.
5) There's not enough people working together.
6) The commercial users of Ada, aerospace/military, don't do open source, they use it though.
7) The speed of language updates really is glacial and based mainly on what the commercial users of the language want.
8) Not enough use outside military and aerospace.

For 3 above, I hate Vi-like editors, Emacs is dog slow and auto-complete is tag based and pretty crap, imo. GPS crashes all over the place and auto complete doesn't work there either. I refuse to use web browser based editors as I don't consider them stable or good enough or fast enough and I consider them to be experimental in nature. Everything else isn't good either.

So, the choice is, imo, a new toolchain sticking to all the Ada baggage, or a new language which we can start from a blank slate and attempting to make a better Ada for this and the next century.

Re: Ada Successor Language

[ric.wai88]

I'm currently training a team of 1st and 2nd year students in Ada. They're loving it. I run a company that specializes in commercial and enterprise Ada applications.

I think training and building, like I am actually doing, is a lot less work, and a lot less effective than trying to fix something that's not broken.

Re: Ada Successor Language

[Lucretia]

On Sunday, 3 June 2018 14:09:01 UTC+1, Shark8  wrote:

there's more chance of a successor language than the correction of most of these mistakes; just ask Randy.)

^ This 

Re: Ada Successor Language

[Lucretia]

On Sunday, 3 June 2018 16:14:13 UTC+1, ric....@gmail.com  wrote:
> I'm currently training a team of 1st and 2nd year students in Ada. They're loving it. I run a company that specializes in commercial and enterprise Ada applications.
> 
> I think training and building, like I am actually doing, is a lot less work, and a lot less effective than trying to fix something that's not broken.

Ask them what they like about it and how it compares to what they're used to, and explicitly ask what they're used to, which language, etc.

Re: Ada Successor Language

[ric.wai88]

On Sunday, June 3, 2018 at 11:16:01 AM UTC-4, Lucretia wrote:
> On Sunday, 3 June 2018 16:14:13 UTC+1, ric....@gmail.com  wrote:
> > I'm currently training a team of 1st and 2nd year students in Ada. They're loving it. I run a company that specializes in commercial and enterprise Ada applications.
> > 
> > I think training and building, like I am actually doing, is a lot less work, and a lot less effective than trying to fix something that's not broken.
> 
> Ask them what they like about it and how it compares to what they're used to, and explicitly ask what they're used to, which language, etc.

No. I'd rather focus on getting them to work. We'll be open-sourcing a large majority of our work too.

If you want to create a new language, go for it. But there exists no other language that is as carefully engineered and considered than Ada. You're talking about making another Rust. 

In my mind, I'm on a mission to bring Ada to more general use, and to promote good engineering discipline that Ada already encourages.

I can't understand why you're here. If you think you've got such a great idea, go build it. I have no more to contribute to this discussion - I've got to get to work.

Re: Ada Successor Language

[Lucretia]

On Sunday, 3 June 2018 16:22:34 UTC+1, ric....@gmail.com  wrote:

> I can't understand why you're here. If you think you've got such a great idea, go build it. I have no more to contribute to this discussion - I've got to get to work.

Because I like the language, but there are issues with it too, to say there aren't is to bury your head in the sand.

Re: Ada Successor Language

[ric.wai88]

On Sunday, June 3, 2018 at 11:31:14 AM UTC-4, Lucretia wrote:
> On Sunday, 3 June 2018 16:22:34 UTC+1, ric....@gmail.com  wrote:
> 
> > I can't understand why you're here. If you think you've got such a great idea, go build it. I have no more to contribute to this discussion - I've got to get to work.
> 
> Because I like the language, but there are issues with it too, to say there aren't is to bury your head in the sand.

*Sigh* Alright, you baited me just enough with that one.

I've overseen the development, deployment, and maintenance of very large, distributed, high-availability cloud-native enterprise systems, exclusively in Ada 2012.

We've used just about every single feature of the language in this. We've got hundreds of packages, and prevalent re-use. We have had not one single bug in production, and no unplanned downtime. Testing took about 10% of the allotted time because of the lack of bugs.

Nothing in this world is perfect. But I have not encountered a single serious deficiency in Ada. Having trained quite a few people in Ada, and supervising teams, as well as personally contributing a large portion of the original codebase, I can tell you from direct experience that every so-called deficiency in Ada has actually been a reflection of a detractor's own personal short comings. I know that's harsh to say, but this is frankly a huge part of the problem here.

Ada is very different from other languages because it is probably the only one out there that was not written by programmers for programmers. This is why it gets hate. Making it more programmer friendly is not fixing it.

Yes, we need more compilers, and more than AdaCore. I'm working on that. I'm giving it my all.

But nothing gets my blood boiling more than talk of reinventing the wheel. There are more pressing problems in computing and software. There will never be a "perfect" language. We are making too many damn languages. This is not the real problem.

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-03 17:09, Lucretia wrote:

> GPS crashes all over the place and auto complete doesn't work there either. I refuse to use web browser based editors as I don't consider them stable or good enough or fast enough and I consider them to be experimental in nature. Everything else isn't good either.

Maybe Linux version does. Windows version of GPS is quite stable and 
automatic completion works just fine. The only problem is that I don't 
know how to turn it off, for I hate that annoying stuff.

> So, the choice is, imo, a new toolchain sticking to all the Ada baggage, or a new language which we can start from a blank slate and attempting to make a better Ada for this and the next century.

And why should it turn any easier? The reasons why Ada is not popular 
and why there is no investment in Ada tools and libraris will not go 
away. These reasons lie outside technicalities. The technology is a 
subject here and is shaped so that only worst languages gain support. 
You cannot work against negative selection, it is a force of the 
economical nature. The new language can only be worse in order to 
survive. I stay with Ada.

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

Re: Ada Successor Language

[Jeffrey R. Carter]

On 06/03/2018 05:09 PM, Lucretia wrote:
> 
> GPS crashes all over the place and auto complete doesn't work there either. 
I haven't had any problems with GPS crashing nor with its auto-completion features.

GPS 6.1.2016 that comes from the Xubuntu 18.04 repositories has problems with 
highlighting, so I use GPS 2017, which doesn't have that problem.

-- 
Jeff Carter
"It's symbolic of his struggle against reality."
Monty Python's Life of Brian
78

Re: Ada Successor Language

[Björn Lundin]

On 2018-06-03 17:09, Lucretia wrote:
> GPS crashes all over the place and auto complete doesn't work there either.

Hmm, I use it on debian almost every day. Can't say that I
consider it crash-prone.
I can't remember when it happened last.

-- 
--
Björn

Re: Ada Successor Language

[Paul Rubin]

Lucretia <laguest9000@googlemail.com> writes:
> It's seen as old fashioned because it uses a Wirthian-esque syntax,
> yet C syntax is just as old.

It has Algol-esque syntax and Algol's best known dialect was from 1960.
C is nowhere near that old.  More cogently C's syntax displaced
Algol/Pascal syntax because people liked its conciseness.

> 1) "I can't read it, it's too verbose," some C/C++ programmer, who
> can't read words but apparently can read the crap that people write in
> those languages.

"Verbose" to me refers to the total amount of code you have to write to
get something done, rather than localized begin-vs-curly differences.
It does seem to me that you need more code in Ada than in other
languages.  Looking at examples on Rosetta code bears this out.

I looked at the docs for Ada's priority queues with the idea of fixing
the Rosetta example about Hamming numbers, but it started to look like a
huge project, compared with the Python heapq-based example that I wrote
in about 5 minutes.  The Corporate Bullshit Sentence Generator that I
looked at a few weeks ago (while a fun program) also seemed very
verbose, with its 500 different random number generation functions and
supporting datatypes.  

> 6) The commercial users of Ada, aerospace/military, don't do open
> source, they use it though.

I thought Ada was losing ground even in those areas.

Re: Ada Successor Language

[Dan'l Miller]

On Sunday, June 3, 2018 at 2:37:38 PM UTC-5, Paul Rubin wrote:
> Lucretia writes:
> > It's seen as old fashioned because it uses a Wirthian-esque syntax,
> > yet C syntax is just as old.
> 
> It has Algol-esque syntax and Algol's best known dialect was from 1960.
> C is nowhere near that old.

C's syntax derives directly from B.  (B descended from BCPL at Multics but BCPL had a more Algol-esque/PL/I-lite syntax.)  B originated in 1969.

> > 6) The commercial users of Ada, aerospace/military, don't do open
> > source, they use it though.
> 
> I thought Ada was losing ground even in those areas.

Job postings are a moderately good leading indicator.  Job postings from defense contractors in the Dallas & Fort Worth, Texas, metropolitan area fall into 3 categories:
1) Java, Java, everywhere, including non-UI/UX embedded systems.
2) C/C++ for embedded hard-realtime.
3) Ada-to-C++ conversion to decommission Ada systems.

In recent months, I haven't seen •any• Ada-only or you're-going-to-author-Ada-source-code job postings at DoD/aerospace companies locally here.  And that includes the local facilities for Raytheon, Boeing, Rockwell Collins, L3, General Dynamics, Northrup Grumman, and Textron Vaught Bell helicopters.

Re: Ada Successor Language

[Paul Rubin]

"Dan'l Miller" <optikos@verizon.net> writes:
> C's syntax derives directly from B.  (B descended from BCPL at Multics
> but BCPL had a more Algol-esque/PL/I-lite syntax.)  B originated in
> 1969.

Yes, Algol (starting 1958) is considerably older in computing history.
I do see that BCPL used curly braces though.  

> Job postings are a moderately good leading indicator....
> 1) Java, Java, everywhere, including non-UI/UX embedded systems.
> 2) C/C++ for embedded hard-realtime.
> 3) Ada-to-C++ conversion to decommission Ada systems.

Oh well, 2) and 3) are unfortunate I guess.  1) is meh: I can see
advantages to using Java (or these days Scala) in non-realtime
programming.

Rust's ascendance shows people really do see the issues of C and C++,
enough to be willing to switch languages.  That they chose to develop a
new language instead of using Ada supports the idea that it's time for
an Ada successor.  Is Rust the successor?  Should Mozilla's Firefox
rewrite have just used Ada instead?  I dunno.

Re: Ada Successor Language

[Ben Bacarisse]

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

> "Dan'l Miller" <optikos@verizon.net> writes:
>> C's syntax derives directly from B.  (B descended from BCPL at Multics
>> but BCPL had a more Algol-esque/PL/I-lite syntax.)  B originated in
>> 1969.
>
> Yes, Algol (starting 1958) is considerably older in computing history.
> I do see that BCPL used curly braces though.

That's relatively recent.  The 1967 description is neutral on the exact
characters.  It uses a section sign and an underlines section sign.  The
implementation I am familiar with used $( and $).

<snip>
-- 
Ben.

Re: Ada Successor Language

[ric.wai88]

On Sunday, June 3, 2018 at 7:56:05 PM UTC-4, Dan'l Miller wrote:

> Job postings are a moderately good leading indicator.  Job postings from defense contractors in the Dallas & Fort Worth, Texas, metropolitan area fall into 3 categories:
> 1) Java, Java, everywhere, including non-UI/UX embedded systems.
> 2) C/C++ for embedded hard-realtime.
> 3) Ada-to-C++ conversion to decommission Ada systems.
> 
> In recent months, I haven't seen •any• Ada-only or you're-going-to-author-Ada-source-code job postings at DoD/aerospace companies locally here.  And that includes the local facilities for Raytheon, Boeing, Rockwell Collins, L3, General Dynamics, Northrup Grumman, and Textron Vaught Bell helicopters.

There are a few studies out there that have shown training new hires in Ada is very easy, and is much easier than trying to find programmers already proficient in Ada. Of course the money-driven defence industry would rather hire a bunch of cheap young people than older experienced people. I also do Ada training, and I concur that it is quite easy to do. We also don't explicitly require Ada on our job applications, since most universities don't teach Ada (unfortunately), and we're not working in aerospace.

So I personally don't think that the job postings not including Ada as a requirement really means, definitively, that these companies are not using Ada anymore. Ada is technically superior in many cases, and this has to be a consideration for some of the more competent managers, however rare they may be. 

Re: Ada Successor Language

[Dan'l Miller]

On Saturday, June 2, 2018 at 1:52:13 AM UTC-5, Luke A. Guest wrote:
> We should adopt the common C shorthand operators, -=, +=, etc. Which means
> picking a different /= operator, may as well use != here too.

If hardwiring C-symbol syntax into next-generation replaces hardwiring Pascal/Wirth-esque syntax into Ada8652, then next-generation Ada had better have a hundred or a thousand better reasons to exist than such cosmetic battles.  The only way that C-symbol syntax should be allowed into next-generation Ada is as per-site policy.

Ada already is the A#1 language on the planet* where per-site policies harshly restrict which language features are forbidden (e.g., don't use any Ada95-or-later features; don't use tagged-record-based features; don't use any post-Ada95 features whatsoever; don't use anything that begins with unchecked_).  And this is in addition to Ada's much vaunted profiles of adding focused areas of functionality and/or assurance.

* and that is an extraordinarily difficult competition to win versus C++, whose coding standards read like a long list of all the dozens to low hundreds of undefined-behaviors/gotchas/code-smells to not do.

Perhaps Ada should take the hint that its main claim to future fame is to be the ultimate language for per-site policy-set custom-tailorization.  In this view, Ada could have various correctness checks/philosophies turned on or off.

To Luke's C-symbol point, a per-site (or even per-developer) policy could be:  at check-out, give me the C-symbol alternate syntax, or give me the old pragma-based syntax, or give me the new aspect-based syntax, or any other syntactic variant for the same underlying semantic meaning.

Re: Ada Successor Language

[John Smith]

On Saturday, June 2, 2018 at 12:43:52 AM UTC-4, Shark8 wrote:
> It occurs to me that in order to design a successor to Ada, there’s not merely one language that ought to be defined — but five — and the reason is that Ada is several languages all at once: there’s a language for generics, a language for proofs [SPARK], low-level hardware, and a language for tasking in addition to the Ada that maps to “normal” programming languages.
> 	One of the frustrations about Ada as-it-is is that there is a lot that seems like it could be “folded together”, things like (eg) all the Ada.[Wide_[Wide_]]Strings packages. Or, some sort of mechanism for [explicitly] showing the relationships between types.
> 	In order to do that we would need some sort of meta-language, wherein all the rest of the languages (ideally both syntactic and semantic) could be defined.
> 
> (1)	The Meta language
> (2)	The Generic Language
> (3)	The Concurrent/Parallelism language
> (4)	The Proving language [SPARK]
> (5)	The HW/Representation language
> 
> ----------
> Your thoughts?

It seems like Ada has some legacy code (like the "Wide") that's left over.  Splitting it up into 5 different languages doesn't make any sense.  It's like your tetris game having some legacy features... so you decide to make 5 different games.  One game just rotates a block.  One game just drops blocks.  And so on and so on.  This doesn't make any sense.

Re: Ada Successor Language

[Jacob Sparre Andersen]

Jeffrey R. Carter wrote:

> I haven't had any problems with GPS crashing nor with its
> auto-completion features.

The version packaged with Debian isn't exactly stable, but if you on
have one main per project, it is usable.

The binary distribution provided directly by AdaCore works fine, but
I've only tried it with compilers distributed by AdaCore.

Greetings,

Jacob
-- 
"It's not a question of whose habitat it is,
 it's a question of how fast you hit it."

Re: Ada Successor Language

[Simon Wright]

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

> Jeffrey R. Carter wrote:
>
>> I haven't had any problems with GPS crashing nor with its
>> auto-completion features.
>
> The version packaged with Debian isn't exactly stable, but if you on
> have one main per project, it is usable.
>
> The binary distribution provided directly by AdaCore works fine, but
> I've only tried it with compilers distributed by AdaCore.

From a Mac perspective, I have to use the AdaCore binary (far too many
dependencies for me to manage a build myself!), and always with an FSF
compiler.

Managing more than one FSF compiler is a little tedious, though (have to
edit a little script deep inside the application bundle).

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-04 09:19 AM, Simon Wright wrote:
> Jacob Sparre Andersen <jacob@jacob-sparre.dk> writes:
> 
>> Jeffrey R. Carter wrote:
>>
>>> I haven't had any problems with GPS crashing nor with its
>>> auto-completion features.
>>
>> The version packaged with Debian isn't exactly stable, but if you on
>> have one main per project, it is usable.
>>
>> The binary distribution provided directly by AdaCore works fine, but
>> I've only tried it with compilers distributed by AdaCore.
> 
>  From a Mac perspective, I have to use the AdaCore binary (far too many
> dependencies for me to manage a build myself!), and always with an FSF
> compiler.
> 
> Managing more than one FSF compiler is a little tedious, though (have to
> edit a little script deep inside the application bundle).

Out of curiosity.

Does OS X have a free repository of binary packages to put Ada there? 
Homebrew looks like source only.

Why did nobody port rpm-dnf or dpkg-apt to OS X?

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

Re: Ada Successor Language

[Lucretia]

On Monday, 4 June 2018 08:19:23 UTC+1, Simon Wright  wrote:

> From a Mac perspective, I have to use the AdaCore binary (far too many
> dependencies for me to manage a build myself!), and always with an FSF
> compiler.
> 
> Managing more than one FSF compiler is a little tedious, though (have to
> edit a little script deep inside the application bundle).

This is what I have atm, and it's unstable.

Re: Ada Successor Language

[Björn Lundin]

On 2018-06-04 09:44, Dmitry A. Kazakov wrote:
> Out of curiosity.
> 
> Does OS X have a free repository of binary packages to put Ada there?
> Homebrew looks like source only.

Mac had DarwinPort, which after some fuzz became MacPort.
This was - at the begining - source only.
But later releases includes some binary ports too.
Like the big and/or popular ones.
And I think the binary ports increases


-- 
--
Björn

Re: Ada Successor Language

[Dan'l Miller]

On Monday, June 4, 2018 at 2:19:23 AM UTC-5, Simon Wright wrote:
> Jacob Sparre Andersen writes:
> 
> > Jeffrey R. Carter wrote:
> >
> >> I haven't had any problems with GPS crashing nor with its
> >> auto-completion features.
> >
> > The version packaged with Debian isn't exactly stable, but if you on
> > have one main per project, it is usable.
> >
> > The binary distribution provided directly by AdaCore works fine, but
> > I've only tried it with compilers distributed by AdaCore.
> 
> From a Mac perspective, I have to use the AdaCore binary (far too many
> dependencies for me to manage a build myself!)

Luke, the your-mileage-may-vary different outcomes for (in)stability on the ‘same’ Linux distribution might be due to your machine having a ••different mix of versions of .so shared-library-based dependencies•• than the people who are reporting that it is perfectly stable.

>, and always with an FSF
> compiler.
> 
> Managing more than one FSF compiler is a little tedious, though (have to
> edit a little script deep inside the application bundle).

Re: Ada Successor Language

[Lucretia]

On Monday, 4 June 2018 15:08:35 UTC+1, Dan'l Miller  wrote:

> Luke, the your-mileage-may-vary different outcomes for (in)stability on the ‘same’ Linux distribution might be due to your machine having a ••different mix of versions of .so shared-library-based dependencies•• than the people who are reporting that it is perfectly stable.

I know. I just haven't got around to packaging it for free-ada yet, the billion dependencies and getting the right versions is a nightmare.

Re: Ada Successor Language

[G. B.]

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

> Why did nobody port rpm-dnf or dpkg-apt to OS X?

MacOS users can expect a working DMG, at least if the vendor is not in
[Oracle].
Also, MacOS offers a pretty stable BSD Unix, I‘d think. MacPort etc. have
been
one backfiring maintenance hazard needing attention all the time.

I don‘t know a good reason for free software to depend on layers of Unix
“ported” to Unix!
Isn’t it a better idea to clean out dated non-portable non-POSIX
dependences?

Even performance wise, and addressing architecture, if GNAT can benefit
from
features of the Darwin OS, why put a hindrance of several layers of C
libraries in
between?

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-04 18:54, G. B. wrote:

> I don‘t know a good reason for free software to depend on layers of Unix
> “ported” to Unix! Isn’t it a better idea to clean out dated non-portable non-POSIX
> dependences?

[ Well, having no POSIX is a great advantage ]

It looks that Mac OS X is no position to have a say in anything. The 
situation is similar to the one for Ada. We have to use horrid Linux C 
libraries however much we hate it, because there is no substitute 
written in Ada.

> Even performance wise, and addressing architecture, if GNAT can benefit
> from features of the Darwin OS, why put a hindrance of several layers of C
> libraries in between?

Because there is nothing else?

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

Re: Ada Successor Language

[Mehdi Saada]

What kind of structural change/additional features would allow for more compile-time bugs discovery/safety/speed/you-name-it ?

...Damn, reading Dan Miller made me speak like Marvel' Celestials !

Re: Ada Successor Language

[Dan'l Miller]

On Saturday, June 2, 2018 at 1:52:13 AM UTC-5, Luke A. Guest wrote:
> Shark8 <> wrote:
> 
> > 
> > (1)	The Meta language
> > (2)	The Generic Language
> > (3)	The Concurrent/Parallelism language
> > (4)	The Proving language [SPARK]
> > (5)	The HW/Representation language
> > 
> > ----------
> > Your thoughts?
> > 
> 
> There’s a guy, eLucian, wanting to implement his own language because Ada
> is too complex, his is level, where he has defined 5 compilers all written
> in different languages with different capabilities.

5 compilers, written in 5 different languages is a mess.  The Level logo is an eye-catching design though.

Conversely, Shark8's Meta-language is analogous to what I call hypoAda:  the rudimentary Ada-esque language constructs in which Ada8652 (or variants thereof) could be written as a library of sorts (or perhaps a plug-in DLL to the compiler).  These rudimentary language constructs would be somewhat like what Seed7 does and very much as William Wulf's & Mary Shaw's Alphard partially explored during the 1970s.

Imagine Seed7 not being a subset of Ada's type-declaration language.  Then Seed7 would be a start on hypoAda or what, I think, Shark8 calls The Meta-language.

Re: Ada Successor Language

[Paul Rubin]

Shark8 <onewingedshark@gmail.com> writes:
> (1)	The Meta language
> (2)	The Generic Language
> (3)	The Concurrent/Parallelism language
> (4)	The Proving language [SPARK]
> (5)	The HW/Representation language

By "Meta language" I first thought you meant replacing the ARM with a
machine checkable specification, written in something like Twelf[1].
That seems like a great idea.  But instead it seems like you want some
general syntactic umbrella in which the other stuff is embedded as
DSL's.  I.e. you are reinventing Lisp ;).  

Also it's unclear what you mean by the Generic language: is that
supposed to be a special sub-language for type-level programming,
something like ML's module language?  I dunno, maybe that should be
closely connected with the proving language.

Concurrency/Parallelism doesn't need a special language: it's mostly
runtime stuff with a bit of compiler backend support and maybe an even
smaller bit of syntactic support.

The proving language might look quite a bit different from SPARK because
of how much that field has changed since SPARK was new.  I wonder if
again a Lisp-inspired approach would be helpful: the language definition
would include a formal spec for AST's that could be handed off to
external proof systems, along with any embedded assertions and contracts
that could be connected up with proofs packaged separately from the user
program.

I wonder if we're in for some big advances in automated proof search any
time soon.  I haven't been hearing anything about it but it just seems
like an obvious thing for people to be working on.

Re: Ada Successor Language

[Randy Brukardt]

>Luke A. Guest" <laguest@archeia.com> wrote in message 
>news:217213441.549636947.114978.laguest-archeia.com@nntp.aioe.org...
> Mehdi Saada <00120260a@gmail.com> wrote:
>
>>> We should adopt the common C shorthand operators, -=, +=, etc.
>> What's the problem with @ ? It's more elegant and versatile.
>>
>
> The proposal is to use +:=, -:=, etc which is ok but a little weird.

Which has been extensively discussed by the ARG but rejected. There's both 
technical issues (given the possibility of overloading, "A +:= B" cannot 
always be equivalent to "A := A + B") and the ugliness factor.

> The other proposal is to use @ as the lhs shorthand.

This is in Ada 2020. I believe GNAT already supports it (in extensions 
mode). It's a lot more flexible since it can be used in any function or 
attribute -- no restriction to operators.

                                       Randy.

Re: Ada Successor Language

[G.B.]

On 04.06.18 21:37, Dmitry A. Kazakov wrote:
> On 2018-06-04 18:54, G. B. wrote:
> 
>> I don‘t know a good reason for free software to depend on layers of Unix
>> “ported” to Unix! Isn’t it a better idea to clean out dated non-portable non-POSIX
>> dependences?
> 
> [ Well, having no POSIX is a great advantage ]
> 
> It looks that Mac OS X is no position to have a say in anything. 

Actually, Apple's devices have inspired AdaCore customers to want
a way of translating Ada to whatever runs on iOS. It's done via C,
currently, IIUC. Since much of iOS inherits the C-tradition, and since
AdaCore had already put efforts into that kind of translation,
that's a reasonable choice.


>> Even performance wise, and addressing architecture, if GNAT can benefit
>> from features of the Darwin OS, why put a hindrance of several layers of C
>> libraries in between?
> 
> Because there is nothing else?

Why layers of Unix on Unix?

If Unix needs to be between Ada and the OS for GNAT to work,
then why not just use the BSD Unix that Macs have got?

It seems as though programmers like putting much effort into making
their programs work with autoconf and xyz-ports.
This takes away much time that could be spent on making programs just
work on the most wide spread flavors of Unix. Just in case, that
includes Apple BSD and Linux for Android.

Re: Ada Successor Language

[Shark8]

On Monday, June 4, 2018 at 3:14:57 PM UTC-6, Paul Rubin wrote:
> Shark8 writes:
> > (1)	The Meta language
> > (2)	The Generic Language
> > (3)	The Concurrent/Parallelism language
> > (4)	The Proving language [SPARK]
> > (5)	The HW/Representation language
> 
> By "Meta language" I first thought you meant replacing the ARM with a
> machine checkable specification, written in something like Twelf[1].
> That seems like a great idea.  But instead it seems like you want some
> general syntactic umbrella in which the other stuff is embedded as
> DSL's.  I.e. you are reinventing Lisp ;).  

A little of column-A, a little of column-B.
(I would love to get my hands on a copy of the source for Symbolics Ada; it was awesome to see how integrated it was with the LISP environment -- But have no Idea where to start for that.)

Having the LRM define a nice, relatively-simple, machine-checkable language which could be used to define everything else would be really, really nice for compiler developers.

Having [some] things formally and explicitly defined in terms of sets would also be helpful -- see: https://en.wikibooks.org/wiki/Ada_Programming/Type_System#The_Type_Hierarchy -- having (eg) a real definition of Universal_Integer would allow some nice definition clean-up.

(ALSO: I personally think that a user definable "abstract type interface" [kinda/sorta type classes], as well as user-definable attributes, would be great ways to handle the above while expanding the capabilities of Ada'Succ.)

> 
> Also it's unclear what you mean by the Generic language: is that
> supposed to be a special sub-language for type-level programming,
> something like ML's module language?  I dunno, maybe that should be
> closely connected with the proving language.

Ada already /has/ a generic language; the whole section on generic formal parameters defines it -- https://en.wikibooks.org/wiki/Ada_Programming/Generics#Generic_formal_types -- and these are going to be expanded in Ada 2020, IIUC, to certain provability properties.

> 
> Concurrency/Parallelism doesn't need a special language: it's mostly
> runtime stuff with a bit of compiler backend support and maybe an even
> smaller bit of syntactic support.

Except it already is its own language TASK, SELECT, and arguably DELAY don't really appear in the rest of the language.

This is likely going to become more apparent with parallel-blocks and the proposed method for mapping.

> 
> The proving language might look quite a bit different from SPARK because
> of how much that field has changed since SPARK was new.  I wonder if
> again a Lisp-inspired approach would be helpful: the language definition
> would include a formal spec for AST's that could be handed off to
> external proof systems, along with any embedded assertions and contracts
> that could be connected up with proofs packaged separately from the user
> program.

There's some interesting stuff that could be done in this area; for compilers we could commandeer the ideas here -- http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.324.4139&rep=rep1&type=pdf and https://pdfs.semanticscholar.org/d3a1/4b2301487946614ca89ec23726abf27d9f65.pdf and [IIRC these two papers] https://www.cc.gatech.edu/~xzhang36/papers/pldi14b-long.pdf and http://www.rug.nl/research/portal/files/33882898/Kurs14a_ParsingContext.pdf -- for some really interesting capabilities.

> 
> I wonder if we're in for some big advances in automated proof search any
> time soon.  I haven't been hearing anything about it but it just seems
> like an obvious thing for people to be working on.

There were a few papers I read early last year that were interesting, though I don't remember them off the top of my head.

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-05 00:12, G.B. wrote:
> On 04.06.18 21:37, Dmitry A. Kazakov wrote:
>> On 2018-06-04 18:54, G. B. wrote:
>>> Even performance wise, and addressing architecture, if GNAT can benefit
>>> from features of the Darwin OS, why put a hindrance of several layers 
>>> of C libraries in between?
>>
>> Because there is nothing else?
> 
> Why layers of Unix on Unix?

It is not about technical merits. UNIX is an awful OS. It is just as the 
things are. Most of public domain libraries are developed for Linux, 
ported to Windows and nobody really cares about the rest.

> If Unix needs to be between Ada and the OS for GNAT to work,
> then why not just use the BSD Unix that Macs have got?

Because Mac users don't want to use BSD?

> It seems as though programmers like putting much effort into making
> their programs work with autoconf and xyz-ports.

Luckily we have gpr projects [*]. But the question was about packaging 
and handling dependencies.

--------
* The irony is that AdaCore does trust it and continues to use the 
configure-mess.

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

Re: Ada Successor Language

[Lucretia]

On Monday, 4 June 2018 22:06:03 UTC+1, Dan'l Miller  wrote:

> > There’s a guy, eLucian, wanting to implement his own language because Ada
> > is too complex, his is level, where he has defined 5 compilers all written
> > in different languages with different capabilities.
> 
> 5 compilers, written in 5 different languages is a mess.

Yes, I told him as much. His reasoning was that it was to learn the languages, I don't see that as an excuse for over complicating things.

>  The Level logo is an eye-catching design though.

Nah, looks like Jevel.

Re: Ada Successor Language

[Dan'l Miller]

On Monday, June 4, 2018 at 7:17:26 PM UTC-5, Shark8 wrote:
> On Monday, June 4, 2018 at 3:14:57 PM UTC-6, Paul Rubin wrote:
> > Shark8 writes:
> > > (1)	The Meta language
> > > (2)	The Generic Language
> > > (3)	The Concurrent/Parallelism language
> > > (4)	The Proving language [SPARK]
> > > (5)	The HW/Representation language
> > 
> > By "Meta language" I first thought you meant replacing the ARM with a
> > machine checkable specification, written in something like Twelf[1].
> > That seems like a great idea.  But instead it seems like you want some
> > general syntactic umbrella in which the other stuff is embedded as
> > DSL's.  I.e. you are reinventing Lisp ;).  
> 
> A little of column-A, a little of column-B.
> (I would love to get my hands on a copy of the source for Symbolics Ada; it was awesome to see how integrated it was with the LISP environment -- But have no Idea where to start for that.)

http://www.symbolics-dks.com
The intellectual property of the old Symbolics is for sale if you can raise enough money to license pieces of it.

Conversely, in the modern era, Thomas Mertes PhD thesis is somewhat interesting:
It is not Lisp, but Seed7's definable language constructs for a language such as Ada8652 could be at least an inspiration for what you call The Meta Language or what I call hypoAda.  

definable language constructs:
http://seed7.sourceforge.net/examples/declstat.htm

definable operators:
http://seed7.sourceforge.net/examples/operator.htm

Re: Ada Successor Language

[Alejandro R. Mosteo]

On 03/06/2018 17:09, Lucretia wrote:

> 4) There's no one place to get Ada sources from, people want an equivalent of go get and rust's cargo.

There are two projects working in this direction that I'm aware of:

http://ravenports.ironwolf.systems/

And from yours truly:

https://github.com/alire-project/alr

Re: Ada Successor Language

[Niklas Holsti]

On 18-06-05 00:14 , Paul Rubin wrote:
> Shark8 <onewingedshark@gmail.com> writes:
>> (1)	The Meta language
>> (2)	The Generic Language
>> (3)	The Concurrent/Parallelism language
>> (4)	The Proving language [SPARK]
>> (5)	The HW/Representation language
>
> By "Meta language" I first thought you meant replacing the ARM with a
> machine checkable specification, written in something like Twelf[1].
> That seems like a great idea.

I agree strongly. Extending the ARM with a formal specification would, I 
believe, make it much easier to evolve Ada further, assuming that the 
formalization would permit automatic analysis and proof of properties of 
the language, such as the absence of Beaujolais effects and the absence 
of contradictory specifications in different parts of the ARM.

This would make it easier to understand the impact of any proposed 
change to Ada, both for backward compatibility and for the properties of 
the changed language. It might make it easier to permit language changes 
that break backward compatibility: by showing precisely where and how 
that break affects the language, it might help compilers optionally 
support both the old and the new forms of the language.

The formalization should allow the automatic generation of an Ada parser 
and semantic analyzer, to the same level as ASIS now provides. Such a 
tool, even if not fast enough for a production compiler, should mitigate 
the obstacles that the rich (some would say "complex") Ada syntax and 
semantics now pose for experimental language extensions and language 
"augmentation" tools (source-to-source tools).

This formalization will not be easy or cheap, but should be feasible 
today, at least for the syntax and static semantics.

I'm not sure if the dynamic semantics can be formalized in a way that 
permits proof of its properties (as opposed to mere simulation of the 
execution). The increasing powers of program-proving tools make me 
hopeful. However, current tools focus on proving properties of a 
particular (single) program, but proving properties of the Ada dynamic 
semantics would require considering all Ada programs that obey those 
semantics.

Note that I do not insist on a formalization that provides fully 
automatic proofs, just one that allows formal (automatically checked) 
proofs, even if manually guided or programmed.

To comment on the general "Ada successor" discussion, I think the 
language should be kept integrated, for example with the "Proving 
language" being an integrated part of the whole, as in Ada 2012 
contracts, rather than being an add-on, as with the original SPARK 
embedded in Ada comments.

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

Re: Ada Successor Language

[gautier_niouzes]

Le mardi 5 juin 2018 18:46:22 UTC+2, Alejandro R. Mosteo a écrit :
> On 03/06/2018 17:09, Lucretia wrote:
> 
> > 4) There's no one place to get Ada sources from, people want an equivalent of go get and rust's cargo.
> 
> There are two projects working in this direction that I'm aware of:
> 
> http://ravenports.ironwolf.systems/
> 
> And from yours truly:
> 
> https://github.com/alire-project/alr

Cool! For feeding catalogs, or for getting Ada sources "manually", the following two places have already a good bunch of them:

https://sourceforge.net/directory/language:ada/

https://github.com/search?utf8=%E2%9C%93&q=language%3AAda&type=Repositories&ref=advsearch

Re: Ada Successor Language

[Alejandro R. Mosteo]

On 06/06/2018 23:02, gautier_niouzes@hotmail.com wrote:
> Le mardi 5 juin 2018 18:46:22 UTC+2, Alejandro R. Mosteo a écrit :
>> On 03/06/2018 17:09, Lucretia wrote:
>>
>>> 4) There's no one place to get Ada sources from, people want an equivalent of go get and rust's cargo.
>>
>> There are two projects working in this direction that I'm aware of:
>>
>> http://ravenports.ironwolf.systems/
>>
>> And from yours truly:
>>
>> https://github.com/alire-project/alr
> 
> Cool! For feeding catalogs, or for getting Ada sources "manually", the following two places have already a good bunch of them:
> 
> https://sourceforge.net/directory/language:ada/
> 
> https://github.com/search?utf8=%E2%9C%93&q=language%3AAda&type=Repositories&ref=advsearch

Thanks! I was already tracking github
and http://www.adaic.org/ada-resources/tools-libraries/

Right now I'm prioritizing projects announced here, followed by my 
perceived popularity of projects in the public repositories above.

Re: Ada Successor Language

[Dan'l Miller]

> This formalization will not be easy or cheap,
> but should be feasible today, at least for the
> syntax and static semantics. 

Who would be willing to fund such an effort?
1) fizzle: The big tech companies on the West Coast of the USA seem highly disinterested in safety.
2) fizzle: DARPA seems to have moved on to AI & robotics only, not all the goals that motivated Ada.
3) fizzle: INRIA seems more interested in OCaml than Ada.
3) potential: The most likely funding would come from national governments in Europe, especially France or Germany, who are at times pursuing safe software systems.

What allied hot topic would attract funding to translating the _LRM_ into some sort of formal-specifications language?  Ada as required by the insurance industry?  Ada for robotics?  AI for Ada?  Ada for blockchain currency?

Re: Ada Successor Language

[Mehdi Saada]

> Ada for robotics?  AI for Ada ?
Are you saying that it is not fit for those kinds of applications ?

Re: Ada Successor Language

[Shark8]

On Friday, June 8, 2018 at 10:28:04 AM UTC-6, Dan'l Miller wrote:
> > This formalization will not be easy or cheap,
> > but should be feasible today, at least for the
> > syntax and static semantics. 
> 
> Who would be willing to fund such an effort?
Perhaps this is the wrong question. The big problem being so few with resources have bought into Ada -- and those that have (eg Boeing) seem to either be transitioning away, or satisfied with state of things and uninterested in improvement.

I have a few contacts locally who might be interested, given the proper presentation; I'm trying to write up a proposal about it. / I could probably use some help doing so, but I plan to present it first and foremost as a full-IDE (and fully verified) for HW and SW. (pop me an e-mail if you're interested in helping.)

> 1) fizzle: The big tech companies on the West Coast of the USA seem highly disinterested in safety.
While I agree based on my experiences, and attitudes in lower management corporately; do you have any citable references on this? It would help boost my proposal, I think.

> 2) fizzle: DARPA seems to have moved on to AI & robotics only, not all the goals that motivated Ada.
Sad, and stupid. -- "AI" as it is now is nothing less than pattern-matching and while necessary for AI is not sufficient. (For true AI, we're about at the level of "epileptic chicken".) 

> 3) fizzle: INRIA seems more interested in OCaml than Ada.
Well, given the hype-wave of "functional programming" this is at least understandable. Though, IIRC, there were some fans/proponents of Ada there.

> 3) potential: The most likely funding would come from national governments in Europe, especially France or Germany, who are at times pursuing safe software systems.
Interesting.

> What allied hot topic would attract funding to translating the _LRM_ into some sort of formal-specifications language?  Ada as required by the insurance industry?  Ada for robotics?  AI for Ada?  Ada for blockchain currency?
Honestly, I think Ada at the systems-level would work well. Microsoft Research did a fully type-safe OS (Verve) a while back and the researchers were blown away by the lack of need for a debugger: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/pldi117-yang.pdf -- You can almost hear the amazement off those paragraphs.

Re: Ada Successor Language

[Mehdi Saada]

Do you see only an IDE, or also new higher level constructs in the language itself ?

Re: Ada Successor Language

[Dan'l Miller]

> Shark8 wrote:
> > Dan’l Miller wrote:
> > 3) potential: The most likely funding would
> > come from national governments in Europe,
> > especially France or Germany, who are at
> > times pursuing safe software systems. 
> Interesting.

The European science-research apparatus commenced on this once before sometime around 1987.  Here is an AJPO paper from the USA side of the Atlantic:

 https://www.researchgate.net/publication/235202926_The_European_Formal_Definition_of_Ada_A_US_Perspective

https://link.springer.com/chapter/10.1007/BFb0022125

It was presented at the ESEC 1987 conference:
https://link.springer.com/book/10.1007/BFb0022092

The big question is why it stopped at a draft version of a formal description of (a subset?) of Ada83:
https://cordis.europa.eu/project/rcn/17317_fr.html

Re: Ada Successor Language

[Luke A. Guest]

Dan'l Miller <> wrote:


> The big question is why it stopped at a draft version of a formal
> description of (a subset?) of Ada83:
> https://cordis.europa.eu/project/rcn/17317_fr.html
> 

It’s posts like these that make me wonder why so many Ada people keep
living in the past. Don’t you think it’s time to learn from the past and
drag your arses into the 21st century.

Re: Ada Successor Language

[Dan'l Miller]

> Luke Guest wrote:
> > Dan'l Miller <> wrote: 
> > The big question is why it stopped at a draft version of a formal 
> > description of (a subset?) of Ada83: 
> > https://cordis.europa.eu/project/rcn/17317_fr.html 
>
> It’s posts like these that make me wonder why so many
> Ada people keep 
> living in the past. Don’t you think it’s time to learn from
> the past and drag your arses into the 21st century. 

The only way to drag my arse into the 21st century is for me & likeminded fellows to figure out what the heck went so wrong on this path.  If you think the current path is the best one, then Dr Strangelove‘s advice to stop be afraid and love the “bomb”, so to speak.

Re: Ada Successor Language

[Luke A. Guest]

Dan'l Miller <t> wrote:

> The only way to drag my arse into the 21st century is for me & likeminded
> fellows to figure out what the heck went so wrong on this path.  If you
> think the current path is the best one, then Dr Strangelove‘s advice to
> stop be afraid and love the “bomb”, so to speak.
> 

It was a good path back then although mightily complicated, still
complicated tbh. Time to modernise! 😝😝😝

Re: Ada Successor Language

[Shark8]

On Friday, June 8, 2018 at 2:38:44 PM UTC-6, Mehdi Saada wrote:
> Do you see only an IDE, or also new higher level constructs in the language itself ?

The IDE idea is rather separate from an Ada successor language, at the moment. Given things like the Meltdown and Specter vulnerabilities it's becoming obvious that HW is reaching the point where it needs provable verification just like SW does -- at least for SW we have SPARK -- a fully integrated Ada and VHDL IDE  would allow some form of crossover, allowing the SPARK provers to be used on HW descriptions and prove properties there, just like we do in SW.

This gets even more exciting when you have HW and SW together: you can verify the whole system! Imagine, for a moment, the possibilities of a chip, its OS, and its compiler all formally verified.

Re: Ada Successor Language

[Shark8]

On Tuesday, June 12, 2018 at 9:23:08 AM UTC-6, Luke A. Guest wrote:
> Dan'l Miller <> wrote:
> 
> 
> > The big question is why it stopped at a draft version of a formal
> > description of (a subset?) of Ada83:
> > https://cordis.europa.eu/project/rcn/17317_fr.html
> > 
> 
> It’s posts like these that make me wonder why so many Ada people keep
> living in the past. Don’t you think it’s time to learn from the past and
> drag your arses into the 21st century.

Well, some of the 21st century "solutions" are utterly inferior -- take "Continuous Integration" and "Source Control" as an example -- integrating both together solves a lot of problems: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.26.2533&rep=rep1&type=pdf

+ Less redundant processing; you don't need to parse everything to check its correctness.
+ Better and more accurate source-control (because meaningless things like whitespace don't matter)
+ Formatting/style wars don't matter (because meaningless things like whitespace don't matter)
+ File-system environment doesn't matter, because the program source is in an actual DB instead of in test-files in the ad-hoc DB of the file-system.

Re: Ada Successor Language

[Simon Wright]

Shark8 <onewingedshark@gmail.com> writes:

> Well, some of the 21st century "solutions" are utterly inferior --
> take "Continuous Integration" and "Source Control" as an example --
> integrating both together solves a lot of problems:
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.26.2533&rep=rep1&type=pdf
>
> + Less redundant processing; you don't need to parse everything to
> check its correctness.
> + Better and more accurate source-control (because meaningless things
> like whitespace don't matter)
> + Formatting/style wars don't matter (because meaningless things like
> whitespace don't matter)
> + File-system environment doesn't matter, because the program source
> is in an actual DB instead of in test-files in the ad-hoc DB of the
> file-system.

Sounds like the Ratinal Environment.

Re: Ada Successor Language

[Dan'l Miller]

> > Dan'l Miller <t> wrote: 
> > The only way to drag my arse into the 21st
> > century is for me & likeminded fellows to
> > figure out what the heck went so wrong on
> > this path.  If you think the current Ada8652
> > path of currently-extant compilers is the best
> > one, then Dr Strangelove‘s advice to
> > stop worrying and love the “bomb”, so to
> > speak. 
> 
> It was a good path back then although mightily
> complicated, still complicated tbh. Time to
> modernise! 😝😝😝

(I corrected my mistakes in the quotation above.)

Modernization likely means an Ada-esque drastic subset.

My idea of a next-gen Ada goes the opposite direction:  nearly everything in Ada8652, except breaking backwards compatibility in some Ichbiah oddities that are standing in the way of new modern era features, then plus one heck of a lot more.  The problem with Ada8652 is that odd baggage is holding Ada back from being a much much bigger language.

The answer to the question of why did the release of this work stop at a draft is because its VDM spec turned commercial to become the DDC-I Ada compiler still extant today.
https://cordis.europa.eu/project/rcn/17317_fr.html

More-detailed history:
https://en.m.wikipedia.org/wiki/Dansk_Datamatik_Center

Re: Ada Successor Language

[Luke A. Guest]

Dan'l Miller <net> wrote:

likely means an Ada-esque drastic subset.
> 
> My idea of a next-gen Ada goes the opposite direction:  nearly everything
> in Ada8652, except breaking backwards compatibility in some Ichbiah
> oddities that are standing in the way of new modern era features, then
> plus one heck of a lot more.  The problem with Ada8652 is that odd
> baggage is holding Ada back from being a much much bigger language.
> 

An issue is that not all types can be restricted and extended. Seems that
these are features of Ada but not for all types like it should be.

Re: Ada Successor Language

[G. B.]

Dan'l Miller <optikos@verizon.net> wrote:
>> Luke Guest wrote:
>>> Dan'l Miller <> wrote: 
>>> The big question is why it stopped at a draft version of a formal 
>>> description of (a subset?) of Ada83: 
>>> https://cordis.europa.eu/project/rcn/17317_fr.html 
>> 
>> It’s posts like these that make me wonder why so many
>> Ada people keep 
>> living in the past. Don’t you think it’s time to learn from
>> the past and drag your arses into the 21st century. 
> 
> The only way to drag my arse into the 21st century is for me & likeminded
> fellows to figure out what the heck went so wrong on this path.  

A good candidate:
“the tax payers’ gov. wants it” seen as a huge economic opportunity. An
opportunity that grows even larger if one can minimize investment.
Unfortunately, only tool makers and consultants see it that way. “Too
expensive”, I’ve heard a few times when asking why it went wrong.

> If you think the current path is the best one, then Dr Strangelove‘s
> advice to stop be afraid and love the “bomb”, so to speak.
> 

The advice captures cloud computing trends pretty well, IMO. The mainframes
are back! The service models are just too promising.

Re: Ada Successor Language

[Shark8]

On Wednesday, June 13, 2018 at 12:57:34 AM UTC-6, Simon Wright wrote:
> 
> Sounds like the Ratinal Environment.

I've only ever read about it myself; but the people that I've talked with that have personally used it seem to be pretty impressed with it (considering its age and the contemporary environments).

IMO, the rise to prominence of Unix and C [and arguably C++] is the worst thing that happened in the field of CS. The amount of money, time, energy, and effort sucked up by these is so staggering to contemplate that it would be difficult to overestimate the costs, both real [e.g. all the buffer overflow vulnerabilities] and opportunities lost [e.g. the low-level of today's "advanced" continuous integration, or the cost of using the FS as a DB, or the costs of moronically considering unstructured text as THE appropriate/native format for storing programs].

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-13 20:58, Shark8 wrote:
> On Wednesday, June 13, 2018 at 12:57:34 AM UTC-6, Simon Wright wrote:
>>
>> Sounds like the Ratinal Environment.
> 
> I've only ever read about it myself; but the people that I've talked with that have personally used it seem to be pretty impressed with it (considering its age and the contemporary environments).

I used Rational in one project and can confirm, I was impressed.

> IMO, the rise to prominence of Unix and C [and arguably C++] is the worst thing that happened in the field of CS. The amount of money, time, energy, and effort sucked up by these is so staggering to contemplate that it would be difficult to overestimate the costs, both real [e.g. all the buffer overflow vulnerabilities] and opportunities lost [e.g. the low-level of today's "advanced" continuous integration, or the cost of using the FS as a DB, or the costs of moronically considering unstructured text as THE appropriate/native format for storing programs].

Unix, Windows, C could not be so efficient in burning everything down 
had economical conditions not allowed price dumping, monopolization and 
in the end killing the SW market.

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

Re: Ada Successor Language

[Paul Rubin]

Shark8 <onewingedshark@gmail.com> writes:
> Unix and C [and arguably C++] is the worst thing ... opportunities
> lost [e.g. the low-level of today's "advanced" continuous integration,
> or the cost of using the FS as a DB, or the costs of moronically
> considering unstructured text as THE appropriate/native format for
> storing programs].

I don't think those lost opportunities have much to do with Unix or C.
Fancy CI that I've seen has usually been in conjunction with Ruby or
Python projects, etc.  The FS is similarly a perfectly good DB depending
on what you want for it to do, syntax can be recovered from free text by
parsing, etc.  This mostly comes down to human factors rather than
artifacts of buffer overflows or anything like that.  Ada to zeroth
order is C++ without the buffer overflows.  That's a good thing but it
doesn't affect the other stuff you mentioned.

Re: Ada Successor Language

[Lucretia]

On Wednesday, 13 June 2018 20:19:30 UTC+1, Dmitry A. Kazakov  wrote:

> Unix, Windows, C could not be so efficient in burning everything down 

Windows was originally written in Pascal, not C, C and C++ came later.

Re: Ada Successor Language

[Lucretia]

On Wednesday, 13 June 2018 22:15:21 UTC+1, Paul Rubin  wrote:

> Python projects, etc.  The FS is similarly a perfectly good DB depending

You want a FS that's a DB, look at BeOS' FS.

Re: Ada Successor Language

[Shark8]

On Wednesday, June 13, 2018 at 3:15:21 PM UTC-6, Paul Rubin wrote:
> Shark8 writes:
> > Unix and C [and arguably C++] is the worst thing ... opportunities
> > lost [e.g. the low-level of today's "advanced" continuous integration,
> > or the cost of using the FS as a DB, or the costs of moronically
> > considering unstructured text as THE appropriate/native format for
> > storing programs].
> 
> I don't think those lost opportunities have much to do with Unix or C.

Oh, but it does!

> Fancy CI that I've seen has usually been in conjunction with Ruby or
> Python projects, etc.

Relatively new; when they should have been industry standard two decades ago? Sounds like lost opportunity that we-as-an-industry are just now rediscovering. (Also, TTBOMK all of these solutions are text-based.)

> The FS is similarly a perfectly good DB depending
> on what you want for it to do, syntax can be recovered from free text by
> parsing, etc.

The FS is NOT a good substitute for a DB, furthermore it introduces perfectly avoidable environmental dependence which would not otherwise exist (e.g. case sensitivity, the path, the path separator, timestamp resolution, etc.)

> This mostly comes down to human factors rather than
> artifacts of buffer overflows or anything like that.  Ada to zeroth
> order is C++ without the buffer overflows.  That's a good thing but it
> doesn't affect the other stuff you mentioned.

Except you're ignoring things like the Rational 1000 which was mentioned earlier in this thread -- which is thirty years old now, IIRC -- the entire environment was geared for SW development; instead of getting environments like this we-as-an-industry wasted time and energy on C-isms and Unix-isms.

The whole text-based craze which causes you to parse everything again and again and again is straight from Unix. But more than this, it's false sense "mostly works" and lack of foresight is littered throughout.

Let's take the whole "one program that does one thing well" concept, ok that's all well and good. So you build a system piping inputs and outputs...it seems fine, at first glance, until you look at the fact that the medium of transport [pipes] is text. -- Now what you have is a system that serailizes and deserializes constantly, but not with any actual standard way, and usually with each component using an ad hoc method to read and write. -- So what you've done by standardizing on text is forced continual parsing and re-parsing for every element in the pipeline. 

This is the whole reason that JSON is popular; because it "solves" the problem of text-stream consistency... sadly, the industry fails to realized that these serialize/deserialize problems were already solved via ASN.1.

I highly recommend you watch this video:  http://www.youtube.com/watch?v=8pTEmbeENF4

Re: Ada Successor Language

[Paul Rubin]

Shark8 <onewingedshark@gmail.com> writes:
>> Fancy CI that I've seen
> Relatively new; when they should have been industry standard two
> decades ago?

No I don't think the associated technology or the machine resources were
available that easily 20 years ago.  

> The FS is NOT a good substitute for a DB,

Depends on wat you are doing

> (e.g. case sensitivity, the path, the path separator, timestamp
> resolution, etc.)

Might not matter, depending on what you are doing.

> Except you're ignoring things like the Rational 1000 which was

Whatever that is, almost nobody uses it now, probably for a reason.

> This is the whole reason that JSON is popular; because it "solves" the
> problem of text-stream consistency...

JSON is just restricted, curly-braced S-expressions.

> sadly, the industry fails to realized that these serialize/deserialize
> problems were already solved via ASN.1.

That's just another thing to parse and unparse.  Here's my favorite
ASN.1 related rant:

https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt

That said, reprocessing ad hoc text formats was more tractable in the
20th century Unix era, when there weren't so many programs around.  This
stuff exists in the real world after all.

> I highly recommend you watch this video:
> http://www.youtube.com/watch?v=8pTEmbeENF4

On my list.

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-14 05:19, Lucretia wrote:
> On Wednesday, 13 June 2018 20:19:30 UTC+1, Dmitry A. Kazakov  wrote:
> 
>> Unix, Windows, C could not be so efficient in burning everything down
> 
> Windows was originally written in Pascal, not C, C and C++ came later.

Windows 3.1 is 1992. C++ is a decade older, around 1980. C is another 
decade older.

(It took a considerable time for C to poison everything. Same is true 
for Windows.)

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

Re: Ada Successor Language

[Marius Amado-Alves]

The Rational brand of IBM started as an Ada product. Didn't know that. My mind is blown.

Recently worked with RTC Rational Team Concert in a small team (10 people). Did the job, but way too many features getting in the way. In the past, worked with Rational Rose, similar feelings. And saw no Ada in either.

They surely managed to frack up whatever good was in the Ada foundation.

Re: Ada Successor Language

[Lucretia]

On Thursday, 14 June 2018 08:26:35 UTC+1, Dmitry A. Kazakov  wrote:
> On 2018-06-14 05:19, Lucretia wrote:
> > On Wednesday, 13 June 2018 20:19:30 UTC+1, Dmitry A. Kazakov  wrote:
> > 
> >> Unix, Windows, C could not be so efficient in burning everything down
> > 
> > Windows was originally written in Pascal, not C, C and C++ came later.
> 
> Windows 3.1 is 1992. C++ is a decade older, around 1980. C is another 
> decade older.

I didn't mean the languages came later, the Windows implementations in those languages did.

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-14 13:25, Lucretia wrote:
> On Thursday, 14 June 2018 08:26:35 UTC+1, Dmitry A. Kazakov  wrote:
>> On 2018-06-14 05:19, Lucretia wrote:
>>> On Wednesday, 13 June 2018 20:19:30 UTC+1, Dmitry A. Kazakov  wrote:
>>>
>>>> Unix, Windows, C could not be so efficient in burning everything down
>>>
>>> Windows was originally written in Pascal, not C, C and C++ came later.
>>
>> Windows 3.1 is 1992. C++ is a decade older, around 1980. C is another
>> decade older.
> 
> I didn't mean the languages came later, the Windows implementations in those languages did.

My guess is that Windows is still in QuickBASIC ...

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

Re: Ada Successor Language

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:1b03e4ff-daf1-4c13-84ef-13aec1ba96e9@googlegroups.com...
>IMO, the rise to prominence of Unix and C [and arguably C++] is the worst 
>thing that happened
>in the field of CS. The amount of money, time, energy, and effort sucked up 
>by these is so
>staggering to contemplate that it would be difficult to overestimate the 
>costs, both real [e.g.
>all the buffer overflow vulnerabilities] and opportunities lost [e.g. the 
>low-level of today's
>"advanced" continuous integration, or the cost of using the FS as a DB, or 
>the costs of
>moronically considering unstructured text as THE appropriate/native format 
>for storing
>programs].

While I agree with your basic premise, I'm dubious that there is a better 
format than unstructured text for programs. There were many such 
alternatives explored in the 1980's, and they all had the property of making 
editing more complex. (I tried one for a while when a vendor wanted us to 
consider bundling it; it was a very nice job for the time, but the attempt 
to keep code parsable at all times made it much harder to do program 
editing - one needed multiple steps to do what was easy to do in one step 
and a bit of text editing. For instance, consider cutting out an elsif 
branch and turning it into a stand-alone if statement -- a restucturing I 
tend to do fairly frequently.)

More generally, non-plain-text editors put barriers into program 
construction, and those barriers make one stop and worry about how to make 
the editor happy rather than continuing to worry about the actual problem 
you are solving. While some level of friction can be tolerated if it leads 
to big savings later (that's why we can tolerate Ada's strong typing!), 
syntax errors just aren't a significant enough problem (they get detected 
soon enough in any scheme) to give much benefit.

This area is a problem I've been thinking about for literally decades, and 
I'm pretty convinced that most of the "solutions" are worse than the problem 
they'd be fixing. For a new scheme to be better, it would have to have 
little friction.

I also worry about the fragility of databases. If some "unstructured text" 
gets corrupted, you might lose a subprogram or two. (That used to happen a 
lot in the old days, and it still does once in a while.) And you can usually 
get that from a backup. But a corrupted database is pretty much useless - if 
the recovery tools fail, the only choice is to reconstruct from scratch. (I 
just had to reinstall one of the subsystems on our Windows Server because of 
a problem like this - had to uninstall the entire subsystem, delete all of 
the files, and then reinstall. Luckily I mainly cared about getting rid of 
the error messages, not so much the loss of data.)

With databases, everything is harder than it is with simple files: backups, 
searching, etc. all need specialized tools. So the benefits would have to be 
massive in order to make up for the variety of tiny pains that would ensue.

                                               Randy. 

Re: Ada Successor Language

[Lucretia]

On Thursday, 14 June 2018 13:22:59 UTC+1, Dmitry A. Kazakov  wrote:

> My guess is that Windows is still in QuickBASIC ...

If it was any BASIC it would be Visual. But the sources have been leaked a number of times, I'm fairly sure it's C++ now, not that I've seen it. Neither do I care to.

Re: Ada Successor Language

[Lucretia]

On Thursday, 14 June 2018 22:00:24 UTC+1, Randy Brukardt  wrote:
> "Shark8" <> wrote in message 
> news:1b03e4ff-daf1-4c13-84ef-13aec1ba96e9@googlegroups.com...
> >IMO, the rise to prominence of Unix and C [and arguably C++] is the worst 
> >thing that happened

TBH, standardising on an OS API is not a bad idea, the fact they did it based on C and it's issues was a bad idea. The fact that Unix *was* originally open and availbale to pretty much all was a good thing, but when AT&T (I think) who revoked that, not a good move.


> >"advanced" continuous integration, or the cost of using the FS as a DB, or 
> >the costs of
> >moronically considering unstructured text as THE appropriate/native format 
> >for storing
> >programs].
> 
> While I agree with your basic premise, I'm dubious that there is a better 
> format than unstructured text for programs. There were many such 
> alternatives explored in the 1980's, and they all had the property of making 
> editing more complex. (I tried one for a while when a vendor wanted us to 

I agree that the whole idea that the source should be a DB is a bad idea from the outset. The idea of the APSE was hated from the outset, pretty much every idea that Shark8 has about bringing Ada "back" is from the original bad ideas that everyone hated and there are numerous papers on what was bad at the time. Time to move on and not repeat the mistakes of the past, especially where Ada is concerned.

Luke.

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-15 05:41, Lucretia wrote:
> On Thursday, 14 June 2018 22:00:24 UTC+1, Randy Brukardt  wrote:

>> While I agree with your basic premise, I'm dubious that there is a better
>> format than unstructured text for programs. There were many such
>> alternatives explored in the 1980's, and they all had the property of making
>> editing more complex. (I tried one for a while when a vendor wanted us to
> 
> I agree that the whole idea that the source should be a DB is a bad idea from the outset.

It is two different ideas, actually.

1. The source code is not stream of characters but a persistent object 
of certain structure, e.g. a text buffer.

2. The source code objects have dependencies and grouped in larger 
structures.

Both ideas are valid, good and long time due. The only obstacle are two 
horrific families of OS - Unix and Windows.

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

Re: Ada Successor Language

[Simon Wright]

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

> While I agree with your basic premise, I'm dubious that there is a
> better format than unstructured text for programs. There were many
> such alternatives explored in the 1980's, and they all had the
> property of making editing more complex. (I tried one for a while when
> a vendor wanted us to consider bundling it; it was a very nice job for
> the time, but the attempt to keep code parsable at all times made it
> much harder to do program editing - one needed multiple steps to do
> what was easy to do in one step and a bit of text editing. For
> instance, consider cutting out an elsif branch and turning it into a
> stand-alone if statement -- a restucturing I tend to do fairly
> frequently.)

The R1000 had three phases for a unit: the first, whose name I forget,
was essentially free text; the second was 'semanticised', i.e. parsed
and checked for legality; the third, again I forget the name, was
code-generated. Once a unit was semanticised, the free text form was
forgotten and would be regenerated if you needed to edit the unit.

Annoying if you really didn't like the code format enforced by the
system, but it didn't take long to let go of that particular form of
artistic hubris!

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-15 05:35, Lucretia wrote:
> On Thursday, 14 June 2018 13:22:59 UTC+1, Dmitry A. Kazakov  wrote:
> 
>> My guess is that Windows is still in QuickBASIC ...
> 
> If it was any BASIC it would be Visual.

No way! Visual Basic is not backward compatible with itself. It must 
QuickBASIC, as the legend tells that B.G. personally wrote a few lines 
of ...

> But the sources have been leaked a number of times, I'm fairly sure it's C++ now, not that I've seen it. Neither do I care to.

Same here. (:-))

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

Re: Ada Successor Language

[jm.tarrasa]

> 
> I used Rational in one project and can confirm, I was impressed.
> 
Just curious.
How much cost a seat of such impressing environment?

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-15 13:38, jm.tarrasa@gmail.com wrote:
>>
>> I used Rational in one project and can confirm, I was impressed.
>>
> Just curious.
> How much cost a seat of such impressing environment?

I cannot say, we were a subcontractor, all expenses were paid by another 
party.

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

Re: Ada Successor Language

[J-P. Rosen]

Le 15/06/2018 à 14:06, Dmitry A. Kazakov a écrit :
> On 2018-06-15 13:38, jm.tarrasa@gmail.com wrote:
>>>
>>> I used Rational in one project and can confirm, I was impressed.
>>>
>> Just curious.
>> How much cost a seat of such impressing environment?
> 
> I cannot say, we were a subcontractor, all expenses were paid by another
> party.
> 
I don't know the exact price, but all users I met said that
1) it was very expensive
2) the price was quickly covered by the gains in productivity

-- 
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: Ada Successor Language

[Lucretia]

On Friday, 15 June 2018 08:20:27 UTC+1, Dmitry A. Kazakov  wrote:
> On 2018-06-15 05:35, Lucretia wrote:
> > On Thursday, 14 June 2018 13:22:59 UTC+1, Dmitry A. Kazakov  wrote:
> > 
> >> My guess is that Windows is still in QuickBASIC ...
> > 
> > If it was any BASIC it would be Visual.
> 
> No way! Visual Basic is not backward compatible with itself. It must 
> QuickBASIC, as the legend tells that B.G. personally wrote a few lines 
> of ...

If BG had anytrhing to do with it, then QuickBASIC would've been too unstable to do anything with. I used AmigaBASIC bitd and it crashed a lot, that was written by BG apparently.

;)

Re: Ada Successor Language

[Simon Wright]

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

> Le 15/06/2018 à 14:06, Dmitry A. Kazakov a écrit :
>> On 2018-06-15 13:38, jm.tarrasa@gmail.com wrote:
>>>>
>>>> I used Rational in one project and can confirm, I was impressed.
>>>>
>>> Just curious.
>>> How much cost a seat of such impressing environment?
>> 
>> I cannot say, we were a subcontractor, all expenses were paid by
>> another party.
>> 
> I don't know the exact price, but all users I met said that
> 1) it was very expensive
> 2) the price was quickly covered by the gains in productivity

I worked for Ferranti at the time; we had a site in Cwmbran which was
the software engineering & research part (from our point of view,
what we'd now call toolchain and driver developers).

The Cwmbran team had I think 7 R1000s. This was (according to a rumour)
because they weren't happy with Rational's CMVC (Configuration
Management & Version Control) and insisted on implementing their own on
top of it, so needed more machines than Rational would have thought
necessary. Good for Rational's bottom line, of course.

Re: Ada Successor Language

[jm.tarrasa]

> > 
> I don't know the exact price, but all users I met said that
> 1) it was very expensive
> 2) the price was quickly covered by the gains in productivity

How much is "very expensive"?
Are similar products for other languages as expensive?

Re: Ada Successor Language

[Shark8]

On Friday, June 15, 2018 at 11:55:18 AM UTC-6, jm.ta...@gmail.com wrote:
> > > 
> > I don't know the exact price, but all users I met said that
> > 1) it was very expensive
> > 2) the price was quickly covered by the gains in productivity
> 
> How much is "very expensive"?
> Are similar products for other languages as expensive?

AFAIK, there's no other "similar product" to that degree. What is really interesting though is the statement "the price was quickly covered by the gains in productivity" -- this means the utility in ONLY productivity was enough to quickly pay for itself.

The reason is that the entire thing was an Integrated Development Environment in the true sense of the phrase, not the "hyped up editor" (a slight exaggeration) that modern IDEs get. / One of the issues is that the tools in such environments *AREN'T* integrated. So you get idiotic text-based source control where

   int main() { while (true){}; }
and
   int main()
   { while (true){}; }

are actually *different* -- this means that stupid things like 'style', "tabs vs. spaces" and other formatting elements are flagged as 'changes' completely apart from any semantic alteration. (This means that, within such source-control, there can be many "false positives" when you're looking at a change-log... and even if you have the proper revision loaded, finding the actual alteration that was supposed to be logged might be difficult because so many non-semantic changes interfere with getting a picture of the actual semantic changes. [ex: looking at a diff when someone's editor helpfully changed tabs/spaces and they committed some buggy code.])

The lack of integration can be seen in other areas too; take CPAN [perl's package manager] for instance -- it's essentially a giant archive of zip-files and an index, synchronized across a network -- so far, so good & everything works well... until the text-based index is corrupted or there's clashes between zip-files or such. // An alternative would be to store the code as a DB-amiable IR, which is stored in a DB... things could be done here like *automatically* tracking dependencies, and compatibilities within these dependencies; such an effort would be incredibly hard to set-up [and maintain] in the "text-file + zip-files" approach.

This sort of integration is something that isn't all that common in the places I've worked, which usually go with various individual tools.

----------
This Technical Report [1988; 92 pg] describes the whole thing:
http://resources.sei.cmu.edu/asset_files/TechnicalReport/1988_005_001_15650.pdf

There's an Army Report [1995; 72 pg] here, which I haven't read yet:
http://www.dtic.mil/get-tr-doc/pdf?AD=ADA301551

Re: Ada Successor Language

[Dennis Lee Bieber]

On Fri, 15 Jun 2018 09:03:59 -0700 (PDT), Lucretia
<laguest9000@googlemail.com> declaimed the following:

>
>If BG had anytrhing to do with it, then QuickBASIC would've been too unstable to do anything with. I used AmigaBASIC bitd and it crashed a lot, that was written by BG apparently.
>
	It was still better than the MetaComCo ABC (or ABasiC or some such)
that came with first generation AmigaOS.

	Once ARexx was released, it became my goto for quick&dirty programs
(especially with the add-on library that gave support for standard
requesters and dialogs). Then came Irmen's port of Python... and within a
week I'd written an out-going mail daemon that WORKED for my needs. At that
time, mail clients were ports from UNIX (AmigaELM?) and worked with local
mailbox files that had to be populated by a separate POP client program,
and relied upon external scripts to spool outgoing mail for SMTP program to
send... Well, the first such SMTP I tried would attempt direct connection
to each addressee (not even checking MX records for routing, obviously this
was before the practice of having to relay via one's ISP started) -- and
would block the entire pending queue if one message could not be sent. The
second program I tried did use ISP relay mode, but it did not parse CC and
BCC headers so only addresses found in the TO header would receive the
mail. My Python daemon correctly extracted TO, CC, and BCC (and then
removed BCC from the message itself) and relayed to the ISP (I used a short
ARexx script for the mail client submission/queue handler).


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

Re: Ada Successor Language

[Simon Wright]

Shark8 <onewingedshark@gmail.com> writes:

>  (This means that, within such source-control, there can be many
> "false positives" when you're looking at a change-log... and even if
> you have the proper revision loaded, finding the actual alteration
> that was supposed to be logged might be difficult because so many
> non-semantic changes interfere with getting a picture of the actual
> semantic changes. [ex: looking at a diff when someone's editor
> helpfully changed tabs/spaces and they committed some buggy code.])

I had to refuse an offer to collaborate on the Ada 95 Booch Components
because the person insisted on editing using an editor (Grasp?) which
didn't respect the original layout.

Mind, someone who insisted on using an editor that did that might not
have been a very good collaborator anyway.

Re: Ada Successor Language

[jm.tarrasa]

 
> AFAIK, there's no other "similar product" to that degree.

For me, Visual Studio is more stable and advanced that GPS or any Ada toolchain. I don't know what has Rational, but I find Visual Studio impressing.

>What is really interesting though is the statement "the price was quickly covered by the gains in productivity" -- this means the utility in ONLY productivity was enough to quickly pay for itself.

It looks that nobody can answer how much is a seat of Rational (and that is scaring). I've heard about 15.000$, but I can't confirm or deny it. If I'm doing projects of 10 millions dollars, 15.000 may be acceptable. If I'm doing 50.000 100.000$ projects, it is not.

So, maybe there is one of the answers of why Ada is not more popular. Only deep pockets and really big project can use Ada at its full power.

> are actually *different* -- this means that stupid things like 'style', "tabs vs. spaces" and other formatting elements are flagged as 'changes' completely apart from any semantic alteration. (This means that, within such source-control, there can be many "false positives" when you're looking at a change-log...

Formatting and styles *are changes*. In fact I make commits to correct style. Maybe editors should store source in a compact format and reflow it on the fly when you load the file, so, if you load with a classic editor a source of  Ada,C,C++, etc, you would only see a very long line. But until such editors become the mainstream, changes in formatting and style are not false positives, are changes that must be committed.

> 
> This sort of integration is something that isn't all that common in the places I've worked, which usually go with various individual tools.

Most IDEs integrate Editor (with completion, refactoring, jumping easily from a definition to another, stubs, help and a few things), some kind of files of project and a Debugger.

There are other tools (Version control, code analyzers etc) Does integrating such tools boots productivity a 20%? I don't think so. So, if the environment is a 5% of prize of the project or a 20% of the project, the level of integration may be secondary.

Re: Ada Successor Language

[Simon Wright]

jm.tarrasa@gmail.com writes:

> It looks that nobody can answer how much is a seat of Rational (and
> that is scaring). I've heard about 15.000$, but I can't confirm or
> deny it. If I'm doing projects of 10 millions dollars, 15.000 may be
> acceptable. If I'm doing 50.000 100.000$ projects, it is not.

We've been talking about the Rational R1000 (Delta 4, I think)
Environment, which ran on custom hardware (the R1000). Rational then
developed Apex (or ported Delta 4) to provide the same/similar
facilities on then-common hardware. Sold to IBM ... Atego ... PTC.

I've never used Apex.

https://en.wikipedia.org/wiki/Rational_R1000
http://www.adaic.org/ada-resources/pro-tools-services/
https://www.ptc.com/en/products/developer-tools/apexada

Re: Ada Successor Language

[Jeffrey R. Carter]

On 06/16/2018 12:22 PM, Simon Wright wrote:
> 
> We've been talking about the Rational R1000 (Delta 4, I think)
> Environment, which ran on custom hardware (the R1000). Rational then
> developed Apex (or ported Delta 4) to provide the same/similar
> facilities on then-common hardware. Sold to IBM ... Atego ... PTC.
> 
> I've never used Apex.

I never used the R1000, but I saw it demonstrated once.

I used Apex on 2 projects. The thing about it is that it stores the code in an 
internal format (DIANA, I think), not as text. When you view a unit as text, the 
code is formatted according to your preferences. That means everyone on a 
project may use his personal formatting preferences without impacting anyone 
else. While entering or editing text, the editor formats on the fly pretty 
aggressively, and tends to point out syntax errors.

There are default formatting preferences, which are pretty poor IMO, and a way 
to modify them, though finding the place to do that just from the UI seemed to 
be impossible. One project decided everyone should use the default. On the 
other, they had instructions on how to change your preferences, so everyone 
customized theirs. The only drawback to this was when you looked at code on 
another's display, and the formatting was not what you were used to.

-- 
Jeff Carter
"That was the most fun I've ever had without laughing."
Annie Hall
43

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-16 11:14, jm.tarrasa@gmail.com wrote:

> For me, Visual Studio is more stable and advanced that GPS or any Ada toolchain.

Actually GPS is more stable than VS now. It is pretty much faster and 
has better source code navigation. Another huge problem with VS is that 
each new version brings new project formats, new incompatibilities, new 
look and feel. I did a lot of VS migration 2003 to 2005 to 2008 to 2010, 
and now incoming 2017 horror. The only bad thing about GPS is the debugger.

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

Re: Ada Successor Language

[Dan'l Miller]

On Monday, June 4, 2018 at 7:17:26 PM UTC-5, Shark8 wrote:
> (ALSO: I personally think that a user definable "abstract type interface" [kinda/sorta type classes], as well
> as user-definable attributes, would be great ways to handle the above while expanding the capabilities of
> Ada'Succ.)

Ada'Succ is an awesome name at some level (e.g., "Ada'Succ" would be unique on WWW searches).  Instead of a play on Ada Lovelace Byron's name et cetera, it is the 2nd insect regarding Ada when read phonetically:  Ada tick suck.  The mascot could be literally be a tick insect.

(Ada95 would be either Ada'Class or Ada'Tag under this system of monikers.)

With some creativity, somehow the sucking blood metaphor of “ada tick suck” could be retailored to be a positive meaning.  E.g.,

1) the Boost project that is influencing modern C++ in the 21st century was originally jokingly named Booze as a beverage even better than Java/coffee/joe.  Booze got morphed into Boost.

2) Boilermaker was an insult applied by another college-town's newspaper to Purdue University's athletes back in the 19th century who were working part-time at a local steam-equipment factory to pay their way through Purdue University.  Instead of being an insult, those athletes wore the moniker as their official badge of honor as their official team name.

Where there is a will, there is a way.

Re: Ada Successor Language

[Björn Lundin]

On 2018-06-18 05:31, Dan'l Miller wrote:
> Ada'Succ is an awesome name at some level (e.g., "Ada'Succ" would be unique on WWW searches).  
> Instead of a play on Ada Lovelace Byron's name et cetera, it is the
2nd insect regarding Ada when read phonetically:
> Ada tick suck.  The mascot could be literally be a tick insect.

Another pun in the spirit of c++ is tcl's OO framework
called 'incr tcl'.

i++ in tcl is written as incr i
No-one but tcl:ers know this. It is a bad name.
How many, execpt ada:ers, know the meaning of T'Succ?

Besides, a tick is a nasty spider related animal, arachnid. Not an
insect. And it is the bearer of at lest two seroius deceases (TBE and
Borrelios). Really want that as a mascot? I don't.


And I can really imagine problems on wiki-pages and other printed
materail when you say
<source lang='Ada'Succ'>

The parsers/string handlers will not like it.


-- 
--
Björn

Re: Ada Successor Language

[Dan'l Miller]

On Monday, June 18, 2018 at 1:58:13 AM UTC-5, björn lundin wrote:
> On 2018-06-18 05:31, Dan'l Miller wrote:
> > Ada'Succ is an awesome name at some level (e.g., "Ada'Succ" would be unique on WWW searches).  
> > Instead of a play on Ada Lovelace Byron's name et cetera, it is the
> 2nd insect regarding Ada when read phonetically:
> > Ada tick suck.  The mascot could be literally be a tick insect.
> 
> Another pun in the spirit of c++ is tcl's OO framework
> called 'incr tcl'.
> 
> i++ in tcl is written as incr i
> No-one but tcl:ers know this. It is a bad name.
> How many, execpt ada:ers, know the meaning of T'Succ?
> 
> Besides, a tick is a nasty spider related animal, arachnid. Not an
> insect.

8-bit bites from a tick would be more appropriate for a computer-programming language than a 6-bit bite from an insect anyway.

Re: Ada Successor Language

[Niklas Holsti]

On 18-06-18 06:31 , Dan'l Miller wrote:
> On Monday, June 4, 2018 at 7:17:26 PM UTC-5, Shark8 wrote:
>> (ALSO: I personally think that a user definable "abstract type
>> interface" [kinda/sorta type classes], as well as user-definable
>> attributes, would be great ways to handle the above while expanding
>> the capabilities of Ada'Succ.)
>
> Ada'Succ is an awesome name at some level (e.g., "Ada'Succ" would be
> unique on WWW searches).

Nah... invites "Ada'Succ sucks".

My entry into the pool of names: Ada Nouveau.

The first DuckDuckGo hit (for me) is the "Beaujolais effect" from Wikipedia.

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

Re: Ada Successor Language

[Dan'l Miller]

On Monday, June 18, 2018 at 2:16:31 PM UTC-5, Niklas Holsti wrote:
> My entry into the pool of names: Ada Nouveau.

Ada'Tock:  Time marches onward.

Re: Ada Successor Language

[Jeffrey R. Carter]

On 06/18/2018 09:16 PM, Niklas Holsti wrote:
> 
> Nah... invites "Ada'Succ sucks".

Also, in Ada, Ada'Succ is not the successor of Ada.

-- 
Jeff Carter
"He nevere yet no vileynye ne sayde
In al his lyf unto no maner wight."
Canterbury Tales
156

Re: Ada Successor Language

[Niklas Holsti]

On 18-06-18 23:22 , Jeffrey R. Carter wrote:
> On 06/18/2018 09:16 PM, Niklas Holsti wrote:
>>
>> Nah... invites "Ada'Succ sucks".
>
> Also, in Ada, Ada'Succ is not the successor of Ada.

But perhaps the successor language will let us write X'Succ as an 
abbreviation of X_Type'Succ(X) ... similarly to the recent introduction 
of X'Image.

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

Re: Ada Successor Language

[Shark8]

On Monday, June 18, 2018 at 2:45:39 PM UTC-6, Niklas Holsti wrote:
> On 18-06-18 23:22 , Jeffrey R. Carter wrote:
> > On 06/18/2018 09:16 PM, Niklas Holsti wrote:
> >>
> >> Nah... invites "Ada'Succ sucks".
> >
> > Also, in Ada, Ada'Succ is not the successor of Ada.
> 
> But perhaps the successor language will let us write X'Succ as an 
> abbreviation of X_Type'Succ(X) ... similarly to the recent introduction 
> of X'Image.

I'd honestly like the ability to use X'Type; this would allow us to say something like this:

Procedure Swap( A, B : in out Some_Type ) is
  Temp : Constant B'Type := B;
Begin
  B:= A;
  A:= Temp;
End Swap;

Yeah, I know, it's a little thing and you can do it with generics, etc. But that's not entirely the point, the point is that this allows the declaration of types dependent on objects... it provides some of the niceties of type-inference without having to resort to such lazy/possibly-error-prone methodologies.

Re: Ada Successor Language

[ric.wai88]

On Monday, June 18, 2018 at 5:20:32 PM UTC-4, Shark8 wrote:

> I'd honestly like the ability to use X'Type; this would allow us to say something like this:
> 
> Procedure Swap( A, B : in out Some_Type ) is
>   Temp : Constant B'Type := B;
> Begin
>   B:= A;
>   A:= Temp;
> End Swap;
> 
> Yeah, I know, it's a little thing and you can do it with generics, etc. But that's not entirely the point, the point is that this allows the declaration of types dependent on objects... it provides some of the niceties of type-inference without having to resort to such lazy/possibly-error-prone methodologies.


Why would you want that? You have to have visibility to the type to declare an object of the type. In your above example, you explicitly know about Some_Type, and you also explicitly know that A and B are of that type. So you don't need to query the parameter, since it is implicit.

Your example above has no purpose. It would be better in ever single respect to just say:

Temp: constant Some_Type := B;

Any other case where you wouldn't know about the type until runtime is exactly what generics are for.

Re: Ada Successor Language

[Shark8]

On Monday, June 18, 2018 at 3:27:13 PM UTC-6, ric....@gmail.com wrote:
> On Monday, June 18, 2018 at 5:20:32 PM UTC-4, Shark8 wrote:
> 
> > I'd honestly like the ability to use X'Type; this would allow us to say something like this:
> > 
> > [snip]
> > 
> > Yeah, I know, it's a little thing and you can do it with generics, etc. But that's not entirely the point, the point is that this allows the declaration of types dependent on objects... it provides some of the niceties of type-inference without having to resort to such lazy/possibly-error-prone methodologies.
> 
> 
> Why would you want that? You have to have visibility to the type to declare an object of the type. In your above example, you explicitly know about Some_Type, and you also explicitly know that A and B are of that type. So you don't need to query the parameter, since it is implicit.
> 
> Your example above has no purpose.

Unless you're rapid-prototyping.

> > Procedure Swap( A, B : in out Some_Other_Type ) is
> >   Temp : Constant B'Type := B;
> > Begin
> >   B:= A;
> >   A:= Temp;
> > End Swap;

One change in the above, no change-cascades into the body.

This is precisely why text is such a bad format to think of as "natural" for the 'source' -- it's not -- what we really have here problem-wise stated in plain language is: "Given some type, and two names referring to them, switch which names belong to which object."

But that brings up something else that would be nice, the ability to do a swap like so:

(a, b) := (b, a);

> Any other case where you wouldn't know about the type until runtime is exactly what generics are for.

Generics in Ada are statically known at compile-time, just as the given example.

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-18 23:20, Shark8 wrote:
> On Monday, June 18, 2018 at 2:45:39 PM UTC-6, Niklas Holsti wrote:
>> On 18-06-18 23:22 , Jeffrey R. Carter wrote:
>>> On 06/18/2018 09:16 PM, Niklas Holsti wrote:
>>>>
>>>> Nah... invites "Ada'Succ sucks".
>>>
>>> Also, in Ada, Ada'Succ is not the successor of Ada.
>>
>> But perhaps the successor language will let us write X'Succ as an
>> abbreviation of X_Type'Succ(X) ... similarly to the recent introduction
>> of X'Image.
> 
> I'd honestly like the ability to use X'Type; this would allow us to say something like this:
> 
> Procedure Swap( A, B : in out Some_Type ) is
>    Temp : Constant B'Type := B;
> Begin
>    B:= A;
>    A:= Temp;
> End Swap;
> 
> Yeah, I know, it's a little thing and you can do it with generics, etc. But that's not entirely the point, the point is that this allows the declaration of types dependent on objects... it provides some of the niceties of type-inference without having to resort to such lazy/possibly-error-prone methodologies.

It is not a little thing. It requires classes for all types.

Then all types with assignment (non-limited types) will be members of 
the class Not_Limited [*]. E.g.

    type Integer is ... and Not_Limited;
    type String  is ... and Not_Limited;
    ...

Then you could write a class-wide Swap:

    procedure Swap (A, B : in out Not_Limited'Class) is
       Temp : constant Not_Limited'Class := B;
    begin
       B := A;
       A := Temp;
    end Swap;

-----------------------------
* You must also deal with type cloning, so that

    type X is new Integer;

will get its own copy of the Not_Limited class. I.e. the whole type tree 
must be copied. It is not a little thing.

P.S. Stepanov arguing for generics (templates) claimed that the reason 
why C++ needed this mess was impossibility to write Max using dynamic 
polymorphism. Generic Swap is a similar case. I believe it is possible 
to have a language where generic Max and Swap could be written without 
generics.

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

Re: Ada Successor Language

[Paul Rubin]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> P.S. Stepanov arguing for generics (templates) claimed that the reason
> why C++ needed this mess was impossibility to write Max using dynamic
> polymorphism... I believe it is possible to have a language where
> generic Max and Swap could be written without generics.

I've been wanting to look up how Ada generics work.  C++ generics are
implemented with templates which leads to a horrible mess, but generics
themselves don't have to be a mess, as far as I know.

Some comparisons:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.110.122&rep=rep1&type=pdf

Re: Ada Successor Language

[Dan'l Miller]

On Monday, June 18, 2018 at 5:36:56 PM UTC-5, Paul Rubin wrote:
> "Dmitry A. Kazakov" writes:
> > P.S. Stepanov arguing for generics (templates) claimed that the reason
> > why C++ needed this mess was impossibility to write Max using dynamic
> > polymorphism... I believe it is possible to have a language where
> > generic Max and Swap could be written without generics.
> 
> I've been wanting to look up how Ada generics work.  C++ generics are
> implemented with templates which leads to a horrible mess, but generics
> themselves don't have to be a mess, as far as I know.
> 
> Some comparisons:
> 
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.110.122&rep=rep1&type=pdf

It seems that Ada would score rather well in Table 1 on page 4 had it been included:

Ada
 ●   :   multi-type concepts
 ●   :   multiple constraints
 ●   :   associated type access
 ◒   :   constraints on associated types
 ●   :   type aliases
 ●   :   separate compilation (exemplary Ada compilers)
 ●   :   implicit argument deduction

Re: Ada Successor Language

[Lucretia]

On Monday, 18 June 2018 20:16:31 UTC+1, Niklas Holsti  wrote:

> > Ada'Succ is an awesome name at some level (e.g., "Ada'Succ" would be
> > unique on WWW searches).
> 
> Nah... invites "Ada'Succ sucks".

ADa'Succs
 
> My entry into the pool of names: Ada Nouveau.

Nope. Said it before, I'll say it again, get rid of the name Ada and all connotations, otherwise you're just dooming any new language to the same fate.

Re: Ada Successor Language

[Shark8]

On Monday, June 18, 2018 at 4:23:41 PM UTC-6, Dmitry A. Kazakov wrote:
> On 2018-06-18 23:20, Shark8 wrote:
> > On Monday, June 18, 2018 at 2:45:39 PM UTC-6, Niklas Holsti wrote:
> >> On 18-06-18 23:22 , Jeffrey R. Carter wrote:
> >>> On 06/18/2018 09:16 PM, Niklas Holsti wrote:
> >>>>
> >>>> Nah... invites "Ada'Succ sucks".
> >>>
> >>> Also, in Ada, Ada'Succ is not the successor of Ada.
> >>
> >> But perhaps the successor language will let us write X'Succ as an
> >> abbreviation of X_Type'Succ(X) ... similarly to the recent introduction
> >> of X'Image.
> > 
> > I'd honestly like the ability to use X'Type; this would allow us to say something like this:
> > 
> > Procedure Swap( A, B : in out Some_Type ) is
> >    Temp : Constant B'Type := B;
> > Begin
> >    B:= A;
> >    A:= Temp;
> > End Swap;
> > 
> > Yeah, I know, it's a little thing and you can do it with generics, etc. But that's not entirely the point, the point is that this allows the declaration of types dependent on objects... it provides some of the niceties of type-inference without having to resort to such lazy/possibly-error-prone methodologies.
> 
> It is not a little thing. It requires classes for all types.

No, it doesn't.
A 'Type attribute could simply mean "the [sub]type of this object", and thereby given "A : Positive" we know that A'Type is positive, statically, at compile time, and without any notion of classes.

> 
> Then all types with assignment (non-limited types) will be members of 
> the class Not_Limited [*]. E.g.
> 
>     type Integer is ... and Not_Limited;
>     type String  is ... and Not_Limited;
>     ...

Why would they need to have a Not_Limited class? We already know they're not limited from the type declaration "Type Integer is new System.Integer;"...
We can currently use the generic-language "type T (<>) is abstract tagged limited private;" to specify "Any tagged type, abstract or concrete, limited or not."


> Then you could write a class-wide Swap:
> 
>     procedure Swap (A, B : in out Not_Limited'Class) is
>        Temp : constant Not_Limited'Class := B;
>     begin
>        B := A;
>        A := Temp;
>     end Swap;
> 
> -----------------------------
> * You must also deal with type cloning, so that
> 
>     type X is new Integer;
> 
> will get its own copy of the Not_Limited class. I.e. the whole type tree 
> must be copied. It is not a little thing.

Why would it need a Not_Limited class? It looks like you're trying to combine regular "Interface" with the attributes-and-classification of the type.

Re: Ada Successor Language

[G. B.]

Shark8 <onewingedshark@gmail.com> wrote:

> I'd honestly like the ability to use X'Type; this would allow us to say
> something like this:
> 
> Procedure Swap( A, B : in out Some_Type ) is
>   Temp : Constant B'Type := B;
> Begin
>   B:= A;
>   A:= Temp;
> End Swap;
> 
> Yeah, I know, it's a little thing and you can do it with generics, etc.
> But that's not entirely the point, the point is that this allows the
> declaration of types dependent on objects... it provides some of the
> niceties of type-inference without having to resort to such
> lazy/possibly-error-prone methodologies.
> 

What is the ‘Size of B’Type?

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-19 04:45, Shark8 wrote:
> On Monday, June 18, 2018 at 4:23:41 PM UTC-6, Dmitry A. Kazakov wrote:
>> On 2018-06-18 23:20, Shark8 wrote:
>>> On Monday, June 18, 2018 at 2:45:39 PM UTC-6, Niklas Holsti wrote:
>>>> On 18-06-18 23:22 , Jeffrey R. Carter wrote:
>>>>> On 06/18/2018 09:16 PM, Niklas Holsti wrote:
>>>>>>
>>>>>> Nah... invites "Ada'Succ sucks".
>>>>>
>>>>> Also, in Ada, Ada'Succ is not the successor of Ada.
>>>>
>>>> But perhaps the successor language will let us write X'Succ as an
>>>> abbreviation of X_Type'Succ(X) ... similarly to the recent introduction
>>>> of X'Image.
>>>
>>> I'd honestly like the ability to use X'Type; this would allow us to say something like this:
>>>
>>> Procedure Swap( A, B : in out Some_Type ) is
>>>     Temp : Constant B'Type := B;
>>> Begin
>>>     B:= A;
>>>     A:= Temp;
>>> End Swap;
>>>
>>> Yeah, I know, it's a little thing and you can do it with generics, etc. But that's not entirely the point, the point is that this allows the declaration of types dependent on objects... it provides some of the niceties of type-inference without having to resort to such lazy/possibly-error-prone methodologies.
>>
>> It is not a little thing. It requires classes for all types.
> 
> No, it doesn't.
> A 'Type attribute could simply mean "the [sub]type of this object", and thereby given "A : Positive" we know that A'Type is positive, statically, at compile time, and without any notion of classes.

X'Type is useless because it does not reveal anything about the type, 
e.g. if you can assign it. X can be a task.

And you cannot use it in declaration without having an object.

>> Then all types with assignment (non-limited types) will be members of
>> the class Not_Limited [*]. E.g.
>>
>>      type Integer is ... and Not_Limited;
>>      type String  is ... and Not_Limited;
>>      ...
> 
> Why would they need to have a Not_Limited class? We already know they're not limited from the type declaration "Type Integer is new System.Integer;"...

You must be able to declare a class-wide non-limited object in order to 
define an operation dealing with it. It is just what strong manifested 
typing is.

> We can currently use the generic-language "type T (<>) is abstract tagged limited private;" to specify "Any tagged type, abstract or concrete, limited or not."

Integer is not tagged.

>> Then you could write a class-wide Swap:
>>
>>      procedure Swap (A, B : in out Not_Limited'Class) is
>>         Temp : constant Not_Limited'Class := B;
>>      begin
>>         B := A;
>>         A := Temp;
>>      end Swap;
>>
>> -----------------------------
>> * You must also deal with type cloning, so that
>>
>>      type X is new Integer;
>>
>> will get its own copy of the Not_Limited class. I.e. the whole type tree
>> must be copied. It is not a little thing.
> 
> Why would it need a Not_Limited class? It looks like you're trying to combine regular "Interface" with the attributes-and-classification of the type.

I don't know what "regular interface" is, but each type implements a lot 
of interfaces, most of which are implicit in Ada. E.g. Integer is 
copyable (has ":="), comparable (has "="), ordered (has ">"), additive 
group (has "+") etc.

If these interfaces were explicit and allowed run-time instances 
(class-wide objects of) then things like Swap would work right off the 
shelf. We could write generic algorithms (as in Stepanov's STL) in terms 
of these interfaces rather than in terms of generic instances.

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

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-19 00:36, Paul Rubin wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> P.S. Stepanov arguing for generics (templates) claimed that the reason
>> why C++ needed this mess was impossibility to write Max using dynamic
>> polymorphism... I believe it is possible to have a language where
>> generic Max and Swap could be written without generics.
> 
> I've been wanting to look up how Ada generics work.  C++ generics are
> implemented with templates which leads to a horrible mess, but generics
> themselves don't have to be a mess, as far as I know.

There are 50 shades of mess. Ada's generics try to introduce some 
weakly-typed contracts on the formal generic parameters, where C++ 
templates go completely untyped, but mess is always mess. You cannot 
make a decent language out of macro processor.

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

Re: Ada Successor Language

[Dan'l Miller]

On Tuesday, June 19, 2018 at 2:35:30 AM UTC-5, G. B. wrote:
> Shark8 wrote:
> 
> > I'd honestly like the ability to use X'Type; this would allow us to say
> > something like this:
> > 
> > Procedure Swap( A, B : in out Some_Type ) is
> >   Temp : Constant B'Type := B;
> > Begin
> >   B:= A;
> >   A:= Temp;
> > End Swap;
> > 
> > Yeah, I know, it's a little thing and you can do it with generics, etc.
> > But that's not entirely the point, the point is that this allows the
> > declaration of types dependent on objects... it provides some of the
> > niceties of type-inference without having to resort to such
> > lazy/possibly-error-prone methodologies.
> > 
> 
> What is the ‘Size of B’Type?

Zero

Re: Ada Successor Language

[Dan'l Miller]

On Monday, June 18, 2018 at 7:20:15 PM UTC-5, Lucretia wrote:
> On Monday, 18 June 2018 20:16:31 UTC+1, Niklas Holsti  wrote:
> > My entry into the pool of names: Ada Nouveau.
> 
> Nope. Said it before, I'll say it again, get rid of the name Ada and all connotations, otherwise you're just
> dooming any new language to the same fate.

Ada Nouveau, Ada'Succ, HyperAda, or whatever its name would be needs both Ada's current syntax as well as a C-esque syntax mapped isomorphically as a per-programmer preference, normalized at check-out from and check-in to repositories much the same as tabs/spaces conversion or LF/CRLF line termination conversion.

To that end, both syntaxes of the same language each need their own distinct name.  Given that A and D are hexadecimal digits, this lends itself nicely to:
1) the successor-to-Ada with the current syntax would be called Ada#16 (pronounced Ada hex)
but
2) the isomorphic mapping to C-esque syntax would be called 0xAda (pronounced hex Ada).

And Luke can call them 2778#10 and 2778 if he likes to eliminate the name Ada by converting to base 10.

Re: Ada Successor Language

[Dan'l Miller]

On Tuesday, June 19, 2018 at 6:51:20 AM UTC-5, Dan'l Miller wrote:
> On Monday, June 18, 2018 at 7:20:15 PM UTC-5, Lucretia wrote:
> > On Monday, 18 June 2018 20:16:31 UTC+1, Niklas Holsti  wrote:
> > > My entry into the pool of names: Ada Nouveau.
> > 
> > Nope. Said it before, I'll say it again, get rid of the name Ada and all connotations, otherwise you're just
> > dooming any new language to the same fate.
> 
> Ada Nouveau, Ada'Succ, HyperAda, or whatever its name would be needs both Ada's current syntax as
> well as a C-esque syntax mapped isomorphically as a per-programmer preference, normalized at check
> out from and check-in to repositories much the same as tabs/spaces conversion or LF/CRLF line
> termination conversion.
> 
> To that end, both syntaxes of the same language each need their own distinct name.  Given that A and D
> are hexadecimal digits, this lends itself nicely to:
> 1) the successor-to-Ada with the current syntax would be called Ada (pronounced Ada hex)
> but
> 2) the isomorphic mapping to C-esque syntax would be called 0xAda (pronounced hex Ada).
> 
> And Luke can call them 2778#10 and 2778 if he likes to eliminate the name Ada by converting to base
> 10.

Oh, I meant 16#Ada.  The confusion arose via:  in 16#Ada, the base would also be permitted to be specified by suffix subscripts:  16#Ada = Ada₁₆ = 2778₁₀ (= 0xAda in C).

Re: Ada Successor Language

[Shark8]

On Monday, June 18, 2018 at 4:23:41 PM UTC-6, Dmitry A. Kazakov wrote:
> On 2018-06-18 23:20, Shark8 wrote:
> > On Monday, June 18, 2018 at 2:45:39 PM UTC-6, Niklas Holsti wrote:
> >> On 18-06-18 23:22 , Jeffrey R. Carter wrote:
> >>> On 06/18/2018 09:16 PM, Niklas Holsti wrote:
> >>>>
> >>>> Nah... invites "Ada'Succ sucks".
> >>>
> >>> Also, in Ada, Ada'Succ is not the successor of Ada.
> >>
> >> But perhaps the successor language will let us write X'Succ as an
> >> abbreviation of X_Type'Succ(X) ... similarly to the recent introduction
> >> of X'Image.
> > 
> > I'd honestly like the ability to use X'Type; this would allow us to say something like this:
> > 
> > Procedure Swap( A, B : in out Some_Type ) is
> >    Temp : Constant B'Type := B;
> > Begin
> >    B:= A;
> >    A:= Temp;
> > End Swap;
> > 
> > Yeah, I know, it's a little thing and you can do it with generics, etc. But that's not entirely the point, the point is that this allows the declaration of types dependent on objects... it provides some of the niceties of type-inference without having to resort to such lazy/possibly-error-prone methodologies.
> 
> It is not a little thing. It requires classes for all types.

No, it doesn't.
A 'Type attribute could simply mean "the [sub]type of this object", and thereby given "A : Positive" we know that A'Type is positive, statically, at compile time, and without any notion of classes.

> 
> Then all types with assignment (non-limited types) will be members of 
> the class Not_Limited [*]. E.g.
> 
>     type Integer is ... and Not_Limited;
>     type String  is ... and Not_Limited;
>     ...

Why would they need to have a Not_Limited class? We already know they're not limited from the type declaration "Type Integer is new System.Integer;"...
We can currently use the generic-language "type T (<>) is abstract tagged limited private;" to specify "Any tagged type, abstract or concrete, limited or not."


> Then you could write a class-wide Swap:
> 
>     procedure Swap (A, B : in out Not_Limited'Class) is
>        Temp : constant Not_Limited'Class := B;
>     begin
>        B := A;
>        A := Temp;
>     end Swap;
> 
> -----------------------------
> * You must also deal with type cloning, so that
> 
>     type X is new Integer;
> 
> will get its own copy of the Not_Limited class. I.e. the whole type tree 
> must be copied. It is not a little thing.

Why would it need a Not_Limited class? It looks like you're trying to combine regular "Interface" with the attributes-and-classification of the type.

Re: Ada Successor Language

[Shark8]

On Tuesday, June 19, 2018 at 1:35:30 AM UTC-6, G. B. wrote:
> Shark8 wrote:
> 
> > I'd honestly like the ability to use X'Type; this would allow us to say
> > something like this:
> > 
> > Procedure Swap( A, B : in out Some_Type ) is
> >   Temp : Constant B'Type := B;
> > Begin
> >   B:= A;
> >   A:= Temp;
> > End Swap;
> > 
> > Yeah, I know, it's a little thing and you can do it with generics, etc.
> > But that's not entirely the point, the point is that this allows the
> > declaration of types dependent on objects... it provides some of the
> > niceties of type-inference without having to resort to such
> > lazy/possibly-error-prone methodologies.
> > 
> 
> What is the ‘Size of B’Type?

In the given case?
Since B'Type is Some_Type, B'Type'Size is exactly Some_Type'Size.

Re: Ada Successor Language

[G. B.]

Shark8 <onewingedshark@gmail.com> wrote:
> On Tuesday, June 19, 2018 at 1:35:30 AM UTC-6, G. B. wrote:
>> Shark8 wrote:
>> 
>>> I'd honestly like the ability to use X'Type; this would allow us to say
>>> something like this:
>>> 
>>> Procedure Swap( A, B : in out Some_Type ) is
>>> Temp : Constant B'Type := B;
>>> Begin
>>> B:= A;
>>> A:= Temp;
>>> End Swap;
>>> 
>>> Yeah, I know, it's a little thing and you can do it with generics, etc.
>>> But that's not entirely the point, the point is that this allows the
>>> declaration of types dependent on objects... it provides some of the
>>> niceties of type-inference without having to resort to such
>>> lazy/possibly-error-prone methodologies.
>>> 
>> 
>> What is the ‘Size of B’Type?
> 
> In the given case?
> Since B'Type is Some_Type, B'Type'Size is exactly Some_Type'Size.
> 

And the size of Some_Type is? Noting that the compiler can separately
compile procedures for  Some_Type which covers many different types... How
does it work?

Re: Ada Successor Language

[Paul Rubin]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> There are 50 shades of mess. Ada's generics try to introduce some
> weakly-typed contracts on the formal generic parameters, where C++
> templates go completely untyped, but mess is always mess. You cannot
> make a decent language out of macro processor.

I don't understand what you're getting at.  Are Ada generics implemented
with a macro processor?  C++ templates amount to that, but there are
other, better ways to implement generics.

Re: Ada Successor Language

[Dan'l Miller]

On Tuesday, June 19, 2018 at 2:19:56 PM UTC-5, Paul Rubin wrote:
> "Dmitry A. Kazakov" writes:
> > There are 50 shades of mess. Ada's generics try to introduce some
> > weakly-typed contracts on the formal generic parameters, where C++
> > templates go completely untyped, but mess is always mess. You cannot
> > make a decent language out of macro processor.
> 
> I don't understand what you're getting at.  Are Ada generics implemented
> with a macro processor?  C++ templates amount to that, but there are
> other, better ways to implement generics.

I think Dmitry is saying that the Ada's _LRM_ standard doesn't require that better way.  GNAT's generics are closer to C++'s macro-esque approach, AIUI.  Conversely, Janus Ada's generics are at the other end of the spectrum, perhaps an exemplar model of "the better way" desired state.

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-19 21:19, Paul Rubin wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> There are 50 shades of mess. Ada's generics try to introduce some
>> weakly-typed contracts on the formal generic parameters, where C++
>> templates go completely untyped, but mess is always mess. You cannot
>> make a decent language out of macro processor.
> 
> I don't understand what you're getting at.  Are Ada generics implemented
> with a macro processor?  C++ templates amount to that, but there are
> other, better ways to implement generics.

Generics and macros are same thing regardless implementation. The core 
idea and all power lies in textual substitution as opposed to the 
concept substitutability in a properly typed systems. You can have 
shared generic bodies as in Janus Ada, but that changes nothing on the 
nature of generics. It was a mistake for both Ada and C++ to have them 
in the first place.

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

Re: Ada Successor Language

[Paul Rubin]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> Generics and macros are same thing regardless implementation.  

That makes no sense under the notion of generics in that paper whose url
I posted.  C++ does them with a macro-like scheme that can get messy but
Haskell does them in a much sounder way that works really well and
doesn't involve macros.

> You can have shared generic bodies as in Janus Ada, but that changes
> nothing on the nature of generics. It was a mistake for both Ada and
> C++ to have them in the first place.

I don't understand what the issue is.  I don't think it was a mistake
for C++ to have generics since the generic approach in C++ is IME much
better than the OO approach with inheritance.  But, I could agree that
C++'s use of templates to implement generics causes some problems.  I
use them but encounter the obvious annoyances in doing so.

"Dan'l Miller" <optikos@verizon.net> writes:
> I think Dmitry is saying that the Ada's _LRM_ standard doesn't require
> that better way.  GNAT's generics are closer to C++'s macro-esque
> approach, AIUI.  Conversely, Janus Ada's generics are at the other end
> of the spectrum, perhaps an exemplar model of "the better way" desired
> state.

Oh hmm, ok, that's interesting.  But I'm surprised that the LRM is loose
enough to allow two observably different implementations like that.

Re: Ada Successor Language

[Paul Rubin]

"Dan'l Miller" <optikos@verizon.net> writes:
> Ada
>  ●   :   multi-type concepts
>  ●   :   multiple constraints
>  ●   :   associated type access
>  ◒   :   constraints on associated types
>  ●   :   type aliases
>  ●   :   separate compilation (exemplary Ada compilers)
>  ●   :   implicit argument deduction

Thanks, that's interesting.  I believe that Haskell's fairly recent
addition of type families (associated types) was in response to that
paper.

Re: Ada Successor Language

[Dan'l Miller]

On Tuesday, June 19, 2018 at 3:32:27 PM UTC-5, Paul Rubin wrote:
> "Dan'l Miller" writes:
> > Ada
> >  ●   :   multi-type concepts
> >  ●   :   multiple constraints
> >  ●   :   associated type access
> >  ◒   :   constraints on associated types
> >  ●   :   type aliases
> >  ●   :   separate compilation (exemplary Ada compilers)
> >  ●   :   implicit argument deduction
> 
> Thanks, that's interesting.  I believe that Haskell's fairly recent
> addition of type families (associated types) was in response to that
> paper.

Btw, I missed a row.  I think that it should be the following, but I am not certain.

  ◯   :  retroactive modeling

Re: Ada Successor Language

[Dan'l Miller]

On Tuesday, June 19, 2018 at 2:39:30 PM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-06-19 21:19, Paul Rubin wrote:
> > "Dmitry A. Kazakov" writes:
> >> There are 50 shades of mess. Ada's generics try to introduce some
> >> weakly-typed contracts on the formal generic parameters, where C++
> >> templates go completely untyped, but mess is always mess. You cannot
> >> make a decent language out of macro processor.
> > 
> > I don't understand what you're getting at.  Are Ada generics implemented
> > with a macro processor?  C++ templates amount to that, but there are
> > other, better ways to implement generics.
> 
> Generics and macros are same thing regardless implementation. The core 
> idea and all power lies in textual substitution as opposed to the 
> concept substitutability in a properly typed systems.

Clearly, Ada's generics are not performing textual substitution.  Ada's generics are performing constraint-matching on subtypes passed as formal arguments.  If the criteria of the constraints are satisfied, the previously-declared-long-ago subtype in the AST is what is passed in as the formal argument of an Ada generic.

Dmitry, instead of the pox-on-all-their-houses approach to wholesale maligning of generics (as a troller fisherman would do to foment needless more-heat-than-light argument), what would the better world desired-state look like without generics (as a true luminary would do to positively contribute insightful expertise)?

I hope that you don't say for 25 would-be passings of different subtypes in as the formal argument of a single would-be generic package's type parameter that a human being should manually author the same or nearly the same differently-named packages 25 times (and get carpal-tunnel syndrome).  I am hoping that you have some brilliant genius insight regarding:
1) multi-stage programming and source-code generation therewith, or
2) highly-expressive compile-time type-manipulation language, or
3) something like that.

Re: Ada Successor Language

[Simon Wright]

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

> Oh hmm, ok, that's interesting.  But I'm surprised that the LRM is
> loose enough to allow two observably different implementations like
> that.

"observably"? how? code size of the generic will change, not sure that
overall code size will, & anyway who cares?

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-19 23:07, Dan'l Miller wrote:
> On Tuesday, June 19, 2018 at 2:39:30 PM UTC-5, Dmitry A. Kazakov wrote:
>> On 2018-06-19 21:19, Paul Rubin wrote:
>>> "Dmitry A. Kazakov" writes:
>>>> There are 50 shades of mess. Ada's generics try to introduce some
>>>> weakly-typed contracts on the formal generic parameters, where C++
>>>> templates go completely untyped, but mess is always mess. You cannot
>>>> make a decent language out of macro processor.
>>>
>>> I don't understand what you're getting at.  Are Ada generics implemented
>>> with a macro processor?  C++ templates amount to that, but there are
>>> other, better ways to implement generics.
>>
>> Generics and macros are same thing regardless implementation. The core
>> idea and all power lies in textual substitution as opposed to the
>> concept substitutability in a properly typed systems.
> 
> Clearly, Ada's generics are not performing textual substitution.  Ada's generics are performing constraint-matching on subtypes passed as formal arguments.  If the criteria of the constraints are satisfied, the previously-declared-long-ago subtype in the AST is what is passed in as the formal argument of an Ada generic.

There is no such thing in Ada. Formal generic types, e.g.

    type Foo (<>) is private;

match pretty much anything. The actual type is then substituted in all 
language constructs just like macros do. The only constraint here is the 
language syntax and a few sematic checks which make the language of 
generics (not to confuse with the core language) weakly typed, where C++ 
templates are completely untyped.

> I hope that you don't say for 25 would-be passings of different subtypes in as the formal argument of a single would-be generic package's type parameter that a human being should manually author the same or nearly the same differently-named packages 25 times (and get carpal-tunnel syndrome).

Certainly I do. Subtypes in Ada are directly substitutable. You need 
just one body:

    procedure Foo (X : Integer); -- You can use any Integer subtype here

I you meant rather *types*, then as I said earlier, polymorphism can be 
achieved by different means and ad-hoc polymorphism offered by generics 
the worst possible way. My point was to use dynamic polymorphism instead.

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

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-19 22:30, Paul Rubin wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> Generics and macros are same thing regardless implementation.
> 
> I don't understand what the issue is.

1. Generics is a second-order language. We don't need yet another 
language unless strong reasons shown. [ This how Stepanov's advocacy 
goes. He tries to show that generic programming requires generics. My 
point is that maybe not. ]

2. Generics are static. There is no class-wide instances of generic 
classes. E.g. taking the generic class "(<>) is private" as in

    type T is (<>) is private;

There is no way to declare:

    X : (<>) is private'Class := <result from some instance>;

This has very concrete consequences. For example, declare dimensioned 
measurement unit types in a generic and then try to write a calculator 
dealing with units. No way.

3. Once generic, always generic.

4. No proper reuse. Generic bodies are no proper compilation units, you 
cannot have a shared library of generics. Therefore the only possible 
form of reuse is textual substitution and recompilation of the client code.

5. No proper separation of interface and implementation. If you used Ada 
generics you would know that successful compilation of a generic body 
means little. Instantiation can always fail even if all formal 
parameters match. The compiler must look into the body not just for the 
sake of optimization and representation, but for validity of 
instantiation, just like in C++. A macro is a macro.

> I don't think it was a mistake
> for C++ to have generics since the generic approach in C++ is IME much
> better than the OO approach with inheritance.

This is evidently wrong. Ada programs extensively using generics are as 
impossible to maintain as C++ programs using templates. IMO generics 
have no place in SW engineering.

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

Re: Ada Successor Language

[Marius Amado-Alves]

On Tuesday, 19 June 2018 01:10:33 UTC+1, Dan'l Miller  wrote:
> On Monday, June 18, 2018 at 5:36:56 PM UTC-5, Paul Rubin wrote:
> > "Dmitry A. Kazakov" writes:
> > > P.S. Stepanov arguing for generics (templates) claimed that the reason
> > > why C++ needed this mess was impossibility to write Max using dynamic
> > > polymorphism... I believe it is possible to have a language where
> > > generic Max and Swap could be written without generics.
> > 
> > I've been wanting to look up how Ada generics work.  C++ generics are
> > implemented with templates which leads to a horrible mess, but generics
> > themselves don't have to be a mess, as far as I know.
> > 
> > Some comparisons:
> > 
> > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.110.122&rep=rep1&type=pdf
> 
> It seems that Ada would score rather well in Table 1 on page 4 had it been included:
> 
> Ada
>  ●   :   multi-type concepts
>  ●   :   multiple constraints
>  ●   :   associated type access
>  ◒   :   constraints on associated types
>  ●   :   type aliases
>  ●   :   separate compilation (exemplary Ada compilers)
>  ●   :   implicit argument deduction

That's exactly why Ada was precluded: it would make Haskell look bad. That or the ignorance of the authors (Ada83 was the 1st standard language with generics). Either way this tells me the paper is trash.

Re: Ada Successor Language

[Alejandro R. Mosteo]

On 20/06/2018 09:33, Dmitry A. Kazakov wrote:

> I you meant rather *types*, then as I said earlier, polymorphism can be 
> achieved by different means and ad-hoc polymorphism offered by generics 
> the worst possible way. My point was to use dynamic polymorphism instead.

Is something interfaces-like what you mean here? I admit I still have 
sometimes the doubt of doing things the generic vs interface way.

Re: Ada Successor Language

[Alejandro R. Mosteo]

On 20/06/2018 09:59, Dmitry A. Kazakov wrote:

> 5. No proper separation of interface and implementation. If you used Ada 
> generics you would know that successful compilation of a generic body 
> means little. Instantiation can always fail even if all formal parameters 
> match. The compiler must look into the body not just for the sake of 
> optimization and representation, but for validity of instantiation, just 
> like in C++. A macro is a macro.

This happened to me recently, and after so many years it was a harsh 
surprise.

Re: Ada Successor Language

[Alejandro R. Mosteo]

On 18/06/2018 23:27, ric.wai88@gmail.com wrote:
> On Monday, June 18, 2018 at 5:20:32 PM UTC-4, Shark8 wrote:
> 
>> I'd honestly like the ability to use X'Type; this would allow us to say something like this:
>>
>> Procedure Swap( A, B : in out Some_Type ) is
>>    Temp : Constant B'Type := B;
>> Begin
>>    B:= A;
>>    A:= Temp;
>> End Swap;
>>
>> Yeah, I know, it's a little thing and you can do it with generics, etc. But that's not entirely the point, the point is that this allows the declaration of types dependent on objects... it provides some of the niceties of type-inference without having to resort to such lazy/possibly-error-prone methodologies.
> 
> 
> Why would you want that? You have to have visibility to the type to declare an object of the type. In your above example, you explicitly know about Some_Type, and you also explicitly know that A and B are of that type. So you don't need to query the parameter, since it is implicit.

I won't discuss the merit of the idea, but isn't C++11's "auto" doing this?

Re: Ada Successor Language

[Dan'l Miller]

On Wednesday, June 20, 2018 at 2:33:26 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-06-19 23:07, Dan'l Miller wrote:
> > On Tuesday, June 19, 2018 at 2:39:30 PM UTC-5, Dmitry A. Kazakov wrote:
> >> On 2018-06-19 21:19, Paul Rubin wrote:
> >>> "Dmitry A. Kazakov" writes:
> >>>> There are 50 shades of mess. Ada's generics try to introduce some
> >>>> weakly-typed contracts on the formal generic parameters, where C++
> >>>> templates go completely untyped, but mess is always mess. You cannot
> >>>> make a decent language out of macro processor.
> >>>
> >>> I don't understand what you're getting at.  Are Ada generics implemented
> >>> with a macro processor?  C++ templates amount to that, but there are
> >>> other, better ways to implement generics.
> >>
> >> Generics and macros are same thing regardless implementation. The core
> >> idea and all power lies in textual substitution as opposed to the
> >> concept substitutability in a properly typed systems.
> > 
> > Clearly, Ada's generics are not performing textual substitution.  Ada's generics are performing
> restriction-matching on subtypes passed as formal arguments.  If the criteria of the restrictions are
> satisfied, the previously-declared-long-ago subtype in the AST is what is passed in as the formal
> argument of an Ada generic.
> 
> There is no such thing in Ada.

No such thing?  Nothing?  Nada?  Zilch?  Empty set?  Apparently you have not read §12.1 in the _AARM_ nor examples {12.3.15.i, 12.3.18.c} a few pages later.

Just about the only restriction not permitted on generic formal parameters is constraint on subtypes:
“Reason: The reason for forbidding constraints in subtype_indications is that it simplifies the elaboration of
generic_declarations (since there is nothing to evaluate), and that it simplifies the matching rules, and makes them more checkable at compile time.”

12.3.15.i:
type T1 is tagged record ... end record;
generic
type Formal is new T1;

12.3.18.c:
type Ancestor is tagged null record;
generic
type Formal is new Ancestor with private;

and in
http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-6-5.html

generic
   type T is limited new LT;    -- untagged
   type TT is limited new TLT with private;    -- tagged

type A is interface;
procedure Op1(X: A; ... ) is abstract;
procedure N1(X: A; ... ) is null;
generic
   type F is interface and A;

These are the awesome achievement in Ada that Stroustup & Austern have been struggling for a decade to standardize in C++ under the jargon “concepts”.  The C++ standardization committee keeps finding some gotcha that causes the proposal to be rejected from C++{11,14,17}.

Ada also has concept maps (which Stroustrup was also trying to standardize a while back to facilitate concepts):

again from the Ada2005 Rationale linked above:

generic
   type My_Element is private;
   with package Sets is new Set_Signature(Element => My_Element, others => <>);

overriding
procedure This is new That( ... );

All these {T1, Ancestor, LT, TLT, A, Set_Signature, Element, That} are the restrictions that, if absent, cause the generic package to fail to compile.  So, yes, there most certainly is such a thing in Ada.

> Formal generic types, e.g.
> 
>     type Foo (<>) is private;

red herring.  I am discussing nearly every category of generic parameter other than (<>).

> match pretty much anything. The actual type is then substituted in all 
> language constructs just like macros do. The only constraint here is the 
> language syntax and a few sematic checks which make the language of 
> generics (not to confuse with the core language) weakly typed,

How are strictly matching the generic formal parameters' overtly-stated restrictions on {T1, Ancestor, LT, TLT, A, Set_Signature, Element, That} in the examples above not strongly typed?  I don't see any loosey-goosey loopholes to bypass those restrictions to sneak a mismatch-to-those-restrictions in the backdoor when no one is looking.

> where C++ templates are completely untyped.

I would say that C++ templates have no overt matching based on •restrictions• on the formal-parameters, (other than absences discovered later on upon expanding the template).  Conversely, the entire Turing-completeness debacle in C++ templates is caused by carving out specific types as exceptional/nongeneric/special-case template specializations that occlude the generic template for those precisely-matched type parameters.  So the Turing completeness is entirely based on the vicinity that C++ templates have the utmost of strong typing (that even Ada doesn't have*:  Ada cannot utilize strong typing to carve out nongeneric/special-case parameterized-type package from the generic parameterized-type package).

* Thank goodness Ada generics lack C++'s template specialization, because that is the key feature needed to go down the path of C++-metatemplate-programming-esque Turing-complete functional programming (with horrendous cobbled-together syntax) in Ada generics.

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-22 17:18, Dan'l Miller wrote:
> On Wednesday, June 20, 2018 at 2:33:26 AM UTC-5, Dmitry A. Kazakov wrote:
>> On 2018-06-19 23:07, Dan'l Miller wrote:
>>> On Tuesday, June 19, 2018 at 2:39:30 PM UTC-5, Dmitry A. Kazakov wrote:
>>>> On 2018-06-19 21:19, Paul Rubin wrote:
>>>>> "Dmitry A. Kazakov" writes:
>>>>>> There are 50 shades of mess. Ada's generics try to introduce some
>>>>>> weakly-typed contracts on the formal generic parameters, where C++
>>>>>> templates go completely untyped, but mess is always mess. You cannot
>>>>>> make a decent language out of macro processor.
>>>>>
>>>>> I don't understand what you're getting at.  Are Ada generics implemented
>>>>> with a macro processor?  C++ templates amount to that, but there are
>>>>> other, better ways to implement generics.
>>>>
>>>> Generics and macros are same thing regardless implementation. The core
>>>> idea and all power lies in textual substitution as opposed to the
>>>> concept substitutability in a properly typed systems.
>>>
>>> Clearly, Ada's generics are not performing textual substitution.  Ada's generics are performing
>> restriction-matching on subtypes passed as formal arguments.  If the criteria of the restrictions are
>> satisfied, the previously-declared-long-ago subtype in the AST is what is passed in as the formal
>> argument of an Ada generic.
>>
>> There is no such thing in Ada.
> 
> No such thing?

Exactly so. Ada subtypes are equivalent, there is no way to accept 
Positive and reject Negative in most context, generic formals included.

> generic
>     type My_Element is private;
>     with package Sets is new Set_Signature(Element => My_Element, others => <>);
> 
> overriding
> procedure This is new That( ... );
> 
> All these {T1, Ancestor, LT, TLT, A, Set_Signature, Element, That} are the restrictions that, if absent, cause the generic package to fail to compile.  So, yes, there most certainly is such a thing in Ada.

Yes. Things you mentioned are not Ada-subtype constraints.
  --
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-22 13:13, Alejandro R. Mosteo wrote:
> On 20/06/2018 09:33, Dmitry A. Kazakov wrote:
> 
>> I you meant rather *types*, then as I said earlier, polymorphism can 
>> be achieved by different means and ad-hoc polymorphism offered by 
>> generics the worst possible way. My point was to use dynamic 
>> polymorphism instead.
> 
> Is something interfaces-like what you mean here?

Sure. Especially when ad-hoc superclasses are needed. There is no way to 
foresee and declare all possible interfaces of a type. One should be 
able to declare a common interface ancestor later on.

> I admit I still have 
> sometimes the doubt of doing things the generic vs interface way.

Generics are automatically at disadvantage, even performance-wise, 
because in all contexts where types are statically known there is no 
dispatch in Ada. Since generics are always static in all comparable 
cases dynamically polymorphic calls are statically resolved.

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

Re: Ada Successor Language

[Jacob Sparre Andersen]

Dmitry A. Kazakov wrote:

> 5. No proper separation of interface and implementation. If you used
> Ada generics you would know that successful compilation of a generic
> body means little. Instantiation can always fail even if all formal
> parameters match. The compiler must look into the body not just for
> the sake of optimization and representation, but for validity of
> instantiation, just like in C++. A macro is a macro.

If the compilation of a generic succeeds, then any instantiation with
actuals matching the formal generic parameters have to succeed, no
matter what's in the implementation of the generic.

If that somehow isn't the case in the very newest version of the
standard, then the ARG has messed up, and I doubt that.

Greetings,

Jacob
-- 
"Lots of information, strong cast, but a bit weak on the narrative."
              -- Pratchet, Stewart & Cohen reviews a phone directory

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-23 21:21, Jacob Sparre Andersen wrote:
> Dmitry A. Kazakov wrote:
> 
>> 5. No proper separation of interface and implementation. If you used
>> Ada generics you would know that successful compilation of a generic
>> body means little. Instantiation can always fail even if all formal
>> parameters match. The compiler must look into the body not just for
>> the sake of optimization and representation, but for validity of
>> instantiation, just like in C++. A macro is a macro.
> 
> If the compilation of a generic succeeds, then any instantiation with
> actuals matching the formal generic parameters have to succeed, no
> matter what's in the implementation of the generic.

That is not possible because generic formal contracts are weakly typed. 
Consider, for simplicity, this:

    with Ada.Finalization;
    generic
       type T is new Ada.Finalization.Controlled with private;
    package P is
       type S is new T with null record;
       not overriding procedure Foo (X : S);
    end P;

If the given descendant of Controlled has Foo already, you are out of 
luck. The contract says: any descendant of Ada.Finalization.Controlled. 
That is a lie.

> If that somehow isn't the case in the very newest version of the
> standard, then the ARG has messed up, and I doubt that.

No, it is a fundamental problem of the generic formal contracts (and 
macro processing).

No contract can describe all behavior. In the first-order language we 
handle that by adding run-time exceptions. So when you substitute 
Positive where a full Integer is expected you get Constraint_Error and 
since the exception is in the contract, the contract is saved.

In the second-order language, like generics, there is no such escape. 
The "behavior" of a generic program is the generated source text in the 
first-order language to compile. If something goes wrong, the exception 
is compile fault (or letting the garbage through). You can try to

1. strengthen generic formal contracts

2. weaken the generic language

#1 is extremely difficult (if possible) and would lead to explosion of 
RM rules. #2 will render generics useless.

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

Re: Ada Successor Language

[J-P. Rosen]

Le 24/06/2018 à 09:34, Dmitry A. Kazakov a écrit :
> That is not possible because generic formal contracts are weakly typed.
> Consider, for simplicity, this:
> 
>    with Ada.Finalization;
>    generic
>       type T is new Ada.Finalization.Controlled with private;
>    package P is
>       type S is new T with null record;
>       not overriding procedure Foo (X : S);
>    end P;
> 
> If the given descendant of Controlled has Foo already, you are out of
> luck. The contract says: any descendant of Ada.Finalization.Controlled.
> That is a lie.
You really need to understand the rules: "assume the best" in generic
specifications, "assume the worse" in generic bodies.

i.e. a generic spec is legal if there is at least one legal
instantiation. This is because the user is assumed to see the
specification, and therefore understand why some instantiation is rejected.

a generic body is illegal if there is at least one illegal
instantiation. This is because the user is not assumed to see the body
of a generic.

Hint: a generic can be made legal by moving some declarations from the
body to the specification (even into the private part).

-- 
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: Ada Successor Language

[briot.emmanuel]

> You really need to understand the rules: "assume the best" in generic
> specifications, "assume the worse" in generic bodies.

Thanks Jean-Pierre,

I have been using generics for a long time (and I like them and find them useful).
I must say I never saw such a simple explanation of why a generic might compile
and yet an instantiation might fail !

Emmanuel

Re: Ada Successor Language

[Marius Amado-Alves]

This conjecture, that OO polymorphism is *always* preferrable to generics, is picking my mind big time. I've got a strong intuition that there are cases best served by generics. I'll try to find examples. Or if anyone has some please post.

Re: Ada Successor Language

[Paul Rubin]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> Generics are automatically at disadvantage, even performance-wise,
> because in all contexts where types are statically known there is no
> dispatch in Ada. Since generics are always static in all comparable
> cases dynamically polymorphic calls are statically resolved.

Why are generics worse performance-wise then?  If the type can be
statically deduced then the compiler can generate specialized code.

Do you use ML?  Do you think its module language is also bad?

Re: Ada Successor Language

[Marius Amado-Alves]

> Hint: a generic can be made legal by moving some declarations from the
> body to the specification (even into the private part).

The single most useful dirty trick in Ada:-)

Re: Ada Successor Language

[Alejandro R. Mosteo]

On 23/06/2018 21:21, Jacob Sparre Andersen wrote:
> Dmitry A. Kazakov wrote:
> 
>> 5. No proper separation of interface and implementation. If you used
>> Ada generics you would know that successful compilation of a generic
>> body means little. Instantiation can always fail even if all formal
>> parameters match. The compiler must look into the body not just for
>> the sake of optimization and representation, but for validity of
>> instantiation, just like in C++. A macro is a macro.
> 
> If the compilation of a generic succeeds, then any instantiation with
> actuals matching the formal generic parameters have to succeed, no
> matter what's in the implementation of the generic.
> 
> If that somehow isn't the case in the very newest version of the
> standard, then the ARG has messed up, and I doubt that.

See this one, which is the case that bit me recently:

procedure Blah is

	generic
		type Something is private;
	package Duh is		
		type Meh is new Something;		
	end Duh;

	type Oh is tagged null record;
	
	package Ouch is new Duh (Oh);

begin
    null;
end Blah;

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-25 10:21, Paul Rubin wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> Generics are automatically at disadvantage, even performance-wise,
>> because in all contexts where types are statically known there is no
>> dispatch in Ada. Since generics are always static in all comparable
>> cases dynamically polymorphic calls are statically resolved.
> 
> Why are generics worse performance-wise then?

At least not better. However I suppose that plain code is easier to 
optimize than an outcome of generic instantiation. Maybe that is the 
reason why GNAT inlines generics.

> If the type can be
> statically deduced then the compiler can generate specialized code.
> 
> Do you use ML?  Do you think its module language is also bad?

No, I don't use functional languages. Generics might be natural for 
non-computational languages (if you have no side-effects, there is 
nothing to compute, right? (:-))

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

Re: Ada Successor Language

[Jeffrey R. Carter]

On 06/25/2018 10:58 AM, Alejandro R. Mosteo wrote:
> 
> procedure Blah is
> 
>      generic
>          type Something is private;
>      package Duh is
>          type Meh is new Something;
>      end Duh;
> 
>      type Oh is tagged null record;
> 
>      package Ouch is new Duh (Oh);
> 
> begin
>     null;
> end Blah;

Generics are fine and have no problems if you're smart enough to avoid 
programming by extension.

-- 
Jeff Carter
"Clear? Why, a 4-yr-old child could understand this
report. Run out and find me a 4-yr-old child. I can't
make head or tail out of it."
Duck Soup
94

Re: Ada Successor Language

[J-P. Rosen]

Le 25/06/2018 à 10:58, Alejandro R. Mosteo a écrit :
> See this one, which is the case that bit me recently:
> 
> procedure Blah is
>     generic
>         type Something is private;
>     package Duh is       
>         type Meh is new Something;       
>     end Duh;
> 
>     type Oh is tagged null record;
>     
>     package Ouch is new Duh (Oh);
> 
> begin
>    null;
> end Blah;

A private formal allows tagged and untagged types. However, deriving
without extension is legal only for untagged types. Since it is a
specification (that you are supposed to have read), the compiler assumes
the best and allows the derivation. When you instantiate with a tagged
type, you would be doing something illegal and the instantiation is not
allowed.

The same derivation would not compile in the body of the generic, where
the worst is assumed.

-- 
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: Ada Successor Language

[Niklas Holsti]

On 18-06-25 15:41 , J-P. Rosen wrote:
> Le 25/06/2018 à 10:58, Alejandro R. Mosteo a écrit :
>> See this one, which is the case that bit me recently:
>>
>> procedure Blah is
>>     generic
>>         type Something is private;
>>     package Duh is
>>         type Meh is new Something;
>>     end Duh;
>>
>>     type Oh is tagged null record;
>>
>>     package Ouch is new Duh (Oh);
>>
>> begin
>>    null;
>> end Blah;
>
> A private formal allows tagged and untagged types. However, deriving
> without extension is legal only for untagged types.

So it says in RM 3.4(5/2), but even the Annotated RM has no motivation 
for it, and I don't see why Ada could not assume a null extension when 
the type is tagged. Can someone explain why the RM is so strict on this?

(In fact, it seems to me that Ada could allow untagged record extensions 
as well; the effect would be the same as for tagged ones, but no 'Class 
would be formed, and no class-wide programming or dynamic dispatch could 
be used, so all such types would be static. It would be semantically 
equivalent to aggregation of a component of the parent type with the 
extension components, but would allow direct access to the inherited 
components from the parent type. This could be a useful separation of 
extensions from tags.)

> Since it is a
> specification (that you are supposed to have read), the compiler assumes
> the best and allows the derivation. When you instantiate with a tagged
> type, you would be doing something illegal and the instantiation is not
> allowed.
>
> The same derivation would not compile in the body of the generic, where
> the worst is assumed.

But it does compile in the body, at least with my GNAT. And ARM 
3.4(5.e/2) explains: "Note that this is legal in the private part or 
body of an instance, both to avoid a contract model violation, and 
because no code that can see that the type is actually tagged can also 
see the derived type declaration."

By the way, it seems to me that the Ramification ARM 3.4(5.b/2) is wrong 
to refer to the "only if" part of the rule in 5/2, and should instead 
refer to the "if" part of the rule, which is the part that is violated 
in the ARM example (which is the same as the example being discussed here).

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

Re: Ada Successor Language

[Alejandro R. Mosteo]

On 25/06/2018 14:41, J-P. Rosen wrote:
> Le 25/06/2018 à 10:58, Alejandro R. Mosteo a écrit :
>> See this one, which is the case that bit me recently:
>>
>> procedure Blah is
>>      generic
>>          type Something is private;
>>      package Duh is
>>          type Meh is new Something;
>>      end Duh;
>>
>>      type Oh is tagged null record;
>>      
>>      package Ouch is new Duh (Oh);
>>
>> begin
>>     null;
>> end Blah;
> 
> A private formal allows tagged and untagged types. However, deriving
> without extension is legal only for untagged types. Since it is a
> specification (that you are supposed to have read), the compiler assumes
> the best and allows the derivation. When you instantiate with a tagged
> type, you would be doing something illegal and the instantiation is not
> allowed.

Someone explained it to me at the time, and your best/worst explanation 
is great. It was rather an example of that you can have a generic that 
compiles, a type that fulfills the generic formal, and an instantiation 
that fails, which admittedly irks me.

> The same derivation would not compile in the body of the generic, where
> the worst is assumed
GNAT 7.3/2018 does compile it if I move it to the private part or body, 
which thus must be a bug, as hinted by that it allows taking the type's 
'Class...

procedure Blah is

generic
	type Something is private;
package Duh is					
private	
	type Meh is new Something;
	function Yes (M : Meh) return Boolean is (True);
	function Yes_Class (M : Meh'Class) return Boolean is (True);
end Duh;

type Oh is tagged null record;

package Ouch is new Duh (Oh); -- This fails with non-tagged formal

begin
    null;
end Blah;

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-25 16:03, Niklas Holsti wrote:

> (In fact, it seems to me that Ada could allow untagged record extensions 
> as well; the effect would be the same as for tagged ones, but no 'Class 
> would be formed, and no class-wide programming or dynamic dispatch could 
> be used, so all such types would be static.

Ada could allow T'Class for untagged T. T'Class would be an indefinite 
type with values consisting of the actual type's tag and its value. When 
T is by-value type, you pass T'Class to a subprogram as tag + value. 
When T is by-reference type, you pass tag + reference.

Upon dispatch, you strip the tag from the value or reference before 
passing value/reference down.

P.S. No re-dispatch is possible in this model, sorry.

P.P.S. Tagged type is a special case when T and T'Class have same 
representation.

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

Re: Ada Successor Language

[J-P. Rosen]

Le 25/06/2018 à 16:21, Dmitry A. Kazakov a écrit :
> Ada could allow T'Class for untagged T. T'Class would be an indefinite
> type with values consisting of the actual type's tag and its value. When
> T is by-value type, you pass T'Class to a subprogram as tag + value.
> When T is by-reference type, you pass tag + reference.
> 
> Upon dispatch, you strip the tag from the value or reference before
> passing value/reference down.

It was a requirement of Ada95 that OOP be strictly contained, and that
the same typing system as Ada83 be kept for those who don't want OOP.

You are free to choose the programming paradigm that you like, but don't
think that everybody works your way.

-- 
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: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-25 16:44, J-P. Rosen wrote:
> Le 25/06/2018 à 16:21, Dmitry A. Kazakov a écrit :

>> Ada could allow T'Class for untagged T. T'Class would be an indefinite
>> type with values consisting of the actual type's tag and its value. When
>> T is by-value type, you pass T'Class to a subprogram as tag + value.
>> When T is by-reference type, you pass tag + reference.
>>
>> Upon dispatch, you strip the tag from the value or reference before
>> passing value/reference down.
> 
> It was a requirement of Ada95 that OOP be strictly contained, and that
> the same typing system as Ada83 be kept for those who don't want OOP.

Don't want OO, don't declare T'Class objects. Where is a problem?

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

Re: Ada Successor Language

[Dan'l Miller]

On Monday, June 25, 2018 at 10:19:15 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-06-25 16:44, J-P. Rosen wrote:
> > Le 25/06/2018 à 16:21, Dmitry A. Kazakov a écrit :
> 
> >> Ada could allow T'Class for untagged T. T'Class would be an indefinite
> >> type with values consisting of the actual type's tag and its value. When
> >> T is by-value type, you pass T'Class to a subprogram as tag + value.
> >> When T is by-reference type, you pass tag + reference.
> >>
> >> Upon dispatch, you strip the tag from the value or reference before
> >> passing value/reference down.
> > 
> > It was a requirement of Ada95 that OOP be strictly contained, and that
> > the same typing system as Ada83 be kept for those who don't want OOP.
> 
> Don't want OO, don't declare T'Class objects. Where is a problem?

The problem is that you just proposed 'Class for non-OO semantics.  Your proposal violates the Principal of Least Surprise.

Re: Ada Successor Language

[J-P. Rosen]

Le 25/06/2018 à 17:19, Dmitry A. Kazakov a écrit :
> Don't want OO, don't declare T'Class objects. Where is a problem?
> 
Just that what you are suggesting would imply tags even for untagged
types...

-- 
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: Ada Successor Language

[Niklas Holsti]

On 18-06-25 17:21 , Dmitry A. Kazakov wrote:
> On 2018-06-25 16:03, Niklas Holsti wrote:
>
>> (In fact, it seems to me that Ada could allow untagged record
>> extensions as well; the effect would be the same as for tagged ones,
>> but no 'Class would be formed, and no class-wide programming or
>> dynamic dispatch could be used, so all such types would be static.
>
> Ada could allow T'Class for untagged T. T'Class would be an indefinite
> type with values consisting of the actual type's tag and its value. When
> T is by-value type, you pass T'Class to a subprogram as tag + value.
> When T is by-reference type, you pass tag + reference.

Yes, that could be another point in the division of the "OO programming 
concept" into smaller, more "primitive" features -- building blocks -- 
which could be combined in various ways.

Your suggestion would allow class-wide programming without storing tags 
_in_ objects.

> Upon dispatch, you strip the tag from the value or reference before
> passing value/reference down.

> P.S. No re-dispatch is possible in this model, sorry.

Indeed. However, while I insist on re-dispatch in some cases, I don't 
insist on re-dispatch in all cases :-)  The possible need for 
re-dispatch would then be one of the reasons for choosing the untagged 
approach (your suggestion) or the tagged approach (present Ada).

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

Re: Ada Successor Language

[Niklas Holsti]

On 18-06-25 17:44 , J-P. Rosen wrote:
> Le 25/06/2018 à 16:21, Dmitry A. Kazakov a écrit :
>> Ada could allow T'Class for untagged T. T'Class would be an indefinite
>> type with values consisting of the actual type's tag and its value. When
>> T is by-value type, you pass T'Class to a subprogram as tag + value.
>> When T is by-reference type, you pass tag + reference.
>>
>> Upon dispatch, you strip the tag from the value or reference before
>> passing value/reference down.
>
> It was a requirement of Ada95 that OOP be strictly contained, and that
> the same typing system as Ada83 be kept for those who don't want OOP.

Neither Dmitry's suggestion for untagged class-wide programming nor my 
suggestion for untagged record extension conflicts with or replaces the 
Ada83 typing system. Rather, these suggestions would interpolate new 
typing features intermediate between the Ada83 typing system and Ada95 
tagged types.

If these features had been suggested for and included in Ada95, they 
might have helped some Ada83 designs evolve incrementally towards OOP, 
without leaping all the way to tagged types.

Whether the impact on Ada95 compiler complexity would have been too 
large to be worth it, is another question. Both suggestions seem to 
require new kinds of code generation for some calls, not needed for 
Ada83 (where there are no tags) nor for tagged types (where tags are 
embedded in objects).

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

Re: Ada Successor Language

[Dan'l Miller]

On Monday, June 25, 2018 at 2:16:36 PM UTC-5, Niklas Holsti wrote:
> On 18-06-25 17:21 , Dmitry A. Kazakov wrote:
> > On 2018-06-25 16:03, Niklas Holsti wrote:
> >
> >> (In fact, it seems to me that Ada could allow untagged record
> >> extensions as well; the effect would be the same as for tagged ones,
> >> but no 'Class would be formed, and no class-wide programming or
> >> dynamic dispatch could be used, so all such types would be static.
> >
> > Ada could allow T'Class for untagged T. T'Class would be an indefinite
> > type with values consisting of the actual type's tag and its value. When
> > T is by-value type, you pass T'Class to a subprogram as tag + value.
> > When T is by-reference type, you pass tag + reference.
> 
> Yes, that could be another point in the division of the "OO programming 
> concept" into smaller, more "primitive" features -- building blocks -- 
> which could be combined in various ways.
> 
> Your suggestion would allow class-wide programming without storing tags 
> _in_ objects.

The programmer promising to correctly store the right tag outside of objects would be a new level of human achievement in defeating strong typing.  It would be a new level of (dubious-)achievement that not even C++ has—and that is incredibly hard to contrive, because C++ is the goose that has laid so many rotten eggs!  (Just when I thought C++ couldn't conceivably plant any more landmines than it already has, the •Ada• community of all people devises an even worse one.)

Please humor me.  Just how would this outside-of-object flyweight-design-pattern tag be kept strongly typed & typesafe?  Would there be an XTag type that corresponds one-to-one and onto 'Class-able untagged X type?  How* would XTag be made known to X at time of either X's or XTag's declaration?

* i.e., what syntax?

Re: Ada Successor Language

[Niklas Holsti]

On 18-06-25 23:13 , Dan'l Miller wrote:
> On Monday, June 25, 2018 at 2:16:36 PM UTC-5, Niklas Holsti wrote:
>> On 18-06-25 17:21 , Dmitry A. Kazakov wrote:
>>> On 2018-06-25 16:03, Niklas Holsti wrote:
>>>
>>>> (In fact, it seems to me that Ada could allow untagged record
>>>> extensions as well; the effect would be the same as for tagged
>>>> ones, but no 'Class would be formed, and no class-wide
>>>> programming or dynamic dispatch could be used, so all such
>>>> types would be static.
>>>
>>> Ada could allow T'Class for untagged T. T'Class would be an
>>> indefinite type with values consisting of the actual type's tag
>>> and its value. When T is by-value type, you pass T'Class to a
>>> subprogram as tag + value. When T is by-reference type, you pass
>>> tag + reference.
>>
>> Yes, that could be another point in the division of the "OO
>> programming concept" into smaller, more "primitive" features --
>> building blocks -- which could be combined in various ways.
>>
>> Your suggestion would allow class-wide programming without storing
>> tags _in_ objects.
>
> The programmer promising to correctly store the right tag outside of
> objects would be a new level of human achievement in defeating strong
> typing.

No, there would be no manual tag manipulation. The compiler would 
automatically pass the tag value when needed, that is, when a call 
associates an object/expression of a statically known specific type S 
with a formal parameter of the type (some ancestor of S)'Class.

The compiler would construct the tag values for an untagged type 
derivation tree just as for tagged types, but would not store the tag 
values in objects.

Passing the tag separately, as part of a parameter of type T'Class, is 
similar to passing separately the actual bounds of a formal parameter of 
an unconstrained array type.

> * i.e., what syntax?

Same syntax as now: specific types T (whether tagged or untagged) and 
class-wide types T'Class. But, as Dmitry said, re-dispatch for untagged 
T'Class would not be possible, because only objects of class-wide types 
would carry tags. Objects (and views) of specific types would not carry 
tags at run time; the compiler would know the tag value for each such 
object and use it when an object of a specific type is converted to a 
class-wide type for passing to a class-wide operation.

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

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-25 20:05, J-P. Rosen wrote:
> Le 25/06/2018 à 17:19, Dmitry A. Kazakov a écrit :
>> Don't want OO, don't declare T'Class objects. Where is a problem?
>>
> Just that what you are suggesting would imply tags even for untagged
> types...

No, they don't. No tag will be ever stored in an non-tagged type, so 
everything will remains as it is now.

P.S. The "separation of OO" is already there because T'Class as a 
distinct type.

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

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-25 18:21, Dan'l Miller wrote:
> On Monday, June 25, 2018 at 10:19:15 AM UTC-5, Dmitry A. Kazakov wrote:
>> On 2018-06-25 16:44, J-P. Rosen wrote:
>>> Le 25/06/2018 à 16:21, Dmitry A. Kazakov a écrit :
>>
>>>> Ada could allow T'Class for untagged T. T'Class would be an indefinite
>>>> type with values consisting of the actual type's tag and its value. When
>>>> T is by-value type, you pass T'Class to a subprogram as tag + value.
>>>> When T is by-reference type, you pass tag + reference.
>>>>
>>>> Upon dispatch, you strip the tag from the value or reference before
>>>> passing value/reference down.
>>>
>>> It was a requirement of Ada95 that OOP be strictly contained, and that
>>> the same typing system as Ada83 be kept for those who don't want OOP.
>>
>> Don't want OO, don't declare T'Class objects. Where is a problem?
> 
> The problem is that you just proposed 'Class for non-OO semantics.  Your proposal violates the Principal of Least Surprise.

Remember, Ada is a strongly typed language, T'Class is not T, there is 
no way it could break or change anything in T.

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

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-25 22:52, Niklas Holsti wrote:
> The compiler would construct the tag values for an untagged type 
> derivation tree just as for tagged types, but would not store the tag 
> values in objects.

And during binding/linking it would throw away any generated dispatching 
tables if there is no reference to T'Class (or X'Tag) for the given 
hierarchy of types in the program. I think it is a simple enough global 
optimization to perform.

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

Re: Ada Successor Language

[jm.tarrasa]

El lunes, 4 de junio de 2018, 7:01:31 (UTC+2), Jacob Sparre Andersen  escribió:
> Jeffrey R. Carter wrote:
> 
> > I haven't had any problems with GPS crashing nor with its
> > auto-completion features.
> 
> The version packaged with Debian isn't exactly stable, but if you on
> have one main per project, it is usable.
> 
> The binary distribution provided directly by AdaCore works fine, but
> I've only tried it with compilers distributed by AdaCore.
> 

That is a classic in Ada forum "That version is not stable..." "don't try to build X, download the binaries from Adacore"

Re: Ada Successor Language

[Dan'l Miller]

On Tuesday, June 26, 2018 at 2:44:26 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-06-25 18:21, Dan'l Miller wrote:
> > On Monday, June 25, 2018 at 10:19:15 AM UTC-5, Dmitry A. Kazakov wrote:
> >> On 2018-06-25 16:44, J-P. Rosen wrote:
> >>> Le 25/06/2018 à 16:21, Dmitry A. Kazakov a écrit :
> >>
> >>>> Ada could allow T'Class for untagged T. T'Class would be an indefinite
> >>>> type with values consisting of the actual type's tag and its value. When
> >>>> T is by-value type, you pass T'Class to a subprogram as tag + value.
> >>>> When T is by-reference type, you pass tag + reference.
> >>>>
> >>>> Upon dispatch, you strip the tag from the value or reference before
> >>>> passing value/reference down.
> >>>
> >>> It was a requirement of Ada95 that OOP be strictly contained, and that
> >>> the same typing system as Ada83 be kept for those who don't want OOP.
> >>
> >> Don't want OO, don't declare T'Class objects. Where is a problem?
> > 
> > The problem is that you just proposed 'Class for non-OO semantics.  Your proposal violates the Principal of Least Surprise.
> 
> Remember, Ada is a strongly typed language, T'Class is not T, there is 
> no way it could break or change anything in T.

Quit putting non sequitur words in my mouth.  I never said that it would break anything in T.  I said that it would break T'Class in •some• situations of the untagged extended records, analogous to ways that are known in C++ as slicing.  Ada community wants one of C++'s most-maligned problems where the compiler sometimes picks the wrong strong typing?  Who knew?!

Re: Ada Successor Language

[ric.wai88]

On Tuesday, June 26, 2018 at 9:59:17 AM UTC-4, Dan'l Miller wrote:

> Ada community wants one of C++'s most-maligned problems where the compiler sometimes picks the wrong strong typing?  Who knew?!

I hope I can opt to be out-side of this "Ada" community who seem bent on wasting copious time determining overly contrived ways of destroying Ada from the inside out.. Apparently because Ada's carefully enforced discipline is too inconvenient, or something.

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-26 15:59, Dan'l Miller wrote:
> On Tuesday, June 26, 2018 at 2:44:26 AM UTC-5, Dmitry A. Kazakov wrote:
>> On 2018-06-25 18:21, Dan'l Miller wrote:
>>> On Monday, June 25, 2018 at 10:19:15 AM UTC-5, Dmitry A. Kazakov wrote:
>>>> On 2018-06-25 16:44, J-P. Rosen wrote:
>>>>> Le 25/06/2018 à 16:21, Dmitry A. Kazakov a écrit :
>>>>
>>>>>> Ada could allow T'Class for untagged T. T'Class would be an indefinite
>>>>>> type with values consisting of the actual type's tag and its value. When
>>>>>> T is by-value type, you pass T'Class to a subprogram as tag + value.
>>>>>> When T is by-reference type, you pass tag + reference.
>>>>>>
>>>>>> Upon dispatch, you strip the tag from the value or reference before
>>>>>> passing value/reference down.
>>>>>
>>>>> It was a requirement of Ada95 that OOP be strictly contained, and that
>>>>> the same typing system as Ada83 be kept for those who don't want OOP.
>>>>
>>>> Don't want OO, don't declare T'Class objects. Where is a problem?
>>>
>>> The problem is that you just proposed 'Class for non-OO semantics.  Your proposal violates the Principal of Least Surprise.
>>
>> Remember, Ada is a strongly typed language, T'Class is not T, there is
>> no way it could break or change anything in T.
> 
> Quit putting non sequitur words in my mouth.  I never said that it would break anything in T.  I said that it would break T'Class in •some• situations of the untagged extended records,

Such situations are strictly non-existent for neither T'Class nor record 
extensions are presently allowed for non-tagged types.

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

Re: Ada Successor Language

[Dan'l Miller]

On Tuesday, June 26, 2018 at 9:17:02 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-06-26 15:59, Dan'l Miller wrote:
> > On Tuesday, June 26, 2018 at 2:44:26 AM UTC-5, Dmitry A. Kazakov wrote:
> >> On 2018-06-25 18:21, Dan'l Miller wrote:
> >>> On Monday, June 25, 2018 at 10:19:15 AM UTC-5, Dmitry A. Kazakov wrote:
> >>>> On 2018-06-25 16:44, J-P. Rosen wrote:
> >>>>> Le 25/06/2018 à 16:21, Dmitry A. Kazakov a écrit :
> >>>>
> >>>>>> Ada could allow T'Class for untagged T. T'Class would be an indefinite
> >>>>>> type with values consisting of the actual type's tag and its value. When
> >>>>>> T is by-value type, you pass T'Class to a subprogram as tag + value.
> >>>>>> When T is by-reference type, you pass tag + reference.
> >>>>>>
> >>>>>> Upon dispatch, you strip the tag from the value or reference before
> >>>>>> passing value/reference down.
> >>>>>
> >>>>> It was a requirement of Ada95 that OOP be strictly contained, and that
> >>>>> the same typing system as Ada83 be kept for those who don't want OOP.
> >>>>
> >>>> Don't want OO, don't declare T'Class objects. Where is a problem?
> >>>
> >>> The problem is that you just proposed 'Class for non-OO semantics.  Your proposal violates the Principal of Least Surprise.
> >>
> >> Remember, Ada is a strongly typed language, T'Class is not T, there is
> >> no way it could break or change anything in T.
> > 
> > Quit putting non sequitur words in my mouth.  I never said that it would break anything in T.  I said that it would break T'Class in •some• situations of the untagged extended records,
> 
> Such situations are strictly non-existent for neither T'Class nor record 
> extensions are presently allowed for non-tagged types.

And yet, you propose them.

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-26 16:42, Dan'l Miller wrote:
> On Tuesday, June 26, 2018 at 9:17:02 AM UTC-5, Dmitry A. Kazakov wrote:
>> On 2018-06-26 15:59, Dan'l Miller wrote:
>>> On Tuesday, June 26, 2018 at 2:44:26 AM UTC-5, Dmitry A. Kazakov wrote:
>>>> On 2018-06-25 18:21, Dan'l Miller wrote:
>>>>> On Monday, June 25, 2018 at 10:19:15 AM UTC-5, Dmitry A. Kazakov wrote:
>>>>>> On 2018-06-25 16:44, J-P. Rosen wrote:
>>>>>>> Le 25/06/2018 à 16:21, Dmitry A. Kazakov a écrit :
>>>>>>
>>>>>>>> Ada could allow T'Class for untagged T. T'Class would be an indefinite
>>>>>>>> type with values consisting of the actual type's tag and its value. When
>>>>>>>> T is by-value type, you pass T'Class to a subprogram as tag + value.
>>>>>>>> When T is by-reference type, you pass tag + reference.
>>>>>>>>
>>>>>>>> Upon dispatch, you strip the tag from the value or reference before
>>>>>>>> passing value/reference down.
>>>>>>>
>>>>>>> It was a requirement of Ada95 that OOP be strictly contained, and that
>>>>>>> the same typing system as Ada83 be kept for those who don't want OOP.
>>>>>>
>>>>>> Don't want OO, don't declare T'Class objects. Where is a problem?
>>>>>
>>>>> The problem is that you just proposed 'Class for non-OO semantics.  Your proposal violates the Principal of Least Surprise.
>>>>
>>>> Remember, Ada is a strongly typed language, T'Class is not T, there is
>>>> no way it could break or change anything in T.
>>>
>>> Quit putting non sequitur words in my mouth.  I never said that it would break anything in T.  I said that it would break T'Class in •some• situations of the untagged extended records,
>>
>> Such situations are strictly non-existent for neither T'Class nor record
>> extensions are presently allowed for non-tagged types.
> 
> And yet, you propose them.

Proposing something that is already there would be kind of pointless...

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

Re: Ada Successor Language

[Simon Wright]

ric.wai88@gmail.com writes:

> I hope I can opt to be out-side of this "Ada" community who seem bent
> on wasting copious time determining overly contrived ways of
> destroying Ada from the inside out.. Apparently because Ada's
> carefully enforced discipline is too inconvenient, or something.

I agree with you. It feels as though we have a few people around who
enjoy wild flights of fancy.

Re: Ada Successor Language

[Dan'l Miller]

On Tuesday, June 26, 2018 at 10:38:50 AM UTC-5, Simon Wright wrote:
> ric.wai88@gmail.com writes:
> 
> > I hope I can opt to be out-side of this "Ada" community who seem bent
> > on wasting copious time determining overly contrived ways of
> > destroying Ada from the inside out.. Apparently because Ada's
> > carefully enforced discipline is too inconvenient, or something.
> 
> I agree with you. It feels as though we have a few people around who
> enjoy wild flights of fancy.

I agree.  Ada does not need records with external-to-record tags.  (What the heck would we call these, btw?  Untagged tagged records?  Tagged untagged records?)

In a more general case, what Ada needs slightly more that is vaguely on a similar topic is satisfying Steelman requirement 3-3F, one of the very few Steelman requirements that Ada83 didn't live up to:
 https://www.dwheeler.com/steelman/steeltab.htm#3-3F

Presumably the external-to-record tag could be such a constant field of the record, where that field does not occupy storage in the record, as 3-3F requires permitting.

(But Steelman 3-3F does nothing to rectify my fear that the compiler would choose the wrong strong type and thus choose the wrong external-to-record tag in certain situations, importing C++ slicing into Ada.)

Re: Ada Successor Language

[Shark8]

On Monday, June 25, 2018 at 2:20:42 AM UTC-6, Marius Amado-Alves wrote:
> This conjecture, that OO polymorphism is *always* preferrable to generics, is picking my mind big time. I've got a strong intuition that there are cases best served by generics. I'll try to find examples. Or if anyone has some please post.

I disagree with that summation wholeheartedly; one place generics are superior to OO is in sharing code. OOP is _not_ good for that purpose, despite some claims it is.

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-26 18:50, Dan'l Miller wrote:
> On Tuesday, June 26, 2018 at 10:38:50 AM UTC-5, Simon Wright wrote:
>> ric.wai88@gmail.com writes:
>>
>>> I hope I can opt to be out-side of this "Ada" community who seem bent
>>> on wasting copious time determining overly contrived ways of
>>> destroying Ada from the inside out.. Apparently because Ada's
>>> carefully enforced discipline is too inconvenient, or something.
>>
>> I agree with you. It feels as though we have a few people around who
>> enjoy wild flights of fancy.
> 
> I agree.  Ada does not need records with external-to-record tags.

Ada already has them, since 1983.

> (What the heck would we call these, btw?  Untagged tagged records?  Tagged untagged records?)

There is no special name in RM 3.8, just "record".

> In a more general case, what Ada needs slightly more that is vaguely on a similar topic is satisfying Steelman requirement 3-3F, one of the very few Steelman requirements that Ada83 didn't live up to:
>   https://www.dwheeler.com/steelman/steeltab.htm#3-3F
> 
> Presumably the external-to-record tag could be such a constant field of the record, where that field does not occupy storage in the record, as 3-3F requires permitting.

Surely type tag is a constraint and can be considered a discriminant. 
Note that array type constraints (bounds) are in the object only if the 
array object is indefinite. Compare this with the type tag.

> (But Steelman 3-3F does nothing to rectify my fear that the compiler would choose the wrong strong type and thus choose the wrong external-to-record tag in certain situations, importing C++ slicing into Ada.)

You have a mental lock on how type-specific objects and class-wide 
objects must be represented. Embedded type tag is an artifact of tagged 
types design, mainly for the purpose of having view conversions between 
T<:T1<:T2 and T and T'Class. It does not mean that all objects must have 
such representation, by no means.

Again, remember that Ada was designed with the idea of separation of 
interface and implementation. Many problems Ada has come from 
disregarding this principle. Embedded tag and by-reference parameter 
passing are just implementation details.

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

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-26 19:20, Shark8 wrote:
> On Monday, June 25, 2018 at 2:20:42 AM UTC-6, Marius Amado-Alves wrote:
>> This conjecture, that OO polymorphism is *always* preferrable to generics, is picking my mind big time. I've got a strong intuition that there are cases best served by generics. I'll try to find examples. Or if anyone has some please post.
> 
> I disagree with that summation wholeheartedly; one place generics are superior to OO is in sharing code. OOP is _not_ good for that purpose, despite some claims it is.

How so? The code of the bodies of inherited primitive operations and the 
bodies of class-wide operations are shared the in proper sense of this word.

Sharing with generics is a quite difficult task if you really tried to 
do this. E.g. there are several approaches to specialization of shared 
generic code:

1. You can pass a package instance

    generic
       type T is ...
       package Foobar is new Foo (T => T, ...
    package Bar

2. You can use child generic package

    generic
       ...
    package Foo.Bar is

None of which works satisfactory and geometrically explodes in presence 
of several type-parameters. An equivalent of

    Bar (X : A'Class; Y : B'Class; Z : C'Class);

is barely possible.

P.S. I have an impression that people advocating generics never really 
used them beyond instantiation of containers from the standard library. 
A real-life challenge looks like this:

    http://www.dmitry-kazakov.de/ada/fuzzy.htm#8

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

Re: Ada Successor Language

[Jacob Sparre Andersen]

jm.tarrasa@gmail.com writes:

> That is a classic in Ada forum "That version is not stable..."

Considering how much non-Ada code there is in the program in question,
and how few resources there are for testing the program, I'm not really
surprised.

But yes, somebody should have tested it with a wider selection of
project files, before releasing it.

Greetings,

Jacob
-- 
<URL: small-talk://work/hallway-meeting/...>

Re: Ada Successor Language

[Dan'l Miller]

On Tuesday, June 26, 2018 at 12:25:27 PM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-06-26 18:50, Dan'l Miller wrote:
> > On Tuesday, June 26, 2018 at 10:38:50 AM UTC-5, Simon Wright wrote:
> >> ric.wai88@gmail.com writes:
> >>
> >>> I hope I can opt to be out-side of this "Ada" community who seem bent
> >>> on wasting copious time determining overly contrived ways of
> >>> destroying Ada from the inside out.. Apparently because Ada's
> >>> carefully enforced discipline is too inconvenient, or something.
> >>
> >> I agree with you. It feels as though we have a few people around who
> >> enjoy wild flights of fancy.
> > 
> > I agree.  Ada does not need records with external-to-record tags.
> 
> Ada already has them, since 1983.

Wait.  Ada83 already has what you are proposing regarding 'Class for untagged records, eh?  But merely 3 hours ago you said that your proposing of something that is already there would be pointless:

On Tuesday, June 26, 2018 at 9:47:38 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-06-26 16:42, Dan'l Miller wrote:
> > On Tuesday, June 26, 2018 at 9:17:02 AM UTC-5, Dmitry A. Kazakov wrote:
> >> On 2018-06-26 15:59, Dan'l Miller wrote:
> >>> On Tuesday, June 26, 2018 at 2:44:26 AM UTC-5, Dmitry A. Kazakov wrote:
> >>>> On 2018-06-25 18:21, Dan'l Miller wrote:
> >>>>> On Monday, June 25, 2018 at 10:19:15 AM UTC-5, Dmitry A. Kazakov wrote:
> >>>>>> On 2018-06-25 16:44, J-P. Rosen wrote:
> >>>>>>> Le 25/06/2018 à 16:21, Dmitry A. Kazakov a écrit :
> >>>>>>
> >>>>>>>> Ada could allow T'Class for untagged T. T'Class would be an indefinite
> >>>>>>>> type with values consisting of the actual type's tag and its value. When
> >>>>>>>> T is by-value type, you pass T'Class to a subprogram as tag + value.
> >>>>>>>> When T is by-reference type, you pass tag + reference.
> >>>>>>>>
> >>>>>>>> Upon dispatch, you strip the tag from the value or reference before
> >>>>>>>> passing value/reference down.
> >>>>>>>
> >>>>>>> It was a requirement of Ada95 that OOP be strictly contained, and that
> >>>>>>> the same typing system as Ada83 be kept for those who don't want OOP.
> >>>>>>
> >>>>>> Don't want OO, don't declare T'Class objects. Where is a problem?
> >>>>>
> >>>>> The problem is that you just proposed 'Class for non-OO semantics.  Your proposal violates the Principal of Least Surprise.
> >>>>
> >>>> Remember, Ada is a strongly typed language, T'Class is not T, there is
> >>>> no way it could break or change anything in T.
> >>>
> >>> Quit putting non sequitur words in my mouth.  I never said that it would break anything in T.  I said that it would break T'Class in •some• situations of the untagged extended records,
> >>
> >> Such situations are strictly non-existent for neither T'Class nor record
> >> extensions are presently allowed for non-tagged types.
> > 
> > And yet, you propose them.
> 
> Proposing something that is already there would be kind of pointless...

Your not-proposing proposing talks yourself in circles.  Or is it that you are proposing nonproposals?  I cannot keep your circular nonsense straight.

> > (What the heck would we call these, btw?  Untagged tagged records?  Tagged untagged records?)
> 
> There is no special name in RM 3.8, just "record".

Ummmm.  _LRM_'s §3.8 says nothing about your 'Class usage on untagged records.

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-26 20:47, Dan'l Miller wrote:
> On Tuesday, June 26, 2018 at 12:25:27 PM UTC-5, Dmitry A. Kazakov wrote:
>> On 2018-06-26 18:50, Dan'l Miller wrote:
>>> On Tuesday, June 26, 2018 at 10:38:50 AM UTC-5, Simon Wright wrote:
>>>> ric.wai88@gmail.com writes:
>>>>
>>>>> I hope I can opt to be out-side of this "Ada" community who seem bent
>>>>> on wasting copious time determining overly contrived ways of
>>>>> destroying Ada from the inside out.. Apparently because Ada's
>>>>> carefully enforced discipline is too inconvenient, or something.
>>>>
>>>> I agree with you. It feels as though we have a few people around who
>>>> enjoy wild flights of fancy.
>>>
>>> I agree.  Ada does not need records with external-to-record tags.
>>
>> Ada already has them, since 1983.
> 
> Wait.  Ada83 already has what you are proposing regarding 'Class for untagged records, eh?

Ada 83 has "untagged" records, yes.

> But merely 3 hours ago you said that your proposing of something that is already there would be pointless:

Exactly. I never proposed "untagged" records. I proposed a method to 
have a class-wide type rooted in a non-tagged type, not only records but 
scalar types, array types, even tasks and protected objects as well.

>>> (What the heck would we call these, btw?  Untagged tagged records?  Tagged untagged records?)
>>
>> There is no special name in RM 3.8, just "record".
> 
> Ummmm.  _LRM_'s §3.8 says nothing about your 'Class usage on untagged records.

It says about records, all records including "untagged" ones.

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

Re: Ada Successor Language

[Dan'l Miller]

On Tuesday, June 26, 2018 at 2:29:48 PM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-06-26 20:47, Dan'l Miller wrote:
> > On Tuesday, June 26, 2018 at 12:25:27 PM UTC-5, Dmitry A. Kazakov wrote:
> >> On 2018-06-26 18:50, Dan'l Miller wrote:
> >>> On Tuesday, June 26, 2018 at 10:38:50 AM UTC-5, Simon Wright wrote:
> >>>> ric.wai88@gmail.com writes:
> >>>>
> >>>>> I hope I can opt to be out-side of this "Ada" community who seem bent
> >>>>> on wasting copious time determining overly contrived ways of
> >>>>> destroying Ada from the inside out.. Apparently because Ada's
> >>>>> carefully enforced discipline is too inconvenient, or something.
> >>>>
> >>>> I agree with you. It feels as though we have a few people around who
> >>>> enjoy wild flights of fancy.
> >>>
> >>> I agree.  Ada does not need records with external-to-record tags.
> >>
> >> Ada already has them, since 1983.
> > 
> > Wait.  Ada83 already has what you are proposing regarding 'Class for untagged records, eh?
> 
> Ada 83 has "untagged" records, yes.

But Ada83 does not have your 'Class for untagged types.

> > But merely 3 hours ago you said that your proposing of something that is already there would be pointless:
> 
> Exactly. I never proposed "untagged" records. I proposed a method to 
> have a class-wide type rooted in a non-tagged type, not only records but 
> scalar types, array types, even tasks and protected objects as well.

Ahhh, now your words have finally circled back to that bad idea that threatens to bring C++ slicing to Ada when the compiler's choice of strong type differed from the programmer's intended strong type.  Welcome back!  Many happy returns.

> >>> (What the heck would we call these, btw?  Untagged tagged records?  Tagged untagged records?)
> >>
> >> There is no special name in RM 3.8, just "record".
> > 
> > Ummmm.  _LRM_'s §3.8 says nothing about your 'Class usage on untagged records.
> 
> It says about records, all records including "untagged" ones.

But not your 'Class for untagged records using your external-to-record tag.

Re: Ada Successor Language

[J-P. Rosen]

Le 25/06/2018 à 16:03, Niklas Holsti a écrit :
> So it says in RM 3.4(5/2), but even the Annotated RM has no motivation
> for it, and I don't see why Ada could not assume a null extension when
> the type is tagged. Can someone explain why the RM is so strict on this?
> 
> (In fact, it seems to me that Ada could allow untagged record extensions
> as well; the effect would be the same as for tagged ones, but no 'Class
> would be formed, and no class-wide programming or dynamic dispatch could
> be used, so all such types would be static. It would be semantically
> equivalent to aggregation of a component of the parent type with the
> extension components, but would allow direct access to the inherited
> components from the parent type. This could be a useful separation of
> extensions from tags.)
You can achieve exactly this with a tagged type and Restriction
(No_Dispatch)

-- 
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: Ada Successor Language

[Niklas Holsti]

On 18-06-26 23:16 , J-P. Rosen wrote:
> Le 25/06/2018 à 16:03, Niklas Holsti a écrit :
>> So it says in RM 3.4(5/2), but even the Annotated RM has no motivation
>> for it, and I don't see why Ada could not assume a null extension when
>> the type is tagged. Can someone explain why the RM is so strict on this?
>>
>> (In fact, it seems to me that Ada could allow untagged record extensions
>> as well; the effect would be the same as for tagged ones, but no 'Class
>> would be formed, and no class-wide programming or dynamic dispatch could
>> be used, so all such types would be static. It would be semantically
>> equivalent to aggregation of a component of the parent type with the
>> extension components, but would allow direct access to the inherited
>> components from the parent type. This could be a useful separation of
>> extensions from tags.)
> You can achieve exactly this with a tagged type and Restriction
> (No_Dispatch)

Not exactly that, no: you would still have to declare the types as 
tagged, and the objects of these types would still have to store the tag 
value somewhere, at least for use when X'Tag is taken for a controlling 
parameter X of an inherited (non-overridden) operation.

Moreover, Restriction (No_Dispatch) is partition-wide (or so I believe, 
because "tailored" run-time systems are mentioned in that part of the 
RM, H.4). Thus it would not let one use both tagged record extensions 
and untagged record extensions in the same program partition.

In fact the only similarity I can see between Restriction (No_Dispatch) 
and the suggested extensibility of non-tagged records is that the latter 
(as I suggested it) would also not allow dispatching -- but preventing 
dispatch was not the point of the suggestion.

Combining extension of untagged records with Dmitry's suggestion for 
untagged class-wide types would allow dispatch (but not re-dispatch) for 
such extensions, which IMO shows that Restriction (No_Dispatch) is 
independent of untagged record extensions.

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

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-26 22:03, Dan'l Miller wrote:
> On Tuesday, June 26, 2018 at 2:29:48 PM UTC-5, Dmitry A. Kazakov wrote:
>> On 2018-06-26 20:47, Dan'l Miller wrote:
>>> On Tuesday, June 26, 2018 at 12:25:27 PM UTC-5, Dmitry A. Kazakov wrote:
>>>> On 2018-06-26 18:50, Dan'l Miller wrote:
>>>>> On Tuesday, June 26, 2018 at 10:38:50 AM UTC-5, Simon Wright wrote:
>>>>>> ric.wai88@gmail.com writes:
>>>>>>
>>>>>>> I hope I can opt to be out-side of this "Ada" community who seem bent
>>>>>>> on wasting copious time determining overly contrived ways of
>>>>>>> destroying Ada from the inside out.. Apparently because Ada's
>>>>>>> carefully enforced discipline is too inconvenient, or something.
>>>>>>
>>>>>> I agree with you. It feels as though we have a few people around who
>>>>>> enjoy wild flights of fancy.
>>>>>
>>>>> I agree.  Ada does not need records with external-to-record tags.
>>>>
>>>> Ada already has them, since 1983.
>>>
>>> Wait.  Ada83 already has what you are proposing regarding 'Class for untagged records, eh?
>>
>> Ada 83 has "untagged" records, yes.
> 
> But Ada83 does not have your 'Class for untagged types.

Your question was about naming "untagged" records and that they may 
break something if introduced. Records are defined in RM 3.8. They 
cannot be introduced because they are already there. They cannot break 
anything for the same reason. So far clear?

Adding a class-wide type cannot break anything for the reason of being a 
distinct type. Whatever semantic T'Class has it is related to the 
objects of this and only this type, because Ada has strong nominal type 
system. OK?

>>> But merely 3 hours ago you said that your proposing of something that is already there would be pointless:
>>
>> Exactly. I never proposed "untagged" records. I proposed a method to
>> have a class-wide type rooted in a non-tagged type, not only records but
>> scalar types, array types, even tasks and protected objects as well.
> 
> Ahhh, now your words have finally circled back to that bad idea that threatens to bring C++ slicing to Ada when the compiler's choice of strong type differed from the programmer's intended strong type.  Welcome back!  Many happy returns.

I have no idea about C++ slicing anything. Even less about Ada choosing 
types. Ada is a strongly manifestedly typed language. There is no way 
the compiler could choose a type for the programmer. There is no type 
inference in Ada and there is no such thing in my proposal. Please 
explain what exactly you mean.

>>>>> (What the heck would we call these, btw?  Untagged tagged records?  Tagged untagged records?)
>>>>
>>>> There is no special name in RM 3.8, just "record".
>>>
>>> Ummmm.  _LRM_'s §3.8 says nothing about your 'Class usage on untagged records.
>>
>> It says about records, all records including "untagged" ones.
> 
> But not your 'Class for untagged records using your external-to-record tag.

Yes, and?

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

Re: Ada Successor Language

[Niklas Holsti]

On 18-06-26 16:59 , Dan'l Miller wrote:
> On Tuesday, June 26, 2018 at 2:44:26 AM UTC-5, Dmitry A. Kazakov
> wrote:
>> On 2018-06-25 18:21, Dan'l Miller wrote:
>>> On Monday, June 25, 2018 at 10:19:15 AM UTC-5, Dmitry A. Kazakov
>>> wrote:
>>>> On 2018-06-25 16:44, J-P. Rosen wrote:
>>>>> Le 25/06/2018 à 16:21, Dmitry A. Kazakov a écrit :
>>>>
>>>>>> Ada could allow T'Class for untagged T. T'Class would be an
>>>>>> indefinite type with values consisting of the actual type's
>>>>>> tag and its value. When T is by-value type, you pass
>>>>>> T'Class to a subprogram as tag + value. When T is
>>>>>> by-reference type, you pass tag + reference.
>>>>>>
>>>>>> Upon dispatch, you strip the tag from the value or
>>>>>> reference before passing value/reference down.
>>>>>
>>>>> It was a requirement of Ada95 that OOP be strictly contained,
>>>>> and that the same typing system as Ada83 be kept for those
>>>>> who don't want OOP.
>>>>
>>>> Don't want OO, don't declare T'Class objects. Where is a
>>>> problem?
>>>
>>> The problem is that you just proposed 'Class for non-OO
>>> semantics.  Your proposal violates the Principal of Least
>>> Surprise.
>>
>> Remember, Ada is a strongly typed language, T'Class is not T, there
>> is no way it could break or change anything in T.
>
> Quit putting non sequitur words in my mouth.  I never said that it
> would break anything in T.  I said that it would break T'Class in
> •some• situations of the untagged extended records, analogous to ways
> that are known in C++ as slicing.  Ada community wants one of C++'s
> most-maligned problems where the compiler sometimes picks the wrong
> strong typing?

I'm far from competent in C++, but searching a little for "C++ slicing" 
suggests that the slicing problem has to do with non-virtual assignment 
operators which implicitly and silently convert a derived-type 
expression on the right hand side, to a parent type variable (reference) 
on the left hand side, discarding the components added in the derivation.

As Ada does not let one define one's own assignment operators, and as 
class-wide types are understood as discriminated by the tag, I don't 
think Dmitry's suggestion for class-wide types rooted in untagged types 
would lead to the same problems as slicing in C++.

Dan'l, could you explain more about the slicing-like problem you see in 
Dmitry's suggestion?

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

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-26 22:49, Niklas Holsti wrote:
> On 18-06-26 23:16 , J-P. Rosen wrote:
>> Le 25/06/2018 à 16:03, Niklas Holsti a écrit :
>>> So it says in RM 3.4(5/2), but even the Annotated RM has no motivation
>>> for it, and I don't see why Ada could not assume a null extension when
>>> the type is tagged. Can someone explain why the RM is so strict on this?
>>>
>>> (In fact, it seems to me that Ada could allow untagged record extensions
>>> as well; the effect would be the same as for tagged ones, but no 'Class
>>> would be formed, and no class-wide programming or dynamic dispatch could
>>> be used, so all such types would be static. It would be semantically
>>> equivalent to aggregation of a component of the parent type with the
>>> extension components, but would allow direct access to the inherited
>>> components from the parent type. This could be a useful separation of
>>> extensions from tags.)
>> You can achieve exactly this with a tagged type and Restriction
>> (No_Dispatch)
> 
> Not exactly that, no: you would still have to declare the types as 
> tagged, and the objects of these types would still have to store the tag 
> value somewhere, at least for use when X'Tag is taken for a controlling 
> parameter X of an inherited (non-overridden) operation.
> 
> Moreover, Restriction (No_Dispatch) is partition-wide (or so I believe, 
> because "tailored" run-time systems are mentioned in that part of the 
> RM, H.4). Thus it would not let one use both tagged record extensions 
> and untagged record extensions in the same program partition.
> 
> In fact the only similarity I can see between Restriction (No_Dispatch) 
> and the suggested extensibility of non-tagged records is that the latter 
> (as I suggested it) would also not allow dispatching -- but preventing 
> dispatch was not the point of the suggestion.
> 
> Combining extension of untagged records with Dmitry's suggestion for 
> untagged class-wide types would allow dispatch (but not re-dispatch) for 
> such extensions, which IMO shows that Restriction (No_Dispatch) is 
> independent of untagged record extensions.

Furthermore, it must not be limited to only record types or only 
extensions. Since by-reference semantics and view conversions do not 
hold for non-tagged types anyway, we could allow representation 
overriding as an alternative to representation extension.

With representation overriding the derived type must provide value 
conversions used for inherited operations. The parent type's value is no 
longer a part of the descendant's value. That will give us extending and 
shrinking enumeration types, making Unbounded_String a descendant of 
String and much more.

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

Re: Ada Successor Language

[Niklas Holsti]

On 18-06-26 18:38 , Simon Wright wrote:
> ric.wai88@gmail.com writes:
>
>> I hope I can opt to be out-side of this "Ada" community who seem bent
>> on wasting copious time determining overly contrived ways of
>> destroying Ada from the inside out.. Apparently because Ada's
>> carefully enforced discipline is too inconvenient, or something.
>
> I agree with you. It feels as though we have a few people around who
> enjoy wild flights of fancy.

Hey, the subject is "Ada Successor Language". Some non-conventional 
ideas should be allowed, no?

Regarding Dmitry's and my suggestions to split the OO concept into a few 
simpler primitives, instead of bundling them all into tagged types, it 
has been conventional to use just such a "building block" approach to 
defend some aspects of the design of Ada95 and later Ada versions -- 
most often, to defend the lack of built-in multiple inheritance, for 
which Ada is said to provide building blocks from which the designer can 
build the kind of MI she needs.

Perhaps the suggestions for untagged record extension and class-wide 
types rooted in untagged types are not exactly building blocks -- I 
don't now see how tagged types could be built from such blocks -- but at 
least they are in same spirit.

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

Re: Ada Successor Language

[Dan'l Miller]

On Tuesday, June 26, 2018 at 4:01:22 PM UTC-5, Niklas Holsti wrote:
> On 18-06-26 16:59 , Dan'l Miller wrote:
> > On Tuesday, June 26, 2018 at 2:44:26 AM UTC-5, Dmitry A. Kazakov
> > wrote:
> >> On 2018-06-25 18:21, Dan'l Miller wrote:
> >>> On Monday, June 25, 2018 at 10:19:15 AM UTC-5, Dmitry A. Kazakov
> >>> wrote:
> >>>> On 2018-06-25 16:44, J-P. Rosen wrote:
> >>>>> Le 25/06/2018 à 16:21, Dmitry A. Kazakov a écrit :
> >>>>
> >>>>>> Ada could allow T'Class for untagged T. T'Class would be an
> >>>>>> indefinite type with values consisting of the actual type's
> >>>>>> tag and its value. When T is by-value type, you pass
> >>>>>> T'Class to a subprogram as tag + value. When T is
> >>>>>> by-reference type, you pass tag + reference.
> >>>>>>
> >>>>>> Upon dispatch, you strip the tag from the value or
> >>>>>> reference before passing value/reference down.
> >>>>>
> >>>>> It was a requirement of Ada95 that OOP be strictly contained,
> >>>>> and that the same typing system as Ada83 be kept for those
> >>>>> who don't want OOP.
> >>>>
> >>>> Don't want OO, don't declare T'Class objects. Where is a
> >>>> problem?
> >>>
> >>> The problem is that you just proposed 'Class for non-OO
> >>> semantics.  Your proposal violates the Principal of Least
> >>> Surprise.
> >>
> >> Remember, Ada is a strongly typed language, T'Class is not T, there
> >> is no way it could break or change anything in T.
> >
> > Quit putting non sequitur words in my mouth.  I never said that it
> > would break anything in T.  I said that it would break T'Class in
> > •some• situations of the untagged extended records, analogous to ways
> > that are known in C++ as slicing.  Ada community wants one of C++'s
> > most-maligned problems where the compiler sometimes picks the wrong
> > strong typing?
> 
> I'm far from competent in C++,

  The following replies from me interspersed below might seem harsh or snarky.  But they paint a crystal clear picture of how precisely a C++ programmer must think when tip-toeing through the field of landmines that is C++.

> but searching a little for "C++ slicing" 
> suggests that the slicing problem has to do with non-virtual 

  Stop right there and you will learn something.

> assignment operators

Oops.  Now that is where you went off in the weeds.  There are more ways of slicing via non-virtual behaviors than merely assignment operators.

> which implicitly and silently convert a derived-type 
> expression

Stop right there and you will learn something.

> on the right hand side,

Oops.  Now that is where you went off in the weeds.  There are more ways of converting a derived-type expression to its base type than being an r-value on the right-hand side.

> to a parent type variable (reference) 

Stop right there and you will learn something.

> on the left hand side,

Oops.  Now there is where you went off in the weeds.  There are more ways of discarding the components added in the derivation than being an l-value on the left-hand side.

> discarding the components added in the derivation.

Now we're back on track to learning something about slicing.

Niklas, you have the outcomes understood, but you don't see the multiple situations where slicing can occur.  Watch out!  Don't step on •that• landmine!  Or •that other one• over there either!  (i.e., you need to think more like a C++ programmer:  landmines landmines everywhere every waking moment.)

> … I don't 
> think Dmitry's suggestion for class-wide types rooted in untagged types 
> would lead to the same problems as slicing in C++.

Then you are an unable to foresee slicing situations as Bjarne Stroustrup was.  Bjarne should not be one's role model as a language designer.

> Dan'l, could you explain more about the slicing-like problem you see in 
> Dmitry's suggestion?

as quoting from page 80 of Item 22 in Scott Meyers's _Effective C++:  50 ways to improve your programs and designs_ (1992, over a quarter century ago!):
“Passing parameters by reference [context: in C++ jargon, when the object is a class or struct that has a pointer-to-vtable = in Ada jargon, when the object is a tagged record] has another advantage:  it avoids what is sometimes called the ‘slicing problem.’  When a derived class object is turned into a base class object [Niklas, take note:  via •any• of the multitude of language features], all of the specialized features [i.e., the pointer-to-vtable and dispatch therethrough] that made it behave like a derived class object are ‘sliced’ off, and you're left with a simple base class object.  This is almost never what you want.  …”

So here we see Scott Meyers over 25 years prior to your Bing/Google search telling of a quite different(-than-assignment-operator) way of achieving the dubious accomplishment of slicing implicitly quietly without warning or error, because the programmer inadvertently told the compiler to do something that the programmer did not really intend.  When the C++ programmer in effect accidentally said, blow my leg off via that slicing landmine that I didn't notice (i.e., •any• treating of the extended record as the base record, in Ada jargon), the C++ compiler dutifully says, “Yes, sir!  Right away, sir!  Boom.  <leg now smithereens>”

And just when you think that we have itemized the entire set of slicing landmines, the history of C++ demonstrates that we can concoct yet another slicing/combination-of-language-features situation.  Any language feature that permits •this• versus •that• can be transformed into a landmine.  With enough contemplation, any landmine can be utilized to concoct a slicing situation.

Re: Ada Successor Language

[Dan'l Miller]

On Tuesday, June 26, 2018 at 5:03:13 PM UTC-5, Dan'l Miller wrote:
> Then you are an unable to foresee slicing situations as Bjarne Stroustrup was.  Bjarne should not be
> one's role model as a language designer.

Typo:  Then you are /as/ unable to foresee …

Btw, what I am ultimately saying about the compiler automagically what rules say is the correct strong type's tag in a given situation (which might differ from what the programmer thought would occur) violates a fundamental premise of Ada:  source code whose behavior is obvious to human beings.  C++ is the ultimate language for voluminous automagical behavior that has not one iota of overt source code.  Ada absolutely does not need more of that, or at least in the C++ school of thought.

This comes down to a cognitive dimensions of notations issue.  C++ prioritizes automagical disembodied-fairies-without-source-code over overt source code, as some sort of variant of less-is-more.  (C++ has 2 cryptosyntaxes:  1) the symbols on the surface and 2{ the implicit unstated automagical disembodied-fairies-without-source-code floating around the programmer as a cloud of ghosts in the [compiler-]machine.)  Ichbiah's Ada83 is the utmost of ‘The program does exactly what the source code overtly states that it does—nothing more, nothing less’.
 https://en.wikipedia.org/wiki/Cognitive_dimensions_of_notations

'Class with tags-external-to-untagged-types is a C++-esque automagical disembodied-fairy-without-source-code, bringing one of the kinds of crypto syntax #2 into Ada.  No thank you:  we already have one C++; we don't need another one.

Re: Ada Successor Language

[Dan'l Miller]

On Tuesday, June 26, 2018 at 9:28:42 PM UTC-5, Dan'l Miller wrote:
> On Tuesday, June 26, 2018 at 5:03:13 PM UTC-5, Dan'l Miller wrote:
> > Then you are an unable to foresee slicing situations as Bjarne Stroustrup was.  Bjarne should not be
> > one's role model as a language designer.
> 
> Typo:  Then you are /as/ unable to foresee …
> 
> Btw, what I am ultimately saying about the compiler automagically what rules say is the correct strong
> type's tag in a given situation (which might differ from what the programmer thought would occur)
> violates a fundamental premise of Ada:  source code whose behavior is obvious to human beings.  C++
> is the ultimate language for voluminous automagical behavior that has not one iota of overt source code. 
> Ada absolutely does not need more of that, or at least in the C++ school of thought.
> 
> This comes down to a cognitive dimensions of notations issue.  C++ prioritizes automagical
> disembodied-fairies-without-source-code over overt source code, as some sort of variant of
> less-is-more.  (C++ has 2 cryptosyntaxes:  1) the symbols on the surface and 2{ the implicit unstated
> automagical disembodied-fairies-without-source-code floating around the programmer as a cloud of
> ghosts in the [compiler-]machine.)  Ichbiah's Ada83 is the utmost of ‘The program does exactly what the
> source code overtly states that it does—nothing more, nothing less’.
>  https://en.wikipedia.org/wiki/Cognitive_dimensions_of_notations
> 
> 'Class with tags-external-to-untagged-types is a C++-esque automagical
> disembodied-fairy-without-source-code, bringing one of the kinds of crypto syntax #2 into Ada.
>  No thank you:  we already have one C++; we don't need another one.

Or in a word:  homociconicity
https://en.wikipedia.org/wiki/Homoiconicity

Ada (especially Ichbiah's Ada83) is vastly closer to the homoiconicity end of the spectrum:  what you overtly see in the source code is the program that you get at run-time.  Ada95's
1) tagged-records' dispatch,
2) limited nonprivate types,
and
3) controlled types' finalization
are all incremental (but tolerable) steps in the direction of C++'s degree of anti-homoiconicity.

With zeal, C++ flagrantly eschews homoiconicity as homoiconicity would get in the way of many of its vast quantities of automagical implicit incantations
a) that often have absolutely no source-code representation whatsoever
or
b) that have only oblique/cryptic appearance in the source code as steering the direction that the disembodied-fairies-without-source-code fly.

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-26 23:15, Niklas Holsti wrote:

> Perhaps the suggestions for untagged record extension and class-wide 
> types rooted in untagged types are not exactly building blocks -- I 
> don't now see how tagged types could be built from such blocks -- but at 
> least they are in same spirit.

I think it could be possible, if we considered the tag of a tagged type 
as a discriminant.

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

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-27 00:03, Dan'l Miller wrote:
> On Tuesday, June 26, 2018 at 4:01:22 PM UTC-5, Niklas Holsti wrote:

>> … I don't
>> think Dmitry's suggestion for class-wide types rooted in untagged types
>> would lead to the same problems as slicing in C++.
> 
> Then you are an unable to foresee slicing situations as Bjarne Stroustrup was.  Bjarne should not be one's role model as a language designer.

But you are able to foresee that, right? Then maybe you put up an 
example of what the problem is?

P.S. The major failure of OO design in C++ is conflating specific and 
class-wide types, which makes C++ OO weakly-typed, whereas in Ada OO is 
strongly typed all the way. So any comparison to C++ without concrete 
examples is useless.

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

Re: Ada Successor Language

[Dan'l Miller]

On Wednesday, June 27, 2018 at 2:15:23 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-06-27 00:03, Dan'l Miller wrote:
> > On Tuesday, June 26, 2018 at 4:01:22 PM UTC-5, Niklas Holsti wrote:
> 
> >> … I don't
> >> think Dmitry's suggestion for class-wide types rooted in untagged types
> >> would lead to the same problems as slicing in C++.
> > 
> > Then you are an unable to foresee slicing situations as Bjarne Stroustrup was.  Bjarne should not be one's role model as a language designer.
> 
> But you are able to foresee that, right? Then maybe you put up an 
> example of what the problem is?

Rather than talk in C++-speak about importation of one of C++'s notorious flaws, let us instead talk in Ada-speak about an analogous proposed Ada feature.  The Steelman requirement 3-3F strongly resembles portions of your tag-external-to-type idea on which your 'Class for untagged types depends.  Both 3-3F and your tag-external-to-type require the compiler to know precisely which strong type is being utilized in ••every language construct everywhere under all circumstances••.  If the compiler at any time obfuscates that single strong type among a set of multiple related types, then the compiler runs the risk of
1) losing track of precisely which strong type this versus that 3-3F no-storage-allocated-within-record extra fields among various 3-3F-utilizing record-types.
or
2) losing track of precisely which strong type had this versus that tag-external-to-type regarding your various untagged types.

Just like Bjarne and the C++ standards committee's accidental introduction of landmines in C++, no sane person would •intentionally• design the losing-of-track into the language.  Rather, these losings-of-track would occur at the intersection/junction/boundary of 2 or more language features.  Because there are hundreds of language features, the combinatorial explosion of 2 or more language features in each other's context is quite a large number (hence the difficulty of the language designer foreseeing them all on Day One).  The medical world has a term for flaws at the junction of 2 or more tissue features:  conjunctive nevus.  Nearly all of C++'s landmines that must be meticulously vigilantly avoided every waking moment are in fact conjunctive nevuses where 2 or more language features interact badly with each other at their point of contact with each other.  That is what we are looking for here as well in Ada regarding 3-3F's and tags-external-to-type's perfect inability to never ever lose track of the single strong type.

Several language features come to mind immediately that could potentially be such obfuscations of strong typing into a set of 2 or more related types existing concurrently or progressively/incrementally over time:
a) generics
  a.1) especially compilers whose generics factor out a common object code for all/some varieties of arguments passed in
b) in the subprograms after OO tag dispatch via tagged records
c) discriminants
d) universal integer
e) private
f) Ada compilers with the _LRM_-permitted automatic garbage collection
g) constrained subtypes vis a vis each other and vis a vis the type's first subtype
h) array slices vis a vis each other and vis a vis the whole array
i) with … use
j) renames
h) child packages
j) aspects
k) pragmas
l) unchecked_conversion
m) unchecked_access
n) unchecked_deallocation
o) unchecked_union
p) any other language feature that directly allows  /this/ versus /that/ or conspires in /this/ versus /that/

Let us assume for the moment (or always) that Jean Ichbiah and Tucker Taft (and indeed the people at AJPO stating the goals of the Ada9X project) aren't ignorant dolts who didn't do their homework.  Let us assume that both Ichbiah and Taft actually read Steelman requirement 3-3F.  Let us assume that both Ichbiah et. al. and Taft et. al. seriously pondered how to achieve Steelman requirement 3-3F.

http://www.adahome.com/History/Steelman/steeltas.htm#3-3F

But both Ada83 and Ada95 lack 3-3F.  Are we to infer that twice 2 language-design teams with 2 strong captains at the helm of the ship goofed up and accidentally forgot to include 3-3F?  No, sometime around 1980 give or take a few years and sometime around 1993 give or take a few years someone found really good reasons why 3-3F is a bad idea for Ada, because 3-3F would have __________ negative interactions with the _____________ language feature or because 3-3F would have ________ negative interactions with the ___________ psychology of the programmer as measured by the aforementioned cognitive dimensions of notation.

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

> P.S. The major failure of OO design in C++ is conflating specific and 
> class-wide types, which makes C++ OO weakly-typed, whereas in Ada OO is 
> strongly typed all the way.

Oh how quickly you change your tune.  Just 8 or 7 days ago you claimed the opposite regarding Ada's generics being a “weakly-typed” “50 shades of mess”.  Now Ada generics are the paragon of strong typing able to nobly withstand any interaction with bad-idea other language features.

On Tuesday, June 19, 2018 at 2:58:49 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-06-19 00:36, Paul Rubin wrote:
> > "Dmitry A. Kazakov" writes:
> >> P.S. Stepanov arguing for generics (templates) claimed that the reason
> >> why C++ needed this mess was impossibility to write Max using dynamic
> >> polymorphism... I believe it is possible to have a language where
> >> generic Max and Swap could be written without generics.
> > 
> > I've been wanting to look up how Ada generics work.  C++ generics are
> > implemented with templates which leads to a horrible mess, but generics
> > themselves don't have to be a mess, as far as I know.
> 
> There are 50 shades of mess. Ada's generics try to introduce some 
> weakly-typed contracts on the formal generic parameters, where C++ 
> templates go completely untyped, but mess is always mess. You cannot 
> make a decent language out of macro processor.

On Wednesday, June 20, 2018 at 2:33:26 AM UTC-5, Dmitry A. Kazakov wrote:
> On Tuesday, June 19, 2018 at 2:39:30 PM UTC-5, Dmitry A. Kazakov wrote: 
> >> Generics and macros are same thing regardless implementation. The core
> >> idea and all power lies in textual substitution as opposed to the
> >> concept substitutability in a properly typed systems.
> 
> There is no such thing in Ada. Formal generic types, e.g.
> 
>     type Foo (<>) is private;
> 
> match pretty much anything. The actual type is then substituted in all 
> language constructs just like macros do. The only constraint here is the 
> language syntax and a few sematic checks which make the language of 
> generics (not to confuse with the core language) weakly typed, where C++ 
> templates are completely untyped.

> So any comparison to C++ without concrete examples is useless.

No, any critique of an Ada proposal that has not been written up as an official AI or tantamount (same format &  content) to an AI is what is truly useless.  It isn't the responsibility of the other 7 billion people on the planet to •guess• what you mean.  The onus is on you to take the warnings that I have offered as food for thought when •you• write the AI for this 'Class for untagged types (and its external-to-type tag).  After the AI is in my hands, then and only then is the onus on me to critique it, both in Ada-only domain and vicariously by drawing meticulous parallels to C++.  Currently, I have nothing but hand-waving to work with there.

Without such an AI, every time that I nail your bad idea and eviscerate it totally (hitting the nail directly on the head of a fundamental flaw in your bad idea), you can play mind games of fibbing, “oh, silly you, my idea is quite different than that,” then going down dozens of oblique tangents of distraction.  With such an AI, we can see whether your AI plugs every hole in the leaky dike, whether the intersection of language features has planted a buried C++-esque landmine or whether the junction of language features has a conjunctive-nevus flaw.

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-27 18:33, Dan'l Miller wrote:
> On Wednesday, June 27, 2018 at 2:15:23 AM UTC-5, Dmitry A. Kazakov wrote:
>> On 2018-06-27 00:03, Dan'l Miller wrote:
>>> On Tuesday, June 26, 2018 at 4:01:22 PM UTC-5, Niklas Holsti wrote:
>>
>>>> … I don't
>>>> think Dmitry's suggestion for class-wide types rooted in untagged types
>>>> would lead to the same problems as slicing in C++.
>>>
>>> Then you are an unable to foresee slicing situations as Bjarne Stroustrup was.  Bjarne should not be one's role model as a language designer.
>>
>> But you are able to foresee that, right? Then maybe you put up an
>> example of what the problem is?
> 
> Rather than talk in C++-speak about importation of one of C++'s notorious flaws, let us instead talk in Ada-speak about an analogous proposed Ada feature.  The Steelman requirement 3-3F strongly resembles portions of your tag-external-to-type idea on which your 'Class for untagged types depends.  Both 3-3F and your tag-external-to-type require the compiler to know precisely which strong type is being utilized in ••every language construct everywhere under all circumstances••.

Yep, that is strong typing property. Ada has it. What's wrong with that?

> If the compiler at any time obfuscates that single strong type among a set of multiple related types, then the compiler runs the risk of
> 1) losing track of precisely which strong type this versus that 3-3F no-storage-allocated-within-record extra fields among various 3-3F-utilizing record-types.
> or
> 2) losing track of precisely which strong type had this versus that tag-external-to-type regarding your various untagged types.

There is nothing to lose. All types are statically known, thus all tags 
are known too.

> Several language features come to mind immediately that could potentially be such obfuscations of strong typing into a set of 2 or more related types existing concurrently or progressively/incrementally over time:

Show an example of such an obfuscation.

>> P.S. The major failure of OO design in C++ is conflating specific and
>> class-wide types, which makes C++ OO weakly-typed, whereas in Ada OO is
>> strongly typed all the way.
> 
> Oh how quickly you change your tune.  Just 8 or 7 days ago you claimed the opposite regarding Ada's generics being a “weakly-typed” “50 shades of mess”.  Now Ada generics are the paragon of strong typing able to nobly withstand any interaction with bad-idea other language features.

Ada OO /= Ada generics. The whole point is that the knowledge of type 
systems accumulated since 80's allows us now to get rid of generics and 
have a much more simpler, regular, smaller and safer language.

>> So any comparison to C++ without concrete examples is useless.
> 
> No, any critique of an Ada proposal that has not been written up as an official AI or tantamount (same format &  content) to an AI is what is truly useless.

Why bother with AI which will never be considered? To push such changes 
trough the ARG one needs somebody like Tucker Taft.

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

Re: Ada Successor Language

[Paul Rubin]

"Dan'l Miller" <optikos@verizon.net> writes:
> bad idea that threatens to bring C++ slicing to Ada

Are you talking about this?

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

Does Ada somehow escape from it now?  It does sound bad.

Re: Ada Successor Language

[Dan'l Miller]

On Thursday, June 28, 2018 at 10:11:59 PM UTC-5, Paul Rubin wrote:
> "Dan'l Miller" writes:
> > bad idea that threatens to bring C++ slicing to Ada
> 
> Are you talking about this?
> 
>    https://en.wikipedia.org/wiki/Object_slicing

Yes, but the Wikipedia article does not explore every tentacle.

> Does Ada somehow escape from it now?

I personally believe that Ada as currently defined never has had the slicing problem.  (But the Ada luminaries on the ARG would know best.)  This is because the Ada language designers have meticulously rejected language features in the vicinity of that topic to steer clear of it.  E.g., Ada doesn't permit overloading the assignment operator in any way that C++ does.  I suspect that repeatedly rejecting Steelman requirement 3-3F has something to do with it too.

> It does sound bad.

It is.  There are about a half dozen of the big causes of landmines in the landmine-field that is C++.  Slicing is perhaps the most potent/pernicious/silent of those big-6.  Conversely, programming professionally in C++ is like growing up as a child or teenager in a war zone:  you just learn that constant never-ending paranoia about avoiding all possibility of stepping on a landmine every waking moment is a really healthy survival/coping technique.  Still, I'd love to switch entirely over to Ada away from C++, hence why I am always looking for how to get Ada2012 or greater across all the platforms that I work on, especially the remaining ones:  iOS with Cocoa Touch, MacOS with Cocoa, Android via JNI, and soon to be Tizen and FuchsiaOS too.

Re: Ada Successor Language

[Paul Rubin]

"Dan'l Miller" <optikos@verizon.net> writes:
> It is.  There are about a half dozen of the big causes of landmines in
> the landmine-field that is C++.  Slicing is perhaps the most
> potent/pernicious/silent of those big-6.

I don't understand the exact reasons but the functional-programming
community tends to dislike subtypes altogether, preferring bounded
polymorphism (Num a => sum :: [a] -> a) to accomplish somewhat similar
goals.  Maybe slicing is one of the issues.  But I think it's more of
an obstacle to type inference.

Because of that same FP indoctrination, in C++ I tend to use generics
where it might be possible to use OO instead.  Does that avoid the
hazards of slicing?  Of course it has its own hassles, but once you
get something to compile it tends to do the right thing.

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-29 05:11, Paul Rubin wrote:
> "Dan'l Miller" <optikos@verizon.net> writes:
>> bad idea that threatens to bring C++ slicing to Ada
> 
> Are you talking about this?
> 
>     https://en.wikipedia.org/wiki/Object_slicing
> 
> Does Ada somehow escape from it now?

Sure, there is no way to reconstruct that in Ada.

> It does sound bad.

Only due to C++ design fault. Assignment is a classic multiple dispatch 
operation (a multi-method). C++ per design does no support MD. Here you go.

With MD it is no more an issue. Let T and S be two types T <: S. The 
assignment operation of mixed arguments and result

    ":=" : S x T -> S

could not be safely inherited by S from T's:

    ":=" : T x T -> T

Therefore the compiler would ask the programmer to override it (or 
redesign). Problem solved.

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

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-29 05:48, Paul Rubin wrote:

> Because of that same FP indoctrination, in C++ I tend to use generics
> where it might be possible to use OO instead.  Does that avoid the
> hazards of slicing?

That depends on how you use generics. If the language has this or any 
other problem, then in most cases, you can reconstruct it using generic 
instances. Simply put the offending code in a generic and here you are.

If you mean specifically inheritance, then generics are not capable of 
it. There is no generic equivalent of, because each generic instance 
creates isolated types. Surely, you can use formal parameters like:

    generic
       type S is new T with private;

but that is inheritance the generic borrows from outside, not a generic 
mechanism by itself.

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

Re: Ada Successor Language

[Dan'l Miller]

On Friday, June 29, 2018 at 2:20:40 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-06-29 05:11, Paul Rubin wrote:
> > "Dan'l Miller" writes:
> >> bad idea that threatens to bring C++ slicing to Ada
> > 
> > Are you talking about this?
> > 
> >     https://en.wikipedia.org/wiki/Object_slicing
> > 
> > Does Ada somehow escape from it now?
> 
> Sure, there is no way to reconstruct that in Ada.
> 
> > It does sound bad.
> 
> Only due to C++ design fault. Assignment is a classic multiple dispatch 
> operation (a multi-method). C++ per design does no support MD. Here you go.
> 
> With MD it is no more an issue. Let T and S be two types T <: S. The 
> assignment operation of mixed arguments and result
> 
>     ":=" : S x T -> S
> 
> could not be safely inherited by S from T's:
> 
>     ":=" : T x T -> T
> 
> Therefore the compiler would ask the programmer to override it (or 
> redesign). Problem solved.

Dmitry, you make it sound as though multiple dispatch would solve slicing in C++ (which has no dispatch whatsoever).  In the situations where slicing occurs, it is due to the old backwards-compatibility-with-C functionality in C++.  No vtable, pointer-to-vtable, no dispatching required to utilized or even to be present at all.  Slicing occurs at the intersection of:
1) inheritance (a.k.a. record extension in Ada-speak)
2) C semantics;
3) either:
3.1) when, regarding the base-struct, operating on whole structs/classes (whole records in Ada-speak), not on addresses per se: pointers alone, l-value references alone, r-value references alone
or
3.2) when at least one member-function (subprogram in Ada-speak) of the ‘same name’ is present in the base class and derived class that was not virtual (Ada83 subtype ‘inheritance’ in Ada-speak, due to being untagged inheritance).  In C++, base-struct's and derived-struct's destructors—either human authored or compiler generated—have the ‘same name’ for our purposes here, despite having different names of types; focus on the tilde ~ and the AST more than the type-name of the struct.

At the intersection of those 3 then the C++ compiler deduces that it is working in C mode instead of OO mode and abuses the strong type that it thinks that is in play (i.e., the base struct) and accomplishes the requested goal (e.g., assignment, shallow copy, pass-by-value, return-by-value, and so forth) thinking in C-semantics only of the base-struct, not in OO-semantics of bringing along the derived-struct's extension too.

Even when a vtable is present, you can convince a C++ compiler to ignore it by working in C semantics instead.  The hypothetical analogue in Ada would be to somehow convince an Ada compiler to ignore an Ada95-era tagged record by working with Ada83-era subtype inheritance that by its nature is untagged.  At some crude level, Ada has the Ada83 semantics and the Ada95-onward semantics analogous to C++ having the C-era semantics and the OO-era semantics.  Only by a dozen foresightful wisdoms & preclusions & carve-outs in just the right places of the _LRM_ does Ada not have much the same problem.

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-29 15:25, Dan'l Miller wrote:
> On Friday, June 29, 2018 at 2:20:40 AM UTC-5, Dmitry A. Kazakov wrote:
>> On 2018-06-29 05:11, Paul Rubin wrote:
>>> "Dan'l Miller" writes:
>>>> bad idea that threatens to bring C++ slicing to Ada
>>>
>>> Are you talking about this?
>>>
>>>      https://en.wikipedia.org/wiki/Object_slicing
>>>
>>> Does Ada somehow escape from it now?
>>
>> Sure, there is no way to reconstruct that in Ada.
>>
>>> It does sound bad.
>>
>> Only due to C++ design fault. Assignment is a classic multiple dispatch
>> operation (a multi-method). C++ per design does no support MD. Here you go.
>>
>> With MD it is no more an issue. Let T and S be two types T <: S. The
>> assignment operation of mixed arguments and result
>>
>>      ":=" : S x T -> S
>>
>> could not be safely inherited by S from T's:
>>
>>      ":=" : T x T -> T
>>
>> Therefore the compiler would ask the programmer to override it (or
>> redesign). Problem solved.
> 
> Dmitry, you make it sound as though multiple dispatch would solve slicing in C++ (which has no dispatch whatsoever).

I said nothing about dispatch! All types in question are statically known!

> In the situations where slicing occurs, it is due to the old backwards-compatibility-with-C functionality in C++.

I care little of C++ design flaws. There are plenty and C++ is far 
beyond the point where anything could be done to fix it. I argued that 
this problem could never occur in Ada with its sane type system.

The case constituting this bug in C++ is well present in Ada:

    type T is tagged null record;
    function F return T;

    type S is new T with record
       I : Integer;
    end record;

Now carefully observe that this does *not* compile exactly because of 
the problem that F cannot be inherited by S since the latter has members 
F could not initialize. F must be overridden. Treatment of assignment, 
should it ever become a primitive operation, would be no different.

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

Re: Ada Successor Language

[Dan'l Miller]

On Friday, June 29, 2018 at 12:39:59 PM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-06-29 15:25, Dan'l Miller wrote:
> > On Friday, June 29, 2018 at 2:20:40 AM UTC-5, Dmitry A. Kazakov wrote:
> >> On 2018-06-29 05:11, Paul Rubin wrote:
> >>> "Dan'l Miller" writes:
> >>>> bad idea that threatens to bring C++ slicing to Ada
> >>>
> >>> Are you talking about this?
> >>>
> >>>      https://en.wikipedia.org/wiki/Object_slicing
> >>>
> >>> Does Ada somehow escape from it now?
> >>
> >> Sure, there is no way to reconstruct that in Ada.
> >>
> >>> It does sound bad.
> >>
> >> Only due to C++ design fault. Assignment is a classic multiple dispatch
> >> operation (a multi-method). C++ per design does no support MD. Here you go.
> >>
> >> With MD it is no more an issue. Let T and S be two types T <: S. The
> >> assignment operation of mixed arguments and result
> >>
> >>      ":=" : S x T -> S
> >>
> >> could not be safely inherited by S from T's:
> >>
> >>      ":=" : T x T -> T
> >>
> >> Therefore the compiler would ask the programmer to override it (or
> >> redesign). Problem solved.
> > 
> > Dmitry, you make it sound as though multiple •dispatch• would solve slicing in C++ (which has no
> > dispatch whatsoever).
> 
> I said nothing about •dispatch•! All types in question are statically known!

Dmitry, do you even read what you write?  In what you just wrote 12 hours ago above, the “classic multiple •dispatch•”, the “does no[t] support •MD•” where MD = multiple •dispatch•, the “compiler would ask the programmer to •override• it” via the OO tag/vtable mechanism, and the “••Problem solved••” all directly mention multiple •dispatch• and how MD is directly related to the remedy to maldesigns in user-provided assignment operators in your direct reply to slicing via C++ assignment.

Turing test and uncanny valley come to mind.

> > In the situations where slicing occurs, it is due to the old backwards-compatibility-with-C functionality in C++.
> 
> I care little of C++ design flaws. There are plenty and C++ is far 
> beyond the point where anything could be done to fix it. I argued that 
> this problem could never occur in Ada with its sane type system.
> 
> The case constituting this bug in C++ is well present in Ada:
> 
>     type T is tagged null record;
>     function F return T;
> 
>     type S is new T with record
>        I : Integer;
>     end record;

That is clearly not analogous to the vicinity where C++'s slicing occurs.  That is analogous to correctly-functioning behavior of C++.

••Hypothetically•• in (not-this-timeline's-)Ada the analogous situation would be in the vicinity of:

a) tagged T is then constrained-subtyped as CST, a constrained subtype of T (to evoke Ada83-era semantics instead of Ada95).

b) Then 2 same-named subprograms would be overloaded to take T as the first parameter and CST as the first parameter.

c) Then tagged S would extend CST instead of T, so that the Ada95-era OO was mixed with the Ada83-era pre-OO inheritance of T to CST.

d) Then the programmer thinks that he is invoking the overloaded subprogram with CST as the first parameter, passing S in,

e) but (if Ada were as botched in certain areas as C++) instead the overloaded program with T as the first parameter is invoked (chopping the S-ness off S) so that the strong typing of S versus T is strictly enforced the wrong way, and the compiler would definitely strongly-typedly work with T when the programmer thought that the context was definitely strongly-typed as S and CST.

This perfect storm is merely one ••hypothetical•• case of trying to cause slicing in Ada via trying to trick the compiler to pick the ‘wrong’ overloaded subprogram of same name.  All the other ways of slicing (e.g., assignment, 'Image, record return value, perhaps generics, and so forth) would have their own contrived Ada95-tagged inheritance versus Ada83-untagged inheritance ••hypothetical•• stress tests that hopefully the _LRM_ individually explicitly carves out as overtly prohibited in at least one way.

There might even be ways of stress-testing potential slicing scenarios in Ada
1) without resorting to Ada83's subtyping at all
or
2) without putting Ada83's subtype constraints in direct •head-to-head• conflict with Ada95's OO tagged record extensions, but rather more obliquely through the interaction of 2 or more other language features (e.g., generics, child packages, private, use).

One would hope that 100% of all the dozen or so contrived* stress-tests would fail to compile (and fail to compile due to overt wording in the _LRM_—not due to spurious misinterpretation of the _LRM_ or due to bug-box compiler internal fault).

* perfect storm of 2 or more Ada{83, 95, 2005, 2012, 2020} language features interacting

Re: Ada Successor Language

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:776f3645-ed0c-4118-9b4d-21660e3bba4b@googlegroups.com...
...
>I'd honestly like the ability to use X'Type; this would allow us to say 
>something like this:

Please forget that idea, it would be a terrible can of worms in Ada 
semantics (or anything close to Ada sematics). See the write-up of 
AI12-0123-1 (long killed) for some details as to why.

                              Randy.

Re: Ada Successor Language

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:ly4lhyj5gb.fsf@pushface.org...
> Paul Rubin <no.email@nospam.invalid> writes:
>
>> Oh hmm, ok, that's interesting.  But I'm surprised that the LRM is
>> loose enough to allow two observably different implementations like
>> that.
>
> "observably"? how? code size of the generic will change, not sure that
> overall code size will, & anyway who cares?

Performance changes, too. But you really have to look in the cracks to see 
the differences. Ada uses "assume-the-worst" rules in generic bodies, so 
code that would actually execute differently under one scheme or the other 
would be illegal.

                           Randy.

Re: Ada Successor Language

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:pgd1hq$ca2$1@gioia.aioe.org...
...
> 4. No proper reuse. Generic bodies are no proper compilation units, you 
> cannot have a shared library of generics. Therefore the only possible form 
> of reuse is textual substitution and recompilation of the client code.

Since Janus/Ada implements them exactly this way, this is demonstratably 
false. The lack of reuse in some implementations (i.e. GNAT) is an intended 
implementation decision, not a language requirement.

> 5. No proper separation of interface and implementation. If you used Ada 
> generics you would know that successful compilation of a generic body 
> means little. Instantiation can always fail even if all formal parameters 
> match. The compiler must look into the body not just for the sake of 
> optimization and representation, but for validity of instantiation, just 
> like in C++. A macro is a macro.

This is also False. Ada uses "assume-the-worst" rules such that any legal 
generic body is legal for any possible instantiation. There are *different* 
rules for the generic specification, and perhaps you are running afoul of 
those (those can cause failure of an instantiation). Or of compiler bugs 
causing compilation failures in instance bodies. Neither make the above 
true.

In any case, it is technically impossible for the above to be true in 
Janus/Ada (the body is a regular compilation unit that is shared with all 
instances - it is never looked at during an instantation and the compiler 
doesn't have any saved information with which to do that anyway).

                                            Randy.



>> I don't think it was a mistake
>> for C++ to have generics since the generic approach in C++ is IME much
>> better than the OO approach with inheritance.
>
> This is evidently wrong. Ada programs extensively using generics are as 
> impossible to maintain as C++ programs using templates. IMO generics have 
> no place in SW engineering.
>
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de 

Re: Ada Successor Language

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:pgnl2q$19tv$1@gioia.aioe.org...
...
> That is not possible because generic formal contracts are weakly typed. 
> Consider, for simplicity, this:
>
>    with Ada.Finalization;
>    generic
>       type T is new Ada.Finalization.Controlled with private;
>    package P is
>       type S is new T with null record;
>       not overriding procedure Foo (X : S);
>    end P;

There's no generic body here - your original complaint was about generic 
bodies. The failure (if there is one) is in the generic specification -- the 
entire thing is part of the contract of the generic (it's not just the 
formal parameters). Thinking that the formal parameters reflect the entire 
contract is wishful (and incorrect) thinking -- that would be impractical 
for a reasons that you pointed out yourself.

                                Randy. 

Re: Ada Successor Language

[Randy Brukardt]

"Alejandro R. Mosteo" <alejandro@mosteo.com> wrote in message 
news:pgqas8$mjm$1@dont-email.me...
> On 23/06/2018 21:21, Jacob Sparre Andersen wrote:
>> Dmitry A. Kazakov wrote:
>>
>>> 5. No proper separation of interface and implementation. If you used
>>> Ada generics you would know that successful compilation of a generic
>>> body means little. Instantiation can always fail even if all formal
>>> parameters match. The compiler must look into the body not just for
>>> the sake of optimization and representation, but for validity of
>>> instantiation, just like in C++. A macro is a macro.
>>
>> If the compilation of a generic succeeds, then any instantiation with
>> actuals matching the formal generic parameters have to succeed, no
>> matter what's in the implementation of the generic.
>>
>> If that somehow isn't the case in the very newest version of the
>> standard, then the ARG has messed up, and I doubt that.
>
> See this one, which is the case that bit me recently:
>
> procedure Blah is
>
> generic
> type Something is private;
> package Duh is type Meh is new Something; end Duh;
>
> type Oh is tagged null record;
>
> package Ouch is new Duh (Oh);
>
> begin
>    null;
> end Blah;

This can be fixed by moving the derived type to the private part. (It's the 
case that causes all of those exceptional rules in the RM "This legality 
rule is also enforced in the private part" -- the rule for the derived type 
is the only known case where that boilerplate rule is *not* needed.)

                                   Randy.

Re: Ada Successor Language

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:fpcb15Fk3saU1@mid.individual.net...
...
> (In fact, it seems to me that Ada could allow untagged record extensions 
> as well; the effect would be the same as for tagged ones, but no 'Class 
> would be formed, and no class-wide programming or dynamic dispatch could 
> be used, so all such types would be static. It would be semantically 
> equivalent to aggregation of a component of the parent type with the 
> extension components, but would allow direct access to the inherited 
> components from the parent type. This could be a useful separation of 
> extensions from tags.)

Very early versions of Ada 9X included type extension on all composite 
types. I believe 'Class was allowed on all types. Eventually, that and many 
other things were dropped because the reviewers thought that the language 
design was too ambitious. Some of those other things have been resurfacing 
in later Ada versions - even now (Ada 2020 is adding aggregate iterators, an 
idea that was proposed and dropped from Ada 9X).

We haven't had any serious requests for reintroducing either type extension 
on untagged types nor 'Class on all types (random discussion here doesn't 
count - one needs real programming problems for a formal request).

                                          Randy.

Re: Ada Successor Language

[Randy Brukardt]

"Alejandro R. Mosteo" <alejandro@mosteo.com> wrote in message 
news:pgqtk8$avk$1@dont-email.me...
> On 25/06/2018 14:41, J-P. Rosen wrote:
...
>> The same derivation would not compile in the body of the generic, where
>> the worst is assumed
> GNAT 7.3/2018 does compile it if I move it to the private part or body, 
> which thus must be a bug, as hinted by that it allows taking the type's 
> 'Class...
>
> procedure Blah is
>
> generic
> type Something is private;
> package Duh is private type Meh is new Something;

-- This is legal, as I noted earlier. This is legal because there is no 
place where the type is both known to be tagged and known to be untagged. 
Inside this generic, the type is untagged.

> function Yes (M : Meh) return Boolean is (True);
> function Yes_Class (M : Meh'Class) return Boolean is (True);

-- This is *illegal*, Meh is not a tagged type. If GNAT is allowing this, it 
is a compiler bug.

> end Duh;
>
> type Oh is tagged null record;
>
> package Ouch is new Duh (Oh); -- This fails with non-tagged formal

This should work, assuming that the (illegal) 'Class is not included.

> begin
>    null;
> end Blah;

I suggest a GNAT bug report.

                            Randy.

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-29 21:46, Dan'l Miller wrote:
> On Friday, June 29, 2018 at 12:39:59 PM UTC-5, Dmitry A. Kazakov wrote:
>> On 2018-06-29 15:25, Dan'l Miller wrote:
>>> On Friday, June 29, 2018 at 2:20:40 AM UTC-5, Dmitry A. Kazakov wrote:
>>>> On 2018-06-29 05:11, Paul Rubin wrote:
>>>>> "Dan'l Miller" writes:
>>>>>> bad idea that threatens to bring C++ slicing to Ada
>>>>>
>>>>> Are you talking about this?
>>>>>
>>>>>       https://en.wikipedia.org/wiki/Object_slicing
>>>>>
>>>>> Does Ada somehow escape from it now?
>>>>
>>>> Sure, there is no way to reconstruct that in Ada.
>>>>
>>>>> It does sound bad.
>>>>
>>>> Only due to C++ design fault. Assignment is a classic multiple dispatch
>>>> operation (a multi-method). C++ per design does no support MD. Here you go.
>>>>
>>>> With MD it is no more an issue. Let T and S be two types T <: S. The
>>>> assignment operation of mixed arguments and result
>>>>
>>>>       ":=" : S x T -> S
>>>>
>>>> could not be safely inherited by S from T's:
>>>>
>>>>       ":=" : T x T -> T
>>>>
>>>> Therefore the compiler would ask the programmer to override it (or
>>>> redesign). Problem solved.
>>>
>>> Dmitry, you make it sound as though multiple •dispatch• would solve slicing in C++ (which has no
>>> dispatch whatsoever).
>>
>> I said nothing about •dispatch•! All types in question are statically known!
> 
> Dmitry, do you even read what you write?  In what you just wrote 12 hours ago above, the “classic multiple •dispatch•”, the “does no[t] support •MD•” where MD = multiple •dispatch•, the “compiler would ask the programmer to •override• it” via the OO tag/vtable mechanism, and the “••Problem solved••” all directly mention multiple •dispatch• and how MD is directly related to the remedy to maldesigns in user-provided assignment operators in your direct reply to slicing via C++ assignment.

You are confusing "multiple dispatch" as a property of an operation with 
[multiple] "dispatch" as an act of resolution of a call at run-time. The 
former in Ada terms means that an operation has multiple controlling 
arguments/results see RM 3.9.2 for the term "controlling".

If C++ had both arguments and the result of "=" controlling then the 
problem were resolved, regardless run-time dispatch involved or not.

Equivalently, if C++'s assignment "=" were in Ada terms a primitive 
operation of its type the problem were resolved.

In Ada terms C++'s "=" should have been declared as:

    function "=" (Left : in out T; Right : T) return T;

Since C++ has no MD, it is effectively declared, again in Ada terms, as:

    function "=" (Left : in out T; Right : T'Class) return T'Class;

This is a ticking bomb since C++ does not distinguish T and T'Class. As 
the result, "=" is contravariant in the second argument and the result. 
So goes a big boom, because contravariance is *unsafe* upon type extension.

[I am sorry explaining such trivial things]

> Turing test and uncanny valley come to mind.
> 
>>> In the situations where slicing occurs, it is due to the old backwards-compatibility-with-C functionality in C++.
>>
>> I care little of C++ design flaws. There are plenty and C++ is far
>> beyond the point where anything could be done to fix it. I argued that
>> this problem could never occur in Ada with its sane type system.
>>
>> The case constituting this bug in C++ is well present in Ada:
>>
>>      type T is tagged null record;
>>      function F return T;
>>
>>      type S is new T with record
>>         I : Integer;
>>      end record;
> 
> That is clearly not analogous to the vicinity where C++'s slicing occurs.

It clearly is. Inheriting F could lead to the situation when some fields 
of S were undefined, just like inheriting assignment does.

> ••Hypothetically•• in (not-this-timeline's-)Ada the analogous situation would be in the vicinity of:

[...]

None of the situations you mentioned could ever lead to the problem. 
There is absolutely no way to have such a thing in a strongly typed 
language. Whatever issues C++ has these are because of its weak typing.

P.S. Like with dispatch, you keep on confusing Ada subtyping with OO 
and/or LSP subtyping. These are different things sharing only the name. 
In no way Ada's subtyping can be exposed to a problem similar to C++.

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

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-29 22:17, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:pgd1hq$ca2$1@gioia.aioe.org...
> ...
>> 4. No proper reuse. Generic bodies are no proper compilation units, you
>> cannot have a shared library of generics. Therefore the only possible form
>> of reuse is textual substitution and recompilation of the client code.
> 
> Since Janus/Ada implements them exactly this way, this is demonstratably
> false. The lack of reuse in some implementations (i.e. GNAT) is an intended
> implementation decision, not a language requirement.

You must use some very special linker/loader then. Considering a generic 
package like:

    generic
       type T is private;
       with function Init return T;
    package P
       X : T := Init;
    end P;

the linker must magically multiply the object X for each instance of the 
package P and call Init for each of them, none of which it may know in 
advance.

>> 5. No proper separation of interface and implementation. If you used Ada
>> generics you would know that successful compilation of a generic body
>> means little. Instantiation can always fail even if all formal parameters
>> match. The compiler must look into the body not just for the sake of
>> optimization and representation, but for validity of instantiation, just
>> like in C++. A macro is a macro.
> 
> This is also False. Ada uses "assume-the-worst" rules such that any legal
> generic body is legal for any possible instantiation. There are *different*
> rules for the generic specification, and perhaps you are running afoul of
> those (those can cause failure of an instantiation). Or of compiler bugs
> causing compilation failures in instance bodies. Neither make the above
> true.

Maybe it was bugs. I simply do not know because it is so complicated 
that there is no way to tell. Usually it involves some name conflict in 
the body upon instantiation a child generic unit.

BTW, using different rules for specifications and bodies is indicative 
by itself.

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

Re: Ada Successor Language

[Dan'l Miller]

On Friday, June 29, 2018 at 4:36:22 PM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-06-29 21:46, Dan'l Miller wrote:
> > On Friday, June 29, 2018 at 12:39:59 PM UTC-5, Dmitry A. Kazakov wrote:
> >> On 2018-06-29 15:25, Dan'l Miller wrote:
> >>> On Friday, June 29, 2018 at 2:20:40 AM UTC-5, Dmitry A. Kazakov wrote:
> >>>> On 2018-06-29 05:11, Paul Rubin wrote:
> >>>>> "Dan'l Miller" writes:
> >>>>>> bad idea that threatens to bring C++ slicing to Ada
> >>>>>
> >>>>> Are you talking about this?
> >>>>>
> >>>>>       https://en.wikipedia.org/wiki/Object_slicing
> >>>>>
> >>>>> Does Ada somehow escape from it now?
> >>>>
> >>>> Sure, there is no way to reconstruct that in Ada.
> >>>>
> >>>>> It does sound bad.
> >>>>
> >>>> Only due to C++ design fault. Assignment is a classic multiple dispatch
> >>>> operation (a multi-method). C++ per design does no support MD. Here you go.
> >>>>
> >>>> With MD it is no more an issue. Let T and S be two types T <: S. The
> >>>> assignment operation of mixed arguments and result
> >>>>
> >>>>       ":=" : S x T -> S
> >>>>
> >>>> could not be safely inherited by S from T's:
> >>>>
> >>>>       ":=" : T x T -> T
> >>>>
> >>>> Therefore the compiler would ask the programmer to override it (or
> >>>> redesign). Problem solved.
> >>>
> >>> Dmitry, you make it sound as though multiple •dispatch• would solve slicing in C++ (which has no
> >>> dispatch whatsoever).
> >>
> >> I said nothing about •dispatch•! All types in question are statically known!
> > 
> > Dmitry, do you even read what you write?  In what you just wrote 12 hours ago above, the “classic multiple •dispatch•”, the “does no[t] support •MD•” where MD = multiple •dispatch•, the “compiler would ask the programmer to •override• it” via the OO tag/vtable mechanism, and the “••Problem solved••” all directly mention multiple •dispatch• and how MD is directly related to the remedy to maldesigns in user-provided assignment operators in your direct reply to slicing via C++ assignment.
> 
> You are confusing "multiple dispatch" as a property of an operation with 
> [multiple] "dispatch" as an act of resolution of a call at run-time. The 
> former in Ada terms means that an operation has multiple controlling 
> arguments/results see RM 3.9.2 for the term "controlling".
> 
> If C++ had both arguments and the result of "=" controlling then the 
> problem were resolved, regardless run-time dispatch involved or not.
> 
> Equivalently, if C++'s assignment "=" were in Ada terms a primitive 
> operation of its type the problem were resolved.
> 
> In Ada terms C++'s "=" should have been declared as:
> 
>     function "=" (Left : in out T; Right : T) return T;
> 
> Since C++ has no MD, it is effectively declared, again in Ada terms, as:
> 
>     function "=" (Left : in out T; Right : T'Class) return T'Class;
> 
> This is a ticking bomb since C++ does not distinguish T and T'Class. As 
> the result, "=" is contravariant in the second argument and the result. 
> So goes a big boom, because contravariance is *unsafe* upon type extension.
> 
> [I am sorry explaining such trivial things]
> 
> > Turing test and uncanny valley come to mind.
> > 
> >>> In the situations where slicing occurs, it is due to the old backwards-compatibility-with-C functionality in C++.
> >>
> >> I care little of C++ design flaws. There are plenty and C++ is far
> >> beyond the point where anything could be done to fix it. I argued that
> >> this problem could never occur in Ada with its sane type system.
> >>
> >> The case constituting this bug in C++ is well present in Ada:
> >>
> >>      type T is tagged null record;
> >>      function F return T;
> >>
> >>      type S is new T with record
> >>         I : Integer;
> >>      end record;
> > 
> > That is clearly not analogous to the vicinity where C++'s slicing occurs.
> 
> It clearly is. Inheriting F could lead to the situation when some fields 
> of S were undefined, just like inheriting assignment does.

No, you are factually incorrect.  As soon as you put the keyword tagged in the Ada code, the •directly corresponding• C++ code would have the keyword virtual on F.  And then slicing is impossible because no C-era semantics are evoked in combination with any other language feature.  Do you even read the prior content of this thread?

Re: Ada Successor Language

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:ph6aqs$1cj7$1@gioia.aioe.org...
> On 2018-06-29 22:17, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:pgd1hq$ca2$1@gioia.aioe.org...
>> ...
>>> 4. No proper reuse. Generic bodies are no proper compilation units, you
>>> cannot have a shared library of generics. Therefore the only possible 
>>> form
>>> of reuse is textual substitution and recompilation of the client code.
>>
>> Since Janus/Ada implements them exactly this way, this is demonstratably
>> false. The lack of reuse in some implementations (i.e. GNAT) is an 
>> intended
>> implementation decision, not a language requirement.
>
> You must use some very special linker/loader then. Considering a generic 
> package like:
>
>    generic
>       type T is private;
>       with function Init return T;
>    package P
>       X : T := Init;
>    end P;
>
> the linker must magically multiply the object X for each instance of the 
> package P and call Init for each of them, none of which it may know in 
> advance.

You've forgotten the magic of a level of indirection. :-) Every generic 
operation takes a (hidden) parameter that is a generic sharing block, and 
that includes all of the package-level data for the generic, information 
about the generic parameters, and more. The linker has nothing to do with 
it.

It's the sharing data and the level of indirection that it implies that 
makes generic sharing run slower than a macro approach.

>>> 5. No proper separation of interface and implementation. If you used Ada
>>> generics you would know that successful compilation of a generic body
>>> means little. Instantiation can always fail even if all formal 
>>> parameters
>>> match. The compiler must look into the body not just for the sake of
>>> optimization and representation, but for validity of instantiation, just
>>> like in C++. A macro is a macro.
>>
>> This is also False. Ada uses "assume-the-worst" rules such that any legal
>> generic body is legal for any possible instantiation. There are 
>> *different*
>> rules for the generic specification, and perhaps you are running afoul of
>> those (those can cause failure of an instantiation). Or of compiler bugs
>> causing compilation failures in instance bodies. Neither make the above
>> true.
>
> Maybe it was bugs. I simply do not know because it is so complicated that 
> there is no way to tell. Usually it involves some name conflict in the 
> body upon instantiation a child generic unit.

That's definitely a bug: the body is a separate name-space from a child.

> BTW, using different rules for specifications and bodies is indicative by 
> itself.

'twasn't my idea. I probably would have treated them the same, with more 
contracts in the formal part. But that would be clearly harder to use, so 
it's hard to be certain that it would be better. It surely would be easier 
to implement (there's some 60 rules that have to be re-enforced in an 
instantiation, all of which require special code in Janus/Ada. I see the 
appeal of GNAT's approach, but then they have to be able to *not* enforce 
those 60 rules in generic instance bodies. Doesn't sound a lot better. :-)

                                              Randy.

Re: Ada Successor Language

[Shark8]

On Friday, June 29, 2018 at 2:05:17 PM UTC-6, Randy Brukardt wrote:
> "Shark8" wrote in message 
> news:776f3645-ed0c-4118-9b4d-21660e3bba4b...
> ...
> >I'd honestly like the ability to use X'Type; this would allow us to say 
> >something like this:
> 
> Please forget that idea, it would be a terrible can of worms in Ada 
> semantics (or anything close to Ada sematics). See the write-up of 
> AI12-0123-1 (long killed) for some details as to why.

But we *are* talking about an Ada successor language; not Ada itself. This means a chance to change things out, breaking backwards compatibility, getting rid of things like anonymous accesses, defining a sensible interface.

So give some ideas that you've had that wouldn't be adopted by the ARG. Maybe some inspiration from some other language. Take macros for instance, most people don't like them because C/C++ has promulgated the "textual substitution" idea of macros, but LISP and BLISS both have pretty impressive macro facilities.

Re: Ada Successor Language

[Dmitry A. Kazakov]

On 2018-06-30 00:36, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:ph6aqs$1cj7$1@gioia.aioe.org...
>> On 2018-06-29 22:17, Randy Brukardt wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:pgd1hq$ca2$1@gioia.aioe.org...
>>> ...
>>>> 4. No proper reuse. Generic bodies are no proper compilation units, you
>>>> cannot have a shared library of generics. Therefore the only possible
>>>> form
>>>> of reuse is textual substitution and recompilation of the client code.
>>>
>>> Since Janus/Ada implements them exactly this way, this is demonstratably
>>> false. The lack of reuse in some implementations (i.e. GNAT) is an
>>> intended
>>> implementation decision, not a language requirement.
>>
>> You must use some very special linker/loader then. Considering a generic
>> package like:
>>
>>     generic
>>        type T is private;
>>        with function Init return T;
>>     package P
>>        X : T := Init;
>>     end P;
>>
>> the linker must magically multiply the object X for each instance of the
>> package P and call Init for each of them, none of which it may know in
>> advance.
> 
> You've forgotten the magic of a level of indirection. :-) Every generic
> operation takes a (hidden) parameter that is a generic sharing block, and
> that includes all of the package-level data for the generic, information
> about the generic parameters, and more. The linker has nothing to do with
> it.

OK, but that means precisely that the things you pass this way are not 
shared! You can share only parts of a generic unit, not everything.

> It's the sharing data and the level of indirection that it implies that
> makes generic sharing run slower than a macro approach.

Dispatch allows to formalize things being passed as a context of a call 
and binds these things to a type and an operation of. Same approach, but 
clean and well-defined.

> 'twasn't my idea. I probably would have treated them the same, with more
> contracts in the formal part. But that would be clearly harder to use, so
> it's hard to be certain that it would be better. It surely would be easier
> to implement (there's some 60 rules that have to be re-enforced in an
> instantiation, all of which require special code in Janus/Ada. I see the
> appeal of GNAT's approach, but then they have to be able to *not* enforce
> those 60 rules in generic instance bodies. Doesn't sound a lot better. :-)

It simply does not worth to invest limited resources into generics. That 
thing will never fly, IMO.

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

Re: Ada Successor Language

[Alejandro R. Mosteo]

On 29/06/2018 22:23, Randy Brukardt wrote:
> "Alejandro R. Mosteo" <alejandro@mosteo.com> wrote in message
> news:pgqas8$mjm$1@dont-email.me...
>> On 23/06/2018 21:21, Jacob Sparre Andersen wrote:
>>> Dmitry A. Kazakov wrote:
>>>
>>>> 5. No proper separation of interface and implementation. If you used
>>>> Ada generics you would know that successful compilation of a generic
>>>> body means little. Instantiation can always fail even if all formal
>>>> parameters match. The compiler must look into the body not just for
>>>> the sake of optimization and representation, but for validity of
>>>> instantiation, just like in C++. A macro is a macro.
>>>
>>> If the compilation of a generic succeeds, then any instantiation with
>>> actuals matching the formal generic parameters have to succeed, no
>>> matter what's in the implementation of the generic.
>>>
>>> If that somehow isn't the case in the very newest version of the
>>> standard, then the ARG has messed up, and I doubt that.
>>
>> See this one, which is the case that bit me recently:
>>
>> procedure Blah is
>>
>> generic
>> type Something is private;
>> package Duh is type Meh is new Something; end Duh;
>>
>> type Oh is tagged null record;
>>
>> package Ouch is new Duh (Oh);
>>
>> begin
>>     null;
>> end Blah;
> 
> This can be fixed by moving the derived type to the private part. (It's the
> case that causes all of those exceptional rules in the RM "This legality
> rule is also enforced in the private part" -- the rule for the derived type
> is the only known case where that boilerplate rule is *not* needed.)

First time I was caught unaware of this issue was with a generic whose 
purpose was to export the new type to clients. I no longer remember the 
specifics of how I got around that in the end.

Thanks,
Álex.

Re: Ada Successor Language

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:865f290f-65c1-4699-b8ae-28781428ba34@googlegroups.com...
On Friday, June 29, 2018 at 2:05:17 PM UTC-6, Randy Brukardt wrote:
> "Shark8" wrote in message
> news:776f3645-ed0c-4118-9b4d-21660e3bba4b...
> ...
>> >I'd honestly like the ability to use X'Type; this would allow us to say
>> >something like this:
>>
>> Please forget that idea, it would be a terrible can of worms in Ada
>> semantics (or anything close to Ada sematics). See the write-up of
>> AI12-0123-1 (long killed) for some details as to why.
>
>But we *are* talking about an Ada successor language; not Ada itself.
>This means a chance to change things out, breaking backwards
>compatibility, getting rid of things like anonymous accesses, defining a
>sensible interface.

I don't think it would work in any language with semantics reasonably close 
to Ada's type model. If you're blowing away Ada's type model, then it is no 
longer an Ada successor language, but just a new language.

                                         Randy.