Community Input for the Maintenance and Revision of the Ada Programming Language

Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

ISO/IEC JTC 1/SC 22/WG 9 (WG 9) is responsible for the maintenance?and 
revision of the Ada Programming Language and associated standards and 
technical reports. As part of the language?maintenance activity, WG 9 has 
established a group of Ada experts as the Ada Rapporteur Group (ARG). The 
ARG receives input from the Ada?community at large to consider for inclusion 
in revision to the Ada programming language standard. The WG 9 has produced 
a number of?revisions to the language in accordance with ISO policy and 
to?address the evolution of technology (Ada 83, Ada 95, Ada 2005, Ada 2012).

Presently, the ARG is beginning work on a revision to Ada 2012 so?that ISO 
standardization of the new version can be completed by 2020. This is a 
relatively short horizon, but it ensures that the?language continues to 
evolve, and at the same time requires that the?changes to the language are 
evolutionary and do not present an undue?implementation burden on existing 
compilers and users.

WG 9 requests the Ada community to submit enhancements to be considered for 
inclusion in the next?revision of Ada. These should be sent to 
ada-comment@ada-auth.org as described in the Ada Reference Manual 
Introduction 
(http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-0-3.html#p58). For 
enhancement requests, it is very important to describe the programming 
problem?and why the Ada 2012 solution is complex, expensive, or impossible. 
A detailed description of a specific enhancement is welcome but not 
necessarily?required. The goal of the ARG is to solve as many 
programming?problems as possible with new/enhanced Ada features that fit 
into?the existing Ada framework. Thus the ARG will be looking at 
the?language as a whole, which may suggest alternative solutions to 
the?problem posed by an enhancement request. For a more detailed discussion, 
the guidelines presented?for the Ada 2005 revision (see
http://archive.adaic.com/news/pressrelease/call4apis.html) can be?used as 
the ARG requirements are little changed.

WG9 accepts enhancement requests at any time. To be considered for inclusion 
in the next revision of Ada, enhancement requests must be received by 15 
January 2018.?Suggestions received after that date may be considered if 
they?relate to topics already under development; others will be?considered 
only for future versions of Ada.

WG 9 has directed the ARG to focus its work on three areas of?particular 
interest to the Ada community: additional facilities for?multi-core and 
multithreaded programming, improved facilities for?program correctness, and 
enhanced container libraries. There are?numerous proposed enhancements in 
these and other areas. Some of?these proposals originated with members of 
the ARG, and others from?members of the community at large. The interested 
reader can find the current state of these at 
http://www.ada-auth.org/AI12-SUMMARY.HTML.

WG 9 encourages members of the Ada community at large to use the?guidelines 
outlined above to provide input to WG 9 and the ARG for?needed revisions and 
upgrades to the Ada programming language. 

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Lucretia]

I've added a link to /r/Compilers and /r/ProgrammingLanguages so that some people other than Ada people will see it.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Lucretia]

On Thursday, 3 August 2017 13:06:23 UTC+1, Lucretia  wrote:
> I've added a link to /r/Compilers and /r/ProgrammingLanguages so that some people other than Ada people will see it.

Also posted the above to comp.compilers.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Luke A. Guest]

Additions I'd like to see:

1) endian aspects.
2) full Unicode support including sorting, character db, regexps, bounded
and unbounded need, iterators for code points, graphème clusters, word
boundaries, bidi, etc.
3) cross platform GUI.
4) multiple return types:

  function Blah return Integer, Float; 

As an example.

5) Lambdas for the people looking for new (i.e. Old) trendy features.

6) support for offloading to gpu's.
7) memory mapped streams.
8) networking support packages.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Luke A. Guest]

Luke A. Guest <laguest@archeia.com> wrote:
> Additions I'd like to see:

> 8) networking support packages.
> 

Basically stuff every other language has by default. It's this stuff that
makes or breaks a language now. Make it easy for people to develop desktop
apps from the get go. People don't want to be stuck making console apps,
they want to see stuff visually. Ada is a better Pascal, yet the seriously
limited Pascal has been extended to death and can do more out of the box
now, even though the language is crap by comparison. See Lazarus / Delphi.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Lucretia]

On Wednesday, 9 August 2017 22:12:34 UTC+1, Luke A. Guest  wrote:
> Luke A. Guest <me@me dot com> wrote:
> > Additions I'd like to see:
> 
> > 8) networking support packages.
> > 

9) Update the Interfaces.C package to include new types in the newer C specs.

10) Standardised C++ binding, what the compiler does underneath shouldn't matter as long as the interface specifying the binding is consistent and has a way to add platform specific changes, i.e. DLL binding for Windows, standard binding for other OSes.

11) Including bindings to other languages that are starting to appear?

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-08-10 16:43, Lucretia wrote:

> 10) Standardised C++ binding, what the compiler does underneath
> shouldn't matter as long as the interface specifying the binding is
> consistent and has a way to add platform specific changes, i.e. DLL
> binding for Windows, standard binding for other OSes.

Is that even possible? I used to make a C++ library (with some 
templates) compilable by both Borland C++ and Visual Studio C++. That 
was fun!

I had a few cases when I needed to deal with C++ from Ada. It did not 
take long time to understand that this was far beyond a mere mortal like 
me. Luckily it was possible to put all that mess into a custom DLL with 
plain C interface which I used instead.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:omht83$p98$1@gioia.aioe.org...
> On 2017-08-10 16:43, Lucretia wrote:
>
>> 10) Standardised C++ binding, what the compiler does underneath
>> shouldn't matter as long as the interface specifying the binding is
>> consistent and has a way to add platform specific changes, i.e. DLL
>> binding for Windows, standard binding for other OSes.
>
> Is that even possible? I used to make a C++ library (with some templates) 
> compilable by both Borland C++ and Visual Studio C++. That was fun!

The ARG tried to think about this once. And the result was to change the 
existing B.3's title and introduction to include "C++" -- to make it clear 
that these facilities are useful for interfacing to C++ as well. We didn't 
think it made sense in any way to try to do more (massive complexity both 
for the implementation and for the user). As always, we considered that we 
might standardize something vendors came up with, but they didn't come up 
with anything suitable. Has anything changed?

                                               Randy.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

"Lucretia" <laguest9000@googlemail.com> wrote in message 
news:085872f2-2876-401d-9661-4ca5c82bb7ea@googlegroups.com...
...
> 9) Update the Interfaces.C package to include new types in the newer C 
> specs.

That most likely will get done at some point before Ada 2020 gets done. But 
it might be best to send a comment so it gets an agenda item; it would be 
useful to know which new types you find relevant.

...
> 11) Including bindings to other languages that are starting to appear?

As I previously noted, we can only reference languages that have ISO/IEC 
standards (there might be a few other kinds of standards that are 
acceptable, but most aren't). That reduces the universe of what we could do 
quite a bit.

It's the same reason that we can't name Windows or Linux in the standard, 
which is why Ada.Directories.Information is defined as 
"implementation-defined" and Windows and Linux versions are given in an AARM 
note.

Moral: not everything can be done in the language standard. You need an 
implementer focused on mobile applications if you're going to see much 
progress in that field. Etc. The downside of having one dominant vendor is 
that they're going to set the agenda in many ways, and that agenda is thus 
safety-critical embedded systems.

                                   Randy.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[G.B.]

On 11.08.17 03:24, Randy Brukardt wrote:
> The downside of having one dominant vendor is
> that they're going to set the agenda in many ways, and that agenda is thus
> safety-critical embedded systems.

As a corollary, the dominant vendors in the programming
tools market can create the illusion of their languages
being intrinsically bundled with their libraries, OSs,
and so on. In this way, a correlation can become a fixed
association in our minds.

Witness this thread. Swift per se is not tied to Cocoa;
Java per se is not tied to JVMs; C is not tied to either
microcontrollers or Unix; ... To what is Ada per se tied,
actually?

If any vendor can dominate a programming market, when
competitors are starving, then we know at least how
demand is responding to supply.

Or that Customers = Sheep.
Or that the company won't fire you for buying the dominator's.
Or that being a passive follower will pay.

Facilitating the negations of the above will facilitate
improvements to Ada.

Good luck!

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[G.B.]

On 09.08.17 23:08, Luke A. Guest wrote:

> 1) endian aspects.
> 2) full Unicode support including sorting, character db, regexps, bounded
> and unbounded need, iterators for code points, graphème clusters, word
> boundaries, bidi, etc.

Unicode support can be a joint effort without major investments of time
and money:
practically adressing Randy Brukardt's remark that this is going to
require politics, there is libiconv, the Unicode related designs done
for the Swift language, java.text.*, and so forth.

> 3) cross platform GUI.

Care to elaborate why? Having seen cross platform GUIs fail in all but
corporate surroundings, and possibly games, even then, new proprietary
libraries like Metal seem to entail non-portable program designs again.
A portable abstract design of UIs could be economically more promising.
It fits the OS's ways and customers like that. Also removes one layer
of politics, support, and software, at least in parts.

> 4) multiple return types:
>
>   function Blah return Integer, Float;

Should other parameters in the subprogram's profile be non-variant,
co-variant, or contra-variant, or just what the programmer specifies?

> As an example.
>
> 5) Lambdas for the people looking for new (i.e. Old) trendy features.

Would you want lambdas that can be returned, or assigned? Or just
lambdas that are unnamed expression_function-s of Ada 2012?

> 6) support for offloading to gpu's.
> 7) memory mapped streams.
> 8) networking support packages.

It seems as if C, the language and library, has very few of
these additions and yet C is a good choice for embedded needs
if judging by market share. How do C programmers port their
networking code from Unix to Windows? Could Ada support packages
provide convincing advantages (politics...) because of the language?

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Lucretia]

On Thursday, 10 August 2017 06:41:56 UTC+1, G.B.  wrote:
> On 09.08.17 23:08, Luke A. Guest wrote:
> 
> > 1) endian aspects.
> > 2) full Unicode support including sorting, character db, regexps, bounded
> > and unbounded need, iterators for code points, graphème clusters, word
> > boundaries, bidi, etc.
> 
> Unicode support can be a joint effort without major investments of time
> and money:
> practically adressing Randy Brukardt's remark that this is going to
> require politics, there is libiconv, the Unicode related designs done
> for the Swift language, java.text.*, and so forth.
> 
> > 3) cross platform GUI.
> 
> Care to elaborate why? Having seen cross platform GUIs fail in all but

I already explained in a previous post, the post does not just relate to 8 but to all my points.

> corporate surroundings, and possibly games, even then, new proprietary

In games, companies either use a third party UI or write their own, I know, because I used to work in games.

> libraries like Metal seem to entail non-portable program designs again.

See the Vulkan portability initiative https://www.khronos.org/blog/khronos-announces-the-vulkan-portability-initiative

> A portable abstract design of UIs could be economically more promising.
> It fits the OS's ways and customers like that. Also removes one layer
> of politics, support, and software, at least in parts.

This would be for desktop / mobile domains, not embedded. Remember that Ada was designed to replace all the languages the DoD were using for all application domains, not just embedded[1].

> > 4) multiple return types:
> >
> >   function Blah return Integer, Float;
> 
> Should other parameters in the subprogram's profile be non-variant,
> co-variant, or contra-variant, or just what the programmer specifies?

This is for the language designers to determine.
 
> > As an example.
> >
> > 5) Lambdas for the people looking for new (i.e. Old) trendy features.
> 
> Would you want lambdas that can be returned, or assigned? Or just
> lambdas that are unnamed expression_function-s of Ada 2012?

This is for the language designers to determine.

I know people want this, because I've seen this in this newsgroup.
 
> > 6) support for offloading to gpu's.
> > 7) memory mapped streams.
> > 8) networking support packages.
> 
> It seems as if C, the language and library, has very few of
> these additions and yet C is a good choice for embedded needs
> if judging by market share. How do C programmers port their
> networking code from Unix to Windows? Could Ada support packages
> provide convincing advantages (politics...) because of the language?

You can't really compare C and Ada, C is low-level, Ada is very high-level. C already has everything I've already noted, yes as third party libs, but other high-level languages have them in their standard library, this is what I'm talking about.

Again, you seem to be very myopic in that C and Ada are only used in embedded. I refer you back to [1] above. You seem to have forgotten this.

Windows has sockets, it also has other networking libs available, people just tend to create platform specific ports on top of those libs, Ada could do the same.

Don't you people want Ada to grow into more areas? I've seen people look at the language because it seemed interesting to them, then ask, "Does Ada have a GUI lib?" or "Does Ada have OpenGL?" or "Does Ada have DirectX?" etc. When they are told no, they leave never to return, because this is what they want in a language's runtime.

Seems to me you people only want Ada to stay hobbled in the embedded corner. If that's the case, I think it's time to start considering a new language, but there aren't any that have the features I want.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[J-P. Rosen]

Le 10/08/2017 à 16:41, Lucretia a écrit :
> I've seen people look at the language because it seemed interesting
> to them, then ask, "Does Ada have a GUI lib?" or "Does Ada have
> OpenGL?" or "Does Ada have DirectX?" etc. When they are told no, they
> leave never to return, because this is what they want in a language's
> runtime.

Why in the world would you answer "No" ? Here is how I deal with these
questions:

"Does Ada have a GUI lib?"
Sure, like other languages, we have interfaces to GTK, QT, Tcl/TK, Lua,
Python...

"Does Ada have OpenGL?"
Yes, see adaopengl on SourceForge

"Does Ada have DirectX?"
Yes, see DirectX binding to Ada on SourceForge

etc...

-- 
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: Community Input for the Maintenance and Revision of the Ada Programming Language

[Luke A. Guest]

J-P. Rosen <rosen@adalog.fr> wrote:
> Le 10/08/2017 à 16:41, Lucretia a écrit :
>> I've seen people look at the language because it seemed interesting
>> to them, then ask, "Does Ada have a GUI lib?" or "Does Ada have
>> OpenGL?" or "Does Ada have DirectX?" etc. When they are told no, they
>> leave never to return, because this is what they want in a language's
>> runtime.
> 
> Why in the world would you answer "No" ? Here is how I deal with these
> questions:

I ever said I said no. But the other answers people have given are as
follows:

> 
> "Does Ada have a GUI lib?"
> Sure, like other languages, we have interfaces to GTK, QT, Tcl/TK, Lua,
> Python...

GTK - horrible API
Qt - preprocessor 
Tcl/Tk - ancient
Lia and Python are not gui's

> "Does Ada have OpenGL?"
> Yes, see adaopengl on SourceForge

Only supports 2.1 and is dead

> "Does Ada have DirectX?"
> Yes, see DirectX binding to Ada on SourceForge
>

No idea on that one?

> etc...
> 

Etc

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-08-10 17:25, J-P. Rosen wrote:
> Le 10/08/2017 à 16:41, Lucretia a écrit :
>> I've seen people look at the language because it seemed interesting
>> to them, then ask, "Does Ada have a GUI lib?" or "Does Ada have
>> OpenGL?" or "Does Ada have DirectX?" etc. When they are told no, they
>> leave never to return, because this is what they want in a language's
>> runtime.
> 
> Why in the world would you answer "No" ? Here is how I deal with these
> questions:
> 
> "Does Ada have a GUI lib?"
> Sure, like other languages, we have interfaces to GTK, QT, Tcl/TK, Lua,
> Python...
> 
> "Does Ada have OpenGL?"
> Yes, see adaopengl on SourceForge
> 
> "Does Ada have DirectX?"
> Yes, see DirectX binding to Ada on SourceForge

The interfaces of these libraries follow the paradigms of the 
implementation language. This becomes an increasing problem with the 
complexity GUI design and interaction has. Tasking and object 
hierarchies and interfaces is in particular difficult. So merely having 
bindings to an alien library is not enough.

I don't think that having GUI in Ada standard is realistic or desirable. 
But we need tools to design Ada libraries with GTK, QT etc as a back-end 
rather than direct bindings.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

"Lucretia" <laguest9000@googlemail.com> wrote in message 
news:4527d955-a6fe-4782-beea-e59c3bb69f21@googlegroups.com...
On Thursday, 10 August 2017 06:41:56 UTC+1, G.B.  wrote:
> On 09.08.17 23:08, Luke A. Guest wrote:
...
>> > 5) Lambdas for the people looking for new (i.e. Old) trendy features.
>>
>> Would you want lambdas that can be returned, or assigned? Or just
>> lambdas that are unnamed expression_function-s of Ada 2012?
>
>This is for the language designers to determine.

Well, we've discussed this, and we seem to be split about 50-50. (or maybe 
it is more like 30-40-30 where one of the numbers is forget the lambdas). At 
least some of the people think that adding simple lambdas would be bad 
enough advertising for Ada that we'd be better off not doing it at all in 
that case.

Another group is rather opposed to doing a complex version because it is 
likely to add erroneousness to the language, or essentially force Ada 
implementations to switch to spaggetti stacks and require some form of 
garbage collection. (Some people think that a set of rules could be defined 
to make it safe, but I personally think they're daft -- there are so many 
special cases that there would be a boatload of rules, and there would be a 
lot of risk of missing something important. I suppose I've given away which 
group I'm in. :-)

>I know people want this, because I've seen this in this newsgroup.

I'd recommend letting those people advocate for themselves, 'cause we need 
to know what their needs are -- we can then see how those fit into the 
various proposals as they continue to be developed. I don't want to guess (I 
don't see any need for lambdas or generators -- they both seem like features 
de-jure to me -- and yes, I know they've both been around a long time).

One of the main reasons for focusing on problems rather than solutions is to 
get some guidance on the answers to questions like this. "I need lambdas" 
tells us nothing about how or why someone wants to use the feature. 
Describing a problem and a possible solution using lambdas (or whatever 
feature) is more enlightening.

                                            Randy.



 

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

"Lucretia" <laguest9000@googlemail.com> wrote in message 
news:4527d955-a6fe-4782-beea-e59c3bb69f21@googlegroups.com...
...
>Again, you seem to be very myopic in that C and Ada are only used
>in embedded. I refer you back to [1] above. You seem to have forgotten
>this.
>
>Windows has sockets, it also has other networking libs available, people
>just tend to create platform specific ports on top of those libs, Ada could
>do the same.

The ARG sent out a call for APIs (really, a call for interfaces to possibly 
standardize) in 2003 (I think). What did we receive then and in the 
intervening years?? Absolutely nothing. Crickets. (We had decent success 
with doing a partial delegation for the containers library; we had two 
volunteers, we picked one, and Matt Heaney did a lot of hard work (including 
wrestling with the ARG) getting the containers into a standardizable form. 
But apparently no one else wanted to put in the time and money. (The link to 
that announcement can be found in the announcement that started this 
thread.)

That offer has remained open in the years since, and it's still open now (it 
was linked into the recent announcement to give it a refresh). The ARG does 
not have the manpower to do a lot of libraries in a form that can reasonably 
be added to the Standard. (Think a level of detail that would allow writing 
ACATS tests to prove proper operation.) If you really want these libraries, 
then put YOUR time and money where your month is. Otherwise, I'm sorry, 
they're not happening.

>Don't you people want Ada to grow into more areas? I've seen people
>look at the language because it seemed interesting to them, then ask,
>"Does Ada have a GUI lib?" or "Does Ada have OpenGL?" or "Does
>Ada have DirectX?" etc. When they are told no, they leave never to
>return, because this is what they want in a language's runtime.

Most of those things are not appropriate for a language standard. What we do 
has to either be stand-alone or tied to some other ISO/IEC standard. Things 
specific to a single OS like Windows aren't a possibility - those have to 
lie with the implementation (and the community, at least for open source 
users).

                                                  Randy.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Shark8]

On Thursday, August 10, 2017 at 7:10:28 PM UTC-6, Randy Brukardt wrote:
> 
> The ARG sent out a call for APIs (really, a call for interfaces to possibly 
> standardize) in 2003 (I think). What did we receive then and in the 
> intervening years?? Absolutely nothing. Crickets.

2003 was a while ago -- 12 years -- it was before I'd been introduced to Ada.

> 
> That offer has remained open in the years since, and it's still open now (it 
> was linked into the recent announcement to give it a refresh).

Interesting.
Though I'd like to contribute I have nothing *to* contribute. (Something like a whole generic GUI API exceeds my grasp at the moment.) -- But, in all likelihood, it would probably be better to define such [API] in terms of Ada as its own standard.

> The ARG does 
> not have the manpower to do a lot of libraries in a form that can reasonably 
> be added to the Standard. (Think a level of detail that would allow writing 
> ACATS tests to prove proper operation.) If you really want these libraries, 
> then put YOUR time and money where your month is. Otherwise, I'm sorry, 
> they're not happening.

I for one appreciate all the work the ARG does; but/and not everything Ada-related ought to be part of the standard, as you note.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Luke A. Guest]

Shark8 <onewingedshark@gmail.com> wrote:
> On Thursday, August 10, 2017 at 7:10:28 PM UTC-6, Randy Brukardt wrote:
>> 
>> The ARG sent out a call for APIs (really, a call for interfaces to possibly 
>> standardize) in 2003 (I think). What did we receive then and in the 
>> intervening years?? Absolutely nothing. Crickets.
> 
> 2003 was a while ago -- 12 years -- it was before I'd been introduced to Ada.

I've not seen this until now either and I'd just gone back to Ada about
then.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Justin Sq]

On Thursday, August 10, 2017 at 10:41:24 AM UTC-4, Lucretia wrote:
> On Thursday, 10 August 2017 06:41:56 UTC+1, G.B.  wrote:
> > On 09.08.17 23:08, Luke A. Guest wrote:
> > 
> > > 1) endian aspects.
> > > 2) full Unicode support including sorting, character db, regexps, bounded
> > > and unbounded need, iterators for code points, graphème clusters, word
> > > boundaries, bidi, etc.
> > 
> > Unicode support can be a joint effort without major investments of time
> > and money:
> > practically adressing Randy Brukardt's remark that this is going to
> > require politics, there is libiconv, the Unicode related designs done
> > for the Swift language, java.text.*, and so forth.
> > 
> > > 3) cross platform GUI.
> > 
> > Care to elaborate why? Having seen cross platform GUIs fail in all but
> 
> I already explained in a previous post, the post does not just relate to 8 but to all my points.
> 
> > corporate surroundings, and possibly games, even then, new proprietary
> 
> In games, companies either use a third party UI or write their own, I know, because I used to work in games.
> 

I have no doubt Ada would benefit from a decent modern GUI or UI framework, but its just not something I think the ARG folks should worry about. There are important tasks directly related to the language itself that can't be solved by third parties generally -- and that argument applies to any other runtime feature or addition proposal.

Perhaps a decent Qt binding is in order?

On the otherhand Ada.Directories and Ada.Text_IO are woefully outdated. For example, if you have a computer and you speak a language like Japanese, French, German, Spanish, etc. think of how frustrating it is when you simply can't open a file with anything other than ASCII in the path. A program that deals with relative directories might work fine in one directory but get moved and suddenly fail hopelessly. Poor end-user :(

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[jsquirek]

On Friday, August 11, 2017 at 10:42:12 AM UTC-4, Justin Sq wrote:
> On Thursday, August 10, 2017 at 10:41:24 AM UTC-4, Lucretia wrote:
> > On Thursday, 10 August 2017 06:41:56 UTC+1, G.B.  wrote:
> > > On 09.08.17 23:08, Luke A. Guest wrote:
> > > 
> > > > 1) endian aspects.
> > > > 2) full Unicode support including sorting, character db, regexps, bounded
> > > > and unbounded need, iterators for code points, graphème clusters, word
> > > > boundaries, bidi, etc.
> > > 
> > > Unicode support can be a joint effort without major investments of time
> > > and money:
> > > practically adressing Randy Brukardt's remark that this is going to
> > > require politics, there is libiconv, the Unicode related designs done
> > > for the Swift language, java.text.*, and so forth.
> > > 
> > > > 3) cross platform GUI.
> > > 
> > > Care to elaborate why? Having seen cross platform GUIs fail in all but
> > 
> > I already explained in a previous post, the post does not just relate to 8 but to all my points.
> > 
> > > corporate surroundings, and possibly games, even then, new proprietary
> > 
> > In games, companies either use a third party UI or write their own, I know, because I used to work in games.
> > 
> 
> I have no doubt Ada would benefit from a decent modern GUI or UI framework, but its just not something I think the ARG folks should worry about. There are important tasks directly related to the language itself that can't be solved by third parties generally -- and that argument applies to any other runtime feature or addition proposal.
> 
> Perhaps a decent Qt binding is in order?
> 
> On the otherhand Ada.Directories and Ada.Text_IO are woefully outdated. For example, if you have a computer and you speak a language like Japanese, French, German, Spanish, etc. think of how frustrating it is when you simply can't open a file with anything other than ASCII in the path. A program that deals with relative directories might work fine in one directory but get moved and suddenly fail hopelessly. Poor end-user :(

My mistake String supports more than just ASCII (Duh), but Asian and other esoteric languages obvious not.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Luke A. Guest]

<jsquirek@gmail.com> wrote:
> On Friday, August 11, 2017 at 10:42:12 AM UTC-4, Justin Sq wrote:

>> On the otherhand Ada.Directories and Ada.Text_IO are woefully outdated.
>> For example, if you have a computer and you speak a language like
>> Japanese, French, German, Spanish, etc. think of how frustrating it is
>> when you simply can't open a file with anything other than ASCII in the
>> path. A program that deals with relative directories might work fine in
>> one directory but get moved and suddenly fail hopelessly. Poor end-user :(
> 
> My mistake String supports more than just ASCII (Duh), but Asian and
> other esoteric languages obvious not.
> 

Unicode would solve this. Ah 21st century technology! 😋

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Justin Sq]

On Friday, August 11, 2017 at 1:10:34 PM UTC-4, Luke A. Guest wrote:
> <...@gmail.com> wrote:
> > On Friday, August 11, 2017 at 10:42:12 AM UTC-4, Justin Sq wrote:
> 
> >> On the otherhand Ada.Directories and Ada.Text_IO are woefully outdated.
> >> For example, if you have a computer and you speak a language like
> >> Japanese, French, German, Spanish, etc. think of how frustrating it is
> >> when you simply can't open a file with anything other than ASCII in the
> >> path. A program that deals with relative directories might work fine in
> >> one directory but get moved and suddenly fail hopelessly. Poor end-user :(
> > 
> > My mistake String supports more than just ASCII (Duh), but Asian and
> > other esoteric languages obvious not.
> > 
> 
> Unicode would solve this. Ah 21st century technology! 😋

Or just Wide Strings ; )...

I really don't see the point of UTF encoding even. Memory is so cheep and we normally end up sending gobs of CSS and minified JS on webpages anyway.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-08-11 19:24, Justin Sq wrote:
> On Friday, August 11, 2017 at 1:10:34 PM UTC-4, Luke A. Guest wrote:
>> <...@gmail.com> wrote:
>>> On Friday, August 11, 2017 at 10:42:12 AM UTC-4, Justin Sq wrote:
>>
>>>> On the otherhand Ada.Directories and Ada.Text_IO are woefully outdated.
>>>> For example, if you have a computer and you speak a language like
>>>> Japanese, French, German, Spanish, etc. think of how frustrating it is
>>>> when you simply can't open a file with anything other than ASCII in the
>>>> path. A program that deals with relative directories might work fine in
>>>> one directory but get moved and suddenly fail hopelessly. Poor end-user :(
>>>
>>> My mistake String supports more than just ASCII (Duh), but Asian and
>>> other esoteric languages obvious not.

I believe GNAT implementation under Linux shamelessly ignores this and 
passes UTF-8 encoded names through.

I think ARM should simply mandate this behavior for all implementations, 
e.g. for Windows.

>> Unicode would solve this. Ah 21st century technology! 😋
> 
> Or just Wide Strings ; )...

No, it must be Wide_Wide_String.

> I really don't see the point of UTF encoding even. Memory is so cheep
> and we normally end up sending gobs of CSS and minified JS on
> webpages  anyway.

It is not that cheap. A typical ARM board has only 1GB. Furthermore 
shuffling 32 bits around instead of 8 is quite a performance hit. And, 
finally, this is inconsistent with stream interfaces. Surely you don't 
propose forceful conversions of octet streams into Wide_Wide_Character 
ones. This would break almost everything.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:oml2tl$11i5$1@gioia.aioe.org...
>>>> On Friday, August 11, 2017 at 10:42:12 AM UTC-4, Justin Sq wrote:
>>>
>>>>> On the otherhand Ada.Directories and Ada.Text_IO are woefully 
>>>>> outdated.
>>>>> For example, if you have a computer and you speak a language like
>>>>> Japanese, French, German, Spanish, etc. think of how frustrating it is
>>>>> when you simply can't open a file with anything other than ASCII in 
>>>>> the
>>>>> path. A program that deals with relative directories might work fine 
>>>>> in
>>>>> one directory but get moved and suddenly fail hopelessly. Poor 
>>>>> end-user :(
>>>>
>>>> My mistake String supports more than just ASCII (Duh), but Asian and
>>>> other esoteric languages obvious not.
>
> I believe GNAT implementation under Linux shamelessly ignores this and 
> passes UTF-8 encoded names through.

Their claim is that it happens automatically; apparently no one (either GNAT 
or Linux) ever checks the characters of a file name for legality. So UTF-8 
characters "work", since any arbitrary code can be in the file system.

OTOH, most other systems have checks, and this doesn't work on the Mac, on 
Windows, etc.

The problem is that AdaCore's desire to keep this misfeature killed the 
first attempt to allow UTF-8 in file names generally. There needs to be some 
way to tell UTF-8 strings from Latin-1 strings (as characters over 128 are 
encoded differently); I believe there was a suggestion to use a BOM to do 
this. That would have broken the "free" use in Linux, and it was killed. So 
you guys got nothing.

The "obvious" fix is to add Wide_Directories and Wide_Wide_Directories, and 
then add Wide_ and Wide_Wide_ versions of all of the file name routines in 
the file packages. (This is the "Tom Petty" solution to me, since it would 
result is adding Wide_Wide_Open.) This Wide_Wide_ stuff is absolutely 
disgusting, and it doesn't provide a proper solution to anything UTF-8. Thus 
I'd like to find a better solution for generalized strings. I think this is 
where this discussion started ...

Round and round the merry go around we go, never to stop. :-)

                              Randy.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Robert Eachus]

