What would you like in Ada202X?

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

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Hi, very good topic :-D

Le Wed, 25 Apr 2012 09:47:06 +0200, Martin <martin@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

Re: What would you like in Ada202X?

[stefan-lucks]

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!  ------

Re: What would you like in Ada202X?

[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.

Re: What would you like in Ada202X?

[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

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 Apr 2012 10:36:09 +0200, Jacob Sparre Andersen <sparre@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?

-- 
“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

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 Apr 2012 10:36:41 +0200, Dmitry A. Kazakov  
<mailbox@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)

-- 
“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

Re: What would you like in Ada202X?

[leonid]

On Apr 25, 10:46 am, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> 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?
>
> --
> “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

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

Re: What would you like in Ada202X?

[Georg Bauhaus]

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 starters for 10 are:
>
> 1) 1st class functions / lambdas
> 2) parallel loops / functions
> 3) Multiple dispatch

My favorite change would start here:

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


-Georg

Re: What would you like in Ada202X?

[Martin]

On Wednesday, April 25, 2012 9:36:09 AM UTC+1, Jacob Sparre Andersen wrote:
> 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.

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

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

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

> 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 starters for 10 are:
>>
>> 1) 1st class functions / lambdas
>> 2) parallel loops / functions
>> 3) Multiple dispatch
>
> My favorite change would start here:
>
> 0) Which features do you think can be dropped from Ada?
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?

-- 
“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

Re: What would you like in Ada202X?

