What would you like in Ada202X?

[Martin]

Ok, we don't officially have Ada2012 yet but as no new features are going to be added to it, now seems like a good time to start thinking about the next revision.

My starters for 10 are:

1) 1st class functions / lambdas
2) parallel loops / functions
3) Multiple dispatch

-- Martin

[Yannick Duchêne (Hibou57)]

Hi, very good topic :-D

Le Wed, 25 Apr 2012 09:47:06 +0200, Martin <mar...@thedowies.com> a écrit:

> Ok, we don't officially have Ada2012

No, we still don't, as long as compiler support is… well, not perfect.

> yet but as no new features are going to be added to it, now seems like a
> good time to start thinking about the next revision.
>
> My starters for 10 are:
>
> 1) 1st class functions / lambdas
> 2) parallel loops / functions
> 3) Multiple dispatch
>
> -- Martin

Mine:

1) in/out specification at call place (as a recall, for explicitness, just
like named parameters are)
2) coroutine (well, resume next invocation at the place it previously
returned, with all locals preserved) (*)
3) SML signature‑like for package (ability to write a specification of
what minimal requirements other package have to specify at least)
4) constant as anonymous functions (just like enumeration items are) (**)
5) + the somethings I forget I will recall some later day.

Cheese! :-D

(*) You can fake it with task, but that cost a lot!

(**) May break backward compatibility? Actually, you can fake it using
function just returning always the same value, but that's source bloat and
that's ugly.

--
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

[stefan...@see-the.signature]

On Wed, 25 Apr 2012, Yannick Duchêne (Hibou57) wrote:

> 4) constant as anonymous functions (just like enumeration items are) (**)

What are you asking for, beyond what Ada 2012 already provides? With Ada
2012, you can write

function To_String(X: Integer) return String is ("don't know");

even in a package specification (then, To_String does not need an
implementation).


--
---- Stefan.Lucks (at) uni-weimar.de, University of Weimar, Germany ----
<http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
------ I love the taste of Cryptanalysis in the morning! ------

[Jacob Sparre Andersen]

Martin wrote:

> Ok, we don't officially have Ada2012 yet but as no new features are
> going to be added to it, now seems like a good time to start thinking
> about the next revision.

Did you listen to the discussion on the subject chaired by Robert Dewar
at FOSDEM?

Greetings,

Jacob
--
Beware of people with Gnus, they may Hurd you.

[Dmitry A. Kazakov]

On Wed, 25 Apr 2012 00:47:06 -0700 (PDT), Martin wrote:

> Ok, we don't officially have Ada2012 yet but as no new features are going
> to be added to it, now seems like a good time to start thinking about the
> next revision.
>
> My starters for 10 are:
>
> 1) 1st class functions / lambdas

Yep, proper procedural types to get rid of nasty access-to-procedure in
downward closures. No upward closures however.

Some set of operations to compose procedures, though the syntax for that is
unclear. I definitely do not want the mess typical for functional
languages.

> 2) parallel loops / functions

I don't think this is important.

But I do like to see some low-level primitives to support lock-free
concurrency, like atomic increment etc. The compiler would either use the
corresponding hardware operations or else generate a protected object if no
hardware support is there.

> 3) Multiple dispatch

Sure, but there is no working model of. The requirement is that dispatch
never fails at run-time (statically checked dispatching tables).

4) Full multiple inheritance.

5) Proper constructors and destructors (for all types), enforced,
exception-safe with roll-back.

6) Delegation, this is related to the position 1.

7) Classes for all types (including by-value types). Inheritance from all
types protected types and tasks included (one exception could be T'Class
another, maybe, the procedural types)

8) Interface inheritance from concrete types while dropping the
implementation.

9) "." (member), "in" (membership test), "'" (attribute), "(" (aggregate),
":=" made primitive operations.

10) Array index types to be a class. 1st class sets of indices (e.g.
ranges) and array subtypes (e.g. slices).

11) Package interfaces, transitive "use." I.e. an ability to make things
visible in some package visible in another without repeating all its with
and use clauses. And, of course, "use" should imply "with" where
applicable.

12) Renaming fixed. Renaming shall create no new objects. Renaming shall
respect array bounds. Renaming shall be available for types and subtypes.
Renamed entities shall never conflict with what they rename or themselves.

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

[Yannick Duchêne (Hibou57)]

Le Wed, 25 Apr 2012 10:36:09 +0200, Jacob Sparre Andersen <spa...@nbi.dk>
a écrit:

> Martin wrote:
>
>> Ok, we don't officially have Ada2012 yet but as no new features are
>> going to be added to it, now seems like a good time to start thinking
>> about the next revision.
>
> Did you listen to the discussion on the subject chaired by Robert Dewar
> at FOSDEM?

On my own side, I don't. What did he said?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 Apr 2012 10:36:41 +0200, Dmitry A. Kazakov
<mai...@dmitry-kazakov.de> a écrit:

> 11) Package interfaces, transitive "use." I.e. an ability to make things
> visible in some package visible in another without repeating all its with
> and use clauses. And, of course, "use" should imply "with" where
> applicable.

Why this one? (I agree with all, but this single one)

[leonid]

On Apr 25, 10:46 am, Yannick Duchêne (Hibou57)

May be it's a bad idea, but in accept statement and entry
why not write: accept ... with delay ...
and accept ... with delay until ...
it's a more simple then or alternative in select statement

[Georg Bauhaus]

My favorite change would start here:

0) Which features do you think can be dropped from Ada?


-Georg

[Martin]

Sorry, no didn't know about this...I'll check them at home tonight...
-- Martin

[Yannick Duchêne (Hibou57)]

Le Wed, 25 Apr 2012 11:09:22 +0200, Georg Bauhaus
<rm.dash...@futureapps.de> a écrit:

That's a good question, as it's a common wisdom to say its good there is
nothing more to remove.

I don't really see one. May be attributes is some cases? I/O attributes?

[Dmitry A. Kazakov]

On Wed, 25 Apr 2012 10:59:02 +0200, Yannick Duchêne (Hibou57) wrote:

> Le Wed, 25 Apr 2012 10:36:41 +0200, Dmitry A. Kazakov
> <mai...@dmitry-kazakov.de> a écrit:
>> 11) Package interfaces, transitive "use." I.e. an ability to make things
>> visible in some package visible in another without repeating all its with
>> and use clauses. And, of course, "use" should imply "with" where
>> applicable.
> Why this one? (I agree with all, but this single one)

Because Ada is a language for software engineering.

It was no problem back in 80s when a project had 10 or so units. It became
a huge problem now with thousands of units especially when generics are
used with instances of packages scattered all over the project. Typically
instances are bound by common parameters, e.g. the actual types used for
formal types. There is no way to put these related instances together in a
third package, make visible what you all need to, and then reuse the
result.

The most simple example is:

package P is
package Q is new Foo;
end P;

There is no means to flatten P making declarations of Q be directly visible
for clients of P. E.g. something like

package P is
package Q is new Foo (...);
use all Q; -- Make things from Q declared directly in P
end P;

Note that this is a next level of software developing. Instantiations of
some generics is just an implementation detail. The goal is to obtain a new
package of desired properties unconstrained by arbitrary details like
incidental names of instances They should not contaminate the result, e.g.

package P is
use all new Foo (...); -- I don't need the instance name
end P;

[Dmitry A. Kazakov]

On Wed, 25 Apr 2012 11:09:22 +0200, Georg Bauhaus wrote:

> 0) Which features do you think can be dropped from Ada?

-1) Dynamic pre-/postconditions
-2) Dynamic accessibility checks
-3) Limited-valued functions
-4) Limited aggregates
-5) if-operator
-6) Executable code in declarations

[Dmitry A. Kazakov]

13) Forgot the most important thing: contracted exceptions

[Yannick Duchêne (Hibou57)]

Le Wed, 25 Apr 2012 11:24:18 +0200, Dmitry A. Kazakov
<mai...@dmitry-kazakov.de> a écrit:

> The most simple example is:
>
> package P is
> package Q is new Foo;
> end P;
>
> There is no means to flatten P making declarations of Q be directly
> visible
> for clients of P. E.g. something like
>
> package P is
> package Q is new Foo (...);
> use all Q; -- Make things from Q declared directly in P
> end P;

Ok, I see, something like SML's “open” directive.

[Jacob Sparre Andersen]

Yannick Duchêne wrote:
> Le Wed, 25 Apr 2012 10:36:09 +0200, Jacob Sparre Andersen
> <spa...@nbi.dk> a écrit:

>> Did you listen to the discussion on the subject chaired by Robert
>> Dewar at FOSDEM?

> On my own side, I don't. What did he said?

I can't remember all the details (there is a recording on-line for
that), but one of his points was (as I understand it) that whatever we
add to Ada should either simplify it (if that is possible) or be a
"killer feature" for attracting new people to Ada.

One of the ideas discussed was to extend what you can control with
storage pools. (I've earlier argued for dereferencing being managed by
the storage pools. :-)

The full recording is here:

http://www.jacob-sparre.dk/recordings/fosdem-2012/

Greetings,

Jacob
--
"Those who profess to favor freedom and yet depreciate agitation, are
people who want crops without ploughing the ground; they want rain
without thunder and lightning; they want the ocean without the roar of
its waters." -- Frederick Douglas

[Georg Bauhaus]

On 25.04.12 09:47, Martin wrote:

> 2) parallel loops / functions

Array support in the direction of utilizing parallel
micro-micro-processing powers. Might require suitable

(array types,
array operators,
restrictions)

Array operands will make multimedia programming, or scientific
computing, or ..., more robust, simple, and more efficient
at the same time. Likewise, anything to do with linear algebra
can get rid of nested for loops, clever indexing schemes, etc
once there are types that can express, without resorting to
loops, that

Result := M * v;

Without resorting to loops, I'll mention that again. Computers
can work on a good mapping to hardware.

[Nicholas Paul Collin Gloucester]

I would like infinite precision; infinite accuracy; and infinite
speed. In practice, I may need to compromise on at least one of
those. If I resort to a compromise, then I would benefit from being
able to absolutely trivially have different executables of the same
source code which differ in their mathematical implementations (such
as one executable using fixed-point numbers and another executable
exploiting fractions to represent real numbers etc.). I can already
substitute one reification of an abstract datatype by another, but I
want this without any overhead.