On Friday, August 11, 2017 at 5:13:44 PM UTC-4, Randy Brukardt wrote:

> The problem is that AdaCore's desire to keep this misfeature killed the 
> first attempt to allow UTF-8 in file names generally. There needs to be some 
> way to tell UTF-8 strings from Latin-1 strings (as characters over 128 are 
> encoded differently); I believe there was a suggestion to use a BOM to do 
> this. That would have broken the "free" use in Linux, and it was killed. So 
> you guys got nothing.

There is an 'elegant' solution.  Add a UTF8 character string type.  If only a few places in a program need this instead of Latin-1 strings, a child package of Standard with the type declared inside is the way to go.  It would require adding To_UTF8 functions in the same package, but that is a good thing.  You need three, with parameters of String, Wide_String, and Wide_Wide_String types.  This gets away from the need for three sets of file operations.  I'd probably make UTF8 a private type, and provide two Create and Open functions, one taking Latin-1 strings, the other taking UTF8 strings.  Thus:

      Open(Ada_File, In_File, Some_String);
  and Open(Ada_File, In_File, To_UTF8(Some_String));

Will open the same file if Some_String contains only lower page characters, and a quite different file if some upper page characters are included.

Oh, a child of UTF8 could provide a subtype of UTF8_String, and operations on that type.  It might even be useful for say Cyrillic.  But for Unicode or full ISO 10646?  I wouldn't want to write or maintain a package like that, and it sure doesn't belong in the standard.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

"Robert Eachus" <rieachus@comcast.net> wrote in message 
news:725b229b-f768-4603-b564-4751e5e7136f@googlegroups.com...
On Friday, August 11, 2017 at 5:13:44 PM UTC-4, Randy Brukardt wrote:

>> The problem is that AdaCore's desire to keep this misfeature killed the
>> first attempt to allow UTF-8 in file names generally. There needs to be 
>> some
>> way to tell UTF-8 strings from Latin-1 strings (as characters over 128 
>> are
>> encoded differently); I believe there was a suggestion to use a BOM to do
>> this. That would have broken the "free" use in Linux, and it was killed. 
>> So
>> you guys got nothing.

>There is an 'elegant' solution.  Add a UTF8 character string type.

Possible, but in no way elegant: you'd still need duplicate operations for 
it all over the runtime library. (I.e. UTF8_Open, UTF8_Name, etc.). Can't 
change the existing routines without nasty compability problems. (Note that 
auto-conversions don't work either, as they'd make almost all existing code 
with string literals ambiguous.)

The other operations exist already, of course, in the 
Ada.Strings.UTF_Encodings packages. They don't help for uses like I/O and 
Exception_Information.

                                Randy.


 

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Jacob Sparre Andersen]

Robert Eachus wrote:

> There is an 'elegant' solution.  Add a UTF8 character string type.

Wouldn't it be more elegant to redefine Character to cover all Unicode
code-points?  (And make Wide_Character and Wide_Wide_Character renamings
(i.e. subtypes) of Character.)  The Latin-N character sets will of
course have to be declared as subtypes of Character, and I/O
serialization will have to be told of character encodings.

I can imagine that there may be some incompabilities from making such a
change, but what are they?

Greetings,

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 31/08/2017 09:36, Jacob Sparre Andersen wrote:
> Robert Eachus wrote:
> 
>> There is an 'elegant' solution.  Add a UTF8 character string type.
> 
> Wouldn't it be more elegant to redefine Character to cover all Unicode
> code-points?  (And make Wide_Character and Wide_Wide_Character renamings
> (i.e. subtypes) of Character.)  The Latin-N character sets will of
> course have to be declared as subtypes of Character, and I/O
> serialization will have to be told of character encodings.
> 
> I can imagine that there may be some incompabilities from making such a
> change, but what are they?

You need a view of a string as an array of code points / unicode 
characters *and* another view as an array of encoding items, e.g. octet 
for UTF-8 or word for UTF-16 etc.

UTF-16 and UTF-8 strings are equivalent types in the view of code point 
arrays. UCS-2 is a constrained subtype of both. ASCII string is a 
constrained subtype of any.

In the second view ASCII string is a subtype of only UTF-8 string. It is 
an unrelated type to UCS-2 and UTF-16.

You cannot handle this in present Ada.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Jacob Sparre Andersen]

Dmitry A. Kazakov wrote:

> You need a view of a string as an array of code points / unicode
> characters *and* another view as an array of encoding items,
> e.g. octet for UTF-8 or word for UTF-16 etc.

But the encoding stuff is (mostly) on the out-side of the application.
I don't mind having routines for mapping to and from various encodings,
but the encoded types should not have character or string literals, they
should just be arrays of octets with certain characteristics.

> UTF-16 and UTF-8 strings are equivalent types in the view of code
> point arrays. UCS-2 is a constrained subtype of both. ASCII string is
> a constrained subtype of any.

Yes.

> In the second view ASCII string is a subtype of only UTF-8 string. It
> is an unrelated type to UCS-2 and UTF-16.

Don't worry so much about the encoding-view.  Push the encoding troubles
to the edge of your application, and work in a consistent form inside
the application.

> You cannot handle this in present Ada.

You can, if you harmonize to a single encoding for the character and
string view, and only see specific encodings as serializations of
(subsets of) the general character and string types.

The places I expect to see trouble is if some source text assumes that
Standard.Character and Interfaces.C.char are the the same.

Greetings,

Jacob
-- 
"In space, no-one can press CTRL-ALT-DEL"
                                        -- An Ada programmer

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 31/08/2017 14:49, Jacob Sparre Andersen wrote:
> Dmitry A. Kazakov wrote:
> 
>> You need a view of a string as an array of code points / unicode
>> characters *and* another view as an array of encoding items,
>> e.g. octet for UTF-8 or word for UTF-16 etc.
> 
> But the encoding stuff is (mostly) on the out-side of the application.

Not really. E.g. parsing is done in octets for obvious reasons. That was 
the reason why UTF-8 was designed this way.

> I don't mind having routines for mapping to and from various encodings,
> but the encoded types should not have character or string literals, they
> should just be arrays of octets with certain characteristics.

I don't understand this. What is the use of a string type without 
literals? Unbounded_String is a perfect example why this does not work.

It is all about having an ability to choose a representation (encoding) 
rather than getting it enforced upon you by the language. It is no 
solution if you simply create yet another type with the required 
representation losing the original type's interface and forced to 
convert forth and back between two types all over the place. This mess 
does not deserve consideration. We have it aplenty: String, Wide_String, 
Unbounded_String, char_array, chars_ptr ad infinitum.

> Don't worry so much about the encoding-view.  Push the encoding troubles
> to the edge of your application, and work in a consistent form inside
> the application.

Many, if not most, applications never care about code points. 
Applications deal with substrings starting and ending at the boundary of 
a code point. For them it is no matter if the substring is a chain of 
code points or a chain of encoding items.

>> You cannot handle this in present Ada.
> 
> You can, if you harmonize to a single encoding for the character and
> string view, and only see specific encodings as serializations of
> (subsets of) the general character and string types.
> 
> The places I expect to see trouble is if some source text assumes that
> Standard.Character and Interfaces.C.char are the the same.

It should assume Standard.Octet and Interfaces.C.char same. You simply 
cannot drop either encoding items or code points. It would never work.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Jacob Sparre Andersen]

Dmitry A. Kazakov wrote:

> Not really. E.g. parsing is done in octets for obvious reasons. That
> was the reason why UTF-8 was designed this way.

What obvious reasons?  Performance?

As I see it, there is nothing wrong with reading a sequence of octets
containing an UTF-8 encoded string, mapping it to the internal encoding,
and *then* parse the text.  It may be slightly slower, but it allows for
modularity, so you easily can swap in a decoder for a different
encoding.

> What is the use of a string type without literals?

The point is that you shouldn't ever treat an encoded string as a
string.  If you need to treat it as a string, you map it to
Standard.String, and do what you have to do.

> It is all about having an ability to choose a representation
> (encoding) rather than getting it enforced upon you by the
> language.

The whole point is that enforcing a single internal representation
simplifies things.

Encoding of characters is purely an interfacing/serialization issue.  It
isn't something the programmer should have to worry about when not
interfacing.

> It is no solution if you simply create yet another type with
> the required representation losing the original type's interface and
> forced to convert forth and back between two types all over the
> place.

Not all over the place.  Only where you need to (de)serialize the
strings.

> Many, if not most, applications never care about code points.

They usually do.  They just tend to call them "characters".

Greetings,

Jacob
-- 
"Friends don't let friends program in C++." -- Ludovic Brenta.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 31/08/2017 16:09, Jacob Sparre Andersen wrote:
> Dmitry A. Kazakov wrote:
> 
>> Not really. E.g. parsing is done in octets for obvious reasons. That
>> was the reason why UTF-8 was designed this way.
> 
> What obvious reasons?  Performance?

Performance and simplicity.

> As I see it, there is nothing wrong with reading a sequence of octets
> containing an UTF-8 encoded string, mapping it to the internal encoding,
> and *then* parse the text.

UTF-8 *is* the internal encoding. It is the best representation for most 
cases.

>> What is the use of a string type without literals?
> 
> The point is that you shouldn't ever treat an encoded string as a
> string.  If you need to treat it as a string, you map it to
> Standard.String, and do what you have to do.

There is no such thing as a not encoded string. String encoding = string 
representation. All objects have representation. [Not encoded string is 
string value]

>> It is all about having an ability to choose a representation
>> (encoding) rather than getting it enforced upon you by the
>> language.
> 
> The whole point is that enforcing a single internal representation
> simplifies things.

Nobody ever uses Wide_Wide_String which is such a representation now.

> Encoding of characters is purely an interfacing/serialization issue.  It
> isn't something the programmer should have to worry about when not
> interfacing.

Everything in computing is about and in encoding. Program is encoded 
semantics. There is nothing else.

>> It is no solution if you simply create yet another type with
>> the required representation losing the original type's interface and
>> forced to convert forth and back between two types all over the
>> place.
> 
> Not all over the place.  Only where you need to (de)serialize the
> strings.

Table tokens, constants, keys, parameters of subprograms are all in 
their corresponding encodings. Most of them are in UTF-8, of course.

>> Many, if not most, applications never care about code points.
> 
> They usually do.  They just tend to call them "characters".

Yes.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Simon Wright]

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

> On 31/08/2017 16:09, Jacob Sparre Andersen wrote:

>> As I see it, there is nothing wrong with reading a sequence of octets
>> containing an UTF-8 encoded string, mapping it to the internal
>> encoding, and *then* parse the text.
>
> UTF-8 *is* the internal encoding. It is the best representation for
> most cases.

But see the thread beginning at [1], and specifically [2], for the
effect of different normalization forms ..

[1]
https://groups.google.com/d/msg/comp.lang.ada/ZhDARPQ8deQ/fubEjsggBAAJ

[2]
https://groups.google.com/d/msg/comp.lang.ada/ZhDARPQ8deQ/6v-c9SmNAQAJ

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-08-31 17:45, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On 31/08/2017 16:09, Jacob Sparre Andersen wrote:
> 
>>> As I see it, there is nothing wrong with reading a sequence of octets
>>> containing an UTF-8 encoded string, mapping it to the internal
>>> encoding, and *then* parse the text.
>>
>> UTF-8 *is* the internal encoding. It is the best representation for
>> most cases.
> 
> But see the thread beginning at [1], and specifically [2], for the
> effect of different normalization forms ..
> 
> [1]
> https://groups.google.com/d/msg/comp.lang.ada/ZhDARPQ8deQ/fubEjsggBAAJ
> 
> [2]
> https://groups.google.com/d/msg/comp.lang.ada/ZhDARPQ8deQ/6v-c9SmNAQAJ

I would not blame UNICODE alone. There are lot of characters same and 
different at the same time. E.g. а /= a (the first one is Cyrillic). 
Apart from advice never ever normalize anything, the problem arise from 
an attempt to attach some meaning to the string. It is a slippery slope 
[*]. It is also an argument against conversions Jacob hopes to be solution.

--------------------------------------------
* The problem is that equivalent names under an OS are not necessarily 
ones invariant under given conversion. We cannot resolve it at the 
language level. It is hopeless.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> 
> UTF-8 *is* the internal encoding. It is the best representation for most 
> cases.

Most of the cases with which you are dealing, I guess?

>>> What is the use of a string type without literals?

It's a lot like the use of a type without literals.



> Nobody ever uses Wide_Wide_String .

I do use Wide_Wide_String, but I'm nobody.

> Everything in computing is about and in encoding. Program is encoded 
> semantics. There is nothing else.

There is programming, which is about something.
I'm not primarily payed for being a computer.


>> Not all over the place.  Only where you need to (de)serialize the
>> strings.
> 
> Table tokens, constants, keys, parameters of subprograms are all in 
> their corresponding encodings. Most of them are in UTF-8, of course.

Bad design, as some would say: this seems to be 
dragging external coding issues right into the program's text.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

"Jacob Sparre Andersen" <jacob@jacob-sparre.dk> wrote in message 
news:87val3aoly.fsf@jacob-sparre.dk...
...
> The places I expect to see trouble is if some source text assumes that
> Standard.Character and Interfaces.C.char are the the same.

Any rep. clause that assumed that Standard.Character was 8 bits (that is, 
essentially all of them) would fail. Any code that assumed that 
Standard.Character has 256 enumeration values would fail. It would be wildly 
incompatible, and at least some of that incompatibility would be at runtime 
(code would silently change behavior -- the worst kind).

                                   Randy.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Justin Sq]

There is a lot of high-level discussion here regarding the many issues with Ada strings and UTF8 - and I agree for the most part, but I think the solution here would be to add some new versions or amendments to Text_IO and Directories that take Wide_Strings and Wide_Wide_Strings for paths. It would be intuitive, solve the problem, and fit the style of the runtime.

Perhaps I will submit an AI for it.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 01/09/2017 05:51, Justin Sq wrote:
> There is a lot of high-level discussion here regarding the many 
> issues with Ada strings and UTF8 - and I agree for the most part,
> but I think the solution here would be to add some new versions or
> amendments to Text_IO and Directories that take Wide_Strings and
> Wide_Wide_Strings for paths. It would be intuitive, solve the
> problem, and fit the style of the runtime

This will break a lot of code that uses string literals in arguments as 
well as the code with operations like:

    function Extension (Name : in String) return String;

And it would not solve the problem with Unbounded_String.

P.S. There is no solution based on overloading with unrelated string and 
characters types. The packages like Wide_Text_IO was an attempt to keep 
types unrelated while overloading at package level. Surprise, that 
didn't work either.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[jsquirek]

On Friday, September 1, 2017 at 3:24:42 AM UTC-4, Dmitry A. Kazakov wrote:
> On 01/09/2017 05:51, Justin Sq wrote:
> > There is a lot of high-level discussion here regarding the many 
> > issues with Ada strings and UTF8 - and I agree for the most part,
> > but I think the solution here would be to add some new versions or
> > amendments to Text_IO and Directories that take Wide_Strings and
> > Wide_Wide_Strings for paths. It would be intuitive, solve the
> > problem, and fit the style of the runtime
> 
> This will break a lot of code that uses string literals in arguments as 
> well as the code with operations like:
> 
>     function Extension (Name : in String) return String;
> 
> And it would not solve the problem with Unbounded_String.
> 
> P.S. There is no solution based on overloading with unrelated string and 
> characters types. The packages like Wide_Text_IO was an attempt to keep 
> types unrelated while overloading at package level. Surprise, that 
> didn't work either.
> 

Ah yes, I suppose you are right. This is a difficult situation...

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

"Justin Sq" <jsquirek@gmail.com> wrote in message 
news:d3f10832-6382-4ca7-b6c1-1aece935689b@googlegroups.com...
>There is a lot of high-level discussion here regarding the many issues with 
>Ada strings
>and UTF8 - and I agree for the most part, but I think the solution here 
>would be to
>add some new versions or amendments to Text_IO and Directories that take
>Wide_Strings and Wide_Wide_Strings for paths. It would be intuitive, solve 
>the
>problem, and fit the style of the runtime.
>
>Perhaps I will submit an AI for it.

Please don't waste our (my) time with that; there already is an AI for 
"additional internationalization", which would cover any solution (including 
the stupid one).

Note that overloading routines for Wide_String and the like doesn't work 
because no calls could use string literals in that case (which would be 
wildly incompatible); the routines would need an entirely new set of times.

I call this the "Tom Petty" solution, because it would require a trip into 
the Wide_Wide_Open to do that. ;-)

                             Randy.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Robert Eachus]

On Friday, August 11, 2017 at 10:48:39 AM UTC-4, jsqu...@gmail.com wrote:

> > On the otherhand Ada.Directories and Ada.Text_IO are woefully outdated. For example, if you have a computer and you speak a language like Japanese, French, German, Spanish, etc. think of how frustrating it is when you simply can't open a file with anything other than ASCII in the path. A program that deals with relative directories might work fine in one directory but get moved and suddenly fail hopelessly. Poor end-user :(
> 
> My mistake String supports more than just ASCII (Duh), but Asian and other esoteric languages obvious not.

There are three decisions about character sets made every time you create Ada source files.  It is nice to have them all the same, but people used to that get their minds wrapped around the axle when it is not true.  The three cases are:

1) The character set used to write the Ada parts of the program.
2) The character sets the executing computer will use when interpreting characters and string values.
3) The character sets used by the programmer to express character and string constants.

In addition, there are the character sets for the keyboard, the display, any printers, etc.  Fortunately most printers today can handle mixed character sets if the compiler knows how to prepare listings for them.  Also a compiler may allow characters in comments which are not allowed elsewhere in the source--but it is nice for the character sets in Strings and comments to match.

Compilers can, and do have switches to set the character set used for the Ada code.  Technically it is not standard compliant to compile in this mode for the international standard, but may be fine for National standards. It is also possible to have switches choose the source and target representation for characters and strings.  Since the name of a file is represented as a String, it is quite possible for a compiler to support ShiftJIS as the character set for String, and thus for file names.  Of course, you need the computer running the program to interpret them the same way...

I hope that Ada is (slowly) moving toward UTF-8 as the default--with the emphasis on slowly.  For example, a standard conversion from UTF-8 to Long_Long_Character and back would be very nice.  (What about Long_Character?  It should be Unicode, and if there is any deviation between UTF-16 and Unicode, stick with Unicode.)

Is it possible for you to find an Ada compiler that will allow programs written in your favorite language and character set?  That is a market issue.  Ada has moved in the direction of supporting multiple character sets a lot better than most standard languages.  But if you don't have the vendor support?  To take an example from above, you should always be able to pass ShiftJIS strings to the file system.*  But to write the programs in Ada, you will need a ShiftJIS capable terminal and printer to stay sane.   I would hope that Unicode and full ISO 10646 is gradually replacing other Japanese encodings.

* Gotchas:  If the second byte of a shift JIS pair is '"', you will need to put an extra " in when writing the string, with the compiler thinking you are using Latin-1 or whatever.  Similarly high page control codes will have to be entered by name.  The best thing to do is write a program that can convert JIS or Shift JIS source to an 8-bit Ada source string.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Shark8]

On Friday, August 18, 2017 at 2:33:30 PM UTC-6, Robert Eachus wrote:
> 
> > > On the otherhand Ada.Directories and Ada.Text_IO are woefully outdated.
> > 
> > My mistake String supports more than just ASCII (Duh), but Asian and other esoteric languages obvious not.
> 
> There are three decisions about character sets made every time you create Ada source files.  It is nice to have them all the same, but people used to that get their minds wrapped around the axle when it is not true.  The three cases are:
> 
> 1) The character set used to write the Ada parts of the program.
> 2) The character sets the executing computer will use when interpreting characters and string values.
> 3) The character sets used by the programmer to express character and string constants.

This is true -- but there's a conspicuous disconnect here, regarding Ada.Directories.

The problem is the idea that strings/names and the object are equivalent, as evidenced by ARM A.16.1 5/2, 6/2, 7/2, etc.
5/2    function Current_Directory return String;
6/2    procedure Set_Directory (Directory : in String);
7/2    procedure Create_Directory (New_Directory : in String;
                               Form          : in String := "");
8/2    procedure Delete_Directory (Directory : in String);

Function "Current_Directory" should *NOT* return a string, but a directory-type (tagged or not is irrelevant), not a string, likewise "Set_Directory" and "Delete_Directory" should take said directory-objects instead of strings.

In short: A directory is *NOT* a string, but a object in its own right.

Moreover, thinking of directories in terms of strings leads to string manipulation for referring and it is *easy* to make errors there.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-08-19 03:24, Shark8 wrote:

> Moreover, thinking of directories in terms of strings leads to
> string manipulation for referring and it is *easy* to make errors there.

Exactly, but the problem is the file type system. The file path type 
must be a subtype of a universal string type in order to be able to write:

    Open ("my_file.txt")

instead of something like:

    Open
    (  Current_Node +
       Current_Directory +
       To_File_Name ("my_file") +
       To_MIME_Type ("txt")
    )

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Shark8]

On Saturday, August 19, 2017 at 2:55:10 AM UTC-6, Dmitry A. Kazakov wrote:
> On 2017-08-19 03:24, Shark8 wrote:
> 
> > Moreover, thinking of directories in terms of strings leads to
> > string manipulation for referring and it is *easy* to make errors there.
> 
> Exactly, but the problem is the file type system. The file path type 
> must be a subtype of a universal string type in order to be able to write:
> 
>     Open ("my_file.txt")
> 

But the file path should NOT be inherently a string, of any type, it should be a "directory-type" -- and any to/from string conversions (say from external sources) should be done properly -- that's the whole point I'm making: a directory is NOT a string, nor should we use strings [natively] to represent them.

> instead of something like:
> 
>     Open
>     (  Current_Node +
>        Current_Directory +
>        To_File_Name ("my_file") +
>        To_MIME_Type ("txt")
>     )

Why would we need something like the above?

Besides, the Open function having the implicit parameter of Location defaulting to the "current location" would take care of half of that.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-08-19 18:38, Shark8 wrote:
> On Saturday, August 19, 2017 at 2:55:10 AM UTC-6, Dmitry A. Kazakov wrote:
>> On 2017-08-19 03:24, Shark8 wrote:
>>
>>> Moreover, thinking of directories in terms of strings leads to
>>> string manipulation for referring and it is *easy* to make errors there.
>>
>> Exactly, but the problem is the file type system. The file path type
>> must be a subtype of a universal string type in order to be able to write:
>>
>>      Open ("my_file.txt")
>>
> 
> But the file path should NOT be inherently a string, of any type, it
> should be a "directory-type"

File path type, not {absolute|relative} directory type.

> -- and any to/from string conversions (say
> from external sources) should be done properly -- that's the whole point
> I'm making: a directory is NOT a string, nor should we use strings
> [natively] to represent them.

File name encoded in a string is the normal use case most of the time. I 
agree that using strings makes it non-portable since string 
representations vary from OS to OS. Yet it is how things are.

>> instead of something like:
>>
>>      Open
>>      (  Current_Node +
>>         Current_Directory +
>>         To_File_Name ("my_file") +
>>         To_MIME_Type ("txt")
>>      )
> 
> Why would we need something like the above?

You need literal or aggregates or any other form to specify a value of 
the file path in Open. I used an expression.

BTW, it would be portable too.

> Besides, the Open function having the implicit parameter of Location
> defaulting to the "current location" would take care of half of that.

This works only with type conversions or massive overloading. Which was 
my point.

In order to have this mess typed, and you correctly said that it must 
be, you will need *separate* types for:

- Node / device
- Absolute directory
- Relative directory
- Simple name
- MIME type (extension)
- File version / change number (e.g. for VMS or source control systems)
- File name (simple name, MIME type, version number)
- Directory name (node, directory)
- File path (node, directory, name, MIME type, version number)

If Open were defined on file path, then a partial name would not match, 
unless converted implicitly, e.g. by adding directory name.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Robert Eachus]

On Saturday, August 19, 2017 at 1:09:07 PM UTC-4, Dmitry A. Kazakov wrote:
 
> In order to have this mess typed, and you correctly said that it must 
> be, you will need *separate* types for:
> 
> - Node / device
> - Absolute directory
> - Relative directory
> - Simple name
> - MIME type (extension)
> - File version / change number (e.g. for VMS or source control systems)
> - File name (simple name, MIME type, version number)
> - Directory name (node, directory)
> - File path (node, directory, name, MIME type, version number)
> 
> If Open were defined on file path, then a partial name would not match, 
> unless converted implicitly, e.g. by adding directory name.

That way lies madness.  What you want is a tagged type URL.  The base type could have conversions to/from string, with child types like local_path, etc., which could be used to generate a (full) URL from a local file name.  Is there any reason why Ada 2020 Text_IO should not have a Open that takes a URL as an argument?

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 22/08/2017 08:02, Robert Eachus wrote:
> On Saturday, August 19, 2017 at 1:09:07 PM UTC-4, Dmitry A. Kazakov wrote:
>   
>> In order to have this mess typed, and you correctly said that it must
>> be, you will need *separate* types for:
>>
>> - Node / device
>> - Absolute directory
>> - Relative directory
>> - Simple name
>> - MIME type (extension)
>> - File version / change number (e.g. for VMS or source control systems)
>> - File name (simple name, MIME type, version number)
>> - Directory name (node, directory)
>> - File path (node, directory, name, MIME type, version number)
>>
>> If Open were defined on file path, then a partial name would not match,
>> unless converted implicitly, e.g. by adding directory name.
> 
> That way lies madness.

Why is that madness?

> What you want is a tagged type URL.

Typed with all types necessary. E.g. we need an operations to iterate 
directory nodes etc.

> The base type could have conversions to/from string, with child types
> like local_path, etc.,

I don't directly see how the above types should be rooted in the same 
parent. File version has nothing to do with MIME type.

> Is there any reason why Ada 2020 Text_IO should not
> have a Open that takes a URL as an argument?

There is no reason why. There is also no reason why it should not take 
file name and other partial types. That was the point about overloading 
vs. subtyping [non-Ada ones].

Another point was about factoring out encodings. If you can produce file 
name type from any kind of Ada string, then single Directories and 
single Text I/O package is sufficient.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Robert Eachus]

On Tuesday, August 22, 2017 at 3:34:56 AM UTC-4, Dmitry A. Kazakov wrote: 
> > What you want is a tagged type URL.
> 
> Typed with all types necessary. E.g. we need an operations to iterate 
> directory nodes etc.
> 
> > The base type could have conversions to/from string, with child types
> > like local_path, etc.,
> 
> I don't directly see how the above types should be rooted in the same 
> parent. File version has nothing to do with MIME type.

You are missing the concept.  A URL is well defined today.  But say that as quantum computers become more common, there is a form of locator which uses set notation:  "I want photographs taken September 17, 2012, near these (Lat/Long) coordinates."  URLs are extensible, and there is no reason why you shouldn't have one form for local files, and another for internet resources.

The function which converts a text string to a URL can call itself recursively, or more likely have typed calls to say the part of the function which processes file names.

Hmmm.  Another example is that long URL from HTML get accesses.  You might want to have an extension to decode your custom get queries.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-08-26 06:41, Robert Eachus wrote:
> On Tuesday, August 22, 2017 at 3:34:56 AM UTC-4, Dmitry A. Kazakov wrote:
>>> What you want is a tagged type URL.
>>
>> Typed with all types necessary. E.g. we need an operations to iterate
>> directory nodes etc.
>>
>>> The base type could have conversions to/from string, with child types
>>> like local_path, etc.,
>>
>> I don't directly see how the above types should be rooted in the same
>> parent. File version has nothing to do with MIME type.
> 
> You are missing the concept.

Certainly

> A URL is well defined today.

I don't see how URL is relevant to this at all.

The point was that path identifying a node in a tree of directories 
should not be represented by a string type in a language like Ada.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Jacob Sparre Andersen]

Dmitry A. Kazakov wrote:

> I don't see how URL is relevant to this at all.

I think the point is that a URL is a generalisation of a file/directory
name.  And if we're going to introduce a new interface for handling
files, why not make it more general, and include resources located on
remote servers as well.  One problem with that is going to be how we map
the conventional file operations to operations on URL's, but I think it
is still worth considering.

Greetings,