[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  
> <mailbox@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;

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

Re: What would you like in Ada202X?

[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

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

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Wed, 25 Apr 2012 10:36:41 +0200, Dmitry A. Kazakov wrote:

> 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.

13) Forgot the most important thing: contracted exceptions

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

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 Apr 2012 11:24:18 +0200, Dmitry A. Kazakov  
<mailbox@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.

-- 
“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

Re: What would you like in Ada202X?

[Jacob Sparre Andersen]

Yannick Duch�ne wrote:
> Le Wed, 25 Apr 2012 10:36:09 +0200, Jacob Sparre Andersen
> <sparre@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

Re: What would you like in Ada202X?

[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.

Re: What would you like in Ada202X?

[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.

Re: What would you like in Ada202X?

[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

Re: What would you like in Ada202X?

[Georg Bauhaus]

On 25.04.12 15:11, Marc C wrote:
> 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".

Particularly interesting, since now Microsoft is popularizing
partial classes.

Re: What would you like in Ada202X?

[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

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

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

-- 
“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

Re: What would you like in Ada202X?

[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

Re: What would you like in Ada202X?

[tmoran]

> 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.

Re: What would you like in Ada202X?

[Lucretia]

On Wednesday, April 25, 2012 5:12:29 PM UTC+1, björn lundin wrote:
> 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

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.

Re: What would you like in Ada202X?

[okellogg]

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

Re: What would you like in Ada202X?

[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.

On Wed, 25 Apr 2012 06:10:58 -0700, Nicholas Paul Collin Gloucester  
<Colin_Paul_Gloster@acm.org> wrote:

> 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.

Re: What would you like in Ada202X?

[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

Re: What would you like in Ada202X?

[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.

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

Re: What would you like in Ada202X?

[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...

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

Re: What would you like in Ada202X?

[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?

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

Re: What would you like in Ada202X?

[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

Re: What would you like in Ada202X?

[Adam Beneschan]

On Wednesday, April 25, 2012 11:07:15 AM UTC-7, okel...@users.sourceforge.net wrote:
> 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

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

Re: What would you like in Ada202X?

[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

Re: What would you like in Ada202X?

[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.

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

Re: What would you like in Ada202X?

[okellogg]

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

Re: What would you like in Ada202X?

[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

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

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

> On Wednesday, April 25, 2012 5:12:29 PM UTC+1, björn lundin wrote:
>> 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
>
> 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.

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.

-- 
“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

Re: What would you like in Ada202X?

[Jeffrey Carter]

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

That reminds me:

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

-- 
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

Re: What would you like in Ada202X?

[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

Re: What would you like in Ada202X?

[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.

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 Apr 2012 20:14:59 +0200, Jeffrey Carter  
<spam.jrcarter.not@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 .

-- 
“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

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

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

> 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

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 .

-- 
“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

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

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

> On 04/25/2012 01:12 PM, okellogg@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?


-- 
“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

Re: What would you like in Ada202X?

[Martin Dowie]

Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> wrote:
> On 04/25/2012 01:12 PM, okellogg@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

Re: What would you like in Ada202X?

[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.

-- 
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

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 Apr 2012 21:02:57 +0200, Oliver Kleinke  
<oliver.kleinke@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?


-- 
“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

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 Apr 2012 23:14:51 +0200, Jeffrey Carter  
<spam.jrcarter.not@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.


-- 
“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

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 Apr 2012 23:14:51 +0200, Jeffrey Carter  
<spam.jrcarter.not@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.

-- 
“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

Re: What would you like in Ada202X?

[okellogg]

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

Re: What would you like in Ada202X?

[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

Re: What would you like in Ada202X?

[Georg Bauhaus]

On 25.04.12 23:11, Martin Dowie wrote:
> Jeffrey Carter<spam.jrcarter.not@spam.not.acm.org>  wrote:
>> On 04/25/2012 01:12 PM, okellogg@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 :-)

Re: What would you like in Ada202X?

[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.

Re: What would you like in Ada202X?

[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.

-- 
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

Re: What would you like in Ada202X?

[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

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Le Thu, 26 Apr 2012 00:14:47 +0200, ytomino <aghia05@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);
> 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.

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.

-- 
“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

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Le Thu, 26 Apr 2012 00:30:38 +0200, Shark8 <onewingedshark@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.

-- 
“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

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Le Thu, 26 Apr 2012 00:33:11 +0200, Jeffrey Carter  
<spam.jrcarter.not@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.

-- 
“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

Re: What would you like in Ada202X?

[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.

-- 
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

Re: What would you like in Ada202X?

[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

Re: What would you like in Ada202X?

[Randy Brukardt]

"Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message 
news:87sjfsaw1r.fsf@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.

Re: What would you like in Ada202X?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@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.

Re: What would you like in Ada202X?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1xll47vz9nd7t.14ahwiifomrut.dlg@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.

Re: What would you like in Ada202X?

[Randy Brukardt]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:4f97bf40$0$6559$9b4e6d93@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.

Re: What would you like in Ada202X?

[Randy Brukardt]

<okellogg@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.

Re: What would you like in Ada202X?

[Randy Brukardt]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:4f98781c$0$6557$9b4e6d93@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.

Re: What would you like in Ada202X?

[Randy Brukardt]

"Adam Beneschan" <adam@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.

Re: What would you like in Ada202X?

[Randy Brukardt]

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

"Yannick Duch�ne (Hibou57)" <yannick_duchene@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.

Re: What would you like in Ada202X?

[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.

Re: What would you like in Ada202X?

[Mart van de Wege]

Adam Beneschan <adam@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.

Re: What would you like in Ada202X?

[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

Re: What would you like in Ada202X?

[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.kleinke@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.

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

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

> "Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
> news:4f97bf40$0$6559$9b4e6d93@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

Re: What would you like in Ada202X?

[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 <aghia05@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.

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

Re: What would you like in Ada202X?

[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...

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

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

> "Dmitry A. Kazakov" <mailbox@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.

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

Re: What would you like in Ada202X?

[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

Re: What would you like in Ada202X?

[Georg Bauhaus]

On 26.04.12 10:15, Oliver Kleinke wrote:
>>>>> 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

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.

Re: What would you like in Ada202X?

[gautier_niouzes]

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/

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Le Thu, 26 Apr 2012 10:44:39 +0200, Dmitry A. Kazakov  
<mailbox@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?

-- 
“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

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Le Thu, 26 Apr 2012 11:29:00 +0200, <gautier_niouzes@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)

-- 
“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

Re: What would you like in Ada202X?

[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

Re: What would you like in Ada202X?

[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.

Re: What would you like in Ada202X?

[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  
> <mailbox@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.

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

Re: What would you like in Ada202X?

[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_niouzes@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

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

Re: What would you like in Ada202X?

[Mart van de Wege]

Georg Bauhaus <rm.dash-bauhaus@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.

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

Re: What would you like in Ada202X?

[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

Re: What would you like in Ada202X?

[Simon Wright]

björn lundin <b.f.lundin@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).

Re: What would you like in Ada202X?

[Adam Beneschan]

On Thursday, April 26, 2012 12:43:00 AM UTC-7, Mart van de Wege wrote:
> Adam Beneschan 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 ...]
> }

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

Re: What would you like in Ada202X?

[anon]

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

>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 <87sjfsaw1r.fsf@adaheads.sparre-andersen.dk>, Jacob Sparre Andersen <sparre@nbi.dk> writes:
>Yannick Duch�ne wrote:
>> Le Wed, 25 Apr 2012 10:36:09 +0200, Jacob Sparre Andersen
>> <sparre@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

Re: What would you like in Ada202X?

[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.

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

Re: What would you like in Ada202X?

[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

Re: What would you like in Ada202X?

[Mart van de Wege]

Jeffrey Carter <spam.jrcarter.not@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.

Mart

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

Re: What would you like in Ada202X?

[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.

-- 
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

Re: What would you like in Ada202X?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@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" <mailbox@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.

Re: What would you like in Ada202X?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@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.

Re: What would you like in Ada202X?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@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.

Re: What would you like in Ada202X?

[sbelmont700]

+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?!

Re: What would you like in Ada202X?

[Randy Brukardt]

<anon@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...

Re: What would you like in Ada202X?

[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.

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Le Fri, 27 Apr 2012 01:50:07 +0200, Randy Brukardt <randy@rrsoftware.com>  
a écrit:
> I tried to suggest making objects overloadable
I'm not sure to see. Objects of the same name with different types in the  
same declaration list?

    E : Cat_Type;
    E : Rabbit_Type;

?

> Probably this would have to wait for Ada-prime (or perhaps Bob Duff's
> language :-).
He did design one? Where can we read about?

-- 
“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

Re: What would you like in Ada202X?

[Nasser M. Abbasi]

On 04/25/2012 02:47 AM, 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
> 2) parallel loops / functions
> 3) Multiple dispatch
>
> -- Martin

I do not think Ada needs more language lawyers adding more fancy things 
to it :)

What Ada needs is more user libraries for all sorts of things. More 
bindings, and such.

Use the energy and the effort on these issues, enough making the 
language more complicated. If I wanted a complicated language, there is 
always c++11 :)

Ada for me is like a solid foundation sitting on a solid
rock but does not have enough materials and enough crew needed to build 
high rise buildings on these foundations.

While other languages, with much weaker foundations and sit on much 
weaker soil, have plenty of material and lots of crew to build lots of 
high rise buildings (buildings which always seem to shake, crack easily, 
and sometimes fall).

Ada's foundation are very solid. What it needs is the materials to use 
to build on top of this foundations, otherwise, it will always remain 
just a very strong foundation, but with few buildings on top of it.

--Nasser

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Le Fri, 27 Apr 2012 02:09:38 +0200, Randy Brukardt <randy@rrsoftware.com>  
a écrit:

> "Dmitry A. Kazakov" <mailbox@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).
Formal proof? Or did you mean strong certitudes?

-- 
“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

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Le Fri, 27 Apr 2012 07:10:33 +0200, Nasser M. Abbasi <nma@12000.org> a  
écrit:
> I do not think Ada needs more language lawyers adding more fancy things  
> to it :)
>
> What Ada needs is more user libraries for all sorts of things. More  
> bindings, and such.

Precisely what I disagree with since very long. Some people tends to say  
“X's a good language”, and when you ask them why as you are pointing some  
issues, they may replies with things looking like “I could send an e‑mail  
with a single line of source”: that's not the language, but the library.  
Library and language should not be confused. The only kind of library  
required for a language, is the runtime (*). Libraries may make a language  
famous, but can't make a language better. Both should be clearly distinct  
things in the mind of everyones. A language is not just intended to reuse  
what's already done, it's also intended to do.


(*) To be more general, all parts of the standard library which are  
required for some of the language features to be meaningful. Ex.  
Ada.Finalization.

-- 
“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

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Thu, 26 Apr 2012 18:58:06 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@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
> object that is an anonynous access to Root_Storage_Pool'Class handles this 
> need nicely,

But you won't say that a C-fan arguing that there is no need in-out
parameters because int* does the job? (:-))

>>> (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.

Do not both Integer and Float implement "is private", T'Image, X'Size? MI
is all around you without any tagged types, you cannot get rid of it. You
sweep it under the carpet and pretend it does not exist.

> 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).

That is because the broken Java model was deployed. Look you cannot make a
type non-limited by adding "private" (=copyiable) interfaces. There is no
problem, except for fighting shadows.

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

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Thu, 26 Apr 2012 19:09:38 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@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.

But not for use-clauses.

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

Re: What would you like in Ada202X?

[Jacob Sparre Andersen]

Georg Bauhaus wrote:

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

I would like to drop (most of) the predefined numerical types from
package Standard.  We have to keep Duration, but are any of the other
numerical types in Standard really required by the language?  (Natural
and Integer'Base are used in the declaration of "**".  Is there a
sensible way around that?)

And the rationale: I believe that avoiding predefined types will limit
the temptation to use the same type (or two types) for all numerical
objects.

Greetings,

Jacob
-- 
"If it's a mess, hide it..." -- J-P. Rosen

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Thu, 26 Apr 2012 18:50:07 -0500, Randy Brukardt wrote:

> 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.

BTW, if procedures become 1st class, then they will be objects, and you
will have to overload them anyway.

>> 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.

OK, but there must be a way to ensure that each non-anonymous entity would
have at least one unique name valid for all contexts were it is accessible.
It is already a problem.

> 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;

More overloading cannot make legal programs illegal.

> 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).

Because type is not an object. It is already kind of overloaded with the
type conversion function of its own, e.g. T as a type and T(X) as
conversion function.

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

Re: What would you like in Ada202X?

[Georg Bauhaus]

On 27.04.12 04:38, ytomino wrote:

> And, some languages such as C# has tackled the problem that a base-class is changed independently of derived-classes.

Implying, maybe, that inheritance of classes may not be the
best way to write reusable modules?

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Fri, 27 Apr 2012 10:09:31 +0200, Georg Bauhaus wrote:

> On 27.04.12 04:38, ytomino wrote:
> 
>> And, some languages such as C# has tackled the problem that a base-class
>> is changed independently of derived-classes.
> 
> Implying, maybe, that inheritance of classes may not be the
> best way to write reusable modules?

and the best way is?

It reminds me people arguing against Ada because it gives them too much
error messages. Inheritance reports problems which other methods of
decomposition either do not detect at all or do much later, usually too
late.

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

Re: What would you like in Ada202X?

[Georg Bauhaus]

On 27.04.12 10:19, Dmitry A. Kazakov wrote:
> On Fri, 27 Apr 2012 10:09:31 +0200, Georg Bauhaus wrote:
> 
>> On 27.04.12 04:38, ytomino wrote:
>>
>>> And, some languages such as C# has tackled the problem that a base-class
>>> is changed independently of derived-classes.
>>
>> Implying, maybe, that inheritance of classes may not be the
>> best way to write reusable modules?
> 
> and the best way is?

Starting from at least one important distinction:

- is-a inheritance used where
- has-a should have been used.

then, not answering by giving "the best", or even "an optimal" way,
not even saying that interfaces have no uses,
just pointing out that all O-O language seem to have, after
some time, discovered that systems get "better" when they
use call-back style objects, or delegate objects (these
would then implement a interface).

Another hint at a possibly non-best way is the STL.

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Fri, 27 Apr 2012 11:46:24 +0200, Georg Bauhaus wrote:

> On 27.04.12 10:19, Dmitry A. Kazakov wrote:
>> On Fri, 27 Apr 2012 10:09:31 +0200, Georg Bauhaus wrote:
>> 
>>> On 27.04.12 04:38, ytomino wrote:
>>>
>>>> And, some languages such as C# has tackled the problem that a base-class
>>>> is changed independently of derived-classes.
>>>
>>> Implying, maybe, that inheritance of classes may not be the
>>> best way to write reusable modules?
>> 
>> and the best way is?
> 
> Starting from at least one important distinction:
> 
> - is-a inheritance used where
> - has-a should have been used.

HAS-A to reuse modules? To start with you cannot have HAS-A on subprograms
in Ada.

> Another hint at a possibly non-best way is the STL.

So the claim is that reuse of generic units does not suffer the problems
reuse of inherited operations have? In particular, the discussion was about
conflicting names coming from independently developed modules. Are you
telling me that generics have less problems with name clashes? Seriously?
They have FAR worse problems with this!

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

Re: What would you like in Ada202X?

[Martin]

On Wednesday, April 25, 2012 8:47:06 AM UTC+1, 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
> 2) parallel loops / functions
> 3) Multiple dispatch
> 
> -- Martin

4) 'Image for records/arrays

Or some means of iterating through each component, obtaining its name and values, such that I could write my own function quickly.

5) The ability to override the 'Image function
6) An alternative to 'Image that doesn't have a leading space for integers!

-- Martin

Re: What would you like in Ada202X?

[Georg Bauhaus]

On 27.04.12 12:05, Dmitry A. Kazakov wrote:
> On Fri, 27 Apr 2012 11:46:24 +0200, Georg Bauhaus wrote:
> 
>> On 27.04.12 10:19, Dmitry A. Kazakov wrote:
>>> On Fri, 27 Apr 2012 10:09:31 +0200, Georg Bauhaus wrote:
>>>
>>>> On 27.04.12 04:38, ytomino wrote:
>>>>
>>>>> And, some languages such as C# has tackled the problem that a base-class
>>>>> is changed independently of derived-classes.
>>>>
>>>> Implying, maybe, that inheritance of classes may not be the
>>>> best way to write reusable modules?
>>>
>>> and the best way is?
>>
>> Starting from at least one important distinction:
>>
>> - is-a inheritance used where
>> - has-a should have been used.
> 
> HAS-A to reuse modules?

In a place A, I use the features of a module M without
introducing any of its naming issues into the facade
of A.

If someone changes the module M, this change does not
propagate into the facade of A. This method dismisses,
I should say, any compiler based reasoning that transcends
the boundaries of either M or A and stops at the rules
for using features of M behind the facade of A.

> To start with you cannot have HAS-A on subprograms
> in Ada.

I mentioned delegate objects, resorting to single subprograms
is not considered necessary or advantageous in many O-O settings.
This idea blends well, I think, with the subprogram
types that you have mentioned. Meaning that subprograms
are in fact objects.

I fantasize that it does not blend well with grand unified
type theory. Not saying that this lack is any good.

To see the reason for the bias, consider "non-data type" as
a hash table because implementing "non-data type" uses
a hash table. I'd like a language to prevent this use of
IS-A, rather than encourage it.

>> Another hint at a possibly non-best way is the STL.
> 
> So the claim is that reuse of generic units does not suffer the problems
> reuse of inherited operations have?

No. The STL does not seem to suffer, otherwise there would
be huge pressure to change it to be IS-A all over the place.
Some uses of C++ templates and resolution rules can create
pain, if judged by efforts to ease the pain, in part with
the help of "concepts".

If names of generic instances are made problems, they are not
really the same problems that overriding names could
produce, or are they?  And then, the goal of generics was not,
I think, to supplant true MI.

  --  S := { set of dotless names }, |S| =: n.
  package P is new G;
  --  S' := S ∪ { set of dotless names introduced by P }.
  --  |S'| = n + 1.

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Fri, 27 Apr 2012 13:04:08 +0200, Georg Bauhaus wrote:

> On 27.04.12 12:05, Dmitry A. Kazakov wrote:
>> On Fri, 27 Apr 2012 11:46:24 +0200, Georg Bauhaus wrote:
>> 
>>> On 27.04.12 10:19, Dmitry A. Kazakov wrote:
>>>> On Fri, 27 Apr 2012 10:09:31 +0200, Georg Bauhaus wrote:
>>>>
>>>>> On 27.04.12 04:38, ytomino wrote:
>>>>>
>>>>>> And, some languages such as C# has tackled the problem that a base-class
>>>>>> is changed independently of derived-classes.
>>>>>
>>>>> Implying, maybe, that inheritance of classes may not be the
>>>>> best way to write reusable modules?
>>>>
>>>> and the best way is?
>>>
>>> Starting from at least one important distinction:
>>>
>>> - is-a inheritance used where
>>> - has-a should have been used.
>> 
>> HAS-A to reuse modules?
> 
> In a place A, I use the features of a module M without
> introducing any of its naming issues into the facade
> of A.

This is not RE-use, it is just use. Reuse is when the problem domain
remains same and the code is used to solve a slightly different problem it
solved before.

Plain use of modules obtained per inheritance imposes no problem
whatsoever, because the method these modules were obtained is usually
irrelevant to the end user.

>> To start with you cannot have HAS-A on subprograms
>> in Ada.
> 
> I mentioned delegate objects,

Ada does not support delegation. But if it did, delegation would produce
same problems as inheritance does.

The problem is that there is no any problem, it is how things are.

> This idea blends well, I think, with the subprogram
> types that you have mentioned. Meaning that subprograms
> are in fact objects.

First class subprogram might in the end be incompatible with strong typing.
Typed procedures for downward closures, yes, but no further. There are of
course issues with distributed programs (marshaling types, marshaling
operations).

> I fantasize that it does not blend well with grand unified
> type theory. Not saying that this lack is any good.

Quite possible so. I was always suspicious about functional programming
paradigm for being weakly or un-typed.

> To see the reason for the bias, consider "non-data type" as
> a hash table because implementing "non-data type" uses
> a hash table. I'd like a language to prevent this use of
> IS-A, rather than encourage it.

Is there such thing as a non-data type?

>>> Another hint at a possibly non-best way is the STL.
>> 
>> So the claim is that reuse of generic units does not suffer the problems
>> reuse of inherited operations have?
> 
> No. The STL does not seem to suffer, otherwise there would
> be huge pressure to change it to be IS-A all over the place.

Of course it does. Diamond diagram is trivial to construct with generics.
In fact much of fighting with Ada generics is about resolving diamond's
issues. Ada is a very poor help here. It takes incredible efforts to ensure
that all actual parameters of the formal parameters of a generic are
constrained to the required actuals. It is a huge pain to trace cascaded
instantiations and the compile is no help.

People believe that their pet methods are free of MI problems just because
they never arrive at the level of complexity for problems to show. They
replace MI with cut and paste.

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

Re: What would you like in Ada202X?

[Robert A Duff]

"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Le Fri, 27 Apr 2012 01:50:07 +0200, Randy Brukardt
> <randy@rrsoftware.com>  a �crit:
>> Probably this would have to wait for Ada-prime (or perhaps Bob Duff's
>> language :-).
> He did design one? Where can we read about?

It's not ready for publication.  Unfortunately, I can't work
on it full time.

- Bob

Re: What would you like in Ada202X?

[Robert A Duff]

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

> OK, but there must be a way to ensure that each non-anonymous entity would
> have at least one unique name valid for all contexts were it is accessible.
> It is already a problem.

In my language, every named thing must have a unique name.
It can also have an overloaded name.

So it doesn't have trouble with "pragma Mumble(Overloaded);",
as Ada does.

>> 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;
>
> More overloading cannot make legal programs illegal.

I don't think that's true, at least if you want to avoid
Beaujolais-like effects.  That is, if X hides an outer X,
a legal program can refer to the inner X.  If the language
were changed so the two X's are both visible, and overloaded,
it could be ambiguous.

Hiding is evil.  It's a preference rule, and it already
causes Beaujolais-like effects.

- Bob

Re: What would you like in Ada202X?

[mjsilva]

I want Ada to be as easy to use on smaller, popular 32-bit embedded processors as C is now.  And I don't want to have to wait until 202x.

And I'm continuously surprised that hardly anybody else seems to think this is a goal worth pursuing.

Re: What would you like in Ada202X?

[Adam Beneschan]

On Friday, April 27, 2012 12:41:50 AM UTC-7, Jacob Sparre Andersen wrote:
> Georg Bauhaus wrote:
> 
> > 0) Which features do you think can be dropped from Ada?
> 
> I would like to drop (most of) the predefined numerical types from
> package Standard.  We have to keep Duration, but are any of the other
> numerical types in Standard really required by the language?  (Natural
> and Integer'Base are used in the declaration of "**".  Is there a
> sensible way around that?)

They're also used for String types and in lots of places in predefined packages.

> And the rationale: I believe that avoiding predefined types will limit
> the temptation to use the same type (or two types) for all numerical
> objects.

No, it won't.  If you took the predefined types out of the language, programmers would just define their own types in a "common types" package and use those for all (or most) numerical objects.  The alternative would be insanity.

I appreciate the thinking--if programmers gave some thought to every numerical object in their program, and defined their numerical types with appropriate ranges and in a way that accidental inappropriate type conversions couldn't occur between two objects where the numbers have different meanings, it would cut down on errors.  But there's a point where things become too burdensome, and  IMHO having to think about the type of every number used in computations is past that point.  Sure, in an ideal, theoretical world in which theoretical programmers theoretically have 83 hours in a day and limitless theoretical mental energy, it would make sense if programmers did this kind of rigorous analysis on every little piece of their programs.  But we're trying to design a language that real people are going to use, so some balances have to be struck.

                         -- Adam

Re: What would you like in Ada202X?

[Shark8]

On Thursday, April 26, 2012 7:18:02 PM UTC-5, sbelm...@gmail.com wrote:
> 
> 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?!

I thought stubs were an accepted software engineering/design practice...

Re: What would you like in Ada202X?

[Simon Wright]

Martin <martin@thedowies.com> writes:

> 4) 'Image for records/arrays
>
> Or some means of iterating through each component, obtaining its name
> and values, such that I could write my own function quickly.
>
> 5) The ability to override the 'Image function
> 6) An alternative to 'Image that doesn't have a leading space for integers!

For symmetry, I suppose we'd need 'Value as well. Some might say it's
less important, and if the only use of 'Image is in debugging, I might
agree; but I've come across a case (white-box functional testing) where
I needed both, Value so I could specify inputs and expected outputs, and
Image so I could report when the results were wrong.

Re: What would you like in Ada202X?

[sbelmont700]

On Friday, April 27, 2012 12:04:33 PM UTC-4, Shark8 wrote:
> 
> I thought stubs were an accepted software engineering/design practice...

procedure Shut_Down_Reactor (Reactor : Reactor_Type) is null;

is quite literally a disater waiting to happen.  Ada is all about being explicit, and takes a harsh stance on things that could be misused or abused to make a program confusing (i.e. overloading, etc), yet it gives an express lane for writing subprograms that by definition don't do what they intend.  The phrase "where the default behavior is null" is a contridiction in terms; calling a subprogram to achieve the effect of not calling a subprogram is simply bananas.

Re: What would you like in Ada202X?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:11hojzrgyl24o$.1rbxahkuoy4ab$.dlg@40tude.net...
> On Thu, 26 Apr 2012 18:58:06 -0500, Randy Brukardt wrote:
...
>> I've concluded that I'm pretty much against all forms of MI.
>
> Do not both Integer and Float implement "is private", T'Image, X'Size? MI
> is all around you without any tagged types, you cannot get rid of it. You
> sweep it under the carpet and pretend it does not exist.

These examples might be "M" (multiple), but they don't represent "I" 
(inheritance) -- you can't (and shouldn't) inherit these things other than 
linearly.

Note that the things that you mentioned are called "categories", 
"characteristics", and "aspects", respectively, in Ada. You could put them 
all under the unbrella of "properties", but what's important here is that 
the rules are necessarily different for each grouping. For instance, 
"categories" are not necessarily inherited, and can be view-specific (like 
"is private"). There is no way to unify these rules (we tried for Ada 2005 
when we discovered they were poorly defined), because the needs are 
different.

I could imagine extending the "aspect/attribute" feature to user-defined 
aspect/attribute pairs; that would properly mimic the idea of specific 
properties applying to particular types. That's all interfaces really gives 
you anyway, in a much more complicated way.

>> 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).
>
> That is because the broken Java model was deployed. Look you cannot make a
> type non-limited by adding "private" (=copyiable) interfaces. There is no
> problem, except for fighting shadows.

There are of course problems with any model, and they're a lot more than 
shadows. If you have a copyable interface, you of course might copy it -- so 
what happens if the actual object is a limited type? Runtime failures are 
ugly at best, and go completely against the grain of Ada's philosophy of 
preventing errors at compile-time.

If you're willing to abandon all compile-time checking, then of course there 
are no problems (and probably no programs that work, either). That's not 
Ada.

In any case, interfaces is barely compatible with Ada, and a more general 
scheme is impossible -- it would be completely unimplementable. You'd need 
to start over with a new language and new, from scratch implementations 
(which are not happening for Ada).

                                    Randy.

Re: What would you like in Ada202X?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1xjgrplu1bsor$.47yv0ce0fyef$.dlg@40tude.net...
> On Thu, 26 Apr 2012 19:09:38 -0500, Randy Brukardt wrote:
...
>> Not sure what you mean by this; Ada has always had that policy.
>
> But not for use-clauses.

Use clauses cancel if there is any conflict, giving a required error. 
Perhaps you mean the preference for direct visibility? That isn't a 
"conflict" in any sense of the word; the use versions aren't visible at all 
in that case.

And that preference seems necessary because there would be no workaround to 
broken direct visibility (there is no prefix to use as there is in the 
use-clause case) - one of the root philosophies of Ada 83 was that there 
would always be a workaround to any visibility error (which is why Ada has 
the many ways to prefix identifiers and otherwise disambiguate).

                                       Randy.

Re: What would you like in Ada202X?

[Randy Brukardt]

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

"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message 
news:op.wderwrjxule2fv@douda-yannick...
...
>> 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).
>Formal proof? Or did you mean strong certitudes?

During the Ada 9x project, there was a "formal methods" team that was 
supposed to apply formal analysis to what became Ada 95. Their big "product" 
was a formal proof that there no Beaujolias effects in Ada 95. (There were a 
number of other teams, including several "user/implementer" teams that 
prototypes parts of the language -- I led one of those during Ada 9x.)

Of course, like most formal proofs, it was beyond my understanding, so I 
really have no idea if it was correct. But it definitely was done.

                                                     Randy.

Re: What would you like in Ada202X?

[Randy Brukardt]

<sbelmont700@gmail.com> wrote in message 
news:13849842.838.1335485882969.JavaMail.geo-discussion-forums@vbai3...
...
>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.

I presume you also would want to ban the allocation of object for such an 
access type, since it should never be the case that you can allocate objects 
but not be able to deallocate them. (That's a certain storage leak.)

And in that case, Ada 2012 has what you want (sort of): if you set the 
Storage_Size of an general access type to zero, it's illegal to allocate or 
call an instance of Unchecked_Deallocation on the type. See 13.11.2(3.1/3) 
and 4.8(5.4/3). (Why is the instance legal in this case? So that an 
instantiation of a generic that exports such an instantiation as a service 
to clients is still legal; otherwise you would need a separate generic for 
such access types, which is junk.)

                                 Randy.

Re: What would you like in Ada202X?

[Randy Brukardt]

<sbelmont700@gmail.com> wrote in message 
news:2867357.127.1335561067669.JavaMail.geo-discussion-forums@ynee1...
>procedure Shut_Down_Reactor (Reactor : Reactor_Type) is null;
>
>is quite literally a disater waiting to happen.

Sure, but bad management is not a reason to not include a language feature 
that is useful.

> Ada is all about being explicit,

And this *is* explicit. It says "is null", it doesn't imagine that.

>and takes a harsh stance on things that could be misused or abused to make 
>a program confusing (i.e. overloading, >etc), yet it gives an express lane 
>for writing subprograms that by definition don't do what they intend.

This is a significant misreading of Ada's design. Ada 83 included operator 
overloading, even though it is EASY to abuse that to write a confusing 
program:

     function "*" (Left, Right : My_Type) return My_Type is
     begin
          return Left + Right;
     end "*";

The Ada 83 Rationale has an explicit statement about this; the feature was 
included because it was useful, even though it can be misused.

And there are many other features (new and old) that can be abused.

We've talked about this several times in the ARG, and our feeling is that it 
is not our job (or the language's job) to prevent intentional misuse of the 
language. What Ada strives for is eliminating *unintentional* misuse; it 
hard to see that in this case (this is clearly intentional). There is no 
replacement for sensible and enforced programming style (and management that 
understands that without being heavy-handed).

Null procedures are intended to be used in places where doing nothing is a 
reasonable default action. For instance, when you have a "hook" that you 
wouldn't always use. One example was the (eventually rejected) storage pool 
dereference procedure; most pools would have no use for it, so it could be a 
null procedure; pools that did have a use for it could replace it with 
something interesting.

Note that Ada 95 did that (implicitly) for the Initialize/Adjust/Finalize 
routines of type Controlled. We made that more explicit in Ada 2005, but 
that did not reflect any language change. This is another example of a 
"hook".

Using a null procedure for something that must have an action is a serious 
bug, one that could not fail to be caught by a code review (it's hard to 
miss the very explicit "is null" in the code).

> The phrase "where the default behavior is null" is a contridiction in 
> terms; calling
> a subprogram to achieve the effect of not calling a subprogram is simply 
> bananas.

As noted above, it's common to have "hook" routines that aren't used in most 
implementations. It's impossible in general to remove those calls, so what 
else would you have the subprogram do??

                                      Randy.

Re: What would you like in Ada202X?

[Randy Brukardt]

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

"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message 
news:op.wdeqz6wkule2fv@douda-yannick...
Le Fri, 27 Apr 2012 01:50:07 +0200, Randy Brukardt <randy@rrsoftware.com>
a �crit:
>> I tried to suggest making objects overloadable
>I'm not sure to see. Objects of the same name with different types in the 
>same declaration list?
>
>    E : Cat_Type;
>    E : Rabbit_Type;
>
>?

I don't think I went that far, but they would be overloadable for the 
purposes of resolution. So you would not get a conflict if those two objects 
were declared in different packages made visible by use-clauses.

This is essentially the idea that you (was it you?) have talked about about 
making functions and constants work the same. It wouldn't make sense to do 
that for *only* constants (changing something from a constant to a variable 
shouldn't break any uses!), but it could make sense for all objects.

>> Probably this would have to wait for Ada-prime (or perhaps Bob Duff's
>> language :-).
>He did design one? Where can we read about?

I think it's only in his head. He mentions it here from time-to-time.

                                 Randy.

Re: What would you like in Ada202X?

[sbelmont700]

On Friday, April 27, 2012 7:18:34 PM UTC-4, Randy Brukardt wrote:

> Note that Ada 95 did that (implicitly) for the Initialize/Adjust/Finalize 
> routines of type Controlled. We made that more explicit in Ada 2005, but 
> that did not reflect any language change. This is another example of a 
> "hook".

But this, along with the other hooks, seems like a relic of a single-inheritance version of Ada.  A much (well, perhaps just slightly) better version would be to split things up into multiple interfaces.  For instance, instead of just extending Ada.Finalization and getting all three hooks regardless, you split the three routines into three different one-subprogram interfaces.  Types extend exactly which ones they want, and not the ones they don't.  If you don't want Finalization or Initialization, then you only extend the Ada.Finalization.Adjustable (e.g.), and you no longer have usless subprograms being called to perform usless actions, and any mistakes (forgetting to implement one, trying to implement another, etc) are caught at compile time.  Types get exactly what they ask for, and nothing they don't.  Why leave to a human what can be done by the compiler?

-sb

Re: What would you like in Ada202X?

[BrianG]

On 04/27/2012 11:33 AM, mjsilva@scriptoriumdesigns.com wrote:
> I want Ada to be as easy to use on smaller, popular 32-bit embedded processors as C is now.  And I don't want to have to wait until 202x.
>
> And I'm continuously surprised that hardly anybody else seems to think this is a goal worth pursuing.

I don't think it's an uncommon position here, but how do you pursue 
this, and who does the pursuing?  I doubt language-designers can do much 
(except add curly-brackets :-).

It takes convincing the embedded processor makers/distributors (or the 
community) to make compilers available.

Of course, if you can get GCC on the processor, you can also have GNAT - 
without tasking, run time, etc.  "No_Run_Time" is not difficult. 
Perhaps it would help to have a "Minimal_Run_Time" also (e.g. the 
features available using nothing but the C runtime available on a basic 
GCC port - preferably with an Ada flavor, not just a binding), at least 
for GNAT.  Then you need any processor- or system-specific library bindings.

-- 
---
BrianG
000
@[Google's email domain]
.com

Re: What would you like in Ada202X?

[Adam Beneschan]

On Friday, April 27, 2012 4:40:50 PM UTC-7, sbelm...@gmail.com wrote:
> On Friday, April 27, 2012 7:18:34 PM UTC-4, Randy Brukardt wrote:
> 
> > Note that Ada 95 did that (implicitly) for the Initialize/Adjust/Finalize 
> > routines of type Controlled. We made that more explicit in Ada 2005, but 
> > that did not reflect any language change. This is another example of a 
> > "hook".
> 
> But this, along with the other hooks, seems like a relic of a single-inheritance version of Ada.  A much (well, perhaps just slightly) better version would be to split things up into multiple interfaces.  For instance, instead of just extending Ada.Finalization and getting all three hooks regardless, you split the three routines into three different one-subprogram interfaces.  Types extend exactly which ones they want, and not the ones they don't.  If you don't want Finalization or Initialization, then you only extend the Ada.Finalization.Adjustable (e.g.), and you no longer have usless subprograms being called to perform usless actions, and any mistakes (forgetting to implement one, trying to implement another, etc) are caught at compile time.  Types get exactly what they ask for, and nothing they don't.  Why leave to a human what can be done by the compiler?

How is this possibly going to work with class-wide types?  Sure, it's not common to call Initialize/Adjust/Finalize directly in a program, but consider some other abstract type T that has procedure methods A, B, and C.  For one type T1 derived from T, it makes sense that A and B would be no-ops.  For another type T2 derived from T, A and B would do something.  Maybe for another derived type T3, A would do something but C would be a no-op.  Now you want to write a procedure that takes an argument Obj of type T'Class (or access-to-T'Class), and that procedure wants to call method A and/or B and/or C (and is perfectly fine with one or more of those procedures being no-ops).  How can it do this, if you say A, B, and C can't be defined as primitives of type T but have to be defined in some other interface or something like that?  Whatever solution you're going to come up with, it's not worth it.  It would require a lot of rigmarole to implement a rather common situation, and requiring all that extra junk seems likely to make things more error-prone than the problem you're trying to solve.  

                       -- Adam

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Le Sat, 28 Apr 2012 01:25:45 +0200, Randy Brukardt <randy@rrsoftware.com>  
a écrit:

> "Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message
> news:op.wdeqz6wkule2fv@douda-yannick...
> Le Fri, 27 Apr 2012 01:50:07 +0200, Randy Brukardt <randy@rrsoftware.com>
> a écrit:
>>> I tried to suggest making objects overloadable
>> I'm not sure to see. Objects of the same name with different types in  
>> the
>> same declaration list?
>>
>>    E : Cat_Type;
>>    E : Rabbit_Type;
>>
>> ?
>
> I don't think I went that far, but they would be overloadable for the
> purposes of resolution. So you would not get a conflict if those two  
> objects
> were declared in different packages made visible by use-clauses.
>
> This is essentially the idea that you (was it you?) have talked about  
> about making functions and constants work the same.
Yes, was me (red‑face)

> It wouldn't make sense to  do
> that for *only* constants (changing something from a constant to a  
> variable
> shouldn't break any uses!), but it could make sense for all objects.
Good point, indeed.

-- 
“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

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Fri, 27 Apr 2012 17:42:24 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:11hojzrgyl24o$.1rbxahkuoy4ab$.dlg@40tude.net...
>> On Thu, 26 Apr 2012 18:58:06 -0500, Randy Brukardt wrote:
> ...
>>> I've concluded that I'm pretty much against all forms of MI.
>>
>> Do not both Integer and Float implement "is private", T'Image, X'Size? MI
>> is all around you without any tagged types, you cannot get rid of it. You
>> sweep it under the carpet and pretend it does not exist.
> 
> These examples might be "M" (multiple), but they don't represent "I" 
> (inheritance) -- you can't (and shouldn't) inherit these things other than 
> linearly.

You inherit interface here.

> Note that the things that you mentioned are called "categories", 
> "characteristics", and "aspects", respectively, in Ada.

This is only a game of words. However you name it, it will have all
properties of MI.

> You could put them 
> all under the unbrella of "properties", but what's important here is that 
> the rules are necessarily different for each grouping. For instance, 
> "categories" are not necessarily inherited, and can be view-specific (like 
> "is private").

You cannot inherit a category. Category = class. You can belong to a
category or not. Inheritance is nothing but a proposition that some T
belongs to some class (category). This means that it has characteristics,
properties, attributes of members from the class = implements the interface
of the class. MI is nothing but an ability for T to participate in more
than just one class.

> There is no way to unify these rules (we tried for Ada 2005 
> when we discovered they were poorly defined), because the needs are 
> different.
 
Maybe, because desire to do it was not that pressing?

> I could imagine extending the "aspect/attribute" feature to user-defined 
> aspect/attribute pairs; that would properly mimic the idea of specific 
> properties applying to particular types. That's all interfaces really gives 
> you anyway, in a much more complicated way.

In a typed way, you mean? Ad-hocery never pays off.

>>> 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).
>>
>> That is because the broken Java model was deployed. Look you cannot make a
>> type non-limited by adding "private" (=copyiable) interfaces. There is no
>> problem, except for fighting shadows.
> 
> There are of course problems with any model, and they're a lot more than 
> shadows. If you have a copyable interface, you of course might copy it -- so 
> what happens if the actual object is a limited type?

Limited types do not implement that interface per definition. When you
inherit both from "limited private" and from "private" you have a conflict
to resolve. Ada does this using a set of hand-written rules which readers
of RM certainly enjoy. This is an example of a MI problem which exists
without MI being named, for which Javaesque interfaces have no answer.

> If you're willing to abandon all compile-time checking, then of course there 
> are no problems (and probably no programs that work, either). That's not 
> Ada.

No, I want exactly the opposite. I want interfaces checked statically. You
cannot do this without manifesting them up-front. You cannot do that
without MI, because any type implements a whole of bunch of various
interfaces. I want them declared.
 
> In any case, interfaces is barely compatible with Ada, and a more general 
> scheme is impossible -- it would be completely unimplementable.

So long there is no desire to do this, yes.

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

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Fri, 27 Apr 2012 16:40:50 -0700 (PDT), sbelmont700@gmail.com wrote:

> On Friday, April 27, 2012 7:18:34 PM UTC-4, Randy Brukardt wrote:
> 
>> Note that Ada 95 did that (implicitly) for the Initialize/Adjust/Finalize 
>> routines of type Controlled. We made that more explicit in Ada 2005, but 
>> that did not reflect any language change. This is another example of a 
>> "hook".
> 
> But this, along with the other hooks, seems like a relic of a
> single-inheritance version of Ada.  A much (well, perhaps just slightly)
> better version would be to split things up into multiple interfaces.

No, construction is not inheritance. Constructor is not a method.
Initialize/Adjust/Finalize are hooks called from constructor and destructor
proper. It is very unfortunate that Ada dress them up as primitive
operations which they are not.

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

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Fri, 27 Apr 2012 09:56:36 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> OK, but there must be a way to ensure that each non-anonymous entity would
>> have at least one unique name valid for all contexts were it is accessible.
>> It is already a problem.
> 
> In my language, every named thing must have a unique name.
> It can also have an overloaded name.

Is the name space same? One could have a separate name space for unique
names.

>>> 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;
>>
>> More overloading cannot make legal programs illegal.
> 
> I don't think that's true, at least if you want to avoid
> Beaujolais-like effects.  That is, if X hides an outer X,
> a legal program can refer to the inner X.  If the language
> were changed so the two X's are both visible, and overloaded,
> it could be ambiguous.

So the imaginary setup is:

1. X and inner X are unambiguous: not Clash (X, inner X)
2. X hides outer X: Clash (X, outer X)
3. outer X and inner X are ambiguous: Clash (outer X, inner X)

This looks broken already. Ambiguity must be transitive:

   Clash (X, outer X) and  Clash (outer X, inner X) => Clash (X, inner X)

If not transitive, that must be fixed even if backward incompatible.

> Hiding is evil.

Yes, sometimes handy. My pet idea is that instead of hiding the language
should require to rename the offending outer entities.

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

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Fri, 27 Apr 2012 17:46:13 -0500, Randy Brukardt wrote:

> Perhaps you mean the preference for direct visibility? That isn't a 
> "conflict" in any sense of the word; the use versions aren't visible at all 
> in that case.

Which is what the problem is, they silently hide each other.

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

Re: What would you like in Ada202X?

[björn lundin]

Den torsdagen den 26:e april 2012 kl. 17:20:44 UTC+2 skrev Simon Wright:
 
> 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).

But it does work, with some additional tools.
When I ported our system to gnat in 2003, the project files were not good enough.
So I wrote a frontend in tcl, with a flat file for configuring the 'ada library'

This makes it possible to override a src file with another, based
on its location in the file system


I associated a object directory with a file path
 $SRC/sql     $ADA_LIB_ROOT/global
 $SRC/qb/     $ADA_LIB_ROOT/global/qb
 $SRC/qb/test $ADA_LIB_ROOT/global/qb/test
 #-------
 $TRG/qb     $ADA_LIB_ROOT/global/qb

these are parsed and put into $ADA_OBJECTS_PATH and $ADA_INCLUDE_PATH
from the leaf,
so that having actual code in $SRC/qb, 
and an overiding package in $SRC/qb/test will make the 
test package be linked into the process, 
if I link from $TRG/qb.


from pwd, I find the associated object lib. from there, I look for leaves.
so the object path will look like

$ADA_LIB_ROOT/global/qb/test:$ADA_LIB_ROOT/global/qb:$ADA_LIB_ROOT/global

Then I use that path to contruct the ADA_INCLUDE_PATH.
first add those src paths that are associated with 

$ADA_LIB_ROOT/global/qb/test
then all src paths that are associated with
$ADA_LIB_ROOT/global/qb
and finally  src paths that are associated with
$ADA_LIB_ROOT/global
 
and i use the -i option of gnatmake to get the .o file where the .ali file is.
and the script cretates an .ali file for each .adb/.ads in that object structure on beforehand

--
Björn Lundin

Re: What would you like in Ada202X?

[okellogg]

On Thursday, April 26, 2012 2:50:26 AM UTC+2, Hibou57 (Yannick Duchêne) 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”).

Which reminds me to refresh another longstanding wish:
Allow child packages of nested packages as described at
https://groups.google.com/forum/?fromgroups#!msg/comp.lang.ada/RHhA1CpYDcA/ArR1n1HgFRoJ

-- Oliver

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Le Sat, 28 Apr 2012 09:53:45 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>> If you're willing to abandon all compile-time checking, then of course  
>> there
>> are no problems (and probably no programs that work, either). That's not
>> Ada.
>
> No, I want exactly the opposite. I want interfaces checked statically.  
> You cannot do this without manifesting them up-front. You cannot do that
> without MI, because any type implements a whole of bunch of various
> interfaces. I want them declared.

I'm on the way to be convinced.

-- 
“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

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Le Sat, 28 Apr 2012 10:32:44 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>> Hiding is evil.
>
> Yes, sometimes handy. My pet idea is that instead of hiding the language
> should require to rename the offending outer entities.

AdaControl can help here.


-- 
“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

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Le Sat, 28 Apr 2012 13:02:17 +0200, <okellogg@users.sourceforge.net> a  
écrit:

> On Thursday, April 26, 2012 2:50:26 AM UTC+2, Hibou57 (Yannick Duchêne)  
> 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”).
>
> Which reminds me to refresh another longstanding wish:
> Allow child packages of nested packages as described at
> https://groups.google.com/forum/?fromgroups#!msg/comp.lang.ada/RHhA1CpYDcA/ArR1n1HgFRoJ
>
> -- Oliver

You reminds me I had the same wish some months ago. I agree with this one.  
I had to twist everything due to this lack, and the result was in no way  
expressive (unfortunately, I don't remember anymore which package it was  
exactly).

-- 
“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

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 Apr 2012 10:01:48 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
>> 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:
>
> […]


I forget one: separate name‑space for type and object names.

-- 
“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

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Sat, 28 Apr 2012 13:40:40 +0200, Yannick Duch�ne (Hibou57) wrote:

> Le Sat, 28 Apr 2012 09:53:45 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
>>> If you're willing to abandon all compile-time checking, then of course there
>>> are no problems (and probably no programs that work, either). That's not
>>> Ada.
>>
>> No, I want exactly the opposite. I want interfaces checked statically.  
>> You cannot do this without manifesting them up-front. You cannot do that
>> without MI, because any type implements a whole of bunch of various
>> interfaces. I want them declared.
> 
> I'm on the way to be convinced.

You didn't say by whom. (:-))

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

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Le Wed, 25 Apr 2012 10:01:48 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> Mine:
> […]

Another one, from a Ludovic's quote elsewhere, I agree with (it happaned I  
felt the same)

Le Tue, 17 Apr 2012 05:43:49 +0200, Randy Brukardt <randy@rrsoftware.com>  
a écrit:

> "Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message
> news:4f8c93a0$0$6638$9b4e6d93@newsspool2.arcor-online.net...
>> On 16.04.12 20:00, Dmitry A. Kazakov wrote:
> ...
>>> Counter example:
>>
>> Only in case of universally quantified propositions. None of my  
>> business.
>> But anyway,
>>
>>>     procedure Leave (When : Time);
>> ...
>> begin
>>    while Now < When loop
>>       delay Step;
>>       Now := Clock;
>>    end loop;
>>    Left (Slot (When)) := Now;  -- NB p.p. of to leave
>> end Leave;
>>
>> I have tried to choose only unspecific or ambiguous nouns.
>> Do you find this to be explaining itself well? Note the "well,"
>> not: possible to understand for the next few moments.
>
> This is irrelevant, because Ada requires the names of the parameters to  
> be
> those used in *calls*. The names used in the body probably ought to be
> nouns, but in calls, verbs or adjectives often work better:
>
>     Leave (When => Now);
>
> It is a smallish fault of Ada, in fact, because there almost never are  
> names
> that work well both in calls and in the body.

Ability to give parameters, different names, one for body and one for  
invokation place.

Actually, one can fake it choosing a name well suited for call‑places  
(where nothing can be done) and to use renaming of parameters in the body  
(this, is something that can be done). That said, this is far to be a  
priority, as we have renaming.

-- 
“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

Re: What would you like in Ada202X?

[BrianG]

On 04/28/2012 09:21 AM, Yannick Duchêne (Hibou57) wrote:
> Le Wed, 25 Apr 2012 10:01:48 +0200, Yannick Duchêne (Hibou57)
> <yannick_duchene@yahoo.fr> a écrit:
...
> Le Tue, 17 Apr 2012 05:43:49 +0200, Randy Brukardt
> <randy@rrsoftware.com> a écrit:
>
>> "Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message
>> news:4f8c93a0$0$6638$9b4e6d93@newsspool2.arcor-online.net...
...
>> This is irrelevant, because Ada requires the names of the parameters
>> to be
>> those used in *calls*. The names used in the body probably ought to be
>> nouns, but in calls, verbs or adjectives often work better:
>>
>> Leave (When => Now);
>>
>> It is a smallish fault of Ada, in fact, because there almost never are
>> names
>> that work well both in calls and in the body.
>
> Ability to give parameters, different names, one for body and one for
> invokation place.
>
> Actually, one can fake it choosing a name well suited for call‑places
> (where nothing can be done) and to use renaming of parameters in the
> body (this, is something that can be done). That said, this is far to be
> a priority, as we have renaming.
>
This is a problem that I would hate to see "fixed".  It would cause 
headaches for maintenance.  Imagine I have a large body of code that I 
have to maintain.  In researching a problem, I find something like
    This_Is_A_Procedure (Its_Parameter => Some_Value);
My problem relates to Some_Value, so I have to trace Its_Parameter.  I 
search for it, but it only occurs in this line and in the spec of 
This_Is_A_Procedure; the body, I guess, uses a different name in this 
"fix".  So I have to go from the call, to the spec parameter, to the 
body parameter, to the usages; I have to do this for every call, in 
every chain, every time.  That makes maintenance a pain.

With the "fake", there is a single line that associates the 'external' 
and 'internal' names.  I still have to do two searches, but I can't 
choose the way the code was written.

BTW, you can use a renames, or you can assign to a local variable, or to 
a local constant if the parameter is not going to be modified.

-- 
---
BrianG
000
@[Google's email domain]
.com

Re: What would you like in Ada202X?

[Shark8]

On Friday, April 27, 2012 4:11:07 PM UTC-5, sbelm...@gmail.com wrote:
> On Friday, April 27, 2012 12:04:33 PM UTC-4, Shark8 wrote:
> > 
> > I thought stubs were an accepted software engineering/design practice...
> 
> procedure Shut_Down_Reactor (Reactor : Reactor_Type) is null;
> 
> The phrase "where the default behavior is null" is a contridiction in terms; calling a subprogram to achieve the effect of not calling a subprogram is simply bananas.

This is plainly false. Consider a cleanup/freeing procedure in a component-based RAD style program* when it is applied to a form having both components and [sub-]forms which contain both components and forms themselves. 

Having the base COMPONENT with a null procedure for its free is absolutely reasonable, especially if the inherited classes need not do anything special to ensure they are properly disposed of. The form and all of its component-containing children, however, must do something else: pass the free command to those children.


* I'm assuming a class hierarchy with a base COMPONENT type and two branches: the first a CONTAINER class which can hold other components (like visual controls); and one, say ITEM, which is for components which cannot have components added (like a timer). {Yes, this could be done differently, perhaps with an abstract base-class, but then you have the problem that there is no default at all and each actual object of COMPONENT would have to declare its own personal free-procedure....}

Re: What would you like in Ada202X?

[Shark8]

On Friday, April 27, 2012 5:59:09 AM UTC-5, Martin wrote:
> 
> 5) The ability to override the 'Image function
> 6) An alternative to 'Image that doesn't have a leading space for integers!
> 
> -- Martin

I thought I read about a way to do a user-defined Image function that would override the default 'Image attribute... but, alas, I cannot find it.

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Sat, 28 Apr 2012 20:52:31 -0700 (PDT), Shark8 wrote:

> On Friday, April 27, 2012 5:59:09 AM UTC-5, Martin wrote:
>> 
>> 5) The ability to override the 'Image function
>> 6) An alternative to 'Image that doesn't have a leading space for integers!
>> 
>> -- Martin
> 
> I thought I read about a way to do a user-defined Image function that
> would override the default 'Image attribute... but, alas, I cannot find it.

simply by making all attributes primitive operations.

However, attributes of like T'Image (X) should be replaced with X'Image.
You don't need to mention T if 'Image is primitive.

If we go a little further, we will notice that Image is doubly dispatching
on its argument of T and the result of String, which should be from a class
that includes Wide_String, Unbounded_String etc.

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

Re: What would you like in Ada202X?

[J-P. Rosen]

Le 27/04/2012 09:41, Jacob Sparre Andersen a �crit :
> And the rationale: I believe that avoiding predefined types will limit
> the temptation to use the same type (or two types) for all numerical
> objects.

Unfortunately, I have seen too many industrial projects that forbid the
use of predefined type, but where people define:
   type Byte is range 0..255;
and then use only this all over the place...

No language rule can compensate for insufficient training!
-- 
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: What would you like in Ada202X?

[gautier_niouzes]

> However, attributes of like T'Image (X) should be replaced with X'Image.

+1 vote (rather: X'Image would be an alternative to T'Image(X), for compatibility reasons).
So we'd be less tempted to use X'Img that is GNAT-only... 
_________________________
Gautier's Ada programming
http://gautiersblog.blogspot.com/search/label/Ada

Re: What would you like in Ada202X?

[Robert A Duff]

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

> On Fri, 27 Apr 2012 09:56:36 -0400, Robert A Duff wrote:
>> In my language, every named thing must have a unique name.
>> It can also have an overloaded name.
>
> Is the name space same?

Yes.

>...One could have a separate name space for unique
> names.

I'm not sure what you mean.  Usually "separate name space"
implies distinguishing which name space you're referring
to via some syntactic means.  For example, Ada could have
a separate namespace for labels, because they can only
appear after "goto" and inside <<...>>.

Oops, I forgot about Label'Address.  Nix that.

> So the imaginary setup is:
>
> 1. X and inner X are unambiguous: not Clash (X, inner X)
> 2. X hides outer X: Clash (X, outer X)
> 3. outer X and inner X are ambiguous: Clash (outer X, inner X)

I'm not sure what you mean.  I'm suggesting (and, I think, Randy was) a
rule where everything is overloadable, and if you have two things called
X, neither hides the other.  This is the way use-visibility work in Ada,
but only for subprograms.  Single namespace.

The name resolution rules would need to be completely rewritten,
but the basic idea is that if you can't tell which X it is
(based on those rules), it's ambiguous and therefore illegal.

There's no need to prevent clashes.  If you say:

    X: constant Integer := 123;
    X: constant Integer := 456;

(both in the same scope) then all references to X would be
ambiguous.  So don't do that.

These rules would not be compatible, therefore they won't
happen, and I'm not seriously proposing them.

> This looks broken already. Ambiguity must be transitive:
>
>    Clash (X, outer X) and  Clash (outer X, inner X) => Clash (X, inner X)

I agree that ambiguity should be transitive, and never meant
to suggest otherwise.  That is, if you swap inner X and outer X,
it wouldn't change the ambiguity of complete contexts that
have visibility on both.

> If not transitive, that must be fixed even if backward incompatible.

Well, we know you don't care very much about compatibility,
but I assure you ARG would be tarred and feathered if we
threw compatibility concerns out the window.  And rightly so.
The Ada 9X team and the ARG already get grumbling about the
fairly modest incompatibilities that were introduced.

There are all sorts of improvements that could be made
to Ada (or any other language) if we didn't care about
compatibility.  But the end result would be a different
language, and should therefore have a different name.

>> Hiding is evil.
>
> Yes, sometimes handy. My pet idea is that instead of hiding the language
> should require to rename the offending outer entities.

I should have said "Implicit hiding is evil."  Or "Accidental hiding is
evil."  I wouldn't mind having a feature like "hide X, Y, Z;", which
explicitly makes everything with those names vanish.

But anyway we're not going to get rid of implicit hiding in Ada
-- way too incompatible.

- Bob

Re: What would you like in Ada202X?

[Robert A Duff]

okellogg@users.sourceforge.net writes:

> Which reminds me to refresh another longstanding wish:
> Allow child packages of nested packages as described at
> https://groups.google.com/forum/?fromgroups#!msg/comp.lang.ada/RHhA1CpYDcA/ArR1n1HgFRoJ

Ideally, nested packages and child packages would have
identical semantics.  Switching from one to the other
would not change anything.  That's almost, but not quite,
true, and your suggestion above is one example where
it's not true.

- Bob

Re: What would you like in Ada202X?

[sbelmont700]

On Saturday, April 28, 2012 11:20:49 PM UTC-4, Shark8 wrote:

> This is plainly false. Consider a cleanup/freeing procedure in a component-based RAD style program* when it is applied to a form having both components and [sub-]forms which contain both components and forms themselves. 
> 
> Having the base COMPONENT with a null procedure for its free is absolutely reasonable, especially if the inherited classes need not do anything special to ensure they are properly disposed of. The form and all of its component-containing children, however, must do something else: pass the free command to those children.
> 
> 
> * I'm assuming a class hierarchy with a base COMPONENT type and two branches: the first a CONTAINER class which can hold other components (like visual controls); and one, say ITEM, which is for components which cannot have components added (like a timer). {Yes, this could be done differently, perhaps with an abstract base-class, but then you have the problem that there is no default at all and each actual object of COMPONENT would have to declare its own personal free-procedure....}

I would still argue that 'null' is not the *default* behavior.  The default of 'free' is to deallocate something, and there are just certain special circumstances where that involves doing nothing.  Defaulting to null saves you writing 6 words in these special cases, while circumventing a compile-time check if you forget to implement it in all cases, and that's a bad deal (and seems orthogonal to everything else in the language).

And, as you said, there are other (better) ways this could be done with abstract parents, or even better using some sort of auto-deallocation so that you don't need a 'free' at all.  In any case, abstraction should never violate type safety, and if an operation is not appropriate for a type, it shouldn't be able to be called at all, and certainly not automatically swept under the carpet by the language.  Otherwise, where does it stop?  If Sea_Plane extends Plane, and Plane has Extend_Landing_Gear, do we make it null because "it makes sense to be a nop" for a Sea_Plane?  What do we do with Retract_Landing_Gear?  Could the same argument be applied to, say, a Gallon_Of_Milk type?  Landing gear operation is just as applicable to a Sea_Plane as it is to a Gallon_of_Milk, yet one is OK but the other is not?  What would a post-condition for a null procedure ever be, if there is no gaurentee that anything will ever get done?

If you need a null procedure in an interface, then your type hierarchy needs work.  Now that there are interfaces, all it is just shuffling around types.  Is it also too much rigmarole to properly organize numeric types into subtypes so that only applicable values can be used?  Why then is is suddenly so much trouble to do it for tagged record types so that only applicalbe operations can be used?  With the same example, Plane should be abstract and split into an abstract Fixed_Gear and Variable_Gear, and then Regular_Plane and Sea_Plane derived from each.  Calls to manipulate landing gear for planes that don't have it will fail at compile time.

-sb

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Sun, 29 Apr 2012 09:35:30 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>>...One could have a separate name space for unique
>> names.
> 
> I'm not sure what you mean.  Usually "separate name space"
> implies distinguishing which name space you're referring
> to via some syntactic means.

Yes, a certain prefix for example.

>> So the imaginary setup is:
>>
>> 1. X and inner X are unambiguous: not Clash (X, inner X)
>> 2. X hides outer X: Clash (X, outer X)
>> 3. outer X and inner X are ambiguous: Clash (outer X, inner X)
> 
> I'm not sure what you mean.

That more overloading cannot break existing programs, or else there is a
very serious language design bug.

> There's no need to prevent clashes.  If you say:
> 
>     X: constant Integer := 123;
>     X: constant Integer := 456;
> 
> (both in the same scope) then all references to X would be
> ambiguous.  So don't do that.

I see this approach problematic, because ambiguity may stay undetected
until very late, in a context where it cannot be fixed anymore, a context
maintained by another programmer etc. It contradicts to the principle of
detecting potential problems as early as possible.

>> This looks broken already. Ambiguity must be transitive:
>>
>>    Clash (X, outer X) and  Clash (outer X, inner X) => Clash (X, inner X)
> 
> I agree that ambiguity should be transitive, and never meant
> to suggest otherwise.  That is, if you swap inner X and outer X,
> it wouldn't change the ambiguity of complete contexts that
> have visibility on both.

If ambiguity is transitive, then, I have no proof, of course, but my gut
feeling tells me, that it will be impossible to produce ambiguity the way
you described.

>> If not transitive, that must be fixed even if backward incompatible.
> 
> Well, we know you don't care very much about compatibility,

On the contrary, but

1. I also see things rationally. If the language requires 2+2=5, that has
to be fixed even if would break some programs. (There is a hierarchy of
priorities)

2. Compatibility is a handy weapon in the hands of ARG to reject anything
without considering if there will be any compatibility problems actually!
(:-))

> but I assure you ARG would be tarred and feathered if we
> threw compatibility concerns out the window.  And rightly so.
> The Ada 9X team and the ARG already get grumbling about the
> fairly modest incompatibilities that were introduced.

There are plenty examples when incompatibility was introduced with no gain
(e.g. reserving words like "interface"), or causing considerable damage
(changed semantics of returned limited objects).

> But anyway we're not going to get rid of implicit hiding in Ada
> -- way too incompatible.

Nobody seriously considered this, because the problem is way under the
radar of most people who are really capable to design the language. The
purpose of comp.lang.ada is to make them interested... (:-))

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

Re: What would you like in Ada202X?

[okellogg]

On Sunday, April 29, 2012 3:43:21 PM UTC+2, Robert A Duff wrote:
> 
> Ideally, nested packages and child packages would have
> identical semantics.  Switching from one to the other
> would not change anything.  That's almost, but not quite,
> true, and your suggestion above is one example where
> it's not true.

Could you elaborate?

Thanks.

-- Oliver

Re: What would you like in Ada202X?

[Robert Love]

On 2012-04-29 07:57:12 +0000, J-P. Rosen said:

> Le 27/04/2012 09:41, Jacob Sparre Andersen a �crit :
>> And the rationale: I believe that avoiding predefined types will limit
>> the temptation to use the same type (or two types) for all numerical
>> objects.
> 
> Unfortunately, I have seen too many industrial projects that forbid the
> use of predefined type, but where people define:
>    type Byte is range 0..255;
> and then use only this all over the place...

Yes, I've done it.  What would you recommend instead?


> 
> No language rule can compensate for insufficient training!

Re: What would you like in Ada202X?

[Robert A Duff]

okellogg@users.sourceforge.net writes:

> Could you elaborate?

package P is
    package Q is
    private
    end Q;
private
end P;

package body P is
    package body Q is
    end Q;
end P;

In the above nested case:
P spec can see things in Q spec (imagine all sorts of declarations
 at various places above).
Private part of Q cannot see things in private part of P.
Nobody can say "with P.Q;".
If you say "with P;" you can automatically see Q.
Q cannot have its own with clauses.
The one you mentioned: you can't have a child "package P.Q.R is".
Q spec is elaborated in the middle of elaborating P spec,
 and similarly for the bodies.
Etc.

If we transform that structure into child packages:

package P is
private
end P;

package P.Q is
private
end P.Q;

package body P is
end P;

package body P.Q is
end P.Q;

Now every statement I made above about the nested case
is no longer true.  I don't like that.  I think the semantics
of the two above structures should be identical.  Unfortunately,
that was impossible, because child packages were added later,
and we couldn't change nested packages in any incompatible ways.

- Bob

Re: What would you like in Ada202X?

[Robert A Duff]

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

> That more overloading cannot break existing programs, or else there is a
> very serious language design bug.

OK, then there's a language design bug.  I'm not sure it's
serious.

>> There's no need to prevent clashes.  If you say:
>> 
>>     X: constant Integer := 123;
>>     X: constant Integer := 456;
>> 
>> (both in the same scope) then all references to X would be
>> ambiguous.  So don't do that.
>
> I see this approach problematic, because ambiguity may stay undetected
> until very late, in a context where it cannot be fixed anymore, ...

Can't happen.  If anybody writes code referring to X, it will
be illegal.  At that time, there cannot already be any (legal)
uses of X.  Therefore the problem CAN be fixed (presumably by
deleting one of the X declarations, or changing its name).

>...a context
> maintained by another programmer etc.

OK, I admit that the person who adds code referring to X
might be confused by two utterly useless X's.
Assuming it's a different person.

>...It contradicts to the principle of
> detecting potential problems as early as possible.

I'm all for detecting problems early.  But this case doesn't
seem like that big of a deal.  If you do proper unit testing,
you'll catch it right away.

Anyway, I said, "no NEED to prevent clashes".  You could have
a special rule for this case (as Ada already does for
homographs), but it's not necessary for a coherent language
design.

>>> This looks broken already. Ambiguity must be transitive:
>>>
>>>    Clash (X, outer X) and  Clash (outer X, inner X) => Clash (X, inner X)
>> 
>> I agree that ambiguity should be transitive, and never meant
>> to suggest otherwise.  That is, if you swap inner X and outer X,
>> it wouldn't change the ambiguity of complete contexts that
>> have visibility on both.
>
> If ambiguity is transitive, then, I have no proof, of course, but my gut
> feeling tells me, that it will be impossible to produce ambiguity the way
> you described.

I think that would be true if Ada didn't have implicit hiding.
What I'm suggesting is that if you changed Ada to be
"everything is overloadable", then you'd also want to get
rid of implicit hiding, and THAT's what can cause an
incompatibility.

>>> If not transitive, that must be fixed even if backward incompatible.
>> 
>> Well, we know you don't care very much about compatibility,
>
> On the contrary, but
>
> 1. I also see things rationally. If the language requires 2+2=5, that has
> to be fixed even if would break some programs. (There is a hierarchy of
> priorities)
>
> 2. Compatibility is a handy weapon in the hands of ARG to reject anything
> without considering if there will be any compatibility problems actually!
> (:-))

I see the smiley, but seriously, I don't see that happening.
In fact, ARG desperately wants to design nice clean language
features, and it's extremely frustrating when the requirement
for compatibility prevents it.  That's why it's so much more
fun to design a new language.

Of course, "nice clean" is somewhat a matter of opinion.

>> but I assure you ARG would be tarred and feathered if we
>> threw compatibility concerns out the window.  And rightly so.
>> The Ada 9X team and the ARG already get grumbling about the
>> fairly modest incompatibilities that were introduced.
>
> There are plenty examples when incompatibility was introduced with no gain
> (e.g. reserving words like "interface"),...

Don't blame that one on ARG.  ARG proposed to add non-reserved
keywords several times, which would have been compatible,
but WG9 (the parent committee of ARG) shot it down every time.

>...or causing considerable damage
> (changed semantics of returned limited objects).

I've never understood your viewpoint on that.
You keep talking about "true constructors" or "proper
constructors" or something, but you didn't outline your
design in enough detail for me to understand.

- Bob

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Le Sun, 29 Apr 2012 21:04:34 +0200, Robert A Duff  
<bobduff@shell01.theworld.com> a écrit:

> okellogg@users.sourceforge.net writes:
>
>> Could you elaborate?
>
> package P is
>     package Q is
>     private
>     end Q;
> private
> end P;
>
> package body P is
>     package body Q is
>     end Q;
> end P;
>
> In the above nested case:
> P spec can see things in Q spec (imagine all sorts of declarations
>  at various places above).

Yes, and that's useful to define a set of preliminary types needed for the  
definition of a types, which is to be defined in P. Then, I like to do it  
all in Q, avoiding overlong and bloat name which would inevitably be there  
if ever another types follow some similar pattern in P. Unfortunately, if  
you do this, you cannot give Q any child packages, and if you make Q a  
child package, it cannot anymore access stuff already defined in p.

package P

    type Comment_Type …;

    package Q1
       type Role1_Type;
       type Role2_Type;
       type Uuseful_Type;
       -- Useful type defined based on role 1 and role 2
       -- and common type.
    end Q1;

    subtype Some_Type is Q1.Useful_Type;

    package Q2
       type Role1_Type;
       type Role2_Type;
       type Useful_Type;
       -- Note how the pattern is the same as in Q1.
    end Q2;

    subtype Another_Type is Q2.Useful_Type;

end P;


-- 
“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

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Le Sun, 29 Apr 2012 21:04:34 +0200, Robert A Duff
<bobduff@shell01.theworld.com> a écrit:

> okellogg@users.sourceforge.net writes:
>
>> Could you elaborate?
>
> package P is
>     package Q is
>     private
>     end Q;
> private
> end P;
>
> package body P is
>     package body Q is
>     end Q;
> end P;
>
> In the above nested case:
> P spec can see things in Q spec (imagine all sorts of declarations
>  at various places above).

Yes, and that's useful to define a set of preliminary types needed for the
definition of a type, which is to be defined in P. Then, I like to do it
all in Q, avoiding overlong and bloated name which would inevitably be  
there
if ever another types follow some similar pattern in P. Unfortunately, if
you do this, you cannot give Q any child packages, and if you make Q a
child package, it cannot anymore access stuff already defined in p.

package P

      type Comment_Type …;

      package Q1
         type Role1_Type;
         type Role2_Type;
         type Uuseful_Type;
         -- Useful type defined based on role 1 and role 2
         -- and common type.
      end Q1;

      subtype Some_Type is Q1.Useful_Type;

      package Q2
         type Role1_Type;
         type Role2_Type;
         type Useful_Type;
         -- Note how the pattern is the same as in Q1.
      end Q2;

      subtype Another_Type is Q2.Useful_Type;

end P;

Without Q1 and Q2, you would have to give so much different names that the  
common pattern would be less clear, or else would have to use prefix like  
“Q1_” or “Q2_”, which in turn suggest to use nested or child packages.

Not a general case example, just a case I remember.

-- 
“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

Re: What would you like in Ada202X?

[Robert A Duff]

"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Yes, and that's useful to define a set of preliminary types needed for the
> definition of a type, which is to be defined in P. Then, I like to do it
> all in Q, avoiding overlong and bloated name which would inevitably be
> there
> if ever another types follow some similar pattern in P. Unfortunately, if
> you do this, you cannot give Q any child packages, and if you make Q a
> child package, it cannot anymore access stuff already defined in p.

Exactly.

It would be nice if a parent spec could 'with' it's children.
That feature can't be added to Ada without major surgery.

We do allow it for 'limited with', but that's rather restrictive.

- Bob

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Sun, 29 Apr 2012 15:27:10 -0400, Robert A Duff wrote:

>>> There's no need to prevent clashes.  If you say:
>>> 
>>>     X: constant Integer := 123;
>>>     X: constant Integer := 456;
>>> 
>>> (both in the same scope) then all references to X would be
>>> ambiguous.  So don't do that.
>>
>> I see this approach problematic, because ambiguity may stay undetected
>> until very late, in a context where it cannot be fixed anymore, ...
> 
> Can't happen.  If anybody writes code referring to X, it will
> be illegal.

And if he does not? Library packages declare lots of things they don't use
themselves.

> If you do proper unit testing,
> you'll catch it right away.

Here applies another language design principle: anything that can be
checked statically has to be.
 
> In fact, ARG desperately wants to design nice clean language
> features, and it's extremely frustrating when the requirement
> for compatibility prevents it.  That's why it's so much more
> fun to design a new language.
> 
> Of course, "nice clean" is somewhat a matter of opinion.

Yes, it seems that the trend is towards adding orthogonal features, which I
don't consider either nice or clean. To me "nice clean" is when features
are removed (moved to the library level) replaced by fewer, more general
ones.

>>> but I assure you ARG would be tarred and feathered if we
>>> threw compatibility concerns out the window.  And rightly so.
>>> The Ada 9X team and the ARG already get grumbling about the
>>> fairly modest incompatibilities that were introduced.
>>
>> There are plenty examples when incompatibility was introduced with no gain
>> (e.g. reserving words like "interface"),...
> 
> Don't blame that one on ARG.  ARG proposed to add non-reserved
> keywords several times, which would have been compatible,
> but WG9 (the parent committee of ARG) shot it down every time.

What was wrong with already existed

   abstract tagged null record

?

>>...or causing considerable damage
>> (changed semantics of returned limited objects).
> 
> I've never understood your viewpoint on that.

The semantics was changed, that is.

> You keep talking about "true constructors" or "proper
> constructors" or something, but you didn't outline your
> design in enough detail for me to understand.

I tried, but that is irrelevant.

As for constructors, the point, rather a trivial observation, is that you
cannot initialize raw memory with a subprogram in a sanely typed way. It is
up to you, a language designer, to come up with something else. The working
name for that thing is "constructor." Add here a few quite obvious
requirements on the design: safety upon inheritance, safety upon exceptions
raised in the middle of the process, safety against dispatch on not yet
constructed components, safety when some entities are tasks, prevention of
explicit invocation. Here you are.

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

Re: What would you like in Ada202X?

[okellogg]

On Sunday, April 29, 2012 9:04:34 PM UTC+2, Robert A Duff wrote:
> 
> package P is
>     package Q is
>     private
>     end Q;
> private
> end P;
> 
> package body P is
>     package body Q is
>     end Q;
> end P;
> 
> In the above nested case:
> P spec can see things in Q spec (imagine all sorts of declarations
>  at various places above).

Right. This appears natural to me because of the physical nesting: The full source text of Q spec is known to P spec once we're past the "end Q;".

> Private part of Q cannot see things in private part of P.

Again due to the physical nesting: At the point of Q's declaration the source text of P private part has not yet been seen.
Thinking ahead, P.Q.R would differ in this respect as child R could see the private parts of its parent packages - IIUC a consequence of R's physical separation of the source text.

> Nobody can say "with P.Q;".
> If you say "with P;" you can automatically see Q.
> Q cannot have its own with clauses.

I'll admit, the fact that "with P.Q;" is illegal but "with P.Q.R;" would be legal seems a bit non-intuitive at first.

> The one you mentioned: you can't have a child "package P.Q.R is".
> Q spec is elaborated in the middle of elaborating P spec,
>  and similarly for the bodies.

This does not change when Q is extended by child R: P and P.Q are elaborated before child R.

> If we transform that structure into child packages:
> [...]
> 
> Now every statement I made above about the nested case
> is no longer true.  I don't like that.  I think the semantics
> of the two above structures should be identical. [...]

If I play parser I can see why they are semantically different - but not in any way that would present an obstacle to my proposal, unless I'm overlooking something.

Thanks,

  Oliver

Re: What would you like in Ada202X?

[Robert A Duff]

okellogg@users.sourceforge.net writes:

> If I play parser I can see why they are semantically different - but
> not in any way that would present an obstacle to my proposal, unless
> I'm overlooking something.

Yes.  I was not arguing against your proposal.
Just generalizing it (in a way that won't work).

- Bob

Re: What would you like in Ada202X?

[Shark8]

On Sunday, April 29, 2012 10:42:54 AM UTC-5, sbelm...@gmail.com wrote:
> On Saturday, April 28, 2012 11:20:49 PM UTC-4, Shark8 wrote:
> 
> I would still argue that 'null' is not the *default* behavior.  The default of 'free' is to deallocate something, and there are just certain special circumstances where that involves doing nothing.

Which is precisely why it *should* be the default behavior: it is idempotent.
If some component is a clock, then it could have a null deallocation because it only needs to be able to read (and process) the computer's clock; this means there are only procedures associated with this object, as the data is the time (likely memory-mapped) and to "free"/zero-out that data would at best do nothing, at worst reset the clock to some incorrect time.

On the other hand if it (the component) is something like a file parser, the free command needs to ensure that the file is closed and the handle returned to the pool for use.

> Defaulting to null saves you writing 6 words in these special cases, while circumventing a compile-time check if you forget to implement it in all cases,

No, it saves significantly more than that. If it were an abstract method, then EACH component-containing component would need a free procedure AND every non-containing component would need to implement a null-procedure for its free-method (remember, with a base-class being abstract it needs to have a valid FREE method in order to be a concrete object/class).

>and that's a bad deal (and seems orthogonal to everything else in the language).


Wait, I thought orthogonality was, generally, a good thing.

> And, as you said, there are other (better) ways this could be done with abstract parents,

I did not say "better", I said there were other ways (without weighing the general-designs against each other at all).

> or even better using some sort of auto-deallocation so that you don't need a 'free' at all.

In all likelihood an auto-deallocate would be an null procedure which is extended by the other classes. (i.e. doing what we've described, but in this case hidden from the programmer.)

> In any case, abstraction should never violate type safety, and if an operation is not appropriate for a type, it shouldn't be able to be called at all, and certainly not automatically swept under the carpet by the language. 

That's just it though. Thing like the free/deallocate mentioned ARE valid for all types in that class-hierarchy, it's just that (even as you admitted) sometimes it's a NOP.

> Otherwise, where does it stop?  If Sea_Plane extends Plane, and Plane has Extend_Landing_Gear, do we make it null because "it makes sense to be a nop" for a Sea_Plane?  

Well, if Plane is an interface with Extend_Landing_Gear, and Sea_Plane uses Plane, then you bet it does. (Otherwise Sea_Plane violates the contract that is the interface.)

>What do we do with Retract_Landing_Gear? 

Exactly the appropriate thing.

> Could the same argument be applied to, say, a Gallon_Of_Milk type?  Landing gear operation is just as applicable to a Sea_Plane as it is to a Gallon_of_Milk, yet one is OK but the other is not?

No. Gallon_of_Milk is not a Plane, therefore there's no reason that it should have Extend_Landing_Gear... unless you're making it implement the PLANE interface.

> What would a post-condition for a null procedure ever be, if there is no gaurentee that anything will ever get done?

Easy; Post condition would be True. (Always succeed.)
Or, going back to the Plane example, perhaps Extend_Landing_Gear has a post_condition of "Landing_Gear_Deployed" returning true. {And in Sea_Plane's case that would be a function that just returns True; in Boeing_777's case it would return true only checking that the gear was down.}

> If you need a null procedure in an interface, then your type hierarchy needs work.

Not so; just as my Component AND your Plane examples show. 

The same argument could be made against a function that returns a constant for an entire [sub-]hierarchy. And in fact, lets move to the hierarchy of animals, let's say that there is a Rutting function which returns true if that particular animal can mate (and produce offspring) in things like deer it would involve a lookup into the Calander, in Primates it would simply return true: thus making monkeys and humans have "no mating season."

> Now that there are interfaces, all it is just shuffling around types.  Is it also too much rigmarole to properly organize numeric types into subtypes so that only applicable values can be used?

What are you talking about?
I do this a lot and would be surprised if others here didn't.
(In fact, before my HD crashed a year ago I was working on a very-thick OpenGL binding which wouldn't have allowed bad values to be passed to the parameters.)

> Why then is is suddenly so much trouble to do it for tagged record types so that only applicalbe operations can be used?  With the same example, Plane should be abstract and split into an abstract Fixed_Gear and Variable_Gear, and then Regular_Plane and Sea_Plane derived from each.  Calls to manipulate landing gear for planes that don't have it will fail at compile time.

Even if you could get by with an
"If Plane not in Fixed_Gear" [...] for a general auto-landing program, why should that heirchy be forced into such a split? Suppose someone wants to keep the heiarchy more linear (with that point being an "extend from here" for users)?

Specifically, I could see it being useful for GUI-programming; as was said about having callback-hooks suppose you had a WINDOW component and attached some OpenGL handler to it, then maybe it would make sense to have the clear or free (or whatever) be null and only overriden when it needed to be.

(What I'm saying is that some user could have FUN_WINDOW extend WINDOW w/o having to mess with anything except the items/properties he's working on; say altering how it responds to mouse movement, he doesn't CARE about overriding the free or clear, he just wants to play with the mouse... on the other hand, another user may want to have an ACCELERATED_WINDOW and he has to have a function deallocating that particular handle when he closes the window but doesn't give a crap about the mouse input.)

That is to say, a NULL procedure may be a valid alternative to providing an abstract class especially when there would be numerous methods that would need to be defined in order to derive even one of those branches.

Re: What would you like in Ada202X?

[Shark8]

On Sunday, April 29, 2012 2:57:12 AM UTC-5, J-P. Rosen wrote:
> 
> No language rule can compensate for insufficient training!

That's not true! PHP can make even expertly designed projects look like they need training.

;)

Re: What would you like in Ada202X?

[sbelmont700]

On Sunday, April 29, 2012 7:29:24 PM UTC-4, Shark8 wrote:
> In all likelihood an auto-deallocate would be an null procedure which is extended by the other classes. (i.e. doing what we've described, but in this case hidden from the programmer.)
> 

The auto-deallocate scheme I was refering to is to remove the 'free' procedure entirely.  Whenever the object is finalized (by the language, not user-defined finalization), all the elements of the record will be finalized as well.  So the concrete type that contains some sort of Auto_Deallocated_File_Pointer type (that is, itself, controlled) would close the file pointer automatically, and concrete types that contain nothing would do just that.  Free doesn't exist, and certainly isn't null.

Generally I have found that schemes that rely on explictly calling deallocation routines are rarely, if ever, exception safe and normally tend to produce memory leaks.  If you have to deallocate 'n' items and an exception is raised after item 'x', then you leak the memory for n-x items (or have incomprehensible sets of nested exception handlers).  But this is beside the point.

> That's just it though. Thing like the free/deallocate mentioned ARE valid for all types in that class-hierarchy, it's just that (even as you admitted) sometimes it's a NOP.
> 

Having nothing to do is not the same as it having been done, and that's a dangerous philosophy to adhere to.  Free is not valid for a type if there is nothing to free, and extending landing gear is not valid for a plane with fixed gear.  If you were using a straight procedural model (without inheritance), would you go to all the trouble of creating a Free procedure without any code and calling it to accomplish nothing?  Trying to fake a common interface does not make for an abstract program.

Re: What would you like in Ada202X?

[Michael Rohan]

On Wednesday, April 25, 2012 12:47:06 AM UTC-7, 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
> 2) parallel loops / functions
> 3) Multiple dispatch
> 
> -- Martin

Hi,

I'd like to resurrect the discussion on Wide_Strings and OS interfacing, i.e.,
provide Ada.Wide_Directories, Ada.Wide_Command_Line, etc., how to transform a
Wide_String into something the underlying OS will understand should probably
be part of the runtime rather than having application trying to figure it out
in some portable, ad hoc, manner.

While on the subject of Wide_Strings, it would be "nice" to be able to use
them in the context of a "raise ... with" but the syntax and impact of this
would probably be too much.

Take care,
Michael.

Re: What would you like in Ada202X?

[Michael Rohan]

On Wednesday, April 25, 2012 12:47:06 AM UTC-7, 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
> 2) parallel loops / functions
> 3) Multiple dispatch
> > -- Martin

Hi Folks,

Here's another suggestion that will probably upset some people but it's
something I've run into with generated code: it would be nice to have a
more general "separate" (I seem to remember a posting on this thread about
how "separate" was bad!).  What I think would be somewhat useful would be
to allow separate definitions of initializations, e.g.,

    type Integer_List is array (Positive range <>) of Integer;
    My_Data : constant Integer_List := (1, 2, 3, 4);

If the data used to do the initialization is OS dependent, or otherwise
generated, it might be nice to do

    My_Data : constant Integer_List separate;

The separate source could then contain just the generated/OS dependent
data.

This particular syntax for the use of the "separate" keyword feels a
little ugly to me, but the underlying functionality is, I believe, valid.

Take care,
Michael.

Re: What would you like in Ada202X?

[Martin]

On Friday, April 27, 2012 6:05:16 PM UTC+1, Simon Wright wrote:
> Martin <martin@...com> writes:
> 
> > 4) 'Image for records/arrays
> >
> > Or some means of iterating through each component, obtaining its name
> > and values, such that I could write my own function quickly.
> >
> > 5) The ability to override the 'Image function
> > 6) An alternative to 'Image that doesn't have a leading space for integers!
> 
> For symmetry, I suppose we'd need 'Value as well. Some might say it's
> less important, and if the only use of 'Image is in debugging, I might
> agree; but I've come across a case (white-box functional testing) where
> I needed both, Value so I could specify inputs and expected outputs, and
> Image so I could report when the results were wrong.

Sorry Simon, I don't understand why we would need another 'Value?...
Integer'Value (" 1") => 1
Integer'Value ("1")  => 1

What am I missing?!
-- Martin

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Le Mon, 30 Apr 2012 08:40:00 +0200, Michael Rohan <michael@zanyblue.com> a  
écrit:
> Here's another suggestion that will probably upset some people but it's
> something I've run into with generated code: it would be nice to have a
> more general "separate" (I seem to remember a posting on this thread  
> about
> how "separate" was bad!).  What I think would be somewhat useful would be
> to allow separate definitions of initializations, e.g.,
>
>     type Integer_List is array (Positive range <>) of Integer;
>     My_Data : constant Integer_List := (1, 2, 3, 4);
>
> If the data used to do the initialization is OS dependent, or otherwise
> generated, it might be nice to do
>
>     My_Data : constant Integer_List separate;
>
> The separate source could then contain just the generated/OS dependent
> data.

As a practical alternative, you can define per‑platform bodies, and turn  
the constant into a pure function, whose implementation belongs to the  
body. Otherwise, if the matter is that your package interface is to  
explicitly expose platform specific definitions, then that suggest your  
interface is a platform interface, and you may rely on child packages, one  
for each platform. In any case, universal and platform specific  
definitions, should not be mixed, that leads to lack of clarity and  
maintenance troubles.

-- 
“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

Re: What would you like in Ada202X?

[gautier_niouzes]

Le jeudi 26 avril 2012 13:27:14 UTC+2, Hibou57 (Yannick Duchêne) a écrit :

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

+1 for the brillant idea! I improve it in my turn with: Range'Length.
(Width is already defined with another meaning; and Range'Length would match Some_Array'Length)
_________________________
Gautier's Ada programming
http://gautiersblog.blogspot.com/search/label/Ada
NB: follow the above link for a valid e-mail address

Re: What would you like in Ada202X?

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccipgihd99.fsf@shell01.TheWorld.com...
...
> I'm not sure what you mean.  I'm suggesting (and, I think, Randy was) a
> rule where everything is overloadable, and if you have two things called
> X, neither hides the other.  This is the way use-visibility work in Ada,
> but only for subprograms.  Single namespace.

For Ada, I wasn't suggesting any change in hiding rules (even subprograms 
can be hidden in Ada, after all). I was just suggesting that objects are 
overloadable by their profile, which would be the same as a parameterless 
function returning the type of the object. I think changing the hiding rules 
would have to be incompatible, I think just adding some overloading would 
not be incompatible (but since Steve Baird never analyzed it, I could be 
wrong :-). That's because I didn't plan on any change in visibility for 
things with the *right* profile, so if the program is currently legal, it 
would remain legal (either other declarations have the wrong profile or 
remain hidden). What would change is that programs which are currently 
illegal (because of use-clause cancelation) would become legal if exactly 
one of the candidates matched.

In any case, this idea would take some careful analysis, and its main 
purpose was to make "integrated packages" more possible -- which I'm not 
sure is ever really going to matter.

                                                         Randy.

Re: What would you like in Ada202X?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:19h14pweusucs$.1q59fpys2663d.dlg@40tude.net...
> On Fri, 27 Apr 2012 17:42:24 -0500, Randy Brukardt wrote:
>...
>> Note that the things that you mentioned are called "categories",
>> "characteristics", and "aspects", respectively, in Ada.
>
> This is only a game of words. However you name it, it will have all
> properties of MI.

You are not making any sense. There is no "inheritance" of these things; 
they're reconstructed or even lost for subsequent types. Privacy, for 
instance, is never inherited.

I can see why someone that thinks everything should be OOP might consider 
these "interfaces", but it is irrelevant because there is no inheritance, 
much less any multiple inheritance.

>> You could put them
>> all under the unbrella of "properties", but what's important here is that
>> the rules are necessarily different for each grouping. For instance,
>> "categories" are not necessarily inherited, and can be view-specific 
>> (like
>> "is private").
>
> You cannot inherit a category. Category = class. You can belong to a
> category or not. Inheritance is nothing but a proposition that some T
> belongs to some class (category). This means that it has characteristics,
> properties, attributes of members from the class = implements the 
> interface
> of the class. MI is nothing but an ability for T to participate in more
> than just one class.

You're right: it's just wording, and you're inventing your own meaning for 
them as you go. Which makes it impossible to have a useful discussion --  
which is too bad. I'm out of this one.

                                    Randy.

Re: What would you like in Ada202X?

[Randy Brukardt]

"Martin" <martin@thedowies.com> wrote in message 
news:31031393.3509.1335770929925.JavaMail.geo-discussion-forums@vbjb10...
...
>> > 5) The ability to override the 'Image function
>> > 6) An alternative to 'Image that doesn't have a leading space for 
>> > integers!
>>
>> For symmetry, I suppose we'd need 'Value as well. Some might say it's
>> less important, and if the only use of 'Image is in debugging, I might
>> agree; but I've come across a case (white-box functional testing) where
>> I needed both, Value so I could specify inputs and expected outputs, and
>> Image so I could report when the results were wrong.
>
> Sorry Simon, I don't understand why we would need another 'Value?...