[Marc C]

On Wednesday, April 25, 2012 4:09:22 AM UTC-5, Georg Bauhaus wrote:
> On 25.04.12 09:47, Martin wrote:
> > Ok, we don't officially have Ada2012 yet but as no new features are going to be added to it, now seems like a good time to start thinking about the next revision.
> >

> My favorite change would start here:
>
> 0) Which features do you think can be dropped from Ada?

- Stubs, i.e. "is separate".
- Distributed Annex

Marc A. Criley

[Georg Bauhaus]

Particularly interesting, since now Microsoft is popularizing
partial classes.

[Pascal Obry]

Marc,

> - Stubs, i.e. "is separate".
> - Distributed Annex

This last one is a joke, right?

I'm an happy user of the distributed annex and all other technologies
are so far away in term of usability and simplicity.

Pascal.

--

--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

[Yannick Duchêne (Hibou57)]

Le Wed, 25 Apr 2012 15:11:27 +0200, Marc C <mc.prov...@gmail.com> a
écrit:
> - Distributed Annex
Better Annex J: drop everything marked as obsolescent :-P

[björn lundin]

Den onsdagen den 25:e april 2012 kl. 15:11:27 UTC+2 skrev Marc C:
> - Stubs, i.e. "is separate".

That would totally break the system I work on.
We are heavily dependent on separates,,,

/Björn

[tmo...@acm.org]

> Array support in the direction of utilizing parallel

> micro-micro-processing powers. ... can get rid of nested for loops,

> clever indexing schemes, etc once there are types that can express,
> without resorting to loops, that
>
> Result := M * v;

It seems to me that overloaded operators, making library calls, are
better. In this age of rapidly evolving CPU architectures, the compiler
can't know the most efficient code to do a matrix multiplication on
all the different CPUs the code may run on, today and during the lifetime
of the program. So it's better to dynamically load a library routine.

[Lucretia]

Yup, removing separates would essentially cause Ada not to be able to handle cross platform apps in any easy way and would result in the need for a preprocessor - which at the moment can be handled with separates and different package bodies per platform.

Luke.

[okel...@users.sourceforge.net]

On Wednesday, April 25, 2012 9:47:06 AM UTC+2, Martin wrote:
> Ok, we don't officially have Ada2012 yet but as no new features are going
> to be added to it, now seems like a good time to start thinking about the
> next revision.

It's been said before but I'll say it again:
A "continue" statement for quick jump to end of loop body.

I've seen this worked around as follows:

loop
if Some_Condition then
goto Continue;
end if;
-- a couple 100 statements later ...
<<Continue>> null;
end loop;

-- Oliver

[Zhu Qun-Ying]

Arbitrary precision of integer and float numbers (in the sense of GMP,
MPFR).
Specifically to the GNAT case, as GCC include GMP and MPFR to compile
itself, it would be nice that gnat pickup this and have the build in
mechanism to handle arbitrary precision of numbers.

[Jeffrey Carter]

On 04/25/2012 02:09 AM, Georg Bauhaus wrote:
>
> 0) Which features do you think can be dropped from Ada?

Interfaces
Tagged types (but retaining finalization for record types)
Child packages with visibility of their ancestors

These would return Ada to its original vision as a language for programming by
composition.

--
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail
07

[Jeffrey Carter]

Compilers include unbounded-precision integer and floating-point libraries,
hash-table support, and support for an O(log N) searchable data structure. I'd
like these to be made available to those using the compilers.

Package types.

[Dmitry A. Kazakov]

On Wed, 25 Apr 2012 11:14:59 -0700, Jeffrey Carter wrote:

> On 04/25/2012 02:09 AM, Georg Bauhaus wrote:
>>
>> 0) Which features do you think can be dropped from Ada?
>
> Interfaces
> Tagged types (but retaining finalization for record types)
> Child packages with visibility of their ancestors
>
> These would return Ada to its original vision as a language for programming by
> composition.

by *procedural* [de]composition you mean.

tagged types = composition of types per inheritance
child packages = composition of packages

For the sake of purity you could also consider dropping record and array
types as they too involve some types composition. You would pass record
components and array elements as individual parameters to the procedures...

[Dmitry A. Kazakov]

On Wed, 25 Apr 2012 11:24:06 -0700, Jeffrey Carter wrote:

> Package types.

Formal generic package types or 1st class package types?

[Oliver Kleinke]

Greetings,

> 3) Multiple dispatch
>
> -- Martin

That will overcomplicate things. You'd end up with a truck load of
implementations.

> 4) Full multiple inheritance.

Same mess as in C++?

> 5) Proper constructors and destructors (for all types), enforced,
> exception-safe with roll-back.

Roll-back what? Side-effects?

> 11) Package interfaces, transitive "use." I.e. an ability to make things
> visible in some package visible in another without repeating all its with
> and use clauses. And, of course, "use" should imply "with" where
> applicable.

This is a bad, bad, bad idea. Would totally clutter everything and make
everything unreadable. I think the current system is already liberal
enough, and I like to restrict myself to localized 'use' clauses - if
any! - for the sake of readability.

> 13) Forgot the most important thing: contracted exceptions

There exists an interesting paper on that subject.[1]

> 0) Which features do you think can be dropped from Ada?

I don't think features _must_ be dropped, but Ada could certainly
benefit if there was a chance for competitive compilers to emerge.
Otherwise the segmentation will continue.
(While keeping backward compatibility in mind.)

>> 0) Which features do you think can be dropped from Ada?

> - Stubs, i.e. "is separate".

Subunits of compilation units are one of the most important features
when it comes to portability and modularization, you must be kidding.

> - Distributed Annex

Quote: "fuck you.. DSA is Ada's killer feature"

> Particularly interesting, since now Microsoft is popularizing
> partial classes.

partial classes are totally different from subunits. Partial classes are
needed for Microsoft's automated code-generation. Partial classes are
offensive in that they allow arbitrary extension of classes _anywhere_.

>> 2) parallel loops / functions

> Array support in the direction of utilizing parallel
> micro-micro-processing powers.

Already present in GNAT, implicitly though.

What I would like to see in the standard is a modifier for saturation
arithmetic that can be added to any scalar type definition. Right now
there is the option for a "[..] nonstandard real type [that] might have
an asymmetric or unsigned base range, or its predefined operations might
wrap around or “saturate” rather than overflow [..]" RM-3-5-6 (8)

ex.:
type Saturated is new saturated Integer range 0 .. 255;
-- or something similar.

This would be very easy to implement.

Cheers, Oliver

----
[1] - http://dl.acm.org/citation.cfm?id=357094.357100

[Adam Beneschan]

And why would having a "continue" statement be better than the workaround? If I'm looking at a loop like this, and I see a <<Continue>> label at the end, then I know that I can't count on the last however-many statements in the loop being executed before the loop loops back, because there's probably a branch to the label somewhere else in the loop. With a "continue" statement, I might be looking at the loop and going nuts trying to figure out "I know this loop is cycling back, and these last two statements should be executed before the end of the loop because they're not inside an IF statement, so they should be calling this routine, but it seems like it's not being called--why??" Trust me, I've had this exact experience. When I was programming in C I made the decision never to use this statement.

It appears to me that using "continue" makes things more difficult for the reader in order to gain the advantage of saving about sixteen keystrokes for the writer. I don't see any advantage in using this statement even in languages that support it, and I certainly don't see anything to be gained from adding it to Ada.

-- Adam

[Dmitry A. Kazakov]

On Wed, 25 Apr 2012 21:02:57 +0200, Oliver Kleinke wrote:

> Greetings,
>
>> 3) Multiple dispatch
>>
>> -- Martin
>
> That will overcomplicate things.

Nope, it will simplify things, e.g. user-defined assignments,
multi-methods, stream attributes, pool-specific access operations, which
are naturally multiple dispatching.

Note that Ada already has MD for multi-methods in a crippled form, because
you can declare a primitive operation with many dispatching arguments of
same type.

> You'd end up with a truck load of implementations.

So? This is what MD is meant to be: to organize and *statically* verify the
mess of multiple implementations.

>> 4) Full multiple inheritance.
>
> Same mess as in C++?

Nope. A properly designed MI. Ada was capable to sort out the OO mess for
single inheritance, there is no reason why it cannot continue with MI. Ada
2005 interfaces was a Java-mess. We should do MI in Ada way, clean and
consistent.

>> 5) Proper constructors and destructors (for all types), enforced,
>> exception-safe with roll-back.
>
> Roll-back what? Side-effects?

Destroying constructed component and parent objects.

>> 11) Package interfaces, transitive "use." I.e. an ability to make things
>> visible in some package visible in another without repeating all its with
>> and use clauses. And, of course, "use" should imply "with" where
>> applicable.
>
> This is a bad, bad, bad idea. Would totally clutter everything and make
> everything unreadable. I think the current system is already liberal
> enough, and I like to restrict myself to localized 'use' clauses - if
> any! - for the sake of readability.

I am not sure what you mean. Presently large projects using generics become
unmaintainable even with a massive support of the IDE like GPS and prefix
notation. Package interfaces should mow the jungle of packages, child
packages, nested packages and their instances to lawn.

[Adam Beneschan]

On Wednesday, April 25, 2012 1:01:48 AM UTC-7, Hibou57 (Yannick Duchêne) wrote:

> 1) in/out specification at call place (as a recall, for explicitness, just
> like named parameters are)

I'll second this one.

-- Adam

[okel...@users.sourceforge.net]

On Wednesday, April 25, 2012 9:15:13 PM UTC+2, Adam Beneschan wrote:
>
> And why would having a "continue" statement be better than the workaround?

Conciseness, plus avoidance of gratuitous "goto" (banned by various coding guidelines)

> [...] With a "continue" statement, I might be looking at the loop and going

> nuts trying to figure out "I know this loop is cycling back, and these last
> two statements should be executed before the end of the loop because they're
> not inside an IF statement, so they should be calling this routine, but it
> seems like it's not being called--why??"

I'm not sure what you mean.
For clarity, here's my previous example using the continue statement:

loop
if Some_Condition then
continue;
end if;
-- Or, yet more concisely,
continue when Another_Condition;
-- a couple 100 lines of code ...
end loop;

-- Oliver

[Jeffrey Carter]

On 04/25/2012 12:15 PM, Adam Beneschan wrote:
>
> And why would having a "continue" statement be better than the workaround?
> If I'm looking at a loop like this, and I see a<<Continue>> label at the
> end, then I know that I can't count on the last however-many statements in
> the loop being executed before the loop loops back, because there's probably
> a branch to the label somewhere else in the loop. With a "continue"
> statement, I might be looking at the loop and going nuts trying to figure out
> "I know this loop is cycling back, and these last two statements should be
> executed before the end of the loop because they're not inside an IF
> statement, so they should be calling this routine, but it seems like it's not
> being called--why??" Trust me, I've had this exact experience. When I was
> programming in C I made the decision never to use this statement.

I've never used such a statement or the go-to equivalent. There's always a
better way.

It's interesting to note that Ratfor has the "next" statement to do this, but in
321 pages in /Software Tools/, Kernighan and Plauger never use it.

--
Jeff Carter
"Ada has made you lazy and careless. You can write programs in C that
are just as safe by the simple application of super-human diligence."
E. Robert Tisdale
72

[Yannick Duchêne (Hibou57)]

Le Wed, 25 Apr 2012 19:36:47 +0200, Lucretia <lague...@googlemail.com>
a écrit:

Also chances are that people would sometime alter a package hierarchy just
to avoid too much long source files, or else to allow some
multi‑colleagues parallel works.

[Jeffrey Carter]

On 04/25/2012 01:12 PM, okel...@users.sourceforge.net wrote:
>
> continue when Another_Condition;

That reminds me:

return [expression] [when condition];
raise [exception-name [with String-expression]] [when condition];

[Adam Beneschan]

On Wednesday, April 25, 2012 1:12:28 PM UTC-7, okel...@users.sourceforge.net wrote:
> On Wednesday, April 25, 2012 9:15:13 PM UTC+2, Adam Beneschan wrote:
> >
> > And why would having a "continue" statement be better than the workaround?
>
> Conciseness, plus avoidance of gratuitous "goto" (banned by various coding guidelines)

This is the sort of thing that makes me want to cry. There's a reason "goto" is banned from some coding guidelines, and it's not because one day Dijkstra came down from a mountain with a slab that said "Thou shalt not use goto". It's banned because in most cases, using it negatively impacts readability and (as Jeff said) there's almost always a better way. I've tried to argue here that using "continue" is worse for readability than using a "goto" in this case--so if I'm right, it would make no sense to have coding guidelines that disallow "goto" and allow "continue". Of course, if you're able to argue that the "continue" is more readable in this case, please do so. But I suspect that's not possible if ...

> > [...] With a "continue" statement, I might be looking at the loop and going
> > nuts trying to figure out "I know this loop is cycling back, and these last
> > two statements should be executed before the end of the loop because they're
> > not inside an IF statement, so they should be calling this routine, but it
> > seems like it's not being called--why??"
>
> I'm not sure what you mean.

... the entire issue of readability is beyond your understanding.

-- Adam

[Georg Bauhaus]

On 25.04.12 21:02, Oliver Kleinke wrote:

> partial classes are totally different from subunits.

Well, partially different from subunits, at least from a less
technical point of view on structuring source ;-)

>>> 2) parallel loops / functions
>> Array support in the direction of utilizing parallel
>> micro-micro-processing powers.
>
> Already present in GNAT, implicitly though.

Where, please? I'm very curious, since what we have found to be working is
either tied to GCC's type attributes, or seems to be caused by the compiler
working in miraculous ways: small arrays/sequences of floats can be,
or may be, made operands of SIMD instructions on Intel compatible
hardware. Tricky, and hard to control, yet worth a factor 2.

[Yannick Duchêne (Hibou57)]

Le Wed, 25 Apr 2012 20:14:59 +0200, Jeffrey Carter
<spam.jrc...@spam.not.acm.org> a écrit:

> On 04/25/2012 02:09 AM, Georg Bauhaus wrote:
>>
>> 0) Which features do you think can be dropped from Ada?
>
> Interfaces
> Tagged types (but retaining finalization for record types)

Less radical, I was wondering about some redundancies between both.

> Child packages with visibility of their ancestors
>
> These would return Ada to its original vision as a language for
> programming by composition.

You mean visibility of the ancestor's private part to the child package,
is that it?

Programming by composition welcome means to express worlds and domains
with shared internal secrets. On the other hand, package are king of
structure, and Ada's tagged type does not provide visibility of the
internals of one's ancestor. On the third hand (alien talking here),
tagged types don't have this, precisely because it's provided by package
hierarchy.

Imagine a simple case: a serialization of some private object type, with
multiple codecs. I instinctively make each codecs, a child package of the
package defining the serialized type, so that they can build an instance
of type. Or else, you would have to expose to the big world, methods
intended for serialization only, and serialization is often related to the
internal representation of the serialized item (although not required).
Can't give an easy example, but I also believe this would make some
bindings more difficult.

I feel to anticipate removing child package with visibility to their
ancestor's private part, would force people to expose too much in their
specifications, or worst, to fake this feature using export/import behind
the scene.

But I may be wrong, and will more deeply think this case later. I'm so
much made to this, and can't easily think without it. For the time, I have
some personal pending stuff to do a later day, with 5 levels of child
package all with visibility to their parent's privates :-P .

[Yannick Duchêne (Hibou57)]

Le Wed, 25 Apr 2012 20:07:15 +0200, <okel...@users.sourceforge.net> a
écrit:

What about

loop
if Some_Condition then
goto Continue;

else

-- a couple 100 statements later ...

end if;
end loop;

?

Also be aware of a very likely infinite loop with this example :-P .

[Yannick Duchêne (Hibou57)]

Le Wed, 25 Apr 2012 22:26:49 +0200, Jeffrey Carter
<spam.jrc...@spam.not.acm.org> a écrit:

> On 04/25/2012 01:12 PM, okel...@users.sourceforge.net wrote:
>>
>> continue when Another_Condition;
>
> That reminds me:
>
> return [expression] [when condition];
> raise [exception-name [with String-expression]] [when condition];

Two more candidates for the drop‑party?

[Martin Dowie]

Jeffrey Carter <spam.jrc...@spam.not.acm.org> wrote:
> On 04/25/2012 01:12 PM, okel...@users.sourceforge.net wrote:
>>
>> continue when Another_Condition;
>
> That reminds me:
>
> return [expression] [when condition];
> raise [exception-name [with String-expression]] [when condition];

+1

Syntactic sugar but nice...

-- Martin


--
-- Sent from my iPad

[Jeffrey Carter]

On 04/25/2012 01:53 PM, Yannick Duchêne (Hibou57) wrote:
>
> You mean visibility of the ancestor's private part to the child package, is that
> it?

I mean all visibility of its ancestors. Package hierarchies should be for
namespace control only.

>
> Imagine a simple case: a serialization of some private object type, with
> multiple codecs. I instinctively make each codecs, a child package of the
> package defining the serialized type, so that they can build an instance of
> type. Or else, you would have to expose to the big world, methods intended for
> serialization only, and serialization is often related to the internal
> representation of the serialized item (although not required). Can't give an
> easy example, but I also believe this would make some bindings more difficult.

Imagine a simple solution: a collection of private packages that implement the
type and its operations, and a public package that makes public only those
things that should be public.

Another thing I'd like to see removed: anonymous types.

[Yannick Duchêne (Hibou57)]

Le Wed, 25 Apr 2012 21:02:57 +0200, Oliver Kleinke
<oliver....@c-01a.de> a écrit:

>> Particularly interesting, since now Microsoft is popularizing
>> partial classes.
>
> partial classes are totally different from subunits. Partial classes are
> needed for Microsoft's automated code-generation. Partial classes are
> offensive in that they allow arbitrary extension of classes _anywhere_.

What that mean? Kind of Aspect Programming?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 Apr 2012 23:14:51 +0200, Jeffrey Carter
<spam.jrc...@spam.not.acm.org> a écrit:

> Another thing I'd like to see removed: anonymous types.

This one is easy to have right now: use a kind of profile, with the aid of
AdaControl.

[Yannick Duchêne (Hibou57)]

Le Wed, 25 Apr 2012 23:14:51 +0200, Jeffrey Carter
<spam.jrc...@spam.not.acm.org> a écrit:

>> Imagine a simple case: a serialization of some private object type, with
>> multiple codecs. I instinctively make each codecs, a child package of
>> the
>> package defining the serialized type, so that they can build an
>> instance of
>> type. Or else, you would have to expose to the big world, methods
>> intended for
>> serialization only, and serialization is often related to the internal
>> representation of the serialized item (although not required). Can't
>> give an
>> easy example, but I also believe this would make some bindings more
>> difficult.
>
> Imagine a simple solution: a collection of private packages that
> implement the type and its operations, and a public package that makes
> public only those things that should be public.

And you have to modify and respecify the package each time you want to
extend it? The child package way is more modular.

[okel...@users.sourceforge.net]

On Wednesday, April 25, 2012 10:40:01 PM UTC+2, Adam Beneschan wrote:
> > >
> [...] I've tried to argue here that using "continue" is worse for
> readability than using a "goto" in this case-- [...]

In which case?
Looking again at your previous posting,

>
> > > [...] With a "continue" statement, I might be looking at the loop and going
> > > nuts trying to figure out "I know this loop is cycling back, and these last
> > > two statements should be executed before the end of the loop because they're
> > > not inside an IF statement, so they should be calling this routine, but it
> > > seems like it's not being called--why??"
> >

I have difficulty visualizing the code you intend here.
Do you mean something like,

loop
if Condition then
goto Almost_Done;
end if;
-- ... many lines of loop body ...
<<Almost_Done>>
Do_Something;
end loop;

?

At any rate, having heard Robert Dewar's FOSDEM talk ("every new feature damages the language") I will easily renounce my wish...

-- Oliver

[Georg Bauhaus]

