Your wish list for Ada 202X

Your wish list for Ada 202X

[Stoik]

I think that even a casual user of Ada should be able to influence somehow the new version of Ada. I wonder what is high on your list of wishes for Ada 202X?
I suspect many of the proposals could be tested in GNAT before being introduced (or rejected) in the new version. One could add a switch to GNAT indicating that we want to use some of the experimental features.

Re: Your wish list for Ada 202X

[Simon Wright]

Stoik <staszek.goldstein@gmail.com> writes:

> One could add a switch to GNAT indicating that we want to use some of
> the experimental features.

I'm pretty sure it is -gnatX. What, if anything, it enables at the
moment I don't know ..

Re: Your wish list for Ada 202X

[Shark8]

On 25-Mar-14 14:41, Stoik wrote:
> I think that even a casual user of Ada should be able to influence somehow  the new version of Ada. I wonder what is high on your list of wishes 
for Ada
> 202X?
>
> I suspect many of the proposals could be tested in GNAT before being
> introduced (or rejected) in the new version. One could add a switch to
> GNAT indicating that we want to use some of the experimental features.

(1)
I think we should look at simplifying the standard packages.

Consider also the [[wide_]wide_]string packages and the relationship to 
[[wide_]wide_]character -- it would be very nice (as well as aiding 
maintainability) to have the *_String [and character-handling] packages 
be generics instantiated on the proper Character type.

(2)
I also think that the INTERFACE construct could be more beneficial 
introducing properties (virtual fields; possibly with IN / IN OUT / OUT 
modes) and a way to delegate them... Delphi has an IMPLEMENTS keyword 
which allows you to have a field (or property) that implements the maned 
interface ( see: http://stackoverflow.com/a/6067165 ) -- IIRC you can 
also do "partial delegation" and resolution so that, given two 
INTERFACEs I1 and I2 which both have "function Count( Input : I* ) : 
Integer" and you could use both w/o any great gymnastics.

type
  TObj = Class(I1, I2)
   private
     FCount : Integer;              {Internal count for something.}
     FItems : Array of TSomeObject; {Dynamically sized array.}
     function Get_length : Integer implements I2.Count;
   public
     {This treats the read of count as a function-call.}
     property Count   : Integer read FCount implements I1.Count;
  end; {TObj}

{...}

function TObj.Get_length : Integer;
begin
   Get_Length := Length( FItems );
end;


(3)
Third, I think it would be good to extend the FOR loop once again; this 
time giving access to the cursor involved, this way the index can be 
retrieved in the new-style loops.

-- Given Table : array (1..20, 1..20) of Positive we wish to populate it
-- with Pascal's Triangle.
For Element of Table loop
   -- We remember that to construct the triangle there are two rules:
   -- 1) If the row or the column is 1, then the value of the cell is 1,
   -- 2) Otherwise, the value is the sum of the its predecessor in the
   --    row and its predecessor in the column.
   Element:= (if Element'Index(1) = 1 or Element'Index(2) = 1 then
              else
                     Table(Element'Index(1)-1,Element'Index(2)  )
                   + Table(Element'Index(1)  ,Element'Index(2)-1)
             );
end loop;

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Tue, 25 Mar 2014 14:41:16 -0700 (PDT), Stoik wrote:

> I think that even a casual user of Ada should be able to influence somehow
> the new version of Ada. I wonder what is high on your list of wishes for
> Ada 202X?

No. Casual users have casual ideas. Ada already suffered too much from
casual additions.

> I suspect many of the proposals could be tested in GNAT before being
> introduced (or rejected) in the new version. One could add a switch to
> GNAT indicating that we want to use some of the experimental features.

Yes, an experimental sandbox is a good idea. However, better would be a
compiler from a generalized and simpler language with Ada type system
implemented as a library. Most of Ada complexity is due to irregularities
and weaknesses of its type system.

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

Re: Your wish list for Ada 202X

[J Kimball]

On 03/26/2014 03:17 AM, Dmitry A. Kazakov wrote:
> On Tue, 25 Mar 2014 14:41:16 -0700 (PDT), Stoik wrote:
>
>> I think that even a casual user of Ada should be able to influence somehow
>> the new version of Ada. I wonder what is high on your list of wishes for
>> Ada 202X?
>
> No. Casual users have casual ideas. Ada already suffered too much from
> casual additions.

Casual users may also not be content with the status quo and may be spending their non-casual time keeping up with advances in programming language design that could benefit the language where a non-casual user may not have any additional time—of no fault of his own, of course.

>
>> I suspect many of the proposals could be tested in GNAT before being
>> introduced (or rejected) in the new version. One could add a switch to
>> GNAT indicating that we want to use some of the experimental features.
>
> Yes, an experimental sandbox is a good idea. However, better would be a
> compiler from a generalized and simpler language with Ada type system
> implemented as a library. Most of Ada complexity is due to irregularities
> and weaknesses of its type system.
>

A casual user may avoid Ada, never becoming a non-casual user when he encounters these irregularities becoming disenchanted. The wishlist should include ameliorating these irregularities, strengthen the type system and maybe introduce some of the fancy types that academics are using to enforce correctness.

I have recognized your very conservative approach to changes in Ada over time. Do you just want a language that suits Dmitry only or something that may grow interest in the language? Of all the sugar that was added in 2012, not much of it is going to convince anyone to pick up Ada.

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Wed, 26 Mar 2014 04:02:07 -0500, J Kimball wrote:

> On 03/26/2014 03:17 AM, Dmitry A. Kazakov wrote:
>> On Tue, 25 Mar 2014 14:41:16 -0700 (PDT), Stoik wrote:
>>
>>> I think that even a casual user of Ada should be able to influence somehow
>>> the new version of Ada. I wonder what is high on your list of wishes for
>>> Ada 202X?
>>
>> No. Casual users have casual ideas. Ada already suffered too much from
>> casual additions.
> 
> Casual users may also not be content with the status quo and may be
> spending their non-casual time keeping up with advances in programming
> language design that could benefit the language where a non-casual user
> may not have any additional time—of no fault of his own, of course.

Casual language/compiler designers? I don't believe such exist.

>>> I suspect many of the proposals could be tested in GNAT before being
>>> introduced (or rejected) in the new version. One could add a switch to
>>> GNAT indicating that we want to use some of the experimental features.
>>
>> Yes, an experimental sandbox is a good idea. However, better would be a
>> compiler from a generalized and simpler language with Ada type system
>> implemented as a library. Most of Ada complexity is due to irregularities
>> and weaknesses of its type system.
> 
> A casual user may avoid Ada, never becoming a non-casual user when he
> encounters these irregularities becoming disenchanted.

Language preferences is a mystery. I don't think people choose languages
very rationally, even those who chose Ada.

> The wishlist should
> include ameliorating these irregularities, strengthen the type system and
> maybe introduce some of the fancy types that academics are using to
> enforce correctness.

Yes, that is on the top of my personal list. However people understand
different things under correctness. For example to me dynamic checks are
opposite to correctness. How do you reconcile wishes to expand dynamic
checks with wishes removing those altogether, in one list?

> I have recognized your very conservative approach to changes in Ada over
> time.

I thought I was considered a rabid radical here. My approach would be to
rework language foundations keeping the facade intact. Is that
conservative?

> Do you just want a language that suits Dmitry only or something that
> may grow interest in the language?

I am software designer, I am interested in a language that helps me with my
work.

Popularity is another thing. If you believe that Ada could gain popularity
by making the language worse. Well, it is true that only a very bad
language could become very popular. But poor quality alone does not
guaranty the result. For example, Ada 2012 became definitely worse but
barely more popular. It was not ingeniously bad.

> Of all the sugar that was added in
> 2012, not much of it is going to convince anyone to pick up Ada.

Yep, nobody is satisfied.

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

Re: Your wish list for Ada 202X

[Marius Amado-Alves]

"only a very bad language could become very popular" (Kasakov)

You gotta love Kasakov's truisms!
FWIW I disagree that Ada 2012 is worse, I find a few 2012 things useful.
But I agree that Ada "development" should stop.
So my whish for Ada 202X is: no Ada 202X, please.
It's time for a new, good, unpopular language.

Re: Your wish list for Ada 202X

[G.B.]

On 26.03.14 10:02, J Kimball wrote:
> On 03/26/2014 03:17 AM, Dmitry A. Kazakov wrote:
>> On Tue, 25 Mar 2014 14:41:16 -0700 (PDT), Stoik wrote:
>>
>>> I think that even a casual user of Ada should be able to influence
>>> somehow
>>> the new version of Ada. I wonder what is high on your list of wishes for
>>> Ada 202X?
>>
>> No. Casual users have casual ideas. Ada already suffered too much from
>> casual additions.
>
> Casual users may also not be content with the status quo and may be
> spending their non-casual time keeping up with advances in programming
> language design that could benefit the language where a non-casual user
> may not have any additional time—of no fault of his own, of course.


Slight problem with Ada users who would be triggering language design.
Consider these as premises:

1 - Industries depending on Ada consist of competitors.
2 - Language design requires co-operation of those in need of
     a common language.
3 - Commercial Ada support is considered good; they do take care
     of customers (while also steering language design...)
4 - Time and money is usually spent on projects and support.

Conclusion: Industry, insofar as it depends on Ada, is a lame duck:

If programmers (1) want a language feature, and they get past
controlling (4), they first talk to (3), and (3), I imagine, will
then have almost full control of the language situation.

Re: Your wish list for Ada 202X

[G.B.]

On 26.03.14 11:30, Marius Amado-Alves wrote:
> So my whish for Ada 202X is: no Ada 202X, please.
> It's time for a new, good, unpopular language.

Parallel loops are on the way, I guess, so something is
to come.

Other than these, language profiles can help, too!

Some examples:
- no public "access" (subp-pointers excluded?)
- no anonymous types,
- tasking restrictions less severe that RavenSPARK,
...

Re: Your wish list for Ada 202X

[Anh Vo]

On Wednesday, March 26, 2014 1:17:39 AM UTC-7, Dmitry A. Kazakov wrote:
> On Tue, 25 Mar 2014 14:41:16 -0700 (PDT), Stoik wrote:
> 
> > I suspect many of the proposals could be tested in GNAT before being 
> > introduced (or rejected) in the new version. One could add a switch to 
> > GNAT indicating that we want to use some of the experimental features.
> 
> Yes, an experimental sandbox is a good idea. However, better would be a 
> compiler from a generalized and simpler language with Ada type system 
> implemented as a library. Most of Ada complexity is due to irregularities 
> and weaknesses of its type system.

You sound like most Ada type systems are week. It is obviously not true. After all, one of strength of Ada is its types/subtypes. Indeed, I would not choose Ada 25 years ago if it is not the case.

A. Vo  

Re: Your wish list for Ada 202X

[Stoik]

W dniu środa, 26 marca 2014 09:17:39 UTC+1 użytkownik Dmitry A. Kazakov napisał:
> On Tue, 25 Mar 2014 14:41:16 -0700 (PDT), Stoik wrote:
> 
> 
> 
> > I think that even a casual user of Ada should be able to influence somehow
> 
> > the new version of Ada. I wonder what is high on your list of wishes for
> 
> > Ada 202X?
> 
> 
> 
> No. Casual users have casual ideas. Ada already suffered too much from
> 
> casual additions.
> 

I strongly disagree with the view. The casual additions to Ada were not from causal users, but from language designers. The casual ideas of casual users are very easy to reject or just disregard. On the other hand, the bunch of people that now influence the development of Ada is quite small, and if something is proposed, the discussion is mainly on problems that such an addition can cause. 

Ada, as a language, is now half-dead. There is just one compiler on the market, and the fact that some small company wants to use the language is already big news. It is still used as the first programming language at some universities, 
but it is more and more difficult to substantiate its use. The situation will not improve if the language is frozen. Although Ada has a lot of nice features and is still better constructed than some of the more popular languages, there is a lot that causes frustration for the users. I will comment on it more later on.

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Wed, 26 Mar 2014 09:01:56 -0700 (PDT), Anh Vo wrote:

> On Wednesday, March 26, 2014 1:17:39 AM UTC-7, Dmitry A. Kazakov wrote:
>> On Tue, 25 Mar 2014 14:41:16 -0700 (PDT), Stoik wrote:
>> 
>>> I suspect many of the proposals could be tested in GNAT before being 
>>> introduced (or rejected) in the new version. One could add a switch to 
>>> GNAT indicating that we want to use some of the experimental features.
>> 
>> Yes, an experimental sandbox is a good idea. However, better would be a 
>> compiler from a generalized and simpler language with Ada type system 
>> implemented as a library. Most of Ada complexity is due to irregularities 
>> and weaknesses of its type system.
> 
> You sound like most Ada type systems are week. It is obviously not true.

I didn't mean weakly typing, though Ada's type system has some problems
with that as well. Main weakness of Ada type system is lack of abstraction
mechanisms which leads to multiplying special cases increasing language
complexity incredibly.

> After all, one of strength of Ada is its types/subtypes. Indeed, I would
> not choose Ada 25 years ago if it is not the case.

Now is 2014 and there is still no ad-hoc subtypes and supertypes. Subtypes
are still tightly coupled to the type representation. There is still no
procedural [sub/super]types. Initialization/finalization is still a mess.
Renaming to a subtype is still broken and so on and so forth.

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

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Wed, 26 Mar 2014 09:17:04 -0700 (PDT), Stoik wrote:

> W dniu środa, 26 marca 2014 09:17:39 UTC+1 użytkownik Dmitry A. Kazakov napisał:
>> On Tue, 25 Mar 2014 14:41:16 -0700 (PDT), Stoik wrote:
>> 
>>> I think that even a casual user of Ada should be able to influence somehow
>>> the new version of Ada. I wonder what is high on your list of wishes for
>>> Ada 202X?
>> 
>> No. Casual users have casual ideas. Ada already suffered too much from
>> casual additions.
> 
> I strongly disagree with the view. The casual additions to Ada were not
> from causal users, but from language designers. The casual ideas of casual
> users are very easy to reject or just disregard. On the other hand, the
> bunch of people that now influence the development of Ada is quite small,
> and if something is proposed, the discussion is mainly on problems that
> such an addition can cause. 

And the idea is to make it even more casual?
 
> Ada, as a language, is now half-dead. There is just one compiler on the
> market, and the fact that some small company wants to use the language is
> already big news. It is still used as the first programming language at
> some universities, 
> but it is more and more difficult to substantiate its use. The situation
> will not improve if the language is frozen.

It will not. But that does not imply that erratic changes would. IMO, Ada
2005 and 2012 tried exactly this - casual changes, borrowing [false]
concepts from other [poorly designed] languages.

> Although Ada has a lot of nice
> features and is still better constructed than some of the more popular
> languages, there is a lot that causes frustration for the users.

Yes. But people disagree on *what* need to be done and *how* to get there. 

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

Re: Your wish list for Ada 202X

[G.B.]

On 26.03.14 17:17, Stoik wrote:
> There is just one compiler on the market

Do you have some numbers? I understand that besides
GNAT, both ICC and Rational Apex (Atego) support Ada 2005
and there are some supported compilers for Ada 95+, from others.

And, of course, what does the number 1 mean?
There aren't that many different C compilers
in use in the embedded market AFAICT. There is just
one C# compiler AFAIK. In comparison, then,
having just a few Ada compilers seems quite enough.

IIRC, programs for VxWorks don't even need an Ada
runtime to provide tasking support. Systems like these
provide an opportunity for another profile, one that
should make upgrading compilers easier.

Re: Your wish list for Ada 202X

[Simon Wright]

"G.B." <rm-dash-bau-haus@dash.futureapps.de> writes:

> IIRC, programs for VxWorks don't even need an Ada runtime to provide
> tasking support. Systems like these provide an opportunity for another
> profile, one that should make upgrading compilers easier.

But they do need one for Ada tasking support!

Tasking on VxWorks using Ada bindings of the VxWorks tasking primitives
would have little if any benefit over the C version. No protected types
for a start! No rendezvous!

Re: Your wish list for Ada 202X

[Georg Bauhaus]

On 26/03/14 19:47, Simon Wright wrote:
> "G.B." <rm-dash-bau-haus@dash.futureapps.de> writes:
>
>> IIRC, programs for VxWorks don't even need an Ada runtime to provide
>> tasking support. Systems like these provide an opportunity for another
>> profile, one that should make upgrading compilers easier.
>
> But they do need one for Ada tasking support!
>
> Tasking on VxWorks using Ada bindings of the VxWorks tasking primitives
> would have little if any benefit over the C version. No protected types
> for a start! No rendezvous!

You are right, I was actually thinking of “no_task_types”.
What I remembered was a talk by someone whose team did a VxWorks
project for a British railroad something, explaining
how they would wrap a process in a "VxWorks procedure",
written in Ada. So, there would be protected types, I guess.

Nevertheless, there is much that makes Ada different solely
because of its fundamental type system:
The most recent MS-Word/Outlook bug is another instance of
errors that keep being caused by, as the CVE entry explains,
a language that has no bounds checking for indexing arrays.

Side note: SPARK rests on top of things expressed
and expressible in Ada in its (almost) unique ways,
in the small, and without pointers.

An Ada profile for even sequential programs only is worth money.

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Shark8" <OneWingedShark@gmail.com> wrote in message 
news:tvtYu.83108$tD4.27538@fx25.iad...
> On 25-Mar-14 14:41, Stoik wrote:
>> I think that even a casual user of Ada should be able to influence 
>> somehow  the new
>> version of Ada. I wonder what is high on your list of wishes for Ada 
>> 202X?
...
> (1)
> I think we should look at simplifying the standard packages.
>
> Consider also the [[wide_]wide_]string packages and the relationship to 
> [[wide_]wide_]character -- it would be very nice (as well as aiding 
> maintainability) to have the *_String [and character-handling] packages be 
> generics instantiated on the proper Character type.

I agree that this is an area that needs looking at, but I don't think using 
more generics will provide anything useable. The problem, as Dmitry likes to 
say, is that the representation and semantics of a string are intertwined, 
and those have to be separated in order to make a sensible string type 
system.

I've played with some ideas based on an abstract Root_String'Class, and 
pretty much everything necessary can be done with existing Ada 2012 
features, and the few things that can't have a fairly obvious language 
feature that could be defined to provide them (for instance, a mechanism to 
support string literals).

I think the problem is mainly going to be political rather than technical. 
The solution requires defining a large set of new packages that echo 
functionality already in the language, and that would not be used by the 
sorts of safety-critical applications that the paying customers use. 
(They're not using Text_IO or Unbounded_Strings or Directories or ...). 
That's going to make changes in this area a tough sell, I fear. Hope I'm 
wrong.

                                          Randy.

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Stoik" <staszek.goldstein@gmail.com> wrote in message 
news:ea073fca-c607-476c-8c0b-81e2da1686b1@googlegroups.com...
...
> Although Ada has a lot of nice features and is still better constructed 
> than
> some of the more popular languages, there is a lot that causes frustration
> for the users. I will comment on it more later on.

Commenting here is precisely the problem. Most of the user contacts that the 
ARG has is third-hand at best. (Combating that is one of the reasons I hang 
out here.) We really don't have the clear of an idea of what other Ada users 
want. I know I draw on my own experience far more than probably is healthy.

Moreover, we've been asking for years for users to show us the problems that 
they cannot solve with Ada (now Ada 2012), so that we can look at possible 
solutions. That's one of the major purposes of the Ada-Comment mailing list. 
A few people do that, but it's not many. You don't have to be a language 
designer to do that; indeed, we'd rather you didn't try to invent language 
features to solve the problem, since those ideas often obscure the actual 
problem. Of course, we might determine that Ada 2012 already can solve the 
problem sensibly - or that we don't consider it important enough - but 
problems that we don't hear about have a near 100% chance of not being 
addressed.

This is probably a good time to remind everyone that the Ada-Comment mailing 
list is open to everyone. It's for comments and discussion on the Ada 
language and it's Standard, not particular implementations of Ada. (Leave 
your gripes about AdaCore here, please. :-) You can find instructions about 
joining the list at 
http://www.adaic.org/resources/add_content/standards/articles/comment.html.

Of course, that is not to say that discussion here isn't useful when one 
wants to know if they are alone with a concern or the like. But please don't 
assume that just because something is said here it is going to get back to 
the ARG and have an impact on future language standards. (Occassionally, 
someone has taken a discussion here back to Ada-Comment, but no one ought to 
assume that will happen. If you really care, do it yourself!)

                                    Randy Brukardt, ARG Editor.

Re: Your wish list for Ada 202X

[Simon Clubley]

On 2014-03-26, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Wed, 26 Mar 2014 04:02:07 -0500, J Kimball wrote:
>
>> On 03/26/2014 03:17 AM, Dmitry A. Kazakov wrote:
>>> On Tue, 25 Mar 2014 14:41:16 -0700 (PDT), Stoik wrote:
>>>
>>>> I think that even a casual user of Ada should be able to influence somehow
>>>> the new version of Ada. I wonder what is high on your list of wishes for
>>>> Ada 202X?
>>>
>>> No. Casual users have casual ideas. Ada already suffered too much from
>>> casual additions.
>> 
>> Casual users may also not be content with the status quo and may be
>> spending their non-casual time keeping up with advances in programming
>> language design that could benefit the language where a non-casual user
>> may not have any additional time¡Xof no fault of his own, of course.
>
> Casual language/compiler designers? I don't believe such exist.
>

And once again Dmitry, you are projecting _your_ experiences onto
others. :-)

I for once have designed and implemented compilers and interpreters in
the past and the only reason I did it was for fun.

(Hand crafted LL(1) recursive descent parsers/grammars if you are
interested.)

>> I have recognized your very conservative approach to changes in Ada over
>> time.
>
> I thought I was considered a rabid radical here. My approach would be to
> rework language foundations keeping the facade intact. Is that
> conservative?
>

I think it's more the case that you come across as thinking that the
world as experienced by Dmitry is the only world that exists. :-)

I'll give you a example: _every_ time someone talks about getting data
into a embedded board, you immediately assume they are going to use a
ADC interface to accomplish the task (and start to criticise them or offer
opinions based on that), even though you are told that many times people
simply use a binary (low/high) purely digital interface to read data.

You clearly use ADC interfaces a lot, but that doesn't mean it's the
only possible way to read data into a embedded board.

You also tend to be dismissive of approaches outside of your experience.
For example, you seem to be very dismissive of the low cost ARM embedded
boards as being toys (or similar wording) and cannot seem to see their
value in some situations because you use big heavy duty mains operated
equipment in your job.

Simon.

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

Re: Your wish list for Ada 202X

[Simon Clubley]

On 2014-03-26, J Kimball <spam@example.com> wrote:
>
> A casual user may avoid Ada, never becoming a non-casual user when he
> encounters these irregularities becoming disenchanted. The wishlist should
> include ameliorating these irregularities, strengthen the type system and
> maybe introduce some of the fancy types that academics are using to enforce
> correctness.
>

Do you know of any online research papers covering the academic research
on these new kinds of types ? It's something I would like to do a bit of
reading about to see if there's anything of practical interest coming
out of this academic research.

Thanks,

Simon.

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

Re: Your wish list for Ada 202X

[J Kimball]

On 03/26/2014 04:06 PM, Randy Brukardt wrote:
> "Stoik" <staszek.goldstein@gmail.com> wrote in message
> news:ea073fca-c607-476c-8c0b-81e2da1686b1@googlegroups.com...
> ....
>> Although Ada has a lot of nice features and is still better constructed
>> than
>> some of the more popular languages, there is a lot that causes frustration
>> for the users. I will comment on it more later on.
>
> Commenting here is precisely the problem. Most of the user contacts that the
> ARG has is third-hand at best. (Combating that is one of the reasons I hang
> out here.) We really don't have the clear of an idea of what other Ada users
> want. I know I draw on my own experience far more than probably is healthy.
>
> Moreover, we've been asking for years for users to show us the problems that
> they cannot solve with Ada (now Ada 2012), so that we can look at possible
> solutions. That's one of the major purposes of the Ada-Comment mailing list.
> A few people do that, but it's not many. You don't have to be a language
> designer to do that; indeed, we'd rather you didn't try to invent language
> features to solve the problem, since those ideas often obscure the actual
> problem. Of course, we might determine that Ada 2012 already can solve the
> problem sensibly - or that we don't consider it important enough - but
> problems that we don't hear about have a near 100% chance of not being
> addressed.
>
> This is probably a good time to remind everyone that the Ada-Comment mailing
> list is open to everyone. It's for comments and discussion on the Ada
> language and it's Standard, not particular implementations of Ada. (Leave
> your gripes about AdaCore here, please. :-) You can find instructions about
> joining the list at
> http://www.adaic.org/resources/add_content/standards/articles/comment.html.
>
> Of course, that is not to say that discussion here isn't useful when one
> wants to know if they are alone with a concern or the like. But please don't
> assume that just because something is said here it is going to get back to
> the ARG and have an impact on future language standards. (Occassionally,
> someone has taken a discussion here back to Ada-Comment, but no one ought to
> assume that will happen. If you really care, do it yourself!)
>
>                                      Randy Brukardt, ARG Editor.
>
>

That's great. I know there are a lot of ideas out there, but the nebulous task of communicating it to ARG has prohibited moving on them.

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Wed, 26 Mar 2014 16:06:18 -0500, Randy Brukardt wrote:

> Commenting here is precisely the problem.

But people don't post/read AI and Ada-Comment preferring c.l.a because
Usenet group is more comfortable and easier to use for discussions and
informal exchange.

If you want to make Ada-Comment more vital move it to Usenet, Web group
etc. Though, isn't it so that Ada-Comment and AI are meant to be
unwelcoming in order to filter traffic?

Shouldn't there be forums to discuss technical issues separately from
fundamental language concepts, ignoring distracting technicalities?

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

Re: Your wish list for Ada 202X

[Shark8]

On 26-Mar-14 13:41, Randy Brukardt wrote:
> "Shark8" <OneWingedShark@gmail.com> wrote in message
> news:tvtYu.83108$tD4.27538@fx25.iad...
>> On 25-Mar-14 14:41, Stoik wrote:
>>> I think that even a casual user of Ada should be able to influence
>>> somehow  the new
>>> version of Ada. I wonder what is high on your list of wishes for Ada
>>> 202X?
> ...
>> (1)
>> I think we should look at simplifying the standard packages.
>>
>> Consider also the [[wide_]wide_]string packages and the relationship to
>> [[wide_]wide_]character -- it would be very nice (as well as aiding
>> maintainability) to have the *_String [and character-handling] packages be
>> generics instantiated on the proper Character type.
>
> I agree that this is an area that needs looking at, but I don't think using
> more generics will provide anything useable. The problem, as Dmitry likes to
> say, is that the representation and semantics of a string are intertwined,
> and those have to be separated in order to make a sensible string type
> system.

Hm, not even with the new incomplete-type allowances for generics?
Perhaps a "abstract interface" / "abstract type" could be made where, 
you can sever the representation and semantics?

> I've played with some ideas based on an abstract Root_String'Class, and
> pretty much everything necessary can be done with existing Ada 2012
> features, and the few things that can't have a fairly obvious language
> feature that could be defined to provide them (for instance, a mechanism to
> support string literals).

Hm, Really? Care to share your findings?

> I think the problem is mainly going to be political rather than technical.
> The solution requires defining a large set of new packages that echo
> functionality already in the language, and that would not be used by the
> sorts of safety-critical applications that the paying customers use.
> (They're not using Text_IO or Unbounded_Strings or Directories or ...).
> That's going to make changes in this area a tough sell, I fear. Hope I'm
> wrong.

That's rather sad; I'd hope for Ada to be a technically superior 
language -- IMO, it already is in several respects... but that's no 
reason to slack off and not strive for higher quality.

------------
Any comment on idea #2 or #3?

Re: Your wish list for Ada 202X

[Georg Bauhaus]

On 27/03/14 09:26, Dmitry A. Kazakov wrote:
> Though, isn't it so that Ada-Comment and AI are meant to be
> unwelcoming in order to filter traffic?

comp.lang.ada could act as a filter and also as a place to get
feedback first, before suggesting something on Ada-Comment.

Since the Ada situation is such that one Ada vendor _is_ working
on integrating Ada and Parasail, I imagine that not every
suggestion WRT Ada is scrutinized with the help of the backwards
compatibility sledgehammer only.

Let me try one example that is about object construction:

(a)compilers diagnose when a variable is used before
     initialization;

(b) limited (derived) types do not have certain constructors
     that work up the derivation hierarchy;

(c) construction then requires C-style discipline lest it
     be forgotten, possibly leading to erroneous execution.

Then, ignoring the foreseeable backwards compatibility sledgehammer
for the moment; also ignoring the C-style questionimg about how
this is a real, pressing need of competent programmers blah-blah,
I'll ask:

Can there be a language rule that requires detection of
initialization of all parts of said object before use?

Is it worth it?

Is it simple?

Is it elegant?

Is it explicit enough?

Re: Your wish list for Ada 202X

[Jacob Sparre Andersen]

G.B. <rm-dash-bau-haus@dash.futureapps.de> writes:

> On 26.03.14 17:17, Stoik wrote:
>> There is just one compiler on the market
>
> Do you have some numbers? I understand that besides GNAT, both ICC and
> Rational Apex (Atego) support Ada 2005 and there are some supported
> compilers for Ada 95+, from others.

Stoik exaggerates the number of Ada compilers slightly...

At the moment there are no Ada (2012) compilers available on the market.
GNAT is marketed as an Ada 2012 compiler, but they haven't managed to
get their handling of synchronized interfaces (from Ada 2005) working
yet, so I think calling it an Ada compiler is cheating.  Calling it an
Ada 95 compiler is fair though.

As there is no ACATS for Ada (2012) or Ada 2005, it is difficult for us
customers to be sure of the state of the compilers we have to choose
between.

My three big wishes for Ada are that:

1) ACATS is updated to match the current Ada standard.
2) Any new standard is published _with_ a matching edition of ACATS.
3) The ARG establishes a process for expanding ACATS with user-provided examples.

Greetings,

Jacob
-- 
Black Hole: Where the universe made a Divide by Zero.

Re: Your wish list for Ada 202X

[Dan'l Miller]

On Wednesday, March 26, 2014 12:04:44 PM UTC-5, Dmitry A. Kazakov wrote:
> 
> Now is 2014 and there is still no ad-hoc subtypes and supertypes. Subtypes
> are still tightly coupled to the type representation. There is still no
> procedural [sub/super]types. Initialization/finalization is still a mess.
> Renaming to a subtype is still broken and so on and so forth.

Dmitry, for each of these 4 negatively-bashing topics above, please provide positively-enlightening details (e.g., revealing examples with lucid explanation) of precisely what is wrong with the following as well as the desired state that is impossible in Ada 2012 as defined:
1) how subtypes could be less-tightly coupled to the type [without damaging the rest of Ada];
2) how procedural sub-/supertypes would differ from today's runtime polymorphism of subroutines in subtypes overriding same-named subroutines in supertypes [without damaging the rest of Ada];
3) precisely in what ways could initialization & finalization be changed to dismantle the mess [without damaging the rest of Ada];
4) how renaming to a subtype a subtype could be fixed [without damaging the rest of Ada] (or equivalently:  what are your refutations to the ARG's current inhibition of renaming to a subtype, i.e., where did the ARG go excessively restrictive in their thinking regarding renaming to a subtype).

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Thu, 27 Mar 2014 11:54:24 +0100, Georg Bauhaus wrote:

> Can there be a language rule that requires detection of
> initialization of all parts of said object before use?

Yes

> Is it worth it?

Yes
 
> Is it simple?

Yes, because it would be a part of universal construction model. You place
no-default-initialization in the root type, that is all. Compare it to
(<>).

> Is it elegant?

Yes

> Is it explicit enough?

It is to late to make not initialized object syntactically more visible
than they are.

P.S. Most problems are intractable if you try to solve them by means of
inference of the programmer's intent. Don't do that. Let the programmer
manifest his will, like with initialization. This is why explicit
interfaces are really important for making the language simpler.

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

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Thu, 27 Mar 2014 08:03:54 -0700 (PDT), Dan'l Miller wrote:

> On Wednesday, March 26, 2014 12:04:44 PM UTC-5, Dmitry A. Kazakov wrote:
>> 
>> Now is 2014 and there is still no ad-hoc subtypes and supertypes. Subtypes
>> are still tightly coupled to the type representation. There is still no
>> procedural [sub/super]types. Initialization/finalization is still a mess.
>> Renaming to a subtype is still broken and so on and so forth.
> 
> Dmitry, for each of these 4 negatively-bashing topics above, please
> provide positively-enlightening details (e.g., revealing examples with
> lucid explanation) of precisely what is wrong with the following as well
> as the desired state that is impossible in Ada 2012 as defined:

I am not a member of ARG. Even if I were, it would be pointless to make any
language proposals in c.l.a.

> 1) how subtypes could be less-tightly coupled to the type [without
> damaging the rest of Ada];

Every aspect of a subtype must be formalized as an interface open to user
implementation. Existing constructs must be treated as shortcuts providing
predefined implementations of these interfaces.

> 2) how procedural sub-/supertypes would differ from today's runtime
> polymorphism of subroutines in subtypes overriding same-named subroutines
> in supertypes [without damaging the rest of Ada];

They will not be access types. Which would eliminate need of accessibility
checks in downward closures.

Relation to dynamic polymorphism is not direct. One could consider classes
of subprograms as polymorphic bodies with some argument type varying across
the class. I didn't think much about it.

> 3) precisely in what ways could initialization & finalization be changed
> to dismantle the mess [without damaging the rest of Ada];

1. Every type must support user-defined initialization (with arguments) and
finalization;
2. This includes class-wide types;
3. User-defined initialization/finalization must be enforced;
4. Initialization roll-back (on exception) must be supported.

> 4) how renaming to a subtype a subtype could be fixed [without damaging
> the rest of Ada] (or equivalently:  what are your refutations to the ARG's
> current inhibition of renaming to a subtype, i.e., where did the ARG go
> excessively restrictive in their thinking regarding renaming to a
> subtype).

Renaming must either respect declared constraints and bounds [including
bounds shifts] or else reject them. It is intolerable that these are simply
ignored.

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

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:o55d8h8hmzjb.591frxr75ryx$.dlg@40tude.net...
> On Wed, 26 Mar 2014 16:06:18 -0500, Randy Brukardt wrote:
>
>> Commenting here is precisely the problem.
>
> But people don't post/read AI and Ada-Comment preferring c.l.a because
> Usenet group is more comfortable and easier to use for discussions and
> informal exchange.
>
> If you want to make Ada-Comment more vital move it to Usenet, Web group
> etc. Though, isn't it so that Ada-Comment and AI are meant to be
> unwelcoming in order to filter traffic?

I wouldn't characterize it as "meant to be unwelcoming"; after all, it was 
pretty much state-of-art when it originally was defined (in the early 1990s, 
for Ada 9x). It just hasn't changed much since then (last major change was 
in 1998, when I took over hosting it). The AI mechanism is even older; it's 
pretty similar to the mechanism used during Ada 83, so it dates back to at 
least the mid-1980s. The only major change there is the online formatted 
access to them (I added that a few years back), and as that is done by 
automatically adding formatting to plain text documents, it's not perfect.

But it is true that we don't want lots of chit-chat on Ada-Comment. 
Everything said there goes into the permanent record somewhere, so off-topic 
stuff would become a problem. (That's the major reason that I still file 
these messages by hand; it's hard to imagine an automated system that could 
do as good a job of putting messages where they belong. We also do a level 
of triage on the comments, putting queries that are adequately answered 
on-line into ACs where they don't clutter the ARG's agenda. [Originally, 
everything posted to Ada-Comment had to be handled as an AI, which meant 
there was always a bunch of junk AIs on the agenda -- a lousy use of limited 
resources.)

> Shouldn't there be forums to discuss technical issues separately from
> fundamental language concepts, ignoring distracting technicalities?

I'm not sure how one could "discuss technical issues" without considering 
"distracting technicalities". That's kind of the point, after all -- not 
everything that makes sense in the abstract makes sense for Ada because it 
has to fit into the existing type system somehow -- even ignoring absolute 
compatibility. For instance, a lot ideas don't make sense for by-copy types, 
or by-reference types, or discriminated types -- and those things are surely 
going to exist in a future Ada.

We've occassionally talked about using other sorts of forums, but that tends 
to conflict with the mandate for a permanent record that's not tied to a 
particular technology [as technologies disappear over time -- but we still 
go back into the archives to understand old issues from time-to-time (it's 
too bad to we don't have the Ada 83 discussions on line, although apparently 
they're in a series of boxes in John Goodenough's office -- on printouts --  
they're kinda hard to search).] For instance, a wiki might make sense for 
some tasks, but it doesn't appear that there would be any sensible way to 
extract the history from them for long-term use. You can do it using the 
platform, but when it goes away (and all of these things will go away 
someday, especially cloud platforms where you're dependent on others to keep 
it functioning) all of that is lost.

                                        Randy.

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Shark8" <OneWingedShark@gmail.com> wrote in message 
news:x9RYu.3020$XJ3.767@fx09.iad...
> On 26-Mar-14 13:41, Randy Brukardt wrote:
...
>> I've played with some ideas based on an abstract Root_String'Class, and
>> pretty much everything necessary can be done with existing Ada 2012
>> features, and the few things that can't have a fairly obvious language
>> feature that could be defined to provide them (for instance, a mechanism 
>> to
>> support string literals).
>
> Hm, Really? Care to share your findings?

Of course really. The rough sketch is in the !discussion of AI12-0021-1. 
Please note that we've never discussed this AI within the ARG, so I might be 
the only one interested in persuing this idea. I've fleshed it out further 
mentally; in particular, one could imagine supporting conversions through a 
common type (in this case Wide_Wide_String).

The primary "problem" is that in this model, most strings become tagged and 
communicate using Wide_Wide_Character and Wide_Wide_String. That probably 
seems more inefficient than it actually is (after all, Unbounded_Strings are 
already tagged -- controlled, actually -- and this couldn't be less 
efficient than that, so long as the language-defined types stick to single 
inheritance). For the characters, the representation doesn't matter much 
(and on a 32-bit machine, they're all the same performance anyway). So the 
main issue is the cost of converting to-from Wide_Wide_String. Perhaps there 
is some other way to ensure universal convertability which doesn't require 
performance-sapping multiple inheritance or multidispatching.

After all, if storage space is not a concern, Wide_Wide_String is the most 
universal (and efficient) representation. It seems that it makes the most 
sense to do operations in terms of that type and convert for storage --  
since that's what will happen naturally most of the time. (Presuming you're 
not so American-centric that you don't care about anything beyond type 
String. :-)

Anyway, lots more thought needed.

                          Randy.

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Shark8" <OneWingedShark@gmail.com> wrote in message 
news:x9RYu.3020$XJ3.767@fx09.iad...
I seem to have lost the rest of this, here's the reply to the rest:

...
>> I think the problem is mainly going to be political rather than 
>> technical.
>> The solution requires defining a large set of new packages that echo
>> functionality already in the language, and that would not be used by the
>> sorts of safety-critical applications that the paying customers use.
>> (They're not using Text_IO or Unbounded_Strings or Directories or ...).
>> That's going to make changes in this area a tough sell, I fear. Hope I'm
>> wrong.
>
> That's rather sad; I'd hope for Ada to be a technically superior 
> language -- IMO, it already is in several respects... but that's no reason 
> to slack off and not strive for higher quality.

Keep in mind that Standards of all sorts are as much political as technical. 
If there is no political will (as with ASIS), the technical part doesn't 
matter. Most vendors have not had much demand for Wide_Character etc., so 
the interest in it is lukewarm at best. One example: I've never been able to 
convince anyone to write any ACATS tests on internationalization in 
identifiers -- so there are none. (As such, I wouldn't depend on it working 
the same in different compilers.)

> ------------
> Any comment on idea #2 or #3?

#2 looks like lipstick on a pig to me - as you know my thinking on 
interfaces. If we really were going to extend multiple inheritance 
(something I'd personally be against), I'd suggest just allowing it 
everywhere -- in which case abstract types do everything you want and 
interfaces per-se become unnecessary. There are nasty semantic problems with 
that, and it would probably cause serious incompatibilities -- but I see 
little point in duplicating the functionality.

#3 I don't understand. If you want the index/cursor, use that form. If you 
don't need it, then use the object form. I can't see any sensible way of 
using the index/cursor without knowing the type/number of indexes/cursors --  
and if you need to know that, you already know enough to use the 
index/cursor form. We already have attributes and functions so you don't 
need to mention the actual bounds, so I don't see any gain here.

i.e.

    for E of Arr_Obj loop
         E := Arr_Obj(E'Index + 1) + E;
    end loop;

is already assuming a lot about the type and form of the index. Why hide 
that then?

    for I in Arr_Obj'range loop
        Arr_Obj(I) := Arr_Obj(I+1) + Arr_Obj(I);
    end loop;

is a lot clearer as to what's going on. Even better if we adopted the 
in-place add attribute:

    for I in Arr_Obj'range loop
        Arr_Obj(I)'Add (Arr_Obj(I+1));
    end loop;

                                 Randy.

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Jacob Sparre Andersen" <jacob@jacob-sparre.dk> wrote in message 
news:87bnwrn1m9.fsf@adaheads.sparre-andersen.dk...
...
> As there is no ACATS for Ada (2012) or Ada 2005, it is difficult for us
> customers to be sure of the state of the compilers we have to choose
> between.

Huh? ACATS 3.0 for Ada 2005 has been available since 2008. An updated 
version 3.1 was issued in January, for use aftter April 1st. It's not as 
complete as one might like, but it surely exists and tests all of the really 
important new features of Ada 2005.

> My three big wishes for Ada are that:
>
> 1) ACATS is updated to match the current Ada standard.

ACATS 4.0 is under active development and should be released in the next few 
months. I just released the first snapshot last week, see 
http://www.ada-auth.org/acats.html.

> 2) Any new standard is published _with_ a matching edition of ACATS.

That's of course impractical as the same person (that is, me) is responsible 
for both. Finishing up a standard is a full time job. Doing the ACATS 
afterwards works well because it provides me something to do in between 
major Standards work. Else I'd have to get a real job and would most likely 
be unavailable for future work of any kind.

The ARG has a discussion item on the agenda for the next meeting as to 
whether we should require ACATS tests from ARG members, which would 
certainly decrease the time lag. But it also has the possibility of 
preventing a lot of work on the standard, by making it many times more 
difficult for simpler issues. Several ARG members have indicated that they 
have no interest in writing ACATS tests, so we would stand to lose 
participation. (And we need more, not less participation!)

> 3) The ARG establishes a process for expanding ACATS with user-provided 
> examples.

The ACATS has *always* taken user-submitted tests. There are examples in the 
ACATS going back as far as 1990. You can find out about submitting test on 
the user-submitted test page: http://www.ada-auth.org/submit.html. Most the 
tests that I'm using to create ACATS 4.0 are user-submitted.

As far as putting arbitrary user-provided stuff into the ACATS, that's a bad 
idea because it misinterprets the point of the ACATS. The ACATS is intended 
to support FORMAL conformity assessment testing for Ada. It's NOT about 
finding bugs in compilers (although it certainly does do that). ACATS tests 
have to be portable to all reasonable implementations of Ada (or documented 
as to what they don't apply to), they have to include appropriate pass/fail 
information (and be self-checking if executable), and so on. ACATS tests get 
formal maintenance, with a defined dispute procedure and defined change 
mechanism. This could be overwhelmed if lower-quality tests flooded the test 
suite.

That said, it would be great if someone created a lightly-managed repository 
of user-provided examples for Ada. I tried to create such a reposistory back 
in the Ada 9x days, but no one other than me wanted to contribute to it. 
Perhaps some other organization would have better luck.

                        Randy Brukardt, ACAA Technical Agent.

Re: Your wish list for Ada 202X

[Jeffrey Carter]

On 03/27/2014 02:50 PM, Randy Brukardt wrote:
>
> After all, if storage space is not a concern, Wide_Wide_String is the most
> universal (and efficient) representation. It seems that it makes the most
> sense to do operations in terms of that type and convert for storage --
> since that's what will happen naturally most of the time. (Presuming you're
> not so American-centric that you don't care about anything beyond type
> String. :-)

I guess storage space is not a concern for Erlang. The string "ABC" is shorthand 
for the list [65, 66, 67], and apparently each "character" takes 8 bytes: 4 for 
the number, and 4 for the pointer to the next element in the list.

Using 4 bytes for the character is sometimes called support for Unicode.

Why not define Character as 32 bits and get rid of the Wide_ guys?

-- 
Jeff Carter
"My brain hurts!"
Monty Python's Flying Circus
21

Re: Your wish list for Ada 202X

[J-P. Rosen]

Le 27/03/2014 23:50, Randy Brukardt a écrit :
> The ACATS has *always* taken user-submitted tests. There are examples in the 
> ACATS going back as far as 1990. 
Even before, I remember submitting tasking tests in 1984...

-- 
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: Your wish list for Ada 202X

[Shark8]

On 27-Mar-14 15:06, Randy Brukardt wrote:
> #2 looks like lipstick on a pig to me - as you know my thinking on
> interfaces.

Why couldn't it all be done in such a manner as to avoid MI issues? 
Something like what we might use signature-packages for ensuring 
interfaces [functions/procedures] exist for some given type.

EX:
   generic
     Type Element;
     Type Implementation;
     Function Pop (Object : in out Implementation) return Element;
     Procedure Push (Object : in out Implementation; Item : Element);
     -- ...
   package STACK is
     --....
   end STACK;

being essentially the same as

   abstract interface Implementation is private;
     Function Pop (Object : in out Implementation) return Element;
     Procedure Push (Object : in out Implementation; Item : Element);
     -- ...

Though perhaps having a parameter of such an abstract-interface would 
make it prohibitive...

Re: Your wish list for Ada 202X

[Jacob Sparre Andersen]

Randy Brukardt <randy@rrsoftware.com> wrote:

> "Jacob Sparre Andersen" <jacob@jacob-sparre.dk> wrote in message 
> news:87bnwrn1m9.fsf@adaheads.sparre-andersen.dk...
> ...
>> As there is no ACATS for Ada (2012) or Ada 2005, it is difficult for us
>> customers to be sure of the state of the compilers we have to choose
>> between.
>
> Huh? ACATS 3.0 for Ada 2005 has been available since 2008.

Thanks for letting me know.  I don't know how I have managed to miss
it.  I apologise for spreading incorrect information. :-(

> An updated version 3.1 was issued in January, for use aftter April
> 1st. It's not as complete as one might like, but it surely exists and
> tests all of the really important new features of Ada 2005.

Good to know.

>> My three big wishes for Ada are that:
>>
>> 1) ACATS is updated to match the current Ada standard.
>
> ACATS 4.0 is under active development and should be released in the
> next few months. I just released the first snapshot last week, see
> http://www.ada-auth.org/acats.html.

I'll take a look.

>> 2) Any new standard is published _with_ a matching edition of ACATS.
>
> That's of course impractical as the same person (that is, me) is
> responsible for both. Finishing up a standard is a full time
> job. Doing the ACATS afterwards works well because it provides me
> something to do in between major Standards work. Else I'd have to get
> a real job and would most likely be unavailable for future work of any
> kind.

Good point.  I appreciate your work on editing the standard.

> The ARG has a discussion item on the agenda for the next meeting as to
> whether we should require ACATS tests from ARG members, which would
> certainly decrease the time lag. But it also has the possibility of
> preventing a lot of work on the standard, by making it many times more
> difficult for simpler issues. Several ARG members have indicated that
> they have no interest in writing ACATS tests, so we would stand to
> lose participation. (And we need more, not less participation!)

Another good point.

>> 3) The ARG establishes a process for expanding ACATS with
>>    user-provided examples.
>
> The ACATS has *always* taken user-submitted tests. There are examples
> in the ACATS going back as far as 1990. You can find out about
> submitting test on the user-submitted test page:
> http://www.ada-auth.org/submit.html. Most the tests that I'm using to
> create ACATS 4.0 are user-submitted.

Ahh...  Another bit of "secret" ACAA documentation.  It looks like I
should keep quiet about ACATS until I've expanded my study of the
ada-auth.org web site.

> As far as putting arbitrary user-provided stuff into the ACATS, that's
> a bad idea because it misinterprets the point of the ACATS.

I agree completely with you on that point.  But even if the example the
user starts out with isn't necessarily an ideal candidate for a formal
conformity test, it might be possible to guide the author in that
direction, such that the example can be transformed into a (number of)
formal conformity test(s).

> That said, it would be great if someone created a lightly-managed
> repository of user-provided examples for Ada. I tried to create such a
> reposistory back in the Ada 9x days, but no one other than me wanted
> to contribute to it.  Perhaps some other organization would have
> better luck.

Does that repository still exist?  I think I know a number of Ada users,
who would be happy to provide examples for such a repository.

Greetings,

Jacob (just another Ada user)
-- 
»What fun is it being "cool" if you can't wear a sombrero?«

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Thu, 27 Mar 2014 16:50:20 -0500, Randy Brukardt wrote:

> The primary "problem" is that in this model, most strings become tagged and 
> communicate using Wide_Wide_Character and Wide_Wide_String.

In another model only Wide_Wide_String'Class would be tagged.

Real issue: Classes of non-tagged types.

> So the 
> main issue is the cost of converting to-from Wide_Wide_String.

You would not need conversions if the specific operations were provided
rather than inherited (as they are provided presently).

Real issue: Multi-methods (String vs String) and full multiple dispatch
(String vs Character)

To reiterate the point. The implementation of strings in Ada is all OK, it
is the interface to this implementation which sucks.

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

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Jacob Sparre Andersen" <jacob@jacob-sparre.dk> wrote in message 
news:877g7en4gy.fsf@adaheads.sparre-andersen.dk...
> Randy Brukardt <randy@rrsoftware.com> wrote:
...
>> That said, it would be great if someone created a lightly-managed
>> repository of user-provided examples for Ada. I tried to create such a
>> reposistory back in the Ada 9x days, but no one other than me wanted
>> to contribute to it.  Perhaps some other organization would have
>> better luck.
>
> Does that repository still exist?  I think I know a number of Ada users,
> who would be happy to provide examples for such a repository.

It never really got off the ground, so it never had an on-line version. If 
it had, it would have been updated manually, which needs a volunteer to 
manage. There are certainly better solutions available now, but it will take 
someone to manage it. A lot of the tests I had then are now covered by the 
ACATS in some fashion, so there isn't quite the need to have them available 
that there was in the early 1990s.

                                           Randy.

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:o4o5ao9k7hz9.l7ebk8qxfv32.dlg@40tude.net...
> On Thu, 27 Mar 2014 16:50:20 -0500, Randy Brukardt wrote:
...
> Real issue: Multi-methods (String vs String) and full multiple dispatch
> (String vs Character)

That's an alternative, but the question is whether that can be implemented 
with less overhead than the scheme I suggested. I believe the answer is no, 
at least within generalized string packages (which hopefully will become the 
norm for new string operations in Ada). It's surely one of the questions to 
be considered - nothing I think on this topic (or any topic, for that 
matter) is likely to be the last word.

> To reiterate the point. The implementation of strings in Ada is all OK, it
> is the interface to this implementation which sucks.

Right, but that manifests itself in duplicated and overly restrictive 
packages, which would have to be reworked in order to use a more general 
interfaces. (Ada.Strings.Bounded and Ada.Strings.Unbounded in particular 
have overloaded operations that would make everything ambiguous if not 
eliminated.)

                              Randy.

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Fri, 28 Mar 2014 16:27:09 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:o4o5ao9k7hz9.l7ebk8qxfv32.dlg@40tude.net...
>> On Thu, 27 Mar 2014 16:50:20 -0500, Randy Brukardt wrote:
> ...
>> Real issue: Multi-methods (String vs String) and full multiple dispatch
>> (String vs Character)
> 
> That's an alternative, but the question is whether that can be implemented 
> with less overhead than the scheme I suggested. I believe the answer is no, 
> at least within generalized string packages (which hopefully will become the 
> norm for new string operations in Ada).

If and only if the generalized packages would define operations class-wide.
The idea is to rather make them primitive operations, so that a vendor (if
he wanted to) could provide type-specific implementation for the cases of
major interest, e.g.

   overriding function "&" (L, R : String) return String;

instead of inheriting (covariantly) ineffective parent's

    function "&" (L, R : Root_String_Type) return Root_String_Type;

Root_String_Type would be an equivalent of Wide_Wide_String or UTF8_String
or any other full Unicode character set string.

>> To reiterate the point. The implementation of strings in Ada is all OK, it
>> is the interface to this implementation which sucks.
> 
> Right, but that manifests itself in duplicated and overly restrictive 
> packages, which would have to be reworked in order to use a more general 
> interfaces. (Ada.Strings.Bounded and Ada.Strings.Unbounded in particular 
> have overloaded operations that would make everything ambiguous if not 
> eliminated.)

If all string types are members of single class, then all corresponding
overloaded operations are primitive operations on the class. Overloading of
overridden operations in guaranteed unambiguous. That is when you build a
new hierarchy of string types.

Whether Unbounded_String should become a member of this new hierarchy or be
replaced there with a new type is another question. Of course The former
would be greatly preferable. This requires yet another feature Ada lacks -
interface inheritance. Unbounded_String must drop parent's
implementation/representation and inherit only the interface.

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

Re: Your wish list for Ada 202X

[francois_fabien]

One wish to ease Input/output :
To have some equivalent of C primitive : printf("%c %c %c %c %c \n %c %c %c %c %c \n",

Re: Your wish list for Ada 202X

[Luke A. Guest]

<francois_fabien@hotmail.com> wrote:
> One wish to ease Input/output :
> To have some equivalent of C primitive : printf("%c %c %c %c %c \n %c %c %c %c %c \n",

God no. This requires parsing the string in every call, the Ada does it no
is superior. Plus it requires parameter passing from the right rather than
the left.

Re: Your wish list for Ada 202X

[Simon Clubley]

On 2014-03-30, francois_fabien@hotmail.com <francois_fabien@hotmail.com> wrote:
>
> One wish to ease Input/output :
> To have some equivalent of C primitive : printf("%c %c %c %c %c \n %c %c %c %c %c \n",
>

We have just had that discussion a couple of weeks or so ago. :-)

I also would like to see something like that in Ada, but I believe the
actual formatting is a attribute of the data type and is not something
which should be implemented within a I/O package as such.

My general idea is that when you define a data type, you also add support
for External_To_Internal and Internal_To_External conversions to the
data type.

At runtime, the Ada version of printf would call the Internal_To_External
support code within the data type along with the fragment of the format
for the entity in question (and which could include a optional display
length and precision).

Either a exception would be raised (if the requested conversion was
invalid) or the formatted output would be returned to the Ada version
of printf ready for direct inclusion in the output buffer.

As was pointed out the last time I suggested this, if the format string
was a literal, you could even check this at compile time, just as gcc
does for a C program.

Simon.

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

Re: Your wish list for Ada 202X

[Simon Clubley]

On 2014-03-30, Luke A  Guest <laguest@archeia.com> wrote:
><francois_fabien@hotmail.com> wrote:
>> One wish to ease Input/output :
>> To have some equivalent of C primitive : printf("%c %c %c %c %c \n %c %c %c %c %c \n",
>
> God no. This requires parsing the string in every call, the Ada does it no
> is superior. Plus it requires parameter passing from the right rather than
> the left.

The Ada way is ok for simple I/O.

What about when you want to produce a formatted report ?

Regardless of whether you keep the current I/O method only or add
something printf style, it's far more logical and cleaner for the
actual internal to external conversion to be conceptually a part
of the data type rather than yet _another_ package within Text_IO.

(Basically, you need a seriously enhanced version of 'Image with Text_IO
providing the basic non datatype specific I/O framework and the data type
itself doing the formatting/conversion to the requested output length,
editing and precision when applicable.)

This stuff belongs with the data type, not with some Text_IO package.

The same types of comments apply to input as well.

Simon.

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

Re: Your wish list for Ada 202X

[Simon Clubley]

On 2014-03-30, Luke A  Guest <laguest@archeia.com> wrote:
><francois_fabien@hotmail.com> wrote:
>> One wish to ease Input/output :
>> To have some equivalent of C primitive : printf("%c %c %c %c %c \n %c %c %c %c %c \n",
>
> God no. This requires parsing the string in every call, the Ada does it no
> is superior. Plus it requires parameter passing from the right rather than
> the left.

Also, I'm not quite sure what you mean by the latter. As far as I can see,
the parameter passing would be left to right, just as it is in C.

Simon.

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

Re: Your wish list for Ada 202X

[Peter Chapin]

On 2014-03-30 10:28, Simon Clubley wrote:

> Also, I'm not quite sure what you mean by the latter. As far as I can see,
> the parameter passing would be left to right, just as it is in C.

Typical C compilers push arguments onto the stack from right to left.
This is done to support variable length parameter lists such as what
printf() has. For example

    printf("%d\n", some_integer);

The printf function expects to find a pointer to the format string on
the top of the stack. It reads that string to find out what other
arguments to expect and then it indexes down the stack to get them. If
the compiler pushed arguments from left to right the critical pointer to
the format string would be beneath an unknown number of other arguments.

Standard C requires that functions with variable length parameter lists
be prototyped (this is a break from pre-standard C). This gives compiler
writers the option of using a different calling convention by default
and something special for functions with variable length parameters,
since the compiler can be sure such functions will be prototyped and
thus known to the compiler. Some compilers do take advantage of this and
will incorrectly compile calls to printf() if one does not #include
<stdio.h> or otherwise provide a prototype for printf().

Peter

Re: Your wish list for Ada 202X

[Luke A. Guest]

Peter Chapin <PChapin@vtc.vsc.edu> wrote:

Thanks for that, I couldn't remember the details

Re: Your wish list for Ada 202X

[Luke A. Guest]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2014-03-30, Luke A  Guest <laguest@archeia.com> wrote:
>> <francois_fabien@hotmail.com> wrote:
>>> One wish to ease Input/output :
>>> To have some equivalent of C primitive : printf("%c %c %c %c %c \n %c %c %c %c %c \n",
>> 
>> God no. This requires parsing the string in every call, the Ada does it no
>> is superior. Plus it requires parameter passing from the right rather than
>> the left.
> 
> Also, I'm not quite sure what you mean by the latter. As far as I can see,
> the parameter passing would be left to right, just as it is in C.
> 
> Simon.


C uses vararga which are passed right to left as the varargs functions use
thus right-ness to determine the number of parameters.

Luke

Re: Your wish list for Ada 202X

[Luke A. Guest]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2014-03-30, Luke A  Guest <laguest@archeia.com> wrote:
>> <francois_fabien@hotmail.com> wrote:
>>> One wish to ease Input/output :
>>> To have some equivalent of C primitive : printf("%c %c %c %c %c \n %c %c %c %c %c \n",
>> 
>> God no. This requires parsing the string in every call, the Ada does it no
>> is superior. Plus it requires parameter passing from the right rather than
>> the left.
> 
> The Ada way is ok for simple I/O.
> 
> What about when you want to produce a formatted report ?

Then you use the sub program conversions with field widths, ideally 'image
should take field width and padding information as optional parameters.

I see no problem.

Luke

Re: Your wish list for Ada 202X

[Pascal Obry]

Le dimanche 30 mars 2014 à 05:28 -0700, francois_fabien@hotmail.com a
écrit : 
> One wish to ease Input/output :
> To have some equivalent of C primitive : printf("%c %c %c %c %c \n %c %c %c %c %c \n",

Well, this is possible in Ada with some coding of a package, one could
write something like (maybe already implemented by someone, I remember a
simple_io package or something like that):

   Formatted_Print 
      ("%c %c %c %c %c \n %c %c %c %c %c \n"
       & Var1 & Var2 & Var3 & Var4 & Var5 & Var6 & Var7 & Var8);

You just have to code the Formatted_Print routine once for all. No big
deal:

   type Formatted_String is private;

   Format_Error : exception;

   function "&" 
      (F : Formatted_String; V : Character) return Formatted_String;
   function "&" 
      (F : Formatted_String; V : Integer) return Formatted_String;
   function "&" 
      (F : Formatted_String; V : Float) return Formatted_String;
   ...

   procedure Formatted_Print (F : Formatted_String);

   procedure Formatted_Print 
      (File : Text_IO.File_Type; 
       F    : Formatted_String);

...


-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

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

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

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Sun, 30 Mar 2014 18:48:13 +0000 (UTC), Luke A. Guest wrote:

> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> On 2014-03-30, Luke A  Guest <laguest@archeia.com> wrote:
>>> <francois_fabien@hotmail.com> wrote:
>>>> One wish to ease Input/output :
>>>> To have some equivalent of C primitive : printf("%c %c %c %c %c \n %c %c %c %c %c \n",
>>> 
>>> God no. This requires parsing the string in every call, the Ada does it no
>>> is superior. Plus it requires parameter passing from the right rather than
>>> the left.
>> 
>> The Ada way is ok for simple I/O.
>> 
>> What about when you want to produce a formatted report ?
> 
> Then you use the sub program conversions with field widths, ideally 'image
> should take field width and padding information as optional parameters.

What for? Image produces a string, formatted output is done into a string.
It makes little sense first to generate a string and then put it into
another one. The could be done in just one step, e.g.

http://www.dmitry-kazakov.de/ada/strings_edit.htm#Float_Edit
 
-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Sun, 30 Mar 2014 21:02:00 +0200, Pascal Obry wrote:

> Le dimanche 30 mars 2014 à 05:28 -0700, francois_fabien@hotmail.com a
> écrit : 
>> One wish to ease Input/output :
>> To have some equivalent of C primitive : printf("%c %c %c %c %c \n %c %c %c %c %c \n",
> 
> Well, this is possible in Ada with some coding of a package, one could
> write something like (maybe already implemented by someone, I remember a
> simple_io package or something like that):
> 
>    Formatted_Print 
>       ("%c %c %c %c %c \n %c %c %c %c %c \n"
>        & Var1 & Var2 & Var3 & Var4 & Var5 & Var6 & Var7 & Var8);
> 
> You just have to code the Formatted_Print routine once for all. No big
> deal:
> 
>    type Formatted_String is private;
> 
>    Format_Error : exception;
> 
>    function "&" 
>       (F : Formatted_String; V : Character) return Formatted_String;
>    function "&" 
>       (F : Formatted_String; V : Integer) return Formatted_String;
>    function "&" 
>       (F : Formatted_String; V : Float) return Formatted_String;
>    ...
> 
>    procedure Formatted_Print (F : Formatted_String);
> 
>    procedure Formatted_Print 
>       (File : Text_IO.File_Type; 
>        F    : Formatted_String);

I did such things, it is not so simple.

You need a set of "seed" functions to produce initial Formatted_String,
e.g.

   function "&" (L, R : Character) return Formatted_String;
   function "&" (L : Character; R : Integer) return Formatted_String;
   ...

Or you have to use Empty_Formatted_String constant in each expression.

Another consideration is efficiency, as it would keep on copying the string
upon each concatenation.

One method to deal with that is to use reference counting in
Formatted_String. When the argument F has the reference count 1 it is
updated in place and the result is returned. Otherwise F is cloned, the
copy is updated and then returned.

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

Re: Your wish list for Ada 202X

[Pascal Obry]

Le dimanche 30 mars 2014 à 21:33 +0200, Dmitry A. Kazakov a écrit : 
I did such things, it is not so simple.
> 
Sure!

You need a set of "seed" functions to produce initial Formatted_String,
> e.g.
> 
>    function "&" (L, R : Character) return Formatted_String;
>    function "&" (L : Character; R : Integer) return Formatted_String;
>    ...
> 
No since you always start with the Formatted_String (not derived from
string). We need at least a function to create the formatted_string from
a string:

   function "+" (Format : in String) return Formatted_String;

Then:

   +"%c" & var

Or you have to use Empty_Formatted_String constant in each expression.
> 
> Another consideration is efficiency, as it would keep on copying the
string
> upon each concatenation.
> 
Copies should be avoided by using a reference semantic. Note that I have
declared Formatted_String as:

   type Formatted_String is private;

Maybe it should be a tagged type.

This type is a record with the format. The result (Unbounded_String?)
and an index to the current format. That's what I'm thinking.

Let's say we have:

   type Formatted_String is record
      Format : Unbounded_String;
      Index  : Positive;
      Result : Unbounded_String;
   end record;

Then

   +"%c %c"

Set such record to ("%c %c", 1, "")

Then with : & Var

If Var is not a character => raise exception

Let's say Var := 'x'

If a char then the record becomes : ("%c %c", 3, "x")

That's how I would do such implementation.


-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

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

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

Re: Your wish list for Ada 202X

[Simon Clubley]

On 2014-03-30, Luke A  Guest <laguest@archeia.com> wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> On 2014-03-30, Luke A  Guest <laguest@archeia.com> wrote:
>>> <francois_fabien@hotmail.com> wrote:
>>>> One wish to ease Input/output :
>>>> To have some equivalent of C primitive : printf("%c %c %c %c %c \n %c %c %c %c %c \n",
>>> 
>>> God no. This requires parsing the string in every call, the Ada does it no
>>> is superior. Plus it requires parameter passing from the right rather than
>>> the left.
>> 
>> Also, I'm not quite sure what you mean by the latter. As far as I can see,
>> the parameter passing would be left to right, just as it is in C.
>> 
>> Simon.
>
>
> C uses vararga which are passed right to left as the varargs functions use
> thus right-ness to determine the number of parameters.
>

Sorry, I understand what you are saying now. I thought you were
talking about the way it was written in the source code, not the
way the compiler generated the parameter passing code.

Simon.

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

Re: Your wish list for Ada 202X

[Stoik]

W dniu niedziela, 30 marca 2014 21:59:26 UTC+2 użytkownik Pascal Obry napisał:
> Le dimanche 30 mars 2014 à 21:33 +0200, Dmitry A. Kazakov a écrit : 
> 
> I did such things, it is not so simple.
> 
> > 
> 
> Sure!
> 
> 
> 
> You need a set of "seed" functions to produce initial Formatted_String,
> 
> > e.g.
> 
> > 
> 
> >    function "&" (L, R : Character) return Formatted_String;
> 
> >    function "&" (L : Character; R : Integer) return Formatted_String;
> 
> >    ...
> 
> > 
> 
> No since you always start with the Formatted_String (not derived from
> 
> string). We need at least a function to create the formatted_string from
> 
> a string:
> 
> 
> 
>    function "+" (Format : in String) return Formatted_String;
> 
> 
> 
> Then:
> 
> 
> 
>    +"%c" & var
> 
> 
> 
> Or you have to use Empty_Formatted_String constant in each expression.
> 
> > 
> 
> > Another consideration is efficiency, as it would keep on copying the
> 
> string
> 
> > upon each concatenation.
> 
> > 
> 
> Copies should be avoided by using a reference semantic. Note that I have
> 
> declared Formatted_String as:
> 
> 
> 
>    type Formatted_String is private;
> 
> 
> 
> Maybe it should be a tagged type.
> 
> 
> 
> This type is a record with the format. The result (Unbounded_String?)
> 
> and an index to the current format. That's what I'm thinking.
> 
> 
> 
> Let's say we have:
> 
> 
> 
>    type Formatted_String is record
> 
>       Format : Unbounded_String;
> 
>       Index  : Positive;
> 
>       Result : Unbounded_String;
> 
>    end record;
> 
> 
> 
> Then
> 
> 
> 
>    +"%c %c"
> 
> 
> 
> Set such record to ("%c %c", 1, "")
> 
> 
> 
> Then with : & Var
> 
> 
> 
> If Var is not a character => raise exception
> 
> 
> 
> Let's say Var := 'x'
> 
> 
> 
> If a char then the record becomes : ("%c %c", 3, "x")
> 
> 
> 
> That's how I would do such implementation.
> 
> 
> 
> 
> 
> -- 
> 
>   Pascal Obry /  Magny Les Hameaux (78)
> 
> 
> 
>   The best way to travel is by means of imagination
> 
> 
> 
>   http://v2p.fr.eu.org
> 
>   http://www.obry.net
> 
> 
> 
>   gpg --keyserver keys.gnupg.net --recv-key F949BD3B

A clever use of & and + makes it possible to output complicated mixtures of elements of various types, so it seems that nothing needs to be added to the language (unless we have an elegant way of adding an "input" and "output" aspect to the type). On the other hand, there is clearly a need for one or more subprograms for the input of strings. Just now, we have three fairly convenient ways of inputing a line: procedure get_line (with the inconvenience of an additional parameter and the necessity of guessing the maximal length of the string), function get_line returning string (one usually needs to add a block to use it) or get_line returning unbounded_string (very convenient, may be not so efficient). What is needed are subprograms for entering a word (get_word) delimited by default by spaces. This is what cin from C++ does. All methods I know of (not requiring me to write the subprograms) is to enter the whole line and then to chop it, using either subprograms from GNAT library, or things like find_token, slice and delete. Getting a word from the input is so ubiquitous, that one should be able to do it very easily.

Re: Your wish list for Ada 202X

[Adam Beneschan]

On Sunday, March 30, 2014 6:40:24 AM UTC-7, Luke A. Guest wrote:

> 
> > One wish to ease Input/output :
> 
> > To have some equivalent of C primitive : printf("%c %c %c %c %c \n %c %c %c %c %c \n",
> 
> God no. This requires parsing the string in every call, the Ada does it no
> is superior. 

I can't tell what you're trying to say here--it's not grammatical.  If you're trying to say something along the lines of "the Ada way to write this", I'm not sure just what that is.  I'm sure there are several opinions about what "the Ada way" is for this.

> Plus it requires parameter passing from the right rather than
> the left.

No, it wouldn't require parameter passing like that at all.  Some different mechanism would no doubt have to be invented, though.

The original C didn't have function prototypes at all.  Most of the time, you simply used the function, and the compiler would assume it existed.  If the return type were something other than "int", you might have to write an "extern" declaration to tell the compiler the function existed and its return type, but you still didn't tell it anything about the parameters.  The compiler assumed you knew the parameter types and got them right, and if you didn't, then you got to have fun debugging your error.  But functions with variable numbers of argument like printf() could be made to work because the compiler would push the arguments on the stack right-to-left, and the printf() function would read them from the stack like that.

But, certainly, if one were to design a mechanism to allow such parameter passing, one wouldn't be constrained to use the same mechanism adopted by an extremely low-level 1960s programming language like C.  There are many other possibilities, such as pushing the number of parameters and the number of bytes in each passed value as hidden parameters on the stack.  The assumption here would be that the printf function would be *declared* to take a variable-argument-list, and therefore the compiler would know, on *both* sides (when compiling the subprogram body, and when compiling the call), that the special mechanism for passing variable-argument lists would need to be in effect.  This assumption was *not* true for the original C, which is why the right-to-left thing was necessary.

In Java, for instance, methods with variable-length argument lists are just treated as arrays.  So when you say

    System.out.printf("Count=%d value=%8.2f\n", someInteger, someFloat);

printf will see two parameters: a String, and an array of two Objects, where the first element is an Integer and the second is a Float.  (All "objects" in Java are descended from Object, and non-objects like "int" will be automatically converted to Integer objects in some contexts.)  printf can then just traverse the array; it can also check to make sure the variable argument list has the correct number of parameters and parameter types.  

I'm not saying that Ada needs a feature like this, or that it should be implemented the way Java did it.  I'm just saying that it clearly is *not* necessary to use right-to-left parameter passing in order to add a feature like this to the language.  

                                 -- Adam

Re: Your wish list for Ada 202X

[Pascal Obry]

Le lundi 31 mars 2014 à 08:13 -0700, Stoik a écrit : 
> A clever use of & and + makes it possible to output complicated mixtures of 
> elements of various types, so it seems that nothing needs to be added to the language

Expect that it is quite difficult to handle the padding, the leading
zeros, the alignment... All this can be specified in a C/C++ format
string.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

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

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

Re: Your wish list for Ada 202X

[Pascal Obry]

Le lundi 31 mars 2014 à 08:13 -0700, Stoik a écrit : 
> A clever use of & and + makes it possible to output complicated mixtures..

Forgot about my previous message it seems I have miss-read your
comment :)

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

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

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

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Mon, 31 Mar 2014 08:13:33 -0700 (PDT), Stoik wrote:

> What is needed are subprograms for entering a word (get_word) delimited by
> default by spaces.

It seems that you are thinking in the paradigm of tokenizing. There are
more efficient and easier means of parsing.

When writing a compiler you indeed need something like getting an
identifier from the source. But, an identifier is not a word and source is
not a string, though string could be a source. Other stuff like matching
the source against a table of keywords does not need word input either.

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

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:8bhozh836pyt$.1qctlysud0s2q$.dlg@40tude.net...
> On Fri, 28 Mar 2014 16:27:09 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:o4o5ao9k7hz9.l7ebk8qxfv32.dlg@40tude.net...
>>> On Thu, 27 Mar 2014 16:50:20 -0500, Randy Brukardt wrote:
>> ...
>>> Real issue: Multi-methods (String vs String) and full multiple dispatch
>>> (String vs Character)
>>
>> That's an alternative, but the question is whether that can be 
>> implemented
>> with less overhead than the scheme I suggested. I believe the answer is 
>> no,
>> at least within generalized string packages (which hopefully will become 
>> the
>> norm for new string operations in Ada).
>
> If and only if the generalized packages would define operations 
> class-wide.
> The idea is to rather make them primitive operations, so that a vendor (if
> he wanted to) could provide type-specific implementation for the cases of
> major interest, e.g.
>
>   overriding function "&" (L, R : String) return String;
>
> instead of inheriting (covariantly) ineffective parent's
>
>    function "&" (L, R : Root_String_Type) return Root_String_Type;

I don't understand how you are thinking the class-wide operations would work 
if everything isn't primitive. That's the only way for an Ada class-wide 
type to even be useful. So, of course each type will define useful primitive 
operations, and all of the root string operations will be primitive. 
(Indeed, the language definition already makes that so in the case of "&".)

> Root_String_Type would be an equivalent of Wide_Wide_String or UTF8_String
> or any other full Unicode character set string.

"Root_String_Type" would be abstract, and the other types would be derived 
from it. New types corresponding to each interesting representation would be 
defined. The existing types would still exist but be obsolescent.

...
>> Right, but that manifests itself in duplicated and overly restrictive
>> packages, which would have to be reworked in order to use a more general
>> interfaces. (Ada.Strings.Bounded and Ada.Strings.Unbounded in particular
>> have overloaded operations that would make everything ambiguous if not
>> eliminated.)
>
> If all string types are members of single class, then all corresponding
> overloaded operations are primitive operations on the class. Overloading 
> of
> overridden operations in guaranteed unambiguous. That is when you build a
> new hierarchy of string types.

Yes, of course, this is what I've proposing.

> Whether Unbounded_String should become a member of this new hierarchy or 
> be
> replaced there with a new type is another question.

It's not a question. There's no way to do that because the operations 
already defined for Unbounded_String would make it ambigious if given string 
literals (and all Root_String_Type'Class types would have string literals). 
It would be completely unusable.

As such, all new types is the only possibility. That's what makes this idea 
politically messy.

> Of course The former
> would be greatly preferable. This requires yet another feature Ada lacks -
> interface inheritance. Unbounded_String must drop parent's
> implementation/representation and inherit only the interface.

That's not the problem at all. (The parent here would have no 
representation, so there is nothing to drop.)

The problem is that Unbounded_String defines operations like

      function "&" (Left : Unbounded_String; Right : String) return 
Unbounded_String;

which would be ambiguous with the normal "&" if both String and 
Unbounded_String had string literals (as they must for Root_String_Type to 
work). Indeed, that's the only reason that Ada doesn't have a way to define 
string literals for a private type -- we talked about it years ago but 
determined that it cannot be used with any of the existing string packages. 
As such, it would have been a weird thing to define.

We can't get rid of these problematical operations -- it would be way too 
incompatible. So new packages is the only way to go.

                                  Randy.

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Mon, 31 Mar 2014 18:55:07 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:8bhozh836pyt$.1qctlysud0s2q$.dlg@40tude.net...
>> On Fri, 28 Mar 2014 16:27:09 -0500, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:o4o5ao9k7hz9.l7ebk8qxfv32.dlg@40tude.net...
>>>> On Thu, 27 Mar 2014 16:50:20 -0500, Randy Brukardt wrote:
>>> ...
>>>> Real issue: Multi-methods (String vs String) and full multiple dispatch
>>>> (String vs Character)
>>>
>>> That's an alternative, but the question is whether that can be implemented
>>> with less overhead than the scheme I suggested. I believe the answer is no,
>>> at least within generalized string packages (which hopefully will become 
>>> the norm for new string operations in Ada).
>>
>> If and only if the generalized packages would define operations class-wide.
>> The idea is to rather make them primitive operations, so that a vendor (if
>> he wanted to) could provide type-specific implementation for the cases of
>> major interest, e.g.
>>
>>   overriding function "&" (L, R : String) return String;
>>
>> instead of inheriting (covariantly) ineffective parent's
>>
>>    function "&" (L, R : Root_String_Type) return Root_String_Type;
> 
[...]
> So, of course each type will define useful primitive 
> operations, and all of the root string operations will be primitive.

In that case there will be no overhead when an operation is overridden.

> It's not a question. There's no way to do that because the operations 
> already defined for Unbounded_String would make it ambigious if given string 
> literals (and all Root_String_Type'Class types would have string literals). 
> It would be completely unusable.

When you inherit from a type you "define" inherited operations. It is not
ambiguous since operations are primitive. So long there is no overloading
there will be no ambiguity.

>> Of course The former
>> would be greatly preferable. This requires yet another feature Ada lacks -
>> interface inheritance. Unbounded_String must drop parent's
>> implementation/representation and inherit only the interface.
> 
> That's not the problem at all. (The parent here would have no 
> representation, so there is nothing to drop.)

Unbounded_String will be derived from String, or String derived from
Unbounded_String. The point is to keep it a hierarchy. And the real problem
with all that is that there is more than one vector of inheritance:

1. memory management (fixed, bounded, unbounded)
2. range (character, wide_character, wide_wide_character)
3. encoding (UCS-4, UCS-2, UTF-8, ASCII)
 
> The problem is that Unbounded_String defines operations like
> 
>       function "&" (Left : Unbounded_String; Right : String) return 
> Unbounded_String;
> 
> which would be ambiguous with the normal "&" if both String and 
> Unbounded_String had string literals (as they must for Root_String_Type to 
> work).

No, it is unambiguous, because provided Unbounded_String is a descendant of
String (or reversely) 

   function "&" (Left : Unbounded_String; Right : String) return 
      Unbounded_String;

is a part of the implementation of the MD operation

   function "&" (Left, Right : Root_String_Type) return 
      Root_String_Type;

> We can't get rid of these problematical operations -- it would be way too 
> incompatible. So new packages is the only way to go.

You can, and everything will stay compatible if the type system is fixed
first (MD, MI etc). Within present type system it is indeed unfixable and
moreover, new packages will likely become as messy as the old ones.

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

Re: Your wish list for Ada 202X

[G.B.]

On 01.04.14 10:20, Dmitry A. Kazakov wrote:
> part of the implementation of the MD operation
>
>     function "&" (Left, Right : Root_String_Type) return
>        Root_String_Type;

How would MD work, practically, and efficiently, with numeric
types? Should "+" be multiply dispatching, say? I'll assume
that the compiler should then statically find the "+"
determined by the type if its operands. Is this feasible?

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Tue, 01 Apr 2014 12:51:08 +0200, G.B. wrote:

> On 01.04.14 10:20, Dmitry A. Kazakov wrote:
>> part of the implementation of the MD operation
>>
>>     function "&" (Left, Right : Root_String_Type) return
>>        Root_String_Type;
> 
> How would MD work, practically, and efficiently, with numeric
> types? Should "+" be multiply dispatching, say?

Certainly so.

> I'll assume
> that the compiler should then statically find the "+"
> determined by the type if its operands.

Just as it already does, right now.

When types are statically known, and they are not allowed not be known in
present Ada, no dispatch is involved.

Ergo, MD of non-tagged types has *NO* influence on any existing Ada
program.

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

Re: Your wish list for Ada 202X

[Britt]

On Tuesday, March 25, 2014 5:41:16 PM UTC-4, Stoik wrote:
> I wonder what is high on your list of wishes for Ada 202X?

require basic support for 64-bit integer types:
   Standard.Long_Long_Integer (I'm currently missing this in ObjectAda)
   Interfaces.Integer_64
   Interfaces.Unsigned_64
   and corresponding support for C99's "long long", "int64_t" and "uint64_t" in Interfaces.C

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1cdsyxjzsfgzm.1synpaujysv21$.dlg@40tude.net...
...
>>> Of course The former
>>> would be greatly preferable. This requires yet another feature Ada 
>>> lacks -
>>> interface inheritance. Unbounded_String must drop parent's
>>> implementation/representation and inherit only the interface.
>>
>> That's not the problem at all. (The parent here would have no
>> representation, so there is nothing to drop.)
>
> Unbounded_String will be derived from String, or String derived from
> Unbounded_String. The point is to keep it a hierarchy.

Why? There is no interesting relationship between String and 
Unbounded_String other than the interface (which is inherited from the root 
type). There is no opportunity to share implementations, which is the other 
reason to inherit one from another.

Just inheriting things because something *thinks* they should be related is 
silly. There is no advantage to using String'Class (if such a thing existed) 
rather than Root_String'Class, since all the former does is restrict what 
your subprogram can do; it doesn't add any capability.

(In any case, in my model [which is designed for minimum change to the 
existing Ada language], String, Wide_String, and Wide_Wide_String stay 
untagged array types; they have no relationship to the hierarchy of 
Root_String'Class, possibly other than being defined in conversions.)

> And the real problem
> with all that is that there is more than one vector of inheritance:
> 1. memory management (fixed, bounded, unbounded)
> 2. range (character, wide_character, wide_wide_character)
> 3. encoding (UCS-4, UCS-2, UTF-8, ASCII)

1 and 3 are irrelevant, because they shouldn't have any effect on the 
interface -- they're things that should be totally hidden outside of 
streaming for 3. Perhaps 2 should have some affect on the interfaces, but 
that's easily handled with a second level of abtsract types defining those 
interfaces.

Besides, 1 can totally be defined after the fact with packages. That's the 
model that I'm suggesting. "Unbounded_String" is a container for a 
Root_String'Class type; it adds unbounded memory management to whatever the 
string type does. There is no reason that one has to do that as part of the 
string abstraction.

>> The problem is that Unbounded_String defines operations like
>>
>>       function "&" (Left : Unbounded_String; Right : String) return
>> Unbounded_String;
>>
>> which would be ambiguous with the normal "&" if both String and
>> Unbounded_String had string literals (as they must for Root_String_Type 
>> to
>> work).
>
> No, it is unambiguous, because provided Unbounded_String is a descendant 
> of
> String (or reversely)
>
>   function "&" (Left : Unbounded_String; Right : String) return
>      Unbounded_String;
>
> is a part of the implementation of the MD operation
>
>   function "&" (Left, Right : Root_String_Type) return
>      Root_String_Type;

That doesn't help at all. We still don't know which body to execute when a 
string literal is used, because it matches all string types. You would have 
to qualify all string literals in an MD world, and that's something 
programmers would never tolerate.

>> We can't get rid of these problematical operations -- it would be way too
>> incompatible. So new packages is the only way to go.
>
> You can, and everything will stay compatible if the type system is fixed
> first (MD, MI etc). Within present type system it is indeed unfixable and
> moreover, new packages will likely become as messy as the old ones.

As I said before, I am skeptical that an MD system (even ignoring MI) could 
be implemented efficiently enough to be used in critical operations like 
strings. As soon as you go to MD, the linear tag model has to ba abandoned, 
and some sort of search mechanism used for finding bodies to dispatch to. 
(Why? Consider "&". There are three types involved, at least 15 variations 
of those types [encoding * range; many more if one thinks storage has to be 
involved], giving 15**3 possibilities just for that operation alone. It's 
obviously impractical to store that as a flat data structure, especially as 
most slots will be empty.)

The flat tag dispatching model involves a single index into a tag data 
structure, almost always using a compile-time known offset [only univerally 
shared generics have to do something at runtime, and even that's simple]. 
That adds the cost of just a handful instructions and one or two extra 
memory reads [one to get the tag address, one to get the body address] for a 
dispatching call. That's almost never going to be significant, as it is 
dwarfed by parameter passing and the execution of the body. OTOH, if 
dispatching requires looking in various lookup tables to figure out where 
the body address is, that overhead is substantially more expensive and at 
least potentially begins to be a significant part of call overhead.

It's possible that there are things one could do at link-time to cut such 
overhead (there is for MI, for instance), but that would require an all-Ada 
system (which is a rarity these days). I'm skeptical, but I'm not certain so 
I could be convinced otherwise.

                                Randy.

Re: Your wish list for Ada 202X

[Randy Brukardt]

Even on 8-bit and 16-bit processors??

                     Randy.

(Note that no one should be depending on implementation-defined Standard 
types like Long_Long_Integer. These are considered implementation-defined by 
the profile No_Implementation_Extensions; they should be avoided in portable 
Ada code. Also see 3.5.4(28). I have more sympathy for requiring 
System.Max_Int to be at least 2**63-1 on appropriate machines (and the 
appropriate Interfaces types as well)) -- but what's an appropriate machine? 
Janus/Ada has never supported 64-bit integers, mainly because of the nasty 
effect on shared generics for formal integer and discrete types [it would 
force those to use all 64-bit math, which would get pretty expensive for 
Text_IO.Integer_IO and similar generics]. We only support 32-bit machines, 
but of course modern Intel processors all have 64-bit "integers" via the 
floating point instruction set. I've never considered that real 64-bit 
support and ignored it, because of expense and precision concerns [along 
with complications supporting indexing and for loops] -- not worth the 
headache. A 64-bit target would be a different beast, of course.)

"Britt" <britt.snodgrass@gmail.com> wrote in message 
news:2d62368c-9f64-49f3-98a8-5121d0c0fa23@googlegroups.com...
> On Tuesday, March 25, 2014 5:41:16 PM UTC-4, Stoik wrote:
>> I wonder what is high on your list of wishes for Ada 202X?
>
> require basic support for 64-bit integer types:
>   Standard.Long_Long_Integer (I'm currently missing this in ObjectAda)
>   Interfaces.Integer_64
>   Interfaces.Unsigned_64
>   and corresponding support for C99's "long long", "int64_t" and 
> "uint64_t" in Interfaces.C 

Re: Your wish list for Ada 202X

[Jeffrey Carter]

On 04/02/2014 03:53 PM, Randy Brukardt wrote:
> Even on 8-bit and 16-bit processors??

I'd like the language to support any integer type declaration a user is willing 
to write, regardless of "efficiency". For some such declarations, the compiler 
can chain together multiple machine "words" as we used to do in the Good Old 
Days® to get 16-bit integers on 8-bit machines like the 6502. At some the point 
the compiler should be allowed to use the same representation as 
Unbounded_Integer, which would implement the unlimited-precision integer package 
the compiler writer has had to use to write the compiler (or a similar package 
for the target for cross compilers).

Not going to happen, I know, but ...

I'd also like a mode in which objects that don't fit on the stack would be 
automatically put on the heap.

-- 
Jeff Carter
"I feel as though somebody stepped on my tongue
with muddy feet."
Never Give a Sucker an Even Break
112

Re: Your wish list for Ada 202X

[Britt]

On Wednesday, April 2, 2014 6:53:25 PM UTC-4, Randy Brukardt wrote:
> Even on 8-bit and 16-bit processors??

No, I had 32-bit and 64-bit ARM/PowerPC/x86 type processors in mind. The RM currently allows Standard.Long_Long_Integer as an implementation permission. I know how to use project defined subtypes (renames) of Standard types in a reasonably portable way. Its annoying that ObjectAda still doesn't provide 64-bit integer support on the same targets as GNAT. I don't have recent experience with other compilers but I currently use both of these.

Re: Your wish list for Ada 202X

[Shark8]

On 02-Apr-14 15:39, Randy Brukardt wrote:
> It's possible that there are things one could do at link-time to cut such
> overhead (there is for MI, for instance), but that would require an all-Ada
> system (which is a rarity these days).

An all-Ada [build] system would, IMO, be a great thing; especially if we 
were to use formal methods and get the base nice and formally proven -- 
that /is/ the end-goal for my SQUID project: formal verification of the 
translator (and, to a lesser degree, tools).

Re: Your wish list for Ada 202X

[Pascal Obry]

Le mercredi 02 avril 2014 à 17:01 -0700, Jeffrey Carter a écrit : 
> On 04/02/2014 03:53 PM, Randy Brukardt wrote:
> > Even on 8-bit and 16-bit processors??
> 
> I'd like the language to support any integer type declaration a user is willing 
> to write, regardless of "efficiency". For some such declarations, the compiler 
> can chain together multiple machine "words" as we used to do in the Good Old 
> Days® to get 16-bit integers on 8-bit machines like the 6502. At some the point 
> the compiler should be allowed to use the same representation as 
> Unbounded_Integer, which would implement the unlimited-precision integer package 
> the compiler writer has had to use to write the compiler (or a similar package 
> for the target for cross compilers).

But again this is doable today in Ada (even 1983) with a library and
proper overriding of the operators.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

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

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

Re: Your wish list for Ada 202X

[Jeffrey Carter]

On 04/02/2014 10:51 PM, Pascal Obry wrote:
>
> But again this is doable today in Ada (even 1983) with a library and
> proper overriding of the operators.

Well, no. Unbounded_Integer would work like any other integer type. You wouldn't 
have to convert literals or named numbers:

I : Unbounded_Integer := 1E1000;

-- 
Jeff Carter
"I feel as though somebody stepped on my tongue
with muddy feet."
Never Give a Sucker an Even Break
112

Re: Your wish list for Ada 202X

[Georg Bauhaus]

On 03/04/14 07:51, Pascal Obry wrote:
> But again this is doable today in Ada (even 1983) with a library and
> proper overriding of the operators.

If one library L1 has a first subtype with "range -2**63 .. 2**63-1",
and your compiler only supports smaller ranges or private
types from some integer library L2, then the programmer cannot
make L1 and L2 compatible, since the compiler rejects L1.

SQL bindings are one example of the kind L1.

Re: Your wish list for Ada 202X

[Robert A Duff]

Britt <britt.snodgrass@gmail.com> writes:

> On Tuesday, March 25, 2014 5:41:16 PM UTC-4, Stoik wrote:
>> I wonder what is high on your list of wishes for Ada 202X?
>
> require basic support for 64-bit integer types:
>    Standard.Long_Long_Integer (I'm currently missing this in ObjectAda)

Don't make the mistake of thinking standards require anybody
to do anything.  They pretend to, being full of words like
"shall" and "must" and "illegal".  But standards compliance is
voluntary.

As far as I know, ObjectAda does not conform to Ada 2012, so adding
a requirement to Ada 2022 (or 2025 or whatever) is unlikely to
have any effect on ObjectAda.  All it takes to change that is
money.

But I agree with you that Ada ought to require[*] 64-bit integers
(and more, as Jeff Carter said).  On the other hand, I have
no use for Standard.Long_Long_Integer -- I just want to be
able to say things like "range 1..2**123".

[*]or at least pretend to... ;-)

>    Interfaces.Integer_64
>    Interfaces.Unsigned_64
>    and corresponding support for C99's "long long", "int64_t" and "uint64_t" in Interfaces.C

Yes, all of those make sense.

- Bob

Re: Your wish list for Ada 202X

[Pascal Obry]

Le mercredi 02 avril 2014 à 23:27 -0700, Jeffrey Carter a écrit : 
> On 04/02/2014 10:51 PM, Pascal Obry wrote:
> >
> > But again this is doable today in Ada (even 1983) with a library and
> > proper overriding of the operators.
> 
> Well, no. Unbounded_Integer would work like any other integer type. You wouldn't 
> have to convert literals or named numbers:
> 
> I : Unbounded_Integer := 1E1000;

Ok, some little annoyance indeed.

In the same vein, something that is annoying is to have to create record
for returning multiple values from a function. I would rather like to
have support for tuple.

   A, B : Integer;

   function MyName return (Integer, Integer);

And then be able to write:

   (A, B) := (9, 12);

or
   (A, B) := MyName;

Today you need to create a record just for that.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

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

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

Re: Your wish list for Ada 202X

[Dan'l Miller]

On Thursday, April 3, 2014 12:18:37 PM UTC-5, Pascal Obry wrote:
> Le mercredi 02 avril 2014 à 23:27 -0700, Jeffrey Carter a écrit : 
> 
> > On 04/02/2014 10:51 PM, Pascal Obry wrote:
> 
> > >
> 
> > > But again this is doable today in Ada (even 1983) with a library and
> 
> > > proper overriding of the operators.
> 
> > 
> 
> > Well, no. Unbounded_Integer would work like any other integer type. You wouldn't 
> 
> > have to convert literals or named numbers:
> 
> > 
> 
> > I : Unbounded_Integer := 1E1000;
> 
> 
> 
> Ok, some little annoyance indeed.
> 
> 
> 
> In the same vein, something that is annoying is to have to create record
> 
> for returning multiple values from a function. I would rather like to
> 
> have support for tuple.
> 
> 
> 
>    A, B : Integer;
> 
> 
> 
>    function MyName return (Integer, Integer);
> 
> 
> 
> And then be able to write:
> 
> 
> 
>    (A, B) := (9, 12);
> 
> 
> 
> or
> 
>    (A, B) := MyName;
> 
> 
> 
> Today you need to create a record just for that.
> 
> 
> 
> -- 
> 
>   Pascal Obry /  Magny Les Hameaux (78)
> 
> 
> 
>   The best way to travel is by means of imagination
> 
> 
> 
>   http://v2p.fr.eu.org
> 
>   http://www.obry.net
> 
> 
> 
>   gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Your wish list for Ada 202X

[Dan'l Miller]

On Thursday, April 3, 2014 12:18:37 PM UTC-5, Pascal Obry wrote:
>    function MyName return (Integer, Integer);
> 
> And then be able to write:
> 
>    (A, B) := (9, 12);
> or
>    (A, B) := MyName;
>
> Today you need to create a record just for that.

Although I agree that such syntax is preferable to the verbosity that we have today, to fulfill what goal should this be added to Ada202X?  Is Ada202X's purpose to reduce verbosity with clever (or full-fledged mathematical a la Fortress) simplified syntax?  Is the reason to add this to Ada202X the fact that C++2011 has some support for tuples (mainly through its Boost-inspired standard libraries with some back-infusion into the language itself) and that Ada202X's purpose is to address all of the C++ envies?  Is the reason to add this to support some sort of library or code-generator that is awkward or impractical or impossible given today's record-based solution, and hence Ada202X's purpose is driven by what drove the Boost-inspired portions of C++2011:  assisting writers of clever-under-the-hood libraries?

Some of these are scarier than others.  The final one on my list of questions above was the road to perdition in C++2011:  contort C++ & its libraries to be a poor-man's kludge for a functional language.

Re: Your wish list for Ada 202X

[Qun-Ying]

Robert A Duff wrote:
> But I agree with you that Ada ought to require[*] 64-bit integers
> (and more, as Jeff Carter said).  On the other hand, I have
> no use for Standard.Long_Long_Integer -- I just want to be
> able to say things like "range 1..2**123".
> - Bob
>
What prevents a compiler to implement that in the current standard?
Couldn't the compiler use internal representation (like using the gmp 
lib) for such big range?

Re: Your wish list for Ada 202X

[Randy Brukardt]

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

"Pascal Obry" <pascal@obry.net> wrote in message 
news:1396545517.12456.30.camel@pascal.home.net...
>Le mercredi 02 avril 2014 à 23:27 -0700, Jeffrey Carter a écrit :
>> On 04/02/2014 10:51 PM, Pascal Obry wrote:
>> >
>> > But again this is doable today in Ada (even 1983) with a library and
>> > proper overriding of the operators.
>>
>> Well, no. Unbounded_Integer would work like any other integer type. You 
>> wouldn't
>> have to convert literals or named numbers:
>>
>> I : Unbounded_Integer := 1E1000;
>
>Ok, some little annoyance indeed.

Very little, with proper operator definitions

I : Unbounded_Integer := +1E1000;

works today.

And it would be pretty simple to provide an aspect for allowing literals for 
a private type.

But there is no advantage to supporting it as a built-in type - and it would 
have a significant cost, the elimination of practical generic sharing. (If 
built-in integers could use an "unbounded" type, then all integer math in a 
shared generic body would have to use that math. In which case, performance 
would be dismal. Even supporting 64-bit integers on a 32-bit machine would 
have a version of that effect, but of course no where near as severe.)

                             Randy.

Re: Your wish list for Ada 202X

[Robert A Duff]

Qun-Ying <zhu.qunying@gmail.com> writes:

> Robert A Duff wrote:
>> But I agree with you that Ada ought to require[*] 64-bit integers
>> (and more, as Jeff Carter said).  On the other hand, I have
>> no use for Standard.Long_Long_Integer -- I just want to be
>> able to say things like "range 1..2**123".
>> - Bob
>>
> What prevents a compiler to implement that in the current standard?

Nothing prevents it.  It would cost money, though.

Also, users might be surprised that:

    type Biggest_Integer is range System.Min_Int .. System.Max_Int;

is extremely inefficient.

And as I said, standards don't require anybody to do (or not do)
anything.  Standards compliance is optional.  So even if the Ada
RM forbade that, a compiler could allow it anyway (probably in
a special mode, so it could still honestly claim conformance).

But the fact that a compiler can implement very large integers
isn't much use to people who care about portability to all
conforming implementations.

> Couldn't the compiler use internal representation (like using the gmp
> lib) for such big range?

It could.

In fact, recent versions of GNAT support arbitrary-range integers
for intermediate results.  See Appendix D, "Overflow Check Handling
in GNAT" in the GNAT User's Guide.

- Bob

Re: Your wish list for Ada 202X

[Jeffrey Carter]

On 04/03/2014 02:17 PM, Randy Brukardt wrote:
>
> I : Unbounded_Integer := +1E1000;
>
> works today.

I would like to see the definition of "+".

-- 
Jeff Carter
"If I could find a sheriff who so offends the citizens of Rock
Ridge that his very appearance would drive them out of town ...
but where would I find such a man? Why am I asking you?"
Blazing Saddles
37

Re: Your wish list for Ada 202X

[Stefan.Lucks]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 669 bytes --]

On Thu, 3 Apr 2014, Jeffrey Carter wrote:

> On 04/03/2014 02:17 PM, Randy Brukardt wrote:
>> 
>> I : Unbounded_Integer := +1E1000;
>> 
>> works today.
>
> I would like to see the definition of "+".

Second!

My understanding is that 1E1000 is of the pseudo-type Universal Integer, 
(or maybe Universal Float). But the "+" function cannot have an 
in-parameter of that type, so that *should* not work.

Randy, please enlighten us!

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

Re: Your wish list for Ada 202X

[Dan'l Miller]

On Tuesday, March 25, 2014 4:41:16 PM UTC-5, Stoik wrote:
> I think that even a casual user of Ada should be able to influence somehow the new version of Ada. I wonder what is high on your list of wishes for Ada 202X?

High on my list of wishes for Ada 202X is for there to be a clear cattle-prod that is an over-arching guiding principle, instead of Ada 202X being merely a catch-all bag of rather-random miscellany.

Green, Red, etc color languages & Ada 1983's de facto over-arching guiding principle:
explore what ***programming-in-the-large*** needs to replace the plethora of DoD/NATO languages utilized in vehicular & munitions systems.  (Ada & C++ as Ada's dissenting counter-culture successfully taught the world to think bigger, more-disciplined thoughts and aspire to more-sophisticated designs that they would naturally have accomplished in mere Pascal or mere C.)

Ada 1995's de facto over-arching guiding principle:
import into Green Ada 1983 some of the features ***of Red and of C++***, especially OO.  If C++ utilized "Ada 1983 does right" as its mantra, then Ada 1995 effectively utilized "C++ done right" as its counter-mantra as rebuttal or rebuke of C++.

Ada 2005's de facto over-arching guiding principle:
***course-correction*** of Ada 1995 where the OO community criticized.  Although laudable in producing a splendid incremental evolution of Ada, this was a weak mission with merely incremental (i.e., defensive) feature-set.

Ada 2012's de facto over-arching guiding principle:
***dot each i and cross each t*** of Ada 2005.  Although again laudable in producing the best Ada yet, this an extraordinarily weak mission with the feeling that Ada is so mature that Ada will likely change very little from this point forward.

a potential Ada 202X's overt over-arching guiding principle:
A la OCaml & Fortress, rethink how much ***declarative statements*** can preclude imperative statements to make Ada more "math-like".
1) For example, Dmitry Kazahov's idea of setting the Ada 1983-to-2012's data declarations on a new infrastructural foundation of more-primitive declarations.  Perhaps this could permit more of an OCaml-like set of features, regarding type-inference and various "comprehensions", e.g., list-comprehension.
2) For example, providing a wiser not-metatemplate-programming rebuttal/rebuke to C++2011's metatemplate poor-man-functional-programming via kludges in C++ templates, as Round Two of Ada 1995's over-arching guiding mission of "C++ done right".
3) For example, expand Ada's set of programming genres beyond OO/runtime-polymorphic programming, procedural programming, generic/compile-time-parametric-polymorphic programming, parallel programming, etc to include, say, aspect-oriented programming declarations, functional-programming declarations, compile-time reflection to an Ada-like source-code-generating language (e.g., a.app rethought & expanded).

Re: Your wish list for Ada 202X

[J Kimball]

On 04/04/2014 03:20 AM, Stefan.Lucks@uni-weimar.de wrote:
> On Thu, 3 Apr 2014, Jeffrey Carter wrote:
>
>> On 04/03/2014 02:17 PM, Randy Brukardt wrote:
>>>
>>> I : Unbounded_Integer := +1E1000;
>>>
>>> works today.
>>
>> I would like to see the definition of "+".
>
> Second!
>
> My understanding is that 1E1000 is of the pseudo-type Universal Integer, (or maybe Universal Float). But the "+" function cannot have an in-parameter of that type, so that *should* not work.
>
> Randy, please enlighten us!
>
> ------  I  love  the  taste  of  Cryptanalysis  in  the morning!  ------
>      <http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
> --Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany--

On the other hand, using "+" operators in these ways obscures it's real meaning to people and often the compiler. In using a system that combines renames of language-defined and Templates Parser-defined conversion functions things can get rather hairy. Object names usually indicate what's being described, but rarely what type it is. A rich use of the type system makes using "+" boorish.

Re: Your wish list for Ada 202X

[Shark8]

On 25-Mar-14 15:41, Stoik wrote:
> I think that even a casual user of Ada should be able to influence somehow the new version
> of Ada. I wonder what is high on your list of wishes for Ada 202X?

A 'Type attribute would be nice -- there've been a few times where I 
wanted to have one (IIRC, the last time was in dealing w/ generics).

A 'Cursor attribute for arrays might be a good addition, so that you 
could use the indices in calculations inside the new generalized for-loop.

An 'Index attribute might be good for initialization of arrays based on 
a formula:
    A : Array(1..3, 1..3) of Positive:=
         ( others => (A'Index(2)-1)*A'Index(1) + A'Index(2) );
would be [conceptually] equivalent to:
    A : Array(1..3, 1..3) of Positive:= (
        (1, 2, 3),
        (4, 5, 5),
        (7, 8, 9)
      );

Less restrictions (or some form of workaround) on incomplete types as 
formal parameters of generics; it was disappointing to find that they 
did not allow me to quickly, cleanly write out a small 
[test/experimental] implementation of monoids as described in the video 
"Brian Beckman: Don't fear the Monad"
  -- https://www.youtube.com/watch?v=ZhuHCtR3xq8

Re: Your wish list for Ada 202X

[Randy Brukardt]

"J Kimball" <spam@example.com> wrote in message 
news:lhn2ht$v5e$1@loke.gir.dk...
> On 04/04/2014 03:20 AM, Stefan.Lucks@uni-weimar.de wrote:
>> On Thu, 3 Apr 2014, Jeffrey Carter wrote:
>>
>>> On 04/03/2014 02:17 PM, Randy Brukardt wrote:
>>>>
>>>> I : Unbounded_Integer := +1E1000;
>>>>
>>>> works today.
>>>
>>> I would like to see the definition of "+".
>>
>> Second!
>>
>> My understanding is that 1E1000 is of the pseudo-type Universal Integer, 
>> (or maybe Universal Float). But the "+" function cannot have an 
>> in-parameter of that type, so that *should* not work.
>>
>> Randy, please enlighten us!
>
> On the other hand, using "+" operators in these ways obscures it's real 
> meaning to people and
> often the compiler. In using a system that combines renames of 
> language-defined and
> Templates Parser-defined conversion functions things can get rather hairy. 
> Object names
> usually indicate what's being described, but rarely what type it is. A 
> rich use of the type system
>  makes using "+" boorish.

I find this attitude infurating. (And it's wrong, too; literals provide no 
useful type information and adding "+" to the front does not change that 
situation. Taken literally and to the extreme, your thinking implies that 
all overloading of operators is a bad thing because it obscures the types 
involved. But let's stick with the infurating part). Let me give you a bit 
of history:

Very early in the design of Ada, there was a proposal to add a unary 
operator symbol specifically for the purpose converting between types. 
Ichbiah and his team rejected the proposal as "+" already exists and has no 
other useful purpose. They said that "+" should be used for this purpose.

The idea to add a unary operator symbol resurfaces periodically, but it 
always gets shot down because "+" works for that purpose.

OTOH, attempts to actually *use* "+" in that way in the language-defined 
libraries also have always gotten shot down because there is a group which 
cannot stomach using it for non-numeric purposes. For instance, we had 
proposed to add:
    function "+" (A : String) return Unbounded_String renames 
To_Unbounded_String;
to the Unbounded_String package because the conversion here is way too 
wordy. (Most of my packages that use unbounded string start with this 
declaration. The real problem is getting too many such declarations 
colliding.)

The net effect is that Ada has neither an explicit conversion operator nor 
the balls to use "+" as intended. Which makes using language-defined 
packages a wordy mess to the point that I try pretty hard to avoid them. 
That's not how that's supposed to work!

Attitudes such as yours prevent using the language as it was (and is) 
intended. And similar attitudes (on the other side of the debate) prevent 
changing it to make that less controversial. It leaves most people thinking 
the language has no way to do things when in fact the solutions have been 
there ever since the beginning of Ada.

As for the difficulty of figuring out errors in complex expressions --  
remember two things: (1) quality of error handling is not something that the 
standard can changes; and (2) qualified expressions and prefix notation are 
your friend. Compilation is quick enough these days that there is no real 
problem sticking in some qualifications and/or prefix calls to narrow down 
problems in complicated expressions. (And why are you writing complicated 
expressions in the first place? Use some expression functions to break those 
up.)

                                 Randy.

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Jeffrey Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:lhkudj$28t$1@dont-email.me...
> On 04/03/2014 02:17 PM, Randy Brukardt wrote:
>>
>> I : Unbounded_Integer := +1E1000;
>>
>> works today.
>
> I would like to see the definition of "+".

I missed that someone wrote a literal that's insanely large. They should 
simply have written:

I : Unbounded_Integer := (raise Storage_Error);

because that's what will happen. I was thinking about more realistic cases:

Thousand : Unbounded_Integer := +1000;

But anyway, what works today for this *exact* literal (and not the more 
realistic cases I was thinking about):

Really_Large : Unbounded_Integer := +10**1000; -- Or as a stickler 
+1*(+10**1000);

alternatively:

Really_Large : Unbounded_Integer := Value("1E1000");

[since you're going to have Image and Value routines anyway].

"+" looks like:

type Largest_Int is range System.Min_Int .. System.Max_Int;

function "+" (Right : Largest_Int) return Unbounded_String;

I have an 64-bit math package for Janus/Ada that works exactly this way 
(need to it deal with some returns from OS operations), and it works well. 
Most of the literals that are needed are small (0, 1, 2, 10) and it's much 
preferable to write them using "+" rather than some unwieldy function name 
(To_Huge_Integer?).

One could do something similar with Value if large literals were really 
common, but I doubt that they'll appear in expressions very often.

                                      Randy.

Re: Your wish list for Ada 202X

[Shark8]

On 04-Apr-14 14:43, Randy Brukardt wrote:
> (2) qualified expressions and prefix notation are your friend.

Yes!
There should be little to no aversion to using Some_Type'( XXX + YYY ); 
or whatever. Yes it's wordy, but it ALSO makes your intent explicit, 
saying to your future self, other developers, maintainers, etc "This is 
working with *this* particular type."

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:f17effcf-af74-4a1d-9393-4149fe5a666c@googlegroups.com...
...
>Ada 2012's de facto over-arching guiding principle:
>***dot each i and cross each t*** of Ada 2005.  Although again laudable in
> producing the best Ada yet, this an extraordinarily weak mission with the
> feeling that Ada is so mature that Ada will likely change very little from 
> this
> point forward.

That's wrong. There really were two overarching principles for Ada 2012:
(1) Bring contract-oriented programming to the Ada mainstream;
(2) Embrace the shift to container-oriented programming by making the set of 
containers richer and easier to use.

Almost everything that was done falls into one of these two categories. The 
real-time stuff does not, but that's mainly handled by a separate group from 
the main Ada development effort -- we just try to make their ideas fit into 
the Standard.

For instance, all of the expanded expression features exist mainly to make 
it more practical to write contract expressions and to allow compilers and 
tools to analyze them. Aspect clauses come from the realization that pragmas 
just don't cut it for defining contracts (which drove the wider realization 
that they really don't cut it for anything entity-specific). The iterator 
features exist to make iterating over a container much more like iterating 
over a built-in data structure. Same for the indexing and generalized 
reference features.

It's too early to say what the goal for the next version of Ada will be. 
Surely there will be some clean-up of existing features (there always is), 
but that's not a very good reason for a new language standard. (That's more 
the job of a Corrigendum, one of which is likely in the next year or so.) 
Most likely, I would expect a push for finer-grained parallelism, and 
possibly for additional contract features. But I really don't know. We're 
unlikely to turn around so quickly this time; while the feeling was that Ada 
2005 wasn't quite finished [needed bounded containers, contract features, 
etc.], there is no such feeling for Ada 2012. I think we'll need to see 
clear needs from the user community before jumping in again (but I could be 
wrong).

                                       Randy.

Re: Your wish list for Ada 202X

[Luke A. Guest]

"Randy Brukardt" <randy@rrsoftware.com> wrote:
> Very early in the design of Ada, there was a proposal to add a unary 
> operator symbol specifically for the purpose converting between types. 
> Ichbiah and his team rejected the proposal as "+" already exists and has no 
> other useful purpose. They said that "+" should be used for this purpose.

I don't get the idea of using plus as a conversion operator, I'd this so e
mathematical notation I've not come across?

Luke

Re: Your wish list for Ada 202X

[Jeffrey Carter]

On 04/04/2014 01:53 PM, Randy Brukardt wrote:
>
> I missed that someone wrote a literal that's insanely large. They should
> simply have written:
>
> I : Unbounded_Integer := (raise Storage_Error);
>
> because that's what will happen. I was thinking about more realistic cases:

1E1_000 is hardly insanely large for an Unbounded_Integer type. It should take 
less than 420 bytes to store that value. And being unbounded, they're probably 
on the heap.

> Really_Large : Unbounded_Integer := +10**1000; -- Or as a stickler
> +1*(+10**1000);
>
> alternatively:
>
> Really_Large : Unbounded_Integer := Value("1E1000");

Sure, because these are packages rather than language support for unbounded 
integers. Such support should allow all literals the compiler can handle. Every 
Ada compiler I've used could handle

Really_Large : constant := 1E1_000;
Almost_Large : constant :=   1E999;

X : Positive := 28 * Really_Large / Almost_Large;

-- 
Jeff Carter
"He didn't get that nose from playing ping-pong."
Never Give a Sucker an Even Break
110

Re: Your wish list for Ada 202X

[Peter Chapin]

On 2014-04-04 14:31, Dan'l Miller wrote:

> a potential Ada 202X's overt over-arching guiding principle:

I don't think Ada should try to become a functional language. I doubt if
it could do so in a reasonable way while still being compatible to
itself and maintaining its coherence. If you need to program
functionally, don't use Ada. I can live with that.

Ada was originally designed for embedded systems development so it seems
natural for Ada 202X to continue with that focus. In that line enhanced
support for parallelism, as Randy mentioned, seems like a logical step.

Abstract concepts from languages with a theoretical focus (such as
higher kinded types, metaprogramming, declarative programming, etc) just
don't seem to be what Ada is about.

I realize this might scandalize some people here, but I honestly see Ada
as a similar kind of language as C. It is a systems oriented language
intended for "down and dirty" control of hardware, etc. It is, of
course, much safer than C and much better at programming in the large.
(It probably makes more sense to compare Ada to C++). However, in the
grand scheme of programming languages I see Ada, C, and C++ all hanging
out together and well away from the Pythons, the Lisps, the MLs, and the
Prologs.

Peter

Re: Your wish list for Ada 202X

[Pascal Obry]

Le dimanche 30 mars 2014 à 21:33 +0200, Dmitry A. Kazakov a écrit : 
> On Sun, 30 Mar 2014 21:02:00 +0200, Pascal Obry wrote:
> 
> > Le dimanche 30 mars 2014 à 05:28 -0700, francois_fabien@hotmail.com a
> > écrit : 
> >> One wish to ease Input/output :
> >> To have some equivalent of C primitive : printf("%c %c %c %c %c \n %c %c %c %c %c \n",
> > 
> > Well, this is possible in Ada with some coding of a package, one could
> > write something like (maybe already implemented by someone, I remember a
> > simple_io package or something like that):
> > 
> >    Formatted_Print 
> >       ("%c %c %c %c %c \n %c %c %c %c %c \n"
> >        & Var1 & Var2 & Var3 & Var4 & Var5 & Var6 & Var7 & Var8);
> > 
> > You just have to code the Formatted_Print routine once for all. No big
> > deal:
> > 
> >    type Formatted_String is private;
> > 
> >    Format_Error : exception;
> > 
> >    function "&" 
> >       (F : Formatted_String; V : Character) return Formatted_String;
> >    function "&" 
> >       (F : Formatted_String; V : Integer) return Formatted_String;
> >    function "&" 
> >       (F : Formatted_String; V : Float) return Formatted_String;
> >    ...
> > 
> >    procedure Formatted_Print (F : Formatted_String);
> > 
> >    procedure Formatted_Print 
> >       (File : Text_IO.File_Type; 
> >        F    : Formatted_String);
> 
> I did such things, it is not so simple.
> 

GNAT has now support for formatted string.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

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

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

Re: Your wish list for Ada 202X

[Georg Bauhaus]

On 05/04/14 10:28, Pascal Obry wrote:
>>>     procedure Formatted_Print
>>> > >       (File : Text_IO.File_Type;
>>> > >        F    : Formatted_String);
>> >
>> >I did such things, it is not so simple.
>> >
> GNAT has now support for formatted string.

Where would I find this support?

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Wed, 2 Apr 2014 17:39:06 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1cdsyxjzsfgzm.1synpaujysv21$.dlg@40tude.net...
> ...
>>>> Of course The former
>>>> would be greatly preferable. This requires yet another feature Ada 
>>>> lacks -
>>>> interface inheritance. Unbounded_String must drop parent's
>>>> implementation/representation and inherit only the interface.
>>>
>>> That's not the problem at all. (The parent here would have no
>>> representation, so there is nothing to drop.)
>>
>> Unbounded_String will be derived from String, or String derived from
>> Unbounded_String. The point is to keep it a hierarchy.
> 
> Why? There is no interesting relationship between String and 
> Unbounded_String other than the interface (which is inherited from the root 
> type).

The relationship is that you can mix Unbounded_String and String in
operations like "&".

> There is no opportunity to share implementations, which is the other 
> reason to inherit one from another.

Most of implementations of String can be shared by Unbounded_String. This
is what people do manually all the time converting Unbounded_String to
String and back.

> Just inheriting things because something *thinks* they should be related is 
> silly. There is no advantage to using String'Class (if such a thing existed) 
> rather than Root_String'Class, since all the former does is restrict what 
> your subprogram can do; it doesn't add any capability.

You have just said that constrained types are useless. What is the
advantage of using String (1..80). It does not add any capability...

>> And the real problem
>> with all that is that there is more than one vector of inheritance:
>> 1. memory management (fixed, bounded, unbounded)
>> 2. range (character, wide_character, wide_wide_character)
>> 3. encoding (UCS-4, UCS-2, UTF-8, ASCII)
> 
> 1 and 3 are irrelevant, because they shouldn't have any effect on the 
> interface -- they're things that should be totally hidden outside of 
> streaming for 3. Perhaps 2 should have some affect on the interfaces, but 
> that's easily handled with a second level of abtsract types defining those 
> interfaces.

Presently 1-3 are exposed, and I don't understand how you are you going to
hide them:

   type A (Length : Positive) is record
       X : String (1..Length);
   end record;

   type B is record
       X : Unbounded_String;
   end record;

Looks a quite visible difference to me.

> Besides, 1 can totally be defined after the fact with packages. That's the 
> model that I'm suggesting.

This is equivalent to deriving from fixed string, which is the common
denominator. 

> "Unbounded_String" is a container for a 
> Root_String'Class type; it adds unbounded memory management to whatever the 
> string type does. There is no reason that one has to do that as part of the 
> string abstraction.

But then you necessarily loose all operations String cannot have, e.g.
Append, Replace, etc. The idea is of course that Unbounded_String,
Unbounded_Wide_Wide_String, Unbounded_UTF8_String share this interface.

>>> The problem is that Unbounded_String defines operations like
>>>
>>>       function "&" (Left : Unbounded_String; Right : String) return
>>> Unbounded_String;
>>>
>>> which would be ambiguous with the normal "&" if both String and
>>> Unbounded_String had string literals (as they must for Root_String_Type 
>>> to
>>> work).
>>
>> No, it is unambiguous, because provided Unbounded_String is a descendant 
>> of String (or reversely)
>>
>>   function "&" (Left : Unbounded_String; Right : String) return
>>      Unbounded_String;
>>
>> is a part of the implementation of the MD operation
>>
>>   function "&" (Left, Right : Root_String_Type) return
>>      Root_String_Type;
> 
> That doesn't help at all. We still don't know which body to execute when a 
> string literal is used, because it matches all string types.

You are mixing different issues. As I said, there is no ambiguity in "&".
Literals is a completely different case. They are ambiguous already.

> You would have 
> to qualify all string literals in an MD world, and that's something 
> programmers would never tolerate.

Ambiguity of literals can be resolved using preference rules like ones
invented for Universal_Integer. We could introduce Universal_String etc.

Another method could be making Latin-1 literals contravariant String, i.e.

package Dont_Make_Me_Primitive is
   function "A" return String;
   function "AB" return String;
   function "ABC" return String;
   ...
end Dont_Make_Me_Primitive;

not inherited by Unbounded_String, Wide_String etc. That will introduce
desired preference.

And, yes, you will be able to assign "ABC" to Unbounded_String because ":="
is a MD operation with one body dealing with that:

   procedure ":=" (Left : in out Unbounded_String; Right : String);

Otherwise, yes, preference rules are necessary to resolve

   A & B & C

Between

   String'(A & B) & C

and

   Unbounded_String'(A & B) & C

>>> We can't get rid of these problematical operations -- it would be way too
>>> incompatible. So new packages is the only way to go.
>>
>> You can, and everything will stay compatible if the type system is fixed
>> first (MD, MI etc). Within present type system it is indeed unfixable and
>> moreover, new packages will likely become as messy as the old ones.
> 
> As I said before, I am skeptical that an MD system (even ignoring MI) could 
> be implemented efficiently enough to be used in critical operations like 
> strings. As soon as you go to MD, the linear tag model has to ba abandoned, 
> and some sort of search mechanism used for finding bodies to dispatch to.

An MD operation needs an N-D array indexed by tags of controlling
arguments. Dispatching is indexing the array.

(However there are serious problems with implementation of MD which I have
no idea how to resolve. MI is much simpler)

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

Re: Your wish list for Ada 202X

[Pascal Obry]

Le samedi 05 avril 2014 à 13:06 +0200, Georg Bauhaus a écrit : 
> On 05/04/14 10:28, Pascal Obry wrote:
> >>>     procedure Formatted_Print
> >>> > >       (File : Text_IO.File_Type;
> >>> > >        F    : Formatted_String);
> >> >
> >> >I did such things, it is not so simple.
> >> >
> > GNAT has now support for formatted string.
> 
> Where would I find this support?

When it will be merged in FSF GNAT or in GNAT GPL 2015 I suppose.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

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

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

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Luke A. Guest" <laguest@archeia.com> wrote in message 
news:1893909476418340554.191505laguest-archeia.com@nntp.aioe.org...
> "Randy Brukardt" <randy@rrsoftware.com> wrote:
>> Very early in the design of Ada, there was a proposal to add a unary
>> operator symbol specifically for the purpose converting between types.
>> Ichbiah and his team rejected the proposal as "+" already exists and has 
>> no
>> other useful purpose. They said that "+" should be used for this purpose.
>
> I don't get the idea of using plus as a conversion operator, I'd this so e
> mathematical notation I've not come across?

The second part above is so garbled that I can't guess how to respond to it. 
The first part is easy, one camp says unary "+" doesn't have a (useful) 
mathematical meaning, so let's ignore that meaning and use the operator for 
conversions. The other camp says that unary "+" has a (useless) mathematical 
meaning that should be left alone. Because of the dynamics of the Ada 
standards process, neither camp ever gets to lead and the net effect is that 
we never get *any* conversion operator. Which we've needed from day 1, IMHO.

                  Randy. 

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1aa804jg9qq4o$.wdiq33yo621l.dlg@40tude.net...
> On Wed, 2 Apr 2014 17:39:06 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:1cdsyxjzsfgzm.1synpaujysv21$.dlg@40tude.net...
>> ...
>>>>> Of course The former
>>>>> would be greatly preferable. This requires yet another feature Ada
>>>>> lacks -
>>>>> interface inheritance. Unbounded_String must drop parent's
>>>>> implementation/representation and inherit only the interface.
>>>>
>>>> That's not the problem at all. (The parent here would have no
>>>> representation, so there is nothing to drop.)
>>>
>>> Unbounded_String will be derived from String, or String derived from
>>> Unbounded_String. The point is to keep it a hierarchy.
>>
>> Why? There is no interesting relationship between String and
>> Unbounded_String other than the interface (which is inherited from the 
>> root
>> type).
>
> The relationship is that you can mix Unbounded_String and String in
> operations like "&".

Yeah, just like mixing apples and oranges. Mixed operations are not the Ada 
way of typing.

>> There is no opportunity to share implementations, which is the other
>> reason to inherit one from another.
>
> Most of implementations of String can be shared by Unbounded_String. This
> is what people do manually all the time converting Unbounded_String to
> String and back.

No, not really. Most implementations of Root_String'Class could be shared 
amongst string types. But specific implementations are tied to particular 
representations; that's exactly what we want to get rid off.

Moreover, there cannot be automatic sharing of operations; that weakens the 
type system. One only wants to share operations that are explicitly intended 
to be shared; that's the point of declaring packages operating on 
Root_String'Class rather than some specific type.

>> Just inheriting things because something *thinks* they should be related 
>> is
>> silly. There is no advantage to using String'Class (if such a thing 
>> existed)
>> rather than Root_String'Class, since all the former does is restrict what
>> your subprogram can do; it doesn't add any capability.
>
> You have just said that constrained types are useless. What is the
> advantage of using String (1..80). It does not add any capability...

Constrained types *are* useless -- Ada has no such thing. It only has 
unconstrained types (remember that names only apply to subtypes). And in 
particular, a constrained class-wide type is an evil thing, because it's 
mixing things that should not be mixed: relaxing and tightening constraints 
at the same time.

>>> And the real problem
>>> with all that is that there is more than one vector of inheritance:
>>> 1. memory management (fixed, bounded, unbounded)
>>> 2. range (character, wide_character, wide_wide_character)
>>> 3. encoding (UCS-4, UCS-2, UTF-8, ASCII)
>>
>> 1 and 3 are irrelevant, because they shouldn't have any effect on the
>> interface -- they're things that should be totally hidden outside of
>> streaming for 3. Perhaps 2 should have some affect on the interfaces, but
>> that's easily handled with a second level of abtsract types defining 
>> those
>> interfaces.
>
> Presently 1-3 are exposed, and I don't understand how you are you going to
> hide them:
>
>   type A (Length : Positive) is record
>       X : String (1..Length);
>   end record;
>
>   type B is record
>       X : Unbounded_String;
>   end record;
>
> Looks a quite visible difference to me.

Object declarations of course use concrete, specific types. So what's your 
point? The majority of operations would take Root_String'Class and thus work 
on any object. Ones that don't would have been restricted for some good 
reason, and would work as now. What's so hard about that?

>> Besides, 1 can totally be defined after the fact with packages. That's 
>> the
>> model that I'm suggesting.
>
> This is equivalent to deriving from fixed string, which is the common
> denominator.

No, I'm deriving from an abstract type with no representation. There's a 
huge difference.

>> "Unbounded_String" is a container for a
>> Root_String'Class type; it adds unbounded memory management to whatever 
>> the
>> string type does. There is no reason that one has to do that as part of 
>> the
>> string abstraction.
>
> But then you necessarily loose all operations String cannot have, e.g.
> Append, Replace, etc. The idea is of course that Unbounded_String,
> Unbounded_Wide_Wide_String, Unbounded_UTF8_String share this interface.

Ada.Strings.Fixed has all of those operations. Why would we lose them? The 
problem with Ada.Strings as it is is that the operations are subtly 
different; there's no good reason for that.

...
>> You would have
>> to qualify all string literals in an MD world, and that's something
>> programmers would never tolerate.
>
> Ambiguity of literals can be resolved using preference rules like ones
> invented for Universal_Integer. We could introduce Universal_String etc.

That doesn't work at all; universal integer only has a preference against 
itself. All other types are equal. So you still have problem of being unable 
to tell between String and Unbounded_String. And preference rules for 
user-defined types cause all kinds of visibility and maintenance headaches.



> Another method could be making Latin-1 literals contravariant String, i.e.
>
> package Dont_Make_Me_Primitive is
>   function "A" return String;
>   function "AB" return String;
>   function "ABC" return String;
>   ...
> end Dont_Make_Me_Primitive;
>
> not inherited by Unbounded_String, Wide_String etc. That will introduce
> desired preference.

Then Unbounded_String will not have any literals, and you'd still have 
problems with Wide_Wide_String vs. String.

> And, yes, you will be able to assign "ABC" to Unbounded_String because 
> ":="
> is a MD operation with one body dealing with that:
>
>   procedure ":=" (Left : in out Unbounded_String; Right : String);

But that's unimplementable.

> Otherwise, yes, preference rules are necessary to resolve
>
>   A & B & C
>
> Between
>
>   String'(A & B) & C
>
> and
>
>   Unbounded_String'(A & B) & C

Right, and such preferences are always trouble in a programming language. 
They are a prime source of beaujolais effects, which Ada considers 
completely unacceptable. (Adding or removing a declaration should never 
change a legal program into a different legal program with a different 
meaning.)

>>>> We can't get rid of these problematical operations -- it would be way 
>>>> too
>>>> incompatible. So new packages is the only way to go.
>>>
>>> You can, and everything will stay compatible if the type system is fixed
>>> first (MD, MI etc). Within present type system it is indeed unfixable 
>>> and
>>> moreover, new packages will likely become as messy as the old ones.
>>
>> As I said before, I am skeptical that an MD system (even ignoring MI) 
>> could
>> be implemented efficiently enough to be used in critical operations like
>> strings. As soon as you go to MD, the linear tag model has to ba 
>> abandoned,
>> and some sort of search mechanism used for finding bodies to dispatch to.
>
> An MD operation needs an N-D array indexed by tags of controlling
> arguments. Dispatching is indexing the array.

Sure, but you can't represent the array that way, because you don't know N 
at compile-time (someone can define new types and link them in after the 
fact). And even if you did, it would be an impracticaly large a data 
structure in most cases. (Consider that there are something like 20 string 
types in a Root_String'Class model, or that there are around 100 window 
types in Claw.) That being the case, you have to use some sort of lookup 
scheme, and whether that can be efficient enough is a question.

> (However there are serious problems with implementation of MD which I have
> no idea how to resolve. MI is much simpler)

I suppose MI is simpler, but it has a similar problem with tag construction. 
(At least there is only one dimension for interfaces; full MI would turn 
things into a much worse situation, as hidden types would have to be 
allowed - and then its possible for a type to have multiple copies of the 
same interface.)

                               Randy.

Re: Your wish list for Ada 202X

[J Kimball]

On 04/07/2014 07:47 PM, Randy Brukardt wrote:
> "Luke A. Guest" <laguest@archeia.com> wrote in message
> news:1893909476418340554.191505laguest-archeia.com@nntp.aioe.org...
>> "Randy Brukardt" <randy@rrsoftware.com> wrote:
>>> Very early in the design of Ada, there was a proposal to add a unary
>>> operator symbol specifically for the purpose converting between types.
>>> Ichbiah and his team rejected the proposal as "+" already exists and has
>>> no
>>> other useful purpose. They said that "+" should be used for this purpose.
>>
>> I don't get the idea of using plus as a conversion operator, I'd this so e
>> mathematical notation I've not come across?
>
> The second part above is so garbled that I can't guess how to respond to it.
> The first part is easy, one camp says unary "+" doesn't have a (useful)
> mathematical meaning, so let's ignore that meaning and use the operator for
> conversions. The other camp says that unary "+" has a (useless) mathematical
> meaning that should be left alone. Because of the dynamics of the Ada
> standards process, neither camp ever gets to lead and the net effect is that
> we never get *any* conversion operator. Which we've needed from day 1, IMHO.
>
>                    Randy.
>
>

Maybe they could agree on a new unused operator being added. Of course mathematics uses every known graphic in some area. We might be able to agree that an addition should be in the ASCII code points for Unicode which leaves a couple of things that stand out that aren't already in use in Ada. "~" seems like a good character with a derivative meaning "approximates" which often all a conversion can do.

UBString := ~String; -- Would drive people from some linguisitic backgrounds crazy, though.

Re: Your wish list for Ada 202X

[Jeffrey Carter]

On 04/07/2014 09:43 PM, J Kimball wrote:
>
> Maybe they could agree on a new unused operator being added. Of course
> mathematics uses every known graphic in some area. We might be able to agree
> that an addition should be in the ASCII code points for Unicode which leaves a
> couple of things that stand out that aren't already in use in Ada. "~" seems
> like a good character with a derivative meaning "approximates" which often all a
> conversion can do.
>
> UBString := ~String; -- Would drive people from some linguisitic backgrounds
> crazy, though.

I've suggested "\" in the past, to drive C people crazy.

-- 
Jeff Carter
"Crucifixion's a doddle."
Monty Python's Life of Brian
82

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Mon, 7 Apr 2014 20:15:10 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1aa804jg9qq4o$.wdiq33yo621l.dlg@40tude.net...
>> On Wed, 2 Apr 2014 17:39:06 -0500, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:1cdsyxjzsfgzm.1synpaujysv21$.dlg@40tude.net...
>>> ...
>>>>>> Of course The former
>>>>>> would be greatly preferable. This requires yet another feature Ada
>>>>>> lacks -
>>>>>> interface inheritance. Unbounded_String must drop parent's
>>>>>> implementation/representation and inherit only the interface.
>>>>>
>>>>> That's not the problem at all. (The parent here would have no
>>>>> representation, so there is nothing to drop.)
>>>>
>>>> Unbounded_String will be derived from String, or String derived from
>>>> Unbounded_String. The point is to keep it a hierarchy.
>>>
>>> Why? There is no interesting relationship between String and
>>> Unbounded_String other than the interface (which is inherited from the 
>>> root
>>> type).
>>
>> The relationship is that you can mix Unbounded_String and String in
>> operations like "&".
> 
> Yeah, just like mixing apples and oranges.

Like mixing McIntosh and Jonathan apples.

> Mixed operations are not the Ada way of typing.

It is Ada's way of SUBtyping. Obviously Unbounded_String and String are
related subtypes, promoted to types due to implementation reasons only.

>>> There is no opportunity to share implementations, which is the other
>>> reason to inherit one from another.
>>
>> Most of implementations of String can be shared by Unbounded_String. This
>> is what people do manually all the time converting Unbounded_String to
>> String and back.
> 
> No, not really. Most implementations of Root_String'Class could be shared 
> amongst string types.

That would be very inconvenient. Certainly, less class-wide operations are
provided better is the design.

> But specific implementations are tied to particular 
> representations; that's exactly what we want to get rid off.

How a specific implementation could be tied to a class-wide type? That does
not make sense.

The model where operations are primitive has the decisive advantage that
the operation can be inherited or overridden in order to provide a more
efficient version.

> Moreover, there cannot be automatic sharing of operations; that weakens the 
> type system. One only wants to share operations that are explicitly intended 
> to be shared; that's the point of declaring packages operating on 
> Root_String'Class rather than some specific type.

I don't understand the term "shared operation."

If you don't want to provide an implementation you declare the operation
abstract. If you don't want an operation in the class, you move it into the
body. Where is a problem?

>>> Just inheriting things because something *thinks* they should be related 
>>> is silly. There is no advantage to using String'Class (if such a thing existed)
>>> rather than Root_String'Class, since all the former does is restrict what
>>> your subprogram can do; it doesn't add any capability.
>>
>> You have just said that constrained types are useless. What is the
>> advantage of using String (1..80). It does not add any capability...
> 
> Constrained types *are* useless -- Ada has no such thing. It only has 
> unconstrained types (remember that names only apply to subtypes). And in 
> particular, a constrained class-wide type is an evil thing, because it's 
> mixing things that should not be mixed: relaxing and tightening constraints 
> at the same time.

OK, constraining is useless, discriminants are evil, specific instances of
classes are wrong. We have to agree to disagree.

>>>> And the real problem
>>>> with all that is that there is more than one vector of inheritance:
>>>> 1. memory management (fixed, bounded, unbounded)
>>>> 2. range (character, wide_character, wide_wide_character)
>>>> 3. encoding (UCS-4, UCS-2, UTF-8, ASCII)
>>>
>>> 1 and 3 are irrelevant, because they shouldn't have any effect on the
>>> interface -- they're things that should be totally hidden outside of
>>> streaming for 3. Perhaps 2 should have some affect on the interfaces, but
>>> that's easily handled with a second level of abtsract types defining 
>>> those
>>> interfaces.
>>
>> Presently 1-3 are exposed, and I don't understand how you are you going to
>> hide them:
>>
>>   type A (Length : Positive) is record
>>       X : String (1..Length);
>>   end record;
>>
>>   type B is record
>>       X : Unbounded_String;
>>   end record;
>>
>> Looks a quite visible difference to me.
> 
> Object declarations of course use concrete, specific types. So what's your 
> point?

The point is that all aspects I mentioned cannot be hidden = have crucial
effect on the interface and is in part the interface.

> The majority of operations would take Root_String'Class and thus work 
> on any object. Ones that don't would have been restricted for some good 
> reason, and would work as now. What's so hard about that?

It does not make any sense to me. Consider the operation Append. Which
class does it belong to? Does it act on String? Is the argument UCS-2?

>>> Besides, 1 can totally be defined after the fact with packages. That's 
>>> the model that I'm suggesting.
>>
>> This is equivalent to deriving from fixed string, which is the common
>> denominator.
> 
> No, I'm deriving from an abstract type with no representation. There's a 
> huge difference.

No difference whatsoever. We are talking about interfaces. The interface of
Unbounded_String is not the interface of String. When you force a set of
types to one class you must drop parts of the interfaces uncommon to all
members. This is why single parent will never work for any more or less
non-trivial set of types. String types and numeric types are such sets. It
is not even worth trying. The result is doomed.

>>> "Unbounded_String" is a container for a
>>> Root_String'Class type; it adds unbounded memory management to whatever 
>>> the string type does. There is no reason that one has to do that as part of 
>>> the string abstraction.
>>
>> But then you necessarily loose all operations String cannot have, e.g.
>> Append, Replace, etc. The idea is of course that Unbounded_String,
>> Unbounded_Wide_Wide_String, Unbounded_UTF8_String share this interface.
> 
> Ada.Strings.Fixed has all of those operations.

Append (S, SUNDANESE_LETTER_KHA);

>>> You would have
>>> to qualify all string literals in an MD world, and that's something
>>> programmers would never tolerate.
>>
>> Ambiguity of literals can be resolved using preference rules like ones
>> invented for Universal_Integer. We could introduce Universal_String etc.
> 
> That doesn't work at all; universal integer only has a preference against 
> itself. All other types are equal.

They will have no literals of their own, in this model.

>> Another method could be making Latin-1 literals contravariant String, i.e.
>>
>> package Dont_Make_Me_Primitive is
>>   function "A" return String;
>>   function "AB" return String;
>>   function "ABC" return String;
>>   ...
>> end Dont_Make_Me_Primitive;
>>
>> not inherited by Unbounded_String, Wide_String etc. That will introduce
>> desired preference.
> 
> Then Unbounded_String will not have any literals,

Yes, it will inherit to String and thus be able to mix String in its
operations, that will be equivalent to having literals/

> and you'd still have 
> problems with Wide_Wide_String vs. String.

No, because wider literals will go to Wide_String and most wide literal to
Wide_Wide_String. The idea is to dissect literals according to the code
point planes.

>> And, yes, you will be able to assign "ABC" to Unbounded_String because 
>> ":=" is a MD operation with one body dealing with that:
>>
>>   procedure ":=" (Left : in out Unbounded_String; Right : String);
> 
> But that's unimplementable.

Assignment is an operation as any other.

>> Otherwise, yes, preference rules are necessary to resolve
>>
>>   A & B & C
>>
>> Between
>>
>>   String'(A & B) & C
>>
>> and
>>
>>   Unbounded_String'(A & B) & C
> 
> Right, and such preferences are always trouble in a programming language.

It is the nature of things. When you define an n-ary operation on a type
hierarchy you have the problem. You can say that is why you don't want
n-ary operation and/or type hierarchies and go straight back to FORTRAN-IV. 

But large scale and safe software design is unthinkable without this stuff.
So either you force the programmer to do all the work manually, see string
types and operations in Ada for the fruits of this approach, or else you
provide a reasonable support in the language for dealing with real-world
problems, making programmer's life safer and easier.
 
> They are a prime source of beaujolais effects, which Ada considers 
> completely unacceptable. (Adding or removing a declaration should never 
> change a legal program into a different legal program with a different 
> meaning.)

Hierarchies of types are not insulated against each other. You cannot
simply add or remove declaration of an operation in the hierarchy. That
will lead to changes in the dispatching tables, need to define/override
something, if the operation is abstract, which is why freezing rules are
here etc.

It is the nature of a constraint which is far more important than any
"beaujolais effects" - that no dispatch can fail at run-time.

All slots of any dispatching table must be statically checked for being
either properly inherited or overridden. That *necessarily* requires making
something illegal which otherwise would be legal. "No-beaujolais" is a
nicety for separate compilation, another is strong typing imperative. I
gladly trade former for the latter if necessary.

>>>>> We can't get rid of these problematical operations -- it would be way 
>>>>> too incompatible. So new packages is the only way to go.
>>>>
>>>> You can, and everything will stay compatible if the type system is fixed
>>>> first (MD, MI etc). Within present type system it is indeed unfixable 
>>>> and moreover, new packages will likely become as messy as the old ones.
>>>
>>> As I said before, I am skeptical that an MD system (even ignoring MI) 
>>> could be implemented efficiently enough to be used in critical operations like
>>> strings. As soon as you go to MD, the linear tag model has to ba abandoned,
>>> and some sort of search mechanism used for finding bodies to dispatch to.
>>
>> An MD operation needs an N-D array indexed by tags of controlling
>> arguments. Dispatching is indexing the array.
> 
> Sure, but you can't represent the array that way, because you don't know N 
> at compile-time (someone can define new types and link them in after the 
> fact).

I don't need to know it at compile time. I only need to know its subarray
that includes the types visible in the context being compiled. That
subarray is sufficient to get through. N must be known at bind/link-time.

> And even if you did, it would be an impracticaly large a data 
> structure in most cases. (Consider that there are something like 20 string 
> types in a Root_String'Class model,

N is not the total number of related types, N is the depth of the given
hierarchy. You will have to map Tag to some dense index in the operation's
inheritance path and then go into the array with this index. Raw tag is a
poor index.

>> (However there are serious problems with implementation of MD which I have
>> no idea how to resolve. MI is much simpler)
> 
> I suppose MI is simpler, but it has a similar problem with tag construction. 
> (At least there is only one dimension for interfaces; full MI would turn 
> things into a much worse situation, as hidden types would have to be 
> allowed - and then its possible for a type to have multiple copies of the 
> same interface.)

That is a highly desired effect: to support additive model of inheritance.
E.g. additive MI from doubly-linked list element.

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

Re: Your wish list for Ada 202X

[G.B.]

On 08.04.14 11:15, Dmitry A. Kazakov wrote:
>> Constrained types*are*  useless -- Ada has no such thing. It only has
>> >unconstrained types (remember that names only apply to subtypes). And in
>> >particular, a constrained class-wide type is an evil thing, because it's
>> >mixing things that should not be mixed: relaxing and tightening constraints
>> >at the same time.
> OK, constraining is useless, discriminants are evil, specific instances of
> classes are wrong. We have to agree to disagree.

Reminder: an Ada "type", formally, is different from the "type"
that Dmitry has in mind (seeing subtype constraints as
establishing a "type", IIRC, which, for the most part, it isn't
doing, in Ada).

It might help to have a USENET specific type of link
that establishes evidence of the difference in terminology.

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Tue, 08 Apr 2014 12:15:45 +0200, G.B. wrote:

> On 08.04.14 11:15, Dmitry A. Kazakov wrote:
>>> Constrained types*are*  useless -- Ada has no such thing. It only has
>>> >unconstrained types (remember that names only apply to subtypes). And in
>>> >particular, a constrained class-wide type is an evil thing, because it's
>>> >mixing things that should not be mixed: relaxing and tightening constraints
>>> >at the same time.
>> OK, constraining is useless, discriminants are evil, specific instances of
>> classes are wrong. We have to agree to disagree.
> 
> Reminder: an Ada "type", formally, is different from the "type"
> that Dmitry has in mind (seeing subtype constraints as
> establishing a "type", IIRC, which, for the most part, it isn't
> doing, in Ada).
> 
> It might help to have a USENET specific type of link
> that establishes evidence of the difference in terminology.

Can be found in any textbook:

    type is a set of values bound by operations defined on these values

Yes, Ada's subtype is a type, no less than C++'s class is.

But however you call it, Randy's point was about putting a constraint on
some set of values being useless. I can guess that his position is
motivated by the ideas of LSP subtyping. Surely Ada's subtyping is in
contradiction with LSP-subtyping. That does not make Ada's subtyping any
useless or evil. On the contrary, it rather does the LSP-subtyping.

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

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:yl8s1sbhw0lw.1bhypcrvreord.dlg@40tude.net...
> On Mon, 7 Apr 2014 20:15:10 -0500, Randy Brukardt wrote:
...
>> Mixed operations are not the Ada way of typing.
>
> It is Ada's way of SUBtyping. Obviously Unbounded_String and String are
> related subtypes, promoted to types due to implementation reasons only.

Obvious to you only. Any single program/subsystem should stick to a single 
string type. The fact that you can't do that in Ada (unless that type is 
String) is the bug that needs to be fixed.

>>>> There is no opportunity to share implementations, which is the other
>>>> reason to inherit one from another.
>>>
>>> Most of implementations of String can be shared by Unbounded_String. 
>>> This
>>> is what people do manually all the time converting Unbounded_String to
>>> String and back.
>>
>> No, not really. Most implementations of Root_String'Class could be shared
>> amongst string types.
>
> That would be very inconvenient. Certainly, less class-wide operations are
> provided better is the design.

"In"convinient? Why? Use all and prefix notation lets one use class-wide 
operations in many circumstances. And in any case, the whole point is to 
eliminate the requirement to use a single, specific string type for 
operations that should be generic (generic in the English, not Ada, sense).

>> But specific implementations are tied to particular
>> representations; that's exactly what we want to get rid off.
>
> How a specific implementation could be tied to a class-wide type? That 
> does
> not make sense.

Very, very little of string operations should be tied at all to any 
particular implementation. In particular, nothing in Ada.Strings.* is 
primitive to string types per-se; they're all higher level operations 
created out of lower-level primitives. They should therefore be class-wide 
so there only needs to be one implementation.

> The model where operations are primitive has the decisive advantage that
> the operation can be inherited or overridden in order to provide a more
> efficient version.

That wouldn't improve the performance enough to matter. If there is a 
problem with this scheme, it's that it could be very inefficient. But that's 
mostly because of the use of dispatching, and that's required for the goal 
to be reached (for most of the existing predefined operations to have 
versions that take/return Root_String'Class rather than String). If we can't 
reach that goal, there is no point to doing this at all.

My experience is that tagged types with lots of primitives are virtually 
un-extendable -- it just takes too much work to create an extension. The 
vast majority of those primitives have to be overridden (unless you are 
using redispatching, which I agree is a bad idea in general), and it just 
slows the process down to the point where nothing gets accomplished. (I 
essentially abandoned work on the Claw Builder for this reason.)

>> Moreover, there cannot be automatic sharing of operations; that weakens 
>> the
>> type system. One only wants to share operations that are explicitly 
>> intended
>> to be shared; that's the point of declaring packages operating on
>> Root_String'Class rather than some specific type.
>
> I don't understand the term "shared operation."
>
> If you don't want to provide an implementation you declare the operation
> abstract. If you don't want an operation in the class, you move it into 
> the
> body. Where is a problem?

As above, it's too much work to extend a type that requires overridding more 
than a handful of primitives. It takes 3 days of work to get a compilable, 
testable extension of the window type in the Claw Builder -- anything over 4 
hours or so is unacceptable.

...
>> Object declarations of course use concrete, specific types. So what's 
>> your
>> point?
>
> The point is that all aspects I mentioned cannot be hidden = have crucial
> effect on the interface and is in part the interface.

Umm, no, the "interface" doesn't have anything to do with concrete 
implementations. And since you didn't mention any aspects at all, I'm even 
sure what you're talking about. All you did is declare some components of 
specific types.

Maybe you're talking about the constraints, but we already agreed to 
disagree on that. I don't think they have anything whatsoever to do with the 
interface, and in fact explicitly should *not* be part of the interface.

>> The majority of operations would take Root_String'Class and thus work
>> on any object. Ones that don't would have been restricted for some good
>> reason, and would work as now. What's so hard about that?
>
> It does not make any sense to me. Consider the operation Append. Which
> class does it belong to? Does it act on String? Is the argument UCS-2?

Append takes two operands of Root_String'Class, and returns an 
Root_String'Class with the type of its first argument. What's the problem?

...
>> No, I'm deriving from an abstract type with no representation. There's a
>> huge difference.
>
> No difference whatsoever. We are talking about interfaces. The interface 
> of
> Unbounded_String is not the interface of String.

That's true, but that's a bug. They *should* be the same; only the runtime 
behavior should differ (when exceptions are raised and the like).

> When you force a set of
> types to one class you must drop parts of the interfaces uncommon to all
> members. This is why single parent will never work for any more or less
> non-trivial set of types. String types and numeric types are such sets. It
> is not even worth trying. The result is doomed.

Possibly, but then programming language design in general is doomed. The 
only solutions that would work are crazily inefficient.

But the real truth is that you're confusing the totality of the operations 
of a type with the small targeted part of those operations that form a 
valuable abstraction. Interfaces that are useful are small and targeted. The 
main advantage of Ada's interface types is to mix and match those small 
interfaces on a variety of types. But we don't need to do that here.

The only interface that matters is the one that allows useful operations to 
be constructed on Root_String'Class. Other interfaces are irrelevant, 
because there is nothing that we might want to do with them. (And of course, 
if you want to define other interfaces, go ahead - that's the purpose of 
MI.)

>>>> "Unbounded_String" is a container for a
>>>> Root_String'Class type; it adds unbounded memory management to whatever
>>>> the string type does. There is no reason that one has to do that as 
>>>> part of
>>>> the string abstraction.
>>>
>>> But then you necessarily loose all operations String cannot have, e.g.
>>> Append, Replace, etc. The idea is of course that Unbounded_String,
>>> Unbounded_Wide_Wide_String, Unbounded_UTF8_String share this interface.
>>
>> Ada.Strings.Fixed has all of those operations.
>
> Append (S, SUNDANESE_LETTER_KHA);

Yes, that's good. If the underlying type cannot store the letter, 
Constraint_Error is raised.

As with all tagged types, you trade-off compile-time checking for 
generality. You can't have both (I know people try, but they are mad - 
they'll have just as much luck creating a perpetual motion machine).


>>>> You would have
>>>> to qualify all string literals in an MD world, and that's something
>>>> programmers would never tolerate.
>>>
>>> Ambiguity of literals can be resolved using preference rules like ones
>>> invented for Universal_Integer. We could introduce Universal_String etc.
>>
>> That doesn't work at all; universal integer only has a preference against
>> itself. All other types are equal.
>
> They will have no literals of their own, in this model.

They have no literals now, in this model. You're just describing the way 
things are, and then expect it to work differently.

...
>> and you'd still have
>> problems with Wide_Wide_String vs. String.
>
> No, because wider literals will go to Wide_String and most wide literal to
> Wide_Wide_String. The idea is to dissect literals according to the code
> point planes.

So the behavior of the program changes when the contents of a string literal 
changes? No thanks.

...
>> They are a prime source of beaujolais effects, which Ada considers
>> completely unacceptable. (Adding or removing a declaration should never
>> change a legal program into a different legal program with a different
>> meaning.)
>
> Hierarchies of types are not insulated against each other. You cannot
> simply add or remove declaration of an operation in the hierarchy. That
> will lead to changes in the dispatching tables, need to define/override
> something, if the operation is abstract, which is why freezing rules are
> here etc.
>
> It is the nature of a constraint which is far more important than any
> "beaujolais effects" - that no dispatch can fail at run-time.
>
> All slots of any dispatching table must be statically checked for being
> either properly inherited or overridden. That *necessarily* requires 
> making
> something illegal which otherwise would be legal. "No-beaujolais" is a
> nicety for separate compilation, another is strong typing imperative. I
> gladly trade former for the latter if necessary.

In other words, you are willing to weaken Ada's contracts in order to get 
your supposed "strong typing imperative".

Essentially, in your world, you cannot change a package specification 
because you cannot know what effect such changes have on clients (clients 
that you don't know much about). That means that there is no hope for 
reusable software - the originator of the software has to be able to modify 
it in order to improve or correct it. If that breaks all clients, then 
either one can do nothing at all, or people just have to stick to their 
existing (buggy) versions. Neither is acceptable.


>>>>>> We can't get rid of these problematical operations -- it would be way
>>>>>> too incompatible. So new packages is the only way to go.
>>>>>
>>>>> You can, and everything will stay compatible if the type system is 
>>>>> fixed
>>>>> first (MD, MI etc). Within present type system it is indeed unfixable
>>>>> and moreover, new packages will likely become as messy as the old 
>>>>> ones.
>>>>
>>>> As I said before, I am skeptical that an MD system (even ignoring MI)
>>>> could be implemented efficiently enough to be used in critical 
>>>> operations like
>>>> strings. As soon as you go to MD, the linear tag model has to ba 
>>>> abandoned,
>>>> and some sort of search mechanism used for finding bodies to dispatch 
>>>> to.
>>>
>>> An MD operation needs an N-D array indexed by tags of controlling
>>> arguments. Dispatching is indexing the array.
>>
>> Sure, but you can't represent the array that way, because you don't know 
>> N
>> at compile-time (someone can define new types and link them in after the
>> fact).
>
> I don't need to know it at compile time. I only need to know its subarray
> that includes the types visible in the context being compiled. That
> subarray is sufficient to get through. N must be known at bind/link-time.
>
>> And even if you did, it would be an impracticaly large a data
>> structure in most cases. (Consider that there are something like 20 
>> string
>> types in a Root_String'Class model,
>
> N is not the total number of related types, N is the depth of the given
> hierarchy. You will have to map Tag to some dense index in the operation's
> inheritance path and then go into the array with this index. Raw tag is a
> poor index.

But it's all we have. Sure, you can map a tag (this requires a loop, either 
a brute force lookup or some fancier but much more code-intensive version), 
but that's going to make dispatching far more expensive. You can't do this 
mapping at compile-time because what mapping you need depends on the 
interfaces in use.

>>> (However there are serious problems with implementation of MD which I 
>>> have
>>> no idea how to resolve. MI is much simpler)
>>
>> I suppose MI is simpler, but it has a similar problem with tag 
>> construction.
>> (At least there is only one dimension for interfaces; full MI would turn
>> things into a much worse situation, as hidden types would have to be
>> allowed - and then its possible for a type to have multiple copies of the
>> same interface.)
>
> That is a highly desired effect: to support additive model of inheritance.
> E.g. additive MI from doubly-linked list element.

It doesn't work, though, because you have to know *which* copy of the 
interface you are dispatching through. The operations can be different for 
each such interface (if they can't, you've completely given up on privacy).

You could of course just abandon privacy and maintainability for your 
type-system, but the result would bear no resemblance to Ada.

                           Randy.

Re: Your wish list for Ada 202X

[Randy Brukardt]

"J Kimball" <spam@example.com> wrote in message 
news:lhvuom$g1$1@loke.gir.dk...
> On 04/07/2014 07:47 PM, Randy Brukardt wrote:
>> "Luke A. Guest" <laguest@archeia.com> wrote in message
>> news:1893909476418340554.191505laguest-archeia.com@nntp.aioe.org...
>>> "Randy Brukardt" <randy@rrsoftware.com> wrote:
>>>> Very early in the design of Ada, there was a proposal to add a unary
>>>> operator symbol specifically for the purpose converting between types.
>>>> Ichbiah and his team rejected the proposal as "+" already exists and 
>>>> has
>>>> no
>>>> other useful purpose. They said that "+" should be used for this 
>>>> purpose.
>>>
>>> I don't get the idea of using plus as a conversion operator, I'd this so 
>>> e
>>> mathematical notation I've not come across?
>>
>> The second part above is so garbled that I can't guess how to respond to 
>> it.
>> The first part is easy, one camp says unary "+" doesn't have a (useful)
>> mathematical meaning, so let's ignore that meaning and use the operator 
>> for
>> conversions. The other camp says that unary "+" has a (useless) 
>> mathematical
>> meaning that should be left alone. Because of the dynamics of the Ada
>> standards process, neither camp ever gets to lead and the net effect is 
>> that
>> we never get *any* conversion operator. Which we've needed from day 1, 
>> IMHO.
>
> Maybe they could agree on a new unused operator being added.

Did you read my original message? That's been suggested for many years. 
There is a camp that thinks "+" is good enough for that, and thus blocks any 
attempts to add another such operator. (There's a lot of people in that 
camp.)

The other group hates the idea of using "+" for that purpose, and blocks any 
use of that as a conversion in the language. (There's a lot of people in 
this group, too -- some are in both groups.)

The ARG operates by consensus. We have no consensus on either point, thus 
nothing gets done at all. (Luckily, this dynamic doesn't happen very often.)

> Of course mathematics
> uses every known graphic in some area. We might be able to agree that an 
> addition should be in the ASCII code points for Unicode which leaves a 
> couple of things that
> stand out that aren't already in use in Ada. "~" seems like a good 
> character with a derivative meaning "approximates" which often all a 
> conversion can do.

If it was up to me, '@' or '#' or '$' or '~' would have been used for this 
long ago.

> UBString := ~String; -- Would drive people from some linguisitic 
> backgrounds crazy, though.

Probably any choice will annoy someone. I think that's the primary argument 
of the "+" backers -- no other solution is really obviously better, so lets 
not clutter the language further. It's hard to argue with that.

                                           Randy.

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Tue, 8 Apr 2014 18:37:35 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:yl8s1sbhw0lw.1bhypcrvreord.dlg@40tude.net...
>> On Mon, 7 Apr 2014 20:15:10 -0500, Randy Brukardt wrote:
> ...
>>> Mixed operations are not the Ada way of typing.
>>
>> It is Ada's way of SUBtyping. Obviously Unbounded_String and String are
>> related subtypes, promoted to types due to implementation reasons only.
> 
> Obvious to you only. Any single program/subsystem should stick to a single 
> string type. The fact that you can't do that in Ada (unless that type is 
> String) is the bug that needs to be fixed.

I don't understand what you are trying to say. Is it that no program shall
use both Unbounded_String and String or that there must be no String
(Unbounded_String) at all?

>>>>> There is no opportunity to share implementations, which is the other
>>>>> reason to inherit one from another.
>>>>
>>>> Most of implementations of String can be shared by Unbounded_String. This
>>>> is what people do manually all the time converting Unbounded_String to
>>>> String and back.
>>>
>>> No, not really. Most implementations of Root_String'Class could be shared
>>> amongst string types.
>>
>> That would be very inconvenient. Certainly, less class-wide operations are
>> provided better is the design.
> 
> "In"convinient? Why?

Class-wide operations are inefficient, ambiguous, require type casts (and
thus unsafe).

> And in any case, the whole point is to 
> eliminate the requirement to use a single, specific string type for 
> operations that should be generic (generic in the English, not Ada, sense).

And the whole point of keeping operation primitive is to have its interface
generic and the implementation type-specific.

>> The model where operations are primitive has the decisive advantage that
>> the operation can be inherited or overridden in order to provide a more
>> efficient version.
> 
> That wouldn't improve the performance enough to matter. If there is a 
> problem with this scheme, it's that it could be very inefficient. But that's 
> mostly because of the use of dispatching, and that's required for the goal 
> to be reached (for most of the existing predefined operations to have 
> versions that take/return Root_String'Class rather than String). If we can't 
> reach that goal, there is no point to doing this at all.

There will be no dispatching because types are known statically for most
applications. Secondly, even if dispatching is present it is manyfold more
efficient that dispatching within the class-wide bodies per character
basis, which where your proposal leads.

>>> Moreover, there cannot be automatic sharing of operations; that weakens 
>>> the type system. One only wants to share operations that are explicitly 
>>> intended to be shared; that's the point of declaring packages operating on
>>> Root_String'Class rather than some specific type.
>>
>> I don't understand the term "shared operation."
>>
>> If you don't want to provide an implementation you declare the operation
>> abstract. If you don't want an operation in the class, you move it into 
>> the body. Where is a problem?
> 
> As above, it's too much work to extend a type that requires overridding more 
> than a handful of primitives.

String types are library types. You cannot extend String now, so the use
case you are talking about does not exist.

>>> The majority of operations would take Root_String'Class and thus work
>>> on any object. Ones that don't would have been restricted for some good
>>> reason, and would work as now. What's so hard about that?
>>
>> It does not make any sense to me. Consider the operation Append. Which
>> class does it belong to? Does it act on String? Is the argument UCS-2?
> 
> Append takes two operands of Root_String'Class, and returns an 
> Root_String'Class with the type of its first argument. What's the problem?

Append is a procedure. Modifiers of Unbounded_String are in-place
operations, that is the major use case for having Unbounded_String at all.

>>> No, I'm deriving from an abstract type with no representation. There's a
>>> huge difference.
>>
>> No difference whatsoever. We are talking about interfaces. The interface 
>> of Unbounded_String is not the interface of String.
> 
> That's true, but that's a bug. They *should* be the same; only the runtime 
> behavior should differ (when exceptions are raised and the like).

They should not and cannot. The type String cannot have procedure Append
because String size is contracted to be constant. Immutable bounds is the
major use case of String. Mutable bounds is of Unbounded_String. You cannot
have both "same."

>> When you force a set of
>> types to one class you must drop parts of the interfaces uncommon to all
>> members. This is why single parent will never work for any more or less
>> non-trivial set of types. String types and numeric types are such sets. It
>> is not even worth trying. The result is doomed.
> 
> Possibly, but then programming language design in general is doomed. The 
> only solutions that would work are crazily inefficient.

Everything should work exactly so it does now, but without explicit type
conversions.

>>>>> "Unbounded_String" is a container for a
>>>>> Root_String'Class type; it adds unbounded memory management to whatever
>>>>> the string type does. There is no reason that one has to do that as 
>>>>> part of the string abstraction.
>>>>
>>>> But then you necessarily loose all operations String cannot have, e.g.
>>>> Append, Replace, etc. The idea is of course that Unbounded_String,
>>>> Unbounded_Wide_Wide_String, Unbounded_UTF8_String share this interface.
>>>
>>> Ada.Strings.Fixed has all of those operations.
>>
>> Append (S, SUNDANESE_LETTER_KHA);
> 
> Yes, that's good. If the underlying type cannot store the letter, 
> Constraint_Error is raised.

Yes! You want weak typing all the way!

In my system the above will be compile error because

1. String does not have Append;

2. String is Latin-1.
 
> As with all tagged types, you trade-off compile-time checking for 
> generality. You can't have both (I know people try, but they are mad - 
> they'll have just as much luck creating a perpetual motion machine).

I can, this what a proper types system is for. If you don't change the type
system you end up with a weakly typed language, which is where Ada sails to
since 2005.

>>>>> You would have
>>>>> to qualify all string literals in an MD world, and that's something
>>>>> programmers would never tolerate.
>>>>
>>>> Ambiguity of literals can be resolved using preference rules like ones
>>>> invented for Universal_Integer. We could introduce Universal_String etc.
>>>
>>> That doesn't work at all; universal integer only has a preference against
>>> itself. All other types are equal.
>>
>> They will have no literals of their own, in this model.
> 
> They have no literals now, in this model. You're just describing the way 
> things are, and then expect it to work differently.

Yes, a common type hierarchy will make it working differently.

>>> and you'd still have
>>> problems with Wide_Wide_String vs. String.
>>
>> No, because wider literals will go to Wide_String and most wide literal to
>> Wide_Wide_String. The idea is to dissect literals according to the code
>> point planes.
> 
> So the behavior of the program changes when the contents of a string literal 
> changes?

Contents of a literal is the literal itself. That is the meaning of the
word "literal." Yes, if you change the literal the behavior changes.
Compare:

    I : Integer_8 := 100;

vs.

    I : Integer_8 := 100_000;

> No thanks.

After you lumped everything into class-wide operations making it weakly
typed?

>>> They are a prime source of beaujolais effects, which Ada considers
>>> completely unacceptable. (Adding or removing a declaration should never
>>> change a legal program into a different legal program with a different
>>> meaning.)
>>
>> Hierarchies of types are not insulated against each other. You cannot
>> simply add or remove declaration of an operation in the hierarchy. That
>> will lead to changes in the dispatching tables, need to define/override
>> something, if the operation is abstract, which is why freezing rules are
>> here etc.
>>
>> It is the nature of a constraint which is far more important than any
>> "beaujolais effects" - that no dispatch can fail at run-time.
>>
>> All slots of any dispatching table must be statically checked for being
>> either properly inherited or overridden. That *necessarily* requires making
>> something illegal which otherwise would be legal. "No-beaujolais" is a
>> nicety for separate compilation, another is strong typing imperative. I
>> gladly trade former for the latter if necessary.
> 
> In other words, you are willing to weaken Ada's contracts in order to get 
> your supposed "strong typing imperative".

No, it is strengthening of the contracts. You removed beaujolais effects by
weakening the contracts to the point where separately compiled units could
retain their contracts independently. Strengthening may lead to loosing
this property.

> Essentially, in your world, you cannot change a package specification 
> because you cannot know what effect such changes have on clients (clients 
> that you don't know much about).

The effect is exactly known - the clients become illegal. That is the idea
of strong contracts. Instead of keeping clients legal but risking
unanticipated behavioral changes, strong contracts make clients illegal
when there is a possibility of changed behavior. If you can statically
prove that the behavior does not change, there is no need to introduce the
"effect."

> That means that there is no hope for 
> reusable software - the originator of the software has to be able to modify 
> it in order to improve or correct it. If that breaks all clients, then 
> either one can do nothing at all, or people just have to stick to their 
> existing (buggy) versions. Neither is acceptable.

Ada has no support for dynamic linking anyway, so it is how it is right
now. Introducing MD won't make bad any worse.

On the other hand, it is well known that OO interfaces are quite fragile
for dynamic linking with or without MD. But this is another problem, which
must be addressed first, when the type system is OK.

>>> And even if you did, it would be an impracticaly large a data
>>> structure in most cases. (Consider that there are something like 20 
>>> string types in a Root_String'Class model,
>>
>> N is not the total number of related types, N is the depth of the given
>> hierarchy. You will have to map Tag to some dense index in the operation's
>> inheritance path and then go into the array with this index. Raw tag is a
>> poor index.
> 
> But it's all we have. Sure, you can map a tag (this requires a loop, either 
> a brute force lookup or some fancier but much more code-intensive version), 
> but that's going to make dispatching far more expensive. You can't do this 
> mapping at compile-time because what mapping you need depends on the 
> interfaces in use.

I can build a perfect hash at bind/link time when all involved tags become
known.

>>>> (However there are serious problems with implementation of MD which I 
>>>> have no idea how to resolve. MI is much simpler)
>>>
>>> I suppose MI is simpler, but it has a similar problem with tag 
>>> construction.
>>> (At least there is only one dimension for interfaces; full MI would turn
>>> things into a much worse situation, as hidden types would have to be
>>> allowed - and then its possible for a type to have multiple copies of the
>>> same interface.)
>>
>> That is a highly desired effect: to support additive model of inheritance.
>> E.g. additive MI from doubly-linked list element.
> 
> It doesn't work, though, because you have to know *which* copy of the 
> interface you are dispatching through.

Operations will be renamed in order to have it unambiguous. It was always
my desire that Ada would require renaming in all cases when something gets
hidden.

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

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1w6eh0aiksmdh$.1h16p7y0b8c6h.dlg@40tude.net...
> On Tue, 8 Apr 2014 18:37:35 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:yl8s1sbhw0lw.1bhypcrvreord.dlg@40tude.net...
>>> On Mon, 7 Apr 2014 20:15:10 -0500, Randy Brukardt wrote:
>> ...
>>>> Mixed operations are not the Ada way of typing.
>>>
>>> It is Ada's way of SUBtyping. Obviously Unbounded_String and String are
>>> related subtypes, promoted to types due to implementation reasons only.
>>
>> Obvious to you only. Any single program/subsystem should stick to a 
>> single
>> string type. The fact that you can't do that in Ada (unless that type is
>> String) is the bug that needs to be fixed.
>
> I don't understand what you are trying to say. Is it that no program shall
> use both Unbounded_String and String or that there must be no String
> (Unbounded_String) at all?

There should be no reason for a single subsystem to use more than one string 
type. The fact that that is not true in Ada today is the cause of most of 
the problems.

As a correllary, as many operations as possible should work with all 
possible string types (Root_String'Class in my formulation) -- most of the 
time when you need to use multiple string types, its because you have 
libraries that only work with one type (String, Unbounded_String, whatever) 
and you need to use some other type. So you end up converting back and 
forth. If most the libraries simply take Root_String'Class, that doesn't 
happen.

...
>>> That would be very inconvenient. Certainly, less class-wide operations 
>>> are
>>> provided better is the design.
>>
>> "In"convinient? Why?
>
> Class-wide operations are inefficient, ambiguous, require type casts (and
> thus unsafe).

The first I rather understand, but it's the entire point of the change (to 
get as many operations as possible to work with any string type). If that 
proves too inefficient, then there is no solution. But I do think it has to 
be tried in order to determine if its truly too inefficient (worrying about 
that is often premature optimization). [This is the reason that I don't 
dismiss out-of-hand your ideas on MI and MD -- because while I think they're 
likely to be too inefficient, I really don't know that. Of course, since I 
think as much as possible needs to be class-wide, dispatching performance is 
very important, and MD in particular would have a substantial cost there.]

Ambiguous? That's the idea -- most consumers of strings don't care anything 
about the properties of the string, just the sequence of code points that it 
represents.

Require type casts? No idea why you think that - that only happens in bad 
abstractions where you find yourself upcasting to get at components that 
"you know are there". Such things are just plain bad, and surely aren't 
going to happen here as nothing of the implementation is going to be 
exposed. (I.e. either use Root_String'Class, or use a specific type - and 
under no circumstances should you change mid-stream.)

 >> And in any case, the whole point is to
>> eliminate the requirement to use a single, specific string type for
>> operations that should be generic (generic in the English, not Ada, 
>> sense).
>
> And the whole point of keeping operation primitive is to have its 
> interface
> generic and the implementation type-specific.

We don't want "type-specific" implementations of most things -- that's just 
adding a maintenance headache where one isn't needed. Why would anyone want 
a "type-specific" implementation of file open? Or exception messages? That's 
precisely the cause of the problem that we currently have.

...
>> That wouldn't improve the performance enough to matter. If there is a
>> problem with this scheme, it's that it could be very inefficient. But 
>> that's
>> mostly because of the use of dispatching, and that's required for the 
>> goal
>> to be reached (for most of the existing predefined operations to have
>> versions that take/return Root_String'Class rather than String). If we 
>> can't
>> reach that goal, there is no point to doing this at all.
>
> There will be no dispatching because types are known statically for most
> applications. Secondly, even if dispatching is present it is manyfold more
> efficient that dispatching within the class-wide bodies per character
> basis, which where your proposal leads.

Well, my proposal supports slices as a primitive operation, so there's no 
reason for dispatching on single characters unless you really need to access 
single characters.

But you're saying that we shouldn't solve the problem at all, since the 
entire problem is forcing the use of specific types in language-defined 
libraries (and similarly in user-defined libraries). By definition, most of 
the operations would be on class-wide types and thus dispatching.

You seem so focused on virtually useless operations like Append -- they have 
no real value in an Ada application, as the primitives (slicing and &) do 
the job better anyway. One is forced to use them for unbounded string, 
mainly because you don't have very good access to the primitives for those 
types -- that's the whole idea of this change.

...
>>> It does not make any sense to me. Consider the operation Append. Which
>>> class does it belong to? Does it act on String? Is the argument UCS-2?
>>
>> Append takes two operands of Root_String'Class, and returns an
>> Root_String'Class with the type of its first argument. What's the 
>> problem?
>
> Append is a procedure. Modifiers of Unbounded_String are in-place
> operations, that is the major use case for having Unbounded_String at all.

OK, then it takes an in out parameter of Root_String'Class, and an in 
parameter of Root_String'Class. What's the problem?

In any case, Append is a pretty useless operation; the majority of the 
operations in Ada.Strings are that. It takes longer to figure out how they 
work and find the right one than it does to just write the silly operation 
explicitly.

It might make sense to make the most general Index primitive (as it's pretty 
much the only operation that really could benefit from a custom 
implementation), but that's about it. It's very important that the root 
interface be kept as small as possible.

>>>> No, I'm deriving from an abstract type with no representation. There's 
>>>> a
>>>> huge difference.
>>>
>>> No difference whatsoever. We are talking about interfaces. The interface
>>> of Unbounded_String is not the interface of String.
>>
>> That's true, but that's a bug. They *should* be the same; only the 
>> runtime
>> behavior should differ (when exceptions are raised and the like).
>
> They should not and cannot. The type String cannot have procedure Append
> because String size is contracted to be constant. Immutable bounds is the
> major use case of String. Mutable bounds is of Unbounded_String. You 
> cannot
> have both "same."

Of course you can. Consider Bounded string, which has a bound, but it's 
partly mutable. Or better, consider the containers -- they have bounded and 
unbounded versions. Semantically, they all have bounds, it's just that the 
unbounded version increases the bound automatically when needed. There would 
be no problem having a fixed size container (other than such a thing would 
be redunant with the existing arrays). Append is defined in 
Ada.Strings.Fixed, after all, so of course it works for a fixed length 
string.

>>> When you force a set of
>>> types to one class you must drop parts of the interfaces uncommon to all
>>> members. This is why single parent will never work for any more or less
>>> non-trivial set of types. String types and numeric types are such sets. 
>>> It
>>> is not even worth trying. The result is doomed.
>>
>> Possibly, but then programming language design in general is doomed. The
>> only solutions that would work are crazily inefficient.
>
> Everything should work exactly so it does now, but without explicit type
> conversions.

Yeah, and every girl should want to go out with you, without an explicit 
invitation. :-)

>>>>>> "Unbounded_String" is a container for a
>>>>>> Root_String'Class type; it adds unbounded memory management to 
>>>>>> whatever
>>>>>> the string type does. There is no reason that one has to do that as
>>>>>> part of the string abstraction.
>>>>>
>>>>> But then you necessarily loose all operations String cannot have, e.g.
>>>>> Append, Replace, etc. The idea is of course that Unbounded_String,
>>>>> Unbounded_Wide_Wide_String, Unbounded_UTF8_String share this 
>>>>> interface.
>>>>
>>>> Ada.Strings.Fixed has all of those operations.
>>>
>>> Append (S, SUNDANESE_LETTER_KHA);
>>
>> Yes, that's good. If the underlying type cannot store the letter,
>> Constraint_Error is raised.
>
> Yes! You want weak typing all the way!

Yes, that's exactly the idea of class-wide operations -- one weakens the 
typing (by allowing classes of operations) in order to get more generality.

There is always a trade-off between generality and the strength of typing --  
and I surely agree with you that generics don't help in any significant way 
with that.

> In my system the above will be compile error because
>
> 1. String does not have Append;

String *does* have Append (in Ada.Strings.Fixed). Why do you think those 
operations are part of Unbounded_String but not part of String simply 
because someone stuck the latter ones in a library?

...
>> As with all tagged types, you trade-off compile-time checking for
>> generality. You can't have both (I know people try, but they are mad -
>> they'll have just as much luck creating a perpetual motion machine).
>
> I can, this what a proper types system is for. If you don't change the 
> type
> system you end up with a weakly typed language, which is where Ada sails 
> to
> since 2005.

You're delusional on this point. Indeed, you refuse to pay any attention 
when I point out why your system won't work. You just keep relying on some 
sort of magic to make it work - and then go on to laughably claim that it 
would be compatible without a shred of evidence that that could possibly be 
so.

I should know better than to engage with you on anything that involves your 
crazy type system, because the useful ideas that I hope to find out are 
completely lost in this impractical, magic reimagining of the type system.

I'm hoping to come up with a solutions within the existing type system, 
because there is absolutely no evidence that there is a problem it. Indeed, 
the fact that I can come up with a viable all-Ada 2012 solution to the 
string problem shows that. I really don't care whether or not some other 
type system that's never going to happen would work differently. And that's 
the last word on that subject.

...
>>>> They are a prime source of beaujolais effects, which Ada considers
>>>> completely unacceptable. (Adding or removing a declaration should never
>>>> change a legal program into a different legal program with a different
>>>> meaning.)
>>>
>>> Hierarchies of types are not insulated against each other. You cannot
>>> simply add or remove declaration of an operation in the hierarchy. That
>>> will lead to changes in the dispatching tables, need to define/override
>>> something, if the operation is abstract, which is why freezing rules are
>>> here etc.
>>>
>>> It is the nature of a constraint which is far more important than any
>>> "beaujolais effects" - that no dispatch can fail at run-time.
>>>
>>> All slots of any dispatching table must be statically checked for being
>>> either properly inherited or overridden. That *necessarily* requires 
>>> making
>>> something illegal which otherwise would be legal. "No-beaujolais" is a
>>> nicety for separate compilation, another is strong typing imperative. I
>>> gladly trade former for the latter if necessary.
>>
>> In other words, you are willing to weaken Ada's contracts in order to get
>> your supposed "strong typing imperative".
>
> No, it is strengthening of the contracts. You removed beaujolais effects 
> by
> weakening the contracts to the point where separately compiled units could
> retain their contracts independently. Strengthening may lead to loosing
> this property.

In order to "program in the large", separate units have to be able to 
"retain their contracts independently". Otherwise, it's impossible for 
separate development teams to work on the same program -- it's those 
independent contracts that make it safe for one team to add new items and 
not have it cause the program to change behavior without warning. This is a 
property of Ada which every Ada programmer depends upon, but since it's not 
an obvious property, most people don't realize how critical it is.

> Essentially, in your world, you cannot change a package specification
>> because you cannot know what effect such changes have on clients (clients
>> that you don't know much about).
>
> The effect is exactly known - the clients become illegal. That is the idea
> of strong contracts. Instead of keeping clients legal but risking
> unanticipated behavioral changes, strong contracts make clients illegal
> when there is a possibility of changed behavior. If you can statically
> prove that the behavior does not change, there is no need to introduce the
> "effect."

If the clients become illegal, then you don't have Beaujolias, and all is 
well. But that's not the system you described. You descibed one with 
preference rules, and when those exist, an addition or deletion potentially 
causes one legal program to become a different legal program - because the 
preference rule causes a different routine to be called rather than making 
the call illegal. That's not acceptable for Ada (and it shouldn't be 
acceptable for any programming language).

>> That means that there is no hope for
>> reusable software - the originator of the software has to be able to 
>> modify
>> it in order to improve or correct it. If that breaks all clients, then
>> either one can do nothing at all, or people just have to stick to their
>> existing (buggy) versions. Neither is acceptable.
>
> Ada has no support for dynamic linking anyway, so it is how it is right
> now. Introducing MD won't make bad any worse.

MD isn't the problem; preference rules are the problem.

And what does dynamic linking have to do with anything? You should be able 
to get the new version of GTK or Claw and recompile -- if legal, the program 
should work the same way. Period. That's not the case in a system with 
preference rules for user-defined operations.

...
>> But it's all we have. Sure, you can map a tag (this requires a loop, 
>> either
>> a brute force lookup or some fancier but much more code-intensive 
>> version),
>> but that's going to make dispatching far more expensive. You can't do 
>> this
>> mapping at compile-time because what mapping you need depends on the
>> interfaces in use.
>
> I can build a perfect hash at bind/link time when all involved tags become
> known.

"can" means "possible", not "practical". That might be possible if the 
number of tags is small, but that's not the case in a lot of OO systems. (A 
Claw program starts with somewhere around 80.) Finding a perfect hash gets 
very time consuming if the number of items is large - I don't think people 
will be very happy with binding that takes 12 hours.

                        Randy.

Re: Your wish list for Ada 202X

[Georg Bauhaus]

On 10/04/14 05:28, Randy Brukardt wrote:
>>> But it's all we have. Sure, you can map a tag (this requires a loop,
>>> >>either
>>> >>a brute force lookup or some fancier but much more code-intensive
>>> >>version),
>>> >>but that's going to make dispatching far more expensive. You can't do
>>> >>this
>>> >>mapping at compile-time because what mapping you need depends on the
>>> >>interfaces in use.
>> >
>> >I can build a perfect hash at bind/link time when all involved tags become
>> >known.
> "can" means "possible", not "practical". That might be possible if the
> number of tags is small, but that's not the case in a lot of OO systems. (A
> Claw program starts with somewhere around 80.) Finding a perfect hash gets
> very time consuming if the number of items is large - I don't think people
> will be very happy with binding that takes 12 hours.

Are you certain about the cost of computing perfect hashes?
I tried gperf(1) on a hundred words and ran it a thousand times
in a loop. The loop has taken just a few seconds:

a=1000
while test $a -gt 0
  do
     head -100 /usr/share/dict/words |gperf > /dev/null
    a=$(($a - 1))
  done

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Wed, 9 Apr 2014 22:28:36 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1w6eh0aiksmdh$.1h16p7y0b8c6h.dlg@40tude.net...
>> On Tue, 8 Apr 2014 18:37:35 -0500, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:yl8s1sbhw0lw.1bhypcrvreord.dlg@40tude.net...
>>>> On Mon, 7 Apr 2014 20:15:10 -0500, Randy Brukardt wrote:
>>> ...
>>>>> Mixed operations are not the Ada way of typing.
>>>>
>>>> It is Ada's way of SUBtyping. Obviously Unbounded_String and String are
>>>> related subtypes, promoted to types due to implementation reasons only.
>>>
>>> Obvious to you only. Any single program/subsystem should stick to a single
>>> string type. The fact that you can't do that in Ada (unless that type is
>>> String) is the bug that needs to be fixed.
>>
>> I don't understand what you are trying to say. Is it that no program shall
>> use both Unbounded_String and String or that there must be no String
>> (Unbounded_String) at all?
> 
> There should be no reason for a single subsystem to use more than one string 
> type.

Where that follows from?

> The fact that that is not true in Ada today is the cause of most of 
> the problems.

This is even more perplexing. It is two different statements:

1. I can invent a string type for all purposes, thus all applications will
use it.

2. Any given application needs only one string type, but different
applications may require different string types.

Both statements are evidently false.
 
> As a correllary, as many operations as possible should work with all 
> possible string types (Root_String'Class in my formulation) -- most of the 
> time when you need to use multiple string types, its because you have 
> libraries that only work with one type (String, Unbounded_String, whatever) 
> and you need to use some other type.

Libraries and applications use different types because each type has
certain advantages and disadvantages over any other type. This is why many
string types are needed, deploying different memory management strategies,
different encodings and different subsets of Unicode.

> So you end up converting back and 
> forth. If most the libraries simply take Root_String'Class, that doesn't 
> happen.

It is as unrealistic as throwing out all numeric types and using arbitrary
precision arithmetic instead. It simply does not work for real-life
applications.

> Ambiguous? That's the idea -- most consumers of strings don't care anything 
> about the properties of the string, just the sequence of code points that it 
> represents.

Class-wide operations are overloaded, which is why.

> Require type casts? No idea why you think that - that only happens in bad 
> abstractions where you find yourself upcasting to get at components that 
> "you know are there". Such things are just plain bad, and surely aren't 
> going to happen here as nothing of the implementation is going to be 
> exposed. (I.e. either use Root_String'Class, or use a specific type - and 
> under no circumstances should you change mid-stream.)

When the result is class-wide you have to cast it to the specific type. You
cannot go all the way with class-wide objects. It does not work.

>  >> And in any case, the whole point is to
>>> eliminate the requirement to use a single, specific string type for
>>> operations that should be generic (generic in the English, not Ada, 
>>> sense).
>>
>> And the whole point of keeping operation primitive is to have its 
>> interface generic and the implementation type-specific.
> 
> We don't want "type-specific" implementations of most things -- that's just 
> adding a maintenance headache where one isn't needed.

It is need for

1. safety (because you statically know that certain specific operation may
not fail, while class-wide operations can)

2. efficiency

There is no maintenance overhead whatsoever. Here is the proof. Let you can
provide a generic implementation (as you suggested), then this
implementation can be safely inherited. Therefore whether you provide an
overriding or leave it as is that has no influence of the program behavior
=> no maintenance problem.

> Why would anyone want 
> a "type-specific" implementation of file open?

Because generic operation would not work.

What lseek is supposed to do with terminal input? Files are different per
nature of medium they represent, so are strings. There are interfaces
common for various subsets of files and strings. But there is no single
usable interface for the set of all files or the set of all strings. The
model of type extension does not function in real-life.

> Or exception messages? That's 
> precisely the cause of the problem that we currently have.

The cause is that the language does not support factoring out interfaces in
their variety. It either forces single interface for all objects or no
common interface at all. That leads to the design of string types Ada had
(no common interface). Your idea of single interface will fail as well. No
interface is C programmed in Ada. Yours is SmallTalk in Ada, with any
method applicable to any object and MessageNotUnderstood raised at
run-time. I bet that most Ada programmers would prefer C-esque approach to
that. It is uncomfortable but at least safe.

> But you're saying that we shouldn't solve the problem at all, since the 
> entire problem is forcing the use of specific types in language-defined 
> libraries (and similarly in user-defined libraries).

Making operations primitive does not force user-defined libraries to
anything. They still can be designed in generic terms. But since there will
more classes than single root string, it will be also possible to design
specialized libraries as well.

And I see a general language problem in inability to add primitive
operations without huge efforts, e.g. 

   type My_Type_With_New_Ops is new Old_Type with null record;

There must be better means for that especially due to MD. MD will not work
when involved types are frozen.

> You seem so focused on virtually useless operations like Append -- they have 
> no real value in an Ada application, as the primitives (slicing and &) do 
> the job better anyway. One is forced to use them for unbounded string, 
> mainly because you don't have very good access to the primitives for those 
> types -- that's the whole idea of this change.

Append is very useful because Unbounded_Strings are usually constructed
incrementally by adding pieces.

But that is beside the point. I am focused on the language features which
would allow the programmer to describe conglomerates of types like string
types. String types is just an example to illustrate language weaknesses.
Same applies to numeric types, to matrices, to
containers/indices/iterators. Wherever you look you see the same problem,
the language type system is deficient.

>>>> It does not make any sense to me. Consider the operation Append. Which
>>>> class does it belong to? Does it act on String? Is the argument UCS-2?
>>>
>>> Append takes two operands of Root_String'Class, and returns an
>>> Root_String'Class with the type of its first argument. What's the 
>>> problem?
>>
>> Append is a procedure. Modifiers of Unbounded_String are in-place
>> operations, that is the major use case for having Unbounded_String at all.
> 
> OK, then it takes an in out parameter of Root_String'Class, and an in 
> parameter of Root_String'Class. What's the problem?

The problem is passing String as the in out parameter there. You have a
behavior change undetected at compile time. This is not Ada.

>>>>> No, I'm deriving from an abstract type with no representation. There's 
>>>>> a huge difference.
>>>>
>>>> No difference whatsoever. We are talking about interfaces. The interface
>>>> of Unbounded_String is not the interface of String.
>>>
>>> That's true, but that's a bug. They *should* be the same; only the 
>>> runtime behavior should differ (when exceptions are raised and the like).
>>
>> They should not and cannot. The type String cannot have procedure Append
>> because String size is contracted to be constant. Immutable bounds is the
>> major use case of String. Mutable bounds is of Unbounded_String. You 
>> cannot have both "same."
> 
> Of course you can. Consider Bounded string, which has a bound, but it's 
> partly mutable. Or better, consider the containers -- they have bounded and 
> unbounded versions. Semantically, they all have bounds, it's just that the 
> unbounded version increases the bound automatically when needed. There would 
> be no problem having a fixed size container (other than such a thing would 
> be redunant with the existing arrays). Append is defined in 
> Ada.Strings.Fixed, after all, so of course it works for a fixed length 
> string.

Where?

>> Everything should work exactly so it does now, but without explicit type
>> conversions.
> 
> Yeah, and every girl should want to go out with you, without an explicit 
> invitation. :-)

Yes! That would be even better than MD! (:-))

>>>> Append (S, SUNDANESE_LETTER_KHA);
>>>
>>> Yes, that's good. If the underlying type cannot store the letter,
>>> Constraint_Error is raised.
>>
>> Yes! You want weak typing all the way!
> 
> Yes, that's exactly the idea of class-wide operations -- one weakens the 
> typing (by allowing classes of operations) in order to get more generality.

It is not generality it is a bug. If String cannot implement this
interface. Why should it pretend to have?

>> In my system the above will be compile error because
>>
>> 1. String does not have Append;
> 
> String *does* have Append (in Ada.Strings.Fixed). Why do you think those 
> operations are part of Unbounded_String but not part of String simply 
> because someone stuck the latter ones in a library?

A.4.3 does not declare Append.

declare
   S : String (1..10);
begin
   Append (S, "A");  -- What is this supposed to do?

> If the clients become illegal, then you don't have Beaujolias, and all is 
> well. But that's not the system you described. You descibed one with 
> preference rules, and when those exist, an addition or deletion potentially 
> causes one legal program to become a different legal program - because the 
> preference rule causes a different routine to be called rather than making 
> the call illegal.

I never said that preference rules should have this effect. Why should
they, an example?

>>> That means that there is no hope for
>>> reusable software - the originator of the software has to be able to 
>>> modify it in order to improve or correct it. If that breaks all clients, then
>>> either one can do nothing at all, or people just have to stick to their
>>> existing (buggy) versions. Neither is acceptable.
>>
>> Ada has no support for dynamic linking anyway, so it is how it is right
>> now. Introducing MD won't make bad any worse.
> 
> MD isn't the problem; preference rules are the problem.

That requires a proof which shows that no set of rules can exist that
fulfills the requirements X, Y, Z. So far it is word against word. Not even
X, Y, Z is formulated.
 
> And what does dynamic linking have to do with anything? You should be able 
> to get the new version of GTK or Claw and recompile -- if legal, the program 
> should work the same way. Period. That's not the case in a system with 
> preference rules for user-defined operations.

I see no problem why it shouldn't be possible.

As for dynamic linking, the point is to use a new version *without*
recompiling and re-linking.

>>> But it's all we have. Sure, you can map a tag (this requires a loop, either
>>> a brute force lookup or some fancier but much more code-intensive version),
>>> but that's going to make dispatching far more expensive. You can't do this
>>> mapping at compile-time because what mapping you need depends on the
>>> interfaces in use.
>>
>> I can build a perfect hash at bind/link time when all involved tags become
>> known.
> 
> "can" means "possible", not "practical". That might be possible if the 
> number of tags is small, but that's not the case in a lot of OO systems. (A 
> Claw program starts with somewhere around 80.) Finding a perfect hash gets 
> very time consuming if the number of items is large - I don't think people 
> will be very happy with binding that takes 12 hours.

A suboptimal hash wont make much harm. You use different algorithms for
debug and release version optimized for speed. I don't see it as a problem.

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

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Georg Bauhaus" <rm-host.bauhaus@maps.futureapps.de> wrote in message 
news:53465969$0$6708$9b4e6d93@newsspool3.arcor-online.net...
> On 10/04/14 05:28, Randy Brukardt wrote:
...
>>> >I can build a perfect hash at bind/link time when all involved tags 
>>> >become
>>> >known.
>> "can" means "possible", not "practical". That might be possible if the
>> number of tags is small, but that's not the case in a lot of OO systems. 
>> (A
>> Claw program starts with somewhere around 80.) Finding a perfect hash 
>> gets
>> very time consuming if the number of items is large - I don't think 
>> people
>> will be very happy with binding that takes 12 hours.
>
> Are you certain about the cost of computing perfect hashes?

Certain? Only an idiot is certain about anything.

But my understanding is that calculating perfect hashes is an NP-complete 
problem. It's possible to speed up the algorithm (maybe), but it always is 
going to be quadratic in the size of the items. So while handling 100 items 
might only take a second or two, ten times as many must take at least 100 
times more time. The problem with that in a compilation system is that the 
first customer with a program with a lot of tags would find performance 
unacceptable. (What "a lot" is is debatable.)

Two stories about this:

(1) A friend of mine was working for a company developing a computer 
typesetting system. They has been testing prototypes for several weeks, and 
all was going well. A demonstration for company executives was arranged. The 
executive asked for a 72 point headline to be produced. The machine took 
several minutes to produce each letter. The algorithm used was quadratic in 
the type size, and all of the testing had been on small text.

Within a week, the product was canceled, and the entire team fired. My 
friend was out of work.

(2) Early in the development of Janus/Ada, we created and debugged an 
expression resolution algorithm. An algorithm as complex as Ada resolution 
hadn't really been used in compilers before, and the few articles on the 
topic didn't make much sense. So we built our own. It worked great for 
several years.

An new ACVC version came out. The compiler hung on one of the new tests. We 
were unable to find the infinite loop causing the problem. Eventually we 
figured out that that was because the loop wasn't infinite; it was coming 
from resolving an expression with 50 concats in a row. Experiments showed 
that the compiler was working just fine, but the expected compilation time 
on that expression was roughly 20.5 years. The problem being that there were 
a lot of "&" operations being tested, and each level tested those operations 
for all possible combinations of types. So something like 8**50 tests were 
being performed, and that was a problem.

Obviously, we needed to compile the ACVC (now ACATS) a lot quicker than 
that. I found a quick fix by testing the operands in the reverse order. 
Doing it left to right caused the most ambiguous operations to be tested 
first, which maximized the runtime. You could still trigger the problem with 
lots of parens, but just writing
   A & B & C & ...
wouldn't cause trouble. (I don't know if we ever actually fixed the problem, 
or if it just never appeared again.)

Moral of both of these stories: One does not want to knowingly depend on 
quadratic operations, because as soon as someone sticks in a larger than 
anticipated input, you will have trouble.

                                  Randy.

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:17twpp4p8u7o$.1idvzaaio4f3t$.dlg@40tude.net...
...
> This is even more perplexing. It is two different statements:
>
> 1. I can invent a string type for all purposes, thus all applications will
> use it.

Certainly not.

> 2. Any given application needs only one string type, but different
> applications may require different string types.

This is, in general, true. There probably are some wild outlier cases where 
this is not true, but it should be very rare. It's certainly the rule I've 
used in my programs. The problem is that Unbounded_String (in it's existing 
Ada implementation) cannot truly be used in place of String.

> Both statements are evidently false.

Sure, if you literally mean *all* programs. But I've never meant that.

>> As a correllary, as many operations as possible should work with all
>> possible string types (Root_String'Class in my formulation) -- most of 
>> the
>> time when you need to use multiple string types, its because you have
>> libraries that only work with one type (String, Unbounded_String, 
>> whatever)
>> and you need to use some other type.
>
> Libraries and applications use different types because each type has
> certain advantages and disadvantages over any other type. This is why many
> string types are needed, deploying different memory management strategies,
> different encodings and different subsets of Unicode.

Right, and each application should use one such type. As far as libraries 
go, there's clearly two kinds. The only one I care about in this context are 
trying to provide some sort of general usage of strings. Restrictions on the 
type of strings that they operate on just get in the way.

>> So you end up converting back and
>> forth. If most the libraries simply take Root_String'Class, that doesn't
>> happen.
>
> It is as unrealistic as throwing out all numeric types and using arbitrary
> precision arithmetic instead. It simply does not work for real-life
> applications.

Huh? It's exactly how I would define Root_Integer'Class if we had such a 
thing. But the operations would be implemented using dispatching, no 
arbitrary precision arithmetic.

>> Ambiguous? That's the idea -- most consumers of strings don't care 
>> anything
>> about the properties of the string, just the sequence of code points that 
>> it
>> represents.
>
> Class-wide operations are overloaded, which is why.

Overloaded with what? The whole idea with class-wide operations is that 
there is only one of each. Only one body to maintain, works for everything.

>.. here". Such things are just plain bad, and surely aren't
>> going to happen here as nothing of the implementation is going to be
>> exposed. (I.e. either use Root_String'Class, or use a specific type - and
>> under no circumstances should you change mid-stream.)
>
> When the result is class-wide you have to cast it to the specific type. 
> You
> cannot go all the way with class-wide objects. It does not work.

Wow, proof by repeated assertion. It does indeed work, especially using 
containers holding class-wide items. You only go to specific types via 
dispatching, and one does that fairly rarely.

It's more of a problem with a object with a heavy, large interface, because 
one ends up missing operations. (Everything is impractical with a large 
interface - OO makes little sense for such types.) But that doesn't occur 
for simple things like string or integer, because the interface is small and 
complete.

---

It's becoming clear that there is no more to be learned here. We have no 
agreement even on the problem here, so there is no point about worrying 
about solutions. You are simply denying that the interesting problem can be 
solved at all, so there is no further point in talking to you on this topic.

                                         Randy.

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:17twpp4p8u7o$.1idvzaaio4f3t$.dlg@40tude.net...
> On Wed, 9 Apr 2014 22:28:36 -0500, Randy Brukardt wrote:
...
>>> Ada has no support for dynamic linking anyway, so it is how it is right
>>> now. Introducing MD won't make bad any worse.
>>
>> MD isn't the problem; preference rules are the problem.
>
> That requires a proof which shows that no set of rules can exist that
> fulfills the requirements X, Y, Z. So far it is word against word. Not 
> even
> X, Y, Z is formulated.

Actually, there was such a formal proof constructed during the design of Ada 
9x. Unfortunately, that's pretty much all I remember about it, so it's not 
much help in this discussion.

But it's quite clear that (sane) preference rules cause Beaujolias.

Consider an expression node for which two choices (let's call them A and B) 
remain after eliminating obvious mismatches. (This situation can be common 
when literals are involved, as they match so many types). Ada of course 
makes the expression illegal in this case, specifically to avoid Beaujolias.

But let's consider a preference rule instead. The rule choses A over B, and 
then the program is legal and runs.

Now consider adding another operation C in some package that's referenced by 
the semantic closure ("with" in Ada) of our expression. Assume that C also 
is a possible choice for our expression node. If the preference rule picks C 
rather than A (or picks B for that matter), then we have the classic 
Beaujolias scenario when a legal program does something different because an 
operation is added to an unrelated package.

It doesn't matter what the preference rule is, one can always construct such 
a scenario. Unless, of course, the preference rule depends on something 
other than the name and type profiles declared in the source code. Using 
temporal information would work, of course, but it would be a nightmare for 
portability, as starting a new project with the same source code would 
change that information and cause the program to run differently. I believe 
that any rule not involving the contents of the source code would have 
similar problems.

The only time a preference rule is safe is if no user can add or delete 
operations for the types in question. That's why it's OK for 
univeral_integer. (It also means that future versions of the language can't 
add or delete operations for universal_integer, which might be a problem 
someday.)

                              Randy.

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Thu, 10 Apr 2014 17:08:37 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:17twpp4p8u7o$.1idvzaaio4f3t$.dlg@40tude.net...
> ...
>> It is as unrealistic as throwing out all numeric types and using arbitrary
>> precision arithmetic instead. It simply does not work for real-life
>> applications.
> 
> Huh? It's exactly how I would define Root_Integer'Class if we had such a 
> thing.

And no any program needs both Integer_16 and Unsigned_8 anyway. Right?

>>> Ambiguous? That's the idea -- most consumers of strings don't care anything
>>> about the properties of the string, just the sequence of code points that it
>>> represents.
>>
>> Class-wide operations are overloaded, which is why.
> 
> Overloaded with what?

With operations of other classes especially operations of subclasses.
Return a class-wide object is a nightmare. I had a lot of problems with
class-wide operations in recent projects. It is not only ambiguity, but
also a hell of type conversions and other tricks required when you have to
return a class-wide. It works only on paper.

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

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Thu, 10 Apr 2014 17:39:39 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:17twpp4p8u7o$.1idvzaaio4f3t$.dlg@40tude.net...
>> On Wed, 9 Apr 2014 22:28:36 -0500, Randy Brukardt wrote:
> ...
>>>> Ada has no support for dynamic linking anyway, so it is how it is right
>>>> now. Introducing MD won't make bad any worse.
>>>
>>> MD isn't the problem; preference rules are the problem.
>>
>> That requires a proof which shows that no set of rules can exist that
>> fulfills the requirements X, Y, Z. So far it is word against word. Not 
>> even X, Y, Z is formulated.
> 
> Actually, there was such a formal proof constructed during the design of Ada 
> 9x. Unfortunately, that's pretty much all I remember about it, so it's not 
> much help in this discussion.
> 
> But it's quite clear that (sane) preference rules cause Beaujolias.
> 
> Consider an expression node for which two choices (let's call them A and B) 
> remain after eliminating obvious mismatches. (This situation can be common 
> when literals are involved, as they match so many types). Ada of course 
> makes the expression illegal in this case, specifically to avoid Beaujolias.
> 
> But let's consider a preference rule instead. The rule choses A over B, and 
> then the program is legal and runs.
> 
> Now consider adding another operation C in some package that's referenced by 
> the semantic closure ("with" in Ada) of our expression. Assume that C also 
> is a possible choice for our expression node. If the preference rule picks C 
> rather than A (or picks B for that matter), then we have the classic 
> Beaujolias scenario when a legal program does something different because an 
> operation is added to an unrelated package.

Your example refers to overloading possible for operations on unrelated
types. I don't see how this is scenario could be possible for a primitive
MD operation. One of the requirements put on MD is that *all* combinations
of tags up to the root of the inheritance tree be defined and checked at
compile time. This requirement automatically precludes appearance of C from
air. It cannot be primitive and thus the preference rules would not apply
to it.

This requirement is actually a problem of MD, I don't know how to solve,
i.e. how to stretch a hierarchy across several packages. Let two packages
define two types P and Q and a cross operation F between. When in a third
package R gets derived from P, then how and where we define F for R and Q,
provided this third package may know nothing about the package of Q.

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

Re: Your wish list for Ada 202X

[Niklas Holsti]

On 14-04-10 17:31 , Dmitry A. Kazakov wrote:
> On Wed, 9 Apr 2014 22:28:36 -0500, Randy Brukardt wrote:

  [snip]

>> We don't want "type-specific" implementations of most things -- that's just 
>> adding a maintenance headache where one isn't needed.
> 
> It is need for
> 
> 1. safety (because you statically know that certain specific operation may
> not fail, while class-wide operations can)
> 
> 2. efficiency
> 
> There is no maintenance overhead whatsoever. Here is the proof. Let you can
> provide a generic implementation (as you suggested), then this
> implementation can be safely inherited. 

If you change a class-wide operation to an inherited (i.e. primitive)
operation, you have to change its dispatching calls to redispatching
calls, if you want the same behaviour as for the class-wide operation.

But (based on your earlier messages) you refuse to use redispatch, so
this change is not possible for you. Your proof fails when limited to
your subset of Ada, where redispatch is absent.

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

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Fri, 11 Apr 2014 21:04:58 +0200, Niklas Holsti wrote:

> On 14-04-10 17:31 , Dmitry A. Kazakov wrote:
>> On Wed, 9 Apr 2014 22:28:36 -0500, Randy Brukardt wrote:
> 
>   [snip]
> 
>>> We don't want "type-specific" implementations of most things -- that's just 
>>> adding a maintenance headache where one isn't needed.
>> 
>> It is need for
>> 
>> 1. safety (because you statically know that certain specific operation may
>> not fail, while class-wide operations can)
>> 
>> 2. efficiency
>> 
>> There is no maintenance overhead whatsoever. Here is the proof. Let you can
>> provide a generic implementation (as you suggested), then this
>> implementation can be safely inherited. 
> 
> If you change a class-wide operation to an inherited (i.e. primitive)
> operation, you have to change its dispatching calls to redispatching
> calls, if you want the same behaviour as for the class-wide operation.

No. I meant that the behavior of class-wide operation was defined = there
were no re-dispatch to operations that could be overridden to some
unanticipated behavior.

If not, then Randy's argument about maintenance is automatically false.

> But (based on your earlier messages) you refuse to use redispatch, so
> this change is not possible for you. Your proof fails when limited to
> your subset of Ada, where redispatch is absent.

The premise of the proof was that the operation's behavior was
well-defined. Otherwise, it is already unmaintainable.

Regarding use cases where re-dispatch comes in question, which certainly
exist, I think that from the safety and maintenance point of view, the type
system should provide means of body composition beyond simple inherit vs.
override. We know, for example, that constructors (initialize) and
destructors (finalize) require other means of composition. More elaborated
composition tools should eliminate re-dispatch (and most class-wide
operations) => give safety and maintainability.

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

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:n89glydkjsjz.17f34lyu7q1j4.dlg@40tude.net...
> On Thu, 10 Apr 2014 17:08:37 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:17twpp4p8u7o$.1idvzaaio4f3t$.dlg@40tude.net...
>> ...
>>> It is as unrealistic as throwing out all numeric types and using 
>>> arbitrary
>>> precision arithmetic instead. It simply does not work for real-life
>>> applications.
>>
>> Huh? It's exactly how I would define Root_Integer'Class if we had such a
>> thing.
>
> And no any program needs both Integer_16 and Unsigned_8 anyway. Right?
>
>>>> Ambiguous? That's the idea -- most consumers of strings don't care 
>>>> anything
>>>> about the properties of the string, just the sequence of code points 
>>>> that it
>>>> represents.
>>>
>>> Class-wide operations are overloaded, which is why.
>>
>> Overloaded with what?
>
> With operations of other classes especially operations of subclasses.
> Return a class-wide object is a nightmare. I had a lot of problems with
> class-wide operations in recent projects. It is not only ambiguity, but
> also a hell of type conversions and other tricks required when you have to
> return a class-wide. It works only on paper.

Then OOP doesn't work, because that's the only sensible use of OOP (to get 
"generic" operations while still preserving individual characteristics). 
Otherwise, you might as well build a set of unrelated types and use 
generics.

I can believe that there are problems inhibiting the use of class-wide types 
in this way, but those are precisely the problems that the language needs to 
address. Without class-wide programming, OOP is simply a waste of effort 
(and runtime).

                                      Randy.

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:16388p09ph28u$.1mglp0rm7pli9$.dlg@40tude.net...
> On Thu, 10 Apr 2014 17:39:39 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:17twpp4p8u7o$.1idvzaaio4f3t$.dlg@40tude.net...
>>> On Wed, 9 Apr 2014 22:28:36 -0500, Randy Brukardt wrote:
>> ...
>>>>> Ada has no support for dynamic linking anyway, so it is how it is 
>>>>> right
>>>>> now. Introducing MD won't make bad any worse.
>>>>
>>>> MD isn't the problem; preference rules are the problem.
>>>
>>> That requires a proof which shows that no set of rules can exist that
>>> fulfills the requirements X, Y, Z. So far it is word against word. Not
>>> even X, Y, Z is formulated.
>>
>> Actually, there was such a formal proof constructed during the design of 
>> Ada
>> 9x. Unfortunately, that's pretty much all I remember about it, so it's 
>> not
>> much help in this discussion.
>>
>> But it's quite clear that (sane) preference rules cause Beaujolias.
>>
>> Consider an expression node for which two choices (let's call them A and 
>> B)
>> remain after eliminating obvious mismatches. (This situation can be 
>> common
>> when literals are involved, as they match so many types). Ada of course
>> makes the expression illegal in this case, specifically to avoid 
>> Beaujolias.
>>
>> But let's consider a preference rule instead. The rule choses A over B, 
>> and
>> then the program is legal and runs.
>>
>> Now consider adding another operation C in some package that's referenced 
>> by
>> the semantic closure ("with" in Ada) of our expression. Assume that C 
>> also
>> is a possible choice for our expression node. If the preference rule 
>> picks C
>> rather than A (or picks B for that matter), then we have the classic
>> Beaujolias scenario when a legal program does something different because 
>> an
>> operation is added to an unrelated package.
>
> Your example refers to overloading possible for operations on unrelated
> types. I don't see how this is scenario could be possible for a primitive
> MD operation. One of the requirements put on MD is that *all* combinations
> of tags up to the root of the inheritance tree be defined and checked at
> compile time. This requirement automatically precludes appearance of C 
> from
> air. It cannot be primitive and thus the preference rules would not apply
> to it.

Doesn't matter. First, you'd have to prevent adding or removing new 
primitive operations to a hierarchy. That seems like a nasty limitation. 
Second, you can introduce a new primitive operation by withing ["ripple"] or 
using ["Beaujolias"] an existing package that wasn't previously part of the 
client. Introducing an otherwise unused package ought not change the 
behavior of a client.

> This requirement is actually a problem of MD, I don't know how to solve,
> i.e. how to stretch a hierarchy across several packages. Let two packages
> define two types P and Q and a cross operation F between. When in a third
> package R gets derived from P, then how and where we define F for R and Q,
> provided this third package may know nothing about the package of Q.

I suppose if you could actually solve such a problem without introducing 
crazy usage requirements, you could get the same effect as a preference rule 
safely. But I'd guess (and I admit it is a guess) that the problems are 
essentially the same and the fact that one clearly fails the test means that 
the other would clearly fail the test as well.

                                              Randy.

Re: Your wish list for Ada 202X

[Niklas Holsti]

On 14-04-11 22:43 , Dmitry A. Kazakov wrote:
> On Fri, 11 Apr 2014 21:04:58 +0200, Niklas Holsti wrote:
> 
>> On 14-04-10 17:31 , Dmitry A. Kazakov wrote:
>>> On Wed, 9 Apr 2014 22:28:36 -0500, Randy Brukardt wrote:
>>
>>   [snip]
>>
>>>> We don't want "type-specific" implementations of most things -- that's just 
>>>> adding a maintenance headache where one isn't needed.
>>>
>>> It is need for
>>>
>>> 1. safety (because you statically know that certain specific operation may
>>> not fail, while class-wide operations can)
>>>
>>> 2. efficiency
>>>
>>> There is no maintenance overhead whatsoever. Here is the proof. Let you can
>>> provide a generic implementation (as you suggested), then this
>>> implementation can be safely inherited. 
>>
>> If you change a class-wide operation to an inherited (i.e. primitive)
>> operation, you have to change its dispatching calls to redispatching
>> calls, if you want the same behaviour as for the class-wide operation.
> 
> No. I meant that the behavior of class-wide operation was defined = there
> were no re-dispatch to operations that could be overridden to some
> unanticipated behavior.

You mean that a class-wide operation should not call any primitive
operations of its parameters? Your programming style / Ada subset is
becoming "curiouser and curiouser". When _do_ you use dispatching?

> Regarding use cases where re-dispatch comes in question, which certainly
> exist,

Ah, that is comforting. I thought you were totally against redispatch.

> I think that from the safety and maintenance point of view, the type
> system should provide means of body composition beyond simple inherit vs.
> override.

That is certainly an interesting issue. You are thinking of something of
the same kind as the "inner" of Simula?

In my own code, the primitive operations of a type are typically layered
into levels: higher-level operations and lower-level ones. An overriding
higher-level primitive operation is typically implemented by calling
(with redispatch) lower-level primitive operations of the parameter
object. The *same* (i.e. overridden) operation of the parent type is
usually not called, nor does a primitive operation of a parent type call
the same primitive operation from the actual derived type; only
operations from lower layers are called.

> We know, for example, that constructors (initialize) and
> destructors (finalize) require other means of composition. More elaborated
> composition tools should eliminate re-dispatch (and most class-wide
> operations) => give safety and maintainability.

Maybe... suggest something and we'll see.

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

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Sat, 12 Apr 2014 00:04:48 +0200, Niklas Holsti wrote:

> On 14-04-11 22:43 , Dmitry A. Kazakov wrote:
>> On Fri, 11 Apr 2014 21:04:58 +0200, Niklas Holsti wrote:
>> 
>>> On 14-04-10 17:31 , Dmitry A. Kazakov wrote:
>>>> On Wed, 9 Apr 2014 22:28:36 -0500, Randy Brukardt wrote:
>>>
>>>   [snip]
>>>
>>>>> We don't want "type-specific" implementations of most things -- that's just 
>>>>> adding a maintenance headache where one isn't needed.
>>>>
>>>> It is need for
>>>>
>>>> 1. safety (because you statically know that certain specific operation may
>>>> not fail, while class-wide operations can)
>>>>
>>>> 2. efficiency
>>>>
>>>> There is no maintenance overhead whatsoever. Here is the proof. Let you can
>>>> provide a generic implementation (as you suggested), then this
>>>> implementation can be safely inherited. 
>>>
>>> If you change a class-wide operation to an inherited (i.e. primitive)
>>> operation, you have to change its dispatching calls to redispatching
>>> calls, if you want the same behaviour as for the class-wide operation.
>> 
>> No. I meant that the behavior of class-wide operation was defined = there
>> were no re-dispatch to operations that could be overridden to some
>> unanticipated behavior.
> 
> You mean that a class-wide operation should not call any primitive
> operations of its parameters?

They should, that was not the point. Which was maintainability. A
class-wide operation cannot be more maintainable than a primitive
operation. At least, it would require the level of contract thoroughness
Ada presently does not possess, not even close.

>> Regarding use cases where re-dispatch comes in question, which certainly
>> exist,
> 
> Ah, that is comforting. I thought you were totally against redispatch.

Yes I am. Re-dispatch is a flawed solution to a real problem. I don't deny
existence of the problem. I am against the solution, which is inherently
unsafe and constraining (precludes by-copy semantics).

>> I think that from the safety and maintenance point of view, the type
>> system should provide means of body composition beyond simple inherit vs.
>> override.
> 
> That is certainly an interesting issue. You are thinking of something of
> the same kind as the "inner" of Simula?

Yes, but it looks too low-level and hackish to me.

The concept should somehow play together with the notion of polymorphic
operation defined on the class (set of types). Between these two ends:
independent bodies of a primitive operation and single body of a class-wide
operation, there lies a whole spectrum of unexplored possibilities.

> In my own code, the primitive operations of a type are typically layered
> into levels: higher-level operations and lower-level ones. An overriding
> higher-level primitive operation is typically implemented by calling
> (with redispatch) lower-level primitive operations of the parameter
> object. The *same* (i.e. overridden) operation of the parent type is
> usually not called, nor does a primitive operation of a parent type call
> the same primitive operation from the actual derived type; only
> operations from lower layers are called.

Yes, this is the way I implement it too. The difference is that I try to
keep "higher-level" operations class-wide. Then I try to maintain the "no
abstraction inversion" rule, i.e. never call a "higher-level" operation
from a "lower-level" one.

Note that when "higher-level" operations are made class-wide, there is also
a formalized separation of two, as they act on different types.

>> We know, for example, that constructors (initialize) and
>> destructors (finalize) require other means of composition. More elaborated
>> composition tools should eliminate re-dispatch (and most class-wide
>> operations) => give safety and maintainability.
> 
> Maybe... suggest something and we'll see.

It is useless to suggest anything, as you know. And, I am not a language
designer anyway. I am a programmer. As a programmer, from my experience
with Ada, I tell the language designers that they got it all wrong since
Ada 2005. I don't want yet another dynamically typed or functional
language. I need a language for software engineering. More static checks,
more means to make static checks possible. The whole language should
revolute around helping restructuring my programs in order to support
static checks. No Constraint_Error to me, please!

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

Re: Your wish list for Ada 202X

[Nasser M. Abbasi]

On 4/12/2014 3:20 AM, Dmitry A. Kazakov wrote:


> I need a language for software engineering. More static checks,
> more means to make static checks possible. The whole language should
> revolute around helping restructuring my programs in order to support
> static checks. No Constraint_Error to me, please!
>

New languages seems to be all going the other way?
the new language Julia

http://en.wikipedia.org/wiki/Julia_%28programming_language%29

It is all about dynamic multiple dispatching

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

In Julia, the way I understand it, when defining a function
with some signature, then a compiled instance of this function
is made for all the possible primitive types (int16, int32,
real32, real64, etc...) and when the program is run,
the run-time automatically dispatches to the correct matching
function based on the argument used at time the call is made.

It seemed to me just Ada generics, but done automatically.

Those good old fashioned, strong static type checking
at compile time computer languages, seem like, well, old
fashioned these days.

--Nasser

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Fri, 11 Apr 2014 16:44:13 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:16388p09ph28u$.1mglp0rm7pli9$.dlg@40tude.net...

>> Your example refers to overloading possible for operations on unrelated
>> types. I don't see how this is scenario could be possible for a primitive
>> MD operation. One of the requirements put on MD is that *all* combinations
>> of tags up to the root of the inheritance tree be defined and checked at
>> compile time. This requirement automatically precludes appearance of C from
>> air. It cannot be primitive and thus the preference rules would not apply
>> to it.
> 
> Doesn't matter. First, you'd have to prevent adding or removing new 
> primitive operations to a hierarchy. That seems like a nasty limitation.

What? This limitation is with us since Ada 95! You cannot add a primitive
operation after the freezing point in Ada. You cannot remove a primitive
operation at all.

> Second, you can introduce a new primitive operation by withing ["ripple"] or 
> using ["Beaujolias"] an existing package that wasn't previously part of the 
> client. Introducing an otherwise unused package ought not change the 
> behavior of a client.

It will not, because the rule [*] should be that tags higher in the
hierarchy (counting from the root) than the highest known tag in the
expression should not be considered. E.g. if you have

   Root <- A <- B <- C

Then in the expression A + B, the variant C'(A + B) is automatically
depreciated.

>> This requirement is actually a problem of MD, I don't know how to solve,
>> i.e. how to stretch a hierarchy across several packages. Let two packages
>> define two types P and Q and a cross operation F between. When in a third
>> package R gets derived from P, then how and where we define F for R and Q,
>> provided this third package may know nothing about the package of Q.
> 
> I suppose if you could actually solve such a problem without introducing 
> crazy usage requirements, you could get the same effect as a preference rule 
> safely.

Possibly.

> But I'd guess (and I admit it is a guess) that the problems are 
> essentially the same and the fact that one clearly fails the test means that 
> the other would clearly fail the test as well.

If so, then OO failed, as you used to say! 

----------------
* This rule is akin to no re-dispatch rule

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

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Sat, 12 Apr 2014 03:39:44 -0500, Nasser M. Abbasi wrote:

> On 4/12/2014 3:20 AM, Dmitry A. Kazakov wrote:
> 
>> I need a language for software engineering. More static checks,
>> more means to make static checks possible. The whole language should
>> revolute around helping restructuring my programs in order to support
>> static checks. No Constraint_Error to me, please!
> 
> New languages seems to be all going the other way?

They are going nowhere. There were no new language ideas for decades.

> In Julia, the way I understand it, when defining a function
> with some signature, then a compiled instance of this function
> is made for all the possible primitive types (int16, int32,
> real32, real64, etc...)

Is made by whom? 

> and when the program is run,
> the run-time automatically dispatches to the correct matching
> function based on the argument used at time the call is made.

Really? What is the "correct matching" function of int16/real32? Can I have
real_bounded_interval_64? What would be int16/real_bounded_interval_64? Who
does linear system equation resolution function for int16?

The idea that there exist "primitive" and "non-primitive" types is garbage.
The idea that any operation is applicable to any type is garbage.
 
> Those good old fashioned, strong static type checking
> at compile time computer languages, seem like, well, old
> fashioned these days.

If even members of ARG seem not to believe in merits of strong typing or
whatever typing...

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

Re: Your wish list for Ada 202X

[Georg Bauhaus]

On 12/04/14 11:38, Dmitry A. Kazakov wrote:
>> >In Julia, the way I understand it, when defining a function
>> >with some signature, then a compiled instance of this function
>> >is made for all the possible primitive types (int16, int32,
>> >real32, real64, etc...)
> Is made by whom?
>

MIT. Announced for efficient scientific computing. Think:
mathematician sitting in front of a terminal, wanting
all available processors to compute a result and display it
graphically. But without Matlab, and fast, and reasonably type
checked.

The download is 1.5 GiB and starts bootstrapping after
compiling femto Lisp. It's the MIT, after all.

Re: Your wish list for Ada 202X

[Nasser M. Abbasi]

On 4/12/2014 4:38 AM, Dmitry A. Kazakov wrote:

>> In Julia, the way I understand it, when defining a function
>> with some signature, then a compiled instance of this function
>> is made for all the possible primitive types (int16, int32,
>> real32, real64, etc...)
>
> Is made by whom?
>

If you mean in implementation, it is the by
the "just-in-time (JIT) compilation, implemented using LLVM"

The actual language is designed in MIT.

>> and when the program is run,
>> the run-time automatically dispatches to the correct matching
>> function based on the argument used at time the call is made.
>

> Really? What is the "correct matching" function of int16/real32? Can I have
> real_bounded_interval_64? What would be int16/real_bounded_interval_64? Who
> does linear system equation resolution function for int16?
>

 From http://julia.readthedocs.org/en/latest/manual/introduction/ it says

"The ability to define function behavior across
many combinations of argument types via multiple dispatch"
.....
"While the casual programmer need not explicitly
use types or multiple dispatch, they are the core
unifying features of Julia: functions are defined on
different combinations of argument types, and applied
by dispatching to the most specific matching definition."

It seems to be strongly typed language, but
in dynamic sense, (when running the program, one finds
their errors) and not at compile time.

I am no expert in Julia, I just build it on Linux and played
with it a little, since it has syntax that is close to
Matlab in some sense. The above link talks more about
the design of the language itself.

I only mentioned it, since dynamic languages seems to be
the trend these days, and this was a good example.

> The idea that there exist "primitive" and "non-primitive" types is garbage.
> The idea that any operation is applicable to any type is garbage.
>
>> Those good old fashioned, strong static type checking
>> at compile time computer languages, seem like, well, old
>> fashioned these days.
>
> If even members of ARG seem not to believe in merits of strong typing or
> whatever typing...
>

Yes, strong static typing is a good thing.

--Nasser

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Sat, 12 Apr 2014 11:55:32 +0200, Georg Bauhaus wrote:

> On 12/04/14 11:38, Dmitry A. Kazakov wrote:
>>> >In Julia, the way I understand it, when defining a function
>>> >with some signature, then a compiled instance of this function
>>> >is made for all the possible primitive types (int16, int32,
>>> >real32, real64, etc...)
>> Is made by whom?
> 
> MIT.

I meant the implementation of all possible cross breeds of parameters.

> Announced for efficient scientific computing.

Sure.

"This lotion is against cockroaches and a foot perspiration remedy. One
drop of the lotion put in a glass of water turns it into a glass of vodka.
Three drops of the same lotion do a glass of Cognac."

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

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Sat, 12 Apr 2014 05:17:42 -0500, Nasser M. Abbasi wrote:

> On 4/12/2014 4:38 AM, Dmitry A. Kazakov wrote:
> 
>> Really? What is the "correct matching" function of int16/real32? Can I have
>> real_bounded_interval_64? What would be int16/real_bounded_interval_64? Who
>> does linear system equation resolution function for int16?
> 
>  From http://julia.readthedocs.org/en/latest/manual/introduction/ it says
> 
> "The ability to define function behavior across
> many combinations of argument types via multiple dispatch"

An ability to define is not a definition. I asked who defines, not if it
were possible to define.

Though people from MIT should know better not to define natural logarithm
for int16...

> It seems to be strongly typed language, but
> in dynamic sense, (when running the program, one finds
> their errors) and not at compile time.

This makes the language untyped. Type errors at run-time are bugs or else
lack of typing. Weak typing is when at run-time there is possible deviation
of behavior, yet no errors. Strong typing is when the deviation of behavior
is promoted to statically detected type error. Since semantics is
incomputable no language is absolutely strong. But Ada is stronger than C.

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

Re: Your wish list for Ada 202X

[Niklas Holsti]

On 14-04-12 11:20 , Dmitry A. Kazakov wrote:
> On Sat, 12 Apr 2014 00:04:48 +0200, Niklas Holsti wrote:
> 
>> On 14-04-11 22:43 , Dmitry A. Kazakov wrote:
>>> On Fri, 11 Apr 2014 21:04:58 +0200, Niklas Holsti wrote:
>>>
>>>> On 14-04-10 17:31 , Dmitry A. Kazakov wrote:
>>>>> On Wed, 9 Apr 2014 22:28:36 -0500, Randy Brukardt wrote:
>>>>
>>>>   [snip]
>>>>
>>>>>> We don't want "type-specific" implementations of most things -- that's just 
>>>>>> adding a maintenance headache where one isn't needed.
>>>>>
>>>>> It is need for
>>>>>
>>>>> 1. safety (because you statically know that certain specific operation may
>>>>> not fail, while class-wide operations can)
>>>>>
>>>>> 2. efficiency
>>>>>
>>>>> There is no maintenance overhead whatsoever. Here is the proof. Let you can
>>>>> provide a generic implementation (as you suggested), then this
>>>>> implementation can be safely inherited. 
>>>>
>>>> If you change a class-wide operation to an inherited (i.e. primitive)
>>>> operation, you have to change its dispatching calls to redispatching
>>>> calls, if you want the same behaviour as for the class-wide operation.
>>>
>>> No. I meant that the behavior of class-wide operation was defined = there
>>> were no re-dispatch to operations that could be overridden to some
>>> unanticipated behavior.
>>
>> You mean that a class-wide operation should not call any primitive
>> operations of its parameters?
> 
> They should, that was not the point. Which was maintainability. A
> class-wide operation cannot be more maintainable than a primitive
> operation. At least, it would require the level of contract thoroughness
> Ada presently does not possess, not even close.
> 
>>> Regarding use cases where re-dispatch comes in question, which certainly
>>> exist,
>>
>> Ah, that is comforting. I thought you were totally against redispatch.
> 
> Yes I am. Re-dispatch is a flawed solution to a real problem.

Oh. Then I'm not comforted after all.

> I don't deny
> existence of the problem. I am against the solution, which is inherently
> unsafe and constraining (precludes by-copy semantics).

But class-wide operations which contain dispatching calls also preclude
by-copy semantics, don't they? Unless you consider a class-wide type as
similar to an access type, and pass a reference (pointer) by copy. Which
would be a silly meaning of "by-copy".

A class-wide operation, in my view, is just like a primitive operation
except that (1) (re-)dispatching is implicit and automatic for all calls
to primitive operations of the parameter object (because the parameter
is a class-wide type) and (2) the operation cannot be overridden.

Because of (2) I don't often use class-wide operations, but instead make
the operation primitive for the root type and use re-dispatching.

(This is why I don't understand your and Randy's abhorrence of
re-dispatching -- to me, there is no basic difference between
dispatching calls in class-wide operations, and re-dispatching calls in
primitive operations.)

>>> I think that from the safety and maintenance point of view, the type
>>> system should provide means of body composition beyond simple inherit vs.
>>> override.
>>
>> That is certainly an interesting issue. You are thinking of something of
>> the same kind as the "inner" of Simula?
> 
> Yes, but it looks too low-level and hackish to me.

I agree, for the "inner" thing itself. Some language constructs in the
same area (composition of bodies along the inheritance axis) could be
useful, but I don't now see the problems to be solved by these
constructs, because re-dispatching works well enough for me.

> The concept should somehow play together with the notion of polymorphic
> operation defined on the class (set of types). Between these two ends:
> independent bodies of a primitive operation and single body of a class-wide
> operation, there lies a whole spectrum of unexplored possibilities.

I feel that my use of re-dispatching gives me something like that. And I
don't see the problems in re-dispatching that you and Randy worry about.

>> In my own code, the primitive operations of a type are typically layered
>> into levels: higher-level operations and lower-level ones. An overriding
>> higher-level primitive operation is typically implemented by calling
>> (with redispatch) lower-level primitive operations of the parameter
>> object. The *same* (i.e. overridden) operation of the parent type is
>> usually not called, nor does a primitive operation of a parent type call
>> the same primitive operation from the actual derived type; only
>> operations from lower layers are called.
> 
> Yes, this is the way I implement it too. The difference is that I try to
> keep "higher-level" operations class-wide.

I have a few class-wide ops, but not many. They are for sure the
higher-level, if not highest-level ops.

> Then I try to maintain the "no
> abstraction inversion" rule, i.e. never call a "higher-level" operation
> from a "lower-level" one.

Yes, same here.

> Note that when "higher-level" operations are made class-wide, there is also
> a formalized separation of two, as they act on different types.

I think I have some classes with more than two levels of operations, so
this separation would not work fully there.

>>> We know, for example, that constructors (initialize) and
>>> destructors (finalize) require other means of composition. More elaborated
>>> composition tools should eliminate re-dispatch (and most class-wide
>>> operations) => give safety and maintainability.
>>
>> Maybe... suggest something and we'll see.
> 
> It is useless to suggest anything, as you know.

Suggestions have to be very well motivated, as befits Ada's goals of
long-term stability and portability.

> And, I am not a language
> designer anyway. I am a programmer. As a programmer, from my experience
> with Ada, I tell the language designers that they got it all wrong since
> Ada 2005. I don't want yet another dynamically typed or functional
> language. I need a language for software engineering. More static checks,
> more means to make static checks possible. The whole language should
> revolute around helping restructuring my programs in order to support
> static checks. No Constraint_Error to me, please!

That's a good goal, but I don't think it should be the only goal for Ada.

Ada's problem and challenge is that it very ambitiously aims to combine
high-level, expressive, and therefore somewhat dynamic language features
with predictable, efficient execution as required for critical embedded
systems.

I think that it will be more and more difficult to extend and evolve Ada
in both directions (high-level, expressive, dynamic; vs. low-level,
predictable, static) without in practice dividing the language into two:
a "high-Ada" and a "low-Ada", with some compilers targeting the high and
others the low. A bit of that can already be seen now, with some
compilers supporting only some Ada standards and some limited profiles
such as Ravenscar. This division may be the only way to support further
Ada-style programming at both high and low levels. It may not be too bad
a thing, as long as there is a decent amount of overlap (common middle
ground) between high-Ada and low-Ada.

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

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Sun, 13 Apr 2014 22:43:47 +0300, Niklas Holsti wrote:

> On 14-04-12 11:20 , Dmitry A. Kazakov wrote:

>> I don't deny
>> existence of the problem. I am against the solution, which is inherently
>> unsafe and constraining (precludes by-copy semantics).
> 
> But class-wide operations which contain dispatching calls also preclude
> by-copy semantics, don't they?

Not at all. There is no problem for a class-wide operation to act on
by-copy types.

A by-copy class-wide object is a tuple (tag, type-specific value). Upon
dispatch the value is passed copy-in/copy-out to the type specific
operation.

> A class-wide operation, in my view, is just like a primitive operation
> except that (1) (re-)dispatching is implicit and automatic for all calls
> to primitive operations of the parameter object (because the parameter
> is a class-wide type) and (2) the operation cannot be overridden.

There is no re-dispatching in a class-wide operation. It is defined on
class-wide objects, so it simply neither dispatch nor re-dispatch.
 
> (This is why I don't understand your and Randy's abhorrence of
> re-dispatching -- to me, there is no basic difference between
> dispatching calls in class-wide operations, and re-dispatching calls in
> primitive operations.)

The difference is in types involved. A body of a primitive operation is
defined on a particular specific type. A re-dispatch within the body
breaks this type contract by calling an operation defined on *another*
type. This is an untyped behavior.
 
>> The concept should somehow play together with the notion of polymorphic
>> operation defined on the class (set of types). Between these two ends:
>> independent bodies of a primitive operation and single body of a class-wide
>> operation, there lies a whole spectrum of unexplored possibilities.
> 
> I feel that my use of re-dispatching gives me something like that. And I
> don't see the problems in re-dispatching that you and Randy worry about.

Untyped programming style has known problems. The point is not that an
improperly typed program could not expose correct behavior. Of course it
can, "it worked to me" is never an argument. One could design a working
program directly in machine code. That does not imply that this would be a
good idea.

>> Then I try to maintain the "no
>> abstraction inversion" rule, i.e. never call a "higher-level" operation
>> from a "lower-level" one.
> 
> Yes, same here.

But re-dispatch would be exactly this kind of inversion. Remember, no
higher-level operation is primitive, since I make all higher-level
operations class-wide or else self-contained.

>> And, I am not a language
>> designer anyway. I am a programmer. As a programmer, from my experience
>> with Ada, I tell the language designers that they got it all wrong since
>> Ada 2005. I don't want yet another dynamically typed or functional
>> language. I need a language for software engineering. More static checks,
>> more means to make static checks possible. The whole language should
>> revolute around helping restructuring my programs in order to support
>> static checks. No Constraint_Error to me, please!
> 
> That's a good goal, but I don't think it should be the only goal for Ada.
> 
> Ada's problem and challenge is that it very ambitiously aims to combine
> high-level, expressive, and therefore somewhat dynamic language features
> with predictable, efficient execution as required for critical embedded
> systems.

It depends on your understanding of dynamic features. To me it is all OK to
have dynamic features (AKA generic programming) under certain conditions.
One is that the language remains typed. Ada 95 solved that by introducing a
separate type for class-wide objects. Another is that generalized contracts
remain statically checked. Again, it is partially so, because Ada 95
guaranteed that dispatch never fail, an operation is either inherited or
else requires overriding. There is no gaps in the dispatching table (except
for missing MD). But Ada 83 missed that goal when introduced
Constraint_Error for discriminated types, array bounds, overflows without
means to check exception contracts statically. Ada 2005/2012 broke things
even further by adding dynamic constraints, predicates etc.

A related requirement is that whatever categories the language introduces
they must be spelt as objects, types, operations. The language must be
well-structured. Ada 85/95 was, though it had no so much typed things, like
ranges and attributes. Ada 2005/2012 ruined much of that.

> I think that it will be more and more difficult to extend and evolve Ada
> in both directions (high-level, expressive, dynamic; vs. low-level,
> predictable, static) without in practice dividing the language into two:
> a "high-Ada" and a "low-Ada", with some compilers targeting the high and
> others the low.

I don't believe in this separation. To me dynamic vs. static is not high
vs. low. In first place, there is no fully dynamic system. For any given
system observed as dynamic, you can always lump together involved objects,
call the result a type and things become static again.

So, the requirement is that you can have your dynamic things as much you
want, but you MUST introduce an explicit named type for the resulting set
of objects. Just as Ada 95 did with T'Class.

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

Re: Your wish list for Ada 202X

[J Kimball]

On 03/25/2014 04:41 PM, Stoik wrote:
> I think that even a casual user of Ada should be able to influence somehow the new version of Ada. I wonder what is high on your list of wishes for Ada 202X?
> I suspect many of the proposals could be tested in GNAT before being introduced (or rejected) in the new version. One could add a switch to GNAT indicating that we want to use some of the experimental features.
>

I found myself in a situation in which some syntactic sugar on Ada 2012 might be able to help with.

type T is ...;

A : T;

case A is
    when X => null;
    when Y | Z  =>
       case A is
          when Y => null;
          when Z => null;
          when X => null; -- Bleh
       end case;
end case;

I wish there was someway I wouldn't have to cover X for the inner case like maybe the branches could be have variables with implicitly defined subtypes.

case A is
    when X => null;
    when B : Y | Z  =>
       case B is
          when Y => null;
          when Z => null;
       end case;
end case;

A bit of exception choice syntax and an implicit subtype a la Ada 2012.

B : Y | Z might translate to: subtype /anonymous/ is T with Static_Predicate => T in Y | Z; B : /anonymous/; -- Predicate syntax might be wrong.

Is a minor thing, but would save me grumbling each time I do this.

Re: Your wish list for Ada 202X

[Shark8]

You can do that already, with explicitly defined subtypes -- consider:

Input : Integer;

-- ...

Case Input of
   When Integer'First..-1 => -- Handle negative numbers
   When others =>
    Case Natural'(Input) is
     When Natural'First =>   -- Handle 0.
     When Positive'Range =>  -- Handle positives.
    end case;
end case;

But I *do* see how a "implicit subrange" could be interesting/useful.

Re: Your wish list for Ada 202X

[Shark8]

On 25-Mar-14 15:41, Stoik wrote:
> I think that even a casual user of Ada should be able to influence
> somehow the new version of Ada. I wonder what is high on your list
> of wishes for Ada 202X?
>
> I suspect many of the proposals could be tested in GNAT before
> being introduced (or rejected) in the new version. One could add a
> switch to GNAT indicating that we want to use some of the
> experimental features.

Perhaps a way to use a procedure as a function, now that functions can 
have in/in-out parameter modes. Maybe with syntax like:

  Procedure Y( Input  : in     In_type;
               State  : in out State_Type;
               Output :    out Out_Type );
  Function X renames Y with return Output;

-- Function X being roughly equivalent to the following:
  Function X ( Input  : in     In_type;
               State  : in out State_Type)
               return Out_Type is
  begin
   Return Result : Out_Type do
     Y( Input => Input, State => State, Output => Result );
   end return;
  end X;

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:9cm2e094hvj7.sj0t2sh2komn.dlg@40tude.net...
> On Fri, 11 Apr 2014 16:44:13 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:16388p09ph28u$.1mglp0rm7pli9$.dlg@40tude.net...
>
>>> Your example refers to overloading possible for operations on unrelated
>>> types. I don't see how this is scenario could be possible for a 
>>> primitive
>>> MD operation. One of the requirements put on MD is that *all* 
>>> combinations
>>> of tags up to the root of the inheritance tree be defined and checked at
>>> compile time. This requirement automatically precludes appearance of C 
>>> from
>>> air. It cannot be primitive and thus the preference rules would not 
>>> apply
>>> to it.
>>
>> Doesn't matter. First, you'd have to prevent adding or removing new
>> primitive operations to a hierarchy. That seems like a nasty limitation.
>
> What? This limitation is with us since Ada 95! You cannot add a primitive
> operation after the freezing point in Ada. You cannot remove a primitive
> operation at all.

This is an issue with program maintenance, not with an unchanging 
declaration -- so freezing is completely irrelevant. If someone decides 
there is a need to add a primitive operation to the root (for instance), 
then a preference rule towrd the root could potentially silently change the 
behavior of a otherwise tested/proved program. That's the sort of thing that 
needs to be prevented, lest maintenance become too dangerous to allow in 
existing systems.

                                           Randy.

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1bmn1nyjcs0ms.1hs63q2q8nzke.dlg@40tude.net...
> On Sat, 12 Apr 2014 11:55:32 +0200, Georg Bauhaus wrote:
>
>> On 12/04/14 11:38, Dmitry A. Kazakov wrote:
>>>> >In Julia, the way I understand it, when defining a function
>>>> >with some signature, then a compiled instance of this function
>>>> >is made for all the possible primitive types (int16, int32,
>>>> >real32, real64, etc...)
>>> Is made by whom?
>>
>> MIT.
>
> I meant the implementation of all possible cross breeds of parameters.
>
>> Announced for efficient scientific computing.
>
> Sure.
>
> "This lotion is against cockroaches and a foot perspiration remedy. One
> drop of the lotion put in a glass of water turns it into a glass of vodka.
> Three drops of the same lotion do a glass of Cognac."

"It's a desert topping AND a floor wax!" - Saturday Night Live, 1975.

(The American version of the above, and one of my favorite comedy bits of 
all time, because everybody wants something like it, no matter what the 
field of endevour.)

                                           Randy.

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:br07nkFnvrbU1@mid.individual.net...
...
> (This is why I don't understand your and Randy's abhorrence of
> re-dispatching -- to me, there is no basic difference between
> dispatching calls in class-wide operations, and re-dispatching calls in
> primitive operations.)

I don't think it is a good idea to assume that Dmitry and I have the same 
opinion on anything, even if the result appears to be the same. :-)

I view dispatching operations as the low-level primitives of a type, while 
class-wide operations (which actually involve dispatching) as higher-level 
operations of the type. As such, a re-dispatching call means that there is 
some sort of abstraction inversion going on, and that's usually (but not 
always) bad.

Dispatching operations necessarily have weaker contracts than statically 
bound calls, and that is especially important for "contracts" that can't be 
described in Ada and thus can't be checked (either statically or 
dynamically). After all, most extensions are created by someone other than 
the originator of the original class, so violations of those implicit 
contracts are bound to happen. (Errors happen any time humans are involved!) 
Thus, you have much more confidence in operations that don't involve 
re-dispatching -- as a practical matter, it is a lot easier to debug 
statically bound calls rather than dispatching ones.

Finally (really a restating of the last point), I find that it's fairly easy 
to ensure that all of the primitive operations of a particular type have the 
same world-view. That's not as true when some of the operations are assuming 
the object is of type T, and some are re-dispatching to some TT derived from 
T -- I've found many instances where some predicate of TT gets a different 
answer than the same predicate of the same object viewed as a T. That sort 
of things leads to all kinds of bugs, because not all of those predicates 
are explicit in the code (even as statically bound calls).

This last issue doesn't arise for a class-wide operation, where every call 
is going to look at an object of TT as type TT. And that's really the major 
difference between "dispatching" and "re-dispatching".

Perhaps I'm just being too conservative here, but I do like being able to 
get things to work as expected.

                                      Randy.


 

Re: Your wish list for Ada 202X

[Randy Brukardt]

We've (the ARG) already discussed this issue - see the e-mail of 
AI12-0086-1. Proper solutions are way too incompatible with existing code, 
and solutions that aren't incompatible are way too complex (involving 
allowing several possible ways to write the same thing, but still 
disallowing other cases so that we are still getting completeness checking). 
So this is only fixable with added syntax, but this problem is nowhere near 
important enough to add syntax (how common are nested variants?).

                                                   Randy.

"J Kimball" <spam@example.com> wrote in message 
news:lifq02$dap$1@loke.gir.dk...
> On 03/25/2014 04:41 PM, Stoik wrote:
>> I think that even a casual user of Ada should be able to influence 
>> somehow the new version of Ada. I wonder what is high on your list of 
>> wishes for Ada 202X?
>> I suspect many of the proposals could be tested in GNAT before being 
>> introduced (or rejected) in the new version. One could add a switch to 
>> GNAT indicating that we want to use some of the experimental features.
>>
>
> I found myself in a situation in which some syntactic sugar on Ada 2012 
> might be able to help with.
>
> type T is ...;
>
> A : T;
>
> case A is
>    when X => null;
>    when Y | Z  =>
>       case A is
>          when Y => null;
>          when Z => null;
>          when X => null; -- Bleh
>       end case;
> end case;
>
> I wish there was someway I wouldn't have to cover X for the inner case 
> like maybe the branches could be have variables with implicitly defined 
> subtypes.
>
> case A is
>    when X => null;
>    when B : Y | Z  =>
>       case B is
>          when Y => null;
>          when Z => null;
>       end case;
> end case;
>
> A bit of exception choice syntax and an implicit subtype a la Ada 2012.
>
> B : Y | Z might translate to: subtype /anonymous/ is T with 
> Static_Predicate => T in Y | Z; B : /anonymous/; -- Predicate syntax might 
> be wrong.
>
> Is a minor thing, but would save me grumbling each time I do this. 

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Shark8" <OneWingedShark@gmail.com> wrote in message 
news:ICL2v.19008$8l4.966@fx29.iad...
> You can do that already, with explicitly defined subtypes -- consider:
>
> Input : Integer;
>
> -- ...
>
> Case Input of
>   When Integer'First..-1 => -- Handle negative numbers
>   When others =>
>    Case Natural'(Input) is
>     When Natural'First =>   -- Handle 0.
>     When Positive'Range =>  -- Handle positives.
>    end case;
> end case;

Right, but this isn't legal for a variant. So there is an issue for 
variants. The problem is adding an implicit subtype would be very 
incompatible, as it would mean that cases that currently *require* some 
branch would *forbid* them in new code. I suggesting making something like 
the above legal, but it got no traction whatsoever. The alternatives 
proposed are way too complex in my view - they would require a complete redo 
of the way case completeness is handled (both in implementations and to a 
lesser extent in the RM), and the problem just isn't worth that much effort.

                                                    Randy.

Re: Your wish list for Ada 202X

[J Kimball]

More than you'd think I guess. Maybe I overuse them. I try as hard as I can to get anything with discrete values into a matching type. It'd be a lot more painful in a language with switch statements that use breaks. The coverage rules make me feel safer.

On 04/14/2014 07:18 PM, Randy Brukardt wrote:
> We've (the ARG) already discussed this issue - see the e-mail of
> AI12-0086-1. Proper solutions are way too incompatible with existing code,
> and solutions that aren't incompatible are way too complex (involving
> allowing several possible ways to write the same thing, but still
> disallowing other cases so that we are still getting completeness checking).
> So this is only fixable with added syntax, but this problem is nowhere near
> important enough to add syntax (how common are nested variants?).
>
>                                                     Randy.
>
> "J Kimball" <spam@example.com> wrote in message
> news:lifq02$dap$1@loke.gir.dk...
>> On 03/25/2014 04:41 PM, Stoik wrote:
>>> I think that even a casual user of Ada should be able to influence
>>> somehow the new version of Ada. I wonder what is high on your list of
>>> wishes for Ada 202X?
>>> I suspect many of the proposals could be tested in GNAT before being
>>> introduced (or rejected) in the new version. One could add a switch to
>>> GNAT indicating that we want to use some of the experimental features.
>>>
>>
>> I found myself in a situation in which some syntactic sugar on Ada 2012
>> might be able to help with.
>>
>> type T is ...;
>>
>> A : T;
>>
>> case A is
>>     when X => null;
>>     when Y | Z  =>
>>        case A is
>>           when Y => null;
>>           when Z => null;
>>           when X => null; -- Bleh
>>        end case;
>> end case;
>>
>> I wish there was someway I wouldn't have to cover X for the inner case
>> like maybe the branches could be have variables with implicitly defined
>> subtypes.
>>
>> case A is
>>     when X => null;
>>     when B : Y | Z  =>
>>        case B is
>>           when Y => null;
>>           when Z => null;
>>        end case;
>> end case;
>>
>> A bit of exception choice syntax and an implicit subtype a la Ada 2012.
>>
>> B : Y | Z might translate to: subtype /anonymous/ is T with
>> Static_Predicate => T in Y | Z; B : /anonymous/; -- Predicate syntax might
>> be wrong.
>>
>> Is a minor thing, but would save me grumbling each time I do this.
>
>

Re: Your wish list for Ada 202X

[Natasha Kerensikova]

Hello,

On 2014-04-15, Randy Brukardt <randy@rrsoftware.com> wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
> news:br07nkFnvrbU1@mid.individual.net...
> ...
>> (This is why I don't understand your and Randy's abhorrence of
>> re-dispatching -- to me, there is no basic difference between
>> dispatching calls in class-wide operations, and re-dispatching calls in
>> primitive operations.)
>
> [...]
>
> Finally (really a restating of the last point), I find that it's fairly easy 
> to ensure that all of the primitive operations of a particular type have the 
> same world-view. That's not as true when some of the operations are assuming 
> the object is of type T, and some are re-dispatching to some TT derived from 
> T -- I've found many instances where some predicate of TT gets a different 
> answer than the same predicate of the same object viewed as a T. That sort 
> of things leads to all kinds of bugs, because not all of those predicates 
> are explicit in the code (even as statically bound calls).
>
> This last issue doesn't arise for a class-wide operation, where every call 
> is going to look at an object of TT as type TT. And that's really the major 
> difference between "dispatching" and "re-dispatching".

Thanks for the explanation, but I'm a bit lost where the situation I
have encountered the most fits in "dispatching" vs "re-dispatching":

let's consider an abstract type T, with an abstract operation AO and a
huge part of the algorithm implemented in primitive operations for T,
making use of AO. Concrete descendants of T are supposed to implement
AO, and inherit the rest without overriding.

Then in T subprograms I end up with things that look like:
   AO (T'Class (Self), Other, Arguments);


I've always thought of this as "re-disatching". Is it?

Is it somehow more acceptable? (maybe it doesn't make any sense to
consider it as some "predicate with the same object viewed as T")

Are there better language facilities to use in such situations?
(I used to use generics for that, and still do when there is absolutely
no plan for any child package)


Thanks for the clarification,
Natasha

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Mon, 14 Apr 2014 18:39:24 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:9cm2e094hvj7.sj0t2sh2komn.dlg@40tude.net...
>> On Fri, 11 Apr 2014 16:44:13 -0500, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:16388p09ph28u$.1mglp0rm7pli9$.dlg@40tude.net...
>>
>>>> Your example refers to overloading possible for operations on unrelated
>>>> types. I don't see how this is scenario could be possible for a 
>>>> primitive
>>>> MD operation. One of the requirements put on MD is that *all* 
>>>> combinations
>>>> of tags up to the root of the inheritance tree be defined and checked at
>>>> compile time. This requirement automatically precludes appearance of C 
>>>> from
>>>> air. It cannot be primitive and thus the preference rules would not 
>>>> apply
>>>> to it.
>>>
>>> Doesn't matter. First, you'd have to prevent adding or removing new
>>> primitive operations to a hierarchy. That seems like a nasty limitation.
>>
>> What? This limitation is with us since Ada 95! You cannot add a primitive
>> operation after the freezing point in Ada. You cannot remove a primitive
>> operation at all.
> 
> This is an issue with program maintenance, not with an unchanging 
> declaration -- so freezing is completely irrelevant. If someone decides 
> there is a need to add a primitive operation to the root (for instance), 
> then a preference rule towrd the root could potentially silently change the 
> behavior of a otherwise tested/proved program. That's the sort of thing that 
> needs to be prevented, lest maintenance become too dangerous to allow in 
> existing systems.

It is not prevented now and cannot be prevented in the future. If you
change the package specification, which is the only way to add an operation
you potentially change anything. This requires recompilation of all
clients, which is OK, as you said earlier. Thus the problem does not exist.

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

Re: Your wish list for Ada 202X

[J-P. Rosen]

Le 15/04/2014 00:36, Shark8 a écrit :
> Perhaps a way to use a procedure as a function, now that functions can
> have in/in-out parameter modes. Maybe with syntax like:
> 
>  Procedure Y( Input  : in     In_type;
>               State  : in out State_Type;
>               Output :    out Out_Type );
>  Function X renames Y with return Output;
> 
> -- Function X being roughly equivalent to the following:
>  Function X ( Input  : in     In_type;
>               State  : in out State_Type)
>               return Out_Type is
>  begin
>   Return Result : Out_Type do
>     Y( Input => Input, State => State, Output => Result );
>   end return;
>  end X;
It is not equivalent. If, for example, Out_Type is an unconstrained
array type, the procedure has access to (and must obey by) the
constraint of the parameter, while a function can return an object of
any size.

-- 
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: Your wish list for Ada 202X

[Randy Brukardt]

"Natasha Kerensikova" <lithiumcat@instinctive.eu> wrote in message 
news:slrnlkpnfe.i0l.lithiumcat@nat.rebma.instinctive.eu...
...
> let's consider an abstract type T, with an abstract operation AO and a
> huge part of the algorithm implemented in primitive operations for T,
> making use of AO. Concrete descendants of T are supposed to implement
> AO, and inherit the rest without overriding.
>
> Then in T subprograms I end up with things that look like:
>   AO (T'Class (Self), Other, Arguments);
>
> I've always thought of this as "re-disatching". Is it?

I think it is as well.

> Is it somehow more acceptable? (maybe it doesn't make any sense to
> consider it as some "predicate with the same object viewed as T")

Perhaps. The only cases where I've intentionally used re-dispatching look 
like this (one example: action routines in Claw, which are of course 
implemented by each extension -- but the bulk of the work is shared by all 
implementations). Such a case seems somehow different, but I don't think I 
can explain why.

> Are there better language facilities to use in such situations?
> (I used to use generics for that, and still do when there is absolutely
> no plan for any child package)

I don't know of any. One could use access-to-subprograms for such usage, but 
I don't see any big advantage to doing that instead -- there seems to be 
more chance of getting something wrong that way. (Failure to register, 
registering the wrong routine, etc. can't happen with the overridding 
routine solution.)

I suspect that the reason re-dispatching is allowed is because there are 
some cases like this where nothing else would seem to work as well. But 
perhaps there is a better solution, we just haven't found it yet.

                                  Randy.

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:f2mjap6bd64o$.1kk55f3m1qbn1$.dlg@40tude.net...
> On Mon, 14 Apr 2014 18:39:24 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:9cm2e094hvj7.sj0t2sh2komn.dlg@40tude.net...
>>> On Fri, 11 Apr 2014 16:44:13 -0500, Randy Brukardt wrote:
>>>
>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>>> news:16388p09ph28u$.1mglp0rm7pli9$.dlg@40tude.net...
>>>
>>>>> Your example refers to overloading possible for operations on 
>>>>> unrelated
>>>>> types. I don't see how this is scenario could be possible for a
>>>>> primitive
>>>>> MD operation. One of the requirements put on MD is that *all*
>>>>> combinations
>>>>> of tags up to the root of the inheritance tree be defined and checked 
>>>>> at
>>>>> compile time. This requirement automatically precludes appearance of C
>>>>> from
>>>>> air. It cannot be primitive and thus the preference rules would not
>>>>> apply
>>>>> to it.
>>>>
>>>> Doesn't matter. First, you'd have to prevent adding or removing new
>>>> primitive operations to a hierarchy. That seems like a nasty 
>>>> limitation.
>>>
>>> What? This limitation is with us since Ada 95! You cannot add a 
>>> primitive
>>> operation after the freezing point in Ada. You cannot remove a primitive
>>> operation at all.
>>
>> This is an issue with program maintenance, not with an unchanging
>> declaration -- so freezing is completely irrelevant. If someone decides
>> there is a need to add a primitive operation to the root (for instance),
>> then a preference rule towrd the root could potentially silently change 
>> the
>> behavior of a otherwise tested/proved program. That's the sort of thing 
>> that
>> needs to be prevented, lest maintenance become too dangerous to allow in
>> existing systems.
>
> It is not prevented now and cannot be prevented in the future. If you
> change the package specification, which is the only way to add an 
> operation
> you potentially change anything. This requires recompilation of all
> clients, which is OK, as you said earlier. Thus the problem does not 
> exist.

(A) we're specifically talking about a single addition or deletion, *not* a 
general "change".
(B) Of course we're changing the specification and recompiling. But we don't 
want the same client code to mean something different after that 
recompilation without detection -- in the case of a single addition or 
deletion (again, *not* a change).

The reason here is that maintainers need to be free to ADD new 
operations/entities without changing the behavior of any pre-existing client 
(which necessarily does not use those new operations/entities). Otherwise, 
maintenance is just a turkey shoot in which you really have no idea what 
will happen -- deadly in large systems, especially with reused code that's 
not in your control (think of a new version of GTK or Claw). OTOH, if 
maintainers *change* an operation/entity, then the language can (and should) 
provide no assurances.

                                        Randy.

Re: Your wish list for Ada 202X

[Niklas Holsti]

On 14-04-15 10:21 , Natasha Kerensikova wrote:
> Hello, 

  [snip]

> let's consider an abstract type T, with an abstract operation AO and a
> huge part of the algorithm implemented in primitive operations for T,
> making use of AO. Concrete descendants of T are supposed to implement
> AO, and inherit the rest without overriding.
> 
> Then in T subprograms I end up with things that look like:
>    AO (T'Class (Self), Other, Arguments);
> 
> 
> I've always thought of this as "re-disatching". Is it?

Yes, as I understand the word.

> Are there better language facilities to use in such situations?

If, as you say above, descendants of T are supposed to inherit the
primitive operations of T *without overriding them*, you could implement
those primitive operations instead as class-wide operations (operations
on T'Class), and then calls of AO from those class-wide operations would
be (simply) dispatching, and not re-dispatching.

As I understand them, both Dmitry and Randy would consider the
class-wide form a better solution, but it works only if you never need
to override these class-wide operations for any descendant types.

I am seldom sure about that (never needing to override, not even in the
future), so I prefer to have the operations as primitive rather than
class-wide, and consequently to use re-dispatch.

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

Re: Your wish list for Ada 202X

[Natasha Kerensikova]

Hello,

On 2014-04-16, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
> On 14-04-15 10:21 , Natasha Kerensikova wrote:
>> I've always thought of this as "re-disatching". Is it?
>
> Yes, as I understand the word.
>
>> Are there better language facilities to use in such situations?
>
> If, as you say above, descendants of T are supposed to inherit the
> primitive operations of T *without overriding them*, you could implement
> those primitive operations instead as class-wide operations (operations
> on T'Class), and then calls of AO from those class-wide operations would
> be (simply) dispatching, and not re-dispatching.
>
> As I understand them, both Dmitry and Randy would consider the
> class-wide form a better solution, but it works only if you never need
> to override these class-wide operations for any descendant types.
>
> I am seldom sure about that (never needing to override, not even in the
> future), so I prefer to have the operations as primitive rather than
> class-wide, and consequently to use re-dispatch.

Indeed, I can make the whole algorithm class-wide, I had completely
missed the possibility.

In the few cases of such redispatching I encountered recently, it makes
sense to actively prevent the non-abstract operations from being
overridden, because they really need some kind of internal consistency,
so you would either override all of them or none. If you would override
them all, you can just build a new type with the same interface and use
composition.

However it turns out that in those cases I actually can't make them
class-wide, because those operations are part of an interface publicly
implemented by the abstract type. And even if you think of interfaces as
evil, it seems the same problem would arise with a purely abstract
parent.

Is there a technical reason to forbid abstract operations from being
implemented by a class-wide operation on a descendant type, and thereby
being shared rather than inherited for the whole subtree?



Natasha

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Wed, 16 Apr 2014 09:32:15 +0300, Niklas Holsti wrote:

> As I understand them, both Dmitry and Randy would consider the
> class-wide form a better solution, but it works only if you never need
> to override these class-wide operations for any descendant types.

BTW, the language design principle: each type must have a class.

Let T'Class would have a class (T'Class'Class). Then a class-wide operation
of T becomes a primitive operation of T'Class, and thus could be overridden
in some subclass.

Surely there would be problems with that, starting with the problem is that
T'Class is matched by structure rather nominally...

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

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Tue, 15 Apr 2014 16:27:05 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:f2mjap6bd64o$.1kk55f3m1qbn1$.dlg@40tude.net...
>> On Mon, 14 Apr 2014 18:39:24 -0500, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:9cm2e094hvj7.sj0t2sh2komn.dlg@40tude.net...
>>>> On Fri, 11 Apr 2014 16:44:13 -0500, Randy Brukardt wrote:
>>>>
>>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>>>> news:16388p09ph28u$.1mglp0rm7pli9$.dlg@40tude.net...
>>>>
>>>>>> Your example refers to overloading possible for operations on 
>>>>>> unrelated
>>>>>> types. I don't see how this is scenario could be possible for a
>>>>>> primitive
>>>>>> MD operation. One of the requirements put on MD is that *all*
>>>>>> combinations
>>>>>> of tags up to the root of the inheritance tree be defined and checked 
>>>>>> at
>>>>>> compile time. This requirement automatically precludes appearance of C
>>>>>> from
>>>>>> air. It cannot be primitive and thus the preference rules would not
>>>>>> apply
>>>>>> to it.
>>>>>
>>>>> Doesn't matter. First, you'd have to prevent adding or removing new
>>>>> primitive operations to a hierarchy. That seems like a nasty 
>>>>> limitation.
>>>>
>>>> What? This limitation is with us since Ada 95! You cannot add a 
>>>> primitive
>>>> operation after the freezing point in Ada. You cannot remove a primitive
>>>> operation at all.
>>>
>>> This is an issue with program maintenance, not with an unchanging
>>> declaration -- so freezing is completely irrelevant. If someone decides
>>> there is a need to add a primitive operation to the root (for instance),
>>> then a preference rule towrd the root could potentially silently change 
>>> the
>>> behavior of a otherwise tested/proved program. That's the sort of thing 
>>> that
>>> needs to be prevented, lest maintenance become too dangerous to allow in
>>> existing systems.
>>
>> It is not prevented now and cannot be prevented in the future. If you
>> change the package specification, which is the only way to add an 
>> operation
>> you potentially change anything. This requires recompilation of all
>> clients, which is OK, as you said earlier. Thus the problem does not 
>> exist.
> 
> (A) we're specifically talking about a single addition or deletion, *not* a 
> general "change".

And how is it different from single dispatch? Let you override f in S. Then
f(X), given X is of S, will call to the new body.

> (B) Of course we're changing the specification and recompiling. But we don't 
> want the same client code to mean something different after that 
> recompilation without detection -- in the case of a single addition or 
> deletion (again, *not* a change).

It must mean something different. That was the *purpose* of the change to
make the client code mean it different *when* the clients use the types and
operations for which the change was made. 

> The reason here is that maintainers need to be free to ADD new 
> operations/entities without changing the behavior of any pre-existing client 
> (which necessarily does not use those new operations/entities).

Again, no difference between SD and MD. If you add a new primitive
operation (not override an existing one), there cannot be any effect on the
clients because they did not use the operation.

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

Redispatching (was: Your wish list for Ada 202X)

[J-P. Rosen]

Le 16/04/2014 08:32, Niklas Holsti a écrit :
> As I understand them, both Dmitry and Randy would consider the
> class-wide form a better solution, but it works only if you never need
> to override these class-wide operations for any descendant types.
> 
> I am seldom sure about that (never needing to override, not even in the
> future), so I prefer to have the operations as primitive rather than
> class-wide, and consequently to use re-dispatch.

Actually, it's a different use case. Not much discussed in the
litterature, because only Ada has a clear distinction between methods
(primitive operations) and class-wide operations.

A method is for the case where each type has its own way (method!) of
doing things: you don't paint a button like you paint a text.

A class-wide operation is usually a combination of (dispatching) calls
to methods, to build higher level services; it's for the case where you
want to make sure that all objects use the same algorithm; for example,
when you move a widget, you want to guarantee that it is erased from its
current position and repainted somewhere else, and that nobody will
redefine move to do something else! It also ensures that should the
algorithm change, the change needs to be done in only one place.

As far as redispatching is concerned: since a method is linked to a
single class, there should be no redispatching. Feeling a need for
redispatching in a method is often a symptom that a class-wide operation
is a better fit.

And yes, chosing between methods and class-wide ops is not trivial and
requires some thoughts; once you have a clear separation between these,
it makes development a lot easier.

Redispatching is mostly advocated by users of other languages that do
not have class-wide operations, and use methods for what should be
class-wide. In that case, failing to redispatch leads to incorrect
behaviour.

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

[Niklas Holsti]

On 14-04-16 12:30 , J-P. Rosen wrote:
> Le 16/04/2014 08:32, Niklas Holsti a écrit :
>> As I understand them, both Dmitry and Randy would consider the
>> class-wide form a better solution, but it works only if you never need
>> to override these class-wide operations for any descendant types.
>>
>> I am seldom sure about that (never needing to override, not even in the
>> future), so I prefer to have the operations as primitive rather than
>> class-wide, and consequently to use re-dispatch.
> 
> Actually, it's a different use case. Not much discussed in the
> litterature, because only Ada has a clear distinction between methods
> (primitive operations) and class-wide operations.
> 
> A method is for the case where each type has its own way (method!) of
> doing things: you don't paint a button like you paint a text.
> 
> A class-wide operation is usually a combination of (dispatching) calls
> to methods, to build higher level services; it's for the case where you
> want to make sure that all objects use the same algorithm;

I understand this difference (as should have been evident from my
previous posts). But you are presenting it as a black-or-white,
two-valued choice; in my perception, there are also operations which
share features of both extremes. Shades of grey.

> for example,
> when you move a widget, you want to guarantee that it is erased from its
> current position and repainted somewhere else, and that nobody will
> redefine move to do something else! It also ensures that should the
> algorithm change, the change needs to be done in only one place.

But then I derive a widget type which is implemented by a sprite, and
this widget can be moved just by changing its (x,y) registers, without
"erasing" and "redrawing". The "universal" move operation is not really
applicable to this widget, and can be overridden by a special and faster
operation. (I know that sprites are no longer used in display HW, but I
did not want to invent a more up-to-date example.)

> As far as redispatching is concerned: since a method is linked to a
> single class, there should be no redispatching.

(I think you meant to write "linked to a single type", not "class".)

Then you must also be of the opionion that there should be no
inheritance of methods, because inheritance makes the same method become
linked to different types. Is that your view?

Of course I disagree with this.

> Feeling a need for
> redispatching in a method is often a symptom that a class-wide operation
> is a better fit.

Except in these intermediate cases where there is an operation which is
an almost general, default algorithm, which could be class-wide except
that it needs to be overridden for some types in the class.

> And yes, chosing between methods and class-wide ops is not trivial and
> requires some thoughts; once you have a clear separation between these,
> it makes development a lot easier.

Of course I disagree with that (becase I do not consider redispatching
harmful). But in the absence of empirical research on this question,
this is a subjective opinion.

> Redispatching is mostly advocated by users of other languages that do
> not have class-wide operations, and use methods for what should be
> class-wide. In that case, failing to redispatch leads to incorrect
> behaviour.

I think it is very good that Ada provides a choice, and I don't mind
that redispatching is not the default in Ada, even if I use it more
often than not.

I'm not advocating redispatching in general, but I don't hesitate to use
it when it is necessary to give me the behaviour I want.

And I refuse to feel ashamed just because C++ or Java users also use
redispatching.

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

Re: Your wish list for Ada 202X

[Niklas Holsti]

On 14-04-15 03:08 , Randy Brukardt wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
> news:br07nkFnvrbU1@mid.individual.net...
> ...
>> (This is why I don't understand your and Randy's abhorrence of
>> re-dispatching -- to me, there is no basic difference between
>> dispatching calls in class-wide operations, and re-dispatching calls in
>> primitive operations.)
> 
> I don't think it is a good idea to assume that Dmitry and I have the same 
> opinion on anything, even if the result appears to be the same. :-)

I think I knew that... apologies if I implied differently (I see the
smiley, thanks for the forbearance).

> I view dispatching operations as the low-level primitives of a type, while 
> class-wide operations (which actually involve dispatching) as higher-level 
> operations of the type.

In this you and Dmitry agree, it seems.

In an earlier reply to Dmitry, I also agreed that class-wide operations
are higher-level than primitive ops, but having thought a bit more, I
want to modify that statement. Some of my class-wide operations are,
rather, so fundamental for the class that I make them class-wide because
I see no need to ever override them in any derived type of the class.

But I'm not sure if we can equate "fundamental" with "low-level",
architectural analogues notwithstanding ;-)

> As such, a re-dispatching call means that there is 
> some sort of abstraction inversion going on, and that's usually (but not 
> always) bad.

As I replied to Dmitry, my primitive operations tend to be layered, and
redispatching usually goes from a higher-level to a lower-level
operation. So I don't see this as abstraction inversion.

> Dispatching operations necessarily have weaker contracts than statically 
> bound calls, and that is especially important for "contracts" that can't be 
> described in Ada and thus can't be checked (either statically or 
> dynamically).

Hm, I'm not convinced of that. To me, the informal contract for a
dispatching operation Foo is "implements the Foo operation as specified
for the class and as appropriate for the actual type". Of course these
specifications are given in comments.

I don't see the "necessarily ... weaker" for the more formal contracts
either. Yes, for a dispatching call there are more possible callee
operations (implementations) to check against the contract, but the
general contract (as experienced by the caller) can be the same for all.

> After all, most extensions are created by someone other than 
> the originator of the original class,

Not (sadly) the case for my applications. But sometimes years go by
between the definition of the class and the addition of a derived type,
so memory can play tricks, and I have had a few hiccups in that area.
But not many, perhaps thanks to my obsessive commenting.

> so violations of those implicit 
> contracts are bound to happen. (Errors happen any time humans are involved!) 
> Thus, you have much more confidence in operations that don't involve 
> re-dispatching -- as a practical matter, it is a lot easier to debug 
> statically bound calls rather than dispatching ones.

I try to make my contracts explicit in comments.

All I can say is that my experience does not agree with what you say.
But the volume of my programming is not so large as to make a good
empirical study.

> Finally (really a restating of the last point), I find that it's fairly easy 
> to ensure that all of the primitive operations of a particular type have the 
> same world-view. That's not as true when some of the operations are assuming 
> the object is of type T, and some are re-dispatching to some TT derived from 
> T -- I've found many instances where some predicate of TT gets a different 
> answer than the same predicate of the same object viewed as a T. That sort 
> of things leads to all kinds of bugs, because not all of those predicates 
> are explicit in the code (even as statically bound calls).

I'm not disputing your experience, but I haven't experienced the same.
Perhaps there is some difference in our application areas that modulates
the risks and benefits of redispatching.

> This last issue doesn't arise for a class-wide operation, where every call 
> is going to look at an object of TT as type TT.

Except if TT inherits some operation from T, because then that operation
looks at the object as type T. (I know that from the language-semantics
point of view the inherited operation acts on TT, but the programmer
wrote its code with T in mind.)

If redispatching is suspect because it breaks the assocation of an
operation with a unique type, then inheritance of operations must also
be suspect, for the same reason.

I suppose one could forbid both inheritance and redispatching. That
would be a major departure from traditional object/class-oriented
programming.

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

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1wchtiw4r35px.1pwedxqesqlr4.dlg@40tude.net...
...
>> (A) we're specifically talking about a single addition or deletion, *not* 
>> a
>> general "change".
>
> And how is it different from single dispatch? Let you override f in S. 
> Then
> f(X), given X is of S, will call to the new body.

"overriding" is a change of an existing operation, not what I'm talking 
about here.

>> (B) Of course we're changing the specification and recompiling. But we 
>> don't
>> want the same client code to mean something different after that
>> recompilation without detection -- in the case of a single addition or
>> deletion (again, *not* a change).
>
> It must mean something different. That was the *purpose* of the change to
> make the client code mean it different *when* the clients use the types 
> and
> operations for which the change was made.
>
>> The reason here is that maintainers need to be free to ADD new
>> operations/entities without changing the behavior of any pre-existing 
>> client
>> (which necessarily does not use those new operations/entities).
>
> Again, no difference between SD and MD. If you add a new primitive
> operation (not override an existing one), there cannot be any effect on 
> the
> clients because they did not use the operation.

But that's not now and never has been true. Why? Because the new operation 
can have the same name as some existing operation, and the entire point of 
this discussion is that preference rules in overloading resolution have 
potentially bad effects in such cases.

Anyway, what I get from your responses is that you don't think that there is 
any real issue with maintenance (in that you think a change is a change is a 
change, and if there is a change, then behavior might change). Perhaps you 
are right, but that's been one of the cornerstones of the Ada design since 
the beginning, and abandoning it for convinience would be essentally the 
same as abandoning the "maintainability" goals of Ada.

                                           Randy.

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:br8bu5Fg3keU1@mid.individual.net...
> On 14-04-15 03:08 , Randy Brukardt wrote:
...
>> Dispatching operations necessarily have weaker contracts than statically
>> bound calls, and that is especially important for "contracts" that can't 
>> be
>> described in Ada and thus can't be checked (either statically or
>> dynamically).
>
> Hm, I'm not convinced of that. To me, the informal contract for a
> dispatching operation Foo is "implements the Foo operation as specified
> for the class and as appropriate for the actual type". Of course these
> specifications are given in comments.

A lot of our discussion has become subjective, and I don't know if there is 
a lot to be learned comparing somewhat different world-views. So I'm only 
going to respond to a couple of points here...

Anyway, there is two problems with "specifications given in comments":
(A) they can't be checked in any automatic or formal way. When humans are 
involved, mistakes *will* occur, and if they're not checked, the results 
could be disasterous. After all, we just got a lesson in that from OpenSSH. 
Had OpenSSH had a formal contract, the problem could not have ever leaked 
any information. (If the contract was enforced only at runtime, like Pre in 
Ada, OpenSSH might have had at worst a denial-of-service problem, but that 
would have been quickly fixed and most of us would have never heard anything 
about it.)

(B) English (or other natural language) is ambiguous,  and such comments 
often only make sense to the author (and recently at that). I often spend as 
much time decoding old comments (even ones I wrote years ago) than actually 
fixing anything in Janus/Ada these days. There's a decent percentage that 
only make sense if one adds a lot of context to them (and of course a few 
that defy ever making sense).

> I don't see the "necessarily ... weaker" for the more formal contracts
> either. Yes, for a dispatching call there are more possible callee
> operations (implementations) to check against the contract, but the
> general contract (as experienced by the caller) can be the same for all.

LSP says that preconditions have to combine weaker in order for dispatching 
calls to make sense. Whether LSP is really the last word on OOP is an open 
question, but if you mean to follow it, at least part of the contract *has* 
to be weaker in a dispatching call. There's also the point that a 
dispatching call always has to be assumed to be to some body not even 
written yet, so it's nearly impossible to say anything definitive about it's 
contract. (Pre'Class and the like are supposed to solve this latter problem, 
but they have a bug involving (guess what) redispatching so they might not. 
At least until the ARG considers the bug, which I really need to write up 
one of these days.)

>> After all, most extensions are created by someone other than
>> the originator of the original class,
>
> Not (sadly) the case for my applications. But sometimes years go by
> between the definition of the class and the addition of a derived type,
> so memory can play tricks, and I have had a few hiccups in that area.
> But not many, perhaps thanks to my obsessive commenting.

Commenting is good, but formal contracts are better, simply because they 
require you to write the contract in terms that mean the same thing when you 
come back to them in 5 years. And then the additional value provided by 
checking is gravy to people that truly do comment everything.

...
...
>> This last issue doesn't arise for a class-wide operation, where every 
>> call
>> is going to look at an object of TT as type TT.
>
> Except if TT inherits some operation from T, because then that operation
> looks at the object as type T. (I know that from the language-semantics
> point of view the inherited operation acts on TT, but the programmer
> wrote its code with T in mind.)
>
> If redispatching is suspect because it breaks the assocation of an
> operation with a unique type, then inheritance of operations must also
> be suspect, for the same reason.

I understand your point, but I think the language-semantics view is actually 
the correct one. One only allows inheritance of operations when the 
implementation for T and for TT is thought to be identical. One hopes that 
the author of TT considered that carefully!

It's true that maintenance of the T operation might in fact break the TT 
operation (meaning that they should have different implementations), so 
there is some additional danger in inheritance. There is also danger in 
inheritance that the author of TT didn't know about. (I think it would be 
much better if all inheritance was explicit; but to be practical that would 
require a rather different syntax than Ada uses, and thus such a thing would 
not make sense in an Ada perspective. For Claw, we had to write a tool to 
figure out what operations exist for each concrete type, as there are so 
many primitive operations and so many inheritance trees that it was 
completely impossible to keep them straight by hand. I've never been a fan 
of the way inheritance is handled in Ada.)

 > I suppose one could forbid both inheritance and redispatching. That
> would be a major departure from traditional object/class-oriented
> programming.

Not forbid so much as "require declaration of". Ada already does that for 
redispatching; my opinion is that it should be used rarely, but as with all 
such tools (e.g. goto), rarely is certainly not never. Twisting a design 
around to avoid redispatching is not likely to improve anything.

Similarly, inheritance can cause issues, but a lot of the time it also saves 
implementing the same thing five times in a row. (The fact that I couldn't 
make inheritance work for implementing parts of the Claw Builder is a 
significant part of why it became close to unmaintainable.) My mantra tends 
to be that programming languages are better when everything is explicit - 
because when programmers and compilers are assuming stuff, it's not unlikely 
that the assumptions end up different. And that's when trouble happens.

                                                Randy.

Re: Redispatching

[Dmitry A. Kazakov]

On Wed, 16 Apr 2014 22:53:28 +0300, Niklas Holsti wrote:

> On 14-04-16 12:30 , J-P. Rosen wrote:
>> As far as redispatching is concerned: since a method is linked to a
>> single class, there should be no redispatching.
> 
> (I think you meant to write "linked to a single type", not "class".)
> 
> Then you must also be of the opionion that there should be no
> inheritance of methods, because inheritance makes the same method become
> linked to different types. Is that your view?

It is confused. A primitive operation (method) is defined on (linked to)
the whole class T'Class. Its specific body is defined on a specific type
S<:T.

Re-dispatch does not violate the contract of the primitive operation, it
potentially does the contract of the *type-specific* body where re-dispatch
happens.

BTW, it is not just re-dispatch. I would argue that when you call a
parent's implementation from the body you also potentially violate the
contract:

procedure F (X : in out S) is
begin
   ...
   F (T (X)); -- Parent's implementation
   ...
end F;

Of course here potential harm is much lesser than in the case of
re-dispatch.

In short, we know that type coercion is bad, don't we?

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

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Wed, 16 Apr 2014 16:53:05 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1wchtiw4r35px.1pwedxqesqlr4.dlg@40tude.net...
> ...
>>> The reason here is that maintainers need to be free to ADD new
>>> operations/entities without changing the behavior of any pre-existing 
>>> client (which necessarily does not use those new operations/entities).
>>
>> Again, no difference between SD and MD. If you add a new primitive
>> operation (not override an existing one), there cannot be any effect on 
>> the clients because they did not use the operation.
> 
> But that's not now and never has been true. Why? Because the new operation 
> can have the same name as some existing operation, and the entire point of 
> this discussion is that preference rules in overloading resolution have 
> potentially bad effects in such cases.

No, it can have the same name only if the signature is different. That
would be overloading, thus whatever rules of preference for MD are, they
would not apply.

If you want to say that overloading is a can of worms. Yes it is. But that
has nothing to do with MD vs. SD and ambiguity resolution there.

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

Re: Redispatching

[Georg Bauhaus]

On 17/04/14 09:26, Dmitry A. Kazakov wrote:
> BTW, it is not just re-dispatch. I would argue that when you call a
> parent's implementation from the body you also potentially violate the
> contract:
>
> procedure F (X : in out S) is
> begin
>     ...
>     F (T (X)); -- Parent's implementation
>     ...
> end F;
>
> Of course here potential harm is much lesser than in the case of
> re-dispatch.
>
> In short, we know that type coercion is bad, don't we?

 From this knowledge follows a principle of design by contract:

Inside the module, it is its programmer's responsibility to
make sure that F's body is left such that the module is in a
state that fulfills the contract (of outer F, and its module).

In now obsolescent SPARK terms, there is a --# hide after "begin".

Re: Redispatching

[J-P. Rosen]

Le 16/04/2014 21:53, Niklas Holsti a écrit :
> On 14-04-16 12:30 , J-P. Rosen wrote:
>> Actually, it's a different use case. Not much discussed in the
>> litterature, because only Ada has a clear distinction between methods
>> (primitive operations) and class-wide operations.
>>
>> A method is for the case where each type has its own way (method!) of
>> doing things: you don't paint a button like you paint a text.
>>
>> A class-wide operation is usually a combination of (dispatching) calls
>> to methods, to build higher level services; it's for the case where you
>> want to make sure that all objects use the same algorithm;
> 
> I understand this difference (as should have been evident from my
> previous posts). But you are presenting it as a black-or-white,
> two-valued choice; in my perception, there are also operations which
> share features of both extremes. Shades of grey.
In a well organized program, I tend to avoid grey, and match my needs
either to one or the other. It is constraining sometimes, but makes
understanding and maintenance a lot easier.

>> for example,
>> when you move a widget, you want to guarantee that it is erased from its
>> current position and repainted somewhere else, and that nobody will
>> redefine move to do something else! It also ensures that should the
>> algorithm change, the change needs to be done in only one place.
> 
> But then I derive a widget type which is implemented by a sprite, and
> this widget can be moved just by changing its (x,y) registers, without
> "erasing" and "redrawing". The "universal" move operation is not really
> applicable to this widget, and can be overridden by a special and faster
> operation. (I know that sprites are no longer used in display HW, but I
> did not want to invent a more up-to-date example.)
Interesting example... If you consider  that various widgets have
different "methods" of moving, then you have to make it a method and not
a class-wide operation. Those that are not sprite would inherit the
method from the root widget, i.e. the default erase-and-redraw.

>> As far as redispatching is concerned: since a method is linked to a
>> single class, there should be no redispatching.
> 
> (I think you meant to write "linked to a single type", not "class".)
I use "class" because I'm talking about the general concept, not
specifically Ada.
#define class "A package declaring a single tagged type and associated
primitive operations"
;-)

> Then you must also be of the opionion that there should be no
> inheritance of methods, because inheritance makes the same method become
> linked to different types. Is that your view?
> 
Not at all. I view inheritance of methods as providing a default value
for the operation. If you like it, take it, if not, redefine it. However
there is still one method per class, whether redefined or inherited.

>> Feeling a need for
>> redispatching in a method is often a symptom that a class-wide operation
>> is a better fit.
> 
> Except in these intermediate cases where there is an operation which is
> an almost general, default algorithm, which could be class-wide except
> that it needs to be overridden for some types in the class.
See above. The choice is a design decision, and often not an easy one.
But there is value in deciding "this is a property of each specific
type" or "this is a property of the whole class (in the sense class-wide)".
[...]

> I'm not advocating redispatching in general, but I don't hesitate to use
> it when it is necessary to give me the behaviour I want.
To me, it raises an alarm that something might be wrong. A possibility
is that the functionality could be kept class-wide by adding another
method.

Admitedly, that's MY way of working: define a few (sometimes
constraining) patterns and stick to them. Similar to my preference for
standard components (even if I have to adjust my design), rather than
reinventing the wheel if the standard components do not match 100%. YMMV.

> And I refuse to feel ashamed just because C++ or Java users also use
> redispatching.
> 
Nothing to be ashamed of, it is a  matter of philosophy of software
design. What I'm saying is just that Ada has a richer toolset than these
languages, therefore the fact that other languages use a certain
solution does not imply that the same should be used for Ada.

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

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1239ezez4bgf7.e2ihtjo019ka.dlg@40tude.net...
> On Wed, 16 Apr 2014 16:53:05 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:1wchtiw4r35px.1pwedxqesqlr4.dlg@40tude.net...
>> ...
>>>> The reason here is that maintainers need to be free to ADD new
>>>> operations/entities without changing the behavior of any pre-existing
>>>> client (which necessarily does not use those new operations/entities).
>>>
>>> Again, no difference between SD and MD. If you add a new primitive
>>> operation (not override an existing one), there cannot be any effect on
>>> the clients because they did not use the operation.
>>
>> But that's not now and never has been true. Why? Because the new 
>> operation
>> can have the same name as some existing operation, and the entire point 
>> of
>> this discussion is that preference rules in overloading resolution have
>> potentially bad effects in such cases.
>
> No, it can have the same name only if the signature is different. That
> would be overloading, thus whatever rules of preference for MD are, they
> would not apply.
>
> If you want to say that overloading is a can of worms. Yes it is. But that
> has nothing to do with MD vs. SD and ambiguity resolution there.

Well, talking about Ada, there is only overloading resolution. The same 
rules apply to all calls, there is nothing special about primitive 
operations. One could certainly imagine other rules, but they wouldn't fit 
into the framework of Ada resolution without a lot of reworking.

Like a lot of your ideas, they would make much more sense in a new language 
rather than in the context of the existing Ada language.

                                      Randy.

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Thu, 17 Apr 2014 12:29:29 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1239ezez4bgf7.e2ihtjo019ka.dlg@40tude.net...
>> On Wed, 16 Apr 2014 16:53:05 -0500, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:1wchtiw4r35px.1pwedxqesqlr4.dlg@40tude.net...
>>> ...
>>>>> The reason here is that maintainers need to be free to ADD new
>>>>> operations/entities without changing the behavior of any pre-existing
>>>>> client (which necessarily does not use those new operations/entities).
>>>>
>>>> Again, no difference between SD and MD. If you add a new primitive
>>>> operation (not override an existing one), there cannot be any effect on
>>>> the clients because they did not use the operation.
>>>
>>> But that's not now and never has been true. Why? Because the new operation
>>> can have the same name as some existing operation, and the entire point of
>>> this discussion is that preference rules in overloading resolution have
>>> potentially bad effects in such cases.
>>
>> No, it can have the same name only if the signature is different. That
>> would be overloading, thus whatever rules of preference for MD are, they
>> would not apply.
>>
>> If you want to say that overloading is a can of worms. Yes it is. But that
>> has nothing to do with MD vs. SD and ambiguity resolution there.
> 
> Well, talking about Ada, there is only overloading resolution. The same 
> rules apply to all calls, there is nothing special about primitive 
> operations. One could certainly imagine other rules, but they wouldn't fit 
> into the framework of Ada resolution without a lot of reworking.

The point I made was about possibility to have preference rules for MD
without "bad effects." In order to disprove it you should present a case
showing that no set of rules could prevent such effects.

Regarding "reworking" there is no reworking because MD is non-existent in
Ada.

> Like a lot of your ideas, they would make much more sense in a new language 
> rather than in the context of the existing Ada language.

This again requires a proof, which would be quite difficult to make,
because the only reason why MD or other sound type construct would be
impossible in Ada then due to some fatal design errors in the language
core. I trust Ada design most of the time. It surprises me that you
seemingly do not. But then you should present these alleged design faults.

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

Re: Your wish list for Ada 202X

[Robert Love]

On 2014-03-25 21:41:16 +0000, Stoik said:

> I think that even a casual user of Ada should be able to influence 
> somehow the new version of Ada. I wonder what is high on your list of 
> wishes for Ada 202X?
> I suspect many of the proposals could be tested in GNAT before being 
> introduced (or rejected) in the new version. One could add a switch to 
> GNAT indicating that we want to use some of the experimental features.

How about that it comes to be in my lifetime.  Make that my working lifetime.

Re: Your wish list for Ada 202X

[Simon Wright]

Robert Love <rblove@airmail.net> writes:

> On 2014-03-25 21:41:16 +0000, Stoik said:
>
>> I think that even a casual user of Ada should be able to influence
>> somehow the new version of Ada. I wonder what is high on your list
>> of wishes for Ada 202X?
>> I suspect many of the proposals could be tested in GNAT before being
>> introduced (or rejected) in the new version. One could add a switch
>> to GNAT indicating that we want to use some of the experimental
>> features.
>
> How about that it comes to be in my lifetime.  Make that my working
> lifetime.

There is such a switch : -gnatX, "language extensions permitted". I
don't think that there are any such extensions to actually _be_
permitted at the moment, there certainly have been in the past.

Re: Your wish list for Ada 202X

[Niklas Holsti]

(Apologies for a delayed reply.)

On 14-04-14 00:07 , Dmitry A. Kazakov wrote:
> On Sun, 13 Apr 2014 22:43:47 +0300, Niklas Holsti wrote:
> 
>> On 14-04-12 11:20 , Dmitry A. Kazakov wrote:
> 
>>> I don't deny
>>> existence of the problem. I am against the solution, which is inherently
>>> unsafe and constraining (precludes by-copy semantics).
>>
>> But class-wide operations which contain dispatching calls also preclude
>> by-copy semantics, don't they?
> 
> Not at all. There is no problem for a class-wide operation to act on
> by-copy types.
> 
> A by-copy class-wide object is a tuple (tag, type-specific value). Upon
> dispatch the value is passed copy-in/copy-out to the type specific
> operation.

OK, but from the implementation point of view, that form of by-copy
passing could be used for all operations of a tagged class, whether
class-wide or primitive, with or without redispatching. So it is not
evident why you said earlier that redispatching prevents by-copy semantics.

If I may guess, your reasoning is perhaps that if we have a tagged type
T, and a derived type TT with added components, and a primitive
operation Foo on T which is inherited by TT and uses by-copy semantics,
then calling Foo on a TT object X should really copy only the T part of
X, and therefore Foo could not execute a redispatching call to some
operation Bar on T which is overridden for TT, because the conversion
T'Class(X) in the redispatching call would have no way to (re)generate
the TT components of X, because they were not copied.

I think that argument is wrong from the formal point of view, because
when Foo is inherited from T to TT, the inherited operation formally
acts on TT, therefore the by-copy passing would copy all of X, including
the TT components.

Another case that comes to mind is an explicit call to the original (not
inherited) form of Foo, using a call with a conversion of the form
Foo(T(X)) where X is of type TT. Here, there is more reason to feel that
by-copy passing should copy only the T part of X (or, rather, the
conversion should return only the T part of X), and then redispatching
from Foo would indeed be impossible. But if T(X) is seen simply as a
view conversion, not a value conversion, then X could still be passed
by-copy using your (tag, type-specific value) form.

(Of course this is all irrelevant to current Ada, where tagged types are
by-reference and T(X) in the call is a view conversion.)

>> A class-wide operation, in my view, is just like a primitive operation
>> except that (1) (re-)dispatching is implicit and automatic for all calls
>> to primitive operations of the parameter object (because the parameter
>> is a class-wide type) and (2) the operation cannot be overridden.
> 
> There is no re-dispatching in a class-wide operation. It is defined on
> class-wide objects, so it simply neither dispatch nor re-dispatch.

Huh? If a class-wide operation calls a primitive operation, using a
controlling parameter of the class-wide type, that is certainly a
dispatching call.

>> (This is why I don't understand your and Randy's abhorrence of
>> re-dispatching -- to me, there is no basic difference between
>> dispatching calls in class-wide operations, and re-dispatching calls in
>> primitive operations.)
> 
> The difference is in types involved. A body of a primitive operation is
> defined on a particular specific type. A re-dispatch within the body
> breaks this type contract by calling an operation defined on *another*
> type. This is an untyped behavior.

Not in my opinion, of course. In any primitive operation, I consider a
parameter of type T to be just a T-view of an object which may be of
type T or of a derived type. This matches how Ada is now defined and
implemented; your statement reflects another language, or an Ada subset.

I'll stop arguing about redispatching for now. Our views are different.

The only reason I entered this discussion about redispatching is that I
am upset when someone (often you, Dmitry) makes the blank statement that
one should "never redispatch", as if redispatching would lead to
erroneous execution and program crashes as surely as reading an
uninitialized variable might. Redispatching is well defined in Ada and
does not cause erroneous execution or bounded errors. The only arguments
against redispatching either come from a more constrained idea of types
(effectively an Ada subset) or from a fear of increased dynamic choice
of callees, in particular fear of choosing an inappropriate operation of
a different type. Both arguments concern design and coding styles and
their impact on the likelihood of design or coding errors, not of
correct or erroneous execution. My objective has only been to make this
clear to people who might be misled by the blanket condemnations of
redispatching.

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

Re: Your wish list for Ada 202X

[Niklas Holsti]

On 14-04-17 01:27 , Randy Brukardt wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
> news:br8bu5Fg3keU1@mid.individual.net...
>> On 14-04-15 03:08 , Randy Brukardt wrote:
> ...
>>> Dispatching operations necessarily have weaker contracts than statically
>>> bound calls, and that is especially important for "contracts" that can't 
>>> be
>>> described in Ada and thus can't be checked (either statically or
>>> dynamically).
>>
>> Hm, I'm not convinced of that. To me, the informal contract for a
>> dispatching operation Foo is "implements the Foo operation as specified
>> for the class and as appropriate for the actual type". Of course these
>> specifications are given in comments.
> 
> A lot of our discussion has become subjective, and I don't know if there is 
> a lot to be learned comparing somewhat different world-views. So I'm only 
> going to respond to a couple of points here...
> 
> Anyway, there is two problems with "specifications given in comments":

Sorry, I think you misunderstood: I was replying to the case which you
described as "contracts that can't be described in Ada".

I fully agree that formal contracts are preferable to informal ones, no
argument. I don't (yet) use formal contracts, however, except for those
that Ada provides implicitly.

>> I don't see the "necessarily ... weaker" for the more formal contracts
>> either. Yes, for a dispatching call there are more possible callee
>> operations (implementations) to check against the contract, but the
>> general contract (as experienced by the caller) can be the same for all.
> 
> LSP says that preconditions have to combine weaker in order for dispatching 
> calls to make sense.

Weaker *or equal*, I think.

> Whether LSP is really the last word on OOP is an open 
> question, but if you mean to follow it, at least part of the contract *has* 
> to be weaker in a dispatching call.

Why can't it be equal, again from the point of view of the caller?

The full contract for the operation on a derived type is indeed stronger
in the sense that it says something specific about the derived type, for
example about changes in the components added in the derivation. But
those details are not important to the caller's point of view; only the
contract's effects on the higher level (caller's type) are relevant.

For example, if we have a class of "file" types, with different derived
types implementing files on different kinds of storage devices, and a
dispatching call of Open, the changes in the device-specific components
of the file object are not relevant to the caller of Open; it is only
relevant that the file's class-level status changes from "closed" to "open".

> There's also the point that a 
> dispatching call always has to be assumed to be to some body not even 
> written yet, so it's nearly impossible to say anything definitive about it's 
> contract.

But the operation has been *specified*, even if no bodies exist,
therefore the contract *from the caller's point of view* should have
been defined. Otherwise there is not much point in using a class at all,
or indeed in separating operation declarations and bodies.

> ...
>>> This last issue doesn't arise for a class-wide operation, where every 
>>> call is going to look at an object of TT as type TT.
>>
>> Except if TT inherits some operation from T, because then that operation
>> looks at the object as type T. (I know that from the language-semantics
>> point of view the inherited operation acts on TT, but the programmer
>> wrote its code with T in mind.)
>>
>> If redispatching is suspect because it breaks the assocation of an
>> operation with a unique type, then inheritance of operations must also
>> be suspect, for the same reason.
> 
> I understand your point, but I think the language-semantics view is actually 
> the correct one. One only allows inheritance of operations when the 
> implementation for T and for TT is thought to be identical. One hopes that 
> the author of TT considered that carefully!

Well, I use redispatching only when I think that the operation being
called is well specified and is or will be carefully implemented for
each type in the class, as appropriate for that type. Same difference :-)

> It's true that maintenance of the T operation might in fact break the TT 
> operation (meaning that they should have different implementations), so 
> there is some additional danger in inheritance.

Yes. In general, the more a program is "factored" into parts that are
combined and invoked in many contexts, the harder it becomes to maintain
proper behaviour in all contexts. Subprograms, inheritance, dispatching,
redispatching all tend in this direction.

> There is also danger in 
> inheritance that the author of TT didn't know about. (I think it would be 
> much better if all inheritance was explicit; but to be practical that would 
> require a rather different syntax than Ada uses, and thus such a thing would 
> not make sense in an Ada perspective.

To make inheritance explicit, it seems to me that each inherited
operation must be declared for the derived type, with its full profile,
perhaps as

   inherited procedure Foo (X: in T; ....);

This would require just one new reserved word, "inherited", and does not
feel like a "rather different syntax". Did you have something else in mind?

>  > I suppose one could forbid both inheritance and redispatching. That
>> would be a major departure from traditional object/class-oriented
>> programming.
> 
> Not forbid so much as "require declaration of". Ada already does that for 
> redispatching; my opinion is that it should be used rarely, but as with all 
> such tools (e.g. goto), rarely is certainly not never.

Thanks for explaining your view. I think I understand it now.

> Twisting a design  around to avoid redispatching is not likely to
> improve anything.

Agreed. As I said in my last reply to Dmitry, reaching this point was my
reason for commenting on redispatching. I'm content to end here.

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

Re: Redispatching

[Niklas Holsti]

On 14-04-17 10:26 , Dmitry A. Kazakov wrote:
> On Wed, 16 Apr 2014 22:53:28 +0300, Niklas Holsti wrote:
> 
>> On 14-04-16 12:30 , J-P. Rosen wrote:
>>> As far as redispatching is concerned: since a method is linked to a
>>> single class, there should be no redispatching.
>>
>> (I think you meant to write "linked to a single type", not "class".)
>>
>> Then you must also be of the opionion that there should be no
>> inheritance of methods, because inheritance makes the same method become
>> linked to different types. Is that your view?
> 
> It is confused. A primitive operation (method) is defined on (linked to)
> the whole class T'Class. Its specific body is defined on a specific type
> S<:T.

As you see it, yes. However, in Ada the parameters of type T are really
views of objects which may be of type T or of a type derived from T.
This must be kept in mind when coding the body, and then redispatching
is merely view conversion, not type coercion.

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

Re: Redispatching

[Dmitry A. Kazakov]

On Fri, 18 Apr 2014 23:08:25 +0300, Niklas Holsti wrote:

> On 14-04-17 10:26 , Dmitry A. Kazakov wrote:
>> On Wed, 16 Apr 2014 22:53:28 +0300, Niklas Holsti wrote:
>> 
>>> On 14-04-16 12:30 , J-P. Rosen wrote:
>>>> As far as redispatching is concerned: since a method is linked to a
>>>> single class, there should be no redispatching.
>>>
>>> (I think you meant to write "linked to a single type", not "class".)
>>>
>>> Then you must also be of the opionion that there should be no
>>> inheritance of methods, because inheritance makes the same method become
>>> linked to different types. Is that your view?
>> 
>> It is confused. A primitive operation (method) is defined on (linked to)
>> the whole class T'Class. Its specific body is defined on a specific type
>> S<:T.
> 
> As you see it, yes. However, in Ada the parameters of type T are really
> views of objects which may be of type T or of a type derived from T.

Wrong. Consider this set of declarations:

   type T is ...;
   procedure Bar (X : T);

   type S is new T ...;
   procedure Foo (X : S);

Now the following is illegal:

   procedure Bar (X : T) is
   begin
      X.Foo;  -- Compile error
   end Bar;

X in Bar is of the type T and of no other type.

You can convert X using so-called "view-conversion" to an object of another
type, e.g. S or T'Class. This conversion is a type conversion. Yes, it has
certain properties when X is tagged (and thus by-reference), such as
reusing the old object for the new one. These properties are irrelevant to
the type semantics though. You get an object of a different type.

If Ada supported classes of by-copy types, then conversion to S or T'Class
would produce a new object. But the type semantics would remain same.

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

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Fri, 18 Apr 2014 22:10:50 +0300, Niklas Holsti wrote:

> (Apologies for a delayed reply.)
> 
> On 14-04-14 00:07 , Dmitry A. Kazakov wrote:
>> On Sun, 13 Apr 2014 22:43:47 +0300, Niklas Holsti wrote:
>> 
>>> On 14-04-12 11:20 , Dmitry A. Kazakov wrote:
>> 
>>>> I don't deny
>>>> existence of the problem. I am against the solution, which is inherently
>>>> unsafe and constraining (precludes by-copy semantics).
>>>
>>> But class-wide operations which contain dispatching calls also preclude
>>> by-copy semantics, don't they?
>> 
>> Not at all. There is no problem for a class-wide operation to act on
>> by-copy types.
>> 
>> A by-copy class-wide object is a tuple (tag, type-specific value). Upon
>> dispatch the value is passed copy-in/copy-out to the type specific
>> operation.
> 
> OK, but from the implementation point of view, that form of by-copy
> passing could be used for all operations of a tagged class, whether
> class-wide or primitive, with or without redispatching. So it is not
> evident why you said earlier that redispatching prevents by-copy semantics.

Re-dispatching presumes the same object. For by-copy objects a conversion
of T to T'Class would produce a new object on which dispatch would happen.
It would make no sense to call this re-dispatch.

But more importantly is that "re-dispatch" will always dispatch to the
operations of the manifested type. I will consider this in details below.

> If I may guess, your reasoning is perhaps that if we have a tagged type
> T, and a derived type TT with added components, and a primitive
> operation Foo on T which is inherited by TT and uses by-copy semantics,
> then calling Foo on a TT object X should really copy only the T part of
> X, and therefore Foo could not execute a redispatching call to some
> operation Bar on T which is overridden for TT, because the conversion
> T'Class(X) in the redispatching call would have no way to (re)generate
> the TT components of X, because they were not copied.
> 
> I think that argument is wrong from the formal point of view, because
> when Foo is inherited from T to TT, the inherited operation formally
> acts on TT, therefore the by-copy passing would copy all of X, including
> the TT components.

Consider this:

   type T is non-tagged null record;
   procedure Foo (X : T);
   procedure Bar (X : T);

   type TT is new T with record
       I : Integer;
   end record;
   overriding procedure Bar (X : T);

   procedure Foo (X : T) is
   begin
       T'Class (X).Bar;
   end Foo;

   O : T'Class := T'(null record);

   O.Foo;

The representation of O is (T'Tag, null record). When it dispatches on O to
Foo, T'Tag is stripped away and null record is passed to T's Foo. Within
Foo X has the representation null record, *always*. When X is converted in
Foo to T'Class, the result is (T'Tag, null record), because the type of X
is declared as T. When it dispatches on the result Bar, it is T's Bar that
is called, always, because the tag is T'Tag.

As you see, there is no re-dispatch possible with by-copy semantics.
Re-dispatch requires:

1. by-reference semantics (no new objects)

2. extension (parent representations stored within derived objects)

3. embedded tags (class-wide and type-specific representations to be same)

> Another case that comes to mind is an explicit call to the original (not
> inherited) form of Foo, using a call with a conversion of the form
> Foo(T(X)) where X is of type TT. Here, there is more reason to feel that
> by-copy passing should copy only the T part of X (or, rather, the
> conversion should return only the T part of X), and then redispatching
> from Foo would indeed be impossible. But if T(X) is seen simply as a
> view conversion, not a value conversion, then X could still be passed
> by-copy using your (tag, type-specific value) form.

It is the tag in the pair (Tag, Value) which determine the type of Value.
You cannot use T'Tag with TT value, that is inconsistent.

>>> A class-wide operation, in my view, is just like a primitive operation
>>> except that (1) (re-)dispatching is implicit and automatic for all calls
>>> to primitive operations of the parameter object (because the parameter
>>> is a class-wide type) and (2) the operation cannot be overridden.
>> 
>> There is no re-dispatching in a class-wide operation. It is defined on
>> class-wide objects, so it simply neither dispatch nor re-dispatch.
> 
> Huh? If a class-wide operation calls a primitive operation, using a
> controlling parameter of the class-wide type, that is certainly a
> dispatching call.

Yes, but this is a call to some different operation. I thought you were
talking about the class-wide operation itself. This operation does not
[re-]dispatch. What happens in its body is a different issue.

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

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:brdegqFi62jU1@mid.individual.net...
> On 14-04-17 01:27 , Randy Brukardt wrote:
>> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
>> news:br8bu5Fg3keU1@mid.individual.net...
>>> On 14-04-15 03:08 , Randy Brukardt wrote:
...
>> There's also the point that a
>> dispatching call always has to be assumed to be to some body not even
>> written yet, so it's nearly impossible to say anything definitive about 
>> it's
>> contract.
>
> But the operation has been *specified*, even if no bodies exist,
> therefore the contract *from the caller's point of view* should have
> been defined. Otherwise there is not much point in using a class at all,
> or indeed in separating operation declarations and bodies.

Right, but here I'm a practicalist, rather than theortician. Humans write 
programs, and they tend to ignore anything not convinient. That certainly 
goes for whatever part of the contract is not formally specified and 
checked. So there is a lot more risk from re-dispatching than static 
binding, simply because there is more likelihood of error (unintentional or 
malicious).

>> ...
>>>> This last issue doesn't arise for a class-wide operation, where every
>>>> call is going to look at an object of TT as type TT.
>>>
>>> Except if TT inherits some operation from T, because then that operation
>>> looks at the object as type T. (I know that from the language-semantics
>>> point of view the inherited operation acts on TT, but the programmer
>>> wrote its code with T in mind.)
>>>
>>> If redispatching is suspect because it breaks the assocation of an
>>> operation with a unique type, then inheritance of operations must also
>>> be suspect, for the same reason.
>>
>> I understand your point, but I think the language-semantics view is 
>> actually
>> the correct one. One only allows inheritance of operations when the
>> implementation for T and for TT is thought to be identical. One hopes 
>> that
>> the author of TT considered that carefully!
>
> Well, I use redispatching only when I think that the operation being
> called is well specified and is or will be carefully implemented for
> each type in the class, as appropriate for that type. Same difference :-)

If you truly believe that you can "well specify" and "carefully implement" 
everything in your system, well, you're a better man than me. :-) I don't 
believe that about my code even when I write the entire thing at one time - 
much less when other people are involved or years pass between work. One of 
the things that attracted me to Ada in the first place is that it forces me 
to specify enough that it prevents many of my worst impulses. (Instantiating 
Unchecked_Conversion is painful enough to prevent most reuse of objects, for 
one example.) I doubt I'd ever get a lengthy C program to work!

>> It's true that maintenance of the T operation might in fact break the TT
>> operation (meaning that they should have different implementations), so
>> there is some additional danger in inheritance.
>
> Yes. In general, the more a program is "factored" into parts that are
> combined and invoked in many contexts, the harder it becomes to maintain
> proper behaviour in all contexts. Subprograms, inheritance, dispatching,
> redispatching all tend in this direction.

Right.

>> There is also danger in
>> inheritance that the author of TT didn't know about. (I think it would be
>> much better if all inheritance was explicit; but to be practical that 
>> would
>> require a rather different syntax than Ada uses, and thus such a thing 
>> would
>> not make sense in an Ada perspective.
>
> To make inheritance explicit, it seems to me that each inherited
> operation must be declared for the derived type, with its full profile,
> perhaps as
>
>   inherited procedure Foo (X: in T; ....);
>
> This would require just one new reserved word, "inherited", and does not
> feel like a "rather different syntax". Did you have something else in 
> mind?

The problem with this sort of syntax is that it's really wordy and tends to 
obscure the important issues (which is not the exact profile, as least 
unless you have a resolution problem). Remember all of the people that used 
renames to avoid using use clauses for Ada 83? (Maybe not, that was a long 
time ago.) They often had bugs like:
   function "+" (Left, Right : P.Big_Int) return P.Big_Int renames P."-";
where the profile is obscuring the critical differences.

I'd prefer a much simpler declaration of inheritance, something like:
   type Child is new Parent with ...
      with inherits => Foo, Bar, Blech;

where names not listed are hidden from all visibility unless overridden. 
(The Ada dispatching model insists that the routines exist, so for Ada all 
one could do would be to hide any uninherited operations from direct calls. 
One could imagine have uninherited operations raise Program_Error in 
dispatching as an alternative, but that's not ideal either because it makes 
a tripping hazard as Bob calls it. Thirdly, one could require all operations 
to be either inherited or overridden, but that just makes a new kind of pain 
for deriving types, especially for those of us who prefer incremental 
implementation of things).

Whether that's enough or if some alternative with optional profiles is 
necessary, I don't know. Most operations aren't overloaded, after all, so 
the profile is just noise.

                       Randy.

Re: Your wish list for Ada 202X

[Niklas Holsti]

On 14-04-19 00:18 , Dmitry A. Kazakov wrote:
> On Fri, 18 Apr 2014 22:10:50 +0300, Niklas Holsti wrote:
> 
>> (Apologies for a delayed reply.)
>>
>> On 14-04-14 00:07 , Dmitry A. Kazakov wrote:
>>> On Sun, 13 Apr 2014 22:43:47 +0300, Niklas Holsti wrote:
>>>
>>>> On 14-04-12 11:20 , Dmitry A. Kazakov wrote:
>>>
>>>>> I don't deny
>>>>> existence of the problem. I am against the solution, which is inherently
>>>>> unsafe and constraining (precludes by-copy semantics).
>>>>
>>>> But class-wide operations which contain dispatching calls also preclude
>>>> by-copy semantics, don't they?
>>>
>>> Not at all. There is no problem for a class-wide operation to act on
>>> by-copy types.
>>>
>>> A by-copy class-wide object is a tuple (tag, type-specific value). Upon
>>> dispatch the value is passed copy-in/copy-out to the type specific
>>> operation.
>>
>> OK, but from the implementation point of view, that form of by-copy
>> passing could be used for all operations of a tagged class, whether
>> class-wide or primitive, with or without redispatching. So it is not
>> evident why you said earlier that redispatching prevents by-copy semantics.
> 
> Re-dispatching presumes the same object.

No it doesn't. Why should it? Redispatch merely selects an operation
based on the actual type (tag) of the parameter value. Whether the
operation acts on the same object or on a copy is a separate question.

> For by-copy objects a conversion
> of T to T'Class would produce a new object on which dispatch would happen.
> It would make no sense to call this re-dispatch.

In earlier discussion threads, you have criticized redispatching as
logically redundant because it inspects the object's tag twice, making
two dispatching decisions where one should be enough. Here, even if
T'Class makes a new object, the new object has the same tag value, and a
dispatching call on it makes a new decision using the same tag value as
was used to dispatch to the calling operation. I don't see why two
successive dispatching decisions on the same tag value should not be
called redispatching. It is irrelevant whether the tag value is copied
between the decisions.

> But more importantly is that "re-dispatch" will always dispatch to the
> operations of the manifested type. I will consider this in details below.
> 
> ... Consider this:
> 
>    type T is non-tagged null record;

Are you talking about Ada here? Or about the ideal Dmitry-language?

>    procedure Foo (X : T);
>    procedure Bar (X : T);
> 
>    type TT is new T with record
>        I : Integer;
>    end record;
>    overriding procedure Bar (X : T);
> 
>    procedure Foo (X : T) is
>    begin
>        T'Class (X).Bar;

Ah, you are taking the class of a non-tagged type. So this is the
Dmitry-language, not Ada, nor a by-copy variant of Ada.

>    end Foo;
> 
>    O : T'Class := T'(null record);
> 
>    O.Foo;
> 
> The representation of O is (T'Tag, null record). When it dispatches on O to
> Foo, T'Tag is stripped away and null record is passed to T's Foo. Within
> Foo X has the representation null record, *always*. When X is converted in
> Foo to T'Class, the result is (T'Tag, null record), because the type of X
> is declared as T. When it dispatches on the result Bar, it is T's Bar that
> is called, always, because the tag is T'Tag.
> 
> As you see, there is no re-dispatch possible with by-copy semantics.

You are presenting a particular form of by-copy, in which the tag (and
no doubt all extension components) are removed when the value is copied
in a call to a non-class-wide operation. Obviously redispatch is not
possible then. But that is not the only possible way of passing
parameters by copy.

>>>> A class-wide operation, in my view, is just like a primitive operation
>>>> except that (1) (re-)dispatching is implicit and automatic for all calls
>>>> to primitive operations of the parameter object (because the parameter
>>>> is a class-wide type) and (2) the operation cannot be overridden.
>>>
>>> There is no re-dispatching in a class-wide operation. It is defined on
>>> class-wide objects, so it simply neither dispatch nor re-dispatch.
>>
>> Huh? If a class-wide operation calls a primitive operation, using a
>> controlling parameter of the class-wide type, that is certainly a
>> dispatching call.
> 
> Yes, but this is a call to some different operation. I thought you were
> talking about the class-wide operation itself. This operation does not
> [re-]dispatch. What happens in its body is a different issue.

Ok, a misunderstanding between us, we do agree that there is no
dispatching when a class-wide operation is called. But a side issue.

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

Re: Your wish list for Ada 202X

[Niklas Holsti]

On 14-04-19 00:28 , Randy Brukardt wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
> news:brdegqFi62jU1@mid.individual.net...
>> ...
>> Well, I use redispatching only when I think that the operation being
>> called is well specified and is or will be carefully implemented for
>> each type in the class, as appropriate for that type. Same difference :-)
> 
> If you truly believe that you can "well specify" and "carefully implement" 
> everything in your system, well, you're a better man than me. :-)

No, no... I should have made it explicit in the quoted text that what "I
think" is not always correct, and of course I make errors (maybe I
should have written "when I hope" instead of "when I think"). But the
errors don't seem more likely to occur in redispatching calls than in
other calls. This may be because tagged types are not yet the core of my
applications, so my dispatching and redispatching operations are usually
not very complex.

> One of 
> the things that attracted me to Ada in the first place is that it forces me 
> to specify enough that it prevents many of my worst impulses.

I learned programming with Algol and did not encounter C until I had
experienced various forms of BASIC, COBOL, and Fortran (plus a few
assembly languages). This shielded me, I think, from being tempted to
use C-style short-cuts. So, perhaps unusually, I don't feel at all
constrained by Ada's requirements on explicitness, careful
specification, and strong typing.

> I doubt I'd ever get a lengthy C program to work!

I feel a lot more confident in my Ada code than in my C code.

>>> ... (I think it would be
>>> much better if all inheritance was explicit; but to be practical that 
>>> would
>>> require a rather different syntax than Ada uses, and thus such a thing 
>>> would
>>> not make sense in an Ada perspective.
>>
>> To make inheritance explicit, it seems to me that each inherited
>> operation must be declared for the derived type, with its full profile,
>> perhaps as
>>
>>   inherited procedure Foo (X: in T; ....);
>>
>> This would require just one new reserved word, "inherited", and does not
>> feel like a "rather different syntax". Did you have something else in 
>> mind?
> 
> The problem with this sort of syntax is that it's really wordy

Yes indeed.

> and tends to 
> obscure the important issues (which is not the exact profile, as least 
> unless you have a resolution problem). Remember all of the people that used 
> renames to avoid using use clauses for Ada 83? (Maybe not, that was a long 
> time ago.) They often had bugs like:
>    function "+" (Left, Right : P.Big_Int) return P.Big_Int renames P."-";
> where the profile is obscuring the critical differences.

Been there, done that (bugs too), with TLD Ada for a MIL-STD-1750B.

(The bugs usually arose through copy-paste mistakes, where one needed to
rename both "+" and "-" but forgot to change both occurrences of "+" to
"-" in the pasted copy of the renaming for "+")

> I'd prefer a much simpler declaration of inheritance, something like:
>    type Child is new Parent with ...
>       with inherits => Foo, Bar, Blech;
> 
> where names not listed are hidden from all visibility unless overridden.

This form would probably strongly discourage overloaded operation names.

> Whether that's enough or if some alternative with optional profiles is 
> necessary, I don't know. Most operations aren't overloaded, after all, so 
> the profile is just noise.

I have quite a few overloaded primitive operations, perhaps because I
tend to use named association in all calls so that the parameter names
extend and clarify the brief operation name.

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

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Sat, 19 Apr 2014 10:35:36 +0300, Niklas Holsti wrote:

> On 14-04-19 00:18 , Dmitry A. Kazakov wrote:
>> On Fri, 18 Apr 2014 22:10:50 +0300, Niklas Holsti wrote:
>> 
>>> (Apologies for a delayed reply.)
>>>
>>> On 14-04-14 00:07 , Dmitry A. Kazakov wrote:
>>>> On Sun, 13 Apr 2014 22:43:47 +0300, Niklas Holsti wrote:
>>>>
>>>>> On 14-04-12 11:20 , Dmitry A. Kazakov wrote:
>>>>
>>>>>> I don't deny
>>>>>> existence of the problem. I am against the solution, which is inherently
>>>>>> unsafe and constraining (precludes by-copy semantics).
>>>>>
>>>>> But class-wide operations which contain dispatching calls also preclude
>>>>> by-copy semantics, don't they?
>>>>
>>>> Not at all. There is no problem for a class-wide operation to act on
>>>> by-copy types.
>>>>
>>>> A by-copy class-wide object is a tuple (tag, type-specific value). Upon
>>>> dispatch the value is passed copy-in/copy-out to the type specific
>>>> operation.
>>>
>>> OK, but from the implementation point of view, that form of by-copy
>>> passing could be used for all operations of a tagged class, whether
>>> class-wide or primitive, with or without redispatching. So it is not
>>> evident why you said earlier that redispatching prevents by-copy semantics.
>> 
>> Re-dispatching presumes the same object.
> 
> No it doesn't. Why should it? Redispatch merely selects an operation
> based on the actual type (tag) of the parameter value.

This is called dispatch.

> Whether the
> operation acts on the same object or on a copy is a separate question.

"Re-" presumes that dispatch happens again. What is in common to these two
instances of dispatch what makes it re-dispatch? It is 1) the same
polymorphic operation and 2) the same object. Take either away and it is
not re-dispatch anymore:

1. Different operations:

   X.Foo;
   X.Bar;  -- This is not re-dispatch!

2. Different objects:

   X.Foo;
   Y.Foo;  -- This is not re-dispatch!
 
>> For by-copy objects a conversion
>> of T to T'Class would produce a new object on which dispatch would happen.
>> It would make no sense to call this re-dispatch.
> 
> I don't see why two
> successive dispatching decisions on the same tag value should not be
> called redispatching. It is irrelevant whether the tag value is copied
> between the decisions.

See above.

>> But more importantly is that "re-dispatch" will always dispatch to the
>> operations of the manifested type. I will consider this in details below.
>> 
>> ... Consider this:
>> 
>>    type T is non-tagged null record;
> 
> Are you talking about Ada here?

We were talking about implementation dispatch and re-dispatch for by-copy
types. Remember? If yes, that I am also pretty sure you know that this not
Ada, so far.

>>    procedure Foo (X : T);
>>    procedure Bar (X : T);
>> 
>>    type TT is new T with record
>>        I : Integer;
>>    end record;
>>    overriding procedure Bar (X : T);
>> 
>>    procedure Foo (X : T) is
>>    begin
>>        T'Class (X).Bar;
> 
> Ah, you are taking the class of a non-tagged type. So this is the
> Dmitry-language, not Ada, nor a by-copy variant of Ada.

There is no such thing as by-copy variant of Ada.

>>    end Foo;
>> 
>>    O : T'Class := T'(null record);
>> 
>>    O.Foo;
>> 
>> The representation of O is (T'Tag, null record). When it dispatches on O to
>> Foo, T'Tag is stripped away and null record is passed to T's Foo. Within
>> Foo X has the representation null record, *always*. When X is converted in
>> Foo to T'Class, the result is (T'Tag, null record), because the type of X
>> is declared as T. When it dispatches on the result Bar, it is T's Bar that
>> is called, always, because the tag is T'Tag.
>> 
>> As you see, there is no re-dispatch possible with by-copy semantics.
> 
> You are presenting a particular form of by-copy, in which the tag (and
> no doubt all extension components) are removed when the value is copied
> in a call to a non-class-wide operation. Obviously redispatch is not
> possible then. But that is not the only possible way of passing
> parameters by copy.

I gave a use case. If you think that there could be another way to
implement it, we could consider it.

In particular, the case, which is especially interesting and important for
by-copy types, when the derived type has a representation completely
different from the base. For instance:

   type Wide_Wide_Character is ...; -- Full Unicode
   function Is_Digit (X : Wide_Wide_Character) return Boolean;
   function Is_Letter (X : Wide_Wide_Character) return Boolean;
   function Is_Alphanumeric  (X : Wide_Wide_Character) return Boolean;

   type Character is new Wide_Wide_Character without parent's mess ...;
   overriding function Is_Digit (X : Character) return Boolean;
   overriding function Is_Letter (X : Character) return Boolean;
 
Let you wanted re-dispatch in Is_Alphanumeric to Is_Digit and Is_Letter.

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

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Sat, 19 Apr 2014 10:19:02 +0200, Dmitry A. Kazakov wrote:

> "Re-" presumes that dispatch happens again. What is in common to these two
> instances of dispatch what makes it re-dispatch? It is 1) the same
> polymorphic operation and 2) the same object. Take either away and it is
> not re-dispatch anymore:
> 
> 1. Different operations:
> 
>    X.Foo;
>    X.Bar;  -- This is not re-dispatch!
> 
> 2. Different objects:
> 
>    X.Foo;
>    Y.Foo;  -- This is not re-dispatch!

After some consideration, I take the position 1 back. Operation can be
different. But the object must be same.

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

Re: Your wish list for Ada 202X

[Niklas Holsti]

On 14-04-19 11:19 , Dmitry A. Kazakov wrote:
> On Sat, 19 Apr 2014 10:35:36 +0300, Niklas Holsti wrote:
> 
>> On 14-04-19 00:18 , Dmitry A. Kazakov wrote:
>>> On Fri, 18 Apr 2014 22:10:50 +0300, Niklas Holsti wrote:
>>>
>>>> (Apologies for a delayed reply.)
>>>>
>>>> On 14-04-14 00:07 , Dmitry A. Kazakov wrote:
>>>>> On Sun, 13 Apr 2014 22:43:47 +0300, Niklas Holsti wrote:
>>>>>
>>>>>> On 14-04-12 11:20 , Dmitry A. Kazakov wrote:
>>>>>
>>>>>>> I don't deny
>>>>>>> existence of the problem. I am against the solution, which is inherently
>>>>>>> unsafe and constraining (precludes by-copy semantics).
>>>>>>
>>>>>> But class-wide operations which contain dispatching calls also preclude
>>>>>> by-copy semantics, don't they?
>>>>>
>>>>> Not at all. There is no problem for a class-wide operation to act on
>>>>> by-copy types.
>>>>>
>>>>> A by-copy class-wide object is a tuple (tag, type-specific value). Upon
>>>>> dispatch the value is passed copy-in/copy-out to the type specific
>>>>> operation.

I think I misunderstood you here. I now think you meant that only the
type-specific value (the second component of the tuple) is passed
copy-in/copy-out (but the tag is not passed). I misunderstood and
thought that you meant passing the entire tuple value (tag,
type-specific value) by copy-in/out.

>>>> OK, but from the implementation point of view, that form of by-copy
>>>> passing could be used for all operations of a tagged class, whether
>>>> class-wide or primitive, with or without redispatching.

If the tag is not passed (as I now understood you meant), then
redispatch is not possible, I agree.

>>> Re-dispatching presumes the same object.
>>
>> No it doesn't. Why should it? Redispatch merely selects an operation
>> based on the actual type (tag) of the parameter value.
> 
> This is called dispatch.

Yes, redispatch is a form of dispatch.

>> Whether the
>> operation acts on the same object or on a copy is a separate question.
> 
> "Re-" presumes that dispatch happens again. What is in common to these two
> instances of dispatch what makes it re-dispatch?

The fact that the calling operation has been reached by a dispatch on
the parameter's tag, and now a new dispatching call is made (dynamically
within the first dispatching call) based on this same tag.

This feature -- a first choice based on the tag, with a nested second
choice based on the same tag -- was a feature of redispatching that you
criticized in earlier discussions.

> It is 1) the same
> polymorphic operation and 2) the same object. Take either away and it is
> not re-dispatch anymore:
> 
> 1. Different operations:
> 
>    X.Foo;
>    X.Bar;  -- This is not re-dispatch!

Agreed, because the call to X.Bar does not occur in the body of Foo, so
it does not occur dynamically within the first dispatching call.

> 2. Different objects:
> 
>    X.Foo;
>    Y.Foo;  -- This is not re-dispatch!

Of course not.

> In particular, the case, which is especially interesting and important for
> by-copy types, when the derived type has a representation completely
> different from the base. For instance:
> 
>    type Wide_Wide_Character is ...; -- Full Unicode
>    function Is_Digit (X : Wide_Wide_Character) return Boolean;
>    function Is_Letter (X : Wide_Wide_Character) return Boolean;
>    function Is_Alphanumeric  (X : Wide_Wide_Character) return Boolean;
> 
>    type Character is new Wide_Wide_Character without parent's mess ...;
>    overriding function Is_Digit (X : Character) return Boolean;
>    overriding function Is_Letter (X : Character) return Boolean;
>  
> Let you wanted re-dispatch in Is_Alphanumeric to Is_Digit and Is_Letter.

Could you complete your thought here? I don't see a claim or a question yet.


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

Re: Your wish list for Ada 202X

[Niklas Holsti]

On 14-04-19 11:39 , Dmitry A. Kazakov wrote:
> On Sat, 19 Apr 2014 10:19:02 +0200, Dmitry A. Kazakov wrote:
> 
>> "Re-" presumes that dispatch happens again. What is in common to these two
>> instances of dispatch what makes it re-dispatch? It is 1) the same
>> polymorphic operation and 2) the same object. Take either away and it is
>> not re-dispatch anymore:
>>
>> 1. Different operations:
>>
>>    X.Foo;
>>    X.Bar;  -- This is not re-dispatch!
>>
>> 2. Different objects:
>>
>>    X.Foo;
>>    Y.Foo;  -- This is not re-dispatch!
> 
> After some consideration, I take the position 1 back. Operation can be
> different. But the object must be same.

If we are talking about by-copy types, then whether X and Y are the
"same object" is fuzzy. Is a copy the same object as the original? In
some logical sense it is, in a physical sense it isn't. Which do you mean?

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

Re: Redispatching

[Georg Bauhaus]

On 18/04/14 22:51, Dmitry A. Kazakov wrote:

> Consider this set of declarations:
>
>     type T is ...;
>     procedure Bar (X : T);
>
>     type S is new T ...;
>     procedure Foo (X : S);
>
> Now the following is illegal:
>
>     procedure Bar (X : T) is
>     begin
>        X.Foo;  -- Compile error
>     end Bar;
>
> X in Bar is of the type T and of no other type.
>
> You can convert X using so-called "view-conversion" to an object of another
> type, e.g. S or T'Class. This conversion is a type conversion. Yes, it has
> certain properties when X is tagged (and thus by-reference), such as
> reusing the old object for the new one. These properties are irrelevant to
> the type semantics though. You get an object of a different type.

Actually, in Ada, you will predictably get the object that is passed
for X, which "is" of its type. (As usual, the discussion hinges on
the meaning of "is".) This provides the programmer with more semantic
possibilities:

    procedure Bar (X : T) is
    begin
       S(T'Class(X)).Foo;  -- No compile error
    end Bar;

This type conversion (downwards) is legal, and it permits deferring any type
checking to run-time, should programmers have reason to do so. If you think
this is improper design, why not outline an algorithm that transfers any
such program into one that demonstrably dispenses with downward conversions.

> If Ada supported classes of by-copy types, then conversion to S or T'Class
> would produce a new object. But the type semantics would remain same.

In view of the above example, absent an isomorphic program transformation
as requested, by-copy types will require changing the semantics of Ada.

Re: Your wish list for Ada 202X

[Georg Bauhaus]

On 18/04/14 23:28, Randy Brukardt wrote:
> I'd prefer a much simpler declaration of inheritance, something like:
>     type Child is new Parent with ...
>        with inherits => Foo, Bar, Blech;
>
> where names not listed are hidden from all visibility unless overridden.

FTR, Eiffel has something like this, it's called Feature Adaptation.
Specifically, Eiffel allows renaming primitive operations on this occasion.


class Child
   inherit Parent
     redefine Foo, Bar end
     rename Blech as Sheet_Metal end
is ...

Feature_adaptation ::=
    [Undefine]
   [Redefine]
   [Rename]
   [New_exports]
   [Select]

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Sat, 19 Apr 2014 12:08:19 +0300, Niklas Holsti wrote:

> On 14-04-19 11:39 , Dmitry A. Kazakov wrote:
>> On Sat, 19 Apr 2014 10:19:02 +0200, Dmitry A. Kazakov wrote:
>> 
>>> "Re-" presumes that dispatch happens again. What is in common to these two
>>> instances of dispatch what makes it re-dispatch? It is 1) the same
>>> polymorphic operation and 2) the same object. Take either away and it is
>>> not re-dispatch anymore:
>>>
>>> 1. Different operations:
>>>
>>>    X.Foo;
>>>    X.Bar;  -- This is not re-dispatch!
>>>
>>> 2. Different objects:
>>>
>>>    X.Foo;
>>>    Y.Foo;  -- This is not re-dispatch!
>> 
>> After some consideration, I take the position 1 back. Operation can be
>> different. But the object must be same.
> 
> If we are talking about by-copy types, then whether X and Y are the
> "same object" is fuzzy. Is a copy the same object as the original?

A copy is another object.

> In some logical sense it is, in a physical sense it isn't.

The reverse. It might be logically same, when "=" yields true and
physically different.

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

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Sat, 19 Apr 2014 12:05:09 +0300, Niklas Holsti wrote:

> On 14-04-19 11:19 , Dmitry A. Kazakov wrote:
>> On Sat, 19 Apr 2014 10:35:36 +0300, Niklas Holsti wrote:
>> 
>>> On 14-04-19 00:18 , Dmitry A. Kazakov wrote:
>>>> On Fri, 18 Apr 2014 22:10:50 +0300, Niklas Holsti wrote:
>>>>
>>>>> (Apologies for a delayed reply.)
>>>>>
>>>>> On 14-04-14 00:07 , Dmitry A. Kazakov wrote:
>>>>>> On Sun, 13 Apr 2014 22:43:47 +0300, Niklas Holsti wrote:
>>>>>>
>>>>>>> On 14-04-12 11:20 , Dmitry A. Kazakov wrote:
>>>>>>
>>>>>>>> I don't deny
>>>>>>>> existence of the problem. I am against the solution, which is inherently
>>>>>>>> unsafe and constraining (precludes by-copy semantics).
>>>>>>>
>>>>>>> But class-wide operations which contain dispatching calls also preclude
>>>>>>> by-copy semantics, don't they?
>>>>>>
>>>>>> Not at all. There is no problem for a class-wide operation to act on
>>>>>> by-copy types.
>>>>>>
>>>>>> A by-copy class-wide object is a tuple (tag, type-specific value). Upon
>>>>>> dispatch the value is passed copy-in/copy-out to the type specific
>>>>>> operation.
> 
> I think I misunderstood you here. I now think you meant that only the
> type-specific value (the second component of the tuple) is passed
> copy-in/copy-out (but the tag is not passed). I misunderstood and
> thought that you meant passing the entire tuple value (tag,
> type-specific value) by copy-in/out.

Yes

>>> Whether the
>>> operation acts on the same object or on a copy is a separate question.
>> 
>> "Re-" presumes that dispatch happens again. What is in common to these two
>> instances of dispatch what makes it re-dispatch?
> 
> The fact that the calling operation has been reached by a dispatch on
> the parameter's tag, and now a new dispatching call is made (dynamically
> within the first dispatching call) based on this same tag.

But some other object might also have this tag. E.g. when generic
dispatching constructor is used. In my view, the tag is same because the
object is. Since tagged types magically make the tag accessible and
preserved, you could use it to construct a class-wide object and then
dispatch again.

As a side note, observe that preserving the tag is not a requirement,
semantically. For example, upon object's initialization (finalization), the
object's tag ascends (descends) the inheritance path, e.g. in C++.

>> In particular, the case, which is especially interesting and important for
>> by-copy types, when the derived type has a representation completely
>> different from the base. For instance:
>> 
>>    type Wide_Wide_Character is ...; -- Full Unicode
>>    function Is_Digit (X : Wide_Wide_Character) return Boolean;
>>    function Is_Letter (X : Wide_Wide_Character) return Boolean;
>>    function Is_Alphanumeric  (X : Wide_Wide_Character) return Boolean;
>> 
>>    type Character is new Wide_Wide_Character without parent's mess ...;
>>    overriding function Is_Digit (X : Character) return Boolean;
>>    overriding function Is_Letter (X : Character) return Boolean;
>>  
>> Let you wanted re-dispatch in Is_Alphanumeric to Is_Digit and Is_Letter.
> 
> Could you complete your thought here? I don't see a claim or a question yet.

The claim is that there seems no other way to implement
Wide_Wide_Character'Class than as I described earlier.

The representation of a class-wide object containing, say,
ROMAN_DENARIUS_SIGN will be

   (Wide_Wide_Character'Tag, ROMAN_DENARIUS_SIGN)

The representation of a class-wide object containing character 'A' will be

   (Character'Tag, 'A')

Note, this is different from:

   (Wide_Wide_Character'Tag, LATIN_CAPITAL_LETTER_A)

Though both would refer to the same Unicode code point.

When you dispatch on (Character'Tag, 'A') to Is_Alphanumeric, the parameter
of Is_Alphanumeric will be 'A'. You could not re-dispatch from there to
anything but to character's operations.

Note, that if Is_Alphanumeric were inherited, rather than overridden, as in
the example above, the original body would be composed with a conversion to
the parent type. The effect would be:

   Is_Alphanumeric (Wide_Wide_Character ('A'));

Wide_Wide_Character's is
  
   Is_Alphanumeric (x)

Character's is Is_Alphanumeric is

   Is_Alphanumeric (Wide_Wide_Character (x));
   ^^^  inherited body     ^^^ added per inheritance

This is exactly the semantics of Ada's tagged types as well. The conversion
in the case of a tagged type is a view conversion and thus a
null-operation. [Only when there is no MI, actually. In presence of full MI
view conversion could require adjusting the reference to the object]

The bottom line is, you cannot preserve the tag upon dispatching with
by-copy object. Therefore, no re-dispatch will be possible for them.

And the mantra sung here that any reasonable change would break Ada is a
distraction used to shut up the discussion. Ada 95 design of classes was
sound and it is quite possible to extend it to all types.

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

Re: Redispatching

[Dmitry A. Kazakov]

On Sat, 19 Apr 2014 11:17:22 +0200, Georg Bauhaus wrote:

> On 18/04/14 22:51, Dmitry A. Kazakov wrote:
> 
>> Consider this set of declarations:
>>
>>     type T is ...;
>>     procedure Bar (X : T);
>>
>>     type S is new T ...;
>>     procedure Foo (X : S);
>>
>> Now the following is illegal:
>>
>>     procedure Bar (X : T) is
>>     begin
>>        X.Foo;  -- Compile error
>>     end Bar;
>>
>> X in Bar is of the type T and of no other type.
>>
>> You can convert X using so-called "view-conversion" to an object of another
>> type, e.g. S or T'Class. This conversion is a type conversion. Yes, it has
>> certain properties when X is tagged (and thus by-reference), such as
>> reusing the old object for the new one. These properties are irrelevant to
>> the type semantics though. You get an object of a different type.
> 
> Actually, in Ada, you will predictably get the object that is passed
> for X, which "is" of its type. (As usual, the discussion hinges on
> the meaning of "is".) This provides the programmer with more semantic
> possibilities:
> 
>     procedure Bar (X : T) is
>     begin
>        S(T'Class(X)).Foo;  -- No compile error
>     end Bar;
> 
> This type conversion (downwards) is legal,

So would an instantiation of Unchecked_Conversion.

> If you think this is improper design,

Yes I do. You should abstain design of this kind as much as you would ones
using Unchecked_Conversion.

> why not outline an algorithm that transfers any
> such program into one that demonstrably dispenses with downward conversions.

Easily. The algorithm is. Type:

$ rm -f bar.adb

then take a cup of coffee  and review your design.

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

Re: Redispatching

[Georg Bauhaus]

On 19/04/14 12:58, Dmitry A. Kazakov wrote:
> The algorithm is. Type:
>
> $ rm -f bar.adb
>
> then take a cup of coffee  and review your design.

Programmers usually won't be allowed any more coffee after
deleting working solutions. More cleverness is needed.

Re: Your wish list for Ada 202X

[Niklas Holsti]

On 14-04-19 13:06 , Dmitry A. Kazakov wrote:
> On Sat, 19 Apr 2014 12:08:19 +0300, Niklas Holsti wrote:
> 
>> On 14-04-19 11:39 , Dmitry A. Kazakov wrote:
>>> On Sat, 19 Apr 2014 10:19:02 +0200, Dmitry A. Kazakov wrote:
>>>
>>>> "Re-" presumes that dispatch happens again. What is in common to these two
>>>> instances of dispatch what makes it re-dispatch? It is 1) the same
>>>> polymorphic operation and 2) the same object. Take either away and it is
>>>> not re-dispatch anymore:
>>>>
>>>> 1. Different operations:
>>>>
>>>>    X.Foo;
>>>>    X.Bar;  -- This is not re-dispatch!
>>>>
>>>> 2. Different objects:
>>>>
>>>>    X.Foo;
>>>>    Y.Foo;  -- This is not re-dispatch!
>>>
>>> After some consideration, I take the position 1 back. Operation can be
>>> different. But the object must be same.
>>
>> If we are talking about by-copy types, then whether X and Y are the
>> "same object" is fuzzy. Is a copy the same object as the original?
> 
> A copy is another object.

Then (by your definitions) redispatching is never possible based on
by-copy parameters, because (in your definition) redispatching only
occurs if the first and second dispatching call use the same object, but
the pass-by-copy in the first dispatching call (in your view) creates a
new object which is then used in the second dispatching call.

That is a consistent view (good for you) but it disagrees with my memory
of your earlier arguments against redispatching, which were based more
on the logical redundancy of two successive dispatching calls on the
same tag.

>> In some logical sense it is, in a physical sense it isn't.
> 
> The reverse. It might be logically same, when "=" yields true and
> physically different.

That's what I said, logically the same, physically not. You misread my
last sentence.

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

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Sat, 19 Apr 2014 16:53:47 +0300, Niklas Holsti wrote:

> On 14-04-19 13:06 , Dmitry A. Kazakov wrote:
>> On Sat, 19 Apr 2014 12:08:19 +0300, Niklas Holsti wrote:
>> 
>>> On 14-04-19 11:39 , Dmitry A. Kazakov wrote:
>>>> On Sat, 19 Apr 2014 10:19:02 +0200, Dmitry A. Kazakov wrote:
>>>>
>>>>> "Re-" presumes that dispatch happens again. What is in common to these two
>>>>> instances of dispatch what makes it re-dispatch? It is 1) the same
>>>>> polymorphic operation and 2) the same object. Take either away and it is
>>>>> not re-dispatch anymore:
>>>>>
>>>>> 1. Different operations:
>>>>>
>>>>>    X.Foo;
>>>>>    X.Bar;  -- This is not re-dispatch!
>>>>>
>>>>> 2. Different objects:
>>>>>
>>>>>    X.Foo;
>>>>>    Y.Foo;  -- This is not re-dispatch!
>>>>
>>>> After some consideration, I take the position 1 back. Operation can be
>>>> different. But the object must be same.
>>>
>>> If we are talking about by-copy types, then whether X and Y are the
>>> "same object" is fuzzy. Is a copy the same object as the original?
>> 
>> A copy is another object.
> 
> Then (by your definitions) redispatching is never possible based on
> by-copy parameters, because (in your definition) redispatching only
> occurs if the first and second dispatching call use the same object, but
> the pass-by-copy in the first dispatching call (in your view) creates a
> new object which is then used in the second dispatching call.
> 
> That is a consistent view (good for you) but it disagrees with my memory
> of your earlier arguments against redispatching, which were based more
> on the logical redundancy of two successive dispatching calls on the
> same tag.

Why does it disagree? There is no contradiction between A) re-dispatch is
impossible with by-copy semantics, and B) when re-dispatch is possible then
from the SW design POV, it is redundant, abstraction inversion, weak
typing, inefficient, LSP violation, maintenance headache, you name it. 

Arguably, if re-dispatch is impossible for by-copy types when it should be
made unavailable for by-reference types as well.

Finally, it was not necessary to introduce view conversions in Ada for the
purpose of re-dispatch, because the desired effect were achievable through
the Rosen's trick:

   type T is ...
       Self : not null access T'Class := T'Unchecked_Access;
   end record;

   procedure Foo (X : T) is
   begin
       X.Self.Bar; -- I know what I am doing
   end Foo;

Using Self is more visible as dangerous than view conversion, IMO.

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

Re: Your wish list for Ada 202X

[Niklas Holsti]

On 14-04-19 17:21 , Dmitry A. Kazakov wrote:
> On Sat, 19 Apr 2014 16:53:47 +0300, Niklas Holsti wrote:
> 
>> On 14-04-19 13:06 , Dmitry A. Kazakov wrote:
>>> On Sat, 19 Apr 2014 12:08:19 +0300, Niklas Holsti wrote:
>>>
>>>> On 14-04-19 11:39 , Dmitry A. Kazakov wrote:
>>>>> On Sat, 19 Apr 2014 10:19:02 +0200, Dmitry A. Kazakov wrote:
>>>>>
>>>>>> "Re-" presumes that dispatch happens again. What is in common to these two
>>>>>> instances of dispatch what makes it re-dispatch? It is 1) the same
>>>>>> polymorphic operation and 2) the same object. Take either away and it is
>>>>>> not re-dispatch anymore:
>>>>>>
>>>>>> 1. Different operations:
>>>>>>
>>>>>>    X.Foo;
>>>>>>    X.Bar;  -- This is not re-dispatch!
>>>>>>
>>>>>> 2. Different objects:
>>>>>>
>>>>>>    X.Foo;
>>>>>>    Y.Foo;  -- This is not re-dispatch!
>>>>>
>>>>> After some consideration, I take the position 1 back. Operation can be
>>>>> different. But the object must be same.
>>>>
>>>> If we are talking about by-copy types, then whether X and Y are the
>>>> "same object" is fuzzy. Is a copy the same object as the original?
>>>
>>> A copy is another object.
>>
>> Then (by your definitions) redispatching is never possible based on
>> by-copy parameters, because (in your definition) redispatching only
>> occurs if the first and second dispatching call use the same object, but
>> the pass-by-copy in the first dispatching call (in your view) creates a
>> new object which is then used in the second dispatching call.
>>
>> That is a consistent view (good for you) but it disagrees with my memory
>> of your earlier arguments against redispatching, which were based more
>> on the logical redundancy of two successive dispatching calls on the
>> same tag.
> 
> Why does it disagree? 

You are right, it doesn't. I was still thinking about my first
conception of your by-copy method, where the tag would also be copied,
which would allow redispatch. Sorry.

> Arguably, if re-dispatch is impossible for by-copy types when it should be
> made unavailable for by-reference types as well.

As has been made amply clear, I don't share that opinion.

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

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:brepivFq9kcU1@mid.individual.net...
> On 14-04-19 00:28 , Randy Brukardt wrote:
>> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
>> news:brdegqFi62jU1@mid.individual.net...
...
>> One of
>> the things that attracted me to Ada in the first place is that it forces 
>> me
>> to specify enough that it prevents many of my worst impulses.
>
> I learned programming with Algol and did not encounter C until I had
> experienced various forms of BASIC, COBOL, and Fortran (plus a few
> assembly languages). This shielded me, I think, from being tempted to
> use C-style short-cuts. So, perhaps unusually, I don't feel at all
> constrained by Ada's requirements on explicitness, careful
> specification, and strong typing.

Well, I started with various programmable calculator "languages" (really a 
machine language), then Fortran, then various Basics, then Z80 assembler, 
then a language survey class, then a class with C language assignments. The 
only school assignment that I didn't get to work by the due date was in C. I 
spent several hours after presenting it to the professor trying to figure 
out why one of the guns wouldn't fire (it was supposed to a game on a vector 
display, which we had to demonstrate -- I chose something vaguely like Space 
Invaders, which was new at the time). It proved to be an access beyond the 
end of an array that corrupted the firing table. I think I've written 7 or 8 
lines of C since. :-) [C is now pretty much a read-only language for me, 
sort of like French.]

But for me, I don't the languages used would make that much difference. My 
Dad is a tinkerer who would rather try for 4 hours to start a malfunctioning 
chain saw than to just take it to a repair shop and do something else. 
(That's the story from this past weekend, so some things change little!) I 
certainly learned that from him, and I *know* I'd dream up insane ways to 
get the job done if the language didn't impose some sanity. Maybe a little 
less so than in years past, but probably not enough to actually accomplish 
anything.

...
>> I'd prefer a much simpler declaration of inheritance, something like:
>>    type Child is new Parent with ...
>>       with inherits => Foo, Bar, Blech;
>>
>> where names not listed are hidden from all visibility unless overridden.
>
> This form would probably strongly discourage overloaded operation names.

Possible, although in many instances, all of the overloaded routines do 
essentially the same thing and thus either all need overriding or none do. 
(After all, if you have overloaded routines doing *different* things, 
something is wrong!)

>> Whether that's enough or if some alternative with optional profiles is
>> necessary, I don't know. Most operations aren't overloaded, after all, so
>> the profile is just noise.
>
> I have quite a few overloaded primitive operations, perhaps because I
> tend to use named association in all calls so that the parameter names
> extend and clarify the brief operation name.

Yes, that works. But still, you probably don't have too many Open operations 
that close objects. :-) As I said, I've found that it's common that you need 
to override all of the Open operations (because they all need to set a new 
component, for instance, or call a different Open routine that does that), 
or the original versions are all good enough. Perhaps that's different if 
multiple inheritance gets involved, but it certainly seems true for single 
inheritance.

But I don't claim to know the best way to do this, and it's pretty 
irrelevant for Ada anyway (it would be way too incompatible to require for 
derivations unless a new kind of derivation was involved - and it would take 
some imagination to figure a reason for needed a new kind of derivation).

                                     Randy.

Re: Your wish list for Ada 202X

[Niklas Holsti]

On 14-04-22 02:09 , Randy Brukardt wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
> news:brepivFq9kcU1@mid.individual.net...
>> On 14-04-19 00:28 , Randy Brukardt wrote: 
>>> ...
>>> I'd prefer a much simpler declaration of inheritance, something like:
>>>    type Child is new Parent with ...
>>>       with inherits => Foo, Bar, Blech;
>>>
>>> where names not listed are hidden from all visibility unless overridden.
>>
>> This form would probably strongly discourage overloaded operation names.
> 
> Possible, although in many instances, all of the overloaded routines do 
> essentially the same thing and thus either all need overriding or none do.

So saying "inherits => Foo" would inherit all operations named Foo. That
would work, but is a bit weak if the goal is to specify inheritance
explicitly.

> (After all, if you have overloaded routines doing *different* things, 
> something is wrong!)

Yes. So if the goal of "with inherits" is to specify explicitly the
"nature" of the inherited operations, for example all "read" operations
but no "write" operations, it is ok to let one name stand for all
operations with that name.

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

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Mon, 21 Apr 2014 18:09:46 -0500, Randy Brukardt wrote:

> Yes, that works. But still, you probably don't have too many Open operations 
> that close objects. :-) As I said, I've found that it's common that you need 
> to override all of the Open operations (because they all need to set a new 
> component, for instance, or call a different Open routine that does that), 
> or the original versions are all good enough. Perhaps that's different if 
> multiple inheritance gets involved, but it certainly seems true for single 
> inheritance.

But there should be no Open operation at all. The object must be functional
in each its state. Open is not an operation it is a part of the object's
constructor.

This is another language problem that Ada forces you to introduce Open,
which adds unusable object states (not yet opened object), must be
overridden (but there is no way to spell that requirement), must call to
the parent's Open (but. again, no way to ensure that).

Not every instance of bad design is due to the programmer's malice.

P.S. With MD Open will dispatch on File and on Path (path must be MI from
character set and a path|plain name|volume and absolute|relative
hierarchies) and, possibly, on additional parameter types. All variants
must be overridden!..

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

Re: Your wish list for Ada 202X

[Shark8]

On 22-Apr-14 02:02, Dmitry A. Kazakov wrote:
> But there should be no Open operation at all.

Why not?
It seems to me that Open could be ideal for some object, like say an 
object representing flood-gates, or an internally used operation for an 
"e-mail reader", or dozens of other things (perhaps file processing 
[e.g. Get_File_List, Filter, Open as basic 'operations' of the processor]).

> The object must be functional  in each its state. Open is not an
> operation it is a part of the object's constructor.

Again, see the above. -- I realize you're talking about _files_, but 
there's many more things that could need an 'open' than just files. 
{Moreover, 'open' might even be hidden in the implementation.}

> This is another language problem that Ada forces you to introduce Open,
> which adds unusable object states (not yet opened object), must be
> overridden (but there is no way to spell that requirement), must call
> to the parent's Open (but. again, no way to ensure that).

Not entirely true; with pre/post conditions, and perhaps type-invariants 
you can prohibit such states from being entered (which will result in an 
exception).

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Tue, 22 Apr 2014 02:30:17 -0600, Shark8 wrote:

> On 22-Apr-14 02:02, Dmitry A. Kazakov wrote:
>> But there should be no Open operation at all.
> 
> Why not?
> It seems to me that Open could be ideal for some object, like say an 
> object representing flood-gates, or an internally used operation for an 
> "e-mail reader", or dozens of other things (perhaps file processing 
> [e.g. Get_File_List, Filter, Open as basic 'operations' of the processor]).

This is a completely irrelevant case. I talked (and I believe Randy did
too) about Open like file open and hence the problem that it cannot be
inherited with consequent maintenance problems for clients.

>> This is another language problem that Ada forces you to introduce Open,
>> which adds unusable object states (not yet opened object), must be
>> overridden (but there is no way to spell that requirement), must call
>> to the parent's Open (but. again, no way to ensure that).
> 
> Not entirely true; with pre/post conditions, and perhaps type-invariants 
> you can prohibit such states from being entered (which will result in an 
> exception).

Which is exactly the problem - this introduces erroneous states, where
there should be none. From the SW design POV there shall be no way to
create a closed file, an uninitialized widget, a float with the FPU turned
off etc.

The elementary principle of SW design is that the program must be
functional in each of its states., in other words be a correct program.

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

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:10o6qo98dwzjs$.rdpzvq7w1lep.dlg@40tude.net...
...
> Which is exactly the problem - this introduces erroneous states, where
> there should be none. From the SW design POV there shall be no way to
> create a closed file, an uninitialized widget, a float with the FPU turned
> off etc.

I suspect that in the case of files, that would be too limiting to be of 
much use. One could not have a container (or array) of files, for instance, 
because there would be no way to provide the file names to each element 
before it existed. You would have resort to using dynamic allocation for 
almost all uses, and that would be a giant step backwards for an Ada-like 
language.

                         Randy.

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Tue, 22 Apr 2014 18:23:19 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:10o6qo98dwzjs$.rdpzvq7w1lep.dlg@40tude.net...
> ...
>> Which is exactly the problem - this introduces erroneous states, where
>> there should be none. From the SW design POV there shall be no way to
>> create a closed file, an uninitialized widget, a float with the FPU turned
>> off etc.
> 
> I suspect that in the case of files, that would be too limiting to be of 
> much use. One could not have a container (or array) of files, for instance, 
> because there would be no way to provide the file names to each element 
> before it existed.

Firstly, this is another language problem, e.g. lack of user-defined
aggregates and user-defined array constructors.

Secondly, there is a pattern for this. I am using a stock object to
initialize such things. Another example where this is needed is a handle
wrapping a non null pointer:

   type Safe_Handle (<>) is new Ada.Finalization.Controlled with private;
   ...
private
   type Safe_Handle is new Ada.Finalization.Controlled with
       Object : non null access Object_Type'Class := Stock_Object'Access;
   end record;

In the case of files there already is such stick object: /dev/null.

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

Re: Your wish list for Ada 202X

[björn lundin]

Den tisdagen den 25:e mars 2014 kl. 22:41:16 UTC+1 skrev Stoik:
> I think that even a casual user of Ada should be able to influence somehow the new version of Ada. I wonder what is high on your list of wishes for Ada 202X?
> 

I'd like V'Img to be standard ada like T'Image(V);
As in the gnat implementation

type T is some_discrete_type
V : T;

Put_Line(V'Img);

Also, I'd like to be able to define the string function
for a record type to be used for the 'image attribute.

type T2 is record
  A : T;
  B : T;
end record;

function F_T2_Image(O : T2) return String is
begin
  return O.A'Img & " " O.B'Img;
end F_T2_Image;

for T2'Image use F_T2_Image

V2 : T2;
..
Put_Line(V2'Img);


/Björn

Re: Your wish list for Ada 202X

[J-P. Rosen]

Le 23/04/2014 14:55, björn lundin a écrit :

> I'd like V'Img to be standard ada like T'Image(V); As in the gnat
> implementation
> 
No big cost, no big benefit...

> Also, I'd like to be able to define the string function for a record
> type to be used for the 'image attribute.
> 
> type T2 is record A : T; B : T; end record;
> 
> function F_T2_Image(O : T2) return String is begin return O.A'Img & "
> " O.B'Img; end F_T2_Image;
> 
> for T2'Image use F_T2_Image
> 
> V2 : T2; .. Put_Line(V2'Img);
> 
And what is the benefit over writing:
   Put_Line (F_T2_Image (V2));
?

(of course, saving typing 9 characters does not count!)
-- 
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: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Wed, 23 Apr 2014 05:55:00 -0700 (PDT), björn lundin wrote:

> I'd like V'Img to be standard ada like T'Image(V);
> As in the gnat implementation

V means value, not an object? A value could be ambiguous. E.g.

   123'Img

OK, considering no place for the sign as in T'Image(V), the image of a
modular and of an integer type will be same. But what about floating point
types:

   12.0001000020003'Img

Depending on Float, Long_Float, IEEE_Float_32 the result will be different.

> type T is some_discrete_type
> V : T;
> 
> Put_Line(V'Img);
> 
> Also, I'd like to be able to define the string function
> for a record type to be used for the 'image attribute.

The only reason why anybody would use an attribute over a [primitive]
function is that the attribute 'Image is predefined by the
language/compiler. If record types ought to get 'Img, you should specify
how to generate it for whatever record type.

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

Re: Your wish list for Ada 202X

[björn lundin]

Den onsdagen den 23:e april 2014 kl. 15:57:03 UTC+2 skrev J-P. Rosen:
> Le 23/04/2014 14:55, björn lundin a écrit :
> > I'd like V'Img to be standard ada like T'Image(V); As in the gnat
> > implementation
> 
> > 
> 
> No big cost, no big benefit...
> 

No big cost, but the benefit is when you are in
someone else code, or you have a fairly big system,
with type definitions in several files.

You then need to include the whole type
Pkg_with_Long_Name.Child_pkg_With_Even_Longer_Name.T'Image(V)

instead of V'img


Not a great leap for mankind, but still improvement.
I find myself often use 'img in gnat, because it is easy.
Yes, I'm lazy, but many people are lazy.

Also, If I'd like a logfile statement, which I often do
I very much prefer

V'img
before
Pkg_with_Long_Name.Child_pkg_With_Even_Longer_Name.T'Image(V)

> 
> > Also, I'd like to be able to define the string function for a record
> > type to be used for the 'image attribute.
> > type T2 is record A : T; B : T; end record;
> > function F_T2_Image(O : T2) return String is begin return O.A'Img & "
> > " O.B'Img; end F_T2_Image;
> > 
> > for T2'Image use F_T2_Image
> > 
> > V2 : T2; .. Put_Line(V2'Img);
> > 
> 
> And what is the benefit over writing:
> 
>    Put_Line (F_T2_Image (V2));

not very much.
But the usual case is that you have to write

Pkg_with_Long_Name.Child_pkg_With_Even_Longer_Name.F_T2_Image(V2)

instead of V2'img

/Björn

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Wed, 23 Apr 2014 15:57:03 +0200, J-P. Rosen wrote:

> Le 23/04/2014 14:55, björn lundin a écrit :
> 
>> I'd like V'Img to be standard ada like T'Image(V); As in the gnat
>> implementation
>> 
> No big cost, no big benefit...
> 
>> Also, I'd like to be able to define the string function for a record
>> type to be used for the 'image attribute.
>> 
>> type T2 is record A : T; B : T; end record;
>> 
>> function F_T2_Image(O : T2) return String is begin return O.A'Img & "
>> " O.B'Img; end F_T2_Image;
>> 
>> for T2'Image use F_T2_Image
>> 
>> V2 : T2; .. Put_Line(V2'Img);
>> 
> And what is the benefit over writing:
>    Put_Line (F_T2_Image (V2));
> ?

generic
    type T is private;
package Foo is ...

package body Foo is
   procedure Bar (X : T) is
   begin
       ... X'Img ...
 
That is the only use case for an attribute, in absence of primitive
operations of course.

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

Re: Your wish list for Ada 202X

[björn lundin]

Den onsdagen den 23:e april 2014 kl. 16:06:55 UTC+2 skrev Dmitry A. Kazakov:
> On Wed, 23 Apr 2014 05:55:00 -0700 (PDT), björn lundin wrote:

> > I'd like V'Img to be standard ada like T'Image(V);
> > As in the gnat implementation
> V means value, not an object? A value could be ambiguous. E.g.

Yes value. Sorry if I was not clear.

> 
> OK, considering no place for the sign as in T'Image(V), the image of a
> modular and of an integer type will be same. But what about floating point
> types:

I stated discrete_types.

> > type T is some_discrete_type
> 

 
> > Also, I'd like to be able to define the string function
> > for a record type to be used for the 'image attribute.
> The only reason why anybody would use an attribute over a [primitive]
> function is that the attribute 'Image is predefined by the
> language/compiler. If record types ought to get 'Img, you should specify
> how to generate it for whatever record type.

No. Not the only reason.
Another reason is when you work on a legacy system, 
that was implemented with Ada83.
The system then turns out to be stubbornly vital, 
so it won't go away for many years. But there are
few or no tagged types. 

So, being able to define an 'Img attribute on eg

  type AD_ASSIGNMENT_RECORD is
    record
      ASSIGNMENT_ID          : ASSIGNMENT_ID_TYPE;
      ASSIGNMENT_MODE        : ASSIGNMENT_MODE_TYPE;
      ASSIGNMENT_TYPE        : ASSIGNMENT_TYPE_TYPE;
      CURRENT_ADDRESS        : ADDRESS_TYPE;
      DESTINATION            : ADDRESS_TYPE;
      PRIORITY               : INTEGER_4;
      LAST_ASSIGNMENT        : YESNO_TYPE;
      LOAD_TYPE              : PALLET_CODE_TYPE;
      LOAD_HEIGHT            : HEIGHT_CODE_TYPE;
      LOAD_WEIGHT            : INTEGER_4;
      ZONE                   : INTEGER_4;
      HANDLER                : ADDRESS_TYPE;
      SEMI_AUTO_SUB_SYSTEM_ID: SUB_SYSTEM_ID_TYPE;
      SEQUENCE_ID            : STRING(1..SEQUENCE_ID_MAX_LENGTH);
      PALLET_ID              : PALLET_ID_TYPE;
      ADDITIONAL_INFO_LENGTH : ADDITIONAL_INFORMATION_LENGTH_TYPE;
      ADDITIONAL_INFO        : ADDITIONAL_INFORMATION_TYPE;
      FILLER_1               : STRING(1..2);		                -- v8.1
      TRANSPORT_TYPE         : INTEGER_4;		                    -- v9.1
      SHIPPING_DATE          : SATTMATE_CALENDAR.TIME_TYPE;		  -- v9.1
      FILLER_2               : STRING(1..2);		                -- v9.1
    end record;

  for AD_ASSIGNMENT_RECORD'alignment use 4;
  for AD_ASSIGNMENT_RECORD use       -- V6.5b
    record
      ASSIGNMENT_ID           at   0 range 0..31;       -- V6.5b
      ASSIGNMENT_MODE         at   4 range 0..31;       -- V6.5b
      ASSIGNMENT_TYPE         at   8 range 0..31;       -- V6.5b
      CURRENT_ADDRESS         at  12 range 0..8*24-1;   -- V6.5b
      DESTINATION             at  36 range 0..8*24-1;   -- V6.5b
      PRIORITY                at  60 range 0..31;       -- V6.5b
      LAST_ASSIGNMENT         at  64 range 0..31;       -- V6.5b
      LOAD_TYPE               at  68 range 0..31;       -- V6.5b
      LOAD_HEIGHT             at  72 range 0..31;       -- V6.5b
      LOAD_WEIGHT             at  76 range 0..31;       -- V6.5b
      ZONE                    at  80 range 0..31;       -- V6.5b
      HANDLER                 at  84 range 0..8*24-1;   -- V6.5b
      SEMI_AUTO_SUB_SYSTEM_ID at 108 range 0..31;       -- V6.5b
      SEQUENCE_ID             at 112 range 0..8*4-1;    -- V6.5b
      PALLET_ID               at 116 range 0..8*16-1;		-- V6.5b, v8.1
      ADDITIONAL_INFO_LENGTH  at 132 range 0..31;       -- V6.5b, v8.1
      ADDITIONAL_INFO         at 136 range 0..8*50-1;   -- V6.5b, v8.1
      FILLER_1                at 186 range 0..8*2-1;    -- v8.1
      TRANSPORT_TYPE          at 188 range 0..31;       -- v9.1
      SHIPPING_DATE           at 192 range 0..16*7-1;   -- v9.1
      FILLER_2                at 206 range 0..8*2-1;    -- v9.1
    end record;								-- V6.5b

  for AD_ASSIGNMENT_RECORD'SIZE use 8*208;			-- V6.5b, v8.1, v9.1


would be really nice.
All types within the record are 2 or 4 bytes integers or strings

(The representation clauses where vital for sending record like this
 with generic functions using ipc on vax/ppc/ and intel boxes.
 They also where importatant when sending BETWEEN ppc and intelboxes.
 This is now rewritten, but not tested without the representation clauses 
 so I do not dear to remove them just yet 
)


/Björn

Re: Your wish list for Ada 202X

[björn lundin]

Den onsdagen den 23:e april 2014 kl. 16:06:55 UTC+2 skrev Dmitry A. Kazakov:
> On Wed, 23 Apr 2014 05:55:00 -0700 (PDT), björn lundin wrote:

 
> V means value, not an object? A value could be ambiguous. E.g.

I see now that I misinterpreted you.
I did not mean value.
I meant variable. object or not.

as in the V in

V : Integer

>    123'Img
Not like this

> OK, considering no place for the sign as in T'Image(V), the image of a
> modular and of an integer type will be same. But what about floating point
> types:
> 
>    12.0001000020003'Img

Which take away this case, because it is not a variable.
If it was, It would work like Float'Image(variable)
or Long_Float'Image(Variable) depending on how varible was declared

/Björn

Re: Your wish list for Ada 202X

[J-P. Rosen]

Le 23/04/2014 16:32, björn lundin a écrit :
>> And what is the benefit over writing:
>> > 
>> >    Put_Line (F_T2_Image (V2));
> not very much.
> But the usual case is that you have to write
> 
> Pkg_with_Long_Name.Child_pkg_With_Even_Longer_Name.F_T2_Image(V2)
> 
> instead of V2'img
Ah! Another case of "I don't want to use the use clause, give me
something else that avoids writing these damn long names".

Either you think that you need to precisely specify where each called
function is located, and you are bound to long names, or you think that
the abstract meaning is fine and you don't care where it is declared,
and, by all means, just use one of the variants of "use"!


-- 
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: Your wish list for Ada 202X

[J-P. Rosen]

Le 23/04/2014 16:38, Dmitry A. Kazakov a écrit :
>> And what is the benefit over writing:
>> >    Put_Line (F_T2_Image (V2));
>> > ?
> generic
>     type T is private;
> package Foo is ...
> 
> package body Foo is
>    procedure Bar (X : T) is
>    begin
>        ... X'Img ...
>  
> That is the only use case for an attribute, in absence of primitive
> operations of course.

But that would require every type to have a 'Img. Yes, you said you
wanted that, but there are clearly types where no sensible image could
be provided. Of course, you can always provide non-sensible strings...

-- 
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: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Wed, 23 Apr 2014 17:46:04 +0200, J-P. Rosen wrote:

> Le 23/04/2014 16:38, Dmitry A. Kazakov a écrit :
>>> And what is the benefit over writing:
>>> >    Put_Line (F_T2_Image (V2));
>>> > ?
>> generic
>>     type T is private;
>> package Foo is ...
>> 
>> package body Foo is
>>    procedure Bar (X : T) is
>>    begin
>>        ... X'Img ...
>>  
>> That is the only use case for an attribute, in absence of primitive
>> operations of course.
> 
> But that would require every type to have a 'Img. Yes, you said you
> wanted that, but there are clearly types where no sensible image could
> be provided.

No, I didn't want that.

Instead I would do two things:

1. Classes for all types;

2. An interface named Printable (or whatever else name) with the primitive
operation Image.

Now, if a type is supposed to have Image, it must implement the interface.
All scalar types will.

If a record type need to have Image, you inherit to Printable. If Image is
needed in a generic the formal type inherits to Printable. That's it.

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

Re: Your wish list for Ada 202X

[björn lundin]

Den onsdagen den 23:e april 2014 kl. 17:43:48 UTC+2 skrev J-P. Rosen:
> Le 23/04/2014 16:32, björn lundin a écrit :
> 
> >> And what is the benefit over writing:
> >> >    Put_Line (F_T2_Image (V2));
> > not very much.
> > But the usual case is that you have to write
> > Pkg_with_Long_Name.Child_pkg_With_Even_Longer_Name.F_T2_Image(V2)
> > instead of V2'img
> 
> Ah! Another case of "I don't want to use the use clause, give me
> something else that avoids writing these damn long names".

No. using the 'use' is certainly something one can have different opinions on.
But I like to avoid these kind of errors

               SET_ERROR_MODE(NO_ERROR, CRANE_TYPES.ASSIGNMENT_TIMEOUT, FALSE);
                                     |
        >>> error: "NO_ERROR" is not visible
        >>> error: multiple use clauses cause hiding
        >>> error: hidden declaration at crane_types.ads:113
        >>> error: hidden declaration at siemens_interface.ads:374
        >>> error: hidden declaration at core_types.ads:71


One of the best thing with Ada05 was the approval of object.verb notation.
Even if i get to use it seldom at work, I do in hobby projects,
just for this reason. The variable/object knows where it belongs,
no need to use 'use' everywhere.

This is the basic idea for my 'img proposal. 
The variable knows its type. No need to
have long package names or risk hidden declarations.

By the way, the above hidden situation was because of
adding a constant 'NO_ERROR' in siemens_interface.ads

the other two was a constant and a coded value.
no hiding before that.
/Björn

Re: Your wish list for Ada 202X

[J-P. Rosen]

Le 23/04/2014 18:27, Dmitry A. Kazakov a écrit :
>> But that would require every type to have a 'Img. Yes, you said you
>> > wanted that, but there are clearly types where no sensible image could
>> > be provided.
> No, I didn't want that.
> 
> Instead I would do two things:
> 
> 1. Classes for all types;
> 
> 2. An interface named Printable (or whatever else name) with the primitive
> operation Image.
> 
> Now, if a type is supposed to have Image, it must implement the interface.
> All scalar types will.
> 
> If a record type need to have Image, you inherit to Printable. If Image is
> needed in a generic the formal type inherits to Printable. That's it.

But why require such a machinery? If you want to express that a formal
type must feature an Image function, you can do it even in '83:

generic
   type T is private;
   with function Image (Item : T) return String;
package Foo is...

What would an attribute bring as benefit?

-- 
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: Your wish list for Ada 202X

[J-P. Rosen]

Le 23/04/2014 18:31, björn lundin a écrit :
> No. using the 'use' is certainly something one can have different opinions on.
> But I like to avoid these kind of errors
> 
>                SET_ERROR_MODE(NO_ERROR, CRANE_TYPES.ASSIGNMENT_TIMEOUT, FALSE);
>                                      |
>         >>> error: "NO_ERROR" is not visible
>         >>> error: multiple use clauses cause hiding
>         >>> error: hidden declaration at crane_types.ads:113
>         >>> error: hidden declaration at siemens_interface.ads:374
>         >>> error: hidden declaration at core_types.ads:71
> 
> 
> One of the best thing with Ada05 was the approval of object.verb notation.
> Even if i get to use it seldom at work, I do in hobby projects,
> just for this reason. The variable/object knows where it belongs,
> no need to use 'use' everywhere.
> 
> This is the basic idea for my 'img proposal. 
> The variable knows its type. No need to
> have long package names or risk hidden declarations.
> 
> By the way, the above hidden situation was because of
> adding a constant 'NO_ERROR' in siemens_interface.ads
> 
> the other two was a constant and a coded value.
> no hiding before that.

I would tend to say that the "use" has the benefit to show you that you
used the same name in various contexts with various meanings, and that a
bit of reingeneering might be in order...

-- 
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: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Wed, 23 Apr 2014 18:40:33 +0200, J-P. Rosen wrote:

> Le 23/04/2014 18:27, Dmitry A. Kazakov a écrit :
>>> But that would require every type to have a 'Img. Yes, you said you
>>> > wanted that, but there are clearly types where no sensible image could
>>> > be provided.
>> No, I didn't want that.
>> 
>> Instead I would do two things:
>> 
>> 1. Classes for all types;
>> 
>> 2. An interface named Printable (or whatever else name) with the primitive
>> operation Image.
>> 
>> Now, if a type is supposed to have Image, it must implement the interface.
>> All scalar types will.
>> 
>> If a record type need to have Image, you inherit to Printable. If Image is
>> needed in a generic the formal type inherits to Printable. That's it.
> 
> But why require such a machinery? If you want to express that a formal
> type must feature an Image function, you can do it even in '83:
> 
> generic
>    type T is private;
>    with function Image (Item : T) return String;
> package Foo is...
> 
> What would an attribute bring as benefit?

Primitive operation (and an attribute) cannot get lost, become hidden,
replaced by another operation. A stray formal function can and easily does.

Furthermore, the formal declarations above is nothing but a poor man's
description of an interface, ADT + operations (Image, ":=", "=", "/=" etc).

Since Ada 95 has proper interfaces (tagged types), we should rather use
them. Which is shorter (you don't need to reiterate the list of operations)
and *greatly* safer, because proper interfaces are matched nominally, while
generic formal interfaces are matched by structure, proper interfaces can
be encapsulated in packages and formal interfaces cannot, proper interfaces
can be reused in several packages and formal interfaces need cut and paste
and so on.

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

Re: Your wish list for Ada 202X

[björn lundin]

Den onsdagen den 23:e april 2014 kl. 18:42:55 UTC+2 skrev J-P. Rosen:
> Le 23/04/2014 18:31, björn lundin a écrit :
> 
> > No. using the 'use' is certainly something one can have different opinions on.
> 

> 
> I would tend to say that the "use" has the benefit to show you that you
> used the same name in various contexts with various meanings, and that a
> bit of reingeneering might be in order...

Yes. it might. or not. 
The code is written by several programmers during different times.
I think each of them had good reasons to declare a constant NO_ERROR,
when communicationg with different devices, like PLCs.
Either in a conveyor sub system or in a crane sub system. 
Calling then SIEMENS_S5_NO_ERROR or CRANE_NO_ERROR would put the ambiguity away,
but the code would look awful.

The clash was recent, due to ever evolving changes- new demands from customers.
New demands lead me to define yet another NO_ERROR constant, for a new subsystem,
siemens s7.

but reengineer a running project due to I cannot use 'use' in this context.
Well, yes, if the customer pays for that. Otherwise, they are happy with me qualifying NO_ERROR with correct package name.

So, In a technical sense I agree. Re-engineer. But in a practical sense I do not.
Cost way too much, and gains too little.

while my suggestions about 'Img may not gain very much, it would help at least me.
and it would probably not cost very much

/Björn

Re: Your wish list for Ada 202X

[Jeffrey Carter]

On 04/23/2014 08:43 AM, J-P. Rosen wrote:
>>
> Ah! Another case of "I don't want to use the use clause, give me
> something else that avoids writing these damn long names".

While I agree with your sentiment, I think there's something else involved here, 
too. The Ada-95 version of the PragmAda Reusable Components include protected 
versions of the data structures, and in numerous cases users chose the protected 
version for purely sequential software in order to obtain the Object.Operation 
notation that a protected type offers. This was true even for users who used use 
clauses, and so chose to write

Queue.Put (Item => Thingy);

rather than

Put (Onto => Queue, Item => Thingy);

I don't think this is an issue of saving keystrokes, but a belief that the 
former is easier to read than the latter.

With the addition of such notation for tagged types in 2007, exposure to this 
difference has become more widespread, so desiring V'Image rather than T'Image 
(V) may not be entirely about saving keystrokes.

-- 
Jeff Carter
"Run away! Run away!"
Monty Python and the Holy Grail
58

Re: Your wish list for Ada 202X

[Jeffrey Carter]

On 04/23/2014 05:55 AM, björn lundin wrote:
>
> I'd like V'Img to be standard ada like T'Image(V);
> As in the gnat implementation

If this is accepted, it should be V'Image. GNAT uses 'Img because 
implementation-defined attributes are allowed; new uses of existing attributes 
are not.

-- 
Jeff Carter
"Run away! Run away!"
Monty Python and the Holy Grail
58

Re: Your wish list for Ada 202X

[Shark8]

On 23-Apr-14 01:45, Dmitry A. Kazakov wrote:
> In the case of files there already is such stick object: /dev/null.

I think there's a problem with that assertion
> C:\Programming\Projects\SiennaSCL\src>cd /dev/null
> The system cannot find the path specified.

See?

Re: Your wish list for Ada 202X

[Shark8]

On 23-Apr-14 06:55, björn lundin wrote:
>
> I'd like V'Img to be standard ada like T'Image(V);
> As in the gnat implementation

I'd rather get a V'Type attribute; it would effectively solve your 
problem here as V'Img would be equivalent to:
	V'Type'Image( V )

This would also give us a bit more functionality rather than simply 
elevating a common case into the standard..

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Wed, 23 Apr 2014 13:43:19 -0600, Shark8 wrote:

> On 23-Apr-14 01:45, Dmitry A. Kazakov wrote:
>> In the case of files there already is such stick object: /dev/null.
> 
> I think there's a problem with that assertion
>> C:\Programming\Projects\SiennaSCL\src>cd /dev/null
>> The system cannot find the path specified.
> 
> See?

Path /= File

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

Re: Your wish list for Ada 202X

[Randy Brukardt]

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

"björn lundin" <b.f.lundin@gmail.com> wrote in message 
news:4e3a0e68-1514-4255-9c76-ef8758991ded@googlegroups.com...
...
>> Ah! Another case of "I don't want to use the use clause, give me
>> something else that avoids writing these damn long names".
>
>No. using the 'use' is certainly something one can have different opinions 
>on.
>But I like to avoid these kind of errors
>
>               SET_ERROR_MODE(NO_ERROR, CRANE_TYPES.ASSIGNMENT_TIMEOUT, 
> FALSE);
>                                     |
>        >>> error: "NO_ERROR" is not visible
>        >>> error: multiple use clauses cause hiding
>        >>> error: hidden declaration at crane_types.ads:113
>        >>> error: hidden declaration at siemens_interface.ads:374
>        >>> error: hidden declaration at core_types.ads:71

This is precisely why I consider package use a significant maintenance 
hazard. That hazard could have been reduced by allowing more things 
(especially objects) to be overloadable, but it cannot be eliminated (with 
introducing Beaujolias or other nasty effects).

>One of the best thing with Ada05 was the approval of object.verb notation.

Ada 2012 adds "use all type" with essentially the same semantics as 
object.verb notation. If you have untagged types, especially enumerations, I 
strongly suggest using that. (Since it only makes overloadable entities 
visible, it doesn't have the maintenance hazard unless the profiles match --  
in which case you have a design problem.)

                                 Randy.
 

Re: Your wish list for Ada 202X

[Randy Brukardt]

"J-P. Rosen" <rosen@adalog.fr> wrote in message 
news:lj8qid$j23$2@dont-email.me...
...
> I would tend to say that the "use" has the benefit to show you that you
> used the same name in various contexts with various meanings, and that a
> bit of reingeneering might be in order...

That's baloney. For instance, if we were to add an exception to Claw, it 
might very well have the same name as some exception the client (or even 
another third party) declared somewhere. Why do you think this is a problem? 
The teams maintaining the subsystems no contact and only happen to be both 
included in some client program. Our maintenance, however, could break the 
client program even though there is no intended use of the new entity. 
That's just wrong.

I've come to realize that the problem isn't use-clauses per-se, it's use 
clauses of things that maintenance can change (specifically when changes to 
non-overloadable entities can happen). As such, package use clause is 
acceptable on language-defined packages that don't allow 
implementation-defined identifiers, but that's it. In contrast, "use all 
type" (and the more limited "use type") are acceptable anywhere, as their 
maintenance hazard is much more limited, mostly to things for which having 
the same name and type profile is dubious anyway.

                                 Randy.

Re: Your wish list for Ada 202X

[Randy Brukardt]

"Jeffrey Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:lj8v7s$l5o$1@dont-email.me...
> On 04/23/2014 08:43 AM, J-P. Rosen wrote:
>>>
>> Ah! Another case of "I don't want to use the use clause, give me
>> something else that avoids writing these damn long names".
>
> While I agree with your sentiment, I think there's something else involved 
> here, too. The Ada-95 version of the PragmAda Reusable Components include 
> protected versions of the data structures, and in numerous cases users 
> chose the protected version for purely sequential software in order to 
> obtain the Object.Operation notation that a protected type offers. This 
> was true even for users who used use clauses, and so chose to write
>
> Queue.Put (Item => Thingy);
>
> rather than
>
> Put (Onto => Queue, Item => Thingy);
>
> I don't think this is an issue of saving keystrokes, but a belief that the 
> former is easier to read than the latter.
>
> With the addition of such notation for tagged types in 2007, exposure to 
> this difference has become more widespread, so desiring V'Image rather 
> than T'Image (V) may not be entirely about saving keystrokes.

It's not, it's mainly about wanting to avoid the effort to look up the exact 
subtype of an object before writing 'Image. That wastes far more time than 
the few keystrokes ever would take. (Which is redoubled if one has to find 
out whether Image exists or some function has to be used instead.)

                                        Randy.

Re: Your wish list for Ada 202X

[Randy Brukardt]

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

"björn lundin" <b.f.lundin@gmail.com> wrote in message 
news:63812656-3d79-4330-8b02-1836f3669b00@googlegroups.com...
Den onsdagen den 23:e april 2014 kl. 16:06:55 UTC+2 skrev Dmitry A. Kazakov:
...
>> OK, considering no place for the sign as in T'Image(V), the image of a
>> modular and of an integer type will be same. But what about floating 
>> point
>> types:
>
>I stated discrete_types.

That would be a very weird restriction, as subtype'Image is defined for all 
scalar types (including float and fixed types).

Obj'Image almost certainly would not be defined for literals, as a literal 
cannot be the prefix of an attribute and changing the attribute machinery 
would kill the cost/benefit ratio of any such change. One could allow values 
that are names (Float'(3.14159)'Image) but there's not problem determining 
how to handle that.

Also note that the name would be "Image". GNAT uses "Img" because 
language-defined attributes cannot be redefined, but they would have much 
preferred to call it "Image". No need nor sense to use a different name 
('First can have an object or subtype prefix, so nothing new about that.)

If it sounds like I've considered this extensively, that's because I have. 
:-) Another proposal that I worked on carefully was Obj'Succ (where Obj 
could be a complex expression, which is better than Obj := Obj + 1; as that 
has a duplication of Obj.)

...
>No. Not the only reason.
>Another reason is when you work on a legacy system,
>that was implemented with Ada83.
>The system then turns out to be stubbornly vital,
>so it won't go away for many years. But there are
>few or no tagged types.

If it's still required to stay in Ada 83, then adding Obj'Image to Ada 2020 
isn't going to help any. If it's able to be changed, then there are lot of 
things that ought to be re-engineered if substantial work is going to be 
done, and using Obj'Image is down in the noise.

BTW, your proposal is a lot like the way stream attributes work, and that 
has proven to be a massive can-of-worms. The entire mess about availability 
of stream attributes comes about because of the ability of different views 
to have a different ideaa of whether an attribute is legal or not. This is 
not a trivial idea (nor is the one in AI12-0020-1).

(Also note that providing 'Image implies providing a matching 'Value, just 
like providing 'Write implies providing 'Read. 'Value is a lot messier than 
'Image, in general.)

                          Randy.

Re: Your wish list for Ada 202X

[Shark8]

On 23-Apr-14 14:00, Dmitry A. Kazakov wrote:
> On Wed, 23 Apr 2014 13:43:19 -0600, Shark8 wrote:
>
>> On 23-Apr-14 01:45, Dmitry A. Kazakov wrote:
>>> In the case of files there already is such stick object: /dev/null.
>>
>> I think there's a problem with that assertion
>>> C:\Programming\Projects\SiennaSCL\src>cd /dev/null
>>> The system cannot find the path specified.
>>
>> See?
>
> Path /= File

Not much different:

C:\Programming\Projects\SiennaSCL\src>type /dev/null
The syntax of the command is incorrect.

Besides, as there is no '/dev/' there can be no children [files or 
subdirs] thereof.

Re: Your wish list for Ada 202X

[Pascal Obry]

Le mercredi 23 avril 2014 à 10:51 -0700, björn lundin a écrit : 
> Calling then SIEMENS_S5_NO_ERROR or CRANE_NO_ERROR would put the ambiguity away,
> but the code would look awful.

I fully agree. I'm also in the "no use" clan.

Far better to declare the constant NO_ERROR and the packages SIEMENS_S5
and CRANE. Then CRANE_NO_ERROR or CRANE.NO_ERROR does not have more
characters and avoid to have a extended visibility.

I've never understood why people just put use everywhere and most often
at the top of the unit. This gives visibility to the whole unit plus all
the children. It is then harder to refactor the code as it is quite
difficult to see what is actually used and where.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

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

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

Re: Your wish list for Ada 202X

[J-P. Rosen]

Le 23/04/2014 19:39, Dmitry A. Kazakov a écrit :
> Furthermore, the formal declarations above is nothing but a poor man's
> description of an interface, ADT + operations (Image, ":=", "=", "/=" etc).

I won't argue with that. We know that you (and many people, no blaming
intended) see everything through inheritance. Other people (myself,
Randy f.e.) use inheritance in rare cases, only when it is the right
tool for a certain problem.

Generics have also benefits over interfaces, especially since you can
match any formal with any actual, while interfaces impose functions to
have the same name to match. Just one example.

So please consider (as my experience showed very often) that different
people have different ways of thinking. Some think naturally with
classification, others with composition. I don't know if it's related to
being right- or left-brained, it's possible. Ada offers support for
both, which is nice. Please just don't assume that your way of thinking
is the only "right" one.

-- 
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: Your wish list for Ada 202X

[J-P. Rosen]

Le 23/04/2014 23:29, Pascal Obry a écrit :
> I fully agree. I'm also in the "no use" clan.
I am not, but see below

> Far better to declare the constant NO_ERROR and the packages SIEMENS_S5
> and CRANE. Then CRANE_NO_ERROR or CRANE.NO_ERROR does not have more
> characters and avoid to have a extended visibility.
Having a "use" clause does not prevent to use a full name when one
thinks it is more readable. I do that all the time.

> I've never understood why people just put use everywhere and most often
> at the top of the unit. This gives visibility to the whole unit plus all
> the children. It is then harder to refactor the code as it is quite
> difficult to see what is actually used and where.
Sure. Actually, the carefull separation between "with" and "use" has
been designed to allow opening visibility just when and where you need
access to the content. Putting "use" on top of the unit defeats the very
purpose of the "use" clause.

"use" clauses are very helpful and make code a lot more readable,
provided they are restricted to the innermost context where they are
useful (and of course, you have an AdaControl rule to enforce that ;-) ).

-- 
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: Your wish list for Ada 202X

[Shark8]

On 23-Apr-14 16:00, J-P. Rosen wrote:
>
> Actually, the carefull separation between "with" and "use" has been
> designed to allow opening visibility just when and where you need
> access to the content. Putting "use" on top of the unit defeats the
> very purpose of the "use" clause.

I'm going to disagree, slightly; putting a use clause at the top of the 
unit can certainly be valid -- consider using a thick-binding hierarchy, 
to a library that you're using to implement functionality X -- since 
your writing to that binding it is perfectly valid to USE it. (And since 
you're writing specifically to that binding there's little sense in not 
doing it -- though, to be fair, you can make it so that the structure of 
your application is independent of the library via a "layered" 
approach... then using a different lib is simply writing to the 
application/binding interface you already have.)

Another reason is uniformity -- if you have a unit that's going to be 
using a lot of the operations from different units you can use them all 
and keep things uniform:

With
Ada.Integer_IO,
Ada.Text_IO,
Some_Lib.Text_IO,
Some_Lib.Types;

Use
Ada.Integer_IO,
Ada.Text_IO,
Some_Lib.Text_IO;

-- Library-Level Put
Procedure Put( Input : Some_Lib.Types.Some_Record ) si
begin
   Put( "Integer-Field:" );
   Put( Input.Integer_Field );
   New_Line;
   Put( "Name:" );
   Put( Input.Name );
   New_Line;
   --... and so on.
end Library_Level_Put;

> "use" clauses are very helpful and make code a lot more readable,
> provided they are restricted to the innermost context where they are
> useful (and of course, you have an AdaControl rule to enforce that ;-) ).

I fully agree that they are useful/helpful.

Re: Your wish list for Ada 202X

[J-P. Rosen]

Le 24/04/2014 01:48, Shark8 a écrit :
> I'm going to disagree, slightly; putting a use clause at the top of the
> unit can certainly be valid -- consider [...]
Sure, but in theses cases I prefer to put the use clause right at the
beginning of the declarative part than as a context clause.

The only difference it that the use does not apply to other context
clauses - no big deal, and it makes the programming rule more uniform.

-- 
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: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Wed, 23 Apr 2014 15:28:27 -0600, Shark8 wrote:

> On 23-Apr-14 14:00, Dmitry A. Kazakov wrote:
>> On Wed, 23 Apr 2014 13:43:19 -0600, Shark8 wrote:
>>
>>> On 23-Apr-14 01:45, Dmitry A. Kazakov wrote:
>>>> In the case of files there already is such stick object: /dev/null.
>>>
>>> I think there's a problem with that assertion
>>>> C:\Programming\Projects\SiennaSCL\src>cd /dev/null
>>>> The system cannot find the path specified.
>>>
>>> See?
>>
>> Path /= File
> 
> Not much different:

Decisively different.

It would be trivial to implement Null_File_Type, provided there were
Root_File_Type. Alas, non-tagged File_Type is Ada 83 heritage.

If you don't mind being GNAT-locked, you can implement GNAT-specific
Null_File of File_Type on top of GNAT implementation.

For stream I/O everything is here. Root_Stream_Type is tagged.

type Null_Stream_Type is new Root_Stream_Type with null record;
overriding procedure Read ...
overriding procedure Write ...

Null_Stream : Null_Stream_Type;

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

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Wed, 23 Apr 2014 23:40:27 +0200, J-P. Rosen wrote:

> Generics have also benefits over interfaces, especially since you can
> match any formal with any actual, while interfaces impose functions to
> have the same name to match. Just one example.

Yes, they are matched by structure. I don't see it as a benefit. I see it
as a hazard.
 
> So please consider (as my experience showed very often) that different
> people have different ways of thinking. Some think naturally with
> classification, others with composition. I don't know if it's related to
> being right- or left-brained, it's possible. Ada offers support for
> both, which is nice. Please just don't assume that your way of thinking
> is the only "right" one.

And extending your argument (to so to say "cultural relativism") on the
discussion on Ada vs. C. People, let's call them "top-brained", would claim
that Ada were not any better than C. C would be for top-brained. Ada would
for bottom-brained... (:-))

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

Re: Your wish list for Ada 202X

[G.B.]

On 23.04.14 21:48, Shark8 wrote:
> On 23-Apr-14 06:55, björn lundin wrote:
>>
>> I'd like V'Img to be standard ada like T'Image(V);
>> As in the gnat implementation
>
> I'd rather get a V'Type attribute; it would effectively solve your
> problem here as V'Img would be equivalent to:
>      V'Type'Image( V )
>
> This would also give us a bit more functionality rather than simply
> elevating a common case into the standard..

The real motivation for 'Img is debugging.

But few Ada programmers know how to operate a good,
programmable debugger.

Fix that.

Re: Your wish list for Ada 202X

[björn lundin]

>>One of the best thing with Ada05 was the approval of object.verb notation.

>Ada 2012 adds "use all type" with essentially the same semantics as
>object.verb notation. If you have untagged types, especially enumerations, I
>strongly suggest using that. (Since it only makes overloadable entities
>visible, it doesn't have the maintenance hazard unless the profiles match --  
>in which case you have a design problem.) 

Interesting. I did not know. I'll look into that

/Björn

Re: Your wish list for Ada 202X

[björn lundin]

Den onsdagen den 23:e april 2014 kl. 22:14:11 UTC+2 skrev Randy Brukardt:
> "Jeffrey Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
> > I don't think this is an issue of saving keystrokes, but a belief that the 
> > former is easier to read than the latter.
> 
> > With the addition of such notation for tagged types in 2007, exposure to 
> > this difference has become more widespread, so desiring V'Image rather 
> > than T'Image (V) may not be entirely about saving keystrokes.
> 
> 
> 
> It's not, it's mainly about wanting to avoid the effort to look up the exact 
> subtype of an object before writing 'Image. That wastes far more time than 
> the few keystrokes ever would take. (Which is redoubled if one has to find 
> out whether Image exists or some function has to be used instead.)


I agree. It is not just to save keystrokes, it is to simplify work.
And no-one here uses a debugger, so examining log-files is 
the way to find errors (around here anyway).
Debugging does not help when you wan't to examine why something happend or did not happen at a running site.

Logfiles do. If they contain the correct amount of logging.

'Img or 'Image would encourage more people to log stuff they perhaps do
not know that they need to log. 
And it is a pain if you want to log a record, with many separate types,
where the types are defined in several separate files.

Varible'img or Varaible'Image would make life easier for me

/Björn

Re: Your wish list for Ada 202X

[J-P. Rosen]

Le 24/04/2014 09:42, Dmitry A. Kazakov a écrit :
> People, let's call them "top-brained", would claim
> that Ada were not any better than C. C would be for top-brained. Ada would
> for bottom-brained... (:-)
Or better, as Dijkstra put it, small-brained... ;-)

-- 
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: Your wish list for Ada 202X

[björn lundin]

Den onsdagen den 23:e april 2014 kl. 22:28:29 UTC+2 skrev Randy Brukardt:
> "björn lundin" <b.f.lundin@a.gmail.com> wrote in message 
> news:63812656-3d79-4330-8b02-1836f3669b00@googlegroups.com...
> 
> That would be a very weird restriction, as subtype'Image is defined for all 
> scalar types (including float and fixed types).

Hmm, yes. But that comment was due to me misreading/misinterpreting Dmitrys 
answer with ambiguty for float values. 
So yes, it would be a weird restriction.
My thought was to have it as a plain shortcut to 
standard Ada's Type(Variable)'Image 
or gnat's Varable'Img

 
> Also note that the name would be "Image". GNAT uses "Img" because 
> language-defined attributes cannot be redefined, but they would have much 
> preferred to call it "Image". 

And that is totally ok with me. 'Img or 'Image on the varible is ok.
Id just like to get rid of quilifying the type, since the variable knows 
it's own type. That is it.

Then, to make log statements from records,
i propose that the programmer can point out what funtion to 
use for 'Image for this record.
makes it SOO much easier to throw in a log-line.

> If it's still required to stay in Ada 83, then adding Obj'Image to Ada 2020 
> isn't going to help any.

It is not. We compile using Ada05 flag (gnat)
We are migrating homebrew bindings to os-stuff via
e.g. Ada.Directories.
But a great chunk of the code is written in Ada83-style,
meaning very few tagged objects. They are of course of much later date.

> If it's able to be changed, then there are lot of 
> things that ought to be re-engineered if substantial work is going to be 
> done, and using Obj'Image is down in the noise.

Well, that is a money question. I cannot justify too radical changes,
without a firm return on investment paper.
Obj'Image will not cause redesign.
But sure, a complete redesign would be nice. But chances are 
that the decision will be : use C++ for the redesign, so 
I am a bit careful with that.

> 
> BTW, your proposal is a lot like the way stream attributes work, and that 
> has proven to be a massive can-of-worms. The entire mess about availability 
> of stream attributes comes about because of the ability of different views 
> to have a different ideaa of whether an attribute is legal or not. This is 
> not a trivial idea (nor is the one in AI12-0020-1).

I do not see the connection. Is it legal to use T'Image(Value) 
then why would not Value'Image be valid?
It seems (to me) that gnat did figure that out, with Value'Img


> 
> (Also note that providing 'Image implies providing a matching 'Value, just 
> like providing 'Write implies providing 'Read. 'Value is a lot messier than 
> 'Image, in general.)

I can see that. But I suggested Img/'Image only. Not 'Value.
 
 /Björn
 

Re: Your wish list for Ada 202X

[G.B.]

On 24.04.14 11:16, björn lundin wrote:
> Debugging does not help when you wan't to examine why something happend or did not happen at a running site.

A debugger can help examine a "running site",
depending on the qualities of the debugger and
on what the "running site" is offering to it.

> Logfiles do. If they contain the correct amount of logging.

Logfiles---very much part of my daily work---
require much more than a simple 'Img can achieve,
even if 'Img were made a primitive operation.

I need more flexibility than that. To match what I am
using every day, Ada would need to provide for data
introspection and for flexible output of this information.

For example, I need 'Img to produce a string that
some alread-opened logging facility will accept
as properly encoded. I also need different representations
to be produced in different locations in the program.

'Img is a "pragmatic" semi-solution, good for ASCII data,
hence good for traditional Western engineering, and
therefore set to stay forever, like C. What about this:

   X : Wide_Character := '€';  -- site handles currencies
   Y : Character := '¥';
...

   Put (Latin_1_File, X'Img);
   Put (UTF_8_File, Y'Img);

Re: Your wish list for Ada 202X

[björn lundin]

Den torsdagen den 24:e april 2014 kl. 13:33:00 UTC+2 skrev G.B.:
> On 24.04.14 11:16, bj�rn lundin wrote:
> > Debugging does not help when you wan't to examine why something happend or did not happen at a running site.
> 
> A debugger can help examine a "running site",
> depending on the qualities of the debugger and
> on what the "running site" is offering to it.

Perhaps you are right about that. Still, it does not change
the validy of ME wanting a shoutcut for Type(varible)'image

> > Logfiles do. If they contain the correct amount of logging.
> Logfiles---very much part of my daily work---
> require much more than a simple 'Img can achieve,
> even if 'Img were made a primitive operation.

I guess
'depending on the qualities of the debugger and
 on what the "running site" is offering to it.'
works well here to if you change 'debugger' to 'logging'

It all depends. Here we run a business that uses logfiles
for tracing down problems on customer sites. It works well
for us. If it does no work for you - then too bad.

> I need more flexibility than that. To match what I am
> using every day, Ada would need to provide for data
> introspection and for flexible output of this information.

YOU might need more flexibility. I don't . I speak for myself 
in my wish/proposal.

> 
> For example, I need 'Img to produce a string that
> some alread-opened logging facility will accept
> as properly encoded. I also need different representations
> to be produced in different locations in the program.

Then I suggest you improve my wish/proposal about
makeing the progammer decide how to create the image.
I suggested a userdefined function. 
Where is your proposal?

> 'Img is a "pragmatic" semi-solution, good for ASCII data,

and good for me too.

> hence good for traditional Western engineering, and
> therefore set to stay forever, like C. What about this:
> 
>    X : Wide_Character := '�';  -- site handles currencies
>    Y : Character := '�';
> ...
> 
>    Put (Latin_1_File, X'Img);
>    Put (UTF_8_File, Y'Img);


Looks like you have a start for a proposal ...

/Björn

Re: Your wish list for Ada 202X

[G.B.]

On 24.04.14 14:11, björn lundin wrote:
> Then I suggest you improve my wish/proposal about
> makeing the progammer decide how to create the image.

In this logging situation I'd want

(a) what Bub Duff has hinted at, Java's I/O layering, for
   modernizing Ada's Put operations,

(b) what Dmitry Kazakov keeps suggesting: MD, or, alternatively,
    what J.-P. Rosen has just said about generics.

I have used Image as a primitive operation, and this worked
for me, to some extent, but I'm not sure it could work for Ada.
Programmers will have to write and rewrite Image, while they
might expect something to be present already.
'Img works well for AdaCore it seems, like C works well for the
majority of embedded systems, in a similar fashion.

Re: Your wish list for Ada 202X

[Shark8]

On 24-Apr-14 01:30, Dmitry A. Kazakov wrote:
> On Wed, 23 Apr 2014 15:28:27 -0600, Shark8 wrote:
>
>> On 23-Apr-14 14:00, Dmitry A. Kazakov wrote:
>>> On Wed, 23 Apr 2014 13:43:19 -0600, Shark8 wrote:
>>>
>>>> On 23-Apr-14 01:45, Dmitry A. Kazakov wrote:
>>>>> In the case of files there already is such stick object: /dev/null.
>>>>
>>>> I think there's a problem with that assertion
>>>>> C:\Programming\Projects\SiennaSCL\src>cd /dev/null
>>>>> The system cannot find the path specified.
>>>>
>>>> See?
>>>
>>> Path /= File
>>
>> Not much different:
>
> Decisively different.
>
> It would be trivial to implement Null_File_Type, provided there were
> Root_File_Type. Alas, non-tagged File_Type is Ada 83 heritage.
>
> If you don't mind being GNAT-locked, you can implement GNAT-specific
> Null_File of File_Type on top of GNAT implementation.
>
> For stream I/O everything is here. Root_Stream_Type is tagged.
>
> type Null_Stream_Type is new Root_Stream_Type with null record;
> overriding procedure Read ...
> overriding procedure Write ...
>
> Null_Stream : Null_Stream_Type;
>

You're completely missing the point -- it wasn't about a null-file, it 
was about assuming all computers are *nix.

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Thu, 24 Apr 2014 09:20:52 -0600, Shark8 wrote:

> On 24-Apr-14 01:30, Dmitry A. Kazakov wrote:
>> On Wed, 23 Apr 2014 15:28:27 -0600, Shark8 wrote:
>>
>>> On 23-Apr-14 14:00, Dmitry A. Kazakov wrote:
>>>> On Wed, 23 Apr 2014 13:43:19 -0600, Shark8 wrote:
>>>>
>>>>> On 23-Apr-14 01:45, Dmitry A. Kazakov wrote:
>>>>>> In the case of files there already is such stick object: /dev/null.
>>>>>
>>>>> I think there's a problem with that assertion
>>>>>> C:\Programming\Projects\SiennaSCL\src>cd /dev/null
>>>>>> The system cannot find the path specified.
>>>>>
>>>>> See?
>>>>
>>>> Path /= File
>>>
>>> Not much different:
>>
>> Decisively different.
>>
>> It would be trivial to implement Null_File_Type, provided there were
>> Root_File_Type. Alas, non-tagged File_Type is Ada 83 heritage.
>>
>> If you don't mind being GNAT-locked, you can implement GNAT-specific
>> Null_File of File_Type on top of GNAT implementation.
>>
>> For stream I/O everything is here. Root_Stream_Type is tagged.
>>
>> type Null_Stream_Type is new Root_Stream_Type with null record;
>> overriding procedure Read ...
>> overriding procedure Write ...
>>
>> Null_Stream : Null_Stream_Type;
> 
> You're completely missing the point -- it wasn't about a null-file, it 
> was about assuming all computers are *nix.

Where was this assumed? /dev/null was an example of a file which could
serve the purpose. 

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

Re: Your wish list for Ada 202X

[Shark8]

On 24-Apr-14 10:19, Dmitry A. Kazakov wrote:
> On Thu, 24 Apr 2014 09:20:52 -0600, Shark8 wrote:
>
>> On 24-Apr-14 01:30, Dmitry A. Kazakov wrote:
>>> On Wed, 23 Apr 2014 15:28:27 -0600, Shark8 wrote:
>>>
>>>> On 23-Apr-14 14:00, Dmitry A. Kazakov wrote:
>>>>> On Wed, 23 Apr 2014 13:43:19 -0600, Shark8 wrote:
>>>>>
>>>>>> On 23-Apr-14 01:45, Dmitry A. Kazakov wrote:
>>>>>>> In the case of files there already is such stick object: /dev/null.
>>>>>>
>>>>>> I think there's a problem with that assertion
>>>>>>> C:\Programming\Projects\SiennaSCL\src>cd /dev/null
>>>>>>> The system cannot find the path specified.
>>>>>>
>>>>>> See?
>>>>>
>>>>> Path /= File
>>>>
>>>> Not much different:
>>>
>>> Decisively different.
>>>
>>> It would be trivial to implement Null_File_Type, provided there were
>>> Root_File_Type. Alas, non-tagged File_Type is Ada 83 heritage.
>>>
>>> If you don't mind being GNAT-locked, you can implement GNAT-specific
>>> Null_File of File_Type on top of GNAT implementation.
>>>
>>> For stream I/O everything is here. Root_Stream_Type is tagged.
>>>
>>> type Null_Stream_Type is new Root_Stream_Type with null record;
>>> overriding procedure Read ...
>>> overriding procedure Write ...
>>>
>>> Null_Stream : Null_Stream_Type;
>>
>> You're completely missing the point -- it wasn't about a null-file, it
>> was about assuming all computers are *nix.
>
> Where was this assumed? /dev/null was an example of a file which could
> serve the purpose.
>

The assumption is implicit in your example:
__/dev/null__, see?

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Thu, 24 Apr 2014 10:50:49 -0600, Shark8 wrote:

> On 24-Apr-14 10:19, Dmitry A. Kazakov wrote:
>> On Thu, 24 Apr 2014 09:20:52 -0600, Shark8 wrote:
>>
>>> On 24-Apr-14 01:30, Dmitry A. Kazakov wrote:
>>>> On Wed, 23 Apr 2014 15:28:27 -0600, Shark8 wrote:
>>>>
>>>>> On 23-Apr-14 14:00, Dmitry A. Kazakov wrote:
>>>>>> On Wed, 23 Apr 2014 13:43:19 -0600, Shark8 wrote:
>>>>>>
>>>>>>> On 23-Apr-14 01:45, Dmitry A. Kazakov wrote:
>>>>>>>> In the case of files there already is such stick object: /dev/null.
>>>>>>>
>>>>>>> I think there's a problem with that assertion
>>>>>>>> C:\Programming\Projects\SiennaSCL\src>cd /dev/null
>>>>>>>> The system cannot find the path specified.
>>>>>>>
>>>>>>> See?
>>>>>>
>>>>>> Path /= File
>>>>>
>>>>> Not much different:
>>>>
>>>> Decisively different.
>>>>
>>>> It would be trivial to implement Null_File_Type, provided there were
>>>> Root_File_Type. Alas, non-tagged File_Type is Ada 83 heritage.
>>>>
>>>> If you don't mind being GNAT-locked, you can implement GNAT-specific
>>>> Null_File of File_Type on top of GNAT implementation.
>>>>
>>>> For stream I/O everything is here. Root_Stream_Type is tagged.
>>>>
>>>> type Null_Stream_Type is new Root_Stream_Type with null record;
>>>> overriding procedure Read ...
>>>> overriding procedure Write ...
>>>>
>>>> Null_Stream : Null_Stream_Type;
>>>
>>> You're completely missing the point -- it wasn't about a null-file, it
>>> was about assuming all computers are *nix.
>>
>> Where was this assumed? /dev/null was an example of a file which could
>> serve the purpose.
> 
> The assumption is implicit in your example:
> __/dev/null__, see?

Nope.

"
ex·am·ple  (ĭg-zăm′pəl)

n.

1. One that is representative of a group as a whole: the squirrel, an
example of a rodent; introduced each new word with examples of its use."

Here is no assumption that all rodents live on trees, though some squirrels
do.

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

Re: Your wish list for Ada 202X

[Randy Brukardt]

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

"björn lundin" <b.f.lundin@gmail.com> wrote in message 
news:cdd237eb-7cb1-404f-b18e-695cef9f2f73@googlegroups.com...
Den onsdagen den 23:e april 2014 kl. 22:28:29 UTC+2 skrev Randy Brukardt:
...
>> BTW, your proposal is a lot like the way stream attributes work, and that
>> has proven to be a massive can-of-worms. The entire mess about 
>> availability
>> of stream attributes comes about because of the ability of different 
>> views
>> to have a different ideaa of whether an attribute is legal or not. This 
>> is
>> not a trivial idea (nor is the one in AI12-0020-1).
>
>I do not see the connection. Is it legal to use T'Image(Value)
>then why would not Value'Image be valid?
>It seems (to me) that gnat did figure that out, with Value'Img

Sorry, I was talking about the idea of user-defined 'Image for record types.

That's currently not legal for T'Image(Obj), so it's not going to be legal 
for Obj'Image either.

To make it legal is somewhat a can of worms, because visibility gets 
entwined -- especially if any automatic composition is provides (something I 
would like to see, otherwise there is little need for it to be an 
attribute).

>> (Also note that providing 'Image implies providing a matching 'Value, 
>> just
>> like providing 'Write implies providing 'Read. 'Value is a lot messier 
>> than
>> 'Image, in general.)
>
>I can see that. But I suggested Img/'Image only. Not 'Value.

If one supplies user-defined 'Image, we'd pretty much have to support 
user-defined 'Value as well. (You wouldn't have to use it, of course). It's 
rare that only one way I/O is needed. Of course, this ups the effort for 
composition a lot. I don't think I could support user-defined 'Image without 
user-defined 'Value -- it seems asymetric to me.

                       Randy.

Re: Your wish list for Ada 202X

[Randy Brukardt]

"G.B." <rm-dash-bau-haus@dash.futureapps.de> wrote in message 
news:5358d373$0$6703$9b4e6d93@newsspool2.arcor-online.net...
> On 23.04.14 21:48, Shark8 wrote:
...
> But few Ada programmers know how to operate a good,
> programmable debugger.

That would require such a thing to exist. I'd suggest that it is one of 
those cases where you can choose any two of the three. :-)

                    Randy.

Re: Your wish list for Ada 202X

[Shark8]

On 24-Apr-14 19:22, Randy Brukardt wrote:
>
> If one supplies user-defined 'Image, we'd pretty much have to support
> user-defined 'Value as well. (You wouldn't have to use it, of course). It's
> rare that only one way I/O is needed. Of course, this ups the effort for
> composition a lot. I don't think I could support user-defined 'Image without
> user-defined 'Value -- it seems asymetric to me.

At that point it sounds like we're getting into the Stream attributes -- 
though it would be nice to have a secondary IO channel. The distinction 
is, of course, that user-defined 'Image/'Value would be more geared 
towards text rather than the generality of streams.

Re: Your wish list for Ada 202X

[Dmitry A. Kazakov]

On Thu, 24 Apr 2014 20:19:22 -0600, Shark8 wrote:

> On 24-Apr-14 19:22, Randy Brukardt wrote:
>>
>> If one supplies user-defined 'Image, we'd pretty much have to support
>> user-defined 'Value as well. (You wouldn't have to use it, of course). It's
>> rare that only one way I/O is needed. Of course, this ups the effort for
>> composition a lot. I don't think I could support user-defined 'Image without
>> user-defined 'Value -- it seems asymetric to me.
> 
> At that point it sounds like we're getting into the Stream attributes -- 
> though it would be nice to have a secondary IO channel. The distinction 
> is, of course, that user-defined 'Image/'Value would be more geared 
> towards text rather than the generality of streams.

Interestingly that it is already here (A.12.2):

   package Ada.Text_IO.Text_Streams   

Though, there is a big BUT. Since stream attributes rather emulate multiple
dispatch [*] than do full MD, we cannot have your second channel which
would make

   Integer'Output (S, X);

formatting X differently when S is a text file (or a string stream) from
when S is a socket.

-----------
* Stream attributes semantically do cascaded dispatch, first on the I/O
item type, then on the stream type. This precludes stream-dependent
formatting.

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

Re: Your wish list for Ada 202X

[Tero Koskinen]

26.3.2014 23:06, Randy Brukardt wrote:
> Commenting here is precisely the problem. Most of the user contacts
> that the ARG has is third-hand at best. (Combating that is one of
> the reasons I hang out here.) We really don't have the clear of an
> idea of what other Ada users want. I know I draw on my own experience
> far more than probably is healthy.
>
> Moreover, we've been asking for years for users to show us the
> problems that they cannot solve with Ada (now Ada 2012), so that we
> can look at possible solutions.

Not sure have it been proposed anywhere, but a common ABI (application
binary interface) for the most popular platforms (32-bit ARM Linux,
64-bit x86_64/amd64 Linux, 32-bit i386 Windows, 64-bit x86_64/amd64
Windows) would be nice. This way I could use binary libraries generated
by one Ada compiler (version) with another Ada compiler (version)
without providing full sources (or recompilation).

Another thing is the lack of "modern" general purpose libraries for
net/www stuff, embedded devices, various algorithms/data structures,
etc. Those libraries won't necessarily need to be part of the standard.
It is enough if they are just somehow freely available without extra cost.

> Randy Brukardt, ARG Editor.

Yours,
  Tero

Re: Your wish list for Ada 202X

[Dan'l Miller]

2014/04/29 09:26 Tero Koskinen:
> 26.3.2014 23:06, Randy Brukardt wrote: 
> > Commenting here is precisely the problem. Most of the user contacts 
> > that the ARG has is third-hand at best. (Combating that is one of 
> > the reasons I hang out here.) We really don't have the clear of an 
> > idea of what other Ada users want. I know I draw on my own experience 
> > far more than probably is healthy. 
> > 
> > Moreover, we've been asking for years for users to show us the 
> > problems that they cannot solve with Ada (now Ada 2012), so that we 
> > can look at possible solutions. 

> Not sure have it been proposed anywhere, but a common ABI (application 
> binary interface) for the most popular platforms (32-bit ARM Linux, 
> 64-bit x86_64/amd64 Linux, 32-bit i386 Windows, 64-bit x86_64/amd64 
> Windows) would be nice. This way I could use binary libraries generated 
> by one Ada compiler (version) with another Ada compiler (version) 
> without providing full sources (or recompilation). 

This problemspace that Tero Koskinen mentions needs either a common ABI or better (i.e., portable beyond GNAT) compile-time code generation.  C and GNAT rely on conditional compilation to select at compile-time alternative (run-time) source-code.  C++ has been relying on poor-man's functional programming via meta template programming.  Both of these are kludges for how the compile-time code-generation problemspace should be solved.  Non-gnatprep Ada has been recommending alternative selection of entire child packages as a partial solution to this problemspace.  What I envision as a robust complete solution to this problemspace is a revival of something like a.app from the 1980s/1990s Ada combined with multi-stage programming from MetaOCaml, where a Turing-complete imperative (not functional programming) Ada interpreter runs at compile time generating/selecting the next stage of(, say, run-time) source code (in 2-stage programming), which is then compiled by the Ada compiler.  And okay, if not a full-fledged compile-time Ada interpreter within the Ada compiler, then drastic expansion somehow of Ada's (currently coarse-grained) selection of (whole) child packages on a per-architecture (or per-underlying-infrastructure, e.g., GUI library, GPU library, OS API) basis.  C++'s concept-maps for the currently-postponed concepts might or might not be applicable here to map common upper-layer identifiers to a diversity of lower-layer identifiers that fan out to multiple underlying infrastructures (i.e., various software infrastructures and/or various hardware architectures).  Or a Turing-complete a.app-successor might be the better full solution than C++'s concept maps for such adaptation of single portable upper layers of Ada source code to a diversity of unruly infrastructures underneath.

Re: Your wish list for Ada 202X

[Simon Clubley]

On 2014-04-29, Tero Koskinen <tero.koskinen@iki.fi> wrote:
>
> Not sure have it been proposed anywhere, but a common ABI (application
> binary interface) for the most popular platforms (32-bit ARM Linux,
> 64-bit x86_64/amd64 Linux, 32-bit i386 Windows, 64-bit x86_64/amd64
> Windows) would be nice. This way I could use binary libraries generated
> by one Ada compiler (version) with another Ada compiler (version)
> without providing full sources (or recompilation).
>

That is simply not possible.

Your list above includes different architectures (ARM and x86) with
totally different instruction sets. The only way to support both
architectures in the way you want would be fat object modules or
fat libraries which contain both versions of a object module and
that doesn't even address the issues below.

However, even if you restrict yourself to x86/x86_64 then how do you
handle the 32 bit versus 64 bit pointer size issue ? Do you only
generate code for 32 bit x86 ?

However, even if you restrict yourself to 32 bit x86 then those object
modules will still have operating system specific components to them.

How do you handle architecture/operating system specific issues such as
exceptions ?

Simon.

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

Re: Your wish list for Ada 202X

[Tero Koskinen]

29.4.2014 20:10, Simon Clubley wrote:
> On 2014-04-29, Tero Koskinen <tero.koskinen@iki.fi> wrote:
>>
>> Not sure have it been proposed anywhere, but a common ABI (application
>> binary interface) for the most popular platforms (32-bit ARM Linux,
>> 64-bit x86_64/amd64 Linux, 32-bit i386 Windows, 64-bit x86_64/amd64
>> Windows) would be nice. This way I could use binary libraries generated
>> by one Ada compiler (version) with another Ada compiler (version)
>> without providing full sources (or recompilation).
>>
>
> That is simply not possible.
>
> Your list above includes different architectures (ARM and x86) with
> totally different instruction sets.

I meant a separate ABI for each platform. But for example, all
Ada compilers targeting 32-bit ARM Linux should implement same ABI.

In theory it should be relatively easy to say "all must use same ABI
as gnat 4.9 currently uses".

>
> Simon.
>

Yours,
  Tero

Re: Your wish list for Ada 202X

[Simon Clubley]

On 2014-04-29, Tero Koskinen <tero.koskinen@iki.fi> wrote:
> 29.4.2014 20:10, Simon Clubley wrote:
>> On 2014-04-29, Tero Koskinen <tero.koskinen@iki.fi> wrote:
>>>
>>> Not sure have it been proposed anywhere, but a common ABI (application
>>> binary interface) for the most popular platforms (32-bit ARM Linux,
>>> 64-bit x86_64/amd64 Linux, 32-bit i386 Windows, 64-bit x86_64/amd64
>>> Windows) would be nice. This way I could use binary libraries generated
>>> by one Ada compiler (version) with another Ada compiler (version)
>>> without providing full sources (or recompilation).
>>>
>>
>> That is simply not possible.
>>
>> Your list above includes different architectures (ARM and x86) with
>> totally different instruction sets.
>
> I meant a separate ABI for each platform. But for example, all
> Ada compilers targeting 32-bit ARM Linux should implement same ABI.
>

Yes, that makes more sense. Sorry. :-)

> In theory it should be relatively easy to say "all must use same ABI
> as gnat 4.9 currently uses".
>

There's nothing easy about that unfortunately.

There are multiple ABI levels here. Not only do you have the low level
OS specific ABI, you also have a higher level Ada specific ABI (for
tasking, exceptions, etc) with calls into the GNAT run time library.

All of this would need to be formally documented in great detail so that,
say, exceptions from code compiled using compiler A could pass a Ada
exception up to a caller compiled using compiler B.

Similar comments apply for other things, like tasking, which need runtime
library support.

Simon.

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