I can't speak for Simon, but I would have guessed that his comment applied 
more to (5) than to (6): if you can override 'Image, you ought to be able to 
override 'Value as well. And if the language has additional predefined 
'Images, then there ought to be matching predefined 'Values as well.

                                           Randy.

Re: What would you like in Ada202X?

[Martin]

On Tuesday, May 1, 2012 3:45:16 AM UTC+1, Randy Brukardt wrote:
> "Martin" <martin@...com> wrote in message 
> news:31031393.3509.1335770929925.JavaMail.geo-discussion-forums@vbjb10...
> ...
> >> > 5) The ability to override the 'Image function
> >> > 6) An alternative to 'Image that doesn't have a leading space for 
> >> > integers!
> >>
> >> For symmetry, I suppose we'd need 'Value as well. Some might say it's
> >> less important, and if the only use of 'Image is in debugging, I might
> >> agree; but I've come across a case (white-box functional testing) where
> >> I needed both, Value so I could specify inputs and expected outputs, and
> >> Image so I could report when the results were wrong.
> >
> > Sorry Simon, I don't understand why we would need another 'Value?...
> 
> I can't speak for Simon, but I would have guessed that his comment applied 
> more to (5) than to (6): if you can override 'Image, you ought to be able to 
> override 'Value as well. And if the language has additional predefined 
> 'Images, then there ought to be matching predefined 'Values as well.
> 
>                                            Randy.

Ah, yes, that makes sense. Not something I've ever thought I needed but that's just me. I can think of a few times where I'd like to have overriden 'Image and <exaggeration>_millions_</exaggeration> of times where I wish 'Image didn't have a leading space!!

-- Martin

Re: What would you like in Ada202X?

[mjsilva]

On Friday, April 27, 2012 6:38:10 PM UTC-7, BrianG wrote:
> On 04/27/2012 11:33 AM, mj...igns.com wrote:
> > I want Ada to be as easy to use on smaller, popular 32-bit embedded processors as C is now.  And I don't want to have to wait until 202x.
> >
> > And I'm continuously surprised that hardly anybody else seems to think this is a goal worth pursuing.
> 
> I don't think it's an uncommon position here, but how do you pursue 
> this, and who does the pursuing?  

Well, looking at ARM alone, they report 16 million processors shipped every day - that's over 4 billion a year.  One would think somebody would want a piece of that development tools pie, especially since Ada is such a nice fit with even the smallest 32-bit chips that are becoming like jellybeans.

Re: What would you like in Ada202X?

[Simon Wright]

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

> "Martin" <martin@thedowies.com> wrote in message 
> news:31031393.3509.1335770929925.JavaMail.geo-discussion-forums@vbjb10...
> ...
>>> > 5) The ability to override the 'Image function
>>> > 6) An alternative to 'Image that doesn't have a leading space for 
>>> > integers!
>>>
>>> For symmetry, I suppose we'd need 'Value as well. Some might say it's
>>> less important, and if the only use of 'Image is in debugging, I might
>>> agree; but I've come across a case (white-box functional testing) where
>>> I needed both, Value so I could specify inputs and expected outputs, and
>>> Image so I could report when the results were wrong.
>>
>> Sorry Simon, I don't understand why we would need another 'Value?...
>
> I can't speak for Simon, but I would have guessed that his comment applied 
> more to (5) than to (6): if you can override 'Image, you ought to be able to 
> override 'Value as well. And if the language has additional predefined 
> 'Images, then there ought to be matching predefined 'Values as well.

My mistake; yes, Randy's right, it was for (5).

Re: What would you like in Ada202X?

[Shark8]

On Tuesday, May 1, 2012 2:28:26 AM UTC-5, Martin wrote:
> 
> Ah, yes, that makes sense. Not something I've ever thought I needed but that's just me. I can think of a few times where I'd like to have overriden 'Image and <exaggeration>_millions_</exaggeration> of times where I wish 'Image didn't have a leading space!!
> 
> -- Martin