On 25.04.12 23:11, Martin Dowie wrote:
> Jeffrey Carter<spam.jrc...@spam.not.acm.org> wrote:
>> On 04/25/2012 01:12 PM, okel...@users.sourceforge.net wrote:
>>>
>>> continue when Another_Condition;
>>
>> That reminds me:
>>
>> return [expression] [when condition];
>> raise [exception-name [with String-expression]] [when condition];
>
> +1
>
> Syntactic sugar but nice...

Dentists, rejoice!

N := 5;
return 10 * N + Func (N) when Proc_in_out (N) > 5;

case N is
when 1 =>
return 0 when N > 3;
when 2 =>
...
end case;

case Boolean'(V) is
when True =>
return X when X = True;
when False =>
return When True;
end case;

Also, imagine a few line breaks that Perl programmers would write.
They have return [expression] [if expression] and write

$foo = something($bar);
return $foo + frobnicte($bar + $something) # No ';' here!
if $bar > 0;
continuing();

This all becomes very dependent on single ';'s. You can see it when you
feed the above future Ada text to Ada compilers :-)

[ytomino]

Delphi(or C#)'s method resolution clauses.

Java-style interface introduced in Ada2005 makes primitive names to
global.
Method resolution clause restore them to local.

type I1 is interface;
procedure X (Obj : I1);
type I2 is interface;
procedure X (Obj : I2);

type T is new I1 and I2;
procedure X (Obj : T); -- conflicted!!!

If method resolution clause exists:

type T is new I1 and I2;
overriding(I1.X) procedure X1 (Obj : T);
overriding(I2.X) procedure X2 (Obj : T);

X(I1(Obj)); -- calls X1
X(I2(Obj)); -- calls X2

[Shark8]

On Wednesday, April 25, 2012 2:47:06 AM UTC-5, Martin wrote:
> 2) parallel loops / functions

This could already be done with a implementation-specific pragma, applied to a named loop; no?

Granted, it's not in-the-language, but it sounds like exactly the sort of thing that implementation-specific pragmas should be used for: tweaking code generation. (And this format would comply by not altering the legality of the program.)

> 3) Multiple dispatch

Listening to Dmitri talk on this, I think that subject needs a lot of thought put into it BEFORE putting it into the language. Especially because you get M*N operations {where M and N are the number of objects in a Type'Class, and may increase because of further inheritance}... and that's only with two base-classes.

[Jeffrey Carter]

On 04/25/2012 02:30 PM, Yannick Duchêne (Hibou57) wrote:
>
> And you have to modify and respecify the package each time you want to extend
> it? The child package way is more modular.

Ada emphasizes ease of reading over ease of writing (this is and always has been
an explicit design goal stated at the beginning of the ARM); programming by
extension (and your comment) emphasizes ease of writing over ease of reading.
This is why I've always objected to including programming-by-extension features
in Ada.

[Adam Beneschan]

On Wednesday, April 25, 2012 3:05:48 PM UTC-7, okel...@users.sourceforge.net wrote:
> On Wednesday, April 25, 2012 10:40:01 PM UTC+2, Adam Beneschan wrote:
> > > >
> > [...] I've tried to argue here that using "continue" is worse for
> > readability than using a "goto" in this case-- [...]
>
> In which case?

If you write this:

loop
-- several hundred lines of code
Do_This_Action;
end loop;

If I'm looking at the code, and I look at just the bottom part, it's obvious that Do_This_Action will always be called before the loop loops back. If I'm maintaining the code, and I want to add something else that will always be called before the loop cycles back, I can add a statement after Do_This_Action, and I know it will work.

If "continue" is added to the language, this inference is no longer true. Now it raises the possibility that I can add a statement after Do_This_Action, expecting it will always be executed at the end of the loop, but that expectation will be wrong if somewhere, in the hundreds of lines of code, you've stuck a "continue" statement. So that increases the probability of error.

If you've used a goto, however, the end of the loop will look like:

loop
-- several hundred lines of code
Do_This_Action;
<<Continue_Here>>
null;
end loop;

Now I'm aware that if I want to add something that will always be executed in the loop, I need to be careful to make sure I add it at the right place (either after or before the Continue_Here label), and I'll need to study the logic a bit more to make sure I get it right. But the label alerts me to that need. So it's less error-prone. This isn't just a theoretical argument; it's based on what's actually happened, in my experience.

Of course, if there are just a few lines of code, it's easier to figure out what the code is doing and easier to modify it correctly. And I think that in your original example, where you said there would be a couple hundred statements in your loop, that's the real problem. If you have that much code in your loop, chances are you should be putting a lot of it into a subroutine(s). But if your loop is smaller, there's less need to have a "continue" or "goto" statement anyway.

I suppose this is a YMMV matter; maybe other programmers wouldn't have as much trouble reading and maintaining this kind of code. But since it's definitely something that caused me problems, I wanted to make sure I mentioned it. And I'm still skeptical of any coding standard that bans "goto" but not "continue"; I'd suspect that the person who came up with that standard did so because they heard somewhere that goto was evil, demonic, and fattening, not for any rational reason.

-- Adam

[Yannick Duchêne (Hibou57)]

The above may still present issues with overloading. Imagine X exist with
multiple signatures, for both I1 and I2: as your proposal does not refer
the precise signature, this would still be ambiguous.

I did not checked, but I feel there already is a way to avoid this
ambiguity, using a renaming for the different Xs, prior to the definition
of T.

[Yannick Duchêne (Hibou57)]

Le Thu, 26 Apr 2012 00:30:38 +0200, Shark8 <onewing...@gmail.com> a
écrit:

> On Wednesday, April 25, 2012 2:47:06 AM UTC-5, Martin wrote:
>> 2) parallel loops / functions
>
> This could already be done with a implementation-specific pragma,
> applied to a named loop; no?
>
> Granted, it's not in-the-language, but it sounds like exactly the sort
> of thing that implementation-specific pragmas should be used for:
> tweaking code generation. (And this format would comply by not altering
> the legality of the program.)

That's a good idea, and I was also wondering if my wish for coroutines,
could alternatively be reformulated as a wish for a pragma applying to
task types. There too, this would not alter the program's semantic, if
ever the pragma was not handled.

[Yannick Duchêne (Hibou57)]

Le Thu, 26 Apr 2012 00:33:11 +0200, Jeffrey Carter
<spam.jrc...@spam.not.acm.org> a écrit:

> On 04/25/2012 02:30 PM, Yannick Duchêne (Hibou57) wrote:
>>
>> And you have to modify and respecify the package each time you want to
>> extend
>> it? The child package way is more modular.
>
> Ada emphasizes ease of reading over ease of writing (this is and always
> has been an explicit design goal stated at the beginning of the ARM);
> programming by extension (and your comment) emphasizes ease of writing
> over ease of reading. This is why I've always objected to including
> programming-by-extension features in Ada.

Child package are not less readable, as all kind of modularity ease
understanding, be it either child packages or nested packages. However,
there is another less mentioned — while as much important — requirement of
Ada, which is project and source management (thus the “is separate”). And
child packages ease project management, for the reason I gave. Also, child
packages allows for optional additions or various alternatives for a given
addition, by means of project configuration: just remove the path to a set
of child packages source and specs, to remove it from a project. With
nested package, you have to modify the package each time.

Getting ride of child packages (as back to Ada 83), would promise
nightmares for many ones.

[Jeffrey Carter]

On 04/25/2012 05:50 PM, Yannick Duchêne (Hibou57) wrote:
>
> Child package are not less readable, as all kind of modularity ease
> understanding, be it either child packages or nested packages. However, there is
> another less mentioned — while as much important — requirement of Ada, which is
> project and source management (thus the “is separate”). And child packages ease
> project management, for the reason I gave. Also, child packages allows for
> optional additions or various alternatives for a given addition, by means of
> project configuration: just remove the path to a set of child packages source
> and specs, to remove it from a project. With nested package, you have to modify
> the package each time.

I'm not suggesting getting rid of child packages; I'm suggesting not allowing
them to *extend* their ancestors (and all other forms of programming by extension).

> Getting ride of child packages (as back to Ada 83), would promise nightmares for
> many ones.

As I said, I'm not suggesting getting rid of child packages. But it's important
to remember that Ada 83 is a good language. It was a very good language for its
time; compared to most languages in use today, it's still a good language.

[Brad Moore]

On 25/04/2012 5:13 PM, Adam Beneschan wrote:

> If you've used a goto, however, the end of the loop will look like:
>
> loop
> -- several hundred lines of code
> Do_This_Action;
> <<Continue_Here>>
> null;
> end loop;
>

Note: Ada 2012 has made a minor improvement in this area.
The null statement is no longer needed, so you can write this as;

loop
-- many lines of code

goto Continue;

-- many more lines of code

<<Continue>>
end loop;

-- Brad

[Randy Brukardt]

"Jacob Sparre Andersen" <spa...@nbi.dk> wrote in message
news:87sjfsa...@adaheads.sparre-andersen.dk...
...
> One of the ideas discussed was to extend what you can control with
> storage pools. (I've earlier argued for dereferencing being managed by
> the storage pools. :-)

We tried that for Ada 2012 (see AI05-0141-1) [truth-in-advertising: this was
almost completely my idea]. We worked on it for a while, but some corners
are pretty messy (especially the conversion rules), there was problems with
distributed overhead (often, it's necessary to do these things for all
storage pools, whether or not they use the facility) and eventually we
decided that a high-level solution (user-defined references, 4.1.5 in the
Ada 2012 standard) was better.

Which leads to my question: what can you do with this that you can't do with
the user-defined reference facility? After all, all you need to do to get
user-defined *de*references is to create a "managed pointer" type that
provides appropriate user-defined references. (I believe Christoph Grein has
or soon will make an Ada 2012 version of his managed pointer packages that
illustrates how its done.)

After all, anything that encourages people to get explicit access types out
of their visible specifications is a good thing. (Using access types when
unnecessary should get people fifty lashes with a wet noodle. :-)

Randy.

[Randy Brukardt]

"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message
news:mdgi0fhwon01$.18b871w98pjl6.dlg@40tude.net...
...
> There is no means to flatten P making declarations of Q be directly
> visible
> for clients of P. E.g. something like
>
> package P is
> package Q is new Foo (...);
> use all Q; -- Make things from Q declared directly in P
> end P;

We tried to do this for Ada 2012; we made heroic efforts to do so. The
problem is, this feature is a massive potential maintenance problem which
destroys most of the Ada concepts of visibility and maintainablity. (It's
all of the mistakes of package "use" multiplied a hundred-fold.)

The biggest problem comes when there is a conflict between things declared
in P and things declared in Q. Resolving that proved impossible without
introducing major headaches.

In the end, we abandoned it as just being too complex. That's too bad,
because it *seems* important.

Some of the attempts can be found in AI05-0135-1 and AI05-0135-2.

I'd like to think that we explored every possible solution, and none of them
work. Perhaps someone can find a solution that we didn't explore, but in the
absence of that, I don't see a feature like this ever flying in Ada.

Randy.

[Randy Brukardt]

"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message

news:1xll47vz9nd7t.1...@40tude.net...
...
> 13) Forgot the most important thing: contracted exceptions

I'm in your corner on that; AI12-0017-1 is my initial proposal in that area.
(But please keep in mind it will be a while before we seriously start
looking at future Ada features - this AI is meant mainly to ensure that it's
on the agenda when that happens.)

Randy.

[Randy Brukardt]

"Georg Bauhaus" <rm.dash...@futureapps.de> wrote in message
news:4f97bf40$0$6559$9b4e...@newsspool4.arcor-online.net...
> On 25.04.12 09:47, Martin wrote:
...
> My favorite change would start here:

>
> 0) Which features do you think can be dropped from Ada?

Of course, practically, we can't drop anything because of compability
concerns. The most we can do is banish things to Annex J.

I'd probably start with:

(1) Co-extensions (and more generally, allocators for anonymous access
types). [I'd like to get rid of all anonymous types period, but that
probably is going to far.];

(2) Generic in-out object parameters (almost never used, hard to implement,
probably buggy because of the first two);

(3) Interfaces (buys almost nothing over abstract types, except a huge
amount of complication in definition and implementation);

(4) Accessibility checking - both static and dynamic (finds 1 real error for
every hundred reported - I've only once in more than 15 years been able to
use 'Access on an object successfully). On top of that, the rules are
complex and need huge efforts to maintain: clause 3.10.2 is known in the ARG
as the "heart of darkness". And on top of that, it's not ever clear that the
Ada 2005 rules as corrected are actually implementable (we have an open AI
on that).

Randy.

[Randy Brukardt]

<okel...@users.sourceforge.net> wrote in message
news:31103380.3735.1335377235157.JavaMail.geo-discussion-forums@vbuo17...

> On Wednesday, April 25, 2012 9:47:06 AM UTC+2, Martin wrote:
>> Ok, we don't officially have Ada2012 yet but as no new features are going
>> to be added to it, now seems like a good time to start thinking about the
>> next revision.
>
> It's been said before but I'll say it again:
> A "continue" statement for quick jump to end of loop body.

We had this discussion in the context of Ada 2012, and...

> I've seen this worked around as follows:

It's not a "work-around". It's how it's done in Ada. The Ada standard is not
in the business of catering to those who have clueless programming style
guides (or the clueless management that emposed them).

Note that there are at least as many people that do not want additional ways
to transfer control (they think there are too many as it is). The e-mail in
AI05-0179-1 gives some insight into this.

> loop
> if Some_Condition then
> goto Continue;
> end if;
> -- a couple 100 statements later ...
> <<Continue>> null;
> end loop;

The "null;" is not needed here in Ada 2012 (as it is just noise here); a
label goes between statements including at the begining and end. (Earlier
versions of Ada required a label to be on a statement, which lead to the
useless "null".)

loop
if Some_Condition then
goto Continue;
end if;
-- a couple 100 statements later ...
<<Continue>>

end loop;

Randy.

[Randy Brukardt]

"Georg Bauhaus" <rm.dash...@futureapps.de> wrote in message

news:4f98781c$0$6557$9b4e...@newsspool4.arcor-online.net...
...

> Also, imagine a few line breaks that Perl programmers would write.
> They have return [expression] [if expression] and write
>
> $foo = something($bar);
> return $foo + frobnicte($bar + $something) # No ';' here!
> if $bar > 0;
> continuing();
>
> This all becomes very dependent on single ';'s. You can see it when you
> feed the above future Ada text to Ada compilers :-)

Ada requires parens around conditional expressions for this very reason. You
still have get into circumstances where the compiler can't tell if a paren
or ; is missing, but it is never legal without one of them.

Randy.

[Randy Brukardt]

"Adam Beneschan" <ad...@irvine.com> wrote in message
news:18684452.720.1335395636464.JavaMail.geo-discussion-forums@yncc41...
...

>I suppose this is a YMMV matter; maybe other programmers wouldn't have as
>much trouble
> reading and maintaining this kind of code. But since it's definitely
> something that caused me
> problems, I wanted to make sure I mentioned it. And I'm still skeptical
> of any coding standard
> that bans "goto" but not "continue"; I'd suspect that the person who came
> up with that standard
> did so because they heard somewhere that goto was evil, demonic, and
> fattening, not for any
> rational reason.

We made a concious decision to ignore arguments about coding standards
(clueless or not), because many of those rules are based on misinformation
(or out-of-date information -- something I will say probably happens to me
from time-to-time). We do, however, care about programmer expectations
(which is why there is no "continue", why we added conditional expressions
rather than an "implies" operator, and so on).

And thanks for the clear explanation of why this is a bad idea (I think
yours was clearer than any we had when we rejected the idea).

Randy.

[Randy Brukardt]

"Yannick Duchêne (Hibou57)" <yannick...@yahoo.fr> wrote in message
news:op.wdcj0snyule2fv@douda-yannick...
...

>> If method resolution clause exists:
>>
>> type T is new I1 and I2;
>> overriding(I1.X) procedure X1 (Obj : T);
>> overriding(I2.X) procedure X2 (Obj : T);
>
>The above may still present issues with overloading. Imagine X exist with
>multiple signatures, for both I1 and I2: as your proposal does not refer
>the precise signature, this would still be ambiguous.

Right; simple names are never enough. You always need the full profile, else
you still have holes. Those holes were bad enough for pragmas that we dumped
the entire mess and invented aspect specifications for Ada 2012.

We actually considered something like this for Ada 2005, but decided it just
goes too far. In part, that's because having such a problem suggests bad
design somewhere: it should never be the case that you have two routines
with the same name and profile that have different meanings. That's abusing
overloading; the problem can't be detected by a compiler - I think if it
could have been, it would have been illegal from the start. (The Ada 83
rationale explains the inclusion of overloading by saying that the fact that
a feature can be abused is not by itself a reason to exclude it from the
language.)

Ada provides tools (renaming, mostly) to deal with such broken situations,
so one could argue that we could add more tools. But I personally see no
reason to spend more effort on a bad idea (interfaces); they exist mainly to
make some misguided people happy.

Randy.

[ytomino]

On Thursday, April 26, 2012 9:37:30 AM UTC+9, Hibou57 (Yannick Duchêne) wrote:
>
> The above may still present issues with overloading. Imagine X exist with
> multiple signatures, for both I1 and I2: as your proposal does not refer
> the precise signature, this would still be ambiguous.

Really?
I think, compiler can select one of overloaded functions by other parameters.

procedure X (Obj : I1);
procedure X (Obj : I1; Y : Integer);
procedure X (Obj : I2; Y : Integer); -- *1
procedure X (Obj : I2; Y : String);

overriding (I2.X) procedure X3 (Obj : T; Y : Integer);

Unquestionably, X3 is overriding *1.

> I did not checked, but I feel there already is a way to avoid this
> ambiguity, using a renaming for the different Xs, prior to the definition
> of T.
>

Probably, I feel that renaming introduces new primitive, and old name may stay.

[Mart van de Wege]

Adam Beneschan <ad...@irvine.com> writes:

> On Wednesday, April 25, 2012 1:12:28 PM UTC-7,
> okel...@users.sourceforge.net wrote:
>> On Wednesday, April 25, 2012 9:15:13 PM UTC+2, Adam Beneschan wrote:
>> > And why would having a "continue" statement be better than the
>> > workaround?
>> Conciseness, plus avoidance of gratuitous "goto" (banned by various
>> coding guidelines)
>
> This is the sort of thing that makes me want to cry. There's a reason
> "goto" is banned from some coding guidelines, and it's not because one
> day Dijkstra came down from a mountain with a slab that said "Thou
> shalt not use goto". It's banned because in most cases, using it
> negatively impacts readability and (as Jeff said) there's almost
> always a better way. I've tried to argue here that using "continue"
> is worse for readability than using a "goto" in this case--so if I'm
> right, it would make no sense to have coding guidelines that disallow
> "goto" and allow "continue". Of course, if you're able to argue that
> the "continue" is more readable in this case, please do so. But I
> suspect that's not possible if ...
>
Hmm.

I like the Perl use of 'next' and 'last' to influence looping.

Especially when looping over a list of values, it is nice to test for
values you don't want to process at the start of the loop, and
immediately go to the next iteration.

The canonical example is processing a file with comment lines starting
with '#':

while (<$file>) {
next if /^#/; # skip comment lines
[...Do stuff with line ...]
}

Now, this is a lot clearer, and IMO a lot more elegant, than putting a
label on the end of the loop and use 'goto label'.

Although it *is* considered good practice to put your 'next' statements
at the top of the loop to make clear on what conditions the main body
will be skipped. 'next' statements littered throughout the body of the
loop are frowned upon.

Mart

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

[Oliver Kleinke]

>>>> 2) parallel loops / functions

>>> Array support in the direction of utilizing parallel
>>> micro-micro-processing powers.
>>
>> Already present in GNAT, implicitly though.
>
> Where, please? I'm very curious, since what we have found to be working is
> either tied to GCC's type attributes, or seems to be caused by the compiler
> working in miraculous ways: small arrays/sequences of floats can be,
> or may be, made operands of SIMD instructions on Intel compatible
> hardware. Tricky, and hard to control, yet worth a factor 2.

Have you discovered this yet?:
http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Vectorization-of-loops.html

[Oliver Kleinke]

Am 25.04.2012 23:17, schrieb Yannick Duchêne (Hibou57):
> Le Wed, 25 Apr 2012 21:02:57 +0200, Oliver Kleinke
> <oliver....@c-01a.de> a écrit:
>>> Particularly interesting, since now Microsoft is popularizing
>>> partial classes.
>>
>> partial classes are totally different from subunits. Partial classes
>> are needed for Microsoft's automated code-generation. Partial classes
>> are offensive in that they allow arbitrary extension of classes
>> _anywhere_.
>
> What that mean? Kind of Aspect Programming?

Partial classes allow you to split the class definition over multiple
files. Subunits impose a certain restriction in that 1) every subunit
has to be announced (with 'is separate') and 2) can be defined only
once, with one body. Partial classes however, allow you to define any
member functions and attributes you like in an arbitrary number of files.

[Dmitry A. Kazakov]

On Wed, 25 Apr 2012 21:23:37 -0500, Randy Brukardt wrote:

> "Georg Bauhaus" <rm.dash...@futureapps.de> wrote in message
> news:4f97bf40$0$6559$9b4e...@newsspool4.arcor-online.net...
>> On 25.04.12 09:47, Martin wrote:
> ...
>> My favorite change would start here:
>>
>> 0) Which features do you think can be dropped from Ada?
>
> Of course, practically, we can't drop anything because of compability
> concerns. The most we can do is banish things to Annex J.
>
> I'd probably start with:
>
> (1) Co-extensions (and more generally, allocators for anonymous access
> types). [I'd like to get rid of all anonymous types period, but that
> probably is going to far.];

Yes. It was a yet another helpless attempt to circumvent the issue of MI
per mix-ins with co-extensions.

> (2) Generic in-out object parameters (almost never used, hard to implement,
> probably buggy because of the first two);

What about passing a storage pool to a generic?

> (3) Interfaces (buys almost nothing over abstract types, except a huge
> amount of complication in definition and implementation);

Hold on, should it mean that you are for true MI? I cannot believe it!
(:-))

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

[Dmitry A. Kazakov]

On Thu, 26 Apr 2012 02:37:30 +0200, Yannick Duchêne (Hibou57) wrote:

> Le Thu, 26 Apr 2012 00:14:47 +0200, ytomino <agh...@gmail.com> a écrit:
>
>> Delphi(or C#)'s method resolution clauses.
>>
>> Java-style interface introduced in Ada2005 makes primitive names to
>> global.
>> Method resolution clause restore them to local.
>>
>> type I1 is interface;
>> procedure X (Obj : I1);
>> type I2 is interface;
>> procedure X (Obj : I2);
>>
>> type T is new I1 and I2;
>> procedure X (Obj : T); -- conflicted!!!
>>
>> If method resolution clause exists:
>>
>> type T is new I1 and I2;
>> overriding(I1.X) procedure X1 (Obj : T);

I never liked prefix overriding. It would be much better:

procedure X (...) is overriding;
procedure X1 (...) is overriding I1.X;

>> overriding(I2.X) procedure X2 (Obj : T);
>
> The above may still present issues with overloading. Imagine X exist with
> multiple signatures, for both I1 and I2: as your proposal does not refer
> the precise signature, this would still be ambiguous.

So what? This problem already exists in Ada, it is a *different* problem.
Look at renaming, for example.

The proposal is about resolving conflicts by *existing* means. If Ada
provided a better way to identify a procedure than by its fully qualified
name + signature, that could be only welcome and would work here as well.

My complaint has always been that Ada should finally take the policy that
name conflicts shall be treated as errors if not explicitly resolved. That
would nullify your example, because there will be no context with
undistinguishable X.

[Georg Bauhaus]

On 26.04.12 09:43, Mart van de Wege wrote:

> The canonical example is processing a file with comment lines starting
> with '#':
>
> while (<$file>) {
> next if /^#/; # skip comment lines
> [...Do stuff with line ...]
> }

Inherited from Unix scripting, for files that don't have section
indicators, and predating to the more shiny features of later
versions of Perl. When this scheme is used with more prefixes
besides /^#/, I'd immediately want a filtering capability, perhaps
some abstraction, and this filter will likely use Perl 5.10.x's
new switch/when capabilities, or one of its simpler predecessors.

There are really many modes of expressing Perl things now, at all levels
of language, including 3 (three!) different gotos besides next and last!
And "until", and "for", and "foreach", and "each", and "redo" and other
micro-optimizations that are as productive as product diversification
can make them:
no new effects, but many ways to do the same thing, all useful
in avoiding data types describing the intentions, and all of them
understandable as long as you write code in just one version of Perl.

Perhaps someone could introduce an O(f(TIMTOWTDI)) notation for
complexity at the syntax level. Perl certainly isn't linear
in this regard, while Ada was required to be. :-)

> Now, this is a lot clearer, and IMO a lot more elegant, than putting a
> label on the end of the loop and use 'goto label'.
>
> Although it *is* considered good practice to put your 'next' statements
> at the top of the loop to make clear on what conditions the main body
> will be skipped.

Actually, "next" in Perl doesn't jump to the top of the loop.
It jumps to its bottom, because Perl has "continue" in its syntax:

$x = ...;
while ($condition->($x)) {
next if ...;
...
}
continue {
$x += ...;

}


> 'next' statements littered throughout the body of the
> loop are frowned upon.

Yet, multiple uses of "last"(?) were recommended to emulate
a switch statement prior to Perl 5.something...

[Dmitry A. Kazakov]

On Wed, 25 Apr 2012 21:08:06 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message
> news:mdgi0fhwon01$.18b871w98pjl6.dlg@40tude.net...
> ...
>> There is no means to flatten P making declarations of Q be directly
>> visible
>> for clients of P. E.g. something like
>>
>> package P is
>> package Q is new Foo (...);
>> use all Q; -- Make things from Q declared directly in P
>> end P;
>
> We tried to do this for Ada 2012; we made heroic efforts to do so. The
> problem is, this feature is a massive potential maintenance problem which
> destroys most of the Ada concepts of visibility and maintainablity. (It's
> all of the mistakes of package "use" multiplied a hundred-fold.)
>
> The biggest problem comes when there is a conflict between things declared
> in P and things declared in Q. Resolving that proved impossible without
> introducing major headaches.

Certainly there must be a generic mechanism for handling this. Because the
same issue arises with MI.

Probably something really revolutionary is needed here, something like
introduction of T'Class was, which resolved all OO mess just per finger
snap.

[Georg Bauhaus]

Thanks for the pointer; we have essentially tried everything
it says. I notice that the description is optimistic about SIMD
operators for "+", and "*", "adding and some of the multiplying".
We do in addition have a positive case for "/", but not on x86,
only on x86_64. Some other things worked on x86, but not on x86_64,
such as splitting loops in two, and using auxiliary data structures,
perhaps creating enough of independence. Nevertheless, all effects
seem unpredictable (I'm not blaming GNAT or GCC), and not yet near
to what Intel's Fortran does.

[Jacob Sparre Andersen]

Oliver Kleinke wrote:

> Have you discovered this yet?:
> http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Vectorization-of-loops.html

According the documentation it only works partially - unless you disable
overflow checks. :-(

Greetings,

Jacob
--
"They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-- Benjamin Franklin

[gautier...@hotmail.com]

a) The least possible additions to the language (overcomplication is a threat!)
b) Extend the Ada.* libraries (much of the strength of a language is in the available components, so it is better if they are among standard, portable, compatible Ada.* stuff)

Still, I have a very simple wish for a) in my list:
* Enum'Length

For b) I see good ideas in other posts, like indefinite-precision integers or floats.
On my list, something very simple so far:
* Ada.Directories.Set_Modification_Time
* Ada.Directories.Read_Only
* Ada.Directories.Set_Read_Only
_________________________
Gautier's Ada programming
http://sf.net/users/gdemont/

[Yannick Duchêne (Hibou57)]

Le Thu, 26 Apr 2012 10:44:39 +0200, Dmitry A. Kazakov
<mai...@dmitry-kazakov.de> a écrit:

> So what? This problem already exists in Ada, it is a *different* problem.
> Look at renaming, for example.
>
> The proposal is about resolving conflicts by *existing* means. If Ada
> provided a better way to identify a procedure than by its fully qualified
> name + signature, that could be only welcome and would work here as well.

Additional names to complete short names? Like with full‑names vs
first‑names?

[Yannick Duchêne (Hibou57)]

Le Thu, 26 Apr 2012 11:29:00 +0200, <gautier...@hotmail.com> a écrit:
> Still, I have a very simple wish for a) in my list:
> * Enum'Length

What about a more general Range'Width? (which would be universal_integer)

[Marc C]

On Apr 25, 8:11 am, Marc C <mc.provisio...@gmail.com> wrote:

> > 0) Which features do you think can be dropped from Ada?
>

> - Stubs, i.e. "is separate".
> - Distributed Annex

Hey! It's just an *opinion*! :-)

Of course dropping these would break existing code, as would dropping
pretty much any other language feature.

I'm just going by what I see used (or not used) in current-day Ada
software projects, open source and corporate, and that includes the
direction in which I've been seeing the maintenance coding of legacy
systems evolving in recent years.

YMMV.

Marc

[AdaMagica]

Am Donnerstag, 26. April 2012 04:00:12 UTC+2 schrieb Randy Brukardt:
> (I believe Christoph Grein has
> or soon will make an Ada 2012 version of his managed pointer packages that
> illustrates how its done.)

http://www.christ-usch-grein.homepage.t-online.de/Ada/Smart_Pointers.html

I'm waiting for GNAT GPL 2012.

[Dmitry A. Kazakov]

On Thu, 26 Apr 2012 13:22:13 +0200, Yannick Duchêne (Hibou57) wrote:

> Le Thu, 26 Apr 2012 10:44:39 +0200, Dmitry A. Kazakov
> <mai...@dmitry-kazakov.de> a écrit:
>> So what? This problem already exists in Ada, it is a *different* problem.
>> Look at renaming, for example.
>>
>> The proposal is about resolving conflicts by *existing* means. If Ada
>> provided a better way to identify a procedure than by its fully qualified
>> name + signature, that could be only welcome and would work here as well.
>
> Additional names to complete short names? Like with full‑names vs
> first‑names?

I don't know. My position is that conflicting names shall not be allowed in
first place. The compiler should require an explicit renaming of any
conflicting entities.

[Dmitry A. Kazakov]

On Thu, 26 Apr 2012 13:27:14 +0200, Yannick Duchêne (Hibou57) wrote:

> Le Thu, 26 Apr 2012 11:29:00 +0200, <gautier...@hotmail.com> a écrit:
>> Still, I have a very simple wish for a) in my list:
>> * Enum'Length
>
> What about a more general Range'Width? (which would be universal_integer)

The mathematical term for that is "cardinality":

http://en.wikipedia.org/wiki/Cardinality

[Mart van de Wege]

Georg Bauhaus <rm.dash...@futureapps.de> writes:

>>
>> Although it *is* considered good practice to put your 'next' statements
>> at the top of the loop to make clear on what conditions the main body
>> will be skipped.
>
> Actually, "next" in Perl doesn't jump to the top of the loop.

I didn't actually say that. Read carefully.

'next' will immediately skip to the next iteration of a loop. Processing
of the loop body stops at next; therefore it is considered good practice
to put your 'next' statements at the top of the loop, so that it is
immediately clear under which conditions the loop body is skipped.

>
>> 'next' statements littered throughout the body of the
>> loop are frowned upon.
>
> Yet, multiple uses of "last"(?) were recommended to emulate
> a switch statement prior to Perl 5.something...

Oh, I'm not saying Perl is without warts. But I still like it a lot,
even if I'm really warming up to Ada as well (and isn't that a weird
pair of favourite programming languages?).

But as for the missing switch, using 'last' was one way to build one,
alternating elsif blocks another, and my particular favourite was to use
a dispatch table using a hash of sub references.

[Adam Beneschan]

On Wednesday, April 25, 2012 7:52:52 PM UTC-7, Randy Brukardt wrote:
> "Yannick Duchêne (Hibou57)" wrote in message

> news:op.wdcj0snyule2fv@douda-yannick...
> ...
> >> If method resolution clause exists:
> >>
> >> type T is new I1 and I2;
> >> overriding(I1.X) procedure X1 (Obj : T);
> >> overriding(I2.X) procedure X2 (Obj : T);
> >
> >The above may still present issues with overloading. Imagine X exist with
> >multiple signatures, for both I1 and I2: as your proposal does not refer
> >the precise signature, this would still be ambiguous.
>
> Right; simple names are never enough. You always need the full profile, else
> you still have holes. Those holes were bad enough for pragmas that we dumped
> the entire mess and invented aspect specifications for Ada 2012.
>
> We actually considered something like this for Ada 2005, but decided it just
> goes too far. In part, that's because having such a problem suggests bad
> design somewhere: it should never be the case that you have two routines
> with the same name and profile that have different meanings.

I'm not sure that's an indicator of bad design, in this case. It seems quite plausible that the interface types, I1 and I2, were designed by people who had nothing to do with each other, working on totally different open-source projects; and it happened that they came up with the same name and profile for one of their methods. You probably can't attribute that to bad design. Now someone else wants to make use of reusable open-source software and they want to define a type that implements both the I1 and I2 interfaces. I don't think it seems all that far-fetched. I'm only a little familiar with other languages (such as D-Flat) that support interfaces, but from what little I know, it does seem like a definite problem in those languages.

-- Adam

[Simon Wright]

björn lundin <b.f.l...@gmail.com> writes:

> Den onsdagen den 25:e april 2012 kl. 15:11:27 UTC+2 skrev Marc C:
>> - Stubs, i.e. "is separate".
>

> That would totally break the system I work on.
> We are heavily dependent on separates,,,

We use separates with a code generator; the actual implementations are
kept in a parallel directory from the generated ones, so that we don't
need to worry about keeping implementation details in a (UML) model (the
original intent was that the compiler would look at the implementation
directory first, thus superseding any equivalents in the generated
directory; but that doesn't fly with gnatmake, so we delete the
'overridden' files).

[Adam Beneschan]

On Thursday, April 26, 2012 12:43:00 AM UTC-7, Mart van de Wege wrote:

OK, I'll have to admit that I do stuff like this when I use Perl. On the other hand, the mere fact that I've decided to write something in Perl indicates that I don't care about readability for that particular program. I'd rather not have Ada head in the same direction. Plus, I think this is OK in a small loop (maybe a dozen lines) that could be mentally "eaten in one bite".

-- Adam

[an...@att.net]

>I can't remember all the details (there is a recording on-line for
>that), but one of his points was (as I understand it) that whatever we
>add to Ada should either simplify it (if that is possible) or be a
>"killer feature" for attracting new people to Ada.

Adding additions to Ada should be simple. And never repeat that "NEVER"
copied from another language. Such as conditional statements or functions
that look like and act like "C procedure statements." Because people will
say "Ada is trying to become C, and its better to use the real thing,
instead of a copy cat with issues."

Second altering existing paradigms such as "return-by-reference" to
"return-by-type". which kills existing code and destroys a number of
features in existing codes. And these feature were a plus to Ada. Which
now makes Ada useless for backwards compatibility for programs that
use these features.

As for dropping or changing any feature dropped that kills any and
all languages.

And there are plenty of features in Ada 2012. Most should be plugged
before the final ARG vote. Because a lot of these features are not
worth having if they hurt Ada.

Now for "Array support in the direction of utilizing parallel". To allow
this Ada first must become parallel and have an operating systems that
support this type of programming.

As for a parallel operating systems. At the movement most people are more
interested in 64-bits than parallel. Because to fully utilize parallel all
programs and utilities must be compiled for parallel. In a Linux system,
that not only means the Linux but X-Windows and all apps such as Kate would
have to be compiled for parallel and some code re-written for parallel.
Which is not an easy task. As for Windows, even version 8 still will not
fully use the power of parallel.

It seams that programming community to be following Bill Gates time table
of 2025 before we see any "true parallel" compilers or operating systems.
So, I would say look for this feature in 203x or 204x at the earliest for
Ada.



In <87sjfsa...@adaheads.sparre-andersen.dk>, Jacob Sparre Andersen <spa...@nbi.dk> writes:
>Yannick Duchêne wrote:
>> Le Wed, 25 Apr 2012 10:36:09 +0200, Jacob Sparre Andersen
>> <spa...@nbi.dk> a écrit:
>
>>> Did you listen to the discussion on the subject chaired by Robert
>>> Dewar at FOSDEM?
>
>> On my own side, I don't. What did he said?
>
>I can't remember all the details (there is a recording on-line for
>that), but one of his points was (as I understand it) that whatever we
>add to Ada should either simplify it (if that is possible) or be a
>"killer feature" for attracting new people to Ada.
>
>One of the ideas discussed was to extend what you can control with
>storage pools. (I've earlier argued for dereferencing being managed by
>the storage pools. :-)
>
>The full recording is here:
>
> http://www.jacob-sparre.dk/recordings/fosdem-2012/
>
>Greetings,
>
>Jacob
>--
>"Those who profess to favor freedom and yet depreciate agitation, are
> people who want crops without ploughing the ground; they want rain
> without thunder and lightning; they want the ocean without the roar of
> its waters." -- Frederick Douglas

[Dmitry A. Kazakov]

On Thu, 26 Apr 2012 08:19:41 -0700 (PDT), Adam Beneschan wrote:

> On Wednesday, April 25, 2012 7:52:52 PM UTC-7, Randy Brukardt wrote:
>> "Yannick Duchêne (Hibou57)" wrote in message
>> news:op.wdcj0snyule2fv@douda-yannick...
>> ...
>>>> If method resolution clause exists:
>>>>
>>>> type T is new I1 and I2;
>>>> overriding(I1.X) procedure X1 (Obj : T);
>>>> overriding(I2.X) procedure X2 (Obj : T);
>>>
>>>The above may still present issues with overloading. Imagine X exist with
>>>multiple signatures, for both I1 and I2: as your proposal does not refer
>>>the precise signature, this would still be ambiguous.
>>
>> Right; simple names are never enough. You always need the full profile, else
>> you still have holes. Those holes were bad enough for pragmas that we dumped
>> the entire mess and invented aspect specifications for Ada 2012.
>>
>> We actually considered something like this for Ada 2005, but decided it just
>> goes too far. In part, that's because having such a problem suggests bad
>> design somewhere: it should never be the case that you have two routines
>> with the same name and profile that have different meanings.
>
> I'm not sure that's an indicator of bad design, in this case. It seems
> quite plausible that the interface types, I1 and I2, were designed by
> people who had nothing to do with each other, working on totally different
> open-source projects; and it happened that they came up with the same name
> and profile for one of their methods.

It gets promptly forgotten that the idempotent model of inheritance is not
the only one. It is absolutely legitimate to implement exactly same
interface twice or more times under an additive model. As an example,
consider the interface of a doubly linked list.

type Request is new List and List;
-- A request participates in two lists!

The point is, a properly designed MI shall support *both* models in all
possible combinations of. It is up to the programmer to choose the model in
each concrete case.

[Jeffrey Carter]

On 04/26/2012 12:43 AM, Mart van de Wege wrote:
>
> I like the Perl use of 'next' and 'last' to influence looping.

If you're going to use Perl, then by definition you don't care about readability.

--
Jeff Carter
"I'm a kike, a yid, a heebie, a hook nose! I'm Kosher,
Mum! I'm a Red Sea pedestrian, and proud of it!"
Monty Python's Life of Brian
77

[Mart van de Wege]

Jeffrey Carter <spam.jrc...@spam.not.acm.org> writes:

> On 04/26/2012 12:43 AM, Mart van de Wege wrote:
>>
>> I like the Perl use of 'next' and 'last' to influence looping.
>
> If you're going to use Perl, then by definition you don't care about readability.

That's a bit silly. I happen to write very readable Perl; given that
other people have no problems maintaining or even extending my code, I
can say that.

Sure, Perl chooses to favour the writer over the reader, but the 'Perl
is line noise, ha ha ha' joke wears a bit thin.

And even if this were true in general, it still doesn't make specific
points untrue. The use of statement modifiers combined with loop control
constructs make for elegant, terse, yet readable code IMO. Even if the
rest of the program *is* line noise.

There is no reason why one should dismiss a construct out of hand
because of dislike of a language. People who complain about Ada's
'bondage and discipline' nature are just as stupid, because they don't
realise that Ada's elegance makes following the strictures of the
language almost painless.

In the end, using if blocks and a goto is the same thing as using a
dedicated loop control construct. I just find it an affront to my
impression of Ada as an elegant language. In my personal opinion, it
just *feels* clunky.

[Jeffrey Carter]

On 04/26/2012 02:41 PM, Mart van de Wege wrote:
>
> That's a bit silly. I happen to write very readable Perl; given that
> other people have no problems maintaining or even extending my code, I
> can say that.

That's a bit silly. People have maintained and extended code in every language;
that doesn't mean all such code is readable.

> In the end, using if blocks and a goto is the same thing as using a
> dedicated loop control construct. I just find it an affront to my
> impression of Ada as an elegant language. In my personal opinion, it
> just *feels* clunky.

A go-to is not the correct solution to these cases; neither is a "next" statement.

[Randy Brukardt]

"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message

news:w94h61g5wpzn.a60iwvyn0g83$.dlg@40tude.net...

> On Wed, 25 Apr 2012 21:08:06 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message
>> news:mdgi0fhwon01$.18b871w98pjl6.dlg@40tude.net...
>> ...
>>> There is no means to flatten P making declarations of Q be directly
>>> visible
>>> for clients of P. E.g. something like
>>>
>>> package P is
>>> package Q is new Foo (...);
>>> use all Q; -- Make things from Q declared directly in P
>>> end P;
>>
>> We tried to do this for Ada 2012; we made heroic efforts to do so. The
>> problem is, this feature is a massive potential maintenance problem which
>> destroys most of the Ada concepts of visibility and maintainablity. (It's
>> all of the mistakes of package "use" multiplied a hundred-fold.)
>>
>> The biggest problem comes when there is a conflict between things
>> declared
>> in P and things declared in Q. Resolving that proved impossible without
>> introducing major headaches.
>
> Certainly there must be a generic mechanism for handling this. Because the
> same issue arises with MI.

Right, MI definitely has similar problems. Indeed, inheritance in general
(no 'M' needed) has similar issues.

But there are two mitigating factors that help cause the problems to be
hidden in inheritance cases:

(1) If the underlying package never gets maintained, problems caused by
maintenance are irrelevant. The easy way to see that is to compare a package
use clause given on Ada.Text_IO versus some under-development package.
Text_IO changes only when a new compiler version is installed, and usually
not even then (it really only changes when the language version does). In
those cases, the issues caused by the new version greatly outweighs any
issues caused by package use, and thus the effect is unnoticable. OTOH, if
you have an actively developed package specification, changes are frequent,
and errors caused by those changes on unrelated code become a significant
effect (and drag on productivity). I suspect that you seem similar effects
based on how much the root type changes.
(2) Ada uses "cancelation" to avoid so-called Beaujolias effects, where a
change causes one legal program to morph into a different legal program.
Cancelation is contained for overloadable entities (the profiles have to
match, which is not very likely, and suggests a definitional problem if
routines with different meaning but the same name and profile exist), but
for non-overloadable things (objects, types, exceptions, packages), anything
with the same name is canceled, which causes a wide net of damage.
Inheritance only involves overloadable entities in Ada, so the damage is
greatly contained in that case.

I tried to suggest making objects overloadable as a mitigation to the
maintenance problems (I don't think we can ever do better than that; at some
point it has to be the case that entities that are too similar are not
considered "unrelated"). But that of course added a whole 'nother level of
complexity to the proposal, and of course it doesn't do anything for types
and packages.

> Probably something really revolutionary is needed here, something like
> introduction of T'Class was, which resolved all OO mess just per finger
> snap.

Not that revolutionary, not for Ada -- overload everything. Most languages
can only overload on parameters, which is way insufficient (objects usually
don't have parameters, and having all objects the same fixes nothing), but
of course Ada can. The problem is mostly one of compatibility; secondarily,
I don't see a good way to have overloaded types (exceptions aren't a
problem; they're just objects of a built-in type; not sure about packages -
package types would do the trick, but seem way over the top).

Probably this would have to wait for Ada-prime (or perhaps Bob Duff's
language :-).

Randy.

[Randy Brukardt]

"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message

news:lh3gjjdhbg01.k1bt0u2astpl$.dlg@40tude.net...

> On Wed, 25 Apr 2012 21:23:37 -0500, Randy Brukardt wrote:

...

>> (2) Generic in-out object parameters (almost never used, hard to
>> implement,
>> probably buggy because of the first two);
>
> What about passing a storage pool to a generic?

One of the reasons I didn't propose getting rid of anonymous access is that
they're really handy for solving the occasional oddity. Passing an "in"
object that is an anonynous access to Root_Storage_Pool'Class handles this
need nicely, and doesn't require pages of mechanism in the RM and thousands
of lines of never used code in a compiler. (I worry more about the latter
than the former -- I'd never use an "in out" generic object even if it was
supposedly the right solution since you're much more likely to get stopped
by a compiler bug.)

>> (3) Interfaces (buys almost nothing over abstract types, except a huge
>> amount of complication in definition and implementation);
>
> Hold on, should it mean that you are for true MI? I cannot believe it!
> (:-))

I've concluded that I'm pretty much against all forms of MI. Which I realize
is probably too strong, but surely Interfaces isn't it. I'm definitely
against any mechanism that you can only use once, which is the way a
particular interface works. That leads to silliness like the "no hidden
interfaces" rule (because otherwise you could destroy privacy by adding the
"right" interface; alternatively, you could destroy everyone's sanity by
determining what routine to dispatch to by what visibility you have).

Solutions to this mess probably exist, but I'd rather spend my limited
efforts on earth on something that actually will help my programs (say
exception contracts, more static capabilities for pre and postconditions,
etc.).

Randy.

[Randy Brukardt]

"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message

news:bjg1nrfssv58$.1f05frcj5q54s$.dlg@40tude.net...
...

> My complaint has always been that Ada should finally take the policy that
> name conflicts shall be treated as errors if not explicitly resolved. That
> would nullify your example, because there will be no context with
> undistinguishable X.

Not sure what you mean by this; Ada has always had that policy. Indeed,
there was a formal proof for Ada 95 that there were no Beaujolias effects
(which is essentially the same thing).

I could see eliminating some of the hiding rules that Ada already has, but
that's different than what you describe above: those declarations
effectively don't exist in scopes where they are hidden, so they can have no
effect on resolution or legality.

Randy.

[sbelm...@gmail.com]

+1 for proper constructors and destructors. Or, at the very least, a way to inhibit uninitialized private record types (type T is not null record ...?). Apart from finally providing safe initialization, it could always lead the way for constant record elements...

It would certainly be nice to include the requisite 'auto' and 'shared' access types in the standard library, but I suppose this would detract from the verisimilitude that access types are not needed for OOP (which is simply just not the case).

And despite being a minor issue, I really wish they would create a generic formal type for pool-specific access types only (type T_Ptr is not access all T?). It offends my delicate sensitivities that you can instantiate Unchecked_Deallocation for a general access type, because that's a compile time error.

And for the love of all that is holy, remove null procedures, or at least standardize a pragma to do so. The fact that Ada automates the fudging and faking of an operation that is not applicable for a type is anathema to everything the language has stood for since 1983. A procedure Do_Something that does not do something is the most awful, unabashed example of bad design that could possibly exist....and the language has constructs to expedite it?!

[Randy Brukardt]

<an...@att.net> wrote in message news:jnbqqa$tb$2...@speranza.aioe.org...

> >I can't remember all the details (there is a recording on-line for
>>that), but one of his points was (as I understand it) that whatever we
>>add to Ada should either simplify it (if that is possible) or be a
>>"killer feature" for attracting new people to Ada.
>
> Adding additions to Ada should be simple. And never repeat that "NEVER"
> copied from another language. Such as conditional statements or functions
> that look like and act like "C procedure statements." Because people will
> say "Ada is trying to become C, and its better to use the real thing,
> instead of a copy cat with issues."

Huh? "Conditional statements" have been in every programming language since
the beginning of time. Perhaps you meant "conditional expressions", a
feature present in Algol 60 (which predates C by more than 10 years), and a
language which is a direct ancestor of Ada (Algol-60 => Algol-W => Pascal =>
Ada).

I have no clue what a "procedure statement" is; I remember no such thing in
C. No matter, "expression functions" were created solely from my own
imagination. I doubt they are unique (the need occurs in every programming
language for large systems), but I know for a fact that the idea was not
based on any feature present in any other programming language.

...

> Second altering existing paradigms such as "return-by-reference" to
> "return-by-type". which kills existing code and destroys a number of
> features in existing codes. And these feature were a plus to Ada. Which
> now makes Ada useless for backwards compatibility for programs that
> use these features.

Good riddence. "return-by-reference" is garbage. We tried to use it in Claw
and it is impossible (because you can never define the object to return in
any reasonable way.

...

> And there are plenty of features in Ada 2012. Most should be plugged
> before the final ARG vote. Because a lot of these features are not
> worth having if they hurt Ada.

The "final ARG vote" happened in early March. Ada 2012 is in the
standardization channel now with no further changes planned.

Randy.

P.S. Yes, everyone, I know I'm feeding the troll. As usual, it's bad to
leave these misconceptions around in the permanent record of the Internet...

[ytomino]

On Friday, April 27, 2012 12:19:41 AM UTC+9, Adam Beneschan wrote:
>
> I'm not sure that's an indicator of bad design, in this case. It seems quite plausible that the interface types, I1 and I2, were designed by people who had nothing to do with each other, working on totally different open-source projects; and it happened that they came up with the same name and profile for one of their methods. You probably can't attribute that to bad design. Now someone else wants to make use of reusable open-source software and they want to define a type that implements both the I1 and I2 interfaces. I don't think it seems all that far-fetched. I'm only a little familiar with other languages (such as D-Flat) that support interfaces, but from what little I know, it does seem like a definite problem in those languages.

Great!
You said all things that I wanted to say.

And, some languages such as C# has tackled the problem that a base-class is changed independently of derived-classes. Method resolution clause is one of these solutions.