Jacob
-- 
»Saving keystrokes is the job of the text editor, not the
 programming language.«                    -- Preben Randhol

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-08-26 09:16, Jacob Sparre Andersen wrote:
> Dmitry A. Kazakov wrote:
> 
>> I don't see how URL is relevant to this at all.
> 
> I think the point is that a URL is a generalisation of a file/directory
> name.

URL may contain such a name, that alone does not make it generalization 
or a desired direction of generalization.

> And if we're going to introduce a new interface for handling
> files, why not make it more general, and include resources located on
> remote servers as well.

Because see above, URL is not a generalization. It lacks relevant 
properties of a file system, in particular ones for which 
Ada.Directories is meant for, e.g. traversal of the directory tree. URL 
does not tell anything about whether /A/B must exist if /A/B/C does.

> One problem with that is going to be how we map
> the conventional file operations to operations on URL's, but I think it
> is still worth considering.

Maybe though it is far away from the direct problems we have with the 
mess of Ada.Directories and Text_IO.

And all this cannot change the point: using strings there was a bad 
idea, with URLs or without them.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Robert Eachus]

On Saturday, August 26, 2017 at 3:48:28 AM UTC-4, Dmitry A. Kazakov wrote:

> URL may contain such a name, that alone does not make it generalization 
> or a desired direction of generalization.

Sorry, that ship left port more than a decade ago, and the Ada community is not big enough, or strong enough to call it back to the dock.  There is one generalized resource locator worldwide, and it is called a URL.

Having said that, the system I am using might represent URLs in Unicode, your computer might use UTF-8, or some generalized directory structure.  It is definitely the case that I may use local URLs that cannot be resolved in that form on your system. Also there will be multiple strings which resolve to the same resource even starting from the same location on my system, or yours.

So, the right representation of a URL is a private tagged type in Ada.  My system might use Unicode internally, yours might use some generalized file descriptor in a directory structure doesn't matter.  Also, Ada needs to play nicely with ISO 10646, including UTF-8 and Unicode.

I would have functions on my system which create URL objects:

type Locale is private;
function Current_Location return Locale;

function To_URL(Path: String) return URL; -- Latin1? Locally defined Character
function To_URL(Path: UTF8) return URL; -- Might just call the above.  But
                                        -- only if they are the same.
function To_URL(Resource: String;
                Relative_To: Locale) return URL;
function To_URL(Path: Long_String) return URL; -- Unicode version
function To_URL(Resource: File_Type) return URL; -- Ada IO File_Type
function To_URL(Object_Name: Long_String; Relative_To: Locale) return URL;
-- I'd probably use this one a lot on a Unicode system.
...
procedure Open(Resource: in URL;
               Mode: 
               Form: ...

The various creators for URLs may not all be in the same location (but it makes sense for all the language standard defined creators).  And please get it right that you need to be able to create both local and general URLs at a minimum.  One version with locale parameter, one without.
 
> Because see above, URL is not a generalization. It lacks relevant 
> properties of a file system, in particular ones for which 
> Ada.Directories is meant for, e.g. traversal of the directory tree. URL 
> does not tell anything about whether /A/B must exist if /A/B/C does.
>...
> 
> Maybe though it is far away from the direct problems we have with the 
> mess of Ada.Directories and Text_IO.

As I said above, URLs are here to stay, and Ada has to live (or die) in this world.  If parsing file names into directories and (terminal) objects makes sense, then there is no reason not to continue the current directory packages, or mark them as obsolete with continued support.

The real problem with the directory stuff is trying to pound reality into a hierarchical structure.  Even on a single Windows, Linux, or Unix system, the file system is a web with a number of roots which may not be present at all times or reachable from a given starting point.  For now, and the next few decades, URLs may not be perfect but they are what we have.
 
> And all this cannot change the point: using strings there was a bad 
> idea, with URLs or without them.

No, using strings there was a very valid realization of the DoD requirements.  Ada quickly became an international programming language, and resolving the character set and path name issues became important.  But throwing out all existing code wasn't going to happen.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-08-27 14:03, Robert Eachus wrote:
> On Saturday, August 26, 2017 at 3:48:28 AM UTC-4, Dmitry A. Kazakov wrote:
> 
>> Because see above, URL is not a generalization. It lacks relevant
>> properties of a file system, in particular ones for which
>> Ada.Directories is meant for, e.g. traversal of the directory tree. URL
>> does not tell anything about whether /A/B must exist if /A/B/C does.
>> ...
>>
>> Maybe though it is far away from the direct problems we have with the
>> mess of Ada.Directories and Text_IO.
> 
> As I said above, URLs are here to stay, and Ada has to live (or die)
> in this world.

Again, this all is irrelevant. The sole purpose of Ada.Directories is to 
traverse the file system nodes.

> If parsing file names into directories and (terminal)
> objects makes sense, then there is no reason not to continue the current
> directory packages, or mark them as obsolete with continued support.

Right. Either you do this or you have no Ada.Directories. You want to 
eliminate it. Good to you. I don't use Ada.Directories either, because 
it is a non-portable mess. I am using Glib stuff instead. [No, Glib does 
not confuse files with URLs).

> The real problem with the directory stuff is trying to pound reality
> into a hierarchical structure.

I never ever saw relational or networked file system directory 
structure, aside from very early academic attempts. The reality is that 
major file systems are hierarchical.

Though string representation is even less suitable for these than for 
hierarchical topology.

> Even on a single Windows, Linux, or Unix
> system, the file system is a web with a number of roots which may not be
> present at all times or reachable from a given starting point.

If root is inaccessible so are its children.

> For now, and the next few decades, URLs may not be perfect but they
> are what we  have.

Nobody uses URL for file names, so far. My guess that this will not 
change in the following decades either.

>> And all this cannot change the point: using strings there was a bad
>> idea, with URLs or without them.
> 
> No, using strings there was a very valid realization of the DoD
> requirements. Ada quickly became an international programming language,
> and resolving the character set and path name issues became important.
> But throwing out all existing code wasn't going to happen.

It happened already. Nobody in sane mind would use Text_IO otherwise 
that for standard output. Wide_String and Wide_Wide_String variants are 
not even worth consideration.

Lower-level but sane stream I/O to be used instead, yes, with manual 
handling of encoding and line terminators.

Unfortunately record-oriented I/O is long dead. Not that Text_IO handled 
it better than stream-oriented one.

So Stream I/O is a safe, efficient and portable choice, while Text_IO in 
all its incarnations is anything but.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dennis Lee Bieber]

On Sun, 27 Aug 2017 14:35:59 +0200, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> declaimed the following:

>I never ever saw relational or networked file system directory 
>structure, aside from very early academic attempts. The reality is that 

	No hard and/or soft-links used anywhere? (Or Windows "reparse points"
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365503(v=vs.85).aspx
or "mounted folders"
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365237(v=vs.85).aspx
)

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-08-27 16:44, Dennis Lee Bieber wrote:
> On Sun, 27 Aug 2017 14:35:59 +0200, "Dmitry A. Kazakov"
> <mailbox@dmitry-kazakov.de> declaimed the following:
> 
>> I never ever saw relational or networked file system directory
>> structure, aside from very early academic attempts. The reality is that
> 
> 	No hard and/or soft-links used anywhere? (Or Windows "reparse points"
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa365503(v=vs.85).aspx
> or "mounted folders"
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa365237(v=vs.85).aspx

BTW "hierarchical" was not my choice word. It is actually "acyclic 
directed graph" (after removing pseudo-nodes like "." and ".."). That is 
what Ada.Directories is supposed to comply with, at least when looking 
at its present interface.

P.S. There is probably no requirement to test if two nodes are same. I 
don't know why OSes have problems with that, but some seemingly do. 
Nominal equivalence is OK for most applications.

P.P.S. I still don't see how anything of this could possibly justify 
strings. More complex it gets even less suitable strings become.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-08-18 22:33, Robert Eachus wrote:

> There are three decisions about character sets made every time you
> create Ada source files. It is nice to have them all the same, but
> people used to that get their minds wrapped around the axle when it is
> not true. The three cases are:
> 
> 1) The character set used to write the Ada parts of the program.
> 2) The character sets the executing computer will use when interpreting characters and string values.

? Computer does not interpret anything. It executes machine code. The 
semantics of that code is beyond the computer and irrelevant, so long 
the compiler generates it right.

> 3) The character sets used by the programmer to express character and string constants.

The issue has nothing to do with character sets. It does with encodings 
of the same set.

There is no reason to have anything but Unicode code points. All others 
are constrained subsets of.

> I hope that Ada is (slowly) moving toward UTF-8 as the default--with
> the emphasis on slowly. For example, a standard conversion from UTF-8 to
> Long_Long_Character and back would be very nice.

I suppose. "Conversion" from string to code point is called array indexing:

    Text (Index)

(I don't think one should bother considering things called "character" 
in Unicode. Code point is good enough for most purposes.)

> (What about Long_Character? It should be Unicode, and if there is any
> deviation  between UTF-16 and Unicode, stick with Unicode.)

Hmm, UTF-16 is an encoding. AFAIK, per Unicode design there cannot be 
any deviation from it, that is the part "uni" in the name...

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[J-P. Rosen]

Le 09/08/2017 à 23:08, Luke A. Guest a écrit :
> 2) full Unicode support including sorting, character db, regexps, bounded
> and unbounded need, iterators for code points, graphème clusters, word
> boundaries, bidi, etc.
You should have attended my tutorial in Vienna...

The Unicode standard is about 2 and a half the size of the ARM. And
sorting is a much more complicated issue than you can imagine. and...

I don't think compiler vendors are ready to double their teams just to
provide Unicode support ;-)

-- 
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: Community Input for the Maintenance and Revision of the Ada Programming Language

[Lucretia]

On Thursday, 10 August 2017 13:18:48 UTC+1, J-P. Rosen  wrote:
> Le 09/08/2017 à 23:08, Luke A. Guest a écrit :
> > 2) full Unicode support including sorting, character db, regexps, bounded
> > and unbounded need, iterators for code points, graphème clusters, word
> > boundaries, bidi, etc.
> You should have attended my tutorial in Vienna...

Yes well, I can't afford that.
 
> The Unicode standard is about 2 and a half the size of the ARM. And
> sorting is a much more complicated issue than you can imagine. and...

I know, I've read enough of it.
 
> I don't think compiler vendors are ready to double their teams just to
> provide Unicode support ;-)

Double? Really? I don't think so, over exaggeration.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[J-P. Rosen]

Le 10/08/2017 à 14:40, Lucretia a écrit :
>> I don't think compiler vendors are ready to double their teams just to
>> provide Unicode support ;-)
> Double? Really? I don't think so, over exaggeration.
There was a smiley... But it IS a significant effort, unless there are
accepted libraries and the effort is just in binding.

-- 
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: Community Input for the Maintenance and Revision of the Ada Programming Language

[AdaMagica]

Am Donnerstag, 10. August 2017 14:18:48 UTC+2 schrieb J-P. Rosen:
> Le 09/08/2017 à 23:08, Luke A. Guest a écrit :
> > 2) full Unicode support including sorting, character db, regexps, bounded
> > and unbounded need, iterators for code points, graphème clusters, word
> > boundaries, bidi, etc.
> You should have attended my tutorial in Vienna...
> 
> The Unicode standard is about 2 and a half the size of the ARM. And
> sorting is a much more complicated issue than you can imagine. and...

Is this tutorial available?
Christoph

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Pascal Obry]

Le mercredi 09 août 2017 à 22:08 +0100, Luke A.Guest a écrit :
> 4) multiple return types:
> 
>   function Blah return Integer, Float; 

Generalized tuples. I would like this too.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-08-10 18:28, Pascal Obry wrote:
> Le mercredi 09 août 2017 à 22:08 +0100, Luke A.Guest a écrit :
>> 4) multiple return types:
>>
>>    function Blah return Integer, Float;
> 
> Generalized tuples. I would like this too.

Should not they be named? Then it is an anonymous record type:

    function Blah return
       record Count : Integer; Value : Float end record;

How do I pass tuple elements down? Say, I have

    procedure Foo (X : Float; Y : String; Z : Integer);

Now I want to call Foo:

    Foo (X => Blah.Value, Z => Same_Blah.Count, Y => "fun");

?

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Luke A. Guest]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On 2017-08-10 18:28, Pascal Obry wrote:
>> Le mercredi 09 août 2017 à 22:08 +0100, Luke A.Guest a écrit :
>>> 4) multiple return types:
>>> 
>>> function Blah return Integer, Float;
>> 
>> Generalized tuples. I would like this too.
> 
> Should not they be named? Then it is an anonymous record type:
> 
>    function Blah return
>       record Count : Integer; Value : Float end record;
> 
> How do I pass tuple elements down? Say, I have
> 
>    procedure Foo (X : Float; Y : String; Z : Integer);
> 
> Now I want to call Foo:
> 
>    Foo (X => Blah.Value, Z => Same_Blah.Count, Y => "fun");
> 
> ?
> 

Well you could implement with a bunch of generics taking different number
of types but a language level construct would be better.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-08-10 19:08, Luke A. Guest wrote:
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On 2017-08-10 18:28, Pascal Obry wrote:
>>> Le mercredi 09 août 2017 à 22:08 +0100, Luke A.Guest a écrit :
>>>> 4) multiple return types:
>>>>
>>>> function Blah return Integer, Float;
>>>
>>> Generalized tuples. I would like this too.
>>
>> Should not they be named? Then it is an anonymous record type:
>>
>>     function Blah return
>>        record Count : Integer; Value : Float end record;
>>
>> How do I pass tuple elements down? Say, I have
>>
>>     procedure Foo (X : Float; Y : String; Z : Integer);
>>
>> Now I want to call Foo:
>>
>>     Foo (X => Blah.Value, Z => Same_Blah.Count, Y => "fun");
>>
>> ?
>>
> 
> Well you could implement with a bunch of generics taking different number
> of types but a language level construct would be better.

I doubt any number of generics would help.

The question is syntax of passing tuple result down. If resolved it 
could help in other important cases like container element in-place 
update when you want to pass the container's element down in in-out mode.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Lucretia]

On Thursday, 10 August 2017 18:25:30 UTC+1, Dmitry A. Kazakov  wrote:

> >> Should not they be named? Then it is an anonymous record type:
> >>
> >>     function Blah return
> >>        record Count : Integer; Value : Float end record;

No, I would prefer notation for tuples, say <> or [] as they have no use in Ada, or just use () like we do for everything else. In the compiler, it could just generate records.

   function Blah return <Count : Integer; Value: Float>;

then you could pass Blah to function which took as input (only) a tuple which matched.

   procedure Do_Thing (Tuple : in <Integer, Float>);

   Do_Thing (Blah);

   Tuple : <Count : Integer; Value: Float> := Blah;

or:

   Count : Integer;
   Value : Float;

   Count, Value := Blah;


> I doubt any number of generics would help.

No, it would lead to an explosion of generics, that's why I said it wasn't ideal.
 
> The question is syntax of passing tuple result down. If resolved it 
> could help in other important cases like container element in-place 
> update when you want to pass the container's element down in in-out mode.

If you allowed named tuples, as in above "Tuple" you could pass out as well. Each element could be accessed as Tuple.Count and Tuple.Value.

Luke.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-08-11 03:02, Lucretia wrote:
> On Thursday, 10 August 2017 18:25:30 UTC+1, Dmitry A. Kazakov  wrote:
> 
>>>> Should not they be named? Then it is an anonymous record type:
>>>>
>>>>      function Blah return
>>>>         record Count : Integer; Value : Float end record;
> 
> No, I would prefer notation for tuples, say <> or [] as they have no
> use in Ada, or just use () like we do for everything else. In the
> compiler, it could just generate records.
 >
>     function Blah return <Count : Integer; Value: Float>;

These are different things:

1. type definition
2. aggregate

Clearly, for aggregates () must be used, which is tuple mathematical 
notation too. For type definition record is IMO obvious choice.

> then you could pass Blah to function which took as input (only) a tuple which matched.
> 
>     procedure Do_Thing (Tuple : in <Integer, Float>);
> 
>     Do_Thing (Blah);
> 
>     Tuple : <Count : Integer; Value: Float> := Blah;
 >
> or:
> 
>     Count : Integer;
>     Value : Float;
> 
>     Count, Value := Blah;

This is the key issue: tuple flattening. Flattening is when a tuple is 
used in a list like you did with the assignment of two assorted 
variables above. Or when a tuple is used in plain list of parameters as 
I illustrated before. You need syntax rules for that.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

"Lucretia" <laguest9000@googlemail.com> wrote in message 
news:183e2377-26b9-436f-830f-ba2021d455f6@googlegroups.com...
> On Thursday, 10 August 2017 18:25:30 UTC+1, Dmitry A. Kazakov  wrote:
>
>> >> Should not they be named? Then it is an anonymous record type:
>> >>
>> >>     function Blah return
>> >>        record Count : Integer; Value : Float end record;
>
> No, I would prefer notation for tuples, say <> or [] as they have no
>use in Ada, or just use () like we do for everything else. In the
>compiler, it could just generate records.

What problem does this solve better than just declaring a Tuple record type? 
Anonymous types are evil.

                                             Randy.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Luke A. Guest]

Pascal Obry <pascal@obry.net> wrote:
> Le mercredi 09 août 2017 à 22:08 +0100, Luke A.Guest a écrit :
>> 4) multiple return types:
>> 
>>   function Blah return Integer, Float; 
> 
> Generalized tuples. I would like this too.
> 

I wanted this in Ada95 when I wanted to return a value and an error code
from a function, had to change it to a procedure, could do it now with an
out parameter on a function but a type would still be better.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

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

"Luke A. Guest" <laguest@archeia.com> wrote in message 
news:466561720.524077501.729508.laguest-archeia.com@nntp.aioe.org...
> Pascal Obry <pascal@obry.net> wrote:
>> Le mercredi 09 août 2017 à 22:08 +0100, Luke A.Guest a écrit :
>>> 4) multiple return types:
>>>
>>> function Blah return Integer, Float;
>>
>> Generalized tuples. I would like this too.
>>
>
> I wanted this in Ada95 when I wanted to return a value and an error code
> from a function, had to change it to a procedure, could do it now with an
> out parameter on a function but a type would still be better.

Error codes are evil. Use an exception. ;-)

(Yes, this has happened to me, too, but that doesn't change the above.)

Speaking of evil, anonymous types are evil. Why is it hard to declare a 
record type for this purpose?

                                Randy.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[G.B.]

On 11.08.17 03:31, Randy Brukardt wrote:
> Speaking of evil, anonymous types are evil. Why is it hard to declare a
> record type for this purpose?

A record is mutable, a tuple isn't meant to be mutable
(i.e., can't update it's components). Also, it is harder
to start from good types and names than to use a continous
improvement process that finds them.

A tuple language will first let programmers write

    return Integer, Float,
or
    -> (Int, Float)
or
   int, float function;

and then let them use these values "generically": anything that
takes an integer and a floating point value will work:
argument pattern matching, or referring to Fst and
Snd component using built-in ".0" and ".1" suffix notation.
It then does not matter whether the integers and FPT values
really are of types (apples, prices) or (oranges, weight)...
  
It is convenient.

It is prone to logical errors, because it'll make lazy
programmers stop making good use of the type system, i.e.
it eases accidentally mistaking apples for oranges,
or price for weight, IOW make reasonably errors.

It is, therefore, a very viable scheme of language based
supportbusiness.



OTOH, if (int, float) tuples used in the implementation
of an ADT only, then the convenience might loose some of
the disadvantages of depending on tuples.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Stefan.Lucks]

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

>> Speaking of evil, anonymous types are evil. Why is it hard to declare a
>> record type for this purpose?
>
> A record is mutable, a tuple isn't meant to be mutable
> (i.e., can't update it's components).

I don't think, supporting function returning ad-hoc anonymous tuples would 
strengthen Ada's stand as a language well-suited for safe and secure 
systems. Anonymous types are bad in that area, anyway.

If you want tuples, then it would be a lot more consistent to actually 
propose the introduction of tuples (i.e., constant records) into the Ada 
type system, e.g.,

    type May_Be_Integer(Valid: Boolean := True) is constant record
      case Valid is
 	when True  => Value: Integer;
 	when False => null;
      end case;
    end record;

    type Numeric(Is_Float: Boolean := True) is constant record
      case Is_Float is
 	when True  => F: Float;
 	when False => I: Integer;
      end case;
    end record;

Then you can the kind of functions you are requesting:

   function Calculate(A, B, C: Integer; D, E, F: Float) return Numeric;
   -- returns either Integer or Float

but you can also deal with such tuples in a really consistent way. This 
could look about as follows:

   Not_An_Int: May_Be_Integer(False);

   function May_Be(I: Integer) return May_Be_Integer is
      (May_Be_Integer(Value => I));

   function "+"(A, B: May_Be_Integer) return May_Be_Integer is
   begin
      if A.Valid and B.Valid then
        return A.Value + B.Value;
      else
        return Not_An_Int;
      end;
   end "+";

   function "*"(A, B: May_Be_Integer) return May_Be_Integer is
   begin
      if A.Valid and then A.Value = 0 then
         return 0;
      elsif B.Valid and then B.Value = 0 then
         return 0;
      elsif A.Valid and B.Valid then
         return A.Value * B.Value
      else
         return Not_An_Int;
      end;
   end "*";

   function "-"(A, B: May_Be_Integer) return May_Be_Integer is ...
   function "/"(A, B: May_Be_Integer) return May_Be_Integer is ...

At a first look, this may appear like a convoluted approach to evaluate 
integer expressions, replacing exceptions by Not_An_Int. But consider an 
expression like

   May_Be(1) + (May_Be(2) / May_Be(0)) * May_Be(0)

This expression will evaluate to 1, while the corresponding integer 
expression

   1 + (2/0) * 0

will raise an exception. If there is a chance for errors to cancel out,
as in my definition of "*", then integers with error markers are a good 
approach, and exceptions will complicate things a lot.

And yes, I know that my multiplication for May_Be_Integer does not match 
mathematical conventions.



Stefan




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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-08-11 09:57, Stefan.Lucks@uni-weimar.de wrote:

> If you want tuples, then it would be a lot more consistent to actually 
> propose the introduction of tuples (i.e., constant records) into the Ada 
> type system, e.g.,
> 
>     type May_Be_Integer(Valid: Boolean := True) is constant record
>       case Valid is
>      when True  => Value: Integer;
>      when False => null;
>       end case;
>     end record;

Hmm, isn't it simply a subtype:

    type May_Be_Integer (Valid: Boolean := True) is record
       case Valid is
          when True =>
             Value : Integer;
          when False =>
             null;
       end case;
    end record;

    subtype Surely_Integer is May_Be_Integer (True);

> Then you can the kind of functions you are requesting:
> 
>    function Calculate(A, B, C: Integer; D, E, F: Float) return Numeric;
>    -- returns either Integer or Float
[...]

This looks awful to me.

IMO the right approach, which I deployed on several occasions a tagged 
abstract type Numeric with descendants Integer_Number and Float_Number. 
Then "+" is multiple-dispatch emulated via cascaded dispatch:

    function "+" (A : Numeric; B : Numeric'Class) return Numeric'Class;

I don't see any relation to tuples.

However it has a relation to pure compile time subroutines. Because the 
above can be made statically checkable if the body could be split into 
pure and impure parts. The pure part would run at compile time if tags 
are statically known and fold the constants. The impure part will run if 
tags are unknown.

A similar case is dimensioned arithmetic which is closer to what you 
proposed when the dimension is packed in a discriminant rather than tag. 
Here again we want statically known discriminants eliminated and pure 
dimension checks in static cases.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Stefan.Lucks]

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

On Fri, 11 Aug 2017, Dmitry A. Kazakov wrote:

>>    function Calculate(A, B, C: Integer; D, E, F: Float) return Numeric;
>>    -- returns either Integer or Float
> [...]
>
> This looks awful to me.

Well, I didn't say I would like that. But the OP asked for the ad-hoc
creation of anonymous tuples, as in

   function Calculate(A, B, C: Integer; D, E, F: Float)
     return (Integer or Float);

(without actually suggesting a specific syntax; the syntax is mine), and 
my point was, that if you want tuples for Ada, you should ask to define 
them as proper types, rather than as ad-hoc anonymous types.

Stefan

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-08-11 10:53, Stefan.Lucks@uni-weimar.de wrote:
> On Fri, 11 Aug 2017, Dmitry A. Kazakov wrote:
> 
>>>    function Calculate(A, B, C: Integer; D, E, F: Float) return Numeric;
>>>    -- returns either Integer or Float
>> [...]
>>
>> This looks awful to me.
> 
> Well, I didn't say I would like that. But the OP asked for the ad-hoc
> creation of anonymous tuples, as in
> 
>    function Calculate(A, B, C: Integer; D, E, F: Float)
>      return (Integer or Float);
> 
> (without actually suggesting a specific syntax; the syntax is mine), and 
> my point was, that if you want tuples for Ada, you should ask to define 
> them as proper types, rather than as ad-hoc anonymous types.

I don't disagree but types must have meaning. In some cases they don't. 
And why the tuple used in arguments:

    A, B, C: Integer; D, E, F: Float

does not need to have a type? To me tuples are more about handling 
assorted lists like arguments are results.

Also there are many co-types which need not to be named. To name few

    T'Base
    T'Class
    T'Access
    T'Interface
    T'Public_Parent (N)
    T'Array_Element
    T'Array_Index (D)
    T'Array_Range (D)
    T'Record_Member (N)
    T'Discriminants_List
    T'Access_Target_Type
    T'Access_Pool_Type
    T'Arguments_List
    T'Result_Type

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[AdaMagica]

Am Freitag, 11. August 2017 10:34:41 UTC+2 schrieb Dmitry A. Kazakov:
> A similar case is dimensioned arithmetic which is closer to what you 
> proposed when the dimension is packed in a discriminant rather than tag. 
> Here again we want statically known discriminants eliminated and pure 
> dimension checks in static cases.

See here a critical review of what has been done by AdaCore:

http://www.christ-usch-grein.homepage.t-online.de/Ada/Dimension/Physical_units_with_GNAT_GPL_2013-AUJ35.1.pdf

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Jacob Sparre Andersen]

Dmitry A. Kazakov wrote:

>>     type May_Be_Integer(Valid: Boolean := True) is constant record
>>       case Valid is
>>      when True  => Value: Integer;
>>      when False => null;
>>       end case;
>>     end record;
>
> Hmm, isn't it simply a subtype:
>
>    type May_Be_Integer (Valid: Boolean := True) is record
>       case Valid is
>          when True =>
>             Value : Integer;
>          when False =>
>             null;
>       end case;
>    end record;
>
>    subtype Surely_Integer is May_Be_Integer (True);

No.  "constant" must mean that both "Valid" and "Value" are immutable.

I'm not sure why we should need constant/immutable types, but I'm open
to learn.

Greetings,

Jacob
-- 
PNG: Pretty Nice Graphics

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Alejandro R. Mosteo]

On 11/08/17 08:24, G.B. wrote:
> On 11.08.17 03:31, Randy Brukardt wrote:
>> Speaking of evil, anonymous types are evil. Why is it hard to declare a
>> record type for this purpose?
> 
> A record is mutable, a tuple isn't meant to be mutable
> (i.e., can't update it's components). Also, it is harder
> to start from good types and names than to use a continous
> improvement process that finds them.
> 
> A tuple language will first let programmers write
> 
>     return Integer, Float,
> or
>     -> (Int, Float)
> or
>    int, float function;
> 
> and then let them use these values "generically": anything that
> takes an integer and a floating point value will work:
> argument pattern matching, or referring to Fst and
> Snd component using built-in ".0" and ".1" suffix notation.
> It then does not matter whether the integers and FPT values
> really are of types (apples, prices) or (oranges, weight)...
> 
> It is convenient.

Having used it profusely in matlab, it is indeed convenient, specially 
paired with things like "~" (ignore one of the returned values). But:

> It is prone to logical errors, because it'll make lazy
> programmers stop making good use of the type system, i.e.
> it eases accidentally mistaking apples for oranges,
> or price for weight, IOW make reasonably errors.

This.

Alex.

> 
> It is, therefore, a very viable scheme of language based
> supportbusiness.
> 
> 
> 
> OTOH, if (int, float) tuples used in the implementation
> of an ADT only, then the convenience might loose some of
> the disadvantages of depending on tuples.
> 

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Johan Söderlind Åström]

I want the next version to include GNAT attributes.
The X'Range_Length has been useful for me instead of writing (X'Last - X'First + 1)

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Shark8]

On Wednesday, August 9, 2017 at 9:24:40 AM UTC-6, Johan Söderlind Åström wrote:
> I want the next version to include GNAT attributes.
> The X'Range_Length has been useful for me instead of writing (X'Last - X'First + 1)

If we had first-class ranges we could do X'Range'Legth...

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-08-09 19:23, Shark8 wrote:
> On Wednesday, August 9, 2017 at 9:24:40 AM UTC-6, Johan Söderlind Åström wrote:
>> I want the next version to include GNAT attributes.
>> The X'Range_Length has been useful for me instead of writing (X'Last - X'First + 1)
> 
> If we had first-class ranges we could do X'Range'Legth...

True but that immediately brings a more general issue of related types up:

- Element
- Index
- Index set (range)
- Tuple of indices (flat index within n-D array)
- Tuples set (indices indicating elements in an n-D array)
- Array
- Slice
- Subarray (plane, row, column)
- Elements set (diagonals)
- Co-array (e.g. transponse)

This, again, is all about empowering the type system.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Jacob Sparre Andersen]

Johan Söderlind Åström wrote:

> The X'Range_Length has been useful for me instead of writing
> (X'Last - X'First + 1)

So you basically want 'Length to work for discrete subtypes like it does
for arrays?

I've wanted that occasionally.  It would be a nice improvement.

Greetings,

Jacob
-- 
Better save than sorry!

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[faryumg]

For me, Ada is a wonderful language for my engineering calculations, from small, quick one-offs to large simulations of many thousands of lines. (The thick Ada bindings and extensions to the plotter PLplot are incredibly useful here.) Some people would instead use Octave or Matlab but I find these languages inadequate for a number of reasons.

I have built my own tools including operator overloads for real, imaginary, complex, and integer scalars, mating with overloads for vector and matrix types. I have overloads for many scalar math functions already included in Ada along with a number of other tools useful to the engineer and scientist. Consequently, I can type a line of mathematical code that is more readable than Matlab code, thanks in part to strong typing.

Oddly missing from Ada, and commented about on this list before, is why brackets [ ] aren't used for array indexing. This is highly suggestive of the mathematical notation for vector and matrices and would improve readability and remove the confusion of what is an array and what is a function.

Also missing is multidimensional array slicing. This really needs to be added to remove errors of users' attempts to do something similar using ad hoc methods.

Ada 2005 added standardized real-valued vectors and matrices and a little bit of linear algebra. Awesome. What is really needed is native bindings to full high-level libraries of linear algebra: BLAS, LAPACK, possibly via Atlas. These are super stable and have been used for decades in Fortran and C. Bindings exist but are too hard to grok and not built-in. Also, high-level math and special function libraries are needed such as the GNU Scientific Library or even the Octave libraries. Some will question whether these are appropriate to include in the language proper and that is a valid conversation. But it is things like this that will help get Ada away from the "embedded" stereotype.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Simon Wright]

faryumg@gmail.com writes:

> Ada 2005 added standardized real-valued vectors and matrices and a
> little bit of linear algebra. Awesome. What is really needed is native
> bindings to full high-level libraries of linear algebra: BLAS, LAPACK,
> possibly via Atlas. These are super stable and have been used for
> decades in Fortran and C. Bindings exist but are too hard to grok and
> not built-in.

My Ada 2005 Math Extensions project[1] is a minimal extension of the
Annex G facilities for asymmetric and non-Hermitian matrices. Other than
that, there are at least

* AdaLAPACK[2], which uses automatically (mainly?) generated bindings to
  the LAPACK sources, and uses convention Fortran (last code update 5
  years ago).

* Ada-Lapack[3], which contains native code mainly generated by machine
  translation (last update 4 years ago).

[1] http://gnat-math-extn.sourceforge.net/index.html/
[2] https://sourceforge.net/projects/adalapack/
[3] https://sourceforge.net/projects/ada-lapack/

> Also, high-level math and special function libraries are needed such
> as the GNU Scientific Library or even the Octave libraries. Some will
> question whether these are appropriate to include in the language
> proper and that is a valid conversation. But it is things like this
> that will help get Ada away from the "embedded" stereotype.

I suppose such an effort could be under the auspices of the (archived)
Numerics Working Group[4]? or a reconstituted version? Perhaps something
like the Ada Bindings WG[5]?

[4] http://www.sigada.org/wg/numwg/numwg.html
[5] http://www.sigada.org/wg/abwg/abwg.html

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Johan Söderlind Åström]

On Tuesday, August 29, 2017 at 1:49:15 AM UTC+2, far...@gmail.com wrote:
> For me, Ada is a wonderful language for my engineering calculations, from small, quick one-offs to large simulations of many thousands of lines. (The thick Ada bindings and extensions to the plotter PLplot are incredibly useful here.) Some people would instead use Octave or Matlab but I find these languages inadequate for a number of reasons.
> 
> I have built my own tools including operator overloads for real, imaginary, complex, and integer scalars, mating with overloads for vector and matrix types. I have overloads for many scalar math functions already included in Ada along with a number of other tools useful to the engineer and scientist. Consequently, I can type a line of mathematical code that is more readable than Matlab code, thanks in part to strong typing.
> 
> Oddly missing from Ada, and commented about on this list before, is why brackets [ ] aren't used for array indexing. This is highly suggestive of the mathematical notation for vector and matrices and would improve readability and remove the confusion of what is an array and what is a function.
> 
> Also missing is multidimensional array slicing. This really needs to be added to remove errors of users' attempts to do something similar using ad hoc methods.
> 
> Ada 2005 added standardized real-valued vectors and matrices and a little bit of linear algebra. Awesome. What is really needed is native bindings to full high-level libraries of linear algebra: BLAS, LAPACK, possibly via Atlas. These are super stable and have been used for decades in Fortran and C. Bindings exist but are too hard to grok and not built-in. Also, high-level math and special function libraries are needed such as the GNU Scientific Library or even the Octave libraries. Some will question whether these are appropriate to include in the language proper and that is a valid conversation. But it is things like this that will help get Ada away from the "embedded" stereotype.


I agree with everything. And embedded system still need to have high performant code due to power and volume restriction. Embedded is not just PID or boolean logic that turn some relays.

I do not like MATLAB, I think it is not a mature language. With the right libraries Ada can be used just like python or MATLAB. It is never about the language. The libraries is the deciding factor of productivity. The language comes into play when the code grows large. And more libraries reduces the amount of code in a project.

People have laughed at me when I mention Ada and OpenGL. I which I could prove them wrong, and I can not due to "embedded/critical mission" stereotype. Even if I say there is multiple OpenGL bindings available.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Vincent DIEMUNSCH]

Le mardi 29 août 2017 01:49:15 UTC+2, far...@gmail.com a écrit :
> For me, Ada is a wonderful language for my engineering calculations.
> I have built my own tools including operator overloads for real, imaginary, complex, and integer scalars, > mating with overloads for vector and matrix types.

Would you be ready to share this ?

> Oddly missing from Ada, and commented about on this list before, is why brackets [ ] aren't used for 
> array indexing.

True. This is really not understandable in 2017 ! I think it comes from the DoD's Steelman requirements to have the shortest number of ASCII characters. But that was not their best idea and Ada has now taken the opposite path in allowing Unicode identifiers..

Regarding arrays I propose the following evolutions :

1. Allow discriminants in array types (if they are not unconstrained array types).
type Matrix (M,N : Positive) is array (1 .. M, 1 .. N) of Long_Float.

2. Allow a special indexing syntax, that I called relative indexing. Adding a Unary + operator (that has no other purpose ! :-) ) in front of an index expression means starting from A'First. Unary plus would then become the ordinal operator.

 A(+i) simply means A(A'First +i). 

This is an elegant and above all retro-compatible way of permitting to start every array at zero which is easier in algorithms, cf. Dijkstra (EWD 831 "Why numbering should start at zero") or Wirth's Oberon. Using A'Range is not possible outside the basic cases. Anytime you want to compute indexes you fall on relative indexes from 0 to N-1 and convoluted expressions that add or suppress A'First.

> Also missing is multidimensional array slicing. 
But above dimension 2 one needs Column Major Order as Fortran or Matlab...  And not Row Major Order as C or Pascal. Otherwise a slice from a 3 dimension arrays is not binary compatible with a 2 dimensions array.  This is very well known but has never been corrected. Hence the problems between LAPACK and the Ada «Generic_Arrays».


> Some will question whether these are appropriate to include in the language proper and that is a valid
> conversation. But it is things like this that will help get Ada away from the "embedded" stereotype.

I totally agree.

Regards,

Vincent

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-09-02 12:49, Vincent DIEMUNSCH wrote:

> Regarding arrays I propose the following evolutions :
> 
> 1. Allow discriminants in array types (if they are not unconstrained array types).
> type Matrix (M,N : Positive) is array (1 .. M, 1 .. N) of Long_Float.

Yes, all types must be allowed to have discriminants. However, I would 
treat array bounds as discriminants too.

The problem is removing discriminants upond constraining. This seems to 
be why discriminants were not allowed in the first place.

> 2. Allow a special indexing syntax, that I called relative indexing.
> Adding a Unary + operator (that has no other purpose ! :-) ) in front of
> an index expression means starting from A'First. Unary plus would then
> become the ordinal operator.
> 
>   A(+i) simply means A(A'First +i).

A better approach is to allow positional indexing by universal integer 
offset (0-based) or position (1-based).

    A [N] means N-th element
    A'Span would be a positional equivalent to A'Range

Offset vs. position is up to debate.

And C-freaks will finally have their ugly square brackets back! (:-))

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Johan Söderlind Åström]

> 2. Allow a special indexing syntax, that I called relative indexing. Adding a Unary + operator (that has no other purpose ! :-) ) in front of an index expression means starting from A'First. Unary plus would then become the ordinal operator.
> 
>  A(+i) simply means A(A'First +i). 
> 
> This is an elegant and above all retro-compatible way of permitting to start every array at zero which is easier in algorithms, cf. Dijkstra (EWD 831 "Why numbering should start at zero") or Wirth's Oberon. Using A'Range is not possible outside the basic cases. Anytime you want to compute indexes you fall on relative indexes from 0 to N-1 and convoluted expressions that add or suppress A'First.

I usually cast a array to array that starts at zero index when implementing algorithms.

type Integer_Array is array (Integer range <>) of Integer;

procedure Algorithm (Item : Integer_Array) is
  use Ada.Assertions;
  X : Integer_Array (0 .. Item'Length - 1) with Address => Item'Address;
begin
  for I in 0 .. Item'Length - 1 loop
    Assert (X (I) = Item (Item'First + I));
  end loop;
end Algorithm;

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Vincent DIEMUNSCH]

Le samedi 2 septembre 2017 13:21:28 UTC+2, Johan Söderlind Åström a écrit :

> I usually cast a array to array that starts at zero index when implementing algorithms.
> 
> type Integer_Array is array (Integer range <>) of Integer;
> 
> procedure Algorithm (Item : Integer_Array) is
>   use Ada.Assertions;
>   X : Integer_Array (0 .. Item'Length - 1) with Address => Item'Address;

Very clever ! That nice hack shows that some of us have that same concern !
Regards,

Vincent

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Jeffrey R. Carter]

On 09/02/2017 01:21 PM, Johan Söderlind Åström wrote:
> 
> type Integer_Array is array (Integer range <>) of Integer;
> 
> procedure Algorithm (Item : Integer_Array) is
>    use Ada.Assertions;
>    X : Integer_Array (0 .. Item'Length - 1) with Address => Item'Address;
> begin
>    for I in 0 .. Item'Length - 1 loop
>      Assert (X (I) = Item (Item'First + I));
>    end loop;
> end Algorithm;

type Ptr is access Integer_Array;

P : Ptr := new Integer_Array (-1 .. Integer'Last);

Algorithm (P.all);

-- 
Jeff Carter
It's better to be root than to reboot.
119

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Johan Söderlind Åström]

On Saturday, September 2, 2017 at 7:19:47 PM UTC+2, Jeffrey R. Carter wrote:
> On 09/02/2017 01:21 PM, Johan Söderlind Åström wrote:
> > 
> > type Integer_Array is array (Integer range <>) of Integer;
> > 
> > procedure Algorithm (Item : Integer_Array) is
> >    use Ada.Assertions;
> >    X : Integer_Array (0 .. Item'Length - 1) with Address => Item'Address;
> > begin
> >    for I in 0 .. Item'Length - 1 loop
> >      Assert (X (I) = Item (Item'First + I));
> >    end loop;
> > end Algorithm;
> 
> type Ptr is access Integer_Array;
> 
> P : Ptr := new Integer_Array (-1 .. Integer'Last);
> 
> Algorithm (P.all);
> 
> -- 
> Jeff Carter
> It's better to be root than to reboot.
> 119

I tried to run that but it raises STORAGE_ERROR : "object is too large" at line P : Ptr.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

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

"Johan Söderlind Åström" <johaa1993@gmail.com> wrote in message 
news:338b355a-dee4-4c73-b00e-09d9a8430fb1@googlegroups.com...
...
>procedure Algorithm (Item : Integer_Array) is
>  use Ada.Assertions;
>  X : Integer_Array (0 .. Item'Length - 1) with Address => Item'Address;

The use of address clauses other than for interfacing is evil (and not 
guaranteed to work in the case of overlaying Ada code). Don't do that.

You can change the bounds of an array with a type conversion to a 
constrained subtype, which is likely to be cheaper and not break if you 
change compilers.

                            Randy.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Johan Söderlind Åström]

On Sunday, September 3, 2017 at 3:30:23 AM UTC+2, Randy Brukardt wrote:
> "Johan Söderlind Åström" <johaa1993@gmail.com> wrote in message 
> news:338b355a-dee4-4c73-b00e-09d9a8430fb1@googlegroups.com...
> ...
> >procedure Algorithm (Item : Integer_Array) is
> >  use Ada.Assertions;
> >  X : Integer_Array (0 .. Item'Length - 1) with Address => Item'Address;
> 
> The use of address clauses other than for interfacing is evil (and not 
> guaranteed to work in the case of overlaying Ada code). Don't do that.
> 
> You can change the bounds of an array with a type conversion to a 
> constrained subtype, which is likely to be cheaper and not break if you 
> change compilers.
> 
>                             Randy.

What do you mean with cheaper? Faster execution?, Less memory footprint?
Which compiler will break my code?

I do not know how Ada accesses a array element internally. But a zero indexed array must be cheaper than a custom indexed array, see:

Accessing nth element from zero indexed array:
(base_address + index*element_size).

Accessing nth element from a custom indexed array:
(base_address + (index - first)*element_size)

I do not think that accessing a element from a array is a complicated thing and starting from a zero indexed array is even simpler, then why would a compiler not guarantee such a simple thing to work?

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Jacob Sparre Andersen]

Johan Söderlind Åström wrote:

> I do not think that accessing a element from a array is a complicated
> thing and starting from a zero indexed array is even simpler, then why
> would a compiler not guarantee such a simple thing to work?

One possibility is that constrained and unconstrained subtypes of the
same subtype may have slightly different memory layouts.

Or maybe the bounds of the array are stored at the beginning of the
memory structure (where else can we put them?), and your overlaying
changes the subtype of the (possibly constant) array passed to it, by
overwriting the bounds.

Randy has written a part of at least one Ada compiler, so he can
probably come up with some more concrete examples.

Greetings,

Jacob
-- 
"Good enough for physics" -- Ridcully

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Johan Söderlind Åström]

On Wednesday, September 6, 2017 at 5:57:34 PM UTC+2, Jacob Sparre Andersen wrote:
> Johan Söderlind Åström wrote:
> 
> > I do not think that accessing a element from a array is a complicated
> > thing and starting from a zero indexed array is even simpler, then why
> > would a compiler not guarantee such a simple thing to work?
> 
> One possibility is that constrained and unconstrained subtypes of the
> same subtype may have slightly different memory layouts.
> 
> Or maybe the bounds of the array are stored at the beginning of the
> memory structure (where else can we put them?), and your overlaying
> changes the subtype of the (possibly constant) array passed to it, by
> overwriting the bounds.
> 
> Randy has written a part of at least one Ada compiler, so he can
> probably come up with some more concrete examples.
> 
> Greetings,
> 
> Jacob
> -- 
> "Good enough for physics" -- Ridcully

I did not thought of that. Now I have been trying to collide First and Last but I can not seem to do it with GNAT, the variables always represent their specified boundary even with shared memory. GNAT folks probably implemented something in case of me writing reckless code.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

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

"Johan Söderlind Åström" <johaa1993@gmail.com> wrote in message 
news:e9e2556d-9b23-4e7f-9058-776dd506f73c@googlegroups.com...
>On Sunday, September 3, 2017 at 3:30:23 AM UTC+2, Randy Brukardt wrote:
>> "Johan Söderlind Åström" <johaa1993@gmail.com> wrote in message
>> news:338b355a-dee4-4c73-b00e-09d9a8430fb1@googlegroups.com...
>> ...
>> >procedure Algorithm (Item : Integer_Array) is
>> >  use Ada.Assertions;
>> >  X : Integer_Array (0 .. Item'Length - 1) with Address => Item'Address;
>>
>> The use of address clauses other than for interfacing is evil (and not
>> guaranteed to work in the case of overlaying Ada code). Don't do that.
>>
>> You can change the bounds of an array with a type conversion to a
>> constrained subtype, which is likely to be cheaper and not break if you
>> change compilers.

>What do you mean with cheaper? Faster execution?, Less memory footprint?

Both. The address clause adds an extra level of indirection that the type 
conversion doesn't necessarily add. (In Janus/Ada, the conversion would 
remove or replace the bounds descriptor, making the access cost identically 
to the original array accesses; an address clause always adds a level of 
indirection.) But I forgot about the cost to copy the array (usually 
insignificant, but not always).

>Which compiler will break my code?

Any compiler could; 13.3(16) says that it only required for 'Address to have 
a "useful result" if the prefix is aliased or by-reference (neither which is 
true for the parameter Item of type Integer_Array). Ergo, such a usage is 
not portable (even if many compilers allow it). Dunno if it will actually 
break in any implementation, but it is best to avoid these sorts of 
non-portable things.

As discussed,
   procedure Algorithm (Item : Integer_Array) is
        subtype Zero_Array is Integer_Array (0 .. Item'Length - 1);
        X : constant Zero_Array := Zero_Array (Item);

has the same effect (modulo probably making an extra copy of the data), is 
always going to work (assuming Item'Length is short enough to fit in the 
index subtype - the point of Stephen Leake), doesn't need any assertions, 
and is much easier to read.

>I do not know how Ada accesses a array element internally. But a zero
>indexed array must be cheaper than a custom indexed array, see:
>
>Accessing nth element from zero indexed array:
>(base_address + index*element_size).
>
>Accessing nth element from a custom indexed array:
>(base_address + (index - first)*element_size)

In most cases, that is not an issue. Whenever Item'First is static (that is 
known to the compiler), the compiler will fold it into the base address so 
the cost is the same. (And there is a cost to rebasing the array, no matter 
how you do it.)

Specifically, the general form:

(base_address + (index - first)*element_size)
is the same as:
(base_address - (first*element_size) + (index*element_size))

In the usual case, when both first and element_size are known to the 
compiler, the code generation will be

((base_address - (first*element_size)) + (index*element_size))

with the first part calculated by the compiler and generated as a single 
item. The only runtime operations are the + and second *, just as in the 
zero-based form.

Moral: Compilers can eliminate most of the supposedly extra costs; it pays 
only to worry about those that are known (via experiment) to be significant 
in the runtime of a program. (The 90-10 rule says that the performance of 
90% of the code has no effect on the result.)

Moral2: Premature optimization is the root of much evil. Only worry about 
the performance of code that is demonstrably too slow. Otherwise, 
readability and maintainability are the most important goals after 
correctness. YMMV.

                                Randy.



I do not think that accessing a element from a array is a complicated thing 
and starting from a zero indexed array is even simpler, then why would a 
compiler not guarantee such a simple thing to work? 

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Johan Söderlind Åström]

> >What do you mean with cheaper? Faster execution?, Less memory footprint?
> 
> Both. The address clause adds an extra level of indirection that the type 
> conversion doesn't necessarily add. (In Janus/Ada, the conversion would 
> remove or replace the bounds descriptor, making the access cost identically 
> to the original array accesses; an address clause always adds a level of 
> indirection.) But I forgot about the cost to copy the array (usually 
> insignificant, but not always).

Copy the entirety of an array is not insignificant, it is doubling the memory footprint which is not less.

> Moral2: Premature optimization is the root of much evil. Only worry about 
> the performance of code that is demonstrably too slow. Otherwise, 
> readability and maintainability are the most important goals after 
> correctness. YMMV.

It is not about optimization, it is about simplicity.

A (I) + B (I) is more simpler than A (A'First + I) + B (B'First + I) to read.
No copy is more simpler than a copy.

> Moral: Compilers can eliminate most of the supposedly extra costs; it pays 
> only to worry about those that are known (via experiment) to be significant 
> in the runtime of a program. (The 90-10 rule says that the performance of 
> 90% of the code has no effect on the result.)

Near 100% of code is using core functionality of the language like accessing array element.

> In most cases, that is not an issue. Whenever Item'First is static (that is 
> known to the compiler), the compiler will fold it into the base address so 
> the cost is the same. (And there is a cost to rebasing the array, no matter 
> how you do it.)
> 
> Specifically, the general form:
> 
> (base_address + (index - first)*element_size)
> is the same as:
> (base_address - (first*element_size) + (index*element_size))
> 
> In the usual case, when both first and element_size are known to the 
> compiler, the code generation will be
> 
> ((base_address - (first*element_size)) + (index*element_size))
> 
> with the first part calculated by the compiler and generated as a single 
> item. The only runtime operations are the + and second *, just as in the 
> zero-based form.

That is a good optimization and I hope it is not considered a premature optimization because that is optimizing core functionality of the language which will affect near 100% of all Ada code. Luckily you showed me that I do not have to do it manually.

So the simplest way to access a element in Ada is to write: 
  A : Integer_Array (-5 .. 5);
  A (A'First + I);
Which has the same complexity as in C:
  int A[11];
  A [I];
Where I starts from zero.

I would really like to write, for a example:
  (A (I) + B (I)) * C (I) / (D (I) ** E (I));
instead of:
  (A (A'First + I) + B (B'First + I)) * C (C'First + I) / (D (D'First + I) ** E (E'First + I));
... you know for obvious reason.

I appreciate you bringing up the issues with an explanation.
I hope you understand my issues as well :)

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-09-08 23:04, Johan Söderlind Åström wrote:

> I would really like to write, for a example:
>    (A (I) + B (I)) * C (I) / (D (I) ** E (I));
> instead of:
>    (A (A'First + I) + B (B'First + I)) * C (C'First + I) / (D (D'First + I) ** E (E'First + I));
> ... you know for obvious reason.

Since these things are usually happen in a loop the compiler might have 
issues with eliminating index checks. Because you would replace

    for I in A'Range loop
       ... (A (I) + B (I)) * C (I) / (D (I) ** E (I)) ...
    end loop;

with

    for I in 0..A'Length - 1 loop
       ... (A (I) + B (I)) * C (I) / (D (I) ** E (I)) ...
    end loop;

BTW, the code usually looks even uglier:

    for I in A'Range loop
       ... (A (I) + B (I + B'First - A'First)) *
           C (I + C'First - A'First) / (D (I + D'First - A'First) **
           E (I + E'First - A'First)) ...
    end loop;

However, it is easier to optimize, I guess.

To me it is the loop, which should have a form to walk through several 
congruent arrays. E.g. using conventional mathematical notation:

    for I,J,K,L,M in A'Range,B'Range,C'Range,D'Range,E'Range loop
       ... (A (I) + B (J)) * C (K) / (D (L) ** E (M)) ...
    end loop;

Positional indexing is another issue. Position /= index. Position is 
always an ordinal number. It is the same type for all array types. Array 
index is any discrete type, not necessarily integer, and maybe specific 
for each array type.

Ordinal numbers can be used for indexing using S'Val () attribute where 
S is the array index subtype. It is extremely ugly but useful when the 
array index type is not numeric.

I am for adding positional array element access. But it must have a 
clearly distinct syntax. E.g. either by using square brackets:

    A [Position]

or per attribute:

    A'Nth (Position)

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Johan Söderlind Åström]

On Friday, September 8, 2017 at 11:46:28 PM UTC+2, Dmitry A. Kazakov wrote:

> I am for adding positional array element access. But it must have a 
> clearly distinct syntax. E.g. either by using square brackets:
> 
>     A [Position]

I like that!

Type safety:

      for I in Ordinal_Number range A'Ordinal_Range loop
         ... (A [I] + B [I]) * C [I] / (D [I] ** E (E'First + Integer (I))) ...
      end loop;

      for I in Ordinal_Number range A'Ordinal_First .. A'Ordinal_Last loop
         ... (A [I] + B [I]) * C [I] / (D [I] ** E (E'First + Integer (I))) ...
      end loop;

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Johan Söderlind Åström]

> Ordinal numbers can be used for indexing using S'Val () attribute where 
> S is the array index subtype. It is extremely ugly but useful when the 
> array index type is not numeric.

Tested this now and it does not work on ranged types.

    subtype T is Integer range 5 .. 6;
    Put (T'Val (1)); -- prints 1

    type R is (R1, R2, R3);
    Put (R'Val (1)'Image); -- prints R2

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-09-16 14:49, Johan Söderlind Åström wrote:
>> Ordinal numbers can be used for indexing using S'Val () attribute where
>> S is the array index subtype. It is extremely ugly but useful when the
>> array index type is not numeric.
> 
> Tested this now and it does not work on ranged types.

Yes, AFAIK, for integer types I'Pos(X) = X.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[AdaMagica]

> Yes, AFAIK, for integer types I'Pos(X) = X.

'Pos attribute result is of type universal_integer. Thus there is an implicit type conversion in the equality above.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-09-17 13:05, AdaMagica wrote:
>> Yes, AFAIK, for integer types I'Pos(X) = X.
> 
> 'Pos attribute result is of type universal_integer. Thus there is an
> implicit type conversion in the equality above.

Yes, but the point is that it might be somewhat perplexing to encounter that

    Integer'Pos(-1) = -1

It is clear what was the motivation behind this result. Yet a naive 
reader would rather expect

    Integer'Pos(-1) = -1 - Integer'First

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Jeffrey R. Carter]

On 09/08/2017 11:04 PM, Johan Söderlind Åström wrote:
> 
> Copy the entirety of an array is not insignificant, it is doubling the memory footprint which is not less.

Unless a single array is effectively the entire memory usage of your program, 
copying a single array is hardly "doubling the memory footprint". For most 
programs, it is, in fact, an insignificant increase in the memory usage of the 
program.

> A (I) + B (I) is more simpler than A (A'First + I) + B (B'First + I) to read.

No, A (I) + B (I) is less simple, because it doesn't mean A (I) + B (I), it 
really means Real_A (Real_A'First + I) + Real_B (Real_B'First + I), and the 
reader has to remember that to understand what the code is doing. The more the 
reader has to remember, the greater the cognitive load of the code, and a 
significant part of S/W engineering is aimed at reducing the cognitive load. If 
you write Real_A (Real_A'First + I) + Real_B (Real_B'First + I) then the code 
actually does what it says and you haven't increased the cognitive load.

But even better is a common paradigm for when you have to mix arrays with 
mis-matched index ranges (which should not be common). A common paradigm is well 
enough understood by most readers that it doesn't increase the difficulty of 
understanding the code. In my experience, in Ada, that paradigm is

for i in A'range loop
    ... A (I) + B (I + B'First - A'First);

> No copy is more simpler than a copy.

Again, if a copy is easier to understand than the machinations needed to avoid a 
copy, then a copy is simpler. This is especially true when the machinations are 
not portable and someone has to understand why the code no longer works.

> 
> So the simplest way to access a element in Ada is to write:
>    A : Integer_Array (-5 .. 5);
>    A (A'First + I);

No, the simplest way is to write

    A (I)

> I would really like to write, for a example:
>    (A (I) + B (I)) * C (I) / (D (I) ** E (I));
> instead of:
>    (A (A'First + I) + B (B'First + I)) * C (C'First + I) / (D (D'First + I) ** E (E'First + I));

The real question here is why the design has all these parallel arrays with the 
same length but different index ranges.

-- 
Jeff Carter
"[M]any were collected near them, ... to
enjoy the sight of a dead young lady, nay,
two dead young ladies, for it proved twice
as fine as the first report."
Persuasion
155

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Johan Söderlind Åström]

> No, A (I) + B (I) is less simple, because it doesn't mean A (I) + B (I), it 
> really means Real_A (Real_A'First + I) + Real_B (Real_B'First + I), and the 
> reader has to remember that to understand what the code is doing. The more the 
> reader has to remember, the greater the cognitive load of the code, and a 
> significant part of S/W engineering is aimed at reducing the cognitive load. If 
> you write Real_A (Real_A'First + I) + Real_B (Real_B'First + I) then the code 
> actually does what it says and you haven't increased the cognitive load.

Yes you are right. Algorithms has to be taught in the Ada realm.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

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

"Johan Söderlind Åström" <johaa1993@gmail.com> wrote in message 
news:9d4274d7-5ad1-42d0-8ec3-de822e28ec6c@googlegroups.com...
>> Unless a single array is effectively the entire memory usage of your 
>> program,
>> copying a single array is hardly "doubling the memory footprint". For 
>> most
>> programs, it is, in fact, an insignificant increase in the memory usage 
>> of the
>> program.
>
> If you have one array and then copy it, will you have two arrays or one 
> array?
> If somehow by logic you would happen to have two arrays after you copy, 
> will that be double as many arrays as before?
> Does a array have a memory footprint? If no then you are correct 0*2 = 0.

(BTW, I've been on vacation, thus the late answers.)

The above sounds like nonsense to me. Probably because you aren't specifying 
"object" or "type", and thus "array" by itself is unclear.

Assuming you mean "array object", yes, of course after copying you'll have a 
new array. Depending on what you're doing with it, that usually doesn't 
matter. (That is, most objects are just read.) And in the situation that you 
were discussing, that copy only exists as long as the subprogram does, which 
usually isn't very long.

                                  Randy.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

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

"Johan Söderlind Åström" <johaa1993@gmail.com> wrote in message 
news:21692daf-5a52-43f0-a72a-d79e6a7dcc9f@googlegroups.com...
>> >What do you mean with cheaper? Faster execution?, Less memory footprint?
>>
>> Both. The address clause adds an extra level of indirection that the type
>> conversion doesn't necessarily add. (In Janus/Ada, the conversion would
>> remove or replace the bounds descriptor, making the access cost 
>> identically
>> to the original array accesses; an address clause always adds a level of
>> indirection.) But I forgot about the cost to copy the array (usually
>> insignificant, but not always).
>
> Copy the entirety of an array is not insignificant, it is doubling the 
> memory footprint which is not less.

The memory footprint of most arrays is insignificant. I usually do this kind 
of thing with Strings, and the typical string is only a few dozen bytes. 
Obviously, if a single array is using most of the memory on the computer, 
then you don't want to copy it. (But you're not going to pass those as a 
parameter in the first place.)

>> Moral2: Premature optimization is the root of much evil. Only worry about
>> the performance of code that is demonstrably too slow. Otherwise,
>> readability and maintainability are the most important goals after
>> correctness. YMMV.
>
> It is not about optimization, it is about simplicity.
>
> A (I) + B (I) is more simpler than A (A'First + I) + B (B'First + I) to 
> read.
> No copy is more simpler than a copy.

The use of an address clause is a red flag to any (experienced) reader that 
something weird is going on. Attempting to figure out if that is safe and 
what it means and whether it really means what is intended is going kill any 
savings in reading of the actual expressions.

...
>> with the first part calculated by the compiler and generated as a single
>> item. The only runtime operations are the + and second *, just as in the
>> zero-based form.
>
> That is a good optimization and I hope it is not considered a premature
> optimization because that is optimizing core functionality of the language
> which will affect near 100% of all Ada code. Luckily you showed me
> that I do not have to do it manually.

"premature optimization" is referring to the programmer trying to make the 
code fast before he even finds out how it performs. That doesn't refer to 
compiler optimization, which doesn't harm the understandability of the code 
(since it occurs automatically). Compilers can and do a lot of optimizations 
that aren't practical to do by hand.

But if you really need to speed up some piece of code, you have to change 
the algorithm. Robert Dewar (RIP) used to say that "most optimizations are 
disappointing"; by that he meant that all of the optimizations in the world 
(both automatic or hand-generated) will only change the performance of code 
by a small percentage - in almost all cases, less than 20%. And most code 
that is too slow needs a lot more improvement than that. Thus programmers 
tend to focus on the wrong thing much of the time (something to which I am 
not immune!).

For instance, if searching through a large array is too slow, perhaps 
introducing a hash table as an index will speed up the operation enough.

> I would really like to write, for a example:
>  (A (I) + B (I)) * C (I) / (D (I) ** E (I));
> instead of:
>  (A (A'First + I) + B (B'First + I)) * C (C'First + I) / (D (D'First + I) 
> ** E (E'First + I));
> ... you know for obvious reason.

In a case like this, I'd expect that all of the arrays are constrained with 
the same range and thus there is no need to bias any of the indexes. You do 
know that you can declare constrained subtypes such that the array 
parameters of a routine have known bounds, right? Most of my routines use 
constrained arrays and thus don't need this sort of adjustment.

That is, if you know that all of these arrays have the same bounds (and they 
most likely do, they surely need the same length in a formula like this), 
then
     for I in A'Range loop
         F(I) := (A (I) + B (I)) * C (I) / (D (I) ** E (I));
     end loop;

will do the trick without adjusting any bounds.

You could declare the arrays like:
      MAX_LEN : constant := 10;
      type Integer_Array is array (Positive range <>) of Float;
      subtype My_IA is Integer_Array (0 .. MAX_LEN);

      A, B, C : My_IA;

     procedure Mult (A, B : in My_IA; C : out My_IA) is
     begin
          for I in My_IA'Range loop
               C(I) := A(I) * B(I);
          end loop;
     end Mult;

You can also use (in Ada 2012) a precondition or predicate to have a similar 
effect (even to force all arrays to start at 0 if that is your preference). 
Ada 2012 also has loops over the elements of an array, so there is no need 
to write indexes at all in some cases.

                                   Randy.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Johan Söderlind Åström]

> The memory footprint of most arrays is insignificant. I usually do this kind 
> of thing with Strings, and the typical string is only a few dozen bytes. 
> Obviously, if a single array is using most of the memory on the computer, 
> then you don't want to copy it. (But you're not going to pass those as a 
> parameter in the first place.)

I am not? In which way should I pass large arrays?

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

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


"Johan Söderlind Åström" <johaa1993@gmail.com> wrote in message 
news:c6bcd791-6f99-4a9a-aba1-e238b30e611e@googlegroups.com...
>> The memory footprint of most arrays is insignificant. I usually do this 
>> kind
>> of thing with Strings, and the typical string is only a few dozen bytes.
>> Obviously, if a single array is using most of the memory on the computer,
>> then you don't want to copy it. (But you're not going to pass those as a
>> parameter in the first place.)
>
> I am not? In which way should I pass large arrays?

You don't. There can only be one such array per program, so passing it as a 
parameter just adds overhead. Just use a global data structure somewhere.

                                 Randy.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[G.B.]

On 06.09.17 17:02, Johan Söderlind Åström wrote:
> I do not know how Ada accesses a array element internally. But a zero indexed array must be cheaper than a custom indexed array, see:
>
> Accessing nth element from zero indexed array:
> (base_address + index*element_size).
>
> Accessing nth element from a custom indexed array:
> (base_address + (index - first)*element_size)
>
> I do not think that accessing a element from a array is a complicated thing and starting from a zero indexed array is even simpler, then why would a compiler not guarantee such a simple thing to work?

It seems to work well the way it is?
Is it a certainty that your assumptions describe
how our processors are working?

So, I checked, starting from a naive Average function, and
another Average_0 function. Both perform the same algorithm
with the exception of the parameter types: these are,
respectively, an array type with Index range <> and
a zero-based fixed size array type. (Index starts at 0.)

This is the loop body of both functions:

       for V : Likeness of Difference loop
          Result := Result + V / Likeness'Base (Difference'Length);
       end loop;

where Likeness is like Uniformly_Distributed from
Ada.Numerics.Float_Random, and Difference is an array.

The difference in the resulting loop bodies, on Intel,
for Average and Average_0 is this, when passing options
-O2 -gnatp -fno-inline to GNAT:

L17:
	addq	$1, %rax
	movss	(%rcx,%rax,4), %xmm1
	cmpq	%rdx, %rax
	divss	%xmm2, %xmm1
	addss	%xmm1, %xmm0
	jne	L17

L45:
	movss	(%rdi), %xmm1
	addq	$4, %rdi
	cmpq	%rax, %rdi
	divss	%xmm2, %xmm1
	addss	%xmm1, %xmm0
	jne	L45

When I have the functions called 100_000 times, the calls
result in execution time of some 50 seconds for either function.

There are 6 instructions for either 0-based or free bounds.

Maybe the loop isn't sufficiently dominated by addressing
from one or two registers, given DIVSS?

But first, using a modular type as the index type in place
of a range type starting at 0, I get

L24:
	movl	%eax, %edx
	addq	$1, %rax
	subq	%rsi, %rdx
	cmpq	%rax, %rcx
	movss	(%rdi,%rdx,4), %xmm1
	divss	%xmm2, %xmm1
	addss	%xmm1, %xmm0
	jne	L24

L59:
	movss	(%rdi,%rax,4), %xmm1
	addq	$1, %rax
	cmpq	$100000, %rax
	divss	%xmm2, %xmm1
	addss	%xmm1, %xmm0
	jne	L59

Still, no difference. So, using Sum now, here is the loop body
of Sum and Sum_0:

       for V : Likeness of Difference loop
          Result := Result + Float (V);
       end loop;


L63:
	movl	%eax, %edx
	addq	$1, %rax
	subq	%rsi, %rdx
	cmpq	%rax, %rcx
	addss	(%rdi,%rdx,4), %xmm0
	jne	L63

L67:
	addss	(%rdi,%rax,4), %xmm0
	addq	$1, %rax
	cmpq	$100000, %rax
	jne	L67
	ret

This result is independent of the choice of index type.
I had expected the first block to be slower than
the second due to SUB, but was wrong, seemingly.
Durations are around 10 seconds now.

So, if I haven't made some other stupid mistake, 0-based
arrays appear to be a non-issue, at least on Intel CPUs.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

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


"Johan Söderlind Åström" <johaa1993@gmail.com> wrote in message 
news:338b355a-dee4-4c73-b00e-09d9a8430fb1@googlegroups.com...
>I usually cast a array to array that starts at zero index when implementing 
>algorithms.
OK, but just do that and don't use any overlays...

>type Integer_Array is array (Integer range <>) of Integer;
>
>procedure Algorithm (Item : Integer_Array) is
>  use Ada.Assertions;
>  X : Integer_Array (0 .. Item'Length - 1) with Address => Item'Address;

     subtype Zero_Array is Integer_Array (0 .. Item'Length - 1);
     X : Zero_Array := Zero_Array (Item);
...

                         Randy.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Alejandro R. Mosteo]

On 03/09/17 03:35, Randy Brukardt wrote:
> "Johan Söderlind Åström" <johaa1993@gmail.com> wrote in message
> news:338b355a-dee4-4c73-b00e-09d9a8430fb1@googlegroups.com...
>> I usually cast a array to array that starts at zero index when implementing
>> algorithms.
> OK, but just do that and don't use any overlays...
> 
>> type Integer_Array is array (Integer range <>) of Integer;
>>
>> procedure Algorithm (Item : Integer_Array) is
>>   use Ada.Assertions;
>>   X : Integer_Array (0 .. Item'Length - 1) with Address => Item'Address;
> 
>       subtype Zero_Array is Integer_Array (0 .. Item'Length - 1);
>       X : Zero_Array := Zero_Array (Item);

Wouldn't that possibly involve a copy? If so, would using "constant" 
guarantee a free renaming?

And is there a difference to using rename?:

X : Zero_Array renames Item;

(I was actually surprised that you can't explicitly write 
Zero_Array(Item) with renames).

Álex.

> ...
> 
>                           Randy.
> 
> 

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-09-03 12:32, Alejandro R. Mosteo wrote:

> And is there a difference to using rename?:

Yes, because renaming does not touch bounds even if explicitly required 
by the subtype.

It is clear why renaming to a subtype does not slide bounds. That is 
because Ada treat a subtype as a constraint. For the same reason it is 
not illegal have such a renaming, that appears to the reading as bound 
sliding.

What was a language design bug that the new constraint is not enforced. 
The program should raise Constraint_Error when the index is outside the 
new bounds, even if wihin the original bounds.

Surely that would be useless behavior, but that is what follows from the 
Ada's subtype definition. One cannot have both.

> (I was actually surprised that you can't explicitly write 
> Zero_Array(Item) with renames).

I am in favor of changing subtypes to be more flexible with the 
representation.

An alternative would be allowing renaming to another type:

    type Array_Type is array (Integer range <>) of Float;

    procedure Foo (A : Array_Type) is
       type Zero_Array is array (Unsigned range <>) of Float;
       B : Zero_Array renames A;

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:oogubm$1ijg$1@gioia.aioe.org...
> On 2017-09-03 12:32, Alejandro R. Mosteo wrote:
>
>> And is there a difference to using rename?:
>
> Yes, because renaming does not touch bounds even if explicitly required by 
> the subtype.

This was a bug in the Ada 83 design. It came about because Jean Ichbiah did 
not want to define "static matching" for subtypes, so instead the subtype is 
simply ignored. That turned out to be silly; Ada 95 defines "static 
matching".

Had static matching existed in Ada 83, a renames (object or subprogram) 
would have required the constraint(s), if any, to statically match. That 
would have eliminated the weird cases.

                               Randy.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

"Alejandro R. Mosteo" <alejandro@mosteo.com> wrote in message 
news:ooglev$c4u$1@dont-email.me...
> On 03/09/17 03:35, Randy Brukardt wrote:
...
>>       subtype Zero_Array is Integer_Array (0 .. Item'Length - 1);
>>       X : Zero_Array := Zero_Array (Item);
>
> Wouldn't that possibly involve a copy? If so, would using "constant" 
> guarantee a free renaming?

Yes, it involves a copy. (I thought of that after sending the message, 
should have mentioned it.)

90% of the time (and 100% of the time when I would use this, exclusively for 
Strings), the copy isn't consequential.

The remaining 10% of the time, use the original bounds (it isn't that hard).

> And is there a difference to using rename?:

Renames ignores the bounds of the renames; I explained why in the reply to 
Dmitry.

                             Randy.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Jeffrey R. Carter]

On 09/02/2017 12:49 PM, Vincent DIEMUNSCH wrote:
> 
>> Oddly missing from Ada, and commented about on this list before, is why brackets [ ] aren't used for
>> array indexing.
> 
> True. This is really not understandable in 2017 ! I think it comes from the DoD's Steelman requirements to have the shortest number of ASCII characters. But that was not their best idea and Ada has now taken the opposite path in allowing Unicode identifiers..

My first language was FORTRAN, which used parentheses. My favorite language 
before I encountered Ada was Pascal, which used brackets. So before coming to 
Ada I'd used both, and didn't care which Ada used. The origin is in the DoD's 
desire to use characters common to all their systems c. 1977. The ARG are very 
big on backwards compatibility, which is another way of saying this is very 
unlikely to change.

One thing you can do with parentheses that you can't do with brackets is replace 
a mapping function with a constant array. It's possible that this also 
influenced Ichbiah's decision.

-- 
Jeff Carter
It's better to be root than to reboot.
119

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Alejandro R. Mosteo]

On 02/09/17 18:49, Jeffrey R. Carter wrote:

> One thing you can do with parentheses that you can't do with brackets is 
> replace a mapping function with a constant array. It's possible that 
> this also influenced Ichbiah's decision.

I thought this was the actual reason, as read here in some long 
forgotten thread...

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Jeffrey R. Carter]

On 09/02/2017 12:49 PM, Vincent DIEMUNSCH wrote:
> 
>   A(+i) simply means A(A'First +i).

And so it should simply be written A (A'First + I).

What would A(+Red) mean? Indices don't have to be numeric.

A(+I) is already defined for numeric I. This would not be backward compatible, 
so it's very unlikely to happen.

Finally, keystroke-saving constructs like this, or +=, are contrary to the 
explicit design goals of the language. The ARM Introduction, under Design Goals, 
says of the design of the language that "emphasis was placed on program 
readability over ease of writing" (wording unchanged since at least Ada 83). 
Since you can write A (A'First + I), the only possible reason for your proposal 
is to save a few keystrokes. If you want fewer keystrokes, use APL.

-- 
Jeff Carter
It's better to be root than to reboot.
119

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Vincent DIEMUNSCH]

Le samedi 2 septembre 2017 19:08:48 UTC+2, Jeffrey R. Carter a écrit :
> On 09/02/2017 12:49 PM, Vincent DIEMUNSCH wrote:
> >   A(+i) simply means A(A'First +i).
> 
> What would A(+Red) mean? Indices don't have to be numeric.

But an array index needs to be isomorphic to an Integer. It's an array ! Not a dictionnary, or a hash table. 


> A(+I) is already defined for numeric I. This would not be backward compatible, 
> so it's very unlikely to happen.

Sure, it is not fully backward compatible. But by the way, only the absence of any evolution is 100% backward compatible, isn't it ?

> The only possible reason for your proposal is to save a few keystrokes.
No. It was realy to improve readability by having a shorter and more elegant syntax. But that was a misatke, I recognize :-). Square brackets as Dimitry proposed are much better ! 

> "If you want fewer keystrokes, use APL."
:-). Ok, but the argument, always used to defend the verbose syntax of Ada, is a little bit weak, because we use high level languages precisely to write less code !

Regards,

Vincent

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Egil H H]

On Wednesday, September 6, 2017 at 6:38:05 PM UTC+2, Vincent DIEMUNSCH wrote:
> > "If you want fewer keystrokes, use APL."
> :-). Ok, but the argument, always used to defend the verbose syntax of Ada, is a little bit weak, because we use high level languages precisely to write less code !
> 

No, to write readable, maintainable and safer code, with fewer bugs.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

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

"Vincent DIEMUNSCH" <vincent.diemunsch@gmail.com> wrote in message 
news:7d014624-d143-4564-abfa-802534693644@googlegroups.com...
Le samedi 2 septembre 2017 19:08:48 UTC+2, Jeffrey R. Carter a écrit :

...
>> What would A(+Red) mean? Indices don't have to be numeric.
>
>But an array index needs to be isomorphic to an Integer. It's an array ! 
>Not
>a dictionnary, or a hash table.

Why? In Ada 2012, if A is a hashed map, A(Red) is exactly a reference into 
hash table. (Yes, this is formally a function call, but it points out the 
continum of mapping that goes from a basic array object, thru a user-defined 
indexed object, to a function call -- all forms of mapping.)

...
>> A(+I) is already defined for numeric I. This would not be backward 
>> compatible,
>> so it's very unlikely to happen.
>
>Sure, it is not fully backward compatible. But by the way, only the absence 
>of any
>evolution is 100% backward compatible, isn't it ?

Not really true, there is a lot that can be done with pure extensions 
(think, for instance, conditional expressions in Ada 2012 -- their addition 
has no effect on existing Ada 95 code).

There are plenty of uses of unary "+" in existing code, changing the meaning 
would silently break such code -- the worst kind of incompatibility. That we 
would do only for a critical issue (like composition of record "=", and that 
was very controversal, we made the incompatible change only because we 
couldn't find a sensible compatible change), surely not for something that 
would save a handful of keystrokes. (And remember that readability is an 
important goal in Ada, saving keystrokes is not a goal!)

                      Randy.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Jeffrey R. Carter]

On 09/06/2017 06:38 PM, Vincent DIEMUNSCH wrote:
> Le samedi 2 septembre 2017 19:08:48 UTC+2, Jeffrey R. Carter a écrit :
>>
>> What would A(+Red) mean? Indices don't have to be numeric.
> 
> But an array index needs to be isomorphic to an Integer. It's an array ! Not a dictionnary, or a hash table.

Sometimes a map (sometimes called a dictionary by languages intended for people 
not smart enough to understand "map":) is just an array.  A hash table needs 
some extra support, but is mostly an array.

But the fact remains that arrays don't have to have numeric indices. Arrays 
indexed by enumeration types are very useful. Your proposal would have to have a 
well defined meaning for them, too.

> Sure, it is not fully backward compatible. But by the way, only the absence of any evolution is 100% backward compatible, isn't it ?

Demonstrably untrue.

> :-). Ok, but the argument, always used to defend the verbose syntax of Ada, is a little bit weak, because we use high level languages precisely to write less code !

I use them to create readable, correct S/W. How many keystrokes it takes to do 
that is immaterial.

-- 
Jeff Carter
"C++: The power, elegance and simplicity of a hand grenade."
Ole-Hjalmar Kristensen
90

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

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


Le mardi 29 août 2017 01:49:15 UTC+2, far...@gmail.com a écrit :
...
> Oddly missing from Ada, and commented about on this list before, is why 
> brackets [ ] aren't used for
> array indexing.

Why is this odd? There are a number of mapping operations in Ada, and its 
not possible for them all to have different brackets (as there are only 
three sets): array indexing, function calls, type conversions, array 
slicing, etc. Moreover, it's easier to switch between them if the brackets 
don't change (especially when changing from something else to a function 
call).

                            Randy.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Shark8]

On Monday, August 28, 2017 at 5:49:15 PM UTC-6, far...@gmail.com wrote:
> 
> Oddly missing from Ada, and commented about on this list before, is why brackets [ ] aren't used for array indexing. This is highly suggestive of the mathematical notation for vector and matrices and would improve readability and remove the confusion of what is an array and what is a function.

There are basically two reason why square-brackets aren't used for indexing: the first is that when Ada was being developed there were a not-insignificant chunk of computers that lacked it in their native character-sets, and the second was to make array-indexing and function-invocation interface the same.

Ex:
  Is "Data(Item)" a function-call, or is it indexing into an array?
  Answer: Yes. (Indexing into an array is the same as a function: mapping the inputs [indices] to outputs.)

> 
> Also missing is multidimensional array slicing. This really needs to be added to remove errors of users' attempts to do something similar using ad hoc methods.

This is true; I /think/ the reason that Ada doesn't do this has to do with implementation-difficulty *AND* how mapping an array to memory might work.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Björn Lundin]

On 2017-08-03 07:45, Randy Brukardt wrote:

> WG 9 requests the Ada community to submit enhancements to be considered for 
> inclusion in the next revision of Ada. 

Hi!
I sometimes find the need to auto generate code from some kind of
description.
It would help quite a bit if there was a way to
* iterate over fields in a record
* query a field of its properties, like type, length if applicable


  type Data_Type is new Table_Utils.Root_Table_Type with record
    Bldid : Integer_4 := 0 ; -- Primary Key
    Bldsta : Integer_4 := 0 ;
    Bldtyp : Integer_4 := 0 ;
    Bldwei : Float_8 := 0.0 ;
    Blochei : Integer_4 := 0 ;
    Bwmsid : String(1 .. 35) := (others => ' ') ; -- non unique index 2
    Bwmsldid : Integer_4 := 0 ;
    Xlocnam : String(1 .. 20) := (others => ' ') ; -- non unique index 3
    Bcrets : Time_Type := Time_Type_First ;
    Bcartyp : Integer_4 := 0 ;
    Bcawei : Float_8 := 0.0 ;
    Bwanzone : Integer_4 := 0 ;
    Pulv : String(1 .. 3) := (others => ' ') ;
    Ixxlupd : String(1 .. 12) := (others => ' ') ;
    Ixxluts : Time_Type := Time_Type_First ;
  end record;

  Load : Data_Type;


Here I'd like to do

for Field of Load'Fields loop
  case Field.Data_Type is
    when Integer_4 =>
      Text_io.Put_Line(Integer_4'Image(Field));
    when Float_8   =>
      Text_io.Put_Line(Formatted_Float_8.To_String(Field));
    when Time_Type =>
      Text_io.Put_Line(Cal.To_Iso_String(Field));
    when String=>
      Text_io.Put_Line(Field & "-" & Field'Length'Img);
    when others =>
      raise Not_Supported_Data_Type & Field.name;
  end case
end loop;

There is likely more info that would be nice to have, but
The mentioned above would be great.


-- 
--
Björn

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[J-P. Rosen]

Le 01/09/2017 à 16:11, Björn Lundin a écrit :
> Hi!
> I sometimes find the need to auto generate code from some kind of
> description.
> It would help quite a bit if there was a way to
> * iterate over fields in a record
> * query a field of its properties, like type, length if applicable
[...]

This would require full introspection features into the language, which
is not provided for a compiled language (or at a cost that would be
unacceptable to the RT folks).

However, you have "off line" introspection with ASIS. An ASIS program
could generate, f.e., IO packages for your types.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-09-01 16:47, J-P. Rosen wrote:
> Le 01/09/2017 à 16:11, Björn Lundin a écrit :
>> Hi!
>> I sometimes find the need to auto generate code from some kind of
>> description.
>> It would help quite a bit if there was a way to
>> * iterate over fields in a record
>> * query a field of its properties, like type, length if applicable
> [...]
> 
> This would require full introspection features into the language, which
> is not provided for a compiled language (or at a cost that would be
> unacceptable to the RT folks).

I think there is a way to work around run-time issues. The problem is 
with code like this:

    for N in 1..T'Members_Number loop
       Put ("Member No")
       Put (Integer'Image (N));
       Put (", Size =");
       Put (Storage_Count'Image (T'Member_Type (N)'Size));
    end loop;

Now, consider that instead of the attribute T'Member_Type (N) we have 
T'Member_Sizes which would be an array of Storage_Count. Then we could 
write:

    for N in T'Member_Sizes'Range loop
       Put ("Member No")
       Put (Integer'Image (N));
       Put (", Size =");
       Put (Storage_Count'Image (T'Member_Sizes (N));
    end loop;

which would not require run-time support.

> However, you have "off line" introspection with ASIS. An ASIS program
> could generate, f.e., IO packages for your types.

The idea is that instead of ASIS generating programs, we could ask the 
compiler to generate a static object which is then could be walked 
through at run-time. Since that would happen on demand, there would be 
no distributed overhead.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Jacob Sparre Andersen]

Björn Lundin wrote:

> I sometimes find the need to auto generate code from some kind of
> description.
> It would help quite a bit if there was a way to
> * iterate over fields in a record
> * query a field of its properties, like type, length if applicable

One option, as Jean-Pierre suggests, is to write a suitable tool using
ASIS.

Another option is to make your Data_Type type implement a "Visitor"
interface, and go that way.

I would usually suggest writing an ASIS-based tool, but I can easily
find a champion for using the "Visitor" pattern as well.

Greetings,

Jacob
-- 
»A corollary of Murphy's law is that duplicate information
 eventually becomes different information.  Putting both in
 the same file may slow down the process, but it will not
 prevent it.«                                 -- Wes Groleau

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[J-P. Rosen]

Le 01/09/2017 à 19:53, Jacob Sparre Andersen a écrit :
> One option, as Jean-Pierre suggests, is to write a suitable tool using
> ASIS.
> 
> Another option is to make your Data_Type type implement a "Visitor"
> interface, and go that way.
> 
... and a third option is to write an ASIS tool that generates the
implementation of the Visitor interface ;-)

-- 
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: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-09-01 19:53, Jacob Sparre Andersen wrote:

> Another option is to make your Data_Type type implement a "Visitor"
> interface, and go that way.

I wrote a small piece on how to implement introspection on a custom type:

http://ada-programming.blogspot.de/2012/12/type-introspection-in-ada.html

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

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

"Björn Lundin" <b.f.lundin@gmail.com> wrote in message 
news:oobpi2$m60$1@dont-email.me...
> On 2017-08-03 07:45, Randy Brukardt wrote:
>
>> WG 9 requests the Ada community to submit enhancements to be considered 
>> for
>> inclusion in the next revision of Ada.
>
> Hi!
> I sometimes find the need to auto generate code from some kind of
> description.
> It would help quite a bit if there was a way to
> * iterate over fields in a record
> * query a field of its properties, like type, length if applicable

AI12-0020-1 was moving in the direction of providing enough such features so 
that 'Image could be written (or generated) for a record type. Not sure if 
that is going anywhere, though.

As J-P said, full introspection is not appropriate for a compiled language. 
One could even argue that such features don't make sense for any portable 
language, as the meaning depends on the implementation for most things (most 
languages that have it have only one implementation).

                   Randy.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Tarjei Jensen]

It is time to get counted strings into the standard.

The key to counted strings is that they need to be first class objects. The compiler must know how to handle them. Just like it would do when it handles integers or reals of different sizes. You don't have to overload := in order to assign a byte sized integer to a word sized integer. And you don't need to overload operators to add or subtract them.

I strongly believe that implementing it as a general Ada feature will be ineffective. I know that it will be tempting to do so, but RESIST!!!!!!

I also believe that educators will welcome such a move. Especially those who remember Turbo Pascal.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-09-11 20:49, Tarjei Jensen wrote:
> It is time to get counted strings into the standard.

There is no use for specifically reference-counted strings because 
strings are practically never assigned as a whole in properly written 
programs.

There are Unbounded_Strings to have dynamically-bound strings, which is 
not quite same as reference-counted ones, though I see no reason why an 
implementation of it cannot be reference-counted.

> The key to counted strings is that they need to be first class
> objects. The compiler must know how to handle them.

The use-case for reference-counted strings, if there is any then for 
concurrent access. This would require a lot of locking when handling the 
reference count and a lot of copying in order to clone concurrently 
written string body.

> I strongly believe that implementing it as a general Ada feature will be ineffective.

Any general purpose implementation of will be, see above.

For single task access existing string types are sufficient.

> I know that it will be tempting to do so, but RESIST!!!!!!

Why? It is quite trivial.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Tarjei Jensen]

A counted string is not reference counted.

A counted string can be viewed as

type counted_string is record
   max : natural; 
   len : natural;
   str : array range ( 1 .. max) of character;
end record;

The best known environment which uses counted strings is Turbo Pascal. Note that I wrote "uses". It is still being used in education.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[gautier_niouzes]

Have a look at the package Ada.Strings.Bounded ...
It is rarely encountered in programs, but available since Ada 95.
_________________________ 
Gautier's Ada programming 
http://gautiersblog.blogspot.com/search/label/Ada 
NB: follow the above link for a valid e-mail address 

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Tarjei Jensen]

On Tuesday, 12 September 2017 08:38:16 UTC+2, gautier...@hotmail.com  wrote:
> Have a look at the package Ada.Strings.Bounded ...
> It is rarely encountered in programs, but available since Ada 95.
> _________________________ 
> Gautier's Ada programming 
> http://gautiersblog.blogspot.com/search/label/Ada 
> NB: follow the above link for a valid e-mail address

Perhaps there is a reason for the non-use?

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 12/09/2017 09:02, Tarjei Jensen wrote:
> On Tuesday, 12 September 2017 08:38:16 UTC+2, gautier...@hotmail.com  wrote:
>> Have a look at the package Ada.Strings.Bounded ...
>> It is rarely encountered in programs, but available since Ada 95.
>> _________________________
>> Gautier's Ada programming
>> http://gautiersblog.blogspot.com/search/label/Ada
>> NB: follow the above link for a valid e-mail address
> 
> Perhaps there is a reason for the non-use?

Yes, bounded-length strings have no practical use in Ada.

The reason for that is that differently to other languages Ada can 
return fixed-length strings on the stack and can pass string slices down 
where a fixed-length string is expected. This eliminates most of the 
cases for bounded-length strings, the minuscule rest is handled by 
Unbounded_Strings.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Simon Wright]

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

> The reason for that is that differently to other languages Ada can
> return fixed-length strings on the stack and can pass string slices
> down where a fixed-length string is expected. This eliminates most of
> the cases for bounded-length strings, the minuscule rest is handled by
> Unbounded_Strings.

Bounded_Strings are good where you can't use heap allocation or
finalization (e.g. in smaller embedded systems).

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[J-P. Rosen]

Le 12/09/2017 à 09:15, Dmitry A. Kazakov a écrit :
> Yes, bounded-length strings have no practical use in Ada.
> 
> The reason for that is that differently to other languages Ada can
> return fixed-length strings on the stack and can pass string slices down
> where a fixed-length string is expected. This eliminates most of the
> cases for bounded-length strings, the minuscule rest is handled by
> Unbounded_Strings.
> 
No, because Unbounded_Strings are just one type, while bounded strings
create different types.

The use of bounded length is when you have various types, implemented as
strings. In a data base, you don't want an address to be the same type
as a name, even if both are represented as strings. And objects have a
variable length, with a maximum set by the constraints of the
environment (usually a database).

-- 
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: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 12/09/2017 11:23, J-P. Rosen wrote:
> Le 12/09/2017 à 09:15, Dmitry A. Kazakov a écrit :
>> Yes, bounded-length strings have no practical use in Ada.
>>
>> The reason for that is that differently to other languages Ada can
>> return fixed-length strings on the stack and can pass string slices down
>> where a fixed-length string is expected. This eliminates most of the
>> cases for bounded-length strings, the minuscule rest is handled by
>> Unbounded_Strings.
>>
> No, because Unbounded_Strings are just one type, while bounded strings
> create different types.

Which was surely a design bug. If the programmer wants different types 
there exists a language mechanism of type cloning specifically for that 
purpose.

> The use of bounded length is when you have various types, implemented as
> strings. In a data base, you don't want an address to be the same type
> as a name, even if both are represented as strings.

type Name is new String;
type Address is new String;

> And objects have a
> variable length, with a maximum set by the constraints of the
> environment (usually a database).

Which does not justify using bounded-length strings for interfacing the 
DB. No DB bindings I know deploy bounded-length strings. Furthermore 
using bounded-length string would bring only disadvantages when dealing 
with the DB. SQL parameter binding is only possible with plain flat 
strings. Most likely you will end up using the normal string as a middle 
man between the DB and the bounded-length string. And the length 
constraint is an arbitrary implementation detail in most cases. It is 
practically impossible to find a use case for bounded-length strings in Ada.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Shark8]

On Tuesday, September 12, 2017 at 4:07:27 AM UTC-6, Dmitry A. Kazakov wrote:
> 
> No DB bindings I know deploy bounded-length strings.

Isn't that a failing of those bindings?
(Just like we could have a thin C-binding which used return codes.)

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-09-12 18:30, Shark8 wrote:
> On Tuesday, September 12, 2017 at 4:07:27 AM UTC-6, Dmitry A. Kazakov wrote:
>>
>> No DB bindings I know deploy bounded-length strings.
> 
> Isn't that a failing of those bindings? (Just like we could have a
> thin C-binding which used return codes.)
If you mean the side turned towards the DB, it is a requirement, since 
the counterpart is a char * or void *.

If you mean the Ada interface's side, it is convenience. Bounded_Strings 
are difficult to use, while the advantage is zero. If the DB has a field 
constraint that is dynamic on the Ada side. There is no way you could 
push that constraint into the instance of Ada.Strings.Bounded.

Since copying is involved anyway, there is no reason not to have

    Fetch (Column)

just returning String of the actual length. Simple and clean.

If we wanted in-place semantics, a stream is the answer. Fetch would 
supply chunks of data which are accumulated in the stream. There are 
lots of protocols working this way, e.g. HTTP's chunked transfer.

The stream can be backed by a String on an embedded system or by a 
container of dynamically allocated memory chunks. Anyway, no good reason 
to use Ada.Strings.Bounded.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[J-P. Rosen]

Le 12/09/2017 à 12:07, Dmitry A. Kazakov a écrit :
> It is practically impossible to find a use case for bounded-length
> strings in Ada.

Especially if you discard those that have been presented to you...

-- 
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: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-09-12 21:30, J-P. Rosen wrote:
> Le 12/09/2017 à 12:07, Dmitry A. Kazakov a écrit :
>> It is practically impossible to find a use case for bounded-length
>> strings in Ada.
> 
> Especially if you discard those that have been presented to you...

You are free to present DB bindings, say to SQLite, with prepared 
statement's parameters bound to Bounded_String.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[gautier_niouzes]

> Perhaps there is a reason for the non-use?

Bounded_String is an in-between type

                 Flexibility      Simplicity for the machine
                 (for the human)  (and perhaps performance)
                 ---------------  --------------------------
String           Low              High
Bounded_String   Mid              Mid
Unbounded_String High             Low

For comfort I use only String and Unbounded_String, although I did lots of Turbo Pascal previously. Perhaps I do not miss that much having strings unexpectedly truncated after the 255th character, or having conversion surprises from a String[255] to a String[80]...

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Egil H H]

On Tuesday, September 12, 2017 at 8:19:01 AM UTC+2, Tarjei Jensen wrote:
> A counted string is not reference counted.
> 
> A counted string can be viewed as
> 
> type counted_string is record
>    max : natural; 
>    len : natural;
>    str : array range ( 1 .. max) of character;
> end record;
> 

How would this behave differently from a discriminated record?

type My_String(Length : Positive) is
record
   Last : Natural := 0;
   Item : String(1..Length);
end record;


-- 
~egilhh

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Tarjei Jensen]

It is different because you don't need to overload := to make it work.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Egil H H]

On Tuesday, September 12, 2017 at 9:02:15 AM UTC+2, Tarjei Jensen wrote:
> It is different because you don't need to overload := to make it work.

Substituting a discriminant with a record member does not magically change the behaviour of ":=" 

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Tarjei Jensen]

On Tuesday, 12 September 2017 09:42:54 UTC+2, Egil H H  wrote:
> On Tuesday, September 12, 2017 at 9:02:15 AM UTC+2, Tarjei Jensen wrote:
> > It is different because you don't need to overload := to make it work.
> 
> Substituting a discriminant with a record member does not magically change the behaviour of ":="

The whole point is that the compiler knows how counted strings work.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 12/09/2017 09:42, Egil H H wrote:
> On Tuesday, September 12, 2017 at 9:02:15 AM UTC+2, Tarjei Jensen wrote:
>> It is different because you don't need to overload := to make it work.
> 
> Substituting a discriminant with a record member does not magically change the behaviour of ":="

It does, because there are rules limiting assignment of discriminated 
records.

Both presented variants are wrong.

The variant with the discriminant is if we assume that the upper bound 
is not a part of the type, but a subtype constraint. Specifically it 
would imply an ability to assign strings having different upper bounds.

One of issues limiting use of Ada.Strings.Bounded is that the package is 
generic with the bound given the formal parameter.

P.S. Assignment cannot be reasonably implemented without compiler magic 
because multiple dispatch is not supported.

P.P.S. Not that bounded-length strings were much more usable if the 
bound were a proper constraint and assignment worked across all string 
types...

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Egil H H]

On Tuesday, September 12, 2017 at 10:35:43 AM UTC+2, Dmitry A. Kazakov wrote:
> On 12/09/2017 09:42, Egil H H wrote:
> > On Tuesday, September 12, 2017 at 9:02:15 AM UTC+2, Tarjei Jensen wrote:
> >> It is different because you don't need to overload := to make it work.
> > 
> > Substituting a discriminant with a record member does not magically change the behaviour of ":="
> 
> It does, because there are rules limiting assignment of discriminated 
> records.
> 

Just as there would be rules limiting assignment of records with members depending on other members, if we ever allowed that.


-- 
~egilhh

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 12/09/2017 11:21, Egil H H wrote:
> On Tuesday, September 12, 2017 at 10:35:43 AM UTC+2, Dmitry A. Kazakov wrote:
>> On 12/09/2017 09:42, Egil H H wrote:
>>> On Tuesday, September 12, 2017 at 9:02:15 AM UTC+2, Tarjei Jensen wrote:
>>>> It is different because you don't need to overload := to make it work.
>>>
>>> Substituting a discriminant with a record member does not magically change the behaviour of ":="
>>
>> It does, because there are rules limiting assignment of discriminated
>> records.
> 
> Just as there would be rules limiting assignment of records with
> members depending on other members, if we ever allowed that.

Yes, but they would be different. A more close example would be:

type Bounded_String (Bound : Natural := Max) is record
    Length : Natural := 0;
    Text   : String (1..Bound);
end record;

To make things work, apart from having array interfaces, one must change 
the way user-defined assignment works, assuming there is one. It cannot 
be a single body like Adjust in Ada.Finalization. It must consist of two 
parts one to determine the discriminants of the left part and another to 
perform actual actions. The same applies to constructors.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Egil H H]

On Tuesday, September 12, 2017 at 12:22:12 PM UTC+2, Dmitry A. Kazakov wrote:
> 
> Yes, but they would be different. A more close example would be:
> 
> type Bounded_String (Bound : Natural := Max) is record
>     Length : Natural := 0;
>     Text   : String (1..Bound);
> end record;
> 

Well, I don't have unlimited memory, so allocating Natural'Last number of Characters for all my strings is not an option for me, but I guess YMMV.

(Sure, you can use a subtype other than Natural, but how do you choose an upper bound that is both reasonably large to fit most needs, yet reasonably small to limit memory usage?)

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 12/09/2017 12:48, Egil H H wrote:
> On Tuesday, September 12, 2017 at 12:22:12 PM UTC+2, Dmitry A. Kazakov wrote:
>>
>> Yes, but they would be different. A more close example would be:
>>
>> type Bounded_String (Bound : Natural := Max) is record
>>      Length : Natural := 0;
>>      Text   : String (1..Bound);
>> end record;
> 
> Well, I don't have unlimited memory, so allocating Natural'Last 
> number of Characters for all my strings is not an option for me, but
> I guess YMMV.
> 
> (Sure, you can use a subtype other than Natural, but how do you
> choose an upper bound that is both reasonably large to fit most
> needs, yet  reasonably small to limit memory usage?)

The same way I supposed to choose it for Ada.Strings.Bounded?

As I said there is almost no use for bounded-length strings. It is much 
easier to create new local fixed-length strings all the time. String 
re-assignment must ring alarm bells no sane algorithm should require this.

The only one case where Unbounded_String has a use is when returning 
multiple strings out of a procedure. If ad-hoc tuples were supported 
that won't be necessary either. Though it possible to create a result 
record like:

    type Result (L1, L2, L3 : Natural) is record
       S1 : String (1..L1);
       S2 : String (1..L2);
       S3 : String (1..L3);
    end record;

and I frequently do this, it does not look elegant.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Egil H H]

On Tuesday, September 12, 2017 at 2:09:53 PM UTC+2, Dmitry A. Kazakov wrote:
> 
> The same way I supposed to choose it for Ada.Strings.Bounded?

What? That it shouldn't be a generic? That would bring us back to allocating huge amounts of memory per string...


> As I said there is almost no use for bounded-length strings. 

You may not have need for it. That doesn't necessarily make it true for the rest of the world.

-- 
~egilhh

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 12/09/2017 14:56, Egil H H wrote:
> On Tuesday, September 12, 2017 at 2:09:53 PM UTC+2, Dmitry A. Kazakov wrote:
>>
>> The same way I supposed to choose it for Ada.Strings.Bounded?
> 
> What? That it shouldn't be a generic? That would bring us back to
> allocating huge amounts of memory per string...

How? What is the difference between giving the bound in a generic 
instantiation vs in a type declaration?

>> As I said there is almost no use for bounded-length strings.
> 
> You may not have need for it. That doesn't necessarily make it true
> for the rest of the world.
I didn't say that. I said that there is no use case for it. Which is not 
same. Regarding the rest of the world, it is even simpler. It is a mere 
empirical fact relatively easy to measure. Take available Ada code base 
and compare how frequently various types of strings are used there.

That nobody actually uses bounded strings does not necessary mean that 
there is no use of bounded strings. Maybe people are uneducated, have 
prejudices etc. But no the thing is indeed useless, therefore not used. 
Could be quietly removed from the standard, nobody would notice...

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Egil H H]

On Tuesday, September 12, 2017 at 3:14:04 PM UTC+2, Dmitry A. Kazakov wrote:
> 
> How? What is the difference between giving the bound in a generic 
> instantiation vs in a type declaration?
> 

With a generic, a user can decide the absolute maximum for his/her application, so the discriminated record does not need to have an upper bound of Natural'Last, reducing the memory footprint.


> >> As I said there is almost no use for bounded-length strings.
> > 
> > You may not have need for it. That doesn't necessarily make it true
> > for the rest of the world.
> I didn't say that. I said that there is no use case for it. Which is not 
> same. Regarding the rest of the world, it is even simpler. It is a mere 
> empirical fact relatively easy to measure. Take available Ada code base 
> and compare how frequently various types of strings are used there.
> 
> That nobody actually uses bounded strings does not necessary mean that 
> there is no use of bounded strings. Maybe people are uneducated, have 
> prejudices etc. But no the thing is indeed useless, therefore not used. 
> Could be quietly removed from the standard, nobody would notice...

Well, this is clearly _your_ opinion, nothing more. You don't have access to all Ada code bases out there. If you do, there are several intelligence agencies out there that would like a word with you.
_You_ can't find a use case, others can, and have. Maybe you're in the "have prejudices" category...

Get off your high horse, for a change.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 12/09/2017 15:25, Egil H H wrote:
> On Tuesday, September 12, 2017 at 3:14:04 PM UTC+2, Dmitry A. Kazakov wrote:
>>
>> How? What is the difference between giving the bound in a generic
>> instantiation vs in a type declaration?
>>
> 
> With a generic, a user can decide the absolute maximum for his/her
> application, so the discriminated record does not need to have an upper
> bound of Natural'Last, reducing the memory footprint.

So it can do with the custom type:

with Ada.Text_IO;  use Ada.Text_IO;
procedure Test is
    Max : constant := 1000;
    subtype Max_Length is Natural range 0..Max;
    type Bounded (Size : Max_Length := Max_Length'Last) is record
       Length : Max_Length := 0;
       Text   : String (1..Size);
    end record;
    function Value (S : Bounded) return String is
    begin
       return S.Text (1..S.Length);
    end Value;
    procedure Set (S : in out Bounded; Value : String) is
    begin
       S.Length := Value'Length;
       S.Text (1..Value'Length) := Value;
    end Set;
    X : Bounded;
    Y : Bounded (10);
begin
    Set (X, "0123456789ABCDEFGH");
    Put_Line ("X=" & Value (X));
    Set (Y, "abc");
    X := Y;
    Put_Line ("X=" & Value (X));
end Test;

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Egil H H]

On Tuesday, September 12, 2017 at 3:43:40 PM UTC+2, Dmitry A. Kazakov wrote:
> So it can do with the custom type:
> 
> with Ada.Text_IO;  use Ada.Text_IO;
> procedure Test is
>     Max : constant := 1000;
>     subtype Max_Length is Natural range 0..Max;
>     type Bounded (Size : Max_Length := Max_Length'Last) is record
>        Length : Max_Length := 0;
>        Text   : String (1..Size);
>     end record;
>     function Value (S : Bounded) return String is
>     begin
>        return S.Text (1..S.Length);
>     end Value;
>     procedure Set (S : in out Bounded; Value : String) is
>     begin
>        S.Length := Value'Length;
>        S.Text (1..Value'Length) := Value;
>     end Set;
>     X : Bounded;
>     Y : Bounded (10);
> begin
>     Set (X, "0123456789ABCDEFGH");
>     Put_Line ("X=" & Value (X));
>     Set (Y, "abc");
>     X := Y;
>     Put_Line ("X=" & Value (X));
> end Test;
> 

...and you _really_ don't see the value of having all this (and lots more) in _one_ place, implemented _once_, tried and tested? 

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-09-12 16:07, Egil H H wrote:
> On Tuesday, September 12, 2017 at 3:43:40 PM UTC+2, Dmitry A. Kazakov wrote:
>> So it can do with the custom type:
>>
>> with Ada.Text_IO;  use Ada.Text_IO;
>> procedure Test is
>>      Max : constant := 1000;
>>      subtype Max_Length is Natural range 0..Max;
>>      type Bounded (Size : Max_Length := Max_Length'Last) is record
>>         Length : Max_Length := 0;
>>         Text   : String (1..Size);
>>      end record;
>>      function Value (S : Bounded) return String is
>>      begin
>>         return S.Text (1..S.Length);
>>      end Value;
>>      procedure Set (S : in out Bounded; Value : String) is
>>      begin
>>         S.Length := Value'Length;
>>         S.Text (1..Value'Length) := Value;
>>      end Set;
>>      X : Bounded;
>>      Y : Bounded (10);
>> begin
>>      Set (X, "0123456789ABCDEFGH");
>>      Put_Line ("X=" & Value (X));
>>      Set (Y, "abc");
>>      X := Y;
>>      Put_Line ("X=" & Value (X));
>> end Test;
>>
> 
> ...and you _really_ don't see the value of having all this (and lots
> more) in _one_ place, implemented _once_, tried and tested?

No, I don't see value in bounded-length strings in the first place. So I 
have neither this nor Ada.Strings.Bounded anywhere.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Egil H H]

On Tuesday, September 12, 2017 at 3:43:40 PM UTC+2, Dmitry A. Kazakov wrote:
> So it can do with the custom type:
> 
> with Ada.Text_IO;  use Ada.Text_IO;
> procedure Test is
>     Max : constant := 1000;
>     subtype Max_Length is Natural range 0..Max;
>     type Bounded (Size : Max_Length := Max_Length'Last) is record
>        Length : Max_Length := 0;
>        Text   : String (1..Size);
>     end record;
> 
...
>     Y : Bounded (10);

Also, allocating 1000 Characters for a string of max length 10 is hardly an optimal solution...

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-09-12 16:36, Egil H H wrote:
> On Tuesday, September 12, 2017 at 3:43:40 PM UTC+2, Dmitry A. Kazakov wrote:
>> So it can do with the custom type:
>>
>> with Ada.Text_IO;  use Ada.Text_IO;
>> procedure Test is
>>      Max : constant := 1000;
>>      subtype Max_Length is Natural range 0..Max;
>>      type Bounded (Size : Max_Length := Max_Length'Last) is record
>>         Length : Max_Length := 0;
>>         Text   : String (1..Size);
>>      end record;
>>
> ...
>>      Y : Bounded (10);
> 
> Also, allocating 1000 Characters for a string of max length 10 is hardly an optimal solution...

How is that different from:

    package Foo is new Ada.Strings.Bounded (1000);

?

If you are looking for optimal solutions look elsewhere...

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Egil H H]

On Tuesday, September 12, 2017 at 5:55:34 PM UTC+2, Dmitry A. Kazakov wrote:
> 
> How is that different from:
> 
>     package Foo is new Ada.Strings.Bounded (1000);
> 
> ?

The difference?
You have one string type that will always allocate 1000 Characters for every variable of the type, regardless of how many the user specifies as max. 
Ada.Strings.Bounded will allocate as many as the user specifies as max, which is 10 in the part of your example i quoted. So you would use 9990% more memory...

And again, how did you choose 1000? How do you know that will be enough for all users of your string type? Or do you copy/paste the string type every time you need a new max length? 

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-09-12 18:15, Egil H H wrote:
> On Tuesday, September 12, 2017 at 5:55:34 PM UTC+2, Dmitry A. Kazakov wrote:
>>
>> How is that different from:
>>
>>      package Foo is new Ada.Strings.Bounded (1000);
>>
>> ?
> 
> The difference?
> You have one string type that will always allocate 1000 Characters
> for  every variable of the type, regardless of how many the user specifies as
> max. Ada.Strings.Bounded will allocate as many as the user specifies
> as max, which is 10 in the part of your example i quoted. So you
> would use  9990% more memory...

Do you imply that Bounded_String deploys heap? I would consider such 
implementation a bug. Otherwise you will need two instances and two 
different types, which is not the intended use.

The example only illustrates how discriminants work with assignment and 
components.

> And again, how did you choose 1000? How do you know that will be
> enough for all users of your string type?

This is why Bounded_String are not used. The problem space almost never 
provides any upper bound. So the bound is an implementation constraint 
and thus a premature optimization of worst kind.

> Or do you copy/paste the
> string type every time you need a new max length?

Sure, this what generic packages basically are, dressed up macros.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Egil H H]

On Tuesday, September 12, 2017 at 6:40:53 PM UTC+2, Dmitry A. Kazakov wrote:
> 
> Do you imply that Bounded_String deploys heap? I would consider such 
> implementation a bug. Otherwise you will need two instances and two 
> different types, which is not the intended use.
> 

No, but they don't use default discriminants....

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-09-12 18:47, Egil H H wrote:
> On Tuesday, September 12, 2017 at 6:40:53 PM UTC+2, Dmitry A. Kazakov wrote:
>>
>> Do you imply that Bounded_String deploys heap? I would consider such
>> implementation a bug. Otherwise you will need two instances and two
>> different types, which is not the intended use.
> 
> No, but they don't use default discriminants....

Right, but discriminant is a natural way to express constraint in Ada. 
Formal generic parameter is a very bad way doing that.

As for having default value it is a requirement to have the type 
constrained, which is a requirement to make assignment work. Which has 
undesired implications on the type representation. Sigh.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Egil H H]

On Tuesday, September 12, 2017 at 6:59:09 PM UTC+2, Dmitry A. Kazakov wrote:
> Right, but discriminant is a natural way to express constraint in Ada. 
> Formal generic parameter is a very bad way doing that.
> 
> As for having default value it is a requirement to have the type 
> constrained, which is a requirement to make assignment work. Which has 
> undesired implications on the type representation. Sigh.
>

Last time I checked, assignment worked perfectly with Ada.Strings.Bounded.
Sigh, right back to you.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-09-12 19:03, Egil H H wrote:
> On Tuesday, September 12, 2017 at 6:59:09 PM UTC+2, Dmitry A. Kazakov wrote:
>> Right, but discriminant is a natural way to express constraint in Ada.
>> Formal generic parameter is a very bad way doing that.
>>
>> As for having default value it is a requirement to have the type
>> constrained, which is a requirement to make assignment work. Which has
>> undesired implications on the type representation. Sigh.
>>
> 
> Last time I checked, assignment worked perfectly with Ada.Strings.Bounded.
> Sigh, right back to you.

No, it does not work. Try

    package S_1000 is new Ada.Strings.Bounded (1000);
    package S_10 is new Ada.Strings.Bounded (10);

    X : S_1000.Bounded_String;
    Y : S_10.Bounded_String;

    X := Y;

A proper implementation of bounded-length string, provided we needed 
them, should have worked like this:

    X : Bounded_String (1000); -- 1000 is my limit, now I am ""
    Y : Bounded_String (10) := "abc"; -- 10 is mine, now I am "abc"

    X := Y; -- We are both strings, don't we?

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Egil H H]

On Tuesday, September 12, 2017 at 7:17:38 PM UTC+2, Dmitry A. Kazakov wrote:
> No, it does not work. Try
> 
>     package S_1000 is new Ada.Strings.Bounded (1000);
>     package S_10 is new Ada.Strings.Bounded (10);
> 
>     X : S_1000.Bounded_String;
>     Y : S_10.Bounded_String;
> 
>     X := Y;
> 
> A proper implementation of bounded-length string, provided we needed 
> them, should have worked like this:
> 
>     X : Bounded_String (1000); -- 1000 is my limit, now I am ""
>     Y : Bounded_String (10) := "abc"; -- 10 is mine, now I am "abc"
> 
>     X := Y; -- We are both strings, don't we?

Ah, so yo want to give up type safety... those are different types, instantiated for different purposes.
You're on your own, then... 
Good luck with your unsafe memory hog.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-09-12 19:29, Egil H H wrote:
> On Tuesday, September 12, 2017 at 7:17:38 PM UTC+2, Dmitry A. Kazakov wrote:
>> No, it does not work. Try
>>
>>      package S_1000 is new Ada.Strings.Bounded (1000);
>>      package S_10 is new Ada.Strings.Bounded (10);
>>
>>      X : S_1000.Bounded_String;
>>      Y : S_10.Bounded_String;
>>
>>      X := Y;
>>
>> A proper implementation of bounded-length string, provided we needed
>> them, should have worked like this:
>>
>>      X : Bounded_String (1000); -- 1000 is my limit, now I am ""
>>      Y : Bounded_String (10) := "abc"; -- 10 is mine, now I am "abc"
>>
>>      X := Y; -- We are both strings, don't we?
> 
> Ah, so yo want to give up type safety... those are different types,
> instantiated for different purposes.
Sure, like

    X : String (1..1000);
    Y : String (1..10);

Length constraint has nothing to do with type safety. E.g.

    type Address is new Bounded_String (30);
    type Name is new Bounded_String (30);

Same constraint different types and conversely.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Egil H H]

On Tuesday, September 12, 2017 at 9:14:50 PM UTC+2, Dmitry A. Kazakov wrote:
> > 
> > Ah, so yo want to give up type safety... those are different types,
> > instantiated for different purposes.
> Sure, like
> 
>     X : String (1..1000);
>     Y : String (1..10);
> 

You still can't do
X := Y;
so why would you expect Bounded_String to behave that way?

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 12/09/2017 21:58, Egil H H wrote:
> On Tuesday, September 12, 2017 at 9:14:50 PM UTC+2, Dmitry A. Kazakov wrote:
>>>
>>> Ah, so yo want to give up type safety... those are different types,
>>> instantiated for different purposes.
>> Sure, like
>>
>>      X : String (1..1000);
>>      Y : String (1..10);
>>
> 
> You still can't do
> X := Y;

Of course I can it is the same type.

> so why would you expect Bounded_String to behave that way?

Because the contracts of ":=" of fixed- and variable-length strings are 
different.

Fixed-length string assignment cannot change length, as the type name 
suggests. So the contract is that if the lengths are different 
Constraint_Error is propagated.

For bounded-length strings the contract is that the length may not 
exceed the bound. So the contract is that Constraint_Error to propagate 
only then.

For unbounded-length strings the contract is no Constraint_Error at all, 
but Storage_Error to propagate when it is impossible to assign.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Egil H H]

On Wednesday, September 13, 2017 at 9:24:56 AM UTC+2, Dmitry A. Kazakov wrote:
> >>
> >>      X : String (1..1000);
> >>      Y : String (1..10);
> >>
> > 
> > You still can't do
> > X := Y;
> 
> Of course I can it is the same type.
>

Not without a Constraint_Error being raised...

 
> > so why would you expect Bounded_String to behave that way?
> 
> Because the contracts of ":=" of fixed- and variable-length strings are 
> different.
> 
> Fixed-length string assignment cannot change length, as the type name 
> suggests. So the contract is that if the lengths are different 
> Constraint_Error is propagated.
> 

Exactly my point... 
You can't just do X := Y when the ranges differ, and you can't just do X := Y for Bounded_Strings when they are of different types.

> For bounded-length strings the contract is that the length may not 
> exceed the bound. So the contract is that Constraint_Error to propagate 
> only then.
> 

Yes, and there are different types depending on the needs of the users. 
If they need a Name, they create a Bounded_String called Name with an upper bound.
If they need an Address, they create a Bounded_String called Address with an upper bound that may or may not be different from the bound of Name.
But you can't mix and match them willy-nilly, because they are of different types.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 13/09/2017 10:13, Egil H H wrote:
> On Wednesday, September 13, 2017 at 9:24:56 AM UTC+2, Dmitry A. Kazakov wrote:
>>>>
>>>>       X : String (1..1000);
>>>>       Y : String (1..10);
>>>>
>>>
>>> You still can't do
>>> X := Y;
>>
>> Of course I can it is the same type.
> 
> Not without a Constraint_Error being raised...

Which is the desired effect.

>>> so why would you expect Bounded_String to behave that way?
>>
>> Because the contracts of ":=" of fixed- and variable-length strings are
>> different.
>>
>> Fixed-length string assignment cannot change length, as the type name
>> suggests. So the contract is that if the lengths are different
>> Constraint_Error is propagated.
> 
> Exactly my point...

No, you said I cannot assign <=> it would be an illegal program. That is 
wrong. I can. The program is legal, its behavior is defined.

> You can't just do X := Y when the ranges differ,

It is a legal Ada program. It compiles and works as expected.

> and you can't just
> do  X := Y for Bounded_Strings when they are of different types.

This has nothing to do with strings being bounded or not. If an 
operation is not defined on the given combination of types, then it is. 
Calling undefined operations is an illegal program.

>> For bounded-length strings the contract is that the length may not
>> exceed the bound. So the contract is that Constraint_Error to propagate
>> only then.
> 
> Yes, and there are different types depending on the needs of the users.

Non sequitur. The contract of bounded-length string assignment and user 
needs for having types same or different are unrelated issues.

There are plenty examples when the type is same but instances' 
constraints are different. Ada's subtypes and discriminated types are 
all about that.

One can easily find examples for differently constrained instances of 
bounded-length strings:

    Windows_Name : File_Name (MAX_PATH);
    DOS_Name     : File_Name (8 + 1 + 3);

P.S. For further insights see the package Standard with Integer 
*subtypes* Natural and Positive etc.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Egil H H]

On Wednesday, September 13, 2017 at 10:57:50 AM UTC+2, Dmitry A. Kazakov wrote:
> On 13/09/2017 10:13, Egil H H wrote:
> > On Wednesday, September 13, 2017 at 9:24:56 AM UTC+2, Dmitry A. Kazakov wrote:
> >>>>
> >>>>       X : String (1..1000);
> >>>>       Y : String (1..10);
> >>>>
> >>>
> >>> You still can't do
> >>> X := Y;
> >>
> >> Of course I can it is the same type.
> > 
> > Not without a Constraint_Error being raised...
> 
> Which is the desired effect.
> 
> >>> so why would you expect Bounded_String to behave that way?
> >>
> >> Because the contracts of ":=" of fixed- and variable-length strings are
> >> different.
> >>
> >> Fixed-length string assignment cannot change length, as the type name
> >> suggests. So the contract is that if the lengths are different
> >> Constraint_Error is propagated.
> > 
> > Exactly my point...
> 
> No, you said I cannot assign <=> it would be an illegal program. That is 
> wrong. I can. The program is legal, its behavior is defined.
> 
> > You can't just do X := Y when the ranges differ,
> 
> It is a legal Ada program. It compiles and works as expected.
> 
> > and you can't just
> > do  X := Y for Bounded_Strings when they are of different types.
> 
> This has nothing to do with strings being bounded or not. If an 
> operation is not defined on the given combination of types, then it is. 
> Calling undefined operations is an illegal program.
> 
> >> For bounded-length strings the contract is that the length may not
> >> exceed the bound. So the contract is that Constraint_Error to propagate
> >> only then.
> > 
> > Yes, and there are different types depending on the needs of the users.
> 
> Non sequitur. The contract of bounded-length string assignment and user 
> needs for having types same or different are unrelated issues.
> 
> There are plenty examples when the type is same but instances' 
> constraints are different. Ada's subtypes and discriminated types are 
> all about that.
> 
> One can easily find examples for differently constrained instances of 
> bounded-length strings:
> 
>     Windows_Name : File_Name (MAX_PATH);
>     DOS_Name     : File_Name (8 + 1 + 3);
> 
> P.S. For further insights see the package Standard with Integer 
> *subtypes* Natural and Positive etc.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de


Now you're just grasping at straws.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Simon Wright]

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

> This is why Bounded_String are not used. The problem space almost
> never provides any upper bound. So the bound is an implementation
> constraint and thus a premature optimization of worst kind.

In my (current) case, the problem domain requires

   Max_Name_Length : constant := 14;

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Jeffrey R. Carter]

On 09/12/2017 04:36 PM, Egil H H wrote:
> On Tuesday, September 12, 2017 at 3:43:40 PM UTC+2, Dmitry A. Kazakov wrote:
>> So it can do with the custom type:
>>
>> with Ada.Text_IO;  use Ada.Text_IO;
>> procedure Test is
>>      Max : constant := 1000;
>>      subtype Max_Length is Natural range 0..Max;
>>      type Bounded (Size : Max_Length := Max_Length'Last) is record
>>         Length : Max_Length := 0;
>>         Text   : String (1..Size);
>>      end record;
>>
> ...
>>      Y : Bounded (10);
> 
> Also, allocating 1000 Characters for a string of max length 10 is hardly an optimal solution...

If an actual discriminant is provided, the default is not used. This only 
allocates 10 characters.

-- 
Jeff Carter
"Why don't you bore a hole in yourself and let the sap run out?"
Horse Feathers
49

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Alejandro R. Mosteo]

On 12/09/17 19:43, Jeffrey R. Carter wrote:
> On 09/12/2017 04:36 PM, Egil H H wrote:
>> On Tuesday, September 12, 2017 at 3:43:40 PM UTC+2, Dmitry A. Kazakov 
>> wrote:
>>> So it can do with the custom type:
>>>
>>> with Ada.Text_IO;  use Ada.Text_IO;
>>> procedure Test is
>>>      Max : constant := 1000;
>>>      subtype Max_Length is Natural range 0..Max;
>>>      type Bounded (Size : Max_Length := Max_Length'Last) is record
>>>         Length : Max_Length := 0;
>>>         Text   : String (1..Size);
>>>      end record;
>>>
>> ...
>>>      Y : Bounded (10);
>>
>> Also, allocating 1000 Characters for a string of max length 10 is 
>> hardly an optimal solution...
> 
> If an actual discriminant is provided, the default is not used. This 
> only allocates 10 characters.

Just going back to my basics, I think it's been years since I used 
default discriminants. In such a case, if I tried to later assign a 
larger instance to this Y, would it work, given that only 10 chars were 
allocated initially?

Thanks.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Jeffrey R. Carter]

On 09/13/2017 03:07 PM, Alejandro R. Mosteo wrote:
> On 12/09/17 19:43, Jeffrey R. Carter wrote:
>> On 09/12/2017 04:36 PM, Egil H H wrote:
>>> On Tuesday, September 12, 2017 at 3:43:40 PM UTC+2, Dmitry A. Kazakov wrote:
>>>> So it can do with the custom type:
>>>>
>>>> with Ada.Text_IO;  use Ada.Text_IO;
>>>> procedure Test is
>>>>      Max : constant := 1000;
>>>>      subtype Max_Length is Natural range 0..Max;
>>>>      type Bounded (Size : Max_Length := Max_Length'Last) is record
>>>>         Length : Max_Length := 0;
>>>>         Text   : String (1..Size);
>>>>      end record;
>>>>
>>> ...
>>>>      Y : Bounded (10);
>>>
>>> Also, allocating 1000 Characters for a string of max length 10 is hardly an 
>>> optimal solution...
>>
>> If an actual discriminant is provided, the default is not used. This only 
>> allocates 10 characters.
> 
> Just going back to my basics, I think it's been years since I used default 
> discriminants. In such a case, if I tried to later assign a larger instance to 
> this Y, would it work, given that only 10 chars were allocated initially?

No. If you supply a discriminant, the object is constrained to that subtype. 
Only is you do not supply a discriminant is the object unconstrained.

-- 
Jeff Carter
"Hold your temper. Count ten.... Now let 'er go.
You got a good aim."
Never Give a Sucker an Even Break
105

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Egil H H]

On Wednesday, September 13, 2017 at 6:34:43 PM UTC+2, Jeffrey R. Carter wrote:
> 
> No. If you supply a discriminant, the object is constrained to that subtype. 
> Only is you do not supply a discriminant is the object unconstrained.
> 

That's wrong.

"If a discriminated type has default_expressions for its discriminants, then unconstrained variables of the type are permitted, and the values of the discriminants can be changed by an assignment to such a variable."
See RM 3.7 (28)
http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-3-7.html

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Jeffrey R. Carter]

On 09/13/2017 08:34 PM, Egil H H wrote:
> On Wednesday, September 13, 2017 at 6:34:43 PM UTC+2, Jeffrey R. Carter wrote:
>>
>> No. If you supply a discriminant, the object is constrained to that subtype.
>> Only is you do not supply a discriminant is the object unconstrained.
>>
> 
> That's wrong.
> 
> "If a discriminated type has default_expressions for its discriminants, then unconstrained variables of the type are permitted, and the values of the discriminants can be changed by an assignment to such a variable."
> See RM 3.7 (28)
> http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-3-7.html

Let's try it:

procedure Egilhh is
    type R (D : Integer := 0) is null record;

    C : R (D => 3);
begin -- Egilhh
    C := (D => 4);
end Egilhh;

$ gnatmake egilhh.adb
gcc-6 -c egilhh.adb
egilhh.adb:6:06: warning: incorrect value for discriminant "d"
egilhh.adb:6:06: warning: "Constraint_Error" will be raised at run time
gnatbind-6 -x egilhh.ali
gnatlink-6 egilhh.ali
$ ./egilhh

raised CONSTRAINT_ERROR : egilhh.adb:6 discriminant check failed

Unconstrained variables of the type are permitted, but so are constrained 
variables of the type. You declare an unconstrained variable by not providing a 
discriminant. You declare a constrained variable by providing the discriminant. 
This has been true since Ada 83. See the examples at the end of ARM 3.7.1:

15
Large   : Buffer(200);  --  constrained, always 200 characters
                         --   (explicit discriminant value)
Message : Buffer;       --  unconstrained, initially 100 characters
                         --   (default discriminant value)

-- 
Jeff Carter
"If a sperm is wasted, God gets quite irate."
Monty Python's the Meaning of Life
56

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Alejandro R. Mosteo]

On 13/09/17 18:34, Jeffrey R. Carter wrote:
> On 09/13/2017 03:07 PM, Alejandro R. Mosteo wrote:
>> On 12/09/17 19:43, Jeffrey R. Carter wrote:
>>> On 09/12/2017 04:36 PM, Egil H H wrote:
>>>> On Tuesday, September 12, 2017 at 3:43:40 PM UTC+2, Dmitry A. 
>>>> Kazakov wrote:
>>>>> So it can do with the custom type:
>>>>>
>>>>> with Ada.Text_IO;  use Ada.Text_IO;
>>>>> procedure Test is
>>>>>      Max : constant := 1000;
>>>>>      subtype Max_Length is Natural range 0..Max;
>>>>>      type Bounded (Size : Max_Length := Max_Length'Last) is record
>>>>>         Length : Max_Length := 0;
>>>>>         Text   : String (1..Size);
>>>>>      end record;
>>>>>
>>>> ...
>>>>>      Y : Bounded (10);
>>>>
>>>> Also, allocating 1000 Characters for a string of max length 10 is 
>>>> hardly an optimal solution...
>>>
>>> If an actual discriminant is provided, the default is not used. This 
>>> only allocates 10 characters.
>>
>> Just going back to my basics, I think it's been years since I used 
>> default discriminants. In such a case, if I tried to later assign a 
>> larger instance to this Y, would it work, given that only 10 chars 
>> were allocated initially?
> 
> No. If you supply a discriminant, the object is constrained to that 
> subtype. Only is you do not supply a discriminant is the object 
> unconstrained.

Thanks (also for the demo), I suspected as much.

Then I guess that an in/out parameter of such a type might be unsafe to 
assign, in the sense that depending on the actual argument it might 
succeed or raise.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[J-P. Rosen]

Le 14/09/2017 à 14:30, Alejandro R. Mosteo a écrit :
> Then I guess that an in/out parameter of such a type might be unsafe to
> assign, in the sense that depending on the actual argument it might
> succeed or raise.
Right, but the 'Constrained attribute tells you (within the subprogram)
whether the actual parameter can mutate or not

-- 
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: Community Input for the Maintenance and Revision of the Ada Programming Language

[Jeffrey R. Carter]

On 09/14/2017 02:30 PM, Alejandro R. Mosteo wrote:
> 
> Then I guess that an in/out parameter of such a type might be unsafe to assign, 
> in the sense that depending on the actual argument it might succeed or raise.

Typically I return them from functions, but I'd think between your knowledge of 
the discriminants and maybe the 'Constrained attribute you could use them safely.

-- 
Jeff Carter
"I'm off to Alaska. If you need me, I'll be at
Frozen Tundra 6-9290."
Play It Again, Sam
130

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

"Egil H H" <ehh.public@gmail.com> wrote in message 
news:5126ef7a-3324-4e44-b110-5e4838189f5f@googlegroups.com...
...
> Get off your high horse, for a change.

Except that in this case he's absolutely right. Anyone that thinks that a 
bounded string is preferable to an unbounded string or fixed string is 
rather confused (at a minimum, depending on compiler-specific behavior).

                           Randy.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Simon Wright]

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

> That nobody actually uses bounded strings does not necessary mean that
> there is no use of bounded strings. Maybe people are uneducated, have
> prejudices etc. But no the thing is indeed useless, therefore not
> used. Could be quietly removed from the standard, nobody would
> notice...

I have *good reason* to use bounded strings. As I said earlier in the
thread.

Of course I agree that for most people, most of the time, fixed or
unbounded strings are what's needed.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 12/09/2017 16:55, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> That nobody actually uses bounded strings does not necessary mean that
>> there is no use of bounded strings. Maybe people are uneducated, have
>> prejudices etc. But no the thing is indeed useless, therefore not
>> used. Could be quietly removed from the standard, nobody would
>> notice...
> 
> I have *good reason* to use bounded strings. As I said earlier in the
> thread.

Embedded gives even less incentive for bounded strings due to their poor 
memory footprint and performance loss caused by algorithm based on 
assigning strings. If you don't assign strings you don't need 
bounded-length ones. For accumulators in embedded I am customary use a 
stream backed by a String.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:op8mio$1scc$1@gioia.aioe.org...
...
>> You may not have need for it. That doesn't necessarily make it true
>> for the rest of the world.
> I didn't say that. I said that there is no use case for it. Which is not 
> same. Regarding the rest of the world, it is even simpler. It is a mere 
> empirical fact relatively easy to measure. Take available Ada code base 
> and compare how frequently various types of strings are used there.
>
> That nobody actually uses bounded strings does not necessary mean that 
> there is no use of bounded strings. Maybe people are uneducated, have 
> prejudices etc. But no the thing is indeed useless, therefore not used. 
> Could be quietly removed from the standard, nobody would notice...

Tom used bounded strings in some parts of the Claw interface (I forget 
exactly which ones). The underlying Win32 record types acted like a bounded 
string, so it probably seemed like a reasonable mapping. So I can say 
conclusively that there is at least one use of a bounded string out there, 
and Claw would break if the package was removed.

But using them is a pain-in-the-a**. I'd much rather that the types had been 
mapped to regular fixed strings.

In general, I agree with you; Bounded strings have no real use (especially 
on Janus/Ada, where the implementation of a generic like that uses implicit 
heap allocation anyway - so there is no practical difference between it and 
unbounded strings).

                                              Randy.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Simon Wright]

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

> Tom used bounded strings in some parts of the Claw interface (I forget
> exactly which ones). The underlying Win32 record types acted like a
> bounded string, so it probably seemed like a reasonable mapping. So I
> can say conclusively that there is at least one use of a bounded
> string out there, and Claw would break if the package was removed.
>
> But using them is a pain-in-the-a**. I'd much rather that the types
> had been mapped to regular fixed strings.

I quite agree that using bunded strings in a public interface is a
mistake.

> In general, I agree with you; Bounded strings have no real use
> (especially on Janus/Ada, where the implementation of a generic like
> that uses implicit heap allocation anyway - so there is no practical
> difference between it and unbounded strings).

I have a requirement (based on an interface to an external entity) to
store quite a few names of length no more than 14 characters. It seems
reasonable to implement the storage using Bounded_Strings (unless of
course the GNAT overhead gets too much).

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[G.B.]

On 03.10.17 09:48, Simon Wright wrote:

> I have a requirement (based on an interface to an external entity) to
> store quite a few names of length no more than 14 characters. It seems
> reasonable to implement the storage using Bounded_Strings (unless of
> course the GNAT overhead gets too much).

GNAT sources say that the compiler "special cases" Bounded_String,
referring to its own Ada.Strings.Superbounded.

In this package, the type Super_String is a discriminated record,
and then

    type Bounded_String is
      new Superbounded.Super_String (Max_Length);

where

    type Super_String (Max_Length : Positive) is record
       Current_Length : Natural := 0;
       Data           : String (1 .. Max_Length);
       --  ... comments only ...
    end record;


Is it really possible to create less overhead? E.g., by using
allocators, storage pools, and adding string operations as
necessary?

(But, still, predefined string types from the Ada library
depend on types Positive and Natural with their implementation
defined ranges. I understand that the 'Size of these types
is 16 in Janus/Ada?)

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-10-03 11:34, G.B. wrote:

> (But, still, predefined string types from the Ada library
> depend on types Positive and Natural with their implementation
> defined ranges. I understand that the 'Size of these types
> is 16 in Janus/Ada?)

I don't see this as a big problem so long you physically could not 
create larger String objects, e.g. because of the memory architecture.

It is not much different from Stream_Element_Array using 
Stream_Element_Offset.

Some time ago GNAT changed Stream_Element_Offset from 32 to 64 bits on 
32-bit machines. Same can be done for Integer.

Anyway it brings back the argument of bounded-length strings design. The 
size of Integer is not an issue for String because it acts as a 
*constraint*, not as a type property. This does not make any program 
illegal. So long you don't *actually* try to exceed the constraint, 
nothing bad happens. It is not very likely you would actually use 
strings larger than 32K.

Now if size/bound becomes a type or object property that makes some 
programs illegal.

Arguably that could be desirable if the bound comes from the problem 
space. However in most cases it is just more or less arbitrary design 
choice which will hit you hard later if you were too generous.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[G.B.]

On 03.10.17 12:11, Dmitry A. Kazakov wrote:
>  It is not very likely you would actually use strings larger than 32K.

When a program reads a text file, of size > 32K, into some string
("into memory"), this can make text processing a lot easier. Just
think about implementing an abstraction that allows scanning the
entire text in case there is no string large enough to contain it.

Writing a parser seems less likely and more demanding than feeding
a 32+K string to some text processing routine (counting, searching,
substituting, ...). There are fewer corner cases to consider, the
program does not need state for remembering the previous line's
final words, and so forth.

> Now if size/bound becomes a type or object property that makes some programs illegal.
> 
> Arguably that could be desirable if the bound comes from the problem space. However in most cases it is just more or less arbitrary design choice which will hit you hard later if you were too generous.
> 

Indeed, suppose designating parts of strings, such as elements or
slices, were available through some types more targeted than mere
Positive. This choice directly leads to more flexibility, too.

For illustration, making Swift 2, 3, and now 4 has included much work
on overhauling NSString, so that now, in current Swift, it has
become String, and Substring, together with associated types for
iteration, slicing, and so forth.


String is the aftermath of our own bias when commencing the
work of formalization by analyzing our writing. It permeates
all programming to an extent that may be in the way of seeing
proper abstractions. It's close to making

    array (Positive range <>)

be so ubiquitous that it appears in the public interface
of just about any private type. And the above one doesn't,
does it?

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-10-03 15:25, G.B. wrote:
> On 03.10.17 12:11, Dmitry A. Kazakov wrote:
>>  It is not very likely you would actually use strings larger than 32K.
> 
> When a program reads a text file, of size > 32K, into some string
> ("into memory"), this can make text processing a lot easier.

Single line is sufficient, if that is a text file.

> Just
> think about implementing an abstraction that allows scanning the 
> entire text in case there is no string large enough to contain it.

That is a text buffer. Implementing text buffer on top of a single 
string is a bad idea.

> String is the aftermath of our own bias when commencing the
> work of formalization by analyzing our writing. It permeates
> all programming to an extent that may be in the way of seeing
> proper abstractions. It's close to making
> 
>     array (Positive range <>)
> 
> be so ubiquitous that it appears in the public interface
> of just about any private type. And the above one doesn't,
> does it?

Same as number. Sequence of characters is a useful concept. And a 
fruitful interface of a user type.

You can declare your own string type with the index type you wanted, but 
you cannot put it in the same class with String because Ada does not 
have abstract array interface.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:oqvnnn$19se$1@gioia.aioe.org...
> On 2017-10-03 11:34, G.B. wrote:
>
>> (But, still, predefined string types from the Ada library
>> depend on types Positive and Natural with their implementation
>> defined ranges. I understand that the 'Size of these types
>> is 16 in Janus/Ada?)
>
> I don't see this as a big problem so long you physically could not create 
> larger String objects, e.g. because of the memory architecture.

You can, however.

> It is not much different from Stream_Element_Array using 
> Stream_Element_Offset.
>
> Some time ago GNAT changed Stream_Element_Offset from 32 to 64 bits on 
> 32-bit machines. Same can be done for Integer.

There is no real problem in doing that, but it would make virtually all 
binary files (Sequential_IO, Direct_IO, and streams) incompatible. That's 
the main reason that we've never changed it.

> Anyway it brings back the argument of bounded-length strings design. The 
> size of Integer is not an issue for String because it acts as a 
> *constraint*, not as a type property. This does not make any program 
> illegal. So long you don't *actually* try to exceed the constraint, 
> nothing bad happens. It is not very likely you would actually use strings 
> larger than 32K.

I have, unintentionally in the spam filter. Spammers try to do everything 
possible in spam to break spam filters, and that includes sending messages 
without any line breaks. That has occassionally resulted in messages that 
exceeded the capacity of an Unbounded_String. (I used Unbounded_Strings to 
hold lines as an experiment; I consider the experiment failed, but changing 
the code is more work than it is worth.)

                              Randy.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

"G.B." <bauhaus@notmyhomepage.invalid> wrote in message 
news:oqvlie$lh9$1@dont-email.me...
> On 03.10.17 09:48, Simon Wright wrote:
> Is it really possible to create less overhead? E.g., by using
> allocators, storage pools, and adding string operations as
> necessary?

Yes, because I'd solve Simon's problem with a record (and have done so 
repeatedly):

    type Simon_Strings is
         Data : String (1..14);
         Len : Natural;
    end record;

And that has less overhead than the discriminated string type. (Not a lot 
less, but definitely less.)

> (But, still, predefined string types from the Ada library
> depend on types Positive and Natural with their implementation
> defined ranges. I understand that the 'Size of these types
> is 16 in Janus/Ada?)

Yup. One can define a string type in Janus/Ada using Long_Integer, and I've 
occassionally done that. I have had programs run into the 32767 character 
limit in the Unbounded string case; another reason that depending on 
predefined types is evil.

                             Randy.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

"Egil H H" <ehh.public@gmail.com> wrote in message 
news:2deb28e2-f7e8-4461-b8b8-c2c6cf2784aa@googlegroups.com...
> On Tuesday, September 12, 2017 at 12:22:12 PM UTC+2, Dmitry A. Kazakov 
> wrote:
>>
>> Yes, but they would be different. A more close example would be:
>>
>> type Bounded_String (Bound : Natural := Max) is record
>>     Length : Natural := 0;
>>     Text   : String (1..Bound);
>> end record;
>>
>
> Well, I don't have unlimited memory, so allocating Natural'Last number
> of Characters for all my strings is not an option for me, but I guess 
> YMMV.

This works fine on a properly implemented compiler (i.e. Janus/Ada). There 
is no reason that this record type shouldn't be required to work on all 
compilers, except sloth. (Yes, it would have to be disallowed in 
circumstances where no implicit heap operations are allowed, but that's no 
reason to deny that to everyone else.)

Pet peeve.

                     Randy.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Jeffrey R. Carter]

On 09/12/2017 08:18 AM, Tarjei Jensen wrote:
> 
> A counted string can be viewed as
> 
> type counted_string is record
>     max : natural;
>     len : natural;
>     str : array range ( 1 .. max) of character;
> end record;

This is, of course, illegal.

> The best known environment which uses counted strings is Turbo Pascal. Note that I wrote "uses". It is still being used in education.

In Ada 12, you can have something similar to Turbo Pascal's strings:

with Ada.Strings;

package B_Strings is
    type B_String (Max_Length : Positive := 1_000) is tagged limited private;
    -- This works in Ada 12 and only allocates Max_Length.
    -- Default initial value is Null_B_String

    Null_B_String : constant B_String; -- A string of zero characters

    function To_String (Source : B_String) return String;
    function "+" (Source : B_String) return String renames To_String;
    -- Lower bound of result is 1; upper bound is Length (Source)

    function To_B_String (Source : String) return B_String;
    function "+" (Source : String) return B_String renames To_B_String;
    -- Result's Max_Length will be Max (Source'Length, 1)

    function Length (Source : B_String) return Natural;

    Too_Long : exception;

    procedure Assign (To : in out B_String; From : in B_String; Drop : in 
Ada.Strings.Truncation := Ada.Strings.Error);
    -- Gives To the same value as From
    -- If Drop = Error and Length (From) > To.Max_Length, raises Too_Long
    -- To is unchanged if Too_Long is raised

    procedure Assign (To : in out B_String; From : in String; Drop : in 
Ada.Strings.Truncation := Ada.Strings.Error);
    -- Same as Assign (To => To, From => +From, Drop => Drop);

    function "="  (Left : B_String; Right : B_String) return Boolean;
    function "<"  (Left : B_String; Right : B_String) return Boolean;
    function "<=" (Left : B_String; Right : B_String) return Boolean;
    function ">"  (Left : B_String; Right : B_String) return Boolean;
    function ">=" (Left : B_String; Right : B_String) return Boolean;
private -- B_Strings
    type B_String (Max_Length : Positive := 1_000) is tagged limited record
       Len   : Natural := 0;
       Value : String (1 .. Max_Length) := (1 .. Max_Length => ' ');
    end record;

    Null_B_String : constant B_String := (Max_Length => 1, others => <>);
end B_Strings;

For earlier versions of Ada, you can eliminate the default for Max_Length, which 
may be even closer to what TP provides.

-- 
Jeff Carter
"Why don't you bore a hole in yourself and let the sap run out?"
Horse Feathers
49

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[G.B.]

On 11.09.17 20:49, Tarjei Jensen wrote:
> It is time to get counted strings into the standard.
>
> The key to counted strings is that they need to be first class objects. The compiler must know how to handle them. Just like it would do when it handles integers or reals of different sizes. You don't have to overload := in order to assign a byte sized integer to a word sized integer. And you don't need to overload operators to add or subtract them.

      1. procedure Integer_2 is
      2.    type I16 is range 0 .. 100 with Size => 16;
      3.    type I32 is range 0 .. 100_000 with Size => 32;
      4.    X16 : I16;
      5.    X32 : I32;
      6. begin
      7.    X32 := 100_000;
      8.    X16 := I16 (X32);
                   |
         >>> warning: value not in range of type "I16" defined at line 2
         >>> warning: "Constraint_Error" will be raised at run time

      9.    X16 := 100_000;
                   |
         >>> value not in range of type "I16" defined at line 2
         >>> static expression fails Constraint_Check

     10. end Integer_2;

So, an Ada compiler handles this by explaining that one cannot
simply assign any number to any numeric variable. In the first
case, even type conversion is diagnosed to be a predictably bad
idea.

> I strongly believe that implementing it as a general Ada feature will be ineffective. I know that it will be tempting to do so, but RESIST!!!!!!
>
> I also believe that educators will welcome such a move. Especially those who remember Turbo Pascal.
>

Educators have done enough harm by iterating what you suggest.

Low level strings for high level needs? Strings?

Group pressure and imitation make educators force students into
using string literals and string I/O heavily.  Professional
programming makes me think that there shouldn't be any plain strings
in any of today's programs. They can be replaced by typed objects
that are modeled observing their use case. Then, all the trouble of
representation using strings is hidden behind the walls of an ADT
and if you make a new string based ADT, you'll be forced to think
about what it shall mean to perform a type conversion. I'm not sure
compilers can take care of that.  If they can ease string handling,
that's good, but not the end. And Ada can already help with this, see
below. But text types can be expected to be more expressive and less
hardware-ish than any plain composite of whatever characters.

Consider this analogy.  When using numbers, many programmers
will have a range or set in mind, and some operations. Limits are a
first lesson which running a programs will teach when it exceeds
them. Big integers are not an option whenever they do not match
number representations in I/O. Bytes and words, OTOH---these are any
number of what are typically octets---are used in bit fiddling, not
so much when performing "+". Besides, when talking about numbers,
saying "bytes" and "words" can only be justified by crowd misuse.
I'll be surprised if more than a few programmers even know the
definition of "byte" in C. "Word"? Everyone feels justified, however,
because everyone else around them creates the same assumption based
results.

Why teach that again?

Note that in case you find a good reason for using strings, it is
quite possible to use a storage pool. Then, from this pool, simply
use allocators:

    X := new Message' ("Help me");
    Y := new Messagio'("Aiuta me");

    --  entering Little Italy:

    X := Y;

So, if you want to perpetuate the hazards of strings, ask the ARG
for a ready made storage pool for strings.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 12/09/2017 23:04, G.B. wrote:

>     X := new Message' ("Help me");
>     Y := new Messagio'("Aiuta me");
> 
>     --  entering Little Italy:
> 
>     X := Y;

Shudder.

> So, if you want to perpetuate the hazards of strings, ask the ARG
> for a ready made storage pool for strings.

What is so specific about string storage pool?

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[G.B.]

On 13.09.17 09:30, Dmitry A. Kazakov wrote:
> On 12/09/2017 23:04, G.B. wrote:
>
>>     X := new Message' ("Help me");
>>     Y := new Messagio'("Aiuta me");
>>
>>     --  entering Little Italy:
>>
>>     X := Y;
>
> Shudder.
>
>> So, if you want to perpetuate the hazards of strings, ask the ARG
>> for a ready made storage pool for strings.
>
> What is so specific about string storage pool?

The fact that the pool will be there, doing its work without
being noticed, to please those customers who don't like thinking
about string handling and associated storage management.

Also, IF a teacher feels inclined to teach programming using
strings, she won't have to first teach all the things that
are necessary to develop a deeper understanding of what
a string actually is.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-09-13 19:39, G.B. wrote:
> On 13.09.17 09:30, Dmitry A. Kazakov wrote:
>> On 12/09/2017 23:04, G.B. wrote:
>>
>>>     X := new Message' ("Help me");
>>>     Y := new Messagio'("Aiuta me");
>>>
>>>     --  entering Little Italy:
>>>
>>>     X := Y;
>>
>> Shudder.
>>
>>> So, if you want to perpetuate the hazards of strings, ask the ARG
>>> for a ready made storage pool for strings.
>>
>> What is so specific about string storage pool?
> 
> The fact that the pool will be there, doing its work without
> being noticed, to please those customers who don't like thinking
> about string handling and associated storage management.

Which work? Do you mean garbage collection here? That is not specific to 
strings and not much interesting for Ada.

> Also, IF a teacher feels inclined to teach programming using
> strings, she won't have to first teach all the things that
> are necessary to develop a deeper understanding of what
> a string actually is.

I think it is more important for students to understand the basic ideas 
of object representation along with the concept of ADT. One does not 
work without another and algorithmic costs of the choices must be 
understood from the beginning. (This is what differentiates software 
design from mathematics)

Furthermore your example exempts assignment as something special. 
Assignment is a normal type operation. Then your example sweeps object 
life time problematic under the carpet which is a key topic. It is 
important to prevent students thinking in terms of global objects. In 
fact, from the example it is hardly possible to identify objects as it 
deploys a layer of references upon original objects with ADTs of both 
mingled together in order to appear same. How are you going to explain 
all that?

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[G.B.]

On 13.09.17 21:34, Dmitry A. Kazakov wrote:
> On 2017-09-13 19:39, G.B. wrote:
>> On 13.09.17 09:30, Dmitry A. Kazakov wrote:
>>> On 12/09/2017 23:04, G.B. wrote:
>>>
>>>>     X := new Message' ("Help me");
>>>>     Y := new Messagio'("Aiuta me");
>>>>
>>>>     --  entering Little Italy:
>>>>
>>>>     X := Y;
>>>
>>> Shudder.
>>>
>>>> So, if you want to perpetuate the hazards of strings, ask the ARG
>>>> for a ready made storage pool for strings.
>>>
>>> What is so specific about string storage pool?
>>
>> The fact that the pool will be there, doing its work without
>> being noticed, to please those customers who don't like thinking
>> about string handling and associated storage management.
>
> Which work?

OT: "The key to counted strings is that they need to be first class objects.
  The compiler must know how to handle them."

Thus, the work of handling strings. Strings in particular, because apparently
teachers think that they teach something valuable when they suggest
using natural language strings or other semi-formal lumps of characters
in a formal program's text.


> I think it is more important for students to understand the basic ideas of object representation along with the concept of ADT. One does not work without another and algorithmic costs of the choices must be understood from the beginning.

Sure, if CS education wishes to focus on high quality technical
systems, then understanding those basics (including cost)
seems like a good idea. Not so, when some funding organization's
focus is on writing macros in VB, or when "scripting" a framework,
or when preparing for sales of low wage GTD opportunities
in international outsourcing business.

  (This is what differentiates software design from mathematics)

Let's say that, seeing A. Perlis and A. Stepanov as professional
mathematicians, there is an attitude---surely not theirs---that tries
hard to make computation be classified information never to be
shown to others. It is a mistake, though, to think that only the
"result" of a computation is important, in that all of the
computation affects "world". When and to what extent does this
"extended result" affect {plan, system, supplier, customer}?
Can you sell the effects?

This is a challenging research topic for mathematicians specializing
in programming:

  - to not exclude operations' effects from function specifications
    (yes, specifications; it is partly done already when their
     descriptions mention amortized cost)

  - to include more effects of operations when describing results.

Counted strings, then, serve the attitude that tries to indeed
move education under the carpet (compiler), and for strings only.
(Because, then, you don't _need_ to teach all those things that
make counted strings work, and you move on to the _important_
stuff...)


> Furthermore your example

tries to allude to what might be a long term effect of counted
string equivalents on professional programming if you use them
in education, which you had explained further.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 14/09/2017 08:57, G.B. wrote:
> On 13.09.17 21:34, Dmitry A. Kazakov wrote:
>> On 2017-09-13 19:39, G.B. wrote:
>>> On 13.09.17 09:30, Dmitry A. Kazakov wrote:
>>>> On 12/09/2017 23:04, G.B. wrote:
>>>>
>>>>>     X := new Message' ("Help me");
>>>>>     Y := new Messagio'("Aiuta me");
>>>>>
>>>>>     --  entering Little Italy:
>>>>>
>>>>>     X := Y;
>>>>
>>>> Shudder.
>>>>
>>>>> So, if you want to perpetuate the hazards of strings, ask the ARG
>>>>> for a ready made storage pool for strings.
>>>>
>>>> What is so specific about string storage pool?
>>>
>>> The fact that the pool will be there, doing its work without
>>> being noticed, to please those customers who don't like thinking
>>> about string handling and associated storage management.
>>
>> Which work?
> 
> OT: "The key to counted strings is that they need to be first class 
> objects.
>   The compiler must know how to handle them."

Both is wrong.

1. Bounded-length strings need not to be first class if the language 
type system capable of handling them. Ada's type system almost can, up 
to the moment when the user-defined object must expose array interface.

2. The compiler need not to know anything beyond user-provided 
implementation of the ADT.

> Thus, the work of handling strings. Strings in particular, because 
> apparently
> teachers think that they teach something valuable when they suggest
> using natural language strings or other semi-formal lumps of characters
> in a formal program's text.

Why these must be strings and why this specific kind of string?

Remember that bounded-length strings are in most cases premature 
optimization, because problem space bound either does not exist (e.g. 
non-static) or unknown. So the teacher is supposed to explain why X must 
be up to 100 characters long? Then the very idea of assigning strings is 
bad.

> Let's say that, seeing A. Perlis and A. Stepanov as professional
> mathematicians, there is an attitude---surely not theirs---that tries
> hard to make computation be classified information never to be
> shown to others. It is a mistake, though, to think that only the
> "result" of a computation is important, in that all of the
> computation affects "world". When and to what extent does this
> "extended result" affect {plan, system, supplier, customer}?
> Can you sell the effects?

You seem equate single act of computation and a process continuous 
computations, i.e. in a control loop.

Furthermore, there is a question of abstraction, At each level of 
abstraction there are exposed computational elements and hidden 
implementation-defined ones.

Anyway, if you consider computation so important for education, then you 
should not ask hiding memory management and issues of string assignment 
from the students.

> This is a challenging research topic for mathematicians specializing
> in programming:
> 
>   - to not exclude operations' effects from function specifications
>     (yes, specifications; it is partly done already when their
>      descriptions mention amortized cost)
> 
>   - to include more effects of operations when describing results.

OK

> Counted strings, then, serve the attitude that tries to indeed
> move education under the carpet (compiler), and for strings only.
> (Because, then, you don't _need_ to teach all those things that
> make counted strings work, and you move on to the _important_
> stuff...)

and in plain contradiction to the stated goals...

>> Furthermore your example
> 
> tries to allude to what might be a long term effect of counted
> string equivalents on professional programming if you use them
> in education, which you had explained further.

Yes, wrong paradigms have those effects. Not a reason to adhere to them.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[reinert]

Not a big issue, but why does not this function:

    if t1 < Clock and Clock < t2 then ...

Should it?

Example code below for testing.

reinert

with Text_IO;
use  Text_IO;
with Ada.Calendar;
use Ada.Calendar;
procedure test1i is
 t1,t2 : time;
begin
 t1 := Clock + 10.0;
 t2 := Clock + 20.0;

-- bla bla..

--  if t1 < Clock and Clock < t2 then -- this function
    if Clock in t1 .. t2 then         -- this dows *not* function
       Put_Line(" Here A ");
    end if;
end test1i;

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Jeffrey R. Carter]

On 10/02/2017 12:06 PM, reinert wrote:
>   t1,t2 : time;
> begin
>   t1 := Clock + 10.0;
>   t2 := Clock + 20.0;
> 
> --  if t1 < Clock and Clock < t2 then -- this function
>      if Clock in t1 .. t2 then         -- this dows *not* function

What do you mean by "function"?

-- 
Jeff Carter
"He that hath no beard is less than a man."
Much Ado About Nothing
132

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[reinert]

On Monday, October 2, 2017 at 3:54:54 PM UTC+2, Jeffrey R. Carter wrote:
> On 10/02/2017 12:06 PM, reinert wrote:
> >   t1,t2 : time;
> > begin
> >   t1 := Clock + 10.0;
> >   t2 := Clock + 20.0;
> > 
> > --  if t1 < Clock and Clock < t2 then -- this function
> >      if Clock in t1 .. t2 then         -- this dows *not* function
> 
> What do you mean by "function"?

Sorry. I did mean "works" ("it functions = it works" ?)

English is only my third language :-)

Try the test program, or read the code, and you may understand my question :-)

reinert

> 
> -- 
> Jeff Carter
> "He that hath no beard is less than a man."
> Much Ado About Nothing
> 132

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dennis Lee Bieber]

ONE: Your question has nothing to do with "Community Input ... Revision
..." You really should have started a new topic rather than making your
question a reply to an existing thread.

TWO: It would have helped if you provided a description of what you
expected vs what you got from the program -- instead making one recreate
your program to test (UGH -- GPS 2017 looks ugly compared to what I've used
for the last decade or so).

On Mon, 2 Oct 2017 03:06:43 -0700 (PDT), reinert <reinkor@gmail.com>
declaimed the following:

>Not a big issue, but why does not this function:
>
>    if t1 < Clock and Clock < t2 then ...
>
>Should it?
>

	That snippet seems to work fine.

>Example code below for testing.
>
>reinert
>
>with Text_IO;
>use  Text_IO;
>with Ada.Calendar;
>use Ada.Calendar;
>procedure test1i is
> t1,t2 : time;
>begin
> t1 := Clock + 10.0;
> t2 := Clock + 20.0;
>
>-- bla bla..
>
>--  if t1 < Clock and Clock < t2 then -- this function
>    if Clock in t1 .. t2 then         -- this dows *not* function

	Well -- GNAT 2017 reports "scalar type required for range", which seems
rather self-explanatory... t1, t2, and by association, the value returned
from Clock, are not "scalar" values.

	"Time" type is defined as "private" in the standard, so could be made
up of anything internally. The comparison operator "<" (and others) are
defined in the calendar package, so are available for use in the first form
of the "if" statement.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[G.B.]

On 02.10.17 12:06, reinert wrote:
> Not a big issue, but why does not this function:
>
>     if t1 < Clock and Clock < t2 then ...
>
> Should it?

The compiler should accept because the line means

     if "<" (clock, t1) and "<" (clock, t2) then ...

and "<" is defined for Time values.

But the order of evaluation is not determined when writing
the expression in the above way.
    First, "and" is different from "and then". This should
matter when calling Clock if real time is intrinsically sequential.
Second, consider reasons why in SPARK Ada you'll be asked
to always store the result of Clock into a variable (or
constant) by assignment and then use that variable.


>     if Clock in t1 .. t2 then         -- this dows *not* function


     14.     if Clock in t1 .. t2 then         -- this dows *not* function
                            |
         >>> scalar type required for range

This does not work because Time is not a scalar type, even though
time per se, if measured in seconds, say, can make one think it is
of a scalar type. But type Time is private, in Ada, an abstract
point in time, not a number of time units.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[reinert]

On Monday, October 2, 2017 at 5:02:16 PM UTC+2, G.B. wrote:
......
> 
>      14.     if Clock in t1 .. t2 then         -- this dows *not* function
>                             |
>          >>> scalar type required for range
> 
> This does not work because Time is not a scalar type, even though
> time per se, if measured in seconds, say, can make one think it is
> of a scalar type. But type Time is private, in Ada, an abstract
> point in time, not a number of time units.

I thought "x in a..b" was (should be?) short for "a <= x and x <= b"
(where x, a and b are elements in a (strict) linearly ordered set or so).

Here is inspiration: https://en.wikipedia.org/wiki/Total_order

reinert
 

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-10-02 18:23, reinert wrote:
> On Monday, October 2, 2017 at 5:02:16 PM UTC+2, G.B. wrote:
> ......
>>
>>       14.     if Clock in t1 .. t2 then         -- this dows *not* function
>>                              |
>>           >>> scalar type required for range
>>
>> This does not work because Time is not a scalar type, even though
>> time per se, if measured in seconds, say, can make one think it is
>> of a scalar type. But type Time is private, in Ada, an abstract
>> point in time, not a number of time units.
> 
> I thought "x in a..b" was (should be?) short for "a <= x and x <= b"
> (where x, a and b are elements in a (strict) linearly ordered set or so).

Yes, but there is no Time interval type defined in Ada, alas. t1..t2 is 
an expression resulting in an interval.

The right way, considering that Clock is not constant, is:

    Clock - t1 in 0..t2 - t1 then

or, considering implied semantics, simply

    if Clock <= Deadline then

or

    if Clock - Started_At <= Timeout then

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[reinert]

On Monday, October 2, 2017 at 6:38:07 PM UTC+2, Dmitry A. Kazakov wrote:
> On 2017-10-02 18:23, reinert wrote:
> > On Monday, October 2, 2017 at 5:02:16 PM UTC+2, G.B. wrote:
> > ......
> >>
> >>       14.     if Clock in t1 .. t2 then         -- this dows *not* function
> >>                              |
> >>           >>> scalar type required for range
> >>
> >> This does not work because Time is not a scalar type, even though
> >> time per se, if measured in seconds, say, can make one think it is
> >> of a scalar type. But type Time is private, in Ada, an abstract
> >> point in time, not a number of time units.
> > 
> > I thought "x in a..b" was (should be?) short for "a <= x and x <= b"
> > (where x, a and b are elements in a (strict) linearly ordered set or so).
> 
> Yes, but there is no Time interval type defined in Ada, alas. t1..t2 is 
> an expression resulting in an interval.
> 
> The right way, considering that Clock is not constant, is:
> 
>     Clock - t1 in 0..t2 - t1 then
> 
> or, considering implied semantics, simply
> 
>     if Clock <= Deadline then
> 
> or
> 
>     if Clock - Started_At <= Timeout then
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

OK, but conceptually, putting technicality aside, for any two time points, t1 and t2, a third time, t, is such that t1 <= t <= t2 or not. This is (logically) well defined. 

"t1 <= t <= t2" is in mathematical contexts often written "t \in [t1,t2]" where [t1,t2] is thought about as a time interval. It is not a good idea to have a concept of "time intervals" in Ada?

This may though not be a large question :-)

reinert

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-10-02 19:19, reinert wrote:

> "t1 <= t <= t2" is in mathematical contexts often written "t \in
> [t1,t2]" where [t1,t2] is thought about as a time interval. It is not a
> good idea to have a concept of "time intervals" in Ada?

It is a good idea except that Ada does not have means for that. Ranges 
in Ada are hard-wired non-entities.

> This may though not be a large question :-)

To hack it is probably not a big issue, and therefore you will get no 
support for pushing it through. Otherwise, it is a huge problem to get 
first-class ranges and slices with proper types and operations on them. 
Therefore you will get no support either. This or that way it won't 
happen...

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Jeffrey R. Carter]

On 10/02/2017 06:23 PM, reinert wrote:
> 
> I thought "x in a..b" was (should be?) short for "a <= x and x <= b"
> (where x, a and b are elements in a (strict) linearly ordered set or so).

No, "in" checks whether a value is a member of a subtype:

value in subtype_name

value in Low .. High

is shorthand for

value in Subtype_Name range Low .. High

where Subtype_Name is a scalar subtype. This is itself shorthand for

subtype anonymous is Subtype_Name range Low .. High;

value in anonymous

Note that you can do

type T (D : Boolean) is private;
subtype TF is T (D => False);
subtype TT is T (D => True);

V : T (D => Boolean'Value (Get_Line) );

if V in TT then

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Jeffrey R. Carter]

On 10/02/2017 06:23 PM, reinert wrote:
> 
> I thought "x in a..b" was (should be?) short for "a <= x and x <= b"
> (where x, a and b are elements in a (strict) linearly ordered set or so).

No, "in" checks whether a value is a member of a subtype:

value in subtype_name

value in Low .. High

is shorthand for

value in Subtype_Name range Low .. High

where Subtype_Name is a scalar subtype. This is itself shorthand for

subtype anonymous is Subtype_Name range Low .. High;

value in anonymous

Note that you can do

type T (D : Boolean) is private;
subtype TF is T (D => False);
subtype TT is T (D => True);

V : T (D => Boolean'Value (Get_Line) );

if V in TT then

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[reinert]

I noticed that my compiler did not like for example:

  t1 : time := clock + 10.0;
  t2 : time := t1 + 20.0;
  t3 : time range t1 + 10.0 .. t2 + 30.0;


No room for syntactic sugar here? :-)

reinert

On Monday, October 2, 2017 at 9:14:06 PM UTC+2, Jeffrey R. Carter wrote:
> On 10/02/2017 06:23 PM, reinert wrote:
> > 
> > I thought "x in a..b" was (should be?) short for "a <= x and x <= b"
> > (where x, a and b are elements in a (strict) linearly ordered set or so).
> 
> No, "in" checks whether a value is a member of a subtype:
> 
> value in subtype_name
> 
> value in Low .. High
> 
> is shorthand for
> 
> value in Subtype_Name range Low .. High
> 
> where Subtype_Name is a scalar subtype. This is itself shorthand for
> 
> subtype anonymous is Subtype_Name range Low .. High;
> 
> value in anonymous
> 
> Note that you can do
> 
> type T (D : Boolean) is private;
> subtype TF is T (D => False);
> subtype TT is T (D => True);
> 
> V : T (D => Boolean'Value (Get_Line) );
> 
> if V in TT then
> 
> -- 
> Jeff Carter
> "He nevere yet no vileynye ne sayde
> In al his lyf unto no maner wight."
> Canterbury Tales
> 156

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[G.B.]

On 03.10.17 05:30, reinert wrote:
> I noticed that my compiler did not like for example:
> 
>    t1 : time := clock + 10.0;
>    t2 : time := t1 + 20.0;
>    t3 : time range t1 + 10.0 .. t2 + 30.0;
> 
> 
> No room for syntactic sugar here? :-)

For a start, the compiler has no idea what "20.0" should
mean with regard to Time.

Sweets are available from the time unit sellers:
 From Ada.Calendar, you'll get ranges of Year_Number or
Day_Duration or ....
These will all be the result of calling functions that
take Time values and help the programmer to state his
idea of "20.0".
A chapter in Barnes's book shows how to add sugar.

There is more in the Ada.Real_Time store.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[reinert]

On Tuesday, October 3, 2017 at 8:36:22 AM UTC+2, G.B. wrote:
> On 03.10.17 05:30, reinert wrote:
> > I noticed that my compiler did not like for example:
> > 
> >    t1 : time := clock + 10.0;
> >    t2 : time := t1 + 20.0;
> >    t3 : time range t1 + 10.0 .. t2 + 30.0;
> > 
> > 
> > No room for syntactic sugar here? :-)
> 
> For a start, the compiler has no idea what "20.0" should
> mean with regard to Time.
> 

My compiler (gnat on debian) says "clock + 20" means 20 seconds 
into the future :-)  Assuming I have not misunderstood.

reinert

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-10-04 21:21, reinert wrote:

> My compiler (gnat on debian) says "clock + 20" means 20 seconds
> into the future :-)  Assuming I have not misunderstood.

You can add Duration to Time, and get Time back. Then it must be this:

    T : Time := Clock + 20.0; -- OK, 20.0 is Duration, seconds

But this is illegal:

    T : Time := Clock + 20; -- 20 is integer literal

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[G.B.]

On 04.10.17 21:21, reinert wrote:
> On Tuesday, October 3, 2017 at 8:36:22 AM UTC+2, G.B. wrote:
>> On 03.10.17 05:30, reinert wrote:
>>> I noticed that my compiler did not like for example:
>>>
>>>     t1 : time := clock + 10.0;
>>>     t2 : time := t1 + 20.0;
>>>     t3 : time range t1 + 10.0 .. t2 + 30.0;
>>>
>>>
>>> No room for syntactic sugar here? :-)
>>
>> For a start, the compiler has no idea what "20.0" should
>> mean with regard to Time.
>>
> 
> My compiler (gnat on debian) says "clock + 20" means 20 seconds
> into the future :-)  Assuming I have not misunderstood.

That was confused. What I meant was that
    20.0 Time
has no meaning, since time (moment) is not itself countable,
but duration or span are.

Ada ranges would also be used in for loops that make the program
step through the set of values of the range:

    for Moment in Candy_Time range t1 .. t2 loop
       null;  --  How many iterations will there be?
    end loop;

No such problem when using countable units of time:

    procedure Candy is
       T1 : Day_Number := Day (Clock);
       T2 : Day_Number := T1 + 10;
    begin
       for Day in Day_Number range t1 .. t1 loop
          null;  -- 10 + 1 iterations!
       end loop;
    end Candy;

Thus, by use of proper types the program becomes predictable
at the source level.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 2017-10-04 23:45, G.B. wrote:

> Ada ranges would also be used in for loops that make the program
> step through the set of values of the range:

Only ranges of discrete types. Float range cannot be enumerated.

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[G.B.]

On 05.10.17 00:04, Dmitry A. Kazakov wrote:
> On 2017-10-04 23:45, G.B. wrote:
> 
>> Ada ranges would also be used in for loops that make the program
>> step through the set of values of the range:
> 
> Only ranges of discrete types.

Yes. Good hint at Time, also?

> Float range cannot be enumerated.

Actually, it depends. Just like there are functions that
compute discrete values from Time arguments, there are
functions that compute a finite set of values from Float
arguments. But these are not of a discrete type.

    procedure Enumerate_Float (A, B : Float) is
       P : Integer;
       F : Float;
    begin
       P := 0;
       F := A;
       loop
          exit when F > B;

          Eio.Put (P); Fio.Put (F); New_Line;

          P := Integer'Succ (P);
          F := Float'Succ (F);
       end loop;
    end Enumerate_Float;

  But there is no automatic stepping through the values of
a floating point subtype's range, using a for loop.
I cannot see a meaningful use case.

Considering types of 2D object, people might want to have
the notion of *range* include the idea of areas in the plane...
Is there a 2D time, BTW?

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dmitry A. Kazakov]

On 05/10/2017 08:50, G.B. wrote:
> On 05.10.17 00:04, Dmitry A. Kazakov wrote:
>> On 2017-10-04 23:45, G.B. wrote:
>>
>>> Ada ranges would also be used in for loops that make the program
>>> step through the set of values of the range:
>>
>> Only ranges of discrete types.
> 
> Yes. Good hint at Time, also?

Time values are ordered, thus there is nothing except language type 
system weakness to prevent them from having ranges of:

    subtype Victorian_Time is
       Time range Time_Of (1837, 6, 20)
               .. Time_Of (1901, 1, 22);

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

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Daniel Norte Moraes]

Hi! I Will really like added:

1) Support for infinite precision, limited only by memory, for decimal, integer and float.
1.1) and means of changing the internal representation of binary to text (and vice versa) for these types.
1.2) equivalent packages for trigonometry to rational and complex types, too.

How a design start and ideias, I Believe that already have very good packages in use, a) first for Ada MPFR binds and b) recently I discover a good promise in this url http://web.am.qub.ac.uk/users/j.parker/miscellany/arbitrary/ 

For now, 
Thanks in Advance!

[]'s Dani.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:...
> ISO/IEC JTC 1/SC 22/WG 9 (WG 9) is responsible for the maintenance and 
> revision of the Ada Programming Language ...

The commented on announcement should be widely distributed. If you know of 
some other place where Ada users hang out, feel free to post it or link to 
the AdaIC copy (see below). (The Ada Redit group comes to mind, but there 
must be others.)

I see that the cut-and-paste has put a number of question marks into this 
announcement. The copy on AdaIC is probably more readable: 
http://www.adaic.org/2017/08/community-input-for-ada/.

We've been waiting on posting this announcement until WG 9 has finished 
voting on the proposed work plan. So it is now official; we're planning on 
completing the next revision for standardization in 2020 (which means 
completing work in summer 2019).

                 Randy Brukardt, ARG Editor.

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dirk Craeynest]

In article <oludp8$skl$1@franka.jacob-sparre.dk>,
Randy Brukardt <randy@rrsoftware.com> wrote:
>The commented on announcement should be widely distributed. If you know of 
>some other place where Ada users hang out, feel free to post it or link to 
>the AdaIC copy (see below). (The Ada Redit group comes to mind, but there 
>must be others.)
>
>I see that the cut-and-paste has put a number of question marks into this 
>announcement. The copy on AdaIC is probably more readable: 
>http://www.adaic.org/2017/08/community-input-for-ada/.

FYI, I've posted a pointer to various LinkedIn groups, i.e.
- Ada Programming Language
- SPARK User Community
- Safety-Critical Systems Club
- Ada for Microcontrollers
- Parallel Computing in Ada
- Ada Programming Language in Safety-Critical Systems

Dirk
Dirk.Craeynest@cs.kuleuven.be (for Ada-Belgium/Ada-Europe/SIGAda/WG9)

*** 23rd Intl.Conf.on Reliable Software Technologies - Ada-Europe'2018
*** June 18-22, 2018 ** Lisbon, Portugal *** http://www.ada-europe.org

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Dirk Craeynest]

Dirk Craeynest <dirk@feles.cs.kuleuven.be.> wrote:

>Randy Brukardt <randy@rrsoftware.com> wrote:
>>http://www.adaic.org/2017/08/community-input-for-ada/.
>
>FYI, I've posted a pointer to various LinkedIn groups, i.e.
[...]

FWIW, I also announced the URL on Twitter using hashtags #Ada2020
and #AdaProgramming.

Dirk
Dirk.Craeynest@cs.kuleuven.be (for Ada-Belgium/Ada-Europe/SIGAda/WG9)

*** 23rd Intl.Conf.on Reliable Software Technologies - Ada-Europe'2018
*** June 18-22, 2018 ** Lisbon, Portugal *** http://www.ada-europe.org

Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Randy Brukardt]

"Dirk Craeynest" <dirk@feles.cs.kuleuven.be.> wrote in message 
news:olur5p$7d2$1@dont-email.me...
...
> FYI, I've posted a pointer to various LinkedIn groups, i.e.
> - Ada Programming Language
> - SPARK User Community
> - Safety-Critical Systems Club
> - Ada for Microcontrollers
> - Parallel Computing in Ada
> - Ada Programming Language in Safety-Critical Systems

Thanks, Dirk.

                  Randy.

Community Input for the Maintenance and Revision of the Ada Programming Language

[laguest9000]

ISO/IEC JTC 1/SC 22/WG 9 (WG 9) is responsible for the maintenance and
revision of the Ada Programming Language and associated standards and
technical reports. As part of the language maintenance activity, WG 9 has
established a group of Ada experts as the Ada Rapporteur Group (ARG). The
ARG receives input from the Ada community at large to consider for inclusion
in revision to the Ada programming language standard. The WG 9 has produced
a number of revisions to the language in accordance with ISO policy and
to address the evolution of technology (Ada 83, Ada 95, Ada 2005, Ada 2012).

Presently, the ARG is beginning work on a revision to Ada 2012 so that ISO
standardization of the new version can be completed by 2020. This is a
relatively short horizon, but it ensures that the language continues to
evolve, and at the same time requires that the changes to the language are
evolutionary and do not present an undue implementation burden on existing
compilers and users.

WG 9 requests the Ada community to submit enhancements to be considered for
inclusion in the next revision of Ada. These should be sent to
ada-c@ada-auth.org as described in the Ada Reference Manual
Introduction
(http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-0-3.html#p58). For
enhancement requests, it is very important to describe the programming
problem and why the Ada 2012 solution is complex, expensive, or impossible.
A detailed description of a specific enhancement is welcome but not
necessarily required. The goal of the ARG is to solve as many
programming problems as possible with new/enhanced Ada features that fit
into the existing Ada framework. Thus the ARG will be looking at
the language as a whole, which may suggest alternative solutions to
the problem posed by an enhancement request. For a more detailed discussion,
the guidelines presented for the Ada 2005 revision (see
http://archive.adaic.com/news/pressrelease/call4apis.html) can be used as
the ARG requirements are little changed.

WG9 accepts enhancement requests at any time. To be considered for inclusion
in the next revision of Ada, enhancement requests must be received by 15
January 2018. Suggestions received after that date may be considered if
they relate to topics already under development; others will be considered
only for future versions of Ada.

WG 9 has directed the ARG to focus its work on three areas of particular
interest to the Ada community: additional facilities for multi-core and
multithreaded programming, improved facilities for program correctness, and
enhanced container libraries. There are numerous proposed enhancements in
these and other areas. Some of these proposals originated with members of
the ARG, and others from members of the community at large. The interested
reader can find the current state of these at
http://www.ada-auth.org/AI12-SUMMARY.HTML.

WG 9 encourages members of the Ada community at large to use the guidelines
outlined above to provide input to WG 9 and the ARG for needed revisions and
upgrades to the Ada programming language.