Hm, why not rename Trim or make a subprogram/function that wraps it? 
Could the new expression functions perhaps do that? (I haven't played w/ them.)

Or, I suppose that since this is a "feature X would be cool" thread, something like String'Trim( "  DATA STRING  " ) to return "DATA STRING" attribute; much like we have Float'Truncation(X). Seems reasonable to me.

It might be a little wordier than some would like; but Ada's always emphasized readability, and the above method seems to fit in well, especially considering the 'Truncation attribute.

Re: What would you like in Ada202X?

[Jeffrey Carter]

On 05/01/2012 10:15 AM, Shark8 wrote:
>
> Hm, why not rename Trim or make a subprogram/function that wraps it? Could
> the new expression functions perhaps do that? (I haven't played w/ them.)
>
> Or, I suppose that since this is a "feature X would be cool" thread,
> something like String'Trim( "  DATA STRING  " ) to return "DATA STRING"
> attribute; much like we have Float'Truncation(X). Seems reasonable to me.
>
> It might be a little wordier than some would like; but Ada's always
> emphasized readability, and the above method seems to fit in well, especially
> considering the 'Truncation attribute.

At work we make heavy use of PragmARC.Images.

http://pragmada.x10hosting.com/

http://pragmada.co.cc/

-- 
Jeff Carter
"It's all right, Taggart. Just a man and a horse being hung out there."
Blazing Saddles
34

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Tue, 1 May 2012 10:15:43 -0700 (PDT), Shark8 wrote:

> Or, I suppose that since this is a "feature X would be cool" thread,
> something like String'Trim( "  DATA STRING  " ) to return "DATA STRING"
> attribute; much like we have Float'Truncation(X). Seems reasonable to me.
> 
> It might be a little wordier than some would like; but Ada's always
> emphasized readability, and the above method seems to fit in well,
> especially considering the 'Truncation attribute.

Neither adds anything to readability. T'Foo (X) attributes are just noise.
Float'Truncation (X) should have been X'Truncated or [X].

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

Re: What would you like in Ada202X?

[Robert A Duff]

Shark8 <onewingedshark@gmail.com> writes:

> It might be a little wordier than some would like; but Ada's always
> emphasized readability, and the above method seems to fit in well,
> especially considering the 'Truncation attribute.

Gratuitous verbosity does not enhance readability.
An attribute that takes away a ' ' that shouldn't
have been there in the first place?  Yuck.
What were they thinking?

At this point, the ONLY reason for that extra space
is compatibility.

- Bob

Re: What would you like in Ada202X?

[tmoran]

> An attribute that takes away a ' ' that shouldn't
> have been there in the first place?  Yuck.
> What were they thinking?
>
> At this point, the ONLY reason for that extra space
> is compatibility.

  'Image without the space still wouldn't be good for really nicely
formatted output, and it would be very much less convenient for quick
debug or logging outputs.

Re: What would you like in Ada202X?

[Adam Beneschan]

On Tuesday, May 1, 2012 2:53:40 PM UTC-7, tmo...@acm.org wrote:
> > An attribute that takes away a ' ' that shouldn't
> > have been there in the first place?  Yuck.
> > What were they thinking?
> >
> > At this point, the ONLY reason for that extra space
> > is compatibility.
> 
>   'Image without the space still wouldn't be good for really nicely
> formatted output, and it would be very much less convenient for quick
> debug or logging outputs.

How would it be less convenient without the space?  A big problem is that 'Image adds an extra space for nonnegative numbers but not for negative numbers, so if you want debug or log output that doesn't look messy you either have to concatenate an extra space somewhere else and live with having two spaces in the output, or use Trim or something like that.  OK, I guess that if you know your numbers aren't negative maybe it might be OK.  But I've found the extra space to be a nuisance, including for debugging and logging outputs.

                        -- Adam

Re: What would you like in Ada202X?

[Shark8]

> > How would it be less convenient without the space?  A big problem is that 'Image adds an extra space for nonnegative numbers but not for negative numbers, so if you want debug or log output that doesn't look messy you either have to concatenate an extra space somewhere else and live with having two spaces in the output, or use Trim or something like that.

Well, it depends on the format of the debugging, doesn't it?
Consider the following (in a monospaced font)
Debug Log for simulation 128
Position_X: 13
Position_Y:-4
Turn_Index: 8
Ext_Damage: 14
Int_Damage: 0
Squid_Fire: True

Could it be written [formatted] better? Yes.
Could it be worse? XML.

It seems perfectly adequate to me.

> OK, I guess that if you know your numbers aren't negative maybe it might be OK.  But I've found the extra space to be a nuisance, including for debugging and logging outputs.
> 	Sounds like the formatting I'm used to from FORTRAN... The position
> for the sign indicator was always included in the width of the output
> field, whether or not "+" was printed or implied.

That's probably exactly where it came from. The interop w/FORTRAN would have given Ada a big boost in numeric processing "back in the day" and having 'Image and 'Value read/write that way by default ALSO meant that old data-files could more-easily be read in.

But, in any case
   Function Image( Input: In Integer ) Return String is
      use Ada.Strings, Ada.Strings.Fixed;
   begin
      Return Trim( Source => Integer'Image(Input), Side => Ada.Strings.Left );
   end Image;
is not too bad; the real downside is that currently we can't do something like:

   Function Image( Input: In Integer ) Return String Renames
      Ada.Strings.Fixed(
         Source => Integer'Image(Input), -- Have it "know" about the params passed
         Side => Ada.Strings.Left
       );
and have the whole thing in a spec file. (The 2012 standard fixes that so that we can have expressions named as functions, IIUC.) So, is this a big issue?

On the other hand, being able to override the 'Image (and 'Value) attributes might be appropriate.

Re: What would you like in Ada202X?

[Martin]

On Tuesday, May 1, 2012 6:15:43 PM UTC+1, Shark8 wrote:
> On Tuesday, May 1, 2012 2:28:26 AM UTC-5, Martin wrote:
> > 
> > Ah, yes, that makes sense. Not something I've ever thought I needed but that's just me. I can think of a few times where I'd like to have overriden 'Image and <exaggeration>_millions_</exaggeration> of times where I wish 'Image didn't have a leading space!!
> > 
> > -- Martin
> 
> Hm, why not rename Trim or make a subprogram/function that wraps it? 
> Could the new expression functions perhaps do that? (I haven't played w/ them.)

I do...all the time and it just becomes noise in the code.

-- Martin

Re: What would you like in Ada202X?

[Shark8]

On Wednesday, May 2, 2012 3:18:37 AM UTC-5, Martin wrote:
> On Tuesday, May 1, 2012 6:15:43 PM UTC+1, Shark8 wrote:
> > On Tuesday, May 1, 2012 2:28:26 AM UTC-5, Martin wrote:
> > > 
> > > Ah, yes, that makes sense. Not something I've ever thought I needed but that's just me. I can think of a few times where I'd like to have overriden 'Image and <exaggeration>_millions_</exaggeration> of times where I wish 'Image didn't have a leading space!!
> > > 
> > > -- Martin
> > 
> > Hm, why not rename Trim or make a subprogram/function that wraps it? 
> > Could the new expression functions perhaps do that? (I haven't played w/ them.)
> 
> I do...all the time and it just becomes noise in the code.
> 
> -- Martin

I see. That's rather disappointing to hear.

Re: What would you like in Ada202X?

[gautier_niouzes]

Am Dienstag, 1. Mai 2012 09:28:26 UTC+2 schrieb Martin:

> Ah, yes, that makes sense. Not something I've ever thought I needed but that's just me. I can think of a few times where I'd like to have overriden 'Image and <exaggeration>_millions_</exaggeration> of times where I wish 'Image didn't have a leading space!!

Same for me! Latest instance:
http://excel-writer.svn.sf.net/viewvc/excel-writer/extras/spreadsheet_references.adb?view=markup

See the curse on line 15.
BTW, it is a new package which is... Ada 83 compatible :-)
_________________________ 
Gautier's Ada programming 
http://sf.net/users/gdemont/

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Le Thu, 03 May 2012 17:30:16 +0200, <gautier_niouzes@hotmail.com> a écrit:

> Am Dienstag, 1. Mai 2012 09:28:26 UTC+2 schrieb Martin:
>
>> Ah, yes, that makes sense. Not something I've ever thought I needed but  
>> that's just me. I can think of a few times where I'd like to have  
>> overriden 'Image and <exaggeration>_millions_</exaggeration> of times  
>> where I wish 'Image didn't have a leading space!!
>
> Same for me! Latest instance:
> http://excel-writer.svn.sf.net/viewvc/excel-writer/extras/spreadsheet_references.adb?view=markup
>
> See the curse on line 15.

Lol, this “-- Skip the @#*$! leading space...” is not really a recommended  
style.

-- 
“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

Re: What would you like in Ada202X?

[Martin]

On Thursday, May 3, 2012 4:58:14 PM UTC+1, Hibou57 (Yannick Duchêne) wrote:
> Le Thu, 03 May 2012 17:30:16 +0200, <gautier_niouzes@hotmail.com> a écrit:
> 
> > Am Dienstag, 1. Mai 2012 09:28:26 UTC+2 schrieb Martin:
> >
> >> Ah, yes, that makes sense. Not something I've ever thought I needed but  
> >> that's just me. I can think of a few times where I'd like to have  
> >> overriden 'Image and <exaggeration>_millions_</exaggeration> of times  
> >> where I wish 'Image didn't have a leading space!!
> >
> > Same for me! Latest instance:
> > http://excel-writer.svn.sf.net/viewvc/excel-writer/extras/spreadsheet_references.adb?view=markup
> >
> > See the curse on line 15.
> 
> Lol, this “-- Skip the @#*$! leading space...” is not really a recommended  
> style.
> 
> -- 
> “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

I'd let it pass ;-)

-- Martin

Re: What would you like in Ada202X?

[Niklas Holsti]

On 12-04-25 10: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.

There is a proposal for extensible enumerated types, AI95-261 
(http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ais/ai-00261.txt), that was 
rejected (and I don't much like it, either). While reading John Barnes' 
second part of "Rationale for Ada 2012" in Ada User Journal, for some 
reason an idea came to me of a different and perhaps better concept of 
extension for enumerated types. I'm not sure that this would be a 
worth-while addition to Ada, but here it is, for your pleasure or 
displeasure, as briefly as I could write it.

The new concept can be describes as "extending enumerated types by 
deepening", where the AI95-261 concept is "extending by widening".

The terms "deepening" and "widening" come from seeing an enumerated type 
as a classification of some set of things. For example, the messages 
exhanged in some protocol could be classified in this way, initially and 
roughly:

    type Message_Kind1 is (Sign_On, Request, Reply, Sign_Off);

and some general operations might be written using only this rough 
classification. AI95-261 proposed the ability to derive a "wider" type 
with more literals, as in:

    type Wider_Message_Kind1 is new Message_Kind1 with (Tick, Ping);

The main problem with this extension by widening is that the derived 
type, Wider_Message_Kind1, is not a "subclass" of the parent type, 
because some values of the derived type (the new literals) cannot be 
converted to (or viewed as) values of the parent type. The derived type 
can't inherit operations from the parent type, because those operations 
can't handle the added values. AI95-261 suggests to raise 
Constraint_Error in such cases. Note how this differs from derived 
tagged types.

In "extension by deepening", the classification is not widened by adding 
more literals "at the end", but is deepened, or refined, by dividing 
some or all of the parent literals into a set of new literals, to give a 
more detailed classification.

In the protocol example, we can distinguish different kinds of Request: 
a read request or a write request, and different kinds of Reply: some 
data (in reply to a read request), an ack (in reply to a write request), 
or a refusal (in reply to any invalid request). The derivation syntax 
could be like this:

    type Detailed_Message_Kind is new Message_Kind1 with (
       Request => (Read, Write),
       Reply   => (Data, Ack, Refused),
       others  => <>);

The part "others => <>" is an abbreviation for "Sign_On => (Sign_On), 
Sign_Off => (Sign_Off)" and means that the literals Sign_On and Sign_Off 
are not refined in this derivation.

The derived enumerated type Detailed_Message_Kind has the following 
properties:

- Its literals are, in order: Sign_On, Read, Write, Data, Ack, Refused, 
Sign_Off. Note that the Message_Kind1 literals Request and Reply are not 
included, because they are refined into several new literals.

- It inherits all primitive operations of Message_Kind1, except those 
with "out" or "in out" parameters of type Message_Kind1, and except 
functions that return Message_Kind1. (See below for alternative rules.)

- Its values can be converted to type Message_Kind1 (including implicit 
conversion as an "in" parameter to an inherited operation) as follows:

    Sign_On  to Sign_On
    Read     to Request
    Write    to Request
    Data     to Reply
    Ack      to Reply
    Refused  to Reply
    Sign_Off to Sign_Off

- At least conceptually, a Detailed_Message_Kind value is represented by 
some "parent" bits that represent a Message_Kind1 value (default 
encodings 0 .. 3), plus some "extension" bits that are different for 
Read and Write (0 and 1), and different for Data, Ack, and Refused (0, 
1, and 2). For the Message_Kind1 literals that are not refined (Sign_On 
and Sign_Off) the extension bits are logically irrelevant but in 
practice would have a fixed value (zero seems natural).

- Conversion from Detailed_Message_Kind to Message_Kind1 keeps the 
parent bits and discards the extension bits.

- Conversion from Message_Kind1 to Detailed_Message_Kind is not allowed, 
because where would we get the values for the extension bits? This is 
why Detailed_Message_Kind does not inherit Message_Kind1 operations that 
produce values of type Message_Kind1. (An alternative design could 
define default values for the extension bits, for example that a Request 
is by default converted to a Read, but this seems a bit arbitrary. A 
further alternative is to allow conversion for literals that are not 
refined -- in the example, Sign_On and Sign_Off -- and raise 
Constraint_Error otherwise.)

This kind of enumeration extension has some nice features:

- It provides a way to describe hierarchical classifications in a 
value-based way, without involving references to tagged objects in a 
class hierarchy.

- The values that describe the classification are discrete scalars, 
which can be used as discriminants and to index arrays and case statements.

- The derived type inherits many operations of the parent type, and the 
derived type can substitute for the parent type (LSP).

Extension by deepening can also implement a form of "extension by 
widening", as follows: The parent type is provided with an extra literal 
to provide the "root" of any new literals to be added in derived types. 
For example, here we use the literal "More" for this:

    type Message_Kind2 is (Sign_On, Request, Reply, Sign_Off, More);

To "widen" the type by adding message-kinds Tick and Ping, the More 
literal is refined:

    type Wider_Message_Kind is new Message_Kind2 with (
       More   => (Tick, Ping, More),
       others => <>);

Note that we added also a new literal More, so that Wider_Message_Kind 
can be widened further. Wider_Message_Kind has the literals Sign_On, 
Request, Reply, Sign_Off, Tick, Ping, More. A conversion from 
Wider_Message_Kind to Message_Kind2 maps the literals Tick, Ping, and 
(the new) More to Message_Kind2'(More). Thus, the new literals are all 
seen as Message_Kind2'(More) within the operations that 
Wider_Message_Kind inherits from Message_Kind2.

As an option, some standard word or symbol could be standardized to 
serve the role of our "More" literal, above. For example, the reserved 
word "new" could be used for this. We could then come all the way back 
to AI95-261 as follows: if the parent type does not list "new" as a 
literal, but a derived type is derived by refining "new", then 
conversion from the derived type to the parent type is allowed only for 
the non-refined literals and raises Constraint_Error for the added 
literals. For example:

    type Wider_Message_Kind2 is new Message_Kind1 with
       new => (Tick, Ping, new);

(Here I have used an abbreviated syntax, unambiguous in this case, 
without the outermost parentheses and with an assumed "others => <>".)

Continuing to the next derivation level:

    type Widest_Message_Kind is new Wider_Message_Kind2 with
       new => (Greeting, Abort_Last_Request);

Now:

- Any value of Widest_Message_Kind can be converted to 
Wider_Message_Kind2. The literals Greeting and Abort_Last_Request are 
converted to Wider_Message_Kind2'(new).

- An attempt to convert the Wider_Message_Kind2 values Tick, Ping, or 
Wider_Message_Kind2'(new) to Message_Kind1 raises Constraint_Error 
(because Message_Kind1 does not list the "new" literal).

So, there it is. There is much that I haven't thought out, for example 
how representation clauses would work. But the main question is: would 
this feature be useful? Would it be too redundant with tagged types? 
What do you think?

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

Re: What would you like in Ada202X?

[Simon Wright]

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

This seems as if it could be very useful.

> As an option, some standard word or symbol could be standardized to
> serve the role of our "More" literal, above.

"others", perhaps? 

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Sun, 06 May 2012 21:48:00 +0300, Niklas Holsti wrote:

> On 12-04-25 10: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.
> 
> There is a proposal for extensible enumerated types, AI95-261 
> (http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ais/ai-00261.txt), that was 
> rejected (and I don't much like it, either). While reading John Barnes' 
> second part of "Rationale for Ada 2012" in Ada User Journal, for some 
> reason an idea came to me of a different and perhaps better concept of 
> extension for enumerated types. I'm not sure that this would be a 
> worth-while addition to Ada, but here it is, for your pleasure or 
> displeasure, as briefly as I could write it.
> 
> The new concept can be describes as "extending enumerated types by 
> deepening", where the AI95-261 concept is "extending by widening".
> 
> The terms "deepening" and "widening" come from seeing an enumerated type 
> as a classification of some set of things. For example, the messages 
> exhanged in some protocol could be classified in this way, initially and 
> roughly:
> 
>     type Message_Kind1 is (Sign_On, Request, Reply, Sign_Off);
> 
> and some general operations might be written using only this rough 
> classification. AI95-261 proposed the ability to derive a "wider" type 
> with more literals, as in:
> 
>     type Wider_Message_Kind1 is new Message_Kind1 with (Tick, Ping);
> 
> The main problem with this extension by widening is that the derived 
> type, Wider_Message_Kind1, is not a "subclass" of the parent type, 
> because some values of the derived type (the new literals) cannot be 
> converted to (or viewed as) values of the parent type. The derived type 
> can't inherit operations from the parent type, because those operations 
> can't handle the added values.

That depends on the operations. Extension is safe with out-operations.

> AI95-261 suggests to raise 
> Constraint_Error in such cases. Note how this differs from derived 
> tagged types.

Yes, for tagged types operations which are unsafe to inherit are inherited
abstract, e.g. functions returning covariant value.

> It  
> In "extension by deepening", the classification is not widened by adding 
> more literals "at the end", but is deepened, or refined, by dividing 
> some or all of the parent literals into a set of new literals, to give a 
> more detailed classification.
> 
> In the protocol example, we can distinguish different kinds of Request: 
> a read request or a write request, and different kinds of Reply: some 
> data (in reply to a read request), an ack (in reply to a write request), 
> or a refusal (in reply to any invalid request). The derivation syntax 
> could be like this:
> 
>     type Detailed_Message_Kind is new Message_Kind1 with (
>        Request => (Read, Write),
>        Reply   => (Data, Ack, Refused),
>        others  => <>);

[...]
> What do you think?

This looks like plain interface inheritance. You inherit the interface (the
literals of the type) dropping the implementation (encoding). Parent's
operations are inherited per composition with a type conversion.

I always wished to have this mechanism in Ada. Note that instead of
inventing some complicated syntax which purpose is basically to generate
conversion functions (four conversions are needed in most general case),
you should just allow the programmer to define them by himself. This would
also solve Character vs Wide_Character issue.

My opinion is that the language should provide very few fundamental
primitives rather than a forest of special cases. Unfortunately there is a
strong opposition to any move in this direction.

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

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

Le Sun, 06 May 2012 21:28:49 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> My opinion is that the language should provide very few fundamental
> primitives rather than a forest of special cases.

I believe the opposite since long, that is, distinct high‑level constructs  
help to understand the intents of a program. But this also requires to  
avoid redundancy (when there are too much different constructs for the  
same intent).


-- 
“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

Re: What would you like in Ada202X?

[Niklas Holsti]

On 12-05-06 22:27 , Simon Wright wrote:
> Niklas Holsti<niklas.holsti@tidorum.invalid>  writes:
 >>
 >> [ A new suggestion for extending enumerated types ]
 >
> This seems as if it could be very useful.

That's encouraging.

>> As an option, some standard word or symbol could be standardized to
>> serve the role of our "More" literal, above.
>
> "others", perhaps?

That was my first thought, but it becomes ambiguous, for example:

   type Enum is (A, B, C, others);

   E : Enum;

   case E is

   when A => ...

   when others => ...
      -- Does this mean (only) the special literal "others",
      -- or has it the classical meaning "all other literals not
      -- already mentioned"?

   end case;

In contrast, "when new" has no present meaning, so this is unambiguous:

    type Enum is (A, B, C, new);

    E : Enum;

    case E is

    when A => ...

    when new => ...

    when others => ...
       -- Meaning "when B | C =>".

    end case;

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

Re: What would you like in Ada202X?

[Niklas Holsti]

On 12-05-06 22:28 , Dmitry A. Kazakov wrote:
> On Sun, 06 May 2012 21:48:00 +0300, Niklas Holsti wrote:
>
>> On 12-04-25 10: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.
>>
>> There is a proposal for extensible enumerated types, AI95-261
>> (http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ais/ai-00261.txt), that was
>> rejected (and I don't much like it, either). While reading John Barnes'
>> second part of "Rationale for Ada 2012" in Ada User Journal, for some
>> reason an idea came to me of a different and perhaps better concept of
>> extension for enumerated types. I'm not sure that this would be a
>> worth-while addition to Ada, but here it is, for your pleasure or
>> displeasure, as briefly as I could write it.
>>
>> The new concept can be describes as "extending enumerated types by
>> deepening", where the AI95-261 concept is "extending by widening".
>>
>> The terms "deepening" and "widening" come from seeing an enumerated type
>> as a classification of some set of things. For example, the messages
>> exhanged in some protocol could be classified in this way, initially and
>> roughly:
>>
>>      type Message_Kind1 is (Sign_On, Request, Reply, Sign_Off);
>>
>> and some general operations might be written using only this rough
>> classification. AI95-261 proposed the ability to derive a "wider" type
>> with more literals, as in:
>>
>>      type Wider_Message_Kind1 is new Message_Kind1 with (Tick, Ping);
>>
>> The main problem with this extension by widening is that the derived
>> type, Wider_Message_Kind1, is not a "subclass" of the parent type,
>> because some values of the derived type (the new literals) cannot be
>> converted to (or viewed as) values of the parent type. The derived type
>> can't inherit operations from the parent type, because those operations
>> can't handle the added values.
>
> That depends on the operations. Extension is safe with out-operations.

Yes, you are right. In extension by widening, the parent type is a 
"subtype" (a subrange, really) of the derived type, so any value of the 
parent type is also a value of the derived type, and "out" works when 
inherited. But "in" (which I tend to think of as the usual role) has 
problems.

>
>> AI95-261 suggests to raise
>> Constraint_Error in such cases. Note how this differs from derived
>> tagged types.
>
> Yes, for tagged types operations which are unsafe to inherit are inherited
> abstract, e.g. functions returning covariant value.

The same could be done also for extension by deepening, but it is not 
needed, as long as we don't introduce tags and class-wide programming 
for these types. Inheriting these operations as abstract could even be 
inconvenient, since it would force the program to implement (override) 
the operations even when they are not needed.

>> In "extension by deepening", the classification is not widened by adding
>> more literals "at the end", but is deepened, or refined, by dividing
>> some or all of the parent literals into a set of new literals, to give a
>> more detailed classification.
>>
>> In the protocol example, we can distinguish different kinds of Request:
>> a read request or a write request, and different kinds of Reply: some
>> data (in reply to a read request), an ack (in reply to a write request),
>> or a refusal (in reply to any invalid request). The derivation syntax
>> could be like this:
>>
>>      type Detailed_Message_Kind is new Message_Kind1 with (
>>         Request =>  (Read, Write),
>>         Reply   =>  (Data, Ack, Refused),
>>         others  =>  <>);
>
> [...]
>> What do you think?
>
> This looks like plain interface inheritance. You inherit the interface (the
> literals of the type) dropping the implementation (encoding).

Not quite, because the derived type does not inherit the literals that 
are refined. Detailed_Message_Kind does not have the literals Request 
and Reply, because they have been refined into the literals Read and 
Write, and into the literals Data, Ack, and Refused, respectively.

If the derived type refines all the parent-type literals, the parent and 
derived types have no literals in common.

As for the representation, my intent was that it would be inherited, but 
extended with some more bits ("less significant" bits, in a way). So 
yes, the representation would be changed in some ways.

> Parent's
> operations are inherited per composition with a type conversion.

Yep.

> I always wished to have this mechanism in Ada. Note that instead of
> inventing some complicated syntax which purpose is basically to generate
> conversion functions (four conversions are needed in most general case),
> you should just allow the programmer to define them by himself.

There is a trade-off. Using syntax constrains the kinds of conversions 
the programmer can use, which may help compilation and code generation. 
Programmer-defined unrestricted conversion functions could become too 
complex for efficient compilation.

> My opinion is that the language should provide very few fundamental
> primitives rather than a forest of special cases.

I agree, in theory. In practice, it is difficult, even if you could 
define a language from scratch. It is even more difficult for Ada 
because of the compatibility requirements.

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

Re: What would you like in Ada202X?

[ytomino]

It's interesting.

What would happen to 'Pos and 'Val ?

>  type Message_Kind1 is (Sign_On, Request, Reply, Sign_Off); 
>  type Detailed_Message_Kind is new Message_Kind1 with ( 
>       Request => (Read, Write), 
>       Reply   => (Data, Ack, Refused), 
>       others  => <>); 

First, Message_Kind1'Pos (Sign_On) = 1, Request = 2, Reply = 3, Sign_Off = 4, of course.

I think...

1) To keep order, Detailed_Message_Kind'Pos (Read) = 2, Write = 2.5 (float!)
2) To keep as integer, Detailed_Message_Kind'Pos (Read) = 2, Write = 5
3) Simple adding, Detailed_Message_Kind'Pos (Read) = 5, Write = 6
4) Reassign, Detailed_Message_Kind'Pos (Read) = 2, Write = 3, Data = 4, ..., Sign_Off = 7

Which do you intend?

It seems difficult to realize keeping operator "<", ">" and keeping Message_Kind1'Pos (X) = Detailed_Message_Kind'Pos (X) at same time.
And it's unclear about representation of "array (Detailed_Message_Kind) of ...".

However, I too want to use this extensible enum if you have a nice solution.

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Mon, 07 May 2012 00:26:52 +0300, Niklas Holsti wrote:

> On 12-05-06 22:28 , Dmitry A. Kazakov wrote:
>>
>> Yes, for tagged types operations which are unsafe to inherit are inherited
>> abstract, e.g. functions returning covariant value.
> 
> The same could be done also for extension by deepening, but it is not 
> needed, as long as we don't introduce tags and class-wide programming 
> for these types. Inheriting these operations as abstract could even be 
> inconvenient, since it would force the program to implement (override) 
> the operations even when they are not needed.

What are you going to do with user-defined operations?

In the model (1) where the derived type is a subtype (in Ada sense) they
get automatically inherited in any context where visible. [This in effect
makes you exposed to "class-wide" programming with subtypes even if you
don't want to. All subtypes of a type form a class with ad-hoc operations
gathered from all members, when visible.]

In the tagged model (2) the derived type is independent and any specific
operations of the parent are dropped.

>> This looks like plain interface inheritance. You inherit the interface (the
>> literals of the type) dropping the implementation (encoding).
> 
> Not quite, because the derived type does not inherit the literals that 
> are refined. Detailed_Message_Kind does not have the literals Request 
> and Reply, because they have been refined into the literals Read and 
> Write, and into the literals Data, Ack, and Refused, respectively.

OK, +operation disallowing. This would not work in the model #1.

(I guess that difficulties with enumeration extension proposals stem from
attempts to force it under the model #1)

>> Parent's
>> operations are inherited per composition with a type conversion.
> 
> Yep.
> 
>> I always wished to have this mechanism in Ada. Note that instead of
>> inventing some complicated syntax which purpose is basically to generate
>> conversion functions (four conversions are needed in most general case),
>> you should just allow the programmer to define them by himself.
> 
> There is a trade-off. Using syntax constrains the kinds of conversions 
> the programmer can use, which may help compilation and code generation. 
> Programmer-defined unrestricted conversion functions could become too 
> complex for efficient compilation.

Possibly, though a more general construct would reduce the number of cases
the compiler designer should go though. I think that combinatorial
explosion of variants could be a bigger problem for the optimizer.

>> My opinion is that the language should provide very few fundamental
>> primitives rather than a forest of special cases.
> 
> I agree, in theory. In practice, it is difficult, even if you could 
> define a language from scratch.

Yes. More general constructs have more power, which needs to be carefully
constrained in order to keep the language safe. C and PL/1 give us examples
of the damage type conversions may inflict.

> It is even more difficult for Ada 
> because of the compatibility requirements.

On the contrary, it is rather specific extensions which likely are to
become incompatible. Generalizations are less problematic, you simply
define old constructs in new terms.

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

Re: What would you like in Ada202X?

[Niklas Holsti]

On 12-05-07 09:33 , ytomino wrote:
> It's interesting.
>
> What would happen to 'Pos and 'Val ?

They would work in the normal way for enumeration types, just as if the 
parent type and the derived type were declared separately, without 
derivation.

>>   type Message_Kind1 is (Sign_On, Request, Reply, Sign_Off);
>>   type Detailed_Message_Kind is new Message_Kind1 with (
>>        Request =>  (Read, Write),
>>        Reply   =>  (Data, Ack, Refused),
>>        others  =>  <>);
>
> First, Message_Kind1'Pos (Sign_On) = 1, Request = 2, Reply = 3, Sign_Off = 4, of course.

That should be 0, 1, 2, and 3. 'Pos starts from zero.

> 1) To keep order, Detailed_Message_Kind'Pos (Read) = 2, Write = 2.5 (float!)

No, I would make the 'Pos values for Detailed_Message_Kind be the normal 
ones for its list of literals: Detailed_Message_Kind'Pos for Sign_On is 
0, for Read it is 1, for Write it is 2, for Data it is 3, for Ack it is 
4, for Refused it is 5, and for Sign_Off it is 6.

I don't see any reason to keep the same position number for the "same" 
literal of Message_Kind1 and of Detailed_Message_Kind. Although the 
literals have the same identifier, they are not the same value.

That is, Message_Kind1'(Sign_On) is not the same value as 
Detailed_Message_Kind'(Sign_On), although the latter can be converted to 
the former (and perhaps vice versa).

Moreover, neither the parent type nor the derived type is a subtype 
(subrange) of the other type, in the Ada sense.

> It seems difficult to realize keeping operator "<",">" and keeping
> Message_Kind1'Pos (X) = Detailed_Message_Kind'Pos (X) at same time.

The code for the relational operators "<" and ">" would use the 
representation, not the position number. I suggested that values of the 
derived type would be represented by some "parent" bits that represent a 
value of the parent type, and some more "extension bits" to separate the 
refining literals from each other. If these bits are packed in a word, 
with the extension bits less significant than the parent bits, ordinary 
integer comparison instructions can implement "<" and ">" for the 
derived type. (This is just like lexicographic ordering.)

> And it's unclear about representation of "array (Detailed_Message_Kind) of ...".

The array index would be the position number, as usual. The position 
number can be computed from the representation with parent bits and 
extension bits. To make this computation fast, the compiler could use a 
constant array "first_pos" that is indexed by the parent bits (that is, 
by the parent enumerated type) and gives the position number of the 
first derived-type literal that is refined from this parent-type value. 
The position number of any value of the derived type is then computed as 
first_pos(parent bits) + (extension bits).

In the example, first_pos(Message_Kind1'(Sign_On)) would be 0, for 
Request it would be 1, for Reply it would be 3, and for 
Message_Kind1'(Sign_Off) it would be 6.

The value Detailed_Message_Kind'(Ack) would be represented by the parent 
bits 2#10#, representing Reply, and the extension bits 2#01#, to show 
that Ack is the second literal refining Reply. The position number is 
computed as first_pos(Reply) + 1 = 3 + 1 = 4.

Each derived type needs its own "first_pos" array, of course.

> However, I too want to use this extensible enum if you have a nice solution.

Two votes in favour, interesting!

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

Re: What would you like in Ada202X?

[Niklas Holsti]

On 12-05-07 10:49 , Dmitry A. Kazakov wrote:
> On Mon, 07 May 2012 00:26:52 +0300, Niklas Holsti wrote:
>
>> On 12-05-06 22:28 , Dmitry A. Kazakov wrote:
>>>
>>> Yes, for tagged types operations which are unsafe to inherit are inherited
>>> abstract, e.g. functions returning covariant value.
>>
>> The same could be done also for extension by deepening, but it is not
>> needed, as long as we don't introduce tags and class-wide programming
>> for these types. Inheriting these operations as abstract could even be
>> inconvenient, since it would force the program to implement (override)
>> the operations even when they are not needed.
>
> What are you going to do with user-defined operations?

As distinct from what? Predefined operations? Why should there be any 
difference?

> In the model (1) where the derived type is a subtype (in Ada sense)

I'm afraid I don't understand, sorry. Are you talking about Ada 
"subtype" declarations? They are not "derived types" in the Ada sense.

My suggestion for derived enumeration types that extend the parent type 
(by "deepening") would create derived types (in the Ada sense), not 
subtypes (in the Ada sense). Thus any user-defined (primitive) 
operations for the parent type (except those with "out" parameters of 
that type, as already discussed) would be inherited (redeclared) for the 
derived type and implemented with automatic conversion of "in" parameters.

> they
> get automatically inherited in any context where visible. [This in effect
> makes you exposed to "class-wide" programming with subtypes even if you
> don't want to. All subtypes of a type form a class with ad-hoc operations
> gathered from all members, when visible.]

Could you give an example, preferably using the types Message_Kind1 and 
Detailed_Message_Kind?

> In the tagged model (2) the derived type is independent and any specific
> operations of the parent are dropped.

Ditto, example please, in this context?

> (I guess that difficulties with enumeration extension proposals stem from
> attempts to force it under the model #1)

Could be - some discussion in AI95-261 suggests a new reserved word 
"supertype", the reverse of "subtype" - but the main text of the AI uses 
"type .. is new ..", making a derived type and not a subtype (both words 
in the Ada sense).

>>> My opinion is that the language should provide very few fundamental
>>> primitives rather than a forest of special cases.
>>
>> I agree, in theory. In practice, it is difficult, even if you could
>> define a language from scratch.
>
> Yes. More general constructs have more power, which needs to be carefully
> constrained in order to keep the language safe. C and PL/1 give us examples
> of the damage type conversions may inflict.

Especially *implicit* type conversions. Vide C++ ... it is interesting 
to see that even there, forcing explicit conversion is gaining favour.

>> It is even more difficult for Ada
>> because of the compatibility requirements.
>
> On the contrary, it is rather specific extensions which likely are to
> become incompatible. Generalizations are less problematic, you simply
> define old constructs in new terms.

If possible! I fear that the "old constructs" in Ada each have their own 
small, thorny features, carefully defined, for example to avoid specific 
kinds of distributed overhead, or to spare some implementor from having 
to make major changes in his/her compiler. While one could likely make a 
good approximation of the old features by combining new, fundamental 
primitives, getting all these small details exactly right would be 
difficult, and failing there would break compatibility.

However, it would be nice to see this attempted, sooner or later, and 
perhaps the incompatibility could be tolerated.

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

Re: What would you like in Ada202X?

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:a0r0vkFb94U1@mid.individual.net...
> On 12-05-07 09:33 , ytomino wrote:
>> It's interesting.
>>
>> What would happen to 'Pos and 'Val ?
>
> They would work in the normal way for enumeration types, just as if the 
> parent type and the derived type were declared separately, without 
> derivation.
>
>>>   type Message_Kind1 is (Sign_On, Request, Reply, Sign_Off);
>>>   type Detailed_Message_Kind is new Message_Kind1 with (
>>>        Request =>  (Read, Write),
>>>        Reply   =>  (Data, Ack, Refused),
>>>        others  =>  <>);
>>
>> First, Message_Kind1'Pos (Sign_On) = 1, Request = 2, Reply = 3, Sign_Off 
>> = 4, of course.
>
> That should be 0, 1, 2, and 3. 'Pos starts from zero.
>
>> 1) To keep order, Detailed_Message_Kind'Pos (Read) = 2, Write = 2.5 
>> (float!)
>
> No, I would make the 'Pos values for Detailed_Message_Kind be the normal 
> ones for its list of literals: Detailed_Message_Kind'Pos for Sign_On is 0, 
> for Read it is 1, for Write it is 2, for Data it is 3, for Ack it is 4, 
> for Refused it is 5, and for Sign_Off it is 6.
>
> I don't see any reason to keep the same position number for the "same" 
> literal of Message_Kind1 and of Detailed_Message_Kind. Although the 
> literals have the same identifier, they are not the same value.

But the representation of an enumeration type is its position number, unless 
otherwise specified. That's an age-old Ada requirement (found in 13.4(8)). I 
suppose you could drop it, but then a complete replacement would have to be 
defined and that would be complex (and less than useful).

...
>> It seems difficult to realize keeping operator "<",">" and keeping
>> Message_Kind1'Pos (X) = Detailed_Message_Kind'Pos (X) at same time.
>
> The code for the relational operators "<" and ">" would use the 
> representation, not the position number. I suggested that values of the 
> derived type would be represented by some "parent" bits that represent a 
> value of the parent type, and some more "extension bits" to separate the 
> refining literals from each other. If these bits are packed in a word, 
> with the extension bits less significant than the parent bits, ordinary 
> integer comparison instructions can implement "<" and ">" for the derived 
> type. (This is just like lexicographic ordering.)

This makes no sense, since enumerations have well-defined representations, 
which can be specified by the user. And it provides no value that I can see, 
since a compiler is going to have to support conversions to/from these 
enumerations that have user-defined representations anyway. So the only way 
to do the conversions is is with a lookup table.

Moreover, I can't speak for other compilers, but Janus/Ada uses the position 
number for all operations; the only use of the representation is to 
read/store from memory. So the representation is completely irrelevant for 
implementing operations. (We wouldn't even need to enforce the 
representation ordering rules, but of course we do because they're required 
by the language.) We couldn't find any reasonable way to support operations 
like indexing and looping and still support arbitrary representations with 
missing values (holes if you will).

>> And it's unclear about representation of "array (Detailed_Message_Kind) 
>> of ...".

Arrays in Ada should not have holes, so the representation would surely not 
change.

> The array index would be the position number, as usual. The position 
> number can be computed from the representation with parent bits and 
> extension bits. To make this computation fast,

This isn't happening, because of the need to support user-specified 
representations. That's not "fast", and it's almost certain that 
implementations would use the same mechanism for this (why invent a third 
mechanism for something rarely used?).

...
>> However, I too want to use this extensible enum if you have a nice 
>> solution.
>
> Two votes in favour, interesting!

It seemed like a useful idea back in the day, but to be really useful, we 
need the equivalent of class-wide operations. I don't see how to do that if 
the position numbers are completely different between the various types. So 
I'm dubious, but we have a long time before any of this is going to be 
adopted, so perhaps improvements can be made.

                                    Randy.

Re: What would you like in Ada202X?

[Niklas Holsti]

On 12-05-08 03:48 , Randy Brukardt wrote:
> "Niklas Holsti"<niklas.holsti@tidorum.invalid>  wrote in message
> news:a0r0vkFb94U1@mid.individual.net...
>> On 12-05-07 09:33 , ytomino wrote:
>>> It's interesting.
>>>
>>> What would happen to 'Pos and 'Val ?
>>
>> They would work in the normal way for enumeration types, just as if the
>> parent type and the derived type were declared separately, without
>> derivation.
>>
>>>>    type Message_Kind1 is (Sign_On, Request, Reply, Sign_Off);
>>>>    type Detailed_Message_Kind is new Message_Kind1 with (
>>>>         Request =>   (Read, Write),
>>>>         Reply   =>   (Data, Ack, Refused),
>>>>         others  =>   <>);
>>>
>>> First, Message_Kind1'Pos (Sign_On) = 1, Request = 2, Reply = 3, Sign_Off
>>> = 4, of course.
>>
>> That should be 0, 1, 2, and 3. 'Pos starts from zero.
>>
>>> 1) To keep order, Detailed_Message_Kind'Pos (Read) = 2, Write = 2.5
>>> (float!)
>>
>> No, I would make the 'Pos values for Detailed_Message_Kind be the normal
>> ones for its list of literals: Detailed_Message_Kind'Pos for Sign_On is 0,
>> for Read it is 1, for Write it is 2, for Data it is 3, for Ack it is 4,
>> for Refused it is 5, and for Sign_Off it is 6.
>>
>> I don't see any reason to keep the same position number for the "same"
>> literal of Message_Kind1 and of Detailed_Message_Kind. Although the
>> literals have the same identifier, they are not the same value.
>
> But the representation of an enumeration type is its position number, unless
> otherwise specified.

Maybe it wasn't clear, but anything I've said about the representation 
of the "deepened" derived enumeration types has been intended as an 
example of how it could be done, to help machine-oriented readers 
understand how the types work. I don't really care about the representation.

> That's an age-old Ada requirement (found in 13.4(8)).

So, "deepened" enumeration types are a new thing; new rules for new things.

> I suppose you could drop it, but then a complete replacement would
> have to be defined and that would be complex (and less than useful).

This is a side track, but I don't see any compelling reason (except 
compatibility) to define a standard default representation for 
enumeration types. There is no standard representation for Booleans, 
integer types, floats, records; why should enumeration types have one? 
(Is it a remnant of a C-style identification of enumerations with integers?)

Decades ago I liked to specify my own enumeration representations, but I 
would think three times before doing it today. It is only useful for 
unchecked conversions and I/O. If you use it for input, you have to mess 
about with 'Valid or exceptions. For output, there are always other 
important considerations like memory access width and byte ordering. I 
much prefer to use my own code or tables for converting between known 
external representations and unknown internal representations. This also 
avoids the rule about keeping the same order of the literals and the 
representation values.

> ...
>>> It seems difficult to realize keeping operator "<",">" and keeping
>>> Message_Kind1'Pos (X) = Detailed_Message_Kind'Pos (X) at same time.
>>
>> The code for the relational operators "<" and">" would use the
>> representation, not the position number. I suggested that values of the
>> derived type would be represented by some "parent" bits that represent a

I should have said "*could* be represented by...".

>> value of the parent type, and some more "extension bits" to separate the
>> refining literals from each other. If these bits are packed in a word,
>> with the extension bits less significant than the parent bits, ordinary
>> integer comparison instructions can implement "<" and">" for the derived
>> type. (This is just like lexicographic ordering.)
>
> This makes no sense, since enumerations have well-defined representations,

In current Ada, yes.

> which can be specified by the user.

Sure. I was giving an example of a possible default representation (if 
not by position number).

> And it provides no value that I can see,
> since a compiler is going to have to support conversions to/from these
> enumerations that have user-defined representations anyway. So the only way
> to do the conversions is is with a lookup table.

That would be ok for me. The parent-bits/extension-bits representation 
is only an example of an alternative representation that makes the 
conversion from the derived type to the parent type fast (right-shift to 
discard the extension bits). (And it is analogous to the way tagged 
record types are extended by adding new components.)

> Moreover, I can't speak for other compilers, but Janus/Ada uses the position
> number for all operations; the only use of the representation is to
> read/store from memory. So the representation is completely irrelevant for
> implementing operations. (We wouldn't even need to enforce the
> representation ordering rules, but of course we do because they're required
> by the language.) We couldn't find any reasonable way to support operations
> like indexing and looping and still support arbitrary representations with
> missing values (holes if you will).

You could continue using this method for the "deepened" enumeration 
types, whatever representation you choose to use for them, or the user 
specifies for them.

The only new thing that the "deepened" enumeration type needs is a 
compiler-provided conversion to the parent type. The 
parent-bits/extension-bits representation would make that fast, but you 
could also use a simple table, indexed by the derived type (= position 
number), with elements of the parent type.

> ...  it's almost certain that
> implementations would use the same mechanism for this (why invent a third
> mechanism for something rarely used?).

Sure, implementations could do that. And it seems to me that supporting 
user-specified enumeration representations for "deepened" enumeration 
types would not require any new compiler mechanisms.

> It seemed like a useful idea back in the day,

I think that extending enumeration types by "deepening" is a different 
idea than the AI95-261 "widening" idea. Don't you think that they are 
logically different?

> but to be really useful, we
> need the equivalent of class-wide operations.

That is the main question: do we?

> I don't see how to do that if
> the position numbers are completely different between the various types.

I agree. It seems to me that adding class-wide operations would force to 
use some kind of tags, call by reference, and view conversions, and then 
it becomes so similar to tagged types that it is not worth it.

I think the idea of "deepened" enumeration types is worth pursuing only 
if it is useful without class-wide operations.

Another issue is that generic formal types of the "deepened" kind would 
be needed. I think that would be the next point to work on for this 
proposal.

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

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Tue, 08 May 2012 02:18:28 +0300, Niklas Holsti wrote:

> On 12-05-07 10:49 , Dmitry A. Kazakov wrote:
>> On Mon, 07 May 2012 00:26:52 +0300, Niklas Holsti wrote:
>>
>>> On 12-05-06 22:28 , Dmitry A. Kazakov wrote:
>>>>
>>>> Yes, for tagged types operations which are unsafe to inherit are inherited
>>>> abstract, e.g. functions returning covariant value.
>>>
>>> The same could be done also for extension by deepening, but it is not
>>> needed, as long as we don't introduce tags and class-wide programming
>>> for these types. Inheriting these operations as abstract could even be
>>> inconvenient, since it would force the program to implement (override)
>>> the operations even when they are not needed.
>>
>> What are you going to do with user-defined operations?
> 
> As distinct from what? Predefined operations? Why should there be any 
> difference?

Because if you inherit them, you get all substitutability problems you
wished to avoid:

   procedure Foo (X : out Message_Kind1) is
   begin
       X := Request;
   end Foo;

But you already answered below than you want to disallow all out and in-out
operations.

>> In the model (1) where the derived type is a subtype (in Ada sense)
> 
> I'm afraid I don't understand, sorry. Are you talking about Ada 
> "subtype" declarations? They are not "derived types" in the Ada sense.
>
> My suggestion for derived enumeration types that extend the parent type 
> (by "deepening") would create derived types (in the Ada sense), not 
> subtypes (in the Ada sense). Thus any user-defined (primitive) 
> operations for the parent type (except those with "out" parameters of 
> that type, as already discussed) would be inherited (redeclared) for the 
> derived type and implemented with automatic conversion of "in" parameters.

This would exclude all functions returning values of the type. In
particular T'Val, T'Succ, T'Pred. Are you going to define some of them new?

>> they
>> get automatically inherited in any context where visible. [This in effect
>> makes you exposed to "class-wide" programming with subtypes even if you
>> don't want to. All subtypes of a type form a class with ad-hoc operations
>> gathered from all members, when visible.]
> 
> Could you give an example, preferably using the types Message_Kind1 and 
> Detailed_Message_Kind?

So far it is clear, except for:

1. Distinction between primitive and non-primitive operations. Are all
in-operations primitive (inherited). E.g.

   package P
       type Detailed_Message_Kind is new Message_Kind1 ...
   end P;

   package Q is
       procedure Baz (X : Message_Kind1);
       ...
   end Q;

   with P, Q; use P, Q;
   package R is
       X : Detailed_Message_Kind;
   begin
       procedure Baz (X); -- Is this legal?

2. Double-dispatch / multi-methods. What happens with operations which have
several parameters of the parent type:

   procedure Set (X : in out Message_Kind1; Y : Message_Kind1);

This is inherited in Y, but not inherited in X. Will it become
contravariant in X? E.g.

   procedure Set (X : in out Message_Kind1; Y : Detailed_Message_Kind);

3. Overriding. If this is the model #2, you can override

   procedure Old (X : Message_Kind1);

   overriding
      procedure Old (X : Detailed_Message_Kind);

Can you? This is also related to the question 1. If you can override, you
have multiple dispatch issue, you need freezing rules, you need primitive
and non-primitive in-operations. If you cannot override you may have the
problem that depending on the some contexts one or another operation is
called (weak typing).

>>> It is even more difficult for Ada
>>> because of the compatibility requirements.
>>
>> On the contrary, it is rather specific extensions which likely are to
>> become incompatible. Generalizations are less problematic, you simply
>> define old constructs in new terms.
> 
> If possible! I fear that the "old constructs" in Ada each have their own 
> small, thorny features, carefully defined, for example to avoid specific 
> kinds of distributed overhead, or to spare some implementor from having 
> to make major changes in his/her compiler. While one could likely make a 
> good approximation of the old features by combining new, fundamental 
> primitives, getting all these small details exactly right would be 
> difficult, and failing there would break compatibility.
> 
> However, it would be nice to see this attempted, sooner or later, and 
> perhaps the incompatibility could be tolerated.

If there are compatibility problems they will show up in the proposals like
yours. Because any of them must be based on very few fundamental concepts,
like type, class, interface etc. (I don't care about language terms RM uses
for them, I do care about the semantics.)

My point is that if these concepts are sound, then only incompatibilities
possible are language bugs (not just flaws, but hard bugs) to be fixed
anyway. I don't buy the compatibility argument. The rest is merely syntax
sugar questions.

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

Re: What would you like in Ada202X?

[Martin Dowie]

Shark8 <onewingedshark@gmail.com> wrote:
> On Tuesday, May 1, 2012 2:28:26 AM UTC-5, Martin wrote:
>> 
>> Ah, yes, that makes sense. Not something I've ever thought I needed but
>> that's just me. I can think of a few times where I'd like to have
>> overriden 'Image and <exaggeration>_millions_</exaggeration> of times
>> where I wish 'Image didn't have a leading space!!
>> 
>> -- Martin
> 
> Hm, why not rename Trim or make a subprogram/function that wraps it? 
> Could the new expression functions perhaps do that? (I haven't played w/ them.)

I do...all the time! And it's really annoying!! :-)
-- Martin


-- 
-- Sent from my iPad

Re: What would you like in Ada202X?

[Niklas Holsti]

On 12-05-08 12:03 , Dmitry A. Kazakov wrote:
> On Tue, 08 May 2012 02:18:28 +0300, Niklas Holsti wrote:
>
>> On 12-05-07 10:49 , Dmitry A. Kazakov wrote:
>>> On Mon, 07 May 2012 00:26:52 +0300, Niklas Holsti wrote:
>>>
>>>> On 12-05-06 22:28 , Dmitry A. Kazakov wrote:
>>>>>
>>>>> Yes, for tagged types operations which are unsafe to inherit are inherited
>>>>> abstract, e.g. functions returning covariant value.
>>>>
>>>> The same could be done also for extension by deepening, but it is not
>>>> needed, as long as we don't introduce tags and class-wide programming
>>>> for these types. Inheriting these operations as abstract could even be
>>>> inconvenient, since it would force the program to implement (override)
>>>> the operations even when they are not needed.
>>>
>>> What are you going to do with user-defined operations?
>>
>> As distinct from what? Predefined operations? Why should there be any
>> difference?
>
> Because if you inherit them, you get all substitutability problems you
> wished to avoid:
>
>     procedure Foo (X : out Message_Kind1) is
>     begin
>         X := Request;
>     end Foo;
>
> But you already answered below than you want to disallow all out and in-out
> operations.

Yes, so Foo would not be inherited under that strict rule.

Perhaps the derived "deepened" type could inherit operations with "out" 
and "in out" parameters of the parent type if these parameters were kept 
as parent type, and not mapped to the derived type (I see that you bring 
this up later below). For example (referring to the types Message_Kind1 
and Detailed_Message_Kind in my first posting), we could have:

    function Converse (Msg : Message_Kind1) return Message_Kind1
    is
    begin
       case Msg is
       when Sign_On  => return Sign_Off;
       when Request  => return Reply;
       when Reply    => return Request;
       when Sign_Off => return Sign_On;
       end case;
    end Converse;

This function could be inherited (a bit weakly, perhaps) by 
Detailed_Message_Kind with the profile

    function Converse (Msg : Detailed_Message_Kind) return Message_Kind1

For example, Converse (Detailed_Message_Kind'(Read)) would return 
Message_Kind1'(Reply), because Read "is a" Request.

If necessary, the user could write a fully "deepened" function:

    function Converse (Msg : Detailed_Message_Kind)
    return Detailed_Message_Kind
    is
       ...
       when Read => return Data;
       ...
    end Converse;

This Converse would be an overloading of the original Converse and the 
inherited Converse, not an overriding of the latter. But that would be 
OK, in the absence of class-wide programming.

>> My suggestion for derived enumeration types that extend the parent type
>> (by "deepening") would create derived types (in the Ada sense), not
>> subtypes (in the Ada sense). Thus any user-defined (primitive)
>> operations for the parent type (except those with "out" parameters of
>> that type, as already discussed) would be inherited (redeclared) for the
>> derived type and implemented with automatic conversion of "in" parameters.
>
> This would exclude all functions returning values of the type. In
> particular T'Val, T'Succ, T'Pred. Are you going to define some of them new?

Of course the derived "deepened" type must have these operations, since 
it is an enumeration type, but I would not consider them as "inherited" 
(except in the sense that the parent type also has operations with the 
corresponding names and uses). In that sense my wording was inexact and 
confusing, sorry, and I now understand your question about predefined 
vs. user-defined operations. I think.

T'Val, T'Succ, T'Pred (and T'Image and T'Pos) for a "deepened" type 
would work as if the "deepened" type were declared as an unrelated 
enumeration type (by just listing all its literals).

>>> they
>>> get automatically inherited in any context where visible. [This in effect
>>> makes you exposed to "class-wide" programming with subtypes even if you
>>> don't want to. All subtypes of a type form a class with ad-hoc operations
>>> gathered from all members, when visible.]
>>
>> Could you give an example, preferably using the types Message_Kind1 and
>> Detailed_Message_Kind?
>
> So far it is clear, except for:
>
> 1. Distinction between primitive and non-primitive operations. Are all
> in-operations primitive (inherited). E.g.
>
>     package P
>         type Detailed_Message_Kind is new Message_Kind1 ...
>     end P;
>

I assume Q (below) has "with P; use P;".

>     package Q is
>         procedure Baz (X : Message_Kind1);
>         ...
>     end Q;
>
>     with P, Q; use P, Q;
>     package R is

I assume you meant "procedure R is" here.

>         X : Detailed_Message_Kind;
>     begin
>         procedure Baz (X); -- Is this legal?

I would say illegal. The potentially inherited operations should be the 
same as for a derived enumeration type in current Ada, as if the 
deepened type were defined just as

    type Detailed_Message_Kind is new Message_Kind1;

and the only difference should be the treatment of "out" and "in out" 
parameters and function return values.

> 2. Double-dispatch / multi-methods. What happens with operations which have
> several parameters of the parent type:
>
>     procedure Set (X : in out Message_Kind1; Y : Message_Kind1);
>
> This is inherited in Y, but not inherited in X. Will it become
> contravariant in X? E.g.
>
>     procedure Set (X : in out Message_Kind1; Y : Detailed_Message_Kind);

Yes, that could be a way to (weakly) inherit operations with "out" or 
"in out" parameters and function returns. But the consequences of such a 
rule should be thought out, since it differs from the current Ada 
inheritance style, as I understand it.

> 3. Overriding. If this is the model #2, you can override
>
>     procedure Old (X : Message_Kind1);
>
>     overriding
>        procedure Old (X : Detailed_Message_Kind);
>
> Can you?

Yes, just as you can override inherited operations on derived 
enumeration types in current Ada.

> This is also related to the question 1. If you can override, you
> have multiple dispatch issue, you need freezing rules, you need primitive
> and non-primitive in-operations. If you cannot override you may have the
> problem that depending on the some contexts one or another operation is
> called (weak typing).

I'm sure there are complications to sort out. I haven't thought very 
long or deep about this. If people are interested in this idea, it would 
motivate some effort on it.

I would like to make the "deepening" derivation as similar as possible 
to the derivation of enumeration types in

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

Re: What would you like in Ada202X?

[Niklas Holsti]

On 12-05-08 22:20 , Niklas Holsti wrote:

> I would like to make the "deepening" derivation as similar as possible
> to the derivation of enumeration types in

Sorry, some text was lost: that sentence should end "in current Ada".

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

Re: What would you like in Ada202X?

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:a0rsroFp8lU1@mid.individual.net...
(Commenting only on the side-track)

...
> This is a side track, but I don't see any compelling reason (except 
> compatibility) to define a standard default representation for enumeration 
> types. There is no standard representation for Booleans, integer types, 
> floats, records; why should enumeration types have one? (Is it a remnant 
> of a C-style identification of enumerations with integers?)
>
> Decades ago I liked to specify my own enumeration representations, but I 
> would think three times before doing it today. It is only useful for 
> unchecked conversions and I/O. If you use it for input, you have to mess 
> about with 'Valid or exceptions.

'Valid *and* exceptions. You can never assume that Program_Error is not 
raised; using an invalid value is a bounded error and the compiler is 
definitely allowed to raise Program_Error if the error is detected. (And 
Janus/Ada does detect it; as I previously noted, it uses the Position number 
for all operations, and if there is no Position number for a value, we have 
to do something, and the language says that is "raise Program_Error;")

> For output, there are always other important considerations like memory 
> access width and byte ordering.

I wasn't arguing that this capability is important, only that Ada has it and 
both the language design and the implementation have to take the possibility 
into account. We're surely not removing this capability!

It's the same with the default representation for enumeration values. 
Probably 98% of Ada programs don't care at all about the representation, but 
even if only 0.1% do, changing it would break too many programs to consider 
it. (And the Unchecked_Conversion usage is not that unusual.)

A new kind of enumeration type could have different rules, but that's 
confusing (since sometimes you can depend on the representation and sometime 
you can't).

                                 Randy.

Re: What would you like in Ada202X?

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:a0rsroFp8lU1@mid.individual.net...
> On 12-05-08 03:48 , Randy Brukardt wrote:
...
>> It seemed like a useful idea back in the day,
>
> I think that extending enumeration types by "deepening" is a different 
> idea than the AI95-261 "widening" idea. Don't you think that they are 
> logically different?

The details are different, but the basic idea (adding more literals) is 
unchanged. And the use is in adding more literals, the details on exactly 
how you do that are much less important.

>> but to be really useful, we
>> need the equivalent of class-wide operations.
>
> That is the main question: do we?

We need class-wide operations for Integer and Float and (especially) String, 
so it's hard to imagine how we could avoid needing them for such an 
enumeration!

For example:
              Put (X : in Root_Integer'Class);
is much more useable than a generic that you have to instantiation for each 
kind of type. (Some operations really do cross-cut types.)

Inheritance of operations is virtually useless without class-wide 
operations. Note that class-wide operations don't necessarily have to 
involve dispatching, although that does seem like the most sensible model. 
Dmitry has pointed out repeatedly that one does not need to store tags with 
values of specific types; they can be added when converted to a class-wide 
type and that makes the most sense for elementary and array tagged types.

>> I don't see how to do that if
>> the position numbers are completely different between the various types.
>
> I agree. It seems to me that adding class-wide operations would force to 
> use some kind of tags, call by reference, and view conversions, and then 
> it becomes so similar to tagged types that it is not worth it.

Umm, that's when it *does* become worth it. The problem is untagged types 
are pretty hard to use. (Note that I disagree about call-by-reference, but 
that's a detail.)

> I think the idea of "deepened" enumeration types is worth pursuing only if 
> it is useful without class-wide operations.

Then don't bother. IMHO, at least.

> Another issue is that generic formal types of the "deepened" kind would be 
> needed. I think that would be the next point to work on for this proposal.

We already have that. Generic derived types (with the ancestor being an 
enumeration) would provide the needed inheritance. But of course that better 
make semantic sense!

                                        Randy.

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Tue, 8 May 2012 17:22:16 -0500, Randy Brukardt wrote:

> For example:
>               Put (X : in Root_Integer'Class);
> is much more useable than a generic that you have to instantiation for each 
> kind of type. (Some operations really do cross-cut types.)

(That's for sure, generics must be wiped out)

But how would you have Root_Integer'Class without multiple inheritance?
What about Root_Discrete'Class, Root_Scalar'Class, Root_Numeric'Class and
dozens other classes it belongs to? You cannot order interfaces like these
in one string.

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

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Tue, 08 May 2012 22:20:21 +0300, Niklas Holsti wrote:

> On 12-05-08 12:03 , Dmitry A. Kazakov wrote:
>> On Tue, 08 May 2012 02:18:28 +0300, Niklas Holsti wrote:
>>
>>> On 12-05-07 10:49 , Dmitry A. Kazakov wrote:
>>>> On Mon, 07 May 2012 00:26:52 +0300, Niklas Holsti wrote:
>>>>
>>>>> On 12-05-06 22:28 , Dmitry A. Kazakov wrote:
>>>>>>
>>>>>> Yes, for tagged types operations which are unsafe to inherit are inherited
>>>>>> abstract, e.g. functions returning covariant value.
>>>>>
>>>>> The same could be done also for extension by deepening, but it is not
>>>>> needed, as long as we don't introduce tags and class-wide programming
>>>>> for these types. Inheriting these operations as abstract could even be
>>>>> inconvenient, since it would force the program to implement (override)
>>>>> the operations even when they are not needed.
>>>>
>>>> What are you going to do with user-defined operations?
>>>
>>> As distinct from what? Predefined operations? Why should there be any
>>> difference?
>>
>> Because if you inherit them, you get all substitutability problems you
>> wished to avoid:
>>
>>     procedure Foo (X : out Message_Kind1) is
>>     begin
>>         X := Request;
>>     end Foo;
>>
>> But you already answered below than you want to disallow all out and in-out
>> operations.
> 
> Yes, so Foo would not be inherited under that strict rule.
> 
> Perhaps the derived "deepened" type could inherit operations with "out" 
> and "in out" parameters of the parent type if these parameters were kept 
> as parent type, and not mapped to the derived type

No, they must be inherited exactly same way  The new operation has the
parameter of derived type when inherited, that is covariance. When an in
operation is inherited it too has the parameter of the derived type, which
is then converted and passed to the inherited body. For out-operations you
call the inherited body and then convert the result. For in-outs, you
convert-in, call, convert-out.

You might mean that composition with conversion could be inappropriate
here. That is a separate issue. If you want to generate conversions, yes
you are in trouble. If you let the programmer to supply a conversion which
cannot be generated, that becomes his problem.

Note also, that if exceptions were contracted, he would not be able to use
a conversion raising Constraint_Error for missing values. Which would add
necessary safety to the mechanism.

>>> My suggestion for derived enumeration types that extend the parent type
>>> (by "deepening") would create derived types (in the Ada sense), not
>>> subtypes (in the Ada sense). Thus any user-defined (primitive)
>>> operations for the parent type (except those with "out" parameters of
>>> that type, as already discussed) would be inherited (redeclared) for the
>>> derived type and implemented with automatic conversion of "in" parameters.
>>
>> This would exclude all functions returning values of the type. In
>> particular T'Val, T'Succ, T'Pred. Are you going to define some of them new?
> 
> Of course the derived "deepened" type must have these operations, since 
> it is an enumeration type,

(See how quickly multiple inheritance slips in? (:-))

> but I would not consider them as "inherited" 
> (except in the sense that the parent type also has operations with the 
> corresponding names and uses).

The probe question is: do they overload or do they override.

covariant <=> overrides <=> inherited <=> method <=> primitive operation

contravariant <=> overloads <=> not-inherited <=> free function <=>
non-primitive or class-wide

>>>> they
>>>> get automatically inherited in any context where visible. [This in effect
>>>> makes you exposed to "class-wide" programming with subtypes even if you
>>>> don't want to. All subtypes of a type form a class with ad-hoc operations
>>>> gathered from all members, when visible.]
>>>
>>> Could you give an example, preferably using the types Message_Kind1 and
>>> Detailed_Message_Kind?
>>
>> So far it is clear, except for:
>>
>> 1. Distinction between primitive and non-primitive operations. Are all
>> in-operations primitive (inherited). E.g.
>>
>>     package P
>>         type Detailed_Message_Kind is new Message_Kind1 ...
>>     end P;
>>
> 
> I assume Q (below) has "with P; use P;".
> 
>>     package Q is
>>         procedure Baz (X : Message_Kind1);
>>         ...
>>     end Q;
>>
>>     with P, Q; use P, Q;
>>     package R is
> 
> I assume you meant "procedure R is" here.
> 
>>         X : Detailed_Message_Kind;
>>     begin
>>         procedure Baz (X); -- Is this legal?
> 
> I would say illegal. The potentially inherited operations should be the 
> same as for a derived enumeration type in current Ada, as if the 
> deepened type were defined just as
> 
>     type Detailed_Message_Kind is new Message_Kind1;
> 
> and the only difference should be the treatment of "out" and "in out" 
> parameters and function return values.

OK, that is consistent. This is exactly the model we have for tagged types
- embedded tags.

This is why it makes no sense to implement it for specifically enumeration
types. The disadvantages it may have (rather imaginary ones, IMO) will all
be yours. So why not to face it, and just do it for all types. Sorry for
advocating this for years, but there is no other way.

>> 2. Double-dispatch / multi-methods. What happens with operations which have
>> several parameters of the parent type:
>>
>>     procedure Set (X : in out Message_Kind1; Y : Message_Kind1);
>>
>> This is inherited in Y, but not inherited in X. Will it become
>> contravariant in X? E.g.
>>
>>     procedure Set (X : in out Message_Kind1; Y : Detailed_Message_Kind);
> 
> Yes, that could be a way to (weakly) inherit operations with "out" or 
> "in out" parameters and function returns. But the consequences of such a 
> rule should be thought out, since it differs from the current Ada 
> inheritance style, as I understand it.

You will have to solve MD problematic as well. E.g.

   type T1 is (...);
   type T2 is (...);
   procedure D (X : T1; Y : T2);

   type S1 is new T1 with ...;
   type S2 is new T2 with ...;

   X1 : T1;
   X2 : S1;
   Y1 : T2;
   Y2 : S2;
begin
    D (X2, Y1); -- Illegal?
    D (X1, Y2); -- Legal but Constraint_Error (Ada 95 hack)

> I'm sure there are complications to sort out. I haven't thought very 
> long or deep about this. If people are interested in this idea, it would 
> motivate some effort on it.

Second to this! Instead of perpetual hand waving about compatibility and
imaginary evils of MI, we, Ada community, should consider how to sort the
mess out.

> I would like to make the "deepening" derivation as similar as possible 
> to the derivation of enumeration types in

With the problems solved you will get enumeration extension for granted.
Your proposal rounds about how to generate conversion functions. You can
generate in-conversion, but cannot out-conversions. The case of plain
extension has the opposite problem: in-conversions are impossible. But the
mechanics of all this is same: interface inheritance, delegation of some
inherited operations to the parent's body composed with a conversion.

Semantically, there always will be some issue with conversions, because any
non-trivial modification of a type, must break something. If it did not,
you would use the old type instead. It is not the language business, it is
up to the programmer to resolve. The language should simply refuse to
automate suspicious cases forcing the programmer to intervene. 

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

Re: What would you like in Ada202X?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1drg0pngpz60n$.13rm2wqyteyli$.dlg@40tude.net...
> On Tue, 8 May 2012 17:22:16 -0500, Randy Brukardt wrote:
>
>> For example:
>>               Put (X : in Root_Integer'Class);
>> is much more useable than a generic that you have to instantiation for 
>> each
>> kind of type. (Some operations really do cross-cut types.)
>
> (That's for sure, generics must be wiped out)

I'm not interested in "wiping out" generics (that will never happen to Ada 
for the obvious compatibility reasons), just getting decent ease-of-use

> But how would you have Root_Integer'Class without multiple inheritance?

Not sure what "inheritance" has to do with it, multiple or not. Most of 
these things have properties which are generated anew for each type -- and 
the fact that these are *not* inherited is very important to making them 
work properly.

> What about Root_Discrete'Class, Root_Scalar'Class, Root_Numeric'Class and
> dozens other classes it belongs to? You cannot order interfaces like these
> in one string.

Who's trying to order anything? I'm only trying to get at the classes 
already existing in Ada. And all of the above could be handled with normal 
derivation (these *classes* exist in Ada). There would be a problem if you 
wanted to gather arbitrary sets of properities together (things not defined 
by Ada to be classes), but that's not a sensible thing to do, especially in 
the existing Ada language framework.

                           Randy.

Re: What would you like in Ada202X?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:kl5nkc2s9tsx.61oqe3a9ogra.dlg@40tude.net...
> On Tue, 08 May 2012 22:20:21 +0300, Niklas Holsti wrote:
...
>> I'm sure there are complications to sort out. I haven't thought very
>> long or deep about this. If people are interested in this idea, it would
>> motivate some effort on it.
>
> Second to this! Instead of perpetual hand waving about compatibility and
> imaginary evils of MI, we, Ada community, should consider how to sort the
> mess out.

There is no mess to sort out. MI is evil and the worst thing ever to happen 
to Ada was the inclusion of interfaces in Ada 2005. It is imcompatible with 
Ada's goals of fast running code, and simply shouldn't be allowed at all.

(If I'm starting to sound like "anon" on this, I apologize... ;-)

>> I would like to make the "deepening" derivation as similar as possible
>> to the derivation of enumeration types in
>
> With the problems solved you will get enumeration extension for granted.
> Your proposal rounds about how to generate conversion functions. You can
> generate in-conversion, but cannot out-conversions. The case of plain
> extension has the opposite problem: in-conversions are impossible. But the
> mechanics of all this is same: interface inheritance, delegation of some
> inherited operations to the parent's body composed with a conversion.
>
> Semantically, there always will be some issue with conversions, because 
> any
> non-trivial modification of a type, must break something. If it did not,
> you would use the old type instead. It is not the language business, it is
> up to the programmer to resolve. The language should simply refuse to
> automate suspicious cases forcing the programmer to intervene.

Here I agree with Dmitry (but note that the mechanism he is talking about 
here has nothing to do with multiple inheritance; it works just fine with 
Ada 95 type derivation or something similar to that). It makes more sense to 
allow the programmer to provide the needed conversion functions than to come 
up with special features for doing that.

I designed a straw-man "Root_String" around such conversion functions (you 
can find it in AI12-0021-1), and in fact you don't even need any additional 
Ada facilities to make such a type very usable. You could make it even more 
usable by defining a way to get user-defined slicing and literals (the 
conversion functions alone don't work for literals because of ambiguity 
problems, forcing qualification of all literals would be madness). This 
wasn't vetted by anyone, so take it with a grain of salt...but it 
illustrates the possibilities.

                                    Randy.

Re: What would you like in Ada202X?

[ytomino]

On Tuesday, May 8, 2012 7:34:28 AM UTC+9, Niklas Holsti wrote:
> On 12-05-07 09:33 , ytomino wrote:
> > It's interesting.
> >
> > What would happen to 'Pos and 'Val ?
> 
> They would work in the normal way for enumeration types, just as if the 
> parent type and the derived type were declared separately, without 
> derivation.
> 
> >>   type Message_Kind1 is (Sign_On, Request, Reply, Sign_Off);
> >>   type Detailed_Message_Kind is new Message_Kind1 with (
> >>        Request =>  (Read, Write),
> >>        Reply   =>  (Data, Ack, Refused),
> >>        others  =>  <>);
> >
> > First, Message_Kind1'Pos (Sign_On) = 1, Request = 2, Reply = 3, Sign_Off = 4, of course.
> 
> That should be 0, 1, 2, and 3. 'Pos starts from zero.

Oops.

> 
> > 1) To keep order, Detailed_Message_Kind'Pos (Read) = 2, Write = 2.5 (float!)
> 
> No, I would make the 'Pos values for Detailed_Message_Kind be the normal 
> ones for its list of literals: Detailed_Message_Kind'Pos for Sign_On is 
> 0, for Read it is 1, for Write it is 2, for Data it is 3, for Ack it is 
> 4, for Refused it is 5, and for Sign_Off it is 6.
> 
> I don't see any reason to keep the same position number for the "same" 
> literal of Message_Kind1 and of Detailed_Message_Kind. Although the 
> literals have the same identifier, they are not the same value.
> 
> That is, Message_Kind1'(Sign_On) is not the same value as 
> Detailed_Message_Kind'(Sign_On), although the latter can be converted to 
> the former (and perhaps vice versa).
> 
> Moreover, neither the parent type nor the derived type is a subtype 
> (subrange) of the other type, in the Ada sense.
> 
> > It seems difficult to realize keeping operator "<",">" and keeping
> > Message_Kind1'Pos (X) = Detailed_Message_Kind'Pos (X) at same time.
> 
> The code for the relational operators "<" and ">" would use the 
> representation, not the position number. I suggested that values of the 
> derived type would be represented by some "parent" bits that represent a 
> value of the parent type, and some more "extension bits" to separate the 
> refining literals from each other. If these bits are packed in a word, 
> with the extension bits less significant than the parent bits, ordinary 
> integer comparison instructions can implement "<" and ">" for the 
> derived type. (This is just like lexicographic ordering.)
> 
> > And it's unclear about representation of "array (Detailed_Message_Kind) of ...".
> 
> The array index would be the position number, as usual. The position 
> number can be computed from the representation with parent bits and 
> extension bits. To make this computation fast, the compiler could use a 
> constant array "first_pos" that is indexed by the parent bits (that is, 
> by the parent enumerated type) and gives the position number of the 
> first derived-type literal that is refined from this parent-type value. 
> The position number of any value of the derived type is then computed as 
> first_pos(parent bits) + (extension bits).
> 
> In the example, first_pos(Message_Kind1'(Sign_On)) would be 0, for 
> Request it would be 1, for Reply it would be 3, and for 
> Message_Kind1'(Sign_Off) it would be 6.
> 
> The value Detailed_Message_Kind'(Ack) would be represented by the parent 
> bits 2#10#, representing Reply, and the extension bits 2#01#, to show 
> that Ack is the second literal refining Reply. The position number is 
> computed as first_pos(Reply) + 1 = 3 + 1 = 4.
> 
> Each derived type needs its own "first_pos" array, of course.
> 
> > However, I too want to use this extensible enum if you have a nice solution.
> 
> Two votes in favour, interesting!
> 
> -- 
> Niklas Holsti
> Tidorum Ltd
> niklas holsti tidorum fi
>        .      @       .

Thank you for the answer.
Although negative opinions is also seen, I think it's nice.

For myself check...

type Message_Kind1 is (Sign_On, Request, Reply, Sign_Off);

-- Sign_On = 0
-- Request = 1
-- Reply = 2
-- Sign_Off = 3

type Detailed_Message_Kind is new Message_Kind1 with (
   Request =>  (Read, Write),
   Reply   =>  (Data, Ack, Refused),
   others  =>  <>);

(when the offset is 4 bit)
-- Sign_On  = 16#00#
-- Read     = 16#10#
-- Write    = 16#11#
-- Data     = 16#20#
-- Ack      = 16#21#
-- Refused  = 16#22#
-- Sign_Off = 16#30#

X'Pos = first_pos (X'Enum_Rep / 16) + (X'Enum_Rep mod 16)

type More_Detailed_Message_Kind is new Detailed_Message_Kind with (
   Write => (Overwrite, Append),
   others => <>);

-- Sign_On   = 16#000#
-- Read      = 16#100#
-- Overwrite = 16#110#
-- Append    = 16#111#
-- Data      = 16#200#
-- Ack       = 16#210#
-- Refused   = 16#220#
-- Sign_Off  = 16#300#

Y'Pos =
   More_Detailed_Message_Kind'first_pos (
      Detailed_Message_Kind'first_pos (Y'Enum_Rep / 256)
      + (Y'Enum_Rep mod 256 / 16))
   + (Y'Enum_Rep mod 16)

Is it OK? It's interesting.

I feel that you do not need to change the existing representation rule.
Because even if Message_Kind1 has the representation clause, it's unrelated to Detailed_Message_Kind.
It's able to keep the existing rule of root enum-types.
And the representation of Detailed_Message_Kind is new thing, such as your saying.

(I'm only interested, not a language lawyer. I'm sorry that I couldn't help you in this discussion.)

Re: What would you like in Ada202X?

[ytomino]

On Wednesday, April 25, 2012 6:09:22 PM UTC+9, Georg Bauhaus wrote:
> 
> My favorite change would start here:
> 
> 0) Which features do you think can be dropped from Ada?
> 
> 
> -Georg

I remembered one.

The behavior of End_Of_File that ignores last LF.
See https://groups.google.com/d/msg/comp.lang.ada/Wv5ZgVZhXIs/k3q_-k5HkPYJ

Re: What would you like in Ada202X?

[Gustaf Thorslund]

On 2012-04-25 10:36, Dmitry A. Kazakov wrote:

>> 2) parallel loops / functions
>
> I don't think this is important.

I like the idea of parallel loops. Parallel functions I don't really 
know what it is so can't tell. For importance I suppose it depends on 
who you ask. There might even be those who could live without tasks.

Some things I can think of here

a) The loop should be possible to run sequentially so for example

parfor I in 1..10 loop --  parfor might not be best name, but I had to
                        --  invent something
   if I = 5 then
      Wait_For_Some_Event_From(9); -- should not be expected to work
   end if;
end loop;

b) The user have to deal with concurrency

X : Integer := 0
.
.
parfor I in 1..10 loop
   X := X + I; -- should not be expected to work either
end loop;

> 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.

Sounds like something that could also be useful when doing something like b.

47)

Pancake.Fry -- Would be nice it if worked even if Pancake is not tagged 
but just a simple record.

4711.Put -- Might be going a bit too far, but then X.Foo would only be 
syntactic sugar for Foo(X) without the need "use Bar" or write Bar.Foo(X).

Regards,
Gustaf
-- 
http://gustaf.thorslund.org

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Wed, 9 May 2012 19:30:53 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1drg0pngpz60n$.13rm2wqyteyli$.dlg@40tude.net...
>>
>> But how would you have Root_Integer'Class without multiple inheritance?
> 
> Not sure what "inheritance" has to do with it, multiple or not. Most of 
> these things have properties which are generated anew for each type -- and 
> the fact that these are *not* inherited is very important to making them 
> work properly.

Of course they are inherited because they are same and treated as being
same. In *all* cases where Ada does not do the latter it gets in trouble,
e,g. when "+" gets overloaded for the same signature.

BTW interface /= implementation. Whatever the compiler generates and how is
irrelevant to the question if an interface is inherited.

>> What about Root_Discrete'Class, Root_Scalar'Class, Root_Numeric'Class and
>> dozens other classes it belongs to? You cannot order interfaces like these
>> in one string.
> 
> Who's trying to order anything?

You must force classes in one line if only single inheritance allowed. That
means precisely that for any two classes they either do not intersect or
else one is contained by another. This is an absolutely unrealistic
constraint.

> There would be a problem if you 
> wanted to gather arbitrary sets of properities together (things not defined 
> by Ada to be classes), but that's not a sensible thing to do, especially in 
> the existing Ada language framework.

I cannot decipher this, sorry. Are "things defined by Ada to be classes"
allowed to construct new classes? [So far some of them were] Are new
classes classes? [This was also true] Can these user-defined classes be
used to create other classes? [Ditto].

What the point?

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

Re: What would you like in Ada202X?

[Martin]

On Wednesday, April 25, 2012 8:47:06 AM UTC+1, 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
> 2) parallel loops / functions
> 3) Multiple dispatch
> 
> -- Martin

Another triviality...

Adding a Put_Line to all the generic nested packages in Ada.Text_IO.

-- Martin

Re: What would you like in Ada202X?

[Adam Beneschan]

On Thursday, May 10, 2012 12:18:52 AM UTC-7, ytomino wrote:

> 
> I remembered one.
> 
> The behavior of End_Of_File that ignores last LF.
> See https://groups.google.com/d/msg/comp.lang.ada/Wv5ZgVZhXIs/k3q_-k5HkPYJ

This link isn't working for me.  (I don't know if it's because I've switched to the New Google Groups or not.)

                      -- Adam

Re: What would you like in Ada202X?

[ytomino]

On Friday, May 11, 2012 12:25:08 AM UTC+9, Adam Beneschan wrote:
> On Thursday, May 10, 2012 12:18:52 AM UTC-7, ytomino wrote:
> 
> > 
> > I remembered one.
> > 
> > The behavior of End_Of_File that ignores last LF.
> > See https://groups.google.com/d/msg/comp.lang.ada/Wv5ZgVZhXIs/k3q_-k5HkPYJ
> 
> This link isn't working for me.  (I don't know if it's because I've switched to the New Google Groups or not.)
> 
>                       -- Adam

Eh? I've switched to new Google Groups, too. I copied this link from "Paste this link into an email or chat:". It seems to work for me.
The title is "Get_Line problem (GNAT bug?)", at Dec 2006. Please search.
You may remember it because you had joined in this thread. (I had not joined :-)

Re: What would you like in Ada202X?

[Adam Beneschan]

On Thursday, May 10, 2012 8:51:43 AM UTC-7, ytomino wrote:
> On Friday, May 11, 2012 12:25:08 AM UTC+9, Adam Beneschan wrote:
> > On Thursday, May 10, 2012 12:18:52 AM UTC-7, ytomino wrote:

> 
> Eh? I've switched to new Google Groups, too. I copied this link from "Paste this link into an email or chat:". It seems to work for me.

Ah, OK, that works for me too.  It doesn't work when I click on the link, even though the link is highlighted and invites me to click on it.  So when I do, I just get the page that says "Welcome to the new Google Groups".  Welcome, indeed.  I've said this multiple times before, but every time Google improves Google Groups they make it worse.  On the other hand, the new Google Groups does have some cool features, such as ... ummm ... having the word "new" in the title.  That's a cool feature, right?  Right?

Anyway, I looked over the thread, and it's one I was involved a lot in.  As I see it, it boils down to (1) End_Of_File should never be used on standard input, because that could cause problems if standard input is not a file.  It could require the program to attempt to read input from the user at the wrong time.  (2) If End_Of_File is used on a File_Type, implementations can always get things to work reasonably when the file is a disk file, and no language change is needed.

What *might* be useful, though, is an overloaded Get_Line that also returns End_Of_File as an OUT Boolean.  This would solve the problem of requiring an exception to determine when end-of-file occurs, without requiring the program to call End_Of_File before Get_Line which doesn't really work with standard input.

                      -- Adam






> The title is "Get_Line problem (GNAT bug?)", at Dec 2006. Please search.
> You may remember it because you had joined in this thread. (I had not joined :-)

Re: What would you like in Ada202X?

[ytomino]

On Friday, May 11, 2012 2:09:16 AM UTC+9, Adam Beneschan wrote:
> 
> Ah, OK, that works for me too.  It doesn't work when I click on the link, even though the link is highlighted and invites me to click on it.  So when I do, I just get the page that says "Welcome to the new Google Groups".  Welcome, indeed.  I've said this multiple times before, but every time Google improves Google Groups they make it worse.  On the other hand, the new Google Groups does have some cool features, such as ... ummm ... having the word "new" in the title.  That's a cool feature, right?  Right?

That's right... I became uneasy a little because I'm pleased with new Google Reader. Old Google Reader separates a thread by 10 comments. New Google Reader shows it as one page. I feel that's also cool. My sense may be strange... So far so good.

> 
> Anyway, I looked over the thread, and it's one I was involved a lot in.  As I see it, it boils down to (1) End_Of_File should never be used on standard input, because that could cause problems if standard input is not a file.  It could require the program to attempt to read input from the user at the wrong time.  (2) If End_Of_File is used on a File_Type, implementations can always get things to work reasonably when the file is a disk file, and no language change is needed.
> 
> What *might* be useful, though, is an overloaded Get_Line that also returns End_Of_File as an OUT Boolean.  This would solve the problem of requiring an exception to determine when end-of-file occurs, without requiring the program to call End_Of_File before Get_Line which doesn't really work with standard input.

I doubt (2).
Imagine a file containing 10 empty lines. I want to copy it with End_Of_File. I probably will get new file containing 9 empty lines.
If a empty line means something(ex. the blank field), it's bad.

Overloaded Get_Line sounds good. And overloaded Get (Character) is a same because inputting by one character is used sometimes.
(IMHO, I feel the behavior of End_Of_File should be changed like other languages, even if it breaks compatibility...)

Re: What would you like in Ada202X?

[Niklas Holsti]

On 12-05-09 01:22 , Randy Brukardt wrote:
> "Niklas Holsti"<niklas.holsti@tidorum.invalid>  wrote in message
> news:a0rsroFp8lU1@mid.individual.net...
>> On 12-05-08 03:48 , Randy Brukardt wrote:
> ...
>>> It seemed like a useful idea back in the day,
>>
>> I think that extending enumeration types by "deepening" is a different
>> idea than the AI95-261 "widening" idea. Don't you think that they are
>> logically different?
>
> The details are different, but the basic idea (adding more literals) is
> unchanged. And the use is in adding more literals, the details on exactly
> how you do that are much less important.

Perhaps I did not describe it well, but I am surprised that you don't 
see more difference between "widening" and "deepening". Note that:

- The "widening" extension only adds literals. The derived type has all 
literals of the parent type, plus the added literals.

- The "deepening" extension *replaces* some parent literals with new 
literals. The derived type need not have any literals in common with the 
parent type. But each parent-type literal corresponds to a range of 
derived-type literals.

A big difference is that for "widening", there is a natural conversion 
(embedding, really) from the parent type to the derived type, while for 
"deepening" the natural conversion goes the other way, from the derived 
type to the parent type.

>>> but to be really useful, we
>>> need the equivalent of class-wide operations.
>>
>> That is the main question: do we?
>
> We need class-wide operations for Integer and Float and (especially) String,
> so it's hard to imagine how we could avoid needing them for such an
> enumeration!
>
> For example:
>                Put (X : in Root_Integer'Class);
> is much more useable than a generic that you have to instantiation for each
> kind of type. (Some operations really do cross-cut types.)

Ah, I didn't realise that you meant such a radical enlargement of the 
present tagged-type class-wide programming. Is there an AI on that? I 
looked for one, but did not find any.

I agree that if a future Ada allows 'Class on Root_Integer (and 
presumably on most or all other types, too), then "deepened" 
enumerations would also have to support that.

> Inheritance of operations is virtually useless without class-wide
> operations. Note that class-wide operations don't necessarily have to
> involve dispatching, although that does seem like the most sensible model.
> Dmitry has pointed out repeatedly that one does not need to store tags with
> values of specific types; they can be added when converted to a class-wide
> type and that makes the most sense for elementary and array tagged types.

Ok, I see how that can work: you synthesize tags and perhaps other "type 
descriptors" and pass them as hidden parameters to class-wide 
operations. (I guess that your experience in implementing code-sharing 
generics would be useful, no?)

>> It seems to me that adding class-wide operations would force to
>> use some kind of tags, call by reference, and view conversions, and then
>> it becomes so similar to tagged types that it is not worth it.
>
> Umm, that's when it *does* become worth it. The problem is untagged types
> are pretty hard to use.

Do you mean they are hard to use in current Ada, or hard to use with 
class-wide operations in the future Ada?

> (Note that I disagree about call-by-reference, but
> that's a detail.)

I'd be interested in your view on that, since it seems to bear on the 
problem of conversions between parent types and "deepened" types.

>> I think the idea of "deepened" enumeration types is worth pursuing only if
>> it is useful without class-wide operations.
>
> Then don't bother. IMHO, at least.

Since I respect your opinion very much, I will have to think about 
class-wide programming for "deepened" enumerations.

One problem is that there would be two notions of Enum'Class:

1. If Enum'Class covers only enumeration types derived from Enum using 
the current Ada derivation method, then the set of literals is the same 
for all types in Enum'Class. This both simplifies and limits what a 
class-wide operation can do.

2. If Enum'Class covers also "deepened" enumeration types, then 
different types in Enum'Class can have completely different sets of 
literals. However, a class-wide operation can rely on the fact that each 
literal in Enum corresponds to a range of literals in any type in 
Enum'Class. There needs to be some way (an attribute function?) to map 
an Enum value to the range within the actual type of the class-wide 
parameter.

>> Another issue is that generic formal types of the "deepened" kind would be
>> needed. I think that would be the next point to work on for this proposal.
>
> We already have that. Generic derived types (with the ancestor being an
> enumeration) would provide the needed inheritance.

Not quite, I think, because that has the same limitations as the 1st 
notion of Enum'Class, above.

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

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Fri, 11 May 2012 00:22:30 +0300, Niklas Holsti wrote:

> Ok, I see how that can work: you synthesize tags and perhaps other "type 
> descriptors" and pass them as hidden parameters to class-wide 
> operations.

For a scalar type T and T'Class have different representations. That does
the trick. No need in hidden parameters.

You compose class-wide operation T'Class with type conversion T -> T'Class.
This is the model #1. T is handled as if it were as a subtype of T'Class
Tag can be considered a discriminant. T has Tag set to T and the
representation with no tag stored.

This is another language improvement I want to have: removable static
discriminants with static operations on discriminants. Ideally you should
be able to implement all arrays and OO-stuff manually.

> One problem is that there would be two notions of Enum'Class:
> 
> 1. If Enum'Class covers only enumeration types derived from Enum using 
> the current Ada derivation method, then the set of literals is the same 
> for all types in Enum'Class. This both simplifies and limits what a 
> class-wide operation can do.
> 
> 2. If Enum'Class covers also "deepened" enumeration types, then 
> different types in Enum'Class can have completely different sets of 
> literals. However, a class-wide operation can rely on the fact that each 
> literal in Enum corresponds to a range of literals in any type in 
> Enum'Class. There needs to be some way (an attribute function?) to map 
> an Enum value to the range within the actual type of the class-wide 
> parameter.

If literals are primitive operations.

A. Literals are primitive function Foo return Enum. They are inherited and
belong to the class.

B. Literals are values, contravariant and not inherited.

There is no much difference when enumeration have no classes. With classes
one should make a choice.

Since deepening effectively disallows operations in the model B, you will
have problems with disallowed operations used on class-wide objects of the
type which disallowed them. You could use a fallback to be last type which
owned the operation or have Constraint_Exception in all class-wide
contracts (Ada 95 approach).

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

Re: What would you like in Ada202X?

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:a12psmFskuU1@mid.individual.net...
> On 12-05-09 01:22 , Randy Brukardt wrote:
>> "Niklas Holsti"<niklas.holsti@tidorum.invalid>  wrote in message
>> news:a0rsroFp8lU1@mid.individual.net...
>>> On 12-05-08 03:48 , Randy Brukardt wrote:
>> ...
>> The details are different, but the basic idea (adding more literals) is
>> unchanged. And the use is in adding more literals, the details on exactly
>> how you do that are much less important.
>
> Perhaps I did not describe it well, but I am surprised that you don't see 
> more difference between "widening" and "deepening". Note that:
>
> - The "widening" extension only adds literals. The derived type has all 
> literals of the parent type, plus the added literals.
>
> - The "deepening" extension *replaces* some parent literals with new 
> literals. The derived type need not have any literals in common with the 
> parent type. But each parent-type literal corresponds to a range of 
> derived-type literals.
>
> A big difference is that for "widening", there is a natural conversion 
> (embedding, really) from the parent type to the derived type, while for 
> "deepening" the natural conversion goes the other way, from the derived 
> type to the parent type.

You are thinking like a language lawyer, much less like a user (something 
I'm often accused of!). I'm not paying all that much attention to the 
details of your proposal, but rather trying to look at it as a user would. 
In that case, both mechanisms give a way to add/change enumeration literals 
for an existing enumeration type. I think that's the capability that users 
would want -- and I doubt that they care particularly much how it is 
accomplished.

Of course, the details do matter at some point, but given that it's a number 
of years before any of this stuff will be worked on very seriously, I'm 
trying to look at the broad view now.

...
>>>> but to be really useful, we
>>>> need the equivalent of class-wide operations.
>>>
>>> That is the main question: do we?
>>
>> We need class-wide operations for Integer and Float and (especially) 
>> String,
>> so it's hard to imagine how we could avoid needing them for such an
>> enumeration!
>>
>> For example:
>>                Put (X : in Root_Integer'Class);
>> is much more useable than a generic that you have to instantiation for 
>> each
>> kind of type. (Some operations really do cross-cut types.)
>
> Ah, I didn't realise that you meant such a radical enlargement of the 
> present tagged-type class-wide programming.

If we suddenly have class-wide programming for enumerations, it would be mad 
to not allow it for other, similar types.

> Is there an AI on that? I looked for one, but did not find any.

Not really, although I mentioned an off-the-wall proposal for Strings that 
in an AI in another message from Wednesday.

...
>>> It seems to me that adding class-wide operations would force to
>>> use some kind of tags, call by reference, and view conversions, and then
>>> it becomes so similar to tagged types that it is not worth it.
>>
>> Umm, that's when it *does* become worth it. The problem is untagged types
>> are pretty hard to use.
>
> Do you mean they are hard to use in current Ada, or hard to use with 
> class-wide operations in the future Ada?

I was thinking of derived untagged types; I should have said that.

The issue is that there is virtually no difference between a derived type 
and two unrelated types with conversion functions. If you call the 
conversion functions "+" (as some people recommend), you're required to 
write one whole additional character when using two unrelated types. It's 
hard to imagine designing the huge mechanism of derived types (with all of 
its weird problems and compatibility issues) in order to say typing one 
character per use. (One could even say that the extra typing makes the 
program more understandable, I'm not sure I'd go that far.)

The only thing that you can get from derived types that can't be done any 
other way is inherit operations (and their interfaces). And that's just 
short of useless in Ada; the only use you can make of that is via generic 
derived types. (Moreover, once you add operations to untagged derived types, 
you can no longer specify their representation, meaning that using them 
forces you to give up another key Ada feature.)

That led me to say:

...
>>> I think the idea of "deepened" enumeration types is worth pursuing only 
>>> if
>>> it is useful without class-wide operations.
>>
>> Then don't bother. IMHO, at least.


                              Randy.

Re: What would you like in Ada202X?

[Niklas Holsti]

On 12-05-10 03:47 , Randy Brukardt wrote:
> "Dmitry A. Kazakov"<mailbox@dmitry-kazakov.de>  wrote in message
> news:kl5nkc2s9tsx.61oqe3a9ogra.dlg@40tude.net...
>> On Tue, 08 May 2012 22:20:21 +0300, Niklas Holsti wrote:
>>> I would like to make the "deepening" derivation as similar as possible
>>> to the derivation of enumeration types in
>>
>> With the problems solved you will get enumeration extension for granted.
>> Your proposal rounds about how to generate conversion functions. You can
>> generate in-conversion, but cannot out-conversions. The case of plain
>> extension has the opposite problem: in-conversions are impossible. But the
>> mechanics of all this is same: interface inheritance, delegation of some
>> inherited operations to the parent's body composed with a conversion.
>>
>> Semantically, there always will be some issue with conversions, because
>> any
>> non-trivial modification of a type, must break something. If it did not,
>> you would use the old type instead. It is not the language business, it is
>> up to the programmer to resolve. The language should simply refuse to
>> automate suspicious cases forcing the programmer to intervene.
>
> Here I agree with Dmitry (but note that the mechanism he is talking about
> here has nothing to do with multiple inheritance; it works just fine with
> Ada 95 type derivation or something similar to that).

I agree with Dmitry's and your rejection of automated but suspect 
conversions, which is why I suggested not to inherit parent operations 
that would need conversion from the parent enumeration type to the 
"deepened" enumeration type. I could also accept the alternative to 
inherit abstract versions of such parent operations, which would be more 
useful for class-wide programming.

But I don't see how a single programmer-defined conversion function from 
the parent type to the deepened type could work in general, that is, how 
the same conversion would be appropriate for all "out", "in out", and 
function-return positions in all parent operations. And if different 
conversion functions are needed for different operations/parameters, we 
may as well choose "inherit as abstract" and require the programmer to 
implement these operations for the derived type.

> It makes more sense to
> allow the programmer to provide the needed conversion functions than to come
> up with special features for doing that.

The goal of the "deepening extension" for enumerated types is not to 
define conversion functions, but to create classes of enumeration types 
with logical (and hopefully useful) relationships (refinement of 
classifications). The conversion function arises naturally from the 
relationship. (Which of course does not mean that this particular kind 
of relationship is useful enough to merit specific support in the language.)

> I designed a straw-man "Root_String" around such conversion functions (you
> can find it in AI12-0021-1),

Thanks for the pointer. I have read the AI, but I'm not sure which 
"conversion functions" you mean, and how the AI relates to the present 
discussion. The AI defines an interface Root_String with (among others) 
operations Set_Char and Get_Char to set or get the N'th character of the 
string, as a Wide_Wide_Character.

The AI then suggests concrete instances that implement the Root_String 
interface using a String representation, or an UTF_8_String 
representation, which means that the instances must implement Set_Char 
and Get_Char that convert between Character and Wide_Wide_Character, or 
a UTF-8 encoding and Wide_Wide_Character, respectively. Are these the 
"conversion functions" that you mean? But they don't convert between 
Root_String and its instances, they just adapt the Root_String 
operations to various representations. This is "conversion" in some 
abstract sense, but not a conversion of a whole string value from one 
"string" type to another "string" type.

The AI suggests that "most of the IO routines that take strings would 
have versions that would take Root_String'Class" and that "the string 
types would carry their representation along when passed into routines". 
I can understand how that works for "in" parameters, but it is not so 
clear for "in out" parameters and function return values.

For example, the function Ada.Directories.Current_Directory now returns 
String; how would that, and other I/O functions that return String, be 
handled? Would they return Root_String'Class?

> This wasn't vetted by anyone, so take it with a grain of salt...
> but it illustrates the possibilities.

I think Root_String is a special case, because the only real difference 
is in the representation of the string characters. Also, 
Wide_Wide_Character fortuitously provides a universal representation (in 
the current language).

I'm not denying that such hand-built conversions/adapters can be useful, 
but (so far) they seem a bit clumsy compared to more integrated type 
constructions such as tagged type classes.

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

Re: What would you like in Ada202X?

[stefan-lucks]

On Thu, 10 May 2012, Gustaf Thorslund wrote:

> I like the idea of parallel loops. Parallel functions I don't really 
> know what it is so can't tell. For importance I suppose it depends on 
> who you ask. There might even be those who could live without tasks.
> 
[...]
> 
> parfor I in 1..10 loop --  parfor might not be best name, but I had to
>                        --  invent something

That looks like the ideal place for a new pragma, rather than a new 
keyword:

  for I in 1 .. 10 loop
    pragma(Parallelize_Loop);
    ...
  end loop;


--
---- 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!  ------

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Mon, 14 May 2012 11:25:55 +0200, stefan-lucks@see-the.signature wrote:

> On Thu, 10 May 2012, Gustaf Thorslund wrote:
> 
>> I like the idea of parallel loops. Parallel functions I don't really 
>> know what it is so can't tell. For importance I suppose it depends on 
>> who you ask. There might even be those who could live without tasks.
>> 
> [...]
>> 
>> parfor I in 1..10 loop --  parfor might not be best name, but I had to
>>                        --  invent something
> 
> That looks like the ideal place for a new pragma, rather than a new 
> keyword:
> 
>   for I in 1 .. 10 loop
>     pragma(Parallelize_Loop);
>     ...
>   end loop;

No. If that is an advise to try to optimize the loop if possible, that
should be a compiler switch.

When the compiler is rather ordered to run it in parallel and must flag it
as an error if cannot (e.g. a mutex is taken inside etc), then that should
be a statement.

P.S. I wonder why people keep on calling that thing loop. It has little to
do with iterations. It is a set of paramerized sequences of statements
executed asynchronously with a synchronization point at the end. The syntax
should reflect that.

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

Re: What would you like in Ada202X?

[Georg Bauhaus]

On 14.05.12 14:19, Dmitry A. Kazakov wrote:
> On Mon, 14 May 2012 11:25:55 +0200, stefan-lucks@see-the.signature wrote:
> 
>> On Thu, 10 May 2012, Gustaf Thorslund wrote:
>>
>>> I like the idea of parallel loops. Parallel functions I don't really 
>>> know what it is so can't tell. For importance I suppose it depends on 
>>> who you ask. There might even be those who could live without tasks.
>>>
>> [...]
>>>
>>> parfor I in 1..10 loop --  parfor might not be best name, but I had to
>>>                        --  invent something
>>
>> That looks like the ideal place for a new pragma, rather than a new 
>> keyword:
>>
>>   for I in 1 .. 10 loop
>>     pragma(Parallelize_Loop);
>>     ...
>>   end loop;
> 
> No. If that is an advise to try to optimize the loop if possible, that
> should be a compiler switch.
> 
> When the compiler is rather ordered to run it in parallel and must flag it
> as an error if cannot (e.g. a mutex is taken inside etc), then that should
> be a statement.
> 
> P.S. I wonder why people keep on calling that thing loop. It has little to
> do with iterations. It is a set of paramerized sequences of statements
> executed asynchronously with a synchronization point at the end. The syntax
> should reflect that.

For a start,

  for all I in 1 .. 10 do
    { stmt }
  end do all;

  for some I in 1 .. 10 do
    { stmt }
  end do some;

all: do stmt for every I of 1 .. 10, in any order
some: do stmt for one I from 1 .. 10, arbitrarily chosen

While we are at it, can we have goal directed evaluation � la Icon?

   while some I ... => P(I, ...) do
      { stmt }
   end do some;

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Mon, 14 May 2012 15:09:54 +0200, Georg Bauhaus wrote:

> On 14.05.12 14:19, Dmitry A. Kazakov wrote:

>> P.S. I wonder why people keep on calling that thing loop. It has little to
>> do with iterations. It is a set of paramerized sequences of statements
>> executed asynchronously with a synchronization point at the end. The syntax
>> should reflect that.
> 
> For a start,
> 
>   for all I in 1 .. 10 do
>     { stmt }
>   end do all;

Yes, I also thought about that, but it still looks much like a loop.
 
>   for some I in 1 .. 10 do
>     { stmt }
>   end do some;

I considered how to do this:

   up-to-10-instances of
      ...
      accept Service_Request do
          ...
      end do;
      ...
   end;

The semantics is: accept 1 to 10 calls to the entry Service_Request and
service all rendezvous concurrently.

> While we are at it, can we have goal directed evaluation � la Icon?
> 
>    while some I ... => P(I, ...) do
>       { stmt }
>    end do some;

The semantics is unclear, how does I change? Is it inference?

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

Re: What would you like in Ada202X?

[Georg Bauhaus]

On 14.05.12 15:40, Dmitry A. Kazakov wrote:
> On Mon, 14 May 2012 15:09:54 +0200, Georg Bauhaus wrote:
> 
>> On 14.05.12 14:19, Dmitry A. Kazakov wrote:
> 
>>> P.S. I wonder why people keep on calling that thing loop. It has little to
>>> do with iterations. It is a set of paramerized sequences of statements
>>> executed asynchronously with a synchronization point at the end. The syntax
>>> should reflect that.
>>
>> For a start,
>>
>>   for all I in 1 .. 10 do
>>     { stmt }
>>   end do all;
> 
> Yes, I also thought about that, but it still looks much like a loop.

   with all I in 1 .. 10 do
      { stmt }
   end do all;

That's a non-loop indicator up front.

>>   for some I in 1 .. 10 do
>>     { stmt }
>>   end do some;

   with some I in 1 .. 10 do
      { stmt }
   end do some;

> I considered how to do this:
> 
>    up-to-10-instances of
>       ...
>       accept Service_Request do
>           ...
>       end do;
>       ...
>    end;
> 
> The semantics is: accept 1 to 10 calls to the entry Service_Request and
> service all rendezvous concurrently.

How would this work? Expanded into a family? I had thought that each
acceptor servicing would have to perform one atomic sequence, unless
all calls get serviced in the exact same way.

>> While we are at it, can we have goal directed evaluation � la Icon?
>>
>>    while some I ... => P(I, ...) do
>>       { stmt }
>>    end do some;
> 
> The semantics is unclear, how does I change? Is it inference?

The idea is that "some I ..." produces a value as long
as (a) a value is needed and (b) P(I, ...) is true.
This is probably a little vague, and in part syntactic sugar.


procedure Iconic is

   -- <quote>
   -- every subject ? write (find ("fish"));
   -- prints 3, 13, and 23.
   -- </>

   Subject : constant String :=
     "a fish is a fish is a fish";

   Max : constant Natural := 2;
   -- no more than `Max` fish

   function Find
     ( Source : String;
       Pattern : String )
     return Forward_Iterator;

begin
   if some Position in Find(Subject, "fish") => True then
      Put_Line (Natural'Image (Position));
   end if;

   if some Position in Find(Subject, "fish")
     => Position < Subject'Length / 2
   then
      Put_Line (Natural'Image (Position));
   end if;

   while some Position in Find (Subject, "fish")
     => Position < Subject'Length / 2
   do
      Put_Line (Natural'Image (Position));
   end do;

   N := 0;
   while some Position in Find (Subject, "fish")
     => N < Max
   do
      N := N + 1;
      Put_Line (Natural'Image (Position));
   end do;

end Iconic;

Re: What would you like in Ada202X?

[Gustaf Thorslund]

On 2012-05-14 17:50, Georg Bauhaus wrote:
> On 14.05.12 15:40, Dmitry A. Kazakov wrote:
>> On Mon, 14 May 2012 15:09:54 +0200, Georg Bauhaus wrote:
>>
>>> On 14.05.12 14:19, Dmitry A. Kazakov wrote:
>>
>>>> P.S. I wonder why people keep on calling that thing loop. It has little to
>>>> do with iterations. It is a set of paramerized sequences of statements
>>>> executed asynchronously with a synchronization point at the end. The syntax
>>>> should reflect that.
>>>
>>> For a start,
>>>
>>>    for all I in 1 .. 10 do
>>>      { stmt }
>>>    end do all;
>>
>> Yes, I also thought about that, but it still looks much like a loop.
>
>     with all I in 1 .. 10 do
>        { stmt }
>     end do all;
>
> That's a non-loop indicator up front.

Looks good to me. Since there is no "parallel" involved it also doesn't 
give the impression everything will actually run in parallel. I think 
this is good. I suppose somewhere there need to be a way to set max 
concurrency.

Regards,
Gustaf
-- 
http://gustaf.thorslund.org

Re: What would you like in Ada202X?

[tmoran]

>>>> P.S. I wonder why people keep on calling that thing loop. It has little to
>>>> do with iterations.
 Programming should be about what you want to happen, and as little as
possible about the details of how it happens.  So
  for I in 1 .. 10 do
has the advantage that "do" doesn't imply ordering the way "loop" does.
But A := (others=>0); is a still better way of saying "fill array A with
zeros and I don't care what order or how much in parallel you do it".
Similarly, you can say
  A := B+C;
where function "+" is implemented by a call to a library routine
that (may) use machine parallelism.  Certainly
  for I in A'range loop
    A(I) := B(I) + C(I);
  end loop;
is much more verbose and the use of "loop" instead of "do" quite
unnecessarily suggests the programmer insists on a sequential order.

> I suppose somewhere there need to be a way to set max concurrency.
  This ability to say something about the resources to use on the target
machine is normally done with compilation parameters, which is pretty
limiting.  Specifying the max concurrency for a piece of code is analogous
to specifying that certain arrays are rarely accessed and are good
candidates for swapping, while others really need to stay in RAM.  I've
not seen that in a language either.

Re: What would you like in Ada202X?

[Gustaf Thorslund]

On 2012-05-15 00:49, tmoran@acm.org wrote:

>> I suppose somewhere there need to be a way to set max concurrency.
>    This ability to say something about the resources to use on the target
> machine is normally done with compilation parameters, which is pretty
> limiting.  Specifying the max concurrency for a piece of code is analogous
> to specifying that certain arrays are rarely accessed and are good
> candidates for swapping, while others really need to stay in RAM.  I've
> not seen that in a language either.

I agree it would be kind of stupid setting it at compilation time. Was 
thinking of some way setting it at runtime. Then this could be given as 
a command line argument or in a configuration file, but this would be up 
to the user to do. With a database (DBMS) (or browser, or email 
client...) you would not want to set the size of buffers and memory used 
at compilation time, but you would still want to have it configurable.


Looking at "I in 1..5" vs "X in 1..50000" one might expect the first one 
to run with full concurrency, but most of us wouldn't want it on the 
second one (at least not today, but maybe 202X). Nested/recursive calls 
could also result in a bit too much concurrency.

If there should be a global limit and/or local limit I'd leave for 
others to discuss.

For local concurrency control one might still prefer to do

with all I in 1 .. 10 do
   for J in I .. 1000*I loop
     { stmt }
   end loop;
end do all; -- or end with all;

instead of

with all J in 1 .. 10000 do
   { stmt }
end do all; -- or end with all;

But that would be up to the user to decide and could be related to 
resource allocation needed for each concurrent sequence of statements or 
aggregating of the results.

Regards,
Gustaf
-- 
http://gustaf.thorslund.org

Re: What would you like in Ada202X?

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:a1ahq2F7e2U1@mid.individual.net...
> On 12-05-10 03:47 , Randy Brukardt wrote:
>> "Dmitry A. Kazakov"<mailbox@dmitry-kazakov.de>  wrote in message
>> news:kl5nkc2s9tsx.61oqe3a9ogra.dlg@40tude.net...
>>> On Tue, 08 May 2012 22:20:21 +0300, Niklas Holsti wrote:
>>>> I would like to make the "deepening" derivation as similar as possible
>>>> to the derivation of enumeration types in
>>>
>>> With the problems solved you will get enumeration extension for granted.
>>> Your proposal rounds about how to generate conversion functions. You can
>>> generate in-conversion, but cannot out-conversions. The case of plain
>>> extension has the opposite problem: in-conversions are impossible. But 
>>> the
>>> mechanics of all this is same: interface inheritance, delegation of some
>>> inherited operations to the parent's body composed with a conversion.
>>>
>>> Semantically, there always will be some issue with conversions, because
>>> any
>>> non-trivial modification of a type, must break something. If it did not,
>>> you would use the old type instead. It is not the language business, it 
>>> is
>>> up to the programmer to resolve. The language should simply refuse to
>>> automate suspicious cases forcing the programmer to intervene.
>>
>> Here I agree with Dmitry (but note that the mechanism he is talking about
>> here has nothing to do with multiple inheritance; it works just fine with
>> Ada 95 type derivation or something similar to that).
>
> I agree with Dmitry's and your rejection of automated but suspect 
> conversions, which is why I suggested not to inherit parent operations 
> that would need conversion from the parent enumeration type to the 
> "deepened" enumeration type. I could also accept the alternative to 
> inherit abstract versions of such parent operations, which would be more 
> useful for class-wide programming.
>
> But I don't see how a single programmer-defined conversion function from 
> the parent type to the deepened type could work in general, that is, how 
> the same conversion would be appropriate for all "out", "in out", and 
> function-return positions in all parent operations. And if different 
> conversion functions are needed for different operations/parameters, we 
> may as well choose "inherit as abstract" and require the programmer to 
> implement these operations for the derived type.

"Conversion" is almost never a single function; indeed, Ada requires it to 
work both ways in most cases. In particular, if you have "out" parameters, 
you need a conversion from the parent to the child type, just like you need 
a conversion from the child to the parent to implement "in" parameters.

...
>> I designed a straw-man "Root_String" around such conversion functions 
>> (you
>> can find it in AI12-0021-1),
>
> Thanks for the pointer. I have read the AI, but I'm not sure which 
> "conversion functions" you mean, and how the AI relates to the present 
> discussion.

Just a bit: the string types have functions that convert through a universal 
representation. I used that because it was available, but it would work just 
as well with conversions directly between the various representations.

...
> The AI suggests that "most of the IO routines that take strings would have 
> versions that would take Root_String'Class" and that "the string types 
> would carry their representation along when passed into routines". I can 
> understand how that works for "in" parameters, but it is not so clear for 
> "in out" parameters and function return values.
>
> For example, the function Ada.Directories.Current_Directory now returns 
> String; how would that, and other I/O functions that return String, be 
> handled? Would they return Root_String'Class?

Yes, of course, there would be a version of everything that takes a String 
that would take a Root_String'Class. (I don't think there are many routines 
that take "out" String parameters, because you can't change the size that 
way.)

>> This wasn't vetted by anyone, so take it with a grain of salt...
>> but it illustrates the possibilities.
>
> I think Root_String is a special case, because the only real difference is 
> in the representation of the string characters. Also, Wide_Wide_Character 
> fortuitously provides a universal representation (in the current 
> language).
>
> I'm not denying that such hand-built conversions/adapters can be useful, 
> but (so far) they seem a bit clumsy compared to more integrated type 
> constructions such as tagged type classes.

The problem is that the language doesn't provide the syntax to connect the 
"hand-built" conversions with the existing machinery of (sub)type 
conversion; I'm assuming that would be done if the conversion solution was 
intended to be used as a first-class technique.

Specifically, when you "derive" a new type from an existing type, the idea 
is that you could give the derived type any declaration and representation 
you want (it wouldn't have to be related to the parent, with some limits), 
and you could then define conversion functions (always two) similarly to the 
way that streaming subprograms are defined. Inherited routines would use 
those conversions when conversions are needed (as already defined by the 
language). That would allow one to have very unrelated types be "related" 
via derivation.

I'm not sure that it is good idea in general, but certainly it makes sense 
in limited cases (surely including your enumeration example).

                                   Randy.

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Tue, 15 May 2012 01:30:03 -0500, Randy Brukardt wrote:

> Specifically, when you "derive" a new type from an existing type, the idea 
> is that you could give the derived type any declaration and representation 
> you want (it wouldn't have to be related to the parent, with some limits), 
> and you could then define conversion functions (always two) similarly to the 
> way that streaming subprograms are defined.

Four conversions. If supertypes supported, i.e. ones exporting their
operations to the "parent." This gives you two more conversions. If the new
is both sub- and supertype, an "equivalent" type, it would take four
conversions to define.

(Supertypes are important for bringing existing and originally unrelated
types into one class.)

> I'm not sure that it is good idea in general, but certainly it makes sense 
> in limited cases (surely including your enumeration example).

1- all string and character types;
2. all numeric types;
3. managed access types, fat pointers, garbage collection.

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

Re: What would you like in Ada202X?

[Niklas Holsti]

On 12-05-12 03:11 , Randy Brukardt wrote:
> "Niklas Holsti"<niklas.holsti@tidorum.invalid>  wrote in message
> news:a12psmFskuU1@mid.individual.net...
>> On 12-05-09 01:22 , Randy Brukardt wrote:
>>> "Niklas Holsti"<niklas.holsti@tidorum.invalid>   wrote in message
>>> news:a0rsroFp8lU1@mid.individual.net...
>>>> On 12-05-08 03:48 , Randy Brukardt wrote:
>>> ...
>>> The details are different, but the basic idea (adding more literals) is
>>> unchanged. And the use is in adding more literals, the details on exactly
>>> how you do that are much less important.
>>
>> Perhaps I did not describe it well, but I am surprised that you don't see
>> more difference between "widening" and "deepening". Note that:
>>
>> - The "widening" extension only adds literals. The derived type has all
>> literals of the parent type, plus the added literals.
>>
>> - The "deepening" extension *replaces* some parent literals with new
>> literals. The derived type need not have any literals in common with the
>> parent type. But each parent-type literal corresponds to a range of
>> derived-type literals.
>>
>> A big difference is that for "widening", there is a natural conversion
>> (embedding, really) from the parent type to the derived type, while for
>> "deepening" the natural conversion goes the other way, from the derived
>> type to the parent type.
>
> You are thinking like a language lawyer, much less like a user (something
> I'm often accused of!).

It may look like that, but I was trying to explain that the relationship 
between the parent enumeration type and the derived enumeration type is 
quite different in the two cases, and this is important also for the 
user's point of view -- what the derivation "means" for the user. There 
is also a large difference in the "grip" that operations of the parent 
type have on values of the derived type.

> I'm not paying all that much attention to the
> details of your proposal,

Since the difference between "widening" and "deepening" is in these 
so-called :-) details, I now understand why you don't appreciate the 
difference. I'm going to continue the thread a bit anyway.

> but rather trying to look at it as a user would.
> In that case, both mechanisms give a way to add/change enumeration literals
> for an existing enumeration type.

The widening derivation only adds. The deepening derivation changes, by 
refining.

> I think that's the capability that users
> would want -- and I doubt that they care particularly much how it is
> accomplished.

IMO to "add/change enumeration literals" is an abstraction that is not a 
good description of what the user needs. (If I may be a bit cheeky, this 
description seems to be thinking of an enumeration type as just a 
mapping from literals to integers -- "Want add some literals? No 
problem, there are plenty of integers left!")

I think that there are two quite different "use cases", from the user's 
point of view, which correspond to "widening" and "deepening" 
respectively. And I think that the "deepening" case is more worthy of 
language support than the "widening" case.

To make the difference clear-cut, I will limit the "deepening" case to 
the form that only refines literals, and forget about the bybrid case 
that emulates AI95-261 by permitting the addition of new literals with 
no relationship to existing literals in the parent type.

THE WIDENING CASE

In the first case, which corresponds to "widening", the user finds an 
existing enumeration type that classifies some set of phenomena, but the 
user needs to handle a larger set. The user wants an enumeration that 
incorporates the existing enumeration as a subrange, but in addition has 
new literals that classify the new phenomena.

The author of the existing enumeration type has probably not foreseen 
that the type would be extended in this way, making this 
derivation/reuse *opportunistic* rather than planned.

Following AI95-261, the user derives a "widened" enumeration type that 
has some new literals following all the original literals. These new 
literals have no relationship to the original literals, except that of 
being different: they represent phenomena that were not considered or 
even anticipated in the design of the parent enumeration.

It is quite unlikely that the operations on the parent type could do 
anything sensible if given one of the new literals as a parameter, and 
in fact AI95-261 asks for a Constraint_Error if that is attempted. The 
user must therefore override all these operations for the "widened" 
type. At best, the overriding operations can be limited to handling the 
new literals only, while delegating the original literals to the 
original parent-type operations. Inheriting the parent-type operations 
does not help much; it only saves a type conversion in the delegating call.

Classwide operations that take Parent'Class have the same problem: they 
will not know what to do with the added literals. In fact, it feels like 
nonsense to try; for example, a case statement that lists all the Parent 
literals, and thus seems complete, is no longer complete if the new 
literals are considered.

THE DEEPENING CASE

Here, the user sees the existing (parent) enumeration type as a 
high-level (general, rough, large-grain) classification of some 
phenomena, and the user needs a more detailed classification for a 
particular application. It is likely that the designer of the parent 
type has made it general and undetailed on purpose. In other words, the 
parent enumeration type is meant to be extended into a more detailed and 
specialized type. This derivation/reuse is thus planned, not 
opportunistic as in the "widening" case. (This is analogous to making a 
type tagged so that it can be the root of a class.)

The user derives the "deepened" enumeration type by refining each 
literal of the parent type into a set of new literals. These new 
literals represent subcases of the phenomenon represented by the parent 
literal. For example, the parent literal Request can be refined into a 
Read request and a Write request. Both Write and Read "are" Requests, 
and together (in this example) are all the Requests that exist.

Now it makes sense to inherit parent-type operations, because an 
operation that knows what to do for a Request can do that also for a 
Read or a Write, since they "are" Requests. To call an inherited 
parent-type operation with a derived-type "in" parameter the "in" 
parameter is converted to the corresponding parent literal, and the 
parent-type operation is called. Case-statements in the parent-type 
operation are still complete, and the only semantic problems arise if 
the operation has "out" or "in out" parameters or a return value of the 
parent type, as has been discussed in this thread earlier.

If "deepened" enumeration types are further "deepened", we get a forest 
of related enumeration types that classify the original root phenomena 
in more and more detailed ways, possibly on different grounds. For 
example, the Requests could also be divided into Immediate requests and 
Delayed requests.

In a sense, the enumeration literals at the various levels in such a 
forest correspond to the tags in a tagged-type hierarchy of the same shape.

>>>>> but to be really useful, we
>>>>> need the equivalent of class-wide operations.

Ok, I have come to agree with you on this, at least if class-wide 
programming is extended to other non-tagged types like Integer.

>>> The problem is untagged types are pretty hard to use.
>>
>> Do you mean they are hard to use in current Ada, or hard to use with
>> class-wide operations in the future Ada?
>
> I was thinking of derived untagged types; I should have said that.
>
> The issue is that there is virtually no difference between a derived type
> and two unrelated types with conversion functions. If you call the
> conversion functions "+" (as some people recommend), you're required to
> write one whole additional character when using two unrelated types.

True for "in" parameters and function return values, but I think not 
true for "in out" or "out" parameters, check? A user-defined conversion 
function cannot convert an "out" or "in out" parameter.

> It's
> hard to imagine designing the huge mechanism of derived types (with all of
> its weird problems and compatibility issues) in order to say typing one
> character per use. (One could even say that the extra typing makes the
> program more understandable, I'm not sure I'd go that far.)

Of course one also saves the other type declaration itself.

The advantage gained is the proverbial separation of Apple_Count from 
Orange_Count. If, instead of counts, these are some complex data 
structures, declaring them twice as separate types creates redundant, 
duplicated code. Moreover, the conversion functions can become complex 
and expensive, and perhaps practically impossible if limited types are 
involved.

I like very much that Ada lets me derive a new type from any type.

> The only thing that you can get from derived types that can't be done any
> other way is inherit operations (and their interfaces). And that's just
> short of useless in Ada; the only use you can make of that is via generic
> derived types.

I think operation inheritance is useful if the purpose of the derivation 
is to separate Apple_Count from Orange_Count (for complex types).

> (Moreover, once you add operations to untagged derived types,
> you can no longer specify their representation, meaning that using them
> forces you to give up another key Ada feature.)

Ha, I've managed to forget about that one, although I have derived 
record type just to have different representations for the same record. 
(As I recall, this was done in a project that had bodyless "types" 
packages, and so no primitive operations.) From my experience, the need 
to inherit primitive operations *and* have a different representation 
for the derived type is rare, so I'm not much bothered by this problem.

I'll return to class-wide programming with "deepened" enumerations in a 
future posting. This one has evolved in my "Drafts" folder long enough :-)

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

Re: What would you like in Ada202X?

[Niklas Holsti]

On 12-05-10 09:45 , ytomino wrote:
> On Tuesday, May 8, 2012 7:34:28 AM UTC+9, Niklas Holsti wrote:
>> On 12-05-07 09:33 , ytomino wrote:
>>> It's interesting.
>>>
>>> What would happen to 'Pos and 'Val ?
>>
>> They would work in the normal way for enumeration types, just as if the
>> parent type and the derived type were declared separately, without
>> derivation.
>>
>>>>    type Message_Kind1 is (Sign_On, Request, Reply, Sign_Off);
>>>>    type Detailed_Message_Kind is new Message_Kind1 with (
>>>>         Request =>   (Read, Write),
>>>>         Reply   =>   (Data, Ack, Refused),
>>>>         others  =>   <>);
>>>
>>> First, Message_Kind1'Pos (Sign_On) = 1, Request = 2, Reply = 3, Sign_Off = 4, of course.
>>
>> That should be 0, 1, 2, and 3. 'Pos starts from zero.
>
> Oops.
>
>>
>>> 1) To keep order, Detailed_Message_Kind'Pos (Read) = 2, Write = 2.5 (float!)
>>
>> No, I would make the 'Pos values for Detailed_Message_Kind be the normal
>> ones for its list of literals: Detailed_Message_Kind'Pos for Sign_On is
>> 0, for Read it is 1, for Write it is 2, for Data it is 3, for Ack it is
>> 4, for Refused it is 5, and for Sign_Off it is 6.
>>
>> I don't see any reason to keep the same position number for the "same"
>> literal of Message_Kind1 and of Detailed_Message_Kind. Although the
>> literals have the same identifier, they are not the same value.
>>
>> That is, Message_Kind1'(Sign_On) is not the same value as
>> Detailed_Message_Kind'(Sign_On), although the latter can be converted to
>> the former (and perhaps vice versa).
>>
>> Moreover, neither the parent type nor the derived type is a subtype
>> (subrange) of the other type, in the Ada sense.
>>
>>> It seems difficult to realize keeping operator "<",">" and keeping
>>> Message_Kind1'Pos (X) = Detailed_Message_Kind'Pos (X) at same time.
>>
>> The code for the relational operators "<" and">" would use the
>> representation, not the position number. I suggested that values of the
>> derived type would be represented by some "parent" bits that represent a
>> value of the parent type, and some more "extension bits" to separate the
>> refining literals from each other. If these bits are packed in a word,
>> with the extension bits less significant than the parent bits, ordinary
>> integer comparison instructions can implement "<" and">" for the
>> derived type. (This is just like lexicographic ordering.)
>>
>>> And it's unclear about representation of "array (Detailed_Message_Kind) of ...".
>>
>> The array index would be the position number, as usual. The position
>> number can be computed from the representation with parent bits and
>> extension bits. To make this computation fast, the compiler could use a
>> constant array "first_pos" that is indexed by the parent bits (that is,
>> by the parent enumerated type) and gives the position number of the
>> first derived-type literal that is refined from this parent-type value.
>> The position number of any value of the derived type is then computed as
>> first_pos(parent bits) + (extension bits).
>>
>> In the example, first_pos(Message_Kind1'(Sign_On)) would be 0, for
>> Request it would be 1, for Reply it would be 3, and for
>> Message_Kind1'(Sign_Off) it would be 6.
>>
>> The value Detailed_Message_Kind'(Ack) would be represented by the parent
>> bits 2#10#, representing Reply, and the extension bits 2#01#, to show
>> that Ack is the second literal refining Reply. The position number is
>> computed as first_pos(Reply) + 1 = 3 + 1 = 4.
>>
>> Each derived type needs its own "first_pos" array, of course.

Just to avoid focusing too much on an unimportant part of the proposal 
for "deepened" enumeration types, I want to repeat here that my 
suggestions for representing such types with "parent bits" and 
"extension bits" was meant as one possibility, that could perhaps 
explain how the types are meant to work, but it is not central to the 
proposal. "Deepened" enumeration types can use the normal represention 
with position number, for all I care.

> For myself check...
>
> type Message_Kind1 is (Sign_On, Request, Reply, Sign_Off);
>
> -- Sign_On = 0
> -- Request = 1
> -- Reply = 2
> -- Sign_Off = 3
>
> type Detailed_Message_Kind is new Message_Kind1 with (
>     Request =>   (Read, Write),
>     Reply   =>   (Data, Ack, Refused),
>     others  =>   <>);
>
> (when the offset is 4 bit)
> -- Sign_On  = 16#00#
> -- Read     = 16#10#
> -- Write    = 16#11#
> -- Data     = 16#20#
> -- Ack      = 16#21#
> -- Refused  = 16#22#
> -- Sign_Off = 16#30#

Yes, that is what I had in mind if we allocate 4 "parent bits" (more 
significant nybble) and 4 "extension bits" (less significant nybble).

> X'Pos = first_pos (X'Enum_Rep / 16) + (X'Enum_Rep mod 16)

Right.

>
> type More_Detailed_Message_Kind is new Detailed_Message_Kind with (
>     Write =>  (Overwrite, Append),
>     others =>  <>);
>
> -- Sign_On   = 16#000#
> -- Read      = 16#100#
> -- Overwrite = 16#110#
> -- Append    = 16#111#
> -- Data      = 16#200#
> -- Ack       = 16#210#
> -- Refused   = 16#220#
> -- Sign_Off  = 16#300#
>
> Y'Pos =
>     More_Detailed_Message_Kind'first_pos (
>        Detailed_Message_Kind'first_pos (Y'Enum_Rep / 256)
>        + (Y'Enum_Rep mod 256 / 16))
>     + (Y'Enum_Rep mod 16)

That looks right (but it's past midnight and my eyes are crossing a 
bit). You can define the 'Pos function recursively by walking up the 
derivation path.

> I feel that you do not need to change the existing representation rule.
> Because even if Message_Kind1 has the representation clause, it's unrelated to Detailed_Message_Kind.
> It's able to keep the existing rule of root enum-types.
> And the representation of Detailed_Message_Kind is new thing, such as your saying.

I agree. But as I said, the default representation is a secondary issue, 
and I don't think that we need to define a default representation.

> (I'm only interested, not a language lawyer. I'm sorry that I couldn't help you in this discussion.)

Thanks. It's an interesting discussion. It has tempted me to champion 
this proposal more strongly than I originally intended.

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

Re: What would you like in Ada202X?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:4uz9hfn9qr77.1pc1cni103lro.dlg@40tude.net...
> On Tue, 15 May 2012 01:30:03 -0500, Randy Brukardt wrote:
...
>> I'm not sure that it is good idea in general, but certainly it makes 
>> sense
>> in limited cases (surely including your enumeration example).
>
> 1- all string and character types;
> 2. all numeric types;
> 3. managed access types, fat pointers, garbage collection.

Right. I would have said "all scalar types" in order to include enumerations 
as well as numeric types. But that's roughly what I was thinking about. In 
any case, just a wild idea right now.

                                 Randy.

Re: What would you like in Ada202X?

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:a1g0h2Fm2bU1@mid.individual.net...

(I did read your whole message, but since I have to leave here ASAP, I'm 
just going to answer a quick summary.)

...
> The widening derivation only adds. The deepening derivation changes, by 
> refining.

I have never wanted to "refine" an enumeration. Perhaps its not even 
something I would think of (because it's not possible, so why even consider 
it), so I can't be certain that's because its rare, but off-hand, I can't 
think of any possible use of such a construct.

Well, one, where you have a specific literal in your original type for 
"future expansion", and you then hang new literals on it. That is, using 
"deepening" to emulate "widening".

So that's the main problem I have with your concept: it doesn't solve any 
real problems that I have. OTOH, the need to add a new (operation, border 
style, font choice, etc.) happens all of the time. I'm definitely not 
certain that there is anything that can be gained from having a language 
feature to do this.

I understand your desire to keep apples and oranges separate, but typically 
these don't share operations either (most of the operations on these fruits 
are completely different - think removing seeds). That's why the value of 
untagged derived types is low (and that carries over to tagged types for 
many kinds of operations - few things map as well to OOP as GUIs).

I could easily see a version of Dmitry's user-defined conversions to allow 
two otherwise separate types to share operations (but not representations), 
but a more specific feature just doesn't have enough bang-for-the-buck (the 
"buck" here being the effort to define and implement this in language 
terms).

                                            Randy.

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Wed, 16 May 2012 00:35:30 +0300, Niklas Holsti wrote:

> I think that there are two quite different "use cases", from the user's 
> point of view, which correspond to "widening" and "deepening" 
> respectively. And I think that the "deepening" case is more worthy of 
> language support than the "widening" case.

There is narrowing too, presently handled though subtypes. You have type:

1. specialization (e.g. narrowing)
2. generalization (e.g. widening)
3. alternation (e.g. deepening)

Then you have two general models to bring types under one roof to have
objects of the class [*]:

1. subtypes + T'Base
2. separate types + T'Class

The rest is just details.

--------
* generic model lacks this property

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

Re: What would you like in Ada202X?

[Niklas Holsti]

On 12-05-09 11:02 , Dmitry A. Kazakov wrote:
> On Tue, 08 May 2012 22:20:21 +0300, Niklas Holsti wrote:
>>
>> Perhaps the derived "deepened" type could inherit operations with "out"
>> and "in out" parameters of the parent type if these parameters were kept
>> as parent type, and not mapped to the derived type
>
> No, they must be inherited exactly same way

"Must" by which authority?

> parameter of derived type when inherited, that is covariance. When an in
> operation is inherited it too has the parameter of the derived type, which
> is then converted and passed to the inherited body. For out-operations you
> call the inherited body and then convert the result. For in-outs, you
> convert-in, call, convert-out.
>
> You might mean that composition with conversion could be inappropriate
> here.

For result values ("out", "in out", "return") conversion is 
inappropriate because there is no natural conversion in that direction.

>>> This would exclude all functions returning values of the type. In
>>> particular T'Val, T'Succ, T'Pred. Are you going to define some of them new?
>>
>> Of course the derived "deepened" type must have these operations, since
>> it is an enumeration type,
>
> (See how quickly multiple inheritance slips in? (:-))

Only in your wide view of what "multiple inheritance" means :-]

> This is why it makes no sense to implement it for specifically enumeration
> types. The disadvantages it may have (rather imaginary ones, IMO) will all
> be yours. So why not to face it, and just do it for all types. Sorry for
> advocating this for years, but there is no other way.

I wish you would write up your proposal in a self-contained form. Yes, 
you have been advocating this, but in scattered postings, and so 
sketchily that it has not IMO been possible to understand and discuss it.

> You will have to solve MD problematic as well. E.g.
>
>     type T1 is (...);
>     type T2 is (...);
>     procedure D (X : T1; Y : T2);

- Declaration 1: D (T1, T2).
>
>     type S1 is new T1 with ...;

Inheritance from declaration 1 gives:

- Declaration 2: D (S1, T2).

>     type S2 is new T2 with ...;

Inheritance from declaration 1 gives:

- Declaration 3: D (T1, S2).

Inheritance from declaration 2 gives:

- Declaration 4: D (S1, S2).

>     X1 : T1;
>     X2 : S1;
>     Y1 : T2;
>     Y2 : S2;
> begin
>      D (X2, Y1); -- Illegal?

This is D (S1, T2), legal by declaration 2.

>      D (X1, Y2); -- Legal but Constraint_Error (Ada 95 hack)

This is D (T1, S2), legal by declaration 3.

Sorry, which "Ada 95 hack" do you mean?

> Semantically, there always will be some issue with conversions, because any
> non-trivial modification of a type, must break something. If it did not,
> you would use the old type instead.

Yes. Tagged types get around that by using view conversions. But that is 
only possible because a value of a derived tagged type in effect 
contains a value of the parent type, which is independent of the other 
components that were added in the derivation. The parent-type value can 
therefore be changed (by "out" or "in out") without considering the 
added components.

This is not possible for the "deepened" enumeration types.

> It is not the language business, it is
> up to the programmer to resolve. The language should simply refuse to
> automate suspicious cases forcing the programmer to intervene.

In that case, it seems the language would have to be extended further, 
to let programmers write conversion functions that can convert not only 
values, but also "views" of some kind.

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

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Thu, 17 May 2012 17:40:24 +0300, Niklas Holsti wrote:

> On 12-05-09 11:02 , Dmitry A. Kazakov wrote:
>> On Tue, 08 May 2012 22:20:21 +0300, Niklas Holsti wrote:
>>>
>>> Perhaps the derived "deepened" type could inherit operations with "out"
>>> and "in out" parameters of the parent type if these parameters were kept
>>> as parent type, and not mapped to the derived type
>>
>> No, they must be inherited exactly same way
> 
> "Must" by which authority?

(Logic, common sense?)

IF you inherit them, THEN the mechanism must be same.

>> parameter of derived type when inherited, that is covariance. When an in
>> operation is inherited it too has the parameter of the derived type, which
>> is then converted and passed to the inherited body. For out-operations you
>> call the inherited body and then convert the result. For in-outs, you
>> convert-in, call, convert-out.
>>
>> You might mean that composition with conversion could be inappropriate
>> here.
> 
> For result values ("out", "in out", "return") conversion is 
> inappropriate because there is no natural conversion in that direction.

If these operations are inherited, then semantically there is such a
conversion. The compiler is not allowed to reason about program semantics.

>>>> This would exclude all functions returning values of the type. In
>>>> particular T'Val, T'Succ, T'Pred. Are you going to define some of them new?
>>>
>>> Of course the derived "deepened" type must have these operations, since
>>> it is an enumeration type,
>>
>> (See how quickly multiple inheritance slips in? (:-))
> 
> Only in your wide view of what "multiple inheritance" means :-]

And what does it mean in the narrow view of MI-haters? (:-))

>> This is why it makes no sense to implement it for specifically enumeration
>> types. The disadvantages it may have (rather imaginary ones, IMO) will all
>> be yours. So why not to face it, and just do it for all types. Sorry for
>> advocating this for years, but there is no other way.
> 
> I wish you would write up your proposal in a self-contained form. Yes, 
> you have been advocating this, but in scattered postings, and so 
> sketchily that it has not IMO been possible to understand and discuss it.

In case, you didn't notice that, there is no interest in such proposals.

I hope that our discussion will convince at least you, that it is worth to
consider ways Ada's type system could be significantly generalized and
simplified while keeping it fully backward compatible.

>> You will have to solve MD problematic as well. E.g.
>>
>>     type T1 is (...);
>>     type T2 is (...);
>>     procedure D (X : T1; Y : T2);
> 
> - Declaration 1: D (T1, T2).
>>
>>     type S1 is new T1 with ...;
> 
> Inheritance from declaration 1 gives:
> 
> - Declaration 2: D (S1, T2).
> 
>>     type S2 is new T2 with ...;
> 
> Inheritance from declaration 1 gives:
> 
> - Declaration 3: D (T1, S2).
> 
> Inheritance from declaration 2 gives:
> 
> - Declaration 4: D (S1, S2).

That is full MD!

Putting our "diamond mine" at work: put S1 in one package, S2 in another.
Neither knows other. Where D(S1,S2) gets inherited? Unlike to MI, diamond
issues for MD are real.

> Sorry, which "Ada 95 hack" do you mean?

Ada 95 inherits some MD operations as "raise Constraint_Error" without
giving an ability to override (only for multi-methods).

>> Semantically, there always will be some issue with conversions, because any
>> non-trivial modification of a type, must break something. If it did not,
>> you would use the old type instead.
> 
> Yes. Tagged types get around that by using view conversions.

You mean here rather type extensions, not in the sense of enumeration
extension but as a Cartesian product of the values of the parent type and
the extension part. They could be by reference and by value. E.g. you could
extend Float to Complex by "multiplying" Float x Float.

> But that is 
> only possible because a value of a derived tagged type in effect 
> contains a value of the parent type, which is independent of the other 
> components that were added in the derivation. The parent-type value can 
> therefore be changed (by "out" or "in out") without considering the 
> added components.

Strongly disagree.

The internal representation is irrelevant. An ability to generate some type
conversion as a view conversion does not mean that the result of such
conversion is semantically correct (substitutable).

The semantics is defined by the programmer in terms of type operations. It
is up to him to decide whether the operation can be inherited per
composition with [view] conversion or not.

> This is not possible for the "deepened" enumeration types.

Yes, but irrelevant.

I would even claim that in the language like Ada the compiler should
inherit everything abstract. The programmer should always override
explicitly saying if the body is composed per view conversion (or any other
built-in conversion) or overridden (or extended by adding
prologues/epilogues etc). The only reason not to do this is lack of good
syntax sugar to avoid tedious repetitions.

>> It is not the language business, it is
>> up to the programmer to resolve. The language should simply refuse to
>> automate suspicious cases forcing the programmer to intervene.
> 
> In that case, it seems the language would have to be extended further, 
> to let programmers write conversion functions that can convert not only 
> values, but also "views" of some kind.

Yes. It would be useful, e.g. dereferencing fat pointers. Or you could make
something task-safe by seizing mutex while passing converted argument and
releasing it when returning back. Then, of course, for all sorts of
in-place operations of containers: you could derive an ad-hoc container
element type and hang conversions passing the container in the closure
which would modify the element in place.

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

Re: What would you like in Ada202X?

[Niklas Holsti]

On 12-05-15 09:30 , Randy Brukardt wrote:
> "Niklas Holsti"<niklas.holsti@tidorum.invalid>  wrote in message
> news:a1ahq2F7e2U1@mid.individual.net...
>> On 12-05-10 03:47 , Randy Brukardt wrote:
>>> "Dmitry A. Kazakov"<mailbox@dmitry-kazakov.de>   wrote in message
>>> news:kl5nkc2s9tsx.61oqe3a9ogra.dlg@40tude.net...
>>>> On Tue, 08 May 2012 22:20:21 +0300, Niklas Holsti wrote:
>>>>> I would like to make the "deepening" derivation as similar as possible
>>>>> to the derivation of enumeration types in
>>>>
>>>> With the problems solved you will get enumeration extension for granted.
>>>> Your proposal rounds about how to generate conversion functions. You can
>>>> generate in-conversion, but cannot out-conversions. The case of plain
>>>> extension has the opposite problem: in-conversions are impossible. But
>>>> the
>>>> mechanics of all this is same: interface inheritance, delegation of some
>>>> inherited operations to the parent's body composed with a conversion.
>>>>
>>>> Semantically, there always will be some issue with conversions, because
>>>> any
>>>> non-trivial modification of a type, must break something. If it did not,
>>>> you would use the old type instead. It is not the language business, it
>>>> is
>>>> up to the programmer to resolve. The language should simply refuse to
>>>> automate suspicious cases forcing the programmer to intervene.
>>>
>>> Here I agree with Dmitry (but note that the mechanism he is talking about
>>> here has nothing to do with multiple inheritance; it works just fine with
>>> Ada 95 type derivation or something similar to that).
>>
>> I agree with Dmitry's and your rejection of automated but suspect
>> conversions, which is why I suggested not to inherit parent operations
>> that would need conversion from the parent enumeration type to the
>> "deepened" enumeration type. I could also accept the alternative to
>> inherit abstract versions of such parent operations, which would be more
>> useful for class-wide programming.
>>
>> But I don't see how a single programmer-defined conversion function from
>> the parent type to the deepened type could work in general, that is, how
>> the same conversion would be appropriate for all "out", "in out", and
>> function-return positions in all parent operations. And if different
>> conversion functions are needed for different operations/parameters, we
>> may as well choose "inherit as abstract" and require the programmer to
>> implement these operations for the derived type.
>
> "Conversion" is almost never a single function; indeed, Ada requires it to
> work both ways in most cases. In particular, if you have "out" parameters,
> you need a conversion from the parent to the child type, just like you need
> a conversion from the child to the parent to implement "in" parameters.

That is how it works in Ada now, yes. Well, except for the view 
conversions of tagged types et c., I would say.

>> For example, the function Ada.Directories.Current_Directory now returns
>> String; how would that, and other I/O functions that return String, be
>> handled? Would they return Root_String'Class?
>
> Yes, of course, there would be a version of everything that takes a String
> that would take a Root_String'Class.

Ok, that is consistent. The implementation of Ada.Directories on the 
current system decides which concrete kind of string is proper for this 
system, and returns such an object, but seen as Root_String'Class by the 
caller.

> (I don't think there are many routines
> that take "out" String parameters, because you can't change the size that
> way.)

But in general, how would "out" parameters of type Root_String'Class (or 
SomeType'Class) work? Of course the subprogram can call operations like 
Set_Char on the parameter to alter its value, but what about a 
whole-object assignment, Parameter := Value? I guess that must raise 
Constraint_Error if the new Value does not match the actual Parameter in 
type or discriminants.

> The problem is that the language doesn't provide the syntax to connect the
> "hand-built" conversions with the existing machinery of (sub)type
> conversion; I'm assuming that would be done if the conversion solution was
> intended to be used as a first-class technique.

Yes, I think I see what you mean.

> Specifically, when you "derive" a new type from an existing type, the idea
> is that you could give the derived type any declaration and representation
> you want (it wouldn't have to be related to the parent, with some limits),
> and you could then define conversion functions (always two) similarly to the
> way that streaming subprograms are defined. Inherited routines would use
> those conversions when conversions are needed (as already defined by the
> language). That would allow one to have very unrelated types be "related"
> via derivation.
>
> I'm not sure that it is good idea in general, but certainly it makes sense
> in limited cases

Same sentiments here (I assume by "limited cases" you don't mean 
"limited types" in the Ada sense). The main limitation, I think, is that 
the derived type cannot be much more "meaningful" -- that is, carry more 
information -- than the parent type; if it is, the conversion from 
parent to derived would have to supply the additional information, from 
nothing.

> (surely including your enumeration example).

I don't think so, because the "deepened" enumeration type has more 
information than the parent type. In the example I gave, the 
derived-type literals Read and Write convert to the parent-type literal 
Request, but the conversion back from Request to the derived type would 
have to choose either Read or Write, and it has no information to guide 
that choice.

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

Re: What would you like in Ada202X?

[Niklas Holsti]

On 12-05-16 03:19 , Randy Brukardt wrote:
> "Niklas Holsti"<niklas.holsti@tidorum.invalid>  wrote in message
> news:a1g0h2Fm2bU1@mid.individual.net...
>
> (I did read your whole message, but since I have to leave here ASAP, I'm
> just going to answer a quick summary.)
>
> ...
>> The widening derivation only adds. The deepening derivation changes, by
>> refining.
>
> I have never wanted to "refine" an enumeration.

I do it often, but in current Ada I have to do it "in reverse", by 
defining the most detailed enumeration first, and then coarsening it 
into larger-grained concepts by defining subtypes. For example, I write:

    type Detailed_Message_Kind is (
       Sign_On, Read, Write, Data, Ack, Refused, Sign_Off);

and then coarsen it to subtypes:

    subtype Request is Detailed_Message_Kind range Read .. Write;
    subtype Reply   is Detailed_Message_Kind range Data .. Refused;

This works, but it is a bit error-prone when I need to add some literals 
and make sure that they go in the right subtype, and of course the 
collection of "coarsening" subtypes does not itself form an enumeration, 
so I cannot, for example, loop over all the "coarser" concepts.

> Perhaps its not even
> something I would think of (because it's not possible, so why even consider
> it), so I can't be certain that's because its rare, but off-hand, I can't
> think of any possible use of such a construct.
>
> Well, one, where you have a specific literal in your original type for
> "future expansion", and you then hang new literals on it. That is, using
> "deepening" to emulate "widening".
>
> So that's the main problem I have with your concept: it doesn't solve any
> real problems that I have. OTOH, the need to add a new (operation, border
> style, font choice, etc.) happens all of the time.

But surely, in most such cases, the right solution is to open an editor 
and add the new literals to the original type declaration, isn't it?

The constant assumption in this discussion -- although perhaps not 
explicitly stated -- is that we are talking about situations where we 
want to keep the parent type around in its original form, and instead 
derive a new type, with a specific relationship to the parent type. A 
valid reason for this could be, for example, that some operations can be 
written in general form on the parent type, and then inherited by 
several derived types, or that the same genericity can be got from 
classwide programming on Parent'Class.

> I'm definitely not
> certain that there is anything that can be gained from having a language
> feature to do this.

Nor am I certain, but I felt that the "deepening" idea was at least 
significantly better than the "widening" method in AI95-261, so I 
presented it for discussion. Thank you for taking part.

> I understand your desire to keep apples and oranges separate, but typically
> these don't share operations either (most of the operations on these fruits
> are completely different - think removing seeds).

But such operations can be overridden, or even defined separately as 
overloading, for the two types.

> That's why the value of
> untagged derived types is low (and that carries over to tagged types for
> many kinds of operations - few things map as well to OOP as GUIs).

It may be beside the point, but I have found OOP in the form of tagged 
type hierarchies (rooted in abstract types) to be a very good method for 
decoupling subsystems in my programming (and no GUI around).

> I could easily see a version of Dmitry's user-defined conversions to allow
> two otherwise separate types to share operations (but not representations),
> but a more specific feature just doesn't have enough bang-for-the-buck (the
> "buck" here being the effort to define and implement this in language
> terms).

Fair enough, thanks.

I don't think Dmitry's proposal would cover "deepened" enumeration 
types, because there is no natural conversion from the parent type to 
the "deepened" type.

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

Re: What would you like in Ada202X?

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:a1l30fFuqaU1@mid.individual.net...
> On 12-05-15 09:30 , Randy Brukardt wrote:
...
>> (I don't think there are many routines
>> that take "out" String parameters, because you can't change the size that
>> way.)
>
> But in general, how would "out" parameters of type Root_String'Class (or 
> SomeType'Class) work? Of course the subprogram can call operations like 
> Set_Char on the parameter to alter its value, but what about a 
> whole-object assignment, Parameter := Value? I guess that must raise 
> Constraint_Error if the new Value does not match the actual Parameter in 
> type or discriminants.

Right, but keep in mind that's how it works for composite types in Ada now. 
(The bounds and discriminants are passed in with the parameter, and usually 
you can't change them.) So we're not losing anything here, especially as the 
current types are arrays, for which you can never change the bounds.

...
> Same sentiments here (I assume by "limited cases" you don't mean "limited 
> types" in the Ada sense). The main limitation, I think, is that the 
> derived type cannot be much more "meaningful" -- that is, carry more 
> information -- than the parent type; if it is, the conversion from parent 
> to derived would have to supply the additional information, from nothing.
>
>> (surely including your enumeration example).
>
> I don't think so, because the "deepened" enumeration type has more 
> information than the parent type. In the example I gave, the derived-type 
> literals Read and Write convert to the parent-type literal Request, but 
> the conversion back from Request to the derived type would have to choose 
> either Read or Write, and it has no information to guide that choice.

Well, the technique still works, and about the same as your proposal: the 
reverse conversion just would raise an exception in the case where it cannot 
figure out what to do. That might be always in some situations, but it might 
also only have to do so in limited circumstances, so there would be more 
flexibility than your specific proposal would give.

The only loss would be a compile-time vs. a run-time check. But that could 
be handled with a way to specify that there is no reverse conversion:

           with Parent_Conversion => My_Function, Reverse_Parent_Conversion 
=> <>, ...

in which case any uses of that conversion would have to be rejected at 
compile-time. (There might be a generic contract problem with this 
particular idea, though.)

                                      Randy.

Re: What would you like in Ada202X?

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:a1laqhFlkpU1@mid.individual.net...
> On 12-05-16 03:19 , Randy Brukardt wrote:
>> "Niklas Holsti"<niklas.holsti@tidorum.invalid>  wrote in message
>> news:a1g0h2Fm2bU1@mid.individual.net...
>>
>> (I did read your whole message, but since I have to leave here ASAP, I'm
>> just going to answer a quick summary.)
>>
>> ...
>>> The widening derivation only adds. The deepening derivation changes, by
>>> refining.
>>
>> I have never wanted to "refine" an enumeration.
>
> I do it often, but in current Ada I have to do it "in reverse", by 
> defining the most detailed enumeration first, and then coarsening it into 
> larger-grained concepts by defining subtypes. For example, I write:
>
>    type Detailed_Message_Kind is (
>       Sign_On, Read, Write, Data, Ack, Refused, Sign_Off);
>
> and then coarsen it to subtypes:
>
>    subtype Request is Detailed_Message_Kind range Read .. Write;
>    subtype Reply   is Detailed_Message_Kind range Data .. Refused;
>
> This works, but it is a bit error-prone when I need to add some literals 
> and make sure that they go in the right subtype, and of course the 
> collection of "coarsening" subtypes does not itself form an enumeration, 
> so I cannot, for example, loop over all the "coarser" concepts.

Ada 2012 helps here a bit because it doesn't require the subtypes to have 
contiguous literals. (That's a major pain in previous Ada.) A static subtype 
predicate can be used to specify a set of literals, and you can still use 
the subtype name in case statements and loops.

But of course you can't loop over a bunch of subtypes, only one at a time.

...
>> So that's the main problem I have with your concept: it doesn't solve any
>> real problems that I have. OTOH, the need to add a new (operation, border
>> style, font choice, etc.) happens all of the time.
>
> But surely, in most such cases, the right solution is to open an editor 
> and add the new literals to the original type declaration, isn't it?

Perhaps; not so much if this is reusable code and the need is specialized. 
In any case, changing the type declaration causes errors in lots of code 
that might be completely unrelated, and it would be good to have a better 
way to create a new type. (But I think the conversion between semi-unrelated 
types is a better approach, as it can be used in many ways, not just one.)

> The constant assumption in this discussion -- although perhaps not 
> explicitly stated -- is that we are talking about situations where we want 
> to keep the parent type around in its original form, and instead derive a 
> new type, with a specific relationship to the parent type. A valid reason 
> for this could be, for example, that some operations can be written in 
> general form on the parent type, and then inherited by several derived 
> types, or that the same genericity can be got from classwide programming 
> on Parent'Class.

Right.

...
>> I could easily see a version of Dmitry's user-defined conversions to 
>> allow
>> two otherwise separate types to share operations (but not 
>> representations),
>> but a more specific feature just doesn't have enough bang-for-the-buck 
>> (the
>> "buck" here being the effort to define and implement this in language
>> terms).
>
> Fair enough, thanks.
>
> I don't think Dmitry's proposal would cover "deepened" enumeration types, 
> because there is no natural conversion from the parent type to the 
> "deepened" type.

You're not imaginative enough. ;-) See my previous message.

                            Randy.

Re: What would you like in Ada202X?

[Marius Amado-Alves]

Great, great thread. (So "great" I didn't have time to go through all of it yet... so sorry if this was already proposed.)

A predefined attribute 'Length for enumeration types, probably defined as equivalent to

   T'Length = T'Pos (T'Last) - T'Pos (T'First) + 1

(That's the formula I use anyway, FOR EACH AND EVERY ENUMERATION...)

(FWIW I agree with all other proposed enrichements of enumerations.)

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

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

> 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:
> […]

I don't remember this one already in this thread: ability to narrow the  
index type of a derived array type (so far, if you redefine the range, you  
freeze it).

There may be way to workarounds it in some cases: 1) full redefinition of  
a new array type instead of deriving one from an existing one or (may not  
be OK for all cases, and prevent creation of a real type hierarchy, can  
also break readability) 2) give the type an Ada 2012 static invariant.  
Even with this workarounds in mind, that would be more handy and intuitive  
to be able to properly narrow the index type.

-- 
“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

Re: What would you like in Ada202X?

[Yannick Duchêne (Hibou57)]

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

> 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:

Another one again: support for unsigned integer, or else, range type with  
same range for base type and initial subtype.

-- 
“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

Re: What would you like in Ada202X?

[joachim.schroeer]

Am Mittwoch, 25. April 2012 09:47:06 UTC+2 schrieb 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

1. Want to see parameter modes in calls.

procedure Proc (An_In_Parameter     : in     Integer;
                An_Out_Parameter    :    out Integer;
                An_Inout_Parameter  : in out Integer;
                An_Access_Parameter : access Integer);

Proc (An_In_Parameter     <=  A,
      An_Out_Parameter     => B,
      An_Inout_Parameter  <=> C,
      An_Access_Parameter  -> D'Access);

A becomes An_In_Parameter, An_Out_Parameter becomes B, etc.

2. Expressions with Discriminants.

type Symmetric_Matrix (Dim : Natural) is record
  Values : Float_Array (1 .. Dim * (Dim + 1) / 2;
end record;

Best regards 
Achim

Re: What would you like in Ada202X?

[AdaMagica]

On Friday, June 29, 2012 1:29:03 PM UTC+2, (unknown) wrote:
> 1. Want to see parameter modes in calls.
>
> procedure Proc (An_In_Parameter     : in     Integer;
>                 An_Out_Parameter    :    out Integer;
>                 An_Inout_Parameter  : in out Integer;
>                 An_Access_Parameter : access Integer);
>
> Proc (An_In_Parameter     <=  A,
>       An_Out_Parameter     => B,
>       An_Inout_Parameter  <=> C,
>       An_Access_Parameter  -> D'Access);
>
> A becomes An_In_Parameter, An_Out_Parameter becomes B, etc.

I've often wished that be possible. However "<=" is already defined as a relational operator "less or equal". so <== or something like that would be needed. ("Greater or equal" is ">=", so there is no problem, but for consistency ==> would then perhaps be better.)

> 2. Expressions with Discriminants.
>
> type Symmetric_Matrix (Dim : Natural) is record
>   Values : Float_Array (1 .. Dim * (Dim + 1) / 2;
> end record;

Also this would be nice. However then the upper bound would have to be stored as a hidden record component as well, I guess, and this would conflict with respresentation clauses (how to handle hidden components).

> Best regards 
> Achim

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Fri, 29 Jun 2012 04:29:03 -0700 (PDT), joachim.schroeer@cassidian.com 
wrote:

> 1. Want to see parameter modes in calls.
> 
> procedure Proc (An_In_Parameter     : in     Integer;
>                 An_Out_Parameter    :    out Integer;
>                 An_Inout_Parameter  : in out Integer;
>                 An_Access_Parameter : access Integer);
> 
> Proc (An_In_Parameter     <=  A,
>       An_Out_Parameter     => B,
>       An_Inout_Parameter  <=> C,
>       An_Access_Parameter  -> D'Access);
>

Proc 
(  An_In_Parameter := A,
    B := An_Out_Parameter,
    C := An_Inout_Parameter := C,  -- Note great opening opportunities!
    D := An_Access_Parameter.all
);

OK, I am joking. (:-))

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

Re: What would you like in Ada202X?

[stefan-lucks]

On Fri, 29 Jun 2012, AdaMagica wrote:

> > procedure Proc (An_In_Parameter     : in     Integer;
> >                 An_Out_Parameter    :    out Integer;
> >                 An_Inout_Parameter  : in out Integer;
> >                 An_Access_Parameter : access Integer);
> >
> > Proc (An_In_Parameter     <=  A,
> >       An_Out_Parameter     => B,
> >       An_Inout_Parameter  <=> C,
> >       An_Access_Parameter  -> D'Access);
> >
> > A becomes An_In_Parameter, An_Out_Parameter becomes B, etc.
> 
> I've often wished that be possible. However "<=" is already defined as a 
> relational operator "less or equal". so <== or something like that would 
> be needed. ("Greater or equal" is ">=", so there is no problem, but for 
> consistency ==> would then perhaps be better.)

So what about the following?

Proc (An_In_Parameter      => in     A,
      An_Out_Parameter     =>    out B,
      An_Inout_Parameter   => in out C,
      An_Access_Parameter  => access D'Access);

> > type Symmetric_Matrix (Dim : Natural) is record
> >   Values : Float_Array (1 .. Dim * (Dim + 1) / 2;
> > end record;
> 
> Also this would be nice. However then the upper bound would have to be 
> stored as a hidden record component as well, I guess, and this would 
> conflict with respresentation clauses (how to handle hidden components).

It took me a moment to understand the issue, since the component Values 
has to store (or somehow "know") its own upper bound Values'Last, anyway. 

But then, the Symmetric Matrix would additionally have to store its own 
size somewhere, right?

On the other hand, if there is a rep clause that the compiler cannot 
satisfy, than it can just reject the program. It would be better to 
prohibit rep clauses for that type, rather than prohibiting the type 
altogether.

-- 
---- 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!  ------

Re: What would you like in Ada202X?

[Adam Beneschan]

On Friday, June 29, 2012 4:54:55 AM UTC-7, AdaMagica wrote:
> On Friday, June 29, 2012 1:29:03 PM UTC+2, (unknown) wrote:
> > 1. Want to see parameter modes in calls.
> >
> > procedure Proc (An_In_Parameter     : in     Integer;
> >                 An_Out_Parameter    :    out Integer;
> >                 An_Inout_Parameter  : in out Integer;
> >                 An_Access_Parameter : access Integer);
> >
> > Proc (An_In_Parameter     <=  A,
> >       An_Out_Parameter     => B,
> >       An_Inout_Parameter  <=> C,
> >       An_Access_Parameter  -> D'Access);
> >
> > A becomes An_In_Parameter, An_Out_Parameter becomes B, etc.
> 
> I've often wished that be possible. However "<=" is already defined as a relational operator "less or equal". so <== or something like that would be needed. ("Greater or equal" is ">=", so there is no problem, but for consistency ==> would then perhaps be better.)
> 
> > 2. Expressions with Discriminants.
> >
> > type Symmetric_Matrix (Dim : Natural) is record
> >   Values : Float_Array (1 .. Dim * (Dim + 1) / 2;
> > end record;
> 
> Also this would be nice. However then the upper bound would have to be stored as a hidden record component as well, I guess, and this would conflict with respresentation clauses (how to handle hidden components).

The solution is simple: don't allow record representation clauses in cases like that.  I can't imagine anyone wanting to define a record of this nature anyway in a situation where the representation has to be specified exactly because the record is used by code in some other language, or something like that.

(I think implementors are already allowed to reject representation clauses they can't handle, and they're allowed to come up with fake names for hidden components in record rep clauses.  The real reason expressions involving discriminants aren't allowed was, I think, because back when Ada 83 was designed they were thought to add too much complexity for implementors.  Or something like that... I'm not entirely sure.)

                             -- Adam

Re: What would you like in Ada202X?

[Robert A Duff]

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

> On Fri, 29 Jun 2012 04:29:03 -0700 (PDT), joachim.schroeer@cassidian.com 
> wrote:
>
>> 1. Want to see parameter modes in calls.
>> 
>> procedure Proc (An_In_Parameter     : in     Integer;
>>                 An_Out_Parameter    :    out Integer;
>>                 An_Inout_Parameter  : in out Integer;
>>                 An_Access_Parameter : access Integer);
>> 
>> Proc (An_In_Parameter     <=  A,
>>       An_Out_Parameter     => B,
>>       An_Inout_Parameter  <=> C,
>>       An_Access_Parameter  -> D'Access);
>>
>
> Proc 
> (  An_In_Parameter := A,
>     B := An_Out_Parameter,
>     C := An_Inout_Parameter := C,  -- Note great opening opportunities!
>     D := An_Access_Parameter.all
> );
>
> OK, I am joking. (:-))

Something like that was allowed in the original Ada, circa 1980:

Proc (An_In_Parameter     :=  A,
      An_Out_Parameter     =: B,
      An_Inout_Parameter  :=: C,
      An_Access_Parameter :=  D'Access);

I think it only worked for named notation.
It should work for positional notation, too, IMHO.

- Bob

Re: What would you like in Ada202X?

[Brian Drummond]

On Wed, 25 Apr 2012 00:47:06 -0700, 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 2) parallel loops / functions 3)
> Multiple dispatch
> 
> -- Martin

We can overload existing operators (+,-,etc)
But we can't define new ones, e.g. // to denote the value of electronic 
components connected in a parallel circuit) or -- (bad choice! maybe ++) 
for series connection. 

For example, the definition of // would clearly be different for 
resistance and capacitance, which we can assume to be distinct types of 
complex number.

The last language I used that allowed this, (Lingo, on the Linn Rekursiv) 
restricted the characters used to build such an operator to a suitable 
set, chosen to avoid clashes with the inherent language syntax, so no 
{ or } for example. 

One obvious problem with an extensible set of operators, in an operator 
precedence grammar, is assigning the precedence level of new operators.
Lingo resolved that dilemma by assigning the same precedence to all 
operators! You explicitly wrote a + (b*c) - d to achieve the usual 
precedence. Simple, clean, and effective, but entirely inappropriate for 
Ada!

Given that ways can be found to assign precedence to new operators, why 
are extensible operators not found in more languages that allow 
overloading? It would seem to be a useful way to add expressibility, and 
I can't see any fundamental drawbacks. 

If the demand is not there, is that because it has been considered and 
rejected, or is it simply below everyone's radar?

- Brian

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Sat, 30 Jun 2012 12:00:13 +0000 (UTC), Brian Drummond wrote:

> One obvious problem with an extensible set of operators, in an operator 
> precedence grammar, is assigning the precedence level of new operators.

Ada actually solved that by making associations of operators in question
illegal. E.g. a or b and c. "or" cannot share argument with "and".

> Given that ways can be found to assign precedence to new operators, why 
> are extensible operators not found in more languages that allow 
> overloading?

Depends on the syntax. Unicode characters, which are not letters are easy.
Operators conflicting with identifiers will impose a serious problem.

> It would seem to be a useful way to add expressibility, and 

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

A subset or all of them would suffice.

> I can't see any fundamental drawbacks. 

Code review and maintainability problems. The set of symbols cannot be
infinite.

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

Re: What would you like in Ada202X?

[Robert A Duff]

Brian Drummond <brian@shapes.demon.co.uk> writes:

> We can overload existing operators (+,-,etc)
> But we can't define new ones, e.g. // to denote the value of electronic 
> components connected in a parallel circuit) or -- (bad choice! maybe ++) 
> for series connection. 
>
> For example, the definition of // would clearly be different for 
> resistance and capacitance, which we can assume to be distinct types of 
> complex number.
>
> The last language I used that allowed this, (Lingo, on the Linn Rekursiv) 
> restricted the characters used to build such an operator to a suitable 
> set, chosen to avoid clashes with the inherent language syntax, so no 
> { or } for example. 
>
> One obvious problem with an extensible set of operators, in an operator 
> precedence grammar, is assigning the precedence level of new operators.

Yes, you would need some way to deal with precedence, but I think it is
a mistake to think of precedence in terms of "levels".  In Ada
"*" has higher precedence than "+", and "+" the same precedence
as "-".  But "and" and "or" have neither higher, lower, nor equal
precedence.  That last possibility is important to allow, and
in fact should be the default -- perhaps call it "unrelated
precedence".

> Lingo resolved that dilemma by assigning the same precedence to all 
> operators! You explicitly wrote a + (b*c) - d to achieve the usual 
> precedence. Simple, clean, and effective, but entirely inappropriate for 
> Ada!

And some other languages, such as Smalltalk.  Yes, it's simple.
But it's a bad idea, because it violates maths conventions.
I could tolerate a+b*c being illegal, but I can't tolerate it
being legal and meaning (a+b)*c.

> Given that ways can be found to assign precedence to new operators, why 
> are extensible operators not found in more languages that allow 
> overloading?

Perhaps because dealing with precedence adds complexity.
What happens if package P1 declares that "//" has higher
precedence than "\\\", and P2 declares the opposite,
and you say "with P1, P2;"?  The obvious answer is that
they then have unrelated precedence within the scope
of that "with".  But it definitely adds complexity.

Anyway, I don't think I want programs to look like maths textbooks.
Programming isn't the same as maths.  I kind of like reading words, as
in "Union(Intersection(This_Set, That_Set), The_Other);" rather than the
usual maths symbols.  On the other hand, I wish ASCII had proper symbols
for <= and >=.

- Bob

Re: What would you like in Ada202X?

[Brian Drummond]

On Sat, 30 Jun 2012 14:34:10 +0200, Dmitry A. Kazakov wrote:

> On Sat, 30 Jun 2012 12:00:13 +0000 (UTC), Brian Drummond wrote:
> 
>> One obvious problem with an extensible set of operators, in an operator
>> precedence grammar, is assigning the precedence level of new operators.
> 
> Ada actually solved that by making associations of operators in question
> illegal. E.g. a or b and c. "or" cannot share argument with "and".

So one (simple but restrictive) solution would be to extend this 
"unrelated precedence" to all new operators.

> Operators conflicting with identifiers will impose a serious problem.

I was not expecting such operators to be permitted. Alphanumeric 
characters would not be among the set of characters available for the 
purpose.

(a **** b) might be permitted, (a f*** b) would surely not!

> http://en.wikipedia.org/wiki/
Mathematical_operators_and_symbols_in_Unicode
> 
> A subset or all of them would suffice.
> 
>> I can't see any fundamental drawbacks.
> 
> Code review and maintainability problems. The set of symbols cannot be
> infinite.

Practical considerations surely restrict the length of additional 
operators, but I'm not sure that restriction belongs in the syntax.

- Brian

Re: What would you like in Ada202X?

[Brian Drummond]

On Sat, 30 Jun 2012 11:51:51 -0400, Robert A Duff wrote:

> Brian Drummond <brian@shapes.demon.co.uk> writes:
> 
>> We can overload existing operators (+,-,etc)
...
>> But we can't define new ones, e.g. // to denote the value of electronic
>> components connected in a parallel circuit)
>> One obvious problem with an extensible set of operators, in an operator
>> precedence grammar, is assigning the precedence level of new operators.

> ... But
> "and" and "or" have neither higher, lower, nor equal precedence.  That
> last possibility is important to allow, and in fact should be the
> default -- perhaps call it "unrelated precedence".

... and that may help here.

>> Lingo resolved that dilemma by assigning the same precedence to all
>> operators! 
> And some other languages, such as Smalltalk.  Yes, it's simple.
> But it's a bad idea, because it violates maths conventions.
> I could tolerate a+b*c being illegal, but I can't tolerate it being
> legal and meaning (a+b)*c.

While agreeing it's a bad idea, I think it's a fair compromise IF it's 
clearly understood from the beginning, that that is what the language 
does, in order to allow major simplification in other aspects; in Lingo's 
case (and I believe Smalltalk's), sidestepping the precedence problem. 

Other bad ideas abound in computing; some languages violate the 
conventions by making assignment an operator...

I am happy to see neither of these ideas in Ada!

>> Given that ways can be found to assign precedence to new operators, why
>> are extensible operators not found in more languages that allow
>> overloading?
> 
> Perhaps because dealing with precedence adds complexity.
> What happens if package P1 declares that "//" has higher precedence than
> "\\\", and P2 declares the opposite,
> and you say "with P1, P2;"?  The obvious answer is that they then have
> unrelated precedence within the scope of that "with".  But it definitely
> adds complexity.

Conflicting precedences are a problem I hadn't considered. There seems to 
be some parallel with the diamond problem in multiple inheritance. 
If P1."//" and P2."//" apply to different types, does it really matter 
that they have different precedences, unless the base type is the same?
Possibly yes, from the perspective that the expression parser now has to 
take the operand types as well as the operator symbol into consideration. 

"+" by contrast, has the same precedence for integer, real, string, and 
foobar types (whether or not that precedence is appropriate for the 
semantics of e.g. string processing, it's what you get).

Perhaps a simple rule - e.g. all user-defined operators have unrelated 
precedence to ALL other operators - could cut through the complexity. 
But, like the simple rules in Modula-2, that may prove inconveniently 
restrictive.

> Anyway, I don't think I want programs to look like maths textbooks.
> Programming isn't the same as maths.  I kind of like reading words, as
> in "Union(Intersection(This_Set, That_Set), The_Other);" rather than the
> usual maths symbols.  On the other hand, I wish ASCII had proper symbols
> for <= and >=.

Agree that it could be over-used. But in some domains it would be useful. 
After all, I doubt you would want to see too much 
"Add(A,Multiply(B,C))"...

- Brian.

Re: What would you like in Ada202X?

[Robert A Duff]

Brian Drummond <brian@shapes.demon.co.uk> writes:

> Conflicting precedences are a problem I hadn't considered. There seems to 
> be some parallel with the diamond problem in multiple inheritance. 
> If P1."//" and P2."//" apply to different types, does it really matter 
> that they have different precedences, unless the base type is the same?
> Possibly yes, from the perspective that the expression parser now has to 
> take the operand types as well as the operator symbol into consideration. 

I think entangling syntax and semantics in that way would not be
a good idea, both for the programmer, and the compiler writer.

- Bob

Re: What would you like in Ada202X?

[Niklas Holsti]

On 12-06-30 20:37 , Brian Drummond wrote:
> On Sat, 30 Jun 2012 11:51:51 -0400, Robert A Duff wrote:
>
>> Brian Drummond<brian@shapes.demon.co.uk>  writes:
>>
>>> We can overload existing operators (+,-,etc)
> ...
>>> But we can't define new ones, e.g. // to denote the value of electronic
>>> components connected in a parallel circuit)
>>> One obvious problem with an extensible set of operators, in an operator
>>> precedence grammar, is assigning the precedence level of new operators.
   ...
>>> Given that ways can be found to assign precedence to new operators, why
>>> are extensible operators not found in more languages that allow
>>> overloading?
>>
>> Perhaps because dealing with precedence adds complexity.
>> What happens if package P1 declares that "//" has higher precedence than
>> "\\\", and P2 declares the opposite,
>> and you say "with P1, P2;"?  The obvious answer is that they then have
>> unrelated precedence within the scope of that "with".  But it definitely
>> adds complexity.
>
> Conflicting precedences are a problem I hadn't considered. There seems to
> be some parallel with the diamond problem in multiple inheritance.
> If P1."//" and P2."//" apply to different types, does it really matter
> that they have different precedences, unless the base type is the same?
> Possibly yes, from the perspective that the expression parser now has to
> take the operand types as well as the operator symbol into consideration.

Overload resolution would be very messed up. The parsed structure of the 
expression would be different for different resolutions of overloaded 
names and operators. Ugh!

IMO the new operators should all be put at the same precedence level, 
either above or below all the predefined operators. Perhaps below (most 
loosely binding) is the better choice. So a + b // c * d would be parsed 
as (a+b) // (c*d). The parentheses around the operands could even be 
required.

New unary operators should also be allowed, of course.

> Agree that it could be over-used. But in some domains it would be useful.
> After all, I doubt you would want to see too much
> "Add(A,Multiply(B,C))"...

I agree that defining new operators could be useful. It could also be 
overused to make programs hard to read and understand, for a reader who 
does not already know what the new operators mean. But I don't think we 
should forbid new language features just because they can be misused. 
After all, the language cannot require that function names should make 
sense -- if they don't, nested function applications can be hard to 
understand, too.

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

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Sat, 30 Jun 2012 17:00:46 +0000 (UTC), Brian Drummond wrote:

> On Sat, 30 Jun 2012 14:34:10 +0200, Dmitry A. Kazakov wrote:

>> Code review and maintainability problems. The set of symbols cannot be
>> infinite.
> 
> Practical considerations surely restrict the length of additional 
> operators, but I'm not sure that restriction belongs in the syntax.

I didn't meant length. I think that the number of operators should be small
to be memorizable. All symbols should be predefined, e.g. from the Unicode
page.

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

Re: What would you like in Ada202X?

[Brian Drummond]

On Sat, 30 Jun 2012 20:43:17 +0200, Dmitry A. Kazakov wrote:

> On Sat, 30 Jun 2012 17:00:46 +0000 (UTC), Brian Drummond wrote:
> 
>> On Sat, 30 Jun 2012 14:34:10 +0200, Dmitry A. Kazakov wrote:
> 
>>> Code review and maintainability problems. The set of symbols cannot be
>>> infinite.
>> 
>> Practical considerations surely restrict the length of additional
>> operators, but I'm not sure that restriction belongs in the syntax.
> 
> I didn't meant length. I think that the number of operators should be
> small to be memorizable. All symbols should be predefined, e.g. from the
> Unicode page.

A symbol is not necessarily a single character;  "<="  already isn't. And 
restricting the sequence length necessarily restricts the number of 
possible identifiers, so I'm not clear what you are suggesting.
I do take the point that one shouldn't employ unnecessarily many, but is 
it the role of the syntax to enforce that?

- Brian

- Brian

Re: What would you like in Ada202X?

[Oliver Kellogg]

On Saturday, June 30, 2012 11:06:15 PM UTC+2, Brian Drummond wrote:
> 
> A symbol is not necessarily a single character;  "<="  already isn't. And 
> restricting the sequence length necessarily restricts the number of 
> possible identifiers, so I'm not clear what you are suggesting.

IMHO requiring explicit parentheses is a good thing:
The C language comes to mind, where it is legal to write
  a---b
Quick: is that "a-- - b" or "a - --b" ?

Oliver

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Sat, 30 Jun 2012 21:06:15 +0000 (UTC), Brian Drummond wrote:

> On Sat, 30 Jun 2012 20:43:17 +0200, Dmitry A. Kazakov wrote:
> 
>> On Sat, 30 Jun 2012 17:00:46 +0000 (UTC), Brian Drummond wrote:
>> 
>>> On Sat, 30 Jun 2012 14:34:10 +0200, Dmitry A. Kazakov wrote:
>> 
>>>> Code review and maintainability problems. The set of symbols cannot be
>>>> infinite.
>>> 
>>> Practical considerations surely restrict the length of additional
>>> operators, but I'm not sure that restriction belongs in the syntax.
>> 
>> I didn't meant length. I think that the number of operators should be
>> small to be memorizable. All symbols should be predefined, e.g. from the
>> Unicode page.
> 
> A symbol is not necessarily a single character;  "<="  already isn't.

This is an ASCII artefact. With Unicode adopted, there is no need in such
tricks. BTW, less-that-or-equal is one character: U+2264.

> And 
> restricting the sequence length necessarily restricts the number of 
> possible identifiers, so I'm not clear what you are suggesting.

Since we allowed Unicode anyway, we could allow all Unicode mathematical
operators for use as unary and binary operators. I don't see Unicode making
any distinction between unary and binary. If it does Ada should follow
that.

Unicode specifies some symbols as relations, some as operators. According
to that we can assign binary operator priorities (relational level vs.
binary adding level). When priorities are same, association of different
operators is illegal. Unary operators are highest level, right-to-left,
illegal to associate with any binary operators.

That is. No user-defined sequences.

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

Re: What would you like in Ada202X?

[Pascal Obry]

Oliver,

> IMHO requiring explicit parentheses is a good thing:
> The C language comes to mind, where it is legal to write
>   a---b
> Quick: is that "a-- - b" or "a - --b" ?

The former I would bet as -- as higher precedence but I agree that this
is just plain wrong. It should not be allowed.

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

Re: What would you like in Ada202X?

[Brian Drummond]

On Sat, 30 Jun 2012 21:26:09 +0300, Niklas Holsti wrote:

> On 12-06-30 20:37 , Brian Drummond wrote:
>> On Sat, 30 Jun 2012 11:51:51 -0400, Robert A Duff wrote:
>>
>>> Brian Drummond<brian@shapes.demon.co.uk>  writes:
>>>
>>>> We can overload existing operators (+,-,etc)
>>>> But we can't define new ones, e.g. // 
>> If P1."//" and P2."//" apply to different types, does it really matter
>> that they have different precedences, unless the base type is the same?

> Overload resolution would be very messed up. The parsed structure of the
> expression would be different for different resolutions of overloaded
> names and operators. Ugh!

I have to agree with that, and Robert's view that it entangles syntax and 
semantics too closely. So it would require the simplest possible solution 
to the precedence problem :
> IMO the new operators should all be put at the same precedence level,
> either above or below all the predefined operators. Perhaps below (most
> loosely binding) is the better choice. 

Or:
>The parentheses around the operands could even be
> required.

I think that is what the "unrelated precedence" (like "and" and "or) 
achieves, and it is probably the best approach. It also solves Oliver's 
point regarding mixing unary and binary operators.

> New unary operators should also be allowed, of course.

Yes, if possible. I didn't mention unary operations because I wasn't 
clear if that added further issues.

>> "Add(A,Multiply(B,C))"...
> 
> I agree that defining new operators could be useful. It could also be
> overused to make programs hard to read and understand, for a reader who
> does not already know what the new operators mean. 

Right. A good use would be where the operators are already currency in 
the problem domain, or otherwise familiar to the readers. 
There may be uses in translating APL programs (if anyone is still 
familiar with APL).

Another valid use might be to replace e.g. "+" in string manipulation 
where addition (or positive value) is not the intended meaning, but "+" 
is just the least objectionable symbol available. A new operator might 
ease reading by removing confusion with addition.

- Brian

Re: What would you like in Ada202X?

[Brian Drummond]

On Sun, 01 Jul 2012 10:25:07 +0200, Dmitry A. Kazakov wrote:

> On Sat, 30 Jun 2012 21:06:15 +0000 (UTC), Brian Drummond wrote:
> 
>> On Sat, 30 Jun 2012 20:43:17 +0200, Dmitry A. Kazakov wrote:
>> 
>>> On Sat, 30 Jun 2012 17:00:46 +0000 (UTC), Brian Drummond wrote:
>>> 
>>>> On Sat, 30 Jun 2012 14:34:10 +0200, Dmitry A. Kazakov wrote:
>>> 
>>>>> Code review and maintainability problems. The set of symbols cannot
>>>>> be infinite.
>>>> 
>>>> Practical considerations surely restrict the length of additional
>>>> operators, but I'm not sure that restriction belongs in the syntax.
>>> 
>>> I didn't meant length. I think that the number of operators should be
>>> small to be memorizable. All symbols should be predefined, e.g. from
>>> the Unicode page.
>> 
>> A symbol is not necessarily a single character;  "<="  already isn't.
> 
> This is an ASCII artefact. With Unicode adopted, there is no need in
> such tricks. BTW, less-that-or-equal is one character: U+2264.

But until ASCII and/or Latin-1 are fully obsoleted, it is an artefact 
that must be supported. Therefore there are operators that are more than 
one character.

>> And restricting the sequence length necessarily restricts the number of
>> possible identifiers, so I'm not clear what you are suggesting.
...
> That is. No user-defined sequences.

But an extended set of built-in symbols for operators, only supported 
where full Unicode is available?

- Brian

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Sun, 1 Jul 2012 10:57:44 +0000 (UTC), Brian Drummond wrote:

> On Sun, 01 Jul 2012 10:25:07 +0200, Dmitry A. Kazakov wrote:
> 
>> On Sat, 30 Jun 2012 21:06:15 +0000 (UTC), Brian Drummond wrote:
>> 
>>> On Sat, 30 Jun 2012 20:43:17 +0200, Dmitry A. Kazakov wrote:
>>> 
>>>> On Sat, 30 Jun 2012 17:00:46 +0000 (UTC), Brian Drummond wrote:
>>>> 
>>>>> On Sat, 30 Jun 2012 14:34:10 +0200, Dmitry A. Kazakov wrote:
>>>> 
>>>>>> Code review and maintainability problems. The set of symbols cannot
>>>>>> be infinite.
>>>>> 
>>>>> Practical considerations surely restrict the length of additional
>>>>> operators, but I'm not sure that restriction belongs in the syntax.
>>>> 
>>>> I didn't meant length. I think that the number of operators should be
>>>> small to be memorizable. All symbols should be predefined, e.g. from
>>>> the Unicode page.
>>> 
>>> A symbol is not necessarily a single character;  "<="  already isn't.
>> 
>> This is an ASCII artefact. With Unicode adopted, there is no need in
>> such tricks. BTW, less-that-or-equal is one character: U+2264.
> 
> But until ASCII and/or Latin-1 are fully obsoleted, it is an artefact 
> that must be supported. Therefore there are operators that are more than 
> one character.

But no new ones, except for "in", "not in", "and then", "or else" which
must become true operators.

>>> And restricting the sequence length necessarily restricts the number of
>>> possible identifiers, so I'm not clear what you are suggesting.
> ...
>> That is. No user-defined sequences.
> 
> But an extended set of built-in symbols for operators, only supported 
> where full Unicode is available?

Yes.

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

Re: What would you like in Ada202X?

[Randy Brukardt]

On Friday, June 29, 2012 1:29:03 PM UTC+2, (unknown) wrote:
> 1. Want to see parameter modes in calls.
>
> procedure Proc (An_In_Parameter     : in     Integer;
>                 An_Out_Parameter    :    out Integer;
>                 An_Inout_Parameter  : in out Integer;
>                 An_Access_Parameter : access Integer);
>
> Proc (An_In_Parameter     <=  A,
>       An_Out_Parameter     => B,
>       An_Inout_Parameter  <=> C,
>       An_Access_Parameter  -> D'Access);
>
> A becomes An_In_Parameter, An_Out_Parameter becomes B, etc.

Formally, an access parameter has mode "in" ("access" is NOT a parameter 
mode), so this is definitely not exactly obvious.

There is a (brief) discussion of this idea in AI05-0144-1; it was rejected 
as not really solving the problem at hand. (Which is not the same as saying 
that it doesn't solve ANY problem.) I know there was an e-mail discussion on 
this idea as well, but I haven't been able to locate it.

                                 Randy. 

Re: What would you like in Ada202X?

[Randy Brukardt]

"Brian Drummond" <brian@shapes.demon.co.uk> wrote in message 
news:jspaf8$6rm$2@dont-email.me...
...
> But an extended set of built-in symbols for operators, only supported
> where full Unicode is available?

Ada 2012 requires compilers to accept UTF-8 encoded source code. So "full 
Unicode" is available on any Ada 2012 compiler. I suppose source display 
might be an issue if your programming environment is running on Windows 98 
or some other antique, but that's not an issue with modern systems. And of 
course, you need a programming editor that supports UTF-8, but since that's 
the standard source format for Ada 2012 code, they should be readily 
available.

                              Randy.

Re: What would you like in Ada202X?

[Pascal Obry]

I think it would be nice to be able to slice an array of any dimention.

   --  This is Ada

   type T is array (Positive range <>, Positive range <>) of Integer;

   A : T (1 .. 10, 1 .. 100);

   --  This could be Ada 202X

   B : T := A (2 .. 3, 3 .. 8);

Ok it is possible to do that with loop, but that's also true for simple
slice. I suppose also that in such a slice the compiler will be able to
generate efficient code (probably better than a using loop) depending on
the memory representation for the array.

Thoughts?

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

Re: What would you like in Ada202X?

[Pascal Obry]

Le 03/07/2012 17:41, Pascal Obry a �crit :
> 
> I think it would be nice to be able to slice an array of any dimention.
> 
>    --  This is Ada
> 
>    type T is array (Positive range <>, Positive range <>) of Integer;
> 
>    A : T (1 .. 10, 1 .. 100);
> 
>    --  This could be Ada 202X
> 
>    B : T := A (2 .. 3, 3 .. 8);

Ok, there is already a whole thread about this... Sorry for the noise :)

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

Re: What would you like in Ada202X?

[Ada novice]

I would like to see numerical libraries for scientific computing a reality. There has been much work in the early 80's to use Ada in many scientific computations but today no one practically writes a book to show how Ada can help computational engineers to use the language and its software engineering aspects.

Math functions such as fft, ODE solvers, eigensystems for non-symmetric and non-hermitian matrices ahould be made part of the language. 

Interfaces to C, Fortran exist and so to associated IMSL libraries for example but work should really be done to elevate the status of Ada in the computation world. Perhaps an interface to Matlab would be the turning point?

Also, a graphing tool to plot simple x-y plots should be implemented in the language.

Best Regards,
YC

Re: What would you like in Ada202X?

[Nasser M. Abbasi]

On 7/4/2012 6:41 AM, Ada novice wrote:

<snip math/ada>

Fyi,

Ada already has some limited build-in API for the above as
part of its library (solve(), transpose(), etc..).

See my list here:
http://12000.org/my_notes/lapack_analysis/index.htm

There is a lacack 77 binding to Ada. I installed it the other
day. most of the tests passed (using GNAT 2012), but some failed.
I need to figure why some tests failed (the calls made to some
Lapack functions were wrong, need to fix the binding).
The binding is here

ftp://ftp.cs.kuleuven.be/pub/Ada-Belgium/mirrors/gnu-ada/OLD/contrib/lapack-ada/

I had to make few tweaks to makefile to get the build work.

The GNAT command I used to build example1

-----------------------
gnatmake -gnat2012 example1.adb -largs -L/usr/lib/atlas-base/:/usr/lib/atlas-base/atlas/:/usr/lib:/usr/lib/libblas -largs -lblas

gnatbind -x example1.ali

gnatlink example1.ali -L/usr/lib/atlas-base/:/usr/lib/atlas-base/atlas/:/usr/lib:/usr/lib/libblas -lblas
--------------------------

Need to install blas and lapack yourself first. Use Atlas blas.

Will document all that when I have little time, but need
to fix the test errors I got from the above binding first.
I was trying to see if I can use Lapack directly from Ada.

There is also now lapack90. Lapack 77 is old and I think
lapack90 is the better API to use. That is meant for use with
Fortran90 and beyond.

btw, Fortran does have many more math build-in functions (called
intrinsic functions) than Ada does.

--Nasser

Re: What would you like in Ada202X?

[shai.lesh]

On Wednesday, July 4, 2012 1:30:16 PM UTC+1, Nasser M. Abbasi wrote:
> 
> Ada already has some limited build-in API for the above as
> part of its library (solve(), transpose(), etc..).

Yes I know but I do not see any new functions in Ada 2012.

> 
> See my list here:
> http://12000.org/my_notes/lapack_analysis/index.htm

This is very useful indeed.


> 
> There is a lacack 77 binding to Ada. 
> 
> ftp://ftp.cs.kuleuven.be/pub/Ada-Belgium/mirrors/gnu-ada/OLD/contrib/lapack-ada/

Thank you for the link.


> Need to install blas and lapack yourself first. Use Atlas blas.

Is it from http://math-atlas.sourceforge.net/ ?

> 
> Will document all that when I have little time, but need
> to fix the test errors I got from the above binding first.
> I was trying to see if I can use Lapack directly from Ada.

This will indeed be very helpful.

 
> btw, Fortran does have many more math build-in functions (called
> intrinsic functions) than Ada does.

Yes I realised that but that doesn't prevent Ada developers from putting some more efforts into next Ada versions.


Thanks
YC

Re: What would you like in Ada202X?

[Simon Wright]

"Nasser M. Abbasi" <nma@12000.org> writes:

> Need to install blas and lapack yourself first. Use Atlas blas.

Since Ada.Numerics.Generic[_Complex]_Arrays already depend on BLAS and
LAPACK I'd have thought they'd come with GNAT (if not already on the
platform, as they are with Mac OS X).

Re: What would you like in Ada202X?

[Nasser M. Abbasi]

On 7/4/2012 12:55 PM, Simon Wright wrote:
> "Nasser M. Abbasi" <nma@12000.org> writes:
>
>> Need to install blas and lapack yourself first. Use Atlas blas.
>
> Since Ada.Numerics.Generic[_Complex]_Arrays already depend on BLAS and
> LAPACK I'd have thought they'd come with GNAT (if not already on the
> platform, as they are with Mac OS X).
>

If I just do gnatmake on the file that uses laplack binding, (the
example test program, which makes direct calls to lapack), it
will complain, during the link process, about missing symbols in blas.
so the linker does not see them.

So that is why I had to point it to linux installed blas/lapack
area to get the link to work as I showed in the command above.

But if I call solve() in Ada to solve Ax=b (which I assume
ends up making a call to lapack SGESV(), then I do not need
to anything other just type gnatmake. I guess it knows then
where these libraries are. Not sure how. It could be using then
the gnat-own supplied copy of blas, may be located in other area
known to gnatmake. I have not looked into it more.

--Nasser

  

Re: What would you like in Ada202X?

[shai.lesh]

On Wednesday, July 4, 2012 8:22:46 PM UTC+1, Dennis Lee Bieber wrote:

> 	A search of my machine (WinXP, ancient) with the 2011 build from
> AdaCore/libre, seeking *blas*.*
> 
> 
> 	Nothing in E:\GNAT\... and only an old malware checker from M$ in
> system directories.
> -- 

Nothing in mine too. I have both GNAT GPL 2011 and 2012 on Windows. Hope that next Ada versions will make the library more "accessible" and easier to use.

YC

Re: What would you like in Ada202X?

[Simon Wright]

shai.lesh@gmx.com writes:

> On Wednesday, July 4, 2012 8:22:46 PM UTC+1, Dennis Lee Bieber wrote:
>
>> 	A search of my machine (WinXP, ancient) with the 2011 build from
>> AdaCore/libre, seeking *blas*.*
>> 
>> 
>> 	Nothing in E:\GNAT\... and only an old malware checker from M$ in
>> system directories.
>> -- 
>
> Nothing in mine too. I have both GNAT GPL 2011 and 2012 on
> Windows. Hope that next Ada versions will make the library more
> "accessible" and easier to use.

Looks as though for GNAT GPL 2011 on Windows, BLAS and LAPACK are in
C:\GNAT\2011\lib\gcc\i686-pc-mingw32\4.5.3\libgnalasup.a.

Not as obvious as one might have expected.

Re: What would you like in Ada202X?

[shai.lesh]

> On Wed, 04 Jul 2012 23:26:53 +0100, Simon Wright <simon@pushface.org>
> declaimed the following in comp.lang.ada:
> 
> > 
> > Looks as though for GNAT GPL 2011 on Windows, BLAS and LAPACK are in
> > C:\GNAT\2011\lib\gcc\i686-pc-mingw32\4.5.3\libgnalasup.a.
> > 
> > Not as obvious as one might have expected.
> 

Ok but one cannot look at the contents of the file. It's encrypted.

YC

Re: What would you like in Ada202X?

[Simon Wright]

shai.lesh@gmx.com writes:

>> On Wed, 04 Jul 2012 23:26:53 +0100, Simon Wright <simon@pushface.org>
>> declaimed the following in comp.lang.ada:
>> 
>> > 
>> > Looks as though for GNAT GPL 2011 on Windows, BLAS and LAPACK are in
>> > C:\GNAT\2011\lib\gcc\i686-pc-mingw32\4.5.3\libgnalasup.a.
>> > 
>> > Not as obvious as one might have expected.
>> 
>
> Ok but one cannot look at the contents of the file. It's encrypted.

Here, it's a standard 'ar' archive. 'ar' is one of the Unix tools that
you get with a developer install of Cygwin.

Re: What would you like in Ada202X?

[georg bauhaus]

<shai.lesh@gmx.com> wrote:
>> On Wed, 04 Jul 2012 23:26:53 +0100, Simon Wright <simon@pushface.org>
>> declaimed the following in comp.lang.ada:
>> 
>>> 
>>> Looks as though for GNAT GPL 2011 on Windows, BLAS and LAPACK are in
>>> C:\GNAT\2011\lib\gcc\i686-pc-mingw32\4.5.3\libgnalasup.a.
>>> 
>>> Not as obvious as one might have expected.
>> 
> 
> Ok but one cannot look at the contents of the file. It's encrypted.

Just a normal library of compiled functions. You could list the contents,
say, but there is no source text  in it.

Re: What would you like in Ada202X?

[shai.lesh]

Has anyone looked at this Ada 95 binding to the BLAS and if it works?

http://topo.math.u-psud.fr/~sands/Programs/BLAS/index.html


YC

Re: What would you like in Ada202X?

[Nasser M. Abbasi]

On 7/5/2012 6:57 AM, shai.lesh@gmx.com wrote:
> Has anyone looked at this Ada 95 binding to the BLAS and if it works?
>
> http://topo.math.u-psud.fr/~sands/Programs/BLAS/index.html
>
>
> YC
>

Yes.

I downloaded the Ada Blas binding the other day. Only run the
one example1 that comes with it. No more tests there. That example
worked. Using gnat 2012.

----------------------------------
>ls -lrt
total 1662
-rwxrwxrwx 1 me me   3787 Jul 28  2002 print_precisions.adb
-rwxrwxrwx 1 me me  13690 Jul 28  2002 index.html
-rwxrwxrwx 1 me me    477 Jul 28  2002 example_support.ads
-rwxrwxrwx 1 me me    407 Jul 28  2002 example1.adb
-rwxrwxrwx 1 me me   1325 Jul 28  2002 copying
-rwxrwxrwx 1 me me  22799 Jul 28  2002 ada_blas-real.ads
-rwxrwxrwx 1 me me 110580 Jul 28  2002 ada_blas-real.adb
-rwxrwxrwx 1 me me   3703 Jul 28  2002 ada_blas-get_precision.ads
-rwxrwxrwx 1 me me  23987 Jul 28  2002 ada_blas-complex.ads
-rwxrwxrwx 1 me me 123517 Jul 28  2002 ada_blas-complex.adb
-rwxrwxrwx 1 me me   4255 Jul 28  2002 ada_blas.ads
-rwxrwxrwx 1 me me   3651 Jun 27 01:54 print_precisions.ali
-rwxrwxrwx 1 me me   8376 Jun 27 01:54 print_precisions.o
-rwxrwxrwx 1 me me   1684 Jun 27 01:54 ada_blas.ali
-rwxrwxrwx 1 me me   2484 Jun 27 01:54 ada_blas.o
-rwxrwxrwx 1 me me   1074 Jun 27 01:54 ada_blas-get_precision.ali
-rwxrwxrwx 1 me me    726 Jun 27 01:54 ada_blas-get_precision.o
-rwxrwxrwx 1 me me 551658 Jun 27 01:55 print_precisions
-rwxrwxrwx 1 me me   2420 Jun 27 01:56 example1.ali
-rwxrwxrwx 1 me me   1716 Jun 27 01:56 example1.o
-rwxrwxrwx 1 me me   1404 Jun 27 01:56 example_support.ali
-rwxrwxrwx 1 me me  62476 Jun 27 01:56 example_support.o
-rwxrwxrwx 1 me me  67737 Jun 27 01:56 ada_blas-real.ali
-rwxrwxrwx 1 me me    708 Jun 27 01:56 ada_blas-real.o
-rwxrwxrwx 1 me me 602284 Jun 27 08:18 example1
-rwxrwxrwx 1 me me  76954 Jul  5 07:05 ada_blas-complex.ali
-rwxrwxrwx 1 me me    714 Jul  5 07:05 ada_blas-complex.o

This make a call to BLAS dot()
---------------------------
>cat example1.adb
with Ada.Float_Text_IO;
with Ada.Text_IO;
with Example_Support; use Example_Support;

procedure Example1 is
    A : Vector (1 .. 2) := (1.0, 1.0);
    B : Vector (1 .. 2) := (1.0, -1.0);
    D : Float := Real_BLAS.DOT (A, B); -- Does your compiler eliminate all overhead?
begin
    Ada.Text_IO.Put ("Dot product is: ");
    Ada.Float_Text_IO.Put (D);
    Ada.Text_IO.New_Line;
    Ada.Text_IO.Flush;
end Example1;
>
-----------------------

>./example1
Dot product is:  0.00000E+00

On Linux, GNAT 2012

--Nasser

Re: What would you like in Ada202X?

[Nasser M. Abbasi]

On 7/5/2012 7:11 AM, Nasser M. Abbasi wrote:
> On 7/5/2012 6:57 AM, shai.lesh@gmx.com wrote:
>> Has anyone looked at this Ada 95 binding to the BLAS and if it works?
>>
>> http://topo.math.u-psud.fr/~sands/Programs/BLAS/index.html
>>
>>
>> YC
>>
>

>
>> ./example1
> Dot product is:  0.00000E+00
>

I forgot the other example:

-- Copyright (C) 2000-2001 Centre National de la Recherche Scientifique
--  Show the BLAS precisions corresponding to a sample of floating point types.

------------------------------------
>./print_precisions
-- Various BLAS precisions --
Float_Type'Digits: 1
Float_Type'Base'Digits: 6
BLAS precision: SINGLE

Float_Type'Digits: 4
Float_Type'Base'Digits: 6
BLAS precision: SINGLE

Float_Type'Digits: 9
Float_Type'Base'Digits: 15
BLAS precision: DOUBLE

Float_Type'Digits: 13
Float_Type'Base'Digits: 15
BLAS precision: DOUBLE

Float_Type'Digits: 18
Float_Type'Base'Digits: 18
BLAS precision: UNSUPPORTED
---------------------------------

--Nasser

Re: What would you like in Ada202X?

[shai.lesh]

On Thursday, July 5, 2012 1:21:15 PM UTC+1, Nasser M. Abbasi wrote:
> On 7/5/2012 7:11 AM, Nasser M. Abbasi wrote:

> >> ./example1
> > Dot product is:  0.00000E+00

How did you compile and run example 1? I created a project in GPS with example1.adb as the main file in the same directory as Ada_BLAS. I get lots of error messages:

gnatmake -d -PE:\learsof\ada\Ada_BLAS\pure.gpr
gnatbind -E -I- -x E:\learsof\ada\Ada_BLAS\example1.ali
gnatlink E:\learsof\ada\Ada_BLAS\example1.ali -g -o E:\learsof\ada\Ada_BLAS\example1.exe
E:\learsof\ada\Ada_BLAS\example_support.o: In function `example_support__real_blas__amax':
E:/learsof/ada/Ada_BLAS/ada_blas-real.adb:68: undefined reference to `isamax_'

...long list here

E:\learsof\ada\Ada_BLAS\example1.o: In function `example_support__real_blas__dot__2':
E:/learsof/ada/Ada_BLAS/ada_blas-real.adb:388: undefined reference to `sdot_'
collect2: ld returned 1 exit status
gnatlink: error when calling C:\GNAT\2012\bin\gcc.exe
gnatmake: *** link failed.

Would you kindly explain how you succeeded? I am on a Windows platform.


Thanks.
YC

Re: What would you like in Ada202X?

[Nasser M. Abbasi]

On 7/5/2012 8:07 AM, shai.lesh@gmx.com wrote:
> On Thursday, July 5, 2012 1:21:15 PM UTC+1, Nasser M. Abbasi wrote:
>> On 7/5/2012 7:11 AM, Nasser M. Abbasi wrote:
>
>>>> ./example1
>>> Dot product is:  0.00000E+00
>
> How did you compile and run example 1? I created a project in GPS with example1.adb

I do not use windows for anything relating to software development,
and I do not use GPS.

I use linux, and the command line and a text editor :)

I just used gnatmake *.adb

>
> E:\learsof\ada\Ada_BLAS\example1.o: In function `example_support__real_blas__dot__2':
> E:/learsof/ada/Ada_BLAS/ada_blas-real.adb:388: undefined reference to `sdot_'
> collect2: ld returned 1 exit status
> gnatlink: error when calling C:\GNAT\2012\bin\gcc.exe
> gnatmake: *** link failed.
>
> Would you kindly explain how you succeeded? I am on a Windows platform.
>
>

It looks like linker is not seeing your blas library.

Just make sure to install blas before using the above. see note in README

"LAPACK comes with an incomplete version of the BLAS.
The missing routines can be picked up from NETLIB. If you
are using the BLAS that come with LAPACK and your linker
is complaining that it can't find some routines, now you know why!"

I use linux, so all what I have to do is synaptic package
manager and select libatlas3gf-base from the menu
(which is Automatically Tuned Linear Algebra Software, generic shared
library) and click OK. That is all.

This will install all the needed blas stuff on your system.

Now you can go to the Ada BLAS biding and gnatmake it.

Make sure to set your LD_LIBRARY_PATH first

This is my LD_LIBRARY_PATH

>echo $LD_LIBRARY_PATH
/usr/lib/i386-linux-gnu/:/usr/lib/atlas-base/:/usr/lib/atlas-base/atlas/

That is all. Or you can try to find the GNAT supplied blas
library (see the other thread on this), and adjust your
windows env. variables or your gpr build file (I do not use
that). to make sure the linker knows where the shared
blas library is.

--Nasser

Re: What would you like in Ada202X?

[Ada novice]

On Thursday, July 5, 2012 3:08:48 PM UTC+1, Nasser M. Abbasi wrote:
> It looks like linker is not seeing your blas library.
> 
> Just make sure to install blas before using the above. see note in README
> 

Thanks for your suggestions. It is just a big mess to have blas or lapack installed on a Windows platform. I give up.

YC

Re: What would you like in Ada202X?

[johnscpg]

On Wednesday, July 4, 2012 11:26:53 PM UTC+1, Simon Wright wrote:
> shai.lesh writes:
> 
> > On Wednesday, July 4, 2012 8:22:46 PM UTC+1, Dennis Lee Bieber wrote:
> >
> >> 	A search of my machine (WinXP, ancient) with the 2011 build from
> >> AdaCore/libre, seeking *blas*.*
> >> 
> >> 
> >> 	Nothing in E:\GNAT\... and only an old malware checker from M$ in
> >> system directories.
> >> -- 
> >
> > Nothing in mine too. I have both GNAT GPL 2011 and 2012 on
> > Windows. Hope that next Ada versions will make the library more
> > "accessible" and easier to use.
> 
> Looks as though for GNAT GPL 2011 on Windows, BLAS and LAPACK are in
> C:\GNAT\2011\lib\gcc\i686-pc-mingw32\4.5.3\libgnalasup.a.
> 
> Not as obvious as one might have expected.

On linux, the GNAT GPL 2011 lapack stuff seems to be in 
.../lib/gcc/x86_64-pc-linux-gnu/4.5.3/adalib/libgnala.a

Package interfaces.fortran.blas was in the files i-forbla.ads and 
i-forbla.adb, and lapack interfaces in i-forlap.ads.

In the GNAT GPL 2012 distribution I can't find any of these things. I
was able to get your Ada_Numerics.Generic_Arrays package working OK on
GPL 2012, but I had to copy i-forbla.ads and i-forbla.adb from the old
GPL 2011 src, and I had to link to my own lapack and blas libraries. At least
System.Generic_Array_Operations is still in 2012, so Ada_Numerics.Generic_Arrays worked well. 

J.

Re: What would you like in Ada202X?

[Simon Wright]

johnscpg@googlemail.com writes:

> Package interfaces.fortran.blas was in the files i-forbla.ads and
> i-forbla.adb, and lapack interfaces in i-forlap.ads.
>
> In the GNAT GPL 2012 distribution I can't find any of these things. I
> was able to get your Ada_Numerics.Generic_Arrays package working OK on
> GPL 2012, but I had to copy i-forbla.ads and i-forbla.adb from the old
> GPL 2011 src, and I had to link to my own lapack and blas
> libraries. At least System.Generic_Array_Operations is still in 2012,
> so Ada_Numerics.Generic_Arrays worked well.

Same problem with GCC 4.7.

AdaCore have stopped using BLAS and LAPACK; for symmetric real matrices
they use an internal implementation of Jacobi, and for hermitian complex
matrices they say

      --  For a Hermitian matrix C, we convert the eigenvalue problem to a
      --  real symmetric one: if C = A + i * B, then the (N, N) complex
      --  eigenvalue problem:
      --     (A + i * B) * (u + i * v) = Lambda * (u + i * v)
      --
      --  is equivalent to the (2 * N, 2 * N) real eigenvalue problem:
      --     [  A, B ] [ u ] = Lambda * [ u ]
      --     [ -B, A ] [ v ]            [ v ]
      --
      --  Note that the (2 * N, 2 * N) matrix above is symmetric, as
      --  Transpose (A) = A and Transpose (B) = -B if C is Hermitian.

      --  We solve this eigensystem using the real-valued algorithms. The final
      --  result will have every eigenvalue twice, so in the sorted output we
      --  just pick every second value, with associated eigenvector u + i * v.

So, I've got some work ahead of me; and, regrettably, users of my Ada
2005 Math Extensions[1] are probably going to need to install their own
BLAS/LAPACK libraries (not on Mac OS X, I think). Grr. Bug raised[2].

One thing I _don't_ see in the SVN history is any indication of _why_
this change was made.

[1] https://sourceforge.net/projects/gnat-math-extn/
[2] https://sourceforge.net/tracker/?func=detail&aid=3540499&group_id=338296&atid=1416932

Re: What would you like in Ada202X?

[shai.lesh]

On Thursday, July 5, 2012 5:57:12 PM UTC+1, Simon Wright wrote:
> So, I've got some work ahead of me; 

Good luck Simon. 

>and, regrettably, users of my Ada 2005 Math Extensions[1] are probably going  >to need to install their own BLAS/LAPACK libraries (not on Mac OS X, I think). >Grr. Bug raised[2].
> 

If somebody has been able to install BLAS/LAPACK well on Windows and make it work properly, please let me know.

YC

Re: What would you like in Ada202X?

[John B. Matthews]

In article <m23956y61m.fsf@pushface.org>,
 Simon Wright <simon@pushface.org> wrote:

> shai.lesh@gmx.com writes:
> 
> >> On Wed, 04 Jul 2012 23:26:53 +0100, Simon Wright <simon@pushface.org>
> >> declaimed the following in comp.lang.ada:
> >> 
> >> > 
> >> > Looks as though for GNAT GPL 2011 on Windows, BLAS and LAPACK 
> >> > are in C:\GNAT\2011\lib\gcc\i686-pc-mingw32\4.5.3\libgnalasup.a.
> >> > 
> >> > Not as obvious as one might have expected.
> >> 
> >
> > Ok but one cannot look at the contents of the file. It's encrypted.
> 
> Here, it's a standard 'ar' archive. 'ar' is one of the Unix tools 
> that you get with a developer install of Cygwin.

The utility 'nm' may be used to examine the symbols in such as archive.

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: What would you like in Ada202X?

[Ada novice]

On Thursday, July 5, 2012 5:57:12 PM UTC+1, Simon Wright wrote:

> One thing I _don't_ see in the SVN history is any indication of _why_
> this change was made.
> 

Perhaps some information here:
http://patchwork.ozlabs.org/patch/123609/
http://gcc.gnu.org/ml/gcc-patches/2011-08/msg02324.html
http://gcc.gnu.org/ml/gcc-patches/2011-08/msg02408.html

YC

Re: What would you like in Ada202X?

[Simon Wright]

Ada novice <shai.lesh@gmx.com> writes:

> On Thursday, July 5, 2012 5:57:12 PM UTC+1, Simon Wright wrote:
>
>> One thing I _don't_ see in the SVN history is any indication of _why_
>> this change was made.
>> 
>
> Perhaps some information here:
> http://patchwork.ozlabs.org/patch/123609/
> http://gcc.gnu.org/ml/gcc-patches/2011-08/msg02324.html
> http://gcc.gnu.org/ml/gcc-patches/2011-08/msg02408.html
>
> YC

Thanks. The reasons, from the patch diff, ore

+--  This version of Generic_Real_Arrays avoids the use of BLAS and LAPACK. One
+--  reason for this is new Ada 2012 requirements that prohibit algorithms such
+--  as Strassen's algorithm, which may be used by some BLAS implementations. In
+--  addition, some platforms lacked suitable compilers to compile the reference
+--  BLAS/LAPACK implementation. Finally, on many platforms there may be more
+--  floating point types than supported by BLAS/LAPACK.

The last post you reference asked what Ada 2012 requirements prohibit
Strassen's algorithm. Answer came there none; however, looking at the
AARM, G.3.1(86.c)[1] is fairly explicit, and AI05-0047-1[2] shows the
reasoning.

The AI starts "It is clarified that subcubic methods cannot be used for
the implementation of matrix multiplication using "*" in the strict
mode." Although a BLAS might use Strassen for very large matrices,

(a) it probably won't for the sort of reasonably-sized matrices you
might find in an Ada program

(b) whether it ever uses Strassen is probably documented.

My Ada 2005 Math Extensions will continue to use BLAS/LAPACK;
interfacing to an amazing pair of packages like these I can do,
re-invent the wheels I can't and won't.

[1] http://www.ada-auth.org/standards/12aarm/html/AA-G-3-1.html#p86.c
[2] http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0047-1.txt?rev=1.11

Re: What would you like in Ada202X?

[Egil Høvik]

On Friday, July 6, 2012 5:29:20 PM UTC+2, Simon Wright wrote:
> Ada novice writes:
> 
> > On Thursday, July 5, 2012 5:57:12 PM UTC+1, Simon Wright wrote:
> >
> >> One thing I _don't_ see in the SVN history is any indication of _why_
> >> this change was made.
> >> 
> >
> > Perhaps some information here:
> > http://patchwork.ozlabs.org/patch/123609/
> > http://gcc.gnu.org/ml/gcc-patches/2011-08/msg02324.html
> > http://gcc.gnu.org/ml/gcc-patches/2011-08/msg02408.html
> >
> > YC
> 
> Thanks. The reasons, from the patch diff, ore
> 
> +--  This version of Generic_Real_Arrays avoids the use of BLAS and LAPACK. One
> +--  reason for this is new Ada 2012 requirements that prohibit algorithms such
> +--  as Strassen's algorithm, which may be used by some BLAS implementations. In
> +--  addition, some platforms lacked suitable compilers to compile the reference
> +--  BLAS/LAPACK implementation. Finally, on many platforms there may be more
> +--  floating point types than supported by BLAS/LAPACK.
> 

There's also the fact that the BLAS/LAPACK libraries used by AdaCore in 
previous versions were C code generated from very old Fortran, where stack
variables didn't exist, thus the C code is littered with static variables,
which means a ton of issues with multithreading, and is a violation of RM A(3)



-- 
~egilhh

Re: What would you like in Ada202X?

[Simon Wright]

Egil Høvik <egilhovik@hotmail.com> writes:

> There's also the fact that the BLAS/LAPACK libraries used by AdaCore
> in previous versions were C code generated from very old Fortran,
> where stack variables didn't exist, thus the C code is littered with
> static variables, which means a ton of issues with multithreading, and
> is a violation of RM A(3)

Good point!

What's the threading position with current BLAS/LAPACK?

Re: What would you like in Ada202X?

[Egil Høvik]

On Thursday, July 12, 2012 10:29:44 AM UTC+2, Simon Wright wrote:
> Egil Høvik writes:
> 
> > There's also the fact that the BLAS/LAPACK libraries used by AdaCore
> > in previous versions were C code generated from very old Fortran,
> > where stack variables didn't exist, thus the C code is littered with
> > static variables, which means a ton of issues with multithreading, and
> > is a violation of RM A(3)
> 
> Good point!
> 
> What's the threading position with current BLAS/LAPACK?

I wouldn't know, but I expect the highly optimized Intel- and AMD-versions
to be thread-safe as they are probably coded from scratch

-- 
~egilhh

Re: What would you like in Ada202X?

[Nasser M. Abbasi]

On 7/12/2012 3:29 AM, Simon Wright wrote:

>
> What's the threading position with current BLAS/LAPACK?

If you use recent Lapack, it should be OK according to :

http://www.netlib.org/lapack/lapack-3.1.0.changes

"
================
== LAPACK 3.1 ==
================

Release date: Su 11/12/2006.


"6) Thread safety: Removed all the SAVE and DATA statements (or provided
     alternate routines without those statements), increasing reliability
     on SMPs."

Also, from this pdf file,

http://www.lahey.com/docs/blaseman_Lin62.pdf

I see:

"This manual describes the usage of the following two software.
BLAS thread-safe version V4.0
LAPACK thread-safe version V4.0

Example program using thread-safe subroutines
This section shows an example code that uses subroutines
from BLAS and LAPACK thread-safe
versions. The example is simple enough to understand
and intended for use in order to describe
principles of calling thread-safe subroutines from an
OpenMP Fortran program.
"

So, It seems from all the above and few other things I've
seen googling this, that current versions are thread safe.

--Nasser
  

Re: What would you like in Ada202X?

[Georg Bauhaus]

On 12.07.12 11:00, Egil H�vik wrote:
> On Thursday, July 12, 2012 10:29:44 AM UTC+2, Simon Wright wrote:
>> Egil H�vik writes:
>>
>> > There's also the fact that the BLAS/LAPACK libraries used by AdaCore
>> > in previous versions were C code generated from very old Fortran,
>> > where stack variables didn't exist, thus the C code is littered with
>> > static variables, which means a ton of issues with multithreading, and
>> > is a violation of RM A(3)
>>
>> Good point!
>>
>> What's ...

(OT)
Lots of character entity references above, are they the consequence
of high tech organization Google making ASCII match their preferred
text data format?

Re: What would you like in Ada202X?

[Egil Høvik]

On Thursday, July 12, 2012 2:44:09 PM UTC+2, Georg Bauhaus wrote:
> (OT)
> Lots of character entity references above, are they the consequence
> of high tech organization Google making ASCII match their preferred
> text data format?

I should think so, I certainly can't think of any other reason.

-- 
~egilhh

Re: What would you like in Ada202X?

[Adam Beneschan]

On Thursday, July 12, 2012 5:44:09 AM UTC-7, Georg Bauhaus wrote:
 
> (OT)
> Lots of character entity references above, are they the consequence
> of high tech organization Google making ASCII match their preferred
> text data format?

Yeah, that's probably what they'd say if you asked them.  In reality, I think they tried to make a change and just (&#5E;&#7E;&#2A;'ed it up.  If you get my drift...  :) :) :)

I've felt for a long time that every time Google improves Google Groups, they make it worse.

                         -- Adam

Re: What would you like in Ada202X?

[Dmitry A. Kazakov]

On Thu, 12 Jul 2012 08:53:55 -0700 (PDT), Adam Beneschan wrote:

> I've felt for a long time that every time Google improves Google Groups, they make it worse.

Ashes Dejanews beats on my chest...

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

Re: What would you like in Ada202X?

[Georg Bauhaus]

On 12.07.12 17:53, Adam Beneschan wrote:
> On Thursday, July 12, 2012 5:44:09 AM UTC-7, Georg Bauhaus wrote:

>> (OT) Lots of character entity references above, are they the
>> consequence of high tech organization Google making ASCII match
>> their preferred text data format?
>
> Yeah, that's probably what they'd say if you asked them.
> In reality, I think they tried to make a change and just
> (&#5E;&#7E;&#2A;'ed it up.  If you get my drift...
> :) :) :)
>
> I've felt for a long time that every time Google improves Google
> Groups, they make it worse.

What do advertisers make technical talent do? Adam M. Costello
is a Software Engineer at Google: he had written the par program,

http://www.nicemice.net/par/

Re: What would you like in Ada202X?

[Martin]

On Wednesday, April 25, 2012 8:47:06 AM UTC+1, 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
> 2) parallel loops / functions
> 3) Multiple dispatch
> 
> -- Martin

Another one...


Standard 'socket' package, possibly starting a new hierarchy, e.g.

Ada.Networks.Sockets
Ada.Networks.<others>

-- Martin

Re: What would you like in Ada202X?

[Pascal Obry]

Martin,

> Another one...
> 
> Standard 'socket' package, possibly starting a new hierarchy, e.g.
> 
> Ada.Networks.Sockets
> Ada.Networks.<others>

I second that! It will have to come at some point, why not for 202X
then. I think there was already an effort to standardize a socket API.

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

Re: What would you like in Ada202X?

[Martin]

On Friday, July 13, 2012 12:04:19 PM UTC+1, Pascal Obry wrote:
> Martin,
> 
> > Another one...
> > 
> > Standard 'socket' package, possibly starting a new hierarchy, e.g.
> > 
> > Ada.Networks.Sockets
> > Ada.Networks.<others>
> 
> I second that! It will have to come at some point, why not for 202X
> then. I think there was already an effort to standardize a socket API.
> 
> 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

While we're at it, how about...

Ada.Encrytions.<crypt-types>?

-- Martin

Re: What would you like in Ada202X?

[David Thompson]

On Thu, 12 Jul 2012 08:53:55 -0700 (PDT), Adam Beneschan
<adam@irvine.com> wrote:

> On Thursday, July 12, 2012 5:44:09 AM UTC-7, Georg Bauhaus wrote:
>  
> > (OT)
> > Lots of character entity references above, are they the consequence
> > of high tech organization Google making ASCII match their preferred
> > text data format?
> 
> Yeah, that's probably what they'd say if you asked them.  In reality, I think they tried to make 
> a change and just &#24;&#40;&#5E;&#7E;&#21;&#2A;'ed it up.  If you get my drift...  :) :) :)

Nit: ITYM &#x24;&#x40;&#x5E; etc. 

<ObTopicNotReally> and no you can't use &16#2E;  ;-) </>

> 
> I've felt for a long time that every time Google improves Google Groups, they make it worse.
> 
including making your above a single much-too-long line, without even
the fig leaf of format=flowed. I manually broke for the reply, because
Agent (arguably conformingly but inconveniently) won't break
reply-quoted lines. I don't know if you can enter line breaks manually
but I suggest you try if GG continues to do this.

(Or get a real newsreader, unless you can't.)

Re: What would you like in Ada202X?

[Simon Wright]

David Thompson <dave.thompson2@verizon.net> writes:

> I manually broke for the reply, because Agent (arguably conformingly
> but inconveniently) won't break reply-quoted lines.

This is a thing that Emacs Gnus does really well (using M-q).

Re: What would you like in Ada202X?

[Georg Bauhaus]

On 19.07.12 20:22, Simon Wright wrote:
> David Thompson <dave.thompson2@verizon.net> writes:
>
>> I manually broke for the reply, because Agent (arguably conformingly
>> but inconveniently) won't break reply-quoted lines.
>
> This is a thing that Emacs Gnus does really well (using M-q).

What if a Greasemonkey Javascript could do line breaking?

Re: What would you like in Ada202X?

[Ada novice]

I would like to see some Ada fft maths functions. The use of fft is rather pervasive in many scientific fields. Yes one can always code the fft function as here:

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

but since efficient algorithms exist for fft computation, I believe that the above code is not computationally effective.

One can also get an Ada binding to some fft code written in another language as here:

http://fftwada.sourceforge.net/

but why not a native fft Ada function in the first place?